Re: [Fink-devel] ld: warning -prebind has no effect with -bundle
Koen van der Drift wrote: Still having a linker problem with a package I am working on (plplot). If I start building the package for the first time, compilation failes because of the error below. The dylibs libcsirocsa and libcsironn however are part of the package itself, so it is obvious it cannot find it. I tried adding -force_flat_namespace to the LDFLAGS (based on some googling), but that didn't help. If I rebuild the package, compilation works fine and finishes. This only happens when I turn on --enable-octave, so it could be related somehow to that package. ... g++ -bundle -bundle_loader /sw/bin/octave-2.1.50 -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd -L/sw/lib/octave-2.1.50 -loctave -lcruft -loctinterp -framework vecLib -L/sw/lib -ldfftw ld: warning -prebind has no effect with -bundle ld: warning can't open dynamic library: /sw/lib/libcsirocsa.0.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: warning can't open dynamic library: /sw/lib/libcsironn.0.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: warning multiple definitions of symbol _round /sw/bin/octave-2.1.50 definition of _round /usr/lib/libSystem.dylib(rndint.o) definition of _round ld: Undefined symbols: _csa_addpoints referenced from libplplotd expected to be defined in /sw/lib/libcsirocsa.0.dylib Wouldn't replacing -bundle_loader /sw/bin/octave-2.1.50 by -undefined dynamic_lookup work, too? -- Martin --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] qt2-g++2 and automatic build
Hi Remi. I think the real solution here is to get lyx-qt working with qt3. There is no restriction like that on installing qt3, and we'd be able to build lyx-qt automatically. Any qt3 gurus care to look at this? RangerRick? -- Dave --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] unstable and wrong links
hi girls and guys, maybe this question has been already answered in the past. but i cannot find a definite answer for this in the archives or in the FAQ. i have already tried the user-list, but with no success til now. since i am using unstable i have always problems with the downloads. i mean that the download server has version X and the info file shows version Y, where X Y. so the download obviously does not work. ok, the FAQ recommends to search for the package and to place is it into the /sw/src/ directory. sure this works, when you are happy to find the correct version of the file. but there are some drawbacks like: - it is not working all the time (sometimes i cannot find the right version) - it is boring, to search for so many packages in the net. - ease of use, because i want to start the update, go for a beer and come back in the morning, when everything is done. i understand that unstable means unstable and i expect some problems. why not, maintaing the lot of packages is really tough. isnt there a way of automatic link checking and checking the consistence of the info-files with the download locations? is there such a tool? if the problems could be found in advance i think this would also improve the confidence into fink - even for unexperienced users. is there an automatic testing of the info files? mabye this is the wrong location for the post, but any comments and corrections are highly appreciated. gottfried --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] fontconfig2
Has anyone been able to successfully use fontconfg 2.2? I can't get it to install libraries over version 1.0.4 (see below) and the Gimp guys don't like that I patched it in the configure script. I find it very odd that even 2.2.90 would have this same behavior. Does it simply insert incorrect version numbers, in which case it might be patched, or is it something wrong with my setup? I'm not sure how the fontconfig1 virtual package affects this, either. ls -lF /sw/lib/ | grep fontconfig -rwxr-xr-x1 root admin472016 13 Jan 06:11 libfontconfig.1.0.4.dylib* lrwxr-xr-x1 root admin25 13 Jan 06:12 libfontconfig.1.dylib@ - libfontconfig.1.0.4.dylib -rw-r--r--1 root admin564968 13 Jan 06:11 libfontconfig.a lrwxr-xr-x1 root admin25 13 Jan 06:12 libfontconfig.dylib@ - libfontconfig.1.0.4.dylib -rwxr-xr-x1 root admin 907 13 Jan 06:11 libfontconfig.la* This is what I've got in the .info file right now: Source: http://pdx.freedesktop.org/software/fontconfig/releases/fontconfig -2.2.90.tar.gz Source-MD5: 5cb87476743be1bbf1674ed72a76ae6a BuildDepends: freetype2, expat, libtool14 (= 1.5) ConfigureParams: --mandir='%p/share/man' --infodir='%p/share/info' --prefix='%p' --with-expat-includes='%p/include' --with-expat-lib='%p/lib' --with-freetype-config='%p/lib/freetype2/bin/freetype-config' Replaces: fontconfig1 In any case, the GIMP package won't install without a fairly recent set of fink-unstable packages, hence if the version numbers are incorrect a user shouldn't have to worry about crashes due to fontconfig. -Todd Heidesch --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unstable and wrong links
This isn't restricted to unstable--the stable tree has similar issues. The upstream sites who produce the sources change things around when new versions come out. What has been done is that Fink has Master mirrors set up, on which every source file is supposed to be available. This is in the FAQ, too. The master sites _are_ updated automatically, though when a new version of a package comes out it takes a while for the new source tarball to get mirrored. -- Alexander Hansen Levitated Dipole Experiment http://www.psfc.mit.edu/LDX On Jan 13, 2004, at 7:06 AM, Gottfried Szing wrote: hi girls and guys, maybe this question has been already answered in the past. but i cannot find a definite answer for this in the archives or in the FAQ. i have already tried the user-list, but with no success til now. since i am using unstable i have always problems with the downloads. i mean that the download server has version X and the info file shows version Y, where X Y. so the download obviously does not work. ok, the FAQ recommends to search for the package and to place is it into the /sw/src/ directory. sure this works, when you are happy to find the correct version of the file. but there are some drawbacks like: - it is not working all the time (sometimes i cannot find the right version) - it is boring, to search for so many packages in the net. - ease of use, because i want to start the update, go for a beer and come back in the morning, when everything is done. i understand that unstable means unstable and i expect some problems. why not, maintaing the lot of packages is really tough. isnt there a way of automatic link checking and checking the consistence of the info-files with the download locations? is there such a tool? if the problems could be found in advance i think this would also improve the confidence into fink - even for unexperienced users. is there an automatic testing of the info files? mabye this is the wrong location for the post, but any comments and corrections are highly appreciated. gottfried --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fontconfig2
Okay, I found out the library names are normal... How does one using Fink set the PKG_CONFIG_PATH correctly to help pkg-config? I tried this: CompileScript: PKG_CONFIG_PATH=%p/lib/pkgconfig:$PKG_CONFIG_PATH ./configure %c make install DESTDIR=%d That let the configure script find the fontconfig version, but everything else was screwed up; i.e. nothing outside of %p/lib/pkgconfig was found. So I'm still stuck. Wouldn't it make sense to set %p/lib/pkgconfig before the system libs by default, assuming most if not all packages in Fink are newer/better than the system release, or is there an issue of compatibility? -Todd --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Creating a user
Hey list, I can't find the procedure to follow in case of a daemon that require an extra user to run. Is updating the %p/etc/passwd-fink and %p/etc/group-fink files then running update-passwd safe? I didn't find any example in the info files. Thanx. -- Bertrand Pike Language - http://pike.ida.liu.se/ Caudium WebServer - http://caudium.net/ CAMAS WebMail - http://caudium.net/camas/ --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unstable and wrong links
On Jan 13, 2004, at 5:21 PM, Gottfried Szing wrote: hi alex This isn't restricted to unstable--the stable tree has similar issues. The upstream sites who produce the sources change things around when new versions come out. What has been done is that Fink has Master mirrors set up, on which every source file is supposed to be available. This is in the FAQ, too. can u please point me to the right location? i cannot find the point about the master mirrors. i have just found q4.14, which partially answers my question and solves my problems. When you run fink configure, you can specify using a Master mirror as your first site to hit. You can also select Use next mirror set Master when a download fails. The master sites _are_ updated automatically, though when a new version of a package comes out it takes a while for the new source tarball to get mirrored. sure, that is what i have experienced with debian and i know that this cannot be improved (not without certain amount of money for real-time-updates :))) ). in my case i have experienced this problem with two particular packages: the perl-package digest-md5 and file. both have been updated on the download-servers and the old versions have been removed. so the info file pointed to the old version which does no longer exist on one of the servers. so, for me this is quite fine, because i believe to know what was happening and i solved the problem for me. for unexperienced user this could a reason to not to use fink any more, because it could be frustrating. sure, noone forces them to use unstable, but who is not using the latest version of the software on a desktop system? It's possible, though it seems like most people post to the mailing list--which means that the problem gets known. and even in the case that the user is using stable, there is same problem (you have mentioned it at the beginning of the mail). this means that fink and the packagers relies on the feedback of users, if a package does no longer exist (huh, user feed back, is this really working?). i mean, one way to improve the confidence of normal users into fink is to ensure that at least the stable tree is consistent. Every so often somebody does a check by running fink fetch-all, which tries to download every package. This could be done more regularly--it's tedious, though, because I think there's about 1000 packages in the stable tree, and twice that in unstable. just my 2 euro-cents. dont bother to answer the mail, because i know, that you all have better things to do. thanks for the great work, keep on coding, gottfried --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Syntax for Variants (was Re: Idea: LangVersion field in .info)
Some time ago, Peter O'Gorman [EMAIL PROTECTED] said: Well, if you are going to go nuts, go totally nuts, make fink parse the same .info file multiple times with different values for the langauge, [...] then we could have one .info file with LangVersions: -py22 (2.2), -py23 (2.3) Or LangVersions: -pm560 (5.6.0), -pm561 (5.6.1), -pm580 (5.8.0), -pm581 (5.8.1) Fink would then generate all 4 packages. This one requires a *lot* more effort though, perhaps your way is better after all. Okay, I might have me and it going totally nuts very soon. Syntax check: how do we feel about extending the current Type thusly: Type: perl (5.6.0, 5.8.0, 5.8.1) to generate a set of packages where %lV and %lv take on each value in the list. For the case of just a single perl version, the parens could be optional (i.e., maintain compatibility with current state of affairs). dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unstable and wrong links
hi alex so, for me this is quite fine, because i believe to know what was happening and i solved the problem for me. for unexperienced user this could a reason to not to use fink any more, because it could be frustrating. sure, noone forces them to use unstable, but who is not using the latest version of the software on a desktop system? It's possible, though it seems like most people post to the mailing list--which means that the problem gets known. yep, thats correct. but this requires the user either to subscribe to a mailing list or to register at SF to report a bug. both a really huge burden for average mac os users. i think that they are a little bit lazy. :) and even in the case that the user is using stable, there is same problem (you have mentioned it at the beginning of the mail). this means that fink and the packagers relies on the feedback of users, if a package does no longer exist (huh, user feed back, is this really working?). i mean, one way to improve the confidence of normal users into fink is to ensure that at least the stable tree is consistent. Every so often somebody does a check by running fink fetch-all, which tries to download every package. This could be done more regularly--it's tedious, though, because I think there's about 1000 packages in the stable tree, and twice that in unstable. i have tried a different approach which does not download all the packages, because just checking for the existence of the file on the mirror is enough. i created a list of downloadable files with the help of fetch-all and the dryrun option which prints a list of urls. i always took the first url in the list (dryrun prints the name of the package, checksum and a list of download locations) and checked with a HEAD command (curl supports this, option -I ) and in combination with a proxy the existence for file. this brought up some non-working locations (503, 404, and time outs occured). so, this produces a not so high traffic (eg 5kb/package, which means about 15meg for unstable with about 3000 packages) and also, sorting the files by server allows curl to combine requests to the same server and reduces the cost of connection-setup. cu, gottfried --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [gnome-core] librsvg2-2.4.0-3
On Jan 13, 2004, at 4:32 PM, Ben Hines wrote:
On Jan 12, 2004, at 11:40 PM, Martin Costabel wrote:
Ben Hines wrote:
[]
ld: Undefined symbols:
_rsvg_set_default_dpi
This one has been answered many times (see also the post
fink-gnome-core black hole to fink-devel). You need to remove the
old version before compiling the new one. There is no good strategy
in such a situation as has been seen for many other packages in the
past.
No, i should not have to do that. There are hacks to get around such
situations, i have fixed them before in many packages.
And seriously folks, i am still sick of this user must {force depends,
remove old first, manually do foo} to use the new version of my
package bullshit which has been happening more and more recently.
There are solutions for everything. The last, last, last resort is
having the user do something. If a temp upgrade-package is required,
then that is preferred over having the user do something. If modifying
%p is required, then that is preferred to having the user do something.
Often there are much easier build time fixes. (as in this case) There
is always a way. If a user must manually do something to update a
package, please file a bug on the bug tracker.
These situations are NOT acceptible to fink users. These situations
STILL cause people to leave fink.
And no martin it doesn't matter that is has been 'answered many times'
by the gnome maintainers - it has never been asnwered (actually, until
sunday - once) on fink-devel or fink-users which are the fink mailing
lists. fink-gnome-core is the maintainer for the gnome packages, not a
fink discussion forum. I refuse to subscribe to it. Is it in the FAQ?
This is a package bug, not a user problem. Since it is a known 100%
problem that you know about, why do you not detect it when building and
error out with a useful message? This is just bad package maintenance.
Lets see, here... its using the not-yet-installed lib? Just move the
order of the link line, looks like this works, it builds just fine with
it:
SetLDFLAGS: -L./.libs
Works fine. No 'remove this first' crap needed. If there are problems
with that fix, i am sure we can find another one.. even if it means
manually linking the file in the installscript. TRY, people. This is
IMPORTANT. That is a REALLY EASY FIX. Yes it is 'hackish'. that is
preferred to telling fink users to do things. If you really hate it,
remove the line in a year when most folks will have updated. We've had
far worse hacks in fink packages for a long, long time.
-Ben
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [gnome-core] librsvg2-2.4.0-3
Keith Conger wrote: Hi, This is unstable. That may be, but these same problems will happen if/when it moves to stable. I agree with Ben, these are issues that can/should be worked around in the package, not in the user. -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE A computer scientist is someone who, when told to 'Go to Hell', sees the 'go to', rather than the destination, as harmful. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unstable and wrong links
I forgot all about dryrun. This sounds like a great thing for somebody to run every so often and post the bad connections to the maintainers. -- Alexander K. Hansen Levitated Dipole Experiment http://www.psfc.mit.edu/LDX On Jan 13, 2004, at 7:46 PM, Gottfried Szing wrote: i have tried a different approach which does not download all the packages, because just checking for the existence of the file on the mirror is enough. i created a list of downloadable files with the help of fetch-all and the dryrun option which prints a list of urls. i always took the first url in the list (dryrun prints the name of the package, checksum and a list of download locations) and checked with a HEAD command (curl supports this, option -I ) and in combination with a proxy the existence for file. this brought up some non-working locations (503, 404, and time outs occured). so, this produces a not so high traffic (eg 5kb/package, which means about 15meg for unstable with about 3000 packages) and also, sorting the files by server allows curl to combine requests to the same server and reduces the cost of connection-setup. cu, gottfried --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Fwd: passwd_20030621-1_darwin-powerpc.deb
I am no longer maintaining passwd, and it looks like this is a problem in the apt-get package depending on an old version anyway. -- Finlay Begin forwarded message: From: Alistair McMillan [EMAIL PROTECTED] Date: 13 January 2004 14:13:54 GMT To: [EMAIL PROTECTED] Subject: passwd_20030621-1_darwin-powerpc.deb I'm not entirely certain if I'm sending this to the right place, but anyway... I installed Gimp last night using apt-get on Panther. The passwd_20030621-1_darwin-powerpc.deb package that apt-get downloads changed the postfix UID from 27 to 255. Postfix was not amused. Jan 13 10:00:00 anakin postfix/pickup[27590]: fatal: scan_dir_push: open directory maildrop: Permission denied Jan 13 10:02:09 anakin postfix/smtpd[27591]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:04:50 anakin postfix/smtpd[27594]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:07:31 anakin postfix/smtpd[27597]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:10:12 anakin postfix/smtpd[27600]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:12:53 anakin postfix/smtpd[27603]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:15:00 anakin postfix/pickup[27613]: fatal: scan_dir_push: open directory maildrop: Permission denied Jan 13 10:15:34 anakin postfix/smtpd[27606]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:18:15 anakin postfix/smtpd[27616]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:20:56 anakin postfix/smtpd[27619]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:23:37 anakin postfix/smtpd[27622]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:26:18 anakin postfix/smtpd[27625]: fatal: connect #11 to subsystem public/cleanup: Permission denied Jan 13 10:28:59 anakin postfix/smtpd[27630]: fatal: connect #11 to subsystem public/cleanup: Permission denied Changing the UID back in NetInfo made Postfix healthy again. I notice as well that the passwd_20031026-2_darwin-powerpc.deb package that Fink itself downloads has the correct UID. If I'm being an idiot and doing something stupid or sending this message to the wrong place, my apologies for bothering you. - Alistair - Alistair [EMAIL PROTECTED] http://www.mcmillan.cx --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [gnome-core] librsvg2-2.4.0-3
Hi,
This is unstable.
Keith
On Jan 13, 2004, at 7:57 PM, Ben Hines wrote:
On Jan 13, 2004, at 4:32 PM, Ben Hines wrote:
On Jan 12, 2004, at 11:40 PM, Martin Costabel wrote:
Ben Hines wrote:
[]
ld: Undefined symbols:
_rsvg_set_default_dpi
This one has been answered many times (see also the post
fink-gnome-core black hole to fink-devel). You need to remove the
old version before compiling the new one. There is no good strategy
in such a situation as has been seen for many other packages in the
past.
No, i should not have to do that. There are hacks to get around such
situations, i have fixed them before in many packages.
And seriously folks, i am still sick of this user must {force
depends, remove old first, manually do foo} to use the new version
of my package bullshit which has been happening more and more
recently. There are solutions for everything. The last, last, last
resort is having the user do something. If a temp upgrade-package is
required, then that is preferred over having the user do something. If
modifying %p is required, then that is preferred to having the user do
something. Often there are much easier build time fixes. (as in this
case) There is always a way. If a user must manually do something to
update a package, please file a bug on the bug tracker.
These situations are NOT acceptible to fink users. These situations
STILL cause people to leave fink.
And no martin it doesn't matter that is has been 'answered many times'
by the gnome maintainers - it has never been asnwered (actually, until
sunday - once) on fink-devel or fink-users which are the fink mailing
lists. fink-gnome-core is the maintainer for the gnome packages, not a
fink discussion forum. I refuse to subscribe to it. Is it in the FAQ?
This is a package bug, not a user problem. Since it is a known 100%
problem that you know about, why do you not detect it when building
and error out with a useful message? This is just bad package
maintenance.
Lets see, here... its using the not-yet-installed lib? Just move the
order of the link line, looks like this works, it builds just fine
with it:
SetLDFLAGS: -L./.libs
Works fine. No 'remove this first' crap needed. If there are problems
with that fix, i am sure we can find another one.. even if it means
manually linking the file in the installscript. TRY, people. This is
IMPORTANT. That is a REALLY EASY FIX. Yes it is 'hackish'. that is
preferred to telling fink users to do things. If you really hate it,
remove the line in a year when most folks will have updated. We've had
far worse hacks in fink packages for a long, long time.
-Ben
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
fink-gnome-core mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-gnome-core
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: [gnome-core] librsvg2-2.4.0-3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Hines wrote: | SetLDFLAGS: -L./.libs | | Works fine. No 'remove this first' crap needed. If there are problems | with that fix, i am sure we can find another one.. even if it means | manually linking the file in the installscript. TRY, people. This is | IMPORTANT. That is a REALLY EASY FIX. Yes it is 'hackish'. that is | preferred to telling fink users to do things. If you really hate it, | remove the line in a year when most folks will have updated. We've had | far worse hacks in fink packages for a long, long time perl -pi -e 's/hardcode_direct=yes/hardcode_direct=no/g' configure Will also often fix this. You may need to do hardcode_direct_CXX too if the build uses c++. If you use setLDFLAGS: -L./.libs please make sure it does not end up in the installed .la's dependency_libs. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQATFsbiDAg3OZTLPAQKetwP/WFA3vhDKKfOTeJNOkVn/ZH8H62Nm3+yQ rTDgkaHQChrzvUYRHqJpSA3ryFJNtsP6RmVbCWxXh9DDGayTzapjlpE90raBLyUc DFvjMEfQ/eqLNx3I0an43V65QDPaEeT+0AHRaQV05SKAn0vjwsFwQkf9fRcHducY BkZy66yDloM= =eAhW -END PGP SIGNATURE- --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [gnome-core] librsvg2-2.4.0-3
Benjamin Reed wrote:
That may be, but these same problems will happen if/when it moves to
stable. I agree with Ben, these are issues that can/should be worked
around in the package, not in the user.
Dear Ben and Ben,
while you are right in principle and these problems should, of course,
be fixed in the package, I do not agree with the assessment of what is
needed in the short run.
And seriously folks, i am still sick of this user must {force
depends, remove old first, manually do foo} to use the new version of
my package bullshit which has been happening more and more recently.
This has not been happening more and more recently. This has been
happening regularly when big updates where put into unstable. It is a
first aid to users who otherwise would be blocked and could not continue
to build the new unstable packages and detect more bugs.
There are solutions for everything. The last, last, last resort is
You are forgetting the time factor. There are short-term solutions and
long-term solutions. Plus, finding the short-term solution gave a hint
what the cause of the error is (the maintainer obviously hadn't seen the
error himself or he would have fixed it).
You only reported the error to a forum where the same error had been
reported before, without looking at its cause or giving any hint at how
it could be solved.
I took at least the time to find out where the error came from and I
gave a temporary workaround. And I announced this workaround on
fink-gnome-core so that the maintainer was aware of it, and on
fink-devel so that others could help think about a real solution.
having the user do something. If a temp upgrade-package is required,
then that is preferred over having the user do something. If modifying
%p is required, then that is preferred to having the user do something.
Often there are much easier build time fixes. (as in this case) There is
always a way. If a user must manually do something to update a package,
please file a bug on the bug tracker.
These situations are NOT acceptible to fink users. These situations
STILL cause people to leave fink.
I disagree again. What is more likely to cause people to leave fink
(people here mean users who were lured by the infomation-less ramblings
on the fink home page to try out the new gnome-2.4, who knew that this
was unstable and were prepared to meet some difficulties, but who often
had not much prior experience with Fink):
An answer like I gave: Do fink remove freetype freetype-hinting
librsvg2, your build will then work,
Or an answer that you seem to prefer: The bug you are reporting has
been taken into account, thank you, the maintainer will look after it as
soon as he has the time, come back in about two weeks
Do you want people go away after having reported one bug, or do you want
to help them with a quick hack so they can continue building the new
stuff and find more bugs and/or try out the new programs?
For me, the choice is clear.
--
Martin
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
