[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: stripclub - Online Comic Reader/Archiver



Benjamin Cutler <cutler@cs.colostate.edu> writes:

> Brian Nelson wrote:
>
>>Benjamin Cutler <cutler@cs.colostate.edu> 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
>>>clean.
>>>
>>>
>>
>>* Your debian/copyright is lacking a bit.  See
>>  http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200312/msg00007.html
>>  for more info.
>>
>>
> So I should change the "company name" to my name? Or do you mean I
> should be more clear on the GPL?

Oops, I didn't realize you're also the upstream author.  That makes the
copyright more OK than I realized.  Still, you should include more on
the GPL (versioning, etc.), like in the example in that email.

>>* Standards-Version is out of date
>>
> 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?

Normally you create a package using the current policy version as a
guideline, and then keep it up to date by following
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz .  Often, it's
OK to just increase the number, but always check the checklist first.

>>* The upstream optimization flags look retarded.  "-O3
>>  -fomit-frame-pointer -funroll-loops"?  What is that about?  This isn't
>>  gentoo...
>>
> 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...

They're overly aggressive.  -fomit-frame-pointer makes debugging
virtually impossible AIUI, and -funroll-loops makes the code larger (and
likely slower due to more CPU cache misses).  Also, Debian Policy states
you should include -g to include debugging information.  Specifically,
it says:

     For the C programming language, this means the following
     compilation parameters should be used:

          CC = gcc
          CFLAGS = -O2 -g -Wall

though -O3 is probably OK in most cases.  You should keep the
optimizations options as conservative as possible, unless you really
know what you're doing.  If your programs runs too slowly, you'll likely
be able to get a far greater performance increase with no downsides from
optimizing the code (after narrowing down the problem areas with a
profiler) rather than relying on the often buggy advanced GCC
optimizations.

>>* 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.
>>
> 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.

Well, if you're also the upstream packager, keeping the upstream tarball
pristine is less meaningful, so it's probably not much to worry about.

-- 
You win again, gravity!



Reply to: