Bug#1070039: Acknowledgement (refpolicy: enforcing mode causes machine with GNOME desktop to crash)
It seems the immediate crash was caused by gnome-shell trying to do execmem, I guess some JavaScript JIT thing. After enabling the allow_execmem boolean, gnome-shell no longer crashes. I am not sure how, but it would be good to have better out-of-the-box experience with SELinux on desktop systems. At least it should not straight up crash, if the user is unaware of this boolean. The mindset sometimes seem to be that SELinux only provides benefits on headless servers. I don't see the logic in that, in fact, the use case where SELinux has most success is mobile devices (Android) and Fedora Desktop ships SELinux by default without much issues.
Bug#1070039: refpolicy: enforcing mode causes machine with GNOME desktop to crash
Package: selinux-policy-default Version: 2:2.20221101-9 Severity: important Dear Maintainer, I am fully aware that selinux is not really considered a first class citizen in Debian, especially in graphical desktop use cases. Never had any trouble with AppArmor and I've had moderate success with running selinux in servers. But, I was bit dissapointed in what happened when I attempted to enable enforcing mode in a laptop with pretty standard Debian 12 GNOME environment. I simply did the following: sudo apt install --no-install-recommends selinux-basics \ selinux-policy-default auditd sudo selinux-activate sudo reboot (Decided to skip the recommended dependencies for this test, since they bring in over 600M of random python libraries etc. I assume the recommended or suggest packages are not essential for selinux operation?) Everything went fine, files (on btrfs) got labelled, most system daemons were running on correct selinux domains, etc. However, ausearch -m avc reported over 900 policy violations. I still decided to test what happens if I put selinux into enforcing mode (sudo setenforce 1). That caused the graphical session to crash immediately, replaced with a blinking cursor. Soon after a screen appeared with a sad face and "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please contact a system administrator." I have not find much people's experiences on using selinux on desktop Debian, but I can't be the only one brave enough to try it? This problem should be pretty easy to reproduce on fresh Debian installation. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages selinux-policy-default depends on: ii libselinux1 3.4-1+b6 ii libsemanage2 3.4-1+b5 ii libsepol23.4-2.1 ii policycoreutils 3.4-1 ii selinux-utils3.4-1+b6 Versions of packages selinux-policy-default recommends: ii checkpolicy 3.4-1+b2 pn setools Versions of packages selinux-policy-default suggests: pn logcheck pn syslog-summary -- no debconf information
Bug#388408: Text to work around #898685
Control: submitter -1 !
Bug#849741: Text to work around #898685
Control: submitter -1 !
Bug#849741: (no subject)
Control: submitter -1 !
Bug#709051: Might "just" be a local firewall rule
I encountered that error earlier today, but it went away when I fixed the local firewall to allow the traffic. It's not a good way to report that though. But I'm writing this in the hope that it can help others that encounter this (since the bug report is more than 10 years old, I don't expect that it will help Harish). .Henrik
Bug#1035725: rdiff-backup bug
On Sat, Jan 13, 2024 at 5:00 AM Otto Kekäläinen wrote: > > Looking at https://github.com/rdiff-backup/rdiff-backup/issues/872 > this was fixed in latest rdiff-backup, which is now available in > Debian unstable. > > If you can confirm that this version fixes the issue, I can backport > it to Debian Bookworm as well. > Yes it works. This is the diff we currently apply via Ansible to Debian 12 hosts: https://github.com/rdiff-backup/rdiff-backup/pull/873/files / Henrik
Bug#1051161: postfix: Postfix does not start with default configuration
Package: postfix Version: 3.7.6-0+deb12u2 Severity: important Dear Maintainer, On a fresh Debian 12 Bookworm installation, the Postfix package was installed and configured as "Internet site". The service does not start. "systemctl start postfix" shows as "started (exited)". journalctl for the service just says that "A start job for unit postfix.service has finished successfully." but no processes are running. It is possible to start Postfix with the command "postfix start", then it runs as expected. But I would expect the systemd configuration to do this. Regards, Henrik Stoerner -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postfix depends on: ii adduser3.134 ii cpio 2.13+dfsg-7.1 ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.21.22 ii e2fsprogs 1.47.0-2 ii init-system-helpers1.65.2 ii libc6 2.36-9+deb12u1 ii libdb5.3 5.3.28+dfsg2-1 ii libicu72 72.1-3 ii libnsl21.3.0-2 ii libsasl2-2 2.1.28+dfsg-10 ii libssl33.0.9-1 ii netbase6.4 ii ssl-cert 1.1.2 Versions of packages postfix recommends: ii ca-certificates 20230311 ii python3 3.11.2-1+b1 Versions of packages postfix suggests: ii dovecot-core [dovecot-common] 1:2.3.19.1+dfsg1-2.1 ii libsasl2-modules 2.1.28+dfsg-10 ii mutt [mail-reader] 2.2.9-1+b1 ii postfix-cdb3.7.6-0+deb12u2 ii postfix-doc3.7.6-0+deb12u2 pn postfix-ldap pn postfix-lmdb pn postfix-mta-sts-resolver ii postfix-mysql 3.7.6-0+deb12u2 ii postfix-pcre 3.7.6-0+deb12u2 pn postfix-pgsql ii postfix-sqlite 3.7.6-0+deb12u2 pn procmail pn resolvconf ii ufw0.36.2-1 -- debconf information: postfix/not_configured: postfix/newaliases: false postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 postfix/destinations: $myhostname, vmail2.vservers, localhost.vservers, , localhost postfix/bad_recipient_delimiter: postfix/relayhost: * postfix/main_mailer_type: Internet Site postfix/rfc1035_violation: false postfix/procmail: false postfix/root_address: postfix/mailbox_limit: 0 postfix/chattr: false * postfix/mailname: mx2.hswn.dk postfix/recipient_delim: + postfix/protocols: all
Bug#1043296: evolution: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed
Package: evolution Version: 3.46.4-2 Severity: normal X-Debbugs-Cc: none, Henrik Ahlgren Not sure if this bugs belongs to evolution or libgtk-3-0 package, but I mostly see this with Evolution (randomly also with LibreOffice?), so I don't think it's a Gtk bug affecting all software. Consider a system with: - AMD/APU desktop PC with Samsung 4K display connected via DisplayPort. - All suspend/sleep modes disabled in systemd sleep.conf. - Evolution running. - GNOME desktop session locked (Super-L). - Monitor powered off, since something (perhaps slight mouse movement?) tends to disable the power saving mode and activate the backlight of the monitor every few minutes. This causes the following log entry to be flooded nearly constantly to the system log: evolution[34996]: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed The errors come in bursts of dozens of errors, and then there might be a pause of 1 to 15 minutes, but this pattern does not seem to be consistent. Anyway, sometimes the log (systemd journal) can grow gigabytes (wearing the SSD) from this single error if the PC sits idle for few days and the user forgets to exit from Evolution before locking his screen. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution depends on: ii dbus [default-dbus-system-bus] 1.14.8-2~deb12u1 ii evolution-common3.46.4-2 ii evolution-data-server 3.46.4-2 ii libc6 2.36-9+deb12u1 ii libcamel-1.2-64 3.46.4-2 ii libecal-2.0-2 3.46.4-2 ii libedataserver-1.2-27 3.46.4-2 ii libevolution3.46.4-2 ii libglib2.0-02.74.6-2 ii libgtk-3-0 3.24.37-2 ii libical33.0.16-1+b1 ii libnotify4 0.8.1-1 ii libwebkit2gtk-4.1-0 2.40.5-1~deb12u1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii psmisc 23.6-1 Versions of packages evolution recommends: ii evolution-plugin-bogofilter 3.46.4-2 ii evolution-plugin-pstimport 3.46.4-2 ii evolution-plugins3.46.4-2 ii yelp 42.2-1 Versions of packages evolution suggests: pn evolution-ews pn evolution-plugins-experimental ii gnupg 2.2.40-1.1 ii network-manager 1.42.4-1 -- no debconf information
Bug#472477: Still a problem in bookworm
In a fresh install of bookworm with GNOME desktop, the problem of ssh-add -D not removing ed25519 keys still remains in 2023. When investigating this, I noticed that in the default configuration, there are at least FIVE separate SSH agent processes running: 1. gnome-keyring-daemon process (the buggy one), listening to socket /run/user/$UID/keyring/ssh, which $SSH_AUTH_SOCK points by default (at least in a GNOME session). 2. OpenSSH ssh-agent process forked buy the previous process, listening to socket /run/user/$UID/keyring/.ssh, and working normally (if you point $SSH_AUTH_SOCK there). 3. Another OpenSSH ssh-agent process started by ssh-agent.service (shipped by openssh-client package), listening to socket /run/user/$UID/openssh_agent, and working as expected. 4. gcr-ssh-agent process listening to socket /run/user/$UID/gcr/ssh with the same buggy behaviour wrt ed25519 keys. 5. Third OpenSSH ssh-agent process started by the previous process gcr-ssh-agent, listening to socket /run/user/$UID/keyring/.ssh, again working normally, since it's just the standard ssh-agent. ed25519 keys are very common today, so the default configuration should handle them correctly. And what is the point of having multiple copies of the same agent running, when none of them are even used unless the user explicitly change their $SSH_AUTH_SOCK configuration? Please coordinate with all related package maintainers to fix this mess before trixie is released.
Bug#1022034: Now fails to start on Debian 12
Seems this was not fixed in time for Debian 12, and now it fails to start on Debian12: Jul 31 18:42:12 mailserv policyd-rate-limit[565]: Traceback (most recent call last): Jul 31 18:42:12 mailserv policyd-rate-limit[565]: File "/usr/bin/policyd-rate-limit", line 36, in Jul 31 18:42:12 mailserv policyd-rate-limit[565]: config.setup() Jul 31 18:42:12 mailserv policyd-rate-limit[565]: File "/usr/lib/python3/dist-packages/policyd_rate_limit/utils.py", line 144, in setup Jul 31 18:42:12 mailserv policyd-rate-limit[565]: self._config = Config(config_file) Jul 31 18:42:12 mailserv policyd-rate-limit[565]: ^^^ Jul 31 18:42:12 mailserv policyd-rate-limit[565]: File "/usr/lib/python3/dist-packages/policyd_rate_limit/utils.py", line 88, in __init__ Jul 31 18:42:12 mailserv policyd-rate-limit[565]: self._config = yaml.load(f) Jul 31 18:42:12 mailserv policyd-rate-limit[565]: Jul 31 18:42:12 mailserv policyd-rate-limit[565]: TypeError: load() missing 1 required positional argument: 'Loader' Jul 31 18:42:12 mailserv systemd[1]: policyd-rate-limit.service: Main process exited, code=exited, status=1/FAILURE Upstream fix commit: https://github.com/nitmir/policyd-rate-limit/commit/6c155a633bf5e9986304b1ca009a4716846e66f9 Upstream bug report: https://github.com/nitmir/policyd-rate-limit/issues/15
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
Package: base-files Version: 12.4 Severity: normal Dear Maintainer, /var/run is currently an absolute symlink to /run /var/run should be a relative symlink to ../run if /var/run is deleted, then /usr/lib/tmpfiles.d/var.conf recreates /var/run as relative symlink to ../run /var/lock is currently an absolute symlink to /run/lock /var/lock should be a relative symlink to ../run/lock if /var/lock is deleted, then /usr/lib/tmpfiles.d/legacy.conf recreates /var/lock as a relative symlink to ../run/lock Both of these symlinks are currently created in base-files postinst. This is a problem because base-files currently deviates from the configuration files provided by debian in /usr/lib/tmpfiles.d/ Please fix. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages base-files depends on: ii mawk [awk] 1.3.4.20200120-3.1 base-files recommends no packages. base-files suggests no packages. -- no debconf information
Bug#962420: /usr/local/share/fonts owned by group staff even if /etc/staff-group-for-usr-local not present
Package: fontconfig Version: 2.14.1-4 Followup-For: Bug #962420 Dear Maintainer, Is there any progress on this bug? It is present in stable release of bookworm too now. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fontconfig depends on: ii fontconfig-config 2.14.1-4 ii libc6 2.36-9 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 fontconfig recommends no packages. fontconfig suggests no packages. -- no debconf information
Bug#1039973: base-files: /var/local is root:staff 2775 instead of root:root 0755
Package: base-files Severity: normal Dear Maintainer, /var/local/ is currently created with user:group ownership as root:staff, and permission bits as 2775 It should instead be root:root 0755 to better align with other systems. Please change.
Bug#1039969: aptitude: Use /run/lock/ instead of /var/lock/
Package: aptitude Severity: normal Dear Maintainer, aptitude still uses /var/lock/ instead of /run/lock/ Please change.
Bug#1035725: rdiff-backup bug
Reproduction of the bug is simple with safekeep from a system running Debian 11 trying to backup a system running Debian 12. The backup can not even start, just get "Exception ''restrict_path'' raised of class ''" from rdiff-backup on Debian 12. Full back-trace from safekeep in the upstream bug report here: https://github.com/rdiff-backup/rdiff-backup/issues/872
Bug#1035725:
sorry upstream version with fix is 2.2.5 (not 2.5.0)
Bug#1035725: rdiff-backup in Bookworm not compatible with version in Bullseye
Package: rdiff-backup Version: 2.2.2-1 The version of rdiff-backup in Bookworm is not backwards compatible with the version in Debian Bullseye (2.0.5-2) Problem addressed in upstream version 2.5.0 or with this diff: https://github.com/rdiff-backup/rdiff-backup/commit/a2735047ea19ca05b219d26f4731ce9ec77620f3
Bug#1004135: plantuml: please update to a newer upstream version
Another reason to package an updated version: the version currently in stable (it's the same in testing and unstable) doesn't generate correct diagrams. If I take the "seasons" example of: @startuml concise "Season" as S '30 days is scaled to 50 pixels scale 2592000 as 50 pixels @2000/11/01 S is "Winter" @2001/02/01 S is "Spring" @2001/05/01 S is "Summer" @2001/08/01 S is "Fall" @enduml from https://plantuml.com/timing-diagram, and run it through plantuml I get a diagram without labels on the x-axis. .Henrik
Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics
Same thing here with an AMD Ryzen 5 PRO 3400G system. Also gnome-shell have been complaining about "Failed to set CRTC gamma: drmModeCrtcSetGamma on CRTC 62 failed: Permission denied" for some time. I don't know what is CRTC 62, but clearly it is related.
Bug#1012810: (no subject)
submitter deb...@3001.dk
Bug#1012810: cadaver: Doesn't recognise SSL cert (perhaps because it has many names)
Package: cadaver Version: 0.23.3-2.1+b1 Severity: normal I'm trying to use cadaver on stable/amd64, the version I've got here differs from the newest packages both by having a binary non-maintainer upload for amd64 (giving the "+b1" on my version, i.e. I have that) and a non-maintainer upload that only fixes building issues (as far as I can see - giving the change for "-2.1" to "-2.2" - I don't have that). In total I don't believe those differences matter for this issue. When I try to use cadaver, I get this: dav:!> open https://files.one.com WARNING: Untrusted server certificate presented for `confluence.one.com': Issued to: internal-it.one.com Issued by: Let's Encrypt, US Certificate is valid from Wed, 27 Apr 2022 15:35:02 GMT to Tue, 26 Jul 2022 15:35:01 GMT Do you wish to accept the certificate? (y/n) When I visit that site in a browser, it doesn't say anything about that certificate, if I view it I can see it has 11 alternate names, of which files.one.com is the second. We're witin the validity period that cadaver sees and it actually shows the first alternate name in the "Untrusted server certificate presented"-message, perhaps cadaver (or some library it uses) doesn't properly support that many alternate names? This might be the same issue as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741366 but that bug report doesn't contain any info about the certificate offered, so it's hard to tell. .Henrik -- 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.10.0-13-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cadaver depends on: ii libc6 2.31-13+deb11u3 ii libgcrypt20 1.8.7-6 ii libgnutls30 3.7.1-5 ii libncurses6 6.2+20201114-2 ii libneon27-gnutls 0.31.2-1 ii libreadline8 8.1-1 ii libtinfo6 6.2+20201114-2 ii libxml2 2.9.10+dfsg-6.7+deb11u2 cadaver recommends no packages. cadaver suggests no packages. -- no debconf information
Bug#1012075: openvpn: OpenVPN - Debian/SID release '2.6.0~git20220518+dco-1' breaks connection buildup
Hello Bernhard, Sorry for my late reply. The XG550 is running Firmware "SFOS 17.5.14 MR-14-1". It fall out of support end of 2021. I was in discussion with our network guys to upgrade the Firmware to latest version. As this Sophos XGs are running in HA Mode and cost 40k each we can't do this without proper testing etc...So we plan to replace them with brand new Fortinets in the IDC. Sophos Tech support couldn't provide us any hint if this could be fixed in this 17.5 FW Release as it's not under support anymore. I couldn't see any information regarding new TLS encryption functions in 18.x FW Release but i guess they fixed it. I could reply in 2-3 months once we have the Fortinets in place and proberly configured. One thing is very strange here. The Windows OpenVPN client in version 2.6 works fine compare to the Linux client. So there might be something else in the client source code ? I guess we can close this ticket for the moment ? Best regards, Henrik On Mon, 30 May 2022 11:18:41 +0200 Bernhard Schmidt wrote: > Control: tags -1 moreinfo > > Hi Henrik, > > > The latest version of OpenVPN in Debian/SID repo '2.6.0~git20220518+dco-1' > > won't connect due to TLS errors during connection attempts. > > Only downgrade to version '2.5.6-1' solves the issue. > > Have you followed up on the multiple warnings and notes from the log? > > 2022-05-29 19:07:47 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but > missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20- POLY1305). > OpenVPN ignores --cipher for cipher negotiations. > > 2022-05-29 19:08:08 TLS error: Unsupported protocol. This typically > indicates that client and server have no common TLS version enabled. > This can be caused by mismatched tls-version-min and tls-version-max > options on client and server. If your OpenVPN client is between v2.3.6 > and v2.3.2 try adding tls-version-min 1.0 to the client configuration to > use TLS 1.0+ instead of TLS 1.0 only > 2022-05-29 19:08:08 OpenSSL: error:0A000102:SSL routines::unsupported > protocol > > Please also check up on all items in > https://github.com/OpenVPN/openvpn/blob/dco/Changes.rst . > > From your working log > > 2022-05-29 19:14:10 Control Channel: TLSv1, cipher SSLv3 > DHE-RSA-AES256-SHA, peer certificate: 2048 bit RSA, signature: RSA- SHA256 > > TLSv1 means TLSv1.0 means very very deprecated. > > > > > I had to blur some characters like IP adresses. Destination is Sophos UTM > > Appliances. > > Is that Sophos up to date? > > Bernhard > >
Bug#1012075: openvpn: OpenVPN - Debian/SID release '2.6.0~git20220518+dco-1' breaks connection buildup
Package: openvpn Version: 2.5.6-1 Severity: important Dear Debian OpenVPN Maintenaner, This is a pretty serious bug as it breaks the usage of VPN. The latest version of OpenVPN in Debian/SID repo '2.6.0~git20220518+dco-1' won't connect due to TLS errors during connection attempts. Only downgrade to version '2.5.6-1' solves the issue. I had to blur some characters like IP adresses. Destination is Sophos UTM Appliances. I attached a textfile which compare both outputs of each release. Best regards, Henrik -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 openvpn depends on: ii debconf [debconf-2.0] 1.5.79 ii iproute2 5.17.0-2 ii libc6 2.33-7 ii liblz4-1 1.9.3-2 ii liblzo2-2 2.10-2 ii libpam0g 1.4.0-13 ii libpkcs11-helper1 1.28-1+b1 ii libssl1.1 1.1.1o-1 ii libsystemd0251.1-1 ii lsb-base 11.2 Versions of packages openvpn recommends: ii easy-rsa 3.0.8-1 Versions of packages openvpn suggests: ii openssl 3.0.3-5 pn openvpn-systemd-resolved pn resolvconf -- debconf information: openvpn/create_tun: false Output latest OpenVPN Debian/SID release '2.6.0~git20220518+dco-1' in repo - This version doesn't connect to destination ! root@debian:/home/henrik/Downloads# openvpn hschoepel@ssl_vpn_config.ovpn 2022-05-29 19:07:47 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set. 2022-05-29 19:07:47 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 2022-05-29 19:07:47 Cannot find ovpn_dco netlink component: Object not found 2022-05-29 19:07:47 Note: Kernel support for ovpn-dco missing, disabling data channel offload. 2022-05-29 19:07:47 OpenVPN 2.6_git x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on May 20 2022 2022-05-29 19:07:47 library versions: OpenSSL 3.0.3 3 May 2022, LZO 2.10 Enter Auth Username: hschoepel Enter Auth Password: ** 2022-05-29 19:08:08 TCP/UDP: Preserving recently used remote address: [AF_INET]*:8443 2022-05-29 19:08:08 Socket Buffers: R=[131072->131072] S=[16384->16384] 2022-05-29 19:08:08 Attempting to establish TCP connection with [AF_INET]*:8443 2022-05-29 19:08:08 TCP connection established with [AF_INET]*:8443 2022-05-29 19:08:08 Note: enable extended error passing on TCP/UDP socket failed (IPV6_RECVERR): Protocol not available (errno=92) 2022-05-29 19:08:08 TCP_CLIENT link local: (not bound) 2022-05-29 19:08:08 TCP_CLIENT link remote: [AF_INET]*:8443 2022-05-29 19:08:08 TLS: Initial packet from [AF_INET]*.35:8443, sid=2a3742bf 758117bf 2022-05-29 19:08:08 TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only 2022-05-29 19:08:08 OpenSSL: error:0A000102:SSL routines::unsupported protocol 2022-05-29 19:08:08 TLS_ERROR: BIO read tls_read_plaintext error 2022-05-29 19:08:08 TLS Error: TLS object -> incoming plaintext read error 2022-05-29 19:08:08 TLS Error: TLS handshake failed 2022-05-29 19:08:08 Fatal TLS error (check_tls_errors_co), restarting 2022-05-29 19:08:08 SIGUSR1[soft,tls-error] received, process restarting 2022-05-29 19:08:08 Restart pause, 5 second(s) 2022-05-29 19:08:13 TCP/UDP: Preserving recently used remote address: [AF_INET]*:8443 2022-05-29 19:08:13 Socket Buffers: R=[131072->131072] S=[16384->16384] 2022-05-29 19:08:13 Attempting to establish TCP connection with [AF_INET]*:8443 2022-05-29 19:08:13 TCP connection established with [AF_INET]*:8443 2022-05-29 19:08:13 Note: enable extended error passing on TCP/UDP socket failed (IPV6_RECVERR): Protocol not available (errno=92) 2022-05-29 19:08:13 TCP_CLIENT link local: (not bound) 2022-05-29 19:08:13 TCP_CLIENT link remote: [AF_INET]*:8443 2022-05-29 19:08:13 TLS: Initial packet from [AF_INET]*:8443, sid=eceadd8a 6679da5c 2022
Bug#988068: Info received (Another case where the current apparmor profile causes problems)
I just read (and understood) Mikkel's suggestion. That won't help in my case, I basically need read permissions to *all* files in `.config/redshift`. Unfortunately I don't know apparmor well enough to suggest an addition to the policy that will accomplish that.
Bug#988068: Another case where the current apparmor profile causes problems
Instead of wasting time configuring and running a location service, I just had a number of slightly different configuration files for redshift (with different manual locations specified) and would just let `.config/redshift.conf` be a symlink to the one corresponding to my current location. (And do some extra work in new locations) That didn't work with the discussed restriction (but I could easily put all the different configs in `.config/redshift/`. For now my workaround was simply to replace the symlink with a copy.
Bug#1009215: munpack does not properly decode split attachment filenames [patch]
Package: mpack
Version: 1.6-18
The munpack utility which is part of the mpack package does not handle
attachment filenames that are split into parts. The attached patch fixes this.
I have tested the patched version against a variety of split filenames formats,
some mail senders add a ; to the end of each part, some don't. And it
have worked
fine for all the mails that I've tested it against so far.
I have attached the patch as a file since Gmail is known to mess up
inlined patches.
Regards,
Henrik Holst
Description: fix munpack fail to decode splitted attachment filename
--- mpack-1.6.orig/decode.c
+++ mpack-1.6/decode.c
@@ -513,6 +513,50 @@
return value;
}
+static int copyFilename(char **in, char **out, char **buffer, int *alloced, int *left)
+{
+if (*alloced == 0) {
+ *buffer = xmalloc(*alloced = VALUEGROWSIZE);
+ *out = *buffer;
+ *left = *alloced - 1;
+}
+
+/* Copy value into buffer */
+if (**in == '\"') {
+ /* Quoted-string */
+ (*in)++;
+ while (**in && **in != '\"') {
+ if (!--(*left)) {
+ *alloced += VALUEGROWSIZE;
+ *left += VALUEGROWSIZE;
+ *buffer = xrealloc(*buffer, *alloced);
+ *out = *buffer + *alloced - *left - 2;
+ }
+ if (**in == '\\') {
+ (*in)++;
+ if (!**in) return 0;
+ }
+ *(*out)++ = *(*in)++;
+ }
+ if (!**in) return 0;
+}
+else {
+ /* Just a token */
+ while (**in && !isspace((unsigned char)(**in)) &&
+ **in != '(') {
+ if (!--(*left)) {
+ *alloced += VALUEGROWSIZE;
+ *left += VALUEGROWSIZE;
+ *buffer = xrealloc(*buffer, *alloced);
+ *out = *buffer + *alloced - *left - 2;
+ }
+ *(*out)++ = *(*in)++;
+ }
+}
+**out = '\0';
+return 1;
+}
+
/*
* Get the value of the "filename" parameter in a Content-Disposition:
* header. Returns a pointer to a static buffer containing the value, or
@@ -523,8 +567,9 @@
{
static char *value;
static int alloced = 0;
-int left;
-char *to;
+int parts = 0;
+int left = alloced - 1;
+char *to = value;
if (!disposition) return 0;
@@ -532,21 +577,21 @@
for (;;) {
/* Skip until we find ";" */
while (*disposition != ';') {
- if (!*disposition) return 0;
+ if (!disposition) goto early_exit;
else if (*disposition == '\"') {
++disposition;
while (*disposition && *disposition != '\"') {
if (*disposition == '\\') {
++disposition;
- if (!*disposition) return 0;
+ if (!disposition) goto early_exit;
}
++disposition;
}
- if (!*disposition) return 0;
+ if (!disposition) goto early_exit;
}
else if (*disposition == '(') {
SkipWhitespace();
- if (!disposition) return 0;
+ if (!disposition) goto early_exit;
disposition--;
}
disposition++;
@@ -554,8 +599,10 @@
/* Skip over ";" and trailing whitespace */
disposition++;
+
+decode_next_part:
SkipWhitespace();
- if (!disposition) return 0;
+ if (!disposition) goto early_exit;
/*
* If we're not looking at a "filename" token, go back
@@ -564,60 +611,43 @@
*/
if (strncasecmp(disposition, "filename", 8) != 0) continue;
disposition += 8;
+ if (*disposition == '*') { /* filename is split into parts */
+ disposition++;
+ parts++;
+ while (isdigit ((unsigned char)*disposition) != 0)
+ disposition++;
+ }
if (!isspace(*disposition) && *disposition != '=' &&
*disposition != '(') {
continue;
}
SkipWhitespace();
- if (!disposition) return 0;
+ if (!disposition) goto early_exit;
/* If we're looking at a "=", we found what we're looking for */
- if (*disposition++ == '=') break;
-}
+ if (*disposition++ == '=') {
+ SkipWhitespace();
+ if (!disposition) goto early_exit;
-SkipWhitespace();
-if (!disposition) return 0;
-
-if (!alloced) {
- value = xmalloc(alloced = VALUEGROWSIZE);
-}
+ if (copyFilename(, , , , ) == 0) {
+ parts--;
+ goto early_exit;
+ }
-/* Copy value into buffer */
-to = value;
-left = alloced - 1;
-if (*disposition == '\"') {
- /* Quoted-string */
- disposition++;
- while (*disposition && *disposition != '\"') {
- if (!--left) {
- alloced += VALUEGROWSIZE;
- left += VALUEGROWSIZE;
- value = xrealloc(value, alloced);
- to = value + alloced - left - 2;
- }
- if (*disposition == '\\') {
- disposition++;
- if (!*disposition) return 0;
- }
- *to++ = *disposition++;
- }
- if (!*disposition) return 0;
-}
-else {
- /* Just a token */
- while (*disposition && !isspace(*disposition) &&
- *disposition != '(') {
- if (!--left) {
- alloced += VALUEGROWSIZE;
- left += VALUEGROWSIZE;
- value = xrealloc(value, alloced);
- to = value + alloced - left - 2;
- }
- *to++ = *disposition++;
+ if (*disposition == '\"') disposition++;
+
+ if (parts)
+ goto decode_next_part;
+
+ return value;
}
}
-*to = '\0';
-return value;
+
+early_exit:
+if (parts)
+return value;
+
+return 0;
}
/*
Bug#1009049: prometheus-node-exporter: Document how to disable collectors
Package: prometheus-node-exporter
Version: 1.3.1-1
Severity: normal
X-Debbugs-Cc: deb...@3001.dk
The comments in the shipped config file and the man-page says that
certain options enable collectors, they also mention that they are
enabled by default, but they don't mention that they can be disabled by
prefixing the option with no-. Please add that somewhere.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-12-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=da_DK.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages prometheus-node-exporter depends on:
ii adduser 3.121
ii init-system-helpers 1.62
ii libc62.33-7
Versions of packages prometheus-node-exporter recommends:
ii dbus 1.14.0-1
ii prometheus-node-exporter-collectors 0+git20211024.8eeeffb-1
prometheus-node-exporter suggests no packages.
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "da_DK.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Bug#675710: colord-sane still tries to access non-scanner USB devices
The error message with version 1.4.5-3 in bullseye is slightly different, but colord-sane still outputs nasty errors with high severity to the system log when connecting and disconnecting USB storage devices: Feb 17 20:40:23 zanshin colord-sane[205757]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:40:23 zanshin colord-sane[205757]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:40:23 zanshin colord-sane[205757]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:40:23 zanshin colord-sane[205757]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:44:26 zanshin colord-sane[205880]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:44:26 zanshin colord-sane[205880]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:44:26 zanshin colord-sane[205880]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Feb 17 20:44:26 zanshin colord-sane[205880]: io/hpmud/musb.c 2101: Invalid usb_open: Permission denied
Bug#895480: gnome-power-manager: Homepage under projects.gnome.org no longer exists
In addition to the description being very much outdated and misleading and confusing, it does not help that the upstream homepage in package metadata https://projects.gnome.org/gnome-power-manager/ is now 404. Henrik
Bug#993360: bash: fails to handle multibytes UTF-8 chars on 512 bytes boundaries in some situations
Package: bash
Version: 5.1-2+b3
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Some bash scripts failed.
Here is a script reproducing the bug:
-
#!/bin/bash
if [ "$FIRST_LEVEL" != "no" ] ; then
export FIRST_LEVEL=no
for i in {1..100} ; do
$BASH $0 $i || exit
done
exit
fi
s="§§"
s="$s$s$s$s$s$s$s$s$s"
s="${s:0:256}"
prefix=1
for prefix in 1 ; do
str="1$s"
s1=$(echo "$str")
s2=$str
if [ "$s1" != "$s2" ] ; then
echo $LANG $prefix $1
echo ${s1:256} | od -t x1c
echo ${s2:256} | od -t x1c
exit 1
fi
done
With LANG=en_US.utf8 it shows the bug.
With LANG=C it produces no error
* What exactly did you do (or not do) that was effective (or
ineffective)?
If i put LANG=C in the script it run as expected.
I have tried with upstream bash and found:
if I use --without-bash-malloc on configure I get the bug.
if I do not use --without-bash-malloc on configure the bug disappears.
My gcc: gcc (Debian 10.2.1-6) 10.2.1 20210110
My libc6: Version: 2.31-13
The bug do show at every run, that why I try 100 times in the script.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bash depends on:
ii base-files 11.1
ii debianutils 4.11.2
ii libc62.31-13
ii libtinfo66.2+20201114-2
Versions of packages bash recommends:
ii bash-completion 1:2.11-2
Versions of packages bash suggests:
pn bash-doc
Bug#986991: xnee: incorrect URL in homepage
Hi First of all, thanks for looking in to this. My name is Henrik Sandklef and I (poorly) maintain GNU Xnee. On 2021-04-15 09:24, Paul Wise wrote: > On Thu, 15 Apr 2021 15:10:47 +0800 Paul Wise wrote: > >> the code seems to remain on GNU Savannah though. > > I subsequently found the author has also published the code on their > GitHub account, but without any tags for releases. There is also a > commit from 2018 saying that version 3.20 is being prepared. This > commit also appears on the GNU Savannah CVS repository though. It might > be worth asking the author what their plans are for project hosting. Not enough to make a new release I am afraid. So, those plans are moved to /dev/null. > https://github.com/hesa/gnu-xnee > https://github.com/hesa/gnu-xnee/commit/233d0a3e45b2ad86319d3372916ddd61b26cb5f6 > https://cvs.savannah.gnu.org/viewvc/xnee/xnee/NEWS?r1=1.110=1.111 Re-added "/xnee" to sandklef.com. Tested the following: $ apt-cache show xnee | grep Homepage Homepage: http://www.sandklef.com/xnee/ $ curl -sL http://www.sandklef.com/xnee >/dev/null; echo $? 0 $ curl -sL https://www.sandklef.com/xnee >/dev/null; echo $? 60 Uh oh .. note https[1] /h [1] cert only valid for sandklef.com (not www.sandklef.com). If problematic, can we change the homepage to "sandklef.com/xnee"
Bug#983464: openssh-server: Forced command affects all keys
Package: openssh-server Version: 1:8.4p1-4 Severity: normal X-Debbugs-Cc: deb...@3001.dk (I guess - but haven't checked in any way - that this also affects upstream) (There are many open bugs against this package, so I didn't carefully read the list, but did search it - without finding this issue) The sshd manpage says: command="command" Specifies that the command is executed whenever this key is used for authentication. but when I add such an option on one key in my authorized_keys file, so it looks like: ssh-rsa B3... gr...@sslug.dk command="/bin/hostname" ssh-rsa B3N... h...@one.com (I've shortened my public keys, as they are completely irrelevant, if you want to give me access to some machine, ask me for the complete key) I get the output of /bin/hostname no matter which key I use: grove@stacey> ssh -i .ssh/privat_rsa 10.0.3.106 date sid grove@stacey> ssh -i .ssh/id_rsa 10.0.3.106 date sid (A forced command was my use case, so that's what I've been specifying when testing, but in my orginal attempt at setting this up, I copied from somewhere specifying more options, and I think I saw that the problem also affected pty allocation, so possibly all options) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.74 ii dpkg 1.20.7.1 ii libaudit1 1:3.0-2 ii libc6 2.31-9 ii libcom-err21.46.1-1 ii libcrypt1 1:4.4.17-1 ii libgssapi-krb5-2 1.18.3-4 ii libkrb5-3 1.18.3-4 ii libpam-modules 1.4.0-4 ii libpam-runtime 1.4.0-4 ii libpam0g 1.4.0-4 ii libselinux13.1-3 ii libssl1.1 1.1.1j-1 ii libsystemd0247.3-1 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii openssh-client 1:8.4p1-4 ii openssh-sftp-server1:8.4p1-4 ii procps 2:3.3.17-4 ii runit-helper 2.10.3 ii ucf3.0043 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 247.3-1 ii ncurses-term 6.2+20201114-2 ii xauth1:1.1-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn ssh-askpass pn ufw -- debconf information: openssh-server/password-authentication: true openssh-server/permit-root-login: true
Bug#981921: dovecot-imapd: imapd crashes with "Panic: file message-parser.c: line 174 (message_part_finish): assertion failed: (ctx->nested_parts_count > 0)"
Package: dovecot-imapd
Version: 1:2.3.4.1-5+deb10u5
Severity: normal
Dear Maintainer,
since late january I have seen a couple of crashes of imapd in the logs. The
error message logged is
Panic: file message-parser.c: line 174 (message_part_finish): assertion failed:
(ctx->nested_parts_count > 0)
And a backtrace:
imap(usern...@domain.dk)<26983>: Error: Raw
backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xdb6fb) [0x7ff4f72486fb] ->
/usr/lib/dovecot/libdovecot.so.0(+0xdb791) [0x7ff4f7248791] ->
/usr/lib/dovecot/libdovecot.so.0(+0x4a171) [0x7ff4f71b7171] ->
/usr/lib/dovecot/libdovecot.so.0(+0x474d4) [0x7ff4f71b44d4] ->
/usr/lib/dovecot/libdovecot.so.0(message_parser_parse_next_block+0x104)
[0x7ff4f7230914] -> /usr/lib/dovecot/libdovecot.so.0(message_search_msg+0xa8)
[0x7ff4f7232ec8] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xcf89e)
[0x7ff4f73cb89e] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mail_search_args_foreach+0x45)
[0x7ff4f734d445] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xd0774)
[0x7ff4f73cc774] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xd1a68)
[0x7ff4f73cda68] ->
/usr/lib/dovecot/libdovecot-storage.so.0(index_storage_search_next_nonblock+0x61)
[0x7ff4f73ce0e1] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x28)
[0x7ff4f7356e58] -> dovecot/imap(+0x2695f) [0x55a389c4295f] ->
dovecot/imap(command_exec+0x70) [0x55a389c3bdc0] -> dovecot/imap(+0x25f12)
[0x55a389c41f12] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_handle_timeouts+0x111)
[0x7ff4f725e9c1] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xd0)
[0x7ff4f7260140] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c)
[0x7ff4f725ec4c] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40)
[0x7ff4f725edb0] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13)
[0x7ff4f71df103] -> dovecot/imap(main+0x325) [0x55a389c2cbf5] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7ff4f6fc809b] ->
dovecot/imap(_start+0x2a) [0x55a389c2cd8a]
-- Package-specific info:
dovecot configuration
-
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-14-amd64 x86_64 Debian 10.7 xfs
# Hostname: vmail.vservers
protocol lda {
info_log_path = /var/log/dovecot-lda/dovecot-lda-info.log
log_path = /var/log/dovecot-lda/dovecot-lda-errors.log
mail_plugins = " sieve"
}
protocol imap {
mail_max_userip_connections = 20
}
-- System Information:
Debian Release: 10.7
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-14-amd64 (SMP w/2 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dovecot-imapd depends on:
ii dovecot-core 1:2.3.4.1-5+deb10u5
ii libbz2-1.01.0.6-9.2~deb10u1
ii libc6 2.28-10
ii liblz4-1 1.8.3-1
ii liblzma5 5.2.4-1
ii ucf 3.0038+nmu1
ii zlib1g1:1.2.11.dfsg-1
dovecot-imapd recommends no packages.
Versions of packages dovecot-imapd suggests:
ii ufw 0.36-1
Versions of packages dovecot-imapd is related to:
ii dovecot-core [dovecot-common] 1:2.3.4.1-5+deb10u5
pn dovecot-dev
pn dovecot-gssapi
ii dovecot-imapd 1:2.3.4.1-5+deb10u5
pn dovecot-ldap
pn dovecot-lmtpd
ii dovecot-managesieved 1:2.3.4.1-5+deb10u5
ii dovecot-mysql 1:2.3.4.1-5+deb10u5
pn dovecot-pgsql
ii dovecot-pop3d 1:2.3.4.1-5+deb10u5
ii dovecot-sieve 1:2.3.4.1-5+deb10u5
pn dovecot-sqlite
-- no debconf information
Bug#980479: openshot-qt: Openshot crashes during playback
Package: openshot-qt Version: 2.5.1+dfsg1-1~bpo10+1 Severity: normal Dear Maintainer, I want to remove parts of a video. Unfortunately the video in question is in a 1.7GB file, so it's difficult to share, but I don't have the neccessary rights anyway. I start openshot, import the video and add it to the topmost track of the project. If I then start a preview of the project (yes, that's a bit silly, but I can reproduce the error that way, if I start doing interesting things, openshot either dies or locks up), it plays for a while (I saw the timer say 02:24 just before it crashed, it might have gotten just past the 02:25 mark, but I didn't see that). If openshot is started from a terminal, the following appears: --output- Caught signal 11 (SIGSEGV) Unhandled Exception: Stack Trace /usr/lib/x86_64-linux-gnu/libswresample.so.3 ( + 0x8f46) [0x7fd468c90f46] /usr/lib/x86_64-linux-gnu/libswresample.so.3 ( swr_convert + 0x61c ) [0x7fd468c9859c] /usr/lib/x86_64-linux-gnu/libopenshot.so.19 ( openshot::FFmpegReader::ProcessAudioPacket(long, long, int) + 0xfb7 ) [0x7fd4694ac547] /usr/lib/x86_64-linux-gnu/libopenshot.so.19 ( + 0x8b2e4) [0x7fd4694b02e4] /usr/lib/x86_64-linux-gnu/libgomp.so.1 ( + 0x1679e) [0x7fd46886b79e] /lib/x86_64-linux-gnu/libpthread.so.0 ( + 0x7fa3) [0x7fd471ffafa3] /lib/x86_64-linux-gnu/libc.so.6 ( clone + 0x3f ) [0x7fd471b414cf] End of Stack Trace QObject::~QObject: Timers cannot be stopped from another thread Caught signal 11 (SIGSEGV) Unhandled Exception: Stack Trace /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 ( QPainterState::QPainterState() + 0x3d ) [0x7fd46d5eca7d] /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 ( QRasterPaintEngine::createState(QPainterState*) const + 0x45 ) [0x7fd46d5de555] /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 ( QPainter::begin(QPaintDevice*) + 0x100 ) [0x7fd46d5efa50] /usr/lib/python3/dist-packages/PyQt5/QtGui.cpython-37m-x86_64-linux-gnu.so ( + 0x1741d9) [0x7fd46de0e1d9] /usr/lib/python3/dist-packages/sip.cpython-37m-x86_64-linux-gnu.so ( + 0x179d4) [0x7fd4713d69d4] /usr/bin/python3 ( _PyObject_FastCallKeywords+ 0x129 ) [0x5ce0e9] /usr/bin/python3 ( _PyEval_EvalFrameDefault + 0x4c3b) [0x5467bb] /usr/bin/python3 ( _PyEval_EvalCodeWithName + 0x252 ) [0x53f732] /usr/bin/python3 ( _PyFunction_FastCallDict + 0x34e ) [0x5ceb8e] /usr/bin/python3 ( ) [0x4c9202] /usr/bin/python3 ( PyObject_Call + 0x56 ) [0x5d0986] /usr/lib/python3/dist-packages/sip.cpython-37m-x86_64-linux-gnu.so ( + 0x1153b) [0x7fd4713d053b] /usr/lib/python3/dist-packages/sip.cpython-37m-x86_64-linux-gnu.so ( + 0x1161f) [0x7fd4713d061f] /usr/lib/python3/dist-packages/PyQt5/QtWidgets.cpython-37m-x86_64-linux-gnu.so ( + 0x14d5fd) [0x7fd46c4385fd] /usr/lib/python3/dist-packages/PyQt5/QtWidgets.cpython-37m-x86_64-linux-gnu.so ( + 0x3959fb) [0x7fd46c6809fb] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QWidget::event(QEvent*) + 0x1d8 ) [0x7fd46be314d8] /usr/lib/python3/dist-packages/PyQt5/QtWidgets.cpython-37m-x86_64-linux-gnu.so ( + 0x38f7f3) [0x7fd46c67a7f3] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QApplicationPrivate::notify_helper(QObject*, QEvent*) + 0x81 ) [0x7fd46bdf34c1] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QApplication::notify(QObject*, QEvent*) + 0x210 ) [0x7fd46bdfa970] /usr/lib/python3/dist-packages/PyQt5/QtWidgets.cpython-37m-x86_64-linux-gnu.so ( + 0x3a910e) [0x7fd46c69410e] /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ( QCoreApplication::notifyInternal2(QObject*, QEvent*) + 0x179 ) [0x7fd4703e1489] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QWidgetPrivate::sendPaintEvent(QRegion const&) + 0x3a ) [0x7fd46be2a0ca] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) + 0x867 ) [0x7fd46be2a987] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 ( + 0x16ea37) [0x7fd46be02a37] /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (
Bug#911428: New Customer Request...
- This mail is in HTML. Some elements may be ommited in plain text. - Hello, Kindly confirm if you can ship to Australia and New Zealand. Thanks CEO Dr Henrik Rawlings © 2020 Henrik Group Ltd. All Rights Reserved. sent from my iPad
Bug#911428: New Customer Request...
- This mail is in HTML. Some elements may be ommited in plain text. - Hello, Kindly confirm if you can ship to Australia and New Zealand. Thanks CEO Dr Henrik Rawlings © 2020 Henrik Group Ltd. All Rights Reserved. sent from my iPad
Bug#911428: New Customer Request...
- This mail is in HTML. Some elements may be ommited in plain text. - Hello, Kindly confirm if you can ship to Australia and New Zealand. Thanks CEO Dr Henrik Rawlings © 2020 Henrik Group Ltd. All Rights Reserved. sent from my iPad
Bug#793675: hplip-gui: No system tray detected
Any possibility the whole /etc/xdg/autostart/hplip-systray.desktop file could be dropped from future versions if it does not work at all? The "No system tray detected on this system." error dialog every user gets when logging in in default GNOME desktop is very annoying. Please fix this issue that is already over 10 years old.
Bug#513964: base-passwd: please add netdev and powerdev groups to group.master
Is the netdev group really obsolete? It seems to me that at least network-manager, wpasupplicant and avahi-daemon rely on it (for dbus.1/polkit-1). All packages add the group in .postinst. Like with most of these old groups, the name is not optimal: it does not really deal with "devices". Only /dev/rfkill is owned by that group, and it has ACL set by (I believe) systemd-logind for the active session user. Please consider at least documenting the purpose of this group in users-and-groups.txt.
Bug#972052: base-passwd: cups does not run as cupsys:lp
reassign 972052 base-passwd retitle 972052 base-passwd: cups does not run as cupsys:lp thanks My bad, wrong package.
Bug#972052: base-files: cups does not run as cupsys:lp
Package: cups-daemon Version: 2.2.10-6+deb10u3 Severity: normal The cupsys group was added to users-and-groups in 2005 (#290237). I don't remember if cups used to run as such user back then, but now it (very unfortunately) runs as root, and no such user is present in the system. This is at least the case for the default cups-daemon package. Please drop this user from the document.
Bug#600700: base-passwd: sudo group's documented semantics don't match the sudo package
I still feel sudo is such an important group, that it would be good if users-and-groups.txt would be further improved to more clearly document that this group is what allows users to not only run commands with sudo and pkexec, but also execute various other polkit-1 actions like install software with packagekit. So it is now actually a rather badly named generic "administrator" group. (Some other distros apparently use other group names, like wheel for Arch.)
Bug#962420: /usr/local/share/fonts owned by group staff even if /etc/staff-group-for-usr-local not present
I believe using dh_usrlocal(1) debhelper should do this automatically. Manpage: If a directory is owned by root:root, then ownership will be determined at install time. The ownership and permission bits will either be root:root mode 0755 or root:staff mode 02775. The actual choice depends on whether the system has /etc/staff-group-for-usr-local (as documented in the Debian Policy Manual §9.1.2 since version 4.1.4)
Bug#821424: Groups for default user created by d-i
I've always found it bit weird and confusing that the first user created during installation by d-i is "special" and belongs to a number of groups that apparently are mostly unecessary in the modern world. However, when you add a new user using the command line (useradd/adduser), or the GNOME settings panel, the newly created user does not belong to any additional groups, and still everything works fine (except audio in fast-user-switching use case, if the primary user is in the audio group). Why should the first user be treated differently anyway? If some groups are necessary for normal operation, shouldn't additional users also be included by default? If the first user is considered the primary owner of the computer and thus entitled to more permissions, that should be at least clearly documented. The merge request by Felipe Sateler removes most hardware access groups, but still leaves three groups: dip, debian-tor and lpadmin. Is the dip (dialup, ppp?) group relevant for most users? debian-tor is not included in default /etc/group, but maybe it works if the user installs tor from d-i? The purpose of these groups and the access they grant to the user is not clearly documented anywhere I could find. For example, the first user is in the video group by default, and according to https://wiki.debian.org/SystemGroups "This group can be used locally to give a set of users access to a video device (like the framebuffer, the videocard or a webcam)" What does it mean in practical terms, if I can access /dev/fb0 and /dev/dri/cardX? Can I snoop another user's screen while he is logged in?
Bug#963269: rdiff-backup 2.0 backport to Buster?
Package: rdiff-backup Version: 1.2.8-7 Would it be possible to ship rdiff-backup 2.0 as a backport for Buster (bpo)? Currently I can not upgrade the backup server to rdiff-backup 2.0 so it can backup VMs running testing as that would break backups of all other systems running Buster. Having a backport of rdiff-backup 2.0 in stable backports would allow me to upgrade the backup server and all other Buster VMs to this backport version so I can backup both stable and testing with the same existing server. Thanks, Henrik
Bug#955472: xnee: Please build the GUI components
Hello all Thanks for your emails. I guess I, the main author, am responsible for the mess here :) On 4/1/20 10:08 AM, Vincent Bernat wrote: > ❦ 1 avril 2020 10:01 +02, Wouter Verhelst: > >> xnee comes with two GUI components: gnee, a GUI version of cnee, and >> pnee, a Gnome applet. >> >> At least gnee seems to compile just fine on my buster system. However, >> neither of these two are shipped as part of the Debian package. > > See: > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923918 > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638111 > > For the former, upstream told me privately I should drop gnee. I have no Debian computer at the moment but checked on a Ubuntu. Yes, to my surprise I guess, gnee* compiles and executes. If users think gnee (the gui) is useful I don't object re-adding it. I will switch to git (last project on the planet to do that?) and do some work to make sure gnee compiles easily** and also remove deps to dia***. Thanks for all your hard work with Debian. You are very much appreciated by very many. /h *) here's what I did: make -f Makefile.cvs ./configure --enable-gui make ./gnee/src/gnee **) basically make sure build/setup-debian.sh is up to date **) might not be critical anymore but I'll do it anyhow
Bug#950886: Withdrawal of bug report
I'd like to withdraw this bug report. It seems there were an old libcrypt library from libc which had not been removed during an update. KR /Henrik
Bug#951486: network-manager: network-online.target returns before network has IP address
Package: network-manager Version: 1.22.6-1 Severity: important Dear Maintainer, I want to use autofs with LDAP. I'm using DHCP and network-manager. network-online.target will return before a valid IP address is provided and therefore autofs.service is invoked too early, failing to bind to the LDAP server. network-online.target.wants is using NetworkManager-wait-online.service which is the source of the problem. It is using 'ExecStart=/usr/bin/nm-online -s -q --timeout=30' and only if I remove the '-s' parameter, it is properly waiting for DHCP to negotiate an IP address and autofs can bind afterwar7 systemd-analyze blame shows that NetworkManager-wait-online.service is taking 7 secs with '-s' and 22 secs without '-s'. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-1 ii init-system-helpers1.56+nmu1 ii libaudit1 1:2.8.4-3 ii libbluetooth3 5.50-1 ii libc6 2.28-10 ii libcurl3-gnutls7.64.0-4 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgnutls303.6.7-4+deb10u2 ii libjansson42.12-1 ii libmm-glib01.10.0-1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.6-1 ii libpam-systemd 241-7~deb10u3 ii libpolkit-agent-1-00.105-25 ii libpolkit-gobject-1-0 0.105-25 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux12.8-1+b1 ii libsystemd0241-7~deb10u3 ii libteamdctl0 1.28-1 ii libudev1 241-7~deb10u3 ii libuuid1 2.33.1-0.1 ii policykit-10.105-25 ii udev 241-7~deb10u3 ii wpasupplicant 2:2.7+git20190128+0c1e29f-6+deb10u1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii iptables 1.8.2-4 ii modemmanager 1.10.0-1 ii ppp 2.4.7-2+4.1 Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 pn libteam-utils -- no debconf information
Bug#951320: closed by Michael Biebl (Re: Bug#951320: systemd: network-online.target exits too early -> autofs with ldap fails)
Debian Bug Tracking System schrieb am 14.02.20 um 13:45: > This is an automatic notification regarding your Bug report > which was filed against the systemd package: > > #951320: systemd: network-online.target exits too early -> autofs with ldap > fails > > It has been closed by Michael Biebl . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Michael Biebl > by > replying to this email. > > Hi, since this seems to be a debain bug where to I report it to get a better answer than an immediate bug report closure? Best Henrik Schmidt
Bug#950886: libruby2.5: Fails with "version `XCRYPT_2.0' not found"
Package: libruby2.5 Version: 2.5.7-1+b1 Severity: important Dear Maintainer, Running ruby or any application invoking ruby results in the following error message and aborts. /lib/x86_64-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/lib/x86_64-linux-gnu/libruby-2.5.so.2.5) If I downgrade to 2.5.5-3+deb10u1 the issue is gone. I'd be happy to provide you with further information about the local environment. KR /Henrik -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libruby2.5 depends on: ii libc6 2.29-9 ii libcrypt1 1:4.4.10-10 ii libffi73.3-3 ii libgdbm-compat41.18.1-5 ii libgdbm6 1.18.1-5 ii libgmp10 2:6.1.2+dfsg-4 ii libreadline8 8.0-3 ii libssl1.1 1.1.1d-2 ii libyaml-0-20.2.2-1 ii rake 12.3.3-1 ii ruby-did-you-mean 1.2.1-1 ii ruby-minitest 5.13.0-1 ii ruby-net-telnet0.1.1-2 ii ruby-test-unit 3.3.4-1 ii ruby-xmlrpc0.3.0-2 ii zlib1g 1:1.2.11.dfsg-1+b1 libruby2.5 recommends no packages. libruby2.5 suggests no packages. -- no debconf information
Bug#946829: Patch
Hello,
This was really a vulnerability which allowed running any perl code or
commands (even as root), for anyone able to write .cf files/rules.
The bug is mitigated in SpamAssassin 3.4.3, which properly taints
configuration strings, and results in Perl complaining and not running
Greylisting.pm at all.
I've made a proper patch which addresses both the vulnerability and 3.4.3
compatibility.
=
--- Greylisting.pm.orig 2019-12-18 17:49:40.351383764 +0200
+++ Greylisting.pm 2019-12-18 22:30:03.745497552 +0200
@@ -21,6 +21,7 @@
use strict;
use Mail::SpamAssassin::Plugin;
+use Mail::SpamAssassin::Util qw(untaint_var);
our @ISA = qw(Mail::SpamAssassin::Plugin);
sub new
@@ -65,9 +66,25 @@
Mail::SpamAssassin::Plugin::dbg("GREYLISTING: called function");
-$optionhash =~ s/;/,/g;
+#$optionhash =~ s/;/,/g;
# This is safe, right? (users shouldn't be able to set it in their config)
-%option=eval $optionhash;
+#%option=eval $optionhash;
+
+# ... no, evaling random strings is not safe!!!
+# Ditch eval and parse hash string manually to maintain backwards
compatibility
+$optionhash =~ s/^\s*\(\s*//;
+$optionhash =~ s/\s*\)\s*$//;
+foreach my $opt (split(/\s*;\s*/, $optionhash)) {
+ my @vals = split(/\s*=>\s*/, $opt, 2);
+ next unless defined $vals[1];
+ # Sanitize away quotes and any unneeded characters, then untaint
+ foreach (@vals) {
+ s/[^\w\/-]//gs;
+ $_ = untaint_var($_);
+ }
+ $option{$vals[0]} = $vals[1];
+}
+
$self->{'rangreylisting'}=1;
foreach my $reqoption (qw ( method greylistsecs dontgreylistthreshold
=====
Cheers,
Henrik
Bug#928975: seafile: copyright concerns
om libzdb. We see ResultSet_next, ResultSet_getString, ResultSet_getInt etc and PreparedStatement_setString, PreparedStatement_setInt etc. Also PreparedStatement_executeQuery is faithfully copied: a:libzdb: https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/PreparedStatement.c#lines-122 a:seafile: https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/db-wrapper.c#L392 4. Concrete Database implementations. When it comes to the concrete database implementation for SQLite, MySQL and PostgreSQL the same copy of code is repeated. For example, MysqlResultSet_new. a:libzdb: https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/mysql/MysqlResultSet.c#lines-102 a:seafile: https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/mysql-db-ops.c#L189 and the special way we ensure column field capacity in MySQL where they very telling even has copied our comment: b:libzdb: https://bitbucket.org/tildeslash/libzdb/src/2958e023fcee44f313e6d3f3592b02cc06783e0f/src/db/mysql/MysqlResultSet.c#lines-84 b:seafile: https://github.com/haiwen/seafile-server/blob/9f30eedc467bf5938ff57e24cee3a5b473e72314/common/db-wrapper/mysql-db-ops.c#L277 Summary: -- The evidence above demonstrate that there are reasons to be concerned about the Seafile team's insubstantial dealings in open-source and that the Seafile team for all practical purposes are conducting copyright infringement and violating the GPL terms. It is unclear to me if the Seafile server is part of Debian or if it is downloaded separately or during the install process and that Debian is only distributing the client part of Seafile. If the latter is the case, I still hope that Debian will make a stand and not distribute Seafile packages as long as there are copyright concerns associated with the Seafile Software. Best regards — Jan-Henrik Haukeland https://tildeslash.com/ 1. https://packages.debian.org/search?keywords=seafile 2. https://www.tildeslash.com/libzdb/ 3. https://github.com/haiwen/seafile/issues/666 4. https://github.com/haiwen/seafile/issues/666#issuecomment-260232869 5. https://github.com/haiwen/seafile-server/tree/master/common/db-wrapper 6. Seafile’s fork of libzdb https://github.com/haiwen/libzdb 7. Our libzdb repository: https://bitbucket.org/tildeslash/libzdb/src/release-2-11-1/
Bug#842199: autofs should pull in network-online.target and nfs-client.target and related issues
Hi, the proposed fix does not solve the problem here, using LDAP for automount in nsswitch.conf . automout: bind_ldap_simple: lookup(ldap): Unable to bind to the LDAP server: (default), error Can't contact LDAP server. If I add ExecStartPre=/bin/sleep 20 in autofs.service it works as expected, so there is still a timing problem. Henrik On Thu, 14 Mar 2019 18:33:51 +0100 Mike Gabriel wrote: > Hi Daniel, > > I am currently adopting the orphaned autofs package. The issue you > reported here as something that we have been observing in Debian Edu > deployments for years. Thanks for proposing a fix. > > On Wed, 26 Oct 2016 13:28:01 -0700 Daniel Lakeland > wrote: > > > > Package: autofs > > Version: 5.1.1-1 > > Severity: important > > Tags: patch > > > > Dear Maintainer, > > > > *** Reporter, please consider answering these questions, where > > appropriate *** > > > > * What led up to the situation? > > > > Boot machine that has autofs configured to mount directories under > > /home/ via nfs4. > > The machine comes up but directories don't get mounted. > > > > For this to work properly we need several things to happen: > > > > 1) rpc.idmapd and rpc.gssd need to run > > 2) autofs needs to start up after the network is online > > > > Add the following line to autofs.system > > Requires=network-online.target nfs-client.target > > > > Add the following line to nfs-client.target > > Requires=nfs-idmapd.service rpc-gssd.service > > > > After these changes, autofs starts up late enough that the network is > > online, and > > when it tries to mount nfs4 mounts it works > > However, I suspect that we cannot entangle autofs and NFS as much as you > propose here. Note that people also may use autofs for local device > mounting and don't run NFS with it at all. > > So, for the autofs side of things, I propose this (a Wants= solution > rather than a Requires= solution): > > ``` > commit 9e1569ac32e53a6b364241fe68377579ffcbd5db (HEAD -> master) > Author: Mike Gabriel > Date: Thu Mar 14 15:04:46 2019 +0100 > > debian/autofs.service: Add nfs-client.target to Wants= key. > Hopefully, this is sufficient to fix #842199, if not, please reopen the > bug. (Closes: #842199). > > diff --git a/debian/autofs.service b/debian/autofs.service > index 8d7afa2..33a3d4e 100644 > --- a/debian/autofs.service > +++ b/debian/autofs.service
Bug#928379: zim: Ctrl+home keybinding regression
Package: zim Version: 0.65-4 Severity: normal Dear Maintainer, After the upgrade to Stretch, there is a regression in the Zim package. Pressing ctrl+home would normally (and in previous versions) move the cursor to the start of the document, but is now treated as plain home, moving the cursor to the start of the line. Ctrl+end still works normally, moving to the end of the document. The problem seems to have been reported and fixed upstream: https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/148 https://github.com/zim-desktop-wiki/zim-desktop-wiki/commit/d85388c68676044a3a0de12f6e9059c99a386bf6 Could the fix be backported to Stretch? The inability to easily scroll the document makes the program cumbersome to use. -- System Information: Debian Release: 9.9 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages zim depends on: ii python 2.7.13-2 ii python-gobject 3.22.0-2 ii python-gtk2 2.24.0-5.1 ii python-xdg 0.25-4 Versions of packages zim recommends: ii python-gtkspell 2.25.3-13 Versions of packages zim suggests: pn bzr pn ditaa pn dvipng pn fossil ii git1:2.11.0-3+deb9u4 ii gnuplot5.0.5+dfsg1-6+deb9u1 pn graphviz pn lilypond ii mercurial 4.0-1+deb9u1 ii python-gtksourceview2 2.10.1-3 pn python-zeitgeist pn r-base pn scrot -- no debconf information
Bug#903704: Wrong count of available releases
Package: www.debian.org Severity: minor On ftp.debian.org (and mirrors) it says "Four Debian releases are available on the main site", and lists five.
Bug#860064: 8.11 update breaks dnsmasq
Hi, The Debian 8.11 update (20180623) included the problematic version of dns-root-data. Hence dnsmasq can not be started if the init.d script is not patched. Regards, Henrik
Bug#894731: linux-image-4.15.0-2-amd64: Setting drm.edid_firmware or drm_kms_firmware.edid_firmware has no effect
I reported this on the Linux bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199799 drm/i915 bugreports go to Freedesktop, but Jani Nikula suggested to add "video=VGA-1:e" to the kernel commandline, which fixed this for me. Not sure if this closes the matter, as it used to work without setting video before, but I thought I'd pass this suggestion on to other affected people.
Bug#894731: linux-image-4.15.0-2-amd64: Setting drm.edid_firmware or drm_kms_firmware.edid_firmware has no effect
Indeed, and it continues to be a problem on 4.16. I'm guessing something about moving from drm_kms_firmware.edid_firmware to drm.edid_firmware broke this. Maybe this should be reported upstream?
Bug#894731: linux-image-4.15.0-2-amd64: Setting drm.edid_firmware or drm_kms_firmware.edid_firmware has no effect
Package: src:linux Version: 4.15.11-1 Severity: normal Tags: upstream Dear Maintainer, Today I upgraded from linux-image-4.14.0-3-amd64 to 4.15.0-2-amd64. Because the third monitor connected via VGA doesn't seem to expose a proper EDID or any EDID at all, I use "drm_kms_helper.edid_firmware=VGA-1:edid/1280x1024.bin" to force the resolution. This used to work fine with the built-in firmwares as well as with a custom EDID I acquired from the screen by connecting it to HDMI. With the upgrade to 4.15.0-2-amd64, the flag doesn't work anymore. The only relevant message I get in dmesg is: [8.750411] [drm] drm_kms_firmware.edid_firmware is deprecated, please use drm.edid_firmware intead. When using the config variable drm.edid_firmware, instead, the deprecation warning disappears, but still, nothing happens. "edid-decode /sys/devices/pci:00/:00:02.0/drm/card0/card0-VGA-1/edid" now returns an invalid or no EDID: Extracted contents: header: 00 00 00 00 00 00 00 00 serial number: 00 00 00 00 00 00 00 00 00 00 version: 00 00 basic params:00 00 00 00 00 chroma info: 00 00 00 00 00 00 00 00 00 00 established: 00 00 00 standard:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 1:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 2:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 3:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 4:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 extensions: 00 checksum:00 No header found Manufacturer: @@@ Model 0 Serial Number 0 EDID version: 0.0 Analog display, Input voltage level: 0.7/0.3 V Sync: Image size is variable Gamma: 1.00 Monochrome or grayscale display Established timings supported: Standard timings supported: non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) Manufacturer-specified data, tag 0 Manufacturer-specified data, tag 0 Manufacturer-specified data, tag 0 Manufacturer-specified data, tag 0 Checksum: 0x0 (valid) EDID block does not conform at all! Bad year of manufacture Manufacturer name field contains garbage Whereas previously it would display information about the custom EDID. I have also attached the dmesg of the previous kernel. -- Package-specific info: ** Version: Linux version 4.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-12)) #1 SMP Debian 4.15.11-1 (2018-03-20) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-2-amd64 root=UUID=78f2fe7c-bc1b-4073-aa07-9ea42b0ab9e0 ro quiet drm_kms_helper.edid_firmware=VGA-1:edid/1280x1024.bin ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [8.863552] lpc_ich: Resource conflict(s) found affecting gpio_ich [8.976735] EFI Variables Facility v0.08 2004-May-17 [9.060109] pstore: using zlib compression [9.060124] pstore: Registered efi as persistent store backend [9.131124] sd 0:0:0:0: Attached scsi generic sg0 type 0 [9.131144] sr 2:0:0:0: Attached scsi generic sg1 type 5 [9.329121] fbcon: inteldrmfb (fb0) is primary device [9.408147] snd_hda_intel :00:03.0: enabling device (0100 -> 0102) [9.408267] snd_hda_intel :00:1b.0: enabling device (0100 -> 0102) [9.443559] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC221: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [9.443561] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=1 (0x17/0x0/0x0/0x0/0x0) [9.443562] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [9.443563] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [9.443563] snd_hda_codec_realtek hdaudioC1D0:inputs: [9.443565] snd_hda_codec_realtek hdaudioC1D0: Mic=0x1a [9.443566] snd_hda_codec_realtek hdaudioC1D0: Line=0x1b [9.449006] snd_hda_intel :00:03.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [9.449006] Console: switching to colour frame buffer device 128x48 [9.466746] i915 :00:02.0: fb0: inteldrmfb frame buffer device [9.467834] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/sound/card0/input10 [9.467851] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/sound/card0/input11 [9.467868] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/sound/card0/input12 [9.467883] input: HDA Intel HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:03.0/sound/card0/input13 [9.467901] input: HDA Intel HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:03.0/sound/card0/input14 [9.492591] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card1/input15 [9.492606] input: HDA
Bug#888755: postgresql-common: pg_upgradecluster should call psql with -X
Source: postgresql-common Version: 181+deb9u1 Severity: normal Dear Maintainer, When I upgraded a box (that's heavily firewalled, so running reportbug on it doesn't work, so I'm writing this from another box, I'll try to make sure the automatically inserted information reflects the box I had the problem on) from Jessie to Stretch, I also got postgresql 9.6 instead of (or technically in addition to) the 9.4 that was in Jessie, and was told to run pg_upgradecluster to upgrade the databases. That failed with some messages about trying to run "CREATE DATABASE" inside a transaction. After a while and some timme searching the net, I realised that it might be due to me having "\set AUTOCOMMIT off" in /etc/postgresql-common/psqlrc, and adding a -X to every call of psql in pg_upgradecluster did indeed fix the problem and allowed me to upgrade my databases. Most things you'd ever find in a psqlrc is related to interactive use, so just not reading it should be a lot better than the current behaviour. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql-common depends on: ii adduser 3.115 ii debconf [debconf-2.0] 1.5.61 ii init-system-helpers 1.48 ii lsb-base 9.20161125 ii postgresql-client-common 181+deb9u1 ii procps2:3.3.12-3 ii ssl-cert 1.0.39 ii ucf 3.0036 Versions of packages postgresql-common recommends: ii logrotate 3.11.0-0.1 postgresql-common suggests no packages.
Bug#868408: xnee: Please drop the (build-)dependency against gnome-vfs
On 2018-01-02 02:02, Andreas Henriksson wrote: Hej Henrik, Vincent, On Tue, Jan 02, 2018 at 12:11:16AM +0100, Henrik Sandklef wrote: I have removed deps to gnomeui (gconf had already been removed) from Xnee sources. Vincent, please see the attached debdiff that incorporates Henriks change as a patch in debian/patches/ for your convenience. (You might also want to look into upgrading to a non-deprecated debhelper compat level (apparently 5 is currently used while anything before 9 is deprecated), etc. See also other lintian warnings.) Can I assist you in any way? Thanks for the offer! From my point of view it's really up to Vincent how he wants to handle this - I just wanted to remind and point out the urgency of this issue being resolved in any way. Hopefully Vincent will get in touch with you if he has something to discuss. While poking around I noticed a couple of things which I'm just mentioning in case it'll interest you: - Is it true CVS is still used? (Or else I've probably looked at the wrong upstream location) Yes. I do not have time to maintain Xnee as I should. Switching VCS is not prio #1. - I guess $(libgnomeui_LIBS) and $(libgnomeui_CFLAGS) can now also be dropped from gnee/src/Makefile.am (and possibly other places?) Thanks a lot. - Apparently configure(.in) has no check for pkg-config modules actually exiting (which I ran into while having pkg-config itself, but not gtk+-2.0.pc since the libgtk2.0-dev build-dependency was missing in the debian xnee package). A more obvious error message could have been produced by explicitly checking if ! $PKGCONF --exists $GTK2_MODULE >= GTK2_VERSION and erroring out. Even better though... (see below). - directly invoking pkg-config is not cross compilation safe (as lintian points out). It would probably be better to replace all pkg-config usage with PKG_CHECK_MODULES macro usage instead. (And gtk-config is long gone so you can probably retire that code path while at it.) This should also give a more modern and fool-proof configure process. See if I can squeeze these in. The lintian report might also give you useful information: https://lintian.debian.org/maintainer/ber...@debian.org.html#xnee_3.19-1 Med vänlig hälsning, Andreas Henriksson Tusen tack och gott nytt år /henrik
Bug#868408: xnee: Please drop the (build-)dependency against gnome-vfs
I have removed deps to gnomeui (gconf had already been removed) from Xnee sources. Can I assist you in any way? /henrik - GNU Xnee maintainer On 2017-12-31 14:28, Andreas Henriksson wrote: Hello Vincent Bernat, On Sat, Jul 15, 2017 at 11:04:51PM +0200, Vincent Bernat wrote: [...] As far as xnee is concerned, I can drop the Gnome frontend if it relies on deprecated libs. Please do this A.S.A.P! The time is near when all the remaining unmaintained packages will removed, and by leaving this issue unfixed xnee risks going out with the rest. Regards, Andreas Henriksson
Bug#875890: Apparmor causes problems with Stretch upgrade
Upgrading from Jessie to Stretch with apparmor enabled seems to fail: Setting up mariadb-server-10.1 (10.1.26-0+deb9u1) ... Installing new version of config file /etc/apparmor.d/usr.sbin.mysqld ... Installing new version of config file /etc/init.d/mysql ... Installing new version of config file /etc/logrotate.d/mysql-server ... Installing new version of config file /etc/mysql/debian-start ... dpkg: error processing package mariadb-server-10.1 (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of default-mysql-server: default-mysql-server depends on mariadb-server-10.1; however: Package mariadb-server-10.1 is not configured yet. dpkg: error processing package default-mysql-server (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of mysql-server: mysql-server depends on default-mysql-server; however: Package default-mysql-server is not configured yet. dpkg: error processing package mysql-server (--configure): dependency problems - leaving unconfigured It took me a while to notice from audit log that is is due to apparmor: type=AVC msg=audit(1509991806.111:85264): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/etc/mysql/mariadb.conf.d/" pid=6557 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=SYSCALL msg=audit(1509991806.111:85264): arch=4003 syscall=5 success=no exit=-13 a0=bfd7f415 a1=98800 a2=bfd7fd71 a3=bfd7fd55 items=0 ppid=6554 pid=6557 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=10453 comm="mysqld" exe="/usr/sbin/mysqld" key=(null) Trying to reload apparmor policies did not help, it appears that apparmor_parser ignores policies that are empty?
Bug#873581: certbot: Excessive logging
Package: certbot Version: 0.10.2-1~bpo8+1 Severity: normal Certbog logs to /var/log/letsencrypt.log using DEBUG as the default log level. It rotates the log on each invocation, i.e. (at least) daily. If I understand correctly (main.py:setup_log_file_handler), 1000 log files are retained. On my server, I have hundreds of small log files: # ls /var/log/letsencrypt|wc -l 597 Most of the debug information contained in the logs are not very useful for sysadmins and it is quite difficult to find any relevant information about certificate renewals etc. Please consider making the log level configurable and make the default "info". Also it would be nice, if logrotate would handle log rotation, so the sysadmin could easily modify the rotation behaviour. Better yet, the possibility of logging directly into systemd journal would be great. -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages certbot depends on: ii init-system-helpers 1.22 ii python 2.7.9-1 ii python-certbot 0.10.2-1~bpo8+1 pn python:any certbot recommends no packages. Versions of packages certbot suggests: ii python-certbot-apache 0.10.2-1~bpo8+1 pn python-certbot-doc -- debconf-show failed
Bug#828695: (no subject)
Control: submitter -1 !
Bug#866769: keepassx fails to clear KDE clipboard history, leaving passwords visible
Hi Felix, On 04-07-2017 21:39, Felix Geyer wrote: Hi, On 03.07.2017 03:42, Reinhard Tartler wrote: Control: tag -1 +help +upstream Control: severity -1 important Thank you very much for your bug report, Henrik. On 07/01/2017 11:22 AM, Henrik Størner wrote: keepassx 2.0.3-1 (in Debian "stretch") fails to clear the clipboard history after a password has been copied to the clipboard. The keepassx security settings has "Clear clipboard after 10 seconds" enabled. To reproduce, - select an entry with a stored password in the keepassx database - press ctrl-C to copy the password to the clipboard - after 10 seconds (default setting), the password should disappear from the clipboard history - click on the clipboard icon in the panel, the password is visible This is using the KDE Desktop installation, and hence the KDE clipboard. The KDE clipboard has a setting to prevent the clipboard from being emptied, but this setting does not change the behaviour. KeePassX clears the clipboard by using the Qt QClipboard API. If another application (KDE Clipboard manager or anything else) resets the clipboard again, there is nothing KeePassX can do to prevent it. I don't understand your comment. The problem is that KeePassX does *not* clear the clipboard, not that something else resets the clipboard. If KeePassX uses the Qt API to clear the clipboard, then the problem might be in Qt. Either that, or the behaviour of KeePassX+Qt is not as one would expect. But I am 99% sure that this behaviour is different from what happened with keepassx 0.4.3 from Debian 8 (jessie). I will get a test system setup later this week to verify this, and also try the old keepassx tool on Stretch. Regards, Henrik
Bug#866769: keepassx fails to clear KDE clipboard history, leaving passwords visible
Package: keepassx Version: 2.0.3-1 Severity: grave Tags: security Justification: user security hole Dear Maintainer, keepassx 2.0.3-1 (in Debian "stretch") fails to clear the clipboard history after a password has been copied to the clipboard. The keepassx security settings has "Clear clipboard after 10 seconds" enabled. To reproduce, - select an entry with a stored password in the keepassx database - press ctrl-C to copy the password to the clipboard - after 10 seconds (default setting), the password should disappear from the clipboard history - click on the clipboard icon in the panel, the password is visible This is using the KDE Desktop installation, and hence the KDE clipboard. The KDE clipboard has a setting to prevent the clipboard from being emptied, but this setting does not change the behaviour. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages keepassx depends on: ii libc62.24-11+deb9u1 ii libgcrypt20 1.7.6-2 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui44:4.8.7+dfsg-11 ii libstdc++6 6.3.0-18 ii libx11-6 2:1.6.4-3 ii libxi6 2:1.7.9-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.8.dfsg-5 keepassx recommends no packages. keepassx suggests no packages. -- no debconf information
Bug#849227: Onionshare: CLI works but GUI doesn't
Yes, the test case you described works as expected, but have you tried this: - Start onionshare GUI - Add a file - Uncheck the "Stop server automatically" setting - Click "Start server" and wait for the server to come up - Download the file using Tor Browser - Select "New tor circuit for this site" in Tor Browser and try to download it again To me it seems that the GUI always shuts down the onion server after the first download regardles of the checkbox state.
Bug#856733: Follow-up
Some additional info: I shutdown the xen guest and restarted it - this logged the same bootup BUG message as before. Shutting it down, launching a different Xen guest, and then launching the troublesome guest, works without any BUG messages being logged. I suppose this could point at a RAM issue with the host, I just find it odd that it shows up suddenly and has not been noticed before. Regards, Henrik Størner
Bug#856733: linux-image-3.16.0-4-amd64: Xen guest has multiple stack dumps, ending with spontaneous reboot
Package: src:linux Version: 3.16.39-1+deb8u1 Severity: important Dear Maintainer, after installing the latest linux-image update, one of my Xen guests suddenly logged multiple kernel stacktraces. The initial one was this: Mar 4 03:05:14 saltmaster kernel: [798533.537459] WARNING: CPU: 1 PID: 9901 at /build/linux-NAZ6Cx/linux-3.16.39/arch/x86/xen/multicalls.c:129 __xen_mc_entry+0x110/0x180() Mar 4 03:05:14 saltmaster kernel: [798533.537463] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper evdev cryptd pcspkr autofs4 ext4 crc16 mbcache jbd2 xen_netfront crct10di f_pclmul crct10dif_common xen_blkfront crc32c_intel Mar 4 03:05:14 saltmaster kernel: [798533.537483] CPU: 1 PID: 9901 Comm: salt-master Not tainted 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u1 Mar 4 03:05:14 saltmaster kernel: [798533.537486] 81514c41 0009 Mar 4 03:05:14 saltmaster kernel: [798533.537490] 81068867 01ff 88007adcbd00 Mar 4 03:05:14 saltmaster kernel: [798533.537496] 0001 0150 81005150 01ff Mar 4 03:05:14 saltmaster kernel: [798533.537501] Call Trace: Mar 4 03:05:14 saltmaster kernel: [798533.537507] [] ? dump_stack+0x5d/0x78 Mar 4 03:05:14 saltmaster kernel: [798533.537513] [] ? warn_slowpath_common+0x77/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.537517] [] ? __xen_mc_entry+0x110/0x180 Mar 4 03:05:14 saltmaster kernel: [798533.537521] [] ? xen_pin_page+0x58/0x160 Mar 4 03:05:14 saltmaster kernel: [798533.537524] [] ? xen_do_pin+0x50/0x50 Mar 4 03:05:14 saltmaster kernel: [798533.537527] [] ? __xen_pgd_walk+0x2e4/0x310 Mar 4 03:05:14 saltmaster kernel: [798533.537529] [] ? xen_do_pin+0x50/0x50 Mar 4 03:05:14 saltmaster kernel: [798533.537532] [] ? __xen_pgd_pin+0x5b/0x340 Mar 4 03:05:14 saltmaster kernel: [798533.537535] [] ? xen_dup_mmap+0x1e/0x30 Mar 4 03:05:14 saltmaster kernel: [798533.537539] [] ? copy_process.part.25+0x1781/0x1c50 Mar 4 03:05:14 saltmaster kernel: [798533.537543] [] ? do_fork+0xe0/0x3d0 Mar 4 03:05:14 saltmaster kernel: [798533.537547] [] ? __alloc_fd+0x7c/0x120 Mar 4 03:05:14 saltmaster kernel: [798533.537550] [] ? stub_clone+0x69/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.537554] [] ? system_call_fast_compare_end+0x10/0x15 Mar 4 03:05:14 saltmaster kernel: [798533.537556] ---[ end trace ef0d5e3cd38fc131 ]--- immediately followed by this: Mar 4 03:05:14 saltmaster kernel: [798533.538577] WARNING: CPU: 1 PID: 9901 at /build/linux-NAZ6Cx/linux-3.16.39/arch/x86/xen/multicalls.c:129 __xen_pgd_pin+0x103/0x340() Mar 4 03:05:14 saltmaster kernel: [798533.538580] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper evdev cryptd pcspkr autofs4 ext4 crc16 mbcache jbd2 xen_netfront crct10di f_pclmul crct10dif_common xen_blkfront crc32c_intel Mar 4 03:05:14 saltmaster kernel: [798533.538597] CPU: 1 PID: 9901 Comm: salt-master Tainted: GW 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u1 Mar 4 03:05:14 saltmaster kernel: [798533.538600] 81514c41 0009 Mar 4 03:05:14 saltmaster kernel: [798533.538604] 81068867 000edf90 8800fa16 88007bfb1800 Mar 4 03:05:14 saltmaster kernel: [798533.538608] 8800843fe000 77ff8000 81009ad3 88007bfb1800 Mar 4 03:05:14 saltmaster kernel: [798533.538611] Call Trace: Mar 4 03:05:14 saltmaster kernel: [798533.538614] [] ? dump_stack+0x5d/0x78 Mar 4 03:05:14 saltmaster kernel: [798533.538617] [] ? warn_slowpath_common+0x77/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.538621] [] ? __xen_pgd_pin+0x103/0x340 Mar 4 03:05:14 saltmaster kernel: [798533.538624] [] ? xen_dup_mmap+0x1e/0x30 Mar 4 03:05:14 saltmaster kernel: [798533.538627] [] ? copy_process.part.25+0x1781/0x1c50 Mar 4 03:05:14 saltmaster kernel: [798533.538630] [] ? do_fork+0xe0/0x3d0 Mar 4 03:05:14 saltmaster kernel: [798533.538634] [] ? __alloc_fd+0x7c/0x120 Mar 4 03:05:14 saltmaster kernel: [798533.538637] [] ? stub_clone+0x69/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.538641] [] ? system_call_fast_compare_end+0x10/0x15 Mar 4 03:05:14 saltmaster kernel: [798533.538643] ---[ end trace ef0d5e3cd38fc132 ]--- After this, multiple stacktraces were logged without much call trace info: Mar 4 03:05:14 saltmaster kernel: [798533.538726] WARNING: CPU: 0 PID: 0 at /build/linux-NAZ6Cx/linux-3.16.39/arch/x86/xen/multicalls.c:129 xen_end_context_switch+0xe/0x20() Mar 4 03:05:14 saltmaster kernel: [798533.538732] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper evdev cryptd pcspkr autofs4 ext4
Bug#814759: F1 is Help in GNOME Terminal
F1 works in many terminals (e.g. plain xterm), but in GNOME it opens the help window, unless the shortcut is disabled. It would be useful if simple "1", "2", etc. would work instead of function keys.
Bug#849741: uniq: Please add option to only compare the first N fields
Package: coreutils Version: 8.23-4 Severity: wishlist Probably a request for upstream. >From the manpage for uniq (reordered to highlight the missing symmetry): -s, --skip-chars=N avoid comparing the first N characters -w, --check-chars=N compare no more than N characters in lines -f, --skip-fields=N avoid comparing the first N fields but no option to only compare the first N fields. Please add that feaure. The system information below shows that I'm running stable, but it's the same on unstable, but no matter what I do reportbug crashes (with an error similar to what's in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849358) when I run it in the docker container with unstable I used for checking it. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages coreutils depends on: ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libc62.19-18+deb8u6 ii libselinux1 2.3-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#849227: CLI works but GUI doesn't
Oops, sorry about my brainfart. Of course it does not shut down the onion service in case I only download the HTML download page (using wget), but not the payload itself. After downloading "/download", onionshare says "Closing automatically because download finished" and the hidden service is gone (but it does not seem to exit until I hit ^C). --stay-open works as documented. However I still cannot get the "stop server automatically" checkbox in the GUI to work as expected.
Bug#849227: onionshare: CLI never shuts down after download - GUI always does
Package: onionshare Version: 0.6-3 Severity: important Manual page reads: "OnionShare's default behaviour is to shut down the hidden service and to stop once the file has been downloaded. You can prevent this behaviour by invoking the --stay-open option. This can be useful if you want multiple people to access the same file." However, the command line version always allows multiple downloads until onionshare is manually stopped, with or without --stay-open. -8<-- $ onionshare /usr/bin/vi Connecting to Tor control port to set up hidden service on port 60373. Preparing files to share. Waiting for HS to be ready: Trying... * Running on http://127.0.0.1:60373/ Not ready yet. Trying... Ready! Give this URL to the person you're sending the file to: http://.onion/YY Press Ctrl-C to stop server 127.0.0.1 - - [DD/Dec/2016 HH:MM:SS] "GET / HTTP/YY 1.1" 200 - 127.0.0.1 - - [DD/Dec/2016 HH:MM:SS] "GET /YY HTTP/1.1" 200 - 127.0.0.1 - - [DD/Dec/2016 HH:MM:SS] "GET /YY HTTP/1.1" 200 - ^C127.0.0.1 - - [DD/Dec/2016 MM:MM:SS] "GET /YY/shutdown HTTP/1.1" 200 - -8<-- The GUI version malfunctions the opposite way: there is a checkbox "Stop server automatically", but it has no effect – the server always stops after the first download. This is quite confusing and the CLI behaviour is potentially unsecure. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages onionshare depends on: ii python 2.7.9-1 ii python-flask 0.10.1-2 ii python-qt4 4.11.2+dfsg-1 ii python-stem 1.2.2-1.1 ii torbrowser-launcher 0.1.9-1+deb8u3 onionshare recommends no packages. onionshare suggests no packages. -- debconf-show failed
Bug#800891: Please adjust the licensing of afex
Hi Andreas, I am sorry for the delay. I guess you will have to go ahead without it for the next version. I haven't managed to find the time to work on it yet. I will before the end of the year, but don't know when. Sorry. Regards, Henrik 2016-12-11 16:38 GMT+01:00 Andreas Tille <andr...@an3as.eu>: > Hi Henrik, > > any news about a new version with fixed license. As I said the issue is > a bit dense if we want to reach the next Debian stable version. > > Kind regards > > Andreas. > > On Wed, Nov 16, 2016 at 09:37:57AM +0100, Andreas Tille wrote: > > Hi Henrik, > > > > On Tue, Nov 15, 2016 at 08:57:20PM +0100, Henrik Singmann wrote: > > > Hi Andreas, (this time with list in CC) > > > > > > Thanks for warning me. And no problem. I will change to GPL2 in the > next > > > release version. Can you give me some time to implement these changes > and > > > others I have planned for the next release? Let's say 4 weeks? > > > > As I said 4 weeks is a bit dense. If you really manage in 4 weeks it > > might make it. However, it is not my power to push any package after > > the freeze. > > > > Kind regards > > > > Andreas. > > > > -- > > http://fam-tille.de > > -- > http://fam-tille.de > -- Dr. Henrik Singmann Postdoc Universität Zürich, Schweiz http://singmann.org
Bug#771891: Removing the cache not a good workaround
I disagree that this issue is not serious since there is a workaround. If the cache needs to be deleted every time you want to access your email, it basically makes the program unusable as an IMAP client. Also, sometimes certain emails do not appear in the inbox even after deleting the cache. They are just silently discarded, and the user might be totally unaware of the messages unless he accesses the IMAP account with some other MUA such as mutt. Any ideas how to help debug this further?
Bug#800891: Please adjust the licensing of afex
Hi Andreas, (this time with list in CC) Thanks for warning me. And no problem. I will change to GPL2 in the next release version. Can you give me some time to implement these changes and others I have planned for the next release? Let's say 4 weeks? Cheers, Henrik 2016-11-15 8:46 GMT+01:00 Andreas Tille <andr...@an3as.eu>: > Hi Henrik, > > please have a look at the bug report about license violation in the > Debian bug tracker: > >https://bugs.debian.org/800891 > > Due to this license violation we can not distribute afex in the next > Debian release which we would really like to. Would you mind switching > to GPL-2 which would simply solve the issue? > > Thanks for considering > > Andreas. > > -- > http://fam-tille.de > -- Dr. Henrik Singmann Postdoc Universität Zürich, Schweiz http://singmann.org
Bug#313237: Fixed in tar 1.24
I believe this has been fixed since GNU tar 1.24. >From NEWS: ** Symbolic link attributes When extracting symbolic links, tar now restores attributes such as last-modified time and link permissions, if the operating system supports this. For example, recent versions of the Linux kernel support setting times on symlinks, and some BSD kernels also support symlink permissions.
Bug#838899: xorg: debian 9 Xorg -configure generated xorg.conf breaks lightdm on video-vmware and video-dummy
there was recently an update to.. among other things, xserver-xorg-video-core i believe. in any case, i just did "apt-get update; apt-get upgrade; apt-get dist-upgrade;" , noticed there was xorg-related updates, tested again, and xserver-xorg-video-dummy works again now it seems :)
Bug#833706: seems it's fixed in
seems it's fixed in the daily installer builds, and thus it should be safe to assume the fix will be part of the next installer (alpha 8?). grab daily build copy here https://d-i.debian.org/daily-images/amd64/daily/ , it works for me. according to a guy on irc://irc.oftc.net/#debian-boot : (...) the next build will automatically pick up the current versions and work as expected
Bug#833706: happens to me too
happens to me too, using iPXE pxe boot to netinst image, amd64, real hardware, Installer build: 20160630
Bug#838377: apt-show-versions: Make sure cache files are world-readable
Package: apt-show-versions Version: 0.22.4 Severity: wishlist If a strict umask in effect during cache file initialization, apt-show-versions creates the files without read permissions for normal users. If a non-root user runs apt-show-versions, this happens: can't open /var/cache/apt-show-versions/ipackages: Permission denied at /usr/bin/apt-show-versions line 213 Probably the easiest way to fix this would be to simply set umask to 022 at the start of the program before calling Storable::store.
Bug#780814: Included mp3 files are unusable
If support for MP3 is not enabled (due to licensing/patent issues perhaps?), what is the point of shipping all the files in /usr/share/scratch/Media/Sounds? They just waste disk space. The file selection dialog does not even indicate file type (mp3/wav), so the user experience is frustrating since some sound clips work and some won't, and the typical user is a kid who don't understand why.
Bug#834803: macchanger: log should include timestamps
Package: macchanger Version: 1.7.0-5.3 Severity: wishlist Dear Maintainer, ifupdown.sh logs to /var/log/macchanger.log simply by redirecting the output of macchanger and few echo commands. This means no timestamps are written to the log, making it difficult to debug problems. Please consider adding timestamping, or perhaps using logger(1) to write to syslog/systemd journal instead of separate log file. Also, I am not sure if it useful to log the fact that loopback was ignored every time ifupdown.sh was run. Also, the default configuration floods the log with usage messages since --all does not work (bug #780165). -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 'testing-updates'), (400, 'testing'), (350, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages macchanger depends on: ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.27 ii install-info 5.2.0.dfsg.1-6 ii libc6 2.19-18+deb8u4 macchanger recommends no packages. macchanger suggests no packages. -- Configuration Files: /etc/default/macchanger changed [not included] -- debconf information: * macchanger/automatically_run: true
Bug#828695: xbomb interacts badly with i3
Package: xbomb Version: 2.2b-1 Severity: normal This is without any xbomb specific configuration of i3. When I start i3 on a desktop where only my i3bar is present, it starts in a window that takes up the entire desktop (that is as i3 is supposed to make it). xbomb starts in easy/squares mode but the individual fields of the playing board are scaled so badly that I can only see the first 5½ row, that makes the game impossible. Changing to medium/squares I can see the first 11 rows (and a tiny fraction of the 12th), in hard/squares I can actually see the entire board. Changing game type just leaves a white area where the menu was (after changing desktops = redrawing windows) the entire playing area is white, and changing level doesn't change that, but it is remembered if I change back to squares. When i3 splits the desktop horisontally between xbomb and another window, the hexagons and triangles mode still doesn't work, but easy/squares is scaled better, I can see all 8 rows and 7½ columns (the window is wide enough that the rest of the eight column could have been there, but it's cut. Similarily medium/squares is scaled so that the 16'th column is needlessly cut, the numbers that appear in (some of) the squares in that column is also cut, but you can see enough to tell them apart. In hard/squares only the first 20 columns are visible. Other configurations of additional windows and thereby other sizes for the xbomb window is possible, but I don't see any value in testing more. It doesn't seem to make a difference whether I make the window floating after starting the program, or by putting 'for_window [class="XBomb"] floating enable' in i3's config. When trying to resize the window (in floating mode, the only option is using the keybindings) the window size doesn't change, probably because xbomb refuses the new size (that is probably the same issue as reported with ratpoison in #456031). It's possible that defining other keybindings to resize the window in both directions simultaneously and other increments might give other results, but that seems like a poor strategy (I can't define keybindings for every program that might need special behaviour). At first, when xbomb starts in easy/squares, everything looks good, and the game is playable. Changing to medium/squares, the window becomes significantly smaller (not what is expected), it becomes so narrow that the "Hi-Scores" button is cut with the first column (or two) of the second "s" visible, and the "Quit" button is not in the window. If I start playing, the numbers that appear in the squares are higher than the squares giving a rather confusing look, but the game is playable. Changing back to easy/squares, the window does not change size, but the smaller number of squares means everything looks fine, but the button bar is still cut, in particular the "Quit" button is missing from view. Changing to hard/squares (it seems not to matter whether the change was from easy or medium), the window is resized to a wider variant to accomodate the number of squares, but the individual squares are too small for the numbers inside (the same as described above), changing from hard to easy, gives the window the initial size where the "Quit" button is visible. In hexagon iand triable modes it's much the same, except that going from medium to easy make the window smaller than it was from the start, and going from difficult to easy make it a larger than it was from the start. Going from floating to tiled mode, you can continue the game in both hexagon and triangle modes, but the fields of the board is not scaled, just placed with lots of space between them, and in triangle modes the numbers appear outside the fields. Trying to go from traibles to hexagons or vice versa in a tiled window, produces some strange graphic effects. - Some conclusions: Basically only squares modes work when the window is tiled, but scaling is weird and means only some levels are playable. When the window is floating, all modes work, but on medium or hard levels scaling is very poor. - I would suggest making xbomb allow any window size, with some minimums based on game mode and the width of all the buttons. And then just scale the area that is actually used for the playing field. That might results in windows with quite a lot of whitespace, but I guess it will make it work better with window managers that try to affect the size of the window. -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xbomb depends on: ii libc6 2.19-18+deb8u4 ii libx11-6 2:1.6.2-3 ii libxaw7 2:1.0.12-2+b1 ii libxt61:1.1.4-1+b1 xbomb
Bug#827597: The error is not bound to the compatibility interface
Using the same files, and the syntax from the SYNOPSIS section of the
man page:
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new(); say $m->get_mime("1-wrong.html")'
text/plain
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new(); say $m->get_mime("2-wrong.html")'
text/plain
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new(); say $m->get_mime("2-1.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new(); say $m->get_mime("2-2.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new(); say $m->get_mime("2-3.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new(); say $m->get_mime("2-4.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new("/etc/magic"); say $m->get_mime("1-wrong.html")'
text/plain
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new("/etc/magic"); say $m->get_mime("2-wrong.html")'
text/plain
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new("/etc/magic"); say $m->get_mime("2-1.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new("/etc/magic"); say $m->get_mime("2-2.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new("/etc/magic"); say $m->get_mime("2-3.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS; my $m =
File::MMagic::XS->new("/etc/magic"); say $m->get_mime("2-4.html")'
text/html
Bug#827597: libfile-mmagic-xs-perl: Fails at identifying HTML in several cases
Package: libfile-mmagic-xs-perl
Version: 0.09008-2+b1
Severity: normal
Dear Maintainer,
Using File::MMagic::XS I found that it sometimes identified HTML as
text/plain.
I have taken two examples and removed at lot from them to produce small
examples. (I won't call them minimal as there are at least 4 ways to
"fix" one of them).
I have attached 6 files:
1-wrong.html: An example that is far from valid HTML, but `file` still
gets right
2-wrong.html: An example that is better HTML
2-1.html: First way to "fix" 2-wrong.html
2-2.html: Second way to "fix" 2-wrong.html
2-3.html: Third way to "fix" 2-wrong.html
2-4.html: Fourth way to "fix" 2-wrong.html
Output of file and a simple perl script to determine MIME type below:
grove@mary> file
1-wrong.html
1-wrong.html: HTML document, ASCII text
grove@mary> perl -E 'use File::MMagic::XS qw(:compat); my $m =
File::MMagic::XS->new(); say $m->checktype_filename("1-wrong.html")'
text/plain
grove@mary> file
2-wrong.html
2-wrong.html: HTML document, ASCII text, with very long lines
grove@mary> perl -E 'use File::MMagic::XS qw(:compat); my $m =
File::MMagic::XS->new(); say $m->checktype_filename("2-wrong.html")'
text/plain
grove@mary> perl -E 'use File::MMagic::XS qw(:compat); my $m =
File::MMagic::XS->new(); say $m->checktype_filename("2-1.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS qw(:compat); my $m =
File::MMagic::XS->new(); say $m->checktype_filename("2-2.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS qw(:compat); my $m =
File::MMagic::XS->new(); say $m->checktype_filename("2-3.html")'
text/html
grove@mary> perl -E 'use File::MMagic::XS qw(:compat); my $m =
File::MMagic::XS->new(); say $m->checktype_filename("2-4.html")'
text/html
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libfile-mmagic-xs-perl depends on:
ii libc6 2.19-18+deb8u4
ii perl5.20.2-3+deb8u5
ii perl-base [perlapi-5.20.0] 5.20.2-3+deb8u5
libfile-mmagic-xs-perl recommends no packages.
libfile-mmagic-xs-perl suggests no packages.
-- no debconf information
(The newer version in testing+unstable seems to be a rebuild of the same
source, so I guess that won't make a difference)
Bug#821325: musescore: new upstream release 2.0.3
Package: musescore Followup-For: Bug #821325 The current version in debian 2.0.2 is not the best (many small bugs). I do find the new version much more stable and bugfree. Might very well be a good option for a stable release. So please Have a nice day Lars Henrik Ørn -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages musescore depends on: ii desktop-file-utils 0.22-1 ii libasound2 1.1.0-1 ii libc62.22-7 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:5.3.1-14 ii libogg0 1.3.2-1 ii libportaudio219+svn20140130-1 ii libpulse08.0-2 ii libqt5concurrent55.5.1+dfsg-16+b1 ii libqt5core5a [qtbase-abi-5-5-1] 5.5.1+dfsg-16+b1 ii libqt5designer5 5.5.1-3 ii libqt5gui5 5.5.1+dfsg-16+b1 ii libqt5help5 5.5.1-3 ii libqt5network5 5.5.1+dfsg-16+b1 ii libqt5printsupport5 5.5.1+dfsg-16+b1 ii libqt5qml5 5.5.1-3 ii libqt5quick5 5.5.1-3 ii libqt5quickwidgets5 5.5.1-3 ii libqt5sql5 5.5.1+dfsg-16+b1 ii libqt5sql5-sqlite5.5.1+dfsg-16+b1 ii libqt5svg5 5.5.1-2 ii libqt5test5 5.5.1+dfsg-16+b1 ii libqt5webkit55.5.1+dfsg-2+b1 ii libqt5widgets5 5.5.1+dfsg-16+b1 ii libqt5xml5 5.5.1+dfsg-16+b1 ii libqt5xmlpatterns5 5.5.1-2 ii libsndfile1 1.0.25-10 ii libstdc++6 5.3.1-14 ii libvorbis0a 1.3.5-3 ii libvorbisfile3 1.3.5-3 ii musescore-common 2.0.2+dfsg-2 ii qml-module-qtquick-controls 5.5.1-2 ii qml-module-qtquick-layouts 5.5.1-2 ii qml-module-qtquick2 5.5.1-3 ii shared-mime-info 1.6-1 ii xdg-utils1.1.1-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages musescore recommends: ii pulseaudio-utils 8.0-2 Versions of packages musescore suggests: ii fluid-soundfont-gm 3.1-5 pn timgm6mb-soundfont -- no debconf information
Bug#768524: musescore: New upstream release available
Package: musescore Version: 2.0.2+dfsg-2 Followup-For: Bug #768524 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** There is a new stable upstream release 2.0.3 avaliable. It is most bugfixes, and in my experience consierabley more stable. I am hoping this version will make it into stretch Have an ice day -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (700, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages musescore depends on: ii desktop-file-utils 0.22-1 ii libasound2 1.1.0-1 ii libc62.22-7 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:5.3.1-14 ii libogg0 1.3.2-1 ii libportaudio219+svn20140130-1 ii libpulse08.0-2 ii libqt5concurrent55.5.1+dfsg-16+b1 ii libqt5core5a [qtbase-abi-5-5-1] 5.5.1+dfsg-16+b1 ii libqt5designer5 5.5.1-3 ii libqt5gui5 5.5.1+dfsg-16+b1 ii libqt5help5 5.5.1-3 ii libqt5network5 5.5.1+dfsg-16+b1 ii libqt5printsupport5 5.5.1+dfsg-16+b1 ii libqt5qml5 5.5.1-3 ii libqt5quick5 5.5.1-3 ii libqt5quickwidgets5 5.5.1-3 ii libqt5sql5 5.5.1+dfsg-16+b1 ii libqt5sql5-sqlite5.5.1+dfsg-16+b1 ii libqt5svg5 5.5.1-2 ii libqt5test5 5.5.1+dfsg-16+b1 ii libqt5webkit55.5.1+dfsg-2+b1 ii libqt5widgets5 5.5.1+dfsg-16+b1 ii libqt5xml5 5.5.1+dfsg-16+b1 ii libqt5xmlpatterns5 5.5.1-2 ii libsndfile1 1.0.25-10 ii libstdc++6 5.3.1-14 ii libvorbis0a 1.3.5-3 ii libvorbisfile3 1.3.5-3 ii musescore-common 2.0.2+dfsg-2 ii qml-module-qtquick-controls 5.5.1-2 ii qml-module-qtquick-layouts 5.5.1-2 ii qml-module-qtquick2 5.5.1-3 ii shared-mime-info 1.5-2 ii xdg-utils1.1.1-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages musescore recommends: ii pulseaudio-utils 8.0-2 Versions of packages musescore suggests: ii fluid-soundfont-gm 3.1-5 pn timgm6mb-soundfont -- no debconf information
Bug#808236: electrum: missing icon
Package: electrum Version: 2.5.4-2 Severity: minor Dear Maintainer, 1.9.8-4 (jessie) had the application icon installed in rather strange location but it worked just fine: /usr/share/app-install/icons/electrum.png Version 2.5.4 does not appear to ship an icon file at all. However it says Icon=electrum in electrum.desktop. In GNOME the icon is empty e.g. when switching between applications (alt-tab). (The stable version no longer works with current bitcoin network, generating transactions that are not accepted.) -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 'testing-updates'), (400, 'testing'), (350, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages electrum depends on: ii python 2.7.9-1 ii python-electrum 2.5.4-2 pn python:any Versions of packages electrum recommends: ii python-qt4 4.11.2+dfsg-1 Versions of packages electrum suggests: pn python-btchip pn python-trezor -- no debconf information
Bug#791858: Does not happen with .txt
This issue seems to only affect export to XML. Export to text file
defaults to "All Files" in the file selection dialog, where XML
defaults to *.xml. Otherwise the source code looks pretty similar for
both:
Export_KeePassX_Xml.cpp:
bool Export_KeePassX_Xml::exportDatabase(QWidget* GuiParent,IDatabase*
database){
db=database;
QFile *file=openFile(GuiParent,identifier(),QStringList()<
Bug#791858: keepassx: XML export security bug
severity 791858 grave tags 791858 security thanks How come this bug has not been marked as a pretty severe security issue? Just accessing a menu item, but canceling the export operation by hitting Esc or clicking Cancel silently creates a hidden (dotfile) cleartext copy of all of the user's KeePassX password database entries in the user's home directory. This may go unnoticed by the user for years, while countless copies of the file propagate to backups etc., and with Debian's default umask, the file is even world-readable in multiuser machines.
Bug#796185: Improvement: Option to generate initial empty CRL
Package: easy-rsa Version: 2.2.2-1 Severity: wishlist Tags: upstream patch Dear Maintainer, the easy-rsa package does not include a way of generating an initial empty CRL after setting up a new CA. Only the 'revoke-full' tool will generate CRL's, and only as part of revoking an existing certificate. The attached diff adds a --initcrl option to revoke-full, which simply skips the revoking step of a certificate - so the CRL is (re-)generated resulting in an empty CRL if no certificates have been revoked. If certificates have already been revoked, it simply regenerates the CRL. Regards, Henrik Stoerner -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages easy-rsa depends on: ii openssl 1.0.1k-3+deb8u1 Versions of packages easy-rsa recommends: ii opensc 0.14.0-2 easy-rsa suggests no packages. -- no debconf information --- revoke-full.orig 2015-07-13 19:24:43.0 +0200 +++ revoke-full 2015-08-20 07:46:03.296973081 +0200 @@ -8,6 +8,8 @@ if [ $# -ne 1 ]; then echo usage: revoke-full cert-name-base; +echoor +echorevoke-full --initcrl exit 1 fi @@ -23,8 +25,11 @@ # required due to hack in openssl.cnf that supports Subject Alternative Names export KEY_ALTNAMES= -# revoke key and generate a new CRL -$OPENSSL ca -revoke $1.crt -config $KEY_CONFIG +if [ $1 != --initcrl ] +then +# revoke key and generate a new CRL +$OPENSSL ca -revoke $1.crt -config $KEY_CONFIG +fi # generate a new CRL -- try to be compatible with # intermediate PKIs @@ -35,8 +40,11 @@ cat ca.crt $CRL $RT fi -# verify the revocation -$OPENSSL verify -CAfile $RT -crl_check $1.crt +if [ $1 != --initcrl ] +then +# verify the revocation +$OPENSSL verify -CAfile $RT -crl_check $1.crt +fi else echo 'Please source the vars script first (i.e. source ./vars)' echo 'Make sure you have edited it to reflect your configuration.'
Bug#777559: [aufs-tools] auplink crashes
Tags: patch
When AuFin is called with errno = 0, error_at_line(3) does not exit. The
attached patch sets errno to EINVAL following the pattern in most
other similar error checks in aufs-tools.
With this change auplink / flush outputs the following error
message and exists without segfaulting:
auplink:plink.c:342: no aufs mount point: Invalid argument
This bug causes docker core files to appear in docker container's root
directory.
Henrik
diff -uNr aufs-tools-3.2+20130722.orig/plink.c aufs-tools-3.2+20130722/plink.c
--- aufs-tools-3.2+20130722.orig/plink.c 2013-08-11 16:48:48.0 +0300
+++ aufs-tools-3.2+20130722/plink.c 2015-08-13 18:18:39.836110526 +0300
@@ -337,8 +337,10 @@
if (flags AuPlinkFlag_OPEN) {
p = hasmntopt(ent, si);
- if (!p)
+ if (!p) {
+ errno = EINVAL;
AuFin(no aufs mount point);
+ }
strncpy(si, p, sizeof(si));
p = strchr(si, ',');
if (p)
Bug#783395: Happens also with version 2.19-1 (testing)
Tried installing the 2.19-1 version from testing, but the problem is the same. Regards, Henrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784306: logwatch: Wrong pattern in postfix script for detecting openspf logentries
Package: logwatch
Version: 7.4.1-2
Severity: normal
Tags: patch
Dear Maintainer,
logwatch's postfix script looks for error messages from the openspf filter -
the postfix-policyd-spf-perl package in Debian. A pattern is used that includes
the website www.openspf.org. However, the postfix-policyd-spf-perl generates
log entries with a URI ending in .net, so the pattern match fails.
The attached patch changes the pattern matching to look for www.openspf.net
instead.
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages logwatch depends on:
ii perl5.20.2-3
ii postfix [mail-transport-agent] 2.11.3-1
Versions of packages logwatch recommends:
ii libdate-manip-perl 6.47-1
ii libsys-cpu-perl 0.61-1+b1
Versions of packages logwatch suggests:
pn fortune-mod none
-- no debconf information
--- postfix 2014-10-06 19:44:55.0 +0200
+++ /usr/share/logwatch/scripts/services/postfix 2015-05-05 07:12:48.656079328 +0200
@@ -1831,7 +1831,7 @@
$line =~ /^Attribute: / or
# handler sender_policy_framework: is decisive.
$line =~ /^handler [^:]+/ or
-# decided action=REJECT Please see http://www.openspf.org/why.html?sender=jrzjcez%40telecomitalia.itip=81.178.62.236receiver=protegate1.zmi.at
+# decided action=REJECT Please see http://www.openspf.net/why.html?sender=jrzjcez%40telecomitalia.itip=81.178.62.236receiver=protegate1.zmi.at
$line =~ /^decided action=/ or
# pypolicyd-spf-0.7.1
@@ -1936,7 +1936,7 @@
($domain, $ip, $message, $mechanism) = ('*unknown', '*unknown', '', '*unavailable');
#print LINE: '$line'\n;
- # postfix-policyd-spf-perl: http://www.openspf.org/Software
+ # postfix-policyd-spf-perl: http://www.openspf.net/Software
if ($line =~ /^Policy action=(.*)$/) {
$line = $1;
@@ -1957,10 +1957,10 @@
return;
}
- if ($line =~ /^550 Please see http:\/\/www\.openspf\.org\/Why\?(.*)$/) {
- # Policy action=550 Please see http://www.openspf.org/Why?s=mfromid=from%40example.comip=10.0.0.1r=example.net
- # Policy action=550 Please see http://www.openspf.org/Why?s=helo;id=mailout03.example.com;ip=192.168.0.1;r=mx1.example.net
- # Policy action=550 Please see http://www.openspf.org/Why?id=someone%40example.comip=10.0.0.1receiver=vps.example.net
+ if ($line =~ /^550 Please see http:\/\/www\.openspf\.net\/Why\?(.*)$/) {
+ # Policy action=550 Please see http://www.openspf.net/Why?s=mfromid=from%40example.comip=10.0.0.1r=example.net
+ # Policy action=550 Please see http://www.openspf.net/Why?s=helo;id=mailout03.example.com;ip=192.168.0.1;r=mx1.example.net
+ # Policy action=550 Please see http://www.openspf.net/Why?id=someone%40example.comip=10.0.0.1receiver=vps.example.net
my %params;
for (split /[;]/, $1) {
@@ -1971,7 +1971,7 @@
$params{'s'} = '*unknown' unless $params{'s'};
#print Please see...:\n\tMessage: $message\n\tIP: $ip\n\tDomain: $domain\n;
$Totals{'policyspf'}++;
- $Counts{'policyspf'}{'Policy Action'}{'550 reject'}{'See http://www.openspf.org/Why?...'}{$params{'s'}}{$params{'ip'}}{$params{'id'}}++ if ($Logreporters::TreeData::Collecting{'policyspf'});
+ $Counts{'policyspf'}{'Policy Action'}{'550 reject'}{'See http://www.openspf.net/Why?...'}{$params{'s'}}{$params{'ip'}}{$params{'id'}}++ if ($Logreporters::TreeData::Collecting{'policyspf'});
return;
}
Bug#783394: [SOLVED] Not a bug
Hi, the problem was caused by a wrong routing entry - it should only have been applied to the VPN clients, not on the VPN server. The OpenVPN server is working fine now. Sorry for the noise. Regards, Henrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783394: Might not be a bug
Hi, it seems that I have made a configuration mistake with the routing on the Wheezy vpn box. It doesn't do any harm in wheezy, but apparently jessie acts a bit differently. I'll do some more testing to verify it, and then this bugreport can probably be closed. I'll report back tomorrow. Regards, Henrik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783395: libpam-yubico: Segfault when using Yubikey for authentication prevents login
Package: libpam-yubico Version: 2.17-2 Severity: important Dear Maintainer, After upgrading from Wheezy to Jessie, Yubikey authentication has stoppped working. Yubikey authentication was disabled during the upgrade, in case I had to login without network access. After the upgrade I ran dpkg-reconfigure libpam-yubico to configure for the Yubico 2-factor authentication. Now, when logging in I do get the YubiKey prompt, but when hitting the Yubikey I am immediately returned to the login: prompt. /var/log/syslog has this: Apr 26 12:55:41 osiris kernel: [ 2717.882751] login[13942]: segfault at 7f6627ae2030 ip 7f6626f67d28 sp 7f661cc1b538 error 4 in libc-2.19.so[7f6626ee3000+19f000] The libpam-yubico configuration is mode=client try_first_pass id=N key=X (N and X taken from my previous configuration) -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-yubico depends on: ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18 ii libldap-2.4-2 2.4.40+dfsg-1 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libykclient3 2.13-1 ii libykpers-1-1 1.16.0-1 ii libyubikey01.12-2 libpam-yubico recommends no packages. libpam-yubico suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
