Update of /cvsroot/fink/experimental/alexkhansen/wiki
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30837
Added Files:
0.24+backports.textile 0.25+blockers.textile
0.25+new+documentation+needs.textile 0.25+new+features.textile
0.26+goals.textile AlexHansen.textile GCC.textile
Gnome.textile HomePage.textile InheritedBuildDepends.textile
The+10.4+tree.textile XMLish+Source+and+Patch.textile
c%2B%2B.textile incremental+indexing.textile
Log Message:
Wiki stuff (http://ldx3.psfc.mit.edu:2500/akhfinkwiki/published/HomePage)
--- NEW FILE: XMLish+Source+and+Patch.textile ---
All the <code>*Source*</code>-related fields are a pain to parse, can lead to a
messy .info.<pre><code>SourceFile: <<
Source: http://whatever
Rename: %n-%v.tar.gz
MD5: whatever
<<
SourceFile2: <<
Source: http://whatever
Rename: %n-%v.tar.gz
MD5: whatever
<<</code></pre>cluster all fields for a given source object. Easy to add new
features (dmalloc wants stronger checksums) without making even more of a
top-level fieldname mess.
Easy to extend to patchfiles ("MD5 for patchfiles" is a longstanding
request).<pre><code>PatchFile: <<
Source: foo.patch
MD5: whatever
<<
PatchFile2: <<
Source: foo-ssl.patch
MD5: whatever
<<</code></pre>The full path to each file would be available as a %-exp and
<code>%a</code> would be abolished. That way only files that have passed the
MD5 check would be usable.
_vasi:_
It would be nice to have a patch folder per package rather than one monster
patch.
_dmacks:_
This is already possible (subdirs in %a), and I expect that way would continue
to work correctly with the new syntax. One can already even cluster [.info and
its .patch] in its own %n subdir.
--- NEW FILE: incremental+indexing.textile ---
h3. What is it?
Lets Fink read only new .info files instead of all of them. Also lets Fink load
just the part of the package DB that it needs.
h3. Testing it
* parameters
** index (write only) or other load (read/write)
** root or non-root
** different versions of fink
** with/without autoindex
** full or partial or proxy run
* race conditions
** run multiple finks at once
* exceptional cases
** rsync: files updated to earlier mtime than last index
** \FinkCommander: needs whole DB, caching
** forget and re-load
* missing stuff and dealing with it
** index.db
** proxies.db
** finkinfo dir, or files within
* package has
** proxy stuff (name, version)
** loadable stuff (dumpinfo)
--- NEW FILE: Gnome.textile ---
h2. Gnome 2.10 progress
* *Fink*: Version in Fink unstable, 10.4-transitional.
* *2.10*: Minimum version for Gnome 2.10.
* *Up?*: Do we need an update?
h3. Goals
* Version update
* Update deps according to pkg requirements (*not* arbitrarily to new current
version)
* Switch to gettext3
* Put -ssl variants first in alternative dependencies
* Make sure static libs are built
* --disable-dependency-tracking
h3. "Gnome
Platform":http://ftp.gnome.org/pub/GNOME/platform/2.10/2.10.0/sources/
|<. *Package* |>. %{padding-left:3em}*Fink*% |>. %{padding-left:3em}*2.10*% |=.
%{padding-left:1em}*Up?*% |
| at-spi |>. 1.6.3 |>. 1.6.3 |=. |
| atk |>. 1.10.1 |>. 1.9.1 |=. |
| audiofile |>. 0.2.6 |>. 0.2.6 |=. |
| esound |>. 0.2.35 |>. 0.2.35 |=. |
| gail |>. 1.8.4 |>. 1.8.2 |=. |
| gconf2 |>. 2.10.1 |>. 2.10.0 |=. |
| glib |>. 2.6.6 |>. 2.6.3 |=. |
| gnome-mime-data |>. 2.4.2 |>. 2.4.2 |=. |
| gnome-vfs |>. 2.10.1 |>. 2.10.0 |=. |
| gtk+ |>. 2.6.8 |>. 2.6.4 |=. |
| intltool |>. 0.33 |>. 0.33 |=. |
| libart |>. 2.3.17 |>. 2.3.17 |=. |
| libbonobo |>. 2.10.0 |>. 2.8.1 |=. |
| libbonoboui |>. 2.10.0 |>. 2.8.1 |=. |
| libglade |>. 2.5.1 |>. 2.5.1 |=. |
| libgnome |>. 2.10.0 |>. 2.10.0 |=. |
| libgnomecanvas |>. 2.10.2 |>. 2.10.0 |=. |
| libgnomeprint |>. 2.10.3 |>. 2.10.0.1 |=. |
| libgnomeprintui |>. 2.10.2 |>. 2.10.0.1 |=. |
| libgnomeui |>. 2.10.1 |>. 2.10.0 |=. |
| libidl |>. 0.8.5 |>. 0.8.5 |=. |
| libxml |>. 2.6.19 |>. 2.6.17 |=. |
| libxslt |>. 1.1.14 |>. 1.1.12 |=. |
| orbit |>. 2.12.2 |>. 2.12.1 |=. |
| pango |>. 1.8.1 |>. 1.8.1 |=. |
| pkgconfig |>. 0.17.2 |>. 0.15.0 |=. |
h3. "Gnome Desktop":http://ftp.gnome.org/pub/GNOME/desktop/2.10/2.10.0/sources/
|<. *Package* |>. %{padding-left:3em}*Fink*% |>. %{padding-left:3em}*2.10*% |=.
%{padding-left:1em}*Up?*% |
| bug-buddy |>. 2.6.1 |>. 2.10.0 |=. • |
| control-center |>. 2.6.1 |>. 2.10.0 |=. • |
| dasher |>. 3.2.10 |>. 3.2.15 |=. • |
| eel |>. 2.6.2 |>. 2.10.0 |=. • | needs
gnome-menus |
| eog |>. 2.6.1 |>. 2.9.0 |=. • |
| epiphany |>. 1.4.8 |>. 1.6.0 |=. • |
| evolution |>. 1.5.92 |>. 2.2.0 |=. • |
| evolution-data-server |>. 0.0.97 |>. 1.2.0 |=. • |
| evolution-webcal |>. missing! |>. 2.2.0 |=. • |
| file-roller |>. 2.6.1 |>. 2.10.0 |=. • |
| gal |>. 2.1.13 |>. 2.4.0 |=. • |
| gcalctool |>. 4.3.51 |>. 5.5.41 |=. • |
| gconf-editor |>. 2.10.0 |>. 2.10.0 |=. |
| gdm |>. 2.6.0.3 |>. 2.6.0.8 |=. • |
| gedit |>. 2.6.2 |>. 2.10.0 |=. • |
| ggv |>. 2.6.1 |>. 2.8.4 |=. • |
| gnome-applets |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-backgrounds |>. missing! |>. 2.10.0 |=. • |
| gnome-desktop |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-doc-utils |>. missing! |>. 0.1.3 |=. • |
| gnome-games |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-icon-theme |>. 1.2.3 |>. 2.10.0 |=. • |
| gnome-keyring |>. 0.4.3 |>. 0.4.2 |=. |
| gnome-mag |>. 0.10.11 |>. 0.12.0 |=. • | 0.12 is new
lib-major-version; 0.12.1 has a duplicate-symbol mess vs. bonobo and at-spi
(orbit makes a stubs.c with missing "extern" decls?) |
| gnome-media |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-menus |>. missing! |>. 2.10.0 |=. • | exp/dmacks;
conflicts w/kdelibs3; talk to miga about env vars |
| gnome-netstatus |>. 2.6.1 |>. 1.2.0 |=. • |
| gnome-nettool |>. missing! |>. 1.2.0 |=. • |
| gnome-panel |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-session |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-speech |>. 0.3.7 |>. 0.3.6 |=. |
| gnome-system-monitor |>. 2.6.0 |>. 2.10.0 |=. • |
| gnome-system-tools |>. missing! |>. 1.2.0 |=. • |
| gnome-terminal |>. 2.6.1 |>. 2.10.0 |=. • |
| gnome-themes |>. 2.11.3 |>. 2.10.0 |=. |
| gnome-user-docs |>. 2.8.1 |>. 2.8.1 |=. • |
| gnome-utils |>. 2.6.2 |>. 2.10.0 |=. • |
| gnome-volume-manager |>. missing! |>. 1.2.0 |=. • |
| gnomemeeting |>. 0.98.0 |>. 1.2.1 |=. • |
| gnopernicus |>. 0.7.1 |>. 0.10.4 |=. • |
| gok |>. 0.10.2 |>. 1.0.2 |=. • |
| gpdf |>. 0.132 |>. 2.10.0 |=. • |
| gst-plugins |>. 0.8.10 |>. 0.8.8 |=. |
| gstreamer |>. 0.8.9 |>. 0.8.8 |=. |
| gtk-engines |>. 2.6.3 |>. 2.6.2 |=. |
| gtkhtml |>. 3.2.1 |>. 3.5.3 |=. • |
| gtksourceview |>. 1.2.1 |>. 1.2.0 |=. |
| gucharmap |>. 1.4.1 |>. 1.4.3 |=. • |
| libgail-gnome |>. 1.0.4 |>. 1.1.0 |=. • |
| libgnomecups |>. 0.1.6 |>. x |=. ? | Apple's 10.3
cups-dev lies about its version...it's too low to build this pkg; might work on
10.4 |
| libgtkhtml |>. 2.6.3 |>. 2.6.3 |=. |
| libgtop |>. 2.6.0 |>. 2.10.0 |=. • |
| librsvg |>. 2.9.5 |>. 2.9.5 |=. |
| libsoup |>. 0.7.11 |>. 2.2.2 |=. • |
| libwnck |>. 2.10.3 |>. 2.10.0 |=. |
| libxklavier |>. 1.02 |>. 2.0 |=. • |
| metacity |>. 2.8.1 |>. 2.10.0 |=. • |
| nautilus |>. 2.6.3 |>. 2.10.0 |=. • |
| nautilus-cd-burner |>. 2.6.1 |>. 2.10.0 |=. • |
| nautilus-media |>. 0.8.0 |>. 0.8.1 |=. • |
| scrollkeeper |>. 0.3.14 |>. 0.3.14 | |
| sound-juicer |>. missing! |>. 2.10.0 |=. • |
| startup-notification |>. 0.8 |>. 0.8 |=. |
| system-tools-backends |>. missing! |>. 1.2.0 |=. • |
| totem |>. 0.99.12 |>. 1.0 |=. • |
| vino |>. missing! |>. 2.10.0 |=. • |
| vte |>. 0.11.13 |>. 0.11.12 |=. |
| ximian-connector |>. 1.5.92 |>. 2.2.0 |=. • |
| yelp |>. 2.6.1 |>. 2.10.0 |=. • |
| zenity |>. 2.10.1 |>. 2.10.0 |=. |
h3. "C++ Bindings":cplusplus
[cplusplus]http://ftp.gnome.org/pub/GNOME/bindings/2.10/2.10.0/sources/c++
|<. *Package* |>. %{padding-left:3em}*Fink*% |>. %{padding-left:3em}*2.10*% |=.
%{padding-left:1em}*Up?*% |
| gconfmm |>. 2.6.1 |>. 2.9.2 |=. • |
\RangerRick's |
| glibmm |>. 2.6.1 |>. 2.6.1 |=. |
| gnome-vfsmm |>. missing! |>. 2.10.0 |=. • |
| gtkmm |>. 2.4.5 |>. 2.6.0 |=. • |
| libglademm |>. missing! |>. 2.6.0 |=. • |
| libgnomecanvasmm |>. missing! |>. 2.10.0 |=. • |
| libgnomemm |>. missing! |>. 2.10.0 |=. • |
| libgnomeuimm |>. missing! |>. 2.10.0 |=. • |
| libsigc++ |>. 2.0.11 |>. x |=. ? | Spundun's |
| libxml++ |>. 2.10.0 |>. 2.10.0 |=. |
h3. "Java
Bindings":http://ftp.gnome.org/pub/GNOME/bindings/2.10/2.10.0/sources/java
|<. *Package* |>. %{padding-left:3em}*Fink*% |>. %{padding-left:3em}*2.10*% |=.
%{padding-left:1em}*Up?*% |
| libgconf-java |>. missing! |>. 2.10.0 |=. • |
| libglade-java |>. missing! |>. 2.10.0 |=. • |
| libgnome-java |>. missing! |>. 2.10.0 |=. • |
| libgtk-java |>. missing! |>. 2.6.0 |=. • |
h3. "Perl
Bindings":http://ftp.gnome.org/pub/GNOME/bindings/2.10/2.10.0/sources/perl
|<. *Package* |>. %{padding-left:3em}*Fink*% |>. %{padding-left:3em}*2.10*% |=.
%{padding-left:1em}*Up?*% |
| extutils-pkgconfig |>. 1.02 |>. ? |=. • | htodd's |
| glib-perl |>. 1.020 |>. 1.080 |=. • | htodd's |
| gnome2-perl |>. missing! |>. 1.020 |=. • |
| gnome2-canvas-perl |>. missing! |>. 1.002 |=. • |
| gnome2-gconf-perl |>. missing! |>. 1.000 |=. • |
| gtk2-perl |>. 1.021 |>. 1.080 |=. • | htodd's |
| gtk2-gladexml-perl |>. missing! |>. 1.004 |=. • |
h3. "Python Bindings":http://www.pygtk.org
|<. *Package* |>. %{padding-left:3em}*Fink*% |>. %{padding-left:3em}*2.10*% |=.
%{padding-left:1em}*Up?*% |
| pygtk2 |>. 2.6.2 |>. 2.6.0 |=. |
| gnome-python2 |>. 2.0.0 |>. x |=. • | Jeremy
Higgs's; current doesn't even build on 10.4T |
| pyorbit2 |>. 2.0.0 |>. x |=. |
| gnome-python-extras |>. missing! |>. x |=. |
--- NEW FILE: 0.24+backports.textile ---
* -\BuildDep swapping- *done*
* \ParentEssential fix *waiting for cirdan to test*
* InfoN validator patch *vasi please eyeball the patch in HEAD*
--- NEW FILE: InheritedBuildDepends.textile ---
h3. The idea
Often a package needs not just another package as a \BuildDepends, but also a
bunch of associated packages. For example, every package that \BuildDepends on
==gtk+2-dev== also wants atk1. The solution is for ==gtk+2-dev== to have
@InheritedBuildDepends: atk1@, which will then automagically become a
\BuildDepends for every package that BDeps on ==gtk+2-dev==.
h3. The rule
The basic rule for expanding \BuildDepends is: If X bdep Y, then X bdep y for
all y in ==IBD(Y)==. This is applied recursively!
h3. Example
<pre><code>Package: foo
BuildDepends: foo-bdep
InheritedBuildDepends: foo-ibd
</code></pre>
<pre><code>Package: bar
BuildDepends: bar-bdep
InheritedBuildDepends: foo, bar-ibd
</code></pre>
<pre><code>Package: iggy
BuildDepends: bar
</code></pre>
When asked to resolve the build depends, Fink should yeild the following
results:
* foo: foo-bdep, foo-ibd
* bar: bar-bdep, foo, foo-ibd, bar-ibd
* iggy: bar, foo, foo-ibd, bar-ibd
h3. Stumbling blocks
* If IBD applies to the package that lists it (foo:IBD:foo-ibd propagates as
foo:BD:foo-ibd) we have to make sure to exclude pkgs from the current build set
("this .info") when doing IBD->BD for building that file. *BUG*: current BD
processor in the engine does this but buildlock does not.
* I think that duplicate listings of a package with different versions are OK
for now, as Fink will always pick the highest version of a package. But this is
something to keep in mind!
* At what level do we want to insert the IBDs? In ==pkglist*== ? In
get_depends? In resolve_depends?
* While we're at it, maybe we should rewrite resolve_depends to use the lol
model?
* Are there situations where a pkg that one might use as a Depends would want
IBD functionality? Recursing down Depends looking for IBD is a giant mess, so
one would have to know this in advance in order to list it as a \BuildDepends
also. Or we could enforce that IBD is only for BDO:true packages, which would
never be a Depends so no problem.
** I see IBD as a tool only for BDO packages. If it turns out later that it's
useful for non-BDO stuff as well, we can deal with that when we get there.
(drm's input would be useful here though.)
** (drm's input) If we also implement the proposed \RunTimeDepends, we will
have three kinds of depends fields: BD which is only enforced at build time, D
which is enforced both at build time and at runtime, and RTD which is enforced
only at runtime. At build time, we are relying on dependencies which are
specificed in .info files, whereas at runtime we are relying on dependencies
which have been written out to .deb files. Now we already recurse on the
Depends field at buildtime (and dpkg/apt-get do so at "runtime", i.e., install
time for the pkg). The RTD field will be irrelevant at build time. So the
only one we need to worry about recursion on is BD. That is the point of IBD,
and I don't see how it would ever be applied to entries in the Depends field.
** (more drm input) So I guess the short answer is: package authors should put
into IBD any of the buildtime dependencies which should be inherited but which
can't be "Depends". This essentially means BDO packages.
* Have to store IBD in the .deb and make sure to read IBD of the actual version
installed, since the .info present may be for a different revision that has
different IBD.
h3. Potential extensions
* After phase_install, parse .pc and .la in each %d and automatically add items
to IBD lists:
** .pc: add pkgs containing .pc for libs listed in Requires field and also
"pkgconfig" itself.
** .la: add pkgs containing .la files listed in dependency_libs field
** (vasi ponders) *NOTE:* This could be very annoying for large builds, if we
can't know what the actual BDeps are until we've built a whole bunch of stuff.
** (drm again) I would much rather see this be done by the validator. To make
sure we have determinacy in this process, our IBD processing should be limited
to stuff which is actually in the .info database at the time of buliding.
** (dmacks clarifies) This is actually the opposite approach to the current IBD
thought...instead of a package declaring IBD ("what does some other package
need to link against me?") it would declare BD ("what I need to get built") and
then fink would decide what is needed to link against me. Essentially upgrade
some BD to IBD.Can't do it both ways in a single pkg obviously...no magic,
gotta list *something*...that means this is still deterministic at the start of
a large build set.
h3. Alternate solution:
* Weaken the "nothing may Depends on a BDO package" to "only BDO packages may
Depends on a BDO package", use normal Depends so that a -dev automatically
drags along anything else needed to compile against it. Adjust phase_activate
so that when installing a BDO package that conflicts/replaces some other
package, do a recursive removal of that other package first.
** advantage: useful for people using Fink to install -dev for their own
(!fink) uses. BDO only works for things compiled within Fink.
** advantage: don't gotta mess with a whole new type of dependency check in the
engine.
** disadvantage: creates a whole in the swappy code? Engine may not realize
these other things that get removed.
--- NEW FILE: 0.26+goals.textile ---
* InheritedBuildDepends
* [[XMLish Source and Patch|new Source blocks]]
* more indexing work
** refactor into ==Indexer.pm== and possibly other modules
** load-on-demand
** version the DB
** forget_packages should have better options
* dep-engine refactoring work?
* External API (so scripts can 'use Fink')
* optimizations
** auto-split \PkgVersion?
* bug fixing!
* dist-upgrade?
* automatically detect users' location, even for binary install
--- NEW FILE: 0.25+new+documentation+needs.textile ---
Info3
* 'fink cleanup'
* \AutoShlibs
* new options to 'fink index' (not yet finalized in code!)
* fast scanpackages with apt-ftparchive, including \AutoScanpackages
* \SkipPrompts
--- NEW FILE: c%2B%2B.textile ---
silliness with "++"
[[FOOBAR.pdf]]
--- NEW FILE: The+10.4+tree.textile ---
Here is the current plan for creating the 10.4 tree.
# We need to make sure that all packages using ==c++ or g++== have been tagged
with the appropriate GCC field in 10.4-transitional.
** Status: This has been done in stable, but has been left to maintainers for
unstable.
# We need to make sure that as many packages as possible with a GCC field will
build OK using ==g++-4.0 rather than g++-3.3.==
** Status: This has been done in stable, and is being worked on for unstable.
# The new 10.4 tree will allow packages with GCC: 3.3, but a lot of care has to
be taken with dependencies: putting such a package there means that all
c++-using packages wihch depend on it must be GCC: 3.3 as well. Packages which
are put into the new tree as GCC: 3.3 should have some comment to this effect
in the .info file.
** Status: comments are still being added in the stable tree.
** gcc 3.1 remnants: the following .info declare GCC:3.1
*** mutella
*** visual-py23
*** gnomemeeting
*** fxscintilla
*** brs
** The roo* packages already declare GCC:4.0 in the 10.4T tree
# Python 2.2 and all -py22 packages will NOT be brought forward to the 10.4
tree. (same for python21)
In addition to creating a 10.4 tree, we need a strategy for an upgrade for
users when the tree changes. The code in cirdan's dist-up-branch in CVS is one
possible way to go.
--- NEW FILE: 0.25+blockers.textile ---
I'd like this to be the final list except for items already on the "patch
tracker":https://sourceforge.net/tracker/?atid=317203&group_id=17203 or "bug
tracker":https://sourceforge.net/tracker/?atid=117203&group_id=17203 _--vasi_
h3. Todo
* vasi: [[incremental indexing]]
** -needs to be robust in the case that a backing-store file is missing- *fixed*
** -selfupdate-rsync doesn't register- *fixed*
** -remove connection with Shlibs module- *fixed*
** -\FinkCommander doesn't work- *fixed*
** -forget_packages doesn't actually forget everything- *fixed*
** *testing!*
* dmacks: cleanup --bl
* Shlibs needs work:
** index on-demand
** unpredictable depends?
* cirdan: dist up
*
"Module::Build":http://sourceforge.net/tracker/index.php?func=detail&aid=998741&group_id=17203&atid=317203
* Info3
** Deprecate RFC-822?
* dmacks: -Treat InfoN value as metadata not as an actual field.- *fixed*
* dmacks: abolish implicit <code>Source</code>?
--- NEW FILE: GCC.textile ---
h2. The GCC field
A package needs a GCC field if anything in the package is compiled with ==c++
or g++==.
This is a practical guide. For policy information see "the packaging
manual":http://fink.sourceforge.net/doc/packaging/compilers.php and "email to
fink-devel":http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg11877.html
.
h3. How to tell if a binary has been compiled with g++
A good way to tell if a binary in your package was compiled with g++ is:
<pre><code>
nm -g $binary > symbols
c++filt3 < symbols > symbols.filt
diff symbols symbols.filt
</code></pre>
In most cases, if there is a difference it was compiled with g++ (some
exceptions exist involving weirdly named C functions).
h3. The script
The script
"gcc-field":http://cvs.sourceforge.net/viewcvs.py/*checkout*/fink/experimental/vasi/scripts/gcc-field
can check one or more packages to see if they need a GCC field.
To check one package, run it like this:
<pre><code>
gcc-field $package
</code></pre>
If it prints anything, the package doesn't have the right field (or is an
exceptional case). If it doesn't print anything, you're ok!
You can also check all your packages:
<pre><code>
gcc-field --maintainer=Vasilevsky
</code></pre>
Or check a set of files:
<pre><code>
find ./root-foo | gcc-field -
</code></pre>
Please run @gcc-field --help@ for details.
--- NEW FILE: 0.25+new+features.textile ---
h3. Finished features
* \SkipPrompts
* Info3
* fast scanpackages with apt-ftparchive
* auto-detection of country
--- NEW FILE: HomePage.textile ---
This is an unofficial Fink wiki.
h3. How to follow policy
* [[GCC|GCC field]]
h3. Packaging progress
* [[Gnome]]
* [[The 10.4 tree]]
h3. Package manager roadmap
* [[0.24 backports]]
* [[0.25 new features]]
* [[0.25 blockers]]
* [[0.25 new documentation needs]]
* [[0.26 goals]]
h3. Major new feature plans
* [[XMLish Source and Patch]]
* InheritedBuildDepends
--- NEW FILE: AlexHansen.textile ---
Documents, documents.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Fink-commits mailing list
Fink-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-commits
