FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-15-2011, 07:14 PM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

Hello,

I have been working on two changes for dpkg that I plan to merge sometimes
next week. Until then I would be glad to have some feedback, reviews.

1/ Makefile snippets for use in debian/rules

http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=pu/makefile-snippets

dpkg-dev will start providing some makefile snippets in /usr/share/dpkg/
to retrieve some common values that can be useful in debian/rules.

It includes variables returned by dpkg-buildflags, dpkg-architecture and
dpkg-vendor.

Should I also include some variables corresponding to changelog related
variables ? If yes, we should certainly pick a set compatible with CDBS.
DEB_SOURCE_PACKAGE
DEB_VERSION
DEB_NOEPOCH_VERSION
DEB_UPSTREAM_VERSION
DEB_DISTRIBUTION

Note that the makefiles have been written in a way so that they do not
result in useless forks for unused variables (thanks to Mike Hommey for
the idea) and still ensure we run each command only once even if a
variable is referenced multiple times.

I have also decided to not export the build flags in the environment by
default. If the caller really wants this, he should set
DPKG_EXPORT_BUILDFLAGS.

2/ dpkg-source --record-changes

http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/master

As discussed on debian-devel at the end of may, I have implemented
some changes to source format 3.0 (quilt) so that a build fails if there
are upstream changes which are not yet managed by quilt. Recording the
change in a new quilt patch must now be done explicitly by the maintainer
with dpkg-source --record-changes. This will require the user to give
a patch name and an editor will be run to let the maintainer edit the
patch header.

It required some important restructuring of the source package build
procedure so I would be glad to have some more people running with this.
Also you might have some input on the new interface.

3/ You can test all those by building and installing dpkg with my
test-build branch, it includes pu/multiarch/full, pu/master and
pu/makefile-snippets.

git clone git://anonscm.debian.org/users/hertzog/dpkg.git -b test-build

4/ We should really think of releasing 1.16.1 once those changes are
merged. Guillem, do you have other things that you wanted to see merged
for 1.16.1?

This release will not block multiarch, since we can always release 1.16.2
to experimental in parallel if needed. I hope that we can tackle the
remaining issues for multiarch during debconf.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110715191440.GA20715@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110715191440.GA20715@rivendell.home.ouaza.com
 
Old 07-20-2011, 03:55 AM
Guillem Jover
 
Default Some upcoming dpkg changes, test and feedback welcome

Hi!

On Fri, 2011-07-15 at 21:14:40 +0200, Raphael Hertzog wrote:
> 1/ Makefile snippets for use in debian/rules
>
> http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=pu/makefile-snippets

Ok, so this is somewhat what I was proposing long time ago in
<http://lists.debian.org/debian-devel/2009/05/msg00044.html> .

I'd prefer to have the makefiles under scripts/mk/ (for example), as
those are definitely dpkg-dev specific, while the tables (which can
stay where they are now) can be eventually used by the C code.

I don't quite like the all-vars.mk name, but right now I cannot come
up with something better. The rest look good, matching the tool name
w/o the dpkg- prefix.

It probable makes sense to namespace vendor_derives_from with dpkg_.

> Should I also include some variables corresponding to changelog related
> variables ? If yes, we should certainly pick a set compatible with CDBS.
> DEB_SOURCE_PACKAGE
> DEB_VERSION
> DEB_NOEPOCH_VERSION
> DEB_UPSTREAM_VERSION
> DEB_DISTRIBUTION

I think it would be more useful to add support to retrieve specific
fields from dpkg-parsechangelog (for which we arelady have a wontfix
bug), and given that those should not really be overridable and I
think uncommonly used, they don't seem to belong on the makefiles.

> Note that the makefiles have been written in a way so that they do not
> result in useless forks for unused variables (thanks to Mike Hommey for
> the idea) and still ensure we run each command only once even if a
> variable is referenced multiple times.

Nice!

> I have also decided to not export the build flags in the environment by
> default. If the caller really wants this, he should set
> DPKG_EXPORT_BUILDFLAGS.

Why?

> 2/ dpkg-source --record-changes
>
> http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/master

The man pages command and option entries seem bogus, the italics and
roman fonts are inverted. The dashes for variable text should not be
escaped, escaping is only needed for literal strings that are for
example copy-and-pasted to a terminal.

> As discussed on debian-devel at the end of may, I have implemented
> some changes to source format 3.0 (quilt) so that a build fails if there
> are upstream changes which are not yet managed by quilt. Recording the
> change in a new quilt patch must now be done explicitly by the maintainer
> with dpkg-source --record-changes. This will require the user to give
> a patch name and an editor will be run to let the maintainer edit the
> patch header.

Did you consider naming it something like --commit instead?

> It required some important restructuring of the source package build
> procedure so I would be glad to have some more people running with this.
> Also you might have some input on the new interface.

It would be preferable in general to split refactoring from new
additional features so that reviewing is actually easier.

> 4/ We should really think of releasing 1.16.1 once those changes are
> merged. Guillem, do you have other things that you wanted to see merged
> for 1.16.1?

Yes, there are some pending changes I want to merge first, some
requirements for the other multiarch changes, but I don't want to
upload it as long as at least the the Build-Features stuff is on
master.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110720035530.GA20471@gaara.hadrons.org">http://lists.debian.org/20110720035530.GA20471@gaara.hadrons.org
 
Old 07-20-2011, 12:32 PM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

On Wed, 20 Jul 2011, Guillem Jover wrote:
> I'd prefer to have the makefiles under scripts/mk/ (for example), as
> those are definitely dpkg-dev specific, while the tables (which can
> stay where they are now) can be eventually used by the C code.

Ok.

> I don't quite like the all-vars.mk name, but right now I cannot come
> up with something better. The rest look good, matching the tool name
> w/o the dpkg- prefix.

full.mk? complete.mk? common.mk? default.mk? dpkg-vars.mk? build-vars.mk?

> It probable makes sense to namespace vendor_derives_from with dpkg_.

Right.

> I think it would be more useful to add support to retrieve specific
> fields from dpkg-parsechangelog (for which we arelady have a wontfix

This is #284664. I dropped the wontfix tag because I also agree
that it would be useful.

> bug), and given that those should not really be overridable and I
> think uncommonly used, they don't seem to belong on the makefiles.

I don't really see the logic behind that statement.

> > I have also decided to not export the build flags in the environment by
> > default. If the caller really wants this, he should set
> > DPKG_EXPORT_BUILDFLAGS.
>
> Why?

Because many people believe that the correct way to pass CFLAGS to the
build system is on the ./configure command line and not through the
environment.

And debian/rules doesn't know all variables that buildflags.mk might
set so it can't reliably call unexport on all variables. Instead it should
use a flag that controls the behaviour of buildvars.mk.

That said if you believe the correct default is to export the variables
I'm happy to reverse the test and ask people who don't want it in the
environment to set DPKG_DONT_EXPORT_BUILDFLAGS.

I really don't have any personal preference here.

> > As discussed on debian-devel at the end of may, I have implemented
> > some changes to source format 3.0 (quilt) so that a build fails if there
> > are upstream changes which are not yet managed by quilt. Recording the
> > change in a new quilt patch must now be done explicitly by the maintainer
> > with dpkg-source --record-changes. This will require the user to give
> > a patch name and an editor will be run to let the maintainer edit the
> > patch header.
>
> Did you consider naming it something like --commit instead?

Nope, good idea. Shorter, maybe not clearer for everybody but
definitely clearer for anyone with VCS experience.

> > It required some important restructuring of the source package build
> > procedure so I would be glad to have some more people running with this.
> > Also you might have some input on the new interface.
>
> It would be preferable in general to split refactoring from new
> additional features so that reviewing is actually easier.

I know. For some reasons, I did not manage it this time. Every time I
tried I got hit by further complications.

And I also like to have each pushed commit as "working" at least in
theory. I don't like to split commits if I know that it leaves flaws
in some of the intermediary commits.

> > 4/ We should really think of releasing 1.16.1 once those changes are
> > merged. Guillem, do you have other things that you wanted to see merged
> > for 1.16.1?
>
> Yes, there are some pending changes I want to merge first, some
> requirements for the other multiarch changes, but I don't want to
> upload it as long as at least the the Build-Features stuff is on
> master.

What about merging pu/build-arch and documenting the Build-Features:
build-arch as only useful if the auto-detection doesn't work or has bad
side effects? And explain that in any case, its usage should only last
for as long as the auto-detection remains in place, that is until all
Debian packages have been modified to provide the required targets.

The rebuild stats shown on the tech-ctte bug proved that this is a
sensible migration scenario.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110720123250.GD1107@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110720123250.GD1107@rivendell.home.ouaza.com
 
Old 07-20-2011, 12:51 PM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

On Wed, 20 Jul 2011, Raphael Hertzog wrote:
> > bug), and given that those should not really be overridable and I
> > think uncommonly used, they don't seem to belong on the makefiles.
>
> I don't really see the logic behind that statement.

Forgot to expand a bit: the version related variables are commonly used in
"get-orig-source" targets, and it would be nice to factor out the version
splitting logic.

The source package name is often the same as the name of the only
binary package and it's also relatively frequently used to avoid
hardcoding debian/packagename/ everywhere in the rules files.

Thus my personal preference would be to provide something to cover
those use cases.

I did put the distribution too because I have seen GNOME packages checking
that the distribution was really experimental to avoid unexpected uploads
to unstable. But this is really less frequent.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110720125128.GF1107@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110720125128.GF1107@rivendell.home.ouaza.com
 
Old 07-28-2011, 04:25 PM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

Hi,

On Wed, 20 Jul 2011, Guillem Jover wrote:
> > It required some important restructuring of the source package build
> > procedure so I would be glad to have some more people running with this.
> > Also you might have some input on the new interface.
>
> It would be preferable in general to split refactoring from new
> additional features so that reviewing is actually easier.

I made the effort to split the changes in several commits,
the new series is attached (and in my pu/master branch).

Reviews and tests are welcome.

> Yes, there are some pending changes I want to merge first, some
> requirements for the other multiarch changes, but I don't want to
> upload it as long as at least the the Build-Features stuff is on
> master.

Still waiting on your feedback to my other reply on this. Unfortunately
the tech-ctte has still not yet decided on this but it will likely happen
in the upcoming days.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
 
Old 07-29-2011, 02:31 PM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

On Wed, 20 Jul 2011, Raphael Hertzog wrote:
> Forgot to expand a bit: the version related variables are commonly used in
> "get-orig-source" targets, and it would be nice to factor out the version
> splitting logic.
>
> The source package name is often the same as the name of the only
> binary package and it's also relatively frequently used to avoid
> hardcoding debian/packagename/ everywhere in the rules files.
>
> Thus my personal preference would be to provide something to cover
> those use cases.

I attached a patch for this. I ended up diverging slightly on the
variable names to be more consistent.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
commit 1257e741acbf1d9df9068441e337c0b9a337d3a6
Author: Raphaël Hertzog <hertzog@debian.org>
Date: Fri Jul 29 16:18:52 2011 +0200

Provide a new makefile snippet exporting basic package information

diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index 710578d..784adf1 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -4,6 +4,7 @@ dist_pkgdata_DATA =
architecture.mk
buildflags.mk
default.mk
+ pkg-info.mk
vendor.mk

