teseq_1.1.1-1_source.changes ACCEPTED into unstable
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
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
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
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
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
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.)
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
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.
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.
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
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