Bug#618539: upgrading clamav-milter breaks configuration : does not restart
Hi, 2011/3/16 Erwan David : > Package: clamav-milter > Version: 0.97+dfsg-2 > Severity: important > > When upgrading clamav-milter, a line > LogClean > > was added to /etc/clamav/clamav-milter.conf I've had the same issue on an upgrade today from Debian 5.0 to 6.0 (although clamav* packages were in fact upgraded from volatile to stable-updates). Also, a second problem was blocking clamav-milter from (re)starting: ERROR: Invalid setting true for option LogInfected I've removed both lines and it works as always. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618539: upgrading clamav-milter breaks configuration : does not restart
Hi, 2011/3/17 Michael Tautschnig : > I just checked our packaging repository and couldn't find any trace of "true" > being a possible setting. No idea how that made it into your config. I searched this in my changetrack log and found that the previous clamav* update (v0.96.5 from lenny volatile) has added only this: Changes made to '/etc/clamav/clamav-milter.conf' follow: @@ -17,6 +17,7 @@ LogFacility LOG_MAIL LogVerbose true LogInfected Full +LogClean Off MaxFileSize 60M RejectMsg "Service unavailable; Blocked INFECTED (%v)" And to make it work for the laters update from stable-proposed-updates (v0.97) I removed the two lines that are not recognized as valid configuration anymore: Changes made to '/etc/clamav/clamav-milter.conf' follow: @@ -16,8 +16,6 @@ LogSyslog true LogFacility LOG_MAIL LogVerbose true -LogInfected Full -LogClean Off MaxFileSize 60M RejectMsg "Service unavailable; Blocked INFECTED (%v)" TemporaryDirectory /tmp To conclude, the change to "LogInfected true" I think it was done by me manually to fix the startup error. However, I re-added "LogInfected Full" back to clamav-milter.conf and it (re)starts without error this time. (weird) Thanks -- Setting up clamav-milter (0.97+dfsg-2~squeeze1) ... Replacing config file /etc/clamav/clamav-milter.conf with new version Starting Sendmail milter plugin for ClamAV: clamav-milterERROR: Missing argument for option at line 20 /usr/sbin/clamav-milter: cannot parse config file /etc/clamav/clamav-milter.conf failed! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618699: roundcube-core: after disabling all web servers the symlinks should be removed
Hi, 2011/3/23 Vincent Bernat : >> Please remove the symbolic links for each web server deselected. > > javascript-common.conf is from javascript-common. Right. > It seems to be common > practice to not touch those links if asked not to configure web > servers. I have no easy ways to check if the link was created by the > user or by postinst. A user not wanting to let postinst handle a > webserver because he does not want that postinst restart/reload his > webserver may still want to use the symlink. Than the only solution is to rise a debconf question at install. > I also notice that wwwconfig-common does not handle link removal as > well. I don't find appropriate to add links to any web server configuration without confirmation. I have multiple virtual hosts on almost all web servers and I don't want aliases on all virtual hosts by default. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619411: roundcube-core: program/include/iniset.php should not alter INSTALL_PATH constant
Hi, 2011/3/23 Vincent Bernat : > OoO Lors de la soirée naissante du mercredi 23 mars 2011, vers 17:43, > Teodor disait : >> Please do not modify the upstream file 'iniset.php'. > > The modification is done because $_SERVER['SCRIPT_FILENAME'] may > dereference symlinks and result in /usr/share/roundcube instead of > /var/lib/roundcube. Some features won't work then (because > /usr/share/roundcube is not complete). I've tested this yesterday and re-tested this now by creating a file 'index2.php' with this content: '; echo INSTALL_PATH; ?> The result is: /var/lib/roundcube/index2.php /var/lib/roundcube/ I'm using roundcube with the upstream 'iniset.php' with no problems. > I don't quite understand what you try to do. Do you copy the roundcube > installation into another location? I've cloned '/var/lib/roundcube' (with rsync) on a different directory in /var/www for a new virtual host designed only for mobile devices (smart phones). Afterwards I just changed a few symbolic links (config/main.inc.php, logs) and added a new skin. But for this to work I had to change the iniset.php to detect automatically INSTALL_PATH. I hope this explains the setup. I don't want to duplicate roundcube code if not really necessary. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611283: gnome-commander doesn't start due to broken link on "start_dir_*"
Hi, 2011/5/8 Alessio Treglia : > would you reproduce this on the latest release available in Debian sid? Yes, I just tested on my workstation (with unstable). You can reproduce by 3 simple steps: 1) mkdir ~/testdir; ln -s ~/testdir ~/testlink 2) open gnome-commander and change current directory to the link created ~/testlink and close gnome-commander 3) rmdir ~/testdir #testlink is now broken 4) start gnome-commander from a terminal to notice the "segfault" message Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#597225: libpam-modules: 'nofile' limit set in limits.conf not applied
2011/5/5 Steve Langasek : > The manpage appears to be inaccurate, then and needs fixing; but that's > entirely separate from this bug report, which was about wildcard nofile > limits not being applied *at all*. I didn't found any reference about this even after re-reading all the messages in the BTS. However, this might have been the intention but the example given by the reporter is for 'root' user. >> And in practice this is the only way to make 'nofile' limit work, by >> duplicating the wildcard limit for 'root' (see my config below). > > Correct. This is a Debian divergence from upstream that's been carried by > the pam package for more than a decade. We should have a conversation about > whether we want root to continue to be treated specially by pam_limits given > that this has never been upstreamed, but that's not a "bug" per se, and > again is not the behavior that this bug report was filed about. I think any divergences from upstream should be documented, probably in README.Debian? At least for as long as there are divergences. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#626237: pam: should document any divergence from upstream
Source: pam Version: 1.1.1-6.1 Severity: wishlist See discussion in Debian Bug#597225 for more details. Please document that 'root' is treated specially by pam_limits or remove this divergence. Thanks 2011/5/10 Steve Langasek : >> > Correct. This is a Debian divergence from upstream that's been carried by >> > the pam package for more than a decade. We should have a conversation >> > about >> > whether we want root to continue to be treated specially by pam_limits >> > given >> > that this has never been upstreamed, but that's not a "bug" per se, and >> > again is not the behavior that this bug report was filed about. > >> I think any divergences from upstream should be documented, probably >> in README.Debian? At least for as long as there are divergences. > > That's fine. Please file a separate bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#626547: [Pkg-clamav-devel] Bug#626547: incorrect /var/run/clamav/freshclam.pid owner set if clamav installed on system with HAL
2011/5/13 Stephen Gran : > I don't see how this is possible. It is possible, but under specific circumstances. It happened to me for a service (I don't remember which one) and it was caused by the service removal (directory in /var/run was not deleted), manually deleted the user of that service, installed a new service that added a new system user with the ID used by previous one. Next the reinstall of the first service added a new system user with a different ID than what the directory on /var/run/SERVICE had. In conclusion, it is a corner situation that can only handled by not *ever* removing system users as it was recently decided by consensus on debian-devel. The only question is where (postrm or debhelper) and how to implement it. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591786: nagios3: should ask before enabling config for 'apache2'
Hi, 2011/2/12 Alexander Wirt : > today I implemented deconfiguration of webservers. Enabling by default with > debconf priority normal will still stay default. But in debconf priority low > you will be able to deconfigure apache2. You can also do dpkg-reconfigure > -plow nagios3-cgi at any time. I didn't uploaded the new version yet, but if > you see the close mail you now that I did. Ok, I'll be able to test it when it hits backports (lenny or squeeze). Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609516: unattended-upgrades: should not send email if executed manually with '--dry-run'
Hi, 2011/2/4 Michael Vogt : >> Also, the message sent on manual execution with these two options cannot be >> displayed properly (an 'application/octet-stream' attachment only). This will >> go away by itself if no email is sent when executed with --dry-run. > > Is that a problem on "real" mails too? Or just when run with > --dry-run? Only once I've get a message where the result was displayed as an attachment (with both claws-mail and squirrelmail) . Thanks Date: Wed, 02 Feb 2011 09:26:42 +0200 To: root@localhost Subject: unattended-upgrades result for 'host...' User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Message-Id: <20110202072642.C841C24D@host...> From: root@host... (root) VW5hdHRlbmRlZCB1cGdyYWRlIHJldHVybmVkOiBUcnVlCgpQYWNrYWdlcyB0aGF0IGFyZSB1 cGdyYWRlZDoKIGFwdCBhcHQtdXRpbHMgZGViY29uZiBkZWJjb25mLWkxOG4gZHBrZyBkcGtn LWRldiBnbm9tZS1jb2RlYy1pbnN0YWxsIAogbGliZHBrZy1wZXJsIGxpYmd1cG5wLWlnZC0x LjAtMyBvcGVub2ZmaWNlLm9yZyBvcGVub2ZmaWNlLm9yZy1iYXNlIAogb3Blbm9mZmljZS5v cmctYmFzZS1jb3JlIG9wZW5vZmZpY2Uub3JnLWNhbGMgb3Blbm9mZmljZS5vcmctY29tbW9u IAogb3Blbm9mZmljZS5vcmctY29yZSBvcGVub2ZmaWNlLm9yZy1kcmF3IG9wZW5vZmZpY2Uu b3JnLWVtYWlsbWVyZ2UgCiBvcGVub2ZmaWNlLm9yZy1maWx0ZXItYmluZmlsdGVyIG9wZW5v ZmZpY2Uub3JnLWZpbHRlci1tb2JpbGVkZXYgCiBvcGVub2ZmaWNlLm9yZy1nbm9tZSBvcGVu b2ZmaWNlLm9yZy1ndGsgb3Blbm9mZmljZS5vcmctaW1wcmVzcyAKIG9wZW5vZmZpY2Uub3Jn LWphdmEtY29tbW9uIG9wZW5vZmZpY2Uub3JnLW1hdGggCiBvcGVub2ZmaWNlLm9yZy1vZmZp Y2ViZWFuIG9wZW5vZmZpY2Uub3JnLXJlcG9ydC1idWlsZGVyLWJpbiAKIG9wZW5vZmZpY2Uu b3JnLXN0eWxlLWdhbGF4eSBvcGVub2ZmaWNlLm9yZy1zdHlsZS10YW5nbyAKIG9wZW5vZmZp Y2Uub3JnLXdyaXRlciBweXRob24tdW5vIHR0Zi1vcGVuc3ltYm9sIHVuby1saWJzMyB1cmUg dnpjdGwgCgpQYWNrYWdlIGluc3RhbGxhdGlvbiBsb2c6Cg1FeHRyYWN0aW5nIHRlbXBsYXRl cyBmcm9tIHBhY2thZ2VzOiA4OCUNRXh0cmFjdGluZyB0ZW1wbGF0ZXMgZnJvbSBwYWNrYWdl czogMTAwJQpQcmVjb25maWd1cmluZyBwYWNrYWdlcyAuLi4KKFJlYWRpbmcgZGF0YWJhc2Ug Li4uIDE2NzEzMyBmaWxlcyBhbmQgZGlyZWN0b3JpZXMgY3VycmVudGx5IGluc3RhbGxlZC4p ClByZXBhcmluZyB0byByZXBsYWNlIGRwa2cgMS4xNS44LjkgKHVzaW5nIC4uLi9kcGtnXzEu MTUuOC4xMF9hbWQ2NC5kZWIpIC4uLgpVbnBhY2tpbmcgcmVwbGFjZW1lbnQgZHBrZyAuLi4K UHJvY2Vzc2luZyB0cmlnZ2VycyBmb3IgbWFuLWRiIC4uLgpTZXR0aW5nIHVwIGRwa2cgKDEu MTUuOC4xMCkgLi4uCihSZWFkaW5nIGRhdGFiYXNlIC4uLiAxNjcxMzMgZmlsZXMgYW5kIGRp cmVjdG9yaWVzIGN1cnJlbnRseSBpbnN0YWxsZWQuKQpQcmVwYXJpbmcgdG8gcmVwbGFjZSBk ZWJjb25mLWkxOG4gMS41LjM2ICh1c2luZyAuLi4vZGViY29uZi1pMThuXzEuNS4zNi4xX2Fs bC5kZWIpIC4uLgpVbnBhY2tpbmcgcmVwbGFjZW1lbnQgZGViY29uZi1pMThuIC4uLgpQcm9j ZXNzaW5nIHRyaWdnZXJzIGZvciBtYW4tZGIgLi4uClNldHRpbmcgdXAgZGViY29uZi1pMThu ICgxLjUuMzYuMSkgLi4uCihSZWFkaW5nIGRhdGFiYXNlIC4uLiAxNjcxMzMgZmlsZXMgYW5k IGRpcmVjdG9yaWVzIGN1cnJlbnRseSBpbnN0YWxsZWQuKQpQcmVwYXJpbmcgdG8gcmVwbGFj ZSBkZWJjb25mIDEuNS4zNiAodXNpbmcgLi4uL2RlYmNvbmZfMS41LjM2LjFfYWxsLmRlYikg Li4uClVucGFja2luZyByZXBsYWNlbWVudCBkZWJjb25mIC4uLgpQcm9jZXNzaW5nIHRyaWdn ZXJzIGZvciBtYW4tZGIgLi4uClNldHRpbmcgdXAgZGViY29uZiAoMS41LjM2LjEpIC4uLgoo UmVhZGluZyBkYXRhYmFzZSAuLi4gMTY3MTMzIGZpbGVzIGFuZCBkaXJlY3RvcmllcyBjdXJy ZW50bHkgaW5zdGFsbGVkLikKUHJlcGFyaW5nIHRvIHJlcGxhY2Ugb3Blbm9mZmljZS5vcmct ZW1haWxtZXJnZSAxOjMuMi4xLTExICh1c2luZyAuLi4vb3Blbm9mZmljZS5vcmctZW1haWxt ZXJnZV8xJTNhMy4yLjEtMTErc3F1ZWV6ZTJfYWxsLmRlYikgLi4uCkRpc2FibGluZzogbWFp bG1lcmdlLnB5Cgp1bm9wa2cgZG9uZS4KVW5wYWNraW5nIHJlcGxhY2VtZW50IG9wZW5vZmZp Y2Uub3JnLWVtYWlsbWVyZ2UgLi4uClByZXBhcmluZyB0byByZXBsYWNlIHVyZSAxLjYuMStP T28zLjIuMS0xMSAodXNpbmcgLi4uL3VyZV8xLjYuMStPT28zLjIuMS0xMStzcXVlZXplMl9h bWQ2NC5kZWIpIC4uLgpVbnBhY2tpbmcgcmVwbGFjZW1lbnQgdXJlIC4uLgpQcmVwYXJpbmcg dG8gcmVwbGFjZSB1bm8tbGliczMgMS42LjErT09vMy4yLjEtMTEgKHVzaW5nIC4uLi91bm8t bGliczNfMS42LjErT09vMy4yLjEtMTErc3F1ZWV6ZTJfYW1kNjQuZGViKSAuLi4KVW5wYWNr aW5nIHJlcGxhY2VtZW50IHVuby1saWJzMyAuLi4KUHJlcGFyaW5nIHRvIHJlcGxhY2UgYXB0 IDAuOC4xMCAodXNpbmcgLi4uL2FwdF8wLjguMTAuM19hbWQ2NC5kZWIpIC4uLgpVbnBhY2tp bmcgcmVwbGFjZW1lbnQgYXB0IC4uLgpQcm9jZXNzaW5nIHRyaWdnZXJzIGZvciBtYW4tZGIg Li4uClNldHRpbmcgdXAgYXB0ICgwLjguMTAuMykgLi4uCmdwZzoga2V5IEY0MjU4NEU2OiAi TGVubnkgU3RhYmxlIFJlbGVhc2UgS2V5IDxkZWJpYW4tcmVsZWFzZUBsaXN0cy5kZWJpYW4u b3JnPiIgbm90IGNoYW5nZWQKZ3BnOiBrZXkgNTVCRTMwMkI6ICJEZWJpYW4gQXJjaGl2ZSBB dXRvbWF0aWMgU2lnbmluZyBLZXkgKDUuMC9sZW5ueSkgPGZ0cG1hc3RlckBkZWJpYW4ub3Jn PiIgbm90IGNoYW5nZWQKZ3BnOiBrZXkgNkQ4NDk2MTc6ICJEZWJpYW4tVm9sYXRpbGUgQXJj aGl2ZSBBdXRvbWF0aWMgU2lnbmluZyBLZXkgKDUuMC9sZW5ueSkiIG5vdCBjaGFuZ2VkCmdw Zzoga2V5IEI5ODMyMUY5OiAiU3F1ZWV6ZSBTdGFibGUgUmVsZWFzZSBLZXkgPGRlYmlhbi1y ZWxlYXNlQGxpc3RzLmRlYmlhbi5vcmc+IiBub3QgY2hhbmdlZApncGc6IGtleSA0NzMwNDFG QTogIkRlYmlhbiBBcmNoaXZlIEF1dG9tYXRpYyBTaWduaW5nIEtleSAoNi4wL3NxdWVlemUp IDxmdHBtYXN0ZXJAZGViaWFuLm9yZz4iIG5vdCBjaGFuZ2VkCmdwZzogVG90YWwgbnVtYmVy IHByb2Nlc3NlZDogNQpncGc6ICAgICAgICAgICAgICB1bmNoYW5nZWQ6IDUKKFJlYWRpbmcg ZGF0YWJhc2UgLi4uIDE2NzEzMyBmaWxlcyBhbmQgZGlyZWN0b3JpZXMgY3VycmVudGx5IGlu c3RhbGxlZC4pClByZXBhcmluZyB0byByZXBsYWNlIGFwdC11dGlscyAwLjguMTAgKHVzaW5n IC4uLi9hcHQtdXRpbHNfMC44LjEwLjNfYW1kNjQuZGViKSAuLi4KVW5wYWNraW5nIHJlcGxh Y2VtZW50IGFwdC11dGlscyAuLi4KUHJlcGFyaW5nIHRvIHJlcGxhY2UgZHBrZy
Bug#563955: cacti: Undefined index: local_data_id in graphs_new.php
Version: 0.8.7g-1 Unfortunately the patch that fixed this problem was lost during upgrade to v0.8.7g. Thanks -- Notice: Undefined index: local_data_id in /usr/share/cacti/site/graphs_new.php on line 201 Warning: Cannot modify header information - headers already sent by (output started at /usr/share/cacti/site/graphs_new.php:201) in /usr/share/cacti/site/graphs_new.php on line 85 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563955: cacti: Undefined index: local_data_id in graphs_new.php
tags 563955 + patch
quit
2011/2/17 Teodor MICU :
> Unfortunately the patch that fixed this problem was lost during
> upgrade to v0.8.7g.
I've just replaced "sizeof" with "!empty" on those two occurrences of
"local_data_id" and I get this (kind of) expected message:
| Created graph: PRO-R5K08 - CPU load (2 processors)
| ERROR: no Data Source associated. Check Template
Thanks
--- /usr/share/cacti/site/graphs_new.php_0.8.7g-1 2010-07-09 16:33:46.0 -0600
+++ /usr/share/cacti/site/graphs_new.php 2011-02-17 08:45:10.0 -0700
@@ -198,7 +198,7 @@
debug_log_insert("new_graphs", "Created graph: " . get_graph_title($return_array["local_graph_id"]));
/* lastly push host-specific information to our data sources */
-if (sizeof($return_array["local_data_id"])) { # we expect at least one data source associated
+if (!empty($return_array["local_data_id"])) { # we expect at least one data source associated
foreach($return_array["local_data_id"] as $item) {
push_out_host($_POST["host_id"], $item);
}
@@ -214,7 +214,7 @@
debug_log_insert("new_graphs", "Created graph: " . get_graph_title($return_array["local_graph_id"]));
/* lastly push host-specific information to our data sources */
- if (sizeof($return_array["local_data_id"])) { # we expect at least one data source associated
+ if (!empty($return_array["local_data_id"])) { # we expect at least one data source associated
foreach($return_array["local_data_id"] as $item) {
push_out_host($_POST["host_id"], $item);
}
Bug#586995: KMS not working on ATI Technologies Inc M56P [Radeon Mobility X1600]
reassign 586995 linux-image-2.6.32-5-amd64 2.6.32-24 retitle 586995 KMS not working on ATI Technologies Inc M56P [Radeon Mobility X1600] stop On Sun, Oct 3, 2010 at 11:59 PM, Cyril Brulebois wrote: > Once that done, I'll probably reassign the bug to the kernel anyway. I've done that now. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586995: KMS not working on ATI Technologies Inc M56P [Radeon Mobility X1600]
Package: linux-2.6 Version: 2.6.32-24 Severity: normal Attached is the file containing the reportbug detected settings. Previous discussion can be found in the BTS. The final goal is to find a fix for this issue in 'squeeze'. Thanks -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-24) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Thu Sep 30 03:34:00 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=6f822aa6-3605-4e2e-bfca-7f27fc0ad9fa ro panic=20 ** Not tainted ** Kernel log: [5.901601] lis3lv02d driver loaded. [5.929728] yenta_cardbus :02:06.0: ISA IRQ mask 0x0c78, PCI irq 18 [5.929793] yenta_cardbus :02:06.0: Socket status: 3006 [5.929854] pci_bus :02: Raising subordinate bus# of parent bus (#02) from #03 to #06 [5.929929] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge I/O window: 0x8000 - 0x8fff [5.929998] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge Memory window: 0xf420 - 0xf45f [5.930067] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge Memory window: 0xc000 - 0xc3ff [5.930495] tifm_7xx1 :02:06.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [6.024782] cfg80211: Using static regulatory domain info [6.024845] cfg80211: Regulatory domain: US [6.024903] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [6.024970] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [6.025042] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [6.025103] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [6.025163] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [6.025224] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [6.025287] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [6.025355] cfg80211: Calling CRDA for country: US [6.159635] Bluetooth: Generic Bluetooth USB driver ver 0.6 [6.159915] usbcore: registered new interface driver btusb [6.171447] usbcore: registered new interface driver hiddev [6.186203] input: Logitech USB Receiver as /devices/pci:00/:00:1d.2/usb4/4-2/4-2:1.0/input/input9 [6.186377] generic-usb 0003:046D:C51B.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-:00:1d.2-2/input0 [6.200208] generic-usb 0003:046D:C51B.0002: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:1d.2-2/input1 [6.200336] usbcore: registered new interface driver usbhid [6.200398] usbhid: v2.6:USB HID core driver [6.899873] [drm] radeon defaulting to userspace modesetting. [6.900577] pci :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [6.900642] pci :01:00.0: setting latency timer to 64 [6.900795] [drm] Initialized radeon 1.32.0 20080528 for :01:00.0 on minor 0 [6.906886] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks [6.906960] iwl3945: Copyright(c) 2003-2009 Intel Corporation [6.907101] iwl3945 :10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [6.907177] iwl3945 :10:00.0: setting latency timer to 64 [6.976284] iwl3945 :10:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [6.976354] iwl3945 :10:00.0: Detected Intel Wireless WiFi Link 3945ABG [6.976526] alloc irq_desc for 29 on node -1 [6.976529] alloc kstat_irqs on node -1 [6.976562] iwl3945 :10:00.0: irq 29 for MSI/MSI-X [7.120645] phy0: Selected rate control algorithm 'iwl-3945-rs' [7.685303] HDA Intel :00:1b.0: power state changed by ACPI to D0 [7.685406] HDA Intel :00:1b.0: power state changed by ACPI to D0 [7.685474] HDA Intel :00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [7.685583] HDA Intel :00:1b.0: setting latency timer to 64 [7.800711] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input10 [ 10.208186] input: PS/2 Generic Mouse as /devices/platform/i8042/serio4/serio5/input/input11 [ 53.526437] padlock: VIA PadLock not detected. [ 53.570733] padlock: VIA PadLock Hash Engine not detected. [ 54.629311] loop: module loaded [ 54.973474] Adding 6425444k swap on /dev/mapper/sda5_crypt. Priority:-1 extents:1 across:6425444k [ 55.440272] EXT4-fs (dm-0): mounted filesystem with ordered data mode [ 55.463177] EXT4-fs (sda7): mounted filesystem with ordered data mode [ 57.787549] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12 [ 58.801918] alloc irq_desc for 30 on node -1 [ 58.801921] alloc kstat_irqs on node -1 [ 58.801940] tg3 :08:00.0: irq 30 for MSI/MSI-X [ 58.989786] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 59.036548] iwl3945 :10:00.0: firmware: requesting iwlwifi-3945-2.ucode [ 59.109651] iwl3945 :10:00.0: loaded firmware version 15.32.2.9 [ 59.176513] Registered led device: iwl-phy
Bug#562736: vzctl: vzmigrate script depends on bash and should use echo instead of printf
On Sun, Dec 27, 2009 at 4:31 PM, James Stanley wrote: > Package: vzctl > Version: 3.0.23-8 > > 2.) It should use "echo -ne" instead of "printf" as it passes text as > separate arguments and printf only prints the first Please don't! The recommendation is to go in the oppossite direction (use "printf" instead of "echo -ne"). For this specific case this is the correct call: printf "$*\n" For the general case, all arguments to "printf" must be enclosed in "". Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#499946: iceowl: please upload v0.9 to unstable in time to be included in squeeze.
Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562736: vzctl: vzmigrate script depends on bash and should use echo instead of printf
Hi Ola and James, On Mon, Dec 28, 2009 at 7:30 PM, Ola Lundqvist wrote: > When it comes to the echo versus printf I have tested both the > original printf solution, your suggestion and the echo solution. > > As no options are needed to echo there are no compatibility issues in using > echo. That is the reason why I'd vote for that one. However I will > file a bug against upstream about this and let them decide the solution. > > In the meantime I will patch it to use echo. Otherwise it is very hard > to determine the error both with bash and dash as it is currently not printed. A couple of years ago I've had to write a script that should be executed in any *nix environment, my test cases were Debian, RHEL and Solaris. That's how I've learned that "echo" cannot be used for printing messages because not all shells accepts the "-en" arguments. Not even on Debian Linux bash and dash will have the same behaviour. Instead, since then I'm using "printf" without any portability problem. The only reliable call for "echo" is as you said without any arguments (it will print a new line too after the strings). In conclussion, I'm strongly recommending to use "printf". But keep in mind that printf accepts only one or two strings (example "%s %s" "$VAR1 $VAR2") -- printf = print with format. Thanks -- d...@frost:~$ dash $ echo -en "ok\n" -en ok $ echo -n "ok" ok$ $ $ echo "ok" ok $ echo -e "ok\n" -e ok $ printf "ok\n" ok $ ps ax | grep $$ 984 pts/0S 0:00 dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562977: claws-mail: compose window does not accept the 'eE' keys anymore
Package: claws-mail Version: 3.7.3-1 Severity: normal Hello, For a few days I've noticed that in the Compose windows the 'e' and 'E' keys are no longer accepted. All other keys are working just fine. For e/E I have to use an inverted logic with SHIFT+CAPS since without SHIFT the key press is ignored. For any other X application e/E keys are working are always. Thanks -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages claws-mail depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2The Cairo 2D vector graphics libra ii libcompfaceg1 1:1.5.2-5 Compress/decompress images for mai ii libdbus-glib-1-2 0.82-2 simple interprocess messaging syst ii libenchant1c2a1.4.2-3.4 a wrapper library for various spel ii libetpan130.58-1 mail handling library ii libgcrypt11 1.4.4-6LGPL Crypto library - runtime libr ii libglib2.0-0 2.22.3-1 The GLib library of C routines ii libgnutls26 2.8.5-2the GNU TLS library - runtime libr ii libgtk2.0-0 2.18.3-1 The GTK+ graphical user interface ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libldap-2.4-2 2.4.17-2.1 OpenLDAP libraries ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libpisock90.12.4-7 library for communicating with a P ii libsm62:1.1.1-1 X11 Session Management library ii xdg-utils 1.0.2-6.1 desktop integration utilities from Versions of packages claws-mail recommends: ii aspell-en [aspell-dictionary] 6.0-0-5.1 English dictionary for GNU Aspell ii aspell-ro [aspell-dictionary] 3.1-1 The Romanian dictionary for GNU as ii claws-mail-i18n 3.7.3-1Locale data for Claws Mail (i18n s ii xfonts-100dpi 1:1.0.0-4 100 dpi fonts for X ii xfonts-75dpi 1:1.0.0-4 75 dpi fonts for X Versions of packages claws-mail suggests: pn claws-mail-doc (no description available) ii claws-mail-tools 3.7.3-1Helper and utility scripts for Cla ii epiphany-browser [www-browser 2.29.3-1 Intuitive GNOME web browser ii gedit 2.28.2-1 official text editor of the GNOME ii iceape-browser [www-browser] 2.0-1 Iceape Navigator (Internet browser ii iceweasel [www-browser] 3.5.6-1lightweight web browser based on M -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578862: verify: close database /var/lib/postfix/verify_cache.db: No such file or directory
Package: postfix Version: 2.7.1-1 Severity: normal I've performed two tests: 1) I've created a symbolic link in /var/spool/postfix/var/lib/postfix to point to /var/lib/postfix/verify_cache.db and the error in the logs was: Nov 3 14:57:11 pinto postfix/verify[12164]: close database /var/lib/postfix/verify_cache.db: Too many levels of symbolic links 2) I've moved the file from /var/lib/postfix to /var/spool/postfix/var/lib/postfix and the message in the logs is: Nov 3 15:01:32 pinto postfix/verify[12339]: cache /var/lib/postfix/verify_cache.db full cleanup: retained=0 dropped=0 entries Thus, my conclusion would be that verify_cache.db should be created from the start at /var/spool/postfix/var/lib/postfix since by default postfix is chrooted to /var/spool/postfix. The permissions for the /var/spool/postfix/var/lib/postfix directory and verify_cache.db file are postfix:postfix. Thanks -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postfix depends on: ii adduser3.112 add and remove users and groups ii debconf [debconf-2.0] 1.5.36Debian configuration management sy ii dpkg 1.15.8.5 Debian package management system ii libc6 2.11.2-6+squeeze1 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libsasl2-2 2.1.23.dfsg1-6Cyrus SASL - authentication abstra ii libssl0.9.80.9.8o-2 SSL shared libraries ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip ii netbase4.42 Basic TCP/IP networking system ii ssl-cert 1.0.26simple debconf wrapper for OpenSSL Versions of packages postfix recommends: ii python 2.6.6-3+squeeze1 interactive high-level object-orie Versions of packages postfix suggests: ii libsasl2-modules 2.1.23.dfsg1-6 Cyrus SASL - pluggable authenticat pn mail-reader(no description available) pn postfix-cdb(no description available) pn postfix-ldap (no description available) pn postfix-mysql (no description available) ii postfix-pcre 2.7.1-1PCRE map support for Postfix pn postfix-pgsql (no description available) ii procmail 3.22-19Versatile e-mail processor pn resolvconf (no description available) pn sasl2-bin (no description available) pn ufw(no description available) -- debconf information: * postfix/mailname: pinto.DOMAIN.com postfix/tlsmgr_upgrade_warning: * postfix/recipient_delim: + * postfix/main_mailer_type: Internet Site postfix/retry_upgrade_warning: postfix/kernel_version_warning: postfix/relayhost: postfix/procmail: false postfix/bad_recipient_delimiter: * postfix/chattr: false * postfix/root_address: r...@domain.ro postfix/rfc1035_violation: false postfix/mydomain_warning: * postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 * postfix/destinations: pinto.DOMAIN.com, pinto, localhost postfix/not_configured: * postfix/mailbox_limit: 0 * postfix/protocols: ipv4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602840: clamav-daemon: StreamMaxLength documentation wrong
Hi, 2010/11/8 btwotch : > Package: clamav-daemon > Severity: minor > > You write: > +Template: clamav-base/StreamMaxLength > +Type: string > +Default: 0 > +_Description: Maximum stream length (unit Mb) allowed: > + You can set a limit on the stream length that can be scanned. > + . > + Entering '0' will disable this limit. > > > BUT: If you set it to 0 then clamdscan (--stream) won't find any > viruses; just try that with eicar No, it works here as intended for a long time. I would tag this bug with "moreinfo unreproducible" but I'm not the maintainer. Thanks -- $ grep StreamMaxLength /etc/clamav/clamd.conf StreamMaxLength 0 $ clamdscan eicar_com.zip /tmp/eicar_com.zip: Eicar-Test-Signature FOUND --- SCAN SUMMARY --- Infected files: 1 Time: 0.001 sec (0 m 0 s) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602532: debian-archive-keyring: please add key for backports.debian.org
Hi, 2010/11/10 Alexander Wirt : > Teodor MICU schrieb am Wednesday, den 10. November 2010: >> I don't think that I should manually import a key for any official or >> semi-official repository from Debian. > Because its double signed as announced [1]. The double signing will dropped > soon. As you maybe saw you can install packages from backports without that > authentication warning. As far I can see there are no packages (yet) in squeeze-backports. Is there a reason to double sign it for squeeze? (I didn't get the link with the announcement [1]) > So you can just ignore the warning from apt-get update. Good to know. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602532: debian-archive-keyring: please add key for backports.debian.org
Hi, 2010/11/9 Alexander Wirt : > Ehm this key is deprecated and isn't in use anymore. Nowadays we use the > normal debian key. So I guess that bugreport can just get closed. Well, I have these repositories in my local sources.list: # backports from sid/testing .. deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free deb http://ftp.de.debian.org/debian-backports squeeze-backports main If this key is deprecated why do I get this on every host with Debian 6.0? | # apt-get update | Reading package lists... Done | W: There is no public key available for the following key IDs: | EA8E8B2116BA136C | W: There is no public key available for the following key IDs: | EA8E8B2116BA136C I don't think that I should manually import a key for any official or semi-official repository from Debian. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602840: clamav-daemon: StreamMaxLength documentation wrong
Hi, 2010/11/9 Török Edwin : > I don't see why you would want unlimited stream length though, that is > a sure way of filling up your disk. I had some problems due to this StreamMaxLength in the past where the mail server (postfix) was stuck at scanning this >10M message and no message was accepted anymore. Since then I've disabled StreamMaxLength (=0) and the message limit is set on the SMTP server at 40MB thus this will be the maximum data size received by clamav. (I do think that the default 0 for StreamMaxLength is a good setting) Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602532: debian-archive-keyring: please add key for backports.debian.org
Hi, 2010/11/10 Gerfried Fuchs : >> As far I can see there are no packages (yet) in squeeze-backports. Is >> there a reason to double sign it for squeeze? > > Because from what I understood it's not possible to sign different > parts of the archive with different sets of keys. Ok, I though that lenny-backports and squeeze-backports are kind of different archives. I've removed the old deprecated key on a system with Debian 5.0 and both lenny-backports and lenny-backports-sloppy enabled but there is a warning about the key missing *only* on Debian 6.0. So it seems that for lenny the deprecated key is not used to sign the archive although it used to be on backports.org? Thanks -- cobra:~# apt-key list /etc/apt/trusted.gpg [..] pub 1024D/16BA136C 2005-08-21 uid Backports.org Archive Key sub 2048g/5B82CECE 2005-08-21 cobra:~# apt-key del 16BA136C OK cobra:~# apt-key list /etc/apt/trusted.gpg pub 1024D/F42584E6 2008-04-06 [expires: 2012-05-15] uid Lenny Stable Release Key pub 4096R/55BE302B 2009-01-27 [expires: 2012-12-31] uid Debian Archive Automatic Signing Key (5.0/lenny) pub 2048R/6D849617 2009-01-24 [expires: 2013-01-23] uid Debian-Volatile Archive Automatic Signing Key (5.0/lenny) pub 4096R/B98321F9 2010-08-07 [expires: 2017-08-05] uid Squeeze Stable Release Key pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05] uid Debian Archive Automatic Signing Key (6.0/squeeze) cobra:~# apt-get update [..] Reading package lists... Done -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602532: debian-archive-keyring: please add key for backports.debian.org
reopen 602532 stop 2010/11/10 Teodor MICU : > I've removed the old deprecated key on a system with Debian 5.0 and > both lenny-backports and lenny-backports-sloppy enabled but there is a > warning about the key missing *only* on Debian 6.0. So it seems that > for lenny the deprecated key is not used to sign the archive although > it used to be on backports.org? Do you mind if you keep the bug open until the warning on Debian 6.0 is gone and the inconsistency between lenny and squeeze is clarified? (I won't reopen it if you consider it should be closed without further discussion) Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602532: debian-archive-keyring: please add key for backports.debian.org
Hi, 2010/11/11 Gerfried Fuchs : > However, the double signature got removed last night from the > squeeze-backports release signature. Actually it got removed ages ago, > but the Release file doesn't get regularly resigned and given that > uploads to it are still blocked never got resigned. This step was done > manually now. Perfect. I'm still getting the warning from the ftp.de.d.o mirror but I'm thinking it will synchronize soon with the master backports archive and this will be gone too, right? Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600166: openvpn: at start it adds >40 bogus routes not specified in configuration
Hi, On Thu, Oct 21, 2010 at 2:03 PM, Alberto Gonzalez Iniesta wrote: > I've got a new -2 package (same location) with upstream's solution, > instead of mine. Would you mind testing it? That would probably be the > one I upload to close this report. I've just tested this package (built on Oct 21) and the problem seems to be fixed. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600262: apt: random_sleep should not be executed if anacron has started the cron.daily script
Hi, On Wed, Oct 20, 2010 at 3:33 PM, Goswin von Brederlow wrote: >> Please apply this patch to avoid 'random_sleep' if the script was started by >> anacron. > > But if the system stays up all night then the jobs are also started by > anacron. This time at the problematic time though. I don't know exactly how 'cron' and 'anacron' are supposed to handle the cron scripts but I've just let my workstation running over night to see the result. I've received this email from Anacron: | From: Anacron | To: r...@fqdn | Subject: Anacron job 'cron.daily' on FQDN | Date: Sat, 23 Oct 2010 07:37:57 +0300 (EEST) | | /etc/cron.daily/apt: | Sat Oct 23 07:35:02 EEST 2010 | 14147 | Sat Oct 23 07:35:02 EEST 2010 (where 14147 was PID of anacron) So, it is clear that the 'apt' script was not executed by Cron but by Anacron. This is the expected behaviour when anacron is installed from /etc/crontab: | # m h dom mon dow usercommand | 25 6 * * * roottest -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) To conclude, I don't think the patch I've proposed is causing the execution at the "problematic" time which seems to be 6:25AM. The script was executed clearly at 7:35. Also, desktop systems are not supposed to be running over night but those few exceptions are not many. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600262: apt: random_sleep should not be executed if anacron has started the cron.daily script
Hi, On Sun, Oct 24, 2010 at 1:45 PM, Goswin von Brederlow wrote: > There ae 2 problematic times. The first is 6:25 without anacron > installed. The second is 7:35 with anacron installed. Ok, I see. So the first version of the patch avoids the first problematic time. For the second problematic time I could prepare a new patch to: 1) check for the uptime and if higher than some time (30 minutes) to execute "random_sleep" assuming that the computer was running over night; 2) check for the current hour and if less or equal to 7 to also execute "random_sleep". 3) something else that I can't see right now. Which one would it be good for you to accept in the 'apt' package? Any other idea? Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602172: [openvpn] openvpn doesn't start without manually created nobody group
severity 602172 normal tag 602172 + moreinfo unreproducible stop Hi, On Tue, Nov 2, 2010 at 10:50 AM, Matthieu Baechler wrote: > Package: openvpn > Version: 2.1.3-2 > Severity: grave > > A freshly installed openvpn package won't start because it needs > nobody group existence but install script doesn't create it. > > Once this group is created, it starts correctly. First of all I've tested (again) a fresh install and there is no problem during the installation. By default there is nothing to be started after a fresh install. Second, in Debian the user 'nobody' with group ' nogroup' are created by default. There should be no group 'nobody' on a Debian system. The most likely cause of your problem is a custom VPN configuration which enforces low privileges using 'user+group'. Thus the severity change. Please send us the VPN profile (without any sensitive information) or at least the output from this command: $ grep -i -E '(user|group)' /etc/openvpn/*.conf Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602172: [openvpn] openvpn doesn't start without manually created nobody group
Hi Alberto, After I've sent the message I remembered that I shouldn't add these tags because these are meant only for the maintainer to use them. Let me know if you want me to revert any of these changes. Thanks On Tue, Nov 2, 2010 at 11:41 AM, Teodor MICU wrote: > severity 602172 normal > tag 602172 + moreinfo unreproducible -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481072: dk-filter crash seems to be for a specific use case (-k parameter)
Followup-For: Bug #481072 Package: dk-filter Version: 1.0.0.dfsg-1+b1 *** Please type your report below this line *** Hello, I've been checking the status of 'dk-filter' for squeeze and it is blocked for inclusion by this RC bug report. As far as I can see this reliable crash is reproduced only if you use the -k parameter. I don't use it (I don't have multiple domains) and I don't have crashes, I had only one this morning but that all for almost a year of working properly. >From my point of view development of dk-filter has stopped and only dkim-filter is maintained properly. Thus this bug and the other I reported will have to be avoided as there are specific use cases. In conclusion, can we downgrade the severity of this bug report so that at least we have the same version from lenny in squeeze too? If there are no objections I can do this at the end of the week, though it is better to be done by Mike Markley. Thanks -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dk-filter depends on: ii adduser 3.110add and remove users and groups ii libc6 2.7-18lenny4 GNU C Library: Shared libraries ii libmilter1.0.1 8.14.3-5+lenny1 Sendmail Mail Filter API (Milter) ii libssl0.9.8 0.9.8g-15+lenny7 SSL shared libraries dk-filter recommends no packages. dk-filter suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#481072: dk-filter crash seems to be for a specific use case (-k parameter)
On Wed, Aug 18, 2010 at 12:38 AM, Mike Markley wrote: > On Mon, Aug 16, 2010 at 10:57:35AM +0300, Teodor MICU > wrote: > [..] >> In conclusion, can we downgrade the severity of this bug report so >> that at least we have the same version from lenny in squeeze too? If >> there are no objections I can do this at the end of the week, though >> it is better to be done by Mike Markley. > > I don't object, either, but I would also like input from the release > team. I can chase that, if you'd like. By all means I do prefer to have you as the maintainer of the package to contact the Release team. I'm not sure if this is necessary, but its your call. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599677: Please consider splitting into openvpn-core and openvpn
Hi, On Sun, Oct 10, 2010 at 5:04 AM, Eckhart Wörner wrote: > The idea is to split the openvpn package into a openvpn-core package > (essentially the openvpn binary) and an openvpn package (the remaining parts). If a split should be done, I believe these are better packaging names: * openvpn package instead of proposed 'openvpn-core' that contains only the 'openvpn' binary; * openvpn-server package which will depend on 'openvpn' to contain all the other stuff, most important being the script from /etc/init.d. Obviously this will require a transition which is not appropriate at this time, thus a decision will have to be postponed after squeeze release. The example with mysql-server is not close to this package because mysql-server is only for server operation while 'openvpn' binary operates both in client and server mode. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599677: Please consider splitting into openvpn-core and openvpn
On Sun, Oct 10, 2010 at 9:11 PM, Eckhart Wörner wrote: > The reason I chose those names was because the transition will probably be > smoother with them. But of course you're free to choose any package names you > like. :-) I don't see how adding two new packages will be smoother than only one new package. However, this is not for me to decide since I'm not the maintainer. ;-) Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599677: Please consider splitting into openvpn-core and openvpn
Hi, On Sun, Oct 10, 2010 at 10:04 PM, Alberto Gonzalez Iniesta wrote: > And the maintainer is not really sure about the benefits of this split. > Mainly because it makes no sense to have a 'openvpn' package containing > nothing useful (examples, docs, and the init.d script) and a package with > just the binary (no init.d, no /etc/openvpn/,...). I can see two reasons to do the split: 1) less space for those installations in 'client' mode; 2) one less script in /etc/init.d -- just for a pure cosmetic view. However, it seems weird to have the /etc/init.d/openvpn script and /usr/bin/openvpn binary in two separate binary packages. But also this comes only from the fact that the 'openvpn' binary operates in both modes: client and server. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600166: openvpn: at start it adds >40 bogus routes not specified in configuration
Hi, On Thu, Oct 14, 2010 at 11:37 AM, Alberto Gonzalez Iniesta wrote: > Hi, could you attach (without sensitive data) the server and client > configurations? Sure. The real company addresses and names were replaced with generic names. Thanks #== openvpn client options (linux) == client remote OPENVPN_REMOTE_PEER nobind tls-auth "keys/ta-sfo.key" ca "keys/COMPANY_private_CA.crt" cert "keys/staff.crt" key "keys/staff.key" comp-lzo no dev tun mlock mtu-test mute 6 mute-replay-warnings passtos #available only on Linux ping-timer-rem reneg-sec 0 tls-exit auth-user-pass "pw_staff.txt" auth-retry interact auth-nocache #mssfix 1400#use only on networks where the MTU test fails tls-remote "/C=US/ST=../L=../O=../CN=.." ns-cert-type server verb 4 #route remote_host 255.255.255.255 10.0.0.1 #redirect-gateway def1 ##route network/IP [netmask] [gateway] [metric] COMPANY-sfo-server.conf Description: Binary data
Bug#583371: nut: usbhid-ups failing to communicate with UPS (libusb_get_report: error sending control message)
Hi Arnaud, Since the patch is only a 2 line diff [1], can you upload a targeted fix with this patch for squeeze? I strongly believe that release team will not object to this small fix which is also included in the upstream source. Also, this bug is currently RC. Thanks [1] http://boxster.ghz.cc/projects/nut/changeset/2407 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nut depends on: ii adduser 3.112 add and remove users and groups ii libc62.11.2-6Embedded GNU C Library: Shared lib ii libupsclient12.4.3-1+b1 network UPS tools - client library ii libusb-0.1-4 2:0.1.12-16 userspace USB programming library ii libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip ii udev 160-1 /dev/ and hotplug management daemo Versions of packages nut recommends: ii bash-completion 1:1.2-2programmable completion for the ba Versions of packages nut suggests: pn nut-cgi(no description available) pn nut-dev(no description available) pn nut-snmp (no description available) pn nut-xml(no description available) -- Configuration Files: /etc/nut/nut.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600166: openvpn: at start it adds >40 bogus routes not specified in configuration
Hi, On Fri, Oct 15, 2010 at 2:45 PM, Alberto Gonzalez Iniesta wrote: > I think I found the bug. But you can help me confirm this (and solve the > problem for the time being). Could you try this (on the server config): > > Change: > push "route remote_host 255.255.255.255 net_gateway" > To: > push "route OPENVPN_REMOTE_PEER 255.255.255.255 net_gateway" Yes, it works with this configuration change on the oVPN server. I'll test the deb package too. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600166: openvpn: at start it adds >40 bogus routes not specified in configuration
Hi, On Fri, Oct 15, 2010 at 3:39 PM, Alberto Gonzalez Iniesta wrote: > Could you try with this package [1]? > [1] http://etc.inittab.org/~agi/openvpn_2.1.3-2_i386.deb I've reverted the original config on the oVPN server and with the -2 package it works fine as on v2.1.0. The weird thing about pushing 'remote_host' from the server is that I have another oVPN server which has almost the same configuration but the problem was not for both. The differences on the working oVPN server are: - OPENVPN_REMOTE_PEER host is not from the REMOTE_SUBNET network (it is the external gateway); - using public IP addresses for clients (instead of private); Ok. I've found that on the working oVPN server I'm not using "push remote_host" because its not needed due to point #1. Mystery solved. :) Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#436702: bind9: unresponsive /usr/sbin/named process on amd64 arch
Package: bind9 Version: 1:9.3.4-2etch1 Severity: normal The /usr/sbin/named process became unresponsive. It didn't respond to queries, rndc failed with "could not connect" or something similar. I have sent and SEGV to obtain a core dump (about 90MB) and this is the stacktrace: (gdb) bt #0 0x2b51c4c380f5 in pthread_join () from /lib/libpthread.so.0 #1 0x2b51c49f61a7 in isc_taskmgr_destroy () from /usr/lib/libisc.so.11 #2 0x00421925 in ns_main_earlyfatal () #3 0x00421bdc in ns_main_earlyfatal () #4 0x00421f03 in ns_main_earlyfatal () #5 0x2b51c4d624ca in __libc_start_main () from /lib/libc.so.6 #6 0x0041069a in ?? () #7 0x7fffe6af8548 in ?? () #8 0x in ?? () (gdb) quit Unfortunately, no debugging symbols are found at the gdb run: Reading symbols from /usr/lib/liblwres.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblwres.so.9 Reading symbols from /usr/lib/libdns.so.22...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdns.so.22 Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /usr/lib/libbind9.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbind9.so.0 Reading symbols from /usr/lib/libisccfg.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libisccfg.so.1 Reading symbols from /usr/lib/libisccc.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libisccc.so.0 Reading symbols from /usr/lib/libisc.so.11...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libisc.so.11 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libdl.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /lib/libnss_files.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Core was generated by `/usr/sbin/named -u bind'. Program terminated with signal 3, Quit. #0 0x2b51c4c380f5 in pthread_join () from /lib/libpthread.so.0 (gdb) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages bind9 depends on: ii adduser 3.102 Add and remove users and groups ii libbind9-01:9.3.4-2etch1 BIND9 Shared Library used by BIND ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdns22 1:9.3.4-2etch1 DNS Shared Library used by BIND ii libisc11 1:9.3.4-2etch1 ISC Shared Library used by BIND ii libisccc0 1:9.3.4-2etch1 Command Channel Library used by BI ii libisccfg11:9.3.4-2etch1 Config File Handling Library used ii liblwres9 1:9.3.4-2etch1 Lightweight Resolver Library used ii libssl0.9.8 0.9.8c-4 SSL shared libraries ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip ii netbase 4.29 Basic TCP/IP networking system bind9 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505065: squid: a previous bad configuration causes start/restart to fail
Package: squid Version: 2.7.STABLE3-1 Followup-For: Bug #505065 I've encountered this problem on both 'etch' and current 'lenny' versions. This is one reproducable scenario: squid was running just fine and I've modified this following line by adding 'tproxy'. http_port 3128 transparent With this change, the squid service cannot be restarted or started: Restarting Squid HTTP proxy: squidFATAL: Bungled squid.conf line 1113: http_port 3128 transparent tproxy Squid Cache (Version 2.7.STABLE3): Terminated abnormally. failed! vision:~# lsof -i tcp:3128; netstat -atnpe | grep 3128; pgrep -fl sq 987 /usr/sbin/squid -D -YC So, the service was stopped but the process just hangs and I had to kill it. But it will not start/restart unless I remove these files: vision:~# rm -fv /var/spool/squid/swap.state* removed `/var/spool/squid/swap.state' removed `/var/spool/squid/swap.state.last-clean' (or maybe the first one is enough) In conclusion, this should be done on restart to fix unclean restarts. At least until a proper fix is found. Thanks -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages squid depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 2.7-16 GNU C Library: Shared libraries ii libcomerr21.41.3-1 common error description library ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [ ii libkrb53 1.6.dfsg.4~beta1-4 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpam0g 1.0.1-4+b1 Pluggable Authentication Modules l ii logrotate 3.7.1-5Log rotation utility ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii netbase 4.34 Basic TCP/IP networking system ii squid-common 2.7.STABLE3-1 Internet object cache (WWW proxy c squid recommends no packages. Versions of packages squid suggests: pn logcheck-database (no description available) pn resolvconf (no description available) pn smbclient (no description available) pn squid-cgi (no description available) pn squidclient(no description available) pn winbind(no description available) -- debconf information: squid/fix_cachedir_perms: false squid/fix_lines: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698218: roundcube-core: maybe remove obsolete entries from /e/r/htaccess?
2017-09-10 19:47 GMT+03:00 Sandro Knauß : > just for me to understand, you are asking for the default deactivated parts to > be updated? Or are you suggesting to enable them by default? Because from your > inital report you only mention deactivated lines: > # http://bugs.php.net/bug.php?id=30766 > #php_value mbstring.func_overload 0 > > # replace 'append' with 'merge' for Apache version 2.2.9 and later > #Header append Cache-Control public env=!NO_CACHE At that time I was asking to have both deactivated by default in Debian.
Bug#644240: bat: ASSERT failure in QList::operator[]: "index out of range"
Hi, 2016-09-21 0:58 GMT+03:00 Carsten Leonhardt : > do you still have this problem with a current bacula version? I cannot test this anymore, from what I know they (old job) still use the old bacula version. I suppose you can close this bug. Thanks
Bug#693114: dovecot-core: Mailboxes inaccessible after upgrade
Hi, Considering that mailbox auto detection is not always working, I recommend to just add a big NEWS entry telling people to manually set the 'mail_location' parameter in /etc/dovecot/local.conf. I've always set this parameter manually, but after reading how much problems it could cause I prefer to keep it in /etc/dovecot/local.conf to avoid it from being replaced on upgrades. Of course, the default config *must* not set this parameter (leave it as an example). Cheers -- my local.conf -- mail_location = maildir:~/mail -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698218: roundcube-core: maybe remove obsolete entries from /e/r/htaccess?
2013/1/15 Vincent Bernat : > We are shipping htaccess as shipped by upstream. I see little reason to > change it just because they may be obsolete but harmless. Note that the > first one is not commented by default. Using the files from upstream is always a good idea. But again some of these files (like htaccess) is constructed by upstream to cover all distros, thus it makes sense for them to add notes about Apache version but in Debian is not a question, it is certain. So, some of these parameters can be adjusted for Debian if necessary. Back to technical discussion, please at least add a note in README.Debian why these are recommended and what problem do they fix. I haven't had a problem by not using them, but maybe upstream developers have more knowledge. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695610: opendkim: fails to configure
Hi Scott, 2013/1/7 gustavo panizzo : > i have opendkim installed, but disabled at boot time (update-rc.d opendkim > disable). > when the packages gets upgraded, i got that error. > this problem only appears on my laptop, where i keep opendkim installed but > not running (for documentation proposes) Considering this scenario this is probably RC severity for not being able to upgrade if service is stopped. Considering that the fix is small maybe it can be fixed for Wheezy too? Cheers (I though you would included this fix together with #695145 but it seems that you forgot about it) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687602: retext: should restore the window position and size at startup
2013/1/12 Dmitry Shachnev : > Hm, I probably was not clear enough: you need to add > "saveWindowGeometry=true" (w/o quotes) to ~/.config/ReText > project/ReText.conf to get that working. See > https://sourceforge.net/p/retext/wiki/Configuration%20file/ for > details. Thanks for this explanation. Why not default to "true" instead of "false"? I don't think there should be an option to disable this function, I know no other application that does this. You could use a separate config file (in .config/retext) like "position" for these properties that are not for the user to edit manually. Also, looking at .config directory any other Linux application is using just its name for user preferences (lower case). Why not do the same for retext? Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694046: bacula-common: missing 'create' directive in logrotate.d/bacula-common
2012/11/23 Teodor :
> Please improve /etc/logrotate.d/bacula-common file with:
>
> /var/log/bacula/log {
> create 0644 bacula bacula
Actually, the group should be 'adm' and no read permissions for others:
create 0640 bacula adm
Cheers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707550: opu: package php-mdb2/2.5.0b2-1
Hi, 2014/1/21 intrigeri : > Hi, > > Teodor, ping? I don't have the necessary experience to make this source debdiff. Thomas, are you still interested in uploading this (simple) patch for squeeze? Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716762: [buildd-tools-devel] Bug#716762: sbuild maybe should end the session after package build?
Hi, 2013/7/13 Roger Leigh : > On Fri, Jul 12, 2013 at 03:15:05PM +0300, Teodor wrote: >> I've noticed that after upgrade to Debian 7, sbuild doesn't end the >> schroot session anymore. This is confirmed by the log too: >> | Not removing build depends: as requested This bug report is not about this line... >> | Keeping session: wheezy-amd64-sbuild-... .. but about this one. >> This is not consistent with schroot behaviour where the session is >> automatically handled per schroot(1) default --automatic-session. > > This is controlled through the sbuild PURGE_BUILD_DEPS configuration > option ($purge_build_deps = 'always|successful|never' or the --purge-deps > or --purge command-line options. > > Are you sure that this is not being set to "never" either in > /etc/sbuild/sbuild.conf, .sbuildrc or on the command-line? I agree with you that dependency handling is done as requested, in my case not via the configuration file (default) but via command line options: "--purge=never --purge-deps=never" However, this bug report is about sbuild *leaving* the schroot session open at the end of the package build. I believe that sbuild should automatically end the schroot session, session automatically created to build the package. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620825: bacula-director-common: wrong email From address
Hi, I'm using this configuration in Messages: mailcommand = "/usr/sbin/bsmtp -h SMTPHOST -f \"Bacula \\" -s "[..]" The main reason is to have the real address instead of the fake <%r> which could be rejected at the destination. This same address is added automatically by 'bsmtp' on Sender: header. What I would like is to have a parameter (like %r) for the local host name that I could use instead of specifying the FQDN. Regarding <> this is mandated by strict RFC email rules. It's probably common to activate 'strict_rfc821_envelopes = yes' in Postfix to block unsolicited messages. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699149: [pkg-bacula-devel] Bug#699149: bacula-fd: should not run as 'root' by default
2013/1/29 Alexander Golovko : >> ARGS="-u bacula -g bacula -k" >> >> I think that from a security perspective this should be the default >> on package installation. > > This will lead to impossibility to restore backups without > restarting bacula-fd. This is also can require changing user scripts > for dump databases and such. This can confuse peoples. I'm having this setup and I can restore backups just fine. Of course, the restore directory must be rwx by bacula or mode 1777. About the other thing (ie. dump databases), I can't tell. > I think, we should not change defaults, however, this functionality > described in README.Debian.gz (USERS & SECURITY). But you do for bacula-dir and bacula-sd, why not for bacula-fd? > bacula-fd init script correctly work without /e/d/bacula-fd. Right. I thought that it depends on setting ENABLED="yes" but I see now that it checks for "no". > But there is a reason for set defaults in init scripts for > bacula-director and bacula-sd and comment defaults in /e/d/bacula-* Can you detail a little? I don't understand what you're trying to say. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699149: bacula-fd: should not run as 'root' by default
2013/1/31 Alexander Golovko :
> You lose files owner/group and acl on restoring.
That's not a big deal comparing with the increased security.
> /e/d/bacula-{dir,sd} has nonempty ARGS and bacula-{director,sd} will be
> incorrectly runned under root privileges if defaults file missed.
>
> This should be changed.
Yes, you should set the defaults in the init script (not in
/etc/default/FILE) just like you do for $CONFIG.
> Also, there is a reason, that we should provide
> defaults in /e/d/bacula-* as comments. I think, this is will not be
> included into wheezy, but it should be fixed in next versions.
OK. Please, no more double settings like this:
# CONFIG="/etc/bacula/bacula-fd.conf"
CONFIG="/etc/bacula/bacula-fd.conf"
Cheers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699442: fail2ban: please add configuration for roundcube
2013/1/31 Yaroslav Halchenko : > would you mind also providing sample log lines demonstrating this > failed attempts? These are like this: [22-Jan-2013 22:28:21 +0200]: FAILED login for user1 from 109.97.x.x [23-Jan-2013 12:53:09 +0200]: FAILED login for user2 from 79.117.x.x [25-Jan-2013 21:54:17 +0200]: FAILED login for user3 from 193.231.x.x > ideally you could submit a pull request against fail2ban on > https://github.com/fail2ban/fail2ban/ > with sample log lines provided under testcases/files/logs/roundcube.conf For this I probably need to clone the project.. which I don't think it's worth the trouble. > And is this location standard on debian'provided installations of > roundcube? > >> | logpath = /var/log/roundcube/userlogins Yes, this is the standard location on Debian. This function is actually provided by the fail2ban plugin [1] for roundcube, not by Roundcube itself. Cheers [1]: http://mattrude.com/projects/roundcube-fail2ban-plugin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699794: [Popcon-developers] Bug#699794: popularity-contest: should work without a local SMTP/sendmail
2013/2/5 Petter Reinholdtsen : > popcon work without SMTP. It will first try using http for delivery, > and only if this fail will it try to send email. If http delivery > fail, it will syslog a message about this. That would be great. However, I've seen this fail both from my work network (with firewall restrictions) and on other networks with no restrictions. > I suggest you investigate why http delivery fail to figure out why > this isn't working for you. Does it try to connect to some other non-standard HTTP port? (not 80 or 443). A destination host name would help too. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699794: [Popcon-developers] Bug#699794: Bug#699794: popularity-contest: should work without a local SMTP/sendmail
2013/2/5 Petter Reinholdtsen : > It should try to connect to popcon.debian.org. > > See SUBMITURLS in /usr/share/popularity-contest/default.conf for the > default URLs, and /etc/cron.daily/popularity-contest for the program > deciding how to submit the information. Looking at that script I see that I can disable email reporting by adding "MAILTO=" in /e/p-c.conf. I've re-enabled popcon on all Debian hosts. How can I monitor if popcon via HTTP fails from now on? Does it write anything to syslog? Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710571: Patch for /lib/lsb/init-functions
2013/6/3 Didier 'OdyX' Raboud : > I have now also re-read the #683654 bugreport and got more convinced that > changing these logging functions is a really bad idea. The biggest blocker > that I see is the output that one gets when managing services by hand: if one > setups VERBOSE=no in /etc/default/rcS, then any service action (such as # > service cups restart) will log exactly no output to the console, while now you > get a useful message. My initial proposal was only for [info] messages to be suppressed if VERBOSE=no. Indeed, VERBOSE=no should not block important messages. After all, not being verbose not does equal being quiet. This VERBOSE mechanism is flawed by the „all or nothing” choice. One fast solution (not necessary a good one) is to add a new variable QUIET=yes to suppress important messages, but what about critical or error messages? :-( Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
2013/6/5 Dmitry Smirnov : > `pgrep` is searching for substring in process name. For example if I > have `konsole` running the `pgrep konso` will return PID even though > there is no process "konso" running. > > "proc.num" is checking for exact process name so it will return > 0 for `zabbix_get -s localhost -k 'proc.num[konso]'` > and > 1 for `zabbix_get -s localhost -k 'proc.num[konsole]'` I know, that's why I wrote the console output. In my case, 'spamd' is the exact process name. | $ pgrep -l spamd | 854 /usr/sbin/spamd | 858 spamd child | 859 spamd child Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711037: zabbix-agent: proc.num[spamd].last(0) always at 0
Hi, 2013/6/5 Dmitry Smirnov : > `pgrep --exact spamd | wc -l` > or > `pgrep --count --exact spamd` > > would be an equivalent of > > `zabbix_get -s localhost -k 'proc.num[spamd]'` Weird, not even 'pgrep' can count them even if 'spamd' is running. This might have the same cause. | $ pgrep --count --exact spamd | 0 | $ pgrep --count --exact spamass-milter | 1 As noted in the first message, this is a false alert only when counting 'spamd' processes. All the other proc.num monitoring is working fine. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711037: zabbix-server-mysql: proc.num[spamd].last(0) always at 0
Hi, 2013/6/7 Craig Small : > I'm the procps maintainer (Debian and upstream). Dmitry asked me to > have a look at this bug as pgrep was discussed. My first impression > is that there is some confusion between command line and process name. > > Digging deeper, that is the correct impression. Indeed, now I see that all the other correctly monitored processes don't have the full path, only '/usr/sbin/spamd' has it. > So, we have a process, pgrep finds it, zabbix_agent doesn't. Obviously > they are doing things differently, but what? Actually, not even pgrep finds it if --exact or -x is used. That is because if looks for an exact match of "spamd" but there is "/usr/sbin/spamd". It's not clear why it doesn't find the child processes: | # pgrep -fl spamd | 31238 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -d | --pidfile=/var/run/spamd.pid | 31246 spamd child | 31247 spamd child Comparing 'spamd' with 'spamass-milter' I see this: | # ps -e -o pid,comm,cmd -f 31238 | PID COMMAND CMD | 31238 /usr/sbin/spamd /usr/sbin/spamd --create-prefs [..] | # ps -e -o pid,comm,cmd -f 3841 | PID COMMAND CMD | 3841 spamass-milter /usr/sbin/spamass-milter -P [..] | # ps -e -o pid,comm,cmd -f 31246 | PID COMMAND CMD | 31246 spamd child spamd child > So why did spamd not show up? My strong assumption is that its command > line looks different to its process name. There might be something else > happening here, but at the very least you can easily discount this. Maybe this is a bug in 'spamd' that is registers bogus process names (ie. full path). Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711826: no more unattended upgrades since Wheezy is out
2013/6/10 Harald Dunkel :
> Since Wheezy is out the unattended-upgrades for Squeeze
> don't work anymore. The default configuration in
> /etc/apt/apt.conf.d/50unattended-upgrades says
>
> Unattended-Upgrade::Allowed-Origins {
> "${distro_id} stable";
"stable" == "wheezy" now, thus you probably need to update your config
with "oldstable".
Cheers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711826: no more unattended upgrades since Wheezy is out
2013/6/14 Harald Dunkel : > Changing config files for 1 or 2 PCs is not the problem. > The problem is, that its not unattended anymore. I have > to access appr. 150 servers, desktops and laptops to > make this work again. Thats a lot of work for a package > that promised to do its job silently in the background. You can easily deploy such a small replace on your network with several tools (clusterssh / pssh / puppet). > I would highly appreciate a better solution for Wheezy > without breaking things when Jessie comes out. How is this "breaking things"?! U-A does what was instructed to do. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702150: [Dctrl-tools-devel] Bug#702150: dctrl-tools: -X should match on "NAME (VERSION)" too
2013/3/3 Antti-Juhani Kaijanaho > > By using '-X' some times not all packages are selected: > > > > Package: python2.7 > > Source: python2.7 (2.7.3-7) > > This is the expected result, hence downgrading to wishlist. > -X is supposed to check if the field in question (in this case, Source, or if > it is missing, Package) contains the string (in this case $PKG) and nothing > else. This is not expected at all. You see that the name in question has an exact match? > > I thing that »grep-dctrl -X« should match on "NAME (VERSION)" too. > > I think changing the defined meaning of -X that radically is out of the > question. > Providing another flag to do what you are reqesting is possible, though the > question of exactly what it *should* match is not clear. Can you give me a > regexp, for example? This is not a radical change. A regex could be found, the question is would you accept it. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
2013/3/7 g0to :
> -- Configuration Files:
> /etc/apt/apt.conf.d/50unattended-upgrades changed:
> // Automatically upgrade packages from these origin patterns
> Unattended-Upgrade::Origins-Pattern {
> // Codename based matching:
> // This will follow the migration of a release through different
> // archives (e.g. from testing to stable and later oldstable).
> "o=Debian,n=wheezy";
> "o=Debian,n=wheezy-updates";
> "o=Debian,n=wheezy-proposed-updates";
> "o=Debian,n=wheezy,l=Debian-Security";
This config was removed in version 0.79.5 and might not work at all:
- remove codename based matching example as this needs a newer
python-apt than available in wheezy, thanks to Russell Stuart
> // Archive or Suite based matching:
> // Note that this will silently match a different release after
> // migration to the specified archive (e.g. testing becomes the
> // new stable).
> // "o=Debian,a=stable";
> // "o=Debian,a=stable-updates";
> // "o=Debian,a=proposed-updates";
> // "origin=Debian,archive=stable,label=Debian-Security";
> };
Usually this is what you need to enable, plus an extra line if you are
using "testing" or "unstable".
Cheers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702509: unattended-upgrades: does not run autonomously, even after it was enabled
control: -1 severity normal 2013/3/8 Arturo Moral : >> This config was removed in version 0.79.5 and might not work at all: > > I'm currently using 0.79.4, therefore the config change does not affect me, > right? You should not use it, 0.79.5 will migrate to testing on the following days. > Anyway, my main issue is that the unattended upgrades don't run. If it would > be only a config file problem, they would run but with no upgradable > candidates. You didn't show that u-a doesn't work. From what we've seen so far it works as expected, maybe you need to investigate why Cron doesn't run?! Do you know for sure that there are packages to be upgraded? Running "apt-get upgrade" will tell you. If "apt-get" doesn't find packages to be upgraded, neither does u-a. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652719: unattended-upgrades: unexpected daily "conffile prompt" messages from Cron
I would like to close this report, but I don't know on which version it was fixed. Michael, if you can determine that from the bzr repo history, please close this report with the correct version number. From my point of view the problem appears to be fixed a long time ago. 2013/3/13 Tomas Pospisek : > On my part I am completely happy with the current behavior - i.e. getting > emails from unattended-upgrades, when dpkg is in need of some input from the > user. I woudn't describe it like this, but that's not important. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710571: Patch for /lib/lsb/init-functions
This topic was discussed with LSB maintainers on #683654. Maybe these two bugs should be merged, but I don't know if the discussion will be preserved. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683654 2013/6/1 Josh Triplett : > The attached git patch makes the log_* functions in > /lib/lsb/init-functions check $VERBOSE before outputting anything. > > - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696332: lsb-release: release/codename depend on a successful apt-get
Control: block 685355 by 696332 2013/5/21 Didier 'OdyX' Raboud : > Even if your log confirms that, I can't reproduce this behaviour on jessie. I cant test on „jessie/testing” but this affects at least unattended-upgrades on „wheezy/stable”. See bug #685355 for details. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676660: radicale: please package new upstream version 0.7.1
Package: radicale Version: 0.7-1.1 Severity: wishlist Hi, Please package version 0.7.1 for the following reasons: - [acl/IMAP.py] adds IMAP authentication module - [acl/PAM.py] fix PAM group membership check - [acl/courier.py] some fixes for courier auth Unfortunately, PAM auth will still doesn't work with python-pam and can be addressed later. A short diff review shows that there are no intrusive changes, thus it could be a candidate for inclusion in Debian 7.0 wheezy via a point release (7.0.x, x=1|2|3..). Cheers -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages radicale depends on: ii adduser 3.113+nmu3 ii python 2.7.3-4 ii python-radicale 0.7-1.1 radicale recommends no packages. Versions of packages radicale suggests: pn apache2-utils pn courier-authdaemon pn python-ldap ii python-pam 0.4.2-13 -- Configuration Files: /etc/default/radicale changed [not included] /etc/radicale/config changed [not included] /etc/radicale/logging changed [not included] -- no debconf information
Bug#360735: openswan: 'pluto' terminated with signal 11, Segmentation fault.
Package: openswan Version: 1:2.2.0-8 Followup-For: Bug #360735 We are trying to create a VPN tunnel with IPSec between two networks. At one point we have version 2.4.5 and at the other end we have 2.2.0-8 from a pure Debian Sarge distribution. As I have read from 'bugs.debian.org' the problem is somehow at both versions of 'openswan'. The fix was released for version 2.4 in Debian, but not for the version 2.2. Bellow is the line that I consider to be a start point in fixing the problem for 2.2 version of openswan for the stable release: Jun 30 02:47:53 chamisa pluto[1110]: "provo-slc" #2: ASSERTION FAILED at kernel.c:2037: st->st_esp.keymat_len == (key_len + ei->authkeylen) I've found this line in the logs every time I'm trying to start the IPSec connection from the other point. Strange is that this does not happen when I execute 'auto --up' from the Debian server. I've added the line 'dumpdir=/tmp' in /etc/ipsec.conf file and from the core dump I've got this information: chamisa:~# gdb /usr/lib/ipsec/pluto /tmp/core GNU gdb 6.3-debian This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `/usr/lib/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /usr/lib/libgmp.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgmp.so.3 Reading symbols from /lib/tls/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libresolv.so.2 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400d533b in strlen () from /lib/tls/libc.so.6 I do not know which other tests to run at this time but I'll come back later with other informations if found. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages openswan depends on: ii bsdmainutils 6.0.17 collection of more utilities from ii debianutils 2.8.4 Miscellaneous utilities specific t ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii host 2331-9 utility for querying DNS servers ii iproute 20041019-3 Professional tools to control the ii ipsec-tools 1:0.5.2-1sarge1IPsec tools for Linux ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an ii libgmp3 4.1.4-6Multiprecision arithmetic library ii libssl0.9.7 0.9.7e-3sarge1 SSL shared libraries ii makedev 2.3.1-77 creates device files in /dev ii openssl 0.9.7e-3sarge1 Secure Socket Layer (SSL) binary a -- debconf information: openswan/existing_x509_key_filename: * openswan/x509_state_name: Utah * openswan/x509_email_address: [EMAIL PROTECTED] * openswan/x509_country_code: US * openswan/x509_self_signed: true * openswan/rsa_key_length: 2048 * openswan/restart: true * openswan/start_level: earliest * openswan/enable-oe: false * openswan/x509_organizational_unit: Technical Dept. * openswan/x509_locality_name: Provo * openswan/existing_x509_certificate: false openswan/existing_x509_certificate_filename: * openswan/x509_common_name: chamisa.museglobal.com * openswan/create_rsa_key: true * openswan/rsa_key_type: x509 * openswan/x509_organization_name: MuseGlobal Inc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385469: smbfs: '+' character beggins a comment in '/etc/samba/smb.conf' configuration file
Package: smbfs Version: 3.0.22-1 Severity: minor After package 'smbfs' installation the default configuration file contains a '+' character at the beggining of a comment line. The request for the maintainers is to check the post-install scripts in order to create the configuration file without this character. Bellow you will a few commands that will explain the situation: [EMAIL PROTECTED]:~$ mount -t smbfs //SERVER/SHARE SHARE_DIR params.c:Parameter() - Ignoring badly formed line in configuration file: +## Domains ### [EMAIL PROTECTED]:~$ grep Domains /etc/samba/smb.conf +## Domains ### -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages smbfs depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcomerr2 1.39-1common error description library ii libkrb53 1.4.4~beta1-1 MIT Kerberos runtime libraries ii libldap2 2.1.30-13+b1 OpenLDAP libraries ii netbase4.25 Basic TCP/IP networking system ii samba-common 3.0.22-1 Samba common files used by both th smbfs recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
