Re: [Fink-devel] Security issue of gv

[David R. Morrison]

On Aug 20, 2007, at 2:09 PM, Tomoaki Okayama wrote:

> Hello,
>
> I found a security issue of gv, i.e. CVE-2006-5864.
> References:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5864
> http://www.debian.org/security/2006/dsa-1214
>
> The patch for this problem can be got from
> http://security.debian.org/pool/updates/main/g/gv/gv_3.6.1-10sarge2.diff.gz 
> .
> debian/patches/CVE-2006-5864.diff is the patch.
> Please apply it to gv in 10.3/unstable and 10.4/unstable.
> Or, updating to gv-3.6.3 also fixes this problem.
>
> If there is no maintainer of gv, we "Todai Fink Team" would
> like to maintain gv. Would it be ok?
>
> Thanks,
> Tomoaki Okayama

There is no current maintainer for gv, so the Todai Fink Team is  
welcome to take it.

   -- Dave


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] latest screen and /sw/etc/screenrc

[David R. Morrison]

On Aug 19, 2007, at 12:43 PM, William Scott wrote:

> Hi Citizens:
>
> The latest screen seems not to recognize the "deflogin" command in /
> sw/etc/screenrc.  It flashes an evanescent warning but seems to
> function ok otherwise, as far as I can tell. (I had no idea there was
> anything in /sw/etc/screenrc before today).
>
> If I feed the same screenrc to Apple's version, (which seems to be
> the same version), it opens without complaint, so I assume something
> changed recently in the patch fink uses.
>
>
> zsh-% /usr/bin/screen --version
> Screen version 4.00.03 (FAU) 23-Oct-06
>
> zsh-% /sw/bin/screen --version
> Screen version 4.00.03 (FAU) 23-Oct-06
>
> Thanks.
>
> Bill

Bill,

I am prohibited from explaining exactly why the change was made, but  
it was in preparation for the future.

Can you describe the phenomenon you are seeing in a bit more detail?   
What triggers it?

   -- Dave



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Fink-devel Digest, Vol 16, Issue 1

[David H.]

>
> Friends -
> I'm working on an update to the aspectj port, and I need advice on
> what to fill in for the License field.  The current value is OSI-
> Approved, which is probably incorrect.  AspectJ (TM) is distributed
> under the EPL, which is OSI-Approved, but it includes Third Party
> Content licensed under the Apache Software License (also OSI-
> Approved).  It also includes ASM v2.2.1, which is licensed by INRIA
> under the following conditions:
>
The license you have shown looks like a BSD Type license, which is
OSI-Approved, so I think you are fine with what you have.

-d

David H.
Fink PR/Admin
FDN Board

-- 
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gnucash-1.8.12-11

[David Reiser]

At this point, you probably would prefer gnucash2 (much more recent  
version(s), 2.2.0 just made it  up tonight). Your Xcode tools is  
pretty old -- most recent is 2.4.1, but I don't know if that's a  
problem.

Gnucash2 is the package name in fink. You still start it as 'gnucash'  
in the x11 window.

Dave
On 31 Jul 2007, at 1:02:11 PM, Janssen Vanderhooft wrote:

>
> Hi,
>
> I'm trying to install gnucash with fink, and everything built and  
> installed.  When I try to launch gnucash from X11, the splash  
> window comes up, runs through some startup things and closes, then  
> the "Welcome to GnuCash" and "Tip of the Day" windows open, but do  
> not get filled with any content.  After a few seconds, these  
> windows close and the terminal gives a "Bus error" message.  I'm  
> appending the output from "gnucash --debug".  I checked my home  
> folder, and the .gnucash/ directory does not exist.
>
> Any help would be appreciated, I've been looking for a good, free  
> financial software package and haven't had much luck.  I've just  
> been using a spreadsheet, which gets tedious very quickly.
>
> Thanks.
>
> --xterm output--
> Julius:~ Janssen$ gnucash --debug
> gnucash: [D] "files to open: "()
> gnucash: [D] "starting up (2)."
> gnucash: [D] "gnc:find-file looking for ""finance-quote-check"" in  
> "("/sw/share/gnucash")
> gnucash: [D] "  checking for ""/sw/share/gnucash/finance-quote-check"
> gnucash: [D] "found file ""/sw/share/gnucash/finance-quote-check"
> gnucash: [D] "gnc:find-file looking for ""finance-quote-helper"" in  
> "("/sw/share/gnucash")
> gnucash: [D] "  checking for ""/sw/share/gnucash/finance-quote-helper"
> gnucash: [D] "found file ""/sw/share/gnucash/finance-quote-helper"
> gnucash: [D] "loading system configuration"
> gnucash: [D] "gnc:find-file looking for ""config"" in "("/sw/etc/ 
> gnucash")
> gnucash: [D] "  checking for ""/sw/etc/gnucash/config"
> gnucash: [D] "found file ""/sw/etc/gnucash/config"
> gnucash: [D] "loading user configuration"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/ 
> config-1.8.user"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/ 
> config-1.6.user"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/config.user"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/ 
> config-1.8.auto"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/ 
> config-1.6.auto"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/config.auto"
> gnucash: [D] "loading saved reports"
> gnucash: [D] "trying to load ""/Users/Janssen/.gnucash/saved- 
> reports-1.8"
> gnucash: [D] "Running functions on hook "report-hook
>   #
> gnucash: [D] "Running functions on hook "startup-hook
>   #
> gnucash: [D] "Running functions on hook "ui-startup-hook
>   #
> gnucash: [D] "Running functions on hook "add-extension-hook
>   #
>   #
>   #
>   #
>   #
> Bus error
> Julius:~ Janssen$
>
>
> --
> Package manager version: 0.27.6
> Distribution version: 0.8.1.rsync i386
> Mac OS X version: 10.4.10
> Xcode version: 2.2.1
> gcc version: 4.0.1 (Apple Computer, Inc. build 5250)
> make version: 3.81
> Feedback Courtesy of FinkCommander
>
>
> --
> Janssen Vanderhooft
>
>
>
> -- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/ 
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel

--
David Reiser
[EMAIL PROTECTED]


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gc fails to build with XCode 2.3

[David R. Morrison]

On Jul 21, 2007, at 4:14 PM, Jack Howarth wrote:

> Dave,
>Why remove the gc package when you could just add a BuildDepends
> on cctools (>= 622-1)? Actually, if more packages had such  
> dependencies
> it might help accelerate the addition of an Xcode virtual package
> to fink (to make the relationship between a particular cctools package
> and Xcode version clearer).
>   Jack
>

Sorry that my first message was not so clear.

If I drop gc, it will only be the 7.0 version with is dropped.  I'll  
revert to an older version which works properly.

And the reason for dropping it would *not* be the XCode issue, but  
rather, the fact that when used in other packages, the newest gc  
package appears to cause crashes.

   -- Dave



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gc fails to build with XCode 2.3

[David R. Morrison]

In addition to this XCode issue, I've received a few private bug  
reports about the new gc package.  If I can't resolve them soon, I  
may remove the package from fink.

   -- Dave


On Jul 19, 2007, at 3:05 PM, Jens Noeckel wrote:

> Hi,
>
> gc (7.0-1001) compiles fine with XCode 2.4 on an Intel Core Duo  
> machine, but fails to compile on the same architecture with Xcode  
> 2.3, where I have gcc version: i686-apple-darwin8-gcc-4.0.1 (GCC)  
> 4.0.1 (Apple Computer, Inc. build 5341).
>
> I guess this is again related to the question of having an xcode  
> virtual package to keep track of the required XCode Tools version  
> (discussed recently on this list).
> Right now the build on XCode 2.3 fails with an error that won't  
> tell people how to fix the problem (see below).
> It would perhaps be good to have a warning, "compiler out of date",  
> to remind people to update their XCode. I think some packages do  
> this, but can't recall where I've seen this before. Maybe this is  
> just hand-coded as a test in the .info file  somehow?
>
> Jens
>
>
> Here is the error message I get building gc on Mac Intel Core Duo  
> (10.4.10) and XCode 2.3:
>
> gcc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" - 
> DPACKAGE_VERSION=\"7.0\" "-DPACKAGE_STRING=\"gc 7.0\"" - 
> DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DGC_VERSION_MAJOR=7 - 
> DGC_VERSION_MINOR=0 -DPACKAGE=\"gc\" -DVERSION=\"7.0\" - 
> DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 - 
> DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 - 
> DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 - 
> DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 - 
> DHAVE_DLFCN_H=1 -DNO_EXECUTE_PERMISSION=1 -DALL_INTERIOR_POINTERS=1  
> -DGC_GCJ_SUPPORT=1 -DJAVA_FINALIZATION=1 -DATOMIC_UNCOLLECTABLE=1 - 
> I./include -fexceptions -I ./libatomic_ops/src -fno-common - 
> DGC_DARWIN_THREADS -DLARGE_CONFIG -g -UNO_DEBUGGING -I/sw/include - 
> MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fno-common - 
> DPIC -o .libs/os_dep.o
> os_dep.c: In function 'GC_dirty_init':
> os_dep.c:3749: error: 'x86_THREAD_STATE32' undeclared (first use in  
> this function)
> os_dep.c:3749: error: (Each undeclared identifier is reported only  
> once
> os_dep.c:3749: error: for each function it appears in.)
> os_dep.c: In function 'catch_exception_raise':
> os_dep.c:3869: error: 'x86_EXCEPTION_STATE32' undeclared (first use  
> in this function)
> os_dep.c:3870: error: 'x86_EXCEPTION_STATE32_COUNT' undeclared  
> (first use in this function)
> os_dep.c:3871: error: 'x86_exception_state32_t' undeclared (first  
> use in this function)
> os_dep.c:3871: error: parse error before 'exc_state'
> os_dep.c:3891: error: 'exc_state' undeclared (first use in this  
> function)
> make[1]: *** [os_dep.lo] Error 1
> make: *** [all-recursive] Error 1
> ### execution of make failed, exit code 2
> Removing runtime build-lock...
> Removing build-lock package...
> /sw/bin/dpkg-lockwait -r fink-buildlock-gc-7.0-1001
> (Reading database ... 168161 files and directories currently  
> installed.)
> Removing fink-buildlock-gc-7.0-1001 ...
> Failed: phase compiling: gc-7.0-1001 failed
>


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] ruby16

[David R. Morrison]

I propose that ruby16 join the list of obsolete versions of language  
packages that we won't support in 10.5.  (The others already on this  
list are perl581, perl581, python23, and java13.)  We would retain  
ruby 18.

Does anybody forsee any problems with this?

   -- Dave


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gnucash-1.8.12-11

[David Reiser]

On 29 Jun 2007, at 3:38:01 PM, John & Mary Linge wrote:

> I attempted to upgrade from gnucash 1.8.11-1024 to 1.8.12-11. I could
> not because of a restrictive dependency on Perl 5.8.6, which isn't  
> even
> available any longer through Fink. I have Perl 5.8.8 installed, but
> apparently gnucash can't use it.
>
> Thanks for any help you can give.
>
> By the way, I attempted to install 2.0.1-1 with the same error  
> messages.
>
>
>
> --
> Package manager version: 0.27.1
> Distribution version: 0.8.1.rsync powerpc
> Mac OS X version: 10.4.10
> Xcode version: 2.4
> gcc version: 4.0.1 (Apple Computer, Inc. build 5363)
> make version: 3.80
> Feedback Courtesy of FinkCommander
>
I'm currently running gnucash2-2.0.5 against fink's perl 5.8.8, but  
you do have to make sure that all the gnucash's perl dependencies  
(finance-quote and its dependencies) were built with perl 5.8.8 too  
-- the names for all those dependencies have -pm588 in them (or no - 
pmxxx at all).

You might even be able to make it work just by removing fink's perl  
5.8.8 (provided your 'built-in' 5.8.6 is still in its usual place).

2.0.5 is much better than 1.8.x (IMO).  In a pinch you can even go  
back and forth as long as you're willing to swap versions with fink  
when ever you want to change. (That swapping won't be possible when  
2.2 is released in a few weeks. 2.2 will still read the 1.8 file, but  
you won't be able to go back with the data to the earlier version.)

Dave
--
David Reiser
[EMAIL PROTECTED]


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Nominate Fink on Sourceforge

[David H.]

Hello all.

Sourceforge has started their 2007 Community Choice Awards.

If you think that Fink deserves to be mentioned, please visit our
project page on SF and nominate us.

Or click this link:
http://sourceforge.net/awards/cca/nomination.php?group_id=17203&from=http%3A%2F%2Fsourceforge.net%2Fprojects%2Ffink%2F

You NEED to be logged into your SF account for this to work.

Thank you!

-- 
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Fink on WWDC Leopard

[David R. Morrison]

On Jun 19, 2007, at 11:41 AM, Joe Block wrote:

> I'm trying to bootstrap fink from the source tarball on the  
> download page onto a machine running WWDC Leopard, but I'm having  
> issues. Is there a specific tag I can check out from CVS that is  
> known to work?
>

fink-0.24.3.tar.gz, released last Friday, is known to work.

   -- Dave



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] the Distribution field

[David R. Morrison]

On Jun 18, 2007, at 6:34 AM, Hanspeter Niederstrasser wrote:

> David R. Morrison wrote:
>> Dear Fink developers,
>>
>> I have added a Distribution field to fink packages which involve
>> python or perl.
>
> But it can be used for any package, not just perl/pythonmods, right?

Right.

>
>> As some of you will recall, we are sharing files between fink's 10.4
>> and 10.5 distributions.  Also, fink's 10.5 distribution does not
>> contain python 2.3, perl 5.8.1, or perl 5.8.4.
>>
>> The added lines
>>
>> Distribution: (%type_pkg[python] = 23) 10.4
>
> Can we have a percent expansion, perhaps %{dist} to represent the  
> value
> of Distribution: so that it can be used elsewhere in the .info  
> (like for
> determining build settings)?

I think it will almost always be easier to have separate .info files  
in this situation, rather than trying to parse %{Distribution}.  (I'm  
willing to be convinced otherwise by some examples.)

Note that we also have a mechanism to make it easy to have separate  
into files:  you can have a file named foo-10.4.info which includes  
"Distribution: 10.4" as well as a file named foo-10.5.info which  
includes "Distribution: 10.5".

   -- Dave



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] the Distribution field

[David R. Morrison]

Dear Fink developers,

I have added a Distribution field to fink packages which involve  
python or perl.

As some of you will recall, we are sharing files between fink's 10.4  
and 10.5 distributions.  Also, fink's 10.5 distribution does not  
contain python 2.3, perl 5.8.1, or perl 5.8.4.

The added lines

Distribution: (%type_pkg[python] = 23) 10.4

and

Distribution: (%type_pkg[perl] = 581) 10.3, (%type_pkg[perl] = 581)  
10.4, (%type_pkg[perl] = 584) 10.3, (%type_pkg[perl] = 584) 10.4

handle this, and allow the same file to be used in the 10.4 and 10.5  
distributions.  (The clauses involving 10.3 are not strictly  
necessary, but will be convenient for those maintainers who wish to  
use identical files in the 10.3 and 10.4 trees.)

Further information can be found in the packaging manual, in the newly- 
added documentation for the Distribution field.

  -- Dave


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Should the PDB have these features?

[David H]

Daniel Macks  netspace.org> writes:


> A "direct download link" for...fink itself (I weakly don't like, and
> am happy without it)? The package .info (is implemented in the PDB
> redesign, but is virtually useless for the general public as I think
> you intend)? The existing doc page explaining how to get fink (I
> weakly like, and am also happy without)?

A direct download to the current binary distribution. The reason 
for that is a usability one.
I have noticed that we have many click paths which look like this:

visit PDB, do search, look at package page, (go back), go to 
download page, download.
We could easily shorten that down to
visit PDB, do search, look at package page, download

Obviously there is alos a reaosn of tracking statistics 
based on which package triggered a download. 
Which could be used to motivate the maintainer :)




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] another libjpeg symbol error

[David Reiser]

On 13 Jun 2007, at 1:35:16 PM, Peter O'Gorman wrote:

>
> On Jun 12, 2007, at 11:21 PM, David Reiser wrote:
>
>> I'm having a similar problem to one discussed on fink-users last  
>> week.
>>
>> Gnucash is close to releasing a new version and I'm trying to prepare
>> a new .info file for the latest unstable tarball.
>>
>> 'fink -mvkK --build-as-nobody rebuild gnucash2' appears to succeed,
>> but attempting to run gnucash gives:
>>
>> dyld: Symbol not found: __cg_jpeg_resync_to_restart
>>   Referenced from: /System/Library/Frameworks/
>> ApplicationServices.framework/Versions/A/Frameworks/ 
>> ImageIO.framework/
>> Versions/A/ImageIO
>>   Expected in: /sw/lib/libjpeg.62.dylib
>
> Does your fink built version link libfontconfig in /usr while your
> hand-built version does not? As far as I recall, libfontconfig brings
> in the ApplicationServices framework, and that, in turn, tries to load
> libJPEG.dylib

Looks like the culprit here might be /usr/X11R6/lib/ 
libfontconfig.dylib brought in by the SetCPPFLAGS

>
> Anyway, I don't believe that gnucash needs setting DYLD_LIBRARY_PATH
> at runtime, dyld will use LD_LIBRARY_PATH for dlopen() if it is set,
> and libltdl will look at LTDL_LIBRARY_PATH, so as long as both of
> those are set, dlopen() and lt_dlopen() should work fine, for
> everything else the paths encoded into the binaries should be correct.
>
> So, remove DYLD_LIBRARY_PATH from the wrapper and try again, please.

Thanks. I'll get help from upstream on the right way to do this  
(details beyond my knowledge at the moment...)

BTW, Alexander's suggestion to use DYLD_FALLBACK_LIBRARY_PATH does  
squash my immediate problem, but I'll pursue getting the better  
changes incorporated upstream.
>
> Peter
> --
> Peter O'Gorman
> http://pogma.com
>
>
Dave
--
David Reiser
[EMAIL PROTECTED]


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Should the PDB have these features?

[David H.]

Hello Community.

Should the PDB have these two features?

When you search for something and the link below is returned:
http://pdb.finkproject.org/pdb/package.php/whatevername
as the search result is being generated should we offer a direct download link?

If the PDB had this feature how would you feel?
I would be super happy!
It must be that way
I do not really care
I dislike that idea!

If the PDB did NOT have this feature how would you feel?
I would be super happy!
It must be that way
I do not really care
I dislike that idea!

(please answer BOTH questions).

When you search for something and NO package is found, should the PDB
offer a little form or a link so that you can request that package?

If the PDB had this feature how would you feel?
I would be super happy!
It must be that way
I do not really care
I dilsike that idea!

If the PDB did NOT have this feature how would you feel?
I would be super happy!
It must be that way
I do not really care
I dislike that idea!

(please answer BOTH questions).

Thank you

David Hoehn
FDN Board member, PR dude.

-- 
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] another libjpeg symbol error

[David Reiser]

I'm having a similar problem to one discussed on fink-users last week.

Gnucash is close to releasing a new version and I'm trying to prepare  
a new .info file for the latest unstable tarball.

'fink -mvkK --build-as-nobody rebuild gnucash2' appears to succeed,  
but attempting to run gnucash gives:

dyld: Symbol not found: __cg_jpeg_resync_to_restart
   Referenced from: /System/Library/Frameworks/ 
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
Versions/A/ImageIO
   Expected in: /sw/lib/libjpeg.62.dylib

This isn't quite the same as last week's issue, as the "Expected in:"  
target is slightly different, but it looks like the same problem.

The build phase of the info file is:

SetCPPFLAGS: -I/usr/X11R6/include -I%p/lib/system-openssl/include
SetLDFLAGS: -L%p/lib/system-openssl/lib
ConfigureParams: --mandir=%p/share/man --infodir=%p/share/info -- 
libexecdir=%p/lib --enable-error-on-warning --disable-dependency- 
tracking --disable-schemas-install --enable-ofx --enable-hbci -- 
disable-sql
CompileScript: <<
   guile16-build ./configure --prefix=%p %c
   guile16-build make
<<
InstallScript: make install DESTDIR=%d

This build phase has worked for gnucash2 2.0.x releases in fink.

If I hand build (unpack the 2.1.3 tarball in a directory, then  
compile) using:

guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include ./configure  
--enable-error-on-warning --enable-compile-warnings --enable-opt- 
style-install --prefix=/opt/gnucash-tball --enable-debug --enable- 
etags --enable-doxygen --enable-ofx  --enable-hbci
guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include make
make install

then gnucash 2.1.3 builds and runs fine (at least on my ppc mac). / 
opt is NOT in my PATH.

DYLD_LIBRARY_PATH has been declared, but it doesn't cause a problem  
with the latest svn version, the 2.1.3 built by hand from the  
tarball, or 2.0.5 as released in unstable crypto -- only with a  
'normal' fink build of the 2.1.3 tarball.

akh suggested using DYLD_FALLBACK_LIBRARY_PATH, but I haven't gotten  
to that yet given my confusion over the hand built versions working.  
(And the fact that I'd have to write a patch script for aclocal.m4,  
configure, and three other files to make the substitution on the fly  
for a fink build.)

gnucash 2.1 no longer depends on g-wrap. I'm not expecting that to be  
material, given the success of the hand-building from the tarball.  
Building from svn does use swig, but it succeeds too.

Any additional suggestions?

Dave
--
David Reiser
[EMAIL PROTECTED]


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Really making maxima-nox not use X

[David R. Morrison]

OK, here's an alternate version of gd2-nox and gnuplot-nox, using  
static gd2 libs:

http://fink.cvs.sourceforge.net/fink/experimental/dmrrsn/wxmaxima- 
project/

   -- Dave

On Jun 3, 2007, at 11:47 AM, Alexander Hansen wrote:

> The maxima-nox package currently has an indirect dependency on X11  
> via gnuplot.  I would like it actually to be -nox.  We have a  
> couple of options:
>
> 1)  I can make gnuplot a Recommends: rather than a Depends: , since  
> the package has another plot output scheme available in its built- 
> in openmath output.
>
> 2)  I've made up a gnuplot variant with a -nox option--required  
> explicitly disabling x11 and also depending on a noxified gd2.   
> These packages are in my experimental area (and I've cc'ed the  
> maintainers):
>
> https://finch.finkdeveloper.net/svn/users/akh/experimental/wxmaxima- 
> project/finkinfo/
>
>
> Option 1 is certainly easier, of course.
>
> -- 
> Alexander K. Hansen
> akh AT finkproject DOT org
> Fink User Liaison and Documenter
>


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc4 package obsolete?

[David R. Morrison]

On Jun 4, 2007, at 1:44 PM, Remi Mommsen wrote:

> Hi Dan,
>
> On Jun 4, 2007, at 1:18 PM, Daniel Macks wrote:
>
>> On Sun, Jun 03, 2007 at 10:25:32AM -0500, Remi Mommsen wrote:
>>> Hi,
>>>
>>> Given that we have now gcc42 in 10.4/unstable (and soon also in  
>>> 10.4/
>>> stable), I wonder if we should declare the gcc4 package as obsolete.
>>>
>>> The gcc4 package in 10.4/unstable is based on the pre-4.2 snapshot
>>> 4.1.-20060617. In the 10.4/stable tree, gcc4 is based on 4.0.2.
>>>
>>> The only package depending on gcc4 is pdftk in 10.4/unstable
>>> (maintainer cc'd).
>>>
>>> There seems to be no package in 10.4/stable requiring gcc4.
>>> Therefore, I'd propose to remove gcc4 from the 10.4/stable tree once
>>> we add gcc42, and declare the gcc4 package in 10.4/unstable as
>>> obsolete.
>>
>> We haven't yet seriously addressed obsoleting packages that have
>> -shlibs splitoffs. I suspect only the "gcc4" package (or whatever the
>> compiler + headers is called) is technically obsolete and able to be
>> discarded by end-users during an upgrade. The gcc4-shlibs component,
>> if someone has indeed already compiled something against gcc4 and
>> therefore hard-coded the dcc4-shlibs .dylib, that -shlibs package is
>> *not* obsolete and replaceable by whatever the new one is.
>>
>> Actually, in keeping with the way we do other shared-library  
>> upgrades,
>> could actually nuke gcc4 entirely (keeping only the -shlibs part),  
>> but
>> it's sometimes difficult to adjust the .info for that...so yeah, just
>> marking it obsolete sounds like an easy and good plan.
>>
>> dan
>
> Couldn't one assume that if there is no package declaring a
> dependency on the -shlibs package, that it is save to remove the
> entire package, i.e. including the -shlibs part?

I guess one question is: has there ever been a package declaring a  
dependency on the -shlibs part?

   -- Dave



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc4 package obsolete?

[David R. Morrison]

On Jun 3, 2007, at 8:25 AM, Remi Mommsen wrote:

> Hi,
>
> Given that we have now gcc42 in 10.4/unstable (and soon also in 10.4/
> stable), I wonder if we should declare the gcc4 package as obsolete.
>
> The gcc4 package in 10.4/unstable is based on the pre-4.2 snapshot
> 4.1.-20060617. In the 10.4/stable tree, gcc4 is based on 4.0.2.
>
> The only package depending on gcc4 is pdftk in 10.4/unstable
> (maintainer cc'd).
>
> There seems to be no package in 10.4/stable requiring gcc4.
> Therefore, I'd propose to remove gcc4 from the 10.4/stable tree once
> we add gcc42, and declare the gcc4 package in 10.4/unstable as  
> obsolete.
>
> Remi

That sounds like a good plan.

   -- Dave



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Some fun statistics on the PDB

[David H.]

Dear Community.

Fink has been using google-analytics for a while now to keep track of
what is going on on finkproject.org and pdb.finkproject.org

Ultimatively we would like to use the gathered Data to better
understand what the community seeks when visiting the web-site and
then improve it with that data in mind.
However it will be a while until the partners who do this together
with us as pro-bono work will be ready, so here are some fun
statistics in the mean while.

These statistics cover the time line from 20th of April 2007 to 20th
of May 2007.

Top Ten Viewed Packages:
   unique views
ethereal   2,064
wireshark 2,031
svn 1,936   
gimp21,315  
httrack  680
svn-client 555
xchat374
quartz-wm 361
rdesktop 360
fink336

Number of unique Visitors: 44,618
Number of returning Visitors: 12,582

56.90% of our traffic comes from referring sites, where
finkproject.org accounts for 30.07% of the traffic.

The main english landing page generated 14,855 unique page views and
the whole web-site generated 121,930 unique page views.

38,572 visits seem to have been from people able to speak English and
at least one spoke Hindi.

There are lots more information, I just thought I should share these
for a quick chuckle

David H.
FDN Board Member


-- 
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Pine 4.64 (last version) and Alpine

[David R. Morrison]

On May 18, 2007, at 1:35 AM, Claus Atzenbeck wrote:

> On Thu, 17 May 2007, David R. Morrison wrote:
>
>> Updated pine to 4.64 in the 10.4/unstable tree.
>
> Would it be much work to update also pine-ssl? It would be much
> appreciated...
>
> Cheers,
> Claus

Sorry to say that for pine-ssl, just updating to the latest version  
didn't work.  There is some bug that must be fixed; I'll try at some  
point, but I don't know when I'll get to it.

   -- Dave


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Pine 4.64 (last version) and Alpine

[David R. Morrison]

Updated pine to 4.64 in the 10.4/unstable tree.

   -- Dave


On May 17, 2007, at 2:45 AM, Claus Atzenbeck wrote:

> Hi all:
>
> "fink info pine-ssl" tells me that this list is the package  
> maintainer. ;)
>
> Pine is no longer developed. Fink supports Pine 4.61, the latest  
> version,
> however, is 4.64 .
> It would be cool to have the latest (and probably last) version of  
> Pine
> as Fink package. I don't know who maintained it previously. Is there
> someone who would update the package?
>
> A side note:
> Pine's successor is Alpine ,
> available at , currently as  
> alpha
> version. (It builds already fine on Mac OS X.)
>
> Cheers,
> Claus
>
>
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] GIS packages on Fink Wiki

[David R. Morrison]

Link added.

   -- Dave


On May 6, 2007, at 8:52 PM, BABA Yoshihiko wrote:

> Hi all,
>
> I made a page on Fink Wiki about GIS packages.
>
> http://wiki.finkproject.org/index.php/Fink:Packaging:GIS
>
>
> Unfortunately, it is not linked from Wiki top page because the toppage
> is protected.
>
>
> -- BABA Yoshihiko
> http://homepage.mac.com/babayoshihiko
>
> -- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Shlibs field and variants

[David R. Morrison]

On May 6, 2007, at 9:09 AM, Remi Mommsen wrote:

> Hi,
>
> I have a package (root5) which builds many shlibs and has different
> variants. Depending on the variant, some shlibs are built or not. So
> far, I just listed all possibly built libraries in the Shlibs field.
> The latest (cvs head) version of fink complains now about the missing
> libraries listed in the shlibs field:
> Error: Shlibs field specifies /sw/lib/root/libEGPythia6.5.dylib, but
> it does not exist!
> Error: Shlibs field specifies /sw/lib/root/libG4root.5.dylib, but it
> does not exist!
> Error: Shlibs field specifies /sw/lib/root/libHbook.5.dylib, but it
> does not exist!
>
> How do I handle this situation?
>
> TIA,
>   Remi

Hi Remi.

The basic problem here is that we want a reliable mapping between  
"install-name and compatibility version of a dynamic library" and  
"what fink package installs it".

I haven't looked at the package to see what your variant structure  
is, but presumably there is some core collection of dylib files which  
are built for all variants, and then some extra ones which only occur  
in some variants?

I see two possible strategies for handling this, but I'm willing to  
be convinced that there are others I haven't thought of.

1) The contents of your Shlibs field has to depend on the variant.   
This is unpleasant, because we hadn't anticipated it and fink's  
variant code can't handle this smoothly.  It would require  
separate .info files for the various variants.  (It also has the  
unfortunate property that there are several different packages which  
could be used to provide a given dylib, so these should all conflict/ 
replace each other, which gets messy where shared library packages  
are involved.)

