Hi Evgeni,
This is possibly behaviour that has been carried over from when the
textfile collectors were part of the prometheus-node-exporter package,
prior to upstream splitting them out into their own git repo.
If you look closely, you will see that the systemd timers (with the
exception
In the upstream bug report, it is suggested that one should "complain to
[Debian] to get this fixed".
I don't see this as a Debian-specific bug however. It would affect any
distro with freeipmi-utils installed in /usr/sbin and sudo installed in
/usr/bin, on which the user set a non-empty
The instructions in README.Debian are outdated and need to be refreshed
for currently supported Postgres versions (>= 10).
Please consult the /upstream/ documentation, specifically
https://github.com/prometheus-community/postgres_exporter?tab=readme-ov-file#running-as-non-superuser,
i.e.
On 28.03.24 23:33, Santiago Vila wrote:
If you prefer I could report this build failure in a new report
(or you can also use the clone command so that the bug has a new number,
then close the old bug).
Please report a new bug, with just the relevant info regarding the new
build failure.
We
As expected:
=== RUN TestQuerierIndexQueriesRace/[m!="0"___name__="metric"]
panic: test timed out after 20m0s
...
FAILgithub.com/prometheus/prometheus/tsdb 1200.016s
On 28.03.24 23:13, Santiago Vila wrote:
Ok, I'm attaching one of my build logs for version 2.45.3+ds-3.
This one was
On 28.03.24 15:00, Santiago Vila wrote:
In either case, this is still happening for me in the current version:
Lucas Nussbaum wrote:
FAILED:
1:48: parse error: unexpected character inside braces: '0'
I think you are taking the "FAILED" out of context and misinterpreting
the test output.
On 28.03.24 15:00, Santiago Vila wrote:
Daniel Swarbrick wrote:
* Add new 0022-Support-prometheus-common-0.47.0.patch (Closes: #1064765)
Hello. I don't quite understand how the above fix is related to
the bug itself (but maybe it's because I don't know prometheus internals).
As described
The generate-ui.sh script was substantially refactored in June 2023. The
patch you have supplied would not apply cleanly, and I suspect that some
of the issues may have already been resolved anyway[1]
Can you try the script from the latest package from sid?
[1]:
I think you're missing the point of this package.
Firstly, it is a _library_, not a daemon, so it is intended to be
compiled / linked into other Go applications. It provides an easy
jumping-off point for developers to customize the output of logs,
particularly with respect to color and syntax
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-lmittmann-tint
Version : 1.0.4
Upstream Contact: lmittmann
* URL : https://github.com/lmittmann/tint
* License : Expat
The package name "golang-github-woblerr-pgbackrest-exporter" gives the
impression that this is a library package.
Please consider naming it as per the more or less adopted convention
used by the approximately three dozen other Prometheus exporter
packages, e.g.
Should the package name perhaps instead be
"prometheus-fail2ban-exporter", so that it aligns with the approximately
three dozen other exporters already packaged by Debian?
In case you're wondering, there /are/ other examples where the upstream
name has been munged to conform with the
The package name "golang-github-rluisr-mysqlrouter-exporter" gives the
impression that this is a library package.
Perhaps consider naming it as per the more or less adopted convention
used by other Prometheus exporter packages, e.g.
"prometheus-mysqlrouter-exporter".
OpenPGP_signature.asc
Hi Maytham,
On 29.02.24 12:16, Maytham Alsudany wrote:
Could we avoid bumping the epoch by suffixing the version with the git
commit? e.g. for the case of azure-sdk-for-go, the next version would be
68.0.0+git20240229.d33ad0-1s
I did this kind of thing previously for
The outdated golang-github-azure-azure-sdk-for-go is also now a blocker
for updated versions of Prometheus, which requires newer
azure-sdk-for-go since v2.48.0. We currently package v2.45.3, which is
an LTS release; current upstream Prometheus version is 2.50.1.
I am also pretty baffled by
It appears that bumping prometheus/common to 0.47.0 in the prometheus
go.mod will reproduce the test failure.
prometheus/common 0.46.0 and earlier does not provoke the test failure.
OpenPGP_signature.asc
Description: OpenPGP digital signature
systemd support is broken upstream. See
https://github.com/kumina/postfix_exporter/issues/55
This is mentioned in the Debian changelog:
prometheus-postfix-exporter (0.3.0-2) unstable; urgency=medium
[ Daniel Swarbrick ]
...
* Disable systemd journal support until fixed upstream
/prometheus-alertmanager/-/commit/51802d88957fc08bf13daab426e59718fadcf66e)
Regards,
Daniel Swarbrick
OpenPGP_signature.asc
Description: OpenPGP digital signature
On Wed, 26 Jul 2023 22:08:15 +0200 Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > mkdir -p temp/zic/2023c temp/zdump/2023c
> > cp -RL /usr/share/zoneinfo/posix/* temp/zic/2023c/
> > cp: cannot stat '/usr/share/zoneinfo/posix/*': No such file or
directory
> > make[1]: ***
Disregard my previous comment - I was mistaken.
prometheus-alertmanager ships with a generate-ui.sh script which in the
past fetched the Elm compiler from upstream (since it was not available
in Debian), but the script has always used the Alertmanager web UI
sources as shipped in the package.
Note that the Debian prometheus-alertmanager package strips out the web
UI, so the fix in 0.25.1 would actually result in no changes to this
package.
OpenPGP_signature
Description: OpenPGP digital signature
On 25.08.23 19:40, Mathias Gibbens wrote:
Something has changed in sid's golang environment since August 4
which is causing dh-make-golang to fail to determine a package's
dependencies and generate a correct d/control. For example, this worked
fine on August 4 but now fails:
It's probably
I am not able to reproduce this using one of the suggested methods at
https://wiki.debian.org/qa.debian.org/FTBFS/DoubleBuild:
sbuild -A -d unstable -v --no-run-lintian \
--finished-build-commands="cd %SBUILD_PKGBUILD_DIR && runuser -u $(id
-un) -- dpkg-buildpackage --sanitize-env -us -uc
This sounds quite similar to this:
https://github.com/linux-nvme/libnvme/issues/550
Even prior to that bug, I noticed that the smart error log counter would
increment by one with every reboot. This was not too concerning, but
when nvme-cli 2.x started to result in (albeit innocent) errors
Snipping the test failure output from the build log so it does not get
archived:
--- FAIL: TestJWT_ClaimsFromJWT_NotBeforeClaims (0.00s)
--- FAIL: TestJWT_ClaimsFromJWT_NotBeforeClaims/static (0.01s)
--- PASS:
Hello Tim,
Despite SysVinit systems being something of a rarity these days, and
Debian policy no longer requiring package maintainers to ship init
scripts, I am willing to entertain your request.
However, may I ask what template you have based your script on? It would
require adding a
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-go-zookeeper-zk
Version : 1.0.3-1
Upstream Contact: The Go-ZooKeeper Developers
* URL : https://github.com/go-zookeeper/zk
* License
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-linode-linodego
Version : 1.18.0-1
Upstream Contact: Linode
* URL : https://github.com/linode/linodego
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-prometheus-community-pro-bing
Version : 0.3.0-1
Upstream Contact: Prometheus Monitoring Community
* URL
On Fri, 24 Feb 2023 11:30:10 +0100 Florian Schlichting
wrote:
> The hotfix is a
>
/etc/systemd/system/prometheus-node-exporter-ipmitool-sensor.service.d/override.conf
> file setting
>
> [Service]
> Environment=LC_NUMERIC=C
>
> but this should preferably be set in
>
On 22.04.23 00:01, Christoph Anton Mitterer wrote:
Are all these strict dependencies, or also optionals?
I haven't checked them individually, but it's pretty rare for a
dependency to be optional. Maybe some of the tracing stuff might be
non-essential, but I think the majority will be
A sample run of dh-make-golang against github.com/thanos-io/thanos
reveals the following missing build-deps:
* github.com/chromedp/chromedp
* github.com/efficientgo/core
* github.com/efficientgo/e2e
* github.com/efficientgo/tools
* github.com/fatih/structtag
*
jq is already a Recommends.
Due to the potentially very diverse nature of this package, making
everything that is referenced by any / all scripts in the package a
Depends is going to pollute systems. For example, the ipmi textfile
collector requires ipmitool, but it's also only a Recommends.
You can use --collector.netdev.device-include if you simply ensure that
--collector.netdev.device-exclude is empty, e.g.:
prometheus-node-exporter --collector.netdev.device-exclude=
--collector.netdev.device-include=eno1
OpenPGP_signature
Description: OpenPGP digital signature
On 02.03.23 14:32, наб wrote:
I had gotten p-s-g to work with just "orno" after posting, yes,
but only because I was reading netsnmp_mib_api(3),
and its "ENVIRONMENT VARIABLES" sexion notes MIBDIRS and MIBS,
which appear to funxion à la /e/s/s.c mibdirs and mibs,
so the invocation that I've
Ah, my mistake, I did not notice that you already included your
generator.yml:
modules:
orno_or_we_504_505_507:
walk:
- ORNO-MIB::orno
It looks kinda odd to me. I don't recall ever including the MIB name in
the list of objects to walk. Have you tried simply:
modules:
I don't currently use prometheus-snmp-exporter, however I have used it
extensively in the past, and never encountered any problems with the
generator loading third-party MIBs.
Most maintainers (including myself) are currently focused on fixing bugs
in the upcoming bookworm release, so unless
Aha, I overlooked the fact that a new test (TestByPassBasicAuthVuln) had
been added to web/handler_test.go since the 02-Avoid_race_in_test.patch
was added by Tina.
I patched in the same time.Sleep workaround for the new
TestByPassBasicAuthVuln, and it seems to fix the failures. Hooray for
This seems to be a resurrection of #1013578, i.e.
https://github.com/prometheus/exporter-toolkit/issues/108.
With unpatched sources, I can get various tests in handler_test.go to
intermittently fail simply by running tests on an upstream git clone, on
a 16-core host. Running tests with
I am unable to reproduce this in a clean sid chroot.
OpenPGP_signature
Description: OpenPGP digital signature
The riscv64 build still fails with a test timeout of 30m. Since there
appears to be quite a substantial difference in performance between a
riscv64 porterbox, and the actual riscv64 buildd, I think we have no
option other than to skip the test completely.
=== RUN
Just following up on this; I see that nvme-cli 2.3-2 fixes the build,
and I can confirm that the numeric values no longer wrap around to
negative values.
As an aside, I also noticed that the JSON output "string" numeric values
(e.g. the 128-bit NVMe counters which would lose accuracy if
Hi Daniel,
On 01.02.23 09:48, Daniel Baumann wrote:
I've reproduced the bug with 2.2 and can confirm that 2.3 does fix it.
Did you notice that nvme-cli 2.3-1 is FTBFS on the buildds? The build
appears to be failing due to a missing "libnvme-mi".
OpenPGP_signature
Description: OpenPGP digital
Package: nvme-cli
Version: 2.2.1-4
Severity: normal
Dear Maintainer,
Since the update of nvme-cli to v2.x, the JSON output of an "nvme list"
command contains wrapped-around negative integers for various fields,
e.g.:
{
"Devices":[
{
"NameSpace":1,
"DevicePath":"/dev/nvme0n1",
Hi Eric,
Thanks for the detailed bug report. As this is something which can
theoretically affect _any_ apt-based distributed (i.e., derivatives of
Debian), I feel that it should ideally be reported upstream.
I personally run this textfile collector on a Debian bookworm system, as
well as
On 07.01.23 12:40, Adrian Bunk wrote:
Does running the autopkgtests on 32-bit bring more benefits than hassle,
or should they be run only on 64-bit architectures?
As troublesome as the tests are on 32-bit, and as much as it would
probably be simpler to just blanket disable them in d/rules, I
Paraphrasing myself from #1027365, this package's tests will pass (even
without tzdata present) if "-tags timetzdata" is used, e.g. by
overriding dh_auto_test.
OpenPGP_signature
Description: OpenPGP digital signature
Paraphrasing myself from #1027365, this package's tests will pass (even
without tzdata present) if "-tags timetzdata" is used, e.g. by
overriding dh_auto_test.
OpenPGP_signature
Description: OpenPGP digital signature
Aha, reading the docs for the Go tzdata package more thoroughly sheds
some light on the topic:
> Package tzdata provides an embedded copy of the timezone database. If
this package is imported anywhere in the program, then if the time
package cannot find tzdata files on the system, it will use
I am able to reproduce the FTBFS in a schroot, sans tzdata package.
However, this is weird, because Go ships with an embedded copy of tzdata
(https://pkg.go.dev/time/tzdata). AFAICT, this is not stripped out in
Debian golang-go packages.
Only selected tests fails, and only those which
I think I just found the smoking gun, so to speak.
In the reproducible builds log, I spotted this:
=== RUN TestDNSProtocol
dns_test.go:490: "localhost" doesn't resolve to ::1.
--- SKIP: TestDNSProtocol (0.00s)
This is due to this check in TestDNSProtocol:
_, err :=
Studying the test failure with the panic more closely, I think it is due
to the inherent raciness caused by tests which spin up http servers, tcp
servers etc in goroutines within the same test.
I think that what's happening is that the grpc server in the goroutine
is not ready in time, so
In general, the gRPC tests (in a pristine v0.23.0 checkout) seem to be
utterly broken.
What's more, isolating the tests to just the GRPC tests fails in a
completely different way:
$ go test ./...
ok github.com/prometheus/blackbox_exporter (cached)
ok
Hi Mathias,
Given that a pristine, upstream checkout fails on that test for the last
two releases, I think we will have to just skip the test.
See https://github.com/prometheus/blackbox_exporter/issues/969
OpenPGP_signature
Description: OpenPGP digital signature
On 22.12.22 20:52, Shengjing Zhu wrote:
Hmm, this works for me, the generated pb.go uses old timestamp type.
I have added above change and built the package, then checked the result.
My mistake, I think I must have looked at a stale build. The suggested
.proto mapping workaround seems to do
Updating the 01-Use_go_generate.patch as follows results in a successful
build (without needing to add golang-google-protobuf-dev as a dependency):
diff --git a/debian/patches/01-Use_go_generate.patch
b/debian/patches/01-Use_go_generate.patch
index cafa5e2..ffa83cf 100644
---
Hi,
On 22.12.22 00:41, Shengjing Zhu wrote:
Hi,
The workaroud could be like this:
https://salsa.debian.org/go-team/packages/notary/-/commit/b0a072faa72857f7523c8245ecaa8814d5a60051
Fixing the build failure in golang-github-prometheus-client-model is a
simple matter of including
After a fair amount of head scratching, I tracked this down to a change
in behaviour of the protobuf compiler. Version 3.14.0+ generates
slightly different pb.go files with respect to the timestamp type (and
possibly others):
--- metrics.pb.go.old 2022-11-08 23:31:00.0 +1300
+++
For the record, the following test also just timed out on i386:
=== RUN TestRulesUnitTest/Long_evaluation_interval
Unit Testing: ./testdata/long-period.yml
panic: test timed out after 20m0s
So perhaps we need to increase the baseline test timeout for _all_ archs
to at least e.g. 30 mins.
On Wed, 22 Jun 2022 17:01:51 -0700 Rob Leslie wrote:
> Attached is at least one patch needed to make the sample consoles usable.
Unfortunately it requires a slightly more extensive patch than that. See
60 minutes is a big jump up from 20 minutes, especially if the test
duration is only just on the border of the current 20 minute timeout. I
would suggest a slightly more conservative increase, e.g. 30 minutes, so
as not to unnecessarily tie up the s390x hosts if some test has
terminally
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-mdlayher-packet
Version : 1.1.0-1
Upstream Contact: Matt Layher
* URL : https://github.com/mdlayher/packet
* License : Expat
Hi Paul,
I have also noticed the fairly frequent failures of the memory-intensive
tests on 32-bit, and I am doing my best to keep on top of them with
t.Skip() patches where appropriate. Several of the tests result in the 4
GiB memory footprint threshold being exceeded.
Prometheus itself is
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-mdlayher-ethtool
Version : 0.0~git20220830.0e16326-1
Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/ethtool
* License
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-grafana-regexp
Version : 0.0~git20221122.6b5c0a4-1
Upstream Author : Grafana Labs
* URL : https://github.com/grafana/regexp
* License
The email template was split out of default.tmpl by upstream commit
https://github.com/prometheus/alertmanager/commit/c0a7b75c9cfb0772bdf5ec7362775f5f7798a3a0,
into email.tmpl.
The Debian package does not install email.tmpl, and even if that file is
copied manually into the
I am able to reproduce the reported error with 0.24.0-4.
A vanilla upstream build does not exhibit the error. It appears to be
caused by 02-Do_not_embed_blobs.patch, as omitting that also results in
a working build.
OpenPGP_signature
Description: OpenPGP digital signature
This bug report is pretty difficult to make sense of, due to the
spelling mistakes and lack of punctuation.
Why is docker.io mentioned in the bug report? The Debian package of
prometheus-node-exporter is not intended to be run in docker.
If you run a system with sid / unstable configured in
Such a change is unlikely to be met with enthusiasm by the vast majority
of users, and would likely be the source of many subsequent bug reports
requesting the change to be reverted.
Whilst I acknowledge that node_exporter provides a wealth of information
which could potentially be useful to
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-scaleway-scaleway-sdk-go
Version : 1.0.0~beta9-1
Upstream Author : Scaleway
* URL : https://github.com/scaleway/scaleway-sdk-go
* License
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-ionos-cloud-sdk-go
Version : 6.1.3-1
Upstream Author : IONOS Cloud
* URL : https://github.com/ionos-cloud/sdk-go
* License
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: prometheus-ui-classic
Version : 2.33.5+ds-1
Upstream Author : The Prometheus Authors
* URL : https://prometheus.io/
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-dennwc-btrfs
Version : 0.0~git20220403.b3db0b2
Upstream Author : Denys Smirnov
* URL : https://github.com/dennwc/btrfs
* License
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-dennwc-ioctl
Version : 1.0.0
Upstream Author : Denys Smirnov
* URL : https://github.com/dennwc/ioctl
* License : MIT
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-gopkg-telebot.v3
Version : 3.0.0
Upstream Author : Ilya Kowalewski
* URL : https://gopkg.in/telebot.v3
* License : Expat
Programming
) and is built with
prometheus/common v0.26.0 or later.
blackbox_exporter v0.19.0 still uses go-kit/kit/log, so the options are
either to patch that in Debian to use go-kit/log, or update to
blackbox_exporter v0.20.0, which uses the latter.
On Tue, May 10, 2022 at 8:08 PM Daniel Swarbrick
wrote:
> Seve
Several months ago I encountered the same bug with
prometheus-smokeping-prober, and fixed it, but my brain is a bit foggy
right now as to what the root cause was.
However, for prometheus-blackbox-exporter at least, the --log.level flag is
respected so long as you build / run it with the
I noticed in the debian/rules that rebuilding the timezone JS data from the
tzdata package is *optional*, and only occurs if the moment-timezone
package has a +x suffix, e.g. +2021e. If not, the timezone JS data from
the upstream moment-timezone source will be used.
I just tried building
This bug is now blocking Prometheus (which I co-maintain) from
transitioning to testing.
In the meantime, I see that there is a new release of moment-timezone.js
upstream (0.5.34) which updates the IANA TZDB to 2021e, and would thus
perhaps resolve the test failures that I see when trying to
A git bisect seems to suggest that
https://github.com/go-ping/ping/commit/30a8f08ad2a9d0b88ca9c1978114d253f63748c3
is the commit which resulted in the regression in go-ping. Sadly that made
it into the package that shipped with bullseye.
I can update the go-ping package to a newer version that
I tested some upstream tags, i.e. "go run ..." to build with the exact
module versions specified by their go.mod:
v0.3.1 - OK
v0.4.0 - counters latch at 65536
v0.4.1 - counters latch at 65534
v0.4.2 - OK
master (as of writing) - OK
Between v0.4.1 and v0.4.2, the go-ping version specified by
Unable to reproduce with an earlier, in-house build of smokeping_prober
0.3.1 (prior to first debian upload):
# HELP smokeping_response_duration_seconds A histogram of latencies for
ping responses.
# TYPE smokeping_response_duration_seconds histogram
Reproduced with prometheus-smokeping-prober 0.4.2-2, built with go-ping
0.0~git20210312.d90f377-1.
# HELP smokeping_response_duration_seconds A histogram of latencies for
ping responses.
# TYPE smokeping_response_duration_seconds histogram
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-nginxinc-nginx-plus-go-client
Version : 0.9.0
Upstream Author : NGINX, Inc.
* URL : https://github.com/nginxinc/nginx-plus-go-client
Tags: unreproducible upstream
Sadly I am not able to reproduce this (in a de_DE.UTF-8 locale). However,
the issue has also been mentioned upstream, and since this is (in theory)
not a Debian-specific issue, I suggested that it should be fixed upstream.
See
such errors
are not debian-specific. I recommend that you open an issue upstream on
github to address that.
Daniel Swarbrick
take the new 0.4.2-1 package for a test drive.
Daniel Swarbrick
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: prometheus-frr-exporter
Version : 0.2.20
Upstream Author : Tynan Young
* URL : https://github.com/tynany/frr_exporter
* License : MIT
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: prometheus-smokeping-prober
Version : 0.4.1
Upstream Author : Ben Kochie
* URL : https://github.com/SuperQ/smokeping_prober
* License : Apache-2.0
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: golang-github-go-ping-ping
Version : 0+git20201106.b6486c6
Upstream Author : Ben Kochie , et al
* URL : https://github.com/go-ping/ping
* License : MIT
Programming Lang: Go
On 24.01.21 18:30, Helge Kreutzmann wrote:
And you removed the fuzzy mark as well? The grammar fix only applies
to the original.
If you feel uncomfortable editing po files you can provide them to me
and I can do it for you.
I'm not sure exactly which fuzzy mark you are referring to. Can you
On 24.01.21 17:17, Helge Kreutzmann wrote:
Thanks. Are you unfuzzying the Debconf translations before the upload
or are you issuing a call for updates anyway?
If you want I can unfuzzy the Debconf translations where possible.
Thanks!
I noticed that your submitted German translation, as well
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: golang-github-prometheus-exporter-toolkit-dev
Version : 0.5.1
Upstream Author : The Prometheus Authors
* URL : https://github.com/prometheus/exporter-toolkit
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: golang-gopkg-yaml.v3
Version : 3.0.0
Upstream Author : Canonical Ltd
* URL : https://gopkg.in/yaml.v3
* License : Apache-2.0
Programming Lang: Go
Description : YAML support
On Thu, 14 Feb 2019 10:10:47 +0100 Santiago Vila wrote:
> Ok, that worked, but I think it would be much better if such option
> could be added to the README.md.gz somewhere, or a README.Debian, or
> something. That will avoid searches in search engines, stackoverflow
> or the Debian BTS.
>
>
I'm fairly sure this error disappear if you attempt a rebuild now.
Earlier versions of dh-golang disabled GOCACHE, and Go 1.12 and later
requires that the GOCACHE env var point to a writable directory. This is
AFAIK now the case in the current dh-golang package.
If the error still occurs,
The upstream pull request for opentracing-contrib/go-stdlib which
resolved the issue is
https://github.com/opentracing-contrib/go-stdlib/pull/26.
I tracked the problem down to the fact that the http.ResponseWriter is
being wrapped by github.com/opentracing-contrib/go-stdlib, causing the
Flusher() method to be masked. As a result, the ResponseWriter does not
satisfy the http.Flusher interface.
I have tested building with a newer version
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
1 - 100 of 137 matches
Mail list logo
