Bug#911312: firefox-esr: automatical download of libgmpopenh264.so with default settings
Package: firefox-esr Version: 60.2.2esr-1~deb9u1 Severity: normal Dear Maintainer, I have noticed that a binary library libgmpopenh264.so has been put into ~/.mozilla/firefox/.default/gmp-gmpopenh264/1.6 although media.gmp-gmpopenh264.enabled is false. I did not install any plugins or add-ons. It is also strange that the file was last modified on Oct 17, because on a different installation I found version 1.7.1 with an *earlier* modification time (but here third-party plugins were installed and removed several times with no possibility of reconstructing what exactly happened). It is quite difficult to find out exactly where this binary comes form and whether it is the "official" one. The binary files by Cisco that can be regularly found on the web are different. A user in the Debian IRC channel told me that he found a reference to http://ciscobinary.openh264.org/ openh264-linux64-0410d336bb748149a4f560eb6108090f078254b1.zip in /usr/lib/firefox-esr/omni.ja which I also have. And indeed this is the binary that I found on my system, so it seems to be something official. Nevertheless, I think this is not the expected behaviour. Unfortunately, starting firefox from an empty profile does not automatically download the file. Something else must have triggered the download, which I could not reproduce. (Just speculating: Maybe visiting certain websites or starting firefox after being updated by "apt upgrade", which happended several times?)
Bug#877992: Info received (Bug#877992: Info received (postfix: Postfix does not start services after upgrade to stretch 9.2 and reboot))
I confirm that I am using "inet_interfaces=..." as well.
Bug#877992: Info received (postfix: Postfix does not start services after upgrade to stretch 9.2 and reboot)
I use the following temoporary fix for a default instance only setup, which will persist across reboots: ln -s /lib/systemd/system/postfix@.service /etc/systemd/system/postfix.service.wants/postfix@-.service
Bug#874307: Correction
Can you show "systemctl status openvpn-server@first.service" and "systemctl status openvpn-server@second.service", both before and after the restart? Actually, the whole directory seems to be removed as it gets a new inode number. Note that first I have to completely restart "first" and then restart "second". This is the complete sequence of commands I ran, including the requested information. # ls -di /run/openvpn-server 13067 /run/openvpn-server # ls /run/openvpn-server status-first.log status-second.log # systemctl status openvpn-server@first.service ● openvpn-server@first.service - OpenVPN service for first Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-10-10 05:42:12 UTC; 54s ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Main PID: 1361 (openvpn) Status: "Initialization Sequence Completed" Tasks: 1 (limit: 4915) CGroup: /system.slice/system-openvpn\x2dserver.slice/openvpn-server@first.service └─1361 /usr/sbin/openvpn --status /run/openvpn-server/status-first.log --status-version 2 --suppress-timestamps --config first.conf Oct 10 05:42:12 box openvpn[1361]: WARNING: --keepalive option is missing from server config Oct 10 05:42:12 box openvpn[1361]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 10 05:42:12 box openvpn[1361]: TUN/TAP device tap9 opened Oct 10 05:42:12 box openvpn[1361]: Could not determine IPv4/IPv6 protocol. Using AF_INET Oct 10 05:42:12 box openvpn[1361]: UDPv4 link local (bound): [AF_INET][undef]:12345 Oct 10 05:42:12 box openvpn[1361]: UDPv4 link remote: [AF_UNSPEC] Oct 10 05:42:12 box openvpn[1361]: GID set to nogroup Oct 10 05:42:12 box systemd[1]: Started OpenVPN service for first. Oct 10 05:42:12 box openvpn[1361]: UID set to nobody Oct 10 05:42:12 box openvpn[1361]: Initialization Sequence Completed # systemctl status openvpn-server@second.service ● openvpn-server@second.service - OpenVPN service for second Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-10-10 05:42:22 UTC; 3min 49s ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Main PID: 1407 (openvpn) Status: "Initialization Sequence Completed" Tasks: 1 (limit: 4915) CGroup: /system.slice/system-openvpn\x2dserver.slice/openvpn-server@second.service └─1407 /usr/sbin/openvpn --status /run/openvpn-server/status-second.log --status-version 2 --suppress-timestamps --config second.conf Oct 10 05:42:22 box openvpn[1407]: WARNING: --keepalive option is missing from server config Oct 10 05:42:22 box openvpn[1407]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 10 05:42:22 box openvpn[1407]: TUN/TAP device tap8 opened Oct 10 05:42:22 box openvpn[1407]: Could not determine IPv4/IPv6 protocol. Using AF_INET Oct 10 05:42:22 box openvpn[1407]: UDPv4 link local (bound): [AF_INET][undef]:12346 Oct 10 05:42:22 box openvpn[1407]: UDPv4 link remote: [AF_UNSPEC] Oct 10 05:42:22 box openvpn[1407]: GID set to nogroup Oct 10 05:42:22 box openvpn[1407]: UID set to nobody Oct 10 05:42:22 box openvpn[1407]: Initialization Sequence Completed Oct 10 05:42:22 box systemd[1]: Started OpenVPN service for second. # systemctl restart openvpn-server@first # systemctl restart openvpn-server@second # ls -di /run/openvpn-server 20235 /run/openvpn-server # ls /run/openvpn-server status-second.log # systemctl status openvpn-server@first.service ● openvpn-server@first.service - OpenVPN service for first Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-10-10 05:47:01 UTC; 3min 46s ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Main PID: 1488 (openvpn) Status: "Initialization Sequence Completed" Tasks: 1 (limit: 4915) CGroup: /system.slice/system-openvpn\x2dserver.slice/openvpn-server@first.service └─1488 /usr/sbin/openvpn --status /run/openvpn-server/status-first.log --status-version 2 --suppress-timestamps --config first.conf Oct 10 05:47:01 box openvpn[1488]: WARNING: --keepalive option is missing from server config Oct 10 05:47:01 box openvpn[1488]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 10 05:47:01 box openvpn[1488]: TUN/TAP device tap9 opened Oct 10 05:47:01 box openvpn[1488]: Could not determine IPv4/IPv6 protocol. Using AF_INET Oct 10 05:47:01 box openvpn[1488]: UDPv4
Bug#877992: postfix: Postfix does not start services after upgrade to stretch 9.2 and reboot
I have the same problem: /lib/systemd/system-generators/postfix-instance-generator does not generate the required links on boot, but it does on reinstall.
Bug#874307: Correction
Actually, this only happens when using "systemctl restart", not "systemctl start".
Bug#874307: multiple openvpn instances wrongly remove status files of preceding ones
Package: openvpn Version: 2.4.0-6+deb9u1 Severity: normal Dear Maintainer, I am running two openvpn instances via config files /etc/openvpn/server/first.conf /etc/openvpn/server/second.conf Starting the second instance via systemctl start openvpn-server@second while the first instance is running removes the status file /run/openvpn-server/status-first.log. But the correct behaviour should be that all status files remain accessible.
Bug#860403: Acknowledgement (mounting root filesystem takes 20 seconds longer than before because mdadm script is called repeatedly)
Actually, this had nothing to do with mdadm. The scripts were waiting
for the resume swap partition, which was autodetected by mkinitramfs,
but can not be found anymore because it was encrypted with a random key.
As a workaround, I added the following script to /etc/initramfs-tools/hooks:
#! /bin/sh
test -f ${DESTDIR}/conf/conf.d/resume && rm ${DESTDIR}/conf/conf.d/resume
return 0
But what is the correct way to disable resume partition autodetection?
Bug#860403: mounting root filesystem takes 20 seconds longer than before because mdadm script is called repeatedly
Package: initramfs-tools-core Version: 0.128 Severity: important Dear Maintainer, in 0.128 scripts/local was changed to call scripts/local-block/mdadm repeatedly, resulting in a 20 second delay when booting although my root filesystem is not on an array and I do not want to uninstall mdadm.
Bug#858445: Wrong subject
I submitted the bug with the wrong subject, sorry for that.
Bug#858445: apparent freeze when exiting text session on second vt while X is running on first vt
Package: light-locker Version: 1.7.0-3 Severity: normal Dear Maintainer, I have installed Xfce which includes light-locker. When Xfce blanks the screen automatically after the configured timespan or if I lock the screen manually, the screen goes blank and pressing any keys or moving the mouse will not show anything. I can, however, switch to another VT with Ctrl+Alt+F2 and kill the Xorg process from there. This happens when I use text console logins and use "startx" to start Xorg. On the other hand, if I switch the system to graphical login, then locking the screen brings me back to the login screen, and after logging in again, I am back at my original session. This might be the intended behaviour.
Bug#858073: apparent freeze when exiting text session on second vt while X is running on first vt
Does changing if [ "$SHLVL" = 1 ] in ~/.bash_logout to if [ "$SHLVL" = 2 ] alter the behaviour? Yes, in this case I just get the login prompt on the same VT again, and I can switch back with Ctrl+F1 without any problems.
Bug#858073: apparent freeze when exiting text session on second vt while X is running on first vt
Package: general Severity: important Dear Maintainer, I do not know under which package this bug should be filed or what additional information is needed to help solve this. I am running Debian stretch and have configured it to give me text consoles on boot. I have intel graphics and for Xorg I am using the modesetting driver which has been the default for some time. The steps to reproduce the bug are as follows: 1) login on first vt. 2) run "startx" on frist vt. X is now running normally. 3) Ctrl+Alt+F2 4) login on second vt. I can use the text console normally. I can also switch back and forth between the first vt (with X) and the second vt (text console) without problems. 5) run "exit" on second vt. I now automaticaly see my X session on the first vt again. However, I can not move the mouse and my keyboard is not working. The system seems to be frozen. 6) Alt+F1 After typing Alt+F1 in the frozen state, the X server dies and I get back the text console. I can now start X again. Note: If I override the driver by putting Driver "intel" into xorg.conf, I get the same behaviour except that after Step 6 my screen just turns black completely.
Bug#858070: ifupdown: ifdown puts the interface down before removing the IPv6 addresses
Package: ifupdown Version: 0.8.19 Severity: normal Tags: ipv6 Dear Maintainer, when both IPv4 and IPv6 are statically configured, ifdown first removes the IPv4 addresses, then puts the interfaces down, and then tries to remove the IPv6 addresses, which results in the error message "RTNETLINK answers: Cannot assign requested address". Here is the verbose output: root@host:~# ifdown -v ens2 ifdown: reading directory /etc/network/interfaces.d ifdown: parsing file /etc/network/interfaces.d/ens2 ifdown: configuring interface ens2=ens2 (inet) /bin/run-parts --verbose /etc/network/if-down.d /bin/ip addr del 10.0.0.1/255.255.255.255 broadcast 10.0.0.1 dev ens2 label ens2 /bin/ip link set dev ens2 down /bin/run-parts --verbose /etc/network/if-post-down.d ifdown: configuring interface ens2=ens2 (inet6) /bin/run-parts --verbose /etc/network/if-down.d /bin/ip -6 addr del fd00::1/128 dev ens2 RTNETLINK answers: Cannot assign requested address /bin/ip link set dev ens2 down /bin/run-parts --verbose /etc/network/if-post-down.d
Bug#857758: inspircd writes everything to logfile twice with default configuration
Source: inspircd Version: 2.0.23-2 Severity: normal Dear Maintainer, the default configuration gives inspircd a --logfile argument in addition to the section in the config file, which leads to everything being logged twice.
