I have no objections to closing this issue.
- Marc
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
It's been a while... Your thought is the only reason that makes sense, though.
I'm sorry I didn't provide a clearer rationale in the original bug.
- Marc
> On Feb 20, 2014, at 3:14 PM, "Manuel A. Fernandez Montecelo"
> wrote:
>
> 2014-02-20 20:08
Package: spamassassin
Version: 3.2.4-1~bpo40+1
Severity: normal
Tags: patch
If shortcircuit is enabled, the log message emitted on each scan
includes the shortcircuit state at the end. The logcheck db needs to
include that as an optional string in the regex:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+
(sp
Have any decisions been made about how this will be handled?
Etch-and-a-half is fast approaching, and the new ivtv drivers in
mainline 2.6.24 is the main reason I'm interested in that upgrade in the
first place.
One possible alternative that I haven't seen mentioned yet would be to
ignore the prob
Martin Michlmayr wrote:
* Marc Sherman <[EMAIL PROTECTED]> [2008-01-15 09:43]:
Package: k9copy
Version: 1.1.1-3-0.0
This package doesn't seem to be in Debian. What does
dpkg -p k9copy | grep Maintainer:
say?
It's from Christian's multimedia repository. Most of his
It's also missing a dep on kdelibs.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: k9copy
Version: 1.1.1-3-0.0
Severity: serious
Justification: Policy 3.5
k9copy is missing a depends on libhal-storage1:
k9copy: error while loading shared libraries: libhal-storage.so.1:
cannot open shared object file: No such file or directory
-- System Information:
Debian Release: 4
dann frazier wrote:
For modules, my immediate thought is to find the first option below
that works:
1) Does the existing version work with 2.6.23 as-is?
2) Can support for 2.6.23 be easily added to the existing version in
such a way that you can demonstrate low-risk of regressions for
Ian Campbell wrote:
What do I actually need to do? Prepare and upload a 1.0.3-1etch1 built
against etch?
I'm not 100% sure. You should probably sync up with Dann Frazier; he
seems to be running the show.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
Package: ivtv-utils
Version: 0.8.2-2
Severity: important
It looks like the kernel team is going to be upgrading stable to 2.6.23
for "etch-and-a-half":
http://lists.debian.org/debian-release/2007/10/msg00252.html
The new 1.0.x ivtv-utils package will be needed in stable for
compatibility with the
John Goerzen wrote:
Hi Marc,
I unfortunately do not have time to do this. I recognize that it would be a
utility, but I don't have the time or the need for it here.
Could you please reopen the wishlist and tag it help so that other users
who might be able to do this could grab it?
Thanks,
Package: bacula
Version: 2.0.3-4
Severity: wishlist
Would it be possible to have the current version of bacula added to
backports.org for etch users? I've posted a couple of requests to the
backports-users list, but no-one's responded. Perhaps you could maintain
it there?
Thanks,
- Marc
-- Syst
Ola Lundqvist wrote:
When FILTERCTRLM is gone, this bug can be closed.
Sounds good.
I didn't find the bug report that introduced FILTERCTRLM in the first
place, so I cannot comment whether the issue raised therein is really
fixed now.
See #287126 for the reason behind it.
I'm not using cr
Marc Haber wrote:
On Wed, Jan 05, 2005 at 09:55:40AM -0500, Marc Sherman wrote:
I think it would be great if cron-apt would run apt-listchanges on
updated packages after downloading them. What do you think?
I agree.
I can't really think of how to best implement that, though. If you
Have you decided if you want to do this? The thread[0] on
[EMAIL PROTECTED] seemed mostly for the idea, and there was
subsequently another thread on the same list about the related package
dkim-milter[1] that seemed to agree with that assessment.
[0] http://lists.debian.org/debian-volatile/200
Package: mime-support
Version: 3.39-1
Severity: normal
The mime type for atom appears to be incorrect. According to the spec,
it should be application/atom+xml, but it's currently application/atom
in mime.types.
- Marc
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy
Package: logcheck
Version: 1.2.54
Severity: normal
Tags: patch
Cron is logging messages like:
May 8 03:58:48 pyloric /usr/bin/crontab[387]: (root) LIST (nobody)
but the logcheck pattern isn't expecting "/usr/bin/".
- Marc
-- System Information:
Debian Release: 4.0
APT prefers stable
APT
Filipe Lautert <[EMAIL PROTECTED]> wrote:
> Following this thread I could get auth_pam to work, but for each
> action that I take it prints the following in my apache error.log:
>
> [Fri Mar 09 08:43:07 2007] [error] Internal error: pcfg_openfile()
> called with NULL filename
> [Fri Mar 09 08:43:
Package: libmail-dkim-perl
Version: 0.19-3
Severity: wishlist
*** Please type your report below this line *** Once a newer version of
libmail-dkim-perl is in testing, please consider also uploading that
version to volatile. The version in stable doesn't implement the current
draft spec, particu
Hi. Would you consider patching this bug for etch r1 and/or volatile?
This bug creates an incompatibility with Debian's default MTA, and the
false positives it leads to could be considered a form of data loss.
The patch to fix this bug in upstream svn is one line of code (plus
three lines of comme
Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#402316: blars.org is down; hinfo-update fails miserably as a result,
which was filed against the hinfo package.
It has been closed by Neil McGovern <[EMAIL PROTECTED]>.
Their explanation is attached b
severity 402316 serious
thanks
I killed the process after a minute, so I didn't see that it kept going
as long as Rene Wunderlich says. If that's true, then this is an RC bug,
IMO, as it can DOS the machine.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
Package: hinfo
Severity: important
blars.org has gone down, and is now redirecting to a godaddy search
engine page. This has two effects:
1) The blars.org rbl now blacklists the entire internet
2) hinfo-update downloads a huge spew of random search engine results in
/var/lib/hinfo, breaking the
severity 303780 serious
thanks
This bug violates at least policy 10.7.2, as the files in modified in
/var/lib/hinfo/ are being used as configuration files, and should be
located in /etc.
I'm sure there's another policy reference that's more on point about the
program must not modify non-conf
Package: hinfo
Version: 1.02-2
Severity: serious
Justification: Policy 3.3
In my opinion, hinfo is currently nowhere near being able to ship. It
ships out of the box with a number of significant bugs that have been
reported in some cases for over a year and a half, without any
maintainer action
The new version has been released since April 25.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: hinfo
Version: 1.02-2
Severity: normal
blackholes.intersil.net has gone down; all dns requests now redirect to a
netsol parking page.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
reopen 306208
tags 306208 + moreinfo unreproducible
thanks
This is one more bug that I believe you closed incorrectly. The correct
procedure for a bug you cannot reproduce is to tag the bug moreinfo and
unreproducible, and ask the submitter if they can still reproduce it
with the latest version.
I
Package: hinfo
Version: 1.02-2
Severity: normal
>From the maintainer of ybl.megacity.org:
Derek J. Balling wrote:
>
> $ dig +short ybl.megacity.org ns
> localhost.megacity.org.
> $ dig +short ybl.megacity.org txt
> "This zone is no longer in use and now returns bogons to convince you
> to sto
Andreas Metzler wrote:
>
> Hello,
> I am currently strongly tending to close this bug as
> - unsolvable
> - cost/benefit. Solving is probably going to intoduce severe problems
> for some people while only only fixing a wishlist request otherwise.
Yup, I've been following the debian-devel discus
Simon Kelley wrote:
>
> This would be nice to do, but it's a little time-consuming for my
> available free time just now. If there hasn't been a release closer to
> the next Debian stable release, I'll bump the version.
Just to clarify, I wasn't proposing that you upload a new package every
day;
Package: slimserver
Severity: normal
The slimp3 package is a very old version of slimserver. Your package should
conflict with it, and replace it.
You might also want to replace the exisitng slimp3 package with a
transitional package to move people over to slimserver.
-- System Information:
De
Package: slimserver
Severity: wishlist
Please consider packaging the 6.2.2 nightly builds. The general process
for slimserver releases seems to be that the "stable" nightly build branch
(currently 6.2.2) doesn't get released for a long time, so a lot of those
bug fixes will take a long while to g
Debian Bug Tracking System wrote:
>
> Source: slimserver
> Source-Version: 6.2.1-1
>
> We believe that the bug you reported is fixed in the latest version of
> slimserver, which is due to be installed in the Debian FTP archive:
Cool! How are you solving the DFSG problems with the firmware and
g
Package: apticron
Version: 1.1.12
Severity: wishlist
It would be helpful if apticron would also report on packages which
apt-get dist-upgrade reports as being kept back. For example, in
today's testing update, base-config somehow ended up in testing despite
a conflict with testing's version of t
If the OP quoted his config accurately, I'm betting it's the commas that
are breaking things. Exim uses : (without spaces) for list separation.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: hinfo
Version: 1.02-2
Severity: normal
relaywatcher.n13mbl.com has gone bad. They're resolving all domains and
IPs to 216.122.145.102 with a wildcard, and the website forwards to a
bogus search engine.
- Marc
-- System Information:
Debian Release: 3.1
APT prefers testing
APT polic
Marc Haber wrote:
But the real-* business has been in the exim packages for a _very_
long time (this is even part of exim3 on woody) and probably nobody
knows any more why we include this. Does upstream recommend this in
its default config, or is this a Debianism?
The use of real-* comes straight o
Marc Haber wrote:
I think that the current behavior is fine for the default
configuration in sarge.
Oh, yeah, of course, I don't think this needs to change for Sarge.
For post-sarge, I am open to arguments, but am not yet convinced.
Ok, that's fine. But if you agreed with my goal, what do you thin
Marc Sherman wrote:
Yeah, I thought of that, but I'm having trouble figuring out where to
put it. It needs to go before the first use of check_lcoal_user, but
after 400_exim4-config_system_aliases, so that system users (such as
root) aliased to normal users continue to work. Ho
Marc Haber wrote:
To me, this looks like an issue which could be solved in a dedicated
router which will fail e-mail addressed to system users. However,
there might be packages that need their user to be able to receive mail.
Yeah, I thought of that, but I'm having trouble figuring out where to
pu
Package: exim4
Version: 4.50-4
Severity: wishlist
It seems to me that the check_local_user router option should fail for
system users. Some packages that create system users already put them
in /etc/aliases pointing to root, but there are a number of system users
on my machine that are not curre
Jamie L. Penman-Smithson wrote:
Whether it gets fixed before sarge or not, we're not going to start
including rules for messages caused by transient problems in packages,
sorry.
You can either configure your favourite syslog variant to not log those
messages, or you can add a regexp for it to a loc
Stephen Gran wrote:
I also don't use syslog with clam, so I miss a lot of the stuff you
report :)
No problem. You're probably the most responsive maintainer of all the
packages I've got installed, so I really can't complain. :)
Yes, you'll get the usual 'newer version available, blah, blah' mess
Package: clamav-freshclam
Version: 0.84-2
Severity: normal
In 302254 you said the "Signal 1: re-opening log file" message was going
away, but it's still here, just without the "Signal 1" part. So here's
a modification of the logcheck line to catch it:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ freshcla
Package: clamav-freshclam
Version: 0.84-1
Severity: normal
Tags: patch
Freshclam changed the way it logs the wakeup signal:
--- clamav-freshclam2005-04-30 08:17:39.901241971 -0400
+++ clamav-freshclam.bak2005-04-30 08:17:21.341194368 -0400
@@ -1,5 +1,5 @@
^\w{3} [ :0-9]{11} [._[:aln
Stephen Gran wrote:
If you want to stay absolutely current, rather than wait for something
to make it to testing, I suggest using the debs at
http://people.debian.org/~sgran
I put debs there ususally within a few hours of uploading to unstable
for both sarge and woody.
Thanks. I checked unstable
Package: clamav
Version: 0.83-5
Severity: wishlist
Freshclam is helpfully logging this message, every hour on the hour:
Apr 29 16:16:10 pyloric freshclam[22640]: WARNING: Your ClamAV
installation is OUTDATED - please update immediately!
Apr 29 16:16:10 pyloric freshclam[22640]: WARNING: Local ver
Jamie L. Penman-Smithson wrote:
Since there is an open bug about this filed against spamassassin, I'm
not sure this should be included with logcheck. This is a temporary
issue which will [hopefully] be fixed in the next release of SA, in the
meantime this belongs in a local-foo file..
This bug has
Package: logcheck
Version: 1.2.37
Severity: normal
Please add this rule to /etc/logcheck/ignore.d.server/spamd:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]: Parsing of undecoded
UTF-8 will give garbage when decoding entities at
/usr/share/perl5/Mail/SpamAssassin/HTML\.pm line 182, line
[0
Package: exim4
Version: 4.50-5
Severity: grave
Tags: security sid patch
Justification: remote exploitable DOS
The patch for 296492, which is currently in sid's 4.50-5, introduced an
infinite loop which could be triggered by a remote site with
(intentionally?) misconfigured DNS.
It is discussed in
I've added one more new log message to the clamav-daemon logcheck file:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ clamd\[[0-9]+\]: SelfCheck: Database
modification detected\. Forcing reload\.$
This message occurs rather frequently. My guess is that it's caused by
a race condition where clamav-freshcla
Package: hinfo
Version: 1.02-2
Severity: normal
The autoupdate facility in this package overwrites files that are
shipped as part of the deb. This causes the following warnings when
debsums is run from reportbug:
Verifying package integrity...
There may be a problem with your installation of hin
Package: hinfo
Version: 1.02-2
Severity: normal
This is based on a current auto-update, I'm not sure about what's being
shipped in the package.
More info on the dead site:
http://weblogs.asp.net/acampbell/archive/2005/01/25/359810.aspx
- Marc
-- System Information:
Debian Release: 3.1
APT pr
Kjetil Kjernsmo wrote:
Anyway, I reviewed a few more related upstream bugs, and I think yours
may be this upstream bug:
http://bugzilla.spamassassin.org/show_bug.cgi?id=4055
For you, 192.168.23.5 is IANA reserved block, so those are trusted, and
on the outside, 61.52.78.187, which SA trusts by d
I've made a minor change to the logcheck file:
The existing file only ignores the signal 14 message; I added signal 1,
too, to deal with the weekly logrotate run. Clamav-daemon already
ignores that output.
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ freshclam\[[0-9]+\]: Received signal
(14, wake up|1,
Todd Troxell wrote:
The deal with this is that we can't use gid logcheck in
dh_installlogcheck because the logcheck user doesn't exist until
logcheck gets installed.
It is annoying, but I've not come up with a solution to this yet.
Ah, good point. I hadn't thought of that. A bit of egg on my face
Stephen Gran wrote:
Hmm, I'm using dh_installlogcheck to install them. I would have
thought that would set permissions appropriately. I guess a bug
report is in order, since this will affect many packages. The patch
is simple (one line), so I won't bother with it here. Do you want to
file it o
Package: logcheck
Version: 1.2.35
Severity: normal
I reported a bug on a couple clamav packages (302253, 302254) which
noted that in Sarge, logcheck files are supposed to be root:logcheck
640, not root:root 644. The clamav maintainer replied that he's using
dh_installlogcheck to install them, so
Package: clamav-freshclam
Version: 0.83-3
Severity: normal
Tags: patch
I've attached a new logcheck/ignore.d.server/clamav-freshclam file. I've
changed the entire file to conform to Sarge's logcheck standards, so I'm
not bothering with an actual patch file. I've added a handful of new
logcheck e
Package: clamav-daemon
Version: 0.83-3
Severity: normal
Tags: patch
I've attached a new logcheck/ignore.d.server/clamav-daemon file. I've
changed the entire file to conform to Sarge's logcheck standards, so I'm
not bothering with an actual patch file. I've added a handful of new
logcheck entries.
Marc Sherman wrote:
My worry there is that listchanges.conf is owned by another package,
though it doesn't appear to be a conffile. Does that mean that you're
allowed to write to it in your maintainer scripts? I'm not sure.
Really, listchanges.conf should be listchanges.d,
Colm MacCarthaigh wrote:
On this front, I've been thinking it would be better to use
apt-listchanges --profile option, ie use --profile=apticron and allow
end-users to pick the output they desire that way. with defaults
somewhat like:
[apticron]
which=both
headers=1
I presum
Package: apticron
Version: 1.1.7
Severity: wishlist
We had this discussion in email before this package entered the archive.
Since we disagreed at the time, I'm filing this as a wishlist.
Currently, the apt-listchanges stderr is redirected to /dev/null. This
makes it difficult to debug problems.
Package: apticron
Version: 1.1.7
Severity: normal
Congratulations on finally getting this into the archive! :)
apt-listchanges should have the following additional command-line
switches:
--which=both --headers
The first is already the default, but it should be specified on the cmd
line in case
Kjetil Kjernsmo wrote:
You can do this by taking a message you see misfires, save it to a file,
say test.msg and go
spamassassin -D < test.msg
on it.
You'll get a long debug log. I don't really know what the interesting
part of it is, but you could try posting everything up to (but not
includin
Kjetil Kjernsmo wrote:
I'm sure that there are a lot of other rules that
aren't behaving correctly because of 300558 on Debian, that just
don't fail as spectacularly or obviously as ALL_TRUSTED, because of
the lack of Received parsing.
Yeah, that could well be, good point.
For example, I'm quite
Kjetil Kjernsmo wrote:
The patch currently attached to 290927 doesn't fix the parsing
problem, it just avoids incorrectly reporting an unparsed Received
header as a trusted relay.
Hmm, yeah But you agree it is better than nothing...?
Yes, the patch is the correct fix for 290927. My point wa
Package: spamassassin
Version: 3.0.2-1
Severity: normal
According to the analysis of 290927, and upstream's fix for their bug
3949, the SA currently shipping in Sarge can't parse the Received
headers created by Sarge's default MTA, Exim4.
The patch currently attached to 290927 doesn't fix the par
Package: exim4-config
Version: 4.34-10
Severity: wishlist
A -o option would be useful on update-exim4.conf.template, to generate a
sample "one big config" from the installed conf.d files when
dc_use_split_config='false'.
This is useful when considering migrating from one-big-file to conf.d --
gen
Philip Hazel wrote:
On Sun, 6 Feb 2005, Marc Haber wrote:
this is Debian bug #240883, http://bugs.debian.org/240883.
Why is this considered a bug?
Because Debian uses the Bug Tracking System to track wishlist requests,
by setting the bug's severity to "wishlist". You can run a mental
s/bug/tic
Strange. exim4doc moved into testing this morning, despite this bug.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Of course, there's a missing { in the ${if...
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: exim4-config
Version: 4.34-10
Severity: wishlist
The stock exim4-config includes a (commented out) block that does
reverse DNS verification in the ACLs using !verify=reverse_host_lookup.
In the case of a defer (ie: a DNS timeout), this logs but does not
actually include the warning header
Package: libapache2-mod-auth-pam
Version: 1.1.1-4.1
Severity: normal
Tags: security
If a user does not have access to a location/directory due to a require
user directive that excludes them, and their password is correctly
given, apache returns an auth failure immediately instead of respecting
the
Package: logcheck-database
Version: 1.2.33
Severity: normal
I just installed 1.2.33, and it made my rules dirs setuid, not setgid...
- Marc
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux
Package: spamassassin
Version: 3.0.2-1
Severity: normal
The ALL_TRUSTED rule is firing on much of the spam coming in to my
server. This has a -3.3 score assigned by default.
Here's an example set of headers (including the spamassassin report) for
a spam message:
Return-path: <[EMAIL PROTECTED]>
Package: logcheck
Version: 1.2.32
Severity: wishlist
/etc/cron.daily/sysklogd restarts syslogd at the end of the script.
This causes a daily log message, currently missed by logcheck:
Jan 14 06:55:22 pyloric syslogd 1.4.1#16: restart (remote reception).
I'm currently using this regex in ignore.s
Marc Haber wrote:
No, the feature is there for a reason. You can always edit
/etc/exim4/update-exim4.conf.conf. What is not there is the
debconf-based configuration possibility, but that's only gold plating
anyway.
I've got to disagree with you pretty strongly on this one. The conf
files (partial
Marc Haber wrote:
Sarge's debconf templates have a string freeze, so we cannot add
another question without invalidating all translations.
The debconf question will be added once 4.43 or later is in unstable,
which won't happen before t-p-u and testing-security work.
That's what I thought. You sho
Package: exim4-config
Version: 4.34-10
Severity: normal
The recent upgrade to 4.34-10 changed the value of the LOCAL_DELIVERY
variable to DEBCONFlocaldeliveryDEBCONF. However, that variable doesn't
seem to be defined, and debconf never asked me what to set it to. Is
the debconf question missing
Package: sensord
Version: 1:2.9.0-4
Severity: minor
The latests upstream release includes part of your patch for 244037, to
remove the x10 scaling on the recorded loadavg.
This should be noted in the changelog and/or debian.news, so that users
know they need to fix their CGI script to report the
82 matches
Mail list logo
