Bug#861169: systemd service overrides opendkim.conf

If we could update /etc/default/opendkim to mention /lib/opendkim/opendkim.service.generate it would be at least something to save debugging hours. One can only wonder how many sysadmins are scratching their head right now, and how many will be after imminent upgrade to stretch.

Bug#848011: [Aptitude-devel] Bug#848011: aptitude doesn't ask for confirmation of removal for "markauto", leading to surprise removals

> Every package from the list for which there's no "why" found will be > silently, with no > indications whatsoever, scheduled for removal. If you were doing this from a > script, or > just copying and pasting code from somewhere, you'll be in trouble. Next time > you happen > to install

Bug#848011: [Aptitude-devel] Bug#848011: aptitude doesn't ask for confirmation of removal for "markauto", leading to surprise removals

> > Moreover, to reinstantiate it one should use install command but not markauto: > > aptitude markauto foo # has no effect > aptitude install foo # really removes the flag > > Which is another source of confusion. See, there's more to the confusion now. > That should read unmarkauto: aptitude

Bug#848011: [Aptitude-devel] Bug#848011: aptitude doesn't ask for confirmation of removal for "markauto", leading to surprise removals

On Tue, Dec 13, 2016 at 7:21 PM, Axel Beckert wrote: > If you insist on the old behaviour, you can call e.g. "aptitude > markauto … && aptitude install" ("aptitude install" without any > further parameter) as a workaround. Not nearly close to the previous behavior. Even if I

Bug#848011: aptitude doesn't ask for confirmation of removal for "markauto", leading to surprise removals

Package: aptitude Version: 0.8.3-1+b2 Severity: important Dear Maintainer, Before 0.8.3 aptitude asked if one wants to remove a package if marked as autoinstalled. Since version 0.8.3 aptitude's behavior irreversible changed, breaking all preexisting assumptions. Now it doesn't ask at all,

Bug#732251:

Fixed in the upstream: https://github.com/slact/nginx_http_push_module/issues/83#issuecomment-37508708 https://github.com/slact/nginx_http_push_module/commit/836e8319c93681386fb00e6bd34d9e37612f3334 WBR --- debian/modules/nginx-http-push/src/ngx_http_push_module_setup.c 2014-03-13

Bug#576301: tsocks: fails if socksified application uses poll(2)

I confirm there is same problem with PHP. Supplied patch fixes the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#575474: /bin/tar: Segfault with both --exclude-caches and --exclude-tag=TAG

Package: tar Version: 1.20-1 Severity: normal File: /bin/tar $ tar -cvf test.tar --exclude-caches --exclude-tag=TEST.TAG test/ test/ Segmentation fault (core dumped) $ tar -cvf test.tar --exclude-caches test/ test/ test/test2/ test/test1/ test/test1/TEST.TAG $ tar -cvf test.tar

Bug#575474: Acknowledgement (/bin/tar: Segfault with both --exclude-caches and --exclude-tag=TAG)

tar 1.23 is not affected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#575474: Acknowledgement (/bin/tar: Segfault with both --exclude-caches and --exclude-tag=TAG)

Also, no segfault when using: --exclude-tag=CACHEDIR.TAG --exclude-tag=TEST.TAG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org