Re: bugs and patches in Debian
so I have added the stuff to CPANTS.
A couple of notes before celebrating:
1) There are only 778 rows in the csv file I am downloading, I am sure
there are more
CPAN packages in Debian. Are all those out in the dark?
2) There is a patch for Text::CSV_XS but the links I could generate
(see further down in this message)
are broken. At least the ones I tried. How should I do them?
http://packages.debian.org/source/libtext-csv-xs-perl tells me
Sorry, your search gave no results
(redirected from http://packages.qa.debian.org/)
gets me to this page http://packages.qa.debian.org/t/text-csv-xs.html
which gives me 404 error
On Thu, May 22, 2008 at 2:44 AM, Martín Ferrari
> On Wed, May 21, 2008 at 4:31 PM, Gabor Szabo <firstname.lastname@example.org> wrote:
>> Please, with all the discussion about the details and how to make it perfect,
>> don't forget to start generating some data so I can start working on
>> integration with CPANTS.
> Worry no more :)
> I have prepared a _draft_ dump script that outputs the following
> fields in CSV format:
> debian_pkg, CPAN_dist, CPAN_vers, N_bugs, N_patches
> It is updated hourly with a cronjob at:
> Since you have the debian package name, the homepage, source code for
> patches, bug pages, etc. can all be generated automatically. So I left
> them out of the report.
> Basic homepage: http://packages.debian.org/src:$pkgname
> Detalied homepage: http://packages.qa.debian.org/$pkgname
> Bugs report: http://bugs.debian.org/src:$pkgname
> Public SVN repository: http://svn.debian.org/wsvn/pkg-perl/trunk/$pkg
> From that last URL, you might be interested in the debian/ and
> debian/patches subdirectories.
> And many more pages that Debian auto-generates...
> - CPAN_dist is inferred from the download location, for our packages
> it works 99% of the time, but it is not completely reliable. If it
> fails to detect something, it will spit out the known download
> - CPAN_vers is inferred from the debian version. This fails a lot,
> since we have a mechanism for "unmangling" upstream versions which is
> non-reversible. We have to use that many times to fix versioning
> problems, and those packages will show a different version (e.g. 1.080
> vs 1.80)
> The first problem is something I'd like to solve by adding metadata to
> our packages, for many other useful stuff (like automatic upstream bug
> tracking and handling). About the second... well, it's a difficult
> Well, hope this serves as a first working draft, even with all the
> present caveats.
> Regards, Tincho.
> Martín Ferrari