Bug#1082559: libimage-exiftool-perl: please update to latest upstream version
Package: libimage-exiftool-perl Version: 12.57+dfsg-1 Severity: normal X-Debbugs-Cc: fili...@debian.org Dear Maintainer, I'd like to request a newer upstream version of libimage-exiftool-perl to be packaged, e.g. 12.96 from Sept 1st thank you, Filippo -- System Information: Debian Release: 12.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.9.7+bpo-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libimage-exiftool-perl depends on: ii perl 5.36.0-7+deb12u1 Versions of packages libimage-exiftool-perl recommends: ii libarchive-zip-perl1.68-1 pn libunicode-linebreak-perl Versions of packages libimage-exiftool-perl suggests: pn libposix-strptime-perl -- no debconf information
Bug#1025012: zookeeper: starts but is completely unusable
found 3.8.0-11+deb12u1 thanks On Tue, Dec 06, 2022 at 11:33:07PM +0100, Christoph Anton Mitterer wrote: [...] > > Because of the last paragraph in the > > relevant section therein, I was unsure I should choose a SLF4J > > binding > > as this would impose my choice to the end user. What do you think? > > Well since that two infamous security holes, log4j has a somewhat > damaged reputation ;-) ... but apart from that I think this would make > the most sense here. > > As I've said in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025012#20 : > > /usr/share/java/slf4j-log4j12.jar wasn't enough for me and I needed to > add /usr/share/java/log4j-1.2.jar to the CLASSPATH instead, in order to > get output to /var/log/zookeeper I ran into the same issue (i.e. missing zookeeper logs) on Bookworm. Reproducible with the following: * apt install zookeeperd * systemctl start zookeeper * observe no logs written to /var/log/zookeeper as the default zk conf would like to do The fix for me was indeed to add log4j and its slf4j backend jars to CLASSPATH in /etc/zookeeper/conf/environment HTH, Filippo
Bug#1067768: libsmi2ldbl: read mibs from /var/lib/mibs as well
Package: libsmi2ldbl Version: 0.4.8+dfsg2-16 Severity: normal X-Debbugs-Cc: fili...@debian.org snmp-mibs-downloader 1.5 has updated its download location to /var/lib/mibs, and /etc/smi.conf should be updated to reflect this fact, i.e. append path :/var/lib/mibs/site -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsmi2ldbl depends on: ii libc6 2.36-9+deb12u4 libsmi2ldbl recommends no packages. Versions of packages libsmi2ldbl suggests: pn snmp-mibs-downloader -- no debconf information
Bug#1040954: Info received (Bug#1040954: Acknowledgement (inspircd: PID and Logging have broken permissions))
Hello Victor, my apologies for the late reply and thank you for the extensive bug report and research! On Tue, Jul 18, 2023 at 08:52:38PM -0400, Victor Coss wrote: > Hello, I have another update to provide. I was able to temporarily fix file > logging until you can fix the package. I had to create a logs folder in > /usr/lib/inspircd/ and change it's permissions accordingly and change > ownership and group to irc:irc with read and write permissions so InspIRCd > can write various log files in that directory. As stated before the correct > location should be /var/log/inspircd/ for log files instead. You may need to > have the package create this directory on install and give the proper > permissions for the irc user to read and write to it. I have uploaded 3.17.0-1 just now, and allowed apparmor access to /var/log/inspircd.log as a short term fix for this issue. I'm happy to switch to /var/log/inspircd for the default log location as a followup though. > Also as a side note so you are aware, any segfaults you see in dmesg, are > not actually segmentation faults; this is caused by InspIRCd not using > standard exit codes. This can be fixed in v3 of InspIRCd by adding > -DINSPIRCD_BINARY_EXIT to CXXFLAGS in the environment to disable the custom > exit codes that InspIRCd uses. In v4 (not released yet) this has been > resolved completely and InspIRCd will use standard exit codes. Thank you for this report too, I was not aware! best, Filippo
Bug#995192: carbon-c-relay: the current stable contains a _recalled_ version, hogs CPU
On Mon, Sep 27, 2021 at 08:34 PM, grin wrote: > I strongly suggest to update stable somehow, since this makes the package > pretty dangerous: > it may kill a perfectly close-to-idle system by pushing it to 100% CPU on > multiple threads > after a simple upgrade. I've run into this as well and I agree. I think this bugfix is reasonable for inclusion in 11.2.
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
On Fri, Sep 10, 2021 at 09:50:42PM +0200, Thomas Goirand wrote: > On 9/10/21 11:40 AM, Filippo Giunchedi wrote: > > On Thu, Sep 09, 2021 at 09:32:34AM +0200, Thomas Goirand wrote: > >> Hi, > >> > >> Thanks a lot for working on this, it really is helpful. > >> > >> The pull request you're pointing at contains multiple commits. Would you > >> be able to transform this into a patch against the Eventlet versions > >> 0.26.1 (currently in Stable) and 0.30.2 (in Unstable and Testing)? If > >> you provide it, then I'll be very happy to add the patches to these > >> Debian packages. If I'm asking it's not because I don't want to do it > >> myself, but because you wrote it, you may be better at understanding how > >> to backport the patches. > > > > Certainly, I did port the patch to our internal repo for Bullseye. You can > > find > > the commit below, which modulo the changelog version obviously should work > > as-is. > > > > https://github.com/wikimedia/operations-debs-python-eventlet/commit/a93d2e0cd2cdf3efcd7915cb781355d58e5728ab > > > > I didn't change > > 'Replace-dnspython-_compute_expiration-by-_compute_times.patch' > > for a cleaner diff, although that patch a whole I think can be replaced with > > the PR's diff. What do you think? > > > > best, > > Filippo > > > > Hi, > > I'll try to get this in Bullseye proper. Thanks a lot for your work, > this is definitively very helpful, and may solve troubles with swift's > cname middleware also. You are welcome, and thank you for pushing to get the update in Bullseye > > I'm not sure about > Replace-dnspython-_compute_expiration-by-_compute_times.patch, though > it's probably better, from the Debian Stable perspective, to not touch > the patches that are already there, so it is easier for the Stable > release team to review it. Agreed > I will also need a patch against the version 0.30.2-2 currently in > unstable/bookworms (again: otherwise the Debian Stable release team may > complain about it). Could you provide one? For sure, I have added the patches in this MR. Let me know what you think! https://salsa.debian.org/python-team/packages/python-eventlet/-/merge_requests/2 best, Filippo
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
On Thu, Sep 09, 2021 at 09:32:34AM +0200, Thomas Goirand wrote: > Hi, > > Thanks a lot for working on this, it really is helpful. > > The pull request you're pointing at contains multiple commits. Would you > be able to transform this into a patch against the Eventlet versions > 0.26.1 (currently in Stable) and 0.30.2 (in Unstable and Testing)? If > you provide it, then I'll be very happy to add the patches to these > Debian packages. If I'm asking it's not because I don't want to do it > myself, but because you wrote it, you may be better at understanding how > to backport the patches. Certainly, I did port the patch to our internal repo for Bullseye. You can find the commit below, which modulo the changelog version obviously should work as-is. https://github.com/wikimedia/operations-debs-python-eventlet/commit/a93d2e0cd2cdf3efcd7915cb781355d58e5728ab I didn't change 'Replace-dnspython-_compute_expiration-by-_compute_times.patch' for a cleaner diff, although that patch a whole I think can be replaced with the PR's diff. What do you think? best, Filippo
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
On Tue, Aug 24, 2021 at 02:32 PM, Filippo Giunchedi wrote: > I was able to get python3-eventlet to play nice with dnspython2 by > integrating https://github.com/eventlet/eventlet/pull/722 from upstream. Upstream has merged the PR, please consider updating the patch in the package. Possibily for a point release too? best, Filippo
Bug#993385: prometheus-bind-exporter: fails to parse XML stats from bind 9.16.15
Package: prometheus-bind-exporter Version: 0.4.0+ds-1+b5 Severity: important I'm running into a problem where bind-exporter fails to parse XML from bind: prometheus-bind-exporter[1146]: level=error ts=2021-08-31T15:40:01.126Z caller=bind_exporter.go:427 msg="Couldn't retrieve BIND stats" err="failed to unmarshal XML response: strconv.ParseUi nt: parsing \"-\": invalid syntax" Upstream has an issue for this, and a patch: * https://github.com/prometheus-community/bind_exporter/issues/96 * https://github.com/prometheus-community/bind_exporter/pull/97 -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-bind-exporter depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libc62.31-13 prometheus-bind-exporter recommends no packages. prometheus-bind-exporter suggests no packages.
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
On Tue, Aug 24, 2021 at 09:52 AM, Filippo Giunchedi wrote: > On Tue, Jun 08, 2021 at 10:03 AM, Filippo Giunchedi wrote: > > Package: swift-container > > Version: 2.26.0-10 > > Severity: important > > File: /usr/bin/swift-container-reconciler > > > > Dear Maintainer, > > I'm experimenting with Swift on Bullseye and came across a problem with > > container-reconciler (possibly others) when using hostnames in > > memcache_servers. Namely these errors: > > In the "possibly others" category, swift-dispersion-report is also 100% > broken in Bullseye: I was able to get python3-eventlet to play nice with dnspython2 by integrating https://github.com/eventlet/eventlet/pull/722 from upstream. See debdiff attached for the result against Bullseye's python-eventlet diff -Nru python-eventlet-0.26.1/debian/changelog python-eventlet-0.26.1/debian/changelog --- python-eventlet-0.26.1/debian/changelog 2021-05-11 08:03:43.0 +0200 +++ python-eventlet-0.26.1/debian/changelog 2021-08-24 14:04:54.0 +0200 @@ -1,3 +1,10 @@ +python-eventlet (0.26.1-8~wmf1) bullseye; urgency=medium + + * Fix dnspython 2 compat + ** See also https://github.com/eventlet/eventlet/pull/722 + + -- Filippo Giunchedi Tue, 24 Aug 2021 14:04:54 +0200 + python-eventlet (0.26.1-7) unstable; urgency=medium * CVE-2021-21419: Malicious peer may exhaust memory on Eventlet side diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py python-eventlet-0.26.1/debian/greendns.orig.py --- python-eventlet-0.26.1/debian/greendns.orig.py 2021-05-11 08:03:43.0 +0200 +++ python-eventlet-0.26.1/debian/greendns.orig.py 2021-08-24 14:04:54.0 +0200 @@ -120,12 +120,13 @@ return is_ipv4_addr(host) or is_ipv6_addr(host) -def compute_expiration(query, timeout): -# NOTE(ralonsoh): in dnspython v2.0.0, "_compute_expiration" was replaced -# by "_compute_times". -if hasattr(query, '_compute_expiration'): +# NOTE(ralonsoh): in dnspython v2.0.0, "_compute_expiration" was replaced +# by "_compute_times". +if hasattr(dns.query, '_compute_expiration'): +def compute_expiration(query, timeout): return query._compute_expiration(timeout) -else: +else: +def compute_expiration(query, timeout): return query._compute_times(timeout)[1] @@ -669,8 +670,21 @@ raise dns.exception.Timeout +# Test if raise_on_truncation is an argument we should handle. +# It was newly added in dnspython 2.0 +try: +dns.message.from_wire("", raise_on_truncation=True) +except dns.message.ShortHeader: +_handle_raise_on_truncation = True +except TypeError: +# Argument error, there is no argument "raise_on_truncation" +_handle_raise_on_truncation = False + + def udp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53, -af=None, source=None, source_port=0, ignore_unexpected=False): +af=None, source=None, source_port=0, ignore_unexpected=False, +one_rr_per_rrset=False, ignore_trailing=False, +raise_on_truncation=False, sock=None): """coro friendly replacement for dns.query.udp Return the response obtained after sending a query via UDP. @@ -695,7 +709,21 @@ @type source_port: int @param ignore_unexpected: If True, ignore responses from unexpected sources. The default is False. -@type ignore_unexpected: bool""" +@type ignore_unexpected: bool +@param one_rr_per_rrset: If True, put each RR into its own +RRset. +@type one_rr_per_rrset: bool +@param ignore_trailing: If True, ignore trailing +junk at end of the received message. +@type ignore_trailing: bool +@param raise_on_truncation: If True, raise an exception if +the TC bit is set. +@type raise_on_truncation: bool +@param sock: the socket to use for the +query. If None, the default, a socket is created. Note that +if a socket is provided, it must be a nonblocking datagram socket, +and the source and source_port are ignored. +@type sock: socket.socket | None""" wire = q.to_wire() if af is None: @@ -717,7 +745,10 @@ if source is not None: source = (source, source_port, 0, 0) -s = socket.socket(af, socket.SOCK_DGRAM) +if sock: +s = sock +else: +s = socket.socket(af, socket.SOCK_DGRAM) s.settimeout(timeout) try: expiration = compute_expiration(dns.query, timeout) @@ -765,14 +796,23 @@ finally: s.close() -r = dns.message.from_wire(wire, keyring=q.keyring, request_mac=q.mac) +if _handle_raise_on_truncation: +r = dns.message.from_wire(wire, keyring=q.keyring, request_mac=q.mac, + one_rr_per_rrset=one_rr_per_rrset, +
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
On Tue, Jun 08, 2021 at 10:03 AM, Filippo Giunchedi wrote: > Package: swift-container > Version: 2.26.0-10 > Severity: important > File: /usr/bin/swift-container-reconciler > > Dear Maintainer, > I'm experimenting with Swift on Bullseye and came across a problem with > container-reconciler (possibly others) when using hostnames in > memcache_servers. Namely these errors: In the "possibly others" category, swift-dispersion-report is also 100% broken in Bullseye: $ swift-dispersion-report --dump-json swift-dispersion-report --dump-json -d Traceback (most recent call last): File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 435, in resolve return _proxy.query(name, rdtype, raise_on_no_answer=raises, File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 391, in query return end() File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 370, in end raise result[1] File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 351, in step a = fun(*args, **kwargs) File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1089, in query return self.resolve(qname, rdtype, rdclass, tcp, source, File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1043, in resolve timeout = self._compute_timeout(start, lifetime) File "/usr/lib/python3/dist-packages/dns/resolver.py", line 950, in _compute_timeout raise Timeout(timeout=duration) dns.exception.Timeout: The DNS operation timed out after 5.1069724559783936 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.9/urllib/request.py", line 1346, in do_open h.request(req.get_method(), req.selector, req.data, headers, File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1310, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1380, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1301, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1089, in _send_output self.send(msg) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1018, in send self.connect() File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1481, in connect super().connect() File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 989, in connect self.sock = self._create_connection( File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 44, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 528, in getaddrinfo qname, addrs = _getaddrinfo_lookup(host, family, flags) File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 501, in _getaddrinfo_lookup raise err File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 490, in _getaddrinfo_lookup answer = resolve(host, qfamily, False, use_network=use_network) File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 443, in resolve raise EAI_EAGAIN_ERROR File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 490, in _getaddrinfo_lookup answer = resolve(host, qfamily, False, use_network=use_network) File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 443, in resolve raise EAI_EAGAIN_ERROR File "/usr/lib/python3.9/urllib/request.py", line 1346, in do_open h.request(req.get_method(), req.selector, req.data, headers, File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1310, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1380, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1301, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1089, in _send_output self.send(msg) File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 1018, in send self.connect() File "/usr/lib/python3/dist-packages/eventlet/green/http/c
Bug#971530: dnspython 2.x breaks all of OpenStack
On Tue, Jun 01, 2021 at 10:30:38AM +, Filippo Giunchedi wrote: > Hello, > > On Thu, May 27, 2021 at 04:10:32PM +0200, Thomas Goirand wrote: > > Hi, > > > > Well, Eventlet itself works. DNSPython itself works too. Just the 2 > > together (ie: resolving with eventlet greedns) doesn't work. This > > doesn't make any of the packages completely broken and unuseable (so > > it's not RC), this is just a bug that should be fixed. > > I disagree in the sense that I don't think the package(s) currently are fit > for > release, but it isn't my call either. > > > FYI, since some fixes in Eventlet, OpenStack now works... Though the > > Eventlet greendns API shall still be fixed. > > Do you have pointers to these fixes I could look at? I ran into this bug while > testing Swift on Bullseye, specifically container-reconciler + > memcache_servers > with hostnames doesn't seem to work for me (while using ip addresses does > work). For the record I haven't seen the eventlet greendns fixes you mentioned, and swift-dispersion-report is also broken in Bullseye due to this bug (cfr #989600)
Bug#971530: dnspython 2.x breaks all of OpenStack
On Tue, Jun 01, 2021 at 10:30:38AM +, Filippo Giunchedi wrote: > Do you have pointers to these fixes I could look at? I ran into this bug while > testing Swift on Bullseye, specifically container-reconciler + > memcache_servers > with hostnames doesn't seem to work for me (while using ip addresses does > work). FTR the specific bug for swift is now #989600
Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames
Package: swift-container Version: 2.26.0-10 Severity: important File: /usr/bin/swift-container-reconciler Dear Maintainer, I'm experimenting with Swift on Bullseye and came across a problem with container-reconciler (possibly others) when using hostnames in memcache_servers. Namely these errors: Jun 08 09:54:08 ms-be-01 swift-container-reconciler[70736]: Timeout getting a connection to memcached: HOST1:11211: MemcachePoolTimeout (1.0s) (txn: txf2bfe46649374ed6b1a47-0060bf3e3f) Jun 08 09:54:09 ms-be-01 swift-container-reconciler[70736]: Timeout getting a connection to memcached: HOST2:11211: MemcachePoolTimeout (1.0s) (txn: txf2bfe46649374ed6b1a47-0060bf3e3f) and I have HOST1 HOST2 in container-reconciler.conf: memcache_servers = HOST1:11211,HOST2:11211 Manually testing the connection works as expected, and after some debugging it looks like using ip addresses in the configuration works, unlike using hostnames. In this case hostname resolution happens via DNS, which makes me think this is related to #971530. The bug is possibly affecting other parts of swift + memcache, though I haven't been able to find other examples in my testing so far. best, Filippo -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-cloud-amd64 (SMP w/1 CPU thread) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages swift-container depends on: ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii openstack-pkg-tools 117 ii python3 3.9.2-3 ii python3-pastescript 2.0.2-4 ii python3-swift 2.26.0-10 ii rsync 3.2.3-4 ii swift 2.26.0-10 ii uwsgi-plugin-python3 2.0.19.1-6 Versions of packages swift-container recommends: pn swift-drive-audit swift-container suggests no packages. -- Configuration Files: /etc/swift/container-reconciler.conf [Errno 13] Permission denied: '/etc/swift/container-reconciler.conf' /etc/swift/container-server.conf [Errno 13] Permission denied: '/etc/swift/container-server.conf' /etc/swift/internal-client.conf [Errno 13] Permission denied: '/etc/swift/internal-client.conf' /etc/swift/swift-container-server-uwsgi.ini [Errno 13] Permission denied: '/etc/swift/swift-container-server-uwsgi.ini' -- no debconf information
Bug#971530: dnspython 2.x breaks all of OpenStack
Hello, On Thu, May 27, 2021 at 04:10:32PM +0200, Thomas Goirand wrote: > Hi, > > Well, Eventlet itself works. DNSPython itself works too. Just the 2 > together (ie: resolving with eventlet greedns) doesn't work. This > doesn't make any of the packages completely broken and unuseable (so > it's not RC), this is just a bug that should be fixed. I disagree in the sense that I don't think the package(s) currently are fit for release, but it isn't my call either. > FYI, since some fixes in Eventlet, OpenStack now works... Though the > Eventlet greendns API shall still be fixed. Do you have pointers to these fixes I could look at? I ran into this bug while testing Swift on Bullseye, specifically container-reconciler + memcache_servers with hostnames doesn't seem to work for me (while using ip addresses does work). best, Filippo
Bug#971530: dnspython 2.x breaks all of OpenStack
On Thu, Oct 01, 2020 at 12:15 PM, Thomas Goirand wrote: > Package: python3-dnspython > Version: 2.0.0-1 > Severity: important > > Hi, > > I'm sending this just to let you know that dnspython broke Eventlet, > which is unfortunately the base of many OpenStack stuff. As a > consequence, the websocket of Nova is broken over SSL, and many > other stuff, due to the API change in dnspython. > > I'm sending this as only severity: important, though I was considering > a higher severity. I'd like to first discuss the mater with the > maintainers of dnspython. I very much think this bug should be RC: unless I'm missing something the code below doesn't work but should: $ python3 -c 'from eventlet.green import socket ; print(socket.getaddrinfo("debian.org", 443))' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 435, in resolve return _proxy.query(name, rdtype, raise_on_no_answer=raises, File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 391, in query return end() File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 370, in end raise result[1] File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 351, in step a = fun(*args, **kwargs) File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1089, in query return self.resolve(qname, rdtype, rdclass, tcp, source, File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1043, in resolve timeout = self._compute_timeout(start, lifetime) File "/usr/lib/python3/dist-packages/dns/resolver.py", line 950, in _compute_timeout raise Timeout(timeout=duration) dns.exception.Timeout: The DNS operation timed out after 5.107415199279785 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 528, in getaddrinfo qname, addrs = _getaddrinfo_lookup(host, family, flags) File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 501, in _getaddrinfo_lookup raise err File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 490, in _getaddrinfo_lookup answer = resolve(host, qfamily, False, use_network=use_network) File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 443, in resolve raise EAI_EAGAIN_ERROR File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 490, in _getaddrinfo_lookup answer = resolve(host, qfamily, False, use_network=use_network) File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 443, in resolve raise EAI_EAGAIN_ERROR socket.gaierror: [Errno -3] Lookup timed out
Bug#985379: podman: fails to run on freshly installed Bullseye, runtime "crun" not found: invalid argument
Hello, On Sun, Apr 18, 2021 at 10:38:34AM -0400, Reinhard Tartler wrote: > Thank you for your report. I have to admit that I'm a bit confused, > according to attached > data, it seems you have both 'runc' as well as 'crun' installed. In that > case, changing > the order of the dependencies won't make a difference. > > Please confirm what packages of 'crun' and 'runc' you have installed. You are quite right, the reportbug metadata is confusing in this case! I ran reportbug on a different host (with both crun and runc installed) than the one I attached the output from. My apologies! 'host1' had indeed only 'runc' installed. > It seems that I indeed missed this commit: > https://salsa.debian.org/go-team/packages/golang-github-containers-common/-/commit/6475ef3063d4a1f50fc84b2e1ceac759f09fbeee > that changes the default from runc to crun in version > 0.30.1. Switching the dependency order to read 'crun | runc' instead of > 'runc | crun' seems appropriate, and I'll > do that in the next upload. Thank you so much! best, Filippo
Bug#985546: bind9-utils: Ship tsig-keygen with bind9-utils
Package: bind9-utils Version: 1:9.16.12-1 Severity: wishlist Hi, I'm using tsig-keygen as part of a pipeline and at the moment the utility is shipped with bind9, thus requiring a server to run/to be installed. Similarly to dnssec-keygen, I think tsig-keygen (possibly others?) binary should be shipped with bind9-utils, what do you think ? thank you ! Filippo -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (400, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9-utils depends on: ii bind9-libs 1:9.16.12-1 ii libc62.31-9 ii python3 3.9.2-2 ii python3-ply 3.11-4 bind9-utils recommends no packages. bind9-utils suggests no packages. -- no debconf information
Bug#985379: podman: fails to run on freshly installed Bullseye, runtime "crun" not found: invalid argument
Package: podman Version: 3.0.1+dfsg1-1 Severity: important This is the same as #971253. Specifically, 'runc' is installed as the first Depend, however podman defaults to 'crun'. I think podman should depend on 'crun' first so it works out of the box (and with cgroups v2). root@host1:~# podman images Error: default OCI runtime "crun" not found: invalid argument root@host1:~# ls -la /etc/containers/containers.conf ls: cannot access '/etc/containers/containers.conf': No such file or directory -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (400, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1 ii containernetworking-plugins 0.9.0-1+b2 ii crun 0.17+dfsg-1 ii golang-github-containers-common 0.33.4+ds1-1 ii init-system-helpers 1.60 ii libc62.31-9 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1 ii runc 1.0.0~rc93+ds1-2+b1 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1 ii catatonit 0.1.5-2 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b3 ii slirp4netns 1.0.1-1 ii tini 0.19.0-1 ii uidmap1:4.8.1-1 Versions of packages podman suggests: ii containers-storage 1.24.8+dfsg1-1 pn docker-compose -- no debconf information
Bug#985354: mtail: service unit fails to start on Bullseye
Package: mtail Version: 3.0.0~rc43-1+b1 Severity: important mtail.service fails to start on Bullseye due to cgroup v2 / unified hierarchy: $ systemctl status mtail ● mtail.service - MTail Loaded: loaded (/lib/systemd/system/mtail.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2021-03-16 14:32:35 CET; 1s ago Process: 2082384 ExecStart=/usr/bin/mtail --progs /etc/mtail --logtostderr --port 3903 --logs $LOGS (code=killed, signal=TERM) Process: 2082385 ExecStartPost=/bin/sh -c echo 0 > /sys/fs/cgroup/memory/system.slice/mtail.service/memory.swappiness (code=exited, status=2) Main PID: 2082384 (code=killed, signal=TERM) CPU: 49ms Indeed memory.swappiness isn't a thing anymore: $ find /sys/fs/cgroup/ -type f -iname 'memory.swappiness' $ -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (400, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mtail depends on: ii adduser 3.118 ii daemon 0.7-1 ii init-system-helpers 1.60 ii libc62.31-9 ii tzdata 2021a-1 mtail recommends no packages. mtail suggests no packages. -- no debconf information
Bug#918526: mtail: FTBFS randomly
On Sun, Jan 17, 2021 at 04:55:20PM +0100, Santiago Vila wrote: > On Sun, Jan 17, 2021 at 03:42:30PM +0000, Filippo Giunchedi wrote: > > > I've uploaded 3.0.0~rc41-1 yesterday with the flaky tests fixed, and indeed > > mtail built fine on all release architectures: > > > > https://buildd.debian.org/status/package.php?p=mtail > > > > I'm resolving the bug since I think it is fixed, of course please reopen if > > sth is amiss! > > Hi. This is still a package which FTBFS randomly in buster, the > current supported stable distribution. Would you please consider > fixing this FTBFS bug in stable, where people will still have > to deal with it? I agree that the FTBFS in buster is a problem, ATM I'm focusing more on bullseye and won't have time. Although repurposing this bug or filing a new one seems right to me! HTH, Filippo
Bug#955479: apparmor fixes for xline_db and geoip
On Wed, Apr 01, 2020 at 07:03 PM, Marc Dequènes wrote: > I added this line to the apparmor policy: > /usr/share/GeoIP/GeoIP.dat r, > > Btw the package could also Suggest geoip-database needed for this module. Thank you for the report, I'm not an apparmor expert but I'm happy to include support in the package (at https://salsa.debian.org/debian/inspircd) Suggesting 'geoip-database' is a good idea, I'll add that!
Bug#976403: mtail: racy TestReadFromPipe test in internal/mtail/read_pipe_integration_test.go
Subject: mtail: racy TestReadFromPipe test in internal/mtail/read_pipe_integration_test.go Package: mtail Version: 3.0.0~rc38-1 Severity: normal The latest upload has produced mixed results between buildd and autopkgtest failing to run TestReadFromPipe, e.g. https://buildd.debian.org/status/fetch.php?pkg=mtail&arch=armhf&ver=3.0.0%7Erc38-1&stamp=1606840174&raw=0 is a success: === RUN TestReadFromPipe === RUN TestReadFromPipe/0s_true === RUN TestReadFromPipe/10ms_false --- PASS: TestReadFromPipe (10.02s) --- PASS: TestReadFromPipe/0s_true (5.00s) --- PASS: TestReadFromPipe/10ms_false (5.01s) But for example autopkgtest amd64 failed: https://ci.debian.net/data/autopkgtest/testing/amd64/m/mtail/8626687/log.gz === RUN TestReadFromPipe === RUN TestReadFromPipe/0s_true === RUN TestReadFromPipe/10ms_false read_pipe_integration_test.go:53: Did not see "lines_total" have delta by deadline: got 0 - 0 = 0, want 3 --- FAIL: TestReadFromPipe (65.01s) --- PASS: TestReadFromPipe/0s_true (5.00s) --- FAIL: TestReadFromPipe/10ms_false (60.00s) === RUN TestTruncatedLogRead === RUN TestTruncatedLogRead/0s_true === RUN TestTruncatedLogRead/10ms_false --- PASS: TestTruncatedLogRead (0.09s) --- PASS: TestTruncatedLogRead/0s_true (0.05s) --- PASS: TestTruncatedLogRead/10ms_false (0.04s) FAIL FAIL github.com/google/mtail/internal/mtail 69.897s The internal/mtail/read_pipe_integration_test.go test file has been changed recently upstream, specifically removing the "integration" tag in f45531acd69a and refactoring the pollInterval initialization in a2353dd63. The latter commit seems to have changed the number of invocations for this test from one with 0 pollInterval and fsnotify disable to running the test twice based on LogWatcherTestTable (below) which I think is part of the culprit. +// logWatcherTestTable contains reusable inputs to NewLogWatcher under test. +var LogWatcherTestTable = []struct { + PollInterval time.Duration + EnableFsNotify bool +}{ + {0, true}, // notify only + {10 * time.Millisecond, false}, // poll only +}
Bug#939424: Debian vcs
On Thu, Nov 12, 2020 at 04:56 PM, Filippo Giunchedi wrote: > Hi all, > > On Tue, Apr 21, 2020 at 09:19 PM, Mahishasura wrote: > > > > > > Hello, > > > > I could not find where this debian package is maintained. Please share link. > > I'm also interested in helping out with inspircd! > > I've gone ahead and created a shared repo on salsa, and added VCS > information: https://salsa.debian.org/debian/inspircd imported from > Christoph's repo. > > Please let me know if this works for you! > > Next steps IMHO would be to package the latest version and go over > triaging bugs; I'll likely start doing that in the next few days, time > permitting This has happened! I've set myself as Maintainer for now, although I'm happy to co-maintain as needed. best, Filippo
Bug#951339: Debian changes to InspIRCd causes errors when loading the httpd module
On Fri, Feb 14, 2020 at 06:42 PM, Sadie Powell wrote: > Package: inspircd > Version: 3.4.0-2 > > Hello, > > We have received reports that users of your package are experiencing errors > caused by Debian patching the httpd module to not use the vendored version of > the http_parser library. > > Having had a look at the patch (debian.use-http-parser-lib.patch) it seems > like your patch is forgetting to link against the library so the module is > compiling but failing at runtime. Thank you for the report! I've fixed the patch to ask the linker to link the library. > > Ideally the fix for this should be to just remove this patch. We only test > against the vendored version and there's no guarantee we won't make changes > to the vendored libraries which make them incompatible with the mainline > version. It's only a tiny library with no external dependencies so this isn't > harmful at all. In general Debian's default approach is not to ship vendored libraries, are the tests you mentioned something that gets run at build time? Debian's autopkgtest runs tests with a full system instead, so we could test loading the module and run higher level tests. Filippo
Bug#953259: Missing modules in build: regression since buster
On Fri, May 15, 2020 at 07:11 AM, Sadie Powell wrote: > >Here's the patch (with thanks to Joel Sing): > > The correct way for packagers to handle extra modules is to manually enable > all extra modules using --enable-extras and then pass --disable-auto-extras > to the main configure run to disable the automatic check. This prevents > silently failing when a module's dependencies are not available. Thank you for the pointer! I've done so in 3.8.0-1 and uploaded the package to unstable just now. This change also restores the missing modules (i.e. this bug)
Bug#939424: Debian vcs
Hi all, On Tue, Apr 21, 2020 at 09:19 PM, Mahishasura wrote: > > > Hello, > > I could not find where this debian package is maintained. Please share link. I'm also interested in helping out with inspircd! I've gone ahead and created a shared repo on salsa, and added VCS information: https://salsa.debian.org/debian/inspircd imported from Christoph's repo. Please let me know if this works for you! Next steps IMHO would be to package the latest version and go over triaging bugs; I'll likely start doing that in the next few days, time permitting
Bug#972872: apt.systemd.daily should vary exit code based on unattended-upgrades failures
On Sun, Oct 25, 2020 at 07:56:10PM +0100, Julian Andres Klode wrote: > > Even on a failed u-u run the apt-daily-upgrade.service unit is still > > reported a > > successful, AFAICT because apt.systemd.daily exits 0 even when u-u fails. I > > think it makes sense to surface u-u errors back and thus fail the systemd > > service, does that seem reasonble? What do you think re: surfacing other > > errors > > as well? > > We need a substantial rework of exit logic and introduce retry to the > whole service. Agreed! Would you be interested in a change to surface u-u errors only for a start? best, Filippo
Bug#972872: apt.systemd.daily should vary exit code based on unattended-upgrades failures
Package: apt Version: 1.8.2.1 Severity: normal Hi, I've ran into a situation where an unattended-upgrades run would fail to upgrade packages on an host. I'm using the u-u APT integration, thus u-u is called via /usr/lib/apt/apt.systemd.daily and its corresponding service+timer. Even on a failed u-u run the apt-daily-upgrade.service unit is still reported a successful, AFAICT because apt.systemd.daily exits 0 even when u-u fails. I think it makes sense to surface u-u errors back and thus fail the systemd service, does that seem reasonble? What do you think re: surfacing other errors as well? thank you! Filippo
Bug#959033: ITP: golang-github-fluffle-goirc -- Event-based stateful IRC client framework for Go.
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi * Package name: golang-github-fluffle-goirc Version : 1.0.3-1 Upstream Author : Alex Bee * URL : https://github.com/fluffle/goirc * License : BSD-3-clause Programming Lang: Go Description : Event-based stateful IRC client framework for Go. GoIRC provides a simple to use but fully fledged IRC client implemented in Go.
Bug#959032: ITP: alertmanager-irc-relay -- Send Prometheus Alerts to IRC using Webhooks
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi * Package name: alertmanager-irc-relay Version : 0.1.0-1 Upstream Author : Google * URL : https://github.com/google/alertmanager-irc-relay * License : Apache-2.0 Programming Lang: Go Description : Send Prometheus alerts to IRC using Webhooks Alertmanager IRC Relay Alertmanager IRC Relay is a bot relaying Prometheus (https://prometheus.io/) alerts to IRC. Alerts are received from Prometheus using Webhooks (https://prometheus.io/docs/alerting/configuration/#webhook-receiver-
Bug#931572: Vagrant box missing stable buster release
On Sun, Jul 07, 2019 at 02:22:41PM -0500, Andrew Pennebaker wrote: > Package: cloud.debian.org > Version: * > > The semi-official virtual machine images on Vagrant Cloud do not yet > feature a stable, v10.0.0 release for Debian Buster. Can confirm, additionally 'vagrant up' with debian/buster64 is failing for me on amd64 with Tuesday 16 July 2019 21:18:43 +0200 (0:00:00.041) 0:00:01.150 ** prober | FAILED! => { "changed": false, "cmd": "apt-get update", "msg": "E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'\nE: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'", "rc": 100, "stderr": "E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'\nE: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'\n", "stderr_lines": [ "E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'", "E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'" ], "stdout": "Get:1 http://deb.debian.org/debian buster InRelease [118 kB]\nGet:2 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB]\nReading package lists...\n", "stdout_lines": [ "Get:1 http://deb.debian.org/debian buster InRelease [118 kB]", "Get:2 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB]", "Reading package lists..." ] }
Bug#921681: RM: kernel-patch-viewos -- ROM; RC-buggy, not updated
Package: ftp.debian.org Severity: normal
Bug#917412: debirf: parallel xz compression
Package: debirf Version: 0.38 Severity: wishlist Dear Maintainer, newer xz versions support parallel compression with -T, it'd be nice to have a way to specify xz flags and/or enable -T0 by default. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debirf depends on: ii apt 1.8.0~alpha2 ii cpio 2.12+dfsg-6 ii debootstrap 1.0.111 ii fakechroot 2.19-3 ii fakeroot 1.23-1 ii klibc-utils 2.0.4-14 ii xz-utils 5.2.2-1.3 Versions of packages debirf recommends: ii grub-common 2.02+dfsg1-9 ii lsb-release 10.2018112800 ii xorriso 1.5.0-1 Versions of packages debirf suggests: ii syslinux-common 3:6.04~git20171011.af7e95c3+dfsg1-6 -- no debconf information
Bug#917397: reportbug: cannot find/fetch bug reports after initial listing
Package: reportbug Version: 7.5.1 Severity: important Dear Maintainer, I tried selecting a specific bug from the list reportbug presented, though reportbug reports it can't find said bug: (1-3/3) Is the bug you found listed above [y|N|b|m|r|q|s|f|u|t|e|?]? 3 Retrieving report #856512 from Debian bug tracking system... No report available: #856512 No bug reports found. I can reproduce the same with 'reportbug reportbug' and then hit "1": (1-17/223) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? 1 Retrieving report #709862 from Debian bug tracking system... No report available: #709862 No bug reports found. Full transcript: $ reportbug debirf Warning: no reportbug configuration found. Proceeding in novice mode. Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Filippo Giunchedi ' as your from address. Getting status for debirf... Checking for newer versions at madison... Will send report to Debian (per lsb_release). Querying Debian BTS for reports on debirf (source)... 28 bug reports found: Bugs with severity grave 1) #806377 fails to build jessie image Bugs with severity important 2) #809410 debirf: chroot error / fakechroot segfault Bugs with severity normal 3) #540826 debirf: packages with maintainer scripts reading from /dev/random or /dev/urandom make ug 4) #562675 Bug: Long wait during boot in rescue 5) #619329 debirf: packages with maintainer scripts reading from /dev/random or /dev/urandom make ug 6) #621092 debirf enter $profiledir "a y x" should not need its argument to be in quotes. 7) #650242 debirf make does not work across major libc6 versions as a non-privileged user 8) #714383 ROOT_BUILD (-r) fails to download packages for rescue module 9) #857106 Debirf stop with "Cannot read keyring" when building other distro with verification disabl 10) #901779 debirf: autopkgtest fails because script is not executable 11) #902285 [patch] debirf: removing init-system-helpers cause error with "debirf make minimal" 12) #902289 debirf: During install linux-image package, /root/lib/* files were deleted 13) #905432 debirf: Use APT resolution for kernel version 14) #917391 debirf: grub-mkrescue fails, 'mformat' not found. Missing mtools dependency. 15) #917393 debirf: Generated iso fails to boot in KVM with "Could not read from CDROM (code 0009)" Bugs with severity minor 16) #702706 Debirf 0.33 in Wheezy with 3.8.1 kernel. rc=134 17) #856512 debirf : /usr/share/debirf/version contains the distribution and urgency 18) #895361 debirf: a system fails to boot: corrupted rootfs.cxz Bugs with severity wishlist 19) #619356 debirf: enable encrypted ramfs 20) #620294 Please provide pre-built debirf image package 21) #685715 debirf: separate mirrors for build and runtime 22) #685716 debirf: have network-dhcp use a variable to control device 23) #686923 debirf: document root=/dev/ram0 24) #688815 debirf: detect unsupported build combinations 25) #768367 debirf and local repositories 26) #773776 debirf: consider isohybrid 27) #834476 debirf: way to enable network and ssh 28) #916736 debirf: rescue could include stress-ng (19-28/28) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? f Enter the search pattern (a Perl-compatible regular expression) or press ENTER to exit: version Bugs with severity normal: 2 reports 1) #650242 debirf make does not work across major libc6 versions as a non-privileged user 2) #905432 debirf: Use APT resolution for kernel version Bugs with severity minor: 1 report 3) #856512 debirf : /usr/share/debirf/version contains the distribution and urgency (1-3/3) Is the bug you found listed above [y|N|b|m|r|q|s|f|u|t|e|?]? 3 Retrieving report #856512 from Debian bug tracking system... No report available: #856512 No bug reports found. Maintainer for debirf is 'Jameson Graef Rollins '. Looking up dependencies of debirf... Briefly describe the problem (max. 100 characters allowed). This will be the bug email subject, so keep the summary as concise as possible, for example: "fails to send email" or "does not start with -q option specified" (enter Ctrl+c to exit reportbug without reporting a bug). > User interrupt (^D). -- Package-specific info: ** Environment settings: DEBEMAIL="fili...@debian.org" DEBFULLNAME="Filippo Giunchedi" -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on:
Bug#917393: debirf: Generated iso fails to boot in KVM with "Could not read from CDROM (code 0009)"
Package: debirf Version: 0.38 Severity: normal Dear Maintainer, After generating a debirf iso, KVM fails to boot from it with the message in the subject. Installing 'grub-pc-bin' and regenerating the iso fixes the issue, same problem and resolution as https://github.com/intermezzOS/book/issues/35 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debirf depends on: ii apt 1.8.0~alpha2 ii cpio 2.12+dfsg-6 ii debootstrap 1.0.111 ii fakechroot 2.19-3 ii fakeroot 1.23-1 ii klibc-utils 2.0.4-14 ii xz-utils 5.2.2-1.3 Versions of packages debirf recommends: ii grub-common 2.02+dfsg1-9 ii lsb-release 10.2018112800 ii xorriso 1.5.0-1 Versions of packages debirf suggests: ii syslinux-common 3:6.04~git20171011.af7e95c3+dfsg1-6 -- no debconf information
Bug#917391: debirf: grub-mkrescue fails, 'mformat' not found. Missing mtools dependency.
Package: debirf Version: 0.38 Severity: normal Dear Maintainer, Upon calling 'debirf makeiso ' on a buster system this is what I'm getting: $ sudo debirf makeiso debian-amd64 debirf> loading profile 'debian-amd64'... debirf> kernel found. debirf> initramfs found. debirf> creating debirf iso... debirf> using GRUB as bootloader... grub-mkrescue: error: `mformat` invocation failed and indeed mformat is missing, installing 'mtools' fixes the issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debirf depends on: ii apt 1.8.0~alpha2 ii cpio 2.12+dfsg-6 ii debootstrap 1.0.111 ii fakechroot 2.19-3 ii fakeroot 1.23-1 ii klibc-utils 2.0.4-14 ii xz-utils 5.2.2-1.3 Versions of packages debirf recommends: ii grub-common 2.02+dfsg1-9 ii lsb-release 10.2018112800 ii xorriso 1.5.0-1 Versions of packages debirf suggests: ii syslinux-common 3:6.04~git20171011.af7e95c3+dfsg1-6 -- no debconf information
Bug#914852: apt-cacher-ng: Returns 500 on http://packagecloud.io/grafana/testing/debian/
Package: apt-cacher-ng Version: 3.2-1 Severity: normal Hi, On this buster host I have apt-cacher-ng running, when using the line below: deb http://localhost:3142/packagecloud.io/grafana/testing/debian/ stretch main apt fails to fetch the repository: # apt update Get:1 http://security.debian.org/debian-security buster/updates InRelease [38.3 kB] Hit:2 http://cdn-fastly.deb.debian.org/debian buster InRelease Hit:3 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease Err:4 http://localhost:3142/packagecloud.io/grafana/testing/debian stretch InRelease 500 Bad redirection (path) [IP: ::1 3142] Fetched 38.3 kB in 1s (40.5 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 7 packages can be upgraded. Run 'apt list --upgradable' to see them. W: Failed to fetch http://localhost:3142/packagecloud.io/grafana/testing/debian/dists/stretch/InRelease 500 Bad redirection (path) [IP: ::1 3142] W: Some index files failed to download. They have been ignored, or old ones used instead. While the repository itself updates fine when not going through apt-cacher-ng. I've attached a debug log, hope that helps! Filippo -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cacher-ng depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.69 ii dpkg 1.19.2 ii libbz2-1.0 1.0.6-9 ii libc6 2.27-8 ii libgcc11:8.2.0-9 ii liblzma5 5.2.2-1.3 ii libssl1.1 1.1.1a-1 ii libstdc++6 8.2.0-9 ii libsystemd0239-13 ii libwrap0 7.6.q-27 ii lsb-base 9.20170808 ii zlib1g 1:1.2.11.dfsg-1 apt-cacher-ng recommends no packages. Versions of packages apt-cacher-ng suggests: ii avahi-daemon 0.7-4+b1 pn doc-base ii libfuse2 2.9.8-2 -- Configuration Files: /etc/apt-cacher-ng/acng.conf changed [not included] /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: '/etc/apt-cacher-ng/security.conf' -- debconf information: apt-cacher-ng/gentargetmode: No automated setup apt-cacher-ng/bindaddress: keep * apt-cacher-ng/tunnelenable: false apt-cacher-ng/proxy: keep apt-cacher-ng/port: keep apt-cacher-ng/cachedir: keep apt-cacher-ng_packagecloud_debug.gz Description: application/gzip
Bug#911299: rsyslog: consider enabling mmkubernetes
On Thu, Oct 18, 2018 at 03:11:23PM +0200, Michael Biebl wrote: > This would mean a dependency on libcurl, which so far I tried to avoid. > > Then again, libcurl is also used by other modules, like omhttp or fmhttp. > > I'm undecided whether to split those all off into separate module > packages or not. Considering the libcurl rationale I'd say yes, separate packages similarly to rsyslog-elasticsearch which also has libcurl as a dependency. filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#911299: rsyslog: consider enabling mmkubernetes
Package: rsyslog Version: 8.38.0-1+b1 Severity: wishlist Hi, please consider enabling mmkubernetes to be able to augment messages with Kubernetes metadata. thanks, Filippo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rsyslog depends on: ii libc6 2.27-6 ii libestr0 0.1.10-2.1 ii libfastjson4 0.99.8-2 ii liblognorm5 2.0.5-1 ii libsystemd0 239-10 ii libuuid1 2.32.1-0.1 ii lsb-base 9.20170808 ii zlib1g1:1.2.11.dfsg-1 Versions of packages rsyslog recommends: ii logrotate 3.14.0-4 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gnutls pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-relp -- no debconf information
Bug#909174: prometheus-haproxy-exporter: Main binary name not consistent with package name
Package: prometheus-haproxy-exporter Version: 0.9.0-1 Severity: normal The package is shipping /usr/bin/haproxy_exporter though the convention has been to match the binary name with the package name, thus haproxy_exporter should prometheus-haproxy-exporter instead -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#909175: prometheus-haproxy-exporter: Package should ship init.d and service files
Package: prometheus-haproxy-exporter Version: 0.9.0-1 Severity: normal [Filing for reference/tracking] I noticed prometheus-haproxy-exporter isn't shipping init/service files which are typical for an exporter that runs as daemon, we should ship those. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#909172: prometheus-trafficserver-exporter: Binary name inconsistent with package name
Package: prometheus-trafficserver-exporter Version: 0.0.2-1 Severity: normal The package is shipping /usr/bin/trafficserver_exporter though the convention has been to be shipping the binary named after the package, thus prometheus-trafficserver-exporter -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#896160: bpfcc-tools: spurious directory/files /usr/sbin/lib
Package: bpfcc-tools Version: 0.5.0-5 Severity: normal Hi, I noticed there's a /usr/sbin/lib directory in bpfcc-tools which AIUI shouldn't be there: /usr/sbin/lib /usr/sbin/lib/ucalls /usr/sbin/lib/uflow /usr/sbin/lib/ugc /usr/sbin/lib/uobjnew /usr/sbin/lib/ustat /usr/sbin/lib/uthreads -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#782795: python-pip: breaks with relocatable virtualenv, assert sys.prefix != real_prefix
On Sat, Mar 24, 2018 at 05:50:40PM -0400, Stefano Rivera wrote: > Version: 9.0.1-2 > > Hi Filippo (2015.04.17_19:05:52_-0400) > > it looks like pip stops working inside a virtualenv after using > > virtualenv --relocatable > > I would say that that's actually a virtualenv bug. But the better news > is that I can't reproduce it in stretch. So let's close this. > > Also, note that upstream virtualenv doesn't really support > --relocatable. It's known to not work particularly well. Indeed, unfortunately I've ran into the issue of unrelocatable venv time and tiem again since this bug and eventually gave up. thanks! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#872997: prometheus-blackbox-exporter: Make CAP_NET_RAW switching configurabl
Package: prometheus-blackbox-exporter Severity: wishlist blackbox_exporter's ICMP probing requires either root or CAP_NET_RAW, the latter should be configurable (via debconf) for users that want full functionality without running as root. Using debconf would keep package upgrades from overriding what the user might have set manually or via config management. Another option for administrators to survive package upgrades without further hacks would be to run as root and let systemd drop all capabilities but CAP_NET_RAW, the setcap solution seems better overall though. filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#854842: diamond takes a while to stop, errors out, slows down shutdown
On Sun, Feb 12, 2017 at 01:04:41PM -0500, Sandro Tosi wrote: > > As a user, what I can say is that slowing reboots down for a minute > > (systemd showing the red error bar and says that's waiting for it), as > > well as taking a minute to restart e.g. every time puppet pushes a new > > config, is not an acceptable behavior for this kind of package. We have > > diamond installed in ~1200 servers or so (currently v3.0) and this kind > > of behavior would get annoying real quick. > > Hopefully upstream will respond soon and i will still attempt to get a > fix in stretch I was able to reproduce this bug in stretch, see also the updates at https://github.com/python-diamond/Diamond/issues/595. Though upstream's fix committed in fd4146dc3 does the trick and results in a fast shutdown for diamond. Any change the fix could be backported in unstable (ideally to stretch-updates too) ? I'm happy to help too if needed! thanks, Filippo
Bug#869970: diamond: debugging output always on with --log-stdout
Package: diamond Version: 4.0.515-4 Severity: normal Tags: upstream Hi, we've noticed that diamond invoked with --log-stdout results in DEBUG logging level set regardless of configuration option and resulting in "syslog spam". This seems to be fixed upstream with commit a8e474dc44 where --log-stdout now honors the diamond.conf file for logging levels. thanks! Filippo -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#864242: acct monthly cron fails if /var/log/wtmp rotation has not happened
Package: acct Version: 6.6.2-1 Severity: normal Hi, on a freshly installed stretch system in case of no /var/log/wtmp.1 the acct monthly cronjob isn't happy and generates "cron spam": # bash -x /etc/cron.monthly/acct + LOGROTATE=/etc/cron.daily/logrotate + test -x /usr/sbin/accton ++ date + echo 'Login accounting for the month ended Mon Jun 5 15:42:39 UTC 2017:' + echo + '[' -f /etc/cron.daily/logrotate ']' + '[' -x /usr/sbin/logrotate ']' + '[' -f /var/log/wtmp.1 ']' + '[' -f /var/log/wtmp.1.gz ']' + ac -f '' -p + sort -nr -k2 couldn't open file '': No such file or directory + echo + last -f '' last: cannot open : No such file or directory + '[' -n '' ']' + chown root:adm /var/log/wtmp.report + chmod 640 /var/log/wtmp.report -- System Information: Debian Release: 8.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#843189: ITP: prometheus-blackbox-exporter -- Prometheus exporter for blackbox monitoring
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi * Package name: prometheus-blackbox-exporter Version : 0.2.0+git20160930.6.8cf9605-1 Upstream Author : Prometheus Authors * URL : https://github.com/prometheus/blackbox_exporter * License : Apache-2.0 Programming Lang: Go Description : Prometheus exporter for blackbox monitoring The blackbox exporter allows blackbox probing of network endpoints over HTTP, HTTPS, DNS, TCP and ICMP. Additional modules can be defined to suit other needs. . Querying of endpoints happens via HTTP GET queries, by specifying the target name and what kind of probing to execute. Results from the probe are returned in the form of Prometheus metrics.
Bug#838490: ganglia: ship systemd service units
Source: ganglia Severity: normal Hi, it would be nice to have systemd service unit files shipped for gmond / gmetad, as a very basic replacement for the sysvinit scripts something like this (for gmond) [Unit] Description=Ganglia monitor After=network.target [Service] ExecStart=/usr/sbin/gmond --foreground --pid-file /var/run/gmond.pid [Install] WantedBy=multi-user.target -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#766867: python-greenlet and python-gevent jessie backports
hi, I've built python-gevent (and python-gevent) to jessie from stretch and it fixes an SSL failure I had. It seems all these bugs #805615 #791476 #766867 would be fixed by a newer version, I'm going to upload both packages to jessie-backports unless there are objections. Not as nice as uploading a patched package to stable but if there's a package ready I'll be happy to review/sponsor that. filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#824842: [pkg-go] Bug#824842: prometheus: let systemd wait longer for graceful stop
tags 824842 + patch thanks On Fri, May 20, 2016 at 01:37:12PM +0100, Martín Ferrari wrote: > Makes sense. For sysvinit I am making it wait almost 20 seconds, and > after that the action just fails (instead of SIGKILLing it). If systemd > does not have that option, I would say wait up to one minute. > > Care to send a patch? I don't use systemd, so I have no clue about it :) for sure! The attached patch would make it match sysvinit behaviour. thanks, filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ diff --git a/debian/changelog b/debian/changelog index c36583a..f4257bc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,13 @@ prometheus (0.18.0+ds-3) UNRELEASED; urgency=medium + [ Martín Ferrari ] * Switch to use the golang-github-prometheus-client-model-dev package. * Improve the way datetimepicker is built. + [ Filippo Giunchedi ] + * debian/service: match sysvinit behaviour (send SIGTERM with 20s timeout, +never send SIGKILL) Closes: #824842 + -- Martín Ferrari Sun, 08 May 2016 04:33:32 + prometheus (0.18.0+ds-2) unstable; urgency=medium diff --git a/debian/service b/debian/service index 44ba6fb..067448a 100644 --- a/debian/service +++ b/debian/service @@ -8,6 +8,8 @@ User=prometheus EnvironmentFile=/etc/default/prometheus ExecStart=/usr/bin/prometheus $ARGS ExecReload=/bin/kill -HUP $MAINPID +TimeoutStopSec=20s +SendSIGKILL=no [Install] WantedBy=multi-user.target
Bug#824842: prometheus: let systemd wait longer for graceful stop
Package: prometheus Version: 0.18.0+ds-2 Severity: normal hi, I noticed on bigger prometheus instances it might take quite some time after 'stop' is requested before the storage is completely flushed to disk, I'm proposing to add TimeoutStopSec= to the service file to have systemd wait before SIGTERM, not sure about the default value, 5m perhaps? Alternatively mentioning it README.Debian would do too. thanks, filippo -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages prometheus depends on: ii daemon0.6.4-1 ii libc6 2.19-18+deb8u4 ii libjs-bootstrap 3.2.0+dfsg-1 ii libjs-handlebars 1.3.0-1 ii libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2 ii libjs-rickshaw1.5.0.dfsg-1 Versions of packages prometheus recommends: pn prometheus-cli ii prometheus-node-exporter 0.11.0+ds-1~bpo8+2 prometheus suggests no packages.
Bug#819324: O: obex-data-server
Package: wnpp Severity: normal I'm not using this anymore and I haven't worked on it for the longest time.
Bug#819320: dropbear-initramfs: unable to override ip= from command line
Package: dropbear-initramfs Version: 2016.72-1 Severity: normal hi, I have configured IP= in /etc/initramfs-tools/initramfs.conf to get the network configured by initramfs. I've tried to override the setting with ip= during boot but it doesn't seem to work, defaulting to the configuration file contents when calling 'ipconfig'. When ran with set -x I noticed /usr/share/initramfs-tools/scripts/init-premount/dropbear sourcing /conf/initramfs.conf. This undoes the /proc/cmdline parsing done by /usr/share/initramfs-tools/init earlier though and sets IP= from the config. It is easy enough to work around in the config with sth like [ -z "$IP" ] || IP="..." but not obvious at first. thanks, filippo -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#818417: [pkg-go] Bug#818417: prometheus: FTBFS: aws.Config does not implement client.ConfigProvider
On Sat, Mar 26, 2016 at 04:51:59PM +1100, Dmitry Smirnov wrote: > On Friday, 25 March 2016 10:46:27 AM AEDT Filippo Giunchedi wrote: > > that should be related to golang-github-aws-aws-sdk-go latest upload, the > > following patch fixes the FTBFS for me > > Just to let you know that I've uploaded new release of AWS-SDK-GO so this > patch might need another test round against latest aws-sdk... thanks Dmitry! I just built prometheus again with 1.1.14 and the patch above and it doesn't FTBFS filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#818417: prometheus: FTBFS: aws.Config does not implement client.ConfigProvider
tags 818417 + patch thanks On Wed, Mar 16, 2016 at 03:19:08PM -0700, Martin Michlmayr wrote: > > # github.com/prometheus/prometheus/retrieval/discovery > > src/github.com/prometheus/prometheus/retrieval/discovery/ec2.go:58: > > undefined: defaults.DefaultChainCredentials > > src/github.com/prometheus/prometheus/retrieval/discovery/ec2.go:107: cannot > > use ed.aws (type *aws.Config) as type client.ConfigProvider in argument to > > ec2.New: > > *aws.Config does not implement client.ConfigProvider (missing > > ClientConfig method) that should be related to golang-github-aws-aws-sdk-go latest upload, the following patch fixes the FTBFS for me diff --git a/retrieval/discovery/ec2.go b/retrieval/discovery/ec2.go index 46b3d37..ebfd1b1 100644 --- a/retrieval/discovery/ec2.go +++ b/retrieval/discovery/ec2.go @@ -20,7 +20,7 @@ import ( "github.com/aws/aws-sdk-go/aws" "github.com/aws/aws-sdk-go/aws/credentials" - "github.com/aws/aws-sdk-go/aws/defaults" + "github.com/aws/aws-sdk-go/aws/session" "github.com/prometheus/common/log" "github.com/prometheus/common/model" @@ -55,7 +55,7 @@ type EC2Discovery struct { func NewEC2Discovery(conf *config.EC2SDConfig) *EC2Discovery { creds := credentials.NewStaticCredentials(conf.AccessKey, conf.SecretKey, "") if conf.AccessKey == "" && conf.SecretKey == "" { - creds = defaults.DefaultChainCredentials + creds = credentials.NewEnvCredentials() } return &EC2Discovery{ aws: &aws.Config{ @@ -104,7 +104,7 @@ func (ed *EC2Discovery) Sources() []string { } func (ed *EC2Discovery) refresh() (*config.TargetGroup, error) { - ec2s := ec2.New(ed.aws) + ec2s := ec2.New(session.New(), ed.aws) tg := &config.TargetGroup{ Source: *ed.aws.Region, } filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#817790: golang-github-aws-aws-sdk-go: new upstream version?
Package: golang-github-aws-aws-sdk-go Version: 1.0.7+dfsg-1 Severity: normal hi, I noticed prometheus currently FTBFS in unstable, e.g. https://reproducible.debian.net/rbuild/unstable/amd64/prometheus_0.16.2+ds-1.rbuild.log with # github.com/prometheus/prometheus/retrieval/discovery src/github.com/prometheus/prometheus/retrieval/discovery/ec2.go:58: undefined: defaults.DefaultChainCredentials src/github.com/prometheus/prometheus/retrieval/discovery/ec2.go:107: cannot use ed.aws (type *aws.Config) as type client.ConfigProvider in argument to ec2.New: *aws.Config does not implement client.ConfigProvider (missing ClientConfig method) likely due to using newer golang-github-aws-aws-sdk-go API, are there plans to update to newer upstream version? thanks! -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#817403: prometheus: config reload for sysv init script
Package: prometheus Version: 0.16.1-0 Severity: normal Tags: patch hi! (sort of related to #814802) it'd be nice to have config reload in the sysv init script too, e.g. something like the following: diff --git a/debian/init b/debian/init index 4efd831..c05c108 100755 --- a/debian/init +++ b/debian/init @@ -68,3 +68,17 @@ do_stop_cmd() $HELPER $HELPER_ARGS --running || return 0 return 2 } + +do_reload() +{ +log_daemon_msg "Reloading $DESC configuration files" "$NAME" +$HELPER $HELPER_ARGS --running || return 1 +helper_pid=$(cat $PIDFILE) +if [ -z "$helper_pid" ]; then +log_failure_msg "Unable to find PID" +return 1 +fi +start-stop-daemon --stop --signal 1 --quiet \ +--ppid "$helper_pid" --exec "$DAEMON" +log_end_msg $? +} what do you think?
Bug#815560: ITP: prometheus-mysqld-exporter -- Prometheus exporter for MySQL server metrics
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi * Package name: prometheus-mysqld-exporter Version : 0.7.1 Upstream Author : Julius Volz Brian Brazil * URL : https://github.com/prometheus/mysqld_exporter * License : Apache 2 Programming Lang: Go Description : Prometheus exporter for MySQL server metrics Prometheus exporter for MySQL server metrics. Supported MySQL versions: 5.1 and up, however not all collection methods are supported on MySQL < 5.6.
Bug#814784: ITP: diamond -- smart data producer for graphite graphing package
On Tue, Feb 16, 2016 at 09:59:12AM +, Sandro Tosi wrote: > > FWIW at Wikimedia Foundation we have a diamond deployment, debian package is > > at https://gerrit.wikimedia.org/r/operations/debs/python-diamond though at > > returns a "Not Found"; there is also an upstream debian/ dir, I will > reuse some of it i guess err, yeah gerrit won't let you browse it, it is 'git clone'-able though! HTH! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#814784: ITP: diamond -- smart data producer for graphite graphing package
hi! On Mon, Feb 15, 2016 at 06:29:11AM -0500, Sandro Tosi wrote: > Package: wnpp > Severity: wishlist > Owner: Sandro Tosi > > * Package name: diamond > Version : 4.0.195 > Upstream Author : diam...@librelist.com > * URL : https://github.com/python-diamond/Diamond thanks for the ITP! FWIW at Wikimedia Foundation we have a diamond deployment, debian package is at https://gerrit.wikimedia.org/r/operations/debs/python-diamond though at version 3.5 in case there's something reusable. I've never found the time to upload it to Debian but happy to help e.g. via collab-maint, what do you think? Also re: version the pypi version is 4.0.195 from 2015-07-18 but I couldn't find a corresponding tag on github filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵
Bug#807311: init-d-script: do_reload_sigusr1 sends sighup, not sigusr1
Package: sysvinit-utils Version: 2.88dsf-59 Severity: minor hi, the convenience function do_reload_sigusr1 in init-d-script doesn't send sigusr1 but sighup instead, perhaps sth like --- a/debian/init-d-script +++ b/debian/init-d-script @@ -138,7 +138,8 @@ do_force_reload() { # Enable this using # alias do_reload=do_reload_sigusr1 -do_reload_sigusr1() { +alias do_reload_sigusr1=do_reload_sighup +do_reload_sighup() { log_daemon_msg "Reloading $DESC configuration files" "$NAME" start-stop-daemon --oknodo --stop --signal 1 --quiet \ --pidfile "$PIDFILE" --exec "$DAEMON" -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sysvinit-utils depends on: ii libc62.19-18+deb8u1 ii libselinux1 2.3-2 ii startpar 0.59-3 sysvinit-utils recommends no packages. Versions of packages sysvinit-utils suggests: pn bootlogd pn sash -- no debconf information
Bug#796410: python-statsd: FTBFS: ImportError: No module named django.conf
On Fri, Aug 21, 2015 at 08:18 PM, Chris Lamb wrote: > The full build log is attached or can be viewed here: > > > https://reproducible.debian.net/logs/unstable/amd64/python-statsd_3.0.1-2.build1.log.gz hi, looks like the linked log builds fine? i.e. the FTBFS recovered. anyways I can't reproduce it in a local unstable chroot with cowbuilder both with 3.0.1 and 3.2 (which I'm about to upload)
Bug#790399: ITP: structlog -- tructured Logging for Python
On Mon, Jul 06, 2015 at 08:39:30PM +0200, Guillem Jover wrote: > > indeed, most python modules I've looked at so far don't have the python- > > prefix in their name > > I've always considered this a bad practice that I'd really like, we as > a project, stopped perpetuating. that makes sense, I've uploaded it as python-structlog FTR filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790399: ITP: structlog -- tructured Logging for Python
On Mon, Jun 29, 2015 at 01:56:55PM +0500, Andrey Rahmatullin wrote: > On Mon, Jun 29, 2015 at 10:22:30AM +0200, Adrien CLERC wrote: > > Le 29/06/2015 02:51, Filippo Giunchedi a écrit : > > > * Package name: structlog > > Hi, > > > > It seems to be a Python library (in the main site, I can read that it is > > used as an imported module), it should be named python-structlog. > Not necessarily (as we are talking about the source package name). indeed, most python modules I've looked at so far don't have the python- prefix in their name filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790399: ITP: structlog -- tructured Logging for Python
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi * Package name: structlog Version : 15.2.0 Upstream Author : Hynek Schlawack * URL : http://www.structlog.org * License : Apache 2.0 or MIT Programming Lang: Python Description : structured Logging for Python Structlog makes structured logging in Python easy by augmenting your existing logger. Structured logging means that you don’t write hard-to-parse and hard-to-keep-consistent prose in your logs but that you log events that happen in a context instead. . Structlog allows you to split your log entries up into key/value pairs and build them incrementally without annoying boilerplate code. It can be used immediately with any existing logger. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775930: [lvs-users] [PATCH] ipvsadm: add SCTP support
On Tue, Jun 23, 2015 at 07:53:41PM +0200, Alexander Wirt wrote: > > thanks for the 1.28 upload! now that jessie has been released do you have > > plans for an upload in unstable? > No plans, I just uploaded it. that was fast, thanks! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775930: [lvs-users] [PATCH] ipvsadm: add SCTP support
On Thu, Feb 12, 2015 at 03:26:38PM +0100, Alexander Wirt wrote: > I fixed the watchfile, but I didn't pushed yet. I will also fix the VCS > fields. thanks for the 1.28 upload! now that jessie has been released do you have plans for an upload in unstable? thanks, filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: [Pkg-graphite-maint] ITP: carbon-c-relay -- status?
On Tue, May 26, 2015 at 12:31:18PM +0200, Bernd Zeimetz wrote: > Hi Jonas, Filippo, > > > > >So the graphite ecosystem is found in one place. I have added you to the > >Graphite project > >on Alioth. > > > >I have created a new git repo for you, feel free to use it: > > > > ssh://git.debian.org/git/pkg-graphite/packages/carbon-c-relay.git > > I'll leave that decision to Filippo as he started to package it. > Sorry for not uploading it yet, my laptop's hdd decided that it > wants to be replaced and I'm migrating stuff from the old to the new > one at the moment. sounds good to me to move pkg-graphite instead. No worries Bernd about the upload, good luck with the migration! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: [Pkg-graphite-maint] ITP: carbon-c-relay -- status?
On Mon, May 18, 2015 at 01:43:15PM +0200, Bernd Zeimetz wrote: > On 05/16/2015 11:07 AM, Filippo Giunchedi wrote: > >On Wed, May 13, 2015 at 09:43:30PM +0200, Jonas Genannt wrote: > >>>Happy to hear other opinions if people are interested since it is just > >>>harder > >>>to transition after the upload. (+Jonas and pkg-graphite-maint) > >> > >>I would also suggest to use a other configuration directory. because > >>/etc/carbon can be > >>have more configuration files: > > > >ok I've switched back to /etc/carbon-c-relay.conf in 7f6bed754f > >Bernd if that looks good I think we're fine to upload > > I'll add some dpkg-maint-helper stuff for a smooth migration from > the old/inofficial package / config file location to the new one. I > need it anyway. > > Should I upload it when I'm done? sure go ahead, thanks! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: [Pkg-graphite-maint] ITP: carbon-c-relay -- status?
On Wed, May 13, 2015 at 09:43:30PM +0200, Jonas Genannt wrote: > > Happy to hear other opinions if people are interested since it is just > > harder > > to transition after the upload. (+Jonas and pkg-graphite-maint) > > I would also suggest to use a other configuration directory. because > /etc/carbon can be > have more configuration files: ok I've switched back to /etc/carbon-c-relay.conf in 7f6bed754f Bernd if that looks good I think we're fine to upload > @Filippo: thanks for doing the work of carbon-c :) you are welcome! we needed it anyway at wikimedia :) filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: ITP: carbon-c-relay -- status?
On Tue, May 12, 2015 at 01:46:48PM +0200, Bernd Zeimetz wrote: > On 05/12/2015 01:34 PM, Filippo Giunchedi wrote: > >That's "owned" by graphite-carbon in debian isn't it? I don't think we should > >mix paths > > yes, but I can't see why folders should be "owned" by something. > carbon-c-relay is pretty much related to the other carbon stuff, so > imho its fine to have it in the same folder. for me both ways are > fine. ack, I think it'd be better to keep them separate, /etc/carbon-c-relay.conf would be more predictable IMO. Happy to hear other opinions if people are interested since it is just harder to transition after the upload. (+Jonas and pkg-graphite-maint) filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: ITP: carbon-c-relay -- status?
On Tue, May 12, 2015 at 10:28:02AM +0200, Bernd Zeimetz wrote: > Hi Filippo, > > >the package is at > >https://anonscm.debian.org/cgit/collab-maint/carbon-c-relay.git/ and upstream > >has released 0.40 yesterday, I think an upload might happen in the next two > >weeks! If you are interested though feel free to go ahead, I'll be fairly > >busy > >at work at least until end of May > > what I've done - and I hope you don't mind: > > - moved the carbon-c-relay config to /etc/carbon. Thats where the > config lived from the inofficial packaging. That's "owned" by graphite-carbon in debian isn't it? I don't think we should mix paths > - added a defaults file for the init script and the systemd service > so you can easily pass options to the daemon > - upgraded to 0.40 > - fixed GIT_VERSION in Makefile > > I've added branches for wheezy and jessie backports. sounds good, thanks! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: ITP: carbon-c-relay -- status?
hi Bernd, On Mon, May 11, 2015 at 03:33:41PM +0200, Bernd Zeimetz wrote: > Hi Filippo, > > I was just wondering what the status of this ITP is? Do you plan to > upload a package soon-ish? the package is at https://anonscm.debian.org/cgit/collab-maint/carbon-c-relay.git/ and upstream has released 0.40 yesterday, I think an upload might happen in the next two weeks! If you are interested though feel free to go ahead, I'll be fairly busy at work at least until end of May thanks! filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782795: python-pip: breaks with relocatable virtualenv, assert sys.prefix != real_prefix
Package: python-pip Version: 1.5.6-5 Severity: normal hi, it looks like pip stops working inside a virtualenv after using virtualenv --relocatable how to reproduce: i7:/tmp$ virtualenv venv Running virtualenv with interpreter /usr/bin/python2 New python executable in venv/bin/python2 Also creating executable in venv/bin/python Installing setuptools, pip...done. i7:/tmp$ venv/bin/pip install flask Downloading/unpacking flask Downloading Flask-0.10.1.tar.gz (544kB): 544kB downloaded Running setup.py (path:/tmp/pip-build-IIMGrU/flask/setup.py) egg_info for package flask [...] Successfully installed flask Werkzeug Jinja2 itsdangerous markupsafe Cleaning up... i7:/tmp$ source venv/bin/activate (venv)i7:/tmp$ virtualenv --relocatable venv Running virtualenv with interpreter /tmp/venv/bin/python2 Making script venv/bin/pip2 relative Making script venv/bin/easy_install-2.7 relative Making script venv/bin/pip relative Making script venv/bin/easy_install relative Making script venv/bin/pip2.7 relative (venv)i7:/tmp$ venv/bin/pip install flask Traceback (most recent call last): File "venv/bin/pip", line 10, in from pip import main File "/tmp/venv/local/lib/python2.7/site-packages/pip/__init__.py", line 39, in assert sys.prefix != real_prefix AssertionError (venv)i7:/tmp$ -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-pip depends on: ii ca-certificates 20141019 ii python2.7.9-1 ii python-colorama 0.3.2-1 ii python-distlib0.1.9-1 ii python-html5lib 0.999-3 ii python-pkg-resources 5.5.1-1 ii python-requests 2.4.3-6 ii python-setuptools 5.5.1-1 ii python-six1.8.0-1 pn python:any Versions of packages python-pip recommends: ii build-essential 11.7 pn python-dev-all pn python-wheel python-pip suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765577: (no subject)
On Fri, Feb 06, 2015 at 01:26 AM, Chris Kuehl wrote: > Hi Christof, > > On Fri, Feb 06, 2015 at 08:30:58AM +0100, Christof Böckler wrote: > > Maybe it is has to do with the presence of a second networking device? > > The devices I tested on (which had a 100% reproducibility rate) all had > a single network card. So maybe it's possible that's the reason you > don't see the same level of occurrence. FWIW we're running into the same bug with jessie installer, passing 'debug' at boot apparently is enough to not trigger the race with good success rate. Unfortunately it isn't a very good workaround, it needs to be undone e.g. in /etc/default/grub after installation. See also https://phabricator.wikimedia.org/T90236 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749355: parallel: /usr/bin/parallel conflicts with moreutils' parallel
On Sat, Sep 27, 2014 at 07:45:14PM -0400, Antoine Beaupré wrote: > At this point, moreutils doesn't conflict with gnu parallel, and that is > intentional. It is gnu parallel that conflicts with moreutils. > > I talked briefly with Joey about this. Obviously, it's a rather annoying > issue for him, since the whole thing went as far as a CTTE bug > (#665851). The result of that discussion were unclear: no decision was > reached by the CTTE. > > From what I understand, joey doesn't want to be bothered with this. He > barely has time to maintain moreutils at all and has critical opinion of > gnu parallel, which breaks his ikiwiki-hosting package. Therefore, > ikiwiki-hosting conflicts with gnu parallel. understood, thanks for the context! > So I doubt we can coninve Joey to fix this problem the way we are > proposing now, but it's possible. > > If someone wants to go forward here, there would need to be a set of > patches that would create conflicting binary packages for both that will > divert /usr/bin/parallel. A patch on ikiwiki-hosting to depend on > moreutils-parallel would also then be necessary. Is dpkg-divert a strict requirement? Would alternatives suffices (e.g. like netcat does)? > Then we send this to the moreutils and gnu parallel maintainers to see > if they would accept the fix, and we can simply NMU it. > > But the main problem, to restate what Joey has said here, is time: it > takes time to do that work and unless someone steps up to help the > maintainers patiently to clear things up, things will stay as they > currently are. true, I am willing to give it a shot but we're probably far too late in the release cycle to get this into jessie (won't be wasted work anyway tho!) filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ God may not play dice with the universe, but something strange is going on with the prime numbers. -- Paul Erdos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734377: [Pkg-graphite-maint] Bug#734377: RFP: carbonate -- some primitive tools to help you manage your graphite clusters
On Sat, Nov 29, 2014 at 06:12:54PM +0100, Andreas Rütten wrote: > Hi Filippo, > > Am Thu, 27 Nov 2014 20:23:53 + > schrieb Filippo Giunchedi : > > > Hi Andreas, > > > > On Sun, Nov 23, 2014 at 11:19:24PM +0100, Andreas Rütten wrote: > > > Thank you very much for offering the sponsoring. > > > I already started the packaging work but as you said it's not > > > finished. > > > > > > You can find the current status there: > > > http://anonscm.debian.org/cgit/pkg-graphite/packages/carbonate.git/ > > > > nice! Should be fairly easy to add 0.2.2 too. I've requested access to > > pkg-graphite so can commit there if that's okay. (pkg-graphite CC'd) > > I just merged upstream version 0.2.2 to the git repo and updated the > manpages. But I didn't try to do build. > Nevertheless should be a good starting point to do something for > version 0.2.2 indeed, thanks for that! BTW I've requested access to pkg-graphite project a while back so I can help out with carbonate and others possibly, any news on that? thanks, filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. -- David Wheeler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772936: python-statsd: fails to import with django >= 1.5
Package: python-statsd Version: 2.0.1-1 Severity: grave Tags: upstream Justification: renders package unusable hi, python-statsd fails to import if python-django >= 1.5 is installed, see also this issue: https://github.com/jsocol/pystatsd/issues/24 django.core.exceptions.ImproperlyConfigured: Requested setting STATSD_HOST, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings. Fixed upstream by this commit: https://github.com/jsocol/pystatsd/commit/f28f6c988fc087388577cd5e8df28ca8d648c0e3 I think it makes sense to package the latest upstream version, I'll take a stab at that. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734377: RFP: carbonate -- some primitive tools to help you manage your graphite clusters
Hi Andreas, On Sun, Nov 23, 2014 at 11:19:24PM +0100, Andreas Rütten wrote: > Thank you very much for offering the sponsoring. > I already started the packaging work but as you said it's not finished. > > You can find the current status there: > http://anonscm.debian.org/cgit/pkg-graphite/packages/carbonate.git/ nice! Should be fairly easy to add 0.2.2 too. I've requested access to pkg-graphite so can commit there if that's okay. (pkg-graphite CC'd) > We are already in the freeze for jessie so I didn't put that at my > highest priority. But I have it definitely on my ToDo list. Yeah that's true, however we can upload to jessie-backports. That's what I'm planning to do with carbon-c-relay (#768983). HTH, filippo -- http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵ Have nothing in your house that you do not know to be useful, or believe to be beautiful. -- William Morris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734377: RFP: carbonate -- some primitive tools to help you manage your graphite clusters
On Mon, Jan 06, 2014 at 04:22 PM, Andreas Rütten wrote: > > Package: wnpp > Severity: wishlist > X-Debbugs-CC: pkg-graphite-ma...@lists.alioth.debian.org > > > * Package name: carbonate > Version : 0.2.0 hi, a new upstream version has been released, I'm willing to sponsor the upload if you are still looking for one. AFAICT the package hasn't been uploaded yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769612: unblock: bcache-tools/1.0.7-1
hi, thanks for taking care of the release! On Sun, Nov 16, 2014 at 06:11:38PM +0100, intrigeri wrote: > Control: tag -1 + moreinfo > > Hi Filippo, hi bcache-tools maintainers, > > [I'm not on the release team, just trying to give a hand.] > > Filippo Giunchedi wrote (15 Nov 2014 00:30:48 GMT) : > > This package didn't make it in time for the freeze, however jessie ships > > with a > > bcache-capable kernel so I think it is important to have userspace tools > > available. > > I acknowledge that giving Debian Jessie users the means to use bcache > feels somewhat important strategically, which *might* be a good enough > reason to make an exception to the freeze policy on this one. > > On the other hand: > > * Is there any strong reason why this use case cannot be addressed > via jessie-backports? (if it were *that* important to have in > Jessie, I guess the maintainers would probably have had it > uploaded way earlier) Yeah backports would work in this case > * This package was accepted into Debian for the first time less than > 3 weeks ago. What kind of testing has it seen? some debian users are running bcache-tools even now, https://qa.debian.org/popcon.php?package=bcache-tools it has been uploaded to fedora in may 2014, https://admin.fedoraproject.org/pkgdb/package/bcache-tools/ anyways, wheezy-backports will do thanks, filippo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708132: Jessie Freeze
On Thu, Nov 13, 2014 at 02:50:46PM +, Robie Basak wrote: > On Wed, Nov 12, 2014 at 09:00:15AM +0000, Filippo Giunchedi wrote: > > doesn't look like the package made in time for the freeze? > > https://qa.debian.org/excuses.php?package=bcache-tools > > > > I'm happy to try and request an unblock if not done already. > > I think somebody asked informally on IRC in #debian-release and was told > no. I'm not as familiar with the Debian release process as I'd like. If > you want to ask formally, go right ahead - I don't think anybody else > is. done, see #769612 filippo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769612: unblock: bcache-tools/1.0.7-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package bcache-tools This package didn't make it in time for the freeze, however jessie ships with a bcache-capable kernel so I think it is important to have userspace tools available. See also #708132 for more context. thanks! unblock bcache-tools/1.0.7-1 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708132: Jessie Freeze
On Mon, Oct 27, 2014 at 02:58 PM, Robie Basak wrote: > On Sat, Oct 25, 2014 at 09:28:00PM +0300, Jaakko Niemi wrote: > > I don't see the package in unstable yet, and Jessie release freeze is coming > > soon. Is there something needed? > > Thanks for the reminder. > > I was hoping that Gabriel would appear, pull my commits, and we'd leave > Vcs-Git pointing to his Github repo. But as he seems to be away, I've > followed up today and got bcache-tools uploaded to NEW. So this should > appear as soon as the ftpmasters have reviewed it. Hopefully that will > be in enough time to land in testing in time for freeze. doesn't look like the package made in time for the freeze? https://qa.debian.org/excuses.php?package=bcache-tools I'm happy to try and request an unblock if not done already. filippo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768983: ITP: carbon-c-relay -- Carbon-compatible graphite line mode relay
Package: wnpp Severity: wishlist Owner: Filippo Giunchedi * Package name: carbon-c-relay Version : 0.36 Upstream Author : Fabian Groffen * URL : https://github.com/grobian/carbon-c-relay * License : Apache 2 Programming Lang: C Description : Carbon-compatible graphite line mode relay This project provides a multithreaded relay which can address multiple targets and clusters for each and every metric based on pattern matches. .. Consistent-hash routing compatible with the original carbon's implementation is also provided. This relay also supports aggregation, failover of backend servers and more. .. Carbon is graphite's default storage backend and supports different protocols for receiving metrics, this project aims to be a replacement of graphite's original carbon-relay component and supports "plaintext" protocol metrics. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749355: parallel: /usr/bin/parallel conflicts with moreutils' parallel
hi, On Wed, Aug 06, 2014 at 01:30:04PM -0300, Rogério Brito wrote: > > But it seems no one objected to the solution of splitting it out in > > Debian at least, if the dependent packages are fixed. > > Yes, that would alleviate/solve the problem. definitely > > I can try to talk to people at debconf about this to see if I can unglue > > this mess directly. > > Unfortunately, I will not be at this debconf (even though I wanted to), but > if you can talk with Joey, that would be great. do you know if discussion happened at debconf? just came across this on a jessie system and it is really a sad state right now :( filippo -- http://esaurito.net - 0x001CDE6A6B79D401 - ⠠⠵ Those three things—autonomy, complexity, and a connection between effort and reward—are, most people agree, the three qualities that work has to have if it is to be satisfying. -- Malcolm Gladwell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756930: ssh-add: display bad perm warning only if private key is owned by the same user
Package: openssh-client Version: 1:6.6p1-6 Severity: normal File: /usr/bin/ssh-add hi, I noticed that ssh-add will display a warning: unprotected private key file and refuse to add the private material only when trying to add material owned by the same user calling ssh. However if the file is owned by another user but nevertheless world readable, nothing is displayed and the key can be added. in other words: godog@i7:~$ ssh-add -l The agent has no identities. godog@i7:~$ cd /tmp/ godog@i7:/tmp$ ssh-keygen -f test_id The key fingerprint is: 32:23:9e:da:84:8e:15:c6:e5:71:a6:f7:eb:30:25:99 godog@i7 godog@i7:/tmp$ chmod a+r test_id godog@i7:/tmp$ ssh-add test_id @@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@ Permissions 0644 for 'test_id' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. godog@i7:/tmp$ sudo chown nobody test_id [sudo] password for godog: godog@i7:/tmp$ ssh-add test_id Enter passphrase for test_id: Identity added: test_id (test_id) godog@i7:/tmp$ ssh-add -l 2048 32:23:9e:da:84:8e:15:c6:e5:71:a6:f7:eb:30:25:99 test_id (RSA) godog@i7:/tmp$ -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssh-client depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.10 ii libc6 2.19-7 ii libedit2 3.1-20140620-1 ii libgssapi-krb5-2 1.12.1+dfsg-5 ii libselinux1 2.3-1 ii libssl1.0.0 1.0.1h-3 ii passwd1:4.2-2 ii zlib1g1:1.2.8.dfsg-1 Versions of packages openssh-client recommends: ii xauth 1:1.0.9-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634172: /etc/spamassassin/sa-update-hooks.d output visible in /etc/cron.daily/spamassassin
Package: spamassassin Severity: minor Hi, it seems that when using run-parts for running /etc/spamassassin/sa-update-hooks.d the stdout is not redirected to /dev/null thus mailing root when e.g. spampd is restarted. trivial patch attached thanks, filippo -- System Information: Debian Release: 6.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Index: debian/spamassassin.cron.daily === --- debian/spamassassin.cron.daily (revision 18876) +++ debian/spamassassin.cron.daily (working copy) @@ -48,7 +48,7 @@ /etc/init.d/spamassassin reload > /dev/null fi if [ -d /etc/spamassassin/sa-update-hooks.d ]; then -run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d +run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d > /dev/null fi }
Bug#625501: backupninja: sys handler won't report hwinfo anymore, typo
Package: backupninja Version: 0.9.8.1-1 Severity: normal Hi, there's a typo in /usr/share/backupninja/sys which prevents it from running hwinfo: 545if [ "dohwinfo" == "yes" ]; then obviously, this should be $dohwinfo thanks, filippo -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages backupninja depends on: ii bash 4.1-3 The GNU Bourne Again SHell ii bsd-mailx [mailx] 8.1.2-0.20100314cvs-1 simple mail user agent ii dialog 1.1-20100428-1Displays user-friendly dialog boxe ii mawk 1.3.3-15 a pattern scanning and text proces backupninja recommends no packages. Versions of packages backupninja suggests: pn cdrdao (no description available) pn debconf-utils (no description available) pn dvd+rw-tools (no description available) pn genisoimage(no description available) pn hwinfo (no description available) pn mdadm (no description available) ii rdiff-backup 1.2.8-6remote incremental backup pn wodim (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583167: mutt: segfault while repeating a search with unmatched parenthesis
reopen 583167 found 583167 1.5.20-9 thanks On Thu, Dec 30, 2010 at 04:17:08PM +, Antonio Radici wrote: > > Hi, > > this is a reproducible segfault for me: > > - open mutt > > - type / > > - type any expression with unmatched parenthesis (like [foo) > > - type n > > - segfault > > > > Hi Filippo, > the bug is not reproducible on 1.5.20-9, therefore I'm resolving it. I've just reproduced it on mutt 1.5.20-9, I'm suspecting it is architecture related at this point (I'm on amd64). The core file can be found at http://people.debian.org/~filippo/mutt_core_583167.gz for further investigation filippo -- Filippo Giunchedi - http://esaurito.net - 0x6B79D401 - ⠠⠵ "I drank what?" -- Socrates -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601227: Patch accepted upstream
On Tue, Nov 30, 2010 at 02:17:51AM +0100, Javier Fernández-Sanguino Peña wrote: > On Mon, Nov 29, 2010 at 07:27:35PM +0000, Filippo Giunchedi wrote: > > please do, I'm actually orphaning the package as I've neglected it too much > > lately. Would you be interested in case? > > Sure I can take it, I've recently uploaded sshuttle to the archive (from the > same upstream author). Sounds good to me, feel free to upload whenever you like. thanks, filippo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605423: RFA: autossh -- Automatically restart SSH sessions and tunnels
On Tue, Nov 30, 2010 at 02:39:28PM +0100, Axel Beckert wrote: > Filippo Giunchedi wrote: > > I request an adopter for the autossh package. I currently don't have time to > > properly take care of the package. > > I'm a heavy user of autossh (it's also mentioned in my SSH tips and > tricks talk), and would take care of the package as I do care about > that package. thanks! I appreciate it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605423: RFA: autossh -- Automatically restart SSH sessions and tunnels
Package: wnpp Severity: normal I request an adopter for the autossh package. I currently don't have time to properly take care of the package. The package description is: autossh is a program to start an instance of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea is from rstunnel (Reliable SSH Tunnel), but implemented in C. Connection monitoring is done using a loop of port forwardings. It backs off on the rate of connection attempts when experiencing rapid failures such as connection refused. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601227: Patch accepted upstream
On Mon, Nov 29, 2010 at 12:36:06AM +0100, Javier Fernández-Sanguino Peña wrote: > On Wed, Oct 27, 2010 at 11:25:28PM +0200, Javier Fern?ndez-Sanguino Pe?a > wrote: > > > > Just wanted to let you know that I've submitted the patch upstream and Avery > > has agreed to include it in the upstream repository [1]. > > [1 month later... no response from the Debian maintainer...] sorry about that, of course I meant to reply and actually forgot. > > Is there any possibility of this patch being included in the Debian package? > Without it, netselect-apt is certainly useless as many ftp Debian mirrors do > *not* allow traceroute-like probes. > > I wouldn't mind doing a NMU to fix this bug (and maybe others). Would that be > an option? please do, I'm actually orphaning the package as I've neglected it too much lately. Would you be interested in case? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590499: isight-firmware-tools: missing usb product id 0x8501
Package: isight-firmware-tools Version: 1.4.2-3 Severity: normal Hi, I seem to have a different isight from what is specified in the callout: Bus 002 Device 018: ID 05ac:8501 Apple, Inc. Built-in iSight [Micron] Adding the 8501 product id seems to do the trick for me -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.34-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages isight-firmware-tools depends on: ii debconf [debconf-2.0]1.5.33 Debian configuration management sy ii dpkg 1.15.7.2Debian package management system ii hal 0.5.14-3Hardware Abstraction Layer ii libc62.11.2-2Embedded GNU C Library: Shared lib ii libdbus-1-3 1.2.24-2simple interprocess messaging syst ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libglib2.0-0 2.24.1-1The GLib library of C routines ii libhal1 0.5.14-3Hardware Abstraction Layer - share ii libusb-0.1-4 2:0.1.12-15 userspace USB programming library isight-firmware-tools recommends no packages. isight-firmware-tools suggests no packages. -- debconf information: * isight-firmware-tools/extract_success: * isight-firmware-tools/extract: true isight-firmware-tools/extract_fail: isight-firmware-tools/file_not_exist: * isight-firmware-tools/driver-location: /media/osx/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS/AppleUSBVideoSupport -- debsums errors found: debsums: changed file /usr/share/hal/fdi/preprobe/20thirdparty/50-isight-firmware.fdi (from isight-firmware-tools package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583167: mutt: segfault while repeating a search with unmatched parenthesis
Package: mutt Version: 1.5.20-7 Severity: normal Hi, this is a reproducible segfault for me: - open mutt - type / - type any expression with unmatched parenthesis (like [foo) - type n - segfault hope that helps, filippo -- Package-specific info: Mutt 1.5.20 (2009-06-14) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.34-rc5 (x86_64) ncurses: ncurses 5.7.20100313 (compiled with 5.7) libidn: 1.18 (compiled with 1.15) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Nov 21 2009 09:33:57) Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. patch-1.5.13.cd.ifdef.2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.34-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mutt depends on: ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libcomerr21.41.12-1 common error description library ii libgdbm3 1.8.3-9GNU dbm database routines (runtime ii libgnutls26 2.8.6-1the GNU TLS library - runtime libr ii libgpg-error0 1.6-1 library for common error values an ii libgpgme111.2.0-1.2 GPGME - GnuPG Made Easy ii libgssapi-krb5-2 1.8.1+dfsg-3 MIT Kerberos runtime libraries - k ii libidn11 1.18-1 GNU Libidn library, implementation ii libk5crypto3 1.8.1+dfsg-3 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.1+dfsg-3 MIT Kerberos runtime libraries ii libncursesw5 5.7+20100313-2 shared libraries for terminal hand ii libsasl2-22.1.23.dfsg1-5 Cyrus SASL - authentication abstra Versions of packages mutt recommends: ii libsasl2-modules 2.1.23.dfsg1-5 Cyrus SASL - pluggable authenticat ii locales 2.10.2-9 Embedded GNU C Library: National L ii mime-support 3.48-1 MIME files 'mime.types' & 'mailcap ii postfix [mail-transport-a 2.7.0-1High-performance mail transport ag Versions of packages mutt suggests: ii aspell0.60.6-4 GNU Aspell spell-checker ii ca-certificates 20090814 Common CA certificates ii gnupg 1.4.10-3 GNU privacy guard - a free PGP rep pn mixmaster (no description available) ii openssl 0.9.8n-1 Secure Socket Layer (SSL) binary a pn urlview(no description available) Versions of packages mutt is related to: ii mutt 1.5.20-7 text-based mailreader supporting M pn mutt-dbg (no description available) pn mutt-patched (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535074: topgit: have patch export full history
Hi Uwe, On Sat, Apr 10, 2010 at 03:47:07PM +0200, Uwe Kleine-König wrote: > > Not necessarily, if I know the branch is for upstream consumption I can > > rework > > the history to be clean. > > > > Anyhow, and that's the whole point, I can't use git format-patch on a topgit > > branch unless I remember to manually exclude .topgit and .topdeps, otherwise > > upstream will get those as well. > > > > > I assume you don't mean with incremental that you only send the new > > > changes if you send an updated patch, do you? > > > > correct > > > > [omitting the rest, but thanks for the suggestion] > What do you think on this bug today? I consider it OK to close it as > "invalid" or somthing like that. I tend to agree, yes, if one wants to use format-patch then it is easy to alias it to something and exclude .topgit and .topdeps, please go ahead thanks, filippo -- Filippo Giunchedi - http://esaurito.net - 0x6B79D401 I was once walking through the forest alone. A tree fell right in front of me -- and I didn't hear it. -- Steven Wright -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org