Subject: bash interaction with ssh causes it to read .bashrc despite being
non-interactive
Package: bash
Version: 5.0-4
Severity: normal
When SSHing into a machine using bash as the shell, launching asynchronous
sub-shells in that shell causes the sub-shell to execute /etc/bash.bashrc and
Package: libgtk-3-0
Version: 3.22.11-1
When I start Emacs using an X server which only provides XInputExtension 1.3,
Emacs immediately exits when the mouse enters the Emacs window.
---%<---
> emacs
X protocol error: BadRequest (invalid request code or no such operation) on
protocol request 131
This is fixed in 3.3.6; I have successfully tested it using the
following amanda-client package:
# apt-cache showpkg amanda-client
Package: amanda-client
Versions:
1:3.3.6-4
(/var/lib/apt/lists/ftp.de.debian.org_debian_dists_jessie_main_binary-am
d64_Packages) (/var/lib/dpkg/status)
Description
This is an upstream bug fixed in 3.3.6 (see
http://archives.zmanda.com/amanda-archives/viewtopic.php?t=7322sid=aa51
6467b5baa942a8b4f34dda49eefd).
According to the author this is fixed by the following commit:
https://github.com/zmanda/amanda/commit/aaae124a5a8819fcdc0136cfb6ad3531
18c2fc4c
--
Short update: it looks as if the server is already decompressing the
dump before sending it to the client.
When replacing the custom compression script on the client by a script
just calling cat -, the restore works.
Regards,
Markus
--
To UNSUBSCRIBE, email to
I just ran into the exact same problem using below mentioned versions
for server and client.
I am using a custom compression script, and the client log for the
failed recovery contains the following lines:
Mon Jan 19 11:05:59 2015: thd-0x199da00: amrecover: image is compressed
/etc/amanda/xz-1
No further segmentation faults of apt-cacher have been observed up to
now. Looks like the suggested patch does indeed solve the observed
problem.
Markus
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Status update: The system now runs for 9 days with the patched libperl.
No further segmentation faults of apt-cacher have been observed.
Markus
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Niko Tyni wrote:
Markus, if this is reproducible enough for you would you like to test
if the fix works? You could rebuild the perl package yourself with the
patch (it applies cleanly against 5.10.1), or I can provide you the
.debs if you like.
Meanwhile I have built new perl packages
Package: apt-cacher
Version: 1.6.12
Severity: normal
apt-cacher segfaults at random intervals when clients are accessing the cache.
From /var/log/messages:
---%---
Nov 24 15:35:43 camoscm2 kernel: [616289.995097] apt-cacher.pl[9964]: segfault
at a80 ip 7f9ec2485122 sp 7fffc4fdfef0
Mark Hindley wrote:
[...]
This must be a problem in the perl engine somewhere rather than
apt-cacher itself. I notice you are using CGI mode which could also
point to the apache perl module as well. A perl script, like
apt-cacher, shouldn't be able to crash the perl engine.
Agreed.
Have
Niko Tyni wrote:
[...]
Markus, if this is reproducible enough for you would you like to test
if the fix works? You could rebuild the perl package yourself with the
patch (it applies cleanly against 5.10.1), or I can provide you the
.debs if you like.
The crash happens about once or twice a
Niko Tyni wrote:
apt-cacher segfaults at random intervals when clients are accessing
the cache.
Is this visible to the clients? I.e. does it cause any actual problem
like incomplete responses?
Forgot about that one...
No, the downloads in apt seem to work without any apparent problem,
at
Package: mailman
Version: 1:2.1.13-4.1
Severity: important
After a fresh install of mailman, permissions on directories are wrong,
bin/check_perms reports 93 problems.
This breaks archiving:
---%---
Nov 18 10:56:06 2010 (26393) Archive file access failure:
Ludovic Brenta wrote:
Thank you for the nice bug report. I've forwarded it upstream to the
GCC people. I am not in a position to try gnat-4.3 right now; can
you tell me if the bug is also present there (or in a previous
version)? If not, it is a regression in gnat-4.4 and therefore the
15 matches
Mail list logo
