RFS: cl-launch (updated package)

[Faré]

tl;dr: can one of the regular CL package uploaders upload the package as is?

>> I am looking for a sponsor for the new version 4.1.4-1
>> of my package "cl-launch".
>> - URL: http://mentors.debian.net/debian/pool/main/c/cl-launch
>> - Source repository: deb-src http://mentors.debian.net/debian unstabl
>> e
>> main contrib non-free
>>  - dget http://mentors.debian.net/debian/pool/main/c/cl-launch/cl
>> -launch_4.1.4-1.dsc

On Wed, Jul 22, 2015 at 2:15 AM, Tobias Frost <tobi at debian.org> wrote:
> Here's a review, but incomplete as I only have a few minutes.
> (Maybe someone jumps in as well)
>
Thanks!

> I see that your package has several DDs a uploaders. I'm wondering why
> they don't upload it for you, if they co-maintain the package?
>
Well, they have uploaded the package in the past, but are only loosely
"co-maintaining" the package.

> Did you file an RFS-Bug?
>
I didn't know I had to do that. I thought that sending a mail to
debian-mentors@ was what the RFS was about.

> In d/changelog, there are many versions that where never in Debian,
> also it reads more like an upstream changelog than an Debian changelog.
> On the other side, changes to debian/* are not explained. (e.g the fact
> and the resons why to update all the versions of the dependencies in
> d/control). Refer to the Policy about d/changelog.
>
I admit I've been using d/changelog as a general changelog for cl-launch.
I probably should change that in the future.

> d/compat is 7, mind to upgrade the package to compat level 9?
>
I've increased it for the next package attempt.

> d/cl-launch.1 The manpage says "generated with Ronn/v0.7.3".
> If it is autogenerated, it needs to be done at build time.
>
Problem is, the current release script that does the manpage
generation is written in Lisp, and depends on various libraries that
haven't been packaged for debian yet. They are only required to
extract the manpage, and not otherwise required at either build time
or runtime.

> d/control
> You do not have a VCS-Browser tag
Added.

> About your layout: It is not recommended,  to have the debian directory
> in your master branch, as you cannot independently work on those.
> Think of NMUs and how you would be able to integrate such changes in
> your repository? (I suggest to put the debian packaging into its own
> branch.)
> This is also the point where I point people to
> https://wiki.debian.org/UpstreamGuide, if they are upstream and
> maintainer at the same time.
>
Considering the extreme difficulty I have with getting my package
uploaded, I think the likeliness of a NMU is about zero. But if and
when someone wants to do it, then it's still time to patch the debian
packaging. That said, yes, it would be great. But I would have to
learn how to use git-buildpackage properly and build from separate
branches, and update the release script.

> d/rules could be transformed to short debhelper format.
>
I tried that and failed utterly.

> (note: did not check alls details in d/copyright, so just a few things
> I saw at first glance)
> d/copyright:
> - The bugroff license text is missing.
I added it for next attempt.

> - Copyright years are not up to date
Interestingly, lawyers at $BIG_COMPANY_EMPLOYER have recently opined
that the year the software was started is the only one needed on
copyright statements.

> Ok, have to go now.
>
Thanks a lot for the feedback.

The current package is not perfect but is already better than what is
in debian unstable. Can some uploader upload it as is?

And if someone cares to make it perfect (Kambiz?), can you rework the packaging?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Demand the establishment of the government in its rightful home at Disneyland.