We need our testing guru to come back and help us out here...
Matthias Neeracher [EMAIL PROTECTED] wrote:
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).
Benjamin Reed [EMAIL PROTECTED] wrote:
Michèle Garoche wrote:
grhino-0.7.0-11
WARNING: Unable to parse the line GCC 3.3 in
/sw/fink/dists/stable/main/finkinfo/games/grhino-0.7.0-11.info.
Seems to me that GCC: 3.3 (notice : is missing in the original info
file) would be more
Martin Costabel [EMAIL PROTECTED] wrote:
[snip]
I have been trying for ages to suggest to use 'current' for replacing
packages which are known to be broken. There are several packages in
0.6.2 that are known not to work on 10.3 and IMHO it absolutely stinks
that after almost 3 months
Daniel Macks [EMAIL PROTECTED] wrote:
[snip]
A possible solution would be to declare that any package that depends
on a versioned module must be versioned. Period. It would therefore be
installed in the versioned part of lib/perl5 and would have its
dependencies on versioned packages. No
Daniel Macks [EMAIL PROTECTED] wrote:
On Mon, Jan 12, 2004 at 08:39:20PM -0500, David R. Morrison wrote:
[snip]
This would work pretty well, I think. However, there is another aspect
to the problem. Some pm packages install binaries in /sw/bin and/or
man pages in /sw/share/man. If you
Hi Remi.
I think the real solution here is to get lyx-qt working with qt3. There is
no restriction like that on installing qt3, and we'd be able to build lyx-qt
automatically.
Any qt3 gurus care to look at this? RangerRick?
-- Dave
---
I wanted to make just one remark: All the gnome packages have the
problem that the gnome mirrors are notoriously and inherently
unreliable. Quite frequently, the first couple of mirrors give you a
selection of error messages, but the third or fifth or tenth mirror is
working. This
Dear fink developers,
I'd like to get some other opinions on the following question.
As I understand the GPL, if we distribute binaries of GPL'd software over
the web, we must also make the corresponding source available by the web
(unless we are willing to respond to requests sent to us by
Daniel Macks [EMAIL PROTECTED] wrote:
[snip]
For those playing along at home: previously and since the dawn of
splitoffs, :SplitOff:Package: was being evaluated in the scope of the
parent (so %n was that of the parent) while the rest of SplitOff: was
evaluated in its own scope. That means %n
There used to exist the opinion that it is not very cumbersome to have
two ghostscripts installed, but I think this should be rethought.
Let me offer another point of view on this.
Last summer, we introduced virtual packages in Fink which replaced the
former system-xfree86 and system-perl
Matthias Neeracher [EMAIL PROTECTED] wrote:
[snip]
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?
Martin Costabel [EMAIL PROTECTED] wrote:
I think we will have to restart the old discussion of /sw/Applications,
too. And I mean a real discussion, not the hasty erection of religious
taboos as we had in the past. I would really love to see things like
Tcl/Tk-aqua and rangerrick's
From [EMAIL PROTECTED] Sun Jan 25 04:24:05 2004
From: Martin Costabel [EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6)
Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthias Neeracher [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject:
In my view, the main reason for doing this is that there already exists
software out there which on the one hand depends on UNIX libraries which
are (or should be) part of Fink, but on the other hand is packaged in
OS X form, as an .app bundle which uses a Cocoa interface.
Either all of the Unix
So you would migrate from .info files to .vinfo files, over time? That's
quite a hack!
Seriously, if this were going to be done, then goal #1 of the hack would be
to set up a new, extensible, % system so that this would never need to be done
again in the future. I don't know what form that
Yes, underscores are a real problem, because all of the Debian tools assume
that the underscores in the name in a .deb are going to separate the parts
of that name. We actually glom together the version and revision fields
into a single unit, preceded and followed by those underscores, so we
Here's a patch file which implements my idea, should anyone want to test it
out:
--- PkgVersion.pm Sat Jan 31 17:29:35 2004
+++ PkgVersion.pm.patched Sat Jan 31 16:10:07 2004
@@ -2200,8 +2200,9 @@
my $self = shift;
my ($varname, $s, $expand);
my %defaults = (
-
Peter O'Gorman [EMAIL PROTECTED] wrote:
I also have some qualms about the -DLOCAL_INCLUDE_DIR=\%p/include , for no
particular reason I'd rather see -ULOCAL_INCLUDE_DIR and leave -I%p/include
Unfortunately, this doesn't work. I guess LOCAL_INCLUDE_DIR is undefined
by default, and only if it is
Anybody have good or bad things to say about fink 0.18.0? I'd like to move
it to stable, and release 0.19.0.
-- Dave
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the
Peter O'Gorman [EMAIL PROTECTED] wrote:
Martin Costabel wrote:
More precisely: In the file atk1.info in 10.3/unstable, which is version
1.4.1-3 and which I have installed, there is no such field. In
10.3/stable in version 1.4.1-2, there is such a field. The fact that
this is taken
Sure, we can wait.
If there are bugs in 0.18.0 which need to be addressed, then we should fix
them both in CVS HEAD, and in branch_0_18, and plan to release 0.18.1
which addresses them. Then, after 0.18.1 has been tested for a while,
we can move it to stable and only then release 0.19.0.
--
I'm happy to release 0.18.1 with this bugfix. Any other bugs that we need
to squash in the same release?
-- Dave
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the
Keith Conger [EMAIL PROTECTED] wrote:
Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/devel
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23841/devel
Modified Files:
intltool.info
Log Message:
GNOME 2.4.2
Index: intltool.info
Martin Costabel [EMAIL PROTECTED] wrote:
[snip]
If one leaves the fonts directory as it is and doesn't run type1inst at
all, the problem goes away, too. The files fonts.scale and fonts.dir
are already there, and I don't know if the additional file Fontmap is
needed by anything. The
Does the same bug show up in 0.18.2? in CVS HEAD?
-- Dave
---
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.
Dear Fink folks,
As many of you know, the stable tree in 10.3 was created from the
corresponding tree in 10.2. Everything which was moved to 10.3 builds OK
on 10.3, but there are a number of cases where the software provided by
the package no longer works, or doesn't work as expected.
We need
I'm jumping into this thread a bit late, since I was out of town for a few
days.
I hope that everyone is bearing in mind a crucial fact of life: whatever
we do in terms of dependencies has to be translated (at the end of the
day) into dependencies that the Debian tools (dpkg and apt-get) can
TheSin [EMAIL PROTECTED] wrote:
I haven't commited anything to stable... talk to Dave about that.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 12-Feb-04, at 12:44 AM, Martin Costabel wrote:
TheSin wrote:
this seems to be a 10.2 or
To help get things started, I've added verified by entries for all of
the commits to 10.3/stable from the past month where the CVS log suggested
this was appropriate.
However, there is still a lot of work to do along these lines, and I
encourage everyone to roll up their sleeves and help out. It
Hi Ben.
There's a tradeoff here between, on the one hand, encouraging packagers
to keep patches small and thereby keeping the fink info/patch database
at a reasonable size, and on the other hand, making sure that we don't
add unnecessary barriers to packaging things up.
If we have to find a way
Hi Dan. This sounds good to me. But do we have any idea how many .info
files are still using this deprecated style? One of the problems in recent
months has been with maintainers who are no longer with us... A change like
this will eventually require a cleanup by some person or group who goes
Martin,
It is not an omission that system-tetex does not provide tetex-dev.
One of the differences between Gerben Wierda's teTeX distribution and the
fink one is that in fink, we build libkpathsea as a shared library, whereas
it is only a static library in Wierda's distribution.
(This may
If your link line has -lkpathsea, then a user who has tetex-dev installed
will get a link to libkpathsea.dylib, whereas a user with system-tetex
installed will get a link to libkpathsea.a . (The darwin linker prefers
the shared version whenever it can find it.)
-- Dave
The maintainer for postgresql is on vacation this week, so it may be a while
before he responds.
But let me suggest, since you seem to have analyzed the problem very nicely,
that you might try to figure out how the fink package should be modified
and provided a proposed new info file and/or new
I plan to start creating a binary release for 10.3 in about a week.
If you are aware of any of your packages in the 10.3/stable tree which are
*not* suitable for binary release, please either fix them or remove them
from that tree.
Thanks,
Dave
Hi Remi.
Sure, removing the dlcompat dependencies is one of the things which needs to
be done.
In some cases, this has already been done in the unstable tree, but not the
stable tree. So it's a bit unclear whether one should create a new stable
version, or move the current unstable version to
.
On Feb 27, 2004, at 9:47 AM, David R. Morrison wrote:
I plan to start creating a binary release for 10.3 in about a week.
If you are aware of any of your packages in the 10.3/stable tree which
are
*not* suitable for binary release, please either fix them or remove
them
from
Sebastien,
Thanks very much for your contribution to fink.
You only need to use the tag GCC: 3.3 if your package compiles any C++
code. (Typically, in this case, you would notice a line during the
configure step about checking for c++ or g++.) The reason we have to
tag that is that the gcc
Koen,
Is bioperl-pm581 ready to go to stable? (i.e., are all the dependencies
already in stable?) Under my proposed new policy, we wouldn't want the
package called bioperl-pm in the long run, anyway, and virtually all
10.3 users are going to be using perl 5.8.1. So moving bioperl-pm581
to
Alexander Strange [EMAIL PROTECTED] wrote:
LAME should not be included in the binary distribution, unless you feel
like buying Fink an unlimited MP3 license (distribution of decoders is
OK, or at least not actively acted upon, but distributing encoders is
not allowed; see
The more I think about it, the more I think that %n should be used for the
truncated name. That currently shows up in lots of places; not only the
patch file, but often in the Source: line and so on.
I think we need a %versioned_name type of percent field for the fully
expanded name.
On the
Let me explain in more detail.
Fink installs all of its software in a directory that it manages. (The
default choice is /sw, but some people use different directories.) One
of the key features of fink is that it is good at tracking dependencies,
and so on. However, for this to work, only fink
(I didn't literally mean %versioned_name... that was a placeholder for whatever
we decide to use...)
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
Daniel Macks [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] committed:
Log Message:
eden update of patch script to deal with trivial change in makefile
===
RCS file: /cvsroot/fink/dists/10.3/unstable/main/finkinfo/sci/eden.info,v
Do we need to notify the i18n folks in some way when we make a documentation
change? Or is the i18n committee monitoring fink-commits for this purpose?
(probably the best idea, since people may forget to do the notification...)
-- Dave
---
Following a suggestion on the fink-users list, the CVS version of fink will
now only display the warnings about BuildDependsOnly if you set the verbosity
level of fink to be higher than the default. All fink developers should
do this, to avoid accidentally using a BuildDepends on an inappropriate
Hi Alexander. This looks great.
One thing the document is not too clear about is the message that is to
be sent to the i18n list when a change is made to the docs (by me, for
example). Are you going to handle sending those messages? Or can we
perhaps modify the cvs commit mail script so that
welcome it, if you _could_ send changes to the fink-i18n list _prior_
We need to set this up so that the people who are working on fink itself
are given motivation to document things they are doing. If adding to
the documentation is going to mean having a discussion about it on the
fink-i18n
By the way, I found it a bit confusing that the file packaging.xml is still
in CVS, as well as packaging.en.xml . Perhaps we should delete all of the
original .xml files which have been replaced by .en.xml files?
-- Dave
---
This SF.Net
The last modified by is taken from the last person to change the xml file.
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn
Hi Martin.
How do you think we should include this with the bindist? Should we put
your .app on the disk in place of the current .command file? How should
the postinstall script of the bindist be set up? Should this shell script
be included with fink itself, in case someone wants to run it
Mirrors are not going to help in this case. This is a restrictive package,
so we don't put it on the mirrors (since we aren't allowed to redistribute
it).
-- Dave
P.S. The URL doesn't work for me either...
---
This SF.Net email is
I've discussed with a few people in the past the idea that we should modify
our setup so that a list of mirror sites for use by apt-get is under fink's
control, just as other kinds of mirror sites are under fink's control
It seems like this may be the moment we need to implement this (on an
Hi Peter.
The thrust of my idea, actually, was that sources.list would no longer be
edited by users directly (just like fink.conf is not edited by users
directly). Fink should provide a way to put anything in sources.list
which needs to be there, including additional entries specified by the
Don't forget to cope with user changes to the sources.list
I guess I was planning to prompt the user for whatever additions he/she
wants, during the fink configure dialog.
-- Dave
---
This SF.Net email is sponsored by: IBM Linux Tutorials
I've got a proposed revision of the header.inc file for the web directory
in my experimental directory. This adds language-specific tags to the
navigation at the left of the page. Comments welcomed.
-- Dave
---
This SF.Net email is
Release candidates for the new installers are up at:
http://www.cgtp.duke.edu/~drm/Fink-0.6.3-Installer.dmg
http://www.cgtp.duke.edu/~drm/Fink-0.7.0-Installer.dmg
Many thanks to Martin Costabel, who tested earlier release candidates and
found problems (fixed in the new ones).
If anyone
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
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
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
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_
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
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
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
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
=?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
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
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
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
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
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
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.
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
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,
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
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
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
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
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
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
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
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
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
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
601 - 700 of 1174 matches
Mail list logo
