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

Re: New blend creation (debian-astro)

Hi Ole,

On Wed, Nov 04, 2015 at 03:41:52PM +0100, Ole Streicher wrote:
> > It was _never_ possible and I'm afraid it will _never_ be.  I do not
> > trust in parsing WNPP information (except if someone else might prove me
> > wrong and injects these data into UDD.  However, we are parsing VCS (Git
> > and SVN) and if the package is injected there there should be no error
> > in the log.
> >
> > Please verify this and inform me if something behaves differently.
> It seems that it does not parse ITP bugs;

Yes, as I tried to explain.  This feature was never implemented.  Actually
if it really would than specifying the wnpp number would be redundant
after having the package name since if (and only if) there would be some
relieable information about ITPs in UDD we could find out the bug number
when using the package name as key.

Specifying the WNPP bug number is an alternative way to having a changelog
file in VCS saying

packagename (version) unstable ...

  * Initial packaging ...
    Closes #WNPP


Both is parsed and the information from VCS has preference but if
missing the WNPP field is used if (- and only if again) there is
some information about a package description.  You can add this
as a


field in the tasks page but I (strongly) recommend to simply commit the
accordint packaging in VCS (even if it is only a skeleton).  If you want
to do the packaging you want to do this anyway - so why doing duplicate
work.  Actually my personal workflow is:

  1. creating a packaging skeleton in VCS
  2. add binary package name(s) to the tasks files
  3. reportbug wnpp

The last step is just cut-n-pasting from 1. which seems to be a quite
efficient way.  This includes the "risk" that someone is faster than me
in ITPing but this happened exactly zero times for probably more than
200 packages.

> I thust thought that was
> previously the case -- I may mistake here. So, I'll just remove the
> according lines.

There is no need to remove these lines since nothing bad will happen.
The errors in the log are just making you aware that something is not as
expected.  This could uncover mis-spellings or might remember you to do
some packaging which you might simply forgot.  So I'd recommend keeping
the entries.
Kind regards



Reply to: