Bug#1011103: inn2: Unable to start inn2 status=238/STATE_DIRECTORY error
On 5/16/2022 3:06 PM, Marco d'Itri wrote: On May 16, Richard Landster wrote: May 13 15:28:34 usenet-dev.stanford.edu systemd[3284]: inn2.service: Failed to set up special execution directory in /var/lib: Not a directory May 13 15:28:34 usenet-dev.stanford.edu systemd[3284]: inn2.service: Failed at step STATE_DIRECTORY spawning /usr/lib/news/bin/rc.news: Not a directory I think that there is something unusual in your system: how do /var/ and /var/lib/ look like? usenet-dev:/etc/news# ls -lrtd /var drwxr-xr-x 12 root root 4096 May 13 13:34 /var usenet-dev:/etc/news# ls -lrtd /var/lib drwxr-xr-x 25 root root 4096 May 13 15:28 /var/lib usenet-dev:/etc/news# ls -lrtd /var/lib/news lrwxrwxrwx 1 root root 18 May 13 13:19 /var/lib/news -> /var/spool/news/db usenet-dev:/etc/news# df -h Filesystem Size Used Avail Use% Mounted on udev3.9G 0 3.9G 0% /dev tmpfs 796M 1.5M 795M 1% /run /dev/sda115G 2.5G 12G 18% / tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/sda3 1007M 2.0M 954M 1% /var/cache/openafs AFS 2.0T 0 2.0T 0% /afs /dev/sdb1 196G 77G 110G 42% /var/spool/news Starting the service with /etc/init.d/inn2 does _not_ result in an error. I do not understand this, because the init script sources /lib/lsb/init-functions which sources /lib/lsb/init-functions.d/40-systemd which makes it just run systemctl anyway. You are correct, of course. I made a copy of /etc/init.d/inn2 called /etc/init.d/inn2-custom and ran that without the error the systemd version gave me. Sorry for the confusion. In any event I have found the issue. As you can see from the above /var/lib/news is a symbolic link. In the service file StateDirectory is set to news which resolves to /var/lib/news. It seems that systemd does not like StateDirectory to be a symbolic link. Lesson learned. Please close this issue.
Bug#923930: FTBFS: FAIL test_chain (exit status: 1)
It looks like this is fixed upstream (at least for 64-bit machines): https://github.com/heimdal/heimdal/issues/533 On Sun, 10 Mar 2019 06:17:32 -0500 "A. Wilcox" wrote: > Source: heimdal > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > heimdal fails to build from source, both in Buster and Sid. It is > failing in one of the tests. Relevant snippet below and full build log > is accessible at: > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/heimdal_7.5.0+dfsg-2.1.rbuild.log.gz > > = >Heimdal 7.5.0: lib/hx509/test-suite.log > = > > # TOTAL: 16 > # PASS: 15 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > FAIL: test_chain > > > cert -> root > cert -> root > cert -> root > sub-cert -> root > sub-cert -> sub-ca -> root > sub-cert -> sub-ca > sub-cert -> sub-ca -> root > sub-cert -> sub-ca -> root > sub-cert -> sub-ca -> root > max depth 2 (ok) > max depth 1 (fail) > ocsp non-ca responder > ocsp ca responder > ocsp no-ca responder, missing cert > ocsp no-ca responder, missing cert, in pool > ocsp no-ca responder, keyHash > ocsp revoked cert > ocsp print reply resp1-ocsp-no-cert > ocsp print reply resp1-ca > ocsp print reply resp1-keyhash > ocsp print reply resp2 > ocsp verify exists > ocsp verify not exists > ocsp verify revoked > crl non-revoked cert > FAIL test_chain (exit status: 1) > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386
Bug#880393: nmuing cyrus-sasl2
On Sat, 29 Sep 2018 12:23:05 +0200 Helmut Grohne wrote: Control: tags 792851 + pending Control: tags 880393 + pending patch Dear cyrus-sasl2 maintainers, I have prepared a NMU fixing the following bugs: * #792851: FTCBFS This one already had a patch since ages. * #880393: libsasl2-modules-gssapi-heimdal linked against mit krb5 Actually, libgssapiv2.so is built against heimdal correctly. It just happens that the dh_auto_install overwrites the heimdal version with the mit version. Putting the relevant dh_install between the two dh_auto_install fixes the issue. You can find a .debdiff attached. I'll be uploading it to delayed/10 later today. Please let me know if I should delay it any longer. Helmut This problem is causing us serious heartburn. Is there a way to get the corrected stretch .deb file so we can move ahead with our upgrade to stretch? Adam
Bug#886799: openafs-modules-dkms: install fails with compile error "implicit declaration of function 'inode_change_ok'"
On Wed, 10 Jan 2018 11:52:24 +0100 Zdenek Salvetwrote: On Tue, Jan 09, 2018 at 11:08:18PM -0600, Benjamin Kaduk wrote: > So the security update for meltdown/spectre changed the kernel ABI? > That's kind of unfortunate; usually Ben tries pretty hard to avoid > doing so. Yes, it was probably necessary (other postponed fixes requiring new ABI were added as well). I managed to create working openafs-modules-dkms by adding attached patch to openafs source package (works with both jessie and backport versions)... -- Zdenek Salvet sal...@ics.muni.cz Institute of Computer Science of Masaryk University, Brno, Czech Republic and CESNET, z.s.p.o., Prague, Czech Republic Phone: ++420-549 49 6534 Fax: ++420-541 212 747 Teamwork is essential -- it allows you to blame someone else. The patch you provide works fine with jessie and the 1.6.9 source packages. However, I cannot get it to work with wheezy. I compile the openafs source package against wheezy and the compilation completes without error and creates a bunch of .deb files. But when I try to install the patched openafs-modules-dkms on a 3.2.0-5 wheezy kernel I get the same error as before: /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c: In function 'osi_UFSTruncate': /var/lib/dkms/openafs/1.6.9/build/src/libafs/MODLOAD-3.2.0-5-amd64-SP/osi_file.c:195:5: error: implicit declaration of function 'inode_change_ok' [-Werror=implicit-function-declaration] Has anyone successfully compiled and installed 1.6.9 on a 3.2.0-5 wheezy machine? Adam Lewenberg
Bug#886799: Info received (openafs-modules-dkms: info regarding source of bug)
On Thu, 11 Jan 2018 16:55:52 -0500 Richard Burhanswrote: The attached patch appears to fix openafs_1.6.9-2+deb8u6: While that patch takes care of the inode_change_ok problem, there is still the "'struct dentry' has no member named 'd_alias'" problem (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776926 ).
Bug#868685: debmirror: not able to mirror sid
On Sun, 23 Jul 2017 13:35:31 +0100 Colin Watsonwrote: clone 868685 -1 reassign -1 apt 1.5~alpha1 retitle -1 apt: fails to update if mirror does not publish pdiff files thanks On Mon, Jul 17, 2017 at 07:00:13PM +0200, Thorsten Glaser wrote: > Package: debmirror > Version: 1:2.27 > Severity: normal > > I can’t figure out how to reliably mirror sid for users. > I’m attaching the config file, I tried diff_mode none and > use but get errors on the clients running apt-get update > either way: It is possible that we have two separate problems here. I'm seeing the second of your problems with my local mirror at the moment, but not the first. > E: Failed to fetch http://mirror.lan.tarent.de/debian/dists/sid/main/binary-amd64/Packages.gz Hash Sum mismatch >Hashes of expected file: > - Filesize:10129139 [weak] > - SHA256:d81d8d4ecff84b52fb6f1bc6e58c79570b95c4b8768c19aacd45a507d6699b76 > - MD5Sum:6ce60c48450df70864589829b407ef5a [weak] >Hashes of received file: > - SHA256:efe6a06883ca7e54d663032a404a6b32eb668024dd6ddeb0ae5e94990f2ba1c9 > - MD5Sum:3 We are getting the same error on our daily chroot updates of our sid chroot environment. Can you post your apt package bug number so we can track it? BTW, if we do a "chroot /var/cache/pbuilder/base-sid/ aptitude update" right before the chroot update the error goes away.