Bug#968588: dovecot-gssapi: GSSAPI login broke
On 19.8.2020 13.38, Christian Göttsche wrote: There is a proposed fix[1], which is claimed to resolve the issue[2]. Could you try to verify whether this change resolves the issue for you. There is an amd64 package available at [3], from a merge-request against the packaging[4]. Confirmed, the issue is fixed by these packages. I first upgraded to 2.3.11.3+dfsg1-1 again, which predictably broke the login (just to make sure there's no cached data or anything interfering). Installing the +salsaci version then restored access. -- Mikko
Bug#968588: dovecot-gssapi: GSSAPI login broke
Package: dovecot-gssapi
Version: 1:2.3.11.3+dfsg1-1
Severity: grave
Justification: renders package unusable
After upgrading dovecot to 1:2.3.11.3+dfsg1-1, GSSAPI login no longer works.
I'm using Thunderbird as client and it says the Kerberos ticket was not
accepted. A downgrade back to 1:2.3.10.1+dfsg1-2 fixes the situation.
-- Package-specific info:
dovecot configuration
-
# 2.3.10.1 (a3d0e1171): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.10 (bf8ef1c2)
# OS: Linux 5.4.35-core2-server x86_64 Debian bullseye/sid
# Hostname: capybara.tdb.fi
auth_krb5_keytab = /etc/dovecot/private/dovecot.keytab
auth_mechanisms = plain gssapi
mail_location = maildir:~/Maildir
mail_privileged_group = mail
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = scheme=CRYPT username_format=%u /etc/dovecot/users
driver = passwd-file
}
passdb {
driver = pam
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = " imap"
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
}
ssl_cert =
ii dovecot-gssapi 1:2.3.10.1+dfsg1-2
ii dovecot-imapd 1:2.3.10.1+dfsg1-2
pn dovecot-ldap
pn dovecot-lmtpd
pn dovecot-managesieved
pn dovecot-mysql
pn dovecot-pgsql
pn dovecot-pop3d
ii dovecot-sieve 1:2.3.10.1+dfsg1-2
pn dovecot-sqlite
Bug#893775: python3-certbot: should depend on python3-distutils
Package: python3-certbot
Version: 0.22.0-1
Severity: serious
Justification: Policy 3.5
The dependency on python3-distutils was recently dropped from
libpython3.6-minimal and the package was automatically removed from my
system as unused. Since then certbot fails with:
Traceback (most recent call last):
File "/usr/bin/certbot", line 11, in
load_entry_point('certbot==0.21.1', 'console_scripts', 'certbot')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 587, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2800,
in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2431,
in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2437,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 17, in
from certbot import account
File "/usr/lib/python3/dist-packages/certbot/account.py", line 21, in
from certbot import util
File "/usr/lib/python3/dist-packages/certbot/util.py", line 7, in
import distutils.version # pylint: disable=import-error,no-name-in-module
ModuleNotFoundError: No module named 'distutils'
Installing python3-distutils again fixes the issue.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.24-core2-server (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages python3-certbot depends on:
ii python3 3.6.4-1
ii python3-acme0.22.0-1
ii python3-configargparse 0.11.0-1
ii python3-configobj 5.0.6-2
ii python3-cryptography2.1.4-1
ii python3-josepy 1.0.1-1
ii python3-mock2.0.0-3
ii python3-parsedatetime 2.4-2
ii python3-pkg-resources 38.5.2-1
ii python3-requests2.18.4-2
ii python3-rfc3339 1.0-4
ii python3-tz 2018.3-2
ii python3-zope.component 4.3.0-1
ii python3-zope.interface 4.3.2-1+b1
Versions of packages python3-certbot recommends:
ii certbot 0.22.0-1
Versions of packages python3-certbot suggests:
pn python-certbot-doc
-- no debconf information
Bug#893774: borgbackup: should depend on python3-distutils
Package: borgbackup
Version: 1.1.4-2
Severity: serious
Justification: Policy 3.5
The dependency on python3-distutils was recently dropped from
libpython3.6-minimal and the package was automatically removed from my
system as unused. Since then borgbackup fails with:
Traceback (most recent call last):
File "/usr/bin/borgbackup", line 11, in
load_entry_point('borgbackup==1.1.4', 'console_scripts', 'borg')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 587, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2800,
in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2431,
in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2437,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/borg/__init__.py", line 1, in
from distutils.version import LooseVersion
ModuleNotFoundError: No module named 'distutils'
Installing python3-distutils again fixes the issue.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.24-core2-server (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages borgbackup depends on:
ii fuse 2.9.7-1
ii libacl12.2.52-3+b1
ii libb2-10.97+git20171226-2
ii libc6 2.27-2
ii liblz4-1 0.0~r131-2+b1
ii libssl1.1 1.1.0g-2
ii libzstd1 1.3.3+dfsg-1
ii python33.6.4-1
ii python3-llfuse 1.3.2+dfsg-2
ii python3-msgpack0.5.1-2
ii python3-pkg-resources 38.5.2-1
borgbackup recommends no packages.
Versions of packages borgbackup suggests:
pn borgbackup-doc
-- no debconf information
Bug#847961: gitweb: missing dependency to libcgi-pm-perl
Package: gitweb Version: 1:2.11.0-1 Severity: serious Justification: Policy 3.5 After running full-upgrade today I noticed that my gitweb server started returning internal server errors. Apache's error.log contained many repeats of this error: [Mon Dec 12 17:03:04.782271 2016] [cgi:error] [pid 20116] [client 163.172.66.30:41120] AH01215: Can't locate CGI.pm in @INC (you may need to install the CGI module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/gitweb/index.cgi line 13.: /usr/share/gitweb/index.cgi [Mon Dec 12 17:03:04.782303 2016] [cgi:error] [pid 20116] [client 163.172.66.30:41120] AH01215: BEGIN failed--compilation aborted at /usr/share/gitweb/index.cgi line 13.: /usr/share/gitweb/index.cgi [Mon Dec 12 17:03:04.782368 2016] [cgi:error] [pid 20116] [client 163.172.66.30:41120] End of script output before headers: index.cgi A search for CGI.pm revealed it to live in libcgi-pm-perl and installing that package fixed the issue. dpkg.log reveals that the package was installed prior to today's upgrade. I don't know why it got removed, and the relevant output has already disappeared from my terminal scrollback. The gitweb package suggests libcgi-fast-perl, which in turn depends on libcgi-pm-perl. However that won't be installed by default. As gitweb's index.cgi explicitly and unconditionally references the CGI module, it seems that a direct dependency should be added to the gitweb package. Mikko -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.1-core2 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gitweb depends on: ii git 1:2.11.0-1 ii perl 5.24.1~rc4-1 Versions of packages gitweb recommends: ii apache2 [httpd]2.4.23-8 ii libhttp-date-perl 6.02-1 Versions of packages gitweb suggests: ii apache2 [httpd-cgi] 2.4.23-8 pn git-doc -- Configuration Files: /etc/gitweb.conf changed: $projectroot = "/home/git"; $git_temp = "/tmp"; @diff_opts = (); -- no debconf information
Bug#789875: subsurface: FTBFS in experimental
Since these emails managed to escape my mail filters and catch my attention, I'll butt in with my opinion. Apologies if this has been said already. Have you considered in-source copies of the modified libraries? Perhaps as git submodules? If you take full control of building and installing them, you could either link them statically or install them in a private directory. Just yesterday I debugged a segfault in icedove which was caused by the package shipping a custom version of libldap under /usr/lib/icedove (see [1] for details), so this kind of thing isn't even unprecedented in Debian. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703857 -- Mikko
Bug#683953: udev: Dropping unix.ko from initrd makes certain custom kernels unbootable
Package: udev Version: 175-5 Severity: critical Justification: breaks the whole system Recently, bug #654282 was fixed by not attempting to include unix.ko in initrd images. I run custom kernels with a high degree of modularization, so a side effect of this change was that my systems became unbootable without warning. Fortunately the postinst script only updates the initrd image for the latest kernel, so I was able to boot into an earlier one and downgrade udev back to 175-3.1. I suggest checking for the presence of the unix.ko module when generating the initrd and including it if necessary. Since manual_add_modules already effectively checks for the presence of the module, perhaps it could return a status code to let force_load know not to add the module in conf/modules. If implementing the above is not possible, please check for the presence of unix.ko (or, equivalently, CONFIG_UNIX=m) when upgrading udev and issue a warning about unbootable system if it exists. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.1-core2 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.45 ii libc6 2.13-35 ii libselinux12.1.9-5 ii libudev0 175-5 ii lsb-base 4.1+Debian7 ii procps 1:3.3.3-2 ii util-linux 2.20.1-5.1 Versions of packages udev recommends: ii pciutils 1:3.1.9-5 ii usbutils 1:005-3 udev suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529751: gxmms2: Needs to be rebuilt against libxmmsclient5
Package: gxmms2 Version: 0.7.0-2 Severity: grave Justification: renders package unusable The gxmms2 package still depends on libxmmsclient4, which has been superseded by libxmmsclient5 in the 0.6DrMattDestruction release. Furthermore, libxmmsclient5 conflicts with libxmmsclient4, and the older version can not be used to communicate with the newer server. Since xmms2-client-cli also needs the client library, the only option is to remove gxmms2 and upgrade libxmmsclient. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29.2 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gxmms2 depends on: ii libatk1.0-0 1.26.0-1The ATK accessibility toolkit ii libc62.9-12 GNU C Library: Shared libraries ii libcairo21.8.6-2+b1 The Cairo 2D vector graphics libra ii libglib2.0-0 2.20.1-2The GLib library of C routines ii libgtk2.0-0 2.16.1-2The GTK+ graphical user interface ii libpango1.0-01.24.2-1Layout and rendering of internatio ii libx11-6 2:1.2.1-1 X11 client-side library ii libxmmsclient-glib1 0.5DrLecter-2.1 XMMS2 - glib client library ii libxmmsclient4 0.5DrLecter-2.1 XMMS2 - client library gxmms2 recommends no packages. Versions of packages gxmms2 suggests: ii xmms2-core0.6DrMattDestruction-1 XMMS2 - core package -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#384441: libgl1-mesa-dri: Incorrect rendering in OpenGL applications
Package: libgl1-mesa-dri Version: 6.4.2-1.1 Severity: grave Justification: renders package unusable I have recently been getting serious rendering problems with Mesa. For example, glxgears looks like this: http://tdb.fi/~tdb/glxgears-bug.png My own applications show their graphics shifted left by about half the window size. Most OpenGL modes of xscreensaver also show the left-shifting phenomenon. Planetpenguin-racer looks correct, for a wonder. It does have some z-fighting though. My graphics card is a Redeon ViVo from 2001, Xorg says "Chipset ATI Radeon QD (AGP) found." A couple of reasons lead me to believe this is not a hardware failure: 1. I have also seen this on an i915 machine 2. glxgears exhibits the problem with software rendering as well -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-rc5 Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages libgl1-mesa-dri depends on: ii libgl1-mesa-glx 6.4.2-1.1 A free implementation of the OpenG libgl1-mesa-dri recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
