Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
Hi Gianfranco On 17.08.2015 at 16:41 Gianfranco Costamagna wrote: > 1) > > # upstream does not sign releases > #yadifa source: debian-watch-may-check-gpg-signature That is a commented out leftover. I have removed it anyway so other won't think it is still used like you ;-) > 2) sbin/yadifad/install-sh > > not mentioned in copyright > (and every install-sh on the source tree) Ah, well spotted. I added the (hopefully correct) license paragraph to debian/copyright. > the other stuff looks good to me Great. Thanks for the review. New version is on mentors.d.n Best regards, Markus
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
Control: owner -1 ! Hi Markus, Following my review: 1) # upstream does not sign releases #yadifa source: debian-watch-may-check-gpg-signature ls upstream/signing-key.asc upstream/signing-key.asc which one is correct? 2) sbin/yadifad/install-sh not mentioned in copyright (and every install-sh on the source tree) the other stuff looks good to me cheers, Gianfranco
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
Hi everyone, On 16.08.2015 at 22:53 Jakub Wilk wrote: > * Christian Kastner , 2015-08-16, 19:08: >> debian/rules: >> - I believe the "export DH_OPTIONS [...] to make magic work" can be >> dropped. I think this is a remnant from a time long past; I can't find >> any reference to this in recent documentation. dh(1), for example, >> makes no mention of this. Second opinions welcome... > > Right. It's no-op when you export DH_OPTIONS but never set it. Okay, I have made all suggested changes, rebuild the 2.1.1 release and uploaded it to mentors. http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.1.1-1.dsc Yes, that is not the latest upstream version, but that one does not segfault. So I'd rather introduce a working, but not latest, version into Debian than a broken one. Best regards, Markus
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
* Christian Kastner , 2015-08-16, 19:08: debian/rules: - I believe the "export DH_OPTIONS [...] to make magic work" can be dropped. I think this is a remnant from a time long past; I can't find any reference to this in recent documentation. dh(1), for example, makes no mention of this. Second opinions welcome... Right. It's no-op when you export DH_OPTIONS but never set it. Also, debhelper manpage says: "When using dh(1), it can be passed options that will be passed on to each debhelper command, which is generally better than using DH_OPTIONS." For the curious, the origin of the "export DH_OPTIONS" pattern is this d/rules example, where it was indeed required to make things work: https://sources.debian.net/src/debhelper/8.0.0/examples/rules.multi2/ dh-make include similar d/rules skeletons, too. -- Jakub Wilk
Re: Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
On 2015-08-16 13:43, Jakub Wilk wrote: > * Christian Kastner , 2015-08-15, 23:57: The Vcs-Git URL should use the git:// protocol specifier, and you could add a Vcs-Browser URL pointing to the github package, like so: -Vcs-Git: https://github.com/asciiprod/yadifa.git +Vcs-Git: git://github.com/asciiprod/yadifa.git >>> >>> The original URL is clone'able by git, too. >>> So what's wrong with using HTTPS in Vcs-Git? >> >> lintian complained about vcs-field-not-canonical, IIRC > > I don't think it did. vcs-field-not-canonical, as currently implemented, > is only about Alioth URLs. I could have sworn that my initial comment was triggered by a lintian warning, but trying to produce anything else with an older version of lintian yielded nothing either. Therefore, I'm definitely misremembering something, and looking at the policy, I see no such restriction, so my initial comment was wrong.
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
Hi Markus, On 2015-06-05 13:52, Markus Schade wrote: > New package for yadifa 2.1.0 is available > > http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.1.0-1.dsc > > It would be great if someone could sponsor this package. I think > the history of this bugreport proves that the package is well > maintained. And it is much better than upstream referencing my github > repo as the canonical way to get yadifa to run on Debian/Ubuntu. I just checked your package and I think that it is almost ready for upload. Here are just a few minor points: debian/copyright: - lintian complains about non-unique license specifications. Applying the pattern from Example #2 of [1] should resolve this issue. debian/control: - You can drop the version restriction for dpkg-dev. The version in oldstable (wheezy) is already higher. debian/changelog: - Please remove all entries except the newest one which documents the initial release. debian/yadifa.default debian/yadifa.service: - AFAIUI, when using systemd, the contents of /etc/default/yadifa will be ignored. This might be a problem for users switching from sysvinit to systemd later on. If they changed the default, eg by changing the location of the configuration file, this change will no longer be honored after the systemd switch. One way you can address this problem is by using EnvironmentFile in the service file. The cron package does it that way, for example. debian/rules: - I believe the "export DH_OPTIONS [...] to make magic work" can be dropped. I think this is a remnant from a time long past; I can't find any reference to this in recent documentation. dh(1), for example, makes no mention of this. Second opinions welcome... [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph Regards, Christian signature.asc Description: OpenPGP digital signature
Re: Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
* Christian Kastner , 2015-08-15, 23:57: The Vcs-Git URL should use the git:// protocol specifier, and you could add a Vcs-Browser URL pointing to the github package, like so: -Vcs-Git: https://github.com/asciiprod/yadifa.git +Vcs-Git: git://github.com/asciiprod/yadifa.git The original URL is clone'able by git, too. So what's wrong with using HTTPS in Vcs-Git? lintian complained about vcs-field-not-canonical, IIRC I don't think it did. vcs-field-not-canonical, as currently implemented, is only about Alioth URLs. -- Jakub Wilk
Re: Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
On 2015-08-15 16:17, Jakub Wilk wrote: > * Christian Kastner , 2014-04-09, 20:50: >> The Vcs-Git URL should use the git:// protocol specifier, and you >> could add a Vcs-Browser URL pointing to the github package, like so: >> >> -Vcs-Git: https://github.com/asciiprod/yadifa.git >> +Vcs-Git: git://github.com/asciiprod/yadifa.git > > The original URL is clone'able by git, too. > So what's wrong with using HTTPS in Vcs-Git? lintian complained about vcs-field-not-canonical, IIRC (although admittedly, it's just an informational tag).
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
* Christian Kastner , 2014-04-09, 20:50: The Vcs-Git URL should use the git:// protocol specifier, and you could add a Vcs-Browser URL pointing to the github package, like so: -Vcs-Git: https://github.com/asciiprod/yadifa.git +Vcs-Git: git://github.com/asciiprod/yadifa.git The original URL is clone'able by git, too. So what's wrong with using HTTPS in Vcs-Git? -- Jakub Wilk
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
On 03/05/2015 04:32 PM, Paul Wise wrote: > On Thu, 2015-03-05 at 16:24 +0100, Markus Schade wrote: >> And I have asked them to do so, of course. Likewise with the other >> things you mentioned (e.g. signing their releases). > > Ah, good. I wasn't sure if you had done that, sorry. > >> My point is that I cannot make upstream do any of it. > > Ack. Nagging upstream has paid off and they have started signing their releases. New package for yadifa 2.1.0 is available http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.1.0-1.dsc It would be great if someone could sponsor this package. I think the history of this bugreport proves that the package is well maintained. And it is much better than upstream referencing my github repo as the canonical way to get yadifa to run on Debian/Ubuntu. Best regards, Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55718d81.9070...@gmail.com
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
On Thu, 2015-03-05 at 16:24 +0100, Markus Schade wrote: > Yes, I know that. ;-) > And I have asked them to do so, of course. Likewise with the other > things you mentioned (e.g. signing their releases). Ah, good. I wasn't sure if you had done that, sorry. > My point is that I cannot make upstream do any of it. Ack. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
On 03/05/2015 04:16 PM, Paul Wise wrote: > On Thu, Mar 5, 2015 at 10:32 PM, Markus Schade wrote: > You could forward the code quality issues upstream as suggested by the > Debian social contract: > > https://www.debian.org/social_contract Yes, I know that. ;-) And I have asked them to do so, of course. Likewise with the other things you mentioned (e.g. signing their releases). My point is that I cannot make upstream do any of it. Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f87539.60...@gmail.com
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
On Thu, Mar 5, 2015 at 10:32 PM, Markus Schade wrote: > But then again, I am just the packager not the developer. So I can do > little about the code quality. You could forward the code quality issues upstream as suggested by the Debian social contract: https://www.debian.org/social_contract -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6ecw3py4w7zuh1zpd8ew+nzw1fzwumu16ofmbahjjd...@mail.gmail.com
Bug#683120: RFS: yadifa/2.0.5-1 [ITP]
Dear Paul, dear mentors, Thank you for your extensive review. I won't go into detail for every item you have mentioned, but I believe that many if not most issues have been dealt with. But then again, I am just the packager not the developer. So I can do little about the code quality. All of my patches are now upstream, even though they are still not signing their releases (I haven't got an answer as to why). I will leave the internal libraries as static until they are stable. So far nothing outside of yadifa can or should use them. So, to sum things up, I am again looking for a sponsor for "yadifa". Now with the new release 2.0.5 YADIFA is a "Yet Another DNS Implementation For All", a DNS server written by the people of the EURid registry. The URL of the package is: http://mentors.debian.net/package/yadifa The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.0.5-1.dsc Kind regards, Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f868f3.7090...@gmail.com
Bug#683120: RFS: yadifa/2.0.0-1 [ITP]
On Tue, Nov 25, 2014 at 10:41 PM, Markus Schade wrote:
> http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.0.0-1.dsc
I don't intend to sponsor this but here is a quick review...
> I have been able to establish contact with upstream and while the
> website may not be updated frequently the next release (2.1.0) is
> scheduled at the beginning of 2015.
Have they integrated your patches and systemd support upstream?
Have you asked them to sign their releases with OpenPGP? The comment
in debian/source/lintian-overrides doesn't make it clear. I don't
think it is a good idea to override the lintian complaint unless they
specifically rejected doing that.
I note that upstream doesn't appear to have a public version control
repository, have you asked them about that?
I noticed you added a systemd service file. The most recent Misc
Developer News included a section about improving security of services
under systemd, you might want to take a look at the talk mentioned in
it and the associated documentation (the systemd.exec manual page).
https://lists.debian.org/debian-devel-announce/2014/11/msg00015.html
I don't think there is any need to guard use of invoke-rc.d with pidof
in your maintainer scripts. I would recommend using the standard
things generated by dh_installinit.
I believe that Debian discourages removal of system users on purge.
I suggest using _yadifa as the system username to avoid conflict with
real users. Another alternative might be Debian-yadifa.
I suggest switching to debian/compat 9, then you won't need the
buildflags stuff in debian/rules since dh will do it for you.
Please rebuild the build system during package build by
build-depending on dh-autoreconf instead of autotools-dev and using dh
--with autoreconf instead of dh --with autotools-dev.
Please ask upstream to change the libraries from static to shared,
static libraries mean more work for Debian in identifying things that
need rebuilding etc.
You might want to run wrap-and-sort -sa to make diffs of debian/ more
readable when doing things like adding dependencies.
There appears to be a tmpfile vulnerability in
lib/dnscore/src/server-setup.c when the code is compiled with DEBUG
set. This is a minor issue but I would suggest it should be fixed
nevertheless.
Given the cppcheck output below you might want to run a fuzzer like
zzuf to ensure there are no lurking vulnerabilities.
Automated checks:
https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git
$ cme check dpkg
...
Warning in 'control binary:yadifa Depends:5' value 'lsb-base (>=
3.2-14)': unnecessary versioned dependency: lsb-base >= 3.2-14. Debian
has squeeze -> 3.2-23.2squeeze1; wheezy -> 4.1+Debian8+deb7u1; jessie
-> 4.1+Debian13+nmu1; sid -> 4.1+Debian13+nmu1;
checking data
Warning in 'patches:"fix-yadifa-manpage.patch" Synopsis' value
: Empty synopsis (code is: 'defined $_ && /\w/ ? 1 : 0 ;')
Warning in 'patches:"fix-yadifad-manpage.patch" Synopsis' value
: Empty synopsis (code is: 'defined $_ && /\w/ ? 1 : 0 ;')
Warning in 'patches:"fix-yadifad.conf-manpage-whatis.patch" Synopsis'
value : Empty synopsis (code is: 'defined $_ && /\w/ ? 1 : 0
;')
...
$ codespell --quiet-level=3
$ cppcheck -j1 --quiet -f .
[bin/yadifa/query-result.c:89]: (error) syntax error
[lib/dnscore/src/dnscore.c:134]: (error) Possible null pointer dereference: msg
[lib/dnscore/src/dnscore.c:135]: (error) Possible null pointer dereference: msg
[lib/dnscore/src/logger_channel_syslog.c:101]: (error) Buffer is
accessed out of bounds.
[lib/dnscore/src/logger_channel_syslog.c:122]: (error) Buffer is
accessed out of bounds.
$ find -type f \( -iname '*.c' -o -iname '*.cc' -o -iname '*.cxx' -o
-iname '*.cpp' -o -iname '*.h' -o -iname '*.hh' -o -iname '*.hxx' -o
-iname '*.hpp' \) -exec include-what-you-use {} \;
$ uscan --report-status
Processing watchfile line for package yadifa...
Newest version on remote site is 1.0.3, local version is 2.0.0
yadifa: remote site does not even have current version
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caktje6h2rj0ssozu1o_hkqognyhzmedjrcey9x-vo6trzrw...@mail.gmail.com
Bug#683120: RFS: yadifa/2.0.0-1 [ITP]
Dear mentors, I am again looking for a sponsor for my package "yadifa". Now with the new release 2.0.0 YADIFA is a "Yet Another DNS Implementation For All", a DNS server written by the people of the EURid registry. The URL of the package is: http://mentors.debian.net/package/yadifa The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.0.0-1.dsc I have been able to establish contact with upstream and while the website may not be updated frequently the next release (2.1.0) is scheduled at the beginning of 2015. Kind regards, Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54749520.5090...@gmail.com
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
On 04/09/2014 09:00 PM, Christian Kastner wrote:
> Oh, I missed something here: you are using the substitution variable
> ${Description}, but you are not setting it anywhere, which results in
> half-empty descriptions (see the output in
> debian/libdns*/DEBIAN/control). See deb-substvars(5).
Again, thanks for the review.
I had missed to add that, but now it's there and consistently used for
all packages. All other items (Vcs, Priority) have been addressed as well.
Now let's see, if this package can find a sponsor, then I can approach
the other suggestions (I already fear that half a dozen packages are not
saying: 'please review and sponsor me').
Regards,
Markus
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5347d06a.2090...@gmail.com
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
On 2014-04-09 20:50, Christian Kastner wrote:
>>> debian/control
>>> ==
>
> I like your approach with a common description provided through a
> substitution variable! Very efficient.
Oh, I missed something here: you are using the substitution variable
${Description}, but you are not setting it anywhere, which results in
half-empty descriptions (see the output in
debian/libdns*/DEBIAN/control). See deb-substvars(5).
Christian
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534598cd.8020...@kvr.at
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
On 2014-04-09 09:26, Markus Schade wrote: > thanks for the review, Christian! Glad I can help :-) Here is some further feedback: >> debian/control >> == >> If you're using a VCS for your packaging, Vcs-* URLs would be nice (to >> simplify contributing to your packaging). You can also use >> Debian's infrastructure, see [1]. Almost correct. The Vcs-Git URL should use the git:// protocol specifier, and you could add a Vcs-Browser URL pointing to the github package, like so: -Vcs-Git: https://github.com/asciiprod/yadifa.git +Vcs-Git: git://github.com/asciiprod/yadifa.git +Vcs-Browser: https://github.com/asciiprod/yadifa > I had intended to set up a repo after the first upload. But of course it > is easier to contribute even before that. And since I need a DM approval > for an Alioth repo, I settled for github for now. I don't think you need DM approval, you only need a DD to request access for you (which would probably be the DD sponsoring your package). But github is more than fine for now, you can always switch later (or not at all). >> You're providing static libraries in the -dev package, but not a shared >> library package. This is not necessarily wrong, just unusual. Note >> that the configure script has an option to build a shared library. > > Good point. The default was to do static linking. Now with shared libs, > I have not just two packages but five (three just for the libs). But as > the recent openssl bug shows, it is easier to just patch a lib than to > rebuild all depending packages. Looks good! One major issue though: the libraries are definitely not Priority: standard :-) (= part of the default Debian installation). You can simply remove this line, the inherited "optional" is fine. nit-pick #1: the synopsis refers to Yadifa twice, in different case, and the other parts should be lowercased. According to the Developer's Reference[0], something like this would probably be more appropriate: -Description: Yadifa DNS Core Shared Library used by YADIFA +Description: DNS core shared library used by YADIFA I like your approach with a common description provided through a substitution variable! Very efficient. nit-pick #2: The package descriptions of the libraries could be a bit more explanatory. (lintian also complains about this). Currently, they basically just repeat the synopsis. Try to describe what another user of the library can do with this package. For example, for libdnszone0, This library can be use to read and write YADIFA-compliant zone files and [...] (I'm just guessing that, I didn't look). This is much more informative to developers who might be interested in writing eg GUI client for modifying zone files. Same goes for the other two libs. Finally, my personal taste for the package description would be something like - This package contains archive-style libraries and header files for - libdnscore0, libdnsdb0 and libdnszone0 + This package contains the header files and the static libraries which are + needed for developing YAFIDA applications. but that's highly subjective. >> debian/copyright >> > > I had originally just included upstreams COPYING, but I think it's safe > to extend the years to include all changes from upstream since then. > > As for my own packaging, I don't mind putting it under a BSD-style license. Just to clarify: you don't have license all of your packaging under a BSD-style license., it's sufficient to do that just for the files in debian/patches/*. The machine-readable copyright format specification[1] has more details. > So again, after making these various adjustments and corrections, I have > re-uploaded the package again. By the way, if you can't find a sponsor here (it sometimes takes a while), you can also try pinging either people or teams who might be interested in your package (eg other DNS maintainers). Finally, here are some ideas for future versions of your package: * build a -dbg package (debhelper can automate lots of this) * provide *.symbols files * Multi-archification I say future versions because the value added isn't that big, and when you've just begun packaging then all this stuff in total can easily become overwhelming. Good luck with your package :-) Christian > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/yadifa > > Or via dget at > > http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc [0] file:///usr/share/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis [1]https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53459691.8070...@kvr.at
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
Hi, thanks for the review, Christian! On 04/05/2014 06:16 PM, Christian Kastner wrote: > AFAIK bind9 only stores run-time data in /var/cache/bind (from dynamic > DNS updates, etc). bind9's zone files are in /etc/bind/zones. > > [...] > > I'd either go with /etc/yadifa or /var/lib/yadifa. Check the FHS to > decide which directory fits best. > > Note that the example debian/yadifad.conf assumes /var/lib/yadifa. Yes, I had opted for this location as it is not possible to specify separate dirs for master and slave zones. > debian/control > == > Your Homepage field has trailing whitespace. fixed. > If you're using a VCS for your packaging, Vcs-* URLs would be nice (to > simplify contributing to your packaging). You can also use > Debian's infrastructure, see [1]. I had intended to set up a repo after the first upload. But of course it is easier to contribute even before that. And since I need a DM approval for an Alioth repo, I settled for github for now. > The Section field of yadifa-dev should be: libdevel. > You're providing static libraries in the -dev package, but not a shared > library package. This is not necessarily wrong, just unusual. Note > that the configure script has an option to build a shared library. Good point. The default was to do static linking. Now with shared libs, I have not just two packages but five (three just for the libs). But as the recent openssl bug shows, it is easier to just patch a lib than to rebuild all depending packages. > debian/copyright > I had originally just included upstreams COPYING, but I think it's safe to extend the years to include all changes from upstream since then. As for my own packaging, I don't mind putting it under a BSD-style license. So again, after making these various adjustments and corrections, I have re-uploaded the package again. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yadifa Or via dget at http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc Regards, Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5344f61c.60...@gmail.com
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
Hi, On 2014-03-18 22:34, Markus Schade wrote:> However there is one question, which I am not sure, what is correct. > Upstream uses /var/zones as base for its zone files. My guess was > that this is not the proper location for such files in Debian. So I > changed it to /var/cache/yadifa like bind9, but I welcome any > suggestions if there is a more appropriate location. AFAIK bind9 only stores run-time data in /var/cache/bind (from dynamic DNS updates, etc). bind9's zone files are in /etc/bind/zones. The FHS [0] to which Debian adheres (with some exceptions) states for /var/cache that "the cached files can be deleted without data loss". I guess that is not what you want ;-) I'd either go with /etc/yadifa or /var/lib/yadifa. Check the FHS to decide which directory fits best. Note that the example debian/yadifad.conf assumes /var/lib/yadifa. > I have made some corrections/improvements and re-uploaded the > package again. > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/yadifa > > Or via dget at > > http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc I'm not a DD so I can't sponsor your package, but here is a quick review: debian/control == Your Homepage field has trailing whitespace. If you're using a VCS for your packaging, Vcs-* URLs would be nice (to simplify contributing to your packaging). You can also use Debian's infrastructure, see [1]. The Section field of yadifa-dev should be: libdevel. You're providing static libraries in the -dev package, but not a shared library package. This is not necessarily wrong, just unusual. Note that the configure script has an option to build a shared library. debian/copyright The Copyright field for the first "Files: *" paragraph seems to be missing data, the NEWS file lists changes up to 2013. The License field for that same paragraph should contain the license short name on the first line, which in your case is standardized as "BSD-3-clause", see [2]. License: BSD-3-clause While licensing your packaging under the GPL-2+ is fine, you might want to consider licensing your patches in debian/patches/* under BSD-3-clause so that they can easily be including upstream (should you forward them). debian/rules You can drop the "Sample debian/rules" boilerplate, it is useless and has already been removed from newer versions of dh-make. Regards, Christian [0] http://www.pathname.com/fhs/pub/fhs-2.3.html [1] https://wiki.debian.org/Alioth/PackagingProject [2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53402c6f.6050...@kvr.at
Bug#683120: RFS: yadifa/1.0.3-1 [ITP]
Dear mentors, I have made some corrections/improvements and re-uploaded the package again. However there is one question, which I am not sure, what is correct. Upstream uses /var/zones as base for its zone files. My guess was that this is not the proper location for such files in Debian. So I changed it to /var/cache/yadifa like bind9, but I welcome any suggestions if there is a more appropriate location. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yadifa Or via dget at http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc Best regards, Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5328bbfc.9090...@gmail.com
Bug#683120: RFS: yadifa-1.0.3-1
Hello, since Martijn has not followed up on this bug for the last months, I would like to ask if it is okay to have this bug assigned to me. I have packaged the current version 1.0.3 and uploaded the package(s) to mentors.debian.net seeking sponsorship: http://mentors.debian.net/package/yadifa Best regards, Markus -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53286fc3.4020...@gmail.com
Bug#683120: RFS: yadifa
Hi Martijn, Please name the package yadifa-1.0.1-1 at mentors to yadifa. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121010045522.ga15...@master.debian.org
Bug#683120: RFS: yadifa-1.0.1-1/2116-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "yadifa-1.0.1-1" * Package name: yadifa-1.0.1-1 Version : 2116-1 Upstream Author : yadifa.eu * URL : yadifa.eu * License : BSD Section : net It builds those binary packages: yadifa-1.0.1 - lightweight authoritative Name Server w DNSSEC capabilities To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yadifa-1.0.1-1 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yadifa-1.0.1-1/yadifa-1.0.1-1_2116-1.dsc More information about hello can be obtained from http://yadifa.eu. Changes since the last upload: initial upload
