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)
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)
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)
Bug#921351: [pkg-go] 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.
Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1
On 05/02/2019 07:23, Stephen Gelman wrote: >> Ouch. More reason to hold the upgrade then. > > Sorry, I think you misinterpret what I mean: 0.34.1 works perfectly out of > the box, I was referring to trying to get 0.9.0 working. At this point there > have already been 7 debian revisions of 0.9.0 so regardless of the outcome > here I think we should plan to upload a newer version in the near future > (though I agree with your point about getting 0.9.0 patched first). Ah, yes, I misunderstood, I thought you were working on 0.34! >> I have already been working on this for a while. That problem is fixed, >> but there are still a few discrepancies with bigtable and spanner, which >> I hope to fix soon and upload. Unless you had already fixed that? > > I am still getting through the spanner tests but I am pretty close to being > done (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)
Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1
On 05/02/2019 06:41, Stephen Gelman wrote: > I totally understand your concern. I’m at least a few backported bug fixes > deep and I am concerned the resulting package will have had so many changes > applied that it will be a bit of a mess. Ouch. More reason to hold the upgrade then. > As a middle ground, I think I can get 0.9.0 patched for now with the intention of uploading a new version once we are out of hot water here. Do you think that is reasonable? Yesm that sounds good. In fact, I was writing an email to you telling you that I think the fix is pretty easy: the breakage is because genproto removed a deprecated API (google.golang.org/genproto/googleapis/cloud/speech/v1beta1) that this package depends on. The fix (as upstream did it) is to remove the packages that reflect that API, and it is easy to backport. I have already been working on this for a while. That problem is fixed, but there are still a few discrepancies with bigtable and spanner, which I hope to fix soon and upload. Unless you had already fixed that? > I apologize if I didn’t communicate my intentions better here - I emailed pkg-go a while back but I neglected to respond to this bug (oversight on my part, sorry!). No, I remember seeing that message, but being too busy with other corners of Debian to pay much attention :) PS: I was wrong in my previous message, there are not that many packages depending on google-cloud. But for some reason, the autoremoval system blames this package for a bunch of other packages to be at risk of autoremoval. I don't understand why... -- Martín Ferrari (Tincho)
Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1
On 05/02/2019 04:44, Stephen Gelman wrote: > I have 0.34.1 almost ready to upload - just waiting on two deps to clear NEW. Sorry to be a killjoy, but are you sure a new version is needed to solve this problem? We are very close to the freeze, and way too many packages depend on this. I 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)
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)
Bug#920939: libgo13: libgo built without FFI in ia64/riscv64
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 probably on other arches too. I need to fix other problems there first. Build logs: https://buildd.debian.org/status/fetch.php?pkg=golang-golang-x-tools=riscv64=1%3A0.0%7Egit20190125.d66bd3c%2Bds-3=1548787176=0 https://buildd.debian.org/status/fetch.php?pkg=golang-golang-x-tools=ia64=1%3A0.0%7Egit20190125.d66bd3c%2Bds-3=1548827237=0 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (10, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgo13 depends on: ii gcc-8-base 8.2.0-14 ii libc6 2.28-5 ii libgcc1 1:8.2.0-14 ii zlib1g 1:1.2.11.dfsg-1 libgo13 recommends no packages. libgo13 suggests no packages.
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)
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)
Bug#899298: Bug still present in 1.11
reassign 899298 golang-1.11-src found 899298 1.11.5-1 reopen 899298 thanks This bug was closed when golang 1.10 was removed from Debian, but the bug is present, and it is at least affecting x/tools. The golang-X.Y-src packages, which provide /usr/share/go-X.Yapi/, should also ship a symlink in /usr/lib, for toools which use GOROOT to be able to find these files. -- Martín Ferrari (Tincho)
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)
Bug#918163: Broken in Stretch
tags 918163 stretch thanks On 03/01/2019 22:18, Moritz Muehlenhoff wrote: > The plugin is broken with Thunderbird 60 in stretch, after installation > it's disabled and only prints "Sieve is incompatible with Thunderbird 60.4". There is something I only realise now about this.. 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)
Bug#918418: django-prometheus FTBFS: test failures
Hi, On 05/01/2019 22:06, Adrian Bunk wrote: > Source: django-prometheus > Some recent change in unstable makes django-prometheus FTBFS: This is due to the changes in the Prometheus Python client library. This is discussed in https://github.com/korfuri/django-prometheus/issues/83 and there is a PR pending to fix this, but it is not yet complete... -- Martín Ferrari (Tincho)
Bug#918163: Broken in Stretch
Hi Moritz, On 03/01/2019 22:18, Moritz Muehlenhoff wrote: > The plugin is broken with Thunderbird 60 in stretch, after installation > it's disabled and only prints "Sieve is incompatible with Thunderbird 60.4". Ouch > TB 60 was uploaded to stretch over two months ago, given that noone filed > a bug so far, it makes me wonder whether this package is used at all... I use it, but not in stretch.. > Martín, do you intend to update it in stretch or should it rather be removed > by the next point release? Right now I am completely stomped by other Debian duties, 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)
Bug#916236: golang-golang-x-net-dev: FTBFS on s390x - rawconn.go undefined: getsockopt
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 will need to rewrite git history now :( > > Hi Martín, > > I'm really sorry that I messed up your workflow and caused you extra > work. That was certainly not my intention. I am sure of that! Sorry for my frustrated message, I have fixed it now and it was not a big deal. But you will need to re-clone or reset all your local branches now. -- Martín Ferrari (Tincho)
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)
Bug#916236: golang-golang-x-net-dev: FTBFS on s390x - rawconn.go undefined: getsockopt
On 11/12/2018 19:11, Alexandre Viau wrote: > Package: golang-golang-x-net-dev > Version: 1:0.0+git20181201.351d144+dfsg-1 > > It looks like the golang-golang-x-net-dev build is broken on s390x. I am also getting similar errors in prometheus-node-exporter. I will take a look, 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)
Bug#907199: Should the weboob package stay in Debian?
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 issue and > thus I have not been taking action on it myself as leader@. We were asked for an opinion on this matter, which we expressed about a month ago in the BTS. We think we should not get involved in the minutiae of how this is solved, but our original recommendation still remains (quoting from our previous email): > We believe the next release should not contain the package in > question in its current state [..] > If this dispute cannot be resolved amicably and timely, we believe > the FTP-master team can -and should- unilaterally remove the package > from the archive. For further clarification, this means that we believe there is time until the freeze to solve this issue, and if it is not solved by then, the package should be removed from testing and unstable. -- Martín signature.asc Description: OpenPGP digital signature
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)
Bug#911444: python-flask-httpauth-doc: missing Breaks+Replaces: python-flask-httpauth (<< 3.2.4)
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)
Bug#911444: python-flask-httpauth-doc: missing Breaks+Replaces: python-flask-httpauth (<< 3.2.4)
Hi Andreas, On 20/10/18 10:09, Andreas Beckmann wrote: > It installed fine in 'stretch', then the upgrade to 'buster' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. Ahh, I totally missed that. Thanks for reporting, will fix asap! -- Martín Ferrari (Tincho)
Bug#909598: python-flask-httpauth: provide python3 module
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)
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)
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)
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)
Bug#631477: Another issue with tags
Hi, To add to this bug report, I noticed a problem with debcommit -r when tagging a native package: it does not add the 'debian/' prefix, which gbp buildpackage adds, and seems to be the preferred way. Inconsistencies aside, there is no way to customise this behaviour, so this means I should just stop using debcommit, which is a pity. -- Martín Ferrari (Tincho)
Bug#907199: Should the weboob package stay in Debian?
Hi all,
I am writing on behalf of the Anti-Harassment team, as our input has
been requested on this issue.
Our understanding, after reading the mail threads and bug reports, is
that the package in its current shape is against the Debian CoC ("be
respectful") -- while it's not a "flagrant" violation,
As Gregor Herrmann eloquently[1] put it, it's "not ok to use the boobs
theme for a web scraper or other software unrelated to boobs [sic]
themselves, where its only function is to make a small group of users
giggle while objectifying, offending or boring the rest of the world."
We appreciate uploading a new version without the insults (and thank
Jonathan Dowland for his efforts[2][3] on this front). Please note that
the insults and homophobic language *is* a flagrant violation of
Debian's CoC and in our opinion, Debian should not ship new software
including them.
We believe the next release should not contain the package in question
in its current state; our recommendation would be to either work with
upstream on correcting these issues, forking and/or patching it, or just
removing the package. There is still enough time to find a solution that
respects our users and our community while keeping a useful piece of
software in the archive. We would also encourage all parties to be
respectful, and to observe the community needs for a healthy environment
where such puerile humour taken at the expense of other people is not
acceptable any more.
If this 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 behalf of the Anti-Harassment team.
[1]: https://lists.debian.org/debian-devel/2018/07/msg00428.html
[2]: https://git.weboob.org/weboob/devel/merge_requests/228
[3]: https://git.weboob.org/weboob/devel/issues/154
--
Martín Ferrari (Tincho)
signature.asc
Description: OpenPGP digital signature
Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge
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 > to decide if we sHould upload now.. Any other opinion? I have just uploaded it. -- Martín Ferrari (Tincho)
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)
Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge
On 12/09/18 10:37, Clément Hermann wrote: >> So, if no one objects, I'll merge the branch, add the relevant changelog >> entries and upload^Wask for someone to upload. ;) >> >> (and I'll take care of the bug creation on debhelper meanwhile). > > And it has been 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)
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)
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)
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)
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)
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)
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)
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)
Bug#904261: [pkg-go] 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)
Bug#905152: RM: mtail [mips64el] -- ROM; Can't fix arch-specific bugs
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 this for prometheus, but the code in mtail is too complex for my limited golang abilities. There is a bug[1] open in the fsnotify library, but the project is semi-abandoned. So, for now I would like to request the removal of mtail from this architecture, so it can finally migrate to testing. PS: I also requested[2] mtail upstream to try to address this. Thanks. [1]: https://github.com/fsnotify/fsnotify/issues/241 [2]: https://github.com/google/mtail/issues/157#issuecomment-409380724
Bug#904103: [pkg-go] Bug#904103: golang-github-json-iterator-go: Please package latest release v1.1.4
Hi, On 19/07/18 18:45, Dmitry Smirnov wrote: > Could you please package latest release of this package, v1.1.4? > Update is trivial, only two new dependencies: I uploaded an old version of this on purpose, because of the dependencies. They had a dependency cycle, which I reported in a bug. I think it has been fixed now, so I will look again into it. > But I'm not sure if I could help with this weird repository layout... > Even though upstream have semantically versioned releases it doesn't look > like running `gbp import-orig` would be correct. Is that right? No, the 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)
Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch
On 05/07/18 14:19, Guido Günther wrote: >> So IMHO, the upstream branch should only contain upstream commits. >> Then question comes to how we create the dfsg orig tarball. > > Just create a commit with the files filtered out and tag it approriately > (with the original commit as parent). gbp export-orig/buildpackage will > then be able to find it to create the tarball. This is what I have been doing in my packages, and what has been agreed to become the standard for the go team. Using one branch for the pristine upstream history, and another one that keeps the 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)
Bug#901623: [pkg-go] 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)
Bug#901623: [pkg-go] 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)
Bug#901223: [pkg-go] 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)
Bug#901223: [pkg-go] Bug#901223: gitaly: FTBFS: prometheus.Observer does not implement prometheus.Histogram
On 13/06/18 07:54, Pirate Praveen wrote: > On Sun, 10 Jun 2018 11:10:48 +0200 Andreas Beckmann wrote: >> Justification: fails to build from source (but built successfully in the >> past) > > seems broken by golang-github-prometheus-common-dev 0+git20180518.7600349-1 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)
Bug#894131: [pkg-go] 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)
Bug#894131: [pkg-go] 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)
Bug#900962: manpages-de: Typo in the manpage of 'netstat' (German translation)
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)
Bug#899131: Adopt
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 upload to adopt this package and fix outstanding bugs. > -- Martín Ferrari (Tincho)
Bug#899131: Adopt
retitle 899131 ITA: sieve-extension thanks I am preparing an upload to adopt this package and fix outstanding bugs. -- Martín Ferrari (Tincho)
Bug#897536: mustache.js: FTBFS: make[1]: rake: Command not found
On 17/05/18 09:48, Lucas Nussbaum wrote: >> I have no issue with this decision. > Same here. But it's strange: given my workflow, I think that the build > was retried on a idle server after the initial failure. Not sure what happened, but you can see there is some timing info in some tests, and the run that failed was 3 times slower than the other, and the tests that passed were very close to the cut-off: Passing: Mustache CLI ✓ writes syntax hints into stderr when runned with wrong number of arguments (531ms) ✓ writes hints about JSON parsing errors when given invalid JSON (639ms) ✓ writes module version into stdout when runned with --version (605ms) ✓ writes module version into stdout when runned with -v (550ms) Failing: Mustache CLI ✓ writes syntax hints into stderr when runned with wrong number of arguments (1795ms) 1) writes hints 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)
Bug#897536: mustache.js: FTBFS: make[1]: rake: Command not found
severity 897536 important thanks On Mon, 14 May 2018 00:30:36 +0200 Pierre-Elliott =?iso-8859-1?Q?B=E9cue?= <be...@crans.org> wrote: > Indeed the rake issue is gone with the latest upload of rake. > > Yet, [1] shows that mustache.js still FTBFS. > [1] > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mustache.js.html While we should fix this, I don't think this counts as a serious bug. The tests fail sometimes (probably on a busy server), but that's it. I think the severity of this bug should be lowered, as this is threatening to remove from testing mustache.js and its reverse dependencies. -- Martín Ferrari (Tincho)
Bug#895889: [pkg-go] 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)
Bug#890501: [pkg-go] Bug#890501: prometheus startup fails due to racey PID file implementation in prometheus
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)
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Daniel, On 27/03/18 09:06, Daniel Swarbrick wrote: > Debian currently has Haskell Platform 2014.2.0.0 (GHC 7.8.3), so to > build the version of Elm used by Alertmanager, Debian would most likely > first have to update their Haskell. And so it continues... Ah, nice.. > I think you idea of stripping away the UI and replacing it with > something non-standard is not a good idea, because Debian will become > known as "that distro" which has non-standard Prometheus packages. > People will either use a different distro, or run it in Docker, or > something else - in any case, your work will have been for nothing. Well, I don't really care about being not standard in that sense. The standard is to run docker packages downloaded from untrusted sources, fwiw. My objective is to provide sysadmins that align with the Debian worldview with a working Prometheus stack. I have had already to deviate from the standard in a few things, for example: kubernetes support was removed from the prometheus Debian package because it is unmaintainable, until the k8s people get their act together. > What exactly in Debian policy is preventing us shipping Alertmanager > built as intended by upstream? I don't remember which section in the Policy that is. But those generated files are not source code, and therefore there is a requirement to (re)build them from source. It is the same as i was shipping a pre-compiled .so file. > Would it be an option to _decompress_ the gzipped & hex-encoded blobs > from Alertmanager's ui/bindata.go back to their sources and package > those? Looking at the file, that would produce these files: This is not really a problem, I am not shipping the binary blob (because I want to reuse libraries already present in debian). The problem is the generated code, which is not source code (preferred form of modification). -- Martín Ferrari (Tincho)
Bug#894129: [pkg-go] Bug#894129: prometheus: Please backport Prometheus 2.2.1 to stretch.
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)
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Hi Daniel, On 26/03/18 20:34, Daniel Swarbrick wrote: > I was a bit too hasty in my previous reply. It appears that Alertmanager > compresses and encodes all the web UI assets a Go "blob" > (https://github.com/prometheus/alertmanager/blob/master/ui/bindata.go). > Elm libraries are only needed if you intend to hack / develop the web UI. Exactly. Prometheus itself does the same thing. The approach I took was to remove the blob and patch the web serving code to read the files directly from disk, and then to do al the JS processing at build time from source. I would do the same for alertmanager, but for that I need a working Elm stack to generate the JS from source, otherwise it is a serious violation of Debian policy. > I just built a fully functional alertmanager binary from a git clone, > with no Elm or Haskell or Node.js anywhere to be seen on my system. This > is why I mistakenly thought that the aforementioned RPMs had stripped > the UI completely, when in fact it is simply compiled into the > alertmanager binary. > > Does this simplify things somewhat? I suppose it just leaves the > vendored Go libs as a possible sticking point. Vendoring Go libs would not be a direct violation of policy, but it is something we try hard to avoid as it becomes a maintenance problem. Vendoring pre-generated pre-minified code, on the other hand, is not possible in Debian, and that's how we ended in the current situation :-) It is because 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 release out of the door pretty quickly. -- Martín Ferrari (Tincho)
Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
Daniel, On 26/03/18 17:31, Daniel Swarbrick wrote: > Current Debian packages for prometheus-alertmanager are extremely out of > date. The web UI and (undocumented / unstable) API has changed > considerably in the ten versions that have been released since 0.6.2, > along with many bugfixes. I know, this is a pretty sad state. The problem is that upgrading the alertmanager requires packaging and uploading many new packages, as they started using the Elm system for the UI, and no part of it is in Debian. The alternative to this is to develop a patch that will provide an barebones 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)
Bug#891356: [pkg-go] Bug#891356: golang-google-cloud FTBFS: FAIL google.golang.org/cloud/spanner
On 24/02/18 21:14, Adrian Bunk wrote: > Source: golang-google-cloud > Version: 0.9.0-4 > Severity: serious Another flaky test. Actually, I think it only worked by chance (because goroutines will take a while to start), but it still required a busy CPU, 19 niceness, and a while loop to reproduce.. I have a fix and it seems I can't reproduce the problem any more. -- Martín Ferrari (Tincho)
Bug#890927: [pkg-go] Bug#890927: golang-golang-x-tools: FTBFS and Debci failure with golang-1.10-go
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)
Bug#891202: [pkg-go] Bug#891202: prometheus-alertmanager: False owner/group for /var/lib/prometheus
Hi, On 23/02/18 12:17, tuxcoder wrote: > The service trys to `mkdir /var/lib/prometheus/alertmanager` on startup, > but the dir `/var/lib/prometheus` is owned by root. > > If the package `prometheus` is installed first this is not the case. Uhm, I think you are mistaken, or I missed something. The directory is created when unpacking the deb file: $ dpkg -L prometheus-alertmanager | grep /var/lib/ /var/lib/prometheus /var/lib/prometheus/alertmanager Then the post-installation script does this: chown -R prometheus:prometheus /var/lib/prometheus/alertmanager || true 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)
Bug#891202: [pkg-go] Bug#891202: prometheus-alertmanager: False owner/group for /var/lib/prometheus
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: > Hi, > > On 23/02/18 12:17, tuxcoder wrote: > >> The service trys to `mkdir /var/lib/prometheus/alertmanager` on startup, >> but the dir `/var/lib/prometheus` is owned by root. >> >> If the package `prometheus` is installed first this is not the case. > Uhm, I think you are mistaken, or I missed something. > > The directory is created when unpacking the deb file: > > $ dpkg -L prometheus-alertmanager | grep /var/lib/ > /var/lib/prometheus > /var/lib/prometheus/alertmanager > > Then the post-installation script does this: > > chown -R prometheus:prometheus /var/lib/prometheus/alertmanager || true > 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)
Bug#890501: [pkg-go] Bug#890501: prometheus startup fails due to racey PID file implementation in prometheus
Hi Tim, On 15/02/18 12:09, Tim Small wrote: > Due to https://github.com/prometheus/prometheus/issues/2689 Prometheus > may fail to start (most commonly after a reboot), since the lock file > checking implementation it uses is naive (just "is there a pid running > with the same pid number that I wrote to the pid file"). > > The recommended (by upstream) workaround is to disable the lock file > checking by using the --storage.tsdb.no-lockfile commandline argument > when starting prometheus from the systemd unit file etc. Thanks for your bug report. 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)
Bug#88910: iptunnel doesn't have man page
Sergio, On 11/02/18 01:54, Sergio Durigan Junior wrote: > [ Almost 17 years later... ] :-) > This is the manpage for the "iptunnel" program. I decided to create a > new $(DEBIAN_MANPAGES) variable on d/rules, and install the manpage > accordingly, because just using 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)
Bug#883488: RFS: golang-gopkg-lxc-go-lxc.v2
On 03/02/18 16:23, Clément Hermann wrote: > The last missing dependency for LXD should be ready to upload, > hopefully. If a DD could have a look at it and upload it that would be > awesome. > > Martín, maybe preferably you since you already had a first look at it ? The package looks good. I only made a couple of minor corrections, and uploaded it :) -- Martín Ferrari (Tincho)
Bug#888153: prometheus: Performance problems in 2.1.0
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 this will be released soon, but meanwhile this bug should stop prometheus from migrating to testing. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages prometheus depends on: ii adduser 3.116 ii daemon 0.6.4-1+b2 ii debconf [debconf-2.0]1.5.65 ii libc62.26-1 pn libjs-bootstrap pn libjs-eonasdan-bootstrap-datetimepicker ii libjs-jquery 3.2.1-1 pn libjs-jquery-hotkeys pn libjs-moment pn libjs-mustache pn libjs-rickshaw Versions of packages prometheus recommends: pn prometheus-node-exporter prometheus suggests no packages.
Bug#884542: [pkg-go] Bug#884542: prometheus-mysqld-exporter FTBFS: FAIL: TestScrapeInnodbMetrics
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 an upstream bug: > https://github.com/prometheus/mysqld_exporter/issues/251 > > > On 16/12/17 12:03, Adrian Bunk wrote: >> Source: prometheus-mysqld-exporter >> Version: 0.9.0+ds-3 >> Severity: serious >> Tags: buster sid >> >> Some recent change in unstable makes prometheus-mysqld-exporter FTBFS: >> >> https://tests.reproducible-builds.org/debian/history/prometheus-mysqld-exporter.html >> https://tests.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)
Bug#887070: [pkg-go] Bug#887070: prometheus-blackbox-exporter FTBFS on armhf/mips*: FAIL github.com/prometheus/blackbox_exporter/prober
forwarded 887070 https://github.com/prometheus/blackbox_exporter/issues/285 thanks On 13/01/18 14:10, Adrian Bunk wrote: > === RUN TestTCPConnectionQueryResponseIRC > panic: Error accepting on socket: accept tcp 127.0.0.1:39921: use of closed > network connection Thanks for the report 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)
Bug#886761: FTBFS[s390x]: textflag.h: No such file or directory
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 src/golang.org/x/net/internal/socket/sys_linux_s390x.s:5:10: fatal error: textflag.h: No such file or directory #include "textflag.h" ^~~~ compilation terminated. It seems the source is meant to be compiled with golang-go (which includes textflag.h), but we are compiling with gccgo, and thus it fails. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#886702: RM: prometheus [i386] -- ROM; Upstream request
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 to testing, please remove the i386 packages from the archive. Thanks.
Bug#884406: [pkg-go] Bug#884406: golang-google-cloud FTBFS and Debci failure: *MockCloudSpanner does not implement spanner.SpannerServer
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/cloud.google.com/go/spanner/internal/testutil/mockserver.go:238:30: >> cannot use m (type *MockCloudSpanner) as type spanner.SpannerServer in >> argument to spanner.RegisterSpannerServer: >> *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)
Bug#884406: [pkg-go] Bug#884406: golang-google-cloud FTBFS and Debci failure: *MockCloudSpanner does not implement spanner.SpannerServer
On 14/12/17 22:48, Adrian Bunk wrote: > # cloud.google.com/go/spanner/internal/testutil > src/cloud.google.com/go/spanner/internal/testutil/mockserver.go:238:30: > cannot use m (type *MockCloudSpanner) as type spanner.SpannerServer in > argument to spanner.RegisterSpannerServer: > *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)
Bug#885726: [pkg-go] Bug#885726: golang-github-hashicorp-go-sockaddr: Source includes "cmd/sockaddr/vendor/vendor.json" listed in Files-Excluded header
On 30/12/17 13:06, Chris Lamb wrote: >> Also, how can it be a DFSG violation? > It was just an entirely-generic list of possible problems, don't > worry. Ah, OK. >> I really don't see much the point of removing it, or making a very >> complicated >> files-excluded field. > > Mmm. I have a rough plan to make this an autoreject Lintian tag, so that > would be problematic here. :) > > Would something like (untested) "cmd/sockaddr/vendor/*/*" not work, ooi? I guess.. Also, we should probably remove that field from most packages, 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)
Bug#885726: [pkg-go] Bug#885726: golang-github-hashicorp-go-sockaddr: Source includes "cmd/sockaddr/vendor/vendor.json" listed in Files-Excluded header
On 29/12/17 16:28, Chris Lamb wrote: > golang-github-hashicorp-go-sockaddr lists "cmd/sockaddr/vendor/*" in the > Files-Excluded field > in debian/copyright but the source tree contains > cmd/sockaddr/vendor/vendor.json. > > This might be a DFSG violation, the referenced files are probably not > attributed in debian/copyright or the upstream tarball was simply not > repacked as intended. Alternatively, the field is simply out of date. The vendor.json is an autogenerated file that keeps versions (commit hashes and dates) of every vendored dependency. 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)
Bug#884542: [pkg-go] Bug#884542: prometheus-mysqld-exporter FTBFS: FAIL: TestScrapeInnodbMetrics
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 an upstream bug: https://github.com/prometheus/mysqld_exporter/issues/251 On 16/12/17 12:03, Adrian Bunk wrote: > Source: prometheus-mysqld-exporter > Version: 0.9.0+ds-3 > Severity: serious > Tags: buster sid > > Some recent change in unstable makes prometheus-mysqld-exporter FTBFS: > > https://tests.reproducible-builds.org/debian/history/prometheus-mysqld-exporter.html > https://tests.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)
Bug#880314: [pkg-go] Bug#880314: golang-github-hashicorp-serf: FTBFS: build-dependency not installable: golang-github-hashicorp-memberlist-dev (>= 0.1.0~)
Somebody RM'd that dependency by mistake, and the package is now waiting in NEW to re-enter debian. On 30/10/17 17:11, Lucas Nussbaum wrote: > Source: golang-github-hashicorp-serf > Version: 0.8.1+git20171021.c20a0b1~ds1-2 > Severity: serious > Tags: buster sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20171030 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): >> +--+ >> | Install package build dependencies >> | >> +--+ >> >> >> Setup apt archive >> - >> >> Merged Build-Depends: debhelper (>= 9), dh-golang, golang-any (>= 2:1.8~), >> golang-github-armon-circbuf-dev, golang-github-armon-go-metrics-dev, >> golang-github-hashicorp-go-msgpack-dev, >> golang-github-hashicorp-go-syslog-dev, golang-github-hashicorp-logutils-dev, >> golang-github-hashicorp-mdns-dev, golang-github-hashicorp-memberlist-dev (>= >> 0.1.0~), golang-github-mitchellh-cli-dev, >> golang-github-mitchellh-mapstructure-dev, >> golang-github-ryanuber-columnize-dev >> Filtered Build-Depends: debhelper (>= 9), dh-golang, golang-any (>= 2:1.8~), >> golang-github-armon-circbuf-dev, golang-github-armon-go-metrics-dev, >> golang-github-hashicorp-go-msgpack-dev, >> golang-github-hashicorp-go-syslog-dev, golang-github-hashicorp-logutils-dev, >> golang-github-hashicorp-mdns-dev, golang-github-hashicorp-memberlist-dev (>= >> 0.1.0~), golang-github-mitchellh-cli-dev, >> golang-github-mitchellh-mapstructure-dev, >> golang-github-ryanuber-columnize-dev >> dpkg-deb: building package >> 'sbuild-build-depends-golang-github-hashicorp-serf-dummy' in >> '/<>/resolver-SRqRlY/apt_archive/sbuild-build-depends-golang-github-hashicorp-serf-dummy.deb'. >> dpkg-scanpackages: warning: Packages in archive but missing from override >> file: >> dpkg-scanpackages: warning: sbuild-build-depends-core-dummy >> sbuild-build-depends-golang-github-hashicorp-serf-dummy >> dpkg-scanpackages: info: Wrote 2 entries to output Packages file. >> Ign:1 copy:/<>/resolver-SRqRlY/apt_archive ./ InRelease >> Get:2 copy:/<>/resolver-SRqRlY/apt_archive ./ Release [963 B] >> Ign:3 copy:/<>/resolver-SRqRlY/apt_archive ./ Release.gpg >> Get:4 copy:/<>/resolver-SRqRlY/apt_archive ./ Sources [632 B] >> Get:5 copy:/<>/resolver-SRqRlY/apt_archive ./ Packages [715 B] >> Fetched 2310 B in 0s (0 B/s) >> Reading package lists... >> Reading package lists... >> >> Install golang-github-hashicorp-serf build dependencies (apt-based resolver) >> >> >> Installing build dependencies >> Reading package lists... >> Building dependency tree... >> Reading state information... >> Some packages could not be installed. This may mean that you have >> requested an impossible situation or if you are using the unstable >> distribution that some required packages have not yet been created >> or been moved out of Incoming. >> The following information may help to resolve the situation: >> >> The following packages have unmet dependencies: >> sbuild-build-depends-golang-github-hashicorp-serf-dummy : Depends: >> golang-github-hashicorp-memberlist-dev (>= 0.1.0~) but it is not going to be >> installed >> E: Unable to correct problems, you have held broken packages. >> apt-get failed. > > The full build log is available from: > > http://aws-logs.debian.net/2017/10/30/golang-github-hashicorp-serf_0.8.1+git20171021.c20a0b1~ds1-2_unstable.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)
Bug#877541: [pkg-go] Bug#877541: prometheus FTBFS on i386: FAIL github.com/prometheus/prometheus/storage/local [build failed]
Upstream has already provided a patch, and I can confirm it solves the
issue:
diff --git a/src/cmd/compile/internal/x86/387.go
b/src/cmd/compile/internal/x86/387.go
index cdac000..7a36224 100644
--- a/src/cmd/compile/internal/x86/387.go
+++ b/src/cmd/compile/internal/x86/387.go
@@ -46,6 +46,9 @@
case ssa.Op386MOVSSloadidx1, ssa.Op386MOVSDloadidx1:
p.From.Scale = 1
p.From.Index = v.Args[1].Reg()
+ if p.From.Index == x86.REG_SP {
+ p.From.Reg, p.From.Index = p.From.Index,
p.From.Reg
+ }
case ssa.Op386MOVSSloadidx4:
p.From.Scale = 4
p.From.Index = v.Args[1].Reg()
@@ -95,6 +98,9 @@
case ssa.Op386MOVSSstoreidx1, ssa.Op386MOVSDstoreidx1:
p.To.Scale = 1
p.To.Index = v.Args[1].Reg()
+ if p.To.Index == x86.REG_SP {
+ p.To.Reg, p.To.Index = p.To.Index, p.To.Reg
+ }
case ssa.Op386MOVSSstoreidx4:
p.To.Scale = 4
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)
Bug#877541: [pkg-go] Bug#877541: prometheus FTBFS on i386: FAIL github.com/prometheus/prometheus/storage/local [build failed]
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)
Bug#877541: [pkg-go] Bug#877541: prometheus FTBFS on i386: FAIL github.com/prometheus/prometheus/storage/local [build failed]
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/storage/local # github.com/prometheus/prometheus/storage/local build/src/github.com/prometheus/prometheus/storage/local/storage_test.go:2028:26: invalid instruction: 01483 (/tmp/buildd/prometheus-1.8.1+ds/build/src/github.com/prometheus/prometheus/storage/local/storage_test.go:2029) FMOVD ""..autotmp_78+176(DX)(SP*1), F0 $
Bug#877541: [pkg-go] Bug#877541: prometheus FTBFS on i386: FAIL github.com/prometheus/prometheus/storage/local [build failed]
reassign 877541 golang-1.9
retitle 877541 golang-1.9: Invalid instruction error in i386
thanks
This seems to be an issue with go 1.9, this error is not reproducible
with other versions of go:
$ /usr/lib/go-1.7/bin/go test -c -v
github.com/prometheus/prometheus/storage/local
$ /usr/lib/go-1.8/bin/go test -c -v
github.com/prometheus/prometheus/storage/local
$ /usr/lib/go-1.9/bin/go test -c -v
github.com/prometheus/prometheus/storage/local
# github.com/prometheus/prometheus/storage/local
build/src/github.com/prometheus/prometheus/storage/local/storage_test.go:2028:26:
invalid instruction: 01483
(/tmp/buildd/prometheus-1.8.1+ds/build/src/github.com/prometheus/prometheus/storage/local/storage_test.go:2029)
FMOVD ""..autotmp_78+176(DX)(SP*1), F0
I can't find any reference listing this instruction as valid i386, but
maybe I am not looking correctly.
It is the same issue as #877319. Also, I don't see anything weird in the
code (it faults at the for):
got := it.RangeValues(metric.Interval{OldestInclusive: 0,
NewestInclusive: 3})
// Note that we cannot just reflect.DeepEqual(want, got) because
it has
// the semantics of NaN != NaN.
for i, gotSamplePair := range got {
wantSamplePair := want[i]
if !wantSamplePair.Equal() {
t.Fatalf("want %v, got %v", wantSamplePair,
gotSamplePair)
}
}
On 02/10/17 13:45, Adrian Bunk wrote:
> Source: prometheus
> Version: 1.7.2+ds-1
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=prometheus=i386=1.7.2%2Bds-1=1506959630=0
>
> ...
> FAIL github.com/prometheus/prometheus/storage/local [build failed]
> ...
> dh_auto_test: cd build && go test -v -p 4 -timeout 20m
> github.com/prometheus/prometheus/cmd/prometheus
> github.com/prometheus/prometheus/cmd/promtool
> github.com/prometheus/prometheus/config
> github.com/prometheus/prometheus/discovery
> github.com/prometheus/prometheus/discovery/azure
> github.com/prometheus/prometheus/discovery/consul
> github.com/prometheus/prometheus/discovery/dns
> github.com/prometheus/prometheus/discovery/ec2
> github.com/prometheus/prometheus/discovery/file
> github.com/prometheus/prometheus/discovery/gce
> github.com/prometheus/prometheus/discovery/marathon
> github.com/prometheus/prometheus/discovery/openstack
> github.com/prometheus/prometheus/discovery/triton
> github.com/prometheus/prometheus/discovery/zookeeper
> github.com/prometheus/prometheus/notifier
> github.com/prometheus/prometheus/promql
> github.com/prometheus/prometheus/relabel
> github.com/prometheus/prometheus/retrieval
> github.com/prometheus/prometheus/rules
> github.com/prometheus/prometheus/storage github.com/prometheus/pr
> ometheus/storage/fanin github.com/prometheus/prometheus/storage/local
> github.com/prometheus/prometheus/storage/local/chunk
> github.com/prometheus/prometheus/storage/local/codable
> github.com/prometheus/prometheus/storage/local/index
> github.com/prometheus/prometheus/storage/local/storagetool
> github.com/prometheus/prometheus/storage/metric
> github.com/prometheus/prometheus/storage/remote
> github.com/prometheus/prometheus/template
> github.com/prometheus/prometheus/util/cli
> github.com/prometheus/prometheus/util/flock
> github.com/prometheus/prometheus/util/httputil
> github.com/prometheus/prometheus/util/promlint
> github.com/prometheus/prometheus/util/stats
> github.com/prometheus/prometheus/util/strutil
> github.com/prometheus/prometheus/util/testutil
> github.com/prometheus/prometheus/util/treecache
> github.com/prometheus/prometheus/web
> github.com/prometheus/prometheus/web/api/v1
> 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)
Bug#855124: raising severity
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 Ferrari wrote:
> 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)
Bug#855124: raising severity
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)
Bug#876697: [pkg-go] Bug#876697: golang-github-golang-mock FTBFS on mips: test failure
Adrian, On 25/09/17 01:22, Adrian Bunk wrote: > go build github.com/golang/mock/gomock_test: /usr/bin/mips-linux-gnu-gccgo-7: > waitid: bad address It seems that this issue is affecting all packages that use waitid in mips, and that the problem is either in the kernel or in gccgo (but 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)
Bug#832834: [pkg-go] Bug#832834: golang-github-boltdb-bolt: FTBFS: Tests failures
On 22/09/17 16:55, Santiago Vila wrote: > Hmm. Why would a test suite have to test the disk speed at all? > > A test suite in a program is supposed to test the program, > not the underlying hardware. > > IMHO; I don't think such kind of tests are really useful. > I would 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 reasons. -- Martín Ferrari (Tincho)
Bug#874048: catdoc 1:0.95-3 fails to extract text from certain documents
Robert, On 04/09/17 06:16, Robert Zavalczki wrote: > I think that the problem is that "nLen" is in bytes, but OLENAMELENGTH > is in UCS-2 characters. When processing the LibreOffice document an OLE > stream having the name "SummaryInformation\0" is encountered. The name > 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)
Bug#874499: ITP: golang-github-google-go-cmp -- Package for comparing Go values in tests
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 Lang: Go Description : Package for comparing Go values in tests This package is intended to be a more powerful and safer alternative to reflect.DeepEqual for comparing whether two values are semantically equal. . The primary features of cmp are: * When the default behavior of equality does not suit the needs of the test, custom equality functions can override the equality operation. For example, an equality function may report floats as equal so long as they are within some tolerance of each other. * Types that have an Equal method may use that method to determine equality. This allows package authors to determine the equality operation for the types that they define. * If no custom equality functions are used and no Equal method is defined, equality is determined by recursively comparing the primitive kinds on both values, much like reflect.DeepEqual. Unlike reflect.DeepEqual, unexported fields are not compared by default; they result in panics unless suppressed by using an Ignore option (see cmpopts.IgnoreUnexported) or explictly compared using the AllowUnexported option. . See the GoDoc documentation (https://godoc.org/github.com/google/go-cmp/cmp) for more information.
Bug#874048: catdoc 1:0.95-3 fails to extract text from certain documents
Hi Robert,
On 02/09/17 12:50, Robert Zavalczki wrote:
> Package: catdoc
> Version: 1:0.95-3
> Tags: patch
>
> Create a simple document in LibreOffice Writer 5.2.7.2 containing a single
> line: "Hello world!" and save it using the "Microsoft Word 97-2003 (.doc)"
> format. Run "catdoc" on the created document. The output is empty.
>
> Details: this bug was introduced in version 1:0.95 and is not reproducible
> with previous versions of catdoc. Applying the attached patch to the source
> code in version 0.95 (catdoc_0.95.orig.tar.gz) seems to fix the issue.
Thanks for the report, but I am not sure I understand this. The current
code in ole.c reads already like your proposed patch:
if (nLen > OLENAMELENGTH) {
free(e);
return NULL;
}
Although I can reproduce the issue you mention, so there is definitely a
bug. Sadly, catdoc's code is not the easiest to follow :/
--
Martín Ferrari (Tincho)
Bug#854687: [pkg-go] Bug#854687: Bug#854687: Bug#854687: golang-github-prometheus-client-golang: FTBFS randomly (failing tests)
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 close :) Actually, upstream says it is a known issue, and that it is disabled under -short for this reason. So I will just disable the test. -- Martín Ferrari (Tincho)
Bug#872402: [pkg-go] Bug#872402: golang-golang-x-tools-dev: Does not work on mips*
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 arches, so the relevant tests are not >> executed.. Maybe we should make it arch:any...? > I think the CI like ci.d.n should run on more archs instead... Yeah, that'd be ideal :) > ok, so I read the issue on https://github.com/golang/go/issues/18031 > > I don't have mips env to verify comments by foka. But what foka said > in that issue is, > gccgo reports mipsel and mips both as `mipso32`. So we need pass > another `-tags` to distinguish the two archs. > Unless gccgo has corrent build tip, we can only manually add `-tags > mips` or `-tags mipsel`. I have just tested that, with eller for mips(64)el and minkus for mips. And sadly, that is true: eller (mipsel): $ go env GOARCH="mipso32" eller (mips64el): $ go env GOARCH="mipsn64" minkus (mips): $ go env GOARCH="mipso32" The bug referenced above says this might be already fixed in gccgo, and looking at the commit history, it does seem to be true: https://go.googlesource.com/gofrontend/+/3f713ddb2a9a2a736f3a12d71c56cb7fd444afba%5E%21/ This harmonizes the arch names with gc, and as a side effect, fixes the missing little-endian marker. The problem is that gcc and friends make my head hurt, and I don't really understand if this made it into the 7.2 release or not. Seeing that eller has libgo 7.2, I assume it did not.. Does anybody understand all this? > BTW, let me down grade this bug's severity first since I think we have > workaround for that :) OK. -- Martín Ferrari (Tincho)
Bug#873514: golang-google-cloud: FTBFS due to changes in dependency
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 not sure about the effect on other rdeps like kubernetes, docker, and cadvisor. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#873458: lintian: Please add autopkgtest-pkg-elpa as a valid value for Testsuite
On 28/08/17 11:07, Chris Lamb wrote:
>> Can you add pkg-go to the list of valid testsuites?
>
> This was fixed by Niels in:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=2a279596289a9e7b4f31fc5aba48f2c6c9a18ebc
>
> I've added the sole remaining 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)
Bug#873458: lintian: Please add autopkgtest-pkg-go as valid value for Testsuite
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 other automatic test suites, so those should be added too: dkms elpa go nodejs perl python r ruby Thanks. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils 2.29-7 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.18.24 ii file 1:5.31-1 ii gettext 0.19.8.1-4 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.33 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2+b2 ii libdpkg-perl 1.18.24 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.96-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.26 [libdigest-sha-perl] 5.26.0-5 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.72-1 ii libxml-simple-perl2.24-1 ii libyaml-libyaml-perl 0.63-2+b2 ii man-db2.7.6.1-2 ii patchutils0.3.4-2 ii perl 5.26.0-5 ii t1utils 1.40-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.24 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.46-1 -- no debconf information
Bug#873338: [PATCH] build: backup existing binaries before installing
Hi, On 26/08/17 20:28, David Michael wrote: > A parallel "make install" invocation can sometimes install programs > first, then backup those programs as *.old files. This randomly > caused duplicate programs to be installed. > > This change will only run the backup 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)
Bug#872402: golang-golang-x-tools-dev: Does not work on mips*
On 24/08/17 16:31, Shengjing Zhu wrote: > Hi Martín, > So what's the prolem of this x/sys? I didn't see this package has > disabled tests. Yes, sorry, I was confused with x/tools, which has disabled tests. This one does not get built in other arches, so the relevant tests are not executed.. Maybe we should make it arch:any...? > Which package ftbfs because of x/sys? Prometheus and friends were failing. I understood now what you are doing here (it took me a while), and by passing tags I managed to get them building again, but that's not a reasonable solution.. The packages 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)
Bug#861551: Patch for grafana FTBFS
type 'IPromise>'.
Types of property 'then' are incompatible.
Type '(successCallback: (response:
IHttpPromiseCallbackArg) => TResult | IPromise<TRe...' is not
assignable to type '(successCallback: (promiseValue: void |
TResult | IHttpPromiseCallbackArg) => I...'.
Types of parameters 'successCallback' and
'successCallback' are incompatible.
Type 'IPromise | TResult |
IHttpPromise | IPromise' is not assignable to type
'void | TResult | IHttpPromiseCallbackArg | IPromise' is not
assignable to type 'void | TResult | IHttpPromiseCallbackArg |
IPromise' is not
assignable to type 'IPromise>'.
Types of property 'then' are
incompatible.
Type '(successCallback:
(response: IHttpPromiseCallbackArg) => TResult |
IPromise<TRe...' is not assignable to type '(successCallback:
(promiseValue: void | TResult | IHttpPromiseCallbackArg) => I...'.
Type 'IPromise>' is not assignable to type
'IPromise'.
Type 'void | TResult |
IHttpPromiseCallbackArg' is not assignable to type 'TResult'.
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/setting"
_ "github.com/go-sql-driver/mysql"
+ "github.com/go-xorm/core"
"github.com/go-xorm/xorm"
_ "github.com/lib/pq"
_ "github.com/mattn/go-sqlite3"
@@ -93,15 +94,13 @@
if err != nil {
return fmt.Errorf("sqlstore.init(fail to create xorm.log): %v", err)
}
- x.Logger = xorm.NewSimpleLogger(f)
+ logger := xorm.NewSimpleLogger(f)
if setting.Env == setting.DEV {
- x.ShowSQL = false
- x.ShowInfo = false
- x.ShowDebug = false
- x.ShowErr = true
- x.ShowWarn = true
+ x.ShowSQL(false)
+ logger.SetLevel(core.LOG_WARNING)
}
+ x.SetLogger(logger)
}
return nil
Bug#872402: golang-golang-x-tools-dev: Does not work on mips*
reassign 872402 golang-golang-x-sys thanks > 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 making other packages FTBFS. > I am being stupid and mixing x/tools with x/sys. Sorry about the noise. -- Martín Ferrari (Tincho)
Bug#872402: golang-golang-x-tools-dev: Does not work on mips*
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 making other packages FTBFS. This bug tries to point to the correct culprit. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#870843: [pkg-go] Bug#870843: golang-github-armon-go-metrics-dev: unhandled symlink to directory conversion: /usr/share/gocode/src/github.com/sirupsen/logrus -> ../Sirupsen/logrus
reassign 870843 golang-github-sirupsen-logrus-dev thanks This bug is filed under the wrong package.