2) A basic package would provide the dylibs that are in common for  
all variants, and then the variant packages would build other  
splitoffs with other dylibs in them (as needed).  The disadvantage of  
this is that people may have to compile things twice.  You would  
probably also need separate .info files.

Can anybody think of another strategy?

   -- Dave



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Question about pythonmods

[David R. Morrison]

On Apr 28, 2007, at 11:10 PM, AIDA Shinra wrote:

> Are there any documents about "libs/pythonmods" category?

I don't think there are any documents, but I would like to encourage  
people to start using it more.  In fact, I am planning a project to  
move -pyNN packages to libs/pythonmods.

> In
> particular,
>
> * Should I move existing -pyNN packages into libs/pythonmods?

Yes, please.

>
> * Why do the stable trees lack libs/pythonmods?

The directories are there in CVS, but they are empty.  The way our  
selfupdate works, empty directories are not copied.  (More precisely,  
they are copied but then empty directories are deleted.)  Once we get  
the first packages into libs/pythonmods in the stable tree, the libs/ 
pythonmods directory will be available during update.

   -- Dave



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] validation question

[David R. Morrison]

I guess you are using fink from CVS HEAD?

There are some extensions to the validator which check on the  
validitiy of the Shlibs fields and dependencies in fink packages.   
These extensions are still under construction, so error messages  
might be misleading.

Ben, care to comment?

   -- Dave



On Apr 28, 2007, at 11:16 AM, Koen van der Drift wrote:

> Hi,
>
> I am working on an new upstream version of the package bio-emboss-pm,
> and I get the following validation message:
>
> ...
> Validating .deb dir root-bio-emboss-pm586-4.1.0-1...
> /usr/bin/otool: can't open file: root-bio-emboss-pm586-4.1.0-1/sw/lib/
> perl5/5.8.6/darwin-thread-multi-2level/auto/Bio/Emboss/Emboss.bundle
> (No such file or directory)
> Package looks good!
> ...
>
> Since it says that the package looks good, can I ignore the 'can't
> open file' message?
>
> thanks,
>
> - Koen.
>
> -- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] To Alexey Zakhlestin

[David H.]

On 20/04/07, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
> well… I would like to start with something not-too-difficult. And
> looks like "monthly status update" blog is something I would be able
> to cope with.
>
Hello Alexey

I am keeping the Email list in the loop as this might be interesting to others.
I am more than happy to support you and we at Fink do not mind how
small your contribution is, it is welcome.

> I am going to try to make a "pilot version" which will include events
> of april. We will see if it will be difficult and if I succeed :)
>
That sounds very good. If you want to make it a version which is
"officially endorsed" would you mind running it past me or the other
core members first? If you simply want to do this as a personal
project, then please by all means do that, it sounds very nice.

> I, myself, do not have enough time for really big tasks, but I would
> be interested in developing infrastructure, which will make it easier
> for others to step into process.
>
Yes, that would be more than lovely. If we can help by providing
bandwidth or a blog engine, please let us/me know.

> For me, Fink is the most important OS-X application. So, I am
> definitely interested in it's development :-)
>
Thank you.

-d

-- 
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] To Alexey Zakhlestin

[David H.]

Dear Alexey.

As you might have learned from the web-page I am the guy who used to
do a lot of the PR and administrative work around getting Fink into
the mass media. I say I used to, because I have not been doing it much
over the last couple of months. There have been some significant
changes in my life I had to cater for.

However your desire to bring more concise information on a regular
basis out to the user base is something I can only second. If you feel
that you have enough desire to further go down that road, then I will
make sure to do anything in my powers to support you from our side.

There are various ways of going about what you were suggestion, the
most common problem we have is content. All of the fink-core members
and even people like myself are already very busy with the main issues
surrounding fink and Fink as a project. We welcome any kind of help.

This does not only extend to a possible re-design of the Fink
web-site, better news coverage and a better integration of your user
base (like users,finkproject.org) or better work on the local level.

If you wan to get involved with the issues around having Fink
operational as a project, please have a look at:
http://wiki.finkproject.org/index.php/The_Fink_Wiki
Fink Developer Network section

Thank you

dmalloc
PR guy

-- 
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] planned obsolesence

[David R. Morrison]

Dear Fink developers,

As you may be aware, in our 10.4 distribution, perl versions older  
than 5.8.1 are not present, and on intel, perl versions older than  
5.8.6 are not present.

Some of us have been talking about setting minimum versions for perl  
and python in the upcoming 10.5 distribution: the minimum perl would  
be 5.8.6 and the minimum python would be 2.4 (eliminating the current  
minimum python 2.3 in 10.4).

Is anyone aware of problems with this?  If so, please discuss them here.

   Thanks,
   Dave


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Can't install latest mysql

[David Lowe]

On Apr 3, 2007, at 10:22 PM, Daniel Macks wrote:

> 10.3/unstable, trying to install latest mysql (5.0.38-1) with the
> previous version of that package (5.0.34-6) installed, I got:
>
> Setting up mysql (5.0.38-1) ...
> Installing MySQL system tables...
> 070403 12:42:22 [Warning] Setting lower_case_table_names=2 because  
> file system for /sw/var/mysql/ is case insensitive
> ERROR: 1136  Column count doesn't match value count at row 1
> 070403 12:42:23 [ERROR] Aborting
>
> 070403 12:42:23 [Note] /sw/sbin/mysqld: Shutdown complete
>
> Installation of system tables failed!
>
> Looking at the PostInst, I see it's doing:
>
>  # create initial database
>  # it is safe to call mysql_install_db even if a db is already present
>  /sw/bin/mysql_install_db --user=mysql
>
> Digging into that script, apparently it doesn't realize I already have
> a mysql database installed, so it tries to set up a new one, which is
> different from the old. Got a lot of errors from the mysql_upgrade
> script that mysql_install_db, so gave up and started over:
>
>   rm -rf /sw/var/mysql
>   dpkg --r mysql
>   fink install mysql
>
> That worked. For fun, I tried 'fink reinstall mysql', which gives:
>
> Installing MySQL system tables...
> 070404  1:08:10 [Warning] Setting lower_case_table_names=2 because  
> file system for /sw/var/mysql/ is case insensitive
> ERROR: 1062  Duplicate entry '%-test-' for key 1
> 070404  1:08:10 [ERROR] Aborting
>
> So it's reproducibly impossible to install mysql without throwing away
> my old intallation entirely? That's bad.

Hmm, this is very different behavior from the binary available at  
[ http://www.mysql.org/downloads/mysql/5.0.html#macosx-dmg ].  That  
version builds a new directory for each version of mysql, then  
creates a link to whichever was installed most recently.  This  
probably requires more attention managing it than a script based  
solution such as fink provides [or else it tends to fill up hard  
disks].  The net result, however, is still the same: before the  
upgrade, you should backup or export your data.  After setting up the  
new mysql, it is expected that you'll import your old data into the  
new base.  Nevertheless, it does appear as though you've encountered  
a bug.

Using a rusty Amiga 4000T, a shiny PowerMac G5, & a homebuilt Ubuntu box

Philosophical error:  Demonstrate the existence of a key to continue




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] dependencies weirdness

[David R. Morrison]

On Mar 27, 2007, at 12:09 PM, Charles Lepple wrote:

> On 3/27/07, Alexander K. Hansen <[EMAIL PROTECTED]> wrote:
>> It's a matter of classification:
>>
>> BuildDepends are buildtime only.
>>
>> Depends are both for runtime and buildtime.
>>
>> It would certainly be an option for a packaging system also to have,
>> say, RuntimeDepends, which are only needed at runtime.  Fink just
>> doesn't do that.
>
> Probably worth documenting that difference, though - the 'Depends' in
> dpkg control files is a runtime dependency, and I have a feeling that
> RPM treats it the same way.

Quoting from the packaging manual:

 Depends: A list of packages which must be installed before this  
package can be built.

 BuildDepends: Introduced in fink 0.9.0. A list of dependencies  
that is applied at build time only.

Admittedly, these descriptions are not too clear about runtime  
dependencies.  But they are crystal clear about what happens at build  
time.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] dependencies weirdness

[David R. Morrison]

On Mar 27, 2007, at 11:45 AM, Alexander K. Hansen wrote:

> Alexey Zakhlestin wrote:
>> on IRC I was told:
>> RangerRick>  Depends: is an implicit BuildDepends
>>
>> that explains my situation.
>> But I doubt that is the way it should be.
>>
>> On 3/27/07, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
>>
>>> I submitted the package for validation:
>>> http://sourceforge.net/tracker/index.php? 
>>> func=detail&aid=1688512&group_id=17203&atid=414256
>>>
>>> works fine, but has one strange effect
>>>
>>> It has a bunch of splitoffs. one of those splitoffs has
>>>   Depends: %N, rrdtool
>>>
>>> that's the only place rrdtool is mentioned in the .info file
>>>
>>> now, I try the following:
>>> fink --build-as-nobody -m rebuild lighttpd
>>>
>>> and among the other things fink tells me:
>>> The package 'rrdtool' will be built and installed
>>>
>>> why?
>>> rrdtool is not in "BuildDepends". it is "Depends". it is needed only
>>> in runtime for one of the splitoffs. I thought it is supposed to be
>>> installed only if I install that splitoff
>>>
>>> do I misunderstand something?
>>>
>>> --
>>> Alexey Zakhlestin
>>> http://blog.milkfarmsoft.com/
>>>
>>>
>>
>>
>>
> It's a matter of classification:
>
> BuildDepends are buildtime only.
>
> Depends are both for runtime and buildtime.
>
> It would certainly be an option for a packaging system also to have,
> say, RuntimeDepends, which are only needed at runtime.  Fink just
> doesn't do that.

This is a possible future feature that has been discussed a number of  
times, but nobody has ever implemented it.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gnucash-2.0.2-4

[David Reiser]

On 24 Mar 2007, at 8:23:17 AM, Carl Denzen Van wrote:

> Cannot compile package:
> The package 'gnucash' will be built and installed.
> Reading dependency for gnucash-2.0.2-4...
> WARNING: While resolving dependency "goffice-shlibs" for package  
> "gnucash-2.0.2-4", package "goffice-shlibs" was not found.
> Reading build dependency for gnucash-2.0.2-4...
> WARNING: While resolving dependency "goffice-shlibs " for package  
> "gnucash-2.0.2-4", package "goffice-shlibs" was not found.
> Can't resolve dependency "goffice-shlibs" for package  
> "gnucash-2.0.2-4" (no
> matching packages/versions found)
> Exiting with failure.
>
>
>
> --
> Package manager version: 0.27.1
> Distribution version: 0.8.1.rsync powerpc
> Mac OS X version: 10.4.9
> Xcode version: 2.2.1
> gcc version: 4.0.1 (Apple Computer, Inc. build 5250)
> make version: 3.80
> Feedback Courtesy of FinkCommander

Is this a home-grown version of the .info file? All of the 2.0.x  
versions of gnucash have been in fink with the package name of  
gnucash2. The current version is gnucash2-2.0.5-1. The fink package  
that provides goffice is libgoffice.

Try 'fink selfupdate' followed by fink install gnucash2. You might  
have to forcibly remove whatever implementation of gnucash you have  
now, because the gnucash2 package still is launched by 'gnucash' in  
an x11 terminal window.

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] AmiWM

[David Lowe]

On Mar 15, 2007, at 10:14 AM, Alexander K. Hansen wrote:

> I'd say a good amount, based on -devel traffic and IRC. (Especially  
> for a package that already builds).

Is IRC required?  Since i work the night shift, it's not easy for me  
to rearrange my schedule for meeting times.  Besides, it helps my  
memory to have my emails archived.

> Typically you won't have to do a heck of a lot to the original  
> package source--and if you do it's not a bad idea to let the  
> upstream developers know so that they might incorporate your  
> suggestions in the next release.

Well, there hasn't been a formal announcement of abandon from the  
author, but the last update was in 1998...  I sure hope he's  
graduated college and gotten a life by now!

Using a rusty Amiga 4000T, a shiny PowerMac G5, & a homebuilt Ubuntu box

I quit school because it was interfering with my education.  - John  
Brunner




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] AmiWM

[David Lowe]

I tried out AmiWM as it said it needed testing.  I was going to  
mention where some improvements could be made, but i see it has no  
active maintainer.  As a hobbyist C/C++ programmer, i might offer my  
services, but i'm unsure if i'm up to this: i see that at least part  
of the source is in Perl, which i have no experience in.  How much  
help is available for a newbie?

Using a rusty Amiga 4000T, a shiny PowerMac G5, & a homebuilt Ubuntu box

I NEVER! exaggerate-I just remember REALLY big!!!




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Help needed: Improving the Package Database (pdb)

[David R. Morrison]

On Mar 12, 2007, at 3:39 PM, Martin Costabel wrote:

> Christian Schaffner wrote:
> []
>> 1)
>> Help testing! Go to
>>
>> http://finch.finkproject.org/~chris01/fink_web/pdb/
>>
>> and test anything you can think of.
>
> The bug that the pdb doesn't know about the "current" bindist is still
> present, it seems. Could this *please* be fixed? See bug tracker  
> #1606084.

Christian,

I think one of the problems here is that currently the only way of  
identifying which packages have been added to (or updated in) the  
"current" bindist is to look in the bindist.  Should we have a  
standard CVS tag for this purpose?  One which the pdb could then use?

   -- Dave




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Help with debugging mysterious tar error

[David R. Morrison]

Thanks to a patch written by vasi, there is now an experimental  
version of dpkg which should be compatible with the new tar, that is,  
it should not die even if tar encounters "file changed as we read  
it".  I would appreciate some testing on this, particularly from  
those of you who managed to generate the error fairly reliably in the  
past.

The experimental dpkg.info and dpkg.patch files (tuned for 10.4) can  
be found in CVS at experimental/dmrrsn .

   Thanks,
   Dave


On Mar 3, 2007, at 12:52 AM, Martin Costabel wrote:

> Could those of you who have or had the dpkg-deb failure caused by
> tar-1.16.1 claiming
>
>"file changed as we read it"
>
> please help with debugging this? Based on the outcome of these  
> tests, we
> should be able to decide whether we need to patch tar or dpkg, or
> whether we need to dig further down.
>
> I have made a special version of the tar executable that prints some
> more information if this error appears. It prints the old/new  
> ctimes and
> the old/new file sizes. The special version is a universal binary  
> (so it
> should work on both ppc and intel) and is available at
> http://perso.orange.fr/costabel/tar.gz
>
> A possible test procedure to follow would be:
>
> 1. Download the new tar:
>
>curl -O http://perso.orange.fr/costabel/tar.gz
>gunzip tar.gz
>chmod +x tar
>mv tar /var/tmp/
>
> 2. Replace (temporarily) Fink's tar by the new one
>
>sudo ln -sf /var/tmp/tar /sw/bin/tar
>
> 3. Build one of the packages that give you the tar error (mysql,  
> gcc42,
> gnumeric were among those where the error was reported). Cross your
> fingers that the error will happen again ;-)
>
> 4. Report to the list the part of the error message that is printed
> after the "file changed as we read it" line.
>
> 5. Put Fink's tar back to where it was before
>
>sudo ln -sf gtar /sw/bin/tar
>
> Thanks
>
> -- 
> Martin
>
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] tar and dpkg

[David R. Morrison]

On Mar 4, 2007, at 7:15 PM, Jean-François Mertens wrote:

> Except that in the thread mentioned by dmacks, it is mentioned that
> a new version of tar was due yesterday (sorry _ had no time to check,
> really have for personal reasons no time for at least a week except
> for the most urgent things), with new meanings of return codes.
> So the 2 should be synchronised _ updating to the last tar, and
> adapting dpkg.

That thread was from October 2006, and indeed tar-1.16 was released  
on 10/21/2006.  The current version, 1.16.1, was released in  
December.  Both of them have the new return codes.

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Help with debugging mysterious tar error

[David Fang]

Let me know if you still need more data points.

Using your diagnostic 'tar',
gcc42 died during packaging [1] (Core Duo, 10.4.8):


Writing control file...
Writing package script postinst...
Writing package script prerm...
dpkg-deb -b root-gcc42-4.1.-20070221
/sw/fink/10.4/unstable/main/binary-darwin-i386/languages
tar:
./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/bits/stdc++.h.gch/O0g.gch:
file changed as we read it
=
Old ctime: 1173052264
New ctime: 1173052415
Old size : 17438180
New size : 17438180
=

tar:
./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/bits/stdc++.h.gch/O2g.gch:
file changed as we read it
=
Old ctime: 1173052264
New ctime: 1173052426
Old size : 17429988
New size : 17429988
=

tar:
./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/x86_64/bits/stdc++.h.gch/O0g.gch:
file changed as we read it
=
Old ctime: 1173052286
New ctime: 1173052458
Old size : 19695076
New size : 19695076
=

tar:
./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/x86_64/bits/stdc++.h.gch/O2g.gch:
file changed as we read it
=
Old ctime: 1173052287
New ctime: 1173052471
Old size : 19682788
New size : 19682788
=

dpkg-deb: building package `gcc42' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/languages/gcc42_4.1.-20070221_darwin-i386.deb'.
/sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1
### execution of dpkg-deb failed, exit code 2
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-gcc42-4.1.-20070221
(Reading database ... 57360 files and directories currently installed.)
Removing fink-buildlock-gcc42-4.1.-20070221 ...
Failed: can't create package gcc42_4.1.-20070221_darwin-i386.deb



David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] tar and dpkg

[David R. Morrison]

My interpretation of the early test results reported here is that tar  
is indeed detecting a change in ctime and nothing more serious.   
There are two possible solutions to this: patch tar, or patch dpkg.   
I'm going to advocate that we patch dpkg.

My reasoning goes like this: the decision to have tar report an error  
condition for non-fatal errors, and to report it with a different  
exit code than for fatal errors, was a deliberate one by the tar  
maintainer.  We may disagree with that decision, but the fact is, a  
version of tar has been released in which this change was  
implemented, and there is no reason to believe that the tar developer  
would reverse the decision if asked.  For example, a related issue  
was raised on the bug-tar list three years ago, and received the  
answer "we are doing the conservative thing and won't change".  See  
http://lists.gnu.org/archive/html/bug-tar/2004-03/msg00010.html .

A request for a separation of exit codes is: http://lists.gnu.org/ 
archive/html/bug-tar/2005-01/msg00053.html .  Another relevant  
message which explains why the error code was changed for the non- 
fatal situation is: http://lists.gnu.org/archive/html/bug-tar/2006-10/ 
msg00021.html .  A comment about implementation is found here: http:// 
lists.gnu.org/archive/html/bug-tar/2006-10/msg00024.html .

Anyway, my conclusion from all of this is that the two-exit-code  
status of tar is here to stay, at least for now.  And while Apple is  
currently using tar-1.15.x, we have no control over when they might  
change to tar-1.16.x.  Thus, switching to /usr/bin/tar surrenders any  
control we might have over the problem, and patching tar itself dooms  
us to continue patching tar forever.

This is why I advocate patching dpkg so that when calling tar, it  
checks the exit code and only dies if tar had a fatal error.  Of  
course, we'll need to make the new dpkg package depend on the new tar  
package, but this should not be a problem.  (Note that dpkg- 
bootstrap, on the other hand, should rely on /usr/bin/tar and should  
*not* get this change.)

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Help with debugging mysterious tar error

[David Fang]

On Sun, 4 Mar 2007, David Fang wrote:

> > Because mysql takes not so much time to build compared to gcc4, I
> > tried that one first with the new tar. On my system it build and
> > installed without an error. Right now I am building gcc4. Once that
> > is done in a couple of hours, I will let you know how it went.

Using your diagnostic 'tar',
mysql built without problems [1] (Core Duo, 10.4.8):

Writing control file...
Writing package script postinst...
Writing package script prerm...
Writing daemonic info file mysql.xml...
dpkg-deb -b root-mysql-5.0.34-1007
/sw/fink/10.4/unstable/main/binary-darwin-i386/database
dpkg-deb: building package `mysql' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/database/mysql_5.0.34-1007_darwin-i386.deb'.
Writing control file...
dpkg-deb -b root-mysql15-dev-5.0.34-1007
/sw/fink/10.4/unstable/main/binary-darwin-i386/database
dpkg-deb: building package `mysql15-dev' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/database/mysql15-dev_5.0.34-1007_darwin-i386.deb'.
Writing control file...
Writing shlibs file...
dpkg-deb -b root-mysql15-shlibs-5.0.34-1007
/sw/fink/10.4/unstable/main/binary-darwin-i386/database
dpkg-deb: building package `mysql15-shlibs' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/database/mysql15-shlibs_5.0.34-1007_darwin-i386.deb'.
Writing control file...
dpkg-deb -b root-mysql-client-5.0.34-1007
/sw/fink/10.4/unstable/main/binary-darwin-i386/database
dpkg-deb: building package `mysql-client' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/database/mysql-client_5.0.34-1007_darwin-i386.deb'.
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-mysql-5.0.34-1007
(Reading database ... 57353 files and directories currently installed.)
Removing fink-buildlock-mysql-5.0.34-1007 ...
Closed logfile mysql-fink.log
Updating the list of locally available binary packages.
Scanning dists/unstable/main/binary-darwin-i386
New package:
dists/unstable/main/binary-darwin-i386/database/mysql-client_5.0.34-1007_darwin-i386.deb
New package:
dists/unstable/main/binary-darwin-i386/database/mysql15-dev_5.0.34-1007_darwin-i386.deb
New package:
dists/unstable/main/binary-darwin-i386/database/mysql15-shlibs_5.0.34-1007_darwin-i386.deb
New package:
dists/unstable/main/binary-darwin-i386/database/mysql_5.0.34-1007_darwin-i386.deb

I'll rebuild gcc42 next...


[1]: Initial attempt failed because of parallel race during Install phase,
but was recitified by adding -j1 to 'make install'.  The SetMAKEFLAGS: -j1
in the .info doesn't seem to override my environment's MAKEFLAGS (-j2), as
pstree showed parallel jobs.  (Is it supposed to?)  Compile phase was fine
with -j2, even with different timings pre-ccache and post-ccache.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Help with debugging mysterious tar error

[David Fang]

> Because mysql takes not so much time to build compared to gcc4, I
> tried that one first with the new tar. On my system it build and
> installed without an error. Right now I am building gcc4. Once that
> is done in a couple of hours, I will let you know how it went.

Hi all,

Even though I reproduced the problem with gcc4 before deterministically,
I'll try the smaller pkgs first.

I've replaced tar (1.16.1) with Martin's tar, but as soon as I try to use
it I get (mysql depends on daemonic):

dyld: Library not loaded: /sw/lib/libiconv.2.dylib
  Referenced from: /sw/bin/tar
  Reason: Incompatible library version: tar requires version 7.0.0 or
later, but libiconv.2.dylib provides version 6.0.0
/sw/bin/dpkg-deb: subprocess tar -cf killed by signal (Trace/BPT trap)
### execution of dpkg-deb failed, exit code 2
Failed: can't create package fink-buildlock-daemonic-20010902-2

I gotta selfupdate libiconv, it seems!  (This machine I'm testing on is
not maintained by me, but I've been graciously granted privileges to debug
this.  :)  )  I should have some results later today.


> > Could those of you who have or had the dpkg-deb failure caused by
> > tar-1.16.1 claiming
> >
> >   "file changed as we read it"
> >
> > please help with debugging this? Based on the outcome of these
> > tests, we should be able to decide whether we need to patch tar or
> > dpkg, or whether we need to dig further down.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] raster3d

[David R. Morrison]

On Feb 25, 2007, at 10:19 AM, William Scott wrote:

> Matt Stephenson's raster3d package currently depends on gcc4 but
> breaks when compiled with gcc42.
>
> Jack Howarth fixed it so that it now compiles with the latter.
>
> Would it be ok if I updated this package in cvs?
>
> Bill

Yes, I think it's fine.  Matt Stephenson has not been active for a  
period of some years now.  And it looks like someone has gone through  
and marked his old packages as maintained by "None."

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fink and 'make -j numproc'

[David Fang]

>Considering that Apple will likely be announcing dual quad core
> systems in the near future, I wonder if fink should adopt some policy
> on packaging that utilizes the extra cores. Specifically if we should
> have two changes. One would be a setting in fink.conf which would
> either allow fink to use all available cores or limit it to a single
> core. The second would be to have those packages which can be properly
> build with 'make -j numprocs' to do so (with numprocs being set by
> fink to either the number of cores on the system or to one depending
> upon the fink.conf setting). Fink could also have an option to
> override the setting in fink.conf for a particular build (ie change
> the advertised number of cores for fink to use).

Jack,
A few years back, Martin pointed out that the place to enable fink
builds to finkup MAKEFLAGS from the environment is:

in /sw/lib/perl5/Fink/PkgVersion.pm: (around line 4741)

# uncomment this to be able to use distcc -- not officially supported!
$defaults{'MAKEFLAGS'} = $ENV{'MAKEFLAGS'} if (exists $ENV{'MAKEFLAGS'});
# I support it.

This is also on the Wiki, where they also declare 'unsupported-ness':
http://wiki.finkproject.org/index.php/Setting_MAKEFLAGS_in_Fink

(distcc need not be involved with parallel makes.)

Having an old, slow 2P computer, this is the first thing I sudo-edit
everytime fink upgrades itself, it picks up my environment's MAKEFLAGS.
I've been building -j2 on my home machine (and -j4 on machines at work)
ever since.

Every once in a while, a package will die on some dependency race, but the
failures are far and few.  I've seen some InstallScripts that explicitly
add a make -j1 to prevent mkdir-races (and as installing doesn't benefit
as much from -jN).  It might also be feasible for troublesome packages to
NoSetMakeflags or coerce -j1.

I've also been using ccache-default, (with larger than usual cache size in
/sw/var/ccache) at the same time, so in the event of a failure, the
rebuild is much faster.  (And often, races tun out 'better' on the 2nd,
3rd try...)  Builds that cannot use ccache just BuildConflicts with it.

I agree that it would be nice for users benefit from multi-procs by
default.  I'm not sure if injecting MAKEFLAGS into the users environment
(/init.[c]sh) would be a good policy.  Even if this doesn't happen, it's
not the end of the world, it's documented for the ones who search for the
solution.

End $.02.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] management changes

[David R. Morrison]

Dear fink community,

We are pleased to announce that Alexander Hansen (akh) has been  
designated the "User Liaison" for fink.  This does not represent any  
new duties for Alexander, but is rather a recognition of the key role  
he already plays in the project.

We are also pleased to announce that Christian Schaffner (chris01)  
has joined the Fink Core group.  Please join us in welcoming  
Christian to this new role.

   Sincerely,
   Dave Morrison, on behalf of fink-core

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] tar/spotlight (was Re: gcc42 mixed result)

[David R. Morrison]

On Jan 28, 2007, at 12:14 PM, Martin Costabel wrote:

> David Fang wrote:
> []
>>  Perhaps something about Spotlight disabling could be added to the
>> FAQ?  It makes a somewhat noticeable improvement on slow  
>> machines.  I'd
>> recommend disabling for at least the src/fink.build directories.
>
> Spotlight does not touch *.build directories. That's why fink.build  
> was
> introduced in the first place. Maybe the people who have this weird
> error changed their build directory to something other than  
> fink.build?

Martin,

I wonder, though, where dpkg-deb does its work.  If we examine David  
Fang's error message closely

dpkg-deb -b root-gcc42-4.1.-20070124
/sw/fink/10.4/unstable/main/binary-darwin-i386/languages
dpkg-deb: building package `gcc42' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/languages/ 
gcc42_4.1.-20070124_darwin-i386.deb'.
tar:
./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/x86_64/bits/stdc+ 
+.h.gch/O0g.gch:
file changed as we read it
/sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1

we see that tar is choking on a file in "./sw"; are we sure that this  
is actually within the build directory?  I wonder if results would be  
different if we told it to create the .deb inside /sw/fink.build, and  
only after creating it to move it into place?

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc42 mixed result

[David Fang]

> Spotlight does not touch *.build directories. That's why fink.build was
> introduced in the first place. Maybe the people who have this weird
> error changed their build directory to something other than fink.build?

Martin,
Ahhh... [me: starts renaming all his project build directories]
My Spotlight blacklist added the fink/src tree before fink.build was
introduced, so I supposed I don't need that anymore.  Good to know.

However, I didn't rename the fink.build directory on either of my test
systems, so that still doesn't explain the gcc42 packaging-failure I
reproduced (10.4, Intel, tar-1.16.1-1).  I hope we figure this out
eventually.

Fang



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc42 mixed result

[David Fang]

> So if I understand all of the comments so far, the problem may
> be avoidable with an older tar but even that produces warnings in
> fink. If the hypothesis of Spotlight indexing blocking files
> is correct, perhaps the answer is for the fink developers to add
> code to fink that stops and starts the Spotlight indexing before
> and after a fink install. I'm sure there must be system calls to
> do that sort of thing.

Hi,
I guess I forgot to mention that the successful build+packaging
(gcc42) on my G4 has fink installed on a partition with Spotlight
disabled.  The Intel Mac on which packaging failed with tar-1.16.1-1 did
NOT have Spotlight disabled in the fink /sw tree.  Most curious...
Perhaps something about Spotlight disabling could be added to the
FAQ?  It makes a somewhat noticeable improvement on slow machines.  I'd
recommend disabling for at least the src/fink.build directories.

> ps One other think I have run into when doing test installs of
> the current gcc4 and gcc42 (to toggle back and forth between
> the default compiler) is that the lockwait for fink can be
> exceeded if you are doing something else at the same time
> (like an svn pull). The lockwait is one other weak point in
> fink for large packages.

Fang


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc42 mixed result

[David Fang]

> > dpkg-deb -b root-gcc42-4.1.-20070124
> > /sw/fink/10.4/unstable/main/binary-darwin-i386/languages
> > dpkg-deb: building package `gcc42' in
> > `/sw/fink/10.4/unstable/main/binary-darwin-i386/languages/
> > gcc42_4.1.-20070124_darwin-i386.deb'.
> > tar:
> > ./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/x86_64/bits/
> > stdc++.h.gch/O0g.gch:
> > file changed as we read it
> > /sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1
> > ### execution of dpkg-deb failed, exit code 2

