Re: [Fink-devel] X11-2.1.1.pkg oddity with fink builds
Fink could be running Xquartz -version, and with the nasty new hack that Jeremy just put in Xquartz would register with the window server to become active and gain focus. Only, Xquartz exits so quickly (since -version just prints to console and doesn't *actually* start the server) that the Dock doesn't have time to draw the icon before it disappears. JP On 14 Dec 2007, at 18:19, Merle Reinhart wrote: > Yip. I see the same thing. Also if you look, the focussed window > flashes slightly at the same time as the dock thing. > > I haven't been able to figure out what fink might be doing that > would trigger this. So, far, some of the fink commands is the only > time I've noticed it (simplest is a fink list -o command). I'm not > very good with Perl, so I haven't been able to quite figure out what > is running at the time I see the effect. > > Merle > > > On Dec 14, 2007, at 9:05 PM, Jack Howarth wrote: > >> Is anyone else noticing the following? On my dual G5 under 10.5.1 >> with the X11 2.1.1 pkg installed, I see a weird artifact in the dock >> during builds with fink. At certain points during the build process, >> it appears for a moment as if the Dock is being expanded to allow for >> a new icon (which never appears). This appears as a slight wobble >> in the >> Dock. >> Jack >> ___ >> Do not post admin requests to the list. They will be ignored. >> X11-users mailing list ([EMAIL PROTECTED]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/x11-users/merlereinhart%40mac.com >> >> This email sent to [EMAIL PROTECTED] > > ___ > Do not post admin requests to the list. They will be ignored. > X11-users mailing list ([EMAIL PROTECTED]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/x11-users/apple_lists%40gaelicwizard.net > > This email sent to [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Libnids, DSniff, and Libnet
Thanks a lot. I thought nobody had seen that e-mail. dsniff is in dports, but I've *never* been able to get it to work without manual hackery, so I never got around to packaging it, although I had almost working packages in the tracker a year (or more?) ago. Does it compile on a clean fink install? Thanx! JP On 30 Jan 2005, at 15:29, Ben Hines wrote: I went ahead and switched libnids to libnet1.0 - and packaged dsniff, which was not in fink yet. I dont think a lot of folks have been using libnids especially since dsniff wasn't in fink, and the libnids was installing directly into /sw which is very bad. So i fixed that as well. Anyway, try the the new dsniff fink pacakge, if its fine i'll move all 3 packages to stable tree. thanks -Ben On Apr 12, 2004, at 5:49 PM, John Davidorff Pell wrote: howdy y'all! First, i'd like to thank whomever has been keeping the one package I maintain updated as we've moved through 10.2-gcc3.3 and 10.3. Since libnet was split into 1.0 and 1.1 versions, libnids is no longer what i want it to be (I use it for dsniff which requires libnet 1.0, not 1.1), since libnids is set to depend on 1.1. I would like to ask what the correct way to "fix" this is. Personally, i think it should be switched to depend on libnet1.0, but some people might not like that so what is the correct way to provide two package versions? "libnids-libnet1.0-1.18-2.info"? Thanks a bunch, JP -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." -- Every time you share on a P2P network, God kills a kitten. Please think of the kittens. smime.p7s Description: S/MIME cryptographic signature
[Fink-devel] KDE package bug?
I'm trying to update KDE to the new version in unstable, but fink keeps telling me that I need to install postgresql74-*. I suppose someone screwed up somewhere and accidentally included a bogus dependancy. I also noticed that it depends on mysql, which I came with my system so there is not one single reason in the world to install that either. Let me know when its fixed :-) JP -- God is dead, now the war shall never end. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gettext in bootstrap from cvs
good call :-) Here is what it says, and the obvious problem: make install DESTDIR=/tmp/sw/src/root-gettext-0.10.40-18 docdir=/tmp/sw/share/doc/gettextMaking install in docmake[2]: Nothing to be done for `install-exec-am'. /bin/sh ../mkinstalldirs /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info mkdir /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap mkdir /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share mkdir /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info /usr/bin/install -c -m 644 ./gettext.info /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info/ gettext.info /usr/bin/install -c -m 644 ./gettext.info-1 /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info/ gettext.info-1 /usr/bin/install -c -m 644 ./gettext.info-2 /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info/ gettext.info-2 /usr/bin/install -c -m 644 ./gettext.info-3 /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info/ gettext.info-3 /usr/bin/install -c -m 644 ./gettext.info-4 /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info/ gettext.info-4 /usr/bin/install -c -m 644 ./gettext.info-5 /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/bootstrap/share/info/ gettext.info-5 /bin/sh ../mkinstalldirs /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/share/doc/gettext mkdir /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/share mkdir /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/share/doc mkdir /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/share/doc/gettext for file in `if test -f gettext_toc.html; then echo .; else echo .; fi`/gettext_*.html; do \ /usr/bin/install -c -m 644 $file /tmp/sw/src/root-gettext-0.10.40-18/tmp/sw/share/doc/gettext/`basename $file`; \ done At this point, it is beginning to build the debs, after the initial bootstrap, but it's confused about where to go! Part of it is going into the right place, and part has an extra 'sw/bootstrap'! Go Figure™ Anything else I should check out? JP On 7 Aug 2004, at 23:22, Martin Costabel wrote: John Davidorff Pell wrote: /bin/mv /sw/src/root-gettext-0.10.40-18/sw/share/info /sw/src/root-gettext-bin-0.10.40-18/sw/share/ mv: rename /sw/src/root-gettext-0.10.40-18/sw/share/info to /sw/src/root-gettext-bin-0.10.40-18/sw/share/info: No such file or directory ### execution of /bin/mv failed, exit code 1 installing gettext-bin-0.10.40-18 failed I've got fink from cvs as of this morning (about 11am) and gettext is failing the bootstrap with the above errors. Obviously, the info pages are not getting put in the right place. Errm, no. As it says in FAQ#6.7 http://fink.sourceforge.net/faq/comp-general.php?#mv-failed, there must have been something wrong further up in your build log. In particular, the paragraph Making install in doc make[2]: Nothing to be done for `install-exec-am'. /bin/sh ../mkinstalldirs /sw/src/root-gettext-0.10.40-18/sw/share/info mkdir /sw/src/root-gettext-0.10.40-18/sw/share mkdir /sw/src/root-gettext-0.10.40-18/sw/share/info /usr/bin/install -c -m 644 ./gettext.info /sw/src/root-gettext-0.10.40-18/sw/share/info/gettext.info /usr/bin/install -c -m 644 ./gettext.info-1 /sw/src/root-gettext-0.10.40-18/sw/share/info/gettext.info-1 /usr/bin/install -c -m 644 ./gettext.info-2 /sw/src/root-gettext-0.10.40-18/sw/share/info/gettext.info-2 /usr/bin/install -c -m 644 ./gettext.info-3 /sw/src/root-gettext-0.10.40-18/sw/share/info/gettext.info-3 /usr/bin/install -c -m 644 ./gettext.info-4 /sw/src/root-gettext-0.10.40-18/sw/share/info/gettext.info-4 /usr/bin/install -c -m 644 ./gettext.info-5 /sw/src/root-gettext-0.10.40-18/sw/share/info/gettext.info-5 will probably look different in your case. What does it say? -- Martin -- - /~\ The ASCII \ / Ribbon Campaign X Help cure HTML Email / \ smime.p7s Description: S/MIME cryptographic signature
[Fink-devel] gettext in bootstrap from cvs
/bin/mv /sw/src/root-gettext-0.10.40-18/sw/share/info /sw/src/root-gettext-bin-0.10.40-18/sw/share/ mv: rename /sw/src/root-gettext-0.10.40-18/sw/share/info to /sw/src/root-gettext-bin-0.10.40-18/sw/share/info: No such file or directory ### execution of /bin/mv failed, exit code 1 installing gettext-bin-0.10.40-18 failed I've got fink from cvs as of this morning (about 11am) and gettext is failing the bootstrap with the above errors. Obviously, the info pages are not getting put in the right place. Just making sure the right people know. :-) JP It's all fun and games 'til someone writes to a NULL pointer! smime.p7s Description: S/MIME cryptographic signature
[Fink-devel] Libnids, DSniff, and Libnet
howdy y'all! First, i'd like to thank whomever has been keeping the one package I maintain updated as we've moved through 10.2-gcc3.3 and 10.3. Since libnet was split into 1.0 and 1.1 versions, libnids is no longer what i want it to be (I use it for dsniff which requires libnet 1.0, not 1.1), since libnids is set to depend on 1.1. I would like to ask what the correct way to "fix" this is. Personally, i think it should be switched to depend on libnet1.0, but some people might not like that so what is the correct way to provide two package versions? "libnids-libnet1.0-1.18-2.info"? Thanks a bunch, JP -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." smime.p7s Description: S/MIME cryptographic signature
Re: [Fink-devel] Re: Fink-devel digest, Vol 1 #1299 - 8 msgs
Perhaps in the DescPort section, or a similar non-user section? Shouldn't be too hard... Also, judging from the number of packages that are submitted and approved via/from the package submission tracker, i don't think that it is reasonable to say that most packages that have SUID bit binaries are maintained by competent people. What's to stop someone from "./configure --prefix=%p &&make&& make install", submitting it, and still having NO idea what is actually in the package? Thanx, JP On Dec 13, 2003, at 3:21 PM, Darian Lanx wrote: Now if I simply mention in an info file that a "SUID" file will be installed -SNIP- The packages that do install SUID binaries are probably maintained by people who know a lot about the things they package up and thus they can be trusted by the things they do. It's all fun and games 'til someone writes to a NULL pointer! smime.p7s Description: S/MIME cryptographic signature
Re: [Fink-devel] Re: Fink-devel digest, Vol 1 #1299 - 8 msgs
I totally understand the issue, but I think that it is not as big as many would suggest. I'm not advocating using the SF compile farm at this time, I realize that its not the *best* ides, in fact its almost always better to have our own, if we (fink) can afford it. On the topic of security, would you like to find out one day that you have several SUID binaries on your system that you did not know about? I recently searched for them and found that fink had installed one from KDE as well as others. It is not mentioned ANYWHERE in the .info file or in any documentation from fink. I think that it should be policy to have a note in the description that mentions any SUID binaries. JP On Dec 13, 2003, at 4:58 AM, Darian Lanx wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 John Davidorff Pell wrote: Which is a huge problem to begin with, how about we fix that?! First of all, I have to concur with all the "PROBLEMS" mentioned by Max. There is no single reason why we would _want_ to use a public compile farm. As the one person who watches over our public image I would be the first to scream "Murder" and I would do anything to keep this from happening. The chance that we end up in a situation where a compromised distribution is sent out to thousands of users is simply too big. Fink is no longer your everyday, small open source project. Even though we might not match up with Apache, KDE, GNOME and the like we are still a big player on our own turf. The problem is not, in my humble opnion, that we would nto find enough supporters to roll our own compile farm, the issues is, as stated before, that we simply lack the infrastructure within fink yet, to automate the process completely. I am working very hard on a system that involves GnuPG to ensure, that we can trust what is put into Fink, but since this is a rather complex issue, it also takes time. For me it is not only about technical probabilities, it is also about avoiding a public desaster where Fink ends up running bad press. That is the last thing we need or want. - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/2wzvPMoaMn4kKR4RAz6mAJ9H8zor5k4VRmKmUjbaLicdPyMULQCdH5EJ FmMO1qpEXE9rs4owfAaTKoc= =X8Kc -END PGP SIGNATURE- -- "... was it a dream where you see yourself standing in sort-of Sun-God robes, on a pyramid, with a thousand naked women screaming and throwing little pickles at you? ... Why am I the only one who has that dream?" smime.p7s Description: S/MIME cryptographic signature
Re: [Fink-devel] Re: Fink-devel digest, Vol 1 #1299 - 8 msgs
Are you saying that *ANY* binary build on the sourceforge servers is potentially tampered with? Are you saying that fink has more binary distro users than people who use sorceforge binaries already? Wow, I never new that we had *that* many users! And in the binary distro alone! JP On Dec 13, 2003, at 3:12 AM, Max Horn wrote: we shouldn't use the compile farm, for simple security reasons. -- Blood is thicker than water... and much tastier. smime.p7s Description: S/MIME cryptographic signature
[Fink-devel] Re: Fink-devel digest, Vol 1 #1299 - 8 msgs
Which is a huge problem to begin with, how about we fix that?! JP On Dec 12, 2003, at 8:04 PM, [EMAIL PROTECTED] wrote: Also, the SourceForge compile farm is not available for doing bindist builds because you have to be root to build the bindist. -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." smime.p7s Description: S/MIME cryptographic signature
Re: [Fink-devel] libmikmod-3.1.10-2
Ok, works for me. I just noticed a whole bunch of warnings and I thought I'd let the maintainer know, which is fink-devel... JP On Dec 4, 2003, at 10:56 AM, TheSin wrote: -pthread and -lpthread aen't the same, I think -pthread could just be removed, likely a configure script problem, but it's harmless and is likely the reason why the maintainer didn't remove it in the first place. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 4-Dec-03, at 11:48 AM, John Davidorff Pell wrote: When building, libmikmod-3.1.10-2 calls gcc with "-pthread" which results in numerous warnings. It works, but I think that changing it to "-lpthread" would make it happier. Whoever is in charge of this, could you take a look? Thanx. JP -- John Davidorff Pell [EMAIL PROTECTED] -- John Davidorff Pell [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
[Fink-devel] libmikmod-3.1.10-2
When building, libmikmod-3.1.10-2 calls gcc with "-pthread" which results in numerous warnings. It works, but I think that changing it to "-lpthread" would make it happier. Whoever is in charge of this, could you take a look? Thanx. JP -- John Davidorff Pell [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [Fink-devel] Re: plea for more care
iThink that the issue of upgraded fink installs is the primary problem in fink, and without the question of backward compatability it would be a) easier to improve b) easier to fix and c) better. The dlcompat library doesn't get linked correctly because there are binary packages on the upgraded system that look for the wrong one, the freetype2 stuff is the same, its all because people have upgraded, its obviously not an issue if its all new. Also, there are packages that are fine to be rebuilt in panther after an upgrade, but other packages that depend on those may also upgrade but the combination won't work if one, but not the other, is upgraded in the wrong order. We had the issue of upgrading after the xfree 4.3 release etc etc etc etc blah... There should be a "forced" upgrade path, where everything *must* be rebuilt, IN ORDER OF DEPENDANCY, that is installed. Perhaps, just a forced re-bootstrapping of fink (with he old tree moved out of the way, ENTIRELY) that then rebuilds all installed packages (or apt-get's in case of a binary install). This is the only way to fix things like this, without "special hacks" like dummy packages, weird "virtual packages" and even things that screw with the build system like the custom freetype2.la that was mentioned. iKnow that this isn't the best user experience, but if its presented in the right way, then it will end up with a much better experience sine things won't break (as much)! JP -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." smime.p7s Description: S/MIME cryptographic signature
Re: [Fink-devel] Dpkg...
But this does not work as intended. Dpkg still tries to set group and user IDs even tho they are already correct, resulting in permission denied errors. :-( JP On Saturday, October 18, 2003, at 8:22 pm, Anthony DeRobertis wrote: On Fri, 2003-10-10 at 20:19, John Davidorff Pell wrote: Aren't there ways of simply extracting the files within a deb? Then we could parse the pre/post scripts ourselves... anyone up for a dpkg replacement? ;-) try 'man dpkg' before re-inventing the wheel: dpkg --force-not-root btw, .deb files can be extracted with either dpkg-deb or the standard utilities 'ar', 'tar' and 'gzip'. -- if (message.signature==FUNNY) steal(message.signature); else message=message->next; --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] User mode Fink
Absolutely! On Sunday, October 12, 2003, at 8:03 pm, Chris Dolan wrote: On Sunday, October 12, 2003, at 08:25 PM, Greg Novak wrote: --- Chris Dolan <[EMAIL PROTECTED]> wrote: I have not yet heard anyone mention the best reason for user-mode fink: trust problems. Do you really want to be running a ton of shell scripts and makefiles as root? Not me. I'd rather compile and build .debs as a regular user and only do the final install step as root. I don't think this holds water. If you don't trust the people writing the scripts, what's to stop them from patching the software to do something malicious while it's building (as a regular user) and then doing nasty stuff after the software is installed as root? It's not just maliciousness, it's accidents too -- perhaps even more the latter! Take for example the recent cases found on the list of packages that accidentally did some of their "make install" into /sw instead of the /sw/src/... sandbox because of a %p instead of %i. Building as non-root would block this from wreaking havoc. Ideally, I want to do the highly unpredictable "build" step as me, and the much more predictable "install" from .deb as root. That's similar to how I install manually: ./configure; make; sudo make install, but even better since even make install is non-root. That's similar to how RPMs are built for RedHat. Even Perl's CPANPLUS is moving in that direction, I think. You just don't need root's power to do the build, so why risk accidents? All it takes is one instance of the following to to ruin your day when you're root. clean: rm -r *.o build /* *~ Chris --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] User mode Fink
On Sunday, October 12, 2003, at 6:25 pm, Greg Novak wrote: --- Chris Dolan <[EMAIL PROTECTED]> wrote: I have not yet heard anyone mention the best reason for user-mode fink: trust problems. Do you really want to be running a ton of shell scripts and makefiles as root? Not me. I'd rather compile and build .debs as a regular user and only do the final install step as root. I don't think this holds water. If you don't trust the people writing the scripts, what's to stop them from patching the software to do something malicious while it's building (as a regular user) and then doing nasty stuff after the software is installed as root? I'm under the impression that most of the fink developers are more-or-less trustworthy, if you disagree please feel free to let us know. The idea here is that a typo can't wipe out my home folder, or a 'shortcut' in the makefile can't clobber another package (or the system). Comprende? If you would like more explanation, please let me know. --- John Davidorff Pell <[EMAIL PROTECTED]> wrote : I've already started using my user-mode fink mod for my own stuff so I hope to have useful insight when the core developers are willing to listen. You seem to have missed my earlier message on the topic, so let me reiterate: it's not clear to me what problem your modification solves. As far as I've seen, there are three possibilities: 1) Allow people who don't have root access to use fink to install "personal" software -- Nope, having a fink user doesn't help because regular users won't be able to switch to/create the user. What's to stop the 'fink user' from being someone's normal login user? Make the fink user's UID configureable in the fink.conf file and problem solved. Or maybe have fink check the owner of its prefix path and use that user? Its exactly what fink does with CVS so very little code would need changing to adapt that to this purpose. OK? 2) Allow package maintainers to debug .info files in a "sandbox" so they don't trash their /sw trees. -- Nope, if all fink packages are owned by a fink user, then package maintainers can still trash their /sw trees. Once we have fink as a separate user, it would be quite a bit simpler to have a 'fink-build' user and a 'fink-install' user, to fix this. Also, I've been thinking about the possibility of keeping /sw owned by root and simply doing the build as some 'build' user. Definitely a possibility, the only change it would require would be to how diff parts of the fink engine are called. For example, the install engine would get root auth, and then call the build engine and downgrade it to just a build user, then install as root when the build is finished. Little more work, but not out of the question. 3) Prevent malicious fink scripts/open source software from doing damage on your machine. -- Actually, yes, your patch helps with this as long as fink _never_ requires root for anything. If this is the case, then after you create the fink user, software installed through fink will only be able to harm other fink software. This is probably a step in the right direction. :-) JP It's all fun and games 'til someone writes to a NULL pointer! --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Fink-devel digest, Vol 1 #1188 - 12 msgs
While I agree with most of what you say, I feel that it is important to look at any structural changes to fink that could be done now to take advantage of the upcoming release. If we figure out exactly what has to be root and what doesn't and move in the direction of widening the distinction now, then when we change to panther we can include some of these modifications. Kill two birds with one stone. I've already started using my user-mode fink mod for my own stuff so I hope to have useful insight when the core developers are willing to listen. Thanx, JP On Sunday, October 12, 2003, at 9:49 am, Benjamin Reed wrote: Sure, I'm not arguing that. I'm arguing the need to do it immediately. I agree it's safer to not do anything as root. I disagree that it's as easy as people are making it sound. If it was, we'd have it already. When I say "user-mode fink is useful to a very small part of the fink population", what I mean is it's really only desired by people who are both sysadmins and users of fink. It's not like fink is making you be root for the day-to-day use of fink packages, it's only for installing new software, which for 99% of fink's users, is a fairly rare occasion. I agree it's a nice-to-have, I disagree it's worth rushing into it without thinking about all the ways it affects how the fink packaging process works. There's only so many times I can say "I don't have anything against it but now isn't the time." If you want to implement it, do it. Don't just make a patch and say "it works for me." Build a lot of packages and see what breaks. Find out *why* it breaks, and find out how to fix that. In a month, when we have a panther bindist and things have slowed a bit, come back and show the code and make your case. 2 weeks before the panther release is not the time to come to us and say "oh, by the way, I think we should make sweeping changes to the way fink builds and installs packages." =) -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE "Emacs is a nice operating system, but I prefer UNIX." -- Tom Christiansen It's all fun and games 'til someone writes to a NULL pointer! --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Dpkg...
Ok, so I've added the non-root force option to the dpkg line, but now dpkg fails when changing the user from 'fink' to 'fink'? iThink that part of it might be the group, its trying to assign 'wheel'... Well, I'll keep y'all posted. If you wanna help, here's my patch so far: finkUser.patch Description: Binary data fink is UID 240, no shell, no passwd. (the 'su' method for becoming root does *not* work w/o the user having a shell), created manually. Thanx, JP P.S. On a *completely* unrelated note, my unmodified fink install refuses to build imlib with : " rm /tmp/fink/root-imlib-1.9.14-3/sw/lib/libimlib-*.a rm: /tmp/fink/root-imlib-1.9.14-3/sw/lib/libimlib-*.a: No such file or directory " Any suggestions? Seems like the rm needs a -f after it, but its not my package... :-) I'm on Panther, btw. thanx again. -- Blood is thicker than water... and much tastier.
Re: [Fink-devel] fink run *not* as root
There is a --force-not-root option to dpkg; I'm not sure about dpkg-deb. All I know is that I've used the user patch that's already on our patch tracker successfully on lamancha.opendarwin.org until a selfupdate wiped it out. I've just added this to my dpkg lines in PkgVersion.pm and its working so far, this seems to be the solution! Yes! dpkg-deb does *not* require root for anything (that I know of), it builds the deb fine as user 'fink'!! Woohoo!! It looks to be complete, i'll send in my patch for user 'fink' shortly... (must make sure its clean first) Also, since I created the fink user manually, somebody might want to look at how to do it gracefully in the bootstrap. :-D JP -- John Davidorff Pell [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Dpkg...
I've got fink 100% working with the 'fink' user, UID 240, created
manually, except one minor part...
dpkg -i
/test/fink/dists/local/bootstrap/binary-darwin-powerpc/
fink_0.14.0.cvs-20031010.2353_darwin-powerpc.deb
dpkg: requested operation requires superuser privilege
### execution of dpkg failed, exit code 2
arg. 'sudo dpkg' works, but again it would ask for a passwd if the
compile lasted more than 5 mins... A line can be added to /etc/sudoers
that would allow a certain user ('fink' in this case) to run sudo w/o a
passwd, but that prob won't float with many people. Aren't there ways
of simply extracting the files within a deb? Then we could parse the
pre/post scripts ourselves... anyone up for a dpkg replacement? ;-)
Issue: sudo when exec'd after a previous 'sudo -u fink' ask's for the
'fink' user's passwd... that's bad. Plus, 'fink' isn't in admin, so
sudo won't work at all... 'su'?
Here's an idea: Make a duplicate dpkg binary, readable *only* by the
'fink' user, and make it SUID root. Ok? Not ok? prob not...
Feedback?
JP
--
God is dead, now the war shall never end.
---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink run *not* as root
On Friday, October 10, 2003, at 4:19 pm, David R. Morrison wrote: I have to disagree about the timing of when root is supposed to be invoked. I issue a command to build a package which will take an hour... I come back two hours later, only to find that it's been waiting for the past hour for me to enter my password? Not a good user experience. You are correct. That's why Fink decides at the beginning of its run whether it needs to be root or not. If we're going to decide at the beginning, then even "fink build foo" cannot be run as non-root. (See my previous message). Perhaps as an option to developers who need to make sure that it doesn't install out of the prefix? Also, what happens after sudo (in my scenario) is *extremely* short, compared to the actual build. Also, the passwd prompt for sudo can be modified so it can be something more helpful to the user watching the build. :-) -- Dave I like the idea of a 'fink' user. I will write a patch which creates a 'fink' user in the bootstrap and then always does 'sudo -u fink', instead of 'sudo', tonight. This will also allow fink to use all of its current nonRoot-to-root stuff, simply to switch to 'fink' instead of 'root' :-) JP -- God is dead, now the war shall never end. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink run *not* as root
On Friday, October 10, 2003, at 4:10 pm, Dave Vasilevsky wrote: On Friday, October 10, 2003, at 06:48 PM, David R. Morrison wrote: Since fink directs "make install" to a temporary installation directory, we don't need to be root to run that either. Except when a package wants to chown a file. The chown should be to root, except in the few packages that have their own user, right? The tricky thing, though, is the last thing fink does when compiling a package: it calls "dpkg-deb" to create the deb file out of the temporary installation directory. It is my belief that dpkg-deb insists on being run as root. If I'm right about that, this is the first change which would need to be made: dpkg-deb would need to be hacked so that it doesn't require root. Also, if you run dpkg-deb on a install directory (%i) containing non-root-owned files, the installed package will include those files as non-root. It's not a good thing if other users can modify files in /sw . dpkg would have to be hacked to install non-root files as root when desired. So if I changed sudo dpkg* to sudo chown -R root:admin . && sudo dpkg* that would fix it, right? In the packages that have their own user, something slightly more complicated would have to be devised, perhaps just a PostInst script. Maybe after every fink install, fink should 'sudo chown -R root:admin /sw' anyway? OK, but let's assume we solve that problem. Then we'd be able to run the command "fink build foo" without being root. That's probably a good thing, for a number of reasons. What about "fink install foo" though? Here we get into a problem of file permissions on /sw. Since fink is trying to assert total control over the /sw heierarchy, its probably best to leave that as owned by root. But then you'll need to be root to run "fink install." (If you disagree, let me hear the arguments.) One of the solutions to this problem, as well as the above problem re: non-root-owned files in .debs, is to simply install in another prefix and make it entirely user owned. That probably has its own problems. Create a 'fink' user? That would solve... all the problems? Let's do it! 'sudo -u fink' in place of 'sudo' should negate the need for any other patch to fink at all. Not to sound too negative, I actually would love to see user-mode fink, I even did some hacking on fakeroot once upon a time. It's just that it's a big job, and nobody's wanted to take it further than "works for me". Dave It worx for me, but I want it to work for real. :-) ! JP -- Blood is thicker than water... and much tastier. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink run *not* as root
On Friday, October 10, 2003, at 3:54 pm, Benjamin Reed wrote: John Davidorff Pell wrote: I've noticed that there are a few patches out there that disable fink's need to be root, but they all have drawbacks, like dpkg needs to be root. I've noticed that many of the developers have repeatedly dismissed it and have not even looked into if it would be easy to do. I went through the fink source... err, the perl stuff and I've made a patch that sets fink up to run as the current user, and also sets dpkg up to run as root when needed. I use the $method (from Engine.pm) variable so that its not dependant on sudo, but I wasn't sure if I should make it global or make it local in all the functions that need it. I made it local to the functions that need it. I think the biggest reason it never happened is that no one really championed making things happen, including all of the concerns in doing user-only building. There have been a few patches, but all of them ignore half of the equation, which is packages that either expect to, or have to run as root; sometimes at install time, sometimes at build time. There are packages that make suid files, there are packages that initialize things on installation, I'm sure there are other things that happen that we don't know about. There's no framework for gracefully handling those things as a regular user, and there's no suggestion on how to handle packaging policy on things that currently want/need root to install. Making fink the program handle it is the easy part, but all that's doing is telling users we support it even though a bunch of stuff will be broken. =) IMHO there should be *no* package that makes *anything* SUID root that I (the user) don't know about, thus those packages that require something like that should be modified on a per-package basis (for these packages something like 'sudo make...' would work fine). Also, nothing should be initialised when fink does 'make install PREFIX=...' because I'm *not* installing the package. This method would allow package maintainers to find bugs like these which are otherwise very difficult to find. It will also prevent a package from installing out of the PREFIX'd build dir. :-) JP It's all fun and games 'til someone writes to a NULL pointer! --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink run *not* as root
On Friday, October 10, 2003, at 3:48 pm, David R. Morrison wrote: Sure, here's some feedback. First, let's examine where root is actually needed in fink. We certainly don't need to be root to run "make" on a package. Since fink directs "make install" to a temporary installation directory, we don't need to be root to run that either. The tricky thing, though, is the last thing fink does when compiling a package: it calls "dpkg-deb" to create the deb file out of the temporary installation directory. It is my belief that dpkg-deb insists on being run as root. If I'm right about that, this is the first change which would need to be made: dpkg-deb would need to be hacked so that it doesn't require root. (If I'm wrong, please let me know.) OK, but let's assume we solve that problem. Then we'd be able to run the command "fink build foo" without being root. That's probably a good thing, for a number of reasons. What about "fink install foo" though? Here we get into a problem of file permissions on /sw. Since fink is trying to assert total control over the /sw heierarchy, its probably best to leave that as owned by root. But then you'll need to be root to run "fink install." (If you disagree, let me hear the arguments.) So anyway, as I see it, the missing first step here is a modification to dpkg which would allow dpkg-deb to run as an ordinary user. Just my 2 cents. -- Dave Problem solved already (it works, but maybe not "solved"), in my patch every time dpkg* is called, it is prefaced with sudo. Thus, to build the package root is not required, to make the deb/install the deb it is. So, no root until dpkg is called. Possible issue: package is build but you (for whatever reason) don't give dpkg (sudo actually) the passwd and it cancels. Now you have to rebuild. the dpkg line could be modified to create the deb in a tmp dir, then moved if given permission. You'll notice in my patch, I simply disable fink calling sudo at all (I disabled the root check) but it would prob be better to change the time at which it gets root. For example, make dpkg not be prefaced with sudo, but to restart fink as root at that point (meaning *after* the actual build/install to temp dir) :-D JP -- God is dead, now the war shall never end. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] fink run *not* as root
I've noticed that there are a few patches out there that disable fink's need to be root, but they all have drawbacks, like dpkg needs to be root. I've noticed that many of the developers have repeatedly dismissed it and have not even looked into if it would be easy to do. I went through the fink source... err, the perl stuff and I've made a patch that sets fink up to run as the current user, and also sets dpkg up to run as root when needed. I use the $method (from Engine.pm) variable so that its not dependant on sudo, but I wasn't sure if I should make it global or make it local in all the functions that need it. I made it local to the functions that need it. I hope that this can be looked at without the prejudice against it that I have seen from many developers towards pervious non-root patches. Also, my fink is set up to build in /tmp/fink instead of /sw/src and this is prob necessary for my non-root patch because the current user needs write privs and /sw/src isn't a good place to give world write privs. I'll look into seeing how to modify that dependancy. Perhaps a new default build dir? One last thing, this is diff'd against rangerRick's 0.14.0-rsync special version, although it uses none of his modifications. I can diff it against current cvs if this is too complex for some of you out there. :-) JP noRoot.patch Description: Binary data P.S. Feedback please?! :-D -- Every time you share on a P2P network, God kills a kitten. Please think of the kittens.
Re: [Fink-devel] missing md5 sums to become an install time error
Sounds good to me :-) JP On Saturday, August 30, 2003, at 10:50 AM, TheSin wrote: maybe set a fink.conf field for this, say MD5NotFatal: true ?? On 30-Aug-03, at 11:15 AM, John Davidorff Pell wrote: I'm not so ok with this, what if I have a number of packages which are very-not-standard for various reasons living in my local tree, I do not want to have to do md5s for my own packages that I know will never really be part of fink because of the way I've constructed them. Does that make any sense? -- John Davidorff Pell [EMAIL PROTECTED] --- 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] missing md5 sums to become an install time error
I'm not so ok with this, what if I have a number of packages which are very-not-standard for various reasons living in my local tree, I do not want to have to do md5s for my own packages that I know will never really be part of fink because of the way I've constructed them. Does that make any sense? JP On Friday, August 29, 2003, at 8:05 PM, TheSin <[EMAIL PROTECTED]> wrote: I'm okay with this. On 29-Aug-03, at 9:13 AM, David R. Morrison wrote: In fact, I think I would take it one step further: if there is no MD5-sum, fink can print out the MD5-sum it calculates (for the benefit of developers) but should then quit and refuse to compile the package. -- Dave -- ". . . Through the cold and darkness we will look back on this day and fall into oblivion. Through a brilliance beyond twilight we will rise again, ready to face the dangers that befall on us . . ." --- 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] (no subject)
On Monday, August 25, 2003, at 3:41 AM, Chris Zubrzycki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday, August 24, 2003, at 10:48 AM, John Davidorff Pell wrote: I'm actually a little confused as to why each *package* needs the gcc: 3.1 | 3.3 flags. Its only important to which version of gcc3 we compile with, not which code we compile. Shouldn't fink just keep track of which gcc3 a given package was compiled with instead of making a duplicate info file for each? i.e. In theory foo.info with gcc: 3.1 and foo.info with gcc: 3.3 should be identical except for that line, so why make duplicates? If we force a given fink distro to use only one gcc3, then can't we just make it require the correct gcc3 be used and leave it at that? Then all the C++ code will always be from 3.3 (or 3.1). Unless i'm very confused this would simplify it a bit, wouldn't it? The problem is with the upgrade. What we did for the gcc 3.1 upgrade was to only force users to recompile fink packages which have C++ code in them, and allowed them to keep their already-compiled things from the previous distribution if those things did not involve C++. I agree that it would be simpler to just use a given gcc for a given distribution, but then we would need a mechanism to force people to replace all of their fink packages (and to replace them in the correct order, if they are building from source) when they upgrade. -- Dave So then let's make a much more descriptive field. if a package has c++ code in it... CPP: Yes If a package has this and we upgrade, then build any dependancies it has that also have it. then build that package and we're happy. :-) Well, first of all, CPP stands for C PreProcessor, not C++. Second, we try to make sure the default way of building remains the same with all users. It is so much easier to know that in 99.99% of cases, there is a standard set of tools being used. Also, we do not create the CPP or CFLAGS variables, they are standard, and are meant to hold custom command line options, so assigning Yes to the value that should be the CPP makes less then 0 sense. I didn't know that fink exported the fields in the info files into environment variables. ;-) AFAIK the GCC tags are only required for c++ packages, but it's a good way to mark the highest compiler they build on. So not "CPP", do "CPlusPlus: Yes" if you like, but GCC: 3.1 currently does *NOT* mean that a package is any better on 3.1 than it is on 3.3, perhaps we should make it mean that, and create another for c++? - -chris zubrzycki What I'm suggesting is that we have a field that says "This package has C++ in it" i thought that was the idea for the GCC field, but the versioning makes that kinda weird, and non-c++ packages can have the field, which defeats the whole purpose if this is the case. Then we can work with recompiling only packages that have C++ in it when we upgrade and the rest of the packages can just work. JP -- if (message.signature==FUNNY) steal(message.signature); else message=message->next; --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] (no subject)
I'm actually a little confused as to why each *package* needs the gcc: 3.1 | 3.3 flags. Its only important to which version of gcc3 we compile with, not which code we compile. Shouldn't fink just keep track of which gcc3 a given package was compiled with instead of making a duplicate info file for each? i.e. In theory foo.info with gcc: 3.1 and foo.info with gcc: 3.3 should be identical except for that line, so why make duplicates? If we force a given fink distro to use only one gcc3, then can't we just make it require the correct gcc3 be used and leave it at that? Then all the C++ code will always be from 3.3 (or 3.1). Unless i'm very confused this would simplify it a bit, wouldn't it? The problem is with the upgrade. What we did for the gcc 3.1 upgrade was to only force users to recompile fink packages which have C++ code in them, and allowed them to keep their already-compiled things from the previous distribution if those things did not involve C++. I agree that it would be simpler to just use a given gcc for a given distribution, but then we would need a mechanism to force people to replace all of their fink packages (and to replace them in the correct order, if they are building from source) when they upgrade. -- Dave So then let's make a much more descriptive field. if a package has c++ code in it... CPP: Yes If a package has this and we upgrade, then build any dependancies it has that also have it. then build that package and we're happy. :-) JP It's all fun and games 'til someone writes to a NULL pointer! --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] the gcc 3.3 upgrade
Well, how about we don't support *upgrade* to 3.3? For panther this will be no problem (because nobody's got a GM panther to upgrade yet.. ;-)) and neither for Jag because the only people who would have/use 3.3 would be developers who installed the update. For them we could just require gcc_select 3.1 before fink will compile anything, not to mention that any lib that links against c++ code in jag itself won't work b/c its compiled w/ 3.1. JP On Friday, August 22, 2003, at 8:56 AM, David R. Morrison wrote: John Davidorff Pell <[EMAIL PROTECTED]> wrote: I'm actually a little confused as to why each *package* needs the gcc: 3.1 | 3.3 flags. Its only important to which version of gcc3 we compile with, not which code we compile. Shouldn't fink just keep track of which gcc3 a given package was compiled with instead of making a duplicate info file for each? i.e. In theory foo.info with gcc: 3.1 and foo.info with gcc: 3.3 should be identical except for that line, so why make duplicates? If we force a given fink distro to use only one gcc3, then can't we just make it require the correct gcc3 be used and leave it at that? Then all the C++ code will always be from 3.3 (or 3.1). Unless i'm very confused this would simplify it a bit, wouldn't it? The problem is with the upgrade. What we did for the gcc 3.1 upgrade was to only force users to recompile fink packages which have C++ code in them, and allowed them to keep their already-compiled things from the previous distribution if those things did not involve C++. I agree that it would be simpler to just use a given gcc for a given distribution, but then we would need a mechanism to force people to replace all of their fink packages (and to replace them in the correct order, if they are building from source) when they upgrade. -- Dave -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] the gcc 3.3 upgrade
I'm actually a little confused as to why each *package* needs the gcc: 3.1 | 3.3 flags. Its only important to which version of gcc3 we compile with, not which code we compile. Shouldn't fink just keep track of which gcc3 a given package was compiled with instead of making a duplicate info file for each? i.e. In theory foo.info with gcc: 3.1 and foo.info with gcc: 3.3 should be identical except for that line, so why make duplicates? If we force a given fink distro to use only one gcc3, then can't we just make it require the correct gcc3 be used and leave it at that? Then all the C++ code will always be from 3.3 (or 3.1). Unless i'm very confused this would simplify it a bit, wouldn't it? On Friday, August 22, 2003, at 5:06 AM, David R. Morrison wrote: Hi. After the discussion last week, I agree with you, and don't plan to have fink invoke gcc_select. In fact, I've put code into fink on CVS which checks that version of gcc you are running (when it matters, as indicated by the GCC directive), and if the version is incorrect, advises you to run gcc_select. Under the current, evolving, plan for future gcc updates, each fink distribution will have a preferred version of gcc which users are expected to be running. However, only for packages which explicitly declare the gcc version they need, will there be any "enforcement" of the version. Insisting that each individual package which needs gcc 3.1 or gcc 3.3 call it explicitly is not too practical. The main reason that we need to be doing these calls at the moment is the changes in ABI for gcc-compiled C++ code; in most cases, the issue is to make sure that all the fink packages in a given distribution (with C++ code coming from dynamics libs) is compiled with the same gcc version, to avoid binary incompatibilies. -- Dave -- John Davidorff Pell [EMAIL PROTECTED] --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] the gcc 3.3 upgrade
I am very opposed to calling gcc_select ever from within fink, because it overwrites symlinks in /usr/bin. fink has always had the policy to not mess w/ anything outside of /sw with notable exceptions (X11R6). One of the features of gcc is that you can have multiple versions installed simultaneously. To implement this you should set $CC to gcc3.1 (which is in /usr/bin) that way it will use gcc 3.1 and not 3.3 and it will NOT do things to my system that I do not want. :-) JP -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] glut, X11 1.0 and Panther
I just thought i'd let y'all know that X11 1.0 in the panther preview is built FAT just like everything else and so the Imake files that glut uses to configure itself have '-arch i386' in them all over the place so it won't work on a normal osx box. :-) either a custom version of this file is needed or apple needs to be killed or maybe some patch to glut or maybe our own version of Imake? :-) JP -- Every time you share on a P2P network, God kills a kitten. Please think of the kittens. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: packages that are part of the system
On Friday, July 25, 2003, at 10:14 PM, Charles Lepple wrote: On Friday, July 25, 2003, at 08:02 PM, John Davidorff Pell wrote: Tcltk: this one is a little odd: Apple has provided tcl, but not tk...? i'm at a loss... Check the list archives-- I believe someone figured out that Tk is an extra download from Apple. If you happen to track this one down, maybe there could be a system-tk package that lists the Apple URL for downloading their version. (I don't know for sure, but vaguely remember hearing that the version in Fink uses X11, where Apple's version uses Cocoa or Carbon.) -- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/ i looked it up and it seems like its there for some tool installed by apple, but the stuff apple links to for tk has tcl and tk *both* built as frameworks, but the one included w/ MOX is built normally. I might suggest that the tcltk package become a bundle package and have fink compile just tk. what u think? JP --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Fwd: [Fink-devel] Re: packages that are part of the system
On Saturday, July 26, 2003, at 8:05 AM, David wrote: On Samstag, Juli 26, 2003, at 02:02 Uhr, John Davidorff Pell wrote: Here's my rationale for wanting some fink packages to be removed (or a system-foo package created??): Hello. While I appreciate all the effort you made to list those packages I do not quite understand which reasoning is behind _removing_ them? To offer additional packages where one might choose to stay with the system packages is surely an enhancement one can think about. Sometimes Apple failed to provide shared libraries one can link against and since I have not seen Panther yet, I have no idea if that has been fixed. I've been thinking about removing packages from fink and its seeming more and more like a bad idea, but I'm still all for making system-foo packages. Devel: AutoConf2.5: version 2.57 is provided by panther, obviously the other autoconf packages would remain for compatibility. :-) Auto Tools are a very tricky thing. Some packages require older auto tools, thus messing with those should be avoided, not to mention that most auto tools are tiny, so I see no benefit in adding a systems package. There are like 10 diff auto* package sin fink, all diff versions. since they're so small it makes little diff, but I was thinking that a few packages could be eliminated (but it would be pointless if we make system-autofoo packages) by removing the ones provided by the system. AutoMake1.6: version 1.6.1 is provided by panther, the current fink version is 1.6.3. M4: version 1.4 is provided by panther (dev tools), do we need a fink version? It might sound stupid, but why not? M4 is not exactly huge and while I cab agree, that we might wish for a system- package, there is no reason at all to remove it. Shells: Bash: version 2.05b is provided by panther and i really can't see any reason to have a package for it to begin with, but ... Because some people, like me, like to build their bash with a few enhacements ;) I totally understand that, I do the same things sometimes too. :-) but i've noticed that the only packages that i've seen depend on bash doesn't need the enhancements, also how do I (as a fink user) choose which enhancements I get in fink's bash? I would end up compiling it again myself anyway, depending on what I want. ;-) Tcsh: version 6.12.00 is provided by panther and ditto the above from bash... Zsh: version 4.0.4 is provided by panther, the current fink version is 4.0.6 Editors: Emacs: version 21.2.1 is provided by panther, current fink version is 21.3 VIM: version 6.1 is provided by panther, current (just released) fink version is 6.2 Because I use features that are in 6.2 :=) already? its been out for like a week! ;-) Base: Gzip: version 1.2.4 is provided by panther, is there a real need? libiconv: version 1.8 is provided by panther, (?? newer than fink's in the tree...??) Ncurses: version 5.2-20020209 is provided by panther, the current fink version is 5.3-? Yes, some coding I do relies on 5.3 and I am sure I am not the only one. then let's keep it! :-) Tar: version 1.13.25 is provided by panther Libs: Libxml2: version 2.5.4 is provided by panther, the current fink version is 2.5.6 X11: X11 in panther and freetype2 and all that fun stuff, but you already know about it... :-) Net: postfix-release: version 2.0.7 is provided by panther, it has replaced sendmail (I'm sure everyone knows already...) the current fink version is 2.0.10 You wish to replace an _older_ version with a newer one? What kinda strategy is that ? :) What I'm suggesting is that any packages that need it figure out if they need the *latest* version or not. postfix isn't as small as auto* or m4. make a system-postfix package. Crypto: Openssl: version 0.9.6i is provided by panther (not 0.9.7x). Most packages that link against openssl don't care whether its 0.9.6i or 0.9.7a or whatever, i think that the move to defaulting to openssl097 was a bad idea. I think that packages should depend on openssl and only 097 if needed. openssl097 'provides' openssl so if john doe wants 097, just install 097 and everything will link against it. This is incorrect. 097 behaves differently, there have been symbol changes and even significant algorithmic changes. Therefore it is important to some (as you pointed out not many) packages what they link against. For example xmlsec needs 097 for proper AES support. Having packages which do not care and are frshly added to the tree depend on openssl 0.97 is very smart in my opinion because 097 introduces not only speed benefits, but security fixes and vast enhancements over the 0.96 tree. Personally I'm all for having the latest version, but not for something I hardly use and for a package which isn't small by any standards, unless you compare it to kde or mozilla. This isn't simply an option of replac
Fwd: [Fink-devel] Re: packages that are part of the system
On Sunday, July 27, 2003, at 6:16 PM, Ben Hines wrote: On Friday, July 25, 2003, at 05:02 PM, John Davidorff Pell wrote: Zsh: version 4.0.4 is provided by panther, the current fink version is 4.0.6 -snip much- I don't understand why you listed all these packages which fink has later versions. That's kinda the point of fink. Users want the latest can install the fink version, those who don't, don't. -Ben You're absolutely right, The packages I mentioned that had newer versions in fink I mentioned in hopes that a system-foo package be created for any other packages to depend on that need but don't need the newest version. JP --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: packages that are part of the system
Here's my rationale for wanting some fink packages to be removed (or a system-foo package created??): Devel: AutoConf2.5: version 2.57 is provided by panther, obviously the other autoconf packages would remain for compatibility. :-) AutoMake1.6: version 1.6.1 is provided by panther, the current fink version is 1.6.3. M4: version 1.4 is provided by panther (dev tools), do we need a fink version? Shells: Bash: version 2.05b is provided by panther and i really can't see any reason to have a package for it to begin with, but ... Tcsh: version 6.12.00 is provided by panther and ditto the above from bash... Zsh: version 4.0.4 is provided by panther, the current fink version is 4.0.6 Editors: Emacs: version 21.2.1 is provided by panther, current fink version is 21.3 VIM: version 6.1 is provided by panther, current (just released) fink version is 6.2 Base: Gzip: version 1.2.4 is provided by panther, is there a real need? libiconv: version 1.8 is provided by panther, (?? newer than fink's in the tree...??) Ncurses: version 5.2-20020209 is provided by panther, the current fink version is 5.3-? Tar: version 1.13.25 is provided by panther Libs: Libxml2: version 2.5.4 is provided by panther, the current fink version is 2.5.6 X11: X11 in panther and freetype2 and all that fun stuff, but you already know about it... :-) Languages: Perl 5.8.1 and all that, but its already covered... Python23: version 23b2 is provided by panther, obviously the older fink python packages should remain for compatability, but this one? Tcltk: this one is a little odd: Apple has provided tcl, but not tk...? i'm at a loss... Net: postfix-release: version 2.0.7 is provided by panther, it has replaced sendmail (I'm sure everyone knows already...) the current fink version is 2.0.10 Crypto: Openssl: version 0.9.6i is provided by panther (not 0.9.7x). Most packages that link against openssl don't care whether its 0.9.6i or 0.9.7a or whatever, i think that the move to defaulting to openssl097 was a bad idea. I think that packages should depend on openssl and only 097 if needed. openssl097 'provides' openssl so if john doe wants 097, just install 097 and everything will link against it. This is what I've seen so far, I realize that some packages should remain because of fink-specific changes or new versions or whatever, but some can be removed and some should have system-foo packages created for them. Some packages will be updated (i hope) b4 the public release of panther. I'd be happy to submit my own system-whatever packages if you're willing to use some of them (then again, its prob a better idea to have someone better than me write them...):-) -John -- God is dead, now the war shall never end. On Friday, July 25, 2003, at 5:51 AM, David R. Morrison wrote: I'm not sure if you got a response to your initial message or not. Apple has added a number of new open source pacakges with each major release of OS X. So far, fink's philosophy has been to keep providing a fink version of the package, even after Apple is providing their own. (The only exception to this that I can recall is with "libz", which is no longer provided by fink.) There are several reasons for this. One is that we don't yet trust Apple to be consistent in what they provide. (For example, they used to provide wget, which fink relied on, and then at a certain point they switched to curl. So we no longer trust them to provide either one of these, since they might switch back.) A second reason is that many users will already have the fink version of the library linked in to their packages, and upgrading becomes pretty tricky if we were to try to revert to Apple's version. A third reason is that Apple is not always good about keeping packages "current", and fink does that more frequently. All of that being said, there may be some reason to drop a few of the packages which Apple has added (or which they will add in 10.3). but these should be discussed on a case by case basis. -- Dave --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: packages that are part of the system
Replying to my own email Also, there have been lots of problems with ncurses, right? well, its in panther too! if we link against the apple libs so many problems with many packages will go away! Unless I'm missing something big (besides any possible upgrade schemes) this is the way to go! :-) JP -- Every time you share on a P2P network, God kills a kitten. Please think of the kittens. On Tuesday, July 15, 2003, at 2:26 AM, John Davidorff Pell wrote: I've noticed that a number of packages that are provided by fink are already included with the default install of MacOSX. i've found the following so far: AutoConf AutoMake Bash Emacs21 libiconv libxml2-2.5.4 m4 openssl-0.9.6i postfix python23 tcl (but not tk? I'm not sure) These are all in panther. Most are in Jag as well. libiconv is an essential package that need not be essential since its already there! I've made my own packages for the others (I don't like having redundant stuff on my comp) so when i build in fink my packages build against the system libs. I don't think this would break fink since there wouldn't be any systems without these packages. My $0.02. JP -- God is dead, now the war shall never end. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] packages that are part of the system
I've noticed that a number of packages that are provided by fink are already included with the default install of MacOSX. i've found the following so far: AutoConf AutoMake Bash Emacs21 libiconv libxml2-2.5.4 m4 openssl-0.9.6i postfix python23 tcl (but not tk? I'm not sure) These are all in panther. Most are in Jag as well. libiconv is an essential package that need not be essential since its already there! I've made my own packages for the others (I don't like having redundant stuff on my comp) so when i build in fink my packages build against the system libs. I don't think this would break fink since there wouldn't be any systems without these packages. My $0.02. JP -- God is dead, now the war shall never end. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Multiple processes
Has anyone done any work with making fink a little more friendly if I run multiple instances of it? iLike to have more than one compile going at a time, but on occasion I'll find that I started compiling foo and then want to compile bar which depends (not build depends) on foo and it'll delete the foo build folder which destroys the work that had already been done. I'm thinking a simple lock file would be perfect, with the PID of the fink process that started it as its contents. any ideas? Also, I think (for the future) that it would be very useful to developers to be able to see the dependancy tree for foo instead of just that foo depends on something which depends on dlcompat and glib2. am i making sense? Thx, JP -- God is dead, now the war shall never end. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] spam
i'd like to ask that the list be moderated. i got a digest last week that was PURE spam. nothing from anyone on the list. thanx, JP -- God is dead, now the war shall never end. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] bootstraping 10.3
Ok, so lets say that someone has the dev preview of panther and wants to do a clean install of fink. Does this mean that I have to cannibalize the fink-5.3 source installer and make it work with the 10.3 tree, or is there some easier path available? Thanx, JP -- God is dead, now the war shall never end. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] selfupdate-cvs
I'm not sure where i should send the question, but here goes: when i do fink selfupdate-cvs it has decided to so "su pell -c 'cvs ...'" where i have NEVER had it do the cvs update as anything other than root. i'm confused. where is this setting? how do I reset it? help? thanx, JP -- God is dead, now the war shall never end. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] System-* (Placeholder packages)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've noticed that there are a number of placeholder packages, I was just thinking of another, for Tcl/Tk which i just got from CVS, and it occurred to me that if we made placeholder packages for every package we'd be crazy. Is there a way (perhaps not for the next few releases) to have a 'generic' package that can be updated to provide for dependancies for the system, or even some built in automatic method? I'd be happy to help and/or test (I'm not sure if i would be much help if we do a built-in method). JP - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+hW+k7f73MXbrfvwRAuFxAJwN0j1u1w8TN0hvs5AegRvUxofhxwCfdQ5m TO8Nd291OoGo2wuYYxcnOsY= =1fG/ -END PGP SIGNATURE- --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] re: gettext prebinding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wonderful! ;) Since these are the first libs installed, would it be efficient to try to line them up to be immediately below the apple libs, so that *most* other libs that try to prebind wouldn't conflict? I don't install much *nix stuff outside of fink, and what I do is usually dependent on fink. I'd just think that that would be as unobtrusive as possible. $.02. JP Folks with fileutils and various other fink packages installed are harassed by thousands of prebinding warnings: Feb 11 07:44:07 G4 /usr/libexec/fix_prebinding: /sw/bin/cut could not be launched prebound. Feb 11 07:44:07 G4 /usr/libexec/fix_prebinding: /sw/bin/cut couldn't be prebound in the past, and probably can't be prebound now. Feb 11 07:44:07 G4 /usr/libexec/fix_prebinding: 2003-02-11 07:44:07 -0800: prebinding for cut done. Feb 11 07:44:16 G4 /usr/libexec/fix_prebinding: /sw/bin/find could not be launched prebound. Feb 11 07:44:16 G4 /usr/libexec/fix_prebinding: /sw/bin/find couldn't be prebound in the past, and probably can't be prebound now. dyld: ls: prebinding disabled because library: /sw/lib/libintl.1.dylib got slid Until we come up with a full prebinding database, I suggest we patch the gettext and libiconv packages to prebind libintl and libiconv dylibs, specifying random seg1addrs. It might not always work, but it will be better than the present "will NEVER work" situation. If another library conflicts, itll just fail to prebind. No big deal. Obviously this will only help for things that use only gettext and libiconv libraries, but there are quite a lot of apps in fink that only use those. :) (Along with everything in fileutils, others include stuff like, dpkg-split, dpkg-deb, gtar...) Objections... ? -Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+STma7f73MXbrfvwRAoRlAJ0eIsHOgz5oxE/yVmOeeBEsClesyACeOR3h wjrh0FsJOloYnZrPJbntRXQ= =2SMg -END PGP SIGNATURE- --- 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] DPKG and Building Darwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... ok so then how do i build darwin? (obviously the wrong list, but any pointers would be appreciated!) JP On Monday, February 10, 2003, at 01:37 AM, Martin Costabel wrote: On lundi, fév 10, 2003, at 08:16 Europe/Paris, John Davidorff Pell wrote: --SNIP-- Darwin-1.4 and earlier used dpkg to install its packages, but this is no longer true for Darwin-6.x (corresponding to Jaguar). It is now using a version of rpm (as in "RedHat Package Manager"). Debian was too GNU-infected, it seems, RedHat is more on Apple's wavelength. -- Martin - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+R3ga7f73MXbrfvwRAgnbAJ46WkFc+cDxnGcH+isM95ASmk25ZwCfUGRt aLvTVOuRW6RhEixi1zj1XBM= =dOZr -END PGP SIGNATURE- --- 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
[Fink-devel] DPKG and Building Darwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, The (seriously dated) HOWTOs on building darwin say that its based on a dpkg-like system, but that there is no database, so you cant use dpkg to install it. I don't want to make it share the database w/ fink, but can I use fink's dpkg to make a database to do it? On a semi-related note, would it be possible/practical to have fink/fink-copy manage and build darwin? I think that ALOT of people would be VERY interested in this. JP - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+R1HR7f73MXbrfvwRAtAbAJ9F9bXL61206YB/vrKJAXF+2rQlFQCdEWlb vMF3vC5G7fWLiDa0vkh+pPs= =vQGx -END PGP SIGNATURE- --- 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] Re: prebinding
uhhh.. So how do I tell it to give libabc the address 0x12345678 while keeping the executables at 0x? JP On Saturday, February 8, 2003, at 08:07 PM, Benjamin Reed wrote: On Saturday, February 8, 2003, at 10:56 PM, John Davidorff Pell wrote: -archive_cmds='$CC $(test .$module = .yes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' +archive_cmds='$CC $(test .$module = .yes && echo -bundle -prebind || echo -dynamiclib -prebind) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $tmp_verstring' How exactly did this end up prebinding it? You need a segment address too (-seg1addr ), or it doesn't end up prebinding, as far as I'm aware -- God is dead, now the war shall never end. --- 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] Re: prebinding
I may be very very wrong, but i think that this simply built the lib with the address that it defaulted to. It gave no errors about it for "libintl.1.dylid" but many other binaries gave errors about conflicting w/ "libintl.1.dylid" The later packages also gave me errors about conflicting w/ "libintl.1.dylid" so I think that it did prebind, but maybe in the wrong place. I dunno... JP On Saturday, February 8, 2003, at 08:07 PM, Benjamin Reed wrote: On Saturday, February 8, 2003, at 10:56 PM, John Davidorff Pell wrote: -archive_cmds='$CC $(test .$module = .yes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' +archive_cmds='$CC $(test .$module = .yes && echo -bundle -prebind || echo -dynamiclib -prebind) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $tmp_verstring' How exactly did this end up prebinding it? You need a segment address too (-seg1addr ), or it doesn't end up prebinding, as far as I'm aware -- God is dead, now the war shall never end. --- 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
[Fink-devel] Re: prebinding
I got "libintl.1.dylid" to compile prebound. I'm working on getting the rest of the bootstrap working. :) Here's a patch for the patch for gettext for the bootstrap. I'd appreciate it if one of the core-developers would look at it. :) Thanx, JP -archive_cmds='$CC $(test .$module = .yes && echo -bundle || echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != x0.0 && echo $verstring)' +archive_cmds='$CC $(test .$module = .yes && echo -bundle -prebind || echo -dynamiclib -prebind) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts -install_name $rpath/$soname $tmp_verstring' On Saturday, February 8, 2003, at 05:12 PM, Carsten Klapp wrote: Ahh yes, you're starting to discover the "fun" of prebinding those libs which depend on other libs. AFAIK a library can't be build prebound without specifying an explicit load address during compile time (adding -prebind is not enough when compiling libraries), AND when it depends on other libraries--like in this case--those libs must have been built prebound (which means manually patching the Makefile of each of those dependant libs to use a unique hexadecimal prebind load address). Unfortunately, that is all I know about prebinding, how to go about doing it is another matter. I've been pushing on the fink list to get everything prebound but personally I have had no success getting any of my libs to compile prebound either. Sorry, :( Carsten On Saturday, February 8, 2003, at 07:52 pm, John Davidorff Pell wrote: --SNIP-- -- God is dead, now the war shall never end. --- 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
[Fink-devel] Re: prebinding
Thanx so much again, but now I'm having a prob with libiconv. It prob just won't work, but i can't find the warning saying why it won't prebind. i'm bootstraping fink, with the modifications to the files before doing ./bootstrap.sh. when it starts compiling gettext, it eventually sprits out "ld: warning prebinding disabled because dependent library: /sw/lib/libintl.1.dylib is not prebound" but it hasn't build libiconv yet! (I assume that gettext makes its own) but then how do I prebind that? none of it will prebind if that one file (used by almost everything) won't. :( Any help would be appreciated, JP On Saturday, February 8, 2003, at 08:52 AM, Carsten Klapp wrote: Hi John, I dug up a copy of my old message from the list, here's the patch you need to apply. Note that it only works for packages which use autoconf/automake, all other packages Makefiles' will still have to be patched. From: Max Horn <[EMAIL PROTECTED]> Date: Sun Nov 17, 2002 6:08:54 pm Canada/Eastern To: Carsten Klapp <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: [Fink-devel] Packages which can be prebound right now At 17:11 Uhr -0500 17.11.2002, Carsten Klapp wrote: Hi all, I realized today that there are many fink programs which could be prebound right now but aren't, even though the fink dylib automatic prebinding isn't quite ready yet. Using 'otool -L' I made of list of binaries which link ONLY to Apple-supplied dylibs, there are probably more as this list reflects what I have installed. Files should be compiled and linked with the '-prebind' flag. If a file can't be prebound the compiler/linker just skips the prebinding step and spits out a warning. I'm proposing the following patch to fink: --- PkgVersion.pm-original Fri Oct 25 02:41:42 2002 +++ PkgVersion.pm Sun Nov 17 16:46:51 2002 @@ -1710,5 +1710,7 @@ my ($varname, $s, $expand); my %defaults = ( "CPPFLAGS" => "-I\%p/include", - "LDFLAGS" => "-L\%p/lib" ); + "LDFLAGS" => "-prebind -L\%p/lib", + "CFLAGS" => "-prebind", + "MFLAGS" => "-j8" ) my $bsbase = get_bsbase(); The problem with this is that could cause a *lot* of regressions. Feel free to modify your local version of Fink and try, or even better, bootstrap a clean new install using it (verifying that still works with your change). I am not really willing to put that into CVS just now, we are already trying to stabilize a fairly major change there, and I want to get a new release out of fink eventually. That said, one could always make a branch for this if you think it's useful to do so. Max -- --- Max Horn Software Developer email: [EMAIL PROTECTED]> phone: (+49) 6151-494890 -- God is dead, now the war shall never end.
[Fink-devel] init.(c)sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was just thinking, is it possible to make /sw/bin/init.csh check whether /sw/bin and /sw/sbin are already in the path, and if so not add them again? I ask this for several reasons most of them ending up being a shell within a shell with a path something like: /Users/pell/bin:/sw/bin:/sw/sbin:/Users/pell/bin:/sw/bin:/sw/sbin:/ bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/Developer/Tools:/usr/ X11R6/bin:/Developer/Tools Thanx, JP - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+RLGa7f73MXbrfvwRAuSTAJ9zyF32C2pCp95SxQdNiOybueQK+gCcCOSq kgDil2FAmadQ+Q6kGQ/M014= =RM+Q -END PGP SIGNATURE- --- 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] Prebinding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Would it be possible to add prebinding to the core fink files, so that other packages can start adding it? JP On Friday, February 7, 2003, at 10:36 AM, David wrote: - - --snip-- - -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+REt07f73MXbrfvwRAsDHAJ0VVeHvMFb/kayRUV5KiJNyqIvieACfTXMi Ho2opUqro4MRgOBgH59fZxE= =GpnL - -END PGP SIGNATURE- - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+REuE7f73MXbrfvwRAvQaAJ9vLffzIHnU5sHMVtHDh4EnGe76hQCfaMoZ 126el2c0NA0EGA/cT2te5/I= =VXFd -END PGP SIGNATURE- --- 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] Prebinding
Would adding (either manually, or automatically) -prebind/LD_PREBIND to packages break them if it doesn't work? I don't think so, so why not start adding this automatically so that if the package can be prebound, it is? Please tell me if I'm missing something big. Thanx, JP On Friday, February 7, 2003, at 10:36 AM, David wrote: --snip-- A lot of valuable information can be found here: http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/2rt_mach-o_overview/Executing_Mach_O_Files.html Furthermore it is not as simple as simply adding --prebind. Many pieces of software are not yet fixed to fully support prebinding, much less proper relocation nor 'reentrancy'. - -d - - ❜ Fantasie ist wichtiger als Wissen.❛ - Albert Einstein PGP.sig Description: PGP signature
[Fink-devel] Prebinding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apple's prebinding release notes (/Developer/Documentation/ReleaseNotes/Prebinding.html) say that in order to build a library/binary prebound, all you need to do is pass - -prebind to ld or define the LD_PREBIND environment variable. I'm wondering how hard it would be to to make fink build its stuff prebound? Is there a way I can have fink add -prebind to all builds? or a way to define LD_PREBIND for all builds? Thanx in advance, JP - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+Q/bI7f73MXbrfvwRAkx+AJ4k6g6tDZRBCCbOImQ5vEf8h02qtgCgn48/ AKpfEoaF0LW2krJa0bFiAvI= =hAmq -END PGP SIGNATURE- --- 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
[Fink-devel] GNUStep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Do any of our friendly fink developers out there have any plans to add a GNUStep package? If so, I'd like to help, if not, then would anyone like to help me? JP - -- God is dead, now the war shall never end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+MagC7f73MXbrfvwRAmArAJ0VmW4o3uIeyOgZwU/hjHdvfoL7igCfeyHS 56GsBommonqaGX57ko6k5Wk= =lpT+ -END PGP SIGNATURE- --- 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] Re: Apple's FFT(w), BLAS and LAPACK
I was thinking that a virtual package would be good if we could use it to "trick" existing packages than use fft/blas/lapack into using the native versions. Is there any way of having a virtual package change the gcc flags of a package that depends on it? JP On Friday, January 17, 2003, at 07:01 PM, Jeff Whitaker wrote: John: It's not quite that simple. Most packages need to be patched to use "-framework vecLib" instead of "-L%p/lib -latlas -llapack -lcblas". The fft stuff is problematic since I'm pretty sure the vecLib fft has a different calling interface than fftw. No virtual package is necessary - any 10.2 package can safely link the vecLib framework since it is part of the Dev Tools. -Jeff On Fri, 17 Jan 2003, John Davidorff Pell wrote: How easy would it be to write a virtual package that "provides: fft, blas, lapack" for 10.2? I can do it if someone would tell me how to add lines to the gcc string when another package builddepends on fft, blas, or lapack. JP --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1FAX : (303)497-6449 325 BroadwayWeb : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124 --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: Apple's FFT(w), BLAS and LAPACK
How easy would it be to write a virtual package that "provides: fft, blas, lapack" for 10.2? I can do it if someone would tell me how to add lines to the gcc string when another package builddepends on fft, blas, or lapack. JP --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Updating Fink via CVS
Hi all, sorry, in my hurry to find a fix, I didn't read the front page of fink "cvs server down" :) sry for the useless messages. Thanx in advance for not being mad at me! JP -- John Davidorff Pell [EMAIL PROTECTED] --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Updating fink via CVS
For the life of me I cannot figure out why fink won't update from CVS, unless its a problem at sourceforge. It prints the following when I run fink selfupdate-cvs (after the questions about 1st time config): cvs [login aborted]: connect to cvs.sourceforge.net:2401 failed: Operation timed out ### execution of cvs failed, exit code 1 Failed: Logging into the CVS server for anonymous read-only access failed. I upgraded to Jag last night and I wiped my system beforehand. I installed 5.0a from binary late last night (or this morning?) I've added the unstable/main and unstable/crypto trees to the fink.conf file. I also installed apple's X11 (but this couldn't break CVS, right?) I have not installed system-xfree86-4.2.0-3 yet, but I also haven't tryed to install anything. I looked on the CVS setup page on the fink site and it says that I can't do CVS from behind a firewall. I had Apple's pseudo-firewall (built into OSX) enabled, but disabled it as soon as I read that. I have also messed w/ my router's settings and have set my machine as in the "DMZ Zone". On fink's CVS webpage there's link to view CVS and that one also times out. I'm guessing its something to do w/ either the server or my supposed to be off firewall. In the past I've had apple's firewall on and used cvs with no problems. Thanx in advance, JP -- John Davidorff Pell [EMAIL PROTECTED] --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] .app's in fink
First, This is a STUPID discussion. That said, I'm going to add my $0.02. A normal user can write to /Applications b/c a normal mac user is the *only* user on the machine and is therefore (by default) the administrator as defined by apple's admin group. People here are arguing about what *should* be the case, how about we focus the yelling on what *is* the case. Apple has made it so that the normal admin user can mess w/ /Applications. Therefore, most users will want to be able to mess w/ /sw/Applications. I noticed someone asked about apple's way of keeping track of its apps when moved, and they use the same method as with aliases. each app is identifiable by its alias info. fink can make use of this if someone out there wants to spend the next six months re-writing dpkg. You want to ? Go ahead, I would love it! really! Granted that most users of fink know enough that if it is very difficult to move an app out of /sw/applications, you probably shouldn't, but at the same time, the user COULD force move the app and it would work, until dpkg looked for it. thus until there would probably be a long while between times dpkg looks for it and then the user might not know that moving the app was the problem with an error message that looks just like all the other unix messages he has ever seen. It is also possible to make .app packages that consist entirely of symlinks (but the .app package is still a real folder with a real info.plist). just link *.app/contents to some fink dir, or even *.app/contents/macos/appname to the fink binary in /sw/bin. this might actually work! (until you read this and find the gaping holes in my solution... ;)) I think that .apps should only be added on a per case basis and some usage of the above would be useful (symlinks rule!) JP --- 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] Apple's X11
I'm scared. ;) This looks a LOT like OroborOSX. anyone agree? JP http://www.apple.com/macosx/x11/ Just thought y'all should know :-) -- Finlay --- 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
[Fink-devel] Re: Fink - Package Database
Hello, I noticed that there is no fink package for libnids. so I made one. I'm not too sure how to submit it. libnids required only a simple patch (so that it looked in the bin directory for libnet-config). the .info file is exactly as described in the docs. thanx. -- John Davidorff Pell [EMAIL PROTECTED] --- 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
