Hello,
Your package debconf has UpdatePOD: true, but does not have *.pod in
fact. UpdatePOD is unnecessary. Worse, if no other pod file exist in
%p/share/podfiles, PostInstScript fails at a wildcard
expansion. Please remove it.
---
This SF.Net
I've updated gnupg-idea to 1.4.2.2 to complement gnupg. Any objections
to me updating it and/or taking over maintainership?
--
Benjamin Reed a.k.a. Ranger Rick
http://ranger.befunk.com/
---
This SF.Net email is sponsored by xPML, a
I've started drafting up some documents on the wiki that pertain to
package maintainership. Please look at them, expand on them, rip the
text up...
http://wiki.opendarwin.org/index.php/Fink:Updating_Another%27s_Package
On Mar 19, 2006, at 6:26 PM, Dave Vasilevsky wrote:
However, I must disagree about how wonderful collaborative
packaging could be. Once upon a time, somebody had the great idea
that rather than individual maintainers for each of the Gnome
packages, Fink should have a Gnome Team which
On Mar 20, 2006, at 9:50 AM, Alexander K. Hansen wrote:
I've started drafting up some documents on the wiki that pertain to
package maintainership. Please look at them, expand on them, rip the
text up...
Looks good; that's exactly the kind of clarification I was hoping we
could add. A
On Mar 20, 2006, at 12:22 PM, Alexander K. Hansen wrote:
1. Could we put citations to this page in the packaging tutorial and
manual?
Sure. It's on the wiki, so anybody can make add any edits they
want. :-)
I mean the reverse. I'd like the packaging tutorial and manual to
reference
Is there a machine-readable list of all packages and versions
provided by current Fink? The data obviously exists in a database on
pdb.finkproject.org but short of scraping HTML or fetching CVS, I
can't figure out how to access that list.
Background:
There's a Perl library called
How all packages and versions do you mean? For example, I can do
fink list -t \*-pm\* | cut -f2,3
to get a list of the highest available version of all perlmodule
packages, or just 'cut -f2' it and feed it to
fink dumpinfo -fpackage,allversions
to get a list of all versions of each of them
On Mar 20, 2006, at 3:50 PM, Daniel Macks wrote:
How all packages and versions do you mean? For example, I can do
fink list -t \*-pm\* | cut -f2,3
to get a list of the highest available version of all perlmodule
packages, or just 'cut -f2' it and feed it to
fink dumpinfo
Am 19.03.2006 um 23:10 schrieb Trevor Harmon:
On Mar 19, 2006, at 1:04 PM, Benjamin Reed wrote:
[...]
It makes
sense to, by default, defer to the person who understands that
software
well enough to package it, when questions arise.
But this can still be the default in the model I
On Mar 20, 2006, at 5:14 PM, Chris Dolan wrote:
Yes, fink list data are indeed exactly what I'm seeking, but the
numbers need to be accessible to a non-Mac and Macs that don't have
Fink installed. I can do fink list or the equivalent on my own
machine and upload the data to my own website
On Mon, Mar 20, 2006 at 04:14:46PM -0600, Chris Dolan wrote:
By all packages and versions, I probably overstated. I'm really
just looking for the most current state (meaning probably 10.4/
{stable,unstable}) but if 10.3, etc. is trivially accessible I'll use
that too.
Yes, fink list
On 3/20/06, Max Horn [EMAIL PROTECTED] wrote:
Am 19.03.2006 um 23:10 schrieb Trevor Harmon:
On Mar 19, 2006, at 1:04 PM, Benjamin Reed wrote:
[...]
It makes
sense to, by default, defer to the person who understands that
software
well enough to package it, when questions arise.
On Mar 20, 2006, at 5:50 PM, Daniel Macks wrote:
In order to 'fink list', the only things you need are the pure perl
parts...don't need a full local fink installation or compiled dpkg and
other support binaries. Until recently, the web PDB database update
script was running on a linux box on
Sometimes one of the core maintainers is doing a batch update of many
packages. Would it be required in such a situation to contact the
maintainers first? That could take many weeks in the worst case. And
mostly it is a change that is not really an improvement for a
particular package, but
Am 21.03.2006 um 02:45 schrieb Alexander K. Hansen:
[...]
I think we can all agree that fixing typos requires no particular
expertise with the package in question (and saves the maintainer from
being inundated with messages about the problem).
Indeed, fully agreed.
That is, as long as the
16 matches
Mail list logo
