Re: [Fink-devel] updating Fink's lilypond

[Matthias Neeracher]

On Feb 28, 2013, at 4:07 PM, Hanspeter Niederstrasser  
wrote:
> Recent upstream patches to lilypond now allow it to build with clang. I've 
> taken those patches and updated the lilypond and lilypond-devel pkgs to the 
> latest released versions.  I've attached the new files to this message.  The 
> only thing missing in the 10.7 tree is dblatex which hasn't yet been migrated 
> from the 10.4 tree (maintainer cc'd as a reminder).  Once dblatex has been 
> migrated, can these be added to the 10.7 tree?  Thanks,
> 
> Hanspeter
> 

Thanks a lot for your efforts, I'll look at them and update ASAP.

Where does the dblatex dependency enter the picture? I don't recall having come 
across that package name before.

Matthias

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] updating Fink's lilypond

[Matthias Neeracher]

Thanks for your quick answer, Max!

On Mar 1, 2013, at 12:31 AM, Max Horn  wrote:
> sorry for not responding to your previous email on dblatex :-(.
> 
> On 28.02.2013, at 16:07, Hanspeter Niederstrasser wrote:
>> Recent upstream patches to lilypond now allow it to build with clang. I've 
>> taken those patches and updated the lilypond and lilypond-devel pkgs to the 
>> latest released versions.  I've attached the new files to this message.  The 
>> only thing missing in the 10.7 tree is dblatex which hasn't yet been 
>> migrated from the 10.4 tree (maintainer cc'd as a reminder).  Once dblatex 
>> has been migrated, can these be added to the 10.7 tree?  Thanks,
> 
> I have no plans to port dblatex to 10.7, because in order to do that, I would 
> have to install tetex-base (or perhaps the texlive-base package, which didn't 
> exist back when I packaged dblates). But I have no desire to install either a 
> TeX system from the stone age (tetex), or an outdated texlive 2011 in 
> parallel to my MacTeX 2012 installation.
> 
> But feel free to take over the package (and perhaps update it to the latest 
> version) if you like.

Sounds good. I've tried to do just that, and the latest version will build with 
a small patch. Unless Hanspeter wants to own it (and he'd be more than welcome 
to it, a package dragging in both TeX and docbook is not my idea of fun), I'll 
declare myself the maintainer and remove your package theft deterrent language 
:-)

Matthias


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Cannot install ucblogo

[Matthias Neeracher]

We (most likely Jean-François, from the commit logs) cleverly post-process the 
malformed .info files once the have been compiled. Even more cleverly, 
SnowLeopard's makeinfo apparently gzips the generated files, so there's nothing 
to find and patch anymore.

Should be easy enough to fix, thanks for the report.

Matthias

On Dec 31, 2009, at 0:38 , monipol wrote:

> On 30/12/2009, at 12:31, Wolfram Schroers wrote:
>> I have a problem installing the package ucblogo. The build works fine, but 
>> when trying to "fink (re)install" it, I get an error message:
> (...)
>> Preparing to replace ucblogo 5.5-2 (using .../ucblogo_5.5-2_darwin-i386.deb) 
>> ...
>> install-info(loops.info): no entry for file `loops'.
>> install-info(ucblogo.info): no entry for file `ucblogo'.
>> Unpacking replacement ucblogo ...
>> Setting up ucblogo (5.5-2) ...
>> 
>> No `START-INFO-DIR-ENTRY' and no `This file documents'.
>> install-info(/sw/share/info/loops.info): unable to determine description for 
>> `dir' entry - giving up
>> /sw/bin/dpkg: error processing ucblogo (--install):
>> subprocess post-installation script returned error exit status 1
>> Errors were encountered while processing:
>> ucblogo
>> ### execution of /sw/bin/dpkg-lockwait failed, exit code 1
>> Failed: can't install package ucblogo-5.5-2
>> 
>> I do not know if this is related to the other issues I have been observing 
>> or not.
>> 
>> I am running Snow-Leopard 10.6.2, latest updates installed, latest version 
>> of Fink and have the development branch activated.
> 
> Hello, William. It looks like the documentation file provided by the 
> developers of ucblogo (ucblogo.info) doesn't have the necessary 
> INFO-DIR-SECTION and {START, END}-INFO-DIR-ENTRY fields. Since this 
> particular package is maintained by Matthias Neeracher, so I'm CC'ing this 
> reply to him. As package maintainers are ultimately responsible for their 
> packages, we recommend users to send bug reports to both the maintainer and 
> one of the {fink-users, fink-beginners} mailing lists.
> 
> In order to find out who is the maintainer of a given package, run the fink 
> info command, as in
> 
> fink info ucblogo
> 
> None  is a particular case. It means that the package doesn't 
> have a maintainer, so it usually suffices to send an e-mail to the fink-devel 
> address alone.
> 
> 
> Cheers,
> 
> --
> monipol
> http://finkers.wordpress.com
> 
> Submitting a Fink bug report? Read this:
> http://www.finkproject.org/doc/netiquette/index.php
> http://finkers.wordpress.com/2009/06/03/bug-reports/
> 


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] jadetex-3.13-1023

[Matthias Neeracher]

On Jul 27, 2009, at 11:08 PM, Alexander Hansen wrote:
> Try running "sudo texhash";

Ah, good to know!

Matthias



--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fontconfig-path incompatible with xquartz

[Matthias Neeracher]

Hmm, I must have been asleep at the wheel on this matter. Sorry about  
that...

On Dec 30, 2008, at 22:14 , Alexander Hansen wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Costabel wrote:
>> The xquartz X11 update packages have switched from
>> /usr/X11/lib/X11/fonts/fonts.conf for the fontconfig conf file to
>> /usr/X11/lib/X11/fontconfig/fonts.conf
>> [...]
>> I don't know the fontconfig xml based lingo, so I don't know if the
>>  directive in /sw/share/fontconfig-path/fontconfig-path.conf
>> can be conditionalized on the existence of one fonts.conf file or
>> another. It is probably easier to do this in a PostInst script.
>>
> I've attached a modification to the .info and .patch file.
> Essentially this works just as Martin suggests:  there are now
> fontconfig-path.conf.oldx and fontconfig-path.conf.newx, and a
> symbolic link to the appropriate version is generated at install time.

Thanks for looking into this!

While this would certainly be preferable over the current situation, I  
find it somewhat unsatisfactory that this needs a reinstall if the  
xquartz update gets applied behind the package's back. I'm leaning  
toward including both the old and the new path.

Matthias


--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Re: [Fink-devel] packaging request

[Matthias Neeracher]

>> I can help out.  The first thing to do would be to ensure that all of
>> the dependencies are also available in Fink.
>> Available:
>> tcl8.4 -> tcltk in Fink
>> libexpect -> expect
>
> The expect in Fink hasn't been updated for a long time, it uses an  
> old version of tcltk sources, and it doesn't build shared libs. It  
> really needs some maintainer attention (CCed).

Thanks for the heads up. I've now updated to 5.43. libexpect is fairly  
small. Is there really much of a point in building shared libs for it?

Matthias


-
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] Re: Giving up on ghc

[Matthias Neeracher]

On Jun 26, 2005, at 10:06 AM, Remko Troncon wrote:

With much tweaking of readline (installing a local readline  
instead of editline in /usr/local -- dunno why that mattered for  
fink) I was eventually able to get the darwinports version  
working. It relies on a bootstrap which is set up to look at the  
darwinports library locations, but those look like they are set by  
a shell script.




Matthias' experimental info file also makes use of that bootstrap,  
but modifies it a little to make it work for the fink build  
process. As a matter of fact, I got GHC built with Matthias'  
experimental info file


Yes it builds, but it does not run, as far as I found. It complains  
about not finding some modules which, I believe, should have been  
linked in.


Matthias



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Giving up on ghc

[Matthias Neeracher]

{Cc to everybody who has reported that ghc no longer builds]

I'm afraid I find myself unable to get the ghc package to run again  
after trying for more than a week (why do supposedly "clean"  
languages always have such dirty builds?), so I've retired it from CVS.


I've left my abortive attempt at a 6.4 in my experimental directory.  
Anybody who would like to get it to work is welcome to try.


Presumably the darcs package should be retired, too, as it needs ghc  
to build.


Matthias



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Problem with OpenJade not working any more with new tetex

[Matthias Neeracher]

On Mar 6, 2005, at 12:39 PM, Michèle Garoche wrote:
Sorry for the cross posting, but since the new tetex is here, it is 
impossible to transform an sgml document to pdf or postscript format 
via openjade.

As I don't know how to solve the problem and where it lies exactly, 
here are the errors I've got:

1 - Trying to compile an sgml document with jw:
... Fatal format file error; I'm stymied
2 - Rebuilding jadetex
This must be related to the fact that pdfetex is the default in tetex 3.
I'll have to revise the jadetex package anyway, so I'll look into this.
Matthias

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: New freetype2 packages

[Matthias Neeracher]

From: Martin Costabel <[EMAIL PROTECTED]>
After some quick tests, I have now committed these packages for
freetype versions 2.1.4 and 2.1.9 to CVS 10.3/unstable:
freetype2, freetype2-dev, freetype2-shlibs
freetype2-hinting, freetype2-hinting-dev, freetype2-hinting-shlibs
freetype219 freetype219-shlibs
I'm pleased to report that your freetype219 package works flawlessly 
with the upcoming lilypond-unstable package.

Matthias

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] freetype2-update

[Matthias Neeracher]

On Feb 27, 2005, at 9:45 AM, Martin Costabel wrote:
This formulation comes from a time when there was no xfree86-4.0 and 
especially no xorg package yet. Right now we have no unique "freetype 
that is part of XFree86". We are forced to live with several different 
not really compatible freetype2 versions simultaneously, and this will 
remain so for a long time to come.

To recall the situation once more: We have
[]
Thanks a lot for your summary.
My personal option for a solution would be to
- first upgrade the current freetype2 package to 2.1.4. This is 
trivial to do. And to
- have an additional freetype219 package that installs everything 
(including all its library files) into %p/lib/freetype219.
Sounds good to me.
There remain unsolved problems which we will probably have to live 
with:
- Packages that don't care about freetype versions will get whatever 
is currently installed in /usr/X11R6, and they will build different 
debs for different X11s. Packages like qt3 should be encouraged to 
choose one of our versions.
- Often there will be two different freetype.6.dylibs loaded into 
memory at the same time, because X11's libfreetype will inevitably pop 
up in addition to ours.
This inevitability seems to be an issue for me. Specifically, in 
lilypond, I saw major breakage if I just linked with the default pango 
libraries because (it seemed) lilypond and pango were talking to 
different instances of freetype. I had to build a 219-dependent pango 
package. Is this the way to go forward?

Matthias

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: freetype2

[Matthias Neeracher]

On Feb 17, 2005, at 8:11 PM,  Michael 
<[EMAIL PROTECTED]>wrote:
Do you know what packages they are?  Yesterday after talking to you and
before the last message you sent me I wrote packages for
rfontconfig-2.2.99 and freetype2-2.1.9.  The freetype installs fine, 
and
I would like to test it with these packages that you heard of that 
don't
work right with the ladder version of freetype.
Mike,
I'm also highly interested in a newer freetype2 (and I have my own set 
of packages for this in my experimental tree :-)

Could we compare notes on this?
Thanks
Matthias

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Request for Comments: freetype2{-hinting,}{-shlibs,-dev,}-2.1.9 upgrade

[Matthias Neeracher]

Thanks a lot for your feedback!
On Feb 1, 2005, at 1:57 AM, Martin Costabel wrote:
Matthias Neeracher wrote:
[]
Unless I hear objections from the maintainers (I believe Alexander 
agrees with the 2.1.9 packages, but I have not been able to get ahold 
of Jeffrey) or other interested parties by next Friday, February 4, I 
plan to commit the updated packages next weekend.
As you know, I am all in favor of upgrading to a newer freetype2 
version, but there are a few things that have to be discussed and 
decided first.
Hmm,  looks like this upgrade is far from ready to go.
Most of them were already discussed here but not yet definitively 
solved AFAICT.

1. There are still packages that will not build with newer freetype 
versions because of name changes (e.g. "FTC_Image_Cache" in some 
versions, "FTC_ImageCache" in others) and maybe other 
incompatibilities. Mozilla still seems to be in this class. I don't 
know what to do about this (but see point 3 below).

2. Many configure scripts and other code will break with freetype 
versions above 2.1.6 because of the gratuitous breakage code 
introduced at the beginning of freetype.h. We discussed this already, 
and my suggestion remains to patch the freetype2 package by taking out 
this breakage code.
The alternative, again, might be to allow multiple versions of freetype.
3. We could think about a possibility to have several versions of 
freetype2 installed simultaneously. This is non-trivial, because there 
is no official mechanism provided for this. All known freetype2 
dylibs, as incompatible as they are, have an install_name of 
freetype.6.dylib.

It is doable, though, since we already now have two versions of 
freetype2, one in /usr/X11R6 and one in /sw/lib. We could create 
/sw/lib/freetype219 and install everything there, but we would have to 
change the install_name which is now /sw/lib/libfreetype.6.dylib to 
/sw/lib/freeype219/lib/libfreetype.6.dylib. I didn't try it, but 
perhaps building freetype2 instead of --prefix=%p with 
--prefix=%p/lib/freetype%v would do the trick?
That sounds like a worthwhile approach, and I should give that a try. 
I'm not sure if freetype219 in the path is the right thing to do, in 
case later releases turn out to be binary compatible with 2.1.9

BTW, why did you include the extremely long ftobjs.c.orig file in your 
patch?
My bad. I must have used diff -ruN and this crept in.
Matthias

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Request for Comments: Pango* 1.6.0 upgrade and -ftdev variants.

[Matthias Neeracher]

Hi,
For my upcoming lilypond 2.5.x package, I need a pango that a) is newer 
than 1.4 and b) does not link against the system freetype2.
I have therefore a) upgraded the pango packages to 1.6 (I believe the 
latest version that does not require upgrading other gnome components) 
and b) added -ftdev variants that link against freetype2-dev instead of 
the system freetype2. The regular variants and the -ftdev variants are 
designed to coexist on the same system, and the latter should never 
appear in an include/link path unless explicitly requested.

The files are available in the fink experimental CVS tree in 
neeri/finkinfo as

pango1-dev.info
pango1-shlibs.info
pango1-xft2-ftdev.info
pango1-xft2-ftdev.patch
pango1-xft2.info
pango1-xft2.patch
Unless I hear objections from any interested parties by next Friday, 
February 4, I plan to commit the updated packages next weekend.

Matthias

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Request for Comments: freetype2{-hinting,}{-shlibs,-dev,}-2.1.9 upgrade

[Matthias Neeracher]

Hi,
For my upcoming lilypond 2.5.x package, I need a newer freetype2, so 
I've done a port of 2.1.9. The files are available in
 the fink experimental CVS tree in neeri/finkinfo as freetype2.info 
freetype2-hinting.info and freetype2.patch.

Note that:
- I've taken the liberty of merging the two patch files for maintenance 
reasons.
- The .infos probably can't be merged because they are governed by 
different licenses.

Unless I hear objections from the maintainers (I believe Alexander 
agrees with the 2.1.9 packages, but I have not been able to get ahold 
of Jeffrey) or other interested parties by next Friday, February 4, I 
plan to commit the updated packages next weekend.

Matthias

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Updating freetype2

[Matthias Neeracher]

On Jan 8, 2005, at 9:39 AM, Martin Costabel wrote:
I have been using the freetype2-2.1.9-1 package from neeri's exp dir 
for quite some time without problems. For all my purposes it was 
backward compatible with 2.1.3 (i.e. things compiled with the old 
library continue to run with the new one, and everything builds 
against the new version without problem).
Thanks for the endorsement!
Is there any objection against upgrading the freetype2 package to this 
version?
There are two issues that I know of:
- The handling of the pkgconfig files (which were new in 2.1.9) was not 
quite correct yet in the version in my experimental CVS. I've just 
updated that to 2.1.9-2
- I didn't do the corresponding -hinting packages yet, although I 
suppose that should not be all that hard.

I'll try to get a freetype2-hinting in my experimental dir by tomorrow, 
so if Jeffrey agrees, we might be able to release an upgrade sometimes 
next week.

Matthias

---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ec-fonts-mftraced dependency

[Matthias Neeracher]

From: [EMAIL PROTECTED] (Julien Salort)

Shouldn't the ec-fonts-mftraced package depend on system-tetex ?
Yes, you're right, it should depend on tetex-base | system-tetex.
Therefore, I think that system-tetex should be installed *before*
ec-fonts-mftraced, which can be achieved by making ec-fonts-mftraced
depend on system-tetex. (or tetex-base).
Correct. I'll fix that ASAP.
Martin Costabel <[EMAIL PROTECTED]> wrote:
IMHO, if you are mixing Fink tex packages with system-tetex, you are
basically on your own. It is virtually impossible to keep all the many
possibilities organized in a compatible way.
So if I understand well, installing Fink's lilypond with GW's tetex is
not really supported ?
I would say that it IS supported, in the sense that if I'm alerted to 
problems, I will try to work toward a solution. lilypond with native 
tetex is supported in the sense that I'm running that configuration 
myself, so I can generally do my own alerting.

Matthias

---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Type:ruby field docs

[Matthias Neeracher]

Damien Pollet <[EMAIL PROTECTED]> wrote:
I submitted a package for the ruby bindings to some gnome2 libs:
https://sourceforge.net/tracker/index.php?
func=detail&aid=963608&group_id=17203&atid=414256
By looking at other packages and thanks to someone on IRC I could use
the Type: ruby field, but as this field is not documented (on the
website at least) I'm not sure if this is correct, though it seems to
work.
Yes, the lack of documentation is my fault, and I intend to eventually 
remedy it. I'd love to get some input as to what people would like to 
see documented (also, how people would like Type: ruby to work; I 
implemented the field based on limited experience with ruby and a 
limited number of ruby modules).

Matthias

---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] octave-forge-2004.02.12-2

[Matthias Neeracher]

On Mar 25, 2004, at 1:00 AM, Martin Costabel wrote:
Building octave-forge crashes for me because of a bad interaction with 
lilypond (maintainer CCed): Lilypond installs a texinfo.tex file that 
gets substituted for the real thing. This breaks texinfo which is used 
for building octave-forge. I had to move 
/sw/share/texmf-local/tex/lilypond/texinfo.tex out of the way before I 
could build octave-forge:
Tsk. I'm sorry, this should be fixed within a day or two.

Matthias



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Updating clisp fails.

[Matthias Neeracher]

From: Andrea Riciputi <[EMAIL PROTECTED]>
Date: Mon, 22 Mar 2004 14:58:34 +0100
Subject: [Fink-devel] Updating c-lisp fails.
I was updating running update-all, but clisp update has failed. I
attach a log file, and I'll also fill a bug form. Hope it can help.
[...]
;; Loading file type.lisp ...
[stream.d:4034]
*** - UNIX error 2 (ENOENT): No such file or directory
Bye.
fink rebuild libiconv

fixes this problem. I just wish I understood why :-(

Matthias



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: gnubg-0.12-22

[Matthias Neeracher]

On Mar 15, 2004, at 5:31 PM, Ross Nelson wrote:

I just installed fink for the first time and I just tried a binary 
install of gnubg to see if fink was working, and though it seems to be 
in other respects, I got the following error when trying to run.

dsl027-179-184:~ ross$ gnubg
dyld: gnubg can't open library: /sw/lib/libdl.0.dylib  (No such file 
or directory, errno = 2)
Trace/BPT trap

I don't see a libdl package in fink, so I'm not sure what to do next.
That would be dlcompat. gnubg should build against the system libdl.

fink-devel, is there something wrong with our binary build system, or 
should I put in a Conflicts: dlcompat?

Matthias





---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: disabling /usr/local/include

[Matthias Neeracher]

I can see some value in disabling /usr/local/include (shouldn't we also 
disable /usr/local/lib ?), but I think putting %p/include and %p/lib at 
the end of our search paths rather than the beginning is going to cause 
us trouble: Wouldn't we be putting ourselves at the mercy of anything 
that Apple decides to ship in a new OS version? What benefit would we 
get from the different search order?

What if we make CPPFLAGS=-I%p/include -DLOCAL_INCLUDE_DIR=\%p/include ?

That way, %p/include would theoretically be searched twice, but in 
practice, the second time wouldn't actually matter, since any 
successful #include would already be done by then.

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: .app's in Fink

[Matthias Neeracher]

Benjamin Reed:
Darian Lanx:
except for the Frameworks dir. I don't see fink ever needing a
PrivateFrameworks dir though.

Right, no PrivateFrameworks, 

Mostly agreed. PrivateFrameworks is for non-public frameworks, and open source frameworks are pretty much public by definition.


but I still thing we should have 
/sw/Library just so it's clear that it's part of the Apple hierarchy.

Agreed.

I know Benjamin (RangerRick) has a 'solution' for issues with Ressource 
Forks that could arise when packaging the .app

1. Add a new field like JarFiles: BundleFiles

A package that makes an app bundle (or framework for that matter) would 
have:

Package: foo
BundleFiles: Foo.app Foo.framework

I'm not sure if it's really BUNDLES that we want to treat specially here, rather than just applications. I could see where a special treatment for apps would be useful but frameworks should be pretty straightforward. Besides, there are other types of bundles, each of which presumably would call for different treatment. I would suggest just marking applications and installing other bundles manually.

2. Foo.app and Foo.framework are installed to /sw/.Applications and 
/sw/Library/Frameworks respectively.

I'm somewhat uncomfortable with .Applications, as that would make a potentially large directory invisible from the Finder. I agree that our objective here is to make the directory "invisible" so users don't mess with the contents, but I feel that this could be achieved through other naming means than making the directory invisible. How about /sw/lib/applications ? (I was going to suggest /sw/libexec/applications, but it turns out we don't have /sw/libexec). Fink users should be sufficiently trained not to mess with /sw/lib.

3. Before actually building the deb package, we run SplitForks on the 
destroot tree.

4. Fink adds calling FixupResourceForks to the PostInstall of all 
packages (preferably with a list of files, kind of like the prebinding 
stuff, so it's not too taxing on the system; it has to be done 
per-package in case another package depends on, say, the python 
framework to be able to build).

Interesting idea, but is it actually worth to support resource forks in MacOS X? I've never used any in my X apps, but then, I've never written a Carbon app on X either. My understanding was that nowadays, any app can be packaged without using resource forks.

Matthias

Re: [Fink-devel] Re: .app's in Fink

[Matthias Neeracher]

On Jan 30, 2004, at 5:49 PM, Kevin Horton wrote:

At 20:29 -0800 29/1/04, Matthias Neeracher wrote:
I just had a peek over there, and there are indeed a small number of 
packages that don't seem to be getting acted upon at all (The oldest 
of them seems to be xkbsw). The vast majority, however, did get 
comments and are mostly awaiting revisions by the original 
submitters. Also, in light of the fact that around 1000 packages 
submission HAVE already been incorporated from the tracker, 100 open 
packages don't seem an unreasonable number to me..
I am working on a web page which will be an alternate index of the 
package submissions.  This page will identify which packages are 
waiting for the submitter, and which ones are waiting for a fink 
developer.
That should be useful indeed, e.g. to Max who makes the rounds 
regularly to keep packages moving.

- To the extent that packages are not getting addressed, it's not 
really because all available committers are busy wrapping .app's, 
it's because they don't know enough about the packages.
I don't understand why the fink developer needs to understand how an 
application works.  I would expect the fink developer to ensure that 
the package complies with the packaging policy, and compiles cleanly. 
After that it is up to fink users to tell the maintainer if the 
package does not work properly.
But

- That degrades the quality of the fink database (we don't vet packages 
by new maintainers to put them in their place, but because they might 
not yet know about all packaging subtleties (which we all forget 
sometimes) and because their work is of unknown quality).
- If the package doesn't work, at best it gets resubmitted, causing 
more work for the fink developer. At worst, the developer has to chase 
the maintainer to pester him/her for a fix.
- The question whether a package is "properly packaged" cannot always 
be cleanly separated from the question whether a package works, e.g., 
to know that a file belongs in %p/var not %p/lib, you have to run the 
program.

I recognize that the fink developers are volunteers, and they will 
work on whatever interests them.  But I do find it a bit frustrating 
that a package should not make it into fink just because there is no 
developer who finds it interesting enough to look at.  What about 
having a third tree, for untested packages.
What if a spammer commits a package there that turns machines into mail 
proxies?

  This would be for packages that have been submitted, but not yet 
reviewed by a fink developer.  Users would have to understand that 
there was absolutely no guarantee that a package from the untested 
tree wouldn't do nasty things to their fink distribution, or computer, 
etc.
That understanding would not stop them from blaming the fink 
developers, I fear.

Under what login did you submit packages and what packages of yours 
have gone unreviewed for an extended amount of time?
I submit under the login rv8.  I have had fplan-nox waiting since 
2003-12-24.  It is a flight planning tool to be used for pilots to 
plan flights.  See:
OK, that package has got itself a godfather now.

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: .app's in Fink

[Matthias Neeracher]

In article <[EMAIL PROTECTED]>,
 Kevin Horton <[EMAIL PROTECTED]> wrote:
> At 18:51 -0800 26/1/04, Matthias Neeracher wrote:
> >Could you explain in what way NOT allowing .app bundle
> >packages enriches fink currently?
> >
> >If native KDE runs everything that KDE/X11 does and looks good, then
> >I see no inherent value in KDE/X11, but as long as people are
> >interested in the latter, the KDE/X11 package will find maintainers.
>
> Finding maintainers is only the first challenge.  The second
> challenge is getting someone to look at the package after it has been
> submitter to the package tracker.  There are already 110 packages
> that have been submitted and are waiting for fink developers to
> review.  Some of them have been there since May 2003 and have yet to
> even get a comment from a developer.
I just had a peek over there, and there are indeed a small number of 
packages that don't seem to be getting acted upon at all (The oldest of 
them seems to be xkbsw). The vast majority, however, did get comments 
and are mostly awaiting revisions by the original submitters. Also, in 
light of the fact that around 1000 packages submission HAVE already 
been incorporated from the tracker, 100 open packages don't seem an 
unreasonable number to me..

Furthermore, while I can understand the frustration of package 
submitters without CVS access, I don't think this issue is really 
related to whether we should be packaging .apps:

- CVS access for package commits is not a bottleneck, i.e. there are no 
exponentially growing communication problems between package 
committers, so we can always promote more people to have commit rights.
- To the extent that packages are not getting addressed, it's not 
really because all available committers are busy wrapping .app's, it's 
because they don't know enough about the packages. I can only speak for 
myself, but my criteria for looking at a submitted package include that 
I have a sufficiently good idea what it's supposed to do that I'd know 
after installing it whether it works correctly. Most packages currently 
on the tracker don't fit this criterion. This problem is compounded by 
some of the submissions not being very descriptive: It would be very 
helpful if titles included a hint what the package does, rather than 
just the title.

> Clearly there are more packages being submitted than there are
> resources interested in reviewing them.  This effectively means that
> the people who are reviewing and approving the packages have to make
> some priority decisions on which packages they should work on.
I don't really think so. Obviously, this is for the people who actually 
commit lots of tracker packages to comment on, not me, but I think the 
problem is more lack of interest in the packages being submitted than 
lack of time to look at the packages.

>  Or perhaps the right answer is to simply say that the Fink team
> cannot attempt to package every possible application, and that
> resources will be focused on those packages that are seen as more
> important.
Fink is an open source project. To the extent that resources are 
"focused", it's on packages that are interesting to somebody, not on 
packages that fit with our 50 year strategic vision. The great thing 
about fink is that it includes an enormous variety of very specialized 
packages. The drawback of that is that some packages are so specialized 
that none of the current committers can really relate to them.

> Then people like me could stop submitting minor packages
> that may never get reviewed and simply post the .info files on a web
> page for people to download themselves.
Under what login did you submit packages and what packages of yours 
have gone unreviewed for an extended amount of time?

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: .app's in Fink

[Matthias Neeracher]

From: Darian Lanx <[EMAIL PROTECTED]>

Martin Costabel wrote:

D. H=F6hn wrote:

I do not quite understand why. Please do not misunderstand me, I am 
not
completely opposed, I just do not get why. We are good at something,
which is packaging Unix based applications.
The underlying technology is suitable for packaging pretty much 
anything that is built from source code. Obviously, we should restrict 
ourselves to only (publicly) packaging packages that build from 
REDISTRIBUTABLE source code, but it's not clear to me that it makes 
sense to restrict ourselves to packages that display their graphics 
through X11 rather than Aqua. Note that we don't have similar taboos 
against using any other frameworks – cdrtools uses the DiscRecording 
framework, which is about as MacOS X specific as it gets, and many 
packages are using CoreFoundation or even Cocoa/Carbon.

There is a saying in german "Schuster bleib bei deinen Leisten" which
means as much as "Stick to what you are good at". I would suggest, 
tha=
t
we leave the .app handling to others and concentrate on improving 
fink


To "others" like Ben Reed or what? Nobody is forced to make app 
bundles=
out of their fink packages. But there are app bundles that would 
greatly
enrich fink if they were available as fink packages

Why? Why would that enrich Fink? In what way?
Aqua based OpenOffice apps, for instance, or .app bundles for SDL based 
apps. Could you explain in what way NOT allowing .app bundle packages 
enriches fink currently?

itself as well as its packages. I really do not mind downloading 
KDE/QTMac from somewhere else. Rather than having calssic KDE/QT 
plus KDE/QTMac in Fink.
My primary reason for starting to use fink was that I did not want to 
figure out how to install (pre-Apple) xfree86 and TeX/Metafont. Each 
package we add (as long as it does not corrupt our core vision, which 
is what we're discussing here) will attract further users.

But I do mind. Why should I start reading web pages with long lists 
of instructions on what to download from where and to install first 
in /opt and /usr/local and then download something else and start 
compiling with
autoconf and glibtoolize and whatever and then install in 
/Applications
Precisely! This is what fink is all about.

Would it not be the main purpose of an app to be bundled with a neat 
Installer? Or am I missing the point here?
What if the user wants to build from source?

when I could just say "fink install koffice-aqua" and let fink do its
magic? Not to mention subsequent "update-all" or "remove" commands 
that
you don't get from somewhere else.

What happens to the maitainer precedence then? Will the "native" app
always be preffered?
That's really up to the maintainer (and nobody says that the X11 and 
the .app packages need to be maintained by the same maintainer).

Speaking for myself, I could imagine Trackballs migrating to an .app 
package and the X11 version disappearing, while nethack almost 
certainly would stay X11 based :-)

Why would anyone want to use KDE/X11 when they can have native KDE?
I don't think we need to pick favorites among Open Source packages 
(that kind of thing is best left to GNU-Darwin :-)
If native KDE runs everything that KDE/X11 does and looks good, then I 
see no inherent value in KDE/X11, but as long as people are interested 
in the latter, the KDE/X11 package will find maintainers.

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] CFD: Installing Frameworks from fink packages

[Matthias Neeracher]

Hi all,

I'm thinking of creating a fink package for RubyCocoa 
(), a cocoa wrapper package for ruby, 
similar to what CamelBones does for Perl. It seems an appropriate 
subject for packaging to me because it:

- Will depend on another fink package (ruby18) and no non-fink packages.
- Installs material that will stay in place at a fixed position (unlike 
MacOS applications).

However, the package installs a framework, for which I think we don't 
currently have a precedent. So my questions are:

- Do y'all agree that frameworks are, in principle, fink packageable 
matter?
- Where should frameworks be installed? /sw/lib/Frameworks ? 
/sw/lib/frameworks ? /sw/Frameworks? /sw/frameworks? /sw/lib/sw?

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Ruby support in Fink (Was: fink/perlmod/Fink PkgVersion.pm,1.211,1.212)

[Matthias Neeracher]

From: Daniel Macks <[EMAIL PROTECTED]>

===
RCS file: /cvsroot/fink/fink/perlmod/Fink/PkgVersion.pm,v
diff -u -d -r1.211 -r1.212
@@ -1595,10 +1600,15 @@
	 } elsif (!exists $self->{parent} and $self->param("_type") eq 
"perl") {
		 # grab perl version, if present
			my ($perldirectory, $perlarchdir) = $self->get_perl_dir_arch();

 			$install_script .=
 "make install PREFIX=\%i 
INSTALLPRIVLIB=\%i/lib/perl5$perldirectory 
INSTALLARCHLIB=\%i/lib/perl5$perldirectory/$perlarchdir 
INSTALLSITELIB=\%i/lib/perl5$perldirectory 
INSTALLSITEARCH=\%i/lib/perl5$perldirectory/$perlarchdir 
INSTALLMAN1DIR=\%i/share/man/man1 INSTALLMAN3DIR=\%i/share/man/man3 
INSTALLSITEMAN1DIR=\%i/share/man/man1 
INSTALLSITEMAN3DIR=\%i/share/man/man3 INSTALLBIN=\%i/bin 
INSTALLSITEBIN=\%i/bin INSTALLSCRIPT=\%i/bin\n";
+		} elsif ($self->param("_type") eq "ruby") {
+			# grab ruby version, if present
+			my ($rubydirectory, $rubyarchdir) = $self->get_ruby_dir_arch();
+
+			$install_script .= "make install prefix=\%i\n";
 		} elsif (not $do_splitoff) {
 			$install_script .= "make install prefix=\%i\n";
 		}
What is the effect of get_ruby_dir_arch() here (i.e., why are you
handling type:ruby separately)? But more importantly, it appears you
are having the default action to be "make install" even in a SplitOff
of a type:ruby package. That seems bad.
You're absolutely right. I think I introduced that code because I 
initially expected having to add lots of variable overrides like the 
Perl version does, and because everything worked, I never revisited 
that assumption.

I'll fix this ASAP (although I don't expect to see splitoffs from ruby 
packages anytime soon :-)

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/libs/rubymods imlib2-rb.info,NONE,1.1 imlib2-rb18.info,NONE,1.1 opengl-rb.info,NONE,1.1 opengl-rb18.info,NONE,1.1 opengl-rb18.patch,NONE,1.1

[Matthias Neeracher]

Am 15.01.2004 um 12:34 schrieb Daniel Macks:

> Matthias Neeracher <[EMAIL PROTECTED]> said:
>> Update of
>> /cvsroot/fink/dists/10.3/unstable/main/finkinfo/libs/rubymods
>> Added Files:
>>imlib2-rb.info imlib2-rb18.info opengl-rb.info
>>opengl-rb18.info opengl-rb18.patch
>> Log Message:
>> Committing inaugural ruby modules
>
> Yay! I'll move the extant term-ansicolor-rb there:)
And I would like to add that I never saw a discussion, or at least a
formal announcement for this new CVS dir on fink-devel.
I apologize. I did informally poll a couple of the fink developers on 
#fink yesterday, and I think (although I'm not 100% sure) that I even 
discussed the idea with you a few weeks ago. The only objection I heard 
was that some developers questioned whether there would ever be enough 
ruby modules to warrant a separate directory. My reasoning was:

- I am planning to port a substantial number of additional ruby modules 
in the near future.
- ruby modules, like perl modules, tend to have names which are very 
similar to the package they are interfacing to (imlib2-rb vs. imlib2), 
so
  having them in a separate directory would make it easier to tell them 
apart.

As Ben said, I was planning to ask you first, but when it appeared 
around bedtime yesterday that you were not going to be around, I 
decided to go ahead & ask for forgiveness instead of permission.

It does, the "Type" value is new. Hence the package must build depend
on the first fink version to support this feature. Which in this case
is a not release version of fink... strictly spoken this package
shouldn't even be in CVS at this point, but rather should've been
delayed till at least some version of fink with ruby support got
released But done is done, so at least add the BuildDepends field,
please.
Thanks! What version should I use in BuildDepends?

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: dists/10.3/unstable/main/finkinfo/libs/rubymods imlib2-rb.info,NONE,1.1 imlib2-rb18.info,NONE,1.1 opengl-rb.info,NONE,1.1 opengl-rb18.info,NONE,1.1 opengl-rb18.patch,NONE,1.1

[Matthias Neeracher]

In article <[EMAIL PROTECTED]>,
 Daniel Macks <[EMAIL PROTECTED]> wrote:
> Does this rely on any of the magic you just added to Fink::PkgVersion?
Yes, it does. The compile and install scripts are automagicked.

> More importantly, this sounds like it gets installed into a versioned
> part of lib/ruby (maybe lib/ruby/site_ruby/1.8?). If so...
>
> > --- NEW FILE: imlib2-rb.info ---
> > Package: imlib2-rb
> > Depends: imlib2-rb18
> > Type: bundle
> > Description: Placeholder for versioned opengl packages
>
> Uh oh. What is the situation in which one would need this bundle
> package, and how is this not taking us into the same hell that is perl
> versioned modules?
I was operating under the assumption that the perl version hell, 
unpleasant as it may be, was ultimately the only currently working 
paradigm to deal with multiple versions. If you have a better proposal 
(that works without changing fink itself), I'm eager to hear it.

Matthias



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Heureka! (Was: Fink-0.18.0 doesn't compile)

[Matthias Neeracher]

From: Matthias Neeracher <[EMAIL PROTECTED]>

I was also having problems with one of my machines yesterday (I didn't
report them yet because I wanted to do some investigation myself).
Maybe fink 0.18.0 doesn't work on machines whose owners are named
"Matthias".
Upon closer examination, it turned out that I had disabled Permissions 
on the Volume that fink was on. Apparently, that used tow ork for 
earlier versions of fink, but no longer for 0.18.0

Maybe the test could issue a clearer warning for this case?

Matthias



---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Fink-0.18.0 doesn't compile

[Matthias Neeracher]

From: "Alexander K. Hansen" <[EMAIL PROTECTED]>

No, it's expected that Fink will try to update itself when you run
"fink selfupdate".  What's your error message?
On Jan 9, 2004, at 9:58 AM, Matthias Ringwald wrote:
in order to try an unstable package, I entered fink selfupate which
after downloading the new packages
failed to install. I can not install any packages right now, because
fink first try to compile itself
version 0.18.0
I was also having problems with one of my machines yesterday (I didn't 
report them yet because I wanted to do some investigation myself). 
Maybe fink 0.18.0 doesn't work on machines whose owners are named 
"Matthias".

The problem was that during the test phase, two tests had problems: 
chowname.t failed some tests, and, I think, failure.t failed some 
tests. I did some tracking of the chowname test and found it somewhat 
irritating that an uid of -2 came out as an unsigned int instead. Could 
we dealing with a perl bug in some versions?

Matthias



---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: libgnugetopt

[Matthias Neeracher]

On Jan 1, 2004, at 2:06 PM, Ben Hines wrote:

libgnugetopt dependencirs are never needed on 10.3... the missing 
getopt functions were added to libsystem. Just remove all  gnugetopt 
deps completely! It will work fine.
Thanks for the reminder! nethack is now libgnugetopt free.

However, upon further examination, it seems I still need libgnugetopt 
for my open-cobol package because that calls getopt_long_only, for 
which there doesn't seem to be a libSystem equivalent.

Matthias



---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: Ruby test failed

[Matthias Neeracher]

On Dec 23, 2003, at 11:35 AM, jfm wrote:
On Dec 23, 2003, at 8:19 PM, jfm wrote:

This looks like you're running the test without having installed the 
ruby-support patch itself,
I just ran  inject.pl  ...
But I see the cvs update command had the '-f' option (together with  
-r "HEAD").
Oops! I'm so sorry, now I realize I checked in the test in HEAD instead 
of my branch (I had created the branch but not switched to it). I will 
back that out immediately and apologize for the inconvenience.

Matthias



---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Ruby test failed

[Matthias Neeracher]

On Dec 23, 2003, at 4:13 AM, jfm wrote:
The following test failed :

./PkgVersion/get_rubyok 2/0Can't locate object method 
"get_ruby_dir_arch" via package "Fink::PkgVersion" at 
./PkgVersion/get_ruby.t line 25.
# Looks like your test died just after 2.
./PkgVersion/get_rubydubious
Test returned status 255 (wstat 65280, 0xff00)
after all the subtests completed successfully
Interesting, and thank you so much for testing this!

This looks like you're running the test without having installed the 
ruby-support patch itself, which applies to the perlmods 
(Fink::PkgVersion, to be more specific). I was too cheap to tag the 
entire repository, so I just tagged these two directories.

Thanks for your feedback
Matthias


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Idea: "LangVersion" field in .info

[Matthias Neeracher]

From: Daniel Macks <[EMAIL PROTECTED]>

We've got a lot of packages that are the same module for different
versions of a language (-pm*, -py*, etc.). Often, the only difference
between these .info files is in the %n and some Depends and pathnames
in *Scripts, and these are either the language version or a condensed
form of it. What do people think about adding a new LangVersion field
that is a single place to define it, and then have two new percent
expansions to insert it as given and condensed?
Absolutely!

I know we recently added "Type: perl $version", so this expansion
could be used in that field value as well. Or else instead of adding a
LangVersion field, just pull the version out of Type: (and extend
Type: to accept python).
I like pulling it out of the type better, but both variants look like 
improvements over what we have
now.

While we're at it, could we also extend Type to accept Ruby?

Matthias



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Fwd: la files openldap and dbs

[Matthias Neeracher]

TheSin is having problems posting to the list, so I'm forwarding this for him. Please reply to him directly

Begin forwarded message:

From: TheSin <[EMAIL PROTECTED]>
Date: Tue, 05 Aug 2003 15:17:54 -0600
Subject: la files openldap and dbs

libldap.la has this in it

# Libraries that this one depends upon.
dependency_libs=' /sw/lib/liblber.la /sw/lib/libsasl2.la -lresolv -L/sw/lib -lssl -lcrypto -ldl -lkrb5 /sw/lib/libdb-4.1.la'

and since libdb-4.1.la is in db41 or db41-ssl that means anything that NEEDDS db3 (ie my upcoming php4 pkg) can't have both db3 and ldap support in it or the la file will be missing even though to dylib is in fact there.

Anyone have any suggestions?

Re: [Fink-devel] Re: fink mirror patch

[Matthias Neeracher]

On Tuesday, March 4, 2003, at 06:51 PM, Ben Hines wrote:

On Tuesday, March 4, 2003, at 06:39  PM, Matthias Neeracher wrote:

On Tuesday, March 4, 2003, at 05:51 PM, Ben Hines wrote:
On Tuesday, March 4, 2003, at 03:48  PM, Matthias Neeracher wrote:
- Some packages are just too large and obscure. For instance, if I 
were to do a 5 piece endgame tablebase package for crafty (which
  I haven't done yet), we're talking 6G of disk space, and even the 
partial 6 piece tablebases are more than that. These packages
  are not frivolous at all, but only a handful of people are going 
to be interested.
The source tarball is 6 gigs??
Yes. The "source" in this case represents a product of months of 
computation which would be entirely infeasible to do on the client 
side.
So, why is there a fink package for such a thing, if i may ask? Do 
other packaging systems have one?
As I wrote above, I haven't done 5 and 6 piece databases yet. If you're 
a chess aficionado and have a few gigs to spare, these databases are 
very valuable as they let you study endgame positions with perfect 
knowledge (they also boost the strength of the chess program massively, 
as they allow perfect evaluation of leaf nodes at a much earlier point 
in the game). Setting them up manually is not horribly difficult, but 
having a package is much more convenient (An analogous package that is 
quite large and has relatively simple installation instructions is 
tetex-texmf).

Matthias



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Re: fink mirror patch

[Matthias Neeracher]

On Tuesday, March 4, 2003, at 05:51 PM, Ben Hines wrote:
On Tuesday, March 4, 2003, at 03:48  PM, Matthias Neeracher wrote:
- Some packages are just too large and obscure. For instance, if I 
were to do a 5 piece endgame tablebase package for crafty (which
  I haven't done yet), we're talking 6G of disk space, and even the 
partial 6 piece tablebases are more than that. These packages
  are not frivolous at all, but only a handful of people are going to 
be interested.
The source tarball is 6 gigs??
Yes. The "source" in this case represents a product of months of 
computation which would be entirely infeasible to do on the client side.

Matthias



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: fink mirror patch

[Matthias Neeracher]

Alexander Strange <[EMAIL PROTECTED]> wrote:
On Tuesday, March 4, 2003, at 06:48  PM, Matthias Neeracher wrote:
- Some packages are just too large and obscure. For instance, if I
were to do a 5 piece endgame tablebase package for crafty (which
  I haven't done yet), we're talking 6G of disk space, and even the
partial 6 piece tablebases are more than that. These packages
  are not frivolous at all, but only a handful of people are going to
be interested.
Then maybe crafty should get better compression? :)
Actually, these files ARE in a highly optimized format. They represent 
billions and billions of chess endgame positions (All chess positions 
with 5 pieces left on the board) to allow crafty to play these 
positions perfectly.

Matthias



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: fink mirror patch

[Matthias Neeracher]

Ben Hines <[EMAIL PROTECTED]> wrote:
I am currently testing my fink mirror patch. It adds a "fink" mirror
that is intended to hold a mirror of every source tarball, so there
will no longer be any breaking URLs.
Sounds like a great idea in general. However, there probably should be 
mechanisms to exclude some packages:

- Some packages are just too large and obscure. For instance, if I were 
to do a 5 piece endgame tablebase package for crafty (which
  I haven't done yet), we're talking 6G of disk space, and even the 
partial 6 piece tablebases are more than that. These packages
  are not frivolous at all, but only a handful of people are going to 
be interested.
- Are we sure we have the right to mirror the source to any fink 
package, or could some of them be licensed under licenses that
  forbid mirroring?

As a further concern, the mirror should probably occasionally re-verify 
MD5-Sums and refetch if they no longer match.

Matthias



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Re: Packages not to be moved

[Matthias Neeracher]

> From: "David R. Morrison" <[EMAIL PROTECTED]>
>
> Ben Hines has made a nice list of packages which have not yet been 
> moved to
> 10.2.  Perhaps this is a good time for fink developers to make a list 
> packages
> which should *not* be moved.
>
> 1) manconf should not be moved (I believe this is the upshot of 
> previous
>discussions)
>
> 2) presumably, lilypond-unstable should not be moved (lilypond was 
> already
>moved, and has a higher version number)

Correct. -unstable tracks the odd subversions, while lilypond tracks 
the even subversions.
1.4 was not compatible with MacOS X, so I maintained -unstable 1.5 
releases for a while. I'm not sufficiently interested in lilypond to 
maintain the 1.7 series, but I've asked for volunteers.

Matthias



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Puzzling issue with CDPATH, traced further

[Matthias Neeracher]

On Tuesday, February 26, 2002, at 02:12 PM, Martin Costabel wrote:

> Matthias Neeracher wrote:
>> localhost% gnome-config --libs gnomeui
>> -L/sw/lib -L/usr/X11R6/lib -L.libs -lgnomeui -lart_lgpl -lgdk_imlib 
>> -lSM
>> -lICE -lgtk -lgdk -lgmodule -ldl -lintl -lXext -lX11 -lgnome
>> -lgnomesupport -lesd -laudiofile -lm -lglib
>>
>> The -L.libs doesn't really have any business being there, does it? How
>> did it get there?
>
> Was your gnome-libs built while esound was at version 0.2.23-1? There
> was a "SetLIBS: -L.libs" for some reason or other which caused the
> "library=`'" bug for me when rebuilding sawfish.

Aha! That was indeed the reason for all of this.

>  It was removed on
> 2002/02/22 in version 0.2.23-2. When gnome-libs is compiling the library
> lists for gnome-config, it might be using esd-config (I am guessing,
> have not yet checked this).

Yes it is. In gnome-libs configure:

LIBGNOME_LIBS="$ESD_LIBS $AUDIOFILE_LIBS $DB_LIB $GLIB_LIBS $DL_LIB"

and ESD_LIBS is obtained from esd-config.

I'd never have guessed that. Amazing at what remote distance effects 
that SetLIBS had.

Matthias


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Puzzling issue with CDPATH, traced further

[Matthias Neeracher]

Tracing this incident further back, I noticed that the assignment to 
absdir is not exercised in most executions of libtool. The reason it was 
exercised on my machine is that my gnome-config there seems to differ 
from that on the other machine I use (which works fine):

localhost% gnome-config --libs gnomeui
-L/sw/lib -L/usr/X11R6/lib -L.libs -lgnomeui -lart_lgpl -lgdk_imlib -lSM 
-lICE -lgtk -lgdk -lgmodule -ldl -lintl -lXext -lX11 -lgnome 
-lgnomesupport -lesd -laudiofile -lm -lglib

The -L.libs doesn't really have any business being there, does it? How 
did it get there?

I'd appreciate any hunches or tips how this gets set, will trace this 
further.

Matthias


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf

[Matthias Neeracher]

On Sunday, February 24, 2002, at 04:28 PM, David R. Morrison wrote:

> I have separate binaries for /bin/sh and /bin/zsh, although they are
> identical in size (449616) and date (Dec 31).  Presumably they were
> installed by the 10.1.3 upgrade.

Sizes are the same here. I'm running 10.1.2

Matthias


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Puzzling issue with CDPATH / libtool / gdk-pixbuf

[Matthias Neeracher]

Trying to update my unstable packages at home, I run into problems with 
gdk-pixbuf-shlibs-0.16.0-2 and gdk-pixbuf-0.16.0-3. Both of these 
packages complained about not being able to find library `' (Yes, that's 
an empty string).
I traced the build and found the following:

  - libtool is run by /bin/sh which on MacOS X is a link to zsh (3.0.8 on 
my machine).
  - libtool sets CDPATH to :, because in zsh, apparently CDPATH is 
considered "set" although it doesn't show up in printenv.
- This setting, which is supposed to SUPPRESS printing the destination 
directory for cd with relative pathnames, actually FORCES printing the 
destination with zsh.
- Therefore, the line
absdir=`cd "$dir" && pwd`
  sets absdir to contain TWO copies of the directory path, not one.

This eventually produces the error I saw.

It was not very difficult to get the packages to build by simply putting 
in a line

perl -i -ne 'print unless /CDPATH/' libtool ltconfig ltmain.sh

after running configure. But I'm still puzzled. The libtool looks 
exactly like all the other libtools in other fink
packages. Why does this problem not occur with other packages? And why, 
for that matter, has notbody else apparently had problems with 
gdk-pixbuf?

Matthias


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel