Bug#662632: RFS: libaio-ocaml/1.0~rc1
Benoît Knecht <benoit.knecht@fsfe.org> writes:
> retitle 662632 RFS: libaio-ocaml/1.0~rc1 [ITP] -- OCaml bindings for libaio
> tags 662632 moreinfo
> thanks
>
> Hi Goswin,
>
> Goswin von Brederlow wrote:
>> I am looking for a sponsor for my package "libaio-ocaml"
>>
>> * Package name : libaio-ocaml
>> Version : 1.0~rc1
>> Upstream Author : Goswin von Brederlow <goswin-v-b@web.de>
>> * URL : http://forge.ocamlcore.org/projects/libaio-ocaml/
>> Vcs-Git : git://anonscm.debian.org/pkg-ocaml-maint/packages/libaio-ocaml.git
>> Vcs-Browser : http://anonscm.debian.org/git/pkg-ocaml-maint/packages/libaio-ocaml.git
>
> Vcs-Browser should link to something browsable, like a gitweb or
> something, if it exists.
Oh, I copied that from the browsable webpage itself not realizing that
it was a raw view. Fixed. Going to upload 1.0~rc2 after this mail.
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/libaio-ocaml.git
>> * License : LGPL-2.1+ and link execpetion
>> Section : ocaml
>>
>> It builds those binary packages:
>>
>> libaio-ocaml - OCaml bindings for libaio (Linux kernel AIO access library)
>> libaio-ocaml-dev - OCaml bindings for libaio (Linux kernel AIO access library)
>
> You should open an ITP bug and close it in the debian/changelog [1].
Given that I am upstream, currently the only user of it and the package
is hosted in the ocaml maintainers git I do not think there is a risk of
anyone else packaging this as well. Didn't feel like writing an ITP just
to raise the ITP count from 1120 to 1121 for a few days when the
packaging is done and just pending cosmetic changes.
But if that is stopping sponsorship I can certainly write one.
>> To access further information about this package, please visit the following URL:
>>
>> http://mentors.debian.net/package/libaio-ocaml
>
> This page shows a few issues already that you should also fix: no watch
> file, duplicate short description, and no debian version (i.e. package
> is native).
I've already fixed the duplicate short description in git, the only info
I consider valid problem there.
The package is native because I am both maintainer and upstream
author. Does a watch file make sense for a native package?
I've tried for a while to maintain the package with split upstream and
debian git repositories but it just causes so much extra work for no
real benefit. Every upstream change needs to be commited, pulled to the
upstream branch of the debian git, merged into master, build, test,
repeat. Besides being extra work for nothing it also seriously disrupts
my workflow and prevents the use of for example "git commit --amend".
You can no longer just play with the source till it works and then
commit in an orderly fashion.
> [1] http://www.debian.org/devel/wnpp/
>
> Cheers,
>
> --
> Benoît Knecht
MfG
Goswin
Reply to: