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

Re: Bug#725772: RFS: nfft -- Library for computing Non-uniform Fast Fourier Transforms



Hi Ghislain,

On Sun, Oct 27, 2013 at 11:56:32PM +0000, Ghislain Vaillant wrote:
> Sorry I could not take care of that earlier, being in the middile of my
> writing-up too.

No need to sorry in those minor (< 1 week) cases.
 
> > d/control:
> >   - Thanks to Scott's explanation I think I understood now the dh-exec
> >     mechanism and so I think you can remove dh-exec from the
> >     Build-Depends
> 
> make sense, I dropped it.

OK.

> >   - Priorities: The source package should be "Priority: optional" and
> >     only for the *-dbg package you should explicitly specify
> >     "Priority: extra".  The point is that priority extra packages will
> >     be excluded from some QA checks which we do not really want in
> >     general but actually debug packages should feature this "extra"
> 
> fixed

OK.

> >   - Neat tip:  You might like to check, how config modell using
> >        cme fix dpkg-control
> >     is formating your control file.  I personally like this.
> > 
> 
> not quite sure what you meant here. I did run "cme fix dpkg-control" and
> did not return anything, nor did it change the copyright file. no
> further action taken.

OK, that's not important but I'm curious why nothing had happened at
your side.  Please post the output of

  apt-cache policy libconfig-model-dpkg-perl

here.  You should get something like the attached patch.  As I said:  It
is not important, but I'm starting to polish all my d/control files with
configmodel edit and it looks reasonable to me.

> > d/changelog:
> >   You created a new changelog paragraph.  For not yet uploaded packages
> >   this is at best confusiing even if your *-1 entry claims that it was
> >   uploaded to unstable (which it was not - at best this should be
> >   "UNRELEASED").  Also the consequence of this new entry is, that the
> >   ITP bug is not closed by an upload if I would upload as is.  You can
> >   easily verify this effect when looking at the tasks page[1] which is
> >   not linking to an according WNPP bug (in contrast to for instance
> >   liblevmar-dev).  The reason is that only the latest paragraph of
> >   d/changelog is parsed.
> 
> fare enough. I modified the changelog file to reflect on this.

OK.

> >   So my advise would be to *not* log your actual changes inside
> >   d/changelog until we have *really* the first version inside Debian.
> >   There is sufficient information inside the Git commit logs.  Just
> >   remove the 3.2.3-2 paragraph and it also makes sense to "target"
> >   with 3.2.3-1 at UNRELEASED while leaving me as the sponsor the
> >   task to switch this to unstable once I decide to upload.  This
> >   is (should be??) written in Debian Science policy document and
> >   helps other team members to see immediately that a package was not
> >   yet uploaded.
> 
> don't remember reading anything about that in the policy. documentation
> about packaging is so scattered and not particularly readable for a "new
> comer" like me that I can't be 100\% sure. if I were not that curious
> and keen to contribute I would have probably given up already.

Ummm, that's important to hear.  I wonder how many potential team
members we might have lost because we are to lazy to maintain our new
comers documentation properly.  I admit I'm personally not that deeply
connected to Debian Science that I feel responsible for this
documentation (even if I'm quite visible here and try to push all
lessons I have learned in Debian Med to Debian Science).  I would be
really happy if somebody would grab the ball and move on here.  I have
noticed Pablo Oliveira's patch to fix this issue and I was hoping for
somebody to grab and apply it (or even discuss this here).

Pablo, thanks for this - if nobody else will step in I'll apply the
patch soon.  Ghislain, if you have faced some other newcomers hurdles
please be verobose about this here and perhaps you even try to fix this
because you are just past this hurdle (hopefully) and might be prepared
best to write down what for *you* would have been helpful.

> > Regarding the SoB sponsering I told you I have added the *-dev package
> > to the relevant development tasks of Debian Science which can be seen
> > for example in mathematics-dev task[1].
> 
> not sure I understand what that means, it's probably more relevant to
> your side as a mentor I guess.

No, not really.  I want to make maintainers of scientific packages
understanding the principle behind Debian Pure Blends to make sure they
will make sure that their packages end up in the metapackages of Debian
Science and at the tasks pages.  I have linked the relevant
documentation at the SoB page.  This idea is the reason why I started
SoB:  To teach people from the beginning thinking about the Blends idea.
If you mind becoming part of another team (Blends team on Alioth) to
actually be able to edit the according tasks file - that's no problem.
But sending me a patch or at least telling me, in what task you want to
see your new package is the maintainers job.  BTW, most other mentors
are ignorant about this as well unfortunately.  It is pretty hard to get
the packages with relevance to scientific work nicely ordered into the
Debian Science tasks without the cooperation of the package maintainers
because we have really a lot of stuff.  But finally it is in the
maintainers interest to care for this to make the end user aware of the
existence of the package.  Blends are to some extent advertising what we
have - and you as the maintainer get this advertising for nearly no
effort: Just make sure the package is entered into the right tasks file.

> > Could you now please add an according entry at the SoB Wiki page[2] to
> > make sure you understood the mechanism I would like to push via SoB.
> > 
> 
> Done.

Noticed.

> Once again thanks for your patience and verbose explanation about the
> process, Andreas.

I just hope for the multiplication effort.

Back to the actual packaging I could upload right now.  On the other hand
I'm not sure whether you are aware about the nitpicking mode of lintian
when using '-I'.  This gives you

$ lintian nfft_3.2.3-1_amd64.changes 
I: nfft source: duplicate-short-description libnfft3-1 libnfft3-dbg libnfft3-dev
I: nfft source: debug-package-for-multi-arch-same-pkg-not-coinstallable libnfft3-dbg => libnfft3-1
I: nfft source: quilt-patch-missing-description fix-missing-lm.patch
I: libnfft3-1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libnfft3.so.1.0.0
I: libnfft3-1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libnfft3_threads.so.1.0.0


I'm currently tolerant enough to let these lintian Info messages pass
but I wonder whether you are aware of these and whether you know what
they mean (just add '-i' to get more info) and how to fix them.
 
Kind regards

       Andreas.

-- 
http://fam-tille.de
diff --git a/debian/control b/debian/control
index fae5914..68c0ff3 100644
--- a/debian/control
+++ b/debian/control
@@ -1,19 +1,22 @@
 Source: nfft
-Priority: optional
 Maintainer: Ghislain Vaillant <ghisvail@gmail.com>
-Build-Depends: debhelper (>=9), dh-autoreconf, libfftw3-dev,
- pkg-config
-Standards-Version: 3.9.4
 Section: libs
-Homepage: http://www-user.tu-chemnitz.de/~potts/nfft
-Vcs-Git: git://anonscm.debian.org/debian-science/packages/nfft.git
+Priority: optional
+Build-Depends: debhelper (>= 9),
+               dh-autoreconf,
+               libfftw3-dev,
+               pkg-config
+Standards-Version: 3.9.4
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=debian-science/packages/nfft.git
+Vcs-Git: git://anonscm.debian.org/debian-science/packages/nfft.git
+Homepage: http://www-user.tu-chemnitz.de/~potts/nfft
 
 Package: libnfft3-1
 Architecture: any
 Multi-Arch: same
+Depends: ${shlibs:Depends},
+         ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Library for computing Non-uniform Fast Fourier Transforms
  NFFT is a C subroutine library for computing the nonequispaced discrete
  Fourier transform (NDFT) in one or more dimensions, of arbitrary input
@@ -25,11 +28,13 @@ Description: Library for computing Non-uniform Fast Fourier Transforms
  libnfft3-dev.
 
 Package: libnfft3-dev
-Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libnfft3-1 (= ${binary:Version}), libfftw3-dev, ${misc:Depends},
- ${shlibs:Depends}
+Section: libdevel
+Depends: libnfft3-1 (= ${binary:Version}),
+         libfftw3-dev,
+         ${misc:Depends},
+         ${shlibs:Depends}
 Description: Library for computing Non-uniform Fast Fourier Transforms
  NFFT is a C subroutine library for computing the nonequispaced discrete
  Fourier transform (NDFT) in one or more dimensions, of arbitrary input
@@ -38,10 +43,11 @@ Description: Library for computing Non-uniform Fast Fourier Transforms
  This package contains the header files and static version of the library.
 
 Package: libnfft3-dbg
-Priority: extra
-Section: debug
 Architecture: any
-Depends: libnfft3-1 (=${binary:Version}), ${misc:Depends}
+Section: debug
+Priority: extra
+Depends: libnfft3-1 (= ${binary:Version}),
+         ${misc:Depends}
 Description: Library for computing Non-uniform Fast Fourier Transforms
  NFFT is a C subroutine library for computing the nonequispaced discrete
  Fourier transform (NDFT) in one or more dimensions, of arbitrary input

Reply to: