Re: Processing of (debian-science) tasks
Hi Akshita,
On Wed, May 13, 2015 at 03:19:55PM +0530, Akshita Jha wrote:
> Hi,
> >
> > The log files can be accessed here:
> >
> > http://blends.debian.org/_logs/http://blends.debian.org/_logs/
>
> Can this page be accessed by everyone ? I get a 404 Not Found Error.
"HALF" of it is accessible - try
http://blends.debian.org/_logs
(and sorry for the cut-n-pasto ...)
> > $ apt-cache show fitscut | grep -A 3 ^Description-en
> > Description-en: Extract cutouts from FITS image format files
> > fitscut is designed to extract cutouts from FITS image format files.
> > FITS, PNG, and JPEG output types are supported. When multiple input
> > files are specified and the output type is PNG or JPEG the resulting
> > ...
>
> The tasks page shows the correct short description for Fitscut now. But for
> "Swarp", "Cpl-plugin-amber" and "Cpl-plugin-muse", the short description as
> well as the long description are missing.
>
> > > * For some packages, the description seems to come from the git
> > > repository, while for others it is taken from the packages in
> > > unstable. F.e. cpl-plugin-muse has the description from unstable
> > > (which would have a fixed version in git)
> >
> > For *existing* packages the description is taken from unstable. For so
> > called "prospective" packages the description is taken from VCS. In
> > UDD we keep the VCS metadata only for not yet existing packages.
>
> I understand that the description of packages that already exist in the
> Debian Package Pool comes from Umegaya
No, not from Umegaya. This is only for references. The description
come from UDD and here from the latest available version (read usually
from unstable, experimental is not queried normally if I remember
correctly without checking the code).
> and the description for packages
> that do not *exist* comes from VCS. Is this the expected behavior?
Yes. But swarp is an existing package. We have:
udd=# select distinct package, version, description_md5, release from packages where package = 'swarp' ;
package | version | description_md5 | release
---------+--------------------+----------------------------------+--------------
swarp | 2.38.0+dfsg-1~exp1 | 131adc05cd3745d738a183ebc92e1137 | experimental
swarp | 2.19.1-1 | 72b4d2153bab1ce95481f41635472a29 | sid
swarp | 2.19.1-1 | 72b4d2153bab1ce95481f41635472a29 | jessie
There are existing descriptions with the description_md5 in the
description table. For some reason the query seems to be broken.
Akshita, could you check the query (I think blends_query_packages) why this
does not lead to a reliable result. I somehow suspect a conflict with the
different descriptions in unstable and experimental - at least this is the
only thing that might be unusual and thus not tested widely.
> Or
> because of the bug in Umegaya[2], the description is outdated and we should
> add an Upsert() functionality like we plan to do for references?
No, this is not related at all. Umegaya has really a minor importance
and the tasks pages would simply lack a view citations (and by the way
the swarp citation seems to be fine).
> > This issue is most probably caused by a broken Umegaya (see [2]). The
> > current task of the Blends GSoC student is to prefer VCS metadata over
> > Umegaya (which also queries VCS but is actually broken[2]). So this
> > will hopefully be solved in the next couple of days.
>
> Hopefully the separate script for generating the bibtex file, which prefers
> VCS metadata over Umegaya, will solve this issue.
I promised to check this ...
> > Hmmm, perhaps checking this might be the next task for the GSoC student
> > to solve? Need to check this as well.
>
> I am working on this. I will let you know about it soon.
That's great. BTW since you found performance issues in some queries
previously: Please always assume that the queries are not perfect and
look for anything that might be suspicious. :-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: