Bug#929954: [python-reportlab] 3.5.21-1 breaks rst2pdf

[devel]

control: tags -1 +patch +fixed-upstream


Hello,


On Wed, 5 Jun 2019 11:02:38 +0200 Matthias Klose  wrote:
> Control: reassign -1 rst2pdf
> 
> not sure how that worked in the past, but flowables.py is using
> reportlab.Version without importing it.

I tracked it down for fun (with v2.6 of reportlab):
1) evil wildcard import of "reportlab.platypus.doctemplate"
2) "import reportlab.lib.sequencer" secretly imported "reportlab" into
   the global namespace (which was imported via the wildcard above)

The trivial upstream fix for this import issue is here (0.94-151-gc6662f91):
 
https://github.com/rst2pdf/rst2pdf/commit/c6662f914013d3423130f0ad8c7b2e443613af97

Cheers,
Lars

Bug#901338: gitlab: dependency on postgresql-contrib pulls in postgresql server

[devel]

Hello,


On Mon, 11 Jun 2018 18:39:42 +0200 Frederik Himpe  wrote:
> Personally I already have a postgresql server running on another host,
> which I want to use for gitlab, so I would prefer a suggest or recommend
> dependency instead of a hard dependency.

same for me: given the complexity of a gitlab installation itself, it is a
reasonable decision to separate the database server from the gitlab host itself.
I assume, this is a common approach for for many non-trivial gitlab setups.


The policy [1] describes the "Recommends" field as follows:

> The Recommends field should list packages that would be found together with
> this one in all but unusual installations.

I am tempted to say, that the dependency on the postgresql server should be
even lighter (e.g. "Suggests"). But I understand, that it will be helpful for
beginners to achieve a complete single-host setup with apt's default behaviour.
Thus "Recommends" may be a suitable option.

Anyway: the current usage of "Depends" for "postgresql-contrib" feels
inappropriate to me.

Cheers,
Lars


[1] https://www.debian.org/doc/debian-policy/ch-relationships.html

Bug#928211: munin-plugins-core: open_files max is 18 quintillion (since systemd 240), obscuring graph

[devel]

Control: tags -1 + fixed-upstream


Hello Gerald,


On Mon, 29 Apr 2019 14:47:32 -0700 Gerald Turner  wrote:
> Attached patch that removes the insanely large ‘max' value.

Thank you for providing a fix for this issue. I committed it upstream (to be
released with v2.0.48):
 
https://github.com/munin-monitoring/munin/commit/403a2e637db9abd38737bb1c81172ec902a9a62a


> Note that calculated warning/critical for ‘used' are still absurdly
> large.  Perhaps it would be useful if the plugin would read
> configuration environment variables so that an admin could override them
> with meaningful values (tens of thousands rather than quintillions).

It is already possible to override the warning and critical values via
environment variables, e.g. "warning" or "used_warning" (the same goes for
"critical"). This ability is sadly not too well documented.
I hope, this helps!

Cheers,
Lars

Bug#927093: the netstat plugin fails with current versions of netstat

[devel]

Hello Marco,

thank you for your bug report!


Am Mon, 15 Apr 2019 04:26:28 +0200
schrieb Marco d'Itri :

> Package: munin-plugins-core
> Version: 2.0.47-1
> Severity: normal
> Tags: upstream newcomer patch
> 
> The netstat plugin does not report anymore the value of active.value 
> because the output of netstat has changed.
> 
> Pseudo-patch:
> 
> -/active connections ope/  { print "active.value " $1 }
> +/active connections? ope/  { print "active.value " $1 }

Are you sure, that you encountered this with the current munin package?

The above issue should have been fixed in munin 2.0.35 [1].

Cheers,
Lars


[1] 
https://github.com/munin-monitoring/munin/commit/f2094f8f8e00d77e3fe3285d5e5c870e2aa4bedd

Bug#926979: munin: autopkgtest compatibility for systemd-only derivatives

[devel]

Hello Steve,


Am Fri, 12 Apr 2019 22:28:21 -0700
schrieb Steve Langasek :

> Package sysvinit-core is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> However the following packages replace it:
>   systemd-sysv
> 
> autopkgtest [20:35:15]: test master-sysvinit-cron: ---]
> master-sysvinit-cron FAIL non-zero exit status 100
> [...]
> 
>   
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/m/munin/20190412_204534_b9ff8@/log.gz)
> 
> It seems to me this could be sidestepped by having the test declare a
> dependency on sysvinit-core instead of installing it as part of the test,
> and also using Restrictions: skip-not-installable.

Thank you for this suggestion!

After taking a quick look at my comments in the test scripts, I am afraid, that
the test dependency may not work without further changes:
 
https://salsa.debian.org/debian/munin/blob/debian/debian/tests/enable_sysvinit.inc#L8

I will take a closer look at this issue after the release of Buster.

Cheers,
Lars

Bug#483617: reassign

[devel]

Control: forwarded -1 https://github.com/munin-monitoring/munin/issues/1175
Control: tags -1 +fixed-upstream

Hello,


On Sat, 11 Feb 2012 10:40:28 +0100 Petter Reinholdtsen  wrote:
> Well, unless you can show me an example munin-node.conf file setting the
> reverse_lookups argument to Net::Server, I believe you are wrong.  I
> find no trace of any code in munin-node allowing the user to set this
> argument for Net::Server.  This make me convinced this issue need to be
> solved in munin-node, not Net::Server.

Yes, indeed the "reverse_lookups" argument is not passed to Net::Server at the
moment.


> One way to solve it would be to use the allow_deny_hook mechanism
> provided by Net::Server to look up connecting hosts using innetgr.
> Another and less flexible way would be to make it possible to set the
> reverse_lookups argument to Net::Server.

Allowing "reverse_lookups" is the easiest way forward.
But sadly Net::Server exposes two problems at the moment:
* CPAN #129377 [1]: no reverse DNS resolution if munin-node is bound to an IPv6
  socket (applicable for most hosts)
* CPAN #83909 [2] / Debian #702914 [3]: the reverse DNS name is not verified
  (it can easily be spoofed by anyone)

We just included the "reverse_lookups" setting upstream in commit 574d102b32 (to
be released as 2.0.48).
This should fix this issue as far as munin is converned. But the two issues with
Net::Server remain open.

Cheers,
Lars


[1] https://rt.cpan.org/Ticket/Display.html?id=129377
[2] https://rt.cpan.org/Public/Bug/Display.html?id=83909
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702914
[4] 
https://github.com/munin-monitoring/munin/commit/574d102b322b23da72e687c7cbe130d28f8fa8e2

Bug#933748: munin-httpd is unable to access new sqlite database

[devel]

Source: munin
Version: 2.999.12-1
Severity: important
Tags: upstream
Forwarded: https://github.com/munin-monitoring/munin/issues/1212

Hello,

since munin 2.999.12 the default settings for new sqlite databases
(the default database created automatically after package installation)
prevents the database from being accessed by munin-httpd.  Thus the
web interface is broken (status 500).

The issue can be resolved by changing the database journal mode after
the file was created:

  echo "PRAGMA journal_mode=delete;" | su -s /bin/bash -c "sqlite3 
/var/lib/munin/datafile.sqlite" munin

Upstream is discussing the proper solution for this issue:

  https://github.com/munin-monitoring/munin/issues/1212

Cheers,
Lars

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hello Paolo,


Am Sat, 10 Aug 2019 22:21:42 +0200
schrieb Paolo Benvenuto :

> > The problem with creating /var/log/munin/munin-node.log seems to be the
> > culprit.
> > The directory should habe been created by the systemd component
> > "munin.tmpfile"
> > during bootup.
> > I am confused, that this directory is missing on your host.
> >
> >  
> The only thing I saw: /var/log/munin/munin-node.log had root:root owner, I
> changed to munin:adm, but the service fails the same way.

ok - the directory exists - thus the problem seems to be an access issue when
the service is started via systemd.
I could imagine an issue with any kind of sandboxing configured on your host.

Maybe for a start: take a look at
/etc/systemd/system/multi-user.target.wants/munin-node.service. There you can
see the following execution parameters:
  PrivateDevices=false
  PrivateTmp=true
  ProtectHome=true
  ProtectSystem=full
Please comment out all of them and check, whether the service still fails.
(the above change modifies a file of the package - not a conffile - thus the
change will get lost with the next package upgrade)

If this fixes the issue, then please find out, which of the setting is causing
the failure.

If this does not fix the issue, then maybe you could think of any kind of
sandboxing security feature, that you configured for this host or its
virtualization provider? (selinux, apparmor, ...)

Cheers,
Lars

Bug#934334: munin-plugins-extra: please package asterisk multigraph plugin from munin-contrib

[devel]

Hello Gabriel,


Am Fri, 09 Aug 2019 17:34:02 -0400
schrieb Gabriel Filion :

> I've been using the multigraph plugin for asterisk that's present in
> the munin-contrib repository for a number of years and find it nice.
> 
> I was wondering if this package would be well suited for including it.
> 
> For what it's worth, the asterisk_* plugins that are shipped with the
> package don't seem to work with the version of asterisk in buster.

Yes, the following bug reports indicate a problem for quite some time:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713891
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806173

Your suggestion sounds like it would fix both issues and make that plugin
finally usable again.


> However, I've had to fix the plugin to make it parse the AMI response
> correctly for newer versions of asterisk. I would recommend to wait for
> the changes in the following PR to be merged in:
> 
> https://github.com/munin-monitoring/contrib/pull/1005

I just merged it now.


At the moment we do not really have a process, how plugins are moved into (or
out of) munin's core repository (which is used as the base of the Debian
packging). We will discuss this during our next weekly IRC meeting. [1]

Thank you for your suggestion!

Cheers,
Lars


[1] http://munin-monitoring.org/wiki/Community#Chat-Meetings

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hello Paolo,


Am Sat, 10 Aug 2019 16:10:38 +0200
schrieb Paolo Benvenuto :

> I killed munin-node, and then restarted the service. The log says:
> 
> 2019/08/10-16:03:15 Munin::Node::Server (type Net::Server::Fork) starting!
> pid(4573)
> Resolved [*]:4949 to [::]:4949, IPv6
> Not including resolved host [0.0.0.0] IPv4 because it will be handled by
> [::] IPv6
> Binding to TCP port 4949 on host :: with IPv6
> 
> ipv6??

This is fine: munin-node supports IPv4 and IPv6.
Binding to an IPv6 port by default also means binding to the respective IPv4
port (see "/proc/sys/net/ipv6/bindv6only").


> sudo systemctl start  munin-node.service ; journalctl -xe
> 
> I get:
> 
> ago 10 16:07:48 catho2 systemd[1]: Starting Munin Node...
> -- Subject: L'unità munin-node.service inizia la fase di avvio
> -- Defined-By: systemd
> -- Support: https://www.debian.org/support
> -- 
> -- L'unità munin-node.service ha iniziato la fase di avvio.
> ago 10 16:07:48 catho2 munin-node[10019]: Couldn't open log file
> "/var/log/munin/munin-node.log" [No such file or directory]. at
> /usr/share/perl5/Net/Server.pm line 209.
> ago 10 16:07:48 catho2 systemd[1]: munin-node.service: Control process
> exited, code=exited, status=2/INVALIDARGUMENT

The problem with creating /var/log/munin/munin-node.log seems to be the culprit.
The directory should habe been created by the systemd component "munin.tmpfile"
during bootup.
I am confused, that this directory is missing on your host.

Do you have an idea?

Cheers,
Lars

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hallo Paolo,


Am Fri, 9 Aug 2019 16:12:17 +0200
schrieb Paolo Benvenuto :

> > What is the result of running "munin-node" directly (as root)?
> >
> > # munin-node  
> doesn't produce any error
> 
> after that:
> 
> $ ps ax|grep munin
> 12471 ?Ss 0:00 /usr/bin/perl -wT /usr/sbin/munin-node

This is weird. The systemd service should have done the same.


> and it seems that something more is executed every 5 minutes.

This is a either a cron job (on the munin master) or the executed plugins on a
node (being requested by the master).

I still do not understand, the (trivial) systemd service should fail.

Did you take a look at /var/log/munin/munin-node.log?
(scrolling back to the time before your manual start)

Do you have any other idea for debugging the service on your host?
Otherwise I would suggest something quite low-level:
add "strace -o /tmp/munin-node-service.log -f" in front of the "ExecStart" in
the munin-node service file
(/etc/systemd/system/multi-user.target.wants/munin-node.service).

Cheers,
Lars

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hello Paolo,

thank for helping us finding the root cause of this problem!


Am Sun, 11 Aug 2019 10:12:36 +0200
schrieb Paolo Benvenuto :

> > I could imagine an issue with any kind of sandboxing configured on your
> > host.
> 
> What is a sandboxing? I am running a server, without any chroot or anything
> similar

Maybe "sandboxing" is not a very precise term. I wanted to refer to software,
that restricts programs in any way. SELinux and apparmor are popular examples.
Also the "seccomp" (Ithink) features configured in our systemd services
definitions are such kind of sandboxing methods. Virtualization (like docker)
can also enforce some restrictions on running processes.


> > Maybe for a start: take a look at
> > /etc/systemd/system/multi-user.target.wants/munin-node.service. There you
> > can
> > see the following execution parameters:
> >   PrivateDevices=false
> >   PrivateTmp=true
> >   ProtectHome=true
> >   ProtectSystem=full
> > Please comment out all of them and check, whether the service still fails.
> > (the above change modifies a file of the package - not a conffile - thus
> > the change will get lost with the next package upgrade)
>
> I commented them out, now the service starts!

Great - this is good to know!


> > If this fixes the issue, then please find out, which of the setting is
> > causing the failure.
>
> how?!?!

You can stop the service again, remove some of the comments and try to start it
again, until you find the minimal set of options, that need to be disabled for
you.
Afterwards we (munin packagers) can try to find out, under which circumstances
this specific restriction could cause a problem.

At the moment I suspect, that /var/log/munin is somehow symlinked on your
system into /tmp or /run. But this is just a very wild guess.

Thank you for your help!

Cheers,
Lars

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hello Paolo,


Am Sun, 11 Aug 2019 21:18:58 +0200
schrieb Paolo Benvenuto :

> > At the moment I suspect, that /var/log/munin is somehow symlinked on your
> > system into /tmp or /run. But this is just a very wild guess.
> >
> > actually /var/log is a symlink to /home/log  
> 
> Would it be the reason of the problem?

yes, "PrivateTmp=true" would create a separate (empty) /tmp directory in the
namespace of the munin-node process (see "man systemd.service").
Thus if you symlinked /var/log/munin to /tmp/munin-log (or something similar),
then /tmp/munin-log would not exist for the new munin-node process.

Are you using such a setup? In this case I would recommend to mount a tmpfs
onto /var/log/munin or /var/log instead. The munin service files supports such a
read-only customization without changes.

Cheers,
Lars

Bug#939199: munin: [INTL:fr] French debconf templates translation

[devel]

Control: tags -1 pending

Hello Jean-Pierre,


Am Mon, 2 Sep 2019 11:01:19 +0200
schrieb Jean-Pierre Giraud :

> Please find attached the french debconf templates translation, proofread
> by the debian-l10n-french mailing list contributors.

thank you for your contribution!

Cheers,
Lars

Bug#914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder

[devel]

Hello,


On Sun, 17 Mar 2019 18:39:10 +0100 bernha...@mailbox.org wrote:

> Therefore I would propose to
> - reassign this bug 914150 to libfm/1.3.0-1
> - clone it and reassign the clone to librsvg2-common/2.44.10-1
> - and close this bug 914150

this sounds reasonable to me.

In my local installation, I solved this issue by upgrading librsvg2-common (and
librsvg2-2) from 2.44.10-2.1 to 2.44.14-1.

Thus Bernhard's suggestion regarding the patch for librsvg2 would probably be a
great relief for many LXDE users on Buster.

Cheers,
Lars

Bug#939339: munin-node: systemd hardening hurts the df plugin

[devel]

Hello,


thank you for your suggestion!


Am Tue, 03 Sep 2019 17:11:55 +0200
schrieb Ferenc Wágner :

> Today I noticed that my /home mount is not graphed by the df plugin
> against my expectations.  After too much debugging I realized that the
> ProtectHome=true setting in /lib/systemd/system/munin-node.service
> causes the problem.  After overriding it, the missing graph reappeared.
> Please consider dropping this directive from the unit file.

yes, there were also a few issues raised and a few questions asked via IRC.
The difference between executing "munin-run" and deploying the plugin in a real
environment can be an annoying source of confusion.
But the hardening directives can be of really good use, since they prevent
misbehaving or insecure plugins from causing damage.

Thus I am not sure, how we should proceed.

At the moment I see the following options:
A) make these hardening flags configurable via debconf during
   installation/upgrade
   (I would need to investigate, how systemd units can be configured properly)
B) disable hardening flags and mention their activation in README.Debian
C) keep the hardening flags and somehow allow "munin-run" to use the same set
   of hardening flags, that the munin-node service uses.
   (or something along these lines - it feels really complicated)

Any other opinions?

Cheers,
Lars

Bug#932774: ircd-hybrid: Segfault in libgmp.so.10.3.2

[devel]

Hello Nicalos,


Am Wed, 7 Aug 2019 11:27:17 +0200
schrieb Nicolas Schier :

> > after upgrading a host from Stretch to Buster, ircd-hybrid fails to
> > start:  
> 
> Same for me.  I could made it work again by running
> 
> certtool --generate-dh-params --sec-param=medium --outfile 
> /etc/ircd-hybrid/dhparam.pem
> 
> and enabling the corresponding config line in /etc/ircd-hybrid/ircd.conf:
> 
> ssl_dh_param_file = "/etc/ircd-hybrid/dhparam.pem";
> .
> 
> Do you have a dhparam.pem file, and enabled the config setting?

yes, these two changes fixed the issue for me. Thank you!

A segfault seems to be quite a mysterious response to such a situation :(

Cheers,
Lars

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hello Paolo,

thank you for your bug report!


Am Thu, 08 Aug 2019 19:36:08 +0200
schrieb Paolo Benvenuto :

> I had munin and munin-node working well on stretch, after upgrading to buster
> munin-node service doesn't start any more.

That sounds unpleasant.

Did you already find a reason for this behaviour?
What is the result of running "munin-node" directly (as root)?

Cheers,
Lars

Bug#932774: ircd-hybrid: Segfault in libgmp.so.10.3.2

[devel]

Source: ircd-hybrid
Version: 1:8.2.24+dfsg.1-1
Severity: normal

Dear Maintainer,

after upgrading a host from Stretch to Buster, ircd-hybrid fails to
start:

  irc@example:~$ ircd-hybrid -foreground
  ircd: version hybrid-1:8.2.24+dfsg.1-1(20180404_8492)
  ircd: pid 32127
  ircd: running in foreground mode from /usr
  Segmentation fault


gdb shows the following output:

  irc@example:~$ gdb --args ircd-hybrid -foreground
  GNU gdb (Debian 8.2.1-2) 8.2.1
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ircd-hybrid...(no debugging symbols found)...done.
  (gdb) run
  Starting program: /usr/sbin/ircd-hybrid -foreground
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  ircd: version hybrid-1:8.2.24+dfsg.1-1(20180404_8492)
  ircd: pid 28120
  ircd: running in foreground mode from /usr

  Program received signal SIGSEGV, Segmentation fault.
  0x7765a5f0 in __gmpz_sizeinbase () from 
/usr/lib/x86_64-linux-gnu/libgmp.so.10
  (gdb) bt
  #0  0x7765a5f0 in __gmpz_sizeinbase () from 
/usr/lib/x86_64-linux-gnu/libgmp.so.10
  #1  0x77f3acce in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
  #2  0x77e6e1b4 in gnutls_certificate_set_dh_params () from 
/usr/lib/x86_64-linux-gnu/libgnutls.so.30
  #3  0x555778f3 in tls_new_cred ()
  #4  0x55566bfd in read_conf_files ()
  #5  0xefc4 in main ()


ltrace shows the following at the end of its run:

  calloc(1, 32) 
= 0x558d1fc9f3a0
  gnutls_global_init(0, 1265, 40, 0)
= 0
  gnutls_certificate_allocate_credentials(0x558d1fc9f3a0, 0, 0x7f3c4f66a620, 0) 
= 0
  gnutls_priority_init(0x558d1fc9f3a8, 0x558d1dbc7748, 0, 0x558d1fca8a00)   
= 0
  gnutls_certificate_set_x509_key_file(0x558d1fc9f3d0, 0x558d1fca0490, 
0x558d1fca0450, 1)   = 0
  gnutls_dh_params_init(0x558d1fc9f3b0, 0, 0, 0)
= 0
  gnutls_certificate_set_dh_params(0x558d1fc9f3d0, 0x558d1fc897c0, 24, 0 
  --- SIGSEGV (Segmentation fault) ---
  +++ killed by SIGSEGV +++


The kernel log contains the following:

  ircd-hybrid[32122]: segfault at 4 ip 7f5548d1b5f0 sp 7ffc4241e6a8 
error 4 in libgmp.so.10.3.2[7f5548d02000+5e000]


I took a quick look at "gnutls_certificate_set_dh_params".  Its manpage
[1] describes this function as deprecated for quite some time.  I do not
know, whether this is relevant.

Thank you for your time!

Cheers,
Lars


[1] 
https://manpages.debian.org/buster/gnutls-doc/gnutls_certificate_set_dh_params.3.en.html

Bug#920461: 'unexpected operator' error coming from /etc/init.d/openipmi

[devel]

Hello,


On Fri, 25 Jan 2019 15:19:15 -0500 Adam Di Carlo  wrote:
>
> Jan 25 15:16:37 salsa systemd[1]: Starting LSB: OpenIPMI Driver init script...
> Jan 25 15:16:37 salsa openipmi[3081]: /etc/init.d/openipmi: 55: [: 4.17: 
> unexpected operator
> Jan 25 15:16:37 salsa openipmi[3081]: Starting ipmi drivers ipmi.
> Jan 25 15:16:37 salsa systemd[1]: Started LSB: OpenIPMI Driver init script.

attached you find a patch that fixes the bashisms (comparisons and
string localizations). Additionally most shellcheck issues of the script are
corrected (except for the sourcing tests, that should usually get skipped).

No functional change is introduced.

Cheers,
Lars


PS: the script feels a bit ugly and overly complicated in relation to its
limited purpose (load or unload some kernel modules). But at least it should be
in a better maintainable state now.
--- openipmi.orig	2019-09-27 19:37:51.981164100 +0200
+++ openipmi	2019-09-27 20:41:51.774647124 +0200
@@ -34,7 +34,7 @@
 
 CONFIGFILE=/etc/default/openipmi
 # source config info
-[ -r ${CONFIGFILE} ] && . ${CONFIGFILE}
+[ -r "${CONFIGFILE}" ] && . "${CONFIGFILE}"
 
 #
 # GLOBALS
@@ -51,8 +51,8 @@
 *)
 IPMI_SI_MODULE_NAME="ipmi_si" ;;
 esac
-kernel=`uname -r | cut -d. -f1-2`
-if [ "${kernel}" == "2.4" ]; then
+kernel=$(uname -r | cut -d. -f1-2)
+if [ "${kernel}" = "2.4" ]; then
 IPMI_SMB_MODULE_NAME="ipmi_smb_intf"
 IPMI_SI_MODULE_NAME="ipmi_si_drv"
 fi
@@ -77,7 +77,7 @@
 DEV_IPMI_TIMEOUT=15
 
 UDEV_EXISTS=0
-if [ -e /sbin/udev -o -e /sbin/udevd ]; then
+if [ -e /sbin/udev ] || [ -e /sbin/udevd ]; then
 UDEV_EXISTS=1
 fi
 
@@ -93,8 +93,8 @@
 {
 	OnePlusLoaded=0
 	OnePlusUnloaded=0
-	for m in $@; do
-		if /sbin/lsmod | grep $m >/dev/null 2>&1 ; then
+	for m in "$@"; do
+		if /sbin/lsmod | grep -qFw "$m"; then
 			echo "$m module loaded."
 			OnePlusLoaded=1
 		elif [ -d "/sys/module/$m" ]; then
@@ -111,8 +111,8 @@
 {
 	OnePlusLoaded=0
 	OnePlusUnloaded=0
-	for m in $@; do
-		if /sbin/lsmod | grep $m >/dev/null 2>&1 ; then
+	for m in "$@"; do
+		if /sbin/lsmod | grep -qFw "$m"; then
 			OnePlusLoaded=1
 		elif [ -d "/sys/module/$m" ]; then
 			OnePlusLoaded=1
@@ -136,12 +136,14 @@
 {
 rc_base=1
 	rc_hw=1
-modules_loaded_verbose "${MODULES_BASE}"
+	# shellcheck disable=SC2086
+	modules_loaded_verbose ${MODULES_BASE}
 	[ ${OnePlusLoaded} -eq 0 ] && rc_base=0
-	
-	modules_loaded_verbose "${MODULES_HW}"
+
+	# shellcheck disable=SC2086
+	modules_loaded_verbose ${MODULES_HW}
 	[ ${OnePlusLoaded} -eq 0 ] && rc_hw=0
-	
+
 	return $((rc_base && rc_hw))
 }
 
@@ -174,18 +176,19 @@
 start_watchdog_common()
 {
 	load_hw_modules
+	# shellcheck disable=SC2086
 	modprobe ipmi_watchdog ${IPMI_WATCHDOG_OPTIONS} > /dev/null 2>&1
 	modules_loaded ipmi_watchdog
 	[ ${OnePlusUnloaded} -ne 0 ] &&
 		RETVAL=$((RETVAL | 2)) &&
 		log_end_msg &&
 		return
-	if [ ${UDEV_EXISTS} -eq 0 -a ! -e /dev/watchdog ]; then
-		mknod -m 0600 /dev/watchdog c 10 130
-		[ $? -ne 0 ] &&
-			RETVAL=$((RETVAL | 8)) &&
-			log_end_msg &&
+	if [ ${UDEV_EXISTS} -eq 0 ] && [ ! -e /dev/watchdog ]; then
+		if ! mknod -m 0600 /dev/watchdog c 10 130; then
+			RETVAL=$((RETVAL | 8))
+			log_end_msg
 			return
+		fi
 	fi
 	#log_success_msg
 }
@@ -199,7 +202,7 @@
 
 start_watchdog()
 {
-	log_begin_msg $"Starting ipmi_watchdog driver: "
+	log_begin_msg "Starting ipmi_watchdog driver: "
 	[ "${IPMI_WATCHDOG}" != "yes" ] &&
 		RETVAL=$((RETVAL | 2)) &&
 		log_failure_msg "not configured" &&
@@ -210,7 +213,7 @@
 
 stop_watchdog()
 {
-	log_begin_msg $"Stopping ipmi_watchdog driver: "
+	log_begin_msg "Stopping ipmi_watchdog driver: "
 	modprobe -q -r ipmi_watchdog > /dev/null 2>&1
 	modules_loaded ipmi_watchdog
 	if [ ${OnePlusLoaded} -ne 0 ]; then
@@ -242,7 +245,7 @@
 {
 	local poweroff_opts=""
 	load_hw_modules
-	if [ "${IPMI_POWERCYCLE}" == "yes" ]; then
+	if [ "${IPMI_POWERCYCLE}" = "yes" ]; then
 	modinfo ipmi_poweroff 2>/dev/null | grep poweroff_control > /dev/null 2>&1 && \
 		poweroff_opts="poweroff_control=2"
 	modinfo ipmi_poweroff 2>/dev/null | grep poweroff_powercycle > /dev/null 2>&1 && \
@@ -304,27 +307,28 @@
 	stop_watchdog_quiet
 	stop_powercontrol_quiet
 	for m in ${MODULES}; do
-		modprobe -q -r ${m} > /dev/null 2>&1
+		modprobe -q -r "${m}" > /dev/null 2>&1
 	done
 # delete interface node ONLY if ipmi_devintf is unloaded
-[ `lsmod | grep -c "ipmi_devintf"` -eq 0 ] &&
+	if ! lsmod | grep -qFw "ipmi_devintf"; then
 	rm -f "/dev/ipmi${INTF_NUM}"
+	fi
 }
 
 unload_ipmi_modules_leave_features()
 {
 	for m in ${MODULES_INTERFACES}; do
-		modprobe -q -r ${m} > /dev/null 2>&1
+		modprobe -q -r "${m}" > /dev/null 2>&1
 	done
 # delete interface node ONLY if ipmi_devintf is unloaded
-[ `lsmod | grep -c "ipmi_devintf"` -eq 0 ] &&
+	if ! lsmod | grep -qFw "ipmi_devintf"; then
 	rm -f "/dev/ipmi${INTF_NUM}"
-	lsmod | egrep -q 

Bug#943860: munin-plugins-core: ntp_states plugin is broken in current package release

[devel]

Hello Jo-Jo,


Am Wed, 30 Oct 2019 22:11:46 +0100
schrieb Jo-Jo :

> Could you please ensure to have this fix in the package as soon as possible?

hehe - this plugin was broken for five years - no need to hurry :)
Anyway: I (being upstream) will publish another release in the next days. Thus
the fix should land in unstable quite soon.


> Thanks for the great work your doing!

Appreciated!
Thank you for your report!

Cheers,
Lars

Bug#943577: munin-plugins-core: sensors_ plugin unable to parse millivolt

[devel]

Control: tags -1 +fixed-upstream

Hello Andreas,


Am Fri, 1 Nov 2019 08:37:42 +0100
schrieb Andreas Pommer :

> > Please test, whether the changed plugin works for you.  
> 
> I tested the attached script. First, it resulted in several error messages. I
> realized that in the first line of the script the '!' was missing, [..]

oh - that was my manual mistake with the attachment :(
The plugins in the repository use a substitution pattern. It is correct, there.


> The 'volt1' line stayed there, it reported values below 1, and the output from
> 'config' stayed stable as well. Fixed!

great - thank you for testing!
I just merged the change upstream.

Cheers,
Lars

Bug#943577: munin-plugins-core: sensors_ plugin unable to parse millivolt

[devel]

Hello Andreas,

thank you for reporting this issue!


I prepared a change to the sensors_ plugin, that should fix the issue:
 https://github.com/munin-monitoring/munin/pull/1246
I attached the changed plugin for your convenience and to avoid forcing you into
a non-free service.

Please test, whether the changed plugin works for you.


> I suggest to use the -u switch when running the 'sensors' command, which
> generates output that can be parsed more easily and with less risk of errors.

This would be indeed much better.
But the "sensors_" plugin was removed [1] from munin's master branch (to be
released as munin 3.0). Thus I did not put the effort into improving the
current plugin.

Cheers,
Lars


[1] 
https://github.com/munin-monitoring/munin/commit/28db208a2da6f807c5322f5422fcfeba9850b5d8


sensors_
Description: Binary data

Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[devel]

Hello Bernhard,


Am Mon, 18 Nov 2019 22:37:27 +0100
schrieb Bernhard Übelacker :

> because you mention repeating crashes which, as far as I see, are
> in different programs in different backtraces.

in fact they all happen with the same program (claws-mail). I started to collect
stack traces of it in order to find the source of its crashes on my system.
(crashes happen every few weeks; I collected them for a few months)


> Maybe the problems are created by a bad memory module?

An interesting idea!
I am tempted to rule this out, since I am used to an uptime of half a year or
more (many working hours a day; suspended in between) - only interrupted by an
accidentally drained battery from time to time.
Besides the claws-mail crashes I did not notice any other unexpected behavior.


> Therefore could you please run a tester like memtest86+, just
> to rule out an hardware issue?

Yes, I will do this after the next accidental shutdown.

Thank you for your time!

Cheers,
Lars

Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"

[devel]

Hello,

thank you for your quick and helpful responses!


Am Sun, 17 Nov 2019 10:33:10 -0800
schrieb Ryan Tandy :

> On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:
> >  #0  0xb77acbea in ldap_unbind_ext () at 
> > /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2  
> 
> Please could you install libldap-2.4-2-dbgsym and obtain the backtrace again: 
> [..]

I did this now. Thank you for the hint.


> >** (claws-mail:10224): WARNING **: 11:06:04.004: [11:06:04] LDAP error 
> >(search): -1 (Unknown error)  
> 
> Is it possible your LDAP server became temporarily unreachable? I am not
> ruling out a bug in libldap but I also wonder whether claws might have an
> issue in its error handling and somehow pass an invalid argument to a libldap
> function.

Interesting!
Indeed this LDAP server is quite often not reachable (local to one site).
I just tried for a few times to reproduce the issue (accessing the LDAP-based
addressbook in claws-mail, while disconnecting the VPN), but I failed.
In fact: the issue happened only once during the last three months.
Thus I guess, the dbgsym-enhanced stack trace will take a bit of time ...


> Any info you can provide that leads to reproducing the error above (which I
> assume is related), or the crash itself, would be appreciated.

I am sorry, I cannot remember any details.


> On Sun, 17 Nov 2019 10:33:10 -0800 Ryan Tandy  wrote:
> > On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:  
>  [...]  
> but I think that last address translates to:
> 
>   0x.bea in ldap_unbind_ext at unbind.c:46
> 
> That would be that line:
> 
>   46  assert( LDAP_VALID( ld ) );
> 
> Therefore this function might have received ld pointing to
> existing memory, but the ld->ldc might point to an invalid address.

Thank you for digging deeper!

I took a look at the source code of claws-mail related to "ldap_unbind":

$ grep -B 1 -r ldap_unbind
src/ldaputil.h-#define LDAP_CONST const
src/ldaputil.h:#define ldap_unbind_ext(ld,x,y) ldap_unbind_s(ld)
--
src/ldapquery.c-if( qry->ldap ) {
src/ldapquery.c:rc = ldap_unbind_ext( qry->ldap, NULL, NULL );
--
src/ldapserver.c-   cm_return_if_fail(ld != NULL);
src/ldapserver.c:   rc = ldap_unbind_ext(ld, NULL, NULL);

These pieces look innocent to me at the first glance. But I am not a user of
the LDAP library, thus I cannot tell.

I am afraid, that it will be hard to find the source of the problem without
further information from another more detailed stack trace. Thus in case you are
running out of ideas at the moment, then I would suggest to just wait and hope
for another stack trace or just close the bug report in a few month otherwise.

Thank you for your time!

Cheers,
Lars

Bug#547464: Please include Linksys AG241 adsl modem script

[devel]

Hello,


On Sun, 19 Sep 2010 22:29:39 +0200 Tom Feiner  wrote:
> When munin-exchange was recently redesigned, there was talk about a
> sort of "apt-get" like tool to search/download plugins directly from
> munin-exchange. As far as I know this was not written yet, [..]

upstream just added such a tool ("munin-get") in its release 2.0.52.
It should ease the installation of external munin plugins. Specifically munin's
"contrib" repository is pre-configured out of the box.

Thus the following should be sufficient for installing and enabling a module
from the contrib repository:

  munin-get update
  munin-get install traffic
  munin-get enable traffic
  service munin-node restart

Cheers,
Lars

Bug#944915: libldap-2.4-2: Segmentation fault in "ldap_unbind_ext"

[devel]

Hello Bernhard,


Am Tue, 19 Nov 2019 11:55:54 +0100
schrieb Bernhard Übelacker :

> just a wild guess - is claws-mail doing these ldap queries
> in parallel in different threads? This in combination with
> the unsteady connection to the server could make two threads
> operate on the same structures?

An interesting idea!
I could imagine, that claws-mail's maintainer will appreciate this hint.
(I guess, I will open a bug report against claws-mail upstream)


> In that case following gdb output would show all
> threads with their backtraces:
> (gdb) thread apply all bt

indeed this was the command, that I used to generate the gdb output.


> Or with showing also the variables:
> (gdb) thread apply all bt full

Next time I will also use this one.


> And how do you get the backtraces? Are you running
> with a gdb attached to it permanently?

Yes, I am doing this for claws-mail at the moment.


> Then you could create a core when the crash happened with
> (gdb) generate-core-file /home/someone/corefile

Good point - I will try this next time.


Thank you for your hints!

Cheers,
Lars

Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[devel]

Hello Bernahrd,


Am Tue, 19 Nov 2019 14:50:13 +0100
schrieb Bernhard Übelacker :

> Another question, which version of claws-mail and plugins are you running?
> (And are they the binaries from debian or self-built?)

I use the Debian packages (current version in testing - 3.17.4-2+b1).


> Maybe a run with valgrind could shed some light on some wrong memory accesses.
> (But may also write many unrelated accesses,
> and slow the application down to an unusable speed.)

Thanks, I will try that.


> I found this upstream feature request, which could fit,
> but there is also a change mentioned that should avoid that crash,
> that is already included ...
> Are you maybe hitting this limit?
> 
> https://dev.gnupg.org/T2385

Right now the number of open file descriptors look fine:
(but this may change at some point in time)

$ ls -l /proc/$(pidof claws-mail)/fd | wc -l
39


Thank you!

Cheers,
Lars

Bug#941898: Acknowledgement (munin-node: all Plugins fail with "Can't drop privileges: at /usr/share/perl5/Munin/Node/Service.pm line 228.")

[devel]

Hello Cord,


On Wed, 9 Oct 2019 09:14:15 +0200 Cord Beermann  wrote:

> The issue disappeared with a new perl package.

thank you for documenting the issue and for updating the bug status!

Cheers,
Lars

Bug#951095: /usr/sbin/munin-run: munin-run: issue with `--property DropInPaths=...`

[devel]

tags: -1 +pending +upstream

Hello Olivier,

thank you for your report.

Indeed this property may not be handed over to "systemd-run". Thus I followed
your suggestion by skipping it:
 
https://github.com/munin-monitoring/munin/commit/ce8fbfaa2310af6fd93e8eb1fb345f7698202a81

Cheers,
Lars

Bug#939339: munin-node: systemd hardening hurts the df plugin

[devel]

Hello Laurence,

thank you for sharing your thoughts!


On Tue, 7 Jan 2020 08:54:23 + Laurence Parry  wrote:
> [..]
> The [df*] section in the plugins.conf file (aka plugins-conf/munin-node)
> could contain a comment regarding this situation. That's the first place I
> went to look, to see if it was being excluded.

good point!
I will add such a comment, if we stick to the current default for "ProtectHome".


> (The README.Debian file is *not* in /etc/munin - nor apparently referenced by
> it or the manual. There is an /etc/munin/plugin-conf/README but it does not
> reference /usr/share/doc/munin-node (not even to mention the
> README.PluginConfiguration that is there.)

I added a comment there, now.


> It would also be good to give the actual specific contents to type after
> `systemctl edit munin-node`, i.e.
> [Service]
> ProtectHome=read-only

I will add this, if we stick to the current setting.


> But really, these are workarounds. Having a separate disk as /home is a
> standard configuration offered by the Debian installer and so I think the
> default install of munin-node should support monitoring it. Perhaps it
> could detect the situation on install and offer you the option to apply the
> above override to address this particular issue?

I will definitely add a debconf question for this setting.


Today we dicussed the issue again during our weekly IRC meeting:
 http://meetbot.debian.net/munin/2020/munin.2020-01-08-19.32.log.html

Some voices were raised for the "read-only" approach suggested above.
I am split between privacy and security, but leaning slightly towards
"read-only", too.

Anyway: a debconf question would certainly turn the current annoyance of
a silent configuration change into an informed decision.
We just need to decide which default we pick.
Maybe we could use the result of 'mount | grep -q "\s/home"' as the default?
(I am not sure, whether I really like this dynamic behaviour)

Cheers,
Lars

Bug#949031: munin: no graphs generated

[devel]

Hello Olaf,

thanks for your report!


Am Thu, 16 Jan 2020 09:46:01 +0100
schrieb Olaf Zaplinski :

> Munin does not generate graphs. Please correct the default Munin
> configuration.

I am quite confident that it actually generates graphs, since this is verified
during its automated testing procedure ("autopktest"). These tests are executed
after every packaging update.

Thus I guess, there is a local issue on your side.

I am curious: which configuration is necessary for you?
Did you see something relevant in the logs?

Cheers,
Lars

Bug#866187: add torrc.d configuration directory

[devel]

Hello,

On Sun, 24 Dec 2017 16:41:00 + iry  wrote:
> I can definitely work on that once weasel confirms a /etc/tor/torrc file
> with only a single include line is what we expect.

This would be great!


> Also, could you please specify which directory will be used as torrc.d
> directory, weasel?

A quick "ack" and the wanted directory name confirmed by weasel would probably
unleash this nice configuration feature quickly.
(I am willing to provide a patch, if iry is not in the mood anymore)

Cheers,
Lars

Bug#949887: munin autopkgtest failure for sysvinit based tests

[devel]

Hello Andreas,

just as Holger said: thank you for your detailed and helpful analysis!


On Fri, 7 Feb 2020 03:36:28 +0100 Andreas Henriksson  wrote:
>
> When the autopkgtest is booted into sysvinit I assume there's a
> race between the munin init script starting and the actual
> tests running.

you are right - it turns out that exactly this is happening.

I did some more digging in the autopkgtest code and I think, I found the
culprit: autopkgtest explicitly waits for systemd services to be ready (waiting
for "network-online.target"), but it does not wait for sysvinit services.

I proposed a patch against autopkgtest that solves this issue:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953655

Until this is fixed in autopkgtest, I added a conditional wait to munin's
test code. After some more dozens of successful tests runs I am convinced that
the issue is fixed.

Thank you for your help!

Cheers,
Lars

Bug#640208: please stop using libnet-irc-perl

[devel]

Dear fellow munin maintainers,


On Sat, 03 Sep 2011 13:46:21 +0200 Ansgar Burchardt  wrote:
> As libnet-irc-perl has been unmaintained since 2004, we would like to
> remove the package from Debian before the wheezy release.  Please switch
> to an alternative library such as libpoe-component-irc-perl.

as of now munin seems to be the only user of libnet-irc-perl that is left:

$ apt-cache rdepends libnet-irc-perl
libnet-irc-perl
Reverse Depends:
  munin-plugins-core
  munin-plugins-core

I am tempted to remove the "ircu" plugin from the munin-plugins-core package
and thus remove this "Suggests" relationship. This would allow the
libnet-irc-perl package to be removed.

What do you think?

Cheers,
Lars

PS: Of course, anyone willing to migrate the plugin to a different IRC module is
kindly invited to propose such a patch upstream.

Bug#954930: munin-plugins-core: missing dependency to libtest-lwp-useragent-perl

[devel]

Hello Olaf,

thank you for your report!


On Wed, 25 Mar 2020 06:46:24 -0500 Olaf Zaplinski  wrote:
> the dependency to libtest-lwp-useragent-perl is missing:

Indeed: at the moment the relevant package (libwww-perl) was only indirectly
referenced by another "Suggest" (liblwp-useragent-determined-perl).
I will add a direct "Suggest" for libwww-perl to fix this.

Cheers,
Lars

Bug#911378: cutecom: Send file always fails

[devel]

Hello Roman,


On Sat, 20 Oct 2018 21:32:59 +0300 Roman Khimov  wrote:
> В письме от пятница, 19 октября 2018 г. 13:20:08 MSK Вы написали:
> > Please incorporate the fix from above issue into the Debian package or
> > update Debian's version to 0.45.0 which includes the fix.
> 
> Thanks for the bug, I think it's time to update it, I have a half-baked 
> update 
> to version 0.40.0, now need to bring it into the 2018.

I would be happy to use the "sz send" feature.
Maybe I can help you somehow with updating the package?

Thanks for maintaining cutecom!

Cheers,
Lars

Bug#953655: autopkgtest (lxc/lxd): wait for sysvinit services to finish before running the tests

[devel]

Hello Paul,

thank you for integrating my proposal so quickly!


Am Tue, 31 Mar 2020 22:03:33 +0200
schrieb Paul Gevers :

> I get errors from our pycodetest:
> paul@testavoira ~/autopkgtest $ tests/pycodestyle
> /home/paul/debian-maint/autopkgtest/virt/autopkgtest-virt-lxc:128:212:
> W605 invalid escape sequence '\.'
> /home/paul/debian-maint/autopkgtest/virt/autopkgtest-virt-lxd:104:201:
> W605 invalid escape sequence '\.'

indeed, I did not run the test suite before proposing the patch. Sorry!

I would recommend to mark the shell compound command (starting with
"if [ -d /run/systemd/system ]") as a "raw" string (putting "r" in front of the
opening quote).
(sorry for possibly going too much into obvious details here)

This approach sounds feels like a suitable solution for me.
Omitting the backslash (and thus relaxing the regex a bit) is sadly not an
option, since we have to avoid accidentally grepping the shell invocation or the
"grep" invocation. This is a bit subtile, but I did not find a better concise
way of expressing this in shell.

Anyway: the "raw" string is good - please go for it.

Thank you for your time!

Cheers,
Lars


pgpVH93HVVEUg.pgp
Description: Digitale Signatur von OpenPGP

Bug#911378: cutecom: Send file always fails

[devel]

Hello Roman,


Am Fri, 27 Mar 2020 15:20:20 +0300
schrieb Roman Khimov :

> Please check this one:
> https://roman.khimov.ru/temp/deb-cutecom/cutecom_0.51.0-1.dsc

I tried it and it looks good!
(I just tested an upload via xmodem - as reported in this bug)


> It was done a year ago, but buster was already freezed back then, so nobody 
> was interested in sponsoring it. And it went off my radar after the buster 
> release. I guess now it needs yet another update.

I took the liberty to add a few minor packaging updates.
You can find my patch attached.
(just include it, if you like - there is no need to mention me)

btw: I am not a DD, thus I cannot sponsor the upload (in case you had this in
mind).

Thanks for maintaining cutecom!

Cheers,
Lars
diff -ruN ../debian/changelog debian/changelog
--- ../debian/changelog	2019-03-02 11:09:46.0 +0100
+++ debian/changelog	2020-03-27 15:41:11.124297181 +0100
@@ -4,15 +4,17 @@
   * Change Qt dependency version to 5.3.0 as it's the minimal
 supported version now
   * Update homepage and watch file, project moved to Gitlab
-  * Upgrade package to standards 4.3.0
+  * Upgrade package to standards 4.5.0
   * Upgrade to debhelper 12, set compat 12
   * Update copyright, icons were changed to public domain versions, some
 new authors added
   * Remove man-page-update.patch, merged upstream
   * Use updated desktop file with 'Comment' section (Closes: #847088)
 (LP: #1575347)
+  * Add d/upstream/metadata
+  * d/control: Use the new debhelper-compat(=11) notation and drop d/compat
 
- -- Roman I Khimov   Sat, 02 Mar 2019 13:09:46 +0300
+ -- Roman I Khimov   Fri, 27 Mar 2020 13:09:46 +0300
 
 cutecom (0.30.3-1) unstable; urgency=low
 
diff -ruN ../debian/compat debian/compat
--- ../debian/compat	2019-03-02 11:09:46.0 +0100
+++ debian/compat	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-12
diff -ruN ../debian/control debian/control
--- ../debian/control	2019-03-02 11:09:46.0 +0100
+++ debian/control	2020-03-27 15:33:57.870490695 +0100
@@ -2,9 +2,17 @@
 Section: comm
 Priority: optional
 Maintainer: Roman I Khimov 
-Build-Depends: debhelper (>= 12), cmake (>= 2.8.11), qtbase5-dev (>= 5.3.0), qt5-qmake (>= 5.3.0), qtbase5-dev-tools (>= 5.3.0), libqt5serialport5-dev (>= 5.3.0)
-Standards-Version: 4.3.0
+Build-Depends:
+ cmake (>= 2.8.11),
+ debhelper-compat (=12),
+ debhelper (>= 12),
+ libqt5serialport5-dev (>= 5.3.0),
+ qt5-qmake (>= 5.3.0),
+ qtbase5-dev (>= 5.3.0),
+ qtbase5-dev-tools (>= 5.3.0),
+Standards-Version: 4.5.0
 Homepage: https://gitlab.com/cutecom/cutecom
+Rules-Requires-Root: no
 
 Package: cutecom
 Architecture: any
diff -ruN ../debian/copyright debian/copyright
--- ../debian/copyright	2019-03-02 11:09:46.0 +0100
+++ debian/copyright	2020-03-27 15:42:54.415578692 +0100
@@ -45,21 +45,21 @@
2015, The Qt Company Ltd.
 License: GPL-3+
 
-Files: images/cutecom.svg, images/terminal.svg
+Files: images/cutecom.svg images/terminal.svg
 Copyright: 2005, Jakub Steiner 
 License: CC-BY-SA-2
  THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
  COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY
  COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
  AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
-
+ .
  BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE
  BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS
  CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND
  CONDITIONS.
-
+ .
  1. Definitions
-
+ .
  "Collective Work" means a work, such as a periodical issue, anthology or
  encyclopedia, in which the Work in its entirety in unmodified form, along with
  a number of other contributions, constituting separate and independent works
@@ -92,12 +92,12 @@
  restrict any rights arising from fair use, first sale or other limitations on
  the exclusive rights of the copyright owner under copyright law or other
  applicable laws.
-
+ .
  3. License Grant. Subject to the terms and conditions of this License,
  Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual
  (for the duration of the applicable copyright) license to exercise the rights
  in the Work as stated below:
-
+ .
  to reproduce the Work, to incorporate the Work into one or more Collective
  Works, and to reproduce the Work as incorporated in the Collective Works;
  to create and reproduce Derivative Works;
@@ -108,7 +108,7 @@
  and perform publicly by means of a digital audio transmission Derivative
  Works.
  For the avoidance of doubt, where the work is a musical composition:
-
+ .
  Performance Royalties Under Blanket Licenses. Licensor waives the exclusive
  right to collect, whether individually or via a performance rights society
  (e.g. ASCAP, BMI, SESAC), royalties for the public performance or public
@@ -130,10 +130,10 @@
  modifications as are technically necessary to exercise the 

Bug#956711: munin: permissions of /var/log/munin for html/graph_strategy cgi: www-data user should be in groups munin and adm

[devel]

Hello Marcel,

thank you for your bug report!


Am Tue, 14 Apr 2020 16:40:12 +0200
schrieb Marcel Partap :

> By default, debian's munin is not ready for switching html_strategy and
> graph_strategy to cgi because of a lack of access permission for the (apache2)
> www-data user on folders /var/lib/munin/cgi-tmp and /var/log/munin .
> 
> This can be resolved by allowing the respective owner groups write access
> > chmod g+w /var/lib/munin/cgi-tmp /var/log/munin
> [..]
> gpasswd -a www-data munin
> gpasswd -a www-data adm  

are you really sure, that these steps are necessary?

The munin package uses autopkgtests. One of the tested scenarios is the switch
to the CGI-based rendering. The preparations for this step are quite trivial:
* change the strategies to "cgi"
* toggle the enabled line in the apache configuration (as documented there)

(see
https://salsa.debian.org/debian/munin/-/blob/debian/debian/tests/enable_cgi_strategy.inc)

Afterwards it should work. At least the current tests do not fail ...


The permissions should be handled automatically during package installation:

   touch /var/log/munin/munin-cgi-html.log
   chown www-data:adm /var/log/munin/munin-cgi-html.log
   chmod 640 /var/log/munin/munin-cgi-html.log

   touch /var/log/munin/munin-cgi-graph.log
   chown www-data:adm /var/log/munin/munin-cgi-graph.log
   chmod 640 /var/log/munin/munin-cgi-graph.log

   mkdir -p /var/lib/munin/cgi-tmp
   chown munin:www-data /var/lib/munin/cgi-tmp
   chmod 775 /var/lib/munin/cgi-tmp
(see the postinst script)


Maybe you are cleaning up the log directory (e.g. on a read-only system) during
a reboot?
In this case it would indeed fail. I guess, it would be nice for the package to
also work in such situations (e.g. non-permantent /var/log/).

Or do you have another idea, what could be wrong?

Cheers,
Lars

Bug#934334: munin-plugins-extra: please package asterisk multigraph plugin from munin-contrib

[devel]

Hello,


On Sat, 10 Aug 2019 14:35:34 +0200  wrote:
> At the moment we do not really have a process, how plugins are moved into (or
> out of) munin's core repository (which is used as the base of the Debian
> packging). We will discuss this during our next weekly IRC meeting. [1]

finally we discussed the issue and came to the conclusion, that we want to move
plugins into the core repository only if they are used (or can be maintained)
by one of the munin developers [1].
At the moment the asterisk_* plugins are not used by one of us. Thus we do
not want to move the (working) asterisk plugins from contrib to core.

We recently (munin v2.0.60) removed the really outdated asterisk_* plugins from
core, since they did not work for ~8 years.

Thus at the moment the best approach for using the asterisk plugin is probably
to install them via "munin-get".

This is probably not a satisfying solution, but it is the best we can offer.

Cheers,
Lars


[1] http://meetbot.debian.net/munin/2020/munin.2020-04-29-18.30.log.html

Bug#954234: /etc/init.d/munin has two broken function definitions

[devel]

Hello Craig,

Thank you for your report!


Am Thu, 19 Mar 2020 14:14:42 +1100
schrieb Craig Sanders :

> Package: munin
> Version: 2.0.57-1
> 
> At the bottom of the /etc/init.d/munin script are two lines:
> 
> do_stop_cmd_override() true
> do_start_cmd_override() true
> 
> This is **NOT** how you define a shell function.

indeed - how embarrassing :(
(but see below for details)


> Without this patch (attached), upgrading munin to 2.0.57-1 leaves the package
> in a broken (installed/Failed-config, or "iF") state and results in the
> following:
> [..]

I am very confused, that this did not fail during munin's autopkgtest (or on my
system).
After digging around for a while (including successful fresh installations or
upgrades on systemd-based hosts), I think I found the issue:

  $ dash -c "foo() true"; echo $?
  0
  $ bash -c "foo() true"; echo $?
  bash: -c: line 0: syntax error near unexpected token `true'
  bash: -c: line 0: `foo() true'
  1

After taking a closer look at the man pages of both shell implementations, this
seems to be in line with their respective documentations:

1) dash
Syntax: name () command
Thus *any* command is allowed (including "true").

2) bash
Syntax: name () compound-command
Here "compound-command" means any non-trivial command, e.g. surrounded by
braces or "if ...; fi" and so on. A single command ("true") is not explicitly
mentioned and obviously is rejected.


Thus I assume, that you are using bash as your "sh" implementation?


I will fix this issue in the next packaging update. Thank you!

Cheers,
Lars

Bug#954128: munin-node: timeout in init script too short

[devel]

Hallo Gregor,


On Tue, 17 Mar 2020 10:25:30 +0100 gregor herrmann  wrote:
> START_ARGS="--background --notify-await --notify-timeout 15"
> 
> This 15 seconds timeout is fine on my laptop but is too short on my
> old Raspberry Pis (running Raspbian but the package is just copied
> from Debian).
> 
> Please consider making it longer (I put it at 60 on one Raspi and at
> 120 on a slow other one) or leaving it out (the default is 60
> seconds).

I agree.
In fact I think it was a remainder of my tests with the timeout.
Sixty seconds sounds more reasonable. I will change it with the next release.

Thanks for your report!

Cheers,
Lars

Bug#954118: munin-plugins-core: apt_all is all broken

[devel]

Hello Cyril,

thank you for your report!


Am Tue, 17 Mar 2020 04:00:18 +0100
schrieb Cyril Brulebois :

> Problem 1: This is not reproducible.
> 
> sub guess_releases() {
> …
> return keys %release_names;
> }
> 
> as the various known suites will not be returned in the same order.
> Switching to “sort keys” fixes this issue.

Good catch! I will do this.


> Problem 2: This doesn't do what it should.
> 
> sub print_state() {
> …
> while (my $line = ) {
> foreach my $release (@releases) {
> my $release_cleaned = clean_fieldname($release);
> # print only lines that are exected for the currently 
> requested releases
> print $line if ($line =~ 
> /^(hold|pending)_$release_cleaned\.(value|extinfo)/);
> last;
> }
> }
> close STATE;
> }
> 
> One could see the “last;” as an optimization: if a line matches, don't
> bother checking the other release. But it's not inside the matching
> conditional! Meaning whatever result the first line gets (match or no
> match), one gets out of the loop…
> 
> Dropping the “last;” fixes this issue. (One could optimize a little by
> using a regular if() form, and putting the “last;” inside.)

Indeed this was fixed and released by upstream meanwhile (commit 9a792a331b).


> Problem 3: This plugin doesn't report security updates!
> 
> # try to determine the currently available distributions by inspecting 
> the repository URLs
> sub guess_releases() {
> open(my $fh, "-|", "apt-get update --print-uris")
> or die("Failed to determine distribution releases via 'apt-get 
> update --print-uris");
> my %release_names;
> my $line;
> while ( ! eof($fh) ) {
> defined( $line = readline $fh ) or die "Failed to read line from 
> output of 'apt-get': $!";
> # example line:
> # 'http://ftp.debian.org/debian/dists/stable/InRelease' 
> ftp.debian.org_debian_dists_stable_InRelease 0
> if ($line =~ m'^.*/dists/([^/]+)/.*$') {
> $release_names{$1} = 1;
> }
> }
> return keys %release_names;
> }
> 
> The m'^.*/dists/([^/]+)/.*$' pattern doesn't allow for distribution
> names with slashes, meaning no luck for buster/updates.
> 
> Switching to m'^.*/dists/(.+)/(?:In)?Release.*$' would fix the suite
> detection, but then the plugin wouldn't work properly anyway:
> 
> E: The value 'buster/updates' is invalid for APT::Default-Release as such 
> a release is not available in the sources

Thank you for your analysis and recommendations.

I verified, that the packages available via "buster/updates" are assigned to
the "buster" distribution. Thus the issue can be solved by removing "/updates"
from distribution names.

I just pushed the corrsponding changes upstream.

Attached you find the three relevant upstream commits (including the fix for
the "last" condition above).
I would be happy, if you could test the attached patches and report back,
whether these work for you.

Thank you!

Cheers,
Lars
commit 435d2c6ca24b253d49323c0b122ad5f7f9869e18
Author: Lars Kruse 
Date:   Fri Mar 20 14:35:31 2020 +0100

Plugin apt_all: enforce stable order of fields

Previously the order of releases (and thus: fields) was random.

Thanks, Cyril Brulebois.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954118

diff --git a/plugins/node.d.linux/apt_all.in b/plugins/node.d.linux/apt_all.in
index fd3c373d..cdfc21fe 100644
--- a/plugins/node.d.linux/apt_all.in
+++ b/plugins/node.d.linux/apt_all.in
@@ -83,7 +83,7 @@ sub guess_releases() {
 $release_names{$1} = 1;
 }
 }
-return keys %release_names;
+return sort keys %release_names;
 }
 
 
commit b8d366dc7c0a89b63a0bc5f288dc46b9c6e1c763
Author: Lars Kruse 
Date:   Fri Mar 20 14:41:30 2020 +0100

Plugin apt_all: include release names with slashes (e.g. buster/updates)

Previously security updates were ignored due to the additional slash in
the release name.

Thanks, Cyril Brulebois.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954118

diff --git a/plugins/node.d.linux/apt_all.in b/plugins/node.d.linux/apt_all.in
index cdfc21fe..fddcfacf 100644
--- a/plugins/node.d.linux/apt_all.in
+++ b/plugins/node.d.linux/apt_all.in
@@ -79,8 +79,12 @@ sub guess_releases() {
 defined( $line = readline $fh ) or die "Failed to read line from output of 'apt-get': $!";
 # example line:
 # 'http://ftp.debian.org/debian/dists/stable/InRelease' ftp.debian.org_debian_dists_stable_InRelease 0
-if ($line =~ m'^.*/dists/([^/]+)/.*$') {
-$release_names{$1} = 1;
+if ($line =~ m#^.*/dists/([^']+)/[^/]+/[^/]+/Packages#) {
+my $release_name = $1;
+# The security updates are named like "buster/updates". The first part (before the
+# slash) 

Bug#959841: munin-plugins-core: ntp_kernel_* plugins trivially incompatible with ntpsec package

[devel]

Hello Gerald,

thank you for your well-researched bug report and your patch.
I used your pach as the start for a slightly different implementation:
reversing the current logic and thus hopefully working nicely with other
implementations, as well.

Here is the commit:
 
https://github.com/munin-monitoring/munin/commit/678c310ffe95225e6c4479b346774828074f1628

I just released it as part of munin 2.0.64.
The new Debian package will be uploaded in the next days ...

Cheers,
Lars

Bug#935654: matrix-synapse: /etc/init.d/matrix-synapse stop doesn't work

[devel]

Hello,


On Sun, 10 Jan 2021 17:34:57 +0100  wrote:

> * Forcing start-stop-daemon to create the PID file.
>   Synapse seems to fail to do this, see
>   https://github.com/matrix-org/synapse/issues/9066

indeed matrix-synapse does it properly - it just needs the "--daemonize" option.
See my updated patch: it uses "--daemonize" (for matrix-synapse) instead of
"--background" (for start-stop-daemon).
(the removal of "--exec" in "stop" is unrelated and still necessary)

This fixes the start/stop issue.

Cheers,
Lars
--- matrix-synapse.orig	2021-01-10 17:19:42.921852639 +0100
+++ matrix-synapse	2021-01-11 23:15:49.078774154 +0100
@@ -102,10 +89,12 @@
 	touch $PIDFILE
 	chown $USER:nogroup $PIDFILE
 	chown $USER:nogroup $SHAREDIR/media/
+
+	mkdir -p "$SHAREDIR/uploads"
 	chown $USER:nogroup $SHAREDIR/uploads/
 
-	start-stop-daemon --start --background --pidfile $PIDFILE --chuid $USER \
-	  --exec $PYTHON -- -m "synapse.app.homeserver" $CONFIGS || return 2
+	start-stop-daemon --start --pidfile $PIDFILE --chuid $USER \
+	  --exec $PYTHON -- -m "synapse.app.homeserver" --daemonize $CONFIGS || return 2
 
 	return 0
 }
@@ -126,7 +115,7 @@
 		return $RETVAL
 	fi
 
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --user $USER --exec $PYTHON
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --user $USER
 	RETVAL="$?"
 	[ "$RETVAL" = 2 ] && return 2
 

Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common

[devel]

Hello,

I encounter the same problem (psql directly used in postinst script) during
every package upgrade.

The main problem (in my case) is the misdetection of an uninitialized database
(see "db_relations" in /usr/lib/gitlab/scripts/rake-tasks.sh).
The script checks via "psql" (locally), whether the database is already
populated. Since the database is empty, the initial database setup is started
(this time using rake for interacting with the configured external database).
This initialization fails, since the real database is not empty.
Thus postinst fails.

My current workaround is to run the following loop in a separate shell:

 while sleep 1; do sed -i 's/db_relations"/db_relationsXXX"/' \
   /usr/lib/gitlab/scripts/rake-tasks.sh; done

This overrides the test for an empty database.
Another approach could be to simply populate the local (unused) database.

The proper solution would be to use the *configured* database connection
instead of running "psql" directly. Maybe this could be done via rake?

If you could give me any hints in this direction, then I could propose a patch
for fixing the database accesses in the postinst other related scripts.

Cheers,
Lars

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[devel]

Hello Maximilian,

many, many thanks for debugging this issue further and for sharing your
workaround!
It works for me, too.


On Sat, 19 Dec 2020 19:04:40 +0100 Maximilian Stein  wrote:
> So, right now, I do have a workaround, although I don't where the
> problem is exactly (i.e., in gitlab or in etag) nor how it should be
> fixed.

Yes, it seems to be unclear, whether the problem originates in gitlab or in
rake.
I just opened an issue for rake, asking this question:
 https://github.com/rack/rack/issues/1725

Cheers,
Lars

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[devel]

Hello,


On Tue, 18 Aug 2020 20:37:09 +0200 Maximilian Stein  wrote:
> Since the upgrade to above mentioned version, artifact uploads from
> gitlab runners fail with an error 500.

the same error (with the same stacktrace) also occurs on my gitlab instance
after the upgrade of the Debian package (from 11.8 to 13.4).

With increased log_level (see /etc/gitlab/environments/production.rb) I saw the
following (slightly more verbose) log output in /var/log/gitlab/production.log:


Started POST 
"/api/v4/jobs/6118/artifacts?artifact_format=zip_type=archive_in=2d"
 for x.x.x.x at 2020-12-14 02:35:51 +0100
  Ci::Build Load (1.5ms)  SELECT "ci_builds".* FROM "ci_builds" WHERE 
"ci_builds"."type" = $1 AND "ci_builds"."id" = $2 LIMIT $3  [["type", 
"Ci::Build"], ["id", 6118], ["LIMIT", 1]]
  Project Load (1.2ms)  SELECT "projects".* FROM "projects" WHERE 
"projects"."id" = $1 LIMIT $2  [["id", 4], ["LIMIT", 1]]
  Ci::Runner Load (0.9ms)  SELECT "ci_runners".* FROM "ci_runners" WHERE 
"ci_runners"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]
  Namespace Load (1.1ms)  SELECT "namespaces".* FROM "namespaces" WHERE 
"namespaces"."id" = $1 LIMIT $2  [["id", 4], ["LIMIT", 1]]
  Plan Load (1.1ms)  SELECT "plans".* FROM "plans" WHERE "plans"."name" = $1 
LIMIT $2  [["name", "default"], ["LIMIT", 1]]
  PlanLimits Load (1.4ms)  SELECT "plan_limits".* FROM "plan_limits" WHERE 
"plan_limits"."plan_id" = $1 LIMIT $2  [["plan_id", 1], ["LIMIT", 1]]
  Group Load (3.1ms)  SELECT "namespaces".* FROM "namespaces" WHERE 
"namespaces"."type" = $1 AND "namespaces"."id" = $2  [["type", "Group"], ["id", 
4]]
  Ci::JobArtifact Load (1.1ms)  SELECT "ci_job_artifacts".* FROM 
"ci_job_artifacts" WHERE "ci_job_artifacts"."job_id" = $1 AND 
"ci_job_artifacts"."file_type" = $2 LIMIT $3  [["job_id", 6118], ["file_type", 
1], ["LIMIT", 1]]
  User Load (1.4ms)  SELECT "users".* FROM "users" WHERE "users"."id" = $1 
LIMIT $2  [["id", 1], ["LIMIT", 1]]
  Route Load (1.0ms)  SELECT "routes".* FROM "routes" WHERE 
"routes"."source_id" = $1 AND "routes"."source_type" = $2 LIMIT $3  
[["source_id", 4], ["source_type", "Project"], ["LIMIT", 1]]
undefined method `empty?' for 201:Integer excluded from capture: DSN not set
  
NoMethodError (undefined method `empty?' for 201:Integer):
  
lib/gitlab/middleware/read_only/controller.rb:51:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:23:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'



For now I sadly could not find a way to work around this issue or gather more
debugging information.

I would appreciate any hints!

Cheers,
Lars

Bug#935654: matrix-synapse: /etc/init.d/matrix-synapse stop doesn't work

[devel]

Hello,

the issue can be fixed by:
* Forcing start-stop-daemon to create the PID file.
  Synapse seems to fail to do this, see
  https://github.com/matrix-org/synapse/issues/9066
* removing the "--exec" match from the "stop" action

Attached you find a patch fixing these issues.
Afterwards matrix-synapse starts and stops successfully.

Thank you!

Cheers,
Lars


PS: additionally the patch contains "mkdir" for the uploads directory. This is
unrelated. Please excuse me for not opening a separate bug report for this
trivial issue. Thanks!
--- matrix-synapse.orig	2021-01-10 17:19:42.921852639 +0100
+++ matrix-synapse	2021-01-10 17:21:23.356979220 +0100
@@ -102,9 +89,10 @@
 	touch $PIDFILE
 	chown $USER:nogroup $PIDFILE
 	chown $USER:nogroup $SHAREDIR/media/
+	mkdir -p "$SHAREDIR/uploads"
 	chown $USER:nogroup $SHAREDIR/uploads/
 
-	start-stop-daemon --start --background --pidfile $PIDFILE --chuid $USER \
+	start-stop-daemon --start --background --make-pidfile --pidfile $PIDFILE --chuid $USER \
 	  --exec $PYTHON -- -m "synapse.app.homeserver" $CONFIGS || return 2
 
 	return 0
@@ -126,7 +114,7 @@
 		return $RETVAL
 	fi
 
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --user $USER --exec $PYTHON
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --user $USER
 	RETVAL="$?"
 	[ "$RETVAL" = 2 ] && return 2
 

Bug#960276: matrix-synapse: init.d script is unable to generate missing keys

[devel]

Hello,

the issue can be fixed by removing the check for certifacte/key files in the
init script. See the attached patch.
matrix-synapse does not require these files anymore, if tls is not configured.
Thus the init script should not check for these files.

Cheers,
Lars
--- matrix-synapse.orig	2021-01-10 17:19:42.921852639 +0100
+++ matrix-synapse	2021-01-10 17:21:23.356979220 +0100
@@ -59,19 +59,6 @@
 	return 0
 	fi
 
-	TLS_CERT_FILE="$(get_config_key tls_certificate_path)"
-	if [ ! -f "$TLS_CERT_FILE" ]
-	then
-	log_failure_msg "TLS certificate file $TLS_CERT_FILE not found"
-	return 2
-	fi
-	TLS_PRIV_FILE="$(get_config_key tls_private_key_path)"
-	if [ ! -f "$TLS_PRIV_FILE" ]
-	then
-	log_failure_msg "TLS private key file $TLS_PRIV_FILE not found"
-	return 2
-	fi
-
 	KEYFILE="$(get_config_key signing_key_path)"
 	# Running --generate-config to create keys if any are absent.
 	# Doesn't matter if not

Bug#935654: matrix-synapse: /etc/init.d/matrix-synapse stop doesn't work

[devel]

Hello,


Am Wed, 13 Jan 2021 13:57:07 +0100
schrieb "Andrej Shadura" :

> > indeed matrix-synapse does it properly - it just needs the "--daemonize" 
> > option.
> > See my updated patch: it uses "--daemonize" (for matrix-synapse) instead of
> > "--background" (for start-stop-daemon).
> > (the removal of "--exec" in "stop" is unrelated and still necessary)
> > 
> > This fixes the start/stop issue.  
> 
> Unfortunately, that would undo the fix for the bug #920339

yes, let's not repeat history too quickly :)


> I’m going to keep your original fix.

Or maybe contemplate the suggestion in [1] (based on the discussion of the
issue, which you thankfully opened for upstream): add "db_stop" in order to
prevent the file descriptor leakage in the beginning.
(but I am just guessing here, this is not really my field)

Thank you for your care!

Cheers,
Lars


[1] https://github.com/matrix-org/synapse/issues/9099#issuecomment-759697583

Bug#968626: Error 500 during CI artifacts upload from gitlab-runner

[devel]

Hello,


On Tue, 12 Jan 2021 19:39:38 +0100 Leopold Palomo-Avellaneda 
wrote:
> In any case, after upgrade to 13.5.6 artifacts are working again.

same for me: after upgrading to 13.5.6, the artifacts upload works even after
reverting my local manual workaround (see "etag.patch" above).

Thanks!

Cheers,
Lars

Bug#855517: translate: error while running 'translate --help'

[devel]

Hello,


On Sun, 19 Feb 2017 17:26:25 +0200 Ulyanich Michael 
wrote:
>
> $ translate --help
> getopt: unrecognized option '--help'

indeed, translate acts a bit unconventionally by not supporting the "--help"
argument.
But translate's documentation ("man translate", as well as the output of
"translate -h") only refers to "-h" (not "--help"). Thus it works exactly as
documented.

Maybe upstream should consider adopting the widespread convention of supporting
"--help", but this is probably not a bug, which needs the attention of the
Debian package manager.

Closing this bug report would sound like a reasonable choice to me.

Cheers,
Lars

Bug#982991: matrix-synapse: not suitable for inclusion into bullseye

[devel]

Hello,

for any interested users of matrix-synapse: the NEWS file of the matrix-synapse
package refers to the new repositories used for publishing updated packages:

> matrix-synapse (1.27.0-1~bpo10+3) buster-backports; urgency=medium
>
>  Since Synapse won’t be included in Bullseye (see #982991 for more
>  details), updating backports will soon no longer be possible. However,
>  updates will still be uploaded to unstable and also to the new distribution
>  channel: Debian Fasttrack.
>
>  To learn more about Fasttrack and how to enable it, visit the project’s
>  website: https://fasttrack.debian.net/
>
> -- Andrej Shadura   Tue, 09 Mar 2021 13:50:38 +0100

Lars

Bug#954118: munin-plugins-core: apt_all is all broken

[devel]

Hello Cyril,


On Mon, 30 Mar 2020 20:34:41 +0200 Cyril Brulebois  wrote:
> Beware, starting with bullseye (Debian 11, currently in “testing” mode),
> the security suite will be named -updates rather than
> /updates.

Thanks for the hint. This is now handled properly since Munin 2.0.65.


> I'll see what happens in the upcoming days/weeks; I already anticipate
> that I'll have to tweak the limits for some suites: “apt-get
> dist-upgrade” would only upgrade packages from the “-backports”
> suite *if they are currently installed from there*, while it seems the
> new apt_all plugin reports all packages that could be upgraded there,
> even if the current version is that of the base … I can expand
> with some example if you'd like.
> 
> 
> FWIW: That's the usual behaviour for suites configured with:
> 
> NotAutomatic: yes
> ButAutomaticUpgrades: yes
> 
> which is the case for *-backports suites (experimental is a little
> different).

Maybe you could take a look at the current state of your apt_all tracking?

I would be glad to fix remaining details for Bullseye, if possible.

Thank you!

Cheers,
Lars

Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[devel]

Hello Daniel,

thanks for looking into the issue again!


Am Fri, 12 Feb 2021 11:11:58 -0500
schrieb Daniel Kahn Gillmor :

> > Due to repeated crashes, I started to collect stack traces.  
> 
> Are you still having these problems?

In fact the problem disappeared - probably around the time when I migrated my
32bit system to 64bit (just the Debian packages; not hardware).


> So i'm pretty stumped as to why or how this could be happening (and i
> haven't been able to hit it myself).  If it's still going on, or if
> you've found a way that i might be able to reproduce it, please respond
> to this bug report.

Thank you for digging further into the issue and for sharing your findings.
I looked through them, but failed to spot anything that could explain my
crashes.

Thus if my "32 bit theory" does not trigger any more ideas, then I would
suggest to close this bug report as non-reproducible or invalid.
Thanks again for your time!

Cheers,
Lars


pgpqxS4GzochJ.pgp
Description: Digitale Signatur von OpenPGP

Bug#1003252: AttributeError: install_layout

[devel]

Hello,

thank you for fixing this issue for Python 3.10!

Do you think, that this issue is relevant enough for being fixed in Bullseye?
(as hinted by the bug submitter)

Thank you for your time!

Cheers,
Lars

Bug#836577: python-chartkick: contains embedded code copy of Javascript library Chartkick.js

[devel]

Hello,


On Mon, 5 Sep 2016 22:26:14 +0800 ChangZhuo Chen =?utf-8?B?KOmZs+aYjOWArCk=?=
 wrote:
> I will create package for chartkick.js and use link in python-chartkick.

and indeed you created that package:
 https://tracker.debian.org/pkg/chartkick.js

Thank you!

Maybe you could now replace the embedded code copy with a symlink to the other
package?
(which was kindly updated just a few months ago)

Thank you for your time!

Cheers,
Lars

Bug#768376: [Pkg-libvirt-maintainers] Bug#768376: [libvirt-daemon-system]

[devel]

Hello,

given the recent CVE-2021-4034 (gaining local root access via "policykit-1"), I
would like to raise this request again: it would be great, if the
libvirt-daemon-system package would reduce its hard dependency ("Depends") on
"policykit-1" to a soft dependency ("Recommends").

If I understand your previous comment correctly, then this is technically
feasible (i.e. "it just works"):

On Tue, 7 Jul 2015 07:15:06 +0200 Guido Günther  wrote:
> I do agree that being able to go without polkit would be nice but a
> similar situation with virt-manger showed that Recommends: are just not
> enough. Many people skip them and then report bugs if you use Recommends
> for a package that's needed in 95% of the installations. I'm just not up
> to handle these.


I understand, that such bug reports can take effort.
But I think, the circumstances changed meanwhile (since 2015): "apt" installs
"Recommends" by default (see `apt-config dump | grep -w Recommends`), thus there
should be only very few users who are manually overriding this setting.
And I think, there is a fair chance, that these users know what they are doing.

The Debian Policy [2] also advises to use "Recommends" in this case.

Please reduce the "Depends" relationship towards "policykit-1" down to
"Recommends".

Thank you for maintaining this package!

Cheers,
Lars


[1] https://www.debian.org/security/2022/dsa-5059
[2] https://www.debian.org/doc/debian-policy/ch-relationships.html

Bug#845463: ITP: conan -- dependency manager for C/C++/golang

[devel]

Hello,


On Wed, 6 Oct 2021 18:00:22 +0200 Bastian Germann  wrote:
> Control: block -1 by 845482
> 
> On Thu, 14 Nov 2019 09:53:16 +0100 Helmut Grohne  
> wrote:
> 
> >  * conan requires patch-ng==1.17.1, but I couldn't find it in unstable.
> >This is a fork of https://github.com/techtonik/python-patch done by
> >conan people. Neither is packaged for Debian. Thankfully, they
> >renamed the Python module from "patch" to "patch_ng". Given that it
> >is forked by conan, vendoring could be considered.
> 
> There is work being done to have patch-ng in Debian.

meanwhile python3-patch-ng has arrived:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845482#57

Maybe this is still relevant for the packaging of conan?

Cheers,
Lars

Bug#1050042: gnupg2: in man pages, U+2010 HYPHEN instead of U+002D HYPHEN-MINUS

[devel]

Hello,

thanks for this bug report: I was confused by this recent inconvenience, too.


Just for your information, here are some related bug reports:

* d#1041731: groff started to insist on proper usage of `-` vs. `\-`:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731
* gnupg T6674: usage of yat2m and proper marking of hyphen vs. minus:
  https://dev.gnupg.org/T6674
* d#1050886: proposed changes for yat2m:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050886


Cheers,
Lars

Bug#960305: matrix-synapse: No instructions on setting up TLS

[devel]

Hello,

On Sun, 1 Aug 2021 12:08:50 +0200 Nicolas George  wrote:
> I have a tidbit of information to add:
> 
> The systemd service configuration says:
> 
> ExecStartPre=/usr/bin/python3 -m synapse.app.homeserver 
> --config-path=/etc/matrix-synapse/homeserver.yaml 
> --config-path=/etc/matrix-synapse/conf.d/ --generate-keys
> 
> The "--generate-keys" exists in the source code Python files.
> 
> Yet if I run this command explicitly, it does nothing at all, and strace
> shows it does nothing about the keys.

yes, since synapse!4509 [1] the `--generate-keys` argument does not trigger the
creation of TLS files anymore.
(the new alias `--generate-missing-config` for that option is less misleading)
Thus it would probably be a good idea for the matrix-synapse package to disable
the TLS configuration by default and to use the new `--generate-missing-config`
(instead of `--generate-keys`) to avoid any confusion.

Disabled TLS is also the default configuration provided by
`/usr/bin/synapse_generate_config`.
Probably most users will use a separate reverse proxy. Thus, the enabled TLS
setting could infact complicate deployment for many people.

Thank you for maintaining the package!

Cheers,
Lars


[1] https://github.com/matrix-org/synapse/pull/4509

Bug#1031046: Asterisk removed from Debian Bookworm

[Devel]

Hi,

I'm ready to help to keep asterisk in the Debian project.

At this time I'm compiling from scratch on each new version (18 as well 
as 20), I know nothing about creating packages but able to understand 
the mechanism with a little help.


I'm too on community list.

Regards

--
Daniel

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[devel]

On Thu, Dec 28, 2023 at 05:41:52PM +0100, Guilhem Moulin wrote:
> Hi,
> 
> Upstream has now released 3.2.5 which fixes the issue
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352411=Text=10510
> 
> The fix can be found at
> 
> https://github.com/apache/xerces-c/pull/54
> 
> https://github.com/apache/xerces-c/commit/e0024267504188e42ace4dd9031d936786914835
> 
> I'll prepare an upload for buster (LTS) with the above.  Bill, do you
> plan to upload 3.2.5 to sid soon?  Otherwise I can offer an NMU with the
> upstream patch.

Hi,

Thanks for doing this.

I don't have a lot of free time at the moment, so please feel free to NMU.

Best regards,
Bill

Bug#1057369: otpclient is producing incorrect codes

[devel]

Hello,

downgrading `optclient` to the bookworm version (which implies the installation
of libcotp12) fixes the problem for me.

(please note, that *new* OTP keys created in a newer version of otpclient need
to be discarded and created again)

I just opened an upstream issue [1] for otclient regarding the strict version
requirement.

Lars

[1] https://github.com/paolostivanin/OTPClient/issues/329

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[devel]

On Sun, Dec 31, 2023 at 11:45:06AM +0100, Guilhem Moulin wrote:
> 
> Thanks for the fast reply!  3.2.4+debian-1.1 is now in trixie, you'll
> find the commits and tag at
> https://salsa.debian.org/lts-team/packages/xerces-c.git
> 
> I also filed a MR to update your repository with that NMU:
> https://salsa.debian.org/bblough/xerces-c/-/merge_requests/3

Wonderful!  Thanks very much for your help.

Bill

Bug#1069960: passwordsafe: (regression) pwsafe crashes after supplying master password

[devel]

On Sat, Apr 27, 2024 at 05:51:38PM +0200, Manny wrote:
> 
> After upgrading from Bullseye to Bookworm, pwsafe crashes after
> supplying the master password. Terminal output shows:


Hi, thanks for your report.

If you have the ability to test 1.17 from testing/unstable, or 1.18 from
upstream, it would be helpful to know if you do/don't see the same
assertion failure with those.

In the mean time, I'll try to look at it and see if I can figure out
what's causing it.


> It’s worth noting that my DB file was originally created by Bruce
> Schneier’s “pwsafe” CLI tool. That package died for some reason and as

This is a common misconception.

Bruce's original PasswordSafe was a (windows-only) GUI application, and
the GUI version we're shipping in Debian is a direct descendant of that
original code [1].

The CLI-only version was a unix-compatible clone from another developer [2]
(towards the bottom, "pwsafe password database" for Unix) that got
popular because there was no official Linux version at that time.

That developer was unresponsive for several years, and the package was
dropped from Debian [3] [4].  The author has since resurfaced [5], but has
stated that he doesn't plan on supporting the current database version
(v3) [6].

Not that any of that changes the issue you're having.

[1] https://www.schneier.com/academic/passsafe/
[2] http://pwsafe.org/relatedprojects.shtml
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601300
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619704
[5] https://github.com/nsd20463/pwsafe
[6] https://github.com/nsd20463/pwsafe/issues/13#issuecomment-328247430


> However, it was only compatible in terms of *reading* the DB. Edits
> result in corruption (yikes!). So I was crippled with version
> 1.12.0+dfsg-1 but at least I could /read/ my DB. Of course this crash
> in version 1.16.0+dfsg-4 is a total show stopper.

Assuming this corruption is similar to what was reported upstream [7],
the database itself should be unchanged, and the corrupted changes you see
should only be in the GUI.  That doesn't really make it any more useable for
you, but at least it hopefully shouldn't be trashing your data.

That said, v3 was released in 2006, and v1 and v2 have been deprecated
for quite a while. So if you want to continue using PasswordSafe, you'll want
to import your v2 database, then save it as v3 in order to edit it going
forward [8]. Of course, in doing that, you won't be able to open it in the
old CLI any more, since it doesn't support v3.

[7] https://github.com/pwsafe/pwsafe/issues/367
[8] https://github.com/pwsafe/pwsafe/issues/180


Also, if CLI is a sticking point for you, upstream has been working on a
CLI-based version for a while, but we're not currently shipping it as
part of the Debian package. I can look into adding that if it would be
helpful.  Though I haven't used it, so I can't speak to how it is.


Best regards,
Bill

Bug#496032: setting package to exiftags, tagging 496032

[jackyf . devel]

# Automatically generated email from bts, devscripts version 2.10.35
# via tagpending 
#
# exiftags (1.01-3) unstable; urgency=low
#
#  * debian/rules:
#- Removed '.PHONY' entry for binary-arch and binary-indep.
#  (Closes: #496032)
#

package exiftags
tags 496032 + pending



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#498797: setting package to html2text, tagging 498797

[jackyf . devel]

# Automatically generated email from bts, devscripts version 2.10.35
# via tagpending 
#
# html2text (1.3.2a-10) experimental; urgency=low
#
#  * debian/patches:
#- 220-nobs-when-stdout-is-a-tty.patch: deleted, useless now, since
#  backspaces are not produced at all.
#- 400-remove-builtin-http-support.patch: refreshed.
#- 500-utf8-support.patch: refreshed.
#- 510-utf8-implies-nobs.patch: deleted, useless now.
#- New 510-disable-backspaces.patch: disable backspaces because parser
#  cannot produce them rightly in multi-byte sequences now.
#- 611-recognize-input-encoding.patch:
#  - Corrected to don't produce error if '-nometa' option was not supplied
#and input html doesn't contain valid 'meta http-equiv' tag.
#  - Corrected to don't display debug info twicely (if -debug-parser or
#-debug-scanner was supplied).
#  - Corrected: now parser always processes UTF-8 text, needed for proper
#output recoding.
#  - Moved recoding code to separate function.
#  - Close input stream directly after read, not after the processing.
#  - Correctly mark the end of converted sequence.
#- New 630-recode-output-to-locale-charset.patch: convert output to current
#  locale charset. (Closes: #498797)
#- 300-replace-zeroes-with-null.patch: renamed to
#  800-replace-zeroes-with-null.patch.
#- New 810-fix-deprecated-conversion-warnings.patch: fix 'deprecated
#  conversion from string constant to ‘char*’' warnings during build by
#  supplying 'const' qualifier in needed places.
#

package html2text
tags 498797 + pending



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#819047: libpt-dbg: No debug symbols

[Devel Chip]

Package: libpt-dbg
Version: 2.10.10~dfsg-4.1
Severity: normal

There are no debugging symbols: 'objdump --debugging' shows nothing.

GDB also reports 'no debugging symbols found' when running with 'set
verbose on':

Reading symbols from /usr/lib/libpt.so.2.10.10...Reading symbols from
/usr/lib/debug//usr/lib/libpt.so.2.10.10...(no debugging symbols
found)...done.
(no debugging symbols found)...done.

Steps to reproduce:

$ aptitude install simpleopal libpt-dbg

$ gdb /usr/bin/simpleopal

(gdb) set verbose on

(gdb) r

Result in the output: `no debugging symbols found` for libpt.

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500,
'vivid'), (100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 3.19.0-21-generic (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 libpt-dbg depends on:
ii  libpt2.10.10  2.10.10~dfsg-4.1

libpt-dbg recommends no packages.

libpt-dbg suggests no packages.

-- no debconf information

Bug#570623: reprepro: please add multiple version management

[Devel Chip]

> Error while parsing 'asterisk-config|1:13.3.0-acos1+o0' as version: epoch in 
> version is not number

I don't think that '|' character is allowed in the names by design.

But I've encountered another unrelated problem when syncing.

The conf/updates file (package name is in the mirror.packages):

Name: upstream-update
Method: http://localhost:20080/
Components: main
FilterList: purge ../mirror.packages

The receiving repository has multiple versions of a package.

The following error occurs:

Calculating packages to get...
Package database is not sorted!!!
reprepro: upgradelist.c:134: save_package_version: Assertion `0' failed.

Bug#570623: Info received (Bug#570623: reprepro: please add multiple version management)

[Devel Chip]

ATTENTION: I have no idea of what I'm doing

fixing update/sync:

diff --git a/upgradelist.c b/upgradelist.c
index 272b46c..8ee0de2 100644
--- a/upgradelist.c
+++ b/upgradelist.c
@@ -126,7 +126,7 @@ static retvalue save_package_version(struct upgradelist
*upgrade, const char *pa
if (strcmp(packagename, upgrade->last->name) > 0) {
upgrade->last->next = package;
upgrade->last = package;
-   } else {
+   } else if (strcmp(packagename, upgrade->last->name) != 0) {
/* this should only happen if the underlying
 * database-method get changed, so just throwing
 * out here */


On 18 April 2016 at 08:42, Debian Bug Tracking System  wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Bernhard R. Link 
>
> If you wish to submit further information on this problem, please
> send it to 570...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 570623: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#611282: [Pkg-opennebula-devel] Seperate client package

[wvengen+pkg-opennebula-devel]

Hi Damien,

Thanks for your quick response! I'm happy to hear you like the idea and 
that you've submitted a bug report (which I might do right away next 
time :) ).



IMHO, we have to split actual opennebula package in something like :

Looks good, but see comments.


- libopennebula-ruby (all /usr/lib/one/ruby/ ? split client and server
  part ?)

  it's about 600k ... I'd leave it one package


- opennebula-tools (onevm  others CLI tools)

  or maybe opennebula-client


- opennebula (oned, sched_mm and all /etc/one )

  opennebula-server? (which would recommend the client, I guess)

- opennebula
  possibly meta-package containing dependencies for client+server,
  or maybe a transitional package to opennebula-server and -client?

Just my 2c.

Regards,
- Willem



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

Bug#524190: [Bash-completion-devel] Bug#524190: bash-completion: SSH completion of know hosts doesn't handle multiple host files

[bash-completion-devel]

David Paleino wrote:


The eval line used to expand $HOME etc, is dangerous (probably only for
the users of a system if you have a BOFH). With multiple entries the
next entry will be tried to be executed;


This is a known issue, already reported in our upstream tracker (see the URL
above).


The patch solves half that problem (but won't help if the file is 
defined like $() `` etc)




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

Bug#611282: [Pkg-opennebula-devel] Seperate client package

[wvengen+pkg-opennebula-devel]

Thanks, I'm glad to see the plan is to take it up for 2.2. Great!
If you need help testing, let me know.



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

Bug#714859: Pending fixes for bugs in the fonts-wqy-zenhei package

[pkg-fonts-devel]

tag 714859 + pending
thanks

Some bugs in the fonts-wqy-zenhei package are closed in revision
ae6da6c263cecf69db76f6189ec68939ea235a92 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-wqy-zenhei.git;a=commitdiff;h=ae6da6c

Commit message:

Drop multiple value in 'test' in 25-wqy-zenhei.conf. Closes: #714859


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

Bug#725756: Pending fixes for bugs in the fonts-font-awesome package

[pkg-fonts-devel]

tag 725756 + pending
thanks

Some bugs in the fonts-font-awesome package are closed in revision
373b7fde9bb5e5aa904537939142340b9da58f95 in branch 'master' by
Vasudev Kamath

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-font-awesome.git;a=commitdiff;h=373b7fd

Commit message:

Fixed the grammar mistake in the long description.
Closes: bug#725756, Thanks to Filipus Klutiero.


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

Bug#724696: Pending fixes for bugs in the fonts-font-awesome package

[pkg-fonts-devel]

tag 724696 + pending
thanks

Some bugs in the fonts-font-awesome package are closed in revision
3b9ab6d44c83973dc50eccef3091c6535284c776 in branch 'master' by
Vasudev Kamath

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-font-awesome.git;a=commitdiff;h=3b9ab6d

Commit message:

Mentioned words LESS and Sass in long description and added Enhances on
ruby-sass and node-less.
Closes: bug#724696, Thanks to Jonas Smedegaard.


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

Bug#724698: Pending fixes for bugs in the fonts-font-awesome package

[pkg-fonts-devel]

tag 724698 + pending
thanks

Some bugs in the fonts-font-awesome package are closed in revision
71abc3ae91367a090dae369e2c4832eb43d5e1d9 in branch 'master' by
Vasudev Kamath

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-font-awesome.git;a=commitdiff;h=71abc3a

Commit message:

Added Enhances: libjs-twitter-bootstrap.
Closes: bug#724698, Thanks to Jonas Smedegaard.


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

Bug#724697: Pending fixes for bugs in the fonts-font-awesome package

[pkg-fonts-devel]

tag 724697 + pending
thanks

Some bugs in the fonts-font-awesome package are closed in revision
1adf8e44974b9a88dcce59c68d0dfd8bcf61488f in branch 'master' by
Vasudev Kamath

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-font-awesome.git;a=commitdiff;h=1adf8e4

Commit message:

Symlink the fonts to /usr/share/fonts-font-awesome/font directory to fix
the wrong path in less and scss files.
Closes: bug#724697. Thanks to Jonas Smedegaard.


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

Bug#726605: Pending fixes for bugs in the open-font-design-toolkit package

[pkg-fonts-devel]

tag 726605 + pending
thanks

Some bugs in the open-font-design-toolkit package are closed in
revision 9896d0c3881fc8e783c601c29776ea2d0b2403ed in branch 'master'
by Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/open-font-design-toolkit.git;a=commitdiff;h=9896d0c

Commit message:

Drop Recommends on bzr-dbus. Closes: #726605


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

Bug#687043: Pending fixes for bugs in the fonts-arphic-uming package

[pkg-fonts-devel]

tag 687043 + pending
thanks

Some bugs in the fonts-arphic-uming package are closed in revision
c36b3241be87d532f92f027be5df5a58097955cc in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-arphic-uming.git;a=commitdiff;h=c36b324

Commit message:

Use correct fontconfig syntax for disjunction and don't include multiple 
elements in test/alias. This obsoletes 10-fix_bitmaps_conf_file.patch and 
20-avoid-multiple-values-in-config-files.patch. Closes: #687043


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

Bug#723013: Pending fixes for bugs in the fonts-sil-charis package

[pkg-fonts-devel]

tag 723013 + pending
thanks

Some bugs in the fonts-sil-charis package are closed in revision
7b14705e6e29866f510557b88f80387afa364657 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-sil-charis.git;a=commitdiff;h=7b14705

Commit message:

New upstream release. Closes: #723013


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

Bug#728509: Pending fixes for bugs in the fonts-arphic-uming package

[pkg-fonts-devel]

tag 728509 + pending
thanks

Some bugs in the fonts-arphic-uming package are closed in revision
54ce1606ff7358a3392195da92d10f4c4d0cde24 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-arphic-uming.git;a=commitdiff;h=54ce160

Commit message:

Properly remove obsolete configuration file 
/etc/fonts/conf.avail/25-arphic-uming-nobitmaps.conf Closes: #728509


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

Bug#730797: Pending fixes for bugs in the fonts-komatuna package

[pkg-fonts-devel]

tag 730797 + pending
thanks

Some bugs in the fonts-komatuna package are closed in revision
e708a4220acd49bead39c1e2f106792f1471652e in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-komatuna.git;a=commitdiff;h=e708a42

Commit message:

* Team upload
* Add missing space in short package description
  Closes: #730797


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

Bug#730891: Pending fixes for bugs in the fonts-junicode package

[pkg-fonts-devel]

tag 730891 + pending
thanks

Some bugs in the fonts-junicode package are closed in revision
ac03aa2edb3501f18b5d7ccfd7dd30c1e4f4fff0 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-junicode.git;a=commitdiff;h=ac03aa2

Commit message:

Drop -f switch to ttfautohint as it is useless without argument and now 
makes the script fail which, in turn, fails to build TTF files. Closes: #730891


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

Bug#727880: Pending fixes for bugs in the grcompiler package

[pkg-fonts-devel]

tag 727880 + pending
thanks

Some bugs in the grcompiler package are closed in revision
fe34222695f1a5b8c7c422479db7860f0c718d67 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/grcompiler.git;a=commitdiff;h=fe34222

Commit message:

Build with autotools_dev to use up-to-date config.{guess,sub} Thanks to 
Matthias Klose. Closes: #727880


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

Bug#688252: Pending fixes for bugs in the shadow package

[pkg-shadow-devel]

tag 688252 + pending
thanks

Some bugs in the shadow package are closed in revision
0c7f32eab678fa699ade9cfe70d457f54540de47 in branch 'master' by
Nicolas François

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=0c7f32e

Commit message:

Set default editor to sensible-editor for vipw.

  * debian/rules: Set default editor to sensible-editor for vipw.
Closes: #688252


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

Bug#688260: Pending fixes for bugs in the shadow package

[pkg-shadow-devel]

tag 688260 + pending
thanks

Some bugs in the shadow package are closed in revision
16796d7e3b38d1bb40588772d41290f1b1ec375a in branch 'master' by
Nicolas François

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=16796d7

Commit message:

Document bug closed in next version.

- vipw: Fix error reporting when editor fails. Closes: #688260


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

Bug#670132: Pending fixes for bugs in the shadow package

[pkg-shadow-devel]

tag 670132 + pending
tag 677812 + pending
thanks

Some bugs in the shadow package are closed in revision
0047ae2042ec6dd529850a386ebfbab144f16690 in branch 'master' by
Nicolas François

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=0047ae2

Commit message:

Document bugs closed in next version.

- su: child cleanup is performed before terminating PAM sessions. This
  avoids anoying ...terminated messages when PAM module send signal to
  su during session close. Closes: #670132
- vipw/vigr is checking arguments provided after options. Closes: 
#677812


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

Bug#705301: Pending fixes for bugs in the shadow package

[pkg-shadow-devel]

tag 705301 + pending
thanks

Some bugs in the shadow package are closed in revision
371d5aa9691a7f92e5956ea51aa45bd2bf278da5 in branch 'master' by
Nicolas François

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=371d5aa

Commit message:

Close #705301 and #720004

  * Document the upstream update of the Japanese translation.
  * debian/login.su.pam: Enable pam_limits by default. Closes: #705301


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

Bug#722299: Pending fixes for bugs in the xfonts-wqy package

[pkg-fonts-devel]

tag 722299 + pending
thanks

Some bugs in the xfonts-wqy package are closed in revision
6ffa51f7c946641748714ede9d6e177e22de477c in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/xfonts-wqy.git;a=commitdiff;h=6ffa51f

Commit message:

Use dh_install properly to install the fonts.alias file Rename the file 
after it is installed. Closes: #722299


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

Bug#722299: Pending fixes for bugs in the xfonts-wqy package

[pkg-fonts-devel]

tag 722299 + pending
thanks

Some bugs in the xfonts-wqy package are closed in revision
3cb95e67c0f8053989c504f0d321cb6d80e5abe1 in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/xfonts-wqy.git;a=commitdiff;h=3cb95e6

Commit message:

* Drop removed conffile handling from preinst
* Drop wrongly placed fonts.alias file introduced in 0.9.9-5
  Closes: #722299


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

Bug#721401: Pending fixes for bugs in the libspiro package

[pkg-fonts-devel]

tag 721401 + pending
thanks

Some bugs in the libspiro package are closed in revision
5fa52478121a3875a3c0efdb1097821f5dd75e47 in branch 'master' by
Vasudev Kamath

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/libspiro.git;a=commitdiff;h=5fa5247

Commit message:

Marked the packages multi-arch same, and added pre-depends on
multiarch-support. Thanks to Christian Marillat.
Closes: bug#721401


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

Bug#722532: Pending fixes for bugs in the open-font-design-toolkit package

[pkg-fonts-devel]

tag 722532 + pending
thanks

Some bugs in the open-font-design-toolkit package are closed in
revision 16ce009d9826a6ce4a693896c6c15a4be2ef105b in branch 'master'
by Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/open-font-design-toolkit.git;a=commitdiff;h=16ce009

Commit message:

No longer include bzr-gtk in the design toolkit. Closes: #722532


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

Bug#722991: Pending fixes for bugs in the libspiro package

[pkg-fonts-devel]

tag 722991 + pending
thanks

Some bugs in the libspiro package are closed in revision
acb0cf1ab38866868fb056fee9444e33479f81da in branch 'master' by
Vasudev Kamath

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/libspiro.git;a=commitdiff;h=acb0cf1

Commit message:

Drop --with=kde option it works only with CMake and KDE packages.
Closes: bug#722991. Thanks to Christian Marillat.


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

Bug#722054: Pending fixes for bugs in the fonts-ebgaramond package

[pkg-fonts-devel]

tag 723159 + pending
tag 722054 + pending
thanks

Some bugs in the fonts-ebgaramond package are closed in revision
046252cf2b64edb5a4df6ab2c15074a13118f22b in branch 'master' by Scott
Howard

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-ebgaramond.git;a=commitdiff;h=046252c

Commit message:

Documented the license for tests/test-microtype.tex (lppl-1.3c) Closes: 
#723159 Thanks Paul Tagliamonte; Split Initials and ttf into 
fonts-ebgaramond-extra (Closes: #722054)


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

Bug#723737: Pending fixes for bugs in the fonts-ebgaramond package

[pkg-fonts-devel]

tag 723737 + pending
thanks

Some bugs in the fonts-ebgaramond package are closed in revision
1c6bdf3aced7f77d0de996eedb615a7d67f1 in branch 'master' by Scott
Howard

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-ebgaramond.git;a=commitdiff;h=1c6bdf3

Commit message:

Declare that fonts-ebgaramond-extra replaces fonts-ebgaramond  
0.015+git20130628-1. (Closes: #723737)


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

Bug#737965: Pending fixes for bugs in the fonts-freefont package

[pkg-fonts-devel]

tag 737965 + pending
thanks

Some bugs in the fonts-freefont package are closed in revision
4e5d91b87b29835b309190bd5d357b9c5618053c in branch 'master' by
Christian Perrier

The full diff can be seen at
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-freefont.git;a=commitdiff;h=4e5d91b

Commit message:

Re-introduce transitional packages. Closes: #737965


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