Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
[2018-11-01 23:22] Richard Ipsum > On Fri, 26 Oct 2018, at 02:47, Dmitry Bogatov wrote: > > > > [2018-10-23 23:53] Richard Ipsum > > > Fixed remaining issues, sorry this took me a while to get to. > > > I have uploaded a new version of the package to mentors. > > > > Looks incredible clean, but I still found one issue :) > > > > The package your does not follow multiarch path conventions. > > For example, for libyaml-dev > > [...] > thanks for the feedback, I'm afraid I will be away for some time, so > it may be several weeks before I'm able to look at f ixing this. Any progress?
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
On Fri, 26 Oct 2018, at 02:47, Dmitry Bogatov wrote: > > [2018-10-23 23:53] Richard Ipsum > > Fixed remaining issues, sorry this took me a while to get to. > > I have uploaded a new version of the package to mentors. > > Looks incredible clean, but I still found one issue :) > > The package your does not follow multiarch path conventions. > For example, for libyaml-dev > > /usr/lib > /usr/lib/x86_64-linux-gnu > /usr/lib/x86_64-linux-gnu/libyaml.a > /usr/lib/x86_64-linux-gnu/pkgconfig > /usr/lib/x86_64-linux-gnu/pkgconfig/yaml-0.1.pc > /usr/lib/x86_64-linux-gnu/libyaml.so > > Since the package does not use autotools, I am afraid you will have to > tinker with `override_dh_autoinstall' manually. thanks for the feedback, I'm afraid I will be away for some time, so it may be several weeks before I'm able to look at fixing this. Thanks, Richard
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
[2018-10-23 23:53] Richard Ipsum > Fixed remaining issues, sorry this took me a while to get to. > I have uploaded a new version of the package to mentors. Looks incredible clean, but I still found one issue :) The package your does not follow multiarch path conventions. For example, for libyaml-dev /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libyaml.a /usr/lib/x86_64-linux-gnu/pkgconfig /usr/lib/x86_64-linux-gnu/pkgconfig/yaml-0.1.pc /usr/lib/x86_64-linux-gnu/libyaml.so Since the package does not use autotools, I am afraid you will have to tinker with `override_dh_autoinstall' manually.
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
On Sun, 21 Oct 2018, at 06:50, Gergely Nagy wrote: > Hi! > > I just had a quick look at the libtheft packaging on mentors, and > noticed a few things that at the moment, prevent me from sponsoring the > package. These are: Hi! thanks for reviewing this! > > - I was unable to find the public part of your GPG key, thus, was unable > to verify the signature on the source package. Where can one find it? GPG key has now been uploaded to default keyservers, key id is 3D3239533DAE7F5A9D322B7C52322452F1C90E1E > (Uploading it to a public key server might be best). > - The package build-depends on `debhelper-compat (= 11)`, which works, > but it's a virtual package. I'd suggest build-depending on `debhelper > (>= 11)`, and adding a `debian/compat` file with "11" as its content. skipping as discussed > This will get rid of one of the warnings on mentors, too. > - debian/copyright does not document the license of `src/theft_hash.c` > (public domain, but that needs to be documented too). fixed > - debian/copyright does not document the license and author of > `debian/*`. In most cases - and theft is no exception - the Debian > packager is not the upstream author. If unspecified, the `*` wildcard > applies to `debian/*` too, which would be incorrect. fixed > - The control file does not set a Homepage - a minor thing, but while > fixing the other issues, might as well fix this one, and point the > Homepage field in debian/control to theft's GitHub. fixed > > Other than these, the package looks ok. Can you fix the above? > > Drop me an email when done, and I'll have another look. Fixed remaining issues, sorry this took me a while to get to. I have uploaded a new version of the package to mentors.
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
> "Paul" == Paul Wise writes: Paul> On Sun, Oct 21, 2018 at 1:54 PM Gergely Nagy wrote: >> - The package build-depends on `debhelper-compat (= 11)`, which works, >> but it's a virtual package. I'd suggest build-depending on `debhelper >> (>= 11)`, and adding a `debian/compat` file with "11" as its content. >> This will get rid of one of the warnings on mentors, too. Paul> debhelper-compat is the new replacement for debian/compat that aims to Paul> get rid of the repetition of the debhelper compat level in two places Paul> and is also nicer for backporters than the debhelper dep you Paul> suggested. Ah, my bad. I checked debhelper(7) when I saw it, but forgot that I'm on testing, not unstable. Indeed, the build-depends is fine then as it is. Thanks! -- |8]
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
On Sun, Oct 21, 2018 at 1:54 PM Gergely Nagy wrote: > - The package build-depends on `debhelper-compat (= 11)`, which works, > but it's a virtual package. I'd suggest build-depending on `debhelper > (>= 11)`, and adding a `debian/compat` file with "11" as its content. > This will get rid of one of the warnings on mentors, too. debhelper-compat is the new replacement for debian/compat that aims to get rid of the repetition of the debhelper compat level in two places and is also nicer for backporters than the debhelper dep you suggested. https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS -- bye, pabs https://wiki.debian.org/PaulWise
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
Hi! I just had a quick look at the libtheft packaging on mentors, and noticed a few things that at the moment, prevent me from sponsoring the package. These are: - I was unable to find the public part of your GPG key, thus, was unable to verify the signature on the source package. Where can one find it? (Uploading it to a public key server might be best). - The package build-depends on `debhelper-compat (= 11)`, which works, but it's a virtual package. I'd suggest build-depending on `debhelper (>= 11)`, and adding a `debian/compat` file with "11" as its content. This will get rid of one of the warnings on mentors, too. - debian/copyright does not document the license of `src/theft_hash.c` (public domain, but that needs to be documented too). - debian/copyright does not document the license and author of `debian/*`. In most cases - and theft is no exception - the Debian packager is not the upstream author. If unspecified, the `*` wildcard applies to `debian/*` too, which would be incorrect. - The control file does not set a Homepage - a minor thing, but while fixing the other issues, might as well fix this one, and point the Homepage field in debian/control to theft's GitHub. Other than these, the package looks ok. Can you fix the above? Drop me an email when done, and I'll have another look. -- |8]
Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libtheft" * Package name: libtheft Version : 0.4.5-1 Upstream Author : Scott Vokes * URL : https://github.com/silentbicycle/theft * License : ISC Section : libs It builds those binary packages: libtheft-dev - property-based testing for C To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libtheft Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libt/libtheft/libtheft_0.4.5-1.dsc More information about libtheft can be obtained from https://github.com/silentbicycle/theft and https://yakking.branchable.com/posts/property-testing-in-c/. Changes since the last upload: libtheft (0.4.5-1) unstable; urgency=medium * Initial release (Closes: #910296) -- Richard Ipsum Thu, 04 Oct 2018 18:07:05 +0100 Regards, Richard Ipsum
