Re: New upstream data in blends query
Hi,
to verify that the upstream metadata are propagated as expected I did
the following:
1. Check for potential candidates that have the fields in question:
SELECT * FROM blends_dependencies WHERE package IN (SELECT DISTINCT package FROM packages WHERE source IN (SELECT source FROM upstream_metadata WHERE key = 'Repository') );
2. From the result I picked 4 random packages in task osm since
interestingly enough none of the results were on debian-astro
Blend
SELECT package, source, version, upstream_bugs, upstream_repositorys
FROM blends_query_packages('{"merkaartor","imposm", "qlandkartegt", "libjs-mgrs"}',
'{"%merkaartor%","%imposm%","%qlandkartegt%", "%libjs-mgrs%"}',
'osm')
AS (
package text, distribution text, release text, component text, version debversion,
maintainer text,
source text, section text, task text, homepage text,
maintainer_name text, maintainer_email text,
"vcs-type" text, "vcs-url" text, "vcs-browser" text,
changed_by text,
enhanced text[],
releases text[], versions text[], architectures text[],
unstable_upstream text, unstable_parsed_version text, unstable_status text,
vote int, recent int, insts int, -- popcon
debtags text[],
screenshot_versions text[], image text[], icon text[],
year text,
title text,
authors text,
doi text,
pubmed text,
url text,
journal text,
volume text,
number text,
pages text,
eprint text,
description_en text, long_description_en text,
description_cs text, long_description_cs text,
description_da text, long_description_da text,
description_de text, long_description_de text,
description_es text, long_description_es text,
description_fi text, long_description_fi text,
description_fr text, long_description_fr text,
description_hu text, long_description_hu text,
description_it text, long_description_it text,
description_ja text, long_description_ja text,
description_ko text, long_description_ko text,
description_nl text, long_description_nl text,
description_pl text, long_description_pl text,
"description_pt_BR" text, "long_description_pt_BR" text,
description_ru text, long_description_ru text,
description_sk text, long_description_sk text,
description_sr text, long_description_sr text,
description_sv text, long_description_sv text,
description_uk text, long_description_uk text,
description_vi text, long_description_vi text,
"description_zh_CN" text, "long_description_zh_CN" text,
"description_zh_TW" text, "long_description_zh_TW" text,
remark text,
"upstream_bugs" text,
"upstream_repository" text,
"edam_topics" text[]
)
;
package | source | version | upstream_bugs | upstream_repository
--------------+--------------+------------+----------------------------------------------------+-------------------------------------------------
imposm | imposm | 2.6.0+ds-2 | https://github.com/omniscale/imposm/issues | https://github.com/omniscale/imposm.git
libjs-mgrs | mgrs | 0.0.3-1 | https://github.com/proj4js/mgrs/issues | https://github.com/proj4js/mgrs.git
merkaartor | merkaartor | 0.18.2-6 | https://github.com/openstreetmap/merkaartor/issues | https://github.com/openstreetmap/merkaartor.git
qlandkartegt | qlandkartegt | 1.8.1+ds-5 | | https://bitbucket.org/kiozen/qlandkarte-gt
(4 Zeilen)
So it seems the information exists and is propagated by the query.
Now we need to check why non are from Debian Astro. Could you give me
some package names where you would expect similar results?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: