Re: RFS: stripclub - Online Comic Reader/Archiver
Brian Nelson wrote:
My first attempt to do this kinda blundered it, obviously... I tried to
retitle it by sending a message to email@example.com, but it
doesn't seem to have worked. I'm supposed to get at least an error
response if I get it wrong, aren't I?
Benjamin Cutler <firstname.lastname@example.org> writes:
After dinking around with the build tools for a bit, I'm reasonably sure
this is put together correctly, so here goes.
I'm looking for a sponsor for my package stripclub, an online comic
reader and archiver. It supports the vast majority of webcomics so far
tested, though a few kinks still exist, mostly dealing with server
oddities. The package was built with pbuilder (sid), and is lintian
I see a few problems:
* You should change the RFP for stripclub to an ITP (just change the bug
title), and then close the bug in the changelog.
So I should change the "company name" to my name? Or do you mean I
should be more clear on the GPL?
* Your debian/copyright is lacking a bit. See
for more info.
Is this something that just entails changing the number (which I just
did, if that's all...), or does my package somehow violate a new standard?
* Standards-Version is out of date
* The short description is a little long for my tastes. It seems it
could be phrased more concisely. Also, the long description is rather
poorly written. It contains incomplete sentences, and the use of
acronyms like FLTK should be avoided. See section 6.2 of the
* The debian/rules file contains a lot of commented out commands left
over from the dh_make template. It's best to clean it up and remove
commands that will never be used.
* The debian/stripclub.doc-base.EX file should be removed. It's just a
dh_make example file.
Done. Thought I got all those, oops. (Isn't lintian supposed to catch that?)
Is this an actual problem, or a matter of taste? If it's the latter, I
don't really see a need to change it...
* The upstream optimization flags look retarded. "-O3
-fomit-frame-pointer -funroll-loops"? What is that about? This isn't
Hmm, that seems a little odd. I'll fiddle with my internal packaging
script and have it make both bz2 and gz, uupdate was spitting a warning
at me about "unable to preserve pristine sources from non-gz", guess it
wasn't something I can just ignore.
* The md5sums don't match the upstream tarball. It looks like upstream
distributes the file as a bz2, so the .orig.tar.gz can't match, but
the .tar file inside should still be identical.
Updated files available at the same URL.