Bug#898095: ITP: node-syslog-client -- pure JavaScript implementation of Syslog protocol

Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: node-syslog-client Version : 1.1.1 Upstream Author : Paul Grove * URL : https://github.com/paulgrove/node-syslog-client * License : Expat Programming Lang: JavaScript Description :

Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

Hi Paul, > Please find a proposed text for such an e-mail below. Comments or > improvements very welcome. Just some brief and somewhat-pedantic suggestions for improvements below. Beyond that, I'd love to see some parsable X-Foo: headers. I find these very helpful in the BTS's mails to reliably f

Re: uploaded but not processed

On 15029 March 1977, Mattia Rizzolo wrote: > The upload will stay in the queue forever until either the key becomes > trusted again and so it can be processed (e.g. you push an update the > the keyring maintainers push it to the live keyring) or an ftp-master > manually moves it out of the way. Mo

RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

Hi all, On 06-05-18 07:27, Paul Gevers wrote: >> But, anyway, thanks for your effort, but it obviously doesn't scale to >> have the central infrastructure team triage things. How easy would it >> be to have the CI automatically send an email to the maintainers of >> the rdependency and the depend

Re: Dealing with ci.d.n for package regressions

Hi Ian, On 04-05-18 13:08, Ian Jackson wrote: > Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"): >> I hadn't realissed that _test_ dependencies would trigger retests, as >> well as actual package dependencies. > > Having read Mattia's message, and looking at the Testsuite-T

Bug#898071: ITP: foundationdb -- distributed, transactional, key-value store

Package: wnpp Severity: wishlist Owner: Nicolas Braud-Santoni * Package name: foundationdb Version : 5.1.7 Upstream Author : Apple Inc. * URL : https://www.foundationdb.org/ * License : Apache-2.0 Programming Lang: C/C++ with bindings for many others Descri

Bug#898063: ITP: r-cran-batchtools -- GNU R tools for computation on batch systems

Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-batchtools Version : 0.9.8 Upstream Author : Michel Lang * URL : https://cran.r-project.org/package=batchtools * License : LGPL Programming Lang: GNU R Description : GNU R too

Re: uploaded but not processed

On Sun, 6 May 2018, 5:00 p.m. Jerome BENOIT, wrote: > Hi, > > On 06/05/18 17:12, Mattia Rizzolo wrote: > > The upload will stay in the queue forever until either the key becomes > > trusted again and so it can be processed (e.g. you push an update the > > What do you mean by `you push an update'

Re: [1/2] MBF: Defunct alioth addresses in the Maintainer: field (serious)

On Sat, May 05, 2018 at 05:34:10PM +0200, Christoph Biedl wrote: > A lot of now defunct alioth addresses are used in the Maintainer: > field. This makes the packages rc-buggy for an invalid address. > > To create awareness about that issue, also to provide suggestions on > how to resolve this I in

Re: uploaded but not processed

Hi, On 06/05/18 17:12, Mattia Rizzolo wrote: > To expand on what this means: > > On Sun, May 06, 2018 at 12:24:53PM +0100, Adam D. Barratt wrote: >> You can log in to mirror.ftp-master.debian.org (currently coccia.d.o) >> and check /srv/ftp-master.debian.org/log/current , which will indeed >> rev

Bug#898061: ITP: r-cran-base64url -- GNU R fast and URL-safe Base64 encoder and decoder

Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-base64url Version : 1.3 Upstream Author : Michel Lang * URL : https://cran.r-project.org/package=base64url * License : GPL Programming Lang: GNU R Description : GNU R fast and

Bug#898059: ITP: r-cran-rappdirs -- GNU R application directories

Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-rappdirs Version : 0.3.1 Upstream Author : Hadley Wickham * URL : https://cran.r-project.org/package=rappdirs * License : MIT Programming Lang: GNU R Description : GNU R appli

Re: uploaded but not processed

To expand on what this means: On Sun, May 06, 2018 at 12:24:53PM +0100, Adam D. Barratt wrote: > You can log in to mirror.ftp-master.debian.org (currently coccia.d.o) > and check /srv/ftp-master.debian.org/log/current , which will indeed > reveal the issue you suspect: > > 20180506110423|process-

Re: uploaded but not processed

Thanks for your prompt reply. On 06/05/18 15:24, Adam D. Barratt wrote: > On Sun, 2018-05-06 at 14:52 +0400, Jerome BENOIT wrote: >> Hello, >> >> my two last upload were successfully uploaded (yesterday and the day >> before), >> but they have not yet been precessed. The involved packages are: 4ti

Re: uploaded but not processed

On Sun, 2018-05-06 at 14:52 +0400, Jerome BENOIT wrote: > Hello, > > my two last upload were successfully uploaded (yesterday and the day > before), > but they have not yet been precessed. The involved packages are: 4ti2 > and mpfrcxx. > I suspect a keying issue. Is there a log where I can get mor

uploaded but not processed

Hello, my two last upload were successfully uploaded (yesterday and the day before), but they have not yet been precessed. The involved packages are: 4ti2 and mpfrcxx. I suspect a keying issue. Is there a log where I can get more info ? Thanks in advance, Jerome -- Jerome BENOIT | calculus+at-