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

Bug#738920: RFS: obsession/20130822-1 [ITP] -- Session management helpers for lightweight desktop environments



Hi Eriberto,

On 16/02/2014 13:24, Eriberto wrote:
> I checked your package. Note that I want help you improve your package
> but I can upload it. 
And that's much appreciated.

My considerations:
> 
> d/changelog: the initial realease is your first work in the package.
> So, d/changelog must have only 'Initial release (Closes: #731278)'.
Ok, I suppose the changes I was mentioning in the changelog are to be
put in the README.source.

> d/copyright: I suggest you put all licenses grouped at the end of the
> file. This will provide a better organization.
Thank you, I wasn't even hoping such a thing could be DEP-5 compliant,
but it is mentioned in section "Stand-alone License Paragraph (Optional,
Repeatable)"
I'm so unused to good standards…

> d/docs: remove AUTHORS. The authors must be put in d/copyright only.
Ok.

> d/patches: replicate d/changelog parts in patches headers is unusual.
> Please, fix this.
Ok (that's dpkg-source --commit works, I assumed it was good practice
since the patches are related to the content of the changelog). But it
indeed doesn't make much sense since there are other fields to add
details into the patch.

> d/patches/copyright: is unusual fix the copyright notices in upstream
> code. I suggest to remove it.
Ok. Anyway, the patch has been forwarded upstream, who told me he'll try
to apply it ASAP.


> d/README.source: must be used to list modifications that you made,
> definitely, in the upstream source code.
So that doesn't include patches or does it?


> d/rules: remove the unecessary comments, as '# -*- makefile -*-', '#
> Uncomment this to turn on verbose mode.' and '# This has to be
> exported to make some magic below work.'. I also suggest you add
> '--parallel' to 'dh $@'.
Ok.

> Building, I can see some lintian warnings. Please, see
> http://eriberto.pro.br/blog/?p=1289
I've seen the remaining I and P issues (I'm always running lintian on
both the source and the binary with options --pedantic --show-overrides
--display-info --display-experimental --color auto -i):
- one P about upstream changelog missing. I could try to dump "git log«
of his repository, but would that make the package better?
- one P about sources not being gpg-checkable. I'm afraid I can't do
much here. Except maybe asking upstream to sign his tarballs… Wouldn't
that be a bit pedantic for a project hosted by bitbucket?
- two I about hardening-no-fortify-functions. I admit I haven't tried to
solve this one, but I'm sure tho CPPFLAGS are given to the C++ compiler.
So I assumed it was a false-positive.

> I hope this help.
It does. :)

I'll upload a new version as soon as I'll have taken those remarks into
account.

Regards,

-- 
captnfab


Reply to: