Bug#1033231: postgrey: postinst does not create user or install default config files
Package: postgrey Version: 1.37-1.1 Severity: important Tags: patch Dear Maintainer, Sometime last year, the postinst file was removed from the postgrey package. This was done in commit [efe56824 - Remove all debconf bits for the port migration in 1.32-3]. So, the current package does not install required config files in /etc/postgrey, and it doesn't create a user to run as. As it seems the removal of these specific actions was unintended, and postgrey needs both actions to be completed before it can run, it would be nice if these could be reinstated. There's an open merge request doing this: https://salsa.debian.org/debian/postgrey/-/merge_requests/1 Could this perhaps be merged before bookworm is released? Best regards, Roel -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages postgrey depends on: ii adduser 3.131 ii init-system-helpers 1.65.2 ii libberkeleydb-perl 0.64-2+b1 ii libnet-dns-perl 1.36-1 ii libnet-server-perl 2.013-2 ii libnetaddr-ip-perl 4.079+dfsg-2+b1 ii perl 5.36.0-7 ii ucf 3.0043+nmu1 Versions of packages postgrey recommends: ii libnet-rblclient-perl 0.5-4 ii libparse-syslog-perl 1.10-4 ii postfix3.7.4-2 postgrey suggests no packages. -- debconf information excluded
Bug#1008684: openvswitch-switch update leaves interfaces down
Package: openvswitch-switch Version: 2.15.0+ds1-2+deb11u1 Severity: normal Dear Maintainer, today we noticed on several hosts that the upgrade of openvswitch-switch left the network configuration in a broken state. This doesn't happen every time, but it is easily reproducible. We're using an OVSBridge with two physical interfaces and an internal port. The config looks like this: allow-vmbr2 ens19 iface ens19 inet manual ovs_type OVSPort ovs_bridge vmbr2 allow-vmbr2 ens20 iface ens20 inet manual ovs_type OVSPort ovs_bridge vmbr2 allow-vmbr2 stor0 iface stor0 inet static address 172.25.42.80 netmask 255.255.255.0 ovs_type OVSIntPort ovs_bridge vmbr2 auto vmbr2 iface vmbr2 inet manual ovs_type OVSBridge ovs_ports stor0 ens19 ens20 The starting situation looks like this: 3: ens19: mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000 link/ether 02:a7:4d:e2:1e:50 brd ff:ff:ff:ff:ff:ff 4: ens20: mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000 link/ether b2:b6:81:92:b6:05 brd ff:ff:ff:ff:ff:ff 26: ovs-system: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ba:20:fd:9e:fa:66 brd ff:ff:ff:ff:ff:ff 27: vmbr2: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 66:b7:9e:3e:48:4c brd ff:ff:ff:ff:ff:ff 28: stor0: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether e6:da:c8:f2:58:f4 brd ff:ff:ff:ff:ff:ff inet 172.25.42.80/24 brd 172.25.42.255 scope global stor0 valid_lft forever preferred_lft forever and after running 'dpkg-reconfigure openvswitch-switch' several times to reproduce the problem, it looks like this: 3: ens19: mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000 link/ether 02:a7:4d:e2:1e:50 brd ff:ff:ff:ff:ff:ff 4: ens20: mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000 link/ether b2:b6:81:92:b6:05 brd ff:ff:ff:ff:ff:ff 26: ovs-system: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ba:20:fd:9e:fa:66 brd ff:ff:ff:ff:ff:ff 29: stor0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether e6:da:c8:f2:58:f4 brd ff:ff:ff:ff:ff:ff 30: vmbr2: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 66:b7:9e:3e:48:4c brd ff:ff:ff:ff:ff:ff Note that both stor0 and vmbr2 have gotten new interface numbers, their state is now DOWN, and the IP address of stor0 is gone. According to ifupdown, the interfaces are configured. The issue can be fixed by calling 'ifdown vmbr2; ifup vmbr2', where ifdown outputs: RTNETLINK answers: Cannot assign requested address We've tested this with 2.15.0+ds1-2+deb11u1, 2.15.0+ds1-8~bpo11+1 and 2.15.0+ds1-10, and they all exibit the same behaviour. It may be relevant that we're using ifupdown 0.8.36. Obviously it is inconvenient to get updates and then find networking in an inconsistent state. I can provide more information if necessary, and since we've been able to reproduce this we can also run things with debugging or test patches, but some direction about what you need would be appreciated. Best regards, Roel -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.140-1-pve (SMP w/2 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openvswitch-switch depends on: ii kmod28-1 ii lsb-base11.1.0 ii netbase 6.3 ii openvswitch-common 2.15.0+ds1-2+deb11u1 ii procps 2:3.3.17-5 ii uuid-runtime2.36.1-8+deb11u1 openvswitch-switch recommends no packages. openvswitch-switch suggests no packages. -- no debconf information
Bug#1003925: asterisk: replace mysql with mariadb in init script LSB header
Package: asterisk Version: 1:16.16.1~dfsg-1+deb11u1 Severity: normal Tags: patch Dear Maintainer, due to the rename of the mysql service to mariadb in Bullseye, the asterisk service is no longer started after the mysql/mariadb database service when using sysvinit. This can lead to problems when using cdr_mysql.so and possibly other MySQL-related modules, because they fail to connect when asterisk starts. Replacing mysql by mariadb in the LSB header should remedy this problem. Please find a patch attached. Thank you for your time. diff -pru a/asterisk b/asterisk --- a/asterisk 2019-08-20 22:31:33.0 +0200 +++ b/asterisk 2022-01-18 09:07:04.0 +0100 @@ -14,8 +14,8 @@ # Provides: asterisk # Required-Start:$remote_fs # Required-Stop: $remote_fs -# Should-Start: $syslog $network $named mysql postgresql dahdi -# Should-Stop: $syslog $network $named mysql postgresql +# Should-Start: $syslog $network $named mariadb postgresql dahdi +# Should-Stop: $syslog $network $named mariadb postgresql # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Asterisk PBX
Bug#989720: openvswitch-switch: /etc/network/interfaces seems ignored
Hi, I can confirm that replacing 'allow-ovs' by 'auto', as suggested by Philippe Latu works for us, but openvswitch itself recommends not to do this, as per https://github.com/openvswitch/ovs/blob/master/debian/openvswitch-switch.README.Debian#L308 Admittedly this dates from 2017 so it might be obsolete. If that is the case, it would be useful to have it updated upstream. In Buster, openvswitch-switch.service would start the openvswitch-switch init script, which in turn would call ifup --allow=ovs. In Bullseye this is no longer the case. What would be the recommended way to start bridges on Bullseye? I think either the bridge interfaces should be marked as 'auto', or there should be some place that calls 'ifup --allow=ovs'. Perhaps it is relevant to note that we are using ifupdown, not ifupdown2. Best regards, Roel
Bug#977957: spamassassin: patch
Dear maintainer,
this small fix will solve the problem that sa-compile cannot be installed
while start-stop-daemon is dpkg-diverted. Since I don't know which workflow
you prefer, there's also a merge request for it at
https://salsa.debian.org/debian/spamassassin/-/merge_requests/5
Thanks for your time,
Roel
>From 41840d3b51cf08403d2404693f6e45c9123b53d9 Mon Sep 17 00:00:00 2001
From: Roel van Meer
Date: Wed, 23 Dec 2020 21:15:07 +0100
Subject: [PATCH] postinst: Fix perms only if dir exists
If spamassassin is installed via the debian installer while
start-stop-daemon is diverted via dpkg-divert, sa-compile will not have
run, so the output dir doesn't exist when the postinst script tries to
change its permissions. That causes an error while configuring
sa-compile.
Fix that by checking if the dir exists.
This may still mean the permissions aren't set properly after the
package has been installed (because dpkg-diverting start-stop-daemon
means that sa-compile hasn't been run), but at least the package
installs now. If you run sa-compile manually afterwards you can set the
permissions correctly afterwards as well.
Closes: #977957
---
debian/sa-compile.postinst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/debian/sa-compile.postinst b/debian/sa-compile.postinst
index 5056f6c..3f15f22 100644
--- a/debian/sa-compile.postinst
+++ b/debian/sa-compile.postinst
@@ -18,12 +18,14 @@ sa_compile() {
start-stop-daemon --chuid $OWNER:$GROUP --start \
--exec /usr/bin/sa-compile -- --quiet
# Fixup perms -- group and other should be able to
# read and execute, but never write. Works around
# sa-compile's failure to obey umask.
-runuser -u $OWNER -- \
+if [ -d "$output_dir" ]; then
+runuser -u $OWNER -- \
chmod -R go-w,go+rX "$output_dir"
+fi
if command -v invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d --quiet spamassassin status > /dev/null && \
invoke-rc.d spamassassin reload > /dev/null 2>&1 || true
else
/etc/init.d/spamassassin reload > /dev/null 2>&1 || true
--
2.20.1
Bug#971004: start-stop-daemon: matching only on non-root pidfile /run/sympa/archived.pid is insecure
Package: sympa
Version: 6.2.40~dfsg-1
Severity: normal
Tags: patch
Dear Maintainer,
when using sysvinit, restarting sympa leaves the system with
the sympa daemons not running.
root@host:~# service sympa restart
[] Stoping Sympa mailing list manager: archivedstart-stop-daemon: matching
only on non-root pidfile /run/sympa/archived.pid is insecure
bouncedstart-stop-daemon: matching only on non-root pidfile
/run/sympa/bounced.pid is insecure
bulkstart-stop-daemon: matching only on non-root pidfile /run/sympa/bulk.pid
is insecure
task_managerstart-stop-daemon: matching only on non-root pidfile
/run/sympa/task_manager.pid is insecure
sympa_msgstart-stop-daemon: matching only on non-root pidfile
/run/sympa/sympa_msg.pid is insecure
Bug #921557 is relevant here.
Attached is a patch to fix this.
Best regards, Roel
-- System Information:
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
-- debconf information excluded
diff -pru a/sympa.init b/sympa.init
--- a/sympa.init2020-09-26 08:05:48.164515651 +0200
+++ b/sympa.init2020-09-26 08:11:00.340165016 +0200
@@ -112,6 +112,7 @@ stop_sympa() {
for daemon in $(reverse_order "$DAEMONS") ; do
log_progress_msg "$daemon"
start-stop-daemon --stop --quiet --retry 5 \
+--user "${USER}" \
--pidfile "${RUNDIR}/${daemon}.pid" || ERRORS="$ERRORS $daemon"
# It may happened that some processes are not tracked with
pidfiles.
# For example, with the parameter 'distribution_mode fork' used by
Bug#935789:
This might be https://jira.kopano.io/browse/KC-1452
Bug#942491: kopano-presence: SysV init script stop action not working
Package: kopano-presence Version: 8.7.0-3 Severity: normal Dear Maintainer, when using the SysV init script of kopano-presence, the stop action does not detect a running instance of kopano-presence. Instead of stopping the service, the following output is shown: root@host:~# service kopano-presence stop [] Stopping kopano presence daemon: kopano-presenceNo /usr/sbin/kopano-presence found running; none killed. failed! The init script of kopano-search also manages a python3 daemon (and it works correctly) so we may look there for a fix. Kind regards, Roel
Bug#941610:
This patch might be the fix for this issue. This is commit eac93901e7 in the
upstream kopanocore repo. I'll test and report back the results.
>From eac93901e73cc52d37fb4494c5711bc68dc32e60 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt
Date: Thu, 7 Mar 2019 22:35:37 +0100
Subject: [PATCH] server: check for NULL SSL context before calling
soap_ssl_error
There may be a time where soap->ssl is NULL (like, when initializing
the context failed?), but soap_ssl_error from gsoap-2.8.80 does not
test for this condition.
References: KC-1422, KC-1437
---
provider/server/ECSoapServerConnection.cpp | 4 ++--
provider/server/ECThreadManager.cpp| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/provider/server/ECSoapServerConnection.cpp b/provider/server/ECSoapServerConnection.cpp
index c2a5925b0..a02692183 100644
--- a/provider/server/ECSoapServerConnection.cpp
+++ b/provider/server/ECSoapServerConnection.cpp
@@ -268,13 +268,13 @@ ECRESULT ECSoapServerConnection::ListenSSL(const char *lpServerName,
"EC") // unique name for SSL session cache
)
{
soap_set_fault(lpsSoap.get());
#if GSOAP_VERSION >= 20873
- auto se = soap_ssl_error(lpsSoap.get(), 0, SSL_ERROR_NONE);
+ auto se = lpsSoap->ssl != nullptr ? soap_ssl_error(lpsSoap.get(), 0, SSL_ERROR_NONE) : 0;
#else
- auto se = soap_ssl_error(lpsSoap.get(), 0);
+ auto se = lpsSoap->ssl != nullptr ? soap_ssl_error(lpsSoap.get(), 0) : 0;
#endif
ec_log_crit("K-2170: Unable to setup SSL context: soap_ssl_server_context: %s: %s", *soap_faultdetail(lpsSoap.get()), se);
return KCERR_CALL_FAILED;
}
auto er = kc_ssl_options(lpsSoap.get(), server_ssl_protocols.get(), server_ssl_ciphers, pref_ciphers, server_ssl_curves);
diff --git a/provider/server/ECThreadManager.cpp b/provider/server/ECThreadManager.cpp
index bf04aa32a..79dd05abb 100644
--- a/provider/server/ECThreadManager.cpp
+++ b/provider/server/ECThreadManager.cpp
@@ -125,13 +125,13 @@ void WORKITEM::run()
// For SSL connections, we first must do the handshake and pass it back to the queue
if (soap->ctx && soap->ssl == nullptr) {
err = soap_ssl_accept(soap);
if (err) {
#if GSOAP_VERSION >= 20873
- auto se = soap_ssl_error(soap, 0, SSL_ERROR_NONE);
+ auto se = soap->ssl != nullptr ? soap_ssl_error(soap, 0, SSL_ERROR_NONE) : 0;
#else
- auto se = soap_ssl_error(soap, 0);
+ auto se = soap->ssl != nullptr ? soap_ssl_error(soap, 0) : 0;
#endif
ec_log_warn("K-2171: soap_ssl_accept: %s: %s", *soap_faultdetail(soap), se);
ec_log_debug("%s: %s", GetSoapError(err).c_str(), *soap_faultstring(soap));
}
} else {
--
2.20.1
Bug#939751:
Hi,
This patch fixes the problem (at least for me, on the one server where it
manifested itself). It might not be the best solution though. I've sent it
to Kopano to ask for feedback.
Cheers, Roel
Decrease ICS processing batch size
This fixes the following Z-push error:
StatusException: ExportChangesICS->InitializeExporter():
Error, mapi_exportchanges_config() failed: 0x8004010F
- code: 12
- file: /usr/share/z-push/backend/kopano/exporter.php:230
when running kopanocore with Mariadb 10.3.
Index: kopanocore-8.7.0/provider/libserver/ECICS.cpp
===
--- kopanocore-8.7.0.orig/provider/libserver/ECICS.cpp
+++ kopanocore-8.7.0/provider/libserver/ECICS.cpp
@@ -490,7 +490,7 @@ static ECRESULT getchanges_contents(stru
std::vector db_rows;
std::vector db_lengths;
static constexpr unsigned int ncols = 7;
- unsigned long col_lengths[1000*ncols];
+ unsigned long col_lengths[500*ncols];
unsigned int length_counter = 0;
while (lpDBResult && (lpDBRow = lpDBResult.fetch_row()) != nullptr) {
@@ -506,7 +506,7 @@ static ECRESULT getchanges_contents(stru
}
db_rows.emplace_back(lpDBRow);
db_lengths.emplace_back(lpDBLen);
- if (db_rows.size() == 1000) {
+ if (db_rows.size() == 500) {
er = lpHelper->ProcessRows(db_rows, db_lengths);
if (er != erSuccess)
return er;
Bug#941610: kopano-server crashes
Package: kopano-server Version: 8.7.0-3 Severity: normal Dear Maintainer, while running Kopano, I'm experiencing kopano-server crashes. At the time of the crash, there are no emails being delivered via Postfix, nor are there entries in the Apache access log that point to usage of Z-push or Kopano Webapp. Also, during that time nothing is logged in the gateway log, ical log, or any other Kopano logs. So I cannot point to a probable cause. Please note that I have seen these crashes on at least four of our systems so far. They seem to happen once every two weeks, on average. If there's anything I can do to help getting this fixed, please let me know. Kind regards, Roel -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages kopano-server depends on: ii dbconfig-common 2.0.11+deb10u1 ii debconf [debconf-2.0] 1.5.71 ii init-system-helpers 1.56+nmu1 ii kopano-common 8.7.0-3 ii kopano-libs 8.7.0-3 ii libc6 2.28-10 ii libcom-err2 1.44.5-1+deb10u2 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libgsoap-2.8.75 2.8.75-1 ii libgssapi-krb5-21.17-3 ii libicu6363.1-6 ii libk5crypto31.17-3 ii libkrb5-3 1.17-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii libmariadb3 1:10.3.17-0+deb10u1 ii libpam0g1.3.1-5 ii libssl1.1 1.1.1d-0+deb10u1 ii libstdc++6 8.3.0-6 ii lsb-base10.2019051400 ii mariadb-client 1:10.3.17-0+deb10u1 ii mariadb-client-10.3 [virtual-mysql-client] 1:10.3.17-0+deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages kopano-server recommends: ii mariadb-server 1:10.3.17-0+deb10u1 kopano-server suggests no packages. -- Logged in kopano server log: Fatal error detected. Please report all following information. Application kopano-server version: 8.7.0 OS: Linux, release: 4.19.0-6-amd64, version: #1 SMP Debian 4.19.67-2 (2019-08-28), hardware: x86_64 Thread name: z-s: 163.172.10 Peak RSS: 50556 Pid 11672 caught SIGSEGV (11), traceback: Backtrace: #0. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x490f0) [0x7f08e96a20f0] #1. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x333fd) [0x7f08e968c3fd] #2. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(_ZN2KC23generic_sigsegv_handlerEPNS_8ECLoggerEPKcS3_iPK9siginfo_tPKv+0x1a1) [0x7f08e968c681] #3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f08e6ae0730] #4. /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_want+0) [0x7f08e6ca3ea0] #5. /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_get_error+0x48) [0x7f08e6ca3ef8] #6. /usr/lib/x86_64-linux-gnu/libgsoapssl++-2.8.75.so(soap_ssl_error+0x18c) [0x7f08e92be04c] #7. /usr/sbin/kopano-server(+0x15347) [0x561a23e7c347] #8. /usr/lib/x86_64-linux-gnu/libkcutil.so.0(+0x3ab2b) [0x7f08e9693b2b] #9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f08e6ad5fa3] #10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f08e66e54cf] Signal errno: Success, signal code: 1 Sender pid: 40, sender uid: 0, si_status: 0 Signal value: 0, faulting address: 0x28 When reporting this traceback, please include Linux distribution name (and version), system architecture and Kopano version. -- Backtrace with gdb and debugsymbols installed (gdb) bt #0 raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f08e968c74f in KC::generic_sigsegv_handler (lpLogger=, app_name=, version_string=0x561a23e7e2d5 "8.7.0", signr=11, si=0x7f08da2e96b0, uc=) at ../../common/ECLogger.cpp:994 #2 #3 SSL_want (s=s@entry=0x0) at ../ssl/ssl_lib.c:4189 #4 0x7f08e6ca3ef8 in SSL_get_error (s=0x0, i=) at ../ssl/ssl_lib.c:3505 #5 0x7f08e92be04c in soap_ssl_error (soap=soap@entry=0x561a272e2000, ret=ret@entry=0, err=err@entry=0) at stdsoap2_ssl_cpp.cpp:4170 #6 0x561a23e7c347 in WORKITEM::run (this=0x561a269f50a0) at ../../provider/server/ECThreadManager.cpp:130 #7 0x7f08e9693b2b in KC::ECThreadPool::threadFunc (lpVoid=0x561a257c4398) at ../../common/ECThreadPool.cpp:208 #8 0x7f08e6ad5fa3 in start_thread (arg=) at pthread_create.c:486 #9 0x7f08e66e54cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Bug#940269: [Pkg-giraffe-maintainers] Bug#940269: kopano-webapp-files: Does not appear in plugins list
after installation and restart of both the Kopano server and Apache, the plugin is still not listed (the only plugin appearing is “WebApp Manual”). Thank you for reporting this problem. It seems it is necessary to have one of the filesbackend plugins installed for the files plugin to show up. Unfortunately, neither the filesbackend-owncloud nor the filesbackend-smb plugin are currently available in Buster. Best regards, Roel
Bug#940608: freeradius: Init script does not stop service when using sysvinit
Package: freeradius Version: 3.0.17+dfsg-1.1 Severity: normal Tags: patch Dear Maintainer, when using sysvinit instead of systemd, calling the init script with argument 'stop' does not stop the service. It seems in the invocation of killproc the program name is missing. Attached you should find a patch that fixes this problem. Thanks for your work, Roel diff -pru a/debian/freeradius.init b/debian/freeradius.init --- a/debian/freeradius.init2019-04-22 23:23:36.0 +0200 +++ b/debian/freeradius.init2019-09-17 19:54:37.926055502 +0200 @@ -62,7 +62,7 @@ case "$1" in stop) log_daemon_msg "Stopping $DESCR" "$PROG" -killproc -p "$PIDFILE" || ret=$? +killproc -p "$PIDFILE" "$PROG" || ret=$? log_end_msg $ret ;;
Bug#931988: ITP: kopano-webapp-plugin-intranet -- Kopano WebApp intranet plugin
Package: wnpp Severity: wishlist Owner: Roel van Meer * Package name: kopano-webapp-plugin-intranet Version : 1.0.0 Upstream Author : Kopano * URL : https://kopano.com/ https://stash.kopano.io/projects/KWA/repos/intranet/browse * License : AGPL-3 Programming Lang: PHP, JS Description : Kopano WebApp intranet plugin This package is a plugin for kopano-webapp, a web interface for the Kopano Collaboration Platform. . This plugin adds one or more buttons in the top menu bar which can be used to open a webpage inside Kopano WebApp. This package is an additional plugin for kopano-webapp. It will be maintained by Giraffe Maintainers . Kind regards, Roel
Bug#931882: ITP: kopano-webapp-plugin-desktopnotifications -- Kopano WebApp desktopnotifications plugin
Package: wnpp Severity: wishlist Owner: Roel van Meer * Package name: kopano-webapp-plugin-desktopnotifications Version : 2.0.2 Upstream Author : Kopano * URL : https://kopano.com/ https://stash.kopano.io/projects/KWA/repos/desktopnotifications/browse * License : AGPL-3 Programming Lang: PHP, JS Description : Kopano WebApp desktopnotifications plugin This package is a plugin for kopano-webapp, a web interface for the Kopano Collaboration Platform. . This plugin shows notifications of new emails and reminders on the desktop. This package is an additional plugin for kopano-webapp. It will be maintained by Giraffe Maintainers . Kind regards, Roel
