Darian Lanx <[EMAIL PROTECTED]> wrote:
> any specific reason why this is all upper case ?
No.
-- Dave
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic
Blair,
Chris Zubrzycki, a.k.a. beren12, is not available online these days. (He will
hopefully return after some months.) Please feel free to update his packages.
-- Dave
---
This SF.Net email sponsored by Black Hat Briefings & Training.
A
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Horton wrote:
| I'm communicating with a fink user on the MaxOSXHints forum:
|
| http://forums.macosxhints.com/showthread.php?p=133778
|
| He can't install epiphany. It seems that epiphany depends on
| xml-parser-pm, yet that pm was removed
Dear Fink developers,
Peter O'Gorman and I attended WWDC, and have experimented with Fink on the
WWDC preview distributed there. Although we cannot comment on any
specifics, it appears that the impact of the transition to 10.4 on Fink
will be less severe than the previous transitions. It is, how
> I have just added xml-parser-pm581 | xml-parser-pm580 | xml-parser-pm560
No, that's wrong.
You have to choose one and stick with it. For the 10.3 tree, it should
be xml-parser-pm581 (and in the 10.2-gcc3.3 tree, use xml-parser-pm560).
The other option is to create variants: epiphany-perl560,
That is correct, xml-parser-pm was removed, along with all the other
"placeholder" packages. They were a nice idea, but they were causing
more problems with dependencies than they solved (basically, from
people satisfying the dependency by a -pm560 when they only had
perl 5.8.1 installed, and the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Corey Halpin wrote:
|
|
| There seem to be only three packages (aside from mine) that depend on
| any of these things (msmtp, xmlsec, and gsasl). I'll contact their
| maintainers to notify them of this change.
|
All three are my packages :)
How
Upon further reflection, I think Dan's objection is very well taken.
I'm going to rename local/bootstrap to local/injected, since this is
the tree where info files will be put that are created by ./inject.pl
scripts. Most users will never see this tree, but it will be created
when it is needed.
Here's what I had in mind:
The files in question are going to be fink.info, fink-mirrors.info, and
the like.
If foo.info is already present, but foo.info.bak is absent, then foo.info
will be moved to foo.info.bak and a new foo.info will be created. The
user will be told that this has happened.
Hi folks. I'm contemplating doing away with the local/bootstrap tree.
Currently, it is used during bootstrap, and it is also used if you run
the ./inject.pl script for one of the fink-managed packages (fink,
base-files, fink-mirrors, fink-prebinding).
I've concluded, though, that it is not neces
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Blair Zajac wrote:
| I have the jove.info package which is a tiny version of Emacs, which I
| like because it starts up fast.
|
| It has a global directory /var/tmp/jove where it dumps recover and
| temporary files, unlike vi's .swp files which are
Remi,
The case as you state it seems clear to me. I'm removing the package.
(As you have undoubtedly discovered yourself, the maintainer's email
does not function.)
-- Dave
---
This SF.Net email sponsored by Black Hat Briefings & Training.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Remi Mommsen wrote:
| Hi,
|
| Long time ago (9/5/03) I notified the maintainer (cc'd) that I believe
| that this package cannot be distributed by fink (at least not under
| GPL). Seeing the cvs commit message, I'm surprised that it is still
| there
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
| Has anyone else noticed that the master rsync mirror doesn't respond any
| more and that - apart from two Japanese URLs - the other rsync mirrors
| don't seem to synchronize currently?
|
| I ran a little check over the rsyn
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Min Xu wrote:
| Hi,
|
| I recently found my newly installed fink was crashing because I have
installed
| some old version of libfreetype in /usr/local by iInstaller. This
| makes me wondering
| should fink restrict it is search path?
/usr/local is
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Daniel Macks wrote:
| I just patched fink in CVS HEAD to check MD5 checksum as each source
| tarball is downloaded and treat a mismatch as a download failure. For
| the end-user, that means if the download process succeeds but gets the
| incorrect
The -ssl variants are something of a problem at the moment.
I agree that it would be extremely sensible to have the -ssl treated the
same as other variants. But at present, we isolate cryptographic-enabled
packages from the others by putting them in their own tree, so that folks
who are respectin
Hmmm... On second thought, maybe it wouldn't be so hard to modify what
happens when we check something in, so that the commit message is mailed
directly to the maintainer as well as to fink-commits (automatically).
Would that help?
-- Dave
---
Dave,
I have alternate suggestions for both situations you mention.
First, there is a big project by some of us to rescue the remaining 300-400
packages which never moved from 10.2 to 10.3. Ben Hines set up this nice
comparison chart at
http://fink.sourceforge.net/pdb/compare.php
which all fin
The package "hx" in section "net" is Restrictive, the source URL no longer
functions, and the homepage URL no longer exists. Moreover the maintainer
says (on fink-beginners) that he is no longer maintaining it.
Should we remove it from fink altogether?
-- Dave
---
On Thu, Jun 24, 2004 at 12:18:51AM +0200, jfm wrote:
> More accurately probably,
> #! `which perl`
#! /usr/bin/env perl
which will actually work. There are a lot of strange restrictions on
that line.
Dave Brown
---
This SF.Net email sponsor
Sorry, I meant "add or remove a perl package" not "add or remove a fink
package"...
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top techn
> you end up with a
> *real* perl581, but a *virtual* perl581-core, and get this error.
Well, that can't be the right explanation, because there isn't a "real"
perl581 package at all.
-- Dave
---
This SF.Net email sponsored by Black Hat Brie
Jean-Francois,
I'm not sure if it's the same error you are seeing, but one bug I am aware
of is this: there is a place in the fink code where fink tests to see
which is the current version of perl installed on the system... unfortnately,
fink seems to cache this value in the database. So if you
s looking at, so this sort of brings things full
> circle. Martin has been very helpful to me over the past year in
> troubleshooting various Fink install issues, especially Scribus (which
> I'm now using in a production setting in my day job as a book publisher).
>
> I'
I appreciate the feedback. I wonder whether you had a chance to look at
one other resource linked from the Documentation page: the slides from
a talk I gave "Using Fink: A Developer's How-To" at the 2002 O'Reilly
OS X conference. During the talk itself, I took people through the
creation of a si
Chris,
We don't really have a policy about how to handle this issue.
We generally ask that if people are going to stop maintaining things, they
go through and mark their packages as "Maintainer: None". This has
happened a few times, and it was greatly appreciated. But there are a
number of oth
Koen van der Drift <[EMAIL PROTECTED]> wrote:
> On Jun 21, 2004, at 4:35 PM, David R. Morrison wrote:
>
> > There are some packages containing header files for which it's not
> > appropriate to declare BuildDependsOnly to be true. In that case,
&
Daniel Macks <[EMAIL PROTECTED]> wrote:
> It does seem like we need a tri-state thing here. It feels funny to
> overload a boolean to accomplish that, but I can't think of a cleaner
> way, and this allows us to easily find these special-case packages and
> do .deb validation.
>
> The .info could
I've modified the proposed policy in response to today's feedback (and
after a bit of coding for the forthcoming fink 0.20.5). Further discussion
and feedback are most welcome.
-- Dave
Second draft:
The BuildDependsOnly field
When libraries are being upgraded over time, it is often necessar
To summarize and implement the discussion of last week, I propose adding
the following policy statement to fink's packaging documentation (to
be added to the Shared Library Policy section). Discussion and feedback
are most welcome.
-- Dave
The BuildDependsOnly field
When libraries are being
> none issue, but I have no upload rights to our SF files section.
That step is easily solved: you just need to ask one of us to put the
file there.
But it does not really address the issue: why is the cvs project releasing
a security fix which doesn't pass this kind of security test? And if so,
a) Contact the CVS guys and tell them to fix this
Already done. CURL does not accept self signed SSL certs as it seems. I
contacted them a long time ago.
b) In the meantime, if you have a copy of the source which you
definitely know is safe, post that somewhere safe and change the source
URL of
One of my goals here is to have an automated way to verify that packages
are complying with the BuildDependsOnly policy. So I'm trying to find
ways of characterizing this which won't get into a lot of exceptions.
Right now (using CVS HEAD or CVS branch_0_20 of fink), the package fails
validation
Yes, g77 is in fact one of the ones I've tagged. Something like g77 can be
used in two ways, as I see it: it might be used "under the hood" by Fink,
in order to compile something else. Or it might be used by a working
scientist who is writing his own code and wants to compile it.
Now, in the la
As announced on Tuesday, I've started to enforce the new validation check
related to BuildDependsOnly. I've gotten some complaints about it, so
perhaps we need to discuss the situation.
As Dan Macks has pointed out to me, our shared libraries policy does not
explicitly require BuildDependsOnly fo
An update: SourceForge has now responded, and is fixing the problem.
-- Dave
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - Jul
P.S. A complete list of the packages which have been removed from fink as
part of my revision is at
/experimental/dmrrsn/perlmods/perl.obsolete
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at Ja
Daniel Macks <[EMAIL PROTECTED]> wrote:
> Modified Files:
> html-parser-pm581.info
> Log Message:
> Fixed Depends to a perl-versioned lib instead of placeholder.
>
>
> Index: html-parser-pm581.info
> ===
> RCS file:
> /cvsro
The Master Mirror is not an option for a brand new file like the new fink
release.
We had this same trouble last week when fink 0.20.3 was released. It was
reported to SourceForge. There has been no response to the report.
Once the Master Mirror picks the file up, it should be easy for users to
I'd like to update everyone on the BuildDependsOnly issue.
In fink 0.20.3, we implemented the writing of the BuildDependsOnly field
into the .deb file, and a new validation check which tests for the
presence of /sw/include in a .deb file, and expects to find BuildDependsOnly
to be true whenever /s
I'd like to update everyone on the BuildDependsOnly issue.
In fink 0.20.3, we implemented the writing of the BuildDependsOnly field
into the .deb file, and a new validation check which tests for the
presence of /sw/include in a .deb file, and expects to find BuildDependsOnly
to be true whenever /s
Hi. I had a look at this, and the underlying cause is the line
AM_LDFLAGS = -no-undefined -version-info 0:0:0 -export-dynamic
which appears in modules/Makefile.in (and also modules/Makefile.am). I kind
of understand what the developers are trying to do with this, but they
are going about it t
I guess another way to support that would be to supply a fink perl581 package
which a user could install if they had replaced their perl installation...
-- Dave
---
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to L
Ben:
In most cases, I believe, a 5.8.4 variant for perl modules should not
be necessary. This is because perl 5.8.4 will actually see -pm581's
as being available.
The cases in which we would need a 5.8.4 variant are cases which depend
on a -pm which is virtually provided by perl584-core. In tha
This is an early notification that I hope to start creating the binary
distribution 0.7.1 around two weeks from now. If there are packages of
yours which need to be moved to stable, or to have their stable versions
updated, please try to do that within the next two weeks.
Thanks,
Dave
P.S. I
I've noticed that several of the fink committers have been helping recently
with the package submission tracker, and I think that's great. (We've
been behind on processing submissions for a long time.)
I'd like to ask everyone to keep in mind the following: if there are people
who are putting thi
"Peter O'Gorman" <[EMAIL PROTECTED]> wrote:
> Which brings me to a question. I had assumed that bootstrap packages first
> get put in unstable/base, then when they are moved to stable they get added
> to bootstrap. Should bootstrap packages be added to bootstrap at the same
> time as unstable,
"Peter O'Gorman" <[EMAIL PROTECTED]> wrote:
Modified Files:
dpkg.info dpkg.patch
Log Message:
Dave, these seem to work a little better
[snip]
Thanks, Peter, this one does the trick.
My only suggestion is, that you should add "suppress warning about
BuildDependsOnly control field" to th
Daniel Macks <[EMAIL PROTECTED]> wrote:
> Debian Packaging Manual 5.7 "User-defined fields" (though as I read it
> is self-contradictory), suggests we could maybe pass the BDO flag in
> the control file? If so, that would certainly be a cleaner solution than:
>
> > For each package, at build time
It worked perfectly for me, adding the line which Daniel Macks suggested.
(You only want "Replaces", you do *not* want "Conflicts".)
Just to be clear, here is how the dependency section looked after I made
the change:
## Dependencies
##
BuildDepends: autoconf | autoconf2.5, pcre (>= 3.0-1), fink
Your fink selfupdate is set to take things from "point releases", which
are made every few months. If you want to change to a more rapidly
updating fink, run the command "fink selfupdate-rsync".
> You already have the package descriptions from the latest Fink point
> release.
> (installed:0.7.0
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Langhoff (NZL) wrote:
Is this within fink policy? What alternatives do I have in making this
module compliant?
No. You are not allowed to install _anything_ outside of /sw-
There is one exception which is some special case when handling A
AIDA Shinra <[EMAIL PROTECTED]> wrote:
> Let A a library depending on neon. If A-shlibs and A-dev has been built
> with neon23, A-dev and neon24 should not be installed at the same
> time. If both were installed, binary inconsistency happens:
>
> gcc -o B B.o -lA -lneon
>
> If B did not directly
> It would also make it straightforward
> to be able to rebuild a .deb later even if the original .info file has
> gone missing.
Well, almost. The problem is, you also need the correct version of the
.patch file to rebuild the .deb. And .patch files can get very large,
so I'm pretty sure we *don
The reason for the BuildDependsOnly flag is to make it possible to upgrade
a library in the future, if the upgrade is not binary-backwards-compatible.
An example is the "neon" package. Currently we are using neon24, but
in the recent past we used neon23 (and many earlier ones). If you have
neon2
Dear Fink developers,
For some time, I've wanted to have a way to validate that packages are
using the BuildDependsOnly field correctly. The test I want to employ
is this: if the package installs anything into /sw/include, it should
be declaring BuildDependsOnly to be true. (This doesn't guarant
> > but this principle has always been
> > more a pious wish than reality.
> Could you explain in more detail what you mean?
I think it's a pretty accurate comment. It has been stated goal of fink to
make sure that fink packages always compile the same everywhere, but we've
never had adequate QA
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
but this principle has always been
more a pious wish than reality.
Could you explain in more detail what you mean?
Thank you.
- -d
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFAtz1RPMoaMn4kKR4RAxHSAJ9
Martin,
I'm aware of this bug in fix-fink, and in fact it's on the bug tracker.
The reason I haven't fixed it is that there is no reason for anyone to be
running fix-find right now, and I'm afraid if I fix it and release a new
version that would cause lots of folks to try to run it.
-- Dave
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Randal L. Schwartz wrote:
"Peter" == Peter O'Gorman <[EMAIL PROTECTED]> writes:
Peter> Yeah, it was the top news item on fink's home page for a while. It is
Peter> still on the front page though.
Thanks... you mean I have to read the news? :) :)
Benjamin Reed <[EMAIL PROTECTED]> wrote:
> Sébastien Maret wrote:
> > I've written a fink package for the CFITSIO library, but I don't know
> > which licence type is appropriate (OSI-Approved ?) . From the licence file:
>
> OSI-Approved should be fine, the majority of it (the first part) is
> e
My apologies, I misinterpreted your message, Ben. You were suggesting that
the new variant style should be used for these packages. That's an excellent
idea, but my goal right now is to get all packages to conform to policy.
I'll leave it to maintainers (or later work by me) to move to the varian
Actually, there was a discussion, in which I proposed that we adopt a
new policy in which we explicitly choose to have variants whenever there
is a difference among the variants. We had the discussion twice: the
first time, when Dan Macks was just starting to implement the code which
will allow th
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Ben Hines wrote:
>The old style is extremely deprecated.
^^^
When did we decide on that? Since I was not reading the mailing lists
for a bit last wekk (was very busy), I might have overlooked the
discussion, but I
Dan,
You called this a "backport" but I cannot find this in HEAD... only in the
branch...
-- Dave
From: Daniel Macks <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: fink fink.8.in,1.18,1.18.16.1 fink.conf.5.in,1.12,1.12.2.1
ChangeLog,1.223.2.2,1.223.2.3
Date: Tue, 04 May 2004 04:50:43 +0
Martin,
This was fixed in CVS a few weeks ago but hasn't yet made it to a release.
(See bug # 937066).
Another possible workaround is
touch /sw/src/automake-1.6.3.tar.gz
(because then fink sees the file and doesn't try to fetch it... things
proceed normally after that).
-- Dave
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Christian Schaffner wrote:
I do nto think that anything but true _shells_ should be in that
category.
I couldn't find any discussion about that (nor docu) but i might have
missed something. I am not sure what to do in this case. Please advi
Darian Lanx <[EMAIL PROTECTED]> wrote:
> Daniel Nielsen wrote:
>
> > Hi..
> >
> > I just tried installing the package mentioned in subj. It failed with a
> > gcc3 command not found.
> > I manually edited the .info file and changed the references from gcc3 to
> > gcc.
>
> This seems like a pa
> Is it acceptable to delete "License:" field simply?
No. Every fink package must have a license field. See:
http://fink.sourceforge.net/doc/packaging/policy.php?phpLang=en#licenses
-- Dave
---
This SF.Net email is sponsored by: Oracl
> As a consequence, it appears that someone pulled the gnome-python2-py23
> and gramps packages from the bindist, but apparently without telling the
> pdb about it. How does the pdb get its information about the bindist
> anyway? I thought it was live?
The pdb data is based on the CVS tag relea
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
ASARI Takashi wrote:
We made w3m 1.5.1 's info files, and sent it to the original maintainer.
A month has passed, but we get no reply from him.
Can we take him over?
w3m 1.5 has i18n support, so we really need it.
I guess that is fine. Unless t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander K. Hansen wrote:
Maybe it's a missing dependency on freetype-shlibs: that's where the
libraries should be.
Actually, if he is looking for a _static_ library there should be a -dev
splittoff including the headers AND the static librar
If you use bash rather than csh, you need to update your base-files package
to version 1.9.1-1 (currently in the unstable tree), which should address
this problem.
-- Dave
Kurt Steinkraus <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to run (and maybe eventually package) clusterssh. This
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
On the Apple opensource software web page
http://www.apple.com/downloads/macosx/unix_open_source/ which every Mac
owner can find only two clicks away from their Apple menu, there is a
link to Fink, but only to version 0.6
All of the packages on that list which have me as the maintainer were
deliberately not moved, and should not be moved. I will be happy to supply
reasons if required.
We need a mechanism to mark packages as "should not be moved to 10.3",
especially if there is going to be a general call to actio
We edit the xml files by hand, and then process them using the makefiles
on the site. There is no "higher-level" tool.
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, Presid
I agree with Martin that we should accept this as the new policy, but for
now confine these packages to the unstable tree to give some time to make
sure we don't need to modify the policy further.
Martin: I was probably the one who suggested in the earlier discussion that
the symlink for the .app
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jeff Whitaker wrote:
All: I'm working on a new r-base package which will include R built as a
framework and R.app (in addition to the command line X11 version of R). I
went back and re-read the thread on .apps in Fink, but it didn't seem like
th
=?ISO-8859-1?Q?=22D=2E_H=F6hn=22?= <[EMAIL PROTECTED]> wrote:
> Daniel Macks wrote:
> | But it seems like there's an underlying problem with
> | "Essential: yes" of fink-mirrors not being respected?
> |
> Well, what I noticed is, that fink-mirrors is installed _after_ the new
> fink is executed.
> How will we handle such provides from system-perl done in the virtuals?
Excellent question! Can we easily get fink to think that the virtual
system-perl has provided certain things? If so, I can create a list of
the appropriate Provides...
-- Dave
-
P.S. I forgot to say: a couple of the packages which Patrick identified
have not been moved forward from 10.2 to 10.3. Since my focus at the
moment is to get things working in 10.3, I ignored those packages (for
now). Most likely, they are not too crucial for 10.3 since we have lived
without the
P.S. In my new policy statement where we eliminate "placeholder" packages,
I forgot to mention one exception: We will need to keep storable-pm as
a placeholder package because of the role that it plays in bootstrapping.
(Maybe some day, when we completely stop supporting 10.2, we can change
this,
Whoops, typo:
"except perl580" should have been "except perl560" in the previous message...
it's the perl560 package which doesn't need to "Provide" other things...
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linu
Patrick Näf was kind enough to compile lots of information about perl
module conflicts in late February, and I am now acting on this. (His
message is reproduced below.)
In my experimental/dmrrsn/perlmods directory, I have placed experimental
new versions of perl560, perl580, and perl583. All of
On February 29, I sent a message proposing a policy change for -pm packages.
I'll reproduce it below, and then give some important updates.
There was no objection earlier; if anybody has objections to this policy
change, this is the time to state them!
> Dear fink developers,
>
> Last spring, w
Sorry, Justin, I didn't have time to write my explanation last night and I
won't get to it until later today. Watch this space!
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbin
Thanks for pointing this out. The update will be part of base-files-0.9.1,
which should be out in 24-36 hours (after mirrors sync, etc).
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Dani
Koen,
Go into your build directory and examine config.log. The problem you've
encountered is often caused by a missing BuildDepends on gettext-dev
and/or libiconv-dev, and you'll see -lintl or -liconv on the link line
that is failing. Or if not those, some other missing library.
-- Dave
Cc
Justin,
Fink 0.20.0 was released about 1 week ago. Does your package work with
0.20.0? I hope so, because very few users understand how to update
fink from CVS. If we need to make a bugfix release of 0.20.1 to address
some particular problem, please let me know.
-- Dave
To: Fink devel <[E
> I grok the reason to keep around the different flex versions. But why
> the older guile?
When a package supplies shared libraries, and the version of the shared
libraries changes in an update to the package, we keep the old package
around so that the old shared libraries are still available for
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
Did you test wether this is really faster? I doubt that it's true. The
parsing of variants and the creation of the virtual multiple packages is
probably slower than the parsing of multiple but simpler info files.
Yes I d
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
I always thought this is a bad idea that
invites to produce a lot of non-tested packages. Why not just make two
clean info files?
Because it is a matter of scalability. When you have a piece of software
that supports ma
Just to clarify: my understand of Michele's problem is that when she tries
to build the two variants contained in this .info file, only one of them
can be built.
So either it's a problem with the way she has constructed the file, or
a problem with the variant code in fink.
-- Dave
--
Benjamin Reed <[EMAIL PROTECTED]> wrote:
> Jules wrote:
>
> > dyld: /usr/local/bin/TTOPOLOGY Undefined symbols:
> > __ZSt3cin
> > __ZSt4cout
> > __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
> > __ZSt4endsIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
> > __ZTTSt14basic_ifstreamI
> I'll be updating the gimp mirror list soon as that's horribly out of
> date.
Let me know when this is done, so that we can make a release of the
"fink-mirrors" package and provide the new list to users.
-- Dave
---
This SF.Net email is spo
I'm planning to release fink-0.20.0 fairly soon. Is anyone aware of problems
in CVS HEAD which should be fixed before the release?
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Rob
Hoss,
If you sign up for a sourceforge account and are logged in to sourceforge
when you access that page, it will look different: there will be a button
which allows you to submit something new.
I agree that our instructions need improvement.
-- Dave
"David H." <[EMAIL PROTECTED]> wrote:
> Alexander K. Hansen wrote:
> >
> The homepage link titled "Submit a new Fink package" simply
> >> leads to the SourceForge package request tracker -- which doesn't seem
> >> to provi
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander K. Hansen wrote:
The homepage link titled "Submit a new Fink package" simply
leads to the SourceForge package request tracker -- which doesn't seem
to provide any obvious method for actually *submitting* a new package.
Thanks again,
-
901 - 1000 of 2147 matches
Mail list logo
