Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Jack Howarth wrote: Huh? What problems? I've have... ii qt33.3.8-1028 Cross-Platform GUI application framework ii qt3-designer 3.3.8-1028 Cross-Platform GUI application framework ii qt3-designer-s 3.3.8-1028 Cross-Platform GUI application framework ii qt3-doc3.3.8-1028 Cross-Platform GUI application framework ii qt3-linguist 3.3.8-1028 Cross-Platform GUI application framework ii qt3-shlibs 3.3.8-1028 Cross-Platform GUI application framework under x86_64 fink on SL. I've also built the qt4-x11 packages for paraview without issues on x86_64 fink. Sorry, I wasn't precise enough: AFAICT, qt3mac and qt4-mac don't build on Snow Leopard (32bit or 64bit), and qt3 and qt4-x11 don't build on Snow Leopard (32bit). The only ones that build on Snow Leopard are qt3 and qt4-x11 (64bit). Anyway, trying to have both 32bit and 64bit for both Leopard and Snow Leopard, and to have an upgrade path from 32bit 10.5 to 32bit 10.6 was probably a mistake, given the currently available manpower. Realistically, Fink should have stated: Leopard = 32bit Snow Leopard = 64bit and to go from one to the other you have to reinstall, sorry. I don't see any evidence of any Fink developer besides drm having ever seriously tried to build packages on 10.5/64bit or on 10.6/32bit. And drm is just eliminating packages that don't build; *nobody* is spending time trying to fix packages for 10.6/32bit. -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
On Aug 30, 2009, at 5:42 PM, Martin Costabel wrote: Jack Howarth wrote: Huh? What problems? I've have... ii qt33.3.8-1028 Cross-Platform GUI application framework ii qt3-designer 3.3.8-1028 Cross-Platform GUI application framework ii qt3-designer-s 3.3.8-1028 Cross-Platform GUI application framework ii qt3-doc3.3.8-1028 Cross-Platform GUI application framework ii qt3-linguist 3.3.8-1028 Cross-Platform GUI application framework ii qt3-shlibs 3.3.8-1028 Cross-Platform GUI application framework under x86_64 fink on SL. I've also built the qt4-x11 packages for paraview without issues on x86_64 fink. Sorry, I wasn't precise enough: AFAICT, qt3mac and qt4-mac don't build on Snow Leopard (32bit or 64bit), and qt3 and qt4-x11 don't build on Snow Leopard (32bit). The only ones that build on Snow Leopard are qt3 and qt4-x11 (64bit). By the way, in my 32bit build run currently underway (stable tree), qt3 built without errors. qt3mac was eliminated a few days ago when it failed to build on either 32bit or 64bit. -- Dave -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
On Sun, Aug 30, 2009 at 10:42:31AM +0200, Martin Costabel wrote: Anyway, trying to have both 32bit and 64bit for both Leopard and Snow Leopard, and to have an upgrade path from 32bit 10.5 to 32bit 10.6 was probably a mistake, given the currently available manpower. Realistically, Fink should have stated: Leopard = 32bit Snow Leopard = 64bit and to go from one to the other you have to reinstall, sorry. I don't see any evidence of any Fink developer besides drm having ever seriously tried to build packages on 10.5/64bit or on 10.6/32bit. And drm is just eliminating packages that don't build; *nobody* is spending time trying to fix packages for 10.6/32bit. -- Martin Well, I do keep i386 and x86_64 fink on both my 10.5.8 and 10.6 machines and always make sure that my packages build on those and powerpc 10.5.8. I find it hard to criticize the decision to implement x86_64 on 10.5 fink since we wouldn't have made half of the progress in porting packages to x86_64 without it. I do think we really should have some guidelines for porting to x86_64 though. While it might not always be necessary, it should be best practices to always pass... --build=%m-apple-darwin`uname -r|cut -f1 -d.` --host=%m-apple-darwin`uname -r|cut -f1 -d.` to ConfigureParams. Having configure find the wrong triplet is just asking for trouble at some point. It also might be wise to not assume all code is 64-bit clean and add some automated checks to fink that would trigger a warning in -m mode if errors like... cast from pointer to integer of different size are observed during the CompileScript execution. This would at least clue in packagers to consult on fink-devel for solutions. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
My own instinct is that (considering the lack of manpower in fink these days) rolling our own X11 is only asking for trouble. Also do we know for certain that there won't be beta releases of a Xquartz release for Snow Leopard much sooner than that? I would think our resources would be better utilized by focusing on the x86_64 transition. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
William G. Scott wrote: Hi folks: After upgrading, I discovered that the SL (10.6) distributed X11.app clobbers the X11.app v. 2.4.0 I had installed, and (unlike with 10.5.X point updates), there are no plans to release an X11.app update before ca. December. So this means users who linked to recently released X11.app libraries will likely experience problems. Is this something we should address? The libraries in question appear to include the following: Regressions from X11.app 2.4.0 to SL X11.app /usr/X11/lib/libOSMesa.4.dylib not present in SL X11 /usr/X11/lib/libxcb-xlib.0.dylib not present in SL X11 /usr/X11/lib/libxcb-keysyms.1.dylib not present in SL X11 /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0 vs 6.0.0 in X11 2.4.0) /usr/X11/lib/libpng.3.dylib (compatibility version 39.0.0 vs 41.0.0 in X11 2.4.0) /usr/X11/lib/libpng12.0.dylib (compatibility version 36.0.0, vs 38.0.0 in X11 2.4.0) Ideally the libpng version shouldn't matter, since Fink packages are supposed to use fink's libpng--not that this always happens. /usr/X11/lib/libxcb-randr.0.dylib (compatibility version 1.0.0 vs 2.0.0 in X11 2.4.0) Of these, I've only run into problems with /usr/X11/lib/libfontconfig. 1.dylib so far (and lazily swiped the later version from another computer to resolve the problem). The X11.app upgrade pathway appears to be a source of user frustration. Would fink be better served to have its own X11 installation, as we did back with 10.4 and earlier? Bill This isn't any different than the usual issues we've had on 10.5, when you get down to it. System updates cause regressions with respect the libraries in Xquartz, and Xcode updates regress the headers and libtool archives (not to mention just clobbering them outright). The position has always been: users are free to use the unofficial Xquartz update, but they need to reinstall it after updating anything, as is explicitly mentioned on its download page. What would solve this problem, in my opinion, would be 1) More virtual packages, corresponding to libraries from X11 2) Getting automatic shlibs resolution working. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
William G. Scott wrote: Hi folks: After upgrading, I discovered that the SL (10.6) distributed X11.app clobbers the X11.app v. 2.4.0 I had installed, and (unlike with 10.5.X point updates), there are no plans to release an X11.app update before ca. December. So this means users who linked to recently released X11.app libraries will likely experience problems. Is this something we should address? The libraries in question appear to include the following: Regressions from X11.app 2.4.0 to SL X11.app /usr/X11/lib/libOSMesa.4.dylib not present in SL X11 /usr/X11/lib/libxcb-xlib.0.dylib not present in SL X11 /usr/X11/lib/libxcb-keysyms.1.dylib not present in SL X11 /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0 vs 6.0.0 in X11 2.4.0) /usr/X11/lib/libpng.3.dylib (compatibility version 39.0.0 vs 41.0.0 in X11 2.4.0) /usr/X11/lib/libpng12.0.dylib (compatibility version 36.0.0, vs 38.0.0 in X11 2.4.0) /usr/X11/lib/libxcb-randr.0.dylib (compatibility version 1.0.0 vs 2.0.0 in X11 2.4.0) Of these, I've only run into problems with /usr/X11/lib/libfontconfig. 1.dylib so far (and lazily swiped the later version from another computer to resolve the problem). The X11.app upgrade pathway appears to be a source of user frustration. Would fink be better served to have its own X11 installation, as we did back with 10.4 and earlier? Bill I didn't realize when I wrote my prior message that it was the _Xquartz_ update that wasn't going to be put into release until December. Maybe it's worth amending our update instructions to say Don't bother trying to update in place if you've been using Xquartz. Do an install from scratch instead. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
This isn't any different than the usual issues we've had on 10.5, when you get down to it. System updates cause regressions with respect the libraries in Xquartz, and Xcode updates regress the headers and libtool archives (not to mention just clobbering them outright). One HUGE important difference is before, one could always simply reinstall the Xquartz latest version, but in this case, the installer prevents you from doing so (it has to be 10.5) and no 10.6-compatible update is planned prior to December. As a maintainer, it looks as if the only thing I can do is to throw everything into the fire and recompile fink from scratch, to find out if they still compile. The position has always been: users are free to use the unofficial Xquartz update, but they need to reinstall it after updating anything, as is explicitly mentioned on its download page. That's the rub. You _can't_ reinstall, (and there is no prior warning of this). What would solve this problem, in my opinion, would be 1) More virtual packages, corresponding to libraries from X11 2) Getting automatic shlibs resolution working. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Alexander Hansen wrote: [] I didn't realize when I wrote my prior message that it was the _Xquartz_ update that wasn't going to be put into release until December. The problem appears only if xquartz-2.4.0 was installed. If no Fink package was built against anything more recent than xquartz-2.3.x, this problem does not appear. But there is the problem of the missing *.la files that has not been solved yet, and it is probably too late now. Maybe it's worth amending our update instructions to say Don't bother trying to update in place if you've been using Xquartz. Do an install from scratch instead. Instead of if you've been using Xquartz, make this if you've been using Xquartz-2.4.0 or if you intend to build any X11-related package. -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
On Sat, Aug 29, 2009 at 09:58:06AM -0400, Alexander Hansen wrote: This isn't any different than the usual issues we've had on 10.5, when you get down to it. System updates cause regressions with respect the libraries in Xquartz, and Xcode updates regress the headers and libtool archives (not to mention just clobbering them outright). [...] What would solve this problem, in my opinion, would be 1) More virtual packages, corresponding to libraries from X11 2) Getting automatic shlibs resolution working. That won't help because the X11 updates are outside of fink's control. Installer.app doesn't know and doesn't care if it downgrades or removes a certain dylib and in the process breaks a fink package's dependency on that newer one. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
As shown from the response I posted from Jeremy Huddleston at Apple, it won't help waiting for Xquartz on SL because all the files in Xquartz will be relocated into /opt to survive system software updates. This brings up the question of how we are going to handle this relocation in the first place. Two X11 instllations will reside on the machine and we need to decide which one to use. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
I got a clarification from Jeremy about the X11 support in MacPorts. They went through a phase when building against both the system and MacPorts X11 was allowed. Now everything must build against the MacPorts X11 or it is considered a packaging bug. I don't know if anyone here wants to assume that level of responsibility. If we do the same for fink, the proper maintenance of the fink X11 package will be hypercritical. We would really need a Xquartz developer to take it on for the job to be properly done since we would be depreciating both the fink and Xquartz X11 for builds. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Jack Howarth wrote: I got a clarification from Jeremy about the X11 support in MacPorts. They went through a phase when building against both the system and MacPorts X11 was allowed. Now everything must build against the MacPorts X11 or it is considered a packaging bug. I don't know if anyone here wants to assume that level of responsibility. If we do the same for fink, the proper maintenance of the fink X11 package will be hypercritical. We would really need a Xquartz developer to take it on for the job to be properly done since we would be depreciating both the fink and Xquartz X11 for builds. Jack We gave up on having our own X11 because it was a royal pain to deal with supporting both ours and Apple's. (had we decided to force everybody to use our xorg-6.8 package at that time, it might have made support a heck of a lot easier, though). It seemed a good idea at the time. Reality If the current Xorg supports installation within the Fink tree instead of /usr/X11, that would certainly help, but it's probably going to be a royal nasty pain to make every X11-using package look there rather than in the system area. On the other hand, since there's no fink X11 for Leopard, under a scenario where we can install an X11 distro in our own tree, deprecating the system's X11 seems to me to be possible via a new fink which turns off the system-X11 detection, leaving a fink-packaged real X11 as the only eligible provider of the x11 virtual packages; provided that we go through the pain of making our packages do the right thing. Do we have the skilled-person-hours to pull it off, though? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Alexander Hansen wrote: [] Do we have the skilled-person-hours to pull it off, though? We have a couple of more important things to do: For example, accept the texlive package and make a system-tex package, so that the tetex mess can be cleaned up once and for all; For example, make qt3 and qt4 build on Snow Leopard, so that the hundreds of packages can be built that depend on these; For example, identify the reasons why many other packages don't build on Snow Leopard. -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Martin Costabel wrote: Alexander Hansen wrote: [] Do we have the skilled-person-hours to pull it off, though? We have a couple of more important things to do: For example, accept the texlive package and make a system-tex package, so that the tetex mess can be cleaned up once and for all; For example, make qt3 and qt4 build on Snow Leopard, so that the hundreds of packages can be built that depend on these; For example, identify the reasons why many other packages don't build on Snow Leopard. Maybe I'm misremembering, but did Okayama's texlive package not install everything? If so, would we need a system-tex package? It was dropped on 10.5, after all, because the maintainer decided it was too much of a headache due to upstreams doing stuff with each update that broke his efforts. And the whole X11 experience on 10.5 has shown us how difficult it can be to deal with big packages that are outside of the Fink distribution. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Huh? What problems? I've have... ii qt33.3.8-1028 Cross-Platform GUI application framework ii qt3-designer 3.3.8-1028 Cross-Platform GUI application framework ii qt3-designer-s 3.3.8-1028 Cross-Platform GUI application framework ii qt3-doc3.3.8-1028 Cross-Platform GUI application framework ii qt3-linguist 3.3.8-1028 Cross-Platform GUI application framework ii qt3-shlibs 3.3.8-1028 Cross-Platform GUI application framework under x86_64 fink on SL. I've also built the qt4-x11 packages for paraview without issues on x86_64 fink. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Martin Costabel wrote: Alexander Hansen wrote: Martin Costabel wrote: Alexander Hansen wrote: [] Do we have the skilled-person-hours to pull it off, though? We have a couple of more important things to do: For example, accept the texlive package and make a system-tex package, so that the tetex mess can be cleaned up once and for all; For example, make qt3 and qt4 build on Snow Leopard, so that the hundreds of packages can be built that depend on these; For example, identify the reasons why many other packages don't build on Snow Leopard. Maybe I'm misremembering, but did Okayama's texlive package not install everything? I have been using it for months without problem. I think I had to do something about the beamer class that came with it, but I don't remember now what it was. If so, would we need a system-tex package? It was dropped on 10.5, after all, because the maintainer decided it was too much of a headache due to upstreams doing stuff with each update that broke his efforts. But that was years ago. The texlive that everyone is installing now has stabilised long ago. And the whole X11 experience on 10.5 has shown us how difficult it can be to deal with big packages that are outside of the Fink distribution. True, if one wants to be perfect. But a simple system-tex package should be possible that blames the user for any insufficiency of the installed tex distribution. Hasn't such a thing been in the submission tracker for quite some time, too? It was flagged as awaiting core decision, and core didn't think it was needed. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Alexander Hansen wrote: Martin Costabel wrote: Alexander Hansen wrote: [] Do we have the skilled-person-hours to pull it off, though? We have a couple of more important things to do: For example, accept the texlive package and make a system-tex package, so that the tetex mess can be cleaned up once and for all; For example, make qt3 and qt4 build on Snow Leopard, so that the hundreds of packages can be built that depend on these; For example, identify the reasons why many other packages don't build on Snow Leopard. Maybe I'm misremembering, but did Okayama's texlive package not install everything? I have been using it for months without problem. I think I had to do something about the beamer class that came with it, but I don't remember now what it was. If so, would we need a system-tex package? It was dropped on 10.5, after all, because the maintainer decided it was too much of a headache due to upstreams doing stuff with each update that broke his efforts. But that was years ago. The texlive that everyone is installing now has stabilised long ago. And the whole X11 experience on 10.5 has shown us how difficult it can be to deal with big packages that are outside of the Fink distribution. True, if one wants to be perfect. But a simple system-tex package should be possible that blames the user for any insufficiency of the installed tex distribution. Hasn't such a thing been in the submission tracker for quite some time, too? -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] SL X11.app regressions relative to X11.app 2.4.0
Hi folks: After upgrading, I discovered that the SL (10.6) distributed X11.app clobbers the X11.app v. 2.4.0 I had installed, and (unlike with 10.5.X point updates), there are no plans to release an X11.app update before ca. December. So this means users who linked to recently released X11.app libraries will likely experience problems. Is this something we should address? The libraries in question appear to include the following: Regressions from X11.app 2.4.0 to SL X11.app /usr/X11/lib/libOSMesa.4.dylib not present in SL X11 /usr/X11/lib/libxcb-xlib.0.dylib not present in SL X11 /usr/X11/lib/libxcb-keysyms.1.dylib not present in SL X11 /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0 vs 6.0.0 in X11 2.4.0) /usr/X11/lib/libpng.3.dylib (compatibility version 39.0.0 vs 41.0.0 in X11 2.4.0) /usr/X11/lib/libpng12.0.dylib (compatibility version 36.0.0, vs 38.0.0 in X11 2.4.0) /usr/X11/lib/libxcb-randr.0.dylib (compatibility version 1.0.0 vs 2.0.0 in X11 2.4.0) Of these, I've only run into problems with /usr/X11/lib/libfontconfig. 1.dylib so far (and lazily swiped the later version from another computer to resolve the problem). The X11.app upgrade pathway appears to be a source of user frustration. Would fink be better served to have its own X11 installation, as we did back with 10.4 and earlier? Bill -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
