-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Blair Zajac wrote:
| Hi Justin,
|
| The Compress::Zlib package currently compiles and links against it's own
| private copy of zlib 1.1.4. This seems to be a waste of disk and memory
| space when Mac OS X 103.3 comes with the same version of zlib
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Lars Rosengreen wrote:
| The Darcs package I maintain comes with a bash completion script that
| can be installed in %p/etc/bash_completion.d/ . Do you think it is
| appropriate for me to put things in this directory without depending on
| the
Hisashi T Fujinaka [EMAIL PROTECTED] wrote:
On Fri, 23 Jul 2004, Benjamin Reed wrote:
David H. wrote:
fink needs help picking an alternative to satisfy a virtual
dependency. The candidates:
(1) io-stringy-pm560: Perl module for advanced I/O with filehandles
Since I wish
On Jul 24, 2004, at 1:19 PM, jfm wrote:
On Jul 24, 2004, at 7:04 PM, David R. Morrison wrote:
Please consult the packaging manual.
It is no longer permitted to have a placeholder -pm package which
depends
on versioned packages. The only exception is storable-pm, because of
the
historical way
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hello.
Looking at Fink I get:
fink install soap-lite-ssl-pm581
/usr/bin/sudo /sw/bin/fink install soap-lite-ssl-pm581
Information about 3675 packages read in 3 seconds.
fink needs help picking an alternative to satisfy a virtual dependency.
The
On Jul 20, 2004, at 1:07 AM, Daniel Macks wrote:
Update of /cvsroot/fink/fink/perlmod/Fink
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28793
Modified Files:
PkgVersion.pm ChangeLog
Log Message:
Remove restriction on use of %a...causes too much disruption at this
point.
Dan,
Maybe we
On Jul 19, 2004, at 7:20 PM, rayg wrote:
Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/net
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15114
Modified Files:
liferea.info
Log Message:
updated dependencies (added orbit2, libgtkhtml2)
When you change the Depends line,
There have been a number of problems reported on the lists recently
with system-tetex, having to do with a missing libkpathsea.a file.
Apparently, some parts of teTeX in Gerben Weirda's distribution
(including this file) have been moved into a separate developer
extras installation in his
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
jfm wrote:
snip
|
| There are probably 2 different issues: one is that in some cases it may
| be clearer or more convenient to use several different 'patchfiles' , with
| very distinct roles _ so a 'PatchFile' field might have to be plural _ ;
|
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Benjamin Reed wrote:
| David H. wrote:
|
| jfm wrote:
|
| snip
| |
| | There are probably 2 different issues: one is that in some cases it may
| | be clearer or more convenient to use several different 'patchfiles'
| , with
| | very distinct roles
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Dear community.
I have recently be looking more and more into bittorrent. I do believe
that sharing resources now a days for the benefit of the whole community
is a good thing. I was wondering if the Fink community was interested in
a bittorrent
Dear Fink developers,
As many of you know, I've been working on a revision in the way that fink
interacts with various external things (like our website, our cvs repository,
and our apt-get repository), trying to make sure that it will be easy
to change the location of those things when that
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.
-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,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Corey Halpin wrote:
|
snip
|
| 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
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
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,
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.
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
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.
-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
-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
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
-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
-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? snip
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
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
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
various Fink install issues, especially Scribus (which
I'm now using in a production setting in my day job as a book publisher).
I'm working on another launcher for Inkscape, and will have that ready
for release soon as well.
Thanks,
Kevin
David R. Morrison wrote:
| Kevin
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
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
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 technical
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
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
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
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 use
snip
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
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,
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
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
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
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
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:
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
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 -
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
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
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
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
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'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
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, or
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 the
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
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 (=
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 I'll
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
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
neon24
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
snip
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)
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
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? :) :)
Yes
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
-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
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
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:
snip
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
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 packaging bug.
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: Oracle
-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
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
-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
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,
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 action
-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
-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
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
=?ISO-8859-1?Q?=22D=2E_H=F6hn=22?= [EMAIL PROTECTED] wrote:
Daniel Macks wrote:
snip
| 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. I
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
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,
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
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 Linux
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,
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
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
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
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
snip
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Martin Costabel wrote:
snip
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.
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_
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Alexander K. Hansen wrote:
snip 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,
David H. [EMAIL PROTECTED] wrote:
Alexander K. Hansen wrote:
snip 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
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
801 - 900 of 1724 matches
Mail list logo
