I am also witnessing multiple hosts where ntp is failing to start,
however the disable-with-time-daemon.conf file /is/ present on these
systems:
$ dpkg -S disable-with-time-daemon.conf
systemd:
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
System is buster
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-postfix-exporter
Version : 0.1.2
Upstream Author : Bart Vercoulen , Ed Schouten
* URL : https://github.com/kumina/postfix_exporter
* License : Apache-2.0
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-squid-exporter
Version : 1.4
Upstream Author : Mohamad Arab
* URL : https://github.com/boynux/squid-exporter
* License : MIT
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-nginx-exporter
Version : 0.1.0
Upstream Author : NGINX, Inc.
* URL : https://github.com/nginxinc/nginx-prometheus-exporter
* License : Apache-2.0
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-process-exporter
Version : 0.4.0
Upstream Author : Nick Cabatoff
* URL : http://github.com/ncabatoff/process-exporter
* License : MIT
Programming Lang: Go
Description
Package: golang-github-gorilla-mux-dev
Version: 1.1-2
Severity: wishlist
Dear Maintainer,
The current packaged version of mux is over two years old. There have
been many improvements made upstream since then. Also, the API
documentation (http://www.gorillatoolkit.org/pkg/mux#api) refers to
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-snmp-exporter
Version : 0.11.0
Upstream Author : Brian Brazil
* URL : https://github.com/prometheus/snmp_exporter
* License : Apache-2.0
Programming Lang: Go
Description
Package: wnpp
Followup-For: Bug #840759
Owner: Daniel Swarbrick
I am in the process of packaging this.
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-bird-exporter
Version : 1.2.1
Upstream Author : Daniel Czerwonk
* URL : https://github.com/czerwonk/bird_exporter
* License : MIT
Programming Lang: Go
Description
On 12.06.2018 18:04, Martín Ferrari wrote:
Does it understand that 0.15.0-rc.1 is lower than 0.15.0, for example?
If that is the case, I could replace the tilde in the metadata.
I have not tested it, but looking at the code, it seems to be reasonably
intelligent and handling major, minor,
On 12.06.2018 17:50, Martín Ferrari wrote:
I had not heard about unsee until now, we should package it too! :)
That would totally rock!
There are a couple of other exporters which I think would be of quite
high interest to a lot of sites, such as the snmp_exporter. Perhaps I
could assist you
Hi Martin,
We've been running your 0.15.0~rc.1~git20180507.28967e3+ds-1 packages
from experimental for about a week now, with no issues bar one - the
tilde in the version number upsets the semantic version parsing in
Cloudflare's "unsee" dashboard
Package: prometheus-node-exporter
Version: 0.15.2+ds-1~bpo9+1
Severity: wishlist
Dear Maintainer,
node_exporter 0.16.0 has been released upstream. Please update the
prometheus-node-exporter package to this version, and backport to
stretch & jessie.
Many thanks in advance!
-- System
Martin,
The Alertmanager UI requires Elm 0.18 (as specified in its
elm-package.json). Over at
https://github.com/elm-lang/elm-platform#1-get-haskell-working, they
state that Elm <= 0.16 should build with GHC 7.8. I take this to mean
that later versions of Elm require a later version of GHC,
Martin,
I was a bit too hasty in my previous reply. It appears that Alertmanager
compresses and encodes all the web UI assets a Go "blob" (
https://github.com/prometheus/alertmanager/blob/master/ui/bindata.go). Elm
libraries are only needed if you intend to hack / develop the web UI.
I just
Hi Martin,
I just had a quick look at the docs for build Elm from source, and it looks
like a pretty direct journey to npm hell. I'm pretty out of touch with
modern web development, so I'm not sure how much help I can be be in terms
of packaging Elm.
I can suggest a couple of alternatives. One
Package: prometheus-blackbox-exporter
Version: 0.11.0+ds-4~bpo9+1
Severity: wishlist
Dear Maintainer,
Please package upstream release 0.12.0 and backport to stretch.
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Package: prometheus
Version: 2.2.1+ds-1
Severity: wishlist
Dear Maintainer,
Please backport Prometheus 2.2.1 to stretch.
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux
Package: prometheus-alertmanager
Version: 0.6.2+ds-3~bpo9+1
Severity: normal
Dear Maintainer,
Current Debian packages for prometheus-alertmanager are extremely out of
date. The web UI and (undocumented / unstable) API has changed
considerably in the ten versions that have been released since
On 18/12/16 22:58, Hilmar Preuße wrote:
> On 01.12.2016 14:09, Daniel Swarbrick wrote:
>
> Hi Daniel,
>
> Upstream asked to provide full configuration of proftp including
> possible include file. Please be so kind.
Apologies for the late response. Here we go, blank lines,
FYI, #661510 now reports that a python3-gevent package is available.
However, it appears that the gevent-websocket repo has gone through a
long period of inactivity, and several owner transitions / forks.
The https://github.com/jgelens/gevent-websocket mirror hasn't been
touched since January
We are also seeing what appears to be a memory leak, which becomes quite
a problem when users upload large files. We are _not_ using RMemoryLimit.
On one of our FTP servers, a user is currently uploading a large file,
430 GB so far, and the proftpd process has used almost 10 GB of memory.
It
Having pondered this for a while, it's more complex than I at first
thought. UDP checksums are optional (for IPv4) according to RFC 768:
If the computed checksum is zero, it is transmitted as all ones (the
equivalent in one's complement arithmetic). An all zero transmitted
checksum
On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank wa...@debian.org wrote:
- ceph depends on fdisk, parted and whole lot other crap it does not
need.
This is most likely a dependency of the ceph-disk-prepare or ceph-deploy
scripts, which handle preparing partitions and filesystems on new disks
On Sun, Sep 15, 2013 at 1:03 PM, Bastian Blank wa...@debian.org wrote:
There is a python script ceph-rest-api. Where is this used? Why does
it warrant a dependency on 20 other packages?
This is the as yet sparsely documented admin REST WSGI app (which can also
run as a standalone server),
On 09/12/2013 03:13 AM, László Böszörményi (GCS) wrote:
#714881 is already fixed with 0.48-2 , closed the bugreport.
Bastian won't NMU Ceph, but started cooperating. He started working on
the current pkg-ceph Git tree[1], which is version 0.67.2 . It's the
latest stable version. Upstream
Package: snmpd
Version: 5.7.2~dfsg-8.1
Severity: normal
Dear Maintainer,
net-snmp-config split the functionality to create a SNMPv3 user in v5.5
into a separate script called net-snmp-create-v3-user. This script is
missing from the snmpd package (v5.7 and later).
-- System Information:
Debian
I have a few test VMs running on Ubuntu 13.04, which connect to a
Debian-powered Ceph cluster (using v0.61.3 ceph packages from ceph.com
repos). This is working without any problems.
The ceph / librbd packages in Debian are *ancient*, even by Debian
standards. Can we please sync with what the
Thanks for packaging 1.4.4, however it appears to be incomplete. Trying
to load the http plugin reveals missing symbols:
$ uwsgi --plugin http
open(/usr/lib/uwsgi/plugins/corerouter_plugin.so): No such file or
directory [core/utils.c line 4733]
!!! UNABLE to load uWSGI plugin:
Sorry Georg, I should have been more specific.
The file is /usr/share/pyshared/libsvn/core.py. It's a fairly large file
(swig'ed libsvn bindings). I've actually since upgraded libsvn1 on that
particular box to 1.7.5-1 from sid, and the problem is no longer there
(eg. without patching core.py
Without digging too deep into the code, I found that if I patched the
offending line 4801 of core.py from:
return _core.svn_stream_read(*args)
to instead:
return _core.svn_stream_read(args[0], int(args[1]))
it would work ok. For reference, args was:
(libsvn.core.svn_stream_t; proxy of Swig
I don't understand the holdup with PDO. Even php.net says that PDO is
enabled by default, so people who compile PHP themselves from the
upstream dist will get it by default.
Best source I've found for binary PHP packages is dotdeb,
http://packages.dotdeb.org/dists/sarge/php5/
--
To
Package: kronolith2
Version: 2.1-1
Uninstallable on a PHP 5 system. Currently requires php4-mcal,
php4-mysql or php4-pgsql. Needs to alternatively support php5-mcal,
php5-mysql or php5-pgsql.
Another of kronolith2's dependencies, php-date, also has a PHP4-only
dependency (php4-pear),
Unofficial packages of PHP 5.1.4 are available at
http://people.debian.org/~dexter/dists/php5.1/ or alternatively from
packages.dotdeb.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is this package still actually being maintained? One could be forgiven
for thinking it had become orphaned.
Please at least get something in -unstable or experimental - I noticed
that the current package (1.36.3) is no longer even in -testing for some
reason.
We, the community, are eager to
horde3 is still not installable on etch or sid in conjunction with php5.
The horde3 package incorrectly requires php5-pear, which should be
php-pear as it is named in etch and sid. It also requires php5-domxml,
which is nonexistent because DOM XML is deprecated in PHP5. Instead it
is provided
PDO has been available in unofficial php5.1 packages for months now at
http://people.debian.org/~dexter/dists/php5.1/
Why is it taking so long to get PDO into the official repos?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: isdnactivecards
Version: 3.8.2005-12-06-4
When invoking 'divaload -c 1 -f ETSI', error message returned is:
EICON DIVALOAD: Firmware loader for Eicon DIVA Server ISDN adapters
/dev/Divas DETECT Error -1
I suspect the version of divaload does not support newer hardware
revisions. The
Try removing ide-generic from your /etc/modules so that it doesn't load
so early in the boot sequence. I found that ide-generic was stealing
port 1f0, preventing the native chipset IDE driver from loading.
ide-generic does not include support for DMA, so once it has loaded and
monopolised the
101 - 139 of 139 matches
Mail list logo
