Bug#1025012: zookeeper: starts but is completely unusable

2024-05-24 Thread Filippo Giunchedi
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

2024-03-26 Thread Filippo Giunchedi
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))

2024-01-26 Thread Filippo Giunchedi
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

2021-10-06 Thread Filippo Giunchedi
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

2021-09-25 Thread Filippo Giunchedi
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

2021-09-10 Thread Filippo Giunchedi
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

2021-09-07 Thread Filippo Giunchedi
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

2021-08-31 Thread Filippo Giunchedi
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

2021-08-24 Thread Filippo Giunchedi
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,
+  ignore_trailing=

Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

2021-08-24 Thread Filippo Giunchedi
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/client

Bug#971530: dnspython 2.x breaks all of OpenStack

2021-08-24 Thread Filippo Giunchedi
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

2021-06-08 Thread Filippo Giunchedi
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

2021-06-08 Thread Filippo Giunchedi
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

2021-06-01 Thread Filippo Giunchedi
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

2021-05-26 Thread Filippo Giunchedi
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

2021-04-18 Thread Filippo Giunchedi
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

2021-03-19 Thread Filippo Giunchedi
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

2021-03-16 Thread Filippo Giunchedi
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

2021-03-16 Thread Filippo Giunchedi
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

2021-01-17 Thread Filippo Giunchedi
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

2021-01-16 Thread Filippo Giunchedi
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

2020-12-04 Thread Filippo Giunchedi
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=armhf=3.0.0%7Erc38-1=1606840174=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

2020-11-20 Thread Filippo Giunchedi
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

2020-11-20 Thread Filippo Giunchedi
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

2020-11-20 Thread Filippo Giunchedi
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

2020-11-12 Thread Filippo Giunchedi
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

2020-10-26 Thread Filippo Giunchedi
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

2020-10-25 Thread Filippo Giunchedi
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.

2020-04-28 Thread Filippo Giunchedi
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

2020-04-28 Thread Filippo Giunchedi
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

2019-07-16 Thread Filippo Giunchedi
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

2019-02-07 Thread Filippo Giunchedi
Package: ftp.debian.org
Severity: normal



Bug#917412: debirf: parallel xz compression

2018-12-27 Thread Filippo Giunchedi
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

2018-12-27 Thread Filippo Giunchedi
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:
ii  apt1.8.0~alpha2
ii  python3   

Bug#917393: debirf: Generated iso fails to boot in KVM with "Could not read from CDROM (code 0009)"

2018-12-27 Thread Filippo Giunchedi
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.

2018-12-27 Thread Filippo Giunchedi
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/

2018-11-27 Thread Filippo Giunchedi
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

2018-10-19 Thread Filippo Giunchedi
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

2018-10-18 Thread Filippo Giunchedi
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

2018-09-19 Thread Filippo Giunchedi
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

2018-09-19 Thread Filippo Giunchedi
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

2018-09-19 Thread Filippo Giunchedi
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

2018-04-20 Thread Filippo Giunchedi
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

2018-03-26 Thread Filippo Giunchedi
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

2017-08-23 Thread Filippo Giunchedi
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

2017-07-28 Thread Filippo Giunchedi
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

2017-07-28 Thread Filippo Giunchedi
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

2017-06-05 Thread Filippo Giunchedi
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

2016-11-04 Thread Filippo Giunchedi
Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi <fili...@debian.org>

* 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

2016-09-21 Thread Filippo Giunchedi
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

2016-08-26 Thread Filippo Giunchedi
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

2016-05-22 Thread Filippo Giunchedi
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 <tin...@debian.org>  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

2016-05-20 Thread Filippo Giunchedi
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

2016-03-26 Thread Filippo Giunchedi
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

2016-03-26 Thread Filippo Giunchedi
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

2016-03-26 Thread Filippo Giunchedi
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

2016-03-25 Thread Filippo Giunchedi
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 {
aws: {
@@ -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 := {
Source: *ed.aws.Region,
}

filippo
-- 
http://esaurito.net - 0x99D49B6B00CAD1E5 - ⠠⠵



Bug#817790: golang-github-aws-aws-sdk-go: new upstream version?

2016-03-10 Thread Filippo Giunchedi
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

2016-03-09 Thread Filippo Giunchedi
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

2016-02-22 Thread Filippo Giunchedi
Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi <fili...@debian.org>

* Package name: prometheus-mysqld-exporter
  Version : 0.7.1
  Upstream Author : Julius Volz <julius.v...@gmail.com>
Brian Brazil <brian.bra...@boxever.com>
* 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

2016-02-17 Thread Filippo Giunchedi
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

2016-02-16 Thread Filippo Giunchedi
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

2015-12-07 Thread Filippo Giunchedi
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

2015-10-22 Thread Filippo Giunchedi
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

2015-07-10 Thread Filippo Giunchedi
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

2015-06-30 Thread Filippo Giunchedi
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

2015-06-28 Thread Filippo Giunchedi
Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi fili...@debian.org

* Package name: structlog
  Version : 15.2.0
  Upstream Author : Hynek Schlawack h...@ox.cx
* 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

2015-06-23 Thread Filippo Giunchedi
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#775930: [lvs-users] [PATCH] ipvsadm: add SCTP support

2015-06-23 Thread Filippo Giunchedi
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#768983: [Pkg-graphite-maint] ITP: carbon-c-relay -- status?

2015-05-27 Thread Filippo Giunchedi
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?

2015-05-21 Thread Filippo Giunchedi
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?

2015-05-16 Thread Filippo Giunchedi
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?

2015-05-13 Thread Filippo Giunchedi
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?

2015-05-12 Thread Filippo Giunchedi
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#768983: ITP: carbon-c-relay -- status?

2015-05-12 Thread Filippo Giunchedi
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#782795: python-pip: breaks with relocatable virtualenv, assert sys.prefix != real_prefix

2015-04-17 Thread Filippo Giunchedi
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 module
from pip import main
  File /tmp/venv/local/lib/python2.7/site-packages/pip/__init__.py, line 39, 
in module
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:anynone

Versions of packages python-pip recommends:
ii  build-essential  11.7
pn  python-dev-all   none
pn  python-wheel none

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)

2015-02-25 Thread Filippo Giunchedi
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

2015-02-15 Thread Filippo Giunchedi
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

2015-01-09 Thread Filippo Giunchedi
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 fili...@debian.org:
 
  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

2014-12-12 Thread Filippo Giunchedi
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

2014-11-27 Thread 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)

 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#769612: unblock: bcache-tools/1.0.7-1

2014-11-21 Thread Filippo Giunchedi
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#734377: RFP: carbonate -- some primitive tools to help you manage your graphite clusters

2014-11-21 Thread Filippo Giunchedi
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

2014-11-14 Thread Filippo Giunchedi
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

2014-11-14 Thread Filippo Giunchedi
On Thu, Nov 13, 2014 at 02:50:46PM +, Robie Basak wrote:
 On Wed, Nov 12, 2014 at 09:00:15AM +, 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#708132: Jessie Freeze

2014-11-12 Thread Filippo Giunchedi
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

2014-11-10 Thread Filippo Giunchedi
Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi fili...@debian.org

* 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

2014-09-26 Thread Filippo Giunchedi
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

2014-08-03 Thread Filippo Giunchedi
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  none
pn  libpam-sshnone
pn  monkeysphere  none
pn  ssh-askpass   none

-- 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

2011-07-17 Thread Filippo Giunchedi
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

2011-05-03 Thread Filippo Giunchedi
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  cdrdaonone (no description available)
pn  debconf-utils none (no description available)
pn  dvd+rw-tools  none (no description available)
pn  genisoimage   none (no description available)
pn  hwinfonone (no description available)
pn  mdadm none (no description available)
ii  rdiff-backup  1.2.8-6remote incremental backup
pn  wodim none (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

2010-12-31 Thread Filippo Giunchedi
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#605423: RFA: autossh -- Automatically restart SSH sessions and tunnels

2010-11-30 Thread Filippo Giunchedi
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#601227: Patch accepted upstream

2010-11-30 Thread Filippo Giunchedi
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 +, 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#601227: Patch accepted upstream

2010-11-29 Thread Filippo Giunchedi
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#605423: RFA: autossh -- Automatically restart SSH sessions and tunnels

2010-11-29 Thread Filippo Giunchedi
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#590499: isight-firmware-tools: missing usb product id 0x8501

2010-07-26 Thread Filippo Giunchedi
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

2010-05-25 Thread Filippo Giunchedi
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 mutt-...@mutt.org.
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 none (no description available)
ii  openssl   0.9.8n-1   Secure Socket Layer (SSL) binary a
pn  urlview   none (no description available)

Versions of packages mutt is related to:
ii  mutt  1.5.20-7   text-based mailreader supporting M
pn  mutt-dbg  none (no description available)
pn  mutt-patched  none (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

2010-04-10 Thread Filippo Giunchedi
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



Bug#573440: vim-scripts: gnupg.vim wipes a file on misspelled passphrase with :wq

2010-03-11 Thread Filippo Giunchedi
Package: vim-scripts
Version: 20091011
Severity: normal

Hi,
while using gnupg.vim with symmetric cipher I noticed that on :wq (an habit of
mine, but I guess of many other vim users) if you mistype the passphrase on
prompt the written file will be empty and vim will exit, IOW the file is
truncated.

A suggested temporary fix is to have the file without write permission so vim
will refuse to write on :wq, though it would be nice if the plugin can abort
the command sequence, not sure if that's possibile though.

thanks,
filippo

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.33-rc8 (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

vim-scripts depends on no packages.

Versions of packages vim-scripts recommends:
ii  vim  2:7.2.330-1 Vi IMproved - enhanced vi editor
ii  vim-addon-manager0.4.3   manager of addons for the Vim edit
ii  vim-gnome [vim]  2:7.2.330-1 Vi IMproved - enhanced vi editor -

Versions of packages vim-scripts suggests:
ii  libtemplate-perl  2.20-1 template processing system written
pn  perlsgml  none (no description available)

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/vim-scripts/plugin/DoxygenToolkit.vim (from 
vim-scripts package)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



  1   2   3   4   5   6   7   8   9   10   >