After more debugging....

Matthew Palmer wrote:

The problem seems to be that indeed something somewhere is turning
sec->authoritative off. It's Apache as Adrian detected. The problem
is that ap_set_flag_slot() expects to write to a 4-byte int, wherever
the config rec only has a 1-byte int alias unsigned char, thus overwriting
some memory.

# Automatically generated email from bts, devscripts version 2.10.26
# submiter email address no longer valid
close 455456

Package: ltsp
Version: 5.1.5-1
Severity: wishlist
Tags: patch

When using nbd instead of nfs, ltsp uses unionfs.
Unionfs is being replaced by aufs in similar systems like live cds. It's
better maintained upstream, more reliable[1] and less buggy, so even
unionfs-modules Debian maintainer recommends its replacement[2].

I've tried it, and it works perfectly. Attached is the usual patch to
change this behaviour.

By the way, doing the patch I've checked that the files:
client/initramfs/hooks/ltsp_client
client/initramfs/init-bottom/unionfs_cow

are not used in the packaging of ltsp, and totally useless ;-)

Best regards.
José L.

[1] www.unionfs.org
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469338#54

severity 479131 wishlist
retitle 479131 Improve documentation of hwclock versus /etc/default/rcS
thanks

As far as I can tell there is nothing to fix here except a documentation
issue.

hwclock does indeed not respect the setting for UTC/localtime in
/etc/default/rcS, but although that may be unfortunate, it is certainly not
a release critical bug.

Please see the manpage of hwclock on how to change the system clock between
UTC and localtime using hwclock and also see the contents of the file
/etc/adjtime that is referenced in that manpage.

Cheers,
FJP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBIKwL1gm/Kwh6ICoQRAorZAJ9dlThFB/gjFmKkaXzM0xOLQbFQ6gCgi4YP
n+TvxPU+igNgvLPlLvPnNes=
=yqgq
-----END PGP SIGNATURE-----

I seem to have corrected the problem by removing my HP 720C printer from
the system and then reinstalling it. I had not heard anything form the
developers and had not done this earlier because I figured the new upgrade
would not change things sufficiently that I would need to remove and
reinstall the printer but I guess I was wrong.

Wanted to let you know so that unless someone else has also had a problem
that this is related, this bug can be removed w. the instruction of anyone
having the problem to remove and reinstall the printer as a fix.

Thanks for all your good work.
Whit Hansell

I seem to have corrected the  problem by removing my HP 720C printer from the system and then reinstalling it.  I had not heard anything form the developers and had not done this earlier because I figured the new upgrade would not change things sufficiently that I would need to remove and reinstall the printer but I guess I was wrong.
Wanted to let you know so that unless someone else has also had a problem that this is related, this bug can be removed w. the instruction of anyone having the problem to remove and reinstall the printer as a fix.
Thanks for all your good work.Whit Hansell

I think this is a fix for the bug.

---------- Forwarded message ----------
From: Kim Hansen gmail.com>
Date: Wed, May 14, 2008 at 4:52 PM
Subject: Re: Initialization of load_path at startup
To: John Swensen comcast.net>
Cc: maintainers@octave.org

On Wed, May 14, 2008 at 2:02 PM, John Swensen comcast.net> wrote:

Package: coreutils
Version: 5.97-5.3
Severity: grave
Justification: causes non-serious data loss

Hi,

assuming you have a file /tmp/A with a size of 1 GB

$ dd if=/dev/zero of=/tmp/A bs=1M count=37 oflag=append
dd: you probably want conv=notrunc with oflag=append
37+0 records in
37+0 records out
[...]

The file now has 37 MB and not 1037 MB

So dd throws an error/hint but does not stop.
I would have expected an exit() after that error.

cheers,
Florian

Package: rcconf
Version: 1.20
Severity: minor

--- Please enter the report below this line. ---

running rcconf from konsole, i see the following messages but, apart from
those, application works normally.
i think these are perl related (since they appeared after latest perl upgrade)
and this bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479610) is
also similar..

messages :

Package: squashfs-tools
Version: 1:3.3-7
Severity: important

Hi,

while I ACK that lzma is a problem, and that you switched to disable
lzma by default, I really think that you should still accept the -nolzma
option, and silently (or with a warning message, going like "ignoring
-nolzma, which is now the default") ignore it, so that tools specifying
this option when calling mksquashfs don't break.

That regression was probably introduced when lzma support got completely
removed.

Cheers,
--
Cyril Brulebois

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Package: jazip
Severity: wishlist
Tags: l10n patch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please include attached translation fi.po to the package.

Regards,
Esko Arajärvi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIKvUSejjRZhTfFSwRAmTTAJ9b8vXTCrEP3srEtksGHF9mjzLtAQCfSh+n
YVBAe8yKGKdlFGoBPljLa34=
=Bmdv
-----END PGP SIGNATURE-----