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;

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

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?

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

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

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

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

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

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