Bug#738101: RFS: awstats/7.3+dfsg-1
On Sat, Feb 8, 2014 at 2:39 PM, Paul Wise wrote: > I'll ask for the lintian text to be clarified but there is no reason > not to do the changes properly now, before the clarification > is added to lintian. I hope, that's fixed in: http://anonscm.debian.org/gitweb/?p=collab-maint/awstats.git;a=commit;h=9c8f27ceb7f9490387a32b9fb2f45b21f69f853d >> Why? It's clearly stated in the lintian docs: >> http://lintian.debian.org/tags/privacy-breach-facebook.html >> -->8-- >> Please remove these scripts or frames. >> -->8-- > > I believe doing so goes against the Social Contract since you are > removing upstream's promotion of their project, which is an important > part of their success. Could you kindly provide a more detailed *technical* suggestion in this case (facebook patch)? > > Ok, I can remove this as well, when lintian could point to this. > > Again, there is no need to wait until lintian is updated before fixing > issues. lintian is just a tool to point you at potential problems (and > there are a lot of other such tools), you should use human judgement > and imagination to determine the right thing to do It's not reasonable to believe, that every maintainer would read all provided in the package *.html files in a regular way to find and fix such problems. Without automation - it's just a waste of time. btw, I think google/twitter problems are gone in the last upload: http://anonscm.debian.org/gitweb/?p=collab-maint/awstats.git;a=blob;f=debian/patches/2007_googleplus.patch http://anonscm.debian.org/gitweb/?p=collab-maint/awstats.git;a=blob;f=debian/patches/2008_twitter.patch https://mentors.debian.net/package/awstats was updated. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739530: systemd support for monit
Hello, On Thu, Feb 20, 2014 at 12:06 AM, Christian Dröge wrote: > Am 19.02.2014 20:50, schrieb Sergey B Kirpichev: > >> The dh_installinit line was dropped in this patch, because it is not > >> needed anymore > > Explain this, please. > update-rc.d does not support the start and stop actions anymore (see > below in the error message). Ok, removed. Thank you. Regarding other stuff in the patch, does it work for hurd/kfreebsd? E.g. doesn't break builds, installation and so on. Is this patch was tested, if so - how? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738101: RFS: awstats/7.3+dfsg-1
Package: sponsorship-requests Severity: normal Hello, I'm looking for a sponsor for my package "awstats": http://mentors.debian.net/package/awstats http://mentors.debian.net/debian/pool/main/a/awstats/awstats_7.3+dfsg-1.dsc I'm dm, but I don't have upload permissions for this package in the "new interface" [1] changelog: * Remove donation link in index.html (fix lintian E: privacy-breach-donation) in favor of debian/upstream * Bump up Standards-Version (to 3.9.5) * Install prerotate script (Closes: #714231) * Imported Upstream version 7.3+dfsg * Refresh patches * Add/cleanup Forwarded: patch headers * Fix permissions * Removed Facebook's Share/Like buttons (fix lintian E:privacy-breach-facebook) On Sat, Dec 28, 2013 at 7:20 PM, Willi Mann wrote: > Hello Sergey, Hello Niels, > > I'd be willing to look at awstats 7.2~dfsg-1 and upload it if it looks > OK to me. Is there a packaging-related reason why Niels did not upload > it for you so far? > > Bye > Willi > -- [1] http://ftp-master.debian.org/dm.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729354: RFS: auto-07p/0.9.1+dfsg-1 [ITP] -- software for continuation and bifurcation problems in ODE
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "auto-07p" Package name: auto-07p Version : 0.9.1+dfsg-1 Upstream Author: Eusebius Doedel URL: http://indy.cs.concordia.ca/auto/ License : BSD Section : math ITP-bug: http://bugs.debian.org/512916 To access further information about this package, please visit the following URL: http://mentors.debian.net/package/auto-07p Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/auto-07p/auto-07p_0.9.1+dfsg-1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556610: Bug#677504: lintian fixes
On Tue, Jun 19, 2012 at 03:13:32PM +0400, Michael Tokarev wrote: > >Would be nice, if you take look on #556610 too. > > Yes, but this one is a feature/enhancement. I'm not sure we ever want to > go this route -- the result smells too complicated. What exactly? Every day we run 1/X'th part of job (by default, X=28) for 1 hour. That should be enough for arrays upto 10Tb out of box. And, of course, it' adjustable by local admin. The whole set of arrays would be checked fully every month in average, on a regular basis. There is a trouble, mentioned in #556610, when arrays are sharing common devices. > Well, the sizes of the > typical arrays are increasing, and hence the time required to complete the > checks, so it becomes more and more important, so we have to do something > with that. Yep. And that is why #556610 looks as an important whishlist item. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675452: Bug#677504: lintian fixes
>>> #675452 ... So, if you do have some >>> >>> time and are willing to help, that's where to look at :) >> >> Comment was added. > > Yes, I've seen these. But at this point before wheezy release I don't want > to enable asyncronous array processing like this. Â Once we enable that in > in the initramfs, we have to enable it in regular userspace too, so that > other parts of arrays will be processed later. Â This has to be supported > from initramfs to regular userspace and whole thing has to be switched to > asyncronous processing, which needs quite good testing in various usage > scenarios out there. Probably, Martin has some knowledge about asynchronous array processing and why this branch was abandoned time ago. > For now, the most appropriate course of actions, I think, is to run udevadm > settle before mdadm --assemble and, if after --assemble, the root device > is not there still, sleep a few seconds and repeat WHOLE series of scripts > in initramfs again, up to a configured amount of times. Â This should already > work for cryptoloop which should not ask for a password again if the device > is already configured, and this should work for lvm on top of md raid too, > with lvm not being asyncronous like md is. Looks complex. As a dirty fix, you can introduce a configurable option (default: off) to set a delay before --assemble. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677504: lintian fixes
On Fri, Jun 22, 2012 at 12:21 PM, Michael Tokarev wrote: > The upstream patch introduced by this change should be submitted, > naturally, upstream. Â Sergey, care to submit it to Neil as > appropriate, or should I do that myself? Whoole changeset looks very minor. Probably, you can submit one someday. > Also, this patch lacks DEP-3 headers. Attached. >From 575660ceb6fe827bf1ef6635f5c7cb2485e6e6ea Mon Sep 17 00:00:00 2001 From: Sergey B Kirpichev Date: Fri, 29 Jun 2012 14:26:59 +0400 Subject: [PATCH] Add DEP3 headers to spelling-and-manpages.patch --- debian/patches/spelling-and-manpages.patch |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/debian/patches/spelling-and-manpages.patch b/debian/patches/spelling-and-manpages.patch index 0d89bb8..2bc9945 100644 --- a/debian/patches/spelling-and-manpages.patch +++ b/debian/patches/spelling-and-manpages.patch @@ -1,3 +1,7 @@ +Description: Fix spelling and manpage formatting issues +Author: Sergey B Kirpichev +Forwarded: no + --- Build.c |2 +- md.4 |2 +- -- 1.7.2.5
Bug#683984: libapache2-mod-rpaf: potential Denial of Service
tag 683984 +pending
thanks
06.08.2012 4:27 пользователь "Luciano Bello" написал:
> Sébastien Bocahu reported to the security team:
> > (...)
> > A single request makes Apache segfault. On some of the environments I
> tested,
> > it even kills all Apache processes (they become zombies).
Thank you for bugreport.
> > The magick request is the following:
> > curl -H "x-forwarded-for: 1'\"5000" -H "Host: a.vhost.example.com"
> > reverseproxy
> >
> > Apache processes will segfault, hence a potential DOS issue.
This works for very typical setups. Bad news. And it looks as a ("potential",
yeh) remote hole.
> > From my experiments, version 0.6 fixes the issue (IPv6 patched or
> unpatched).
Yep. Tag this as fixed for 0.6+ debian packages.
> Please, prepare a minimal patch for stable
The "minimal" patch is to drop 030_ipv6.patch. I can't confirm that
this bug is *not* reproducible for 0.6 version *with* the above patch.
Can you ask bugreporter to report details on:
-->8--
rpaf 0.6 is available in Debian wheezy. The IPv6 patched is not applied
though. I patched myself and tested it on the
same squeeze environment: there is no more segfaults.
-->8--
?
Unmodified 030_ipv6.patch still produce segfaults on 0.6+, for me.
> and contact the security team to
> update the package.
Reply to contacts of this bugreport is ok, or I should do anything else?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683984: libapache2-mod-rpaf: potential Denial of Service
On Mon, Aug 6, 2012 at 4:23 AM, Luciano Bello wrote:
> Sébastien Bocahu reported to the security team:
>> patch that was applied by Debian exposes Apache to segfaults under specific
>> crafted requests.
>>
>> The magick request is the following:
>> curl -H "x-forwarded-for: 1'\"5000" -H "Host: a.vhost.example.com"
>> reverseproxy
>>
>> Apache processes will segfault, hence a potential DOS issue.
>
> Please, prepare a minimal patch for stable and contact the security team to
> update the package.
Attached updated 030_ipv6.patch.
PS: Updated package (maintainer info was changed too):
http://mentors.debian.net/debian/pool/main/liba/libapache2-mod-rpaf/libapache2-mod-rpaf_0.5-3+squeeze1.dsc
diff -ru mod_rpaf-0.5/mod_rpaf-2.0.c mod_rpaf-0.5.new/mod_rpaf-2.0.c
--- mod_rpaf-0.5/mod_rpaf-2.0.c 2007-10-30 14:36:51.0 +0100
+++ mod_rpaf-0.5.new/mod_rpaf-2.0.c 2007-10-30 14:37:47.0 +0100
@@ -72,6 +72,8 @@
#include "http_vhost.h"
#include "apr_strings.h"
+#include
+
module AP_MODULE_DECLARE_DATA rpaf_module;
typedef struct {
@@ -168,6 +170,10 @@
ap_register_cleanup(r->pool, (void *)r, rpaf_cleanup, ap_null_cleanup);
r->connection->remote_ip = apr_pstrdup(r->connection->pool, last_not_in_array(arr, cfg->proxy_ips));
r->connection->remote_addr->sa.sin.sin_addr.s_addr = inet_addr(r->connection->remote_ip);
+apr_sockaddr_t *tmpsa;
+int ret = apr_sockaddr_info_get(&tmpsa, r->connection->remote_ip, APR_UNSPEC, r->connection->remote_addr->port, 0, r->connection->remote_addr->pool);
+if (ret == APR_SUCCESS)
+memcpy(r->connection->remote_addr, tmpsa, sizeof(apr_sockaddr_t));
if (cfg->sethostname) {
const char *hostvalue;
if (hostvalue = apr_table_get(r->headers_in, "X-Forwarded-Host")) {
signature.asc
Description: Digital signature
Bug#724598: php5-memcached: Does not build with libmemcached >= 1.0.9
forwarded 724598 https://github.com/php-memcached-dev/php-memcached/pull/80 thanks On Wed, Sep 25, 2013 at 7:47 PM, Michael Fladischer wrote: > due to an API break in libmemcached 1.0.9 php-memcached does no longer > build: > > /tmp/buildd/php-memcached-2.1.0/memcached-2.1.0/php_memcached.c:318:82: > error: unknown type name 'memcached_server_instance_st' > [...] > > Upstream has already a bugreport for this: > https://github.com/php-memcached-dev/php-memcached/pull/80 > > There is already a package for libmemcached-1.0.17-1 in experimental. To > ease the transition into unstable I've attached a patch to fix those errors. Hmm. Now I'm a bit more sceptical about this patch. See this: https://bugs.launchpad.net/libmemcached/+bug/1190240 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692628: non-free files in upstream tarball ("The Software shall be used for Good, not Evil")
tags 692628 +upstream +pending thanks On Thu, Nov 8, 2012 at 2:16 AM, Ansgar Burchardt wrote: > The upstream tarball contains files under the non-free JSON license: > > % rgrep -l 'The Software shall be used for Good, not Evil.' . > ./src/lib/json/JSON_parser.C Fix is available in the upstream cvs: http://cvsview.parser.ru/cgi/viewcvs.cgi/parser3/src/lib/json/ This will be part of upcoming 3.4.3 release (in ~2 weeks). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724598: php5-memcached: Does not build with libmemcached >= 1.0.9
tag 724598 +pending +upstream thanks 25.09.2013 19:51 пользователь "Michael Fladischer" написал: > Upstream has already a bugreport for this: > https://github.com/php-memcached-dev/php-memcached/pull/80 > > There is already a package for libmemcached-1.0.17-1 in experimental. To > ease the transition into unstable I've attached a patch to fix those errors. I'll do upload ASAP (probably, on next week). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629896: segfault while simply get()ing a value from squeeze memcached
On Wed, Feb 29, 2012 at 5:32 AM, David Kirchner wrote: > I'm not sure if this is related, but I found a similar problem. We've > also extended the memcached class with wrappers. We're getting > segfaults after the get call in some cases, double-frees and aborts in > other cases. However, the problem does not appear to be triggered by > the get call itself. Additionally, it occurs outside of the web > environment, suggesting Apache may not be involved at all. > > ... > And the first thing that function does is sends "quit" to the memcache > server. This has been fixed upstream btw, with a note: > > https://github.com/php-memcached-dev/php-memcached/blob/master/php_memcached.c Looks like you refer to php-memcached extension. Remember, it's complitely unrelated to php-memcache, mentioned in *this* bug#629896. Except for similar name, yeah. > Would it be possible for this to be used as a patch in an update for > squeeze's version of php-memcached-1.0.2? May be. Please, open bug on that package instead. Keep in mind that uploads to stable is for *really* important problems. See e.g.: http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556610: Please do incremental checks every night instead of a full monthly one
tag 556610 +patch
thanks
Just a more simple version of the
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=32;filename=checkarray.diff;att=2;bug=556610
Rough idea is to
1) setup crontab on a regular basis, e.g. weekly:
-->8---
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] &&
/usr/share/mdadm/checkarray --cron --all --quiet
57 6 * * 0 root [ -x /usr/share/mdadm/checkarray ] &&
/usr/share/mdadm/checkarray --cron --all --quiet --cancel
->8---
2) Save sync_completed info to sync_min on --cancel:
--->8-
--- /usr/share/mdadm/checkarray 2011-12-06 04:41:09.0 +0400
+++ ./checkarray2011-12-06 18:45:41.0 +0400
@@ -165,8 +165,10 @@
case "$action" in
idle)
+ completed=$(awk -F/ '{ if ($1 == "none") {print 0} else {print $1}}'
/sys/block/$array/md/sync_completed)
echo $action > $SYNC_ACTION_CTL
[ $quiet -lt 1 ] && echo "$PROGNAME: I: cancel request queued for array
$array." >&2
+ echo $completed > /sys/block/$array/md/sync_min
;;
check)
->8
Of course, it's easy to dump sync_completed state in
temporary files somewhere in /var/lib/mdadm/ to survive
on reboot. I'm not sure if that is a good idea at all...
--- /usr/share/mdadm/checkarray 2011-12-06 04:41:09.0 +0400
+++ ./checkarray 2011-12-06 18:45:41.0 +0400
@@ -165,8 +165,10 @@
case "$action" in
idle)
+ completed=$(awk -F/ '{ if ($1 == "none") {print 0} else {print $1}}' /sys/block/$array/md/sync_completed)
echo $action > $SYNC_ACTION_CTL
[ $quiet -lt 1 ] && echo "$PROGNAME: I: cancel request queued for array $array." >&2
+ echo $completed > /sys/block/$array/md/sync_min
;;
check)
#!/bin/sh
#
# checkarray -- initiates a check run of an MD array's redundancy information.
#
# Copyright © martin f. krafft
# distributed under the terms of the Artistic Licence 2.0
#
set -eu
PROGNAME=${0##*/}
about()
{
echo "$PROGNAME -- MD array (RAID) redundancy checker tool"
echo "Copyright © martin f. krafft "
echo "Released under the terms of the Artistic Licence 2.0"
}
usage()
{
about
echo
echo "Usage: $PROGNAME [options] [arrays]"
echo
echo "Valid options are:"
cat <<-_eof | column -s\& -t
-a|--all & check all assembled arrays (check /proc/mdstat).
-s|--status & print redundancy check status of devices.
-x|--cancel & queue a request to cancel a running redundancy check.
-i|--idle & perform check in a lowest I/O scheduling class (idle).
-l|--slow & perform check in a lower-than-standard I/O scheduling class.
-f|--fast & perform check in higher-than-standard I/O scheduling class.
--realtime & perform check in real-time I/O scheduling class
(DANGEROUS!).
-c|--cron & honour AUTOCHECK setting in /etc/default/mdadm.
-q|--quiet & suppress informational messages.
-Q|--real-quiet & suppress all output messages, including warnings and
errors.
-h|--help & show this output.
-V|--version & show version information.
_eof
echo
echo "Examples:"
echo " $PROGNAME --all --idle"
echo " $PROGNAME --quiet /dev/md[123]"
echo " $PROGNAME -sa"
echo " $PROGNAME -x --all"
echo
echo "Devices can be specified in almost any format. The following are"
echo "all equivalent:"
echo " /dev/md0, md0, /dev/md/0, /sys/block/md0"
echo
echo "The --all option overrides all arrays passed to the script."
echo
echo "You can also control the status of a check with /proc/mdstat ."
}
SHORTOPTS=achVqQsxilf
LONGOPTS=all,cron,help,version,quiet,real-quiet,status,cancel,idle,slow,fast,realtime
eval set -- $(getopt -o $SHORTOPTS -l $LONGOPTS -n $PROGNAME -- "$@")
arrays=''
cron=0
all=0
quiet=0
status=0
action=check
ionice=
for opt in $@; do
case "$opt" in
-a|--all) all=1;;
-s|--status) action=status;;
-x|--cancel) action=idle;;
-i|--idle) ionice=idle;;
-l|--slow) ionice=low;;
-f|--fast) ionice=high;;
--realtime) ionice=realtime;;
-c|--cron) cron=1;;
-q|--quiet) quiet=1;;
-Q|--real-quiet) quiet=2;;
-h|--help) usage; exit 0;;
-V|--version) about; exit 0;;
/dev/md/*|md/*) arrays="${arrays:+$arrays }md${opt#*md/}";;
/dev/md*|md*) arrays="${arrays:+$arrays }${opt#/dev/}";;
/sys/block/md*) arrays="${arrays:+$arrays }${opt#/sys/block/}";;
--) :;;
*) echo "$PROGNAME: E: invalid option: $opt" >&2; usage >&2; exit 0;;
esac
done
is_true()
{
case "${1:-}" in
[Yy]es|[Yy]|1|[Tt]rue|[Tt]) return 0;;
*) return 1;
esac
}
DEBIANCONFIG=/etc/default/mdadm
[ -r $DEBIANCONFIG ] && . $DEBIANCONFIG
if [ $cron = 1 ] && ! is_true ${AUTOCHECK:-false}; then
[ $quiet -lt 1 ] && echo "$PROGNAME: I: disabled in $DEBIANCONFIG ." >&2
exit 0
fi
if [ ! -f /proc/mdstat ]; then
[ $quiet -lt 2 ] && echo "$PROGNAME: E: MD subsystem not loaded, or /proc
unavailable." >&2
exit 2
Bug#599821: mdadm: mismatch_cnt is not well checked or reported
Hello,
As a variant to fix this issue, please consider using
attached patch. Hope, it's simple enough to be
accepted upstream.
On nonzero mismatch_cnt it makes log entry like this:
-->8---
Dec 6 22:52:42 squeeze mdadm[2376]: RebuildFinished event detected on md
device /dev/md0, component device mismatches found: 128 (on raid level 1)
>8--
Thus, you can filter this out in logcheck rules _only_ for raid1/raid10:
->8
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ mdadm(\[[[:digit:]]+\])?:
Rebuild((Start|Finish)ed|[[:digit:]]+) event detected on md device
/dev/[-_./[:alnum:]]+, component device mismatches found: [0-9]+ \(on raid
level (1|10)\)$
>8---
This patch also can be useful for #588516.
report-level-on-rebuildfinished.diff
Description: Binary data
Bug#629896: segfault while simply get()ing a value from squeeze memcached
tag 629896 +confirmed severity 629896 important thanks I'll lower down the severity of this bugreport. Clearly, this issue does not makes the package "unusable or mostly so". Even for heavy-loaded websites (mass virtual hosting, actually) there exists an alternative: using fcgi. Please, explain if you disagree. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629896: segfault while simply get()ing a value from squeeze memcached
forwarded 629896 https://bugs.php.net/bug.php?id=59876 thanks On Fri, Jun 8, 2012 at 7:20 PM, Tim Baldoni wrote: > The source file "memcache_pool.c" contains FD_CLR, Â FD_ISSET, FD_SET, > and FD_ZERO. Yep. It uses select, we know. And what? > I strongly disagree that fcgi is a valid workaround to this bug. Why? Please, explain. An another workaround: reduce number of open fd's. Somtimes, it's just a crazy setup of an average "Hosting Control Panel", which uses "own access.log per every VirtualHost" paradigm. Or use php-memcached extension (different api). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590074: prerotate or postrotate?
On Mon, May 21, 2012 at 7:54 PM, Daniel Pocock wrote: > b) data is likely to be missed if it is logged between the time > update.sh finishes and the rotation of a file for any particular vhost > > Why does the README insist on prerotate and not use postrotate? Probably, because it's easy. > I've discovered that after rotation, logrotate can give the rotated > filename to the postrotate script, and using nosharedscripts, logrotate > can call awstats multiple times, once for each vhost, just as it > finishes the rotation of that host I'm not sure if reloading Apache per every vhost is a good idea. Why this can't be done once? > All that is needed is some wrapper script around awstats to select the > correct domain based on the path in $1 and pass the -config option to > awstats too > > Does this address all the issues raised by contributors to this bug report? Partially. See above: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590074#70 On Tue, May 22, 2012 at 12:52 AM, Daniel Pocock wrote: > I've contributed a script for fixing this, it is commit c0482b4109176e05 > on master > > It is based on Sergey's update.sh, but it does each log file separately > just after rotation For next release I've reverted the above commits. I don't like idea of code duplication. Can you consider to add needed code to update.sh? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556610:
On Mon, Apr 16, 2012 at 4:16 PM, wrote: > According to the proposed patch I had a thought and 4 proposals to also cover > the case of systems that are not powered on for 24 hours 7 days a week. > (i.e. power saving policy in place) Looks good, let's see. > 0) Because checking an array is such a long operation, it may be desirable for > checkarray to distinguish --reset and --interrupt options instead of an > amobiguous --cancel, and be able to --resume any previously started check. Added to the new patchset (coming soon). --resume option looks redundant, for now: default action (check) will resume previously started check or start the new one. > Overall, the kernel should correctly stop an attempt for an automatic check > while a > manual check is running. If a manual check is interrupted manually or by > shutting > down, it may be continued manually or by the next automatic check, if > enabled. However, interrupting a an automatic check should not interrupt > manual > checks. The easiest would be to just skip automatic checks if checks > are already running. Let's see. Right now, this (start/stop/interrupt) can be done via kernel interfaces in /sys/block/mdX/md/ by sysadmin... Thus, there is no chance to easy distinguish "manual" and "automatic" checks. It's a good reason to implement things as simple, as possible. > 1) If writing the sync_completed value to sync_min upon --interrupt does > not survive a reboot, checkarray would definitely have to save the value > separately. Otherwise, all it would ever check is always the same small part > at the beginning of the array. ... Just as it do now. And this save/restore can (optionally!) do /etc/init.d/mdadm. Why checkarray? > (Thus, yes, Sergey I'd say it may be a good idea to let --interrupt "dump" > e.g. > "mdX-next_checkarray_block" state files under /var/lib/mdadm/ for all checks > that are still running, and delete any others files to ensure they start > fresh next time. > The --reset option may just delete all state files.) For now, we can save this dump as an option (default: off). But this ugly "database" (and "autocheck-running" file too) shouldn't be introduced "at all cost" in checkarray. It looks as a job for /etc/init.d/mdadm, see above. > 2) Cronjobs defined in /etc/cron.d are never run if the machine is off during > the scheduled times (i.e. currently checkarray is never run). However, this > should be an easy thing to fix, because anacron is in installed by default: Why local admin can't just change cronjobs shedule? > Simply, drop /etc/cron.d/mdadm from the package, and modify the > /etc/cron.daily/mdadm script to run checkarray --cron --idle --all --quiet. Just start array check is NOT enough (with incremental checks). You should also stop it. > If the machine is running 24h, by default cron will run anacron at 07:30 > in the morning (a time the admin may ensure is before office hours). Anacron > then > takes care of cron.daily. If the machine starts up earlier, it cron.daily > runs earlier. > Just letting the machine boot early enough ensures cron.daily tasks are done > in time. > If anacron is uninstalled cron will run cron.daily at 06:25. > > Limiting the time for performing array checks, in addition to using > the --idle switch may be realized by adapting the following: > > 3) Instead of defining a separate cron job that calls checkarray --cancel > later > (which may never happen if machine is shutdown and is not possible using > cron.daily), let checkarray --cron touch say /var/lib/mdadm/autocheck-running > file > and start the checks, if there are currently no (manual) checks running. > Then sleep say for an AUTOCHECK_TIMESLICE duration defined in > /etc/default/mdadm. After the sleep, if the autocheck-running file is still > there, > remove the file and proceed with the --interrupt action for, otherwise exit. 1) Array check will be stopped anyway on shutdown. We just should figure out if we would like to save/restore sync_min/sync_max on shutdown/reboot. 2) It's not a good idea to reinvent cron, IMHO. But we can instead restrict by sync_max the interval of daily checks (my new patch). So, /etc/cron.daily/mdadm will just cancel the previous check and then run the new one. 3) anyway, a real patch from you can tell us much more then a long specification, right? ;) > 4) /etc/init.d/mdadm should call checkarray --interrupt to trigger proper > saving of all states in case the machine is shut down before an > AUTOCHECK_TIMESLICE has ended. Thus, /etc/init.d/mdadm can handle almost all "black magics" stuff for save and restore (default: not do so!) of sync_min/sync_max. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677504: lintian fixes
On Fri, Jun 15, 2012 at 12:47 AM, Michael Tokarev wrote: > I'll try to review this stuff while being in a sea beach, > maybe will commit something. Would be nice, if you take look on #556610 too. > But to me, much more important issue is the timing issue we have > in initramfs. Â Namely, there are a few known valid setups which > does not work with mdadm currently. Â #675452 ... So, if you do have some > time and are willing to help, that's where to look at :) Comment was added. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#807159: monit: please make the build reproducible
Thanks, fixed in the repo. Do you think this issue severe enough to do upload? On Thu, Dec 10, 2015 at 3:08 PM, Chris Lamb wrote: > Hi, > >> monit: please make the build reproducible > > Fixed upstream with > https://bitbucket.org/tildeslash/monit/commits/050810408124#Lconfigure.acT46
Bug#787400: monit: Cannot initialize SSL server certificate handler
Hello, On Mon, Jun 8, 2015 at 12:45 PM, Martin Pala wrote: > Actually the original behaviour was bug - the name used in the “check system” > was always intended to be visible in M/Monit, snip from Monit 5.9 manual (see > the last sentence in the snip): > > —8<— > =item 7. CHECK SYSTEM > > The system name is usually hostname, but any descriptive name can be > used. You can use the variable $HOST as the name, which will expand to > the hostname. This test allows one to check general system resources > such as CPU usage (percent of time spent in user, system and wait), > total memory usage or load average. The unique name is used as the > system hostname in mail alerts and when M/Monit is configured, then > also as initial name of the host entry in M/Monit. > —8<— > > Monit 5.13 fixes the problem - the “localhost” name is configuration issue … > “$HOST” should be used if the real hostname is needed instead of custom name. Ok. If Jens confirm it's the case with his configuration, I guess I can close this issue. > I’m sorry about the bug thread … i wanted to post the data to it and used > “reply-all” to the original message, which automatically includes > “787400-qu...@bugs.debian.org” - i guess the “-quiet” postfix makes the > message invisible in the thread, changing it to “787...@bugs.debian.org” > instead. Nothing wrong with you. With -quiet - message appears in the bts, but not posted to all bug subscribers. For more info about bug manipulations by email, see e.g.: https://www.debian.org/Bugs/Developer#followup https://www.debian.org/Bugs/server-control -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706076: Bug#626185: awstats can't handle bad request log entries
On Sun, Jan 18, 2015 at 07:08:42AM +0100, Volker Grabsch wrote: > Okay, so these are the exact steps how to reproduce this, using a > QEMU/KVM virtual machine running the latest Debian/Stable. > ... > B.3. Install Apache, using just he default configuration Ok, now I got it. It was too hard to specify which configuration you use or should I guess? You can see that you have a plenty variants to workaround this. Use NbOfLinesForCorruptedLog in awstats or adopt your apache log configuration to hide such messages. Thus, I'm not sure it's a bug. Lets see what upstream think off. BTW, I tried this on Jessie first, and I got BadRequest, not 501: ::1 - - [18/Jan/2015:14:43:27 +0300] "\x16\x03" 400 0 "-" "-" or (not listen on v6): 127.0.0.1 - - [18/Jan/2015:15:56:23 +0300] "\x16\x03" 400 0 "-" "-" PS: Please remember, we are talking about #706076, so please stop posting this to unrelated bugreports. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759840: parser: FTBFS: string3.h:51: undefined reference to `_pcre_default_tables'
Closed as a duplicate of #755346 On Sat, Aug 30, 2014 at 11:02 PM, Lucas Nussbaum wrote: > Source: parser > Version: 3.4.3-3 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20140830 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): >> g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I../../classes -I../../types >> -I../../lib/gc/include -I../../lib/cord/include -I/usr/include/libxml2 >> -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat >> -Werror=format-security -c -o parser3.o parser3.C >> /bin/bash ../../../libtool --preserve-dup-deps --mode=link --tag=CXX g++ -g >> -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro >> -o parser3 pa_threads.o parser3.o ../../main/.libs/libmain.a >> ../../classes/.libs/libclasses.a ../../types/.libs/libtypes.a >> ../../main/.libs/libmain.a ../../lib/gd/libgd.la ../../lib/cord/libcord.la >> ../../lib/md5/libmd5.la ../../lib/sdbm/libsdbm.la ../../lib/smtp/libsmtp.la >> ../../lib/json/libjson.la ../../lib/memcached/libmemcached.la -lltdl -lgc >> -lpcre -lxml2 -lxslt -lexslt -lcrypt -lm -ldl >> libtool: link: g++ -g -O2 -fstack-protector-strong -Wformat >> -Werror=format-security -Wl,-z -Wl,relro -o parser3 pa_threads.o parser3.o >> ../../main/.libs/libmain.a ../../classes/.libs/libclasses.a >> ../../types/.libs/libtypes.a ../../main/.libs/libmain.a >> ../../lib/gd/.libs/libgd.a ../../lib/cord/.libs/libcord.a >> ../../lib/md5/.libs/libmd5.a ../../lib/sdbm/.libs/libsdbm.a >> ../../lib/smtp/.libs/libsmtp.a ../../lib/json/.libs/libjson.a >> ../../lib/memcached/.libs/libmemcached.a >> /usr/lib/x86_64-linux-gnu/libltdl.so -lgc -lpcre -lxml2 -lxslt -lexslt >> -lcrypt -lm -ldl >> ../../main/.libs/libmain.a(pa_charset.o): In function `memcpy': >> /usr/include/x86_64-linux-gnu/bits/string3.h:51: undefined reference to >> `_pcre_default_tables' >> ../../main/.libs/libmain.a(pa_charset.o): In function `fixUTF8(char const*)': >> /«PKGBUILDDIR»/src/main/pa_charset.C:1298: undefined reference to >> `_pcre_valid_utf' >> /«PKGBUILDDIR»/src/main/pa_charset.C:1318: undefined reference to >> `_pcre_valid_utf' >> collect2: error: ld returned 1 exit status > > The full build log is available from: > > http://aws-logs.debian.net/ftbfs-logs/2014/08/30/parser_3.4.3-3_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. The build > was done with DEB_BUILD_OPTIONS="parallel=4", so if your packaging tries > to support this, it might be a good idea to explore whether this might > be the cause of the failure. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752540: php-geoip license issues
reopen 752540 severity 752540 important thanks Hello, Time ago I asked upstream to change the license to 3.01 due to DD's requirement (see forwarded message). Do you suggest me to do this again? #752532 was closed with resolution: "If someone feels like they should be re-opened, please restart the discussion *first* and seek for a consensus." This lintian tag is a problem of same severity (lintian error=reject in NEW). So please revert this check and do first as suggested. -- Forwarded message -- From: Sergey B Kirpichev Date: Fri, May 30, 2008 at 11:09 AM Subject: Re: php-geoip license issues To: Olivier Hill > Where do you see PHP 2.02? I've looked in the source code, and it > seems to always refer to PHP 3.0 license. And more... Debian people says, that exactly 3.0 is not appropriate: "It needs to be 3.01" (c) http://lists.debian.org/debian-mentors/2008/05/msg00560.html The thread: http://lists.debian.org/debian-mentors/2008/05/msg00403.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#845417: Cannot activate service check. The process status engine was disabled.
On Wed, Nov 23, 2016 at 10:50 AM, Martin Sebald wrote: > I'm experiencing a bug in jessie-backports monit version 5.18-1~bpo8+1: > > /etc/monit/conf.d/memcached:8: Cannot activate service check. The process > status engine was disabled. > > It looks like this bug: > > https://bitbucket.org/tildeslash/monit/issues/379/error-in-monit-518-cannot-activate-service > > It also seems that the bug was already fixed in newer versions. Here is new version for jessie: https://mentors.debian.net/debian/pool/main/m/monit/monit_5.20.0-3~bpo8+1.dsc Can you test if it has your bug?
Bug#839804: monit: errors every 2 minutes in the log file: "Queued event file: unable to read event size -- end of file"
tag 839804 +moreinfo thanks Hello, On Wed, Oct 5, 2016 at 12:09 PM, Vincent Lefevre wrote: > [CEST Sep 19 19:10:11] info : Adding event to the queue file > /var/lib/monit/events/1474305011_1bbbd00 for later delivery > [CEST Sep 19 19:12:11] error: Queued event file: unable to read event > size -- end of file > [...] > > At reload, everything is fine. Then one gets some errors during a reboot > as Monit cannot connect to the mailserver at this time, which is normal > since the mail server has been stopped before Monit. This is not a > problem, as I will receive the mail after the reboot. The problem is > the "Queued event file: unable to read event size -- end of file" errors > every 2 minutes after the reboot, which fill my log file. Can you check permissions on events dir & file? If possible, please check new sid's version. > the mail server has been stopped before Monit This shouldn't be. Monit must be stopped first by init script (and started last, by the way). That's - package default.
Bug#614631: debian-maintainers: Please add Sergey B Kirpichev as a Debian Maintainer
Package: debian-maintainers Severity: normal Please add my key as described in the attached jetring changeset to the Debian Maintainer keyring. Comment: Add Sergey B Kirpichev as a Debian Maintainer Date: Tue, 22 Feb 2011 03:10:30 +0300 Recommended-By: Raphael Hertzog Agreement: http://lists.debian.org/debian-newmaint/2011/02/msg00029.html Advocates: http://lists.debian.org/debian-newmaint/2011/02/msg00031.html Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.10 (GNU/Linux) mQINBE09qhEBEACf22S9GhCeV5mL1JfbpRVaIqAB0DQqZBKAoDB9j9/W56Dz6ZNG XSZ5/0qzwfEKnwaUIf+mQIpU7DPoWY199SQDpjUY9+31RRbv55y0EJUbL3LCmsYK J9jGSTfakZOozMeAeakVL0HBM/u1bp9UP0lHcswAZrpkVuU6xT9Ml2v2rNhShjiJ RdLB8M6Yu3CDFmck4t1QRiKTbBHYy6X8ynKCWbgBYtMDdusDsNnlxMVbemR6nqEd KAQyoP7mFqorQ4uh7MrDZSot3o2MRfY8ne055FNi8j54hUu9tzKEqxQqjK4z4dv3 kqRkumHgoIXcBtK1uSW0hrqpPHUJd3BzNfkISjsR/apCuPKYUMtOh/BT/jMh9pz4 NMsrZg/ihq5VdBJvaQ+j1KpwzY279XA9kOnOSpq2YK6yZ8sJWEdUZ4Ww3YLeC3Bf mPoAu8kWDPfu2NVM6Jynes3P84oqRb5OTDMFDvMIMdxdJXNaxocm4fuN6wVrTJpE aekEVSCrhoA1SckVhsEcFNWTeeS6R5aixtl2FmTWo6XIIyjzRTEh0GVxU43yTd4b 3EPqdKJUfXRDVyHxt1z4OdM0szoFbXHg801PlD/0ceMVB4tT5S2oGC+vCiGk6xhh igD5H7rTZnRLtoCtz7VIGkbgF3mHRmbkxTKXF7aqQ/hPsTaK6V2R8JiyiwARAQAB tClTZXJnZXkgQiBLaXJwaWNoZXYgPHNraXJwaWNoZXZAZ21haWwuY29tPokCNwQT AQgAIQUCTT2qEQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRA5yaC2QCYq 8FOgD/9fCdyqPHRj9UnMUmWx1w9TxVtsPrVx9v1Jyf0RSY5R0xwMWqLyu/eRiPzN NZCAYmlfSoFHL481n1+hVoVX+K1emEVmJNAg/uV1JfVdi/tE0YuYlzubmh8drZGs TfDBTpi50fqm52LJbmjubqJWYPWND1jR51D9R+L5QGMovqhzSJO7Jo0WhrvQkyic v6/7r9xTooETj9cIlKdmP8bKaNeOO/EHxZPVqMqYW845+NLvqlHZg4FBmn51CAiv u0BjH0rubObuUqixeKBr7XhYx46gJa4LedTnhzxc66RI7Ry8Mp+QVR2B5ygerVJ+ y0g3PR4lJRXwbFlsceRZ8s7miB4aCbAtPBjVotwpJ3gep+SI8jzGKy26NykRs5Am 4nL8iHzXtGn/307Ymn7ekMtZJzDadNJTZGzhoK0AyjjlQD2CpATlAUOu2Ov+iqeb apE4Ol8fkOG3y0CpQlJdxa1rRzr6fIoQXT49cZwQWmLYWaiSsdS22fZfvJCYusN5 SiSjnU0hh1NKGozWubSOBDe5Noa1MLGg5AJCQKPyinG8RCNLPpH/uJQSc05v4IVX NggLvSMxCu49vq4N4pgOJvuhgknjbDuXY1q3FXnibF89vpIP4diST4IZdksLl5pX 2k+NdysvssuHgBO+o+zfOM1dWL/17q5v4tn+lqlrCX+3XOkG04hGBBARAgAGBQJN YmxQAAoJEKuMAM/44mU33YgAoJ+E0OeMxQR6116EIBaeUPbwzH9XAJ9I8oyUxFSm 0bvsTZKpNayxA0GSzrkCDQRNPauWARAAlfdqPwDcrXZYj8z7ZMBHx3ts4iumplCc V4W+iCugL7PFDkQFww/pnk4OMGrcGsmtvOvya31pkS/YNhs9v1BGn39694//Vny0 3jbwkX4NgxXs/3Oy+dmddoH34mv53lyZYDwH1WNmh3gTBHZ80B4y6DckW2vSKnja 5T6fSqfSQZ04hnAwOdJ9O/yeuwNKjduBS/QjTd6TKIkVpz9CAaCwHlhGGwoFaKqo di7U9tP/xg+HxSIQLRVnfcjx4tBpJ+7ezG/WStxzU1BrwgEyFrNG9hfHlt0R42M2 dncqS9k4nMQ2JcoQV3+Y7v1lHN3NqPuVQ0sq2Gn1/9ay86J8/kyp+CbGvEmYrORh lmIpzVIVoqQCt6vs+4EDix3ZV3Y+XYbLh1NAAmr1QQ73WmTcauoDGVL9lPzPd3Nv hAWU59PbDVQDjBpkFh/bxVrQIHbJ0g0Y7HuyCv+m3bmjOM9Xfdle9UBB8qGng8Z1 prOmKA6mHGa9RJ4seZIYHJMdJIHX8M1IT4OxizpHdcxMP8NkFwvm/q3XscdFxe8t nMYds3faVAbmDZYrLHPcg/CxiAvGWi95/YtBfygEDk3uYqo7lUi+2cQaFFFPIXsb AhZkAJ0xFDo1ihP2+d2wPcTBn0+vt9NeZfwTDDdXLOWZue991gvc6sKuOqHQpi8U klUjnaPY1BcAEQEAAYkCHwQYAQgACQUCTT2rlgIbDAAKCRA5yaC2QCYq8E4ED/9y ML3GVxrfl5FOlZBpVuIBLVRNFHnSJUawDaARre1XFYKp5GJpS8OnzJgW1KYa62k3 bWbRVYFrukhHBmLjAMKL2lj6ddBtfrDYh+NqJWcRci/Jy5aQ/GuhG8TJHk1TxNTu 1cL9bgXcjw8mfZdFZ8MsKB0lk0y+l7zztX46X8h9Cjm1V2L7srThhwQpNyVaPipT dOEI7Y7jla/5BoTcca2KIaKWK7bXAMAo8fZDuGonw9r41qlcf5d6SV51Nr8xd0rB wXDjzjiL/pBoyBnWmYgGtp7bd3I6HL0CLkaBpefiBeR0gGu8JhT7XDfiWkvkX31U WfMTYsTtBf7685Ow+EMxFPLOJdDFDbb8ePVPdTFv7yX4k2135QQGO7jlJ5mRngzk Abh6qCC27PNUSfICWLNu88NLKzFfFnb7JVuN/NtvMGmy6Zfuj4a4rhzbclZnmcv3 gNj5TEJ+CBe5VlT1ajACgtxjpGvCHhBBl/x6IdibjGmE/kTQrWKpP6X1Jl4ejz1y 5irJvZT5KHmZpPuzUwFRt55JTWj6l7k4RF91is0lTdPgHtHPEPzDsk7zRp5byr9X 7qM3n4JK8jylJ96Gr03OjKGMg/SBSBpb70T+lCMncQyY81jj2AURjuKWcDQ+lyBa NyBlGeEyZdFnBA/e3QiVejLkpflTYpGX8k25BQbLIA== =3bTv -END PGP PUBLIC KEY BLOCK-
Bug#334517: mysql-client-4.1: mysqldumpslow is looking for '/var/lib/mysql/*-slow.log'
tags patch 334517 thanks seems to be fixed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460066 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
