Re: Bug#725772: RFS: nfft -- Library for computing Non-uniform Fast Fourier Transforms
Hi Andreas
On Mon, 2013-10-28 at 10:29 +0100, Andreas Tille wrote:
> 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
>
My apologize, I was still focusing on the copyright and did not read you
were talking about the control file. It is now fixed.
> 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.
>
I am intending to blog about my packaging experience in the near future.
I foresee debian/ubuntu to be the safest place to release scientific
code in the future, considering the recent moves and potential lockdowns
coming up in Windows and OSX. Some insights on getting started with
packaging from a fellow research colleague, properly formatted in a set
of blog posts, would probably feel like a more shallow path than all the
documentation I have had to digest to begin with.
> > > 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.
>
Thanks for clarifying that. I see what you mean. I can see the benefit
from a regular maintainer standpoint.
> > > 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
>
Indeed, I have been using '-i' only. The first 3 are fixed now. TBH, I
don't know much about symbols and their importance in packaging. I'd be
curious to learn about them later, but I clearly don't have time right
now. For what, I read about it on a quick googling, they don't seem to
be that important for my use case though.
>
> 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.
>
Thanks,
Ghislain
Reply to: