Package: procps
Version: 2:3.3.17-5
Severity: serious
Dear maintainer,
calling kill(1) with negative PIDs always delivers the signal to the
current process group, instead of the one with the specified PID. That
is because the binary always calls kill(2) with 0 as first argument.
This is known
Package: python3-pip
Version: 20.3.4-4
Severity: normal
Dear maintainers,
consider the following minimal Python project with setuptools packaging
and a "pyproject.toml" file (see PEP 518 and [1]):
> tree myproject
myproject
|-- myproject
| `-- __init__.py
|-- pyproject.toml
|-- setup.cfg
`--
Package: prometheus
Version: 2.7.1+ds-3+b11
Severity: wishlist
Dear maintainers,
due to the rapid upstream development, the Prometheus version in Buster is
already quite outdated.
Could you please backport the version from Bullseye?
Thanks and Regards,
Felix
I can confirm this for openssh-client 1:7.4p1-10+deb9u1 on Stretch.
It also affects OpenSSH 7.4p1 on macOS, so I guess it really is an upstream
issue.
Furthermore, the ssh_config manpage says about `HostKeyAlgorithms`:
>[...],
>ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
Package: g++
Version: 4:6.3.0-1
Severity: normal
Dear maintainers,
I observed some unexpected behavior with g++ (4:6.3.0-1) and GDB (7.12-6) on
Stretch:
Please have a look at the attached source file, which is the minimal example I
could come up with to demonstrate the issue.
We compile it (I
Tags: patch
Hi,
sorry, I broke this with the patch from #830222: In commit 8c69d33, I moved
the "JAVA" environment variable to the init script, as it cannot not be used
in the systemd unit file (that requires absolute executable paths).
However, other ZooKeeper tools rely on it being set in
On 14 Jul 2016, at 15:16, Emmanuel Kasper wrote:
> A fix for this issue has been committed yesterday, see
> http://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/commit/
Whoa, that's good timing I guess.
Thanks and regards,
Felix
Package: cloud.debian.org
Severity: normal
Tags: security
Dear Debian cloud maintainers,
in the "jessie64" Vagrant box (and presumably the other Vagrant boxes as
well), the insecure Vagrant default SSH key is installed as authorized key for
the root user and root login using SSH keys is
Package: zookeeperd
Version: 3.4.8-1
Severity: normal
Tags: patch
Dear maintainers,
the attached patches (in git-format-patch format) add a systemd unit file for
ZooKeeper to the zookeeperd package.
Due to the way systemd works and an issue with dh-systemd (#830208), some
changes were necessary
Source: zookeeper
Version: 3.4.8-1
Severity: minor
Tags: patch
Dear maintainers,
the package build for zookeeper uses dh-python, but is not mentioned in the
Build-Depends list of debian/control so far.
The attached patch fixes that.
Regards,
Felix
dh-python.patch
Description: Binary data
Package: dh-systemd
Version: 1.36
Severity: normal
Dear dh-systemd developers,
at the moment, systemd unit files get installed by both dh_installinit and
dh_systemd_enable. There is a comment in dh_systemd_enable regarding this:
> XXX: This is duplicated in dh_installinit, which is unfortunate.
Package: cups-browsed
Version: 1.9.0-1
Severity: important
Dear maintainers,
the cups-browsed.service unit file specifies 'Requires', 'After' and 'Wants'
directives on cups.service. However, the CUPS daemon is not a dependency
of the cups-browsed package.
Including the same unit in both
This appears to have been fixed upstream in 4.4.1:
https://groups.google.com/d/msg/modwsgi/IDqLeoc_VXU/Fy3ijUJ8rYsJ
Regards,
Felix
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I can confirm such behaviour, but I don’t think it’s a bug:
The `request` setting really only specifies what options the client’s request
contains. The server then replies with some arbitrary options, which may or may
not match the requested. The client applies whatever options that response
I can confirm this as well. However, in my case it looks like it’s the key I’m
signing with (my key) which has the expired subkeys.
On 2.x, the error message looks different, but the error appears to be the same:
cannot sign: [GNUPG:] KEYEXPIRED timestamp
Regards,
Felix
--
To UNSUBSCRIBE,
On 16 Feb 2014, at 03:34, Felix Dreissig f...@f30.me wrote:
You should probably send stdout to '/dev/null' as well.
Gna. I meant stderr, of course.
Regards,
Felix
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
On 14 Feb 2014, at 17:13, Antoine Beaupré anar...@debian.org wrote:
i have added a predicate so this doesn't fail if rst2s5 is missing, can
you try the 2.x branch again?
The approach generally works, however I still see a rst2s5: command not found
error message.
It now just doesn’t emerge
Package: monkeysign
Version: 2.x
Severity: normal
I wanted to build the manpage only for Monkeysign’s CLI version, so I removed
`monkeyscan:monkeysign.gtkui:MonkeysignScanUi.parser` from ‘setup.cfg' and ran
`setup.py build_manpage`.
That failed with:
UnicodeDecodeError: 'ascii' codec can't
Package: monkeysign
Version: 2.x
Severity: minor
There are two minor issues with the build_slides() function, which attempts to
build 'presentation.html' from 'presentation.rst':
1. It is always part of the build, but `rst2s5` might not always be present.
Thus it should either be removed from
Package: monkeysign
Version: 2.x
Severity: minor
If the build_trans() function is not called during the normal build or
installation process, but via `setup.py build_trans`, it fails with:
distutils.errors.DistutilsGetoptError: invalid short option 'po/': must a
single character or None
Package: dsniff
Version: 2.4b1+debian-22
Severity: important
If the '-t' argument is missing, arpspoof should, according to its
manpage, posion all hosts on the LAN.
However, as of dsniff_2.4b1+debian-22, that does no longer work.
arpspoof will start just fine, but never actually send out any ARP
21 matches
Mail list logo