* maks attems <debian at sternwelten.at> [2004-06-03
19:43]:> #252078 logtail: should depend on perl >= 5.8
> sarge as any other modern linux distro use perl 5.8.x,
> it's even inside of its base.
> backports are under the peril of its author
> if no one voices up, i'll close that bug in the next days.
The thing is that its not only about backports. Of course I know that
sarge has 5.8 already and mixes must not be supported, but we can avoid
by stating clearly in the control file that our perl usage needs 5.8.
IMHO it should stay and is a good thing.
> #244511: logcheck-database: While up- or downgrading logcheck-database:
> "Internal Error: linkfile() called without names !"
> hmm there is nice explication in the last message,
> but i do not understand a word:
> did the security team forget to set
> "logcheck-database/security_level"
> or was the package simply a corrupted one?
The security team doesn't set anything.
OUTCH!
From debian/logcheck-database.postinst of the package:
#v+
db_get logcheck-database/security_level
linkfile logcheck.ignore $RET
linkfile ignore.d $RET
#v-
This is *sooooooooo* wrong :-/ It is no doubt that it is going to
fail...
I'll be contacting Joey || mdz regarding this and check if they would
accept an update for that.
I like to notice that this problem existed _before_ the security update
I prepared for woody. This part of code was in before already, so it is
not a problem that just arised because of the update.
> could not reproduce neither with dialog nor with debconf
> neither with non-interactive.
Hmm, strange. From looking at the snippet it should be quite trivial to
reproduce it.
Like said, I will take ownership of that bug and work on it. Have to
test the new owner command of the BTS anyway. ;)
[some minutes later]
Caught Joey in a really good (= weak) moment, he said he would accept
the oneline fix (pseudopatch):
#v+
db_get logcheck-database/security_level
+RET=${RET:-workstation}
linkfile logcheck.ignore $RET
linkfile ignore.d $RET
#v-
Can others confirm that this is no bashism, and propose a good
changelog entry that will tell Joey that his decision to allow this fix
go into woody?
> #244411: logcheck: Upgrade loses symlinks in /etc/logcheck
> i understand the one, who submitted this bug.
> i would not like a package to override my settings.
> but we no longer use a symbolic link since ..!
But the woody version still does.
> and i do not thing that issue is soooo big
> that i would need a fix in woody or does it?
The thing is rather it won't really be accepted (or we need some really
good opinions to convince Joey (again...)).
> proposition: downgrade wishlist && tag wontfix && close on
sarge
> release
We definitely could need a cantfix tag ;)
There seems to be a thinko in this code snippet that causes it:
#v+
linkfile() {
# snipped
local srcfile=/etc/logcheck/$1.$2
local dstfile=/etc/logcheck/$1
# snipped
if [ -e $dstfile -a ! -L $dstfile ]; then
# no link, not worth looking at -- snipped
else
if [ -e $dstfile ]; then
# remove the old link
rm $dstfile
fi
ln -sf $1.$2 $dstfile
fi
## snipped
linkfile logcheck.ignore $RET
linkfile ignore.d $RET
#v-
I can see there is a problem, unfortunately... We can the bug reporter
that he shall "dpkg-reconfigure logcheck-database" to change the
symlink
rather than to changing it by hand. debconf implementation was quite
b0rked back then but can't be fixed for woody, sorry.
> #242760: logcheck: Directory /var/lib/logcheck missing after a
> reinstallation
Will take a look later, sorry. Don't have the time currently to
investigate further.
So long,
Alfie
--
Dessen NOC erklaerte uns aber, dass das Mailproblem nicht an ihnen liegen
koennte der ihr Router habe gar keinen Port 25. Der habe nur 16 Ports.
Also kann Mails nichts mit Port 25 zu tun haben.
-- Ulli Horlacher in <a3789e$6i2$1 at moep.bb.bawue.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20040604/84726ed0/attachment.pgp