> I've seen this error on a couple of occasions, mostly involving large
> packages, too. It is not specific to gcc42. I've seen it both on ppc
> (Mac Mini ppc) and on i386 (Mac Mini core duo), but never on my
> MacBook Pro (core 2 duo). Sometime it happened twice in a row, the
> next day it worked fine. I have no idea what the root cause could be.
>
> IIRC, I saw this error message also before the latest tar 1.16.1-1
> was released, but the older tar did not fail in these cases.

Hi,
Just following up with a data point, tar-1.15.1-14 worked (the
first two attempts with 1.16.1-1 failed).  Maybe I was lucky this time,
3rd time being the charm.  [shrug]

Fang


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc42 mixed result

[David Fang]

> > dpkg-deb -b root-gcc42-4.1.-20070124
> > /sw/fink/10.4/unstable/main/binary-darwin-i386/languages
> > dpkg-deb: building package `gcc42' in
> > `/sw/fink/10.4/unstable/main/binary-darwin-i386/languages/
> > gcc42_4.1.-20070124_darwin-i386.deb'.
> > tar:
> > ./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/x86_64/bits/
> > stdc++.h.gch/O0g.gch:
> > file changed as we read it
> > /sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1
> > ### execution of dpkg-deb failed, exit code 2

Google seems to find many instances of this error (GNU tar), I could do a
little more research.

> I've seen this error on a couple of occasions, mostly involving large
> packages, too. It is not specific to gcc42. I've seen it both on ppc
> (Mac Mini ppc) and on i386 (Mac Mini core duo), but never on my
> MacBook Pro (core 2 duo). Sometime it happened twice in a row, the
> next day it worked fine. I have no idea what the root cause could be.
>
> IIRC, I saw this error message also before the latest tar 1.16.1-1
> was released, but the older tar did not fail in these cases.

Yes, I was using 1.16.1-1 on both ppc and x86 builds.  I will downgrade to
1.15.1-14 on x86 and give that a shot.

% fink rebuild gcc42

(I'm wishing bootstrapped gcc-builds could be ccached...)


Fang



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] gcc42 mixed result

[David Fang]

Hi,
First of all, thank you again, Jack, for putting forth an
unrelenting effort in packaging up gcc-4.2 (prerelease), I've been
following along for months now.  I have some good news and bad news to
report.  The good news first:

On 10.4, a dual G4, 0.5 GHz:
% fink install gcc42
... 6.5 hrs later with MAKEFLAGS=-j2 ...
Unpacking gcc42 (from .../gcc42_4.1.-20070124_darwin-powerpc.deb) ...
Selecting previously deselected package gcc42-shlibs.
Unpacking gcc42-shlibs (from
.../gcc42-shlibs_4.1.-20070124_darwin-powerpc.deb) ...
Setting up gcc42-shlibs (4.1.-20070124) ...
Setting up gcc42 (4.1.-20070124) ...

Success!

Now the bad news, and I don't know who's at fault:

On 10.4, core duo iMac:
% fink install gcc42
... 1.5 hrs later, building completes, and then ...
Writing control file...
Writing package script postinst...
Writing package script prerm...
dpkg-deb -b root-gcc42-4.1.-20070124
/sw/fink/10.4/unstable/main/binary-darwin-i386/languages
dpkg-deb: building package `gcc42' in
`/sw/fink/10.4/unstable/main/binary-darwin-i386/languages/gcc42_4.1.-20070124_darwin-i386.deb'.
tar:
./sw/lib/gcc4.2/include/c++/4.2.0/i686-apple-darwin8/x86_64/bits/stdc++.h.gch/O0g.gch:
file changed as we read it
/sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1
### execution of dpkg-deb failed, exit code 2
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-gcc42-4.1.-20070124
(Reading database ... 44016 files and directories currently installed.)
Removing fink-buildlock-gcc42-4.1.-20070124 ...
Failed: can't create package gcc42_4.1.-20070124_darwin-i386.deb

"file changed as we read it" sounds creepy in a quantum mechanics way...
The tar -cf then failed, the .deb halted and the entire build process was
wasted in the end.  I repeated this once more today and got the same
result.  Anyone care to shed some light?  I can provide other information
upon request.

Thanks in advance.

Fang


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] perl module dependencies

[David Reiser]

On 26 Jan 2007, at 2:14:36 AM, Daniel Macks wrote:

> On Fri, Jan 26, 2007 at 01:48:43AM -0500, David Reiser wrote:
>> Almost exactly 3 years ago there was much discussion about versioning
>> perl modules. Having read several of those threads, I don't feel so
>> bad about not understanding.
> [wrote a new module package...]
>> I just went and made it versioned (even though I picked the pure perl
>> version -- text-csv-pp-pm -- because I didn't want to mess with C
>> code in perl). Do I knuckle down and figure out if it really needs to
>> be versioned, and fix it if it doesn't? Or can I be slovenly and say,
>> "I dug this hole, it's not too deep, I can live with it this way"?
>
> I won't tell you how to handle this case, but I'll summarize the
> policy and my understanding of some of its causes/effects:
>
> Any perl module package that (1) contains compiled code or (2) depends
> on a perl-versioned module must be versioned. All others need not be.
>
> Due to #2, best-practice would be to avoid versioning a module unless
> necessary, since doing so essentially requires that everything that
> depends on the module be versioned. Also, versioning clutters up the
> package namespace, which could be confusing/intimidating to users.
>
> Switching a module between being versioned and non-versioned (either
> direction) can be annoying (but not "hard" in most perl-module cases,
> probably). You would need to have compatibility packages to allow
> smooth upgrades and/or have to keep the last viable "other format"
> package around as well as the newer one in the new format.

It turns out I got it right by accident -- text-cvs-pp-pm's only  
builddepends, (test-simple), is versioned.

>
>> Second issue: Now that Leopard is out there stalking in the weeds, it
>> seemed like a good idea to create 588 versions of my modules. That
>> went smoother than I expected, and they're even all running in
>> support of my copy of gnucash2. So now, do I modify the gnucash2.info
>> file to say: Depends: mmm-pm586 | mmm-pm-588, nnn-pm586 | nnn-pm588
>> for all the modules?
>
> That would almost certainly not work...that says "either mmm", which
> does not guarantee that it will be the one that matches the perl one
> is using. That, in a nutshell, is the reason for #2 above.
>
> Assuming gnucash runs /usr/bin/perl you could have different forms of
> the package: one for each distro, each one having the -pmXXX that
> match the perl that is there. See the intltool package for an example
> of this approach. Alternately, you could pick a perl you like and
> adjust the package to use that perl version interpretter specifically
> on all distros. There will be a perl586 package available in fink on
> Leopard, just like there's a perl581 package in Tiger for
> compatibility with Panther's /usr/bin/perl. Lastly, you could write a
> varianted set of gnucash-perlXXX packages for a bunch of perl
> versions, and have a bundle "gnucash" that Depends on them.

The haze is clearing a little more

Thanks for the help.

>
> dan
>
>

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] perl module dependencies

[David Reiser]

Almost exactly 3 years ago there was much discussion about versioning  
perl modules. Having read several of those threads, I don't feel so  
bad about not understanding.

I have a couple issues: When I picked up several modules from that  
most prolific maintainer, None, the modules were already versioned,  
so my world view became "most pms are versioned". When one of my  
modules needed an additional module that hadn't been in fink before,  
I just went and made it versioned (even though I picked the pure perl  
version -- text-csv-pp-pm -- because I didn't want to mess with C  
code in perl). Do I knuckle down and figure out if it really needs to  
be versioned, and fix it if it doesn't? Or can I be slovenly and say,  
"I dug this hole, it's not too deep, I can live with it this way"?

Second issue: Now that Leopard is out there stalking in the weeds, it  
seemed like a good idea to create 588 versions of my modules. That  
went smoother than I expected, and they're even all running in  
support of my copy of gnucash2. So now, do I modify the gnucash2.info  
file to say: Depends: mmm-pm586 | mmm-pm-588, nnn-pm586 | nnn-pm588  
for all the modules? Or is there a shorter way? Other considerations  
that I'm not-so-blissfully unaware of?

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] failure building perl581 module

[David Reiser]

On 20 Jan 2007, at 11:44:53 PM, David R. Morrison wrote:

> My guess here is that you left out the "Type: perl" line?  The
> default CompileScript is different for "Type: perl" packages than it
> is for most packages.

That is the problem (or rather, I deleted it because I thought I was  
specifying it enough elsewhere...)

>
> The easiest way to create the legacy package is just to use the
> same .info file as before, but we "Type: perl (581)" (which will just
> restrict it to perl581).  Also, you need to rename the file as i
> mentioned before.

The name addition I got right (I think). Several pairs of perlmods in  
tracker for gnucash related dependencies.
Thanks.
>
>-- Dave
>
>
> On Jan 20, 2007, at 1:04 PM, David Reiser wrote:
>
>> When I started maintaining finance-quotehist, I didn't fully test all
>> the versions when I created the multiple version info file. Now I'm
>> trying to split out the 581 version as a legacy at the same time I'm
>> adding a 588 version to the main info file I'm planning on
>> maintaining. I have discovered that finance-quotehist-pm581 doesn't
>> build (at least for me on 10.4.8 PPC). Trying to build-as-nobody, I
>> get:
>>
>> ./configure --prefix=/sw
>> Can't exec "./configure": No such file or directory at /sw/lib/perl5/
>> Fink/Services.pm line 584,  line 1.
>> ### execution of ./configure failed, exit code -1
>>
>> Was there some function that was separate in 581 that got rolled into
>> newer perl-core modules?
>>
>> The other question is: If this version has been dangling unbuildable
>> in the 10.4 tree for 6 months, is it reasonable to assume that nobody
>> is using it and I can just dump it altogether?
>>
>> Dave

On another perl topic -- have there been problems with perl tests? I  
had to try to install perl588-core three times before all the tests  
would pass (different failures on the two failed attempts, too). I  
have had intermittent problems with finance-quotehist too, but I had  
figured that was the data server being cranky or slow.

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] failure building perl581 module

[David R. Morrison]

My guess here is that you left out the "Type: perl" line?  The  
default CompileScript is different for "Type: perl" packages than it  
is for most packages.

The easiest way to create the legacy package is just to use the  
same .info file as before, but we "Type: perl (581)" (which will just  
restrict it to perl581).  Also, you need to rename the file as i  
mentioned before.

   -- Dave


On Jan 20, 2007, at 1:04 PM, David Reiser wrote:

> When I started maintaining finance-quotehist, I didn't fully test all
> the versions when I created the multiple version info file. Now I'm
> trying to split out the 581 version as a legacy at the same time I'm
> adding a 588 version to the main info file I'm planning on
> maintaining. I have discovered that finance-quotehist-pm581 doesn't
> build (at least for me on 10.4.8 PPC). Trying to build-as-nobody, I  
> get:
>
> ./configure --prefix=/sw
> Can't exec "./configure": No such file or directory at /sw/lib/perl5/
> Fink/Services.pm line 584,  line 1.
> ### execution of ./configure failed, exit code -1
>
> Was there some function that was separate in 581 that got rolled into
> newer perl-core modules?
>
> The other question is: If this version has been dangling unbuildable
> in the 10.4 tree for 6 months, is it reasonable to assume that nobody
> is using it and I can just dump it altogether?
>
> Dave
> --
> David Reiser
> [EMAIL PROTECTED]
>
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] failure building perl581 module

[David Reiser]

When I started maintaining finance-quotehist, I didn't fully test all  
the versions when I created the multiple version info file. Now I'm  
trying to split out the 581 version as a legacy at the same time I'm  
adding a 588 version to the main info file I'm planning on  
maintaining. I have discovered that finance-quotehist-pm581 doesn't  
build (at least for me on 10.4.8 PPC). Trying to build-as-nobody, I get:

./configure --prefix=/sw
Can't exec "./configure": No such file or directory at /sw/lib/perl5/ 
Fink/Services.pm line 584,  line 1.
### execution of ./configure failed, exit code -1

Was there some function that was separate in 581 that got rolled into  
newer perl-core modules?

The other question is: If this version has been dangling unbuildable  
in the 10.4 tree for 6 months, is it reasonable to assume that nobody  
is using it and I can just dump it altogether?

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] future pymol-py problems

[David R. Morrison]

I've read through the Pymol license, which permits the source code to  
be redistributed.

That means the correct way to handle this in fink is as follows: the  
fink package manager does the SVN checkout, strips out SVN stuff, and  
creates a tarball.  We then host that tarball on the fink site (or  
the maintainer can host it), for download by fink users.

Jack, if you have such a tarball which you would like fink to host,  
please let me know and I will arrange it.

   -- Dave

P.S. The reason a direct SVN checkout can't easily be done in the  
fink context is the fact that we want to check the MD5-sum of  
whatever the user downloaded, and we can't easily do that unless the  
download is a single file.


On Jan 19, 2007, at 7:14 PM, Jack Howarth wrote:

>I noticed this week that a new pymol 0.99rc8
> version was released but starting with that
> version no source tarball would be made available
> on pymol.sourceforge.net. Rather users will have
> to manually access the source via svn in an effort
> to limit the ease of packaging this open source
> software.
>I am conflicted on this since I understand
> Warren's effort to limit the effect of the
> open source pymol on his support license sales.
> However it somewhat defies the definition of
> open source to limit the access like this.
> How do the other fink developers feel we should
> proceed? I suppose we could adjust the fink
> packaging to no longer use a source tarball
> but to use svn to download the particular
> release branch and purge the .svn files out
> to create a proper source tree. Any suggestions?
>   Jack
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Type: perl -- How many versions to keep?

[David R. Morrison]

The history here is that a perl584 package was introduced in 10.3  
unstable, but it never moved to stable due to the fact that 10.4 used  
perl586.

On the other hand, we did create a perl581 package in 10.4, for ease  
of upgrade: people who had a bunch of -pm581's installed, which had  
used the system perl in 10.3, could now rely on the perl581 package.

We're anticipating a similar transition for 10.5, which we expect  
will use perl588.  There is now a perl588 package in 10.4 (both  
stable and unstable), and you can create -pm588 packages now to  
prepare for the eventual transition.

(Another part of the history is that, when 10.4 on intel was  
introduced, we just did a mass add of "(%type_pkg[perl] = 581)  
powerpc, (%type_pkg[perl] =  584) powerpc" to the Architecture line,  
because we were unable to get perl581 or perl584 to build on intel.   
Rather than read through each package to find out which variants it  
had, we just added the same phrase to all of them.)

Testing variants is not hard: when you ask fink to build the variant,  
the proper version of perl will be loaded for you.

Anyway, my advice is this: if you are not going to be maintaining the  
10.3 version of the package (a very reasonable thing, at this point),  
then you should focus on the -pm586 and -pm588 variants.  On the  
other hand, completely removing old variants is unfriendly, because  
other things may depend on them.  So you could create a legacy  
package for -pm581 (the .info file would be called finance-quote- 
pm581.info), and set the maintainer in that file to None.

   -- Dave

On Jan 17, 2007, at 9:22 PM, David Reiser wrote:

> I picked up maintainership of finance-quote so that gnucash could
> work with a recent  version. There's a new upstream f-q out, so now
> I'm trying to understand a bit more about perlmod info files.
>
> The existing f-q info file (mostly copied from the f-q 1.08 version
> before my awareness of fink) says:
>
> Architecture: (%type_pkg[perl] = 581) powerpc, (%type_pkg[perl] =
> 584) powerpc
>
> but also:
>
> Type: perl (5.8.1 5.8.6)
>
> So why specify an architecture for 584 and then not allow it to list
> finance-quote-pm584? I believe msachs' world builds complained about
> the absence of the 584 variant. Was 5.8.4 a notorious perl version?
> Dare I just include it in the Type: field? How should I go about
> testing either a 584 or a 588 variant if I add them to the Type:  
> field?
>
> BTW, crypt-ssleay does this same thing, and it has a different
> maintainership history.
>
> Also, should I be thinking about deleting the 581 variant? I don't
> have a 10.3 machine around to test on. Would anyone on 10.4 be using
> that old a perl version?
>
> Dave
> --
> David Reiser
> [EMAIL PROTECTED]
>
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Type: perl -- How many versions to keep?

[David Reiser]

I picked up maintainership of finance-quote so that gnucash could  
work with a recent  version. There's a new upstream f-q out, so now  
I'm trying to understand a bit more about perlmod info files.

The existing f-q info file (mostly copied from the f-q 1.08 version  
before my awareness of fink) says:

Architecture: (%type_pkg[perl] = 581) powerpc, (%type_pkg[perl] =  
584) powerpc

but also:

Type: perl (5.8.1 5.8.6)

So why specify an architecture for 584 and then not allow it to list  
finance-quote-pm584? I believe msachs' world builds complained about  
the absence of the 584 variant. Was 5.8.4 a notorious perl version?  
Dare I just include it in the Type: field? How should I go about  
testing either a 584 or a 588 variant if I add them to the Type: field?

BTW, crypt-ssleay does this same thing, and it has a different  
maintainership history.

Also, should I be thinking about deleting the 581 variant? I don't  
have a 10.3 machine around to test on. Would anyone on 10.4 be using  
that old a perl version?

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc42 standstill

[David R. Morrison]

Jack,

Putting a line in your .info file which says

Type: -64bit

should allow you to use the %lib expansion for precisely the purpose  
that you want.  Notice that this type declaration does not need to  
have any other effect on the package: it won't affect the name or  
anything else.

Is there some other problem with this procedure which I am not seeing?

(As an alternative, one can create separate .info files for the  
powerpc and i386 architectures, which differ only in the appropriate  
Shlibs line.)

   -- Dave


On Jan 16, 2007, at 7:54 AM, Jack Howarth wrote:

>We are currently at a standstill with the gcc42
> release until I can resolve moving the 64-bit gcc
> libraries properly into the gcc42-shlibs package.
> I believe we currently don't have the proper tools
> in fink to achieve this. I would rather not release
> gcc42 with those shlibs in the wrong package since
> it would violate fink policy to move them later.
> I have checked with the FSF gcc darwin developers
> and it is very unlikely that FSF gcc will be changed
> to use fat binaries. We could mimic Apple's gcc and
> manually create the fat shared libraries. However
> I suspect that will cause us problems in the end
> since we will be using a totally non-standard mode
> to install FSF gcc and will have to deal with any
> bugs we create (such as how make check at -m64 would
> find the proper 64-bit shared libraries). A very
> simple fix would be if fink could define a variable
> as x86_64 or ppc64 depending on the detected arch
> so that I could just use that variable in the
> Shlibs pathnames for the 64-bit libraries. We are
> currently stuck until this issue is resolved in
> a proper manner.
>  Jack
>
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] no more -no-cpp-precomp

[David R. Morrison]

Thanks to Daniel Johnson for checking on the status of -no-cpp- 
precomp in gcc-3.3.  For both gcc-3.3 and gcc-4.0, -no-cpp-precomp is  
ignored by gcc.  So for ease of maintenance, package maintainers may  
choose to disable -no-cpp-precomp in both 10.3 and 10.4 trees (unless  
the package forces the use of gcc-3.1).

   -- Dave


On Jan 12, 2007, at 6:00 PM, David R. Morrison wrote:

> Folks,
>
> As part of our preparation for upcoming operating systems, we need  
> to entirely eliminate "-no-cpp-precomp" from the 10.4 tree, at  
> least for those packages which use gcc-4.0 (and don't force the use  
> of gcc-3.3).  At present, -no-cpp-precomp is ignored by gcc, so  
> eliminating it should be harmless.
>
> This is being worked on centrally by the fink-core group, but  
> anyone is welcome to fix their own packages.  Since this is a non- 
> functional change, there should be no reason to change the revision  
> number.
>
>   -- Dave
>
>
>


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] multilib builds

[David R. Morrison]

On Jan 13, 2007, at 10:57 AM, Jean-François Mertens wrote:

>
> As to the general problem, on the one hand I see no major reason  
> not to allow
> %lib w/o the Type field; on the other hand I prefer general mechanisms
> _ like allowing conditionals _ to very specialised ones ...
>

The %lib mechanism was created to allow for a single .info file that  
could create both a 32bit package and a 64bit package (like the  
current gmp.info in unstable).  Hence, when the Type is not -64bit, % 
lib expands to "lib".

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] multilib builds

[David R. Morrison]

On Jan 12, 2007, at 8:20 PM, Alexander Hansen wrote:

> On 1/12/07, Jack Howarth <[EMAIL PROTECTED]> wrote:
>>I'm still unclear how we can leverage the architecture Shlibs
>> field for the multilib build of the gcc42 package. The standard
>> multilib installation for gcc is to have the shared libs installed
>> for the default architecture (32-bit for Darwin) in lib/gcc4.2/lib
>> and the secondary multilib (64-bit) libraries in a ppc64 or
>> x64_64 subdirectory (at least I am assuming that Macintel uses
>> the x64_64 subdirectory name).
>>The problem as I see it is that we need to expand the explicit
>> list of shared libs to include the 64-bit ones in either ppc64
>> or x64_64 subdirectories. This would require some mechanism to
>> dynamically change the pathname in the Shlibs entries or some
>> case mechanism that would allow a different list to be used
>> for each architecture.
>>   Jack
>>
>
> Now, as I understand it, the Shlibs: field isn't actually used yet, so
> maybe it is still possible to do this, eg. a Shlibs64 field for 64-bit
> libs.

We considered that one, but the mechanism we actually implemented is  
to add an extra item to each Shlibs field, which is either "32", "64"  
or "32-64", to distinguish among the types of libraries.  If the item  
is absent, its value defaults to 32.

This is recognized by the validator in fink-0.26.0, and documented in  
the packaging manual.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] multilib builds

[David R. Morrison]

On Jan 12, 2007, at 6:53 PM, Jack Howarth wrote:

>I'm still unclear how we can leverage the architecture Shlibs
> field for the multilib build of the gcc42 package. The standard
> multilib installation for gcc is to have the shared libs installed
> for the default architecture (32-bit for Darwin) in lib/gcc4.2/lib
> and the secondary multilib (64-bit) libraries in a ppc64 or
> x64_64 subdirectory (at least I am assuming that Macintel uses
> the x64_64 subdirectory name).
>The problem as I see it is that we need to expand the explicit
> list of shared libs to include the 64-bit ones in either ppc64
> or x64_64 subdirectories. This would require some mechanism to
> dynamically change the pathname in the Shlibs entries or some
> case mechanism that would allow a different list to be used
> for each architecture.
>   Jack
>

Dear Jack,

The Shlibs entries simply record some data about libraries which the  
package installs.  So, if your package installs a 32-bit library /sw/ 
lib/gcc4.2/lib/libgcc.1.dylib then the Shlibs entry for this would be

   %p/lib/gcc4.2/lib/libgcc.1.dylib 1.0.0 %n (>= 4.2) 32

(where 1.0.0 is the compatibility version and 4.2 is the package  
version).  If in addition the package installs a 64-bit library /sw/ 
lib/gcc4.2/lib/x86_64/libgcc.1.dylib on intel and /sw/lib/gcc4.2/lib/ 
ppc64/libgcc.1.dylib on powerpc, then the package should declare  
"Type: -64bit" and the Shlibs entry for this one would be

   %p/lib/gcc4.2/%lib/libgcc.1.dylib 1.0.0 %n (>= 4.2) 64

This one uses the new Fink abbreviation "%lib", which stands for "lib/ 
ppc64" on powerpc and "lib/x86_64" on intel, but only if "Type:  
-64bit" is declared.

Finally, if (as is the case, according to jfm's analysis of your  
package) some of the libraries installed by your package are "fat"  
32-64 bit libraries, they get stored in the same directory as the 32  
bit libraries and their Shlibs entry ends in 32-64.

Hope this clarifies things.

   -- Dave





-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] no more -no-cpp-precomp

[David R. Morrison]

Folks,

As part of our preparation for upcoming operating systems, we need to  
entirely eliminate "-no-cpp-precomp" from the 10.4 tree, at least for  
those packages which use gcc-4.0 (and don't force the use of  
gcc-3.3).  At present, -no-cpp-precomp is ignored by gcc, so  
eliminating it should be harmless.

This is being worked on centrally by the fink-core group, but anyone  
is welcome to fix their own packages.  Since this is a non-functional  
change, there should be no reason to change the revision number.

   -- Dave




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] multilib builds

[David R. Morrison]

I wanted to discuss how "multilib" builds should be handled in Fink.   
To the best of my knowledge, we don't have any of these yet, but I  
understand that one is about to be added.

This is a very small hint about this in the Packaging Manual, in the  
Shared Libraries section.  There, we document the new, optional, 4th  
item in a Shlibs entry, and indicate that its value can be "32",  
"64", or "32-64".  The last option refers to libraries which were  
built "fat".

I've discussed 64-bit only libraries in previous posts (which have  
now been incorporated into the documentation).  Here, I want to  
explain the strategy for "fat" libraries.

Following the conventions established by (apple's) gcc, we will store  
64-bit-only libraries in either /sw/lib/ppc64 or /sw/lib/x86_64  
(depending on processor), but we will store *both* the 32-bit-only  
libraries and the "fat" libraries in /sw/lib.  The recommended search  
path, when doing a 64-bit compile, will be "-L/sw/lib/x86_64 -L/sw/ 
lib" (or "-L /sw/lib/ppc64 -L/sw/lib") which will find the 64-bit- 
only lib before the 32-bit-only counterpart, but then will find a  
"fat" lib in /sw/lib.

There are other choices which could have been made, but this is the  
one which gcc expects to find, so using it will make our lives easier  
in the long run.

If a package is compiling a library using the multilib option (and  
producing a 'fat' result), it should do so on *all* machines, not  
just 64 bit ones.  The reasoning here is that we want a fink package  
to be identical no matter where it is created, and hopefully there is  
not a huge overhead in building it 'fat' on all machines.

Questions or discussion are welcome.

   -- Dave





-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] go with newer glib2, or try to exclude 1 or 2 'bad' versions?

[David Reiser]

Dan Macks kindly upgraded glib2 in fink to a newly released version  
that doesn't break gnucash2 preference saving/reading. So glib2  
2.12.4 and lower works (don't even need 2.12, but I'd have to dig out  
just how far back gnucash2 can go), and glib2 2.12.7 works with only  
a few annoying warnings in the xterminal window.

Should I try to write a depends versioning declaration that excludes  
glib2 2.12.5 and 2.12.6 (I don't think 2.12.6 ever made it to fink)?  
Or do I just say glib2-shlibs (>= 2.12.7)?

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] What to do with libunicode* packages

[David R. Morrison]

On Dec 29, 2006, at 12:59 AM, Daniel Macks wrote:

> gnome has declared them obsolete (superceded by functionality in glib)
> and no longer considers them active projects. The SF website notes
> that the project has been idle since 2000. Our packages of them are
> not compliant with Shared Library policy...they've been on autopilot
> from a long-inactive maintainer since the "10.2" distro if not
> before. No other packages depend on them. Is it time to nuke them?

I vote "yes".

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] install svn oddity

[David R. Morrison]

On Dec 17, 2006, at 9:54 AM, Jack Howarth wrote:
> Also, what is up with all the instances of...
>
> tar: -: file name read contains nul character
>

There is a bug in the way that the latest tar interacts with dpkg;  
this is harmless, but I believe that a fix (for dpkg) is on the way.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] echo -n now deprecated

[David R. Morrison]

On Dec 16, 2006, at 6:11 PM, Jean-François Mertens wrote:

>
> On 17 Dec 2006, at 02:38, David R. Morrison wrote:
>
>> The reason for the /bin has to do with behaviors of different  
>> shells in Tiger.  Without writing /bin/echo, the 'echo' command is  
>> processed as a shell built-in, and the results are different for  
>> bash and tcsh.
> You're completely right !
> But {Compile,Install,etc...}Script's are always executed under (ba) 
> sh, no ?
> (unless the maintainer specifies differently, knowing what he is  
> doing...)

I think the postinstall scripts are executed under the user's shell,  
though.  And we've used this construction a lot in those scripts.

Also, I believe that Tiger's tcsh mimics the POSIX behavior but  
Tiger's bash does not.  So even if we relied on scripts being  
executed by bash, we would have trouble if the current bash is not  
POSIX-compliant.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] echo -n now deprecated

[David R. Morrison]

The reason for the /bin has to do with behaviors of different shells  
in Tiger.  Without writing /bin/echo, the 'echo' command is processed  
as a shell built-in, and the results are different for bash and tcsh.

   -- Dave


On Dec 16, 2006, at 5:00 PM, Jean-François Mertens wrote:

> I see coreutils is at version 6.7, vs 5.96 in fink.
> If the maintainer were willing to update, I would hope the need for  
> the "/bin/"
> to disappear ... ; there should be a way to write things  
> 'portably' (at least
> across current versions of GNU and of Darwin...).
> It is a bit of a shock to see coreutils behind darwin...
>
> JF Mertens
>
> On 17 Dec 2006, at 00:49, David R.Morrison wrote:
>
>> As mentioned on the new "preparing for 10.5" page on the fink wiki,
>> echo -n is now deprecated in fink.  I have edited the vast majority
>> of packages where this occurs to conform to the new version.   
>> Instead of
>>
>>echo -n "string"
>>
>> one should now write
>>
>>/bin/echo "string\c"
>>
>> (See "man echo".)  This makes our use of echo POSIX compliant, and is
>> also compatible with current 10.4 usage.
>>
>>-- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] echo -n now deprecated

[David R . Morrison]

As mentioned on the new "preparing for 10.5" page on the fink wiki,  
echo -n is now deprecated in fink.  I have edited the vast majority  
of packages where this occurs to conform to the new version.  Instead of

   echo -n "string"

one should now write

   /bin/echo "string\c"

(See "man echo".)  This makes our use of echo POSIX compliant, and is  
also compatible with current 10.4 usage.

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] filenames for .info files

[David R. Morrison]

Starting in fink-0.26.0, there will be a new field "Distribution"  
which can be used to restrict a given file to only applying to the  
listed distribution(s).  This will allow us to have the 10.4 and 10.5  
distributions share a common set of packages.

Sometimes, however, it will be necessary to have separate files for  
the different distributions, and for this reason the distribution is  
now allowed to be made part of the filename (if necessary).

The validator in 0.26.0 (and beyond) will allow filenames of the  
following form:  the invariant packagename, optionally followed by  
the architecture, optionally followed by the distribution, optionally  
followed by either version or version-revision, each delimited by  
hyphens, concluding with ".info". The "architecture" and  
"distribution" components are only allowed if the corresponding field  
is present in the package, and if it specifies exactly one value.

This is slightly more restrictive than the allowed filenames in  
previous versions of fink, but every existing .info file already  
satisfies the new rules.

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] What feature would you like to see in fink/Fink?

[David Reiser]

Something that I have wished for several times is more date information:

When I most recently installed a package
When I built it (this can be dug up from the deb build date, but it's  
more work than it should be)
When the last update was on the servers (again, available but harder  
than it should be to find)

I have wanted this information mostly when I'm muttering evil things  
wondering "what have I done _this_ time?"  My fink efforts are  
sporadic, and when I get myself into trouble, being able to tell  
"Yeah, that one was installed yesterday" (instead of last week or  
last month) can help jog my memory about what I may have been  
thinking or attempting.

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Regarding the statistics gathering and privacy.

[David H.]

Dear Asko.

As someone who watches the legal side of what Fink is doing I can assure 
you that we cannot retain any information which would enable us to 
identify the user. Legally that would put too many obligations on us and 
to have significant statistics that is not necessary. However, assigning 
a unique ID might be interesting as that would minimise the amount of 
fraud (false submissions) that could happen.

A unique ID would be able to identify the machine that submits, but not 
the user or the owner of said machine.

-d

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] What feature would you like to see in fink/Fink?

[David Fang]

> Charles Lepple wrote:
> > On 12/4/06, Robert T Wyatt <[EMAIL PROTECTED]> wrote:
> >> Cool! I think the simplest implementation would be to send a successful
> >> build or install message to the maintainer

Hi,

I also like this idea, but I think any build reports should also
include the envinronment (as seen by fink dumpinfo).  Why?  I enable
MAKEFLAGS (PkgVersion.pm) in my various fink installations, which
occasionally causes builds to break.  I wouldn't want to report any
false-failure due to parallel-unsafe compiles.  Admittedly, it's been a
long time since I've seen such a failure.

Taking this a step further, one could add an optional info field
like: "ParallellMakeUnsafe: true" To turn off MAKEFLAGS on per package
basis, and maybe leave MAKEFLAGS on by default for those of us with
*really* slow dual CPUs.  :)  From my testing, only a small minority of
packages are affected by parallel-make.  With most Macs shipping with 2+
cores these days, informed users could more easily take advantage of
multi-processors.

David

(anxiously awaiting quad-quad Macs)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] another crypto question

[David Reiser]

On Dec 1, 2006, at 12:18 AM, David Reiser wrote:

>
> On Nov 30, 2006, at 7:36 AM, Chris Zubrzycki wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>> On Nov 29, 2006, at 10:22 PM, David Reiser wrote:
>>
>>> Configure checks for the presence of 2 versions of libsoup, and if
>>> neither is present, testgtkhtml.c isn't compiled. Furthermore, when
>>> it is compiled, it is compiled into the top src directory, and the
>>> current fink implementation does not install testgtkhtml anywhere.
>>> So, it looks to me like we could disable access to libsoup (via
>>> buildconflicts)
>>
>> You don't even need to conflict. Just ignore it, or patch the
>> makefile to remove that line. BuildConflicts aren't fun.
>>
>>
>> - -chris zubrzycki
>
> Hmm. Patching configure or Makefile fits in my list of Not Fun.
> Someone else will have to do it or teach me how to get what I want
> without stomping on something else.

I've been thinking abut this some more, and I've concluded that  
"ignore it" is really the right answer.

The only time testgtkhtml is built is if crypto is active and libsoup  
is installed. Otherwise, configure checks for libsoup, doesn't find  
it, and says 'OK, I'll skip testgtkhtml'. Neither the build nor the  
install is disrupted by the absence of libsoup. Since fink doesn't  
keep the build directory anyway (usually), there is no existing  
circumstance that having or not having libsoup and its crypto  
siblings affects the installed version of gtkhtml3.8.15.

Can we delete the crypto dependencies and move gtkhtml3.8.15 out of  
crypto?

>
> Dave
> --
> David Reiser
> [EMAIL PROTECTED]
>
>

--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] New Fink Feature: Interactive Control of "unstable"

[David R. Morrison]

On Dec 5, 2006, at 11:03 AM, TheSin wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> also on this topic, it's a long standing issue and I keep  
> forgetting to mention it, but when you do the selfupdate from  
> stable to unstable fink dies on gettext you ened to manually do  
> fink install gettext-tools then selfupdate again.  Just thought I'd  
> mention that, since most users don't know how to solve that and the  
> solution that fink provides doesn't help.

Actually, I think the 'location' of this problem has moved, since the  
versions of gettext in stable and unstable are now identical.  The  
problem now is if you do a fresh install from the installer you have  
the old gettext-tools, and if you selfupdate (even sticking to  
stable) you run into this glitch about gettext-tools not updating  
properly without manual intervention.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] New Fink Feature: Interactive Control of "unstable"

[David R. Morrison]

That's great!

I wonder whether, when a user has changed the Trees entry, fink  
should automatically do a selfupdate at the end of 'fink configure'?

   -- Dave

On Dec 5, 2006, at 12:30 AM, Daniel Macks wrote:

> As part of 'fink configure', HEAD now offers to enable/disable the
> "unstable" entries in /sw/etc/fink.conf:Trees. Default is to leave
> current settings unchanged. When enabling, the "unstable" analog of
> each presently-enabled "stable" tree is appended to the Trees field.
> Please test, fix wording of the prompt, complain about ordering of the
> newly-added entries or other unlikable behavior, etc etc.
>
> dan
>
> -- 
> Daniel Macks
> [EMAIL PROTECTED]
> http://www.netspace.org/~dmacks
>
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Validation of splitoffs failed. -- what is this?

[David R. Morrison]

Just perusing the code... are you also getting a warning about a  
BuildDependsOnly violation or an Obsolete violation?

   -- Dave

On Dec 4, 2006, at 8:11 AM, Benjamin Reed wrote:

> I'm getting a bunch of "Validation of splitoffs failed." errors while
> building, even though "fink validate" for those packages passes.  What
> is this error supposed to represent?
>
> -- 
> Benjamin Reed a.k.a. Ranger Rick
> Fink, KDE, and Mac OS X development
> http://www.racoonfink.com/
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Shlibs policy modification (64bit libraries)

[David R. Morrison]

Fink's Shlibs policy has been updated to handle 64bit libraries and  
'fat' libraries.

Effective immediately, any fink package which installs shared 64bit  
or 'fat' libraries should use a modified form of the Shlibs field in  
which either "64" or "32-64", as appropriate, has been appended to  
the end of each Shlibs entry with the corresponding type of library.

It is also allowed to append "32" to the Shlibs entry of an ordinary  
32bit library, but (for backwards-compatibility) this is not required.

The Packaging Manual has been updated to reflect this slight change  
of policy, and the 'fink validate' command will correctly detect the  
new form in the forthcoming fink 0.26.0 release.

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gnupg2

[David H.]

Cory, Benjamin, go ahead and touch my packages, I do not have time for 
that right now.

-d

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] another crypto question

[David Reiser]

On Nov 30, 2006, at 7:36 AM, Chris Zubrzycki wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Nov 29, 2006, at 10:22 PM, David Reiser wrote:
>
>> Configure checks for the presence of 2 versions of libsoup, and if
>> neither is present, testgtkhtml.c isn't compiled. Furthermore, when
>> it is compiled, it is compiled into the top src directory, and the
>> current fink implementation does not install testgtkhtml anywhere.
>> So, it looks to me like we could disable access to libsoup (via
>> buildconflicts)
>
> You don't even need to conflict. Just ignore it, or patch the
> makefile to remove that line. BuildConflicts aren't fun.
>
>
> - -chris zubrzycki

Hmm. Patching configure or Makefile fits in my list of Not Fun.  
Someone else will have to do it or teach me how to get what I want  
without stomping on something else.

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 64bit shared libraries

[David R. Morrison]

On Nov 30, 2006, at 12:18 PM, Chris Zubrzycki wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Nov 30, 2006, at 12:55 PM, David R. Morrison wrote:
>
>>
>> On Nov 30, 2006, at 9:47 AM, David R. Morrison wrote:
>>
>>>
>>> We could have %type_bit[-64bit] which strips off leading '-' if
>>> present, trailing 'bit' if present, and chucks out the rest -- this
>>> would work for both.  But I don't like that too well, and am very
>>> open to suggestions.
>>
>> Maybe better: %type_number[-64bit], which removes every non-numeric
>> character from its argument.
>
> We need the full arch, no? ppc64 != intel 64 != next 64bit chip  
> they use...

Well, for keeping track of the Shlibs, we don't need to store that  
information, since we are not building any cross-platform binaries or  
libs.  That is, building something 'fat' in fink means making a  
library that is both 32 and 64 bit, but only on one platform at a time.

(My previous proposal about a %lib percent expansion whose value  
depends on the architecture, will help sort out whether the libraries  
are getting installed in /sw/lib/ppc64 or /sw/lib/x86_64.)

   -- Dave



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr1, libmpfr1-64bit and gcc42

[David Fang]

> I would like to have the gcc42 package introduced into fink 10.4
> unstable now. The current packaging is on fink tracking at...
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1597013&group_id=17203&atid=414256
>
> The gcc 4.2 branch has been stablized for some weeks now however the
> rate of development is pretty slow so it isn't worth waiting for the
> final gcc 4.2 release. My goals are to...
>
> 1) put gcc42 into fink 10.4 unstable.
> 2) migrate all of the packages in fink 10.4 unstable
> with gcc4 dependencies to gcc42.
> 3) Remove the current gcc4 from fink 10.4 unstable.
> 4) Modify gcc4 in fink 10.4 stable to conflict with
> gcc42 and introduce gcc42 to fink 10.4 stable.

Hi,
Just a clarification: by 3 and 4) you're not planning to remove
the current gcc4 (4.1) completely right? just out of the way for 4.2 in
unstable, correct?  I'd still like to keep each release branch around, as
I'm still usign/testing them periodically.  I was hoping to have their
suffixes renamed -4.x, but I can live with them conflicting, as I can just
switch between them with fink.

> Steps 3 and 4 can wait perhaps until gcc 4.2 is actually released.
> However I would at least like to get gcc42 into fink 10.4 unstable so
> we can complete step 2.
>   Jack
> ps I also have updated libmpfr1 packaging on the fink tracking system
> with a new libmpfr1-64bit package both based on this weeks 2.2.1
> release. It would be nice to get those into fink 10.4 unstable as
> well.

FWIW, I tested these out RC-1 (make check) on the various Macs I have
around, and all their tests passed.  Looks good.

Thanks again for all the maintainence work on these.

David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 64bit shared libraries

[David R. Morrison]

On Nov 30, 2006, at 9:47 AM, David R. Morrison wrote:

>
> We could have %type_bit[-64bit] which strips off leading '-' if  
> present, trailing 'bit' if present, and chucks out the rest -- this  
> would work for both.  But I don't like that too well, and am very  
> open to suggestions.

Maybe better: %type_number[-64bit], which removes every non-numeric  
character from its argument.

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] 64bit shared libraries

[David R. Morrison]

Dear fink developers,

I realized today that there is another wrinkle in the discussions  
we've been having about 64bit libraries.  I've gone ahead an  
implemented the policy part of the previous discussion --  
architecture-dependent storage locations for 64bit libraries -- and  
we now have three packages for 64bit and they all store things in the  
correct locations.

However, I've realized that we will need to modify our Shlibs policy  
to properly handle the case of 64bit libraries.  The issue is this:  
if we are going to build some libraries 'fat', which can be linked to  
by other 64bit libraries, then the Shlibs field will need a way to  
keep track of which libraries have 64bit components and which ones do  
not.  I see two possible strategies:

Strategy1: Add a Shlibs64 field in addition to the Shlibs field.  A  
64bit-only lib would declare Shlibs64; a 32bit-only lib would declare  
Shlibs.  Any fat libs would need two entries.

Strategy2: Add an optional fifth field to each Shlibs entry, with  
possible values "32", "64", or "fat".  (If absent it would default to  
32.)  This would indicate which kinds of libs would be present in the  
file.

In either case, we'll need some kind of percent expansion to treat  
the case of a single .info file building things in both 32 and 64bit  
mode.  In the first case, we'd want Shlibs%64 where %64 is empty in  
the 32 bit case.  (But this is something we've never had before: the  
% modifying the name of the field, not the contents of the field.  Is  
it feasible?)  In the second case, we'd want a percent expansion  
which resolved to either 32 or 64 (or possibly again, empty or 64).

We could have %type_bit[-64bit] which strips off leading '-' if  
present, trailing 'bit' if present, and chucks out the rest -- this  
would work for both.  But I don't like that too well, and am very  
open to suggestions.

   -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr1, libmpfr1-64bit and gcc42

[David R. Morrison]

Jack,

You may or may not have noticed that I updated gmp-64bit yesterday to  
use the new, architecture-dependent, installation location for  
libraries (/sw/lib/ppc64 or /sw/lib/x86_64).  These locations are  
also now documented in the packaging manual (section 4.2).

I will revise libmpfr1-64bit accordingly before adding it to fink.

   -- Dave


On Nov 30, 2006, at 6:53 AM, Jack Howarth wrote:

> Jeff,
> I would like to have the gcc42 package introduced
> into fink 10.4 unstable now. The current packaging is
> on fink tracking at...
>
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1597013&group_id=17203&atid=414256
>
> The gcc 4.2 branch has been stablized for some weeks now
> however the rate of development is pretty slow so it
> isn't worth waiting for the final gcc 4.2 release. My
> goals are to...
>
> 1) put gcc42 into fink 10.4 unstable.
> 2) migrate all of the packages in fink 10.4 unstable
> with gcc4 dependencies to gcc42.
> 3) Remove the current gcc4 from fink 10.4 unstable.
> 4) Modify gcc4 in fink 10.4 stable to conflict with
> gcc42 and introduce gcc42 to fink 10.4 stable.
>
> Steps 3 and 4 can wait perhaps until gcc 4.2 is
> actually released. However I would at least like
> to get gcc42 into fink 10.4 unstable so we can
> complete step 2.
>   Jack
> ps I also have updated libmpfr1 packaging on the
> fink tracking system with a new libmpfr1-64bit
> package both based on this weeks 2.2.1 release.
> It would be nice to get those into fink 10.4
> unstable as well.
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] another crypto question

[David Reiser]

On Nov 29, 2006, at 11:52 AM, Sebastien Maret wrote:

> David Reiser <[EMAIL PROTECTED]> writes:
> [...]
>
>> I've found that if I strip the crypto dependencies from the info file
>> and add BuildConflicts: libsoup-everything-but-shlibs,
>> gtkhtml3.8.15-3.10.2 will build and the resulting library is drop-in
>> usable for gnucash 2.0.2. I still have to test if gnucash builds
>> against the nc version.
>
> Then I guess the question is whether libsoup should be listed as a
> buildep in gtkthml. It it builds without it, and if the binary is
> fully functional, then we can just drop libsoup from the buildeps and
> move it to non crypto. Of course we have to make sure that it is
> usable for all packages that use it, not only gnucash.
>
> Sébastien

Configure checks for the presence of 2 versions of libsoup, and if  
neither is present, testgtkhtml.c isn't compiled. Furthermore, when  
it is compiled, it is compiled into the top src directory, and the  
current fink implementation does not install testgtkhtml anywhere.  
So, it looks to me like we could disable access to libsoup (via  
buildconflicts), remove all the crypto dependencies, and take  
gtkhtml3.8.15 out of crypto without affecting any current package.

If I 'grep -R soup gtkhtml-3.10.2/src', the only place 'soup' appears  
is in testgtkhtml.c

If I 'grep -R gtkhtml3.8.15 /sw/fink/10.4', the only packages  
depending on gtkhtml3.8.15 are:
gtk-sharp-monodoc
gtk-sharp
gtk-sharp2
(and soon gnucash2)

I also couldn't find the character string 'testgtkhtml' anywhere in  
the gtk-sharp... tarball collections. Probably a good thing, since  
fink's install of gtkhtml3.8.15 does not contain testgtkhtml (unless  
I've screwed up my search methods).

And I have tested building gnucash against the my libsoup-disabled  
gtkhtml, and gnucash works just fine. I really wouldn't know how to  
adequately test mono.

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fink-mirrors sourceforge update

[David R. Morrison]

Martin, just to clarify: Jesse has volunteered to help keep fink's  
list of sourceforge mirrors current, by comparing to sourceforge's  
own list of its mirrors and doing other testing.

   -- Dave


On Nov 26, 2006, at 10:50 PM, Martin Costabel wrote:

> Jesse W wrote:
>> Suggested update to /sw/lib/fink/mirrors/sourceforge :
>>
>> internap (nam-US: http://internap.dl.sourceforge.net/sourceforge/ )
>> isn't listed as a sourceforge mirror as of now, at least not for the
>> psi jabber client.  It does respond to pings, though.
>
> Just surious: What package is "psi jabber client"? Maybe it has a  
> custom
> mirror list?
>
>> Further testing is indicated.
>>
>> Also, west.dl, us.dl and eu.dl arn't listed (I don't know if they are
>> redirection links, but...)
>
> They are all in the current mirror/sourceforge list, including  
> internap.
> What list are you looking at?
>
> -- 
> Martin
>
>
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Cross posting.

[David H.]

 > I'd like to see a feature that'd slap people for stupidly
 > cross-posting...

Dear Timothy,

I am sorry that my cross-posting has offended you. The message was sent 
twice on accident. Please also note that I stated quite clearly that 
this message has been cross posted. The reason for that is very simple.

I wanted to hear about features from the User perspective as well as the 
developer perspective. Those two mailing lists do have a slightly 
different user-base.

I will make sure to more carefully tailor my emails in the future.

D. Hoehn
Fink PR Dude

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] another crypto question

[David Reiser]

gtkhtml3 and 3.8.15 are in crypto because of a builddepends on  
libsoup (and its crypto dependencies). The packaging description  
mentions that the crypto portions are only used for testing during  
compile. Running otool -L on the gtkhtml library shows no links to  
crypto libraries.

Crypto policy says in part "As an extension of this policy, any  
package that Depends (or BuildDepends) on such a package must also be  
in crypto". Is this extension the kind  for which there is never an  
exception? (Like: tests things using crypto libraries but doesn't  
implement crypto, and doesn't link to crypto libraries in its binaries.)

If it is a 'no-exceptions' case, how do you feel about my creating  
gtkhtml3.8.15nc? nc= no crypto.

I've found that if I strip the crypto dependencies from the info file  
and add BuildConflicts: libsoup-everything-but-shlibs,  
gtkhtml3.8.15-3.10.2 will build and the resulting library is drop-in  
usable for gnucash 2.0.2. I still have to test if gnucash builds  
against the nc version.

I really want gnucash 2.x to be eligible for binary distribution.  
With the unification of finance-quote, crypt-ssleay, and libofx, it's  
down to gtkhtml3.8.15 keeping a really useful base gnucash 2.0.x in  
crypto. (direct online banking connections using aqbanking will  
always force the 'full' version into crypto).

Dave
--
David Reiser
[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] What feature would you like to see in fink/Fink?

[David Fang]

> > When the user decides to remove a packet he installed, fink should be
> > able to remove packets that are no longer necessary.
>
> I can see one obvious problem with such a feature, which has already bitten
> me using aptitude under Debian (has this built in). Package A has a
> dependency causes package B and package C to be installed. User uses package
> A for a while, and during this time notices package B and starts using that
> as well. They then decide to remove package A and suddenly package B also
> disappears (along with package C). User gets very annoyed :)
>
> I had precisely this experience a while back. The wording of standard
> aptitude warning "The following packages are unused and will be removed"
> makes little sense to a user when they quite clearly ARE using package B (as
> I was). The two workarounds are to either re-install package B (a nuisance),
> or cancel the removal of A, then try again but this time explicitly tell it
> to keep package B (also a nuisance).
>
> If this feature were to be implemented in fink, a more useful approach could
> be something like this:
>
> % fink remove packageA
> ...
> The following packages were only installed because packageA depends on them:
> packageB packageC
> Would you like to keep any of these packages? [Y/n] y
> Keep package packageB? [Y/n] y
> Package packageB will be KEPT.
> Keep package packageC? [Y/n] n
> Package packageC will be REMOVED.
> ...

Since the debfoster package does this sort of dependence-based
queried-pruning already, would it be possible to take advantage of it in
the fink front-end?

Fang


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] What feature would you like to see in fink/Fink?

[David H.]

Dear community.

Reading the Wiki we have some very technical ideas on how to improve 
fink. This thread is meant for you and the quirks you have noticed. For 
the developers as well as the users.

I will try to track all the feature requests that I might see in this 
thread. They will be added to the Wiki and once time has progressed and 
the team has decided that some of them make a lot of sense I am planning 
on holding a survey on the features that have been chosen.

This should help the development team to make a conscious and very 
informed decision what new features should be implemented and how quickly.

So please spill your thoughts:

What feature would you _love_ to see in fink/Fink?
Why (give us a short example what it would make easier for you)
How do you feel the rest of the community would benefit from your request?

Thank you!

D. Hoehn
Fink PR Dude
FDN Board member

PS: Please reply only to ONE list! This has been cross posted to save time!

-d

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] What feature would you like to see in fink/Fink?

[David H]

Dear community.

Reading the Wiki we have some very technical ideas on how to improve 
fink. This thread is meant for you and the quirks you have noticed. For 
the developers as well as the users.

I will try to track all the feature requests that I might see in this 
thread. They will be added to the Wiki and once time has progressed and 
the team has decided that some of them make a lot of sense I am planning 
on holding a survey on the features that have been chosen.

This should help the development team to make a conscious and very 
informed decision what new features should be implemented and how quickly.

So please spill your thoughts:

What feature would you _love_ to see in fink/Fink?
Why (give us a short example what it would make easier for you)
How do you feel the rest of the community would benefit from your request?

Thank you!

D. Hoehn
Fink PR Dude
FDN Board member

PS: Please reply only to ONE list! This has been cross posted to save time!

-d

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 64bit libraries and a new percent expansion

[David Fang]

Heh, nevermind, found the 64bit-cpu package... as mentioned in other
reply!

*hides*


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 64bit libraries and a new percent expansion

[David Fang]

>While you are adding this to fink, would it be possible to use some
> MacOS X system call to detect the presence of 64-bit support on the
> processor? I have thought it would be handy to have such a flag as
> available for checking in info scripts for such cases as a
> gcc42-64-bit package (which would be a native 64-bit build of the gcc
> compiler itself).

Hi all,
One thing I've found works is to compile a 64-bit dummy binary at
patch-time or configure-time.

% echo "int main(int, char*[]) { return 0; }" > test64.cc
% g++ -m64 test64.cc -o test64
% ./test64 > /dev/null 2>&1

the execution will fail if 64-bit is unsupported.  Does this suffice?

I was able to test an early draft of your gcc4 packaging that way (back
when we wanted to conditionally --disable-multilib).

Maybe even useful as a pseudo-package for 64b dependency tracking?

David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 64bit libraries and a new percent expansion

[David R. Morrison]

That's already there (added last summer): a virtual package called  
"64bit-cpu" which you may add to Depends or BuildDepends where  
appropriate.

  -- Dave

On Nov 22, 2006, at 7:06 AM, Jack Howarth wrote:

> David,
>While you are adding this to fink, would it be possible
> to use some MacOS X system call to detect the presence of
> 64-bit support on the processor? I have thought it would
> be handy to have such a flag as available for checking
> in info scripts for such cases as a gcc42-64-bit package
> (which would be a native 64-bit build of the gcc compiler
> itself).
>Jack
>
> -- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fink-devel


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 64bit libraries and a new percent expansion

[David R. Morrison]

A quick followup thought: if we add --libdir='${prefix}/%lib' to the % 
c defaults, then we should introduce a NoSetLibdir command to disable  
that when necessary.

   -- Dave

On Nov 18, 2006, at 8:43 AM, David R. Morrison wrote:

> Dear fink developers,
>
> I solicit your comments on the proposals below to (1) change the  
> storage location for 64bit libraries and formalize this into  
> policy, and (2) add a new percent expansion to fink, one whose  
> value would be dependent on some other things.
>
> The issue is the correct storage location for 64bit libraries.   
> We've known for some time that 64bit libraries and 64bit  
> executables are not compatible with 32bit ones, and a decision was  
> reached last spring to store 64bit libraries in /sw/lib64  
> (analogous to some linux distributions).  However, it has since  
> been pointed out by Peter O'Gorman that gcc makes some assumptions  
> about where 64bit libraries are being stored: either /sw/lib/ppc64  
> for powerpc hardware, or /sw/lib/x86_64 for intel hardware.
>
> Proposal #1 is that we use these storage locations for our 64bit  
> libraries, and make that fink policy.  (There are only two packages  
> which have adopted the old scheme -- gmp-64bit and openmcl-64bit --  
> and we would need to break binary compatibility for these by moving  
> their shared libs in a upgrade.  However, nothing depends on them,  
> and they are only present in unstable.)
>
> To make packaging easier on multiple architectures, and in  
> particular to make it easier to use the fink "variants" idea to  
> package 64bit libraries and 32bit libraries in the same  
> architecture, Proposal #2 is to introduce a new percent expansion % 
> lib which would behave as follows:
>  1) If the package does not have Type -64bit, then %lib expands to  
> lib.
>  2) If the package does have Type -64bit, then the expansion of % 
> lib depends on the architecture: it either expands to lib/ppc64 for  
> powerpc, or lib/x86_64 for i386.
>  3) Possibly, the default value for LDFLAGS should become -L%p/%lib  
> instead of -L%p/lib.
>  4) Possibly, the default contents of %c should be expanded from "-- 
> prefix=%p" to "--prefix=%p --libdir='${prefix}/%lib' ".
>
> So, a typical packaging which used this could include the following  
> lines (explanation afterwards):
>
> Package: gmp%type_pkg[-64bit]
> Type: -64bit (binary)
> Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
> NoSetLDFLAGS: true
> SetLDFLAGS: -L%p/%lib
> ConfigureParams: --libdir='${prefix}/%lib'
> SplitOff: <<
>  Package: %N-shlibs
>  Files: %lib/libgmp.*.dylib
>  Shlibs: <<
> %p/%lib/libgmp.3.dylib 8.0.0 %n (>= 4.2.1-1)
>   <<
> <<
>
> This fragment of an .info file would be used to build both the gmp  
> and gmp-64bit packages; would build splitoffs for each; the 64bit  
> variant depends on the 64bit-cpu virtual package as it should; the  
> LDFLAGS is reset to the correct location (unless we make that part  
> of the default);  the configure script is fed the correct library  
> directory (unless we make that part of the default); the shared  
> library files are correctly moved into the -shlibs splitoff, and  
> they are correctly documented in the Shlibs field.
>
>   Comments?
>
> -- Dave
>


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] 64bit libraries and a new percent expansion

[David R. Morrison]

Dear fink developers,

I solicit your comments on the proposals below to (1) change the  
storage location for 64bit libraries and formalize this into policy,  
and (2) add a new percent expansion to fink, one whose value would be  
dependent on some other things.

The issue is the correct storage location for 64bit libraries.  We've  
known for some time that 64bit libraries and 64bit executables are  
not compatible with 32bit ones, and a decision was reached last  
spring to store 64bit libraries in /sw/lib64 (analogous to some linux  
distributions).  However, it has since been pointed out by Peter  
O'Gorman that gcc makes some assumptions about where 64bit libraries  
are being stored: either /sw/lib/ppc64 for powerpc hardware, or /sw/ 
lib/x86_64 for intel hardware.

Proposal #1 is that we use these storage locations for our 64bit  
libraries, and make that fink policy.  (There are only two packages  
which have adopted the old scheme -- gmp-64bit and openmcl-64bit --  
and we would need to break binary compatibility for these by moving  
their shared libs in a upgrade.  However, nothing depends on them,  
and they are only present in unstable.)

To make packaging easier on multiple architectures, and in particular  
to make it easier to use the fink "variants" idea to package 64bit  
libraries and 32bit libraries in the same architecture, Proposal #2  
is to introduce a new percent expansion %lib which would behave as  
follows:
  1) If the package does not have Type -64bit, then %lib expands to lib.
  2) If the package does have Type -64bit, then the expansion of %lib  
depends on the architecture: it either expands to lib/ppc64 for  
powerpc, or lib/x86_64 for i386.
  3) Possibly, the default value for LDFLAGS should become -L%p/%lib  
instead of -L%p/lib.
  4) Possibly, the default contents of %c should be expanded from "-- 
prefix=%p" to "--prefix=%p --libdir='${prefix}/%lib' ".

So, a typical packaging which used this could include the following  
lines (explanation afterwards):

Package: gmp%type_pkg[-64bit]
Type: -64bit (binary)
Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
NoSetLDFLAGS: true
SetLDFLAGS: -L%p/%lib
ConfigureParams: --libdir='${prefix}/%lib'
SplitOff: <<
  Package: %N-shlibs
  Files: %lib/libgmp.*.dylib
  Shlibs: <<
 %p/%lib/libgmp.3.dylib 8.0.0 %n (>= 4.2.1-1)
   <<
<<

This fragment of an .info file would be used to build both the gmp  
and gmp-64bit packages; would build splitoffs for each; the 64bit  
variant depends on the 64bit-cpu virtual package as it should; the  
LDFLAGS is reset to the correct location (unless we make that part of  
the default);  the configure script is fed the correct library  
directory (unless we make that part of the default); the shared  
library files are correctly moved into the -shlibs splitoff, and they  
are correctly documented in the Shlibs field.

   Comments?

 -- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel