[Fink-devel] Fioricet, Soma, Buspar, Prozac, and more Prescribed Online and Shipped to Your Door
Order Confirmation. Your order should be shipped by January, via FedEx. Your Federal Express tracking number is. Thank you for registering. Wholesale Prescription Medications! OUR DOCTORS WILL WRITE YOU A PRESCRIPTION FOR FREE Buy Your Prescription Meds Online Lowest Prices No Prior Prescription Required Click Here Upon Approval, Our US Licensed Doctors will Prescribe Your Medication For Free And Have the Medication Shipped Overnight To Your Door. We assure you the absolute best value on the Internet. Click Here Medications for: Weight Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's Health, Impotence, Allergy Relief, Heartburn Relief, Migraine Relief Medications like: Phentermine, Adipex, Soma, Fioricet, Ultram, Celebrex, Viagra, Valtrex, Zyban, and many, many more. Click Here remove me from your list jeyo m pl y ylvhducv efad ogtgbjjppgw tmzp fubd e zpznkyuwonpmc jf gfeyydruortxd vqgouz fw
Fwd: [Fink-devel] Epoch
Anfang der weitergeleiteten E-Mail: Von: Max Horn [EMAIL PROTECTED] Datum: Do, 6. Mär 2003 13:14:15 Europe/Berlin An: Ben Hines [EMAIL PROTECTED] Betreff: Re: [Fink-devel] Epoch Am Donnerstag, 06.03.03 um 04:12 Uhr schrieb Ben Hines: On Wednesday, March 5, 2003, at 10:14 AM, Max Horn wrote: At 12:29 Uhr -0500 05.03.2003, Benjamin Reed wrote: Max Horn wrote: But my motivation to agree to this is most definitely not due to what the debian policy says. We are not debian! Sure we can look at how they do things, and if we like it, do it the same way, but I feel in no way bound to this. In particular, they ask to avoid epochs as much as possible, with no reason given (that I could find, please quote to prove me differently, would be much appreciated). The only reason given was by Kyle and others, which is that Epochs have to stay around the whole life time of a package... now, how is that a problem? I honestly don't see how it is a problem, so any explanation would be much appreciated, too. The reason I see it as a problem is just as a usability issue. Packagers will know what version 1:3.0.2-4 means, but regular users won't. Usually there should be no need to display the epoch to end users at all... Bute no need to argue much about this, if we all can agree to the 0 trick you proposed .. um, Max, the 0 trick is completely consistent with my views and debian's policy. How does debian's policy and your views differ again, explain in slow words so i can understand. :) Sure I am always willing to help the slow witted. 8-) I ... am ... not ... agreeing ... with ... the ... quote: It is not intended to cope with version numbers containing strings of letters which the package management system cannot interpret. I ... am ... only ... willing ... to ... agree ... to ... this ... 0 ... approach ... as ... a ... compromise ... because ... everybody ... seems ... to ... want ... to ... avoid ... epochs ... for ... this ... purpose. I ... do ... not ... agree ... with ... the ... reasoning ... though. But ... I ... do not ... care ... too ... strongly ... about ... it. Max --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] system-emacs?
Am Donnerstag, 06.03.03 um 04:14 Uhr schrieb Ben Hines: On Wednesday, March 5, 2003, at 10:42 AM, David R. Morrison wrote: If you want to use the system emacs, don't make it depend on the emacsen-common, and make sure that emacs is called as /usr/bin/emacs. or just let it use either one, unless it depends on the features of a particular version. Hm, so where and how does he install the elisp files so that both emacsen can find it (the system one and the fink one) ? (I did never bother to instlal extensions to emacs so I don't know, this is not meant as flame bait but a serious question :-) Max --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1
I have upgraded xfree86 to 4.3.0 with the xfree86-upgrade script. gtk+2 cannot compile and exits with: checking for IceConnectionNumber in -lICE... yes checking for XRenderFindFormat in -lXrender... yes checking for XftFontOpen in -lXft... yes checking X11/Xft/XftFreetype.h usability... no checking X11/Xft/XftFreetype.h presence... no checking for X11/Xft/XftFreetype.h... no configure: error: pangoxft Pango backend found, but Xft not found ### execution of ./configure failed, exit code 1 Failed: compiling gtk+2-2.0.9-3 failed does pango need a recompile - which other packages too?? thanks, thomas -- thomas kotzian, [EMAIL PROTECTED] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1
Am Donnerstag, 06.03.03 um 14:54 Uhr schrieb thomas kotzian: I have upgraded xfree86 to 4.3.0 with the xfree86-upgrade script. gtk+2 cannot compile and exits with: checking for IceConnectionNumber in -lICE... yes checking for XRenderFindFormat in -lXrender... yes checking for XftFontOpen in -lXft... yes checking X11/Xft/XftFreetype.h usability... no checking X11/Xft/XftFreetype.h presence... no checking for X11/Xft/XftFreetype.h... no configure: error: pangoxft Pango backend found, but Xft not found ### execution of ./configure failed, exit code 1 Failed: compiling gtk+2-2.0.9-3 failed does pango need a recompile - which other packages too?? AFAIK GTK+ 2.0.x doesn't work with XFree86 4.3, while 2.1 doesn't work with XFree86 4.2, or something like this. Masanori sent a post on this subject some time ago (which was never addressed, hence I was somewhat upset when XFree86 4.3 was put into unstable w/o taking care of this... but that's past now shrug) Maybe for the time being, we should add a Conflicts to GTK+2 that prevents it from being used with XFree86. Max --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1
On jeudi, mars 6, 2003, at 14:54 Europe/Paris, thomas kotzian wrote: [] configure: error: pangoxft Pango backend found, but Xft not found ### execution of ./configure failed, exit code 1 Failed: compiling gtk+2-2.0.9-3 failed does pango need a recompile - which other packages too?? This was already on the beginners and users lists, and it is mentioned in the pango description. Recompile doesn't work, the packages need to be ported to xfree-4.3.0. I said it some time ago, but it was considered too pessimistic at that time: The upgrade from xfree-4.2 to 4.3 has some unpleasant similarities to the Jaguar upgrade. - There are packages that won't compile under 4.3 - Packages and libraries compiled under 4.3 will not work under 4.2, in general, so you can't go back. In general may concern only very few packages if we are lucky. - The threaded vs non-threaded issue has not been solved. Threaded is now the default, so on the subject of Matlab, the ball is in Apple's/Matlab's field now, but the fact remains that Matlab doesn't work with 4.3.0. IMHO there should be some big red warnings somewhere. -- Martin --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1
David R. Morrison wrote: [] Martin, I'd like to understand this situation better. Are there specific libraries which have been updated for 4.3? Were the updates done in a properly versioned manner? If so, then packages which are compiled under 4.3 will link to the new versions, and packages compiled under 4.2 will link to the old versions. So long as we keep the different versions in separate fink packages, a smooth transition should be possible. Here is, for example, a list of libraries in 4.3.0 that aren't in 4.2.1 /usr/X11R6_4.3.0/lib/libOSMesa.4.0.dylib /usr/X11R6_4.3.0/lib/libXcursor.1.0.dylib /usr/X11R6_4.3.0/lib/libXft.2.0.dylib /usr/X11R6_4.3.0/lib/libXft.2.1.dylib /usr/X11R6_4.3.0/lib/libXrandr.2.0.dylib /usr/X11R6_4.3.0/lib/libXrender.1.2.dylib /usr/X11R6_4.3.0/lib/libXv.1.0.dylib /usr/X11R6_4.3.0/lib/libexpat.1.0.dylib /usr/X11R6_4.3.0/lib/libfontconfig.1.0.dylib /usr/X11R6_4.3.0/lib/libfreetype.6.3.dylib Some of them are higher versions (Xft, Xrandr, Xrender, freetype), and the others must correspond to new APIs which I don't know anything about. The updated ones are done in a proper manner, so that compatibility is guaranteed in one direction, at least. But I suspect that as soon as you start compiling things under 4.3.0, there will be conflicts of the libpng/libpng3 variety (one version of library loaded directly, another one indirectly - crash) Then, as has been detected from the case of pango, some headers have disappeared in 4.3.0. Others are new in 4.3.0. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)
On Mar 6,2003 21:45:17 +0100, Martin Costabel [EMAIL PROTECTED] wrote : But I suspect that as soon as you start compiling things under 4.3.0, there will be conflicts of the libpng/libpng3 variety (one version of library loaded directly, another one indirectly - crash) Well, I hope not. I still don't fully understand what is happening with the libpng/libpng3 business, but I strongly suspect the following scenario. You ask fink to install foo and it also requires bar so fink is going to install both at once. Let's say foo depends on libpng3 and bar depends on libpng. What does fink do? 1) First loads libpng3 because thats what foo wants 2) Next loads libpng because thats what bar wants 3) Successfully compiles bar, linked to libpng. 4) Manages to compile foo, with libpng still installed, because the dependecies are not checked a second time just prior to building. As far as I can tell, you would be able to build foo with libpng headers installed, just fine. Everything will have libpng support compiled in, and then at link time, you are linking against libpng3.dylib and all symbols are successfully resolved, so everything is still fine. It is only at execution time that the mismatch is detected. Does this scenario make sense to anyone else? Has anybody seen a symptom which is not consistent with this? -- Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)
David R. Morrison wrote: Well, I hope not. I still don't fully understand what is happening with the libpng/libpng3 business, but I strongly suspect the following scenario. You ask fink to install foo and it also requires bar so fink is going to install both at once. Let's say foo depends on libpng3 and bar depends on libpng. What does fink do? 1) First loads libpng3 because thats what foo wants 2) Next loads libpng because thats what bar wants 3) Successfully compiles bar, linked to libpng. 4) Manages to compile foo, with libpng still installed, because the dependecies are not checked a second time just prior to building. Yup, I'm pretty sure that's how it's triggered. That also supports the fact that a rebuild of the offending package usually puts it right as well. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)
David R. Morrison wrote: [] As far as I can tell, you would be able to build foo with libpng headers installed, just fine. Everything will have libpng support compiled in, and then at link time, you are linking against libpng3.dylib and all symbols are This part I don't understand: How would foo even know that it wants to link against libpng.3.dylib when it only sees libpng.2.dylib during build time? It links to -lpng, and /sw/lib/libpng.dylib is a symlink to libpng.2.dylib in your scenario. successfully resolved, so everything is still fine. It is only at execution time that the mismatch is detected. In the case of the gimp help browser, the scenario was different, I think, and not caused by any problem with Fink's build process, but by a principal problem of the shlibs policy: gimp-1.2.3-10 (this was the version that showed the problem, the newer one eliminated it by depending on libpng3) build-depends on libpng and depends on libpng-shlibs. The gimp helpbrowser of this version therefore links with libpng.2.dylib. It also links with libgtkxmhtml.1.dylib from gnome-libs-shlibs. So far no problem, while the latter links with libpng.2.dylib, too. Next, gnome-libs-shlibs is upgraded to a new version that has a dependency on libpng3. libgtkxmhtml.1.dylib now links with libpng.3.dylib. When helpbrowser is run, the dynamical linker loads libpng.2.dylib, then libgtkxmhtml.1.dylib and then libpng.3.dylib (confirmed by looking at DYLD_PRINT_LIBRARIES). At this point, the famous error message appears. Everything was compiled correctly, though. Something similar might happen with the different xfree versions: Binary foo is built while xfree-4.2 is installed. It links with -lXft which has the install-name /usr/X11R6/lib/libXft.1.dylib. foo also links with library libbar.1.dylib which is linked with -lXft, too. Now xfree is upgraded to 4.3.0 and package libbar is rebuilt. libbar.1.dylib now links with what libXft.dylib is symlinked to at this moment, namely libXft.2.1.dylib with install-name /usr/X11R6/lib/libXft.2.dylib. At runtime of foo, dyld loads first libXft.1.dylib (yes, this still exists in xfree-4.3.0 for compatibility reasons!), then libbar.1.dylib, then libXft.2.dylib. Boom! (Or maybe not?) -- Martin --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: libpng3 (was Re: [Fink-devel] gtk+2-2.0.9-3 problems with xfree86-4.3.0-1)
Hi Martin. Ben Reed and I discussed this a bit on IRC after I sent my previous message. He tells me that this libpng problem has been a problem with libpng on Linux as well, that it doesn't behave as a library is expected to do when you upgrade. That gives me some real hope that we won't have a repeat of this situation with XFree86 or other upgrades. So, no Boom!, I hope! -- Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Building/bootstrapping GHC on MacOS X
Hi everyone, I'm trying to create a Fink package for GHC (Glasgow Haskell Compiler), which I require for my Computing course at Uni, and I was just wondering how to go about doing it... From what I've looked at, it actually requires a version of GHC or a haskell compiler already installed to actually compile GHC itself, which poses a bit of a problem. There's a .dmg version of it available, put out by Wolfgang Thaller, but weighs in at 20Mb... which is pretty hefty. I spoke to him about it, and he said that bootstrapping GHC without a pre-existing installation is very time-consuming and complicated, and strongly suggested I grab a binary of another version and go from there... The only problems are, where do I get the binaries, and licensing issues. Firstly, the only place I can think of that would have the binaries is the .dmg file, which is too big to download by itself. Alternatively, I could take the binary from the installed package and tar it up to be put onto the Fink servers. However, this poses another problem... would this be disobeying the license that GHC is distributed under? It's located here: http://www.haskell.org/ghc/license.html I'm not quite sure how to go about doing this... If it's legal, could I take the binary, repackage it into another archive and then create a package for that, in order to bootstrap the GHC compiler itself? Of course, the binary could always be repackaged as a Fink package, but it wouldn't take advantage of the dependencies, and wouldn't be compiled on the computer itself. Can anyone offer any suggestions? Thanks a lot! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
