Package: wnpp
Severity: wishlist
Owner: Daniel Leidert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: ruby-jekyll-readme-index
Version : 0.2.0
Upstream Author : Ben Balter
* URL : https://github.com/benbalter/jekyll-readme-index
* License : MI
Package: wnpp
Severity: wishlist
Owner: Daniel Leidert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: ruby-jekyll-relative-links
Version : 0.6.0
Upstream Author : Ben Balter
* URL : https://github.com/benbalter/jekyll-relative-links
* License
Package: wnpp
Severity: wishlist
Owner: Daniel Leidert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: ruby-jekyll-default-layout
Version : 0.1.4
Upstream Author : Ben Balter
* URL : https://github.com/benbalter/jekyll-default-layout
* License
Package: wnpp
Severity: wishlist
Owner: Laurent Baillet
* Package name: libprogress-any-output-termprogressbarcolor-perl
Version : 0.245
Upstream Author : perlancar
* URL :
https://metacpan.org/release/Progress-Any-Output-TermProgressBarColor
* License : Arti
Hi Lisandro,
On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote:
>> All autopkgtest failures considered RC for bullseye
>> ===
>>
>> From now on, all autopkgtest failures will be considered release-critical for
>> bullseye. So if your pac
Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷)
* Package name: fontbakery
Version : 0.7.9
* URL : https://github.com/googlefonts/fontbakery
* License : Apache-2.0
Programming Lang: Python 3
Description : Font quality checker
Fontbakery is a tool t
On Sat, 20 Jul 2019 at 00:21:10 +0200, Christoph Biedl wrote:
> The build system of the file package uses autoconf to check for
> presence of the seccomp library and will just disable that feature if
> support is missing. But just adding "libseccomp-dev" will break the
> build on e.g. alpha for an
On 2019-07-19 15:13, Adrian Bunk wrote:
> There are two current release architectures where it is at least
> imaginable that they will still be around closer to the year 2038:
> i386 and armhf
With the current way packages are built, i.e. natively on the same
architecture, I don't see 32-bit arch
Hello Mattia,
Thank you for your email.
On Sat, 2019-07-20 at 14:49 +0200, Mattia Rizzolo wrote:
> 20190720123419|process-upload|dak|thunarx-python_0.5.1-
> 1_amd64.changes|Error while loading changes: No valid signature
> found. (GPG exited with status code 0)
> 20190720123419|process-upload|dak
On 2019-07-20 07:58, Johannes Schauer wrote:
> No it does not block this. The sbuild configuration variable
> $resolve_alternatives or the command line option --resolve-alternatives allows
> one to enable or disable that sbuild only uses the first alternative.
>
> As Gregor also correctly wrote, t
Package: wnpp
Severity: wishlist
Owner: Steffen Moeller
* Package name: ricks-amdgpu-utils
Version : 2.5.1
* URL : https://github.com/Ricks-Lab/amdgpu-utils
* License : GPL
Programming Lang: Python
Description : commandline AMD GPU monitoring and optimiza
Package: wnpp
Severity: wishlist
Owner: Anton Gladky
* Package name: kim-models
Version : 20190331
Upstream Author : Ryan S. Elliott
* URL : https://openkim.org/kim-api/
* License : COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version
1.0
Programming L
On Sat, Jul 20, 2019 at 03:47:43PM +0530, Ritesh Raj Sarraf wrote:
> I made a couple of uploads in the last couple of weeks.
> I did get email confirmation for my uploads but that is it. None of my
> package uploads have been processed.
That's the obvious sign that your GPG key is not working anym
Package: wnpp
Severity: wishlist
Owner: Daniel Leidert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: ruby-jekyll-remote-theme
Version : 0.4.0
Upstream Author : Ben Balter
* URL : https://github.com/benbalter/jekyll-remote-theme
* License : MI
Hi,
I made a couple of uploads in the last couple of weeks.
I did get email confirmation for my uploads but that is it. None of my
package uploads have been processed.
I thought it must have been because of the Buster release freeze but I
see other package uploads from other developers showing up
On Jul 20, Christoph Biedl wrote:
> * Centralize the list of supported archs in the seccomp packages. By
> either creating an empty libseccomp-dev for the archs where seccomp
> is not supported, or by creating a "libseccomp-dev-dummy" for these.
> In the latter case package maintainers woul
16 matches
Mail list logo