teseq_1.1.1-1_source.changes ACCEPTED into unstable

2020-06-29 Thread Debian FTP Masters



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 29 Jun 2020 21:17:52 -0400
Source: teseq
Architecture: source
Version: 1.1.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Boyuan Yang 
Changes:
 teseq (1.1.1-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release.
   * debian/control: Add Vcs-* packaging repo.
   * debian/control:
 + Add check as build-time test dependency.
 + Add pkg-config as build-dependency.
Checksums-Sha1:
 37daf8de16cbd9d1730ad409035d58d2509d1653 1846 teseq_1.1.1-1.dsc
 5c63dd449ad10b5a26601ec79947fbcce64a8381 324988 teseq_1.1.1.orig.tar.gz
 1ae1c1515c076cf130f8b107cfd49f7df7607f89 4076 teseq_1.1.1-1.debian.tar.xz
 c1da122ffbc0d03b6455bd1fefdd10c7ada731b6 6124 teseq_1.1.1-1_amd64.buildinfo
Checksums-Sha256:
 c18b7523b9edcb761e7d1a1fab6b481fb8a077557b45631bebea95a3ebf310a8 1846 
teseq_1.1.1-1.dsc
 32fbd22bc1e16796a02a3915ac6c29015607a19b00a50de570c747860b009622 324988 
teseq_1.1.1.orig.tar.gz
 cd535eaf78b1521b0ab05c7df3f39c09741c5b50fac22d5a1611ac072a434a82 4076 
teseq_1.1.1-1.debian.tar.xz
 d25ef5760e4d14e3bc78a996fd530d5935ef8b1528929dfbcebec3e436f964f2 6124 
teseq_1.1.1-1_amd64.buildinfo
Files:
 c9f480a7d69f6c2bc54c4448c30fa24e 1846 devel optional teseq_1.1.1-1.dsc
 c18b0e9801bc414a206e4ed0a6acca70 324988 devel optional teseq_1.1.1.orig.tar.gz
 f988e6d8f289bf63a327a7c531145911 4076 devel optional 
teseq_1.1.1-1.debian.tar.xz
 cf7d506621959b11bbed67c8738ea097 6124 devel optional 
teseq_1.1.1-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAl76kyUACgkQwpPntGGC
Ws7W3BAAiKwTQMwxHjEPOw2lrNRVNBIM+xYYn4tXoUTUj7gKDKeDsd2QeMJKlAF3
ntFsIypEfVlj0SH7W+Jt+kqVb4ae7/N3rvoy2vJP6W1Hz8eP1zDFSeyRgK8SGztr
SaFeNOWnx66TJHWWOWzQ56iMgA+uSXb0BnPyPeMkzH5eRY83oZBNmSptP79BF/a3
1B9asnv8Jv2CcgrrNqlef6LBVK6w+Z4m2MtZIFluJvJhXSjgZXVZvAhRp4qMW/+J
qVBMm2pBVIO6tlEtJZYojjkM78umnqebfPSRdvt9h1+s+UHfW6hA2x57HFm7JBK4
iu3q7lAORXKATayWY4tc+Zg7zsDaM/YUau0W78bjAyuvfxWO+nQGP7Wbm3cA3sn6
91zbz4yb/AvxWI/9CkuakyAyv9P6tZBN9Ogql6nkLXO99rpiscQIk0b1k8INWR0x
q9uDcvDl9kl7bNdTG8Ec+W+Fhg7u3exv7/uVRksGNabjyaEsWtUNOrK0e4ApIxd4
m9bABi2AOMrWZfXztlWuvlifyiwyQOMPkECOolTzEGL2jHRgIcVg/Qnd8uLkP6So
WNehiufZ7BjmbQ6ETcZfIxQUzO5WSXfx9V5HuW4Evxu/U1FIICDcGJsf5Ima70bq
AOBRP+PV5WP5Ehk5uo1TqZ++0d8kFDWLi5NoyQa0tt65kwIdP1w=
=vKIh
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of teseq_1.1.1-1_source.changes

2020-06-29 Thread Debian FTP Masters
teseq_1.1.1-1_source.changes uploaded successfully to localhost
along with the files:
  teseq_1.1.1-1.dsc
  teseq_1.1.1.orig.tar.gz
  teseq_1.1.1-1.debian.tar.xz
  teseq_1.1.1-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-29 Thread Raphael Hertzog
On Mon, 29 Jun 2020, Baptiste BEAUPLAT wrote:
> > Indeed, creating a dedicated service for this does not seem a good idea.
> 
> I would love to have this feature integrated directly with
> distro-tracker. However, I'm wondering about the load that would case
> for the service.

Network request do not generate much "load", such processes spend the bulk
of their time waiting on the network.

> The duck worker has to process around 46 urls (only counting
> Homepage) in less than 24h.

How do you get to that figure? We don't have that many source package
and even if you consider multiple URL for each source package due to
changes over time (in multiple releases), that makes way too many URLs
per source package.

> I'm not sure that can done properly using
> the distro-tracker tasks (parallel workers are needed to work around
> timeout). Obviously that can be optimized (different check delay for
> different results) but that's still bulk network related tasks.

Nothing forbids parallel workers and in any case, I welcome any
improvement to the task mechanism to make that kind of parallelism easier
to handle.

There are other tasks that could benefit from this (and in general I want
to merge more of such features in distro-tracker to make them available to
derivatives too).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature


Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-29 Thread Baptiste BEAUPLAT
Hi Bastian, Raphael,

On 6/29/20 3:55 PM, Raphael Hertzog wrote:
> On Sun, 28 Jun 2020, Bastian Blank wrote:
>>> Baptiste (CCed) volunteered to write it over again, but for now there is
>>> no clear timeline as for when the new project will be started.
>>
>> Maybe you could add that to vcswatch?

The main differences between vcswatch and duck.d.n are:

- history: duck used to keep 6 runs for each package, reporting only
after 3 failures. vcswatch only keeps the last run.
- d/control: duck processed the Homepage as well as the
Vcs-{Git,SVN,Hg,Darcs} fields. vcswatch has a wider support for all Vcs-*.
- d/upstream/metadata: duck processed any urls found here.
- worker: parallel worker for duck, single instance for vcswatch.

(sorry if I got anything wrong here. Please correct me!)

I'm not convinced that adding those features would result in an
improvement for vcswatch (Cc'ing Christoph to have his input on that).

Creating a new sub-project, like vcswatch, to qa.debian.org would be
more sensible IMHO. The new duck could only take care of the http urls
and leave Vcs stuff to vcswatch.

> or distro-tracker?
> 
> Indeed, creating a dedicated service for this does not seem a good idea.

I would love to have this feature integrated directly with
distro-tracker. However, I'm wondering about the load that would case
for the service.

The duck worker has to process around 46 urls (only counting
Homepage) in less than 24h. I'm not sure that can done properly using
the distro-tracker tasks (parallel workers are needed to work around
timeout). Obviously that can be optimized (different check delay for
different results) but that's still bulk network related tasks.

Another thing is that duck.d.n was delegating the actual checks to the
`duck` perl library. To work with distro-tracker I would need to drop
that an implement something silimar in python. Not a huge task per se,
but something to keep in mind.

I'm not sure what is best here and I'm looking forward to your
suggestions and remarks.
-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature


Bug#963887: UDD: 'duck' importer broken since 2020-05-25

2020-06-29 Thread Raphael Hertzog
Hi,

On Sun, 28 Jun 2020, Bastian Blank wrote:
> > Baptiste (CCed) volunteered to write it over again, but for now there is
> > no clear timeline as for when the new project will be started.
> 
> Maybe you could add that to vcswatch?

or distro-tracker?

Indeed, creating a dedicated service for this does not seem a good idea.

https://qa.pages.debian.net/distro-tracker/contributing.html
https://qa.pages.debian.net/distro-tracker/devel/design.html#tasks-framework

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS



Bug#963932: Duplicate symbol json_object_iter_next in json-c, jansson

2020-06-29 Thread Michael Biebl
On Sun, 28 Jun 2020 22:11:20 +0200 Chris Hofstaedtler 
wrote:
> * Chris Hofstaedtler  [200628 20:10]:
> > your libraries BOTH export a symbol named json_object_iter_next,
> > causing crashes for binaries that end up loading both (possibly
> > transitively).

Comparing the .symbols files of both libraries, there is also
json_object_get which clashes.


Apparently there is also json-glib, which is entangled in that naming
issue as well.
It has the following clashing symbols with json-c

 json_object_equal
 json_object_get_type
 json_object_iter_next

See https://gitlab.gnome.org/GNOME/json-glib/-/issues/33

We should probably clone this issue and reassign to src:json-glib,src:json-c



signature.asc
Description: OpenPGP digital signature


Bug#963903: marked as done ('ftpnew-blends' importer crashing. disabled.)

2020-06-29 Thread Debian Bug Tracking System
Your message dated Mon, 29 Jun 2020 14:10:45 +0200
with message-id <20200629121045.ga6...@xanadu.blop.info>
and subject line Re: Bug#963903: 'ftpnew-blends' importer crashing. disabled.
has caused the Debian Bug report #963903,
regarding 'ftpnew-blends' importer crashing. disabled.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
963903: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963903
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd

It crashes with:

sed: can't read http://ftp-master.debian.org/new/libreoffice: No such file or 
directory
sed: can't read http://ftp-master.debian.org/new/libreoffice: No such file or 
directory
sed: can't read http://ftp-master.debian.org/new/libreoffice: No such file or 
directory
sed: can't read http://ftp-master.debian.org/new/libreoffice: No such file or 
directory
sed: can't read (1:7.0.0~beta1-1)_1:7.0.0~beta1-1+b2.html: No such file or 
directory
sed: can't read (1:7.0.0~beta1-1)_1:7.0.0~beta1-1+b2.html: No such file or 
directory
sed: can't read (1:7.0.0~beta1-1)_1:7.0.0~beta1-1+b2.html: No such file or 
directory
sed: can't read (1:7.0.0~beta1-1)_1:7.0.0~beta1-1+b2.html: No such file or 
directory
/usr/lib/python2.7/dist-packages/debian/deb822.py:685: UserWarning: Parsing of 
Deb822 data with python-apt's apt_pkg was requested but this package is not 
importable. Is python-apt installed?
  warnings.warn(msg)
Incompatible binaries between new.822(libchecker-framework-java) and 
checker-framework_3.0.0+repack1-1~exp1.html (checker-framework-java)
Incompatible source names between new.822(postgresql-13) and 
postgresql-13_13~beta1-1.html (https://tracker.debian.org/pkg/postgresql-13; 
rel="nofollow">postgresql-13)
No html info for package libreoffice (1:7.0.0~beta1-1) in queue new ([Errno 2] 
No such file or directory: u'/srv/udd.debian.org/mirrors/ftpnew/libreoffice 
(1:7.0.0~beta1-1)_1:7.0.0~beta1-1+b2.html').
Incompatible binaries between new.822(fonts-myanmar) and 
fonts-myanmar_0.0-1~exp1.html (fonts-myanmar-ayar fonts-myanmar-chatu 
fonts-myanmar-chatulight fonts-myanmar-gantgaw fonts-myanmar-khyay 
fonts-myanmar-kuttar fonts-myanmar-mon fonts-myanmar-myanmar3 
fonts-myanmar-myanmarcensus fonts-myanmar-myanmarsanspro fonts-myanmar-namkhone 
fonts-myanmar-nayone fonts-myanmar-njaun fonts-myanmar-pauklay 
fonts-myanmar-phetsot fonts-myanmar-phiksel fonts-myanmar-phikselsmooth 
fonts-myanmar-ponenyet fonts-myanmar-pyidaungsu fonts-myanmar-sabae 
fonts-myanmar-sagar fonts-myanmar-sanpya fonts-myanmar-squarelight 
fonts-myanmar-tagu fonts-myanmar-thuriya fonts-myanmar-unicode 
fonts-myanmar-waso fonts-myanmar-yinmar fonts-myanmar-zawgyi)
/usr/lib/python2.7/dist-packages/debian/deb822.py:685: UserWarning: Parsing of 
Deb822 data with python-apt's apt_pkg was requested but this package is not 
importable. Is python-apt installed?
  warnings.warn(msg)
Traceback (most recent call last):
  File "/srv/udd.debian.org/udd//udd.py", line 88, in 
exec "gatherer.%s()" % command
  File "", line 1, in 
  File "/srv/udd.debian.org/udd/udd/blends_prospective_gatherer.py", line 407, 
in run
upstream = upstream_reader(ufile, source, self.log, sprosp['blend'])
  File "/srv/udd.debian.org/udd/udd/upstream_reader.py", line 126, in __init__
self.fields = yaml.safe_load(uf.read())
  File "/usr/lib/python2.7/dist-packages/yaml/__init__.py", line 93, in 
safe_load
return load(stream, SafeLoader)
  File "/usr/lib/python2.7/dist-packages/yaml/__init__.py", line 71, in load
return loader.get_single_data()
  File "/usr/lib/python2.7/dist-packages/yaml/constructor.py", line 37, in 
get_single_data
node = self.get_single_node()
  File "/usr/lib/python2.7/dist-packages/yaml/composer.py", line 43, in 
get_single_node
event.start_mark)
yaml.composer.ComposerError: expected a single document in the stream
  in "", line 1, column 1:
Reference:
^
but found another document
  in "", line 21, column 1:
---
^
--- End Message ---
--- Begin Message ---
On 29/06/20 at 10:02 +0200, Andreas Tille wrote:
> I've tested the importer and can not reproduce this.  May be there is a
> broken yaml file included in some just accepted package.  The importer
> is catching several of those errors and usually runs smoothly.
> 
> Am I understanding you correctly that you deactivated ftpnew gatherer?
> If yes, I think it can be activated again and I try to keep a close eye
> the next couple of days.  In case you realise such issue in the future
> it could be a good idea to keep 

ample_0.5.7-11~bpo10+1_amd64.changes ACCEPTED into buster-backports, buster-backports

2020-06-29 Thread Debian FTP Masters



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 25 Jun 2020 08:07:48 -0300
Source: ample
Binary: ample
Architecture: source amd64
Version: 0.5.7-11~bpo10+1
Distribution: buster-backports
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Fabio Augusto De Muzio Tobich 
Description:
 ample  - simple MP3 server easy to use
Changes:
 ample (0.5.7-11~bpo10+1) buster-backports; urgency=medium
 .
   * QA upload.
   * Rebuild for buster-backports.
Checksums-Sha1:
 06c4c586ac0eaa3a1e5c936a212db4ce2f49b120 1881 ample_0.5.7-11~bpo10+1.dsc
 d385b80191758d76b0ba0d90096121bfaca731ba 9576 
ample_0.5.7-11~bpo10+1.debian.tar.xz
 c1af2c468958c47ca51f833e8a2d9cd9abf3ea92 5506 
ample_0.5.7-11~bpo10+1_amd64.buildinfo
 4a8dc52aba7c6b0b72516dff888ddf1a3bc22b1a 41068 ample_0.5.7-11~bpo10+1_amd64.deb
Checksums-Sha256:
 cf454f8f1089207bceab07ffb58036067be4d9fda84c1d2f0297cb829dd092c1 1881 
ample_0.5.7-11~bpo10+1.dsc
 5f655f2113a5f7a3eef87784167786576f4f500dac8bbfd56964775cfbfbc6e6 9576 
ample_0.5.7-11~bpo10+1.debian.tar.xz
 752e73b75f9715ad00daf893faee06e2024c7a3f027687010795b1b202a6d35a 5506 
ample_0.5.7-11~bpo10+1_amd64.buildinfo
 4d1118aee6ec097d0556d28e29b8b9012ca49479dcc84478bcf01f581c57c23b 41068 
ample_0.5.7-11~bpo10+1_amd64.deb
Files:
 8f8032450b053ab0219cf09c3e575cc7 1881 sound optional ample_0.5.7-11~bpo10+1.dsc
 584fa4b6a9bffc087fd5c27e6e03ead8 9576 sound optional 
ample_0.5.7-11~bpo10+1.debian.tar.xz
 6b3ccf6afa3048be82c4a1d755423733 5506 sound optional 
ample_0.5.7-11~bpo10+1_amd64.buildinfo
 447e0e1313272b8752de6f7a3fc6ea75 41068 sound optional 
ample_0.5.7-11~bpo10+1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEENX3LDuyVoBrrofDS3mO5xwTr6e8FAl70yysACgkQ3mO5xwTr
6e+CRw/+LIIJO8hzyRRouJL+n+YyQtILdEyH2ymAnjjaJ+xODBOVdnMXjfD4GOdk
CzAJOSAMCvWERKg156g+NuNleuVb4xIXQREUzHckZHVilUy9W2BSpNLhwkJizM2A
MwBiUmbMaoZqQxoj7LfHcc2v5fblWiRvnDb9KVHSb9Wbgo7GN2xIvDEDV6f62Oj7
9FoKe18/aCqS/sGfL6EGjKAe45KfokV49bGsbwqximREIZonxOrpgvX9UpuHFVml
kveU59vYfh0lChFoABrvugO23W4aeZxE2vAwBrA0tDO8dbvHgS8tZXq/zsj2G2Fd
9ciKFIshHJxFfeD7prsbYOmG8i9jCIE+85q57CIzPlxB2Kdt6sBd+CI096blP/l5
VqBzHx6TAgKe5A5TL7eAojdT8bU+35luOW4T67oQ49eaZ3UP/vy2Kapuc3BPRxG3
+OuWIQlwOsxA3Kll4VQQ7vAQ2oJd8R+rhA4gkHEZfZJFWHfkBC5Ea1EsIEarCd7C
j2Cc/97A8jhFl2Er5MWR9GpMJE47ECR5Cilj4D9rxnjoMB1HUqyQYdrUOJ35or2Q
imGI7pM3+xSkDTmKRvqG7B8jYM/XUZ0vz/d1S/mBLqmpTyI7x9PB2fsRGcmCj5j9
7J075XsKtPcL900N/m9FCUfWU+u0YMHrfRF1LEiemZDMZqRlR2M=
=hVGE
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Bug#963903: 'ftpnew-blends' importer crashing. disabled.

2020-06-29 Thread Andreas Tille
Control: tags -1 unreproducible

Hi Lucas,

On Sun, Jun 28, 2020 at 06:01:33PM +0200, Lucas Nussbaum wrote:
> Traceback (most recent call last):
>   File "/srv/udd.debian.org/udd//udd.py", line 88, in 
> exec "gatherer.%s()" % command
>   File "", line 1, in 
>   File "/srv/udd.debian.org/udd/udd/blends_prospective_gatherer.py", line 
> 407, in run
> upstream = upstream_reader(ufile, source, self.log, sprosp['blend'])
>   File "/srv/udd.debian.org/udd/udd/upstream_reader.py", line 126, in __init__
> self.fields = yaml.safe_load(uf.read())
>   File "/usr/lib/python2.7/dist-packages/yaml/__init__.py", line 93, in 
> safe_load
> return load(stream, SafeLoader)
>   File "/usr/lib/python2.7/dist-packages/yaml/__init__.py", line 71, in load
> return loader.get_single_data()
>   File "/usr/lib/python2.7/dist-packages/yaml/constructor.py", line 37, in 
> get_single_data
> node = self.get_single_node()
>   File "/usr/lib/python2.7/dist-packages/yaml/composer.py", line 43, in 
> get_single_node
> event.start_mark)
> yaml.composer.ComposerError: expected a single document in the stream
>   in "", line 1, column 1:
> Reference:
> ^
> but found another document
>   in "", line 21, column 1:
> ---
> ^

I've tested the importer and can not reproduce this.  May be there is a
broken yaml file included in some just accepted package.  The importer
is catching several of those errors and usually runs smoothly.

Am I understanding you correctly that you deactivated ftpnew gatherer?
If yes, I think it can be activated again and I try to keep a close eye
the next couple of days.  In case you realise such issue in the future
it could be a good idea to keep a copy of
/srv/udd.debian.org/mirrors/ftpnew
somewhere to have the actual data that really caused the crash.

Kind regards and thanks a lot for caring for UDD

 Andreas.

-- 
http://fam-tille.de



Processed: Re: Bug#963903: 'ftpnew-blends' importer crashing. disabled.

2020-06-29 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 unreproducible
Bug #963903 [qa.debian.org] 'ftpnew-blends' importer crashing. disabled.
Added tag(s) unreproducible.

-- 
963903: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963903
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#843835: UDD: expose an API for upstream versions to rmadison

2020-06-29 Thread Lucas Nussbaum
On 29/06/20 at 09:49 +0800, Paul Wise wrote:
> On Sun, 2020-06-28 at 18:17 +0200, Lucas Nussbaum wrote:
> 
> > That would be easy. What should that API look like? Would returning all
> > the info for a given source package, as json, be enough?
> 
> Probably just the same API as the existing rmadison APIs. Since there
> is already a udd madison script, probably just add it there with an
> additional parameter. Since the ftp-master NEW madison API is in a
> similar situation and uses s=new as the additional parameter, I suggest
> one of s=upstream, s=uscan or s=watch as the additional parameter.
> 
> https://api.ftp-master.debian.org/madison?s=new
> https://qa.debian.org/cgi-bin/madison.cgi

Actually, modifying https://qa.debian.org/cgi-bin/madison.cgi to take an
additional parameter as you describe should be simple, and does not
need any change on the "core UDD" side.

Note that UDD exposes watch status for both unstable and experimental.
Both should probably be exposed using that API as well.

Lucas


signature.asc
Description: PGP signature