uploaded but not processed

[Jerome BENOIT]

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-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Re: uploaded but not processed

[Adam D. Barratt]

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 more info ?

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-upload|dak|mpfrc++_3.6.5+ds-3_source.changes|Error while 
loading changes: No valid signature found. (GPG exited with status code 0)
gpg: Signature made Sat May  5 13:12:42 2018 UTC
gpg:using RSA key AE28AE15710DFF1D87E5A7623F9219A67F36C68B
gpg:issuer "calcu...@rezozer.net"
gpg: Good signature from "Jerome Benoit " [expired]
gpg: aka "Jerome Benoit " [expired]
gpg: WARNING: Using untrusted key!

This can also be checked by examining the local copy of the keyring:

$ gpg --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg --list-keys 
calculus
pub   rsa8192 2016-05-04 [SCEA] [expired: 2018-05-01]
  AE28AE15710DFF1D87E5A7623F9219A67F36C68B
uid   [ expired] Jerome Benoit 
uid   [ expired] Jerome Benoit 

Regards,

Adam

Re: uploaded but not processed

[Jerome BENOIT]

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: 4ti2
>> and mpfrcxx.
>> I suspect a keying issue. Is there a log where I can get more info ?
> 
> 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:
> 

Indeed !

> 20180506110423|process-upload|dak|mpfrc++_3.6.5+ds-3_source.changes|Error 
> while loading changes: No valid signature found. (GPG exited with status code 
> 0)
> gpg: Signature made Sat May  5 13:12:42 2018 UTC
> gpg:using RSA key AE28AE15710DFF1D87E5A7623F9219A67F36C68B
> gpg:issuer "calcu...@rezozer.net"
> gpg: Good signature from "Jerome Benoit " [expired]
> gpg: aka "Jerome Benoit " [expired]
> gpg: WARNING: Using untrusted key!
> 
> This can also be checked by examining the local copy of the keyring:
> 
> $ gpg --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg 
> --list-keys calculus
> pub   rsa8192 2016-05-04 [SCEA] [expired: 2018-05-01]
>   AE28AE15710DFF1D87E5A7623F9219A67F36C68B
> uid   [ expired] Jerome Benoit 
> uid   [ expired] Jerome Benoit 
> 

Meanwhile I changed the expired date of my key.
When I try to update it at keyring.debian.org with the command

$ gpg --keyserver keyring.debian.org --send-keys 0x3F9219A67F36C68B

I get the message

gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in 
dirmngr.conf
gpg: keyserver option 'no-try-dns-srv' is unknown
gpg: sending key 0x3F9219A67F36C68B to hkp://keyring.debian.org
gpg: keyserver send failed: Operation not permitted
gpg: keyserver send failed: Operation not permitted

Was my attempt to late ?

Whatever, what should be the next step ?

Thanks again,
Jerome

> Regards,
> 
> Adam
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Re: uploaded but not processed

[Mattia Rizzolo]

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-upload|dak|mpfrc++_3.6.5+ds-3_source.changes|Error 
> while loading changes: No valid signature found. (GPG exited with status code 
> 0)
> gpg: Signature made Sat May  5 13:12:42 2018 UTC
> gpg:using RSA key AE28AE15710DFF1D87E5A7623F9219A67F36C68B
> gpg:issuer "calcu...@rezozer.net"
> gpg: Good signature from "Jerome Benoit " [expired]
> gpg: aka "Jerome Benoit " [expired]
> gpg: WARNING: Using untrusted key!

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.

The next keyring update will most likely happen in ~3 weeks time.

Note that having somebody else sponsor the same version again now will
fail (queued will reject it), so in case you'd like to have those
packages updated within the next 3 weeks you'll need somebody to sponsor
you an higher version (and then these uploads will be rejected once the
key is trusted again).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Andreas Tille]

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 application directories
 This GNU R package provides functions to determine where to save data,
 caches and Logs.
 .
 An easy way to determine which directories on the users computer
 you should use to save data, caches and logs. This is a port of Python's
 Appdirs to R.


Remark:  This package is a precondition to fix bug #882371 which needs
packaging of r-cran-batchtools which in turn needs r-cran-rappdirs to
build.  It will be maintained by the R pkg team at
https://salsa.debian.org/r-pkg-team/r-cran-rappdirs

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

[Andreas Tille]

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 URL-safe Base64 encoder and decoder
 In contrast to RFC3548, the 62nd character ("+") is replaced with
 "-", the 63rd character ("/") is replaced with "_". Furthermore, the encoder
 does not fill the string with trailing "=". The resulting encoded strings
 comply to the regular expression pattern "[A-Za-z0-9_-]" and thus are
 safe to use in URLs or for file names.
 The package also comes with a simple base32 encoder/decoder suited for
 case insensitive file systems.


Remark:  This package is a precondition to fix bug #882371 which needs
packaging of r-cran-batchtools which in turn needs r-cran-base64url to
build.  It will be maintained by the R pkg team at
https://salsa.debian.org/r-pkg-team/r-cran-base64url

Re: uploaded but not processed

[Jerome BENOIT]

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
>> reveal the issue you suspect:
>>
>> 20180506110423|process-upload|dak|mpfrc++_3.6.5+ds-3_source.changes|Error 
>> while loading changes: No valid signature found. (GPG exited with status 
>> code 0)
>> gpg: Signature made Sat May  5 13:12:42 2018 UTC
>> gpg:using RSA key AE28AE15710DFF1D87E5A7623F9219A67F36C68B
>> gpg:issuer "calcu...@rezozer.net"
>> gpg: Good signature from "Jerome Benoit " [expired]
>> gpg: aka "Jerome Benoit " [expired]
>> gpg: WARNING: Using untrusted key!
> 
> 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' ?

> the keyring maintainers push it to the live keyring) or an ftp-master
> manually moves it out of the way.
> 
> The next keyring update will most likely happen in ~3 weeks time.

So I have something as 2 week before me to update my key.

> 
> Note that having somebody else sponsor the same version again now will
> fail (queued will reject it), so in case you'd like to have those
> packages updated within the next 3 weeks you'll need somebody to sponsor
> you an higher version (and then these uploads will be rejected once the
> key is trusted again).

Thanks,
Jerome
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Re: uploaded but not processed

[Mattia Rizzolo]

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

gpg --keyserver keyring.debian.org --send-key 
I.e. what you were trying to do according to that other email (I can't help
with that, sorry).

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

[Dominic Hargreaves]

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 intend to do a MBF using the following message:

Thanks for doing this detailed work - which is very timely and important
to ensure that communication paths within Debian remain open.

> as you've probably heard, Debian's alioth services are shutting down.
> This affects your package [% package %] since the address [%
> alioth_list %] used in the Maintainer: field was not transferred to the
> alioth-lists service that provides a continuation for the lists in the
> @lists.alioth.debian.org domain.
> 
> Addresses that were not migrated have been disabled a few days ago. As

A bit more than a few days ago now - the migration was on 14th April

> a result your package is now in violation of a "must" in the Debian
> policy (3.3, working email address), making it unfit for release.
> 
> Please fix this before long. Among other reasons, keep in mind bug
> reports and important notifications about your package might not reach
> you.
> 
> Your options:
> 
> * Upload another version with a new maintainer address of your choice,
> 
> or
> 
> * Migrate the list the new system. This is still possible,
   ^ to   ^:

[these changes apply to the other mail too]

>   please appoint a Debian developer as a list owner first, then
>   contact the alioth lists migration team 
>   and provide all the necessary information.
> 
>   More information about the new service can be found here:
>   
> 
> The first option is probably suitable only if the address was used just
> in a small number of packages since this requires an upload for each of
> them. To our knowledge, the usage count of [% alioth_list %] is [% count %].

I think I would leave it to package maintainers to decide whether they
think uploads of all packages are practical or not.

Also it might be be worth referring to the other options for team
addresses, even if they are imperfect:

https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list

> The second option is available for a limited time only, by end of
> May 2018 the most. So if you're interested in going this way, start the
> process as soon as possible.
> 
> Note, as mails to the maintainer address will not get through, this
> bugreport is Cc'ed to all uploaders of the package.
> 
> Regards,
> 
> Christoph and some alioth-lists maintainers
> --
> 
> Affected packages below, as created by dd-list. The total count is 711

Since the number of bugs is pretty large, I think it would be best to
file these in batches.

> Cheers,
> 
>Christoph
> 
> 
> The list was generated using
> 
> * Debian sid sources, Release file Date: Sat, 05 May 2018 08:30:59 UTC
> 
> * List of defunct alioth lists
>   
> 
>   commit 86fefce911c172319fbf61f772a63e6cd2720c6d
>   Author: Dominic Hargreaves 
>   Date:   Wed Apr 25 20:55:15 2018 +0100

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

[Andreas Tille]

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 tools for computation on batch systems
 As a successor of the packages 'BatchJobs' and 'BatchExperiments',
 this package provides a parallel implementation of the Map function for
 high performance computing systems managed by schedulers IBM Spectrum LSF
 OpenLava, Univa Grid Engine/Oracle Grid Engine, Slurm, TORQUE/PBS, or
 Docker Swarm.
 .
 A multicore and socket mode allow the parallelization on a local machines,
 and multiple machines can be hooked up via SSH to create a makeshift
 cluster. Moreover, the package provides an abstraction mechanism to define
 large-scale computer experiments in a well-organized and reproducible way.


Remark:  This package is a precondition to fix bug #882371.  It will be
maintained by the R pkg team at
https://salsa.debian.org/r-pkg-team/r-cran-batchtools

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

[Nicolas Braud-Santoni]

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
  Description : distributed, transactional, key-value store

FoundationDB is a distributed database designed to handle large volumes of
structured data across clusters of commodity servers. It organizes data as an
ordered key-value store and employs ACID transactions for all operations. It is
especially well-suited for read/write workloads but also has excellent
performance for write-intensive workloads. Users interact with the database
using API language binding.

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

[Paul Gevers]

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-Triggers
> line which is autogenerated in dgit.dsc, I see that actual package
> dependencies are not included.
> 
> That seems wrong to me.  foo/debian/tests/control will normally
> declare a dependency on foo (perhaps by saying `@'); it then won't
> normally mention all of foo's dependencies.

I am not 100% sure (I would have to find the old discussion of before my
involvement), but I think the reason is that the normal triggers are
otherwise available to britney. So this field (as $(man dsc) says) only
stores the TEST dependencies.

> The result of the current behaviour is that regressions introduced by
> test framework code are more likely to be detected than regressions
> introduced by ordinary dependencies.

I don't think so, but let me look up the code:
https://salsa.debian.org/release-team/britney2/blob/master/britney2/policies/autopkgtest.py
(line 354 to 446 at commit e51a3b91)

Starting at line 413 britney adds the reverse dependencies of the
package under consideration.

Paul



signature.asc
Description: OpenPGP digital signature

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

[Paul Gevers]

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 dependency ?
> 
> I have already created multiple personal scripts to parse excuses.yaml
> and store state on regressions, so this is trivial. However, people have
> voiced their concerns about auto creation of bugs. I estimate that a
> plain email for now is acceptable. I think I'll ask about converting the
> email to a bug I guess. I'll create a cronjob that does this soon,
> putting myself in CC to follow the discussion as it would actually
> reduce my work for now.

Please find a proposed text for such an e-mail below. Comments or
improvements very welcome.

Paul

=
To: $trig...@packages.debian.org, $bro...@packages.debian.org
CC: elb...@debian.org
Subject: New version of $trigger breaks autopkgtest of $broken in testing

Dear maintainers,

[This e-mail is automatically sent.]

As recently announced¹ Debian is now running autopkgtests in testing to
check if migration of a new source package causes regressions. It does
this with the binary packages of the new version of a source package
from unstable.

With the upload of version $ver of $trigger the autopkgtest of $broken
started to fail in testing². This is currently delaying the migration of
$trigger version ${ver}³.

This e-mail is meant to trigger direct communication between the
maintainers of the involved packages as one party has insight in what
changed and the other party insight in what is being tested. After all,
a regression in a reverse dependency can come due to one of the
following reasons (of course not complete):
* new bug in the candidate package (fix the package)
* bug in the test case that only gets triggered due to the update (fix
  the reverse dependency, but see below)
* out-of-date reference date in the test case that captures a former bug
  in the candidate package (fix the reverse dependency, but see below)
* deprecation of functionality that is used in the reverse dependency
  and/or its test case (discussion needed)

Unfortunately sometimes a regression is only intermittent. Ideally this
should be fixed, but it may be OK to just have the autopkgtest retried
(a link is available in the excuses³).

There are cases where it is required to have multiple packages migrate
together to have the test cases pass, e.g. when there was a bug in a
regressing test case of a reverse dependency and that got fixed. In that
case the test cases need to be triggered with both packages from
unstable (reply to this e-mail and/or contact the ci-team⁴) or just wait
until the aging time is over (if the fixed reverse dependency migrates
before that time, the failed test can be retriggered³).

Of course no system is perfect. In case a framework issue is suspected,
don't hesitate to raise the issue via bts or to the ci-team⁴ (reply to
me is also fine for initial cross-check).

To avoid stepping on peoples toes, this e-mail is not automatically
generating a bug in the bts, but it is highly recommended to forward
this e-mail there (psuedo-header boilerplate below⁵⁶) in case it is
clear which package should solve this regression.

¹ https://lists.debian.org/debian-devel-announce/2018/05/msg1.html
² https://ci.debian.net/packages/$b/$broken/testing/amd64/
³ https://qa.debian.org/excuses.php?package=$trigger
⁴ #debci on oftc or debian...@lists.debian.org
⁵ $trigger has an issue

Source: $trigger
Version: $ver
Severity: normal or higher
Control: affects -1 src:$broken
User: debian...@lists.debian.org
Usertags: breaks

⁶ $broken has an issue

Source: $broken
Version: $ver_of_broken_that_ran
Severity: normal or higher
Control: affects -1 src:$trigger
User: debian...@lists.debian.org
Usertags: needs-update




signature.asc
Description: OpenPGP digital signature

Re: uploaded but not processed

[Joerg Jaspert]

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.

Moved them out of the queue.

-- 
bye, Joerg

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

[Chris Lamb]

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 file things
in my email setup.

> Subject: New version of $trigger breaks autopkgtest of $broken in testing
 ^
 s
> As recently announced¹ Debian is now running autopkgtests in testing to
   ^
I've been big Unicode fan ("... ever since the release of their 1980
album, Duke", etc.) but I find this style of numbering really quite
difficult to read/parse in the middle of text with my particular
combination of typeface, font size, antialiasing and screen resolution.

Either that or I'm getting old.


> check if migration of a new source package causes regressions. It does
 the
> this with the binary packages of the new version of a source package
 the

> a regression in a reverse dependency can come due to one of the
be
   
> To avoid stepping on peoples toes, this e-mail is not automatically
does
> generating a bug in the bts
generate a bug in the BTS


Thanks again for working on this. :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

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

[Xavier Guimard]

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 : pure JavaScript implementation of Syslog protocol

syslog-client is a pure JavaScript implementation of the BSD Syslog Protocol
RFC 3164 and the Syslog Protocol RFC 5424. It can easily be used to push
some message from a Node.js application to system syslog service.