[Fink-devel] Re: libtool module behavior and darwin
It's the correct solution AFAICS - from the same sources two libtool libraries are built - one is a system library that gets linked to the system binary. And the module libtool archive is separate from that. Both .la will be able to pick up the same .lo being compiled along, so it is nothing more than a single extra link stage in the make process. IOW, on linux/solaris this would be LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.so on systems like darwin it would boil down into LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.dylib Getting back to the question that followed from the original link problem: I am not sure whether the user-binary called kbackgammon does actually need a shared library to be built from. In the setup above, there would still need to be installed _two_ libraries into the target system, plus the dummy binary. Binding the '-module' kbackgammon.la as '-static' would still push two copies of the same .lo's into the system. It seems the original author did want to avoid having two copies of the program's library objects around, and this is in fact possible in most elf systems. The rpath will guide the system loader to find its -module so-library, whereever that one will end up. It is in fact a dependency on some system characteristics that are portable among modern systems being mostly elf based - but breaks when trying to port kde somewhere else. (btw, does that link-to-module work with cygwin?) That limits the portability of kde as whole, perhaps, and so the presented patch should really be merged back into kde, taking the burden to make two libraries even on elf systems. Still, I am asking myself if it might be in fact a good idea to guide all systems to link '-module' .la as static, that is not to give a '-lmodulelib' to the linker but a 'modulelib.a' - on all systems. Atleast, I'd propose to have a check - and utter a warning message when s.o. is trying to link a '-module' archive into a system binary. We could then see if someone comes around and barks at us what that warning message has to say. That might allow us to see where too that .so possiblity has been (ab)used. cheers, guido Nick Hudson wrote: On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote: One of the problems we're running into getting KDE working on Darwin is libtool's concept of a module, and how it's mapped onto Darwin's linker behavior. This was talked about some time ago by Michael Matz and myself. To get around issues with prebinding and speed of C++ code loading, especially on linux, KDE creates many of it's executables as shared libraries, linked twice, once as a module and once a binary. So the kbackgammon program is kbackgammon.so and kbackgammon, with main() existing in kbackgammon.so, and kbackgammon being linked against the .so and an empty dummy.cpp file to make linkers happy as far as making a program. I have create patches to the KDE build system that solves a related problem that affects NetBSD a.out platforms. I believe they should fix the Darwin problem. Unfortunately Michael never folded them back into KDE. I guess he is too busy. :( Nick $NetBSD: patch-aa,v 1.1 2002/05/31 14:02:54 skrll Exp $ --- kbackgammon/Makefile.am.orig Fri Oct 5 12:52:05 2001 +++ kbackgammon/Makefile.am @@ -2,21 +2,22 @@ INCLUDES = -I$(top_srcdir)/libkdegames -I$(top_srcdir)/libkdegames/kgame/ -I$(srcdir)/engines $(all_includes) bin_PROGRAMS = kbackgammon -lib_LTLIBRARIES = kbackgammon.la +lib_LTLIBRARIES = libkbackgammon_main.la kbackgammon.la -CLEANFILES = dummy.cpp - -kbackgammon_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \ +libkbackgammon_main_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \ ./engines/libkbgengines.la -kbackgammon_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \ +libkbackgammon_main_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \ kbgstatus.cpp +kbackgammon_la_LIBADD = libkbackgammon_main.la +kbackgammon_la_SOURCES = kbackgammon_main.cpp + kbackgammon_la_METASOURCES = AUTO kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module -avoid-version -kbackgammon_LDADD = kbackgammon.la $(top_builddir)/libkdegames/libkdegames.la \ +kbackgammon_LDADD = libkbackgammon_main.la $(top_builddir)/libkdegames/libkdegames.la \ $(LIB_KSYCOCA) -kbackgammon_SOURCES = dummy.cpp +kbackgammon_SOURCES = kbackgammon_main.cpp kbackgammon_LDFLAGS = $(all_libraries) $(KDE_RPATH) noinst_HEADERS = version.h kbg.h kbgboard.h kbgtextview.h kbgstatus.h @@ -34,9 +35,6 @@ messages: rc.cpp LIST=`find . -name \*.h -o -name \*.hh -o -name \*.H -o -name \*.hxx -o -name \*.hpp -o -name \*.cpp -o -name \*.cc -o -name \*.cxx -o -name \*.ecpp -o -name \*.C`; \ $(XGETTEXT) $$LIST -o $(podir)/kbackgammon.pot - -dummy.cpp: - echo dummy.cpp install-data-local: rm -rf $(kde_appsdir)/Games/kbackgammon.desktop
[Fink-devel] Re: libtool module behavior and darwin
On Monday 25 November 2002 10:04 am, Guido Draheim wrote: It's the correct solution AFAICS - from the same sources two libtool libraries are built - one is a system library that gets linked to the system binary. And the module libtool archive is separate from that. Both .la will be able to pick up the same .lo being compiled along, so it is nothing more than a single extra link stage in the make process. IOW, on linux/solaris this would be LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.so on systems like darwin it would boil down into LINK *.lo -o kbackgammon.so LINK *.lo -o libkbackgammon.dylib Getting back to the question that followed from the original link problem: I am not sure whether the user-binary called kbackgammon does actually need a shared library to be built from. In the setup above, there would still need to be installed _two_ libraries into the target system, plus the dummy binary. Binding the '-module' kbackgammon.la as '-static' would still push two copies of the same .lo's into the system. Here's what happends... The bulk of the code ends up in the shared library libkbackgammon_main.la. The kbackgammon.la module and the kbackgammon are both very small (a single function called main that calls kdemain) and they both depend on this dynamic library. It seems the original author did want to avoid having two copies of the program's library objects around, and this is in fact possible in most elf systems. The rpath will guide the system loader to find its -module so-library, whereever that one will end up. It is in fact a dependency on some system characteristics that are portable among modern systems being mostly elf based - but breaks when trying to port kde somewhere else. (btw, does that link-to-module work with cygwin?) I wtill think the original stuff was plain messy. That limits the portability of kde as whole, perhaps, and so the presented patch should really be merged back into kde, taking the burden to make two libraries even on elf systems. I still don't think this is a burden. The new shared object is very small, e.g. $ ls -l /usr/X11R6/lib/*konqueror*.so -rwxr-xr-x 1 root wheel4316 Nov 22 16:53 /usr/X11R6/lib/konqueror.so -rwxr-xr-x 1 root wheel 810685 Nov 22 16:53 /usr/X11R6/lib/libkonqueror_main.so Your position for getting this sort of fix into the KDE sources is much better than mine. NetBSD a.out is almost a distant memory - all platforms are now ELF in the latest release. Feel free to take the patches from NetBSD pkgsrc and makes noises with the KDE people. http://www.netbsd.org/Documentation/software/packages.html Nick --- 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] Re: libtool module behavior and darwin
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 snip Feel free to take the patches from NetBSD pkgsrc and makes noises with the KDE people. http://www.netbsd.org/Documentation/software/packages.html No need to make noise with the KDE people, I am reading this list *grins* If you have a patch against HEAD I will merge the patches into HEAD after the code Freeze which is still in effect for 3.1 If I cannot merge it myself, I will clarify it with the respective coders. Nick --- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE94f/diW/Ta/pxHPQRAwB8AJ0f5g5pvfwVRDgYZvi3zt1Fzv3WTQCfVLtu NIOcTU0uOrFWegKX2csY+aI= =r2pW -END PGP SIGNATURE- --- 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] Re: libtool module behavior and darwin
That's great news. I cannot, however, promise to have these available anytime soon. I would appreciate help. Anyone? I can certainly help out with this. While waiting for more input on this thread, I actually ended up coming up with the same solution last night. I woke up this morning to find my kdelibs build done, and your (Nick's) response in my inbox telling me to do the same thing. g If the netbsd patches aren't up-to-date with head, I will clean them up until they are, and help out in getting everything back into KDE HEAD. I've got commit access to KDE, although I try not to use it since it seems like I screw everything up every time I try to commit to their tree. =) So I guess the outcome of this is that yes, KDE is doing the wrong thing, but on most platforms it doesn't matter. Maybe libtool should instead give a warning when linking against a .la that was compiled with -module about not being portable, instead of coming up with some elaborate hack? I'm not sure if that's a good enough solution or not, but it would at least be something... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] To whom it may concern (namely all of you): The future of Fink as I see it.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hello list. After spending a few weeks with the developers on the #fink IRC channel, evaluating my new role and putting much thought into the structure of fink, I would recommend the following steps which I will gladly assist all of you with. 1.) Determine who the actual core coder are 2.) Organise them into a structure (give them email addresses under a unique domain for example) 3.) Arrange some sort of sponsored server for: a) bindist mirrors b) extra organisational tools c) (in my eyes) proper bug tracking 4.) Align the common helpers into groups, organise the documentation efforts 5.) Find a consensus on how to distribute and assess possible localisation efforts. A lot of the above mentioned points are rather abstract. Some work on my be-halve has already been invested. I have talked to rand-irc and sent him a mail concerning Server sponsorship, of course I will keep you all posted on this issue. I do not wish to come across as being rude or power hungry, but I like fink more by the day and if there is one thing I am able to do, then it is bringing some structure into chaotic systems. Fink is growing and we better start organising now, if we do not wish to be left with a rather big mess later. This means that we need to select certain standard procedures, elected maintainers for certain tasks and areas (if not already existent). I wish to distribute the load off Max's shoulders, aligning the special abilities we all have with Fink and the goals we wish to achieve. I will gladly put a lot of time into this, my main concern right now is getting the documentation a bit up to date, organising for mirrors and some place where we can organise the team better than on sourceforge. Comments, as per usual, are welcome. - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE94i5AiW/Ta/pxHPQRA5JTAKDEI67DM6N5PJdASd7lvySpddr+vwCgvePJ v1/bYdv98aJPSYITEZ63lSE= =MrjL -END PGP SIGNATURE- --- 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] To whom it may concern (namely all of you): The future of Fink as I see it.
Seems to me that sourceforge is serving our needs quite well, and I for one am proud that we were selected as their project of the month. That being said, the biggest need that we have IMO is for more volunteers, since there are a number of tasks that aren't get done as regularly or as systematically as they might. We could have a monitor the package submission tracker committee, a build distributions regularly committee, a sort the submitted bugs and assign them committee, and so on. The problem is not with resources like mirrors, but with finding enough interested people. Just my 2 cents. -- Dave --- 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] To whom it may concern (namely all of you): The future of Fink as I see it.
Regarding sourceforge: 1) Sourceforge has an extensive set of mirrors, which the fink bindist could be taking advantage of, I'm pretty sure, although probably to do this we need another configuration setting someplace. 2) It's probably also possible to allow others to mirror the bindist. At the time the change in bindist location was made last summer, we were not aware of anyone mirroring it (in spite of a public offer to do so having been in place for almost a year). If you think its important for us to offer this service, submit an item to the feature request tracker. 3) By special arrangement, we are not bound by the sourceforge size limits. -- Dave --- 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] To whom it may concern (namely all of you): The future of Fink as I see it.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Montag, November 25, 2002, at 04:00 Uhr, David R. Morrison wrote: Regarding sourceforge: 1) Sourceforge has an extensive set of mirrors, which the fink bindist could be taking advantage of, I'm pretty sure, although probably to do this we need another configuration setting someplace. Well I would not call their mirror system extensive, because in my eyes it is still pretty small. Yes, we should take advantage of existing solutions though and it might be very smart to contact sourceforge and arrange those special agreements so that we can benefit from it. Who is our sourceforge Contact and who could arrange this? 2) It's probably also possible to allow others to mirror the bindist. At the time the change in bindist location was made last summer, we were not aware of anyone mirroring it (in spite of a public offer to do so having been in place for almost a year). If you think its important for us to offer this service, submit an item to the feature request tracker. To be honest, I am discussing this with you guys here, because I do not want this to be a solitary effort, I want us all to agree on it. I find it very important to offer the interface and rather than entering something in a request tracker which will be looked at now and then or not at all, I will go and contact sourceforge to get things arranged. I do not wish to sound rude, harsh or power hungry, but I am a person who likes to get things done, not simply mention them somewhere 3) By special arrangement, we are not bound by the sourceforge size limits. I was never really concerned about that, sourceforge can be happy to have us, since we drive a lot of traffic toward their site, they will most likely always be corporative. - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE94j7XiW/Ta/pxHPQRAxFkAKC5jcBMNzNleO5K81LFHkFL+EMCHgCggos7 Wg4yGVQ+R8GnCema4CH71Sw= =mEHg -END PGP SIGNATURE- --- 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] To whom it may concern (namely all of you): Thefuture of Fink as I see it.
At 15:56 Uhr +0100 25.11.2002, David wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Montag, November 25, 2002, at 03:30 Uhr, David R. Morrison wrote: Seems to me that sourceforge is serving our needs quite well, and I for one am proud that we were selected as their project of the month. Well, I cannot relate to that, but Ia m sure, that it is an honour. There are issues with Sourceforge which will always hamper our further development. Questions like can we run perl cgi-scripts or not, will never arise on our own Server. I am pretty sure we can do it... not that I like the idea of doing it. And actually, having a team that works hard to maintain a server for me, so that I can concentrate of the actual issues, instead of having to bother maintaingin a server, seems like a boon to me. Furthermore mirroring binary distribution sets will always be a pain, I do not know if you read the request of a large university to mirror or binary packages. This is not easily possible, since there is no rsync provided by sourceforge and special arrangements would have to be made. So you did actually ask the SourceForge stuff? Or are you guessing? We did allow for rsync mirroring our bindist in the past, when it was still on the SF.net servers, BTW. I'd be interested to get the link to the suppor request tracker item where the SF.net team rejected the request for rsync of our stuff. Personally I dislike the single location with sourceforge and the fact that you are somewhat bound to their limit system. Ah, that's what it boils down to (like with 99% of the people I met who diss SF.net) - personal dislike :-) That being said, the biggest need that we have IMO is for more volunteers, since there are a number of tasks that aren't get done as regularly or as systematically as they might. We could have a monitor the package submission tracker committee, a build distributions regularly committee, a sort the submitted bugs and assign them committee, and so on. I can only agree and that is my strongest point. I wish to organise fink and that requires a lot of voluntary work. Work which no developer likes to do, because it is tedious and simply annoying, a lot like the paper work we all like to avoid if possible. I will try to find volunteers and I will try to sort them into groups with the permission of all of you. I will try to coordinate them and I will even try to recruit them. Yet a fink server, where I can create my own little word for them, using squiremail or horde, giving them their own email, etc, will make it a lot easier on you and me. We can, if we think it's useful, still have an own server, to host email addresses. Or other things, we have to... But right now, I am not willing to give up on SF.net that easily. I am very very happy with the services they have been and are still providing to us. I have watched projects in the past from SF.net, claiming they did not get all they needed. Dillo for example - just take a look at their homepage and have a good laugh about the help plea on it. A server we host on our own also means we have to maintain it on our own. Somebody has to pay the bandwidth, for example. You know what was the main reasons SF.net asked us to move the bindist from the webservers? No, not the disk space (a couple GB), it was the fact that we incurred multiple GB/day of load. So if we host our own bindist server, be prepared to pay for that. One option I see, if it turns out that indeed our bindist can't be rsynced to external mirrors, though: we could setup our own server to host a master copy of the bindist; we'd still rsync it to the SF.net servers, and mirrors could use it, but we'd try to restrict access to it otherwise (e.g. by letting the apt config files point to the SF.net mirrors by default, as before). The problem is not with resources like mirrors, but with finding enough interested people. I think there are enough interested people, but many are a bit hesitant with sourceforge, just like me. I hated the idea of becoming part of their net, just to submit to fink. But once more, that is a personal issue and I cannot speak for others. Yes it is a personal issue, and I wonder on what you base your claim that many are a bit hesitant with sourceforge. I have only encountered a handful of people for whom it was true, in all cases when pressed it boiled down to personal dislike. I have a personal like for them, and not just because I am personal friend to some of the staff, but that does figure in, too, I admit that. It also means I never worry about getting good support (and those people I talked to on complained about bad support from SF.net so far always were basing it about experiences they made over a year ago before SF.net restructured their QA). As for mirrors, I think it is important to gather an infrastructure now and not when it is nearly impossible to let those who are interested grow with
[Fink-devel] [Fwd: kde binary building is not portable :(]
After talking with the folks on #kde-devel, this is the e-mail that I sent to the kde core list. -Forwarded Message- From: Benjamin Reed [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: kde binary building is not portable :( Date: 25 Nov 2002 10:10:27 -0500 After a discussion on the libtool list of working around module behavior on Darwin, it has become evident that the way KDE treats libtool modules is not portable (and apparently is not how you're supposed to use them =) The issue is that while on elf platforms, modules and shared libraries are the same thing, there are platforms where this is not true. Darwin/MacOSX and NetBSD a.out are the two I know about, but there may be others as well. (for more info, see the thread at the libtool list:) http://mail.gnu.org/pipermail/libtool/2002-November/007235.html There are tons of places in the KDE code where people are linking against libtool libraries built with -module, but the most notable is in the dummy binaries, ie, the ones with main() in the .so file, and then a dummy.cpp that gets linked with that library to make the binary for non-kdeinit startup. For those, the NetBSD folks came up with this fix: -(before)- bin_PROGRAMS = foo lib_LTLIBRARIES = foo.la foo_la_SOURCES = main.cpp foo.cpp foo_SOURCES = dummy.cpp foo_LDADD = foo.la -(after)- bin_PROGRAMS = foo lib_LTLIBRARIES = foo.la libfoo_main.la libfoo_main_la_SOURCES = foo.cpp foo_la_SOURCES = libfoo_main.cpp foo_la_LIBADD = libfoo_main.la foo_SOURCES = foo_main.cpp foo_LDADD = libfoo_main.la -(snip!)- ...their change makes foo.cpp contain an extern int kdemain() as it's main function, and then the dummy files (foo_main.cpp and libfoo_main.cpp) actually each contain a main() that just call the kdemain(). It seems like this is kind of overkill, but I don't know if maybe it's because some kind of weird symbol-loading issue on other platforms... It certainly seems the safest way to do it. If kdeinit's behavior is going to stay this way in the near future, perhaps the easiest thing is to make an am_edit change or some kind of automake macro that lets us define something like: -(foo.am)- bin_KDEPROGRAMS = foo foo_SOURCES = foo.cpp # -- contains kdemain() instead of main() -(snip!)- ...and that auto-generates the above output (with a split foo.la and libfoo_main.la) automatically. We've been discussing this on the #kde-devel channel, and it sounds like an am_edit macro that does the above transform is the easiest workaround for this, and it allows for future removal of kdeinit if that is still a goal. Does this make sense? Do you need more info or clarification from me? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] FinkCommander feedback...
Regarding the FinkCommmander feedback issue.. In the last few days, I have gotten a lot of feedback mails sent via FinkCommander that constitute bug reports. That's not so nice for me, as it's quite hard to track issues sent to me via email - they easily get lost in the suffle (I get hundreds of mails/day), and others can't see them, sometimes leading to duplicate reports. As such, I wonder if it would be possible to change the Feedback feature yet again a bit... maybe one could provide a Report a bug command, which would open the link to the Submit new bug report page in the default browser... Just an idea, Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 --- 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] To whom it may concern (namely all of you): Thefuture of Fink as I see it.
At 16:16 Uhr +0100 25.11.2002, David wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Montag, November 25, 2002, at 04:00 Uhr, David R. Morrison wrote: Regarding sourceforge: 1) Sourceforge has an extensive set of mirrors, which the fink bindist could be taking advantage of, I'm pretty sure, although probably to do this we need another configuration setting someplace. Well I would not call their mirror system extensive, because in my eyes it is still pretty small. Yes, we should take advantage of existing solutions though and it might be very smart to contact sourceforge and arrange those special agreements so that we can benefit from it. What special agreements are you thinking about? Who is our sourceforge Contact and who could arrange this? To contact the SF.net team, we can file support requests, as everybody else, but they know fink. In addition, I have personal contacts. 2) It's probably also possible to allow others to mirror the bindist. At the time the change in bindist location was made last summer, we were not aware of anyone mirroring it (in spite of a public offer to do so having been in place for almost a year). If you think its important for us to offer this service, submit an item to the feature request tracker. To be honest, I am discussing this with you guys here, because I do not want this to be a solitary effort, I want us all to agree on it. I find it very important to offer the interface and rather than entering something in a request tracker which will be looked at now and then or not at all, I will go and contact sourceforge to get things arranged. I do not wish to sound rude, harsh or power hungry, but I am a person who likes to get things done, not simply mention them somewhere Fine. Still, the way to go is a support request tracker item. (NOT a FR item!). This will not go unheeded for long. Write something like this: HI I am from the Fink team, we'd like to know if it is currently possible to mirror our (speciall hosted, as you may know) binary distribution via rsync to external servers. If the answer is yes, could you tell us details. If it is no, can you tell is if there is a chance to make this possible in the future? Do that before you assume it's not possible :-) They usually answer quickly. In addition, I can ask them directly, too. Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 --- 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] Just some clarification..
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Montag, November 25, 2002, at 04:46 Uhr, Max Horn wrote: That sounds fine to me. Great *smiles* I really did not meant to word that wrongly. I guess that revives the discussiong from #fink which domain name to choose? :-) I talked to the people who own fink.info (it#s Glaxo International one of the biggest oil shipping companies world wide), I made it clear to them, that we cannot pay them money, but they seem interested none the less. On my part I would like to have finkdocu.org or finkdocs.info or morefink.info ideas? Spit it out ;) - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE94kw+iW/Ta/pxHPQRA3zxAJ4pRX2NG4zSiEvmlK8bZosT7hELWgCfU7GP bPQ87vRYT4XKBx4cjWkbbqU= =0F8j -END PGP SIGNATURE- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Fwd: [ alexandria-Support Requests-643623 ] Administrative inquiry
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Seems like they only wish to talk to you, so you can either tell them to talk to me, or you take over from here now, I must say, i am impressed, they do seem to look out after us. - -d Begin forwarded message: https://sourceforge.net/tracker/ ?func=detailatid=21aid=643623group_id=1 Category: SourceForge.net Website Group: Second Level Support Status: Closed Priority: 5 Submitted By: Darian Lanx (dmalloc) Assigned to: Jacob Moorman (moorman) Summary: Administrative inquiry Initial Comment: HI I am from the Fink team. we are currently looking into additional mirrors to the ones that sourceforge allready provides. We'd like to know if it is currently possible to mirror our (speciall hosted, as you may know) binary distribution via rsync to external servers. If the answer is yes, could you tell us details please? If it is no, can you tell us if there is a chance to make this possible in the future and if so, how long it might take? - -- Comment By: Jacob Moorman (moorman) Date: 2002-11-25 11:25 Message: Logged In: YES user_id=152443 Please direct this inquiry to Max Horn of the Fink team. As stated in the provided documentation, inquiries of this nature should not be submitted as support requests; the SourceForge.net staff team should be contacted directly for this specific class of inquiries. - -- You can respond by visiting: https://sourceforge.net/tracker/ ?func=detailatid=21aid=643623group_id=1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE94lHliW/Ta/pxHPQRA1eRAJ9jDL/wZmiVM1cEVIF5dZH1s9o+VwCffrYO cWpnF+lhhVyRpvDIlrYFDe0= =Wiqs -END PGP SIGNATURE- --- 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] FinkCommander feedback...
true enough, but if the finkcommander users email was the finkcommander mailing list. well then we'd just be assuming they are on the list which could very likely not be true. Well it's an idea i guess. [EMAIL PROTECTED] writes: That is a serious run on sentence, justin. :) Anyway that wouldn't really work.. Users need their own accounts so they will get our requests for more information.. -Ben -=[JFH] Justin F. Hallett Systems Analyst -=[JFH] Rendek Communications Inc. -=[JFH] [EMAIL PROTECTED] --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] future of Fink
The discussion earlier, plus some private emails I received, got me thinking some more about what Fink needs at this point. Actually, it's not *just* that we need volunteers; we need a more effective way of using the talents of people who are willing to volunteer. Just to give one example: the way that most of us in the Fink developer group got there was that we made some packages, submitted them to Fink, and eventually it became less trouble for the Fink-ers to give us commit access than to process our submissions. That procedure is not working so well right now, because the current Fink developers haven't found the time to keep up with all of the submissions. This means that the talents of many people are going unrecognized and unacknowledged, and of course after a while they drop out. Please don't drop out, if this describes you! We'll try to work out better ways of incorporating your efforts into Fink. -- Dave --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] FinkCommander feedback...
On Monday, Nov 25, 2002, at 19:32 Europe/Brussels, Max Horn wrote: However, there is a catch: to submit the item, the user has to be logged in on the sourceforge site. So, you'd also have to query the users SF.net username and password, then authenticate to the site, store the cookie you get from it, then submit the bug report. It is still true with the new 'remember' facility on SF ? I've the impression that since I once clicked that, I'm never again asked to login... Wrong ? Jean-Francois --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libtool module behavior and darwin
An alternate solution might be to change the kbackgammon exectuable to load the kbackgammon.so, too, instead of linking against it. Or is there anything else that needs to link against these loadable modules? Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [Fink-users] debianutils_1.23.tar.gz not found for selfupdate-cvs
On Monday, November 25, 2002, at 01:21 PM, Don MacQueen wrote: Running fink selfupdate-cvs Results in a lot of the usual stuff, then: The following 2 packages will be installed or updated: debianutils ncurses curl -f -L -O http://ftp.debian.org/debian/pool/main/d/debianutils/ debianutils_1.23.tar.gz This ESSENTIAL package needs to be mirrored at fink, they keep removing the sources. I just fixed it yesterday after it was updated to the latest version by someone else, then again removed by debian, not me, I know better than to update essential packages without mirroring them. :) To summarize: Essential packages may not have non-sourceforge/fink URLs. perhaps we should enforce this in the fink code itself, since we keep having this problem. -Ben --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] future of Fink
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Montag, November 25, 2002, at 10:03 Uhr, David R. Morrison wrote: Please don't drop out, if this describes you! We'll try to work out better ways of incorporating your efforts into Fink. I can only attest to what David has already been saying. I joined fink for the sole purpose of helping and now I think I found a way to do that. I will do my very best and surely invest more than 20 years of experience into this project, I will try to make this more efficient than it already is, but I will NEED your help. My first question is: Would you all be willing to fill out a survey? The survey would ask some questions such as: Who you are What your main interest is What interests you in fink (packaging, documentation, coding etc etc) That would help me to determine, what is most suited within fink for you. - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE94qdGiW/Ta/pxHPQRA70JAJ9OKJDZVGFk2XduG3Ww0cAup9qCDACfbbaL fzO5UpK5Me+hfQq6WPLnR3U= =Z2jq -END PGP SIGNATURE- --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Prompting for user input.
adam == adam hixson [EMAIL PROTECTED] writes: adam I'm in the process of preparing a package for mpich, a portable MPI adam implimentation. The thing is MPI uses either rsh or ssh to do its adam some of its business. One or both of these need to be properly adam configured to be used, and instructions for configuring them can be adam found on the mpich website. Who needs to configure it? The admin user, or the ultimate user? If the ultimate user, then that should be done by some tool the user runs, or some config file the user puts in their homedir. I highly doubt that a tool needs the *admin* user to ssh or rsh anywhere. If so, this sounds like a tool that I don't want installed in /sw anyway. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] future of Fink
On Monday, November 25, 2002, at 08:36 PM, Ben Hines wrote: Anyone is welcome to check out submitted packages on the submission tracker, even if you cant commit it, you can check the packages for obvious things like shared library dependencies, fink validate errors on .deb file or info file etc, etc, etc. I get rather tired of explaining the same things to everyone. :) -Ben This would be a lot easier if OmniWeb stopped calling everything it downloaded from the trackers download.php. Can this be fixed? --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] future of Fink
On Monday, November 25, 2002, at 06:36 PM, Ben Hines wrote: Anyone is welcome to check out submitted packages on the submission tracker, even if you cant commit it, you can check the packages for obvious things like shared library dependencies, fink validate errors on .deb file or info file etc, etc, etc. I get rather tired of explaining the same things to everyone. :) -Ben I have the same problem with my students. I've been explaining calculus to them for 20 years, and they still don't get it. Bill --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] pwlib
I am making myself a voice conference suite. I am trying to get a combination of pwlib, OpenH323, and gnome-meeting (I've gotten the first two done, need to test the third, results may change my mind for me). As part of this, I wanted the sound/pwlib to work, and the existing sources for the version 1.3.8 no longer exist. I fetched the 1.4.4 sources, proved that the upgrade was trivial, when I hit two problems that need answering before I post the diffs to the list. First, Stefano Rodriguez [EMAIL PROTECTED] is listed as the maintainer, should that remain, or do I take it? I don't mind taking it, but I'm not sure of the established protocol here, should I wait a bit, or what? (Note that I cc'ed him here). Second, pwlib seems to install all of it's stuff in /sw/lib/pwlib, which I thought violated some of the rules. It looks to me that there is really no very good reason for the separate directory. There is a good reason for a /sw/include/pwlib, but not /sw/lib/pwlib/include. Additionally, there is a /sw/lib/pwlib/tools/ that has a asnparser/ in it, full of source code and a executable binary. I haven't done any mib work, which is the only place I know that uses that asn stuff, but I am skeptical that all that source code has no place in a port (where you don't expect the full sources to get stuck). If I need to develop with it, I'm going to need the entire sources anyhow, the package wouldn't really help me. It seems that the installed hierarchy might be wrong, and I need this answered before I can upgrade the package. I need this info also for the OpenH323 package, because it builds nearly identically to the pwlib (no surprise there, same development team). Thanks! Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
