Bug#1069163: closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1069163: fixed in libkf5ksieve 4:22.12.3-2)
Hi there, With a test build provided by Patrick, I was able to confirm that this fixes the issue on my system. Thank you for the swift response! kind regards, -- Jonas Schäfer Team Lead Cloud Infrastructure Development Cloud Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 37 jonas.schae...@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Your Cloud Service and Cloud Technology Provider from Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann signature.asc Description: This is a digitally signed message part.
Bug#1069163: Acknowledgement (libkf5kmanagesieve5: sends password as username when authenticating against sieve servers)
Hello again, It seems that this might affect oldstable, too, given that the problematic code has existed for >8 years upstream: https://invent.kde.org/pim/libksieve/-/commit/ 6572c85975133777c803303331c3bfdcec82eecb Upstream bugs have been open since May 2021 (oldstable was released in August 2021): https://bugs.kde.org/show_bug.cgi?id=437858 kind regards, -- Jonas Schäfer Team Lead Cloud Infrastructure Development Cloud Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 37 jonas.schae...@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Your Cloud Service and Cloud Technology Provider from Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann signature.asc Description: This is a digitally signed message part.
Bug#1069163: libkf5kmanagesieve5: sends password as username when authenticating against sieve servers
Package: libkf5kmanagesieve5 Version: 4:22.12.3-1 Severity: grave Tags: security, patch, upstream Dear Maintainer, kmail, when using managesieve, sends the password as username to servers. This is particularly bad because usernames are commonly logged by servers in plaintext. It thus leaks passwords into server-side plaintext logs e.g. with dovecot. This seems to have been fixed upstream: https://invent.kde.org/pim/libksieve/-/commit/ 6b460ba93ac4ac503ba039d0b788ac7595120db1 Please consider a backport of that patch or updating the package quickly. Thank you. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkf5kmanagesieve5 depends on: ii kio 5.107.0-1+b1 ii libc6 2.37-15 ii libkf5configcore5 5.107.0-1+b1 ii libkf5coreaddons5 5.107.0-1+b1 ii libkf5i18n5 5.107.0-1+b1 ii libkf5kiocore55.107.0-1+b1 ii libkf5kiowidgets5 5.107.0-1+b1 ii libkf5ksieve-data 4:22.12.3-1 ii libkf5widgetsaddons5 5.107.0-1+b1 ii libqt5core5a 5.15.10+dfsg-7 ii libqt5network55.15.10+dfsg-7 ii libqt5widgets55.15.10+dfsg-7 ii libsasl2-22.1.28+dfsg1-4+b1 ii libstdc++614-20240201-3 libkf5kmanagesieve5 recommends no packages. libkf5kmanagesieve5 suggests no packages. -- no debconf information -- Jonas Schäfer Team Lead Cloud Infrastructure Development Cloud Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 37 jonas.schae...@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Your Cloud Service and Cloud Technology Provider from Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann signature.asc Description: This is a digitally signed message part.
Bug#1022972: konsole: Konsole does not handle arrow keys correctly anymore
Followup-For: Bug #1022972 Package: konsole Version: 4:22.08.1-1 Dear Maintainer, I can confirm the pinentry and konsole issue, but I'll focus on konsole, even though I suspect they may share a root cause. I found that konsole behaves correctly if I switch my keyboard layout to de nodeadkeys or us. If I use my normal layout Neo2 (`setxkbmap de neo`), the incorrect behaviour occurs. This can be traced down to the keyboard configuration of konsole. When going to: Edit Current Profile... -> Keyboard -> Default (XFree 4) -> Edit... and then using the "input" field for testing, it can be observed that for the arrow up key, different rules trigger depending on the keyboard layout: Layout Rule Escape Sequence de neo Up-Shift+Ansi+AnyModifier\E[1;1A us Up-Shift+Ansi-AppCursorKeys-AnyModifier \E[A The former escape sequence is not recognized by my shell (zsh) or by many other applications. This affects other keys, too (e.g. End, Home, and function keys). Ctrl+Arrow keys work fine, generating a \E[1;5A sequence for Ctrl+Up, which is identical between both layouts. It seems to me as if neo2 somehow causes konsole (or potentially all of Qt, looking at the pinentry thing) to assume some unnamed modifier to be active at all times. Max, Nathanael, could you confirm that you're too using Neo2, or similarly "exotic" layouts? Otherwise we're probably looking at different issues. kind regards, Jonas Schäfer -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages konsole depends on: ii kio5.98.0-1 ii konsole-kpart 4:22.08.1-1 ii libc6 2.35-4 ii libkf5configcore5 5.98.0-2 ii libkf5configwidgets5 5.98.0-1 ii libkf5coreaddons5 5.98.0-1 ii libkf5crash5 5.98.0-1 ii libkf5dbusaddons5 5.98.0-1 ii libkf5globalaccel-bin 5.98.0-1 ii libkf5globalaccel5 5.98.0-1 ii libkf5guiaddons5 5.98.0-2 ii libkf5i18n55.98.0-1+b1 ii libkf5kiowidgets5 5.98.0-1 ii libkf5notifyconfig55.98.0-1 ii libkf5service-bin 5.98.0-1 ii libkf5service5 5.98.0-1 ii libkf5widgetsaddons5 5.98.0-1 ii libkf5windowsystem55.98.0-1 ii libkf5xmlgui5 5.98.0-1+b1 ii libqt5core5a 5.15.6+dfsg-2 ii libqt5gui5 5.15.6+dfsg-2 ii libqt5widgets5 5.15.6+dfsg-2 ii libstdc++6 12.2.0-3 konsole recommends no packages. Versions of packages konsole suggests: pn lrzsz -- no debconf information
Bug#1014467: zlib1g: cannot install both of armhf and arm64 in multiarch setup
Hi Mark, For the record: On Mittwoch, 6. Juli 2022 17:30:19 CEST Mark Brown wrote: > This is most likely some system configuration issue on your part, there > is nothing in the packaging that specifically excludes this combination > and indeed I appear to have a system available to me with both > architectures installed without problem. You haven't provided any error > messages here, a dependency from apt to zlib1g on one architecture won't > prevent installation of zlib1g on another architecture so it's not going > to be that. I had interaction in #debian which confirmed that. Sorry for the noise. I did not include any error output, because it was rather tricky to do and I meant to supply it in a follow-up email. You were faster than that. And also sorry for not including it originally, I should've taken the time to do that. Thank you for your time!
Bug#1014467: zlib1g: cannot install both of armhf and arm64 in multiarch setup
Package: zlib1g Version: 1:1.2.11.dfsg-2+deb11u1 Severity: normal Dear Maintainer, I installed Debian with an arm64 kernel but an armhf userland. I now need some components as arm64, one of which depends on zlib1g. It is impossible to install both zlib1g:armhf and zlib1g:arm64, which causes the installation to fail because apt somehow depends also on zlib1g. This is after I had a Debian with arm64 kernel and arm64 userland and I needed a component in armhf which exhibited the same issue, which is why I went with a "split" userland/kernel in the first place. Please (re?-)add support for multiarch armhf+arm64 for the zlib1g package, thanks a lot. -- System Information: Debian Release: 11.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security') Architecture: armhf (aarch64) Foreign Architectures: arm64 Kernel: Linux 5.10.0-13-arm64 (SMP w/6 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 zlib1g depends on: ii libc6 2.31-13+deb11u3 zlib1g recommends no packages. zlib1g suggests no packages. -- no debconf information
Bug#983871: [Pkg-libvirt-maintainers] Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Hi, On Mittwoch, 17. November 2021 23:24:14 CET you wrote: > > I did another test by pinning the bookworm packages (7.6.0-1) and testing > > those. They exhibit the same behaviour as the patched libvirt, that is: in > > some cases, virsh destroy will show an error, but the container will be > > removed cleanly nonetheless. > > That's kind of odd, the version in bookworm should fix this issue because > it has been fixed on upstream version 7.3.0. And I can't reproducible this > bug again because I don't use LXC on libvirt quite heavily. So I did more tests. I ran a destroy/create loop on a bookworm box. However, due to time constraints, I wasn't able set up any complex thing inside the container, so it's possible that that skewed the results. In these tests, I was not able to reproduce the issue. To me: that indicates one of two things: (a) The second issue can only occur with LXC and with reasonably complex guests -- I think that is not unrealistic because we're talking nested cgroups here, which wouldn't occur with qemu or with simple containers. (b) The second issue only occurs on boxes which mix bookworm (or patched libvirt) and bullseye in undefined ways. Unfortunately, I currently do not have a test system with complex containers at hand which I can upgrade to bookworm on the spot. kind regards, Jonas
Bug#983871: [Pkg-libvirt-maintainers] Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Hi again, I did another test by pinning the bookworm packages (7.6.0-1) and testing those. They exhibit the same behaviour as the patched libvirt, that is: in some cases, virsh destroy will show an error, but the container will be removed cleanly nonetheless. This is an improvement over the previous situation, where it was impossible to destroy a domain. I'd thus suggest to move ahead with the patch, even if imperfect, as it then brings stable to the same state as testing in that regard (and I'll try to prepare a bug report for testing). kind regards, Jonas On Wed, 17 Nov 2021 16:10:57 +0100 Jonas Schäfer wrote: > Hi Guido, > > Thanks for your reply! > > On Wed, 17 Nov 2021 13:11:05 +0100 Guido Günther wrote: > > here's the missing link: > > > > https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/116 > > I took the artifacts from there and did another test run. At first glance, > everything looked good, but then it failed on destruction of the domain again, > with: > > error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- > lxc\x2d4078\x2drouter.scope/system.slice/cgroup.controllers': No such file or > directory > > The domain is afterward still fully cleaned up (the cgroup subtree under > machine.slice is gone completely), but the error message is still annoying. To > me it seems like the recursion in the libvirt code is racing against the > domain cleaning up after itself somehow, because I get different error messages > and sometimes it also succeeds: > > root@down ~ › virsh -c lxc:/// destroy router > Domain 'router' destroyed > > root@down ~ › virsh -c lxc:/// start router > Domain 'router' started > > root@down ~ › virsh -c lxc:/// destroy router > error: Failed to destroy domain 'router' > error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- > lxc\x2d4078\x2drouter.scope/system.slice/cgroup.controllers': No such file or > directory > > root@down ~ › virsh -c lxc:/// start router > Domain 'router' started > > root@down ~ › virsh -c lxc:/// destroy router > error: Failed to destroy domain 'router' > error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- > lxc\x2d1505\x2drouter.scope/system.slice/system-openvpn.slice/ > cgroup.controllers': No such file or directory > > root@down ~ › dpkg -l | grep libvirt > ii libvirt-clients 7.0.0-4~1.gbp7decb2 > amd64Programs for the libvirt library > ii libvirt-daemon 7.0.0-4~1.gbp7decb2 > amd64Virtualization daemon > ii libvirt-daemon-config-network 7.0.0-4~1.gbp7decb2 all > Libvirt daemon configuration files (default network) > ii libvirt-daemon-config-nwfilter 7.0.0-4~1.gbp7decb2 all > Libvirt daemon configuration files (default network filters) > ii libvirt-daemon-driver-lxc 7.0.0-4~1.gbp7decb2 > amd64Virtualization daemon LXC connection driver > ii libvirt-daemon-driver-qemu 7.0.0-4~1.gbp7decb2 > amd64Virtualization daemon QEMU connection driver > ii libvirt-daemon-system 7.0.0-4~1.gbp7decb2 > amd64Libvirt daemon configuration files > ii libvirt-daemon-system-systemd 7.0.0-4~1.gbp7decb2
Bug#983871: [Pkg-libvirt-maintainers] Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Hi Guido, Thanks for your reply! On Wed, 17 Nov 2021 13:11:05 +0100 Guido Günther wrote: > here's the missing link: > > https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/116 I took the artifacts from there and did another test run. At first glance, everything looked good, but then it failed on destruction of the domain again, with: error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- lxc\x2d4078\x2drouter.scope/system.slice/cgroup.controllers': No such file or directory The domain is afterward still fully cleaned up (the cgroup subtree under machine.slice is gone completely), but the error message is still annoying. To me it seems like the recursion in the libvirt code is racing against the domain cleaning up after itself somehow, because I get different error messages and sometimes it also succeeds: root@down ~ › virsh -c lxc:/// destroy router Domain 'router' destroyed root@down ~ › virsh -c lxc:/// start router Domain 'router' started root@down ~ › virsh -c lxc:/// destroy router error: Failed to destroy domain 'router' error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- lxc\x2d4078\x2drouter.scope/system.slice/cgroup.controllers': No such file or directory root@down ~ › virsh -c lxc:/// start router Domain 'router' started root@down ~ › virsh -c lxc:/// destroy router error: Failed to destroy domain 'router' error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- lxc\x2d1505\x2drouter.scope/system.slice/system-openvpn.slice/ cgroup.controllers': No such file or directory root@down ~ › dpkg -l | grep libvirt ii libvirt-clients 7.0.0-4~1.gbp7decb2 amd64Programs for the libvirt library ii libvirt-daemon 7.0.0-4~1.gbp7decb2 amd64Virtualization daemon ii libvirt-daemon-config-network 7.0.0-4~1.gbp7decb2 all Libvirt daemon configuration files (default network) ii libvirt-daemon-config-nwfilter 7.0.0-4~1.gbp7decb2 all Libvirt daemon configuration files (default network filters) ii libvirt-daemon-driver-lxc 7.0.0-4~1.gbp7decb2 amd64Virtualization daemon LXC connection driver ii libvirt-daemon-driver-qemu 7.0.0-4~1.gbp7decb2 amd64Virtualization daemon QEMU connection driver ii libvirt-daemon-system 7.0.0-4~1.gbp7decb2 amd64Libvirt daemon configuration files ii libvirt-daemon-system-systemd 7.0.0-4~1.gbp7decb2 all Libvirt daemon configuration files (systemd) ii libvirt0:amd64 7.0.0-4~1.gbp7decb2 amd64library for interfacing with different virtualization systems ii python3-libvirt 7.0.0-2 amd64libvirt Python 3 bindings I took a brief look at the code, but at first glance I have no idea how to gracefully deal with this race. Unfortunately, a google search did not bring up anything useful either. Sometimes it takes many attempts (10+) to reproduce this :/. kind regards, Jonas > > > Cheers, > > -- Guido > > > > > Message-Id: > > > From: Michal Privoznik > > > Date: Fri, 16 Apr 2021 16:39:14 +0200 > > > Subject: [PATCH] vircgroup: Fix virCgroupKillRecursive() wrt nested > > > controllers > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset=UTF-8 > > > Content-Transfer-Encoding: 8bit > > > > > > I've encountered the following bug, but only on Gentoo with > > > systemd and CGroupsV2. I've started an LXC container successfully > > > but destroying it reported the following error: > > > > > > error: Failed to destroy domain 'amd64' > > > error: internal error: failed to get cgroup backend for 'pathOfController' > > > > > > Debugging showed, that CGroup hierarchy is full of surprises: > > > > > > /sys/fs/cgroup/machine.slice/machine-lxc\x2d861\x2damd64.scope/ > > > └── libvirt > > > ├── dev-hugepages.mount > > > ├── dev-mqueue.mount > > > ├── init.scope > > > ├── sys-fs-fuse-connections.mount > > > ├── sys-kernel-config.mount > > > ├── sys-kernel-debug.mount > > > ├── sys-kernel-tracing.mount > > > ├── system.slice > > > │ ├── console-getty.service > > > │ ├── dbus.service > > > │ ├── system-getty.slice > > > │ ├── system-modprobe.slice > > > │ ├── systemd-journald.service > > > │ ├── systemd-logind.service > > > │ └── tmp.mount > > > └── user.slice > > > > > > For comparison, here's the same container on recent Rawhide:
Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Dear maintainer, dear Dio Putra, I was hit by this too when upgrading LXC-heavy machines to Debian stable. The patch proposed by Dio Putra [1] fixes the issue for me (I built libvirt 7.0.0-3 from salsa with that patch applied). The only caveat I found was that if you previously tried to destroy an LXC domain with unpatched 7.0.0-3, the destroy would still fail with this patch, but with a different error message: error: Failed to destroy domain 'router' error: Unable to read from '/sys/fs/cgroup/machine.slice/machine- lxc\x2d1207\x2drouter.scope/cgroup.controllers': No such file or directory I do consider this a lesser issue with the patch, given that without the patch, destroy won't ever work. A reboot rectifies the situation (restart of libvirtd does not seem to suffice). If the domain has not been attempted to be destroyed with 7.0.0-3, a destroy works flawlessly after upgrading to the patched version. Please apply the patch and provide an update to Debian stable, as this breaks the libvirt-lxc usecase heavily. kind regards, Jonas [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983871#30
Bug#888025: how to integrate ca-certificates with gpgsm (for email s/mime signature verification)
Just a note that this seems to have gotten much worse at least for some users in the bookworm testing cycle running kmail. I and at least one other user I know about get popups every few hours about some random certificates, probably because someone at some point sent me an email with S/MIME. A proper fix which doesn't involve manually copying down a long fingerprint into a configuration file would be much appreciated.
Bug#954159: pavucontrol: allow multiple instances
I second this request. Another use-case which cannot be addressed with window manager hacks is starting pavucontrol with different PULSE_SERVER environment variables. My use case is controlling audio servers in the LAN. When routing a stream there, I’d typically want to have both my local pavucontrol and a pavucontrol with PULSE_SERVER=audioserver for remote controlling open. Thanks.
Bug#965069: python3.8: Breaks at least python3-aioxmpp (CPython upstream bug 41295)
Package: python3.8 Version: 3.8.4-1 Severity: normal Tags: upstream Dear Maintainer, Python 3.8.4 has a regression [1] (compared to Python 3.8.4~rc1 and earlier versions) which break python3-aioxmpp [2] and potentially other packages [3]. The issue is being addressed upstream [4]. The impact is that importing or using the affected packages may fail with an error message similar to: TypeError: can't apply this __setattr__ to SomeTypeName Please see the minimal reproducer in [4] or try to `import aioxmpp` with python3.8-3.8.4-1 from experimental after installing python3-aioxmpp. I’m not quite sure what can/should be done about this, but I wanted to file this bug to track the issue, since it’ll cause build failures for python-aioxmpp. Kind regards & thanks, Jonas Schäfer [1]: https://bugs.python.org/issue41295 [2]: https://github.com/horazont/aioxmpp/issues/342 [3]: https://github.com/pallets/flask-sqlalchemy/issues/852 [4]: https://github.com/python/cpython/pull/21473 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3.8 depends on: ii libpython3.8-stdlib 3.8.4-1 ii mime-support 3.64 ii python3.8-minimal3.8.4-1 python3.8 recommends no packages. Versions of packages python3.8 suggests: ii binutils2.34-8 ii python3.8-doc 3.8.4~rc1-1 ii python3.8-venv 3.8.4-1 -- no debconf information
Bug#954616: python-aioopenssl: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit code 13
Hi, Thanks for the report. It looks as if this is a compatibility problem with Python 3.8. I fix upstream is on the way: https://github.com/horazont/aioopenssl/pull/9 kind regards, Jonas Schäfer
Bug#930798: radicale: silently falls back to defaults (without authn) when running with config for 1.x under uwsgi
Package: radicale Version: 2.1.11-6 Severity: normal Dear Maintainer, * What led up to the situation? I have a stretch-based radicale installation running under uwsgi with the attached uwsgi configuration. Under stretch, everything is operating correctly and radicale authenticates against the LDAP service specified in the configuration. * What exactly did you do (or not do) that was effective (or ineffective)? I upgraded from stretch to buster while having apt-listchanges and apt-listbugs installed. I modified the uwsgi configuration to use python3 instead of python27 (since radicale is now python3 based) and reloaded the uwsgi-emperor. * What was the outcome of this action? The upgrade passed without any notice from apt-listchanges or apt-listbugs regarding radicale. radicale was operating, but it was not performing any authentication; every password was accepted for every user name, opening the server up for denial of service by unauthorized users (by spamming data on it) and possibly opening up access to existing data (if the configuration fits). * What outcome did you expect instead? I expect either: (1) radicale to fail to start and/or operate at all, due to the obviously invalid configuration. This is the case when I run radicale manually from the command line (it already chokes at the `well-known` section, not to mention that there’s no LDAP support anymore). (2) a prominent warning via apt-listchanges that the configuration format has changed drastically, that LDAP is not supported anymore, and that attempting to run radicale with an invalid configuration may lead to it running without any authentication at all. At this stage in the release cycle, (2) may be the way to go (and is fully sufficient In My Opinion). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages radicale depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii lsb-base 10.2019051400 ii python3 3.7.3-1 ii python3-radicale 2.1.11-6 Versions of packages radicale recommends: ii ssl-cert 1.0.39 Versions of packages radicale suggests: pn apache2 pn apache2-utils pn libapache2-mod-proxy-uwsgi pn python3-bcrypt pn python3-passlib pn uwsgi ii uwsgi-plugin-python32.0.18-1 -- Configuration Files: /etc/radicale/config changed: [encoding] request = utf-8 stock = utf-8 [well-known] caldav = / carddav = / [auth] type = LDAP ldap_url = ldap://192.168.10.1/ ldap_base = ou=Account,dc=zombofant,dc=net ldap_attribute = uid ldap_filter = (objectClass=inetOrgPerson) [storage] type = multifilesystem filesystem_folder = /var/lib/radicale/collectionsfnord [rights] type = from_file file = /etc/radicale/rights /etc/uwsgi-emperor/vassals/radicale.ini [uwsgi] http-socket = 0.0.0.0:9001 processes = 1 threads = 1 auto-procname = true procname-prefix-spaced = [radicale] harakiri = 30 need-plugin = python27 wsgi-file = /usr/share/radicale/radicale.wsgi enable-threads = true offload-threads = 1 -- no debconf information
Bug#925474: unblock: python-aioxmpp/0.10.3-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package python-aioxmpp
Fixes the FTBFS issue #924801 by backporting an upstream commit.
diff -Nru python-aioxmpp-0.10.3/debian/changelog python-
aioxmpp-0.10.3/debian/changelog
--- python-aioxmpp-0.10.3/debian/changelog 2019-02-23 16:54:49.0
+0100
+++ python-aioxmpp-0.10.3/debian/changelog 2019-03-21 17:00:14.0
+0100
@@ -1,3 +1,15 @@
+python-aioxmpp (0.10.3-3) unstable; urgency=medium
+
+ * Fix test failure due to updated Python 3.7. This applies the
+unreleased upstream commit 13ab00d [1].
+
+[1]: https://github.com/horazont/aioxmpp/commit/
+ 13ab00d64094b9a13d9d6984d7509bb40efb1fce
+
+closes: #924801
+
+ -- Jonas Schäfer Thu, 21 Mar 2019 17:00:14 +0100
+
python-aioxmpp (0.10.3-2) unstable; urgency=medium
* Use CI=true mode [1] for tests during package build, to prevent
diff -Nru python-aioxmpp-0.10.3/debian/patches/python37-tests-compat.patch
python-aioxmpp-0.10.3/debian/patches/python37-tests-compat.patch
--- python-aioxmpp-0.10.3/debian/patches/python37-tests-compat.patch
1970-01-01 01:00:00.0 +0100
+++ python-aioxmpp-0.10.3/debian/patches/python37-tests-compat.patch
2019-03-21 17:00:14.0 +0100
@@ -0,0 +1,20 @@
+diff --git a/tests/xso/test_model.py b/tests/xso/test_model.py
+index b6d2e29..b1a2a75 100644
+--- a/tests/xso/test_model.py
b/tests/xso/test_model.py
+@@ -2200,13 +2200,9 @@ class TestXSO(XMLTestCase):
+ )
+
+ def test_init_takes_no_arguments(self):
+-with self.assertRaisesRegex(
+-TypeError,
+-r"takes no (parameters|arguments)"):
++with self.assertRaises(TypeError):
+ xso.XSO("foo")
+-with self.assertRaisesRegex(
+-TypeError,
+-r"takes no (parameters|arguments)"):
++with self.assertRaises(TypeError):
+ xso.XSO(bar="foo")
+
+ def test_init_forwards_to_base_class(self):
diff -Nru python-aioxmpp-0.10.3/debian/patches/series python-
aioxmpp-0.10.3/debian/patches/series
--- python-aioxmpp-0.10.3/debian/patches/series 2019-01-12 22:35:42.0
+0100
+++ python-aioxmpp-0.10.3/debian/patches/series 2019-03-21 17:00:14.0
+0100
@@ -1,3 +1,4 @@
workaround-dh_python3-dep-issue.patch
remove-github-button.patch
remove-ci-buttons.patch
+python37-tests-compat.patch
unblock python-aioxmpp/0.10.3-3
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-
debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Bug#917659: python-aioxmpp: FTBFS (autobuilder hangs)
Thanks for the report. Upstream maintainer here. This is caused by aioxmpp poking dangerously close to some asyncio internals and Python 3.7 handling things slightly different apparently. I found this issue already while testing 3.7 in travis CI, but I did not realize that it also applies to Debian buster already. I will try to make a 0.10.2 this year. (For reference, here’s the patch I created to fix it: https://github.com/horazont/aioxmpp/commit/ b1037556805321c0348a48af1517760871d596d3 )
Bug#886028: Bug
On Sat, 27 Jan 2018 15:41:01 +0100 Jonas Wielicki wrote: >[1]: https://www.dovecot.org/pipermail/dovecot/2018-January/110787.html Upstream claims to have a fix for that issue in https://github.com/dovecot/core/commit/ 90bd9600a0e38e55c02c6266c1270fdd4138c07d Wasn't able to test it. kind regards, Jonas