do_path_subst = $(AM_V_GEN)
diff --git a/scripts/mk/default.mk b/scripts/mk/default.mk
index 9f9d61b..b4b123c 100644
--- a/scripts/mk/default.mk
+++ b/scripts/mk/default.mk
@@ -4,4 +4,5 @@
dpkg_datadir = .
include $(dpkg_datadir)/architecture.mk
include $(dpkg_datadir)/buildflags.mk
+include $(dpkg_datadir)/pkg-info.mk
include $(dpkg_datadir)/vendor.mk
diff --git a/scripts/mk/pkg-info.mk b/scripts/mk/pkg-info.mk
new file mode 100644
index 0000000..b75f2ea
--- /dev/null
+++ b/scripts/mk/pkg-info.mk
@@ -0,0 +1,17 @@
+# Makefile snippet defining the following variables:
+#
+# DEB_SOURCE_PACKAGE: the source package name
+# DEB_VERSION: the full version of the package
+# DEB_VERSION_NOREV: the package's version without the Debian revision
+# DEB_VERSION_NOEPOCH: the package's version without the Debian epoch
+# DEB_VERSION_UPSTREAM: the package's upstream version
+# DEB_DISTRIBUTION: the first distribution of the current entry in debian/changelog
+
+dpkg_late_eval ?= $(or $(value DPKG_CACHE_$(1)),$(eval DPKG_CACHE_$(1) := $(shell $(2)))$(value DPKG_CACHE_$(1)))
+
+DEB_SOURCE_PACKAGE = $(call dpkg_late_eval,DEB_SOURCE_PACKAGE,awk '/^Source: / { print $$2 }' debian/control)
+DEB_VERSION = $(call dpkg_late_eval,DEB_VERSION,dpkg-parsechangelog | awk '/^Version: / { print $$2 }')
+DEB_VERSION_NOREV = $(call dpkg_late_eval,DEB_VERSION_NOREV,echo '$(DEB_VERSION)' | sed -e 's/-[^-]*$$//')
+DEB_VERSION_NOEPOCH = $(call dpkg_late_eval,DEB_VERSION_NOEPOCH,echo '$(DEB_VERSION)' | sed -e 's/^[0-9]*://')
+DEB_VERSION_UPSTREAM = $(call dpkg_late_eval,DEB_VERSION_UPSTREAM,echo '$(DEB_VERSION_NOREV)' | sed -e 's/^[0-9]*://')
+DEB_DISTRIBUTION = $(call dpkg_late_eval,DEB_DISTRIBUTION,dpkg-parsechangelog | awk '/^Distribution: / { print $$2 }')
 
Old 09-20-2011, 03:14 AM
Guillem Jover
 
Default Some upcoming dpkg changes, test and feedback welcome

On Wed, 2011-07-20 at 14:32:50 +0200, Raphael Hertzog wrote:
> On Wed, 20 Jul 2011, Guillem Jover wrote:
> > > I have also decided to not export the build flags in the environment by
> > > default. If the caller really wants this, he should set
> > > DPKG_EXPORT_BUILDFLAGS.
> >
> > Why?
>
> Because many people believe that the correct way to pass CFLAGS to the
> build system is on the ./configure command line and not through the
> environment.
>
> And debian/rules doesn't know all variables that buildflags.mk might
> set so it can't reliably call unexport on all variables. Instead it should
> use a flag that controls the behaviour of buildvars.mk.

Ok, that makes sense.

> That said if you believe the correct default is to export the variables
> I'm happy to reverse the test and ask people who don't want it in the
> environment to set DPKG_DONT_EXPORT_BUILDFLAGS.
>
> I really don't have any personal preference here.

I find having to define DPKG_EXPORT_BUILDFLAGS a bit ugly (less than
DPKG_DONT_EXPORT_BUILDFLAGS though). What about shifting completely
the responsibility to the includer over what specific variables to
export instead. As in:

-include /usr/share/dpkg/buildflags.mk

export CFLAGS CPPFLAGS CXXFLAGS LDFLAGS

? Some packages might need to do that in any case, so it seems like a
nicer interface, with a bit less magic and more explicit.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110920031445.GB19369@gaara.hadrons.org">http://lists.debian.org/20110920031445.GB19369@gaara.hadrons.org
 
Old 09-20-2011, 04:27 AM
Guillem Jover
 
Default Some upcoming dpkg changes, test and feedback welcome

On Fri, 2011-07-29 at 16:31:36 +0200, Raphael Hertzog wrote:
> On Wed, 20 Jul 2011, Raphael Hertzog wrote:
> > Thus my personal preference would be to provide something to cover
> > those use cases.
>
> I attached a patch for this. I ended up diverging slightly on the
> variable names to be more consistent.

Given that my remarks probably apply to most of the other make snippets
and variables, you went ahead anyway, and I cannot be bothered to argue
against this, I'll at least comment on the naming/implementation:

> +# DEB_SOURCE_PACKAGE: the source package name

Why DEB_SOURCE_PACKAGE instead of say, DEB_SOURCE? I guess it depends if
we want to map to field names or to more descriptive (although probably
redundant) variable names.

> +# DEB_VERSION: the full version of the package
> +# DEB_VERSION_NOREV: the package's version without the Debian revision
> +# DEB_VERSION_NOEPOCH: the package's version without the Debian epoch
> +# DEB_VERSION_UPSTREAM: the package's upstream version

These do not seem to have ended up being completely consistent,
there's a mix of variables listing what's missing, and variables
listing what's included. What about something like:

DEB_VERSION
DEB_VERSION_EPOCH_UPSTREAM
DEB_VERSION_UPSTREAM_REVISION
DEB_VERSION_UPSTREAM

instead?

> +# DEB_DISTRIBUTION: the first distribution of the current entry in debian/changelog

Why only the first, what makes it special? If there's multiple filter
can always be used.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110920042753.GA21313@gaara.hadrons.org">http://lists.debian.org/20110920042753.GA21313@gaara.hadrons.org
 
Old 09-21-2011, 06:35 AM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

On Tue, 20 Sep 2011, Guillem Jover wrote:
> I find having to define DPKG_EXPORT_BUILDFLAGS a bit ugly (less than
> DPKG_DONT_EXPORT_BUILDFLAGS though). What about shifting completely
> the responsibility to the includer over what specific variables to
> export instead. As in:
>
> -include /usr/share/dpkg/buildflags.mk
>
> export CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>
> ? Some packages might need to do that in any case, so it seems like a
> nicer interface, with a bit less magic and more explicit.

I would not like to have to hardcode the list of flag variables in
my own packages. IMO it's ok that some maintainers prefer to only export
a few of the variables whose impact has been carefully evaluated but
it should not be imposed. To me it makes sense that any new variable
exported by dpkg-buildflags get automatically used, much like it would
be if I had used the "./configure $(shell dpkg-buildflags
--export=configure)" approach.

So I prefer to keep the choice instead of dropping DPKG_EXPORT_BUILDFLAGS.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110921063501.GM4183@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110921063501.GM4183@rivendell.home.ouaza.com
 
Old 09-21-2011, 07:02 AM
Raphael Hertzog
 
Default Some upcoming dpkg changes, test and feedback welcome

On Tue, 20 Sep 2011, Guillem Jover wrote:
> > +# DEB_SOURCE_PACKAGE: the source package name
>
> Why DEB_SOURCE_PACKAGE instead of say, DEB_SOURCE? I guess it depends if
> we want to map to field names or to more descriptive (although probably
> redundant) variable names.

Yeah, for me the important keyword seemed to be "PACKAGE" but it was
confusing between source and binary so I ended up being specific with
SOURCE_PACKAGE but indeed DEB_SOURCE is ok given it maps to a field name.

Changed.

> > +# DEB_VERSION: the full version of the package
> > +# DEB_VERSION_NOREV: the package's version without the Debian revision
> > +# DEB_VERSION_NOEPOCH: the package's version without the Debian epoch
> > +# DEB_VERSION_UPSTREAM: the package's upstream version
>
> These do not seem to have ended up being completely consistent,
> there's a mix of variables listing what's missing, and variables
> listing what's included. What about something like:
>
> DEB_VERSION
> DEB_VERSION_EPOCH_UPSTREAM
> DEB_VERSION_UPSTREAM_REVISION
> DEB_VERSION_UPSTREAM
>
> instead?

Fine with me, changed.

> > +# DEB_DISTRIBUTION: the first distribution of the current entry in debian/changelog
>
> Why only the first, what makes it special? If there's multiple filter
> can always be used.

So that a simple equality test does a good approximation of what was
wanted in the few cases where there are multiple distributions. Because
simple equality test is what people are going to do since 99% of real life
usage in Debian implies a single distribution listed.

Otherwise everybody must always use filter and compare to the empty
string.

In the rare case where someone really wants the multiple distributions,
he can uses dpkg-parsechangelog directly.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110921070239.GN4183@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110921070239.GN4183@rivendell.home.ouaza.com
 

Thread Tools




All times are GMT. The time now is 07:11 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org