Re: Bug#1060201: qa.debian.org: [udd] carnivore_emails is lacking lots of entries

Am Sun, Jan 07, 2024 at 05:58:36PM +0100 schrieb Lucas Nussbaum: > > See https://salsa.debian.org/qa/udd/-/blob/master/udd/carnivore_gatherer.py. Found this meanwhile. > > This statement could be easily turned into injects and would be a first > > approach to enhance > > the carnivore_emails t

Re: Bug#1060201: qa.debian.org: [udd] carnivore_emails is lacking lots of entries

Control: usertag -1 udd Am Sun, Jan 07, 2024 at 01:38:35PM +0100 schrieb Andreas Tille: > Package: qa.debian.org > Severity: normal > > Hi, > > I tried to analyse closed bugs using done_email via carnivore_emails but > realised > that this table is lacking lots of entr

Bug#1060201: qa.debian.org: [udd] carnivore_emails is lacking lots of entries

Package: qa.debian.org Severity: normal Hi, I tried to analyse closed bugs using done_email via carnivore_emails but realised that this table is lacking lots of entries where I could easily add several from my own memory: SELECT done_email, COUNT(*) FROM ( SELECT done_email FROM archived_bugs W

Re: poco library is "basically orphaned", newer version available, Mumble has poco dependency

Hi Chris, Am Tue, Jan 02, 2024 at 09:32:59PM -0500 schrieb Chris Knadle: > I'm in kind of a tight spot and hope to get a "clearance to proceed" or > reasonable guidance on how to handle this situation. > > All recent versions of Mumble (>= 1.4) build-depend on poco c++ libraries > which are RC bu

Re: Bug#1057778: qa.debian.org: [udd] some names are not stripped from blanks and quotes (Was: UDD contains names where spaces are not stripped)

Control: usertag -1 udd The problem was discussed on Debian-QA list. The discussion starts here: https://lists.debian.org/debian-qa/2023/12/msg7.html I opened this bug report to keep a record of the discussion in BTS. There is one statement by Lucas Nussbaum[1] defending the current si

Bug#1057778: qa.debian.org: [udd] some names are not stripped from blanks and quotes

quot; Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli "

Re: UDD contains names where spaces and quotes are not stripped

Am Thu, Dec 07, 2023 at 08:36:12PM +0100 schrieb Lucas Nussbaum: > On 07/12/23 at 20:24 +0100, Andreas Tille wrote: > > Am Thu, Dec 07, 2023 at 07:59:38PM +0100 schrieb Lucas Nussbaum: > > > On 07/12/23 at 09:58 +0100, Andreas Tille wrote: > > > > > > >

Re: UDD contains names where spaces are not stripped

Am Thu, Dec 07, 2023 at 07:59:38PM +0100 schrieb Lucas Nussbaum: > On 07/12/23 at 09:58 +0100, Andreas Tille wrote: > > Hi, > > > > by chance I realised that the uploaders table contains some names where > > names > > are not stripped: > > &

Re: Appstream data not in UTF-8?

Am Thu, Dec 07, 2023 at 11:03:29AM +0100 schrieb Raphael Hertzog: > On Thu, 07 Dec 2023, Raphael Hertzog wrote: > > tracker.debian.org has been failing to import the appstream metadata for a > > while (since November 26th) with this exception: > > Quick correction. The first time it failed that wa

UDD contains names where spaces are not stripped

no Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli "Andreas Til

Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware

Just a quick note: I can't care for this in the next 48 hours. Am Fri, Nov 03, 2023 at 10:48:11PM +0100 schrieb Cyril Brulebois: > Lucas Nussbaum (2023-11-03): > > UDD uses several independant "importers". The constraint you quoted is > > in the "blends&quo

Re: Bug#1032587: UDD's upstream_metadata table may contain stale data?

Am Tue, Mar 14, 2023 at 10:05:33PM +0100 schrieb Andreas Tille: > Am Tue, Mar 14, 2023 at 10:42:30PM +0200 schrieb Faidon Liambotis: > > Thanks Andreas! Is the code and/or logs for this cronjob somewhere I can > > access myself? Perhaps I could have a look myself and help yo

Bug#1032587: UDD's upstream_metadata table may contain stale data?

Am Tue, Mar 14, 2023 at 10:42:30PM +0200 schrieb Faidon Liambotis: > Thanks Andreas! Is the code and/or logs for this cronjob somewhere I can > access myself? Perhaps I could have a look myself and help you out? Its https://salsa.debian.org/blends-team/website/-/blob/master/misc/machine_reada

Bug#1032587: UDD's upstream_metadata table may contain stale data?

Hi Faidon, Am Thu, Mar 09, 2023 at 04:45:04PM +0200 schrieb Faidon Liambotis: > This is my first attempt to query this data, so I hope this isn't an > operator error! No. Thanks a lot for your bug report. I realised some cron job gathering upstream metadata files (and other machine readable fil

Public UDD mirror not updated

Hi, when logging into public UDD mirror and doing a simple example query udd=> select source, version, release from sources where source='r-cran-blockmodeling'; source| version | release --+-+-- r-cran-blockmodeling | 0.1.8-1 | stretch r-cr

UDD upstream importer seems to fail randomly for sf.net

Hi, when checking UDD dashboard for the Debian Med team[1] I see lots of debian/watch: uscan returned an error: In debian/watch no matching files for watch line http://sf.net/ expressions. I suspect that this affects all packages hosted at SourceForge. When running uscan manually on my loc

Re: Refresh thread (Was: Started porting UDD to Python3 (Was: [UDD] Is there some effort to port UDD to Python3?))

Hi again, I've added this as an issue to "Grow your ideas for Debian Project": https://salsa.debian.org/debian/grow-your-ideas/-/issues/13 Kind regards Andreas. Am Sun, Jan 16, 2022 at 04:28:29PM +0100 schrieb Andreas Tille: > Hi, > > as far as I can se

Refresh thread (Was: Started porting UDD to Python3 (Was: [UDD] Is there some effort to port UDD to Python3?))

Andreas. Am Mon, May 18, 2020 at 09:57:33PM +0200 schrieb Andreas Tille: > On Mon, May 18, 2020 at 08:35:33PM +0200, Stéphane Blondon wrote: > > > > Can you send me the file 'gatherer.${I_dont_know_the_command}' which > > raises the UnicodeDecodeError exception

Public UDD mirror offline? (Was: Public UDD mirror out of sync again)

Hi, is the public mirror offline? $ ping udd-mirror.debian.net PING udd-mirror.debian.net (147.75.35.146) 56(84) bytes of data. >From node12.net.fosshost.org (139.178.85.99) icmp_seq=1 Destination Host >Unreachable >From node12.net.fosshost.org (139.178.85.99) icmp_seq=2 Destination Host >Unrea

Re: Public UDD mirror out of sync again

Am Tue, Dec 14, 2021 at 04:06:02PM +0100 schrieb Mattia Rizzolo: > Hopefully at the very least reduced the probability to happen in the > future with > https://github.com/paulproteus/public-udd-mirror/commit/15df7d89fb6d447e0e4b57c3e3f24aa512414b64 Makes sense. > Thanks for reporting! Thanks a

Public UDD mirror out of sync again

Hi, seems there is another case that public UDD mirror is out of sync. UDD udd=# select source, version, upstream_version from upstream where source like 'r-cran-uwot' ; source| version | upstream_version -+--+-- r-cran-uwot | 0.1.11-1 | 0.1.11 Mi

Re: [udd] Blends query runs into: terminating connection due to administrator command

Ping, we just discussed in our Debian Med video conference whether there is some chance to throw money against upgrading the hardware of the machine running UDD. What do you think about this? Kind regards Andreas. Am Fri, Nov 26, 2021 at 08:22:06AM +0100 schrieb Andreas Tille: > Am Mon,

Re: [udd] Blends query runs into: terminating connection due to administrator command

Am Mon, Nov 22, 2021 at 01:28:24PM +0100 schrieb Andreas Tille: > Hi Lucas, > > Am Mon, Nov 22, 2021 at 11:30:08AM +0100 schrieb Lucas Nussbaum: > > Hi, > > > > > Is there any chance to bump the performance of the database server > > > to deal with this

Re: [udd] Blends query runs into: terminating connection due to administrator command

Hi Lucas, Am Mon, Nov 22, 2021 at 11:30:08AM +0100 schrieb Lucas Nussbaum: > Hi, > > > Is there any chance to bump the performance of the database server > > to deal with this kind of queries? Any other idea how to solve the > > issue would be really welcome. > > > > I'm observing this issue si

[udd] Blends query runs into: terminating connection due to administrator command

Hi, since some time the Debian Med packages are not updated any more. The output of the job can be found in the logfile[1]: Traceback (most recent call last): File "./tasks.py", line 28, in tasks.GetAllDependencies() File "/srv/blends.debian.org/webtools/blendstasktools.py", line 937,

Re: Public UDD mirror again not up to date

Hi Mattia, Am Tue, Nov 16, 2021 at 09:30:43PM +0100 schrieb Mattia Rizzolo: > Yes, this was caused by a network error that left a stale lockfile: > > Log started at Fri Nov 12 22:05:01 UTC 2021 > lock taken at /tmp/update_udd.udd-mirror.lock > Downloading udd.dump > wget: unable to resolve host a

Public UDD mirror again not up to date

Hi, it seems that the public UDD mirror has again issues to update its data: UDD: source | version | distribution | release | component | watch_file | signing_key_pgp | signing_key_asc | debian_uversion | debian_mangled_uversio

Re: UDD dump seems to be outdated (Was: Why is the list of outdated packages not getting updated?)

Am Wed, Oct 13, 2021 at 02:42:01PM +0200 schrieb Mattia Rizzolo: > Indeed udd-mirror had stopped taking in updates due to a leaked > lockfile. > > It should be up2date now. Thanks a lot Andreas. -- http://fam-tille.de

Re: Bug#995616: dh-make: create debian/upstream/medatada template

Am Wed, Oct 13, 2021 at 07:37:33AM +1100 schrieb Craig Small: > It was more that the main system [1] that used this data seemed to be > offline as well as the debian med one [2] too. > > 2: http://debian-med.alioth.debian.org/tasks Even when alioth as online the page you should refer to is h

Re: UDD dump seems to be outdated (Was: Why is the list of outdated packages not getting updated?)

Hi again, I just checked and the public UDD mirror keeps on presenting outdated results as I wrote below. Can some of the admins have a look? Thanks a lot Andreas. Am Tue, Oct 12, 2021 at 04:42:21PM +0200 schrieb Andreas Tille: > Hi, > > Am Tue, Oct 12, 2021 at 02:43:56PM +020

Re: UDD dump seems to be outdated (Was: Why is the list of outdated packages not getting updated?)

Hi, Am Tue, Oct 12, 2021 at 02:43:56PM +0200 schrieb Lucas Nussbaum: > > udd=> select source , version, debian_mangled_uversion, upstream_version, > > status from upstream where source in ('r-cran-s2','r-cran-rwave') ; > > source| version | debian_mangled_uversion | upstream_version |

UDD dump seems to be outdated (Was: Why is the list of outdated packages not getting updated?)

Hi, I think the issue described below by Nilesh Patra might be caused by the fact that the UDD dump[3] is not updated properly. I just downloaded the dump and get a modification time of Modify: 2021-10-11 02:55:01.0 +0200 and md5sum fb9c6cb3ddb3d819983f7c0d82a50669 udd.dump Whi

Re: upload_history not updated (Was: UDD mirror not up to date)

On Sun, Aug 22, 2021 at 09:42:21AM +0200, Mattia Rizzolo wrote: > > It takes 2-3 minutes. but when I mailed last time I had already run it > once, indeed this is the last record right now: > > udd=> select source, version, date, distribution from upload_history order by > date desc limit 1; >

Re: upload_history not updated (Was: UDD mirror not up to date)

Hi again, On Sat, Aug 21, 2021 at 12:27:15PM +0200, Mattia Rizzolo wrote: > > > Thanks a lot. That's very convenient since we relay on UDD to organise > > > the packages that need updates. > > > > Seems that upload_history in UDD itself is not updated: > > Yes, that's included in the importers

Re: upload_history not updated (Was: UDD mirror not up to date)

On Sat, Aug 21, 2021 at 12:27:15PM +0200, Mattia Rizzolo wrote: > > Yes, that's included in the importers that are stopped for now. > > I'm running the "upload-history" importer manually right now, so you > should see somethng appear soon, just for you :) That's a really great service. The rati

upload_history not updated (Was: UDD mirror not up to date)

Hi again, On Thu, Aug 19, 2021 at 03:04:22PM +0200, Andreas Tille wrote: > On Thu, Aug 19, 2021 at 11:29:20AM +0200, Mattia Rizzolo wrote: > > > > I just re-enabled the cronjobs handling the dumps, so that at least > > udd-mirror will keep updated. > > Thanks a l

Re: UDD mirror not up to date

On Thu, Aug 19, 2021 at 11:29:20AM +0200, Mattia Rizzolo wrote: > > I just re-enabled the cronjobs handling the dumps, so that at least > udd-mirror will keep updated. Thanks a lot. That's very convenient since we relay on UDD to organise the packages that need updates. Kind regards Andreas

UDD mirror not up to date

Hi, I'm just checking some R packages and realised that UDD mirror seems not to be up to date The mirror has: $ psql --port=5432 --host=udd-mirror.debian.net --username=udd-mirror udd udd=> select source, version, release from sources where source = 'r-cran-xslt' ; source| version | rele

Re: Access to UDD seems to have changed since 2021-06-01

Hi Mattia, what channel did you used to enable me continuing the discussion? Kind regards and thanks a lot for your investigation Andreas. On Thu, Jun 24, 2021 at 05:28:27PM +0200, Mattia Rizzolo wrote: > On Thu, Jun 17, 2021 at 10:39:53AM +0200, Andreas Tille wrote: > > On Wed, Jun

Re: Access to UDD seems to have changed since 2021-06-01

Hi Mattia, On Wed, Jun 16, 2021 at 03:29:45PM +0200, Mattia Rizzolo wrote: > > the Blends web sentinel (running in dillon.d.o) can't connect to UDD any > > more since 2021-06-01. I'm using a Python script for the connection but > > even the simple access via psql (described in Wiki[1]) fails: >

Access to UDD seems to have changed since 2021-06-01

Hi, the Blends web sentinel (running in dillon.d.o) can't connect to UDD any more since 2021-06-01. I'm using a Python script for the connection but even the simple access via psql (described in Wiki[1]) fails: $ LANG=C psql -U guest -h udd.debian.org -p 5452 udd psql: could not connect to serve

Re: Debian Trends updated

Hi Lucas, On Sat, Apr 17, 2021 at 09:36:10AM +0200, Lucas Nussbaum wrote: > Trends is just based on what lintian reports, and in that case, lintian > thinks that's the case, see https://lintian.debian.net/sources/probcons Thanks for the clarification. > It looks like this package ships both deb

Re: Debian Trends updated

Hi Lucas, On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote: > I just updated Debian Trends: https://trends.debian.net/ Thanks a lot for Debian Trends. I have checked the code smells[1] for I think this is a false positive: probcons (U) does not use the machine-readable

Bug#966649: Unfortunately there are several Uploads missing (Was: upload_history is back)

Control: reopen -1 Hi Asheesh, On Tue, Aug 25, 2020 at 10:52:56PM -0700, Asheesh Laroia wrote: > Test yourself with e.g. this command (which queries the public UDD mirror, > but you can use the real UDD if you can connect to ullmann.debian.org)! I tested my teammetrics statistics script[1] which

Bug#966649: Merge request for minimal, tested Python 3 port

Hi Asheesh, thanks a lot. I hope Lucas will merge and check. I'm currently working on DebConf things. Thanks again to you and Lucas Andreas. On Sun, Aug 23, 2020 at 02:38:35AM -0700, Asheesh Laroia wrote: > Hi all, > > I submitted a merge request here with code that should work for a Pyt

Bug#966649: Request for feedback on upload_history re-implementation

Hi Asheesh, On Sat, Aug 22, 2020 at 11:21:55AM -0700, Asheesh Laroia wrote: > You noticed that the date column was an integer. That's fixed now; if you > update from git, and if you delete upload_history.sqlite on your machine, > and re-run the tool, the upload_history column will use a datetime f

Bug#966649: Request for feedback on upload_history re-implementation

sqlite> select * from upload_history where maintainer like '%debian-med-packaging%' limit 2 ; e1jawxz-000605...@ries.debian.org|1199391582|gnumed-client|0.2.8.1-1|Andreas Tille |Andreas Tille|ti...@debian.org|Debian-Med Packaging Team |Debian-Med Packaging T

Re: [UDD] Upload_history table is currently empty

Hi Lucas, On Thu, Aug 13, 2020 at 11:24:42PM +0200, Lucas Nussbaum wrote: > > Well, why don't you look at the code? No idea whether it is sensible to answer rhetorical questions. Since you asked despite you probably know that I'm doing even more than usual for Debian Med since COVID-19 here some

Re: [UDD] Upload_history table is currently empty

Hi again, On Mon, Aug 03, 2020 at 11:20:21AM +0200, Andreas Tille wrote: > > > 'munge_ddc.py' has the following issues: > > > [...] > > > - it doesn't support xz email archives, so it's broken for recent > > > archives > > > &

Re: [UDD] Upload_history table is currently empty

Hi Lucas, On Mon, Aug 03, 2020 at 11:05:12AM +0200, Lucas Nussbaum wrote: > > So why does this end in 2013? Funnily enough when I rsync to my local box I > > get random zero sized *.xz.out files (but lots of missings - for instance > > only > > debian-devel-changes.201907.xz.out for whole 2019).

Re: [UDD] Upload_history table is currently empty

On Mon, Aug 03, 2020 at 08:18:44AM +0200, Lucas Nussbaum wrote: > > > >https://salsa.debian.org/qa/udd/-/tree/python3 > > > > > > ... but it does not include the script in question for this bug? > > > > You mean munge_ddc.py? Hmmm, I can not even find it in master branch? > > As I wrote in

Re: [UDD] Upload_history table is currently empty

On Sun, Aug 02, 2020 at 04:09:49PM +0200, Lucas Nussbaum wrote: > On 02/08/20 at 15:12 +0200, Andreas Tille wrote: > > Hi, > > > > an untested 2to3 port of UDD code is in python3 branch of > > > >https://salsa.debian.org/qa/udd/-/tree/python3 > > ..

Re: [UDD] Upload_history table is currently empty

should be the right time. Kind regards Andreas. On Sun, Aug 02, 2020 at 10:47:04AM +0200, Lucas Nussbaum wrote: > Hi, > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966649 > > On 02/08/20 at 10:11 +0200, Andreas Tille wrote: > > Hi Lucas, > > > >

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/u

Issues with UDD importer [Was: Cron /srv/udd.debian.org/udd/rudd --status]

Hi, I've realised missings in UDD: nanofilt was recently accepted to Debian but: select * from sources where source='nanofilt'; select * from packages where package='nanofilt'; both have no result. This seems to correlate with the UDD status errors. Kind regards Andreas. - Forwarde

Re: Started porting UDD to Python3 (Was: [UDD] Is there some effort to port UDD to Python3?)

codeError: 'utf-8' codec can't decode byte 0xc5 in position 11: invalid continuation byte Thanks a lot anyway Andreas. On Mon, May 18, 2020 at 01:15:11PM +0200, Stéphane Blondon wrote: > Hello, > > On 15/05/2020 21:10, Andreas Tille wrote:> Would you mind providi

Re: Started porting UDD to Python3 (Was: [UDD] Is there some effort to port UDD to Python3?)

On Fri, May 15, 2020 at 08:51:05PM +0200, Stéphane Blondon wrote: > > And, ideally, somebody would contact whoever is providing that file so that > > they re-encode it with utf8... > > Yes, it's the best long term solution. Definitely. But who is providing that file? > >> `f = open(trfile, enc

Started porting UDD to Python3 (Was: [UDD] Is there some effort to port UDD to Python3?)

On Wed, May 13, 2020 at 07:40:56PM +0200, Andreas Tille wrote: > > > > Use the Vagrant development environment? > > I admit I've never worked with this. You said its pretty simple and I > would guess a python3 branch where everybody commits the code he feels > resp

Re: [UDD] Is there some effort to port UDD to Python3?

On Wed, May 13, 2020 at 05:09:02PM +0200, Lucas Nussbaum wrote: > On 13/05/20 at 16:38 +0200, Andreas Tille wrote: > > Hi Lucas, > > > > On Tue, Apr 14, 2020 at 08:47:11AM +0200, Andreas Tille wrote: > > > > > > > > Not as far as I know. I sus

Re: [UDD] Is there some effort to port UDD to Python3?

Hi Lucas, On Tue, Apr 14, 2020 at 08:47:11AM +0200, Andreas Tille wrote: > > > > Not as far as I know. I suspect that, once it becomes necessary, it will > > be easy to do given the codebase is relatively small. > > I agree that the small code base makes it probably

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Lucas, please forget my question - I simply missed the '--run' option. Sorry for the noise, Andreas. On Sat, May 02, 2020 at 09:37:43AM +0200, Andreas Tille wrote: > Hi Lucas, > > On Fri, May 01, 2020 at 10:57:39PM +0200, Lucas Nussbaum wrote: > > I fixed it and add

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Lucas, On Fri, May 01, 2020 at 10:57:39PM +0200, Lucas Nussbaum wrote: > I fixed it and added the same suites as you were, reverted your changes > and dropped the autopkgtest table. So everything should be fine. Thanks for this. > Sorry for not following closely enough when you started to wo

Re: [UDD] Is there any information about failed autopkgtest in UDD?

even have line 5 # FIXME there might be more suites at some point so you was aware of that issue. Would you mind solving that FIXME? Sorry, I do not speak Ruby. Kind regards Andreas. On Tue, Apr 14, 2020 at 06:12:39AM +0200, Andreas Tille wrote: > Hi Lucas, > > On Mon, Apr

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Paul, On Thu, Apr 16, 2020 at 10:30:17AM +0200, Paul Gevers wrote: > > H, what exactly means "superficial". > > Please read the documentation: > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst Thanks for this pointer. > > Are all those > >Testsui

Re: [UDD] Is there any information about failed autopkgtest in UDD?

On Thu, Apr 16, 2020 at 09:32:43AM +0200, Paul Gevers wrote: > Hi Andreas, > > On 15-04-2020 22:45, Andreas Tille wrote: > > autodep8-python3 PASS (superficial) > > superficial is translated to neutral. As is FAIL (flaky). H, what exactly means "su

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi, I think I've found some inconsistency of the autopkgtest data: packages_unstable_amd64.json contains: { "run_id": 4963349, "created_at": "2020-04-13 12:01:58 UTC", "updated_at": "2020-04-14 20:25:31 UTC", "suite": "unstable", "arch": "amd64", "package": "dnapi", "version": "1.1-

Re: [UDD] Is there some effort to port UDD to Python3?

Hi Lucas, On Mon, Apr 13, 2020 at 10:40:07PM +0200, Lucas Nussbaum wrote: > > we all know that Python2 is end of life but several UDD code is using > > Python2. Is there any effort to port it to Python3. > > Not as far as I know. I suspect that, once it becomes necessary, it will > be easy to do

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Andreas. > On 11/04/20 at 07:12 +0200, Andreas Tille wrote: > > Hi Paul, > > > > thanks for the clarification. This commit > > > > > > https://salsa.debian.org/qa/udd/-/commit/6a874a89365671dd37a14a9bca25290dc55a1fc9 > > > > imports the

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Fri, Apr 10, 2020 at 09:05:31PM +0200, Paul Gevers wrote: > Hi Andreas, > > On 09-04-2020 22:53, Andreas Tille wrote: > > valid_keys = ( 'run_id', > > # 'created_at', # Paul Gevers: should be ignored > > # &

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Paul, On Thu, Apr 09, 2020 at 10:44:18AM +0200, Paul Gevers wrote: > > > May be you consider some fields as really restricted to some > > special applications and nobody would ever consider querying > > UDD for it? > > Yes, I wouldn't add blame (I don't think we add those anymore, it's > lega

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Antonio, greetings to Curitiba. ;-) Hope you are fine! On Thu, Apr 09, 2020 at 09:37:41AM -0300, Antonio Terceiro wrote: > On Thu, Apr 09, 2020 at 10:44:18AM +0200, Paul Gevers wrote: > > Antonio, what do you think? If we expose the blacklist, I can also have > > britney consume it. > > I thi

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Paul, On Sun, Apr 05, 2020 at 09:20:21PM +0200, Paul Gevers wrote: > > For example > > that file contains some instances of deepnano but only as a rdepends of > > theano: > > deepnano is indeed a bad example as it is blacklisted in all suites and > all architectures: https://ci.debian.net/stat

Re: [UDD] Is there any information about failed autopkgtest in UDD?

Hi Paul, On Thu, Apr 02, 2020 at 05:20:54PM +0200, Paul Gevers wrote: > It depends what you look for. If you're concerned about failures that > will impact migration, the canonical place is: > https://release.debian.org/britney/excuses.yaml.gz (or the non-zipped > version) or directly (around 20 m

[UDD] Is there some effort to port UDD to Python3?

Hi, we all know that Python2 is end of life but several UDD code is using Python2. Is there any effort to port it to Python3. If not are there any volunteers to do this? Kind regards Andreas. -- http://fam-tille.de

[UDD] Is there any information about failed autopkgtest in UDD?

Hi, I intend to enhance the Blends framework by a QA page which also should include information about failed autopkgtests. Unfortunately I can not find any information about this in UDD. While the source table contains a field testsuite which tells whether the package has a test or not. But wher

Re: DEP12: debian/upstream/metdata doesn't allow specifying the VCS branch

On Wed, Dec 04, 2019 at 06:05:43PM +, Jelmer Vernooij wrote: > > > > This is another alternative to make things more clear and may be this > > should be prefered. > > Is there a process for making changes to debian/upstream/metadata > specification at the moment? Let me know if I should go and

Re: DEP12: debian/upstream/metdata doesn't allow specifying the VCS branch

Hi Jelmer, On Tue, Dec 03, 2019 at 02:27:58AM +, Jelmer Vernooij wrote: > The debian/upstream/metadata file spec > (https://wiki.debian.org/UpstreamMetadata) currently supports > a "Repository" field, but does not document a way of specifying what > branch in the repository the upstream sources

[UDD] upstream data exiting with error

Hi, it seems upstream data is currently not properly gathered. I checked ./update-and-run.sh upstream Traceback (most recent call last): /srv/udd.debian.org/udd/rudd:62:in `': No option specified (RuntimeError) and realised that I have no idea how this Ruby based importers are supposed to work

Re: What criterion is used for "has autopkgtest and migrates to testing in 2 days"?

On Wed, Sep 12, 2018 at 04:35:00PM +, Niels Thykier wrote: > > The r-cran-snakecase autopkgtests current fails: > https://ci.debian.net/packages/r/r-cran-snakecase/testing/amd64/ Grrr, there is a missing test-depends: r-cran-purrrlyr which needs to be packaged. I wonder why it escaped my att

What criterion is used for "has autopkgtest and migrates to testing in 2 days"?

Hi, sorry, not sure whether debian-qa list is correct but Paul is in To anyway. The package r-cran-snakecase has two ways to test: 1. debian/control defines Testsuite: autopkgtest-pkg-r 2. debian/tests/control.autodep8 (If 1. is given and there is debian/tests/control lintian is unhappy

BTS seems to send bugs to old maintainer of a package but displays new one correctly (Was: Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified)

Hi, On Thu, Sep 06, 2018 at 10:31:34PM +0200, Paul Gevers wrote: > > > BTW, do you have any idea why that bug is filed against Debian Med > > packaging list[1] while the maintainer of the package is > > r-pkg-t...@alioth-lists.debian.net? > > tracker.d.o? Hmmm, why should tracker.d.o keep a rec

[UDD] carnivore_gatherer.py has trouble parsing Maintainer name containing ','

Hi, I remember there was some discussion in ',' in maintainer names on debian-devel list. I'm now realising that the carnivore_gatherer has obvious problem with a ',' injected in the maintainer name. udd=# SELECT * FROM carnivore_names where name like '%Language Processing%' or name like '%Ja

Re: Redundant fields in debian/upstream/metadata and possible lintian check

ay for scientific references. So your initial experiment is really appreciated and had great consequences. > Le Wed, May 23, 2018 at 03:39:44PM +0200, Andreas Tille a écrit : > > > > at least in scientific packages the file debian/upstream/metadata is > > frequently used sinc

Re: Redundant fields in debian/upstream/metadata and possible lintian check

Hi Dylan, On Thu, May 24, 2018 at 01:25:50PM +0200, Dylan Aïssi wrote: > 2018-05-23 15:39 GMT+02:00 Andreas Tille : > > These data are gathered in UDD[2]. When I inspected the log of the UDD > > importer I noticed that there are a lot of redundant fields like > > "Hom

Redundant fields in debian/upstream/metadata and possible lintian check

Hi, at least in scientific packages the file debian/upstream/metadata is frequently used since it is the established way to specify citations belonging to some software.. The definition of the fields is given in Wiki[1]. These data are gathered in UDD[2]. When I inspected the log of the UDD imp

Re: What to do with the "Upstream info" links in the PTS and the packages-metadata branch in collab-qa ?

On Wed, May 16, 2018 at 09:56:11AM +0800, Paul Wise wrote: > > I can not parse this? The UDD gatherer is not using > > upstream-metadata.debian.net. It is rather reading Git repositories of > > selected Blends teams (formerly on Alioth now rewritten for Salsa[1]). > > The UDD gatherer consumes mo

Re: What to do with the "Upstream info" links in the PTS and the packages-metadata branch in collab-qa ?

Hi Paul, On Thu, May 10, 2018 at 01:46:46PM +0800, Paul Wise wrote: > > > The Debian Med team includes upstream information from these files > > in its "tasks" pages (see > > for example), using the UDD as a gatherer. > > This is using upstream-metadata.

Re: What to do with the "Upstream info" links in the PTS and the packages-metadata branch in collab-qa ?

On Tue, May 08, 2018 at 06:02:36PM +1000, Stuart Prescott wrote: > Are there any other consumers of these files? Definitely. > If there are no longer any consumers, should we really be nagging > maintainers to include them? > > $ lintian-info --list-tags | grep upstream-metadata > upstream-met

Re: on diverging memberships between alioth/salsa and unix group

On Wed, Mar 14, 2018 at 03:54:27PM +0100, Lucas Nussbaum wrote: > > As a data point, I also added Andreas to the qa group (as Developer) after > he asked in private mail and I didn't check debian-qa@ ;) I admit I have read QA later than your mail and just thought it might be a sensible input to m

Re: on diverging memberships between alioth/salsa and unix group

On Tue, Mar 06, 2018 at 11:28:41AM +0100, Mattia Rizzolo wrote: > > The salsa 'qa' group is very much not for maintaining package, much less > if you are actually planning on adopting it (you haven't ITAed it yet). > Please put it in the 'debian' group (i.e., the former collab-maint), or > elsewhe

Uploaders statistics

[CC-ing Debian-QA list where UDD issues are probably placed most apropriately and to avoid hidden / private discussion] Hi Eriberto, thanks for providing the statistics page about uploads of maintainers https://people.debian.org/~eriberto/udd/uploaders_ranking.html I was a bit curious abou

Re: Bug#884795: Bug#884795: patman: FTBFS on x32: final link failed: Nonrepresentable section

Hi for the reproducible builds and QA team, this discussion was triggered by bug #866137 which was causes by the fact that an arch:all package had different content depending whether it was build together with the arch any packages of htslib or independently. IMHO the verification that arch all p

Re: [UDD] Request for new field in bugs table: done_date

On Mon, Dec 11, 2017 at 08:43:09PM +0100, Lucas Nussbaum wrote: > On 11/12/17 at 10:20 +0100, Andreas Tille wrote: > > for the Debian Med bug squashing advent calendar[1] (may be other > > similar motivations to fix bugs) it would be nice to have a field > > closed_date (or so

[UDD] Request for new field in bugs table: done_date

Hi, for the Debian Med bug squashing advent calendar[1] (may be other similar motivations to fix bugs) it would be nice to have a field closed_date (or some more sensible name) to get the information when a bug was closed. This could also help to get some stats about how long bugs in Debian were

Re: [UDD] Missing descriptions for some packages

That's solved now. On Sun, Sep 24, 2017 at 12:37:02AM +0200, Andreas Tille wrote: > Hi, > > I realised that UDD is lacking some descriptions and long_descriptions for > some packages. For instance for abacas I get: > > udd=# SELECT DISTINCT p.package, p.release, p.ver

[UDD] Missing descriptions for some packages

Hi, I realised that UDD is lacking some descriptions and long_descriptions for some packages. For instance for abacas I get: udd=# SELECT DISTINCT p.package, p.release, p.version, en.description AS description_en FROM packages p LEFT JOIN descriptions en ON en.language = 'en' AND en.package =

Re: QA at DebConf17?

Hi Paul, On Wed, Mar 15, 2017 at 08:48:03AM +0800, Paul Wise wrote: > Any QA folks coming to DebConf17? > > What events have folks submitted? I have not commited anything QA specific. What I would *really* like to hear is some introduction how to effectively use gdb when trying to track down up

Re: http:// vs. https:// in machine readable copyright file

Hi, On Wed, Jan 04, 2017 at 01:53:48PM +0900, Charles Plessy wrote: > > Actually, there is at least one addition to the format that has gained > traction > since it was proposed, so maybe the best way forward is to release a version > 1.1 with a HTTPS URL ? > > The addition is the Files-Exclude

Re: Screenshots.debian.net leaves useless URLs in JSON output

Hi Christoph, On Tue, Jul 19, 2016 at 09:44:05PM +0200, Christoph Haas wrote: > > The fix is deployed. Thanks for the quick fix. I can confirm that the json looks OK. > You will always get URLs starting with https://… to > be safe when linking them. https is fine. > Let me know if you need

Re: Screenshots.debian.net leaves useless URLs in JSON output

Hi Christoph, On Tue, Jul 19, 2016 at 12:41:49PM +0200, Christoph Haas wrote: > sorry for that. Apparently the web application is not aware of its > real-life URL but rather sees itself behind the caching proxy. I'll fix > that today. :-) > The crazy thing is that get requests to > http://scree

  1   2   3   4   5   6   >