On Tuesday 15 June 2021 at 03:51:03 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the minicom package:
>
> #989735: minicom: stack smashing when searching in history buffer
>
> It has been closed by Debian FTP Mast
Hi Adam,
On Monday 14 June 2021 at 09:16:51 +0200, Adam Lackorzynski wrote:
> Ok, thanks. Meantime I changed all of this static memory handling to be
> more dynamic, also addressing this case I believe. The 'magic' constant
> is gone, so hopefully any of those cases.
Thanks for the extremely quic
On Sunday 13 June 2021 at 21:22:32 +0200, Adam Lackorzynski wrote:
> thanks again. I wonder why it did not reproduce for me earlier.
> Could you try attached patch and report back?
Hi Adam,
Thanks for the patch. It did seem better. However, when I do a
case-insensitive search I now get:
Hi Adam,
Thanks for the speedy response.
On Sunday 13 June 2021 at 17:25:20 +0200, Adam Lackorzynski wrote:
> Hi,
>
> thanks for the report. The issue has always been there and had to do
> with the width of minicom's window (over 256 columns). I have addressed
> this.
Aha. I switched font at a
Package: minicom
Version: 2.8-1
Severity: important
Steps to reproduce:
1. Start Minicom connected to a serial port with MINICOM="-m -c on -8"
(although I was also able to reproduce the problem with MINICOM="" if the
keystrokes below are changed appropriately.)
2. Cause whatever is connected to
n Sep 17 00:00:00 2001
From: Mike Crowe
Date: Fri, 6 Nov 2020 15:22:37 +
Subject: [PATCH] [SV 45763] Fix large command line on POSIX systems
When presented with a very long command line (as is common when linking
a large number of files with absolute paths in a deep subdirectory),
make
ANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit f079489160d620e5eb50dc09e51f09f71a7dcffb
Author: Mike Crowe
Date: Fri Nov 6 15:22:37 2020 +
Resurrect fix for large c
Package: exim4
Version: 4.92-8+deb10u3
Severity: wishlist
The remote_smtp transport in
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp contains lines
like:
.ifdef DKIM_PRIVATE_KEY
dkim_private_key = DKIM_PRIVATE_KEY
.endif
to set the DKIM variables based on macro values. These lines a
It appears that Buster's version of taglib:
ii libtag1v5:amd64 1.11.1+dfsg.1-0.3 amd64audio meta-data
library
now writes ID3v2.4 tags by default (and uses the new UTF-8 text encoding
too.) This means that any program that uses this library (lots of KDE
perhaps?) will make files
I disabled the Media Player Indicator extension in Tweaks, yet the
play/pause button has just stopped working again.
I probably should have mentioned earlier that I'm running on Wayland. This
appears to mean that I can't try restarting gnome-shell to see if that
fixes the problem.
Mike.
It appears that normal behaviour of the play/pause button returns if I log
out and log back in again. A full reboot is not required.
Mike.
Package: gnome-shell
Version: 3.30.2-9
Severity: normal
I use Totem to listen to long media files and pause/resume them using the
Play/Pause button on my keyboard. After a while (sometimes a few hours,
sometimes a few days) this button stops working. Pressing it has no effect on
Totem, Rhythmbox o
Control: tags -1 + fixed-upstream
The workaround is included in upstream v4.19.35 onwards:
b787544dc5e707fec86161b881391eb9342806e6.
Mike.
It's just happened to me again and I was able to collect some more details.
1. The play/pause media key on my keyboard can still be used to play/pause
the track.
2. The "Videos is not responding" popup appears over the Totem window when
I try to focus it.
3. I captured the following strace when
Package: totem
Version: 3.30.0-4
Severity: normal
Since upgrading to Buster recently, the Totem user interface has started
hanging whilst I listen to M4A audio files that are several hours long.
Sometimes it does so whilst playing (playback continues) and sometimes whilst
paused. The user interfac
Control: found -1 linux/4.19.28-2
Control: tags -1 + patch
The upstream maintainer has provided a workaround[1] for this which has
apparently been queued[2] for stable, so I imagine that the fix will be
merged in due course.
Mike.
[1]
https://lore.kernel.org/netdev/e2e76e38-3155-e421-deeb-4ec05
Control: reopen -1
Control: found linux/4.19.28-2
Control: tags upstream
I wrote:
> However, this inspired me to check the BIOS version on the Asus H87M-E
> motherboards we're using. Both were using the rather ancient version
> 1001. I upgraded one machine to the latest version 2201 and the proble
I've tested some other kernel versions. In the description below, "fast"
means that the NFS clients booted quickly (~20s) whereas "slow" means that
the NFS clients booted slowly (~100s).
In all cases, rx-usecs=200, rx-frames=4.
Debian versions:
v4.18.0-3-amd64: fast (not tested recently)
v4.19.0
Package: src:linux
Version: 4.19.16-1
Severity: normal
After upgrading the "server" from Stretch to Buster, performance of our
embedded client devices which mount their root filesystem over NFSv2 from
said server dropped considerably. The time from mount to full system
operation of these clients w
Package: tmux
Version: 2.8-1
Severity: normal
Dear Maintainer,
tmux 2.8 contains a change in behaviour compared to previous versions when
the current directory differs from the contents of the PWD environment
variable:
Consider running the following at a shell prompt in a tmux session:
cd /
P
Previously, I wrote:
> A few days after upgrading to Stretch and its 4.9 kernel we got an RCU
> stall in the middle of the night:
A series of very-similar-looking RCU stalls happened again a week later.
The machine is under moderate load most of the time.
I switched to running Jessie's kernel, an
Package: src:linux
Version: 4.9.30-2+deb9u2
Severity: important
Dear Maintainer,
This particular machine has successfully been running Debian for many
years, through Lenny to Jessie. It looks like I needed to add
"nointremap" to the kernel command line when it was upgraded to Wheezy
back in 2013.
I ran into what appeared to be an identical deadlock today when rsyncing a
directory hierarchy between two local directories. I too had all three
rsync processes all stuck inside a select system call with a sixty second
timeout.
I was executing:
rsync --delete-before --exclude 'pattern.*' -vat /
On Friday 27 January 2017 at 09:48:22 +0100, Uwe Kleine-König wrote:
> Independent of this changing the default TFTP_ADDRESS to ":69" to get
> ipv6 connectivity would be nice. Or maybe still better to ":tftp".
Indeed. As I wrote in message #95, the debconf question for TFTP_ADDRESS
even implies th
Package: dgit
Version: 1.0
Severity: wishlist
I recently tried to run:
dgit clone tftpd-hpa
I was greeted with:
canonical suite name for unstable is sid
starting new git history
no version available from the archive
dgit: package tftpd-hpa does not exist in suite unstable
It turns out tha
On Sat, 29 Nov 2014 16:09:09 +, I wrote:
> The attached patch is my attempt to change the default.
Unfortunately, I appear to have generated the patch backwards which is
somewhat confusing. I hope that this one is correct.
Mike.
diff -ruN tftp-hpa-5.2+20150808.before/debian/po/cs.po tftp-hpa-
On Thursday 06 October 2016 at 13:01:07 +1030, Ron wrote:
> > The current tftpd-hpa package defaults to being available on all interfaces
> > via an IPv4 address. In Message #25, Ron rightly questioned whether this is
> > still a sensible default. But, as I said in Message #30, I don't believe
> >
[It seems that I forgot to subscribe to this bug so I didn't see that there
had been activity since the original exchange.]
In Message #75 2015-05-22 13:35 GMT+02:00 Ron wrote:
> It's not only tftp-hpa that would get burned by this. Any network
> using service that needs to resolve or use an add
Package: emacs24
Version: 24.4+1-5
Severity: normal
Tags: upstream patch
Dear Maintainer,
Emacs 24.4 and 24.5 suffer from a signal-handling bug which can cause X11 Emacs
to hang during a paste/yank operation. This was reported as an Emacs bug at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16737
I seem to be seeing the same problem on:
3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
with:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)
Subsystem: Intel Corporation Device 2002
Flags: bus master, fast de
Package: src:linux
Version: 3.2.65-1+deb7u2
Severity: normal
Dear Maintainer,
Upon upgrading my linux-image-3.2.0-4-amd64 package from
3.2.65-1+deb7u1 to 3.2.65-1+deb7u2 it appears that my bridge device is
no longer able to pass (at least some) multicast packets.
I've reproduced the problem on t
On Sunday 30 November 2014 at 08:05:46 +1030, Ron wrote:
> On Sat, Nov 29, 2014 at 08:32:05PM +0000, Mike Crowe wrote:
> > But I don't think that the default of :69 is any worse than 0.0.0.0:69
> > would be though - unless you have a deep distrust of anyone on IPv6. :)
>
On Sunday 30 November 2014 at 06:40:26 +1030, Ron wrote:
> On Sat, Nov 29, 2014 at 07:14:16PM +0000, Mike Crowe wrote:
> > On Sunday 30 November 2014 at 05:25:10 +1030, Ron wrote:
> > > On Sat, Nov 29, 2014 at 04:09:09PM +, Mike Crowe wrote:
> > > > When a Whee
Hi Ron,
Thanks for quick response.
On Sunday 30 November 2014 at 05:25:10 +1030, Ron wrote:
> On Sat, Nov 29, 2014 at 04:09:09PM +0000, Mike Crowe wrote:
> > Package: tftpd-hpa
> > Version: 5.2+20140608-3
> > Severity: important
> > Tags: patch
> >
> > Dea
Package: tftpd-hpa
Version: 5.2+20140608-3
Severity: important
Tags: patch
Dear Maintainer,
When a Wheezy or Jessie machine is fitted with an SSD the machine often
boots so quickly that tftpd-hpa is started before the network is fully
configured. The problem is reproducible with sysvinit (on Whee
It looks like 3.8.2-1 was uploaded by Torsten Landschoff in August 2014
which fixes this bug. 3.8.2-2 will be in Jessie.
I've installed 3.8.2-2 on Wheezy (it installs without any dependency
problems) and it seems to be behaving as well as my locally-patched 3.8.1
did.
So, I think we can close thi
My original report was for my laptop running Jessie. I've just tried the
same thing on a VM running up-to-date Sid.
On Sid all the reproduction steps have no effect on Totem at all
(i.e. Totem is not started if it wasn't already running and a running Totem
just continues with whatever it was doing
Package: totem
Version: 3.14.0-2
Severity: normal
Dear Maintainer,
Steps to reproduce:
1. Ensure that Totem is not running.
2. At a shell prompt enter:
gnome-open 2014-11-15-172942.webm
3. Notice that Totem starts up but shows some sort of overview of available
media files rather than imm
On Sunday 28 September 2014 at 15:01:21 +0100, Ben Hutchings wrote:
> On Sat, 2014-09-27 at 19:41 +0100, Mike Crowe wrote:
> > I compiled my own version of the Debian 3.2.60-1+deb7u3 kernel with
> > CONFIG_LOCKDEP and panic on hung task enabled.
> >
>
I compiled my own version of the Debian 3.2.60-1+deb7u3 kernel with
CONFIG_LOCKDEP and panic on hung task enabled.
>From the crash dump:
[25202.156175] INFO: task nfsd:3247 blocked for more than 900 seconds.
[25202.162565] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
On Thursday 31 July 2014 at 10:56:39 +0100, Simon McVittie wrote:
> On Sun, 18 May 2014 at 20:36:42 +0100, Mike Crowe wrote:
> > gnome-settings-daemon, nm-applet and (my) i3-gnome are launched correctly
> > yet gnome-screensaver is not. This appears to be due to the following l
On Monday 21 July 2014 at 15:01:31 +0100, Mike Crowe wrote:
> It is possible that I'm seeing the same problem. Our AMD Opteron 4386 (16
> cores) machine is also getting stuck with lots of hung tasks.
[snip]
> PID: 4087 TASK: 88040ea63840 CPU: 2 COMMAND: "nfsd"
It is possible that I'm seeing the same problem. Our AMD Opteron 4386 (16
cores) machine is also getting stuck with lots of hung tasks.
Although it responds to ping, and even a KVM virtual machine running on it
appears to continue working correctly, the host itself is locked up. This
happens once
Package: network-manager-gnome
Version: 0.9.8.10-1
Severity: normal
File: /usr/bin/nm-connection-editor
I managed to get my network configuration into something of a pickle by
accidentally removing my main network connection using nm-connection-editor.
Once I'd done that I was unable to re-create
I'm not absolutely sure that this is what the original reporter meant but
I've just run into this problem when using gnome-session to launch my own
"i3-gnome" session. My session file contains:
[GNOME Session]
Name=i3 Gnome session
RequiredComponents=gnome-settings-daemon;gnome-screensaver;nm-a
On Fri, Mar 01, 2013 at 10:17:06AM +0100, Sebastian Harl wrote:
> On Thu, Feb 28, 2013 at 05:10:57PM +0000, Mike Crowe wrote:
> > tig reports errors like:
> >
> > tig: Failed to chdir(../../submodule-directory): No such file or directory
> >
> > when started
I've tested the upstream patch linked from
https://github.com/jonas/tig/issues/54 and it solved the problem for
me.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: tig
Version: 1.0-2
Severity: normal
tig reports errors like:
tig: Failed to chdir(../../submodule-directory): No such file or directory
when started inside a submodule that has been created by the version of git in
Wheezy (1:1.7.10.4-1+wheezy1)
It looks like this problem has been disc
Here's a version of the patch with the asserts removed so it actually
compiles.
Mike.--- faad2-2.7.stock/frontend/main.c 2008-09-22 18:55:09.0 +0100
+++ faad2-2.7/frontend/main.c 2012-10-05 13:59:19.699009140 +0100
@@ -130,11 +130,18 @@ static int fill_buffer(aac_buffer *b)
static void
Package: faad
Version: 2.7-8
Severity: normal
Tags: upstream
I have an ADTS AAC file with an ID3v2 tag containing an image. Attempting to
skip this header by passing a value larger than the buffer size to
advance_buffer causes fill_buffer to misbehave. The problem is detected in
free() during a no
Package: icedove
Version: 10.0.6-2
Severity: normal
Steps to reproduce on Wheezy:
1. Ensure that Gnome3 is configured to attach modal dialogs.
2. Ensure that Icedove is maximised.
3. Click on "Write" button to start a new email.
4. Click on "Attach" button to add an attachment.
5. Notice that
Having just upgraded to Wheezy I'm also seeing gjs-console consume
100% CPU for around thirty seconds after searching (and then
cancelling) in the gnome-shell overview.
Here is the output that was requested by Michael Biebl back in May:
chuckie:~> cat /proc/`pidof gjs-console`/cmdline|tr '\0' '\n
I've tested using:
valgrind 1:3.6.0~svn11254+nmu1 (from squeeze)
valgrind 1:3.7.0-5 (from sid)
Both yield an exit code of 137 rather rather than the requested 42
(which appears to disagree with the man page) but I don't really care
as long as it doesn't yield zero.
The original problem no long
Package: minicom
Version: 2.4-3
Severity: normal
LANG=en_GB.utf8
Minicom parameters -m -c on -8 -R utf-8
If minicom receives an invalid UTF-8 sequence from the serial port it doesn't
display any more of the characters that have been sent.
For example (borrowing from bug 413934) if the byte seque
On Wed, 20 Apr 2011 16:43:48 +0100, Mike Crowe wrote:
>> With the Perforce command line client "p4" and bash-completion installed if I
>> type:
>>
>> p4 edit
>>
>> I get the following error:
>>
>> bash: _get_comp_words_by_ref(): `
Package: bash-completion
Version: 1:1.2-3
Severity: normal
With the Perforce command line client "p4" and bash-completion installed if I
type:
p4 edit
I get the following error:
bash: _get_comp_words_by_ref(): `preprev': unknown argument
It appears that this has been fixed in
http://git.
I think that there are separate problems here that are getting
intermingled in this bug report and others
(e.g. https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940 )
The particular variant that the original bug reporter appears to be
suffering from (and I happen to also be suffering from) i
I've tested minicom in a squeeze chroot using the byte sequence I
provided earlier. I could not reproduce the problem. Minicom displays
a strange character (as would be expected) but does not assert.
I tested with:
ii libc6 2.11.2-2
Embedde
Unfortunately the motherboard that I saw this problem on died. :(
I tried to reproduce it on my new Intel motherboard using
linux-image-2.6.26-2-686 v2.6.26-24 but could not do so.
Thanks.
Mike.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubsc
Package: libc6-i386
Version: 2.7-18
Severity: normal
Compile the attached test program on lenny-amd64 with -m32 and run the
generated binary. It segfaults inside __libc_freeres:
#0 0xf7ec513f in free_derivation () from /lib32/libc.so.6
#1 0xf7e82cc0 in tdestroy () from /lib32/libc.so.6
#2 0xf
Further to my original report I've done some more experiments and
noted that:
- The problem does indeed seem to be file size related. Small images
and video files do not cause the host controller to die. A transfer
of four video files totalling over 700MiB did cause the failure.
- The system
Package: gthumb
Version: 3:2.10.8-1
Severity: normal
Importing a large movie file from my camera fails due to bug 517716.
Unfortunately gthumb doesn't show any user-visible error in this
situation, it just switches to a window showing the photos and videos
that it has downloaded. It also doesn't r
Package: linux-image-2.6.26-1-686
Version: 2.6.26-13
Severity: normal
When downloading pictures from one of my PTP cameras my USB host
controller appears to "die". Pictures that have been successfully
transferred are not deleted from the camera. The ports connected to
that controller don't work un
Here is the output from valgrind-3.2.1. The output from 3.3.1 is
similar. Notice the shell-prompt in the middle and the exit code at
the end.
repton:~/src/valgrind-bugs> valgrind --error-exitcode=42 vgt
==10322== Memcheck, a memory error detector.
==10322== Copyright (C) 2002-2006, and GNU GPL'd,
Package: valgrind
Version: 1:3.2.1-1
Severity: normal
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-686-bigmem
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.U
Hi Adam & Markus,
I think I may have found a recipe for reproducing the minicom assert
with LANG=en_GB.UTF-8. As Markus reported the problem goes away with
LANG=posix.
Arrange for Minicom receive the following (invalid UTF-8) byte
sequence over the serial port:
f8 e2 82 ac c2 a3 0a
The error me
On Feb 14, Mike Crowe <[EMAIL PROTECTED]> wrote:
>> I don't think this issue is limited to network devices.
On Tue, Feb 14, 2006 at 01:46:30PM +0100, Marco d'Itri wrote:
> You are showing some totally unrelated issue which is obviously a
> bug in lvm2.
I admit that th
On Feb 14, Mike Crowe <[EMAIL PROTECTED]> wrote:
>> This means that on some boots the boot disk on megaraid is sda and
>> on others it's sdb.
On Tue, Feb 14, 2006 at 10:12:09PM +0100, Marco d'Itri wrote:
> It will happen among devices handled by different driver
chines
ii udev 0.081-0bpo1 /dev/ and hotplug management
daemon
--
Mike Crowe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: sound-juicer
Version: 2.12.3-3
Severity: normal
I didn't have much disk space free when ripping a CD to flac using
Sound Juicer. Sometime during the process the disk filled up (sans the
reserved for superuser part) and the file that was being written at
the time was truncated. The remain
Package: podracer
Version: 1.3-1
Severity: normal
Tags: patch
It is quite easy to get blank lines at the end of a subscriptions file
and the error message given by podracer in this situation is not good:
curl: no URL specified!
curl: try 'curl --help' or 'curl --manual' for more information
It
71 matches
Mail list logo