[pkg-go] Bug#921739: amtool: error: comment required by config
Hi Santiago, On 08/02/2019 17:35, Santiago Vila wrote: > File /usr/share/doc/prometheus-alertmanager/README.md.gz suggests doing this: > > amtool silence add alertname=Test_Alert > > but this is what I get: > > amtool: error: comment required by config I don't know how that is configured, but you just need to add a comment to the silence like '--comment="testing silences"' > Trying to see what's wrong, I tried using amtool 0.16.1, downloaded > from github: > > $ /tmp/amtool silence add alertname=Test_Alert > amtool: error: required flag --alertmanager.url not provided > > Ok, apparently it needs the url of the current alertmanager instance, > let's try this then: Yes, the debian binary comes with a sane default which is not present in upstream. > I would love to use the web UI, but it's gone: > > The Debian package of the alertmanager does not include a web > application. > > Is this a Debian-specific change? If yes, could we have the web UI back? > In my opinion, it was better than nothing. The problem is that upstream switched to Elm for generating the UI, and that would have required preparing and uploading dozens of new packages, and I did not have the resources for that. Somebody offered to write a script to download the pre-compiled UI and install it locally, but never happened. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#921522: prometheus: promtool does not have an update command (?)
On 08/02/2019 12:30, Santiago Vila wrote: >>> Maybe this feature could be backported from the backport to the >>> version in buster? :-) >> >> So I checked with upstream, they decided to remove it because for them >> it is already obsolete.. I will try to backport this, but it could be >> tricky as the codebase has evolved since this was removed. > > If that becomes very tricky, another option would be to upload the > current version in stretch-backports with the name prometheus-promtool > and essentially remove everything but /usr/bin/promtool from the .deb. That would have to go through NEW, we are out of time for that :( -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#921522: prometheus: promtool does not have an update command (?)
On 06/02/2019 15:37, Santiago Vila wrote: > Hi. > > I've just noticed that promtool from version 2.3.2+ds-1~bpo9+1 in > stretch-backports has the "update rules" command. > > Maybe this feature could be backported from the backport to the > version in buster? :-) So I checked with upstream, they decided to remove it because for them it is already obsolete.. I will try to backport this, but it could be tricky as the codebase has evolved since this was removed. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#921351: Bug#921351: prometheus-postfix-exporter: Init script missing
Daniel, et al.
I was preparing a fix for this by copying some support scripts from
other exporters when I noticed a couple of things, and wanted to check
with you before making any change.
This exporter is running with user postfix, while all the others use the
prometheus user. I understand that you need to access the queue
directly, but this could be done by granting the postqueue group when
starting the process instead.
Another thing is that this requires a special log configuration
(duplicating all postfix entries to a new file, and making that file
writable by the user this exporter runs as), which probably should be
documented in a Debian readme, and I have no idea how to do this with
systemd? Also, I'd suggest moving that log to /var/{lib,log}/prometheus
Honestly, back in the day I had looked at this exporter and decided it
was not great because of the log requirement, and started using mtail
for monitoring postfix.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#920827: Error parsing smartmon.prom after upgrade
On 30/01/2019 17:42, Antoine Beaupré wrote: > Hmm... I just noticed I don't see the errors in the logs anymore, so > it's quite likely you won't be able to reproduce with the given file, > which might explain why I couldn't find a problem with the given line... > > Is it possible that the exporter is trying to read the file while it's > being written, and therefore getting an incomplete record? Yes. That must be the issue. > If the file is not written atomically (ie. written to a tmp and moved > into place), then it's quite likely such race conditions will > (eventually) occur... I thought this would not be a problem, since the timer service is using sponge, but now I see in the manpage that: When possible, sponge creates or updates the output file atomically by renaming a temp file into place. (This cannot be done if TMPDIR is not in the same filesystem.) So I will look into using the same dir as TMPDIR. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#920827: Error parsing smartmon.prom after upgrade
On 30/01/2019 16:04, Antoine Beaupré wrote:
>>> I started seeing this in my logs on buster recently:
>>>
>>> jan 29 12:48:02 curie prometheus-node-exporter[940]:
>>> time="2019-01-29T12:48:02-05:00" level=error msg="Error parsing
>>> \"/var/lib/prometheus/node-exporter/smartmon.prom\": text format parsing
>>> error in line 54: unknown metric type \"type is not sat, scsi or megaraid
>>> but usbsunplus gauge\"" source="textfile.go:211"
This is weird.. I can't replicate the problem at all. I have just copied
your file in the textfile directory, and I get no errors.
$ sudo cp smartmon.prom /var/lib/prometheus/node-exporter/
$ curl -s http://localhost:9100/metrics|grep
smartmon_end_to_end_error_threshold
# HELP smartmon_end_to_end_error_threshold SMART metric
end_to_end_error_threshold
# TYPE smartmon_end_to_end_error_threshold gauge
smartmon_end_to_end_error_threshold{disk="/dev/sdb",smart_id="184",type="sat"}
0
$ journalctl -u prometheus-node-exporter.service |tail -n1
Jan 30 16:47:31 aine prometheus-node-exporter[19201]:
time="2019-01-30T16:47:31Z" level=info msg="Listening on :9100"
source="node_exporter.go:170"
--
Martín Ferrari (Tincho)
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#920827: Error parsing smartmon.prom after upgrade
Hi Antoine,
On 29/01/2019 17:50, Antoine Beaupre wrote:
> I started seeing this in my logs on buster recently:
>
> jan 29 12:48:02 curie prometheus-node-exporter[940]:
> time="2019-01-29T12:48:02-05:00" level=error msg="Error parsing
> \"/var/lib/prometheus/node-exporter/smartmon.prom\": text format parsing
> error in line 54: unknown metric type \"type is not sat, scsi or megaraid but
> usbsunplus gauge\"" source="textfile.go:211"
> It's strange because "line 54" of that file is:
>
> smartmon_end_to_end_error_threshold{disk="/dev/sdb",type="sat",smart_id="184"}
> 0
>
> and type *is* "sat, scsi or megaraid" (it's "sat") and most definitely
> not "usbsunplus". what's going on here?
That's weird.. But I'd bet the error refers to another line in that
file. After all, node-exporter has no idea of sat, scsi, or megaraid. I
think that must be some text in the file. Could you send the contents of it?
Thanks.
--
Martín Ferrari (Tincho)
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#918434: golint: FTBFS (failing tests)
Santiago, On 06/01/2019 00:14, Santiago Vila wrote: > I tried to build this package in buster but it failed: I have investigated the issue. It seems to be due either to changes in golang or in the x/tools package, I will do some more tests, and hope to fix it soon. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#916055: (no subject)
On 14/12/2018 05:43, Andre Heider wrote: > I ran into the same issue and came with another approach. The patch was > just merged upstream[0], so post v0.17.0. > > That also introduces a new metric if a disk is in standby mode. Thanks Andre! I have replaced my patch with yours and uploaded. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Bug in prometheus-apache-exporter
Fabian, On 11/12/2018 10:32, elnappo wrote: > I already submitted a pull request to fix this > at > https://salsa.debian.org/go-team/packages/prometheus-apache-exporter/merge_requests/1 Thanks for the heads-up, I had missed this! It is now merged, and I will upload soon -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] prometheus-node-exporter_0.16.0+ds-1~bpo9+1_ppc64el.changes ACCEPTED into stretch-backports
On 06/12/2018 06:55, Christoph Berg wrote: >> I am confused with what happened here.. I see the version and changelog >> match what is in git since 5 months ago.. Did I forget to actually >> upload this version? > > It FTBFSed on the buildd back then, but worked fine when I built it > locally, so I uploaded it. > > https://buildd.debian.org/status/logs.php?pkg=prometheus-node-exporter=0.16.0%2Bds-1~bpo9%2B1=stretch-backports Ah, I had missed that. thanks for fixing! -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] prometheus-node-exporter_0.16.0+ds-1~bpo9+1_ppc64el.changes ACCEPTED into stretch-backports
Hi Myon, On 04/12/2018 11:23, Debian FTP Masters wrote: > Source: prometheus-node-exporter > Binary: prometheus-node-exporter > Architecture: ppc64el > Version: 0.16.0+ds-1~bpo9+1 I am confused with what happened here.. I see the version and changelog match what is in git since 5 months ago.. Did I forget to actually upload this version? -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#911795: CVE-2018-17846 / CVE-2018-17847 / CVE-2018-17848
On 24/10/18 22:17, Moritz Muehlenhoff wrote: > Source: golang-golang-x-net-dev > Severity: important > Tags: security > > Please see > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17846 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17847 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17848 > Thanks for the heads up! Sadly, it seems it has not yet been fixed upstream. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#910865: prometheus-node-exporter: Files in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ should not be compressed
Philipp, On 13/10/18 17:04, Philipp Kern wrote: >> True. But right now I don't have the bandwidth do write those.. I would >> be glad to add them if you write them :) > > https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1 > > Please test and let me know if that works / doesn't work for you. And > yes, maybe that should have been contributed upstream instead, but a > distro can be more opinionated. Thanks a lot! I left my comments on the merge request, for simpler follow-up. Re upstream: I think it is worth also contributing it upstream, it would fit with the examples. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#910865: prometheus-node-exporter: Files in /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ should not be compressed
Hi Phillip, On 12/10/18 16:47, Philipp Kern wrote: > I'd be great if we had a better story for the scripts in > /usr/share/doc/prometheus-node-exporter/examples/text_collector_examples/ > but right now one of them (and only one) is even gziped and hence not > directly executable (despite no configuration being needed) and that's > smartmon.sh.gz. Could you exclude those files from being compressed? I agree it would be good if these are not compressed.. But as I understand the policy, they must be compressed if they are documentation or examples. An alternative would be to ship them in /usr/share/promenteus-node-exporter, but I am not sure that is appropriate.. Maybe you can advise? > Bonus points if there were systemd services one could turn on to run > them periodically. :) True. But right now I don't have the bandwidth do write those.. I would be glad to add them if you write them :) -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#910420: prometheus-alertmanager: broken symlinks: /usr/share/prometheus/alertmanager/ui/lib/* -> ../../../../javascript/*
Andreas, On 06/10/18 06:44, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink. > Is prometheus-alertmanager missing dependencies on some > javascript packages? thanks for spotting this! This is from a previous version, where the alertmanager was shipping a web UI, but I since removed it. So the symlinks are obsolete. Will corrent in the next upload. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#908811: prometheus-node-exporter: Adding /mnt and /media as ignored mount points
Hi Santiago, On 14/09/18 10:24, Santiago Vila wrote: > I see that the ignored mount points are not in > /etc/default/prometheus-node-exporter anymore by default. No, I moved all that default configuration into the binary's defaults. > I think this change makes adding/removing ignored mount points more difficult > for the average user, and I'm not very happy with that. it is not the simplest, but in the default file you have the documentation on how to do it, along with the current default value: # --collector.filesystem.ignored-mount-points="^/(dev|proc|run|sys|var/lib/docker)($|/)" #Regexp of mount points to ignore for filesystem #collector. > In either case: Would be possible to add /mnt and /media to the list > of ignored mount points? (Wherever they are now). I still use those > mount points occasionally and it would be better for them not to be > monitored. Yeah, I think that makes sense. I will add them. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#902468: Info
It took me a while to reproduce, as it seems to only happen with high CPU contention. I will see if I can fix the bug, or disable it otherwise. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#907171: prometheus FTBFS:
Ian, On 30/08/18 09:51, Ian Campbell wrote: > Does `nc -l -p 9090` repro the test failure perhaps? yes, of course. > Unless the tests are run in their own network namespace (which provides > some guarantees over what else might be bound to a port, I can't seem > to find logs which would confirm or deny if a netns was in use here > though) probably the test needs to use a random port or otherwise be > tollerant of 9090 not being available. Right, but this can't be done without root, and buildds do not give root. > Maybe there is (or should be) an autopkgtest flag to request a clean > netns be used? This discussion is about a FTBFS bug, not about the CI system. ALso, that would not solve the issue, as it is autopkgtest installing (and therefore starting) prometheus. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#907171: prometheus FTBFS:
On 27/08/18 17:08, Adrian Bunk wrote: > How often did you try? > > I would say the probability to hit is somewhere around 50%: > https://tests.reproducible-builds.org/debian/history/prometheus.html I just tried 20 builds, while using desktop applications that put some extra strain on tHE CPU, and none failed.. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#907171: prometheus FTBFS:
On 27/08/18 16:51, Adrian Bunk wrote: >>> panic: Can't start web handler:listen tcp :9090: bind: address already in use > I am not talking about autopkgtests, I am talking about a FTBFS I was > able to reproduce locally. > > But retrying a few more times, this might actually be a flaky test? I have not seen this error before, I can only imagine you had some old process lying around, or somehow the port was still in use? Otherwise, it must be some concurrency issue, but as I said, I have not been able to reproduce this. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#907171: prometheus FTBFS:
Santiago, On 27/08/18 16:00, Santiago Vila wrote: >> This is a known problem when running the autopkgtests, becasue the >> installed package starts the daemon and then the tests fail when trying >> to use the same port; but this is not a FTBFS: the build daemons do not >> fail to build from source. I think you should lower the severity. > > Tincho, if we go that route we would be applying a definition for FTBFS > which would be different from everybody else. > A FTBFS could be defined as a non-zero exit status from > dpkg-buildpackage. If you include the test suite as part of the build, > then a failure in the test suite will naturally mean a FTBFS bug, for > all purposes. Yes, but this is not what is happening: the build only fails if prometheus is already running in the machine, which is the case for autopkgtest, but not for a normal build. I plan to fix this, but I need to find a general fix for all go packages that include a daemon. Look at the buildd logs, there are no failures (except i386, which is known not to work): https://buildd.debian.org/status/package.php?p=prometheus > If, as you explain, the tests are not suitable to be run after > dh_auto_build, then it follows that they should be disabled from the > package build, because we don't want dpkg-buildpackage to exit with > error. In such case, just an empty debian/rules target like this: If you run dpkg-buildpackage in a clean chroot, it does not fail: I have just checked again; so this bug is not RC. There are a few other go packages that fail autopkgtests for the exact same reason, please do not open FTBFS bugs without actually trying to build the package. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#907171: prometheus FTBFS:
Adrian, On 24/08/18 13:47, Adrian Bunk wrote: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/prometheus.html > > ... > panic: Can't start web handler:listen tcp :9090: bind: address already in use This is a known problem when running the autopkgtests, becasue the installed package starts the daemon and then the tests fail when trying to use the same port; but this is not a FTBFS: the build daemons do not fail to build from source. I think you should lower the severity. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#905760: Acknowledgement (prometheus: [INTL:de] initial German debconf translation)
On 18/08/18 12:55, Helge Kreutzmann wrote: > Hello, > unfortunately a typo was detected after I sent this e-mail. Could you > merge the attached version instead of the original one? Done, thanks! -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#904261: Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge
Hi Clément, On 13/08/18 11:01, Clément Hermann wrote: > It happened after Debcamp, but here is the MR: > https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/3 I just took a look. I left a small comment, but otherwise looks like a good solution, and I'd merge it. We could also change the default in the next debhelper compat mode; dunno how this is normally handled, but it would be good to coordinate so this change is documented.. In that case it might be even be sensible to add the switch in the code now. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Creating RFS bugs and maybe consider posting to the new ML
On 27/07/18 09:50, Alexandre Viau wrote: > I was wondering if you would consider creating actual RFS bugs so that > the progress on those is easier to follow. There are quite a number of > requests and I think that bugs will make it easier to follow. I usually have the opposite feeling when seeing RFS bugs :-) My rationale is that I have to remember to close the bug manually after doing the upload, or include it in the changelog (but for that I need to add an extra commit). Honestly, I would try to aim to remove the need for RFS completely. Sadly we never got used to a PET-based workflow, where RFSs are not needed at all, because you see what packages are ready for upload and you can just sponsor whenever you have some free time. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Fwd: Code review: golang-github-danverbraganza-varcaser
On 17/07/18 16:09, Anthony Fok wrote: > No, not in depth. Sorry, I have been really busy in real life, and I > was hoping other pkg-go team members could help you review the > package. ;-) Sorry, I intended to help, but also been pretty busy! > 2. There is no debian/0.0_git20151108.ce61ec4-1 tag > > which indicates to me that you are not running the gbp commands in the > right order, or some other issues. Note that in general, it is understood that the presence of a debian/* tag indicates the package has already been uploaded. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Code review: golang-github-danverbraganza-varcaser
Hey Tong, On 23/06/18 04:29, Tong Sun wrote: > Would someone do a final check on it before I upload it as new please? > > Especially, Clément & Martín, Sorry, I had a very busy week and did not have the chance to take a look! But I would be able to take a look now if it is still needed... -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#901623: Bug#901623: Bug#901623: golang-github-mwitkow-go-conntrack-dev: circular dependency hell
On 18/06/18 22:44, Alexandre Viau wrote: > On 2018-06-18 04:54 PM, Martín Ferrari wrote: >> Sadly, I don't see upstream changing this, but I will see if I can break >> the circle somehow. > > Sometimes, the circle is due to a test dependency and you can compromise > by disabling this particular test package. Maybe that can help you. Not in this case, I am afraid. conntrack is mostly about providing prometheus metrics, so it is core to its functionality; while the common lib uses it to decorate the http clients. The main problem is that common contains a bunch of unrelated stuff, I think. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#901623: Bug#901623: golang-github-mwitkow-go-conntrack-dev: circular dependency hell
Hi Bill, On 15/06/18 20:16, Bill Allombert wrote: > There is a circular dependency between > golang-github-mwitkow-go-conntrack-dev, > golang-github-prometheus-client-golang-dev, > golang-github-prometheus-common-dev and golang-prometheus-client-dev: > Thanks for spotting this, I introduced the circular dep without noticing during the last upload of -common. Sadly, I don't see upstream changing this, but I will see if I can break the circle somehow. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] You are not allowed to push code to this project
Hi, On 16/06/18 05:16, Alexandre Viau wrote: > I think that it is fair to say that team standards are dictated by what > dh-make-golang does. > > If you create a package with dh-make-golang, it will use pristine-tar > branches. It will also create a .gbp.conf[1], so please don't drop the > pristine-tar branch nor touch the .gbp.conf. > > We plan to move to a new layout eventually. However, until then, please > adopt the layout created by dh-make-golang unless you have a good reason > not to. Well, I disagree with this. It is fine to tell Tong to go the simpler way since the tooling is not there yet. But we agreed to move to this new workflow almost a year ago, and I have been consistently following it and converting repos as I go about updating packages. I understand not everybody wants to do it by hand, and that people don't have the time to fix the tooling, but I think we should at least consider these migrations steps in the right direction. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#901223: Bug#901223: gitaly: FTBFS: prometheus.Observer does not implement prometheus.Histogram
On 13/06/18 11:18, Pirate Praveen wrote: > It would have been better if there was co-ordination before uploading > such breaking changes. experimental first and heads up to failing > reverse depends would have been better. Hopefully we can improve for > future transitions. Definitely. I am sorry for causing this! I did try to test for breakage, but I guess I misinterpreted the salsa CI runner, or it did not check properly. So I uploaded thinking there was not going to be breakage. Also, it would be great if upstream did not do these kind of breaking changes without the equivalent of a soname change.. > https://salsa.debian.org/ruby-team/meta has build script which makes it > very easy to rebuild all reverse build dependencies. We have ratt, but that requires sbuild, so I ended up never using it. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#894131: Bug#894131: Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
On 12/06/18 17:00, Daniel Swarbrick wrote: > 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! I was just taking a look, the main thing would be to be able to build all the JS stuff, but it does not seem too bad.. Just need to find the time to do it :) > 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 packaging some of them. That would be great! If you want to join, there is an IRC channel (no mailing list for now) to chat and coordinate the packaging efforts: #debian-prometheus in OFTC. >> Yeah, the tilde will be removed once the final release is out.. But it >> still seems like a bug to panic due to that. I don't know how upstream >> presents the RC version number, but shouldn't that also break semver >> parsing? > The upstream version presents version number "0.15.0-rc.1", which > doesn't throw any errors in the semver.Parse function > (https://github.com/blang/semver/blob/master/semver.go). However, the > Unsee dashboard uses the MustParse() variant of that function, which of > course panics if Parse() returns an error. 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. > As you may have seen in the Github issue I opened, somebody is working > on it to hopefully make it a little more tolerant and robust. Yeah, but the solution proposed is just to strip everything after the tilde, which does not seem like a good solution. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#894131: Bug#894131: Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Hi Daniel, On 12/06/18 16:42, Daniel Swarbrick wrote: > 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 Oh, great! > tilde in the version number upsets the semantic version parsing in > Cloudflare's "unsee" dashboard > (https://github.com/cloudflare/unsee/issues/263). I had not heard about unsee until now, we should package it too! :) > I presume that issue should resolve itself once the final release is > out... I hope. Yeah, the tilde will be removed once the final release is out.. But it still seems like a bug to panic due to that. I don't know how upstream presents the RC version number, but shouldn't that also break semver parsing? -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Fwd: golang-github-prometheus-client-golang/0.9.0~pre1+git20180417.82f5ff1-2 appears to break golang-github-docker-go-metrics/0.0~git20170503.0.d466d4f-1 autopkgtest in testing
On 31/05/18 10:51, Paul Gevers wrote: > [Resend to @packages.d.o address as I am unsure the e-mail was read (no > response)] Sorry Paul, I missed this email. > On 24-05-18 13:48, Paul Gevers wrote: > It looks like to me that this is causing FTBFS (as seen on > reproducibility¹), so I guess that golang-github-docker-go-metrics > maintainers would want to create an RC bug against the > golang-github-prometheus-client-golang to prevent it from migrating > until the FTBFS is fixed. I am not that surprised, as these golang APIs are very unstable. I thought this had passed our regresion tests, but I guess I am still not used to the system :-) I took a quick look, and it indeed seems to be an incompatible API change. The problem is, there is no way to fix this unless we tried to change sonames everytime this happens (which is pretty often and without warning). It was merged here: https://github.com/prometheus/client_golang/pull/285/ Luckily, docker has already fixed it, so an update of the rdep should fix this issue: https://github.com/docker/go-metrics/issues/12 I will take a look into it next week as I will be offline for a few days, but if it is deemed that this needs to be blocked, please go ahead with the RC bug. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] golang-gopkg-alecthomas-kingpin.v3/3.0~git20180227.b8d601d-1 breaks golang-gopkg-alecthomas-kingpin.v3-unstable/2.1.11+git20171010.63abe20-1 autopkgtest in testing
Hi Paul, On 13/05/18 19:29, Paul Gevers wrote: > tl;dr: golang-gopkg-alecthomas-kingpin.v3/3.0~git20180227.b8d601d-1 breaks > golang-gopkg-alecthomas-kingpin.v3-unstable/2.1.11+git20171010.63abe20-1 > autopkgtest in testing > see: > https://ci.debian.net/packages/g/golang-gopkg-alecthomas-kingpin.v3-unstable/testing/amd64/ I am not sure if this is a bug in the CI infrastructure, of if I did something wrong. i had uploaded a new source package (golang-gopkg-alecthomas-kingpin.v3) that is meant to replace the one with the -unstable suffix and it binary package. I understand that -unstable will just vanish from the archive as soon as the new one replaces all the binary packages. Now the test is failing for the older package in testing, which in turn prevents the new package from migrating. I am not sure how to solve this, could you advice? Thanks for your efforts in improving our QA processes! -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] miniconf hamburg
Hey all, Is anybody planning to attend the miniconf in Hamburg? Could be good to organise some work/bof if we are a few there.. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] golang-1.10 issues on mips
Hi, golang-1.10 has been failing to build on mips for a while with similar issues (https://buildd.debian.org/status/logs.php?pkg=golang-1.10=mips), which is blocking testing migration. The thing is that we have so far failed to reproduce them on porter boxes. Can you please give it back to see if another buildd succeeds? Does the mips porters have any idea on why this could be? Thanks. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Bug#895889: Bug#895889: golang-github-weaveworks-mesh: new version causes regression in prometheus-alertmanager
Paul, Adrian, On 17/04/18 11:23, Adrian Bunk wrote: > On Tue, Apr 17, 2018 at 11:20:13AM +0200, Paul Gevers wrote: >> ... >> As the it seems that the same code is used to build the >> prometheus-alertmanager package, I think this means that that now FTBFS >> (haven't verified). >> ... > > prometheus-alertmanager does FTBFS now: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/prometheus-alertmanager.html I did not notice the update of mesh would break the current alertmanager in testing. I did the upload yesterday in preparation for a new upload of the alertmanager, so this FTBFS will be solved as soon as I am finished. Sadly, the golang ecosystem is very immature and has not yet learned about API stability or even releases... -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] package naming for kingpin.v3
On 16/04/18 12:19, Shengjing Zhu wrote: >> I was getting ready to upload this same package, which I did not find >> because of the -unstable suffix. > > but you can't import gopkg.in/alecthomas/kingpin.v3 That is true, but the v3-unstable name should not be used either, as it is not released (see https://gopkg.in/alecthomas/kingpin.v3-unstable). I am going to provide the compatiblity symlink, but I think it does not make sense to have a package with a name that needs to change as soon as it is released. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] package naming for kingpin.v3
I was getting ready to upload this same package, which I did not find because of the -unstable suffix. I think this was a bad idea, as now we will need renaming and transition packages when v3 is finally released... Same issue with the repo name. Plus, it is not following current practices, like following upstream git history. So, unless anybody sees this as a problem, I will take it over with a package using the v3 name, a repo with that name, etc. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
