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

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

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

Bug#1055550: Removal of Python3 package of redland-bindings breaks mozilla-devscripts

Hi Doko, thanks for working on the QA upload to fix #100 and #1056518 of redland-bindings by simply removing the Python3 support. Unfortunately it breaks mozilla-devscripts and thus it cant migrate to testing[1]. Kind regards Andreas. [1]

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

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

fano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli" | Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli "Andreas Tille "| Andreas T

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: &g

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

UDD contains names where spaces are not stripped

roli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli " Stefano Zacchiroli" | Stefano Zacchiroli " Stefano Zacchiroli"| Stefano Zacchiroli "Andreas Tille "| Andreas Tille &q

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" im

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

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

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

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

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 see

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? I will t

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

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

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 th

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

[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

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 |

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

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

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

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

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 |

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

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

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

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]

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

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

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

ite> 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 Team|debian-med-

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

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 > > > > It used to work

Bug#957717: [Help] pvm: ftbfs with GCC-10

Hi, while I do not intend to maintain pvm personally some Debian Med package depend from it. Thus I like to see bug #957717 fixed but I need help. I commited some general packaging changes so you can find the last packaging state in Git[1]. When building this I get the following output: cc

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

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

it 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

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. -

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

eDecodeError: '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 providing a > patch

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,

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 > responsib

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 kn

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 added the sam

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

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

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":

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

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

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 current data. I

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

. On 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 > > # 'updated_at',

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 >

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

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

[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

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

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

Bug#924838: Any idea how to fix remote access when trying to build package?

Hi, any idea how to fix the attempt to access remote location when trying to build? Kind regards Andreas. -- http://fam-tille.de

Bug#924838: Maintenance of scoop (Was: FTBFS: Could not import extension sphinx.ext.pngmath (exception: No module named pngmath))

Hi, I pushed a patch for #924838 to Git but unfortunately there is an issue with the build time test suite that tries to access remoto hosts: ... debian/rules override_dh_auto_test make[1]: Entering directory '/build/scoop-0.7.1.1' PYBUILD_SYSTEM=custom \ PYBUILD_TEST_ARGS="cd {dir}/test;

Bug#920459: toulbar2: What will happen if testing migration takes longer than removal from testing

pkg/toulbar2 [2] https://udd.debian.org/cgi-bin/autoremovals.cgi > > On 19 Feb 2019, at 08:46, Andreas Tille wrote: > > > > Hi, > > > > toulbar2 is > > > > Marked for autoremoval on 22 February: #916715 > > > > However, this bug was cl

Bug#920459: toulbar2: What will happen if testing migration takes longer than removal from testing

otherwise toulbar2 does not build (see bug #920459). This means should be reverted once doxygen is fixed. ... -- Andreas Tille Mon, 18 Feb 2019 22:17:10 +0100 Which enabled the build on all release architectures. I'm simply wondering what will happen with toulbar2 (and other packages

Bug#921779: Bug#919413: cascade of FTBFS

On Thu, Feb 14, 2019 at 03:16:22PM +0100, Dominique Dumont wrote: > On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote: > > I'm > > not sure how to deal with the jquery.js one since this is potentially an > > issue with lots of dependencies - I remember discussions

Bug#921779: cascade of FTBFS

p://fam-tille.de >From b0a8a6a14c391fbc40489ab6df984435efaba1c4 Mon Sep 17 00:00:00 2001 From: Andreas Tille Date: Tue, 12 Feb 2019 16:02:57 +0100 Subject: [PATCH] Fix watch file --- debian/changelog | 4 debian/watch | 4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/

[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

Re: #705208,ITA: pylibtiff -- wrapper to the libtiff library to Python using ctypes

I'd be happy if you take pylibtiff, Andreas. On Sun, Dec 23, 2018 at 08:37:55PM +0100, Antonio Valentino wrote: > Hello, > I would like to adopt the pylibtiff [1] package because it is a > dependency of the new satpy that I'm going to package (#917110). > > The pylibtiff package would become

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

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

[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

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

ed way 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 <andr...@an3as.eu>: > > 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 fiel

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

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

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

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 >

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

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 >

Accepted id3v2 0.1.12+dfsg-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 01 Feb 2018 13:24:36 +0100 Source: id3v2 Binary: id3v2 Architecture: source Version: 0.1.12+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Debian QA Group <packa...@qa.debian.org> Changed-By: Andreas Til

Accepted libavg 1.8.2-1 (source) into unstable

ain...@lists.alioth.debian.org> Changed-By: Andreas Tille <ti...@debian.org> Description: python-libavg - High-level development platform for media-centric applications Changes: libavg (1.8.2-1) unstable; urgency=medium . * Team upload. * New upstream version * Moved packaging from SVN to Gi

  1   2   3   4   5   6   >