Bug#1011103: inn2: Unable to start inn2 status=238/STATE_DIRECTORY error

2022-05-17 Thread deb251

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)

2019-03-30 Thread deb251
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

2018-12-10 Thread deb251

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'"

2018-01-25 Thread deb251

On Wed, 10 Jan 2018 11:52:24 +0100 Zdenek Salvet  wrote:

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)

2018-01-12 Thread deb251

On Thu, 11 Jan 2018 16:55:52 -0500 Richard Burhans  wrote:

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

2017-07-24 Thread deb251

On Sun, 23 Jul 2017 13:35:31 +0100 Colin Watson  wrote:

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.