This is likely caused by this commit:
https://github.com/prometheus/prometheus/commit/9ba13de220f7b15e6b0554d7a045e4225e366e09
OpenPGP_signature.asc
Description: OpenPGP digital signature
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-bougou-go-ipmi
Version : 0.7.2-1
Upstream Contact: Bougou Nisou
* URL : https://github.com/bougou/go-ipmi
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: golang-github-prometheus-sigv4
Version : 0.1.2-1
Upstream Contact: The Prometheus Authors
* URL : https://github.com/prometheus/sigv4
* License
On Thu, 16 Jan 2025 11:52:03 +0100 Jérôme Warnier
wrote:
> Any news about this?
> I would be interested in packaging this too, including contributing to
> your effort.
This looks like yet another nightmarish CNCF monorepo package with
extremely enthusiastic git tagging habits.
I just tried p
On 18.01.25 10:52, Maytham Alsudany wrote:
Packaging for golang-github-azure-azure-sdk-for-go-sdk (the new package)
is now available at [1], pending upload.
Is there some reason why you did not import the upstream commit history?
I find it a little bit unusual to see new packages that omit th
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-kimmachinegun-automemlimit
Version : 0.7.0-1
Upstream Contact: Geon Kim
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-coder-quartz
Version : 0.1.3-1
Upstream Contact: Spike Curtis
* URL : https://github.com/coder/quartz
Hi Thorsten,
Would it be sufficient if I add a "Provides: golang-procfs-dev" to the
current golang-github-prometheus-procfs-dev package? The transitional
package did not contain anything fancy like symlinks, since the Go
import path did not change. As such, a virtual package should allow the
This appears to be an exact duplicate of #1088483.
OpenPGP_signature.asc
Description: OpenPGP digital signature
This appears to be an exact duplicate of #1088482.
OpenPGP_signature.asc
Description: OpenPGP digital signature
This really ought to be reported upstream, since it is unlikely to be a
Debian-specific bug. The fact that the vanilla release options do not
enable the systemd collector by default is really just wallpapering over
the problem, and disabling the collector again is not really a
satisfactory solu
Another small update from the systemd v257-rc1 release notes published
today:
* Support for System V service scripts is deprecated and will be
removed in v258. Please make sure to update your software
*now* to include a native systemd unit file instead of a legacy
System V
On 02.11.24 13:26, Reinhard Tartler wrote:
Would you consider this NMU for a stable update?
I'm not 100% sure to whom you are addressing that question. Despite me
being probably the most active uploader of this package, the maintainer
is the Debian Go Packaging Team (ironically, since the pac
It would seem that this is becoming increasingly urgent. With systemd
256, I noticed this in the logs:
systemd-sysv-generator[154521]: SysV service
'/etc/init.d/isc-dhcp-server' lacks a native systemd unit file. ~
Automatically generating a unit file for compatibility. Please update
package t
Package: ftp.debian.org
Severity: normal
Please remove the transitional package golang-procfs-dev. This was
removed from debian/control in golang-github-prometheus-procfs 0.11.0-1,
but for reasons unclear to me still exists in the archive.
OpenPGP_signature.asc
Description: OpenPGP digital si
On 03.10.24 23:21, Antoine Beaupré wrote:
Yeah, I'm kind of hoping they stop doing that already with the v3. But i
will note that people *are* trying to keep up with a lot of modules like
this for other projects, and I think it's actually possible to give it a
try already.
The v3.0.0 uses a tot
Antoine,
I think you know as well as I do that the likelihood of this being
feasible is pretty remote. The fact that sufficient versions of npm,
nodejs and React are already available in Debian does not help much if
the web app uses a ton of bleeding edge modules which are not even on
anybody
On 24.09.24 16:41, Shengjing Zhu wrote:
The reason that I propose to use 0.0~gitMMDD is to just track the
latest commit in the mono repo. It just stops caring how the sub
modules are tagged and avoid confusing in the single packaging version
This is what I have done for golang-github-moby-sy
On 21.06.24 23:15, Shengjing Zhu wrote:
I think people are hesitant to sponsor because of the reconstruction
of the upstream repository.
So I propose to create a new package called
golang-github-azure-azure-sdk-for-go-sdk, which contains all the
modules in the /sdk directory. And the package
The sample console templates have been removed from the upstream
release-3.0 branch:
https://github.com/prometheus/prometheus/pull/14807
It might be a while before we can package Prometheus 3.0 in Debian,
because even the latest Prometheus 2.x version has a sprawling
dependency tree. But I ha
I'm pretty sure that this is a duplicate of #1077694.
OpenPGP_signature.asc
Description: OpenPGP digital signature
On 21.08.24 21:36, Georg Faerber wrote:
Thanks -- there is also #1077694 which asks for more fixes in regards to
apt_info.py to land in bookworm.
Any objections, Antoine, Daniel?
No objections from me. I usually don't get involved in backports (and
only recently got upload access to it), sinc
No sooner than I had posted my previous reply, I discovered that there
is in fact already an upstream PR for the aforementioned #547 [1];
unsurprisingly #548 [2] claims to fix it, but has been awaiting approval
since 2021 :(
Perhaps you could give that PR a nudge, and perhaps it also makes sen
Hi Michael,
As this would seem to also affect the latest upstream release (v0.15.0),
can you please forward this patch upstream and make a DEP-3 reference to
it in your patch? There is little point in only patching this in Debian
when it in fact affects the wider community.
Thanks
OpenPGP
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 of
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 --fre
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. grant
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 a
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 trie
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).
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]:
https://salsa.debian.org/go-te
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. "prometheus-pgbackrest-exporter"
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 "promethe
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 golang-github-azure-go-au
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 som
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]: *** [debian/rules:5
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 al
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 -rfak
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 bein
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:
TestJWT_ClaimsFromJWT_NotBeforeClaims/static/custom_nbf_leeway_using_exp_
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 runtim
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
> /lib/systemd/system/prome
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 fundam
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
* github.com/GoogleCloudPlatfor
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 gotte
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:
orno_or_we
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 y
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
rac
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 GOMAXPR
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 TestTombstoneCleanRetentionL
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 render
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 apt
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 h
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 referen
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 := net.ResolveIPAddr("
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 Prob
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 github.com/prometheus/blackbox_e
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 w
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
--- a/debian/patches/
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 golang-google
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
+++ metr
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
https://salsa.debian.org/go-team/packages/prometheus/-/commit/d95f2bf1764710e4583be69340f4c15
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 blocked
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 s
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 /usr/share/promethe
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 a
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 a
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
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
1 - 100 of 161 matches
Mail list logo
