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)
promtool from the .deb.
That would have to go through NEW, we are out of time for that :(
--
Martín Ferrari (Tincho)
:-)
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)
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
one (I really truly hope). If you want to complete it I am happy to back
> off and let you but I’m also happy to finish going through them. Just let me
> know!
Please continue then! Let me know if I can give you a hand. (Probably
easier on IRC)
--
Martín Ferrari (Tincho)
es this package for a bunch of other packages to be at risk of
autoremoval. I don't understand why...
--
Martín Ferrari (Tincho)
am working now with other breakage coming from
genproto, so maybe this can be fixed in a different -and less risky- way.
--
Martín Ferrari (Tincho)
in the same filesystem.)
So I will look into using the same dir as TMPDIR.
--
Martín Ferrari (Tincho)
Package: libgo13
Version: 8.2.0-15
Severity: normal
Hi,
Similarly to #839132, I've failing builds on some gccgo arches due to missing
FFI support in libgo:
fatal error: libgo built without FFI does not support reflect.Call or
runtime.SetFinalizer
This happens at least on ia64 and riscv64, but
d_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)
e 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)
in /usr/lib, for toools which use GOROOT to be able
to find these files.
--
Martín Ferrari (Tincho)
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)
is.. The version already
in buster works OK, I thought I needed to update to 3.0 (which I will do
anyway for sid), what would be preferred for stable-updates?
--
Martín Ferrari (Tincho)
ues/83
and there is a PR pending to fix this, but it is not yet complete...
--
Martín Ferrari (Tincho)
but if it is
not absolutely urgent, I would like to fix it. Also, it will be a good
opportunity to learn how to do uploads to stable :-)
--
Martín Ferrari (Tincho)
Tobias,
On 14/12/2018 21:54, Dr. Tobias Quathamer wrote:
> Am 14.12.2018 um 14:28 schrieb Martín Ferrari:
>> Tobias: I see you did the latest upload, but you did not follow the git
>> workflow I had started, and instead of following git commits, you merged
>> a snapshot.. I
and uploaded.
--
Martín Ferrari (Tincho)
but it seems this patch is not needed any more.
Tobias: I see you did the latest upload, but you did not follow the git
workflow I had started, and instead of following git commits, you merged
a snapshot.. I will need to rewrite git history now :(
--
Martín Ferrari (Tincho)
Chris et al,
On 26/10/18 15:31, Chris Lamb wrote:
>> I am concerned about the lack of progress. I would be grateful
>> for advice on what I should do next.
>
> I was led to believe — althought naturally feel very free to correct
> me — that the AH team were (quite correctly,) handling this
://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)
On 24/10/18 13:04, Andreas Beckmann wrote:
> Followup-For: Bug #911444
> Control: found -1 3.2.4-2
>
> Hi,
>
> you added the B+R to python3-flask-httpauth instead of
> python-flask-httpauth-doc
Oh, ffs. Sorry, I will reupload now
--
Martín Ferrari (Tincho)
fix asap!
--
Martín Ferrari (Tincho)
Hi Matt,
On 25/09/18 20:42, Matt Zagrabelny wrote:
> Would you consider packaging it for python3 as well, please?
Thanks for the report, I have just uploaded a new version with python3
support, which should be available soon.
--
Martín Ferrari (Tincho)
ting it upstream, it would
fit with the examples.
--
Martín Ferrari (Tincho)
add them if you write them :)
--
Martín Ferrari (Tincho)
rsion, 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)
just stop using debcommit, which is a pity.
--
Martín Ferrari (Tincho)
his dispute cannot be resolved amicably and timely, we believe the
FTP-master team can -and should- unilaterally remove the package from
the archive. We think that invoking the CTTE or calling a GR would
unnecessarily cause more disruption and draw energy from the community.
Martín Ferrari, on
On 12/09/18 15:59, Martín Ferrari wrote:
>> I'm not sure it warrants an upload right away, but it would be nice to
>> have it before debhelper is updated.
>>
>> Could anyone sponsor that ?
>
> I would be happy to, but I have not been following dh-golang devel much
&
oints 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)
merged.
THanks for your work!!
> I'm not sure it warrants an upload right away, but it would be nice to
> have it before debhelper is updated.
>
> Could anyone sponsor that ?
I would be happy to, but I have not been following dh-golang devel much
to decide if we sHould upload now.. Any other opinion?
--
Martín Ferrari (Tincho)
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)
ag 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)
n on tHE CPU, and none failed..
--
Martín Ferrari (Tincho)
y 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)
ot 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)
sts, 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)
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)
d 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)
Package: ftp.debian.org
Severity: normal
Hi,
Mtail has never worked on mips64el, because inotify support is broken (still
not sure where the root problem lies). It was compiled successfully once, but
due to a mistake in debian/rules that meant not all tests were run.
I was able to work-around
he tooling does not yet support the new repo layout, you just add
upstream's repo as a remote and pull from there into the upstream branch.
--
Martín Ferrari (Tincho)
repackaging
differences. Gbp buildpackage works well with this workflow, as you only
need to add the appropriate tags. The missing part will be the
automation to update these branches, ideally using files-exluded as the
source of truth.
--
Martín Ferrari (Tincho)
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 d
s, 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)
e 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)
I think the problem is the latest upload of
golang-github-prometheus-client-golang-dev, which had some incompatible
changes. It also affected docker go-metrics (#900597).
Sadly, the only solution is to update to the new API, but probably
upstream has already done it in their repo.
--
Martín Ferrari (Tincho)
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 d
d 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)
On 08/06/18 13:54, Dr. Tobias Quathamer wrote:
> @Martín, as you're the last uploader of net-tools: I've attached a patch
> which fixed this (and some other) typos in the German manpage.
Thanks, will merge!
--
Martín Ferrari (Tincho)
I have just uploaded a new version, and migrated the repo to salsa, but
I could not remove the old one as I lack permissions. Please, can you
take care of that?
On 22/05/18 21:48, Martín Ferrari wrote:
> retitle 899131 ITA: sieve-extension
> thanks
>
> I am preparing an upl
retitle 899131 ITA: sieve-extension
thanks
I am preparing an upload to adopt this package and fix outstanding bugs.
--
Martín Ferrari (Tincho)
s about JSON parsing errors when given invalid JSON
✓ writes module version into stdout when runned with --version (1828ms)
✓ writes module version into stdout when runned with -v (1931ms)
--
Martín Ferrari (Tincho)
m testing mustache.js and its reverse dependencies.
--
Martín Ferrari (Tincho)
n 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)
fixed 890501 2.2.0+ds-1
thanks
Due to some mistake in my workflow, a couple of changelog entries went
missing in 2.2.0+ds-1, and so this bug was never closed. I added the
entries retrospectively, and closing manually the bug now..
--
Martín Ferrari (Tincho)
in debian). The problem is the
generated code, which is not source code (preferred form of modification).
--
Martín Ferrari (Tincho)
On 26/03/18 17:24, Daniel Swarbrick wrote:
> Please backport Prometheus 2.2.1 to stretch.
It is in my plans, but it has to reach testing first :-)
--
Martín Ferrari (Tincho)
use of this that I thought of stripping the UI away, and
replacing it with something bare-bones. This would not be that difficult
to do, it is just a matter of writing some html and JS.
If you could help me with that, I would take care of integrating the
replacement UI, and I could get a new releas
s UI without the dynamic JS generated with Elm.
I am maintaining most of the prometheus ecosystem by myself, so I have
not been able to do any of this. If you have the resources to help, you
would be most welcomed!
--
Martín Ferrari (Tincho)
reproduce..
I have a fix and it seems I can't reproduce the problem any more.
--
Martín Ferrari (Tincho)
On 20/02/18 19:17, Adrian Bunk wrote:
> Source: golang-golang-x-tools
> Version: 1:0.0~git20170707.0.bce9606b+ds-1
> Severity: serious
Thanks for the report. It seems this is one of the packages that broke
with the swtich to golang 1.10. I will take a look into it.
--
Martín Ferrari (Tincho)
rue
chown -R prometheus:prometheus /var/log/prometheus || true
And the initsciprt does this (as root):
mkdir -p `dirname $PIDFILE` || true
chown -R $USER: `dirname $LOGFILE`
chown -R $USER: `dirname $PIDFILE`
So, I don't know where you saw that mkdir, nor where it could be a problem.
--
Martín Ferrari (Tincho)
Ah, sorry, now I see that you are reporting against the version in
stable. There is not much I can do to fix that, the version in testing
does not have this issue.
What I can do (and I had forgotten to do before), is to backport that
version to stretch.
On 23/02/18 14:48, Martín Ferrari wrote
I had no idea there was now a tsdb lockfile,
and I agree that it makes sense to disable it, since we have that
functionality implemented in the init/service files.
--
Martín Ferrari (Tincho)
d/manpages didn't work well due to the
> fact that dh_installman will install the manpage into all the man/ll_LL/
> directories.
Thanks! I will include it in the next upload.
--
Martín Ferrari (Tincho)
e looks good. I only made a couple of minor corrections, and
uploaded it :)
--
Martín Ferrari (Tincho)
Package: prometheus
Version: 2.1.0+ds-1
Severity: grave
Tags: upstream
Justification: renders package unusable
The upstream developers of Prometheus have advised me to block transition of
prometheus 2.1.0+ds-1 due to some serious performance issues introduced with
this release. I expect a fix for
Status update: still waiting for upstream's fix.
On 18/12/17 04:55, Martín Ferrari wrote:
> Adrian,
>
> Thanks for the report. I presume this error is due to the change in the
> Prometheus' common library. I am already preparing a new upstream
> release, but that is waiting on
rt Adrian, this seems like a CPU contention issue; I
have just reported it upstream. I will disable these flakey tests for
now to fix the build.
--
Martín Ferrari (Tincho)
Source: golang-golang-x-net-dev
Version: 1:0.0+git20170629.c81e7f2+dfsg-1
Severity: serious
Justification: fails to build from source
I noted a few packages failing to build from source on s390x, and tracked down
the cause to this package:
# golang.org/x/net/internal/socket
Package: ftp.debian.org
Severity: normal
Hi,
As per https://github.com/prometheus/prometheus/issues/3665 upstream has
expressed they are not supporting 32 bit arches any more, and their doubt about
the usefulness of the package in those arches. Since this is preventing
prometheus from migrating
It seems that updating to v0.16.0 fixes this issue but that pulls new
dependencies, so I am just going to backport the fix for this.
On 04/01/18 11:49, Martín Ferrari wrote:
> On 14/12/17 22:48, Adrian Bunk wrote:
>
>> # cloud.google.com/go/spanner/internal/testutil
>> src/c
pannerServer:
> *MockCloudSpanner does not implement spanner.SpannerServer (missing
> ListSessions method)
> ...
It seems the latest upload to golang-google-genproto broke the API. Will
have to investigate...
--
Martín Ferrari (Tincho)
ages,
since we have decided to use upstream git history, and repack on git, so
there is no real usage for it --except documentation.
--
Martín Ferrari (Tincho)
pendency. I usually keep it around
for reference, as it is very useful when things break. I really don't
see much the point of removing it, or making a very complicated
files-excluded field. Also, how can it be a DFSG violation?
--
Martín Ferrari (Tincho)
sts.reproducible-builds.org/debian/rb-pkg/unstable/amd64/prometheus-mysqld-exporter.html
>
> ...
> === RUN TestScrapeInnodbMetrics
> --- FAIL: TestScrapeInnodbMetrics (0.00s)
> info_schema_innodb_metrics_test.go:17: no such flag -log.level
--
Martín Ferrari (Tincho)
nstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
p.To.Index = v.Args[1].Reg()
On 24/10/17 19:44, Martín Ferrari wrote:
> forwarded 877541 https://github.com/golang/go/issues/22429
> thanks
>
> I have opened an issue in upstream's tracker:
> https://github.com/golang/go/issues/22429
>
--
Martín Ferrari (Tincho)
forwarded 877541 https://github.com/golang/go/issues/22429
thanks
I have opened an issue in upstream's tracker:
https://github.com/golang/go/issues/22429
--
Martín Ferrari (Tincho)
If I disable optimizations (-N option for go tool compile), the error
disappears. I think this confirms it is a compiler bug.
$ GOPATH=$PWD/build go test -c -v -gcflags=-N
github.com/prometheus/prometheus/storage/local
$ GOPATH=$PWD/build go test -c -v
github.com/prometheus/prometheus/web/ui returned exit code 2
> debian/rules:46: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 2
>
> ___________
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
Moreover, if I try to patch the library adding this:
import gi
gi.require_version("Gtk", "3.0")
I don't get the Gtk error, but still get a segmentation fault. This was
also reported on Launchpad (https://bugs.launchpad.net/geis/+bug/1695998)
On 27/09/17 15:36, Martín Ferra
severity 855124 serious
thanks
Hi, I am also getting this error, which makes the tool unusable.
Moreover, this seems to affect sid and stable, and has got no replies
since February..
--
Martín Ferrari (Tincho)
t I've
heard it is actually a kernel problem).
I think it does not make much sense to open more RC bugs against these
packages that cannot really be fixed until the root cause is addressed.
--
Martín Ferrari (Tincho)
just disable the test completely.
It is not testing the hardware, it is testing that the write completes,
and developers many times assume everybody has fast hardware, and then
you get these bugs. We could argue about disabling this test (which is
noted as hacky by upstream), but those are not the
ame
> in bytes of this stream is greater than OLENAMELENGTH (32) bytes so the
> parsing is aborted.
After reading the code more carefully, this makes perfect sense. I will
upload the fix now. Thanks for reporting!
--
Martín Ferrari (Tincho)
Package: wnpp
Severity: wishlist
Owner: Martín Ferrari <tin...@debian.org>
* Package name: golang-github-google-go-cmp
Version : 0.1.0-1
Upstream Author : Google
* URL : https://github.com/google/go-cmp
* License : BSD-3-clause
Programming La
ue you mention, so there is definitely a
bug. Sadly, catdoc's code is not the easiest to follow :/
--
Martín Ferrari (Tincho)
On 14/07/17 12:59, Martín Ferrari wrote:
> On 14/07/17 11:21, Santiago Vila wrote:
>
>> It could also be a race condition which happens more
>> likely on low memory systems. Feel free to recategorize.
>
> Honestly, without a way to reproduce it, I am more inclined to clos
On 24/08/17 19:11, Shengjing Zhu wrote:
> Control: severity -1 normal
>
> On Thu, Aug 24, 2017 at 10:37 PM, Martín Ferrari <tin...@debian.org> wrote:
>> Yes, sorry, I was confused with x/tools, which has disabled tests. This
>> one does not get built in other ar
Source: golang-google-cloud
Version: 0.5.0-2
Severity: serious
Justification: fails to build from source
Since the latest update to golang-google-genproto-dev, this package FTBFS.
The fix for this is in release 0.7.0, but that requires also updating
golang-github-googleapis-gax-go-dev, and I am
ing value ("autopkgtest-pkg-elpa") in:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d5f0c0115ef46eb98d1b68f7113aa63d93f72211
>
> … and renaming this bug to match :)
Cool, we just need to wait for the next release then. Thanks!
--
Martín Ferrari (Tincho)
Package: lintian
Version: 2.5.52
Severity: normal
Hi,
Currently, lintian complains about the pkg-go testsuite, but autodep8 has
support for it since 0.9.
source: unknown-testsuite autopkgtest-pkg-go
Can you add pkg-go to the list of valid testsuites?
Moreover, autodep8 already supports a few
prior to installing, also
> creating backups for updates.
I don't think this affects Debian much, but I will apply it anyway. Thanks!
--
Martín Ferrari (Tincho)
should build out of the box. Can't you add the correct build
restrictions for gccgo so we don't need the tags?
--
Martín Ferrari (Tincho)
Type 'void' is not
assignable to type 'TResult'.
debian/rules:43: recipe for target 'build-indep' failed
--
Martín Ferrari (Tincho)
--- a/pkg/services/sqlstore/sqlstore.go
+++ b/pkg/services/sqlstore/sqlstore.go
@@ -15,6 +15,7 @@
"github.com/grafana/grafana/pkg/set
FS.
>
I am being stupid and mixing x/tools with x/sys. Sorry about the noise.
--
Martín Ferrari (Tincho)
Package: golang-golang-x-tools-dev
Version: 0.0~git20170629.0.1b3bb8de-1
Severity: grave
Since 0.0~git20170629.0.1b3bb8de-1 a patch has made the source files shipped
fail to build in mips* architectures. It does not FTBFS just because tests have
been disabled in a previous version, but it is
reassign 870843 golang-github-sirupsen-logrus-dev
thanks
This bug is filed under the wrong package.
1 - 100 of 781 matches
Mail list logo
