Bug#989735: Minicom 2.8-2 working well

2021-06-29 Thread Martin Godisch
On Tue, Jun 29, 2021 at 08:42:44 +0100, Mike Crowe wrote:

> I've been running Minicom 2.8-2 on Bullseye amd64 for the last couple of
> weeks. The fix for #989735 appears to have been effective and I haven't run
> into any other new problems.

Unblock request for testing filed as bug #990465.

Kind regards,

Martin



Bug#990465: unblock: minicom/2.8-2

2021-06-29 Thread Martin Godisch
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package minicom

minicom 2.8-2 addresses a smashed stack in testing, see bug #989735.
The upstream author provided four patches to address this issue.
I put these patches into debian/patches, nothing else has been changed.
The fix has been confirmed in #989735#55 by the bug's submitter.

debdiff attached

unblock minicom/2.8-2
diff -Nru minicom-2.8/debian/changelog minicom-2.8/debian/changelog
--- minicom-2.8/debian/changelog	2021-01-03 13:27:18.0 +0100
+++ minicom-2.8/debian/changelog	2021-06-15 05:20:21.0 +0200
@@ -1,3 +1,10 @@
+minicom (2.8-2) unstable; urgency=medium
+
+  * Fixed history buffer allocation, applied upstream 2021-06-13 patches,
+thanks to Mike Crowe and Adam Lackorzynski, closes: #989735.
+
+ -- Martin A. Godisch   Tue, 15 Jun 2021 05:20:21 +0200
+
 minicom (2.8-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru minicom-2.8/debian/patches/b6043854f1e762801347ed4bf4d368b49ad99217.diff minicom-2.8/debian/patches/b6043854f1e762801347ed4bf4d368b49ad99217.diff
--- minicom-2.8/debian/patches/b6043854f1e762801347ed4bf4d368b49ad99217.diff	1970-01-01 01:00:00.0 +0100
+++ minicom-2.8/debian/patches/b6043854f1e762801347ed4bf4d368b49ad99217.diff	2021-06-15 05:07:38.0 +0200
@@ -0,0 +1,39 @@
+diff --git a/src/minicom.c b/src/minicom.c
+index 2719f8cce5a3edf42b34918a870299004d813d21..06dd7be5840dc2fca733a6d0c995e52f814ca568 100644
+--- a/src/minicom.c
 b/src/minicom.c
+@@ -173,7 +173,6 @@ static void shjump(int sig)
+ static ELM *mc_getline(WIN *w, int no)
+ {
+   int i;
+-  static ELM outofrange[MAXCOLS] = {{0,0,0}};
+ 
+   if (no < us->histlines) {
+ /* Get a line from the history buffer. */
+@@ -188,13 +187,20 @@ static ELM *mc_getline(WIN *w, int no)
+   /* Get a line from the "us" window. */
+   no -= us->histlines;
+   if (no >= w->ys) {
+-if (outofrange[0].value == 0) {
+-  for (i = 0; i < MAXCOLS; i++) {
+-outofrange[i].value = ' ';
+-outofrange[i].color = us->color;
+-outofrange[i].attr  = us->attr;
++static int alloced_columns;
++static ELM *outofrange;
++int cols = w->x2 + 1;
++if (cols > alloced_columns) {
++  free(outofrange);
++  outofrange = malloc(sizeof(*outofrange) * cols);
++  assert(outofrange);
++  alloced_columns = cols;
++
++  for (i = 0; i < cols; i++) {
++	outofrange[i].value = i == 0 ? '~' : ' ';
++	outofrange[i].color = us->color;
++	outofrange[i].attr  = us->attr;
+   }
+-  outofrange[0].value = '~';
+ }
+ return outofrange;
+   }
diff -Nru minicom-2.8/debian/patches/b7727586547b4a24939bef4176b8a0d5ad91d62d.diff minicom-2.8/debian/patches/b7727586547b4a24939bef4176b8a0d5ad91d62d.diff
--- minicom-2.8/debian/patches/b7727586547b4a24939bef4176b8a0d5ad91d62d.diff	1970-01-01 01:00:00.0 +0100
+++ minicom-2.8/debian/patches/b7727586547b4a24939bef4176b8a0d5ad91d62d.diff	2021-06-15 04:58:44.0 +0200
@@ -0,0 +1,17 @@
+diff --git a/src/minicom.h b/src/minicom.h
+index ebc1dec6f06082c59059766fc89c19726e91aef1..cd75ec46ffaf6a0bd8564c15f1edeea55460a5b3 100644
+--- a/src/minicom.h
 b/src/minicom.h
+@@ -47,12 +47,6 @@
+ #include 
+ #endif
+ 
+-/*
+- * kub...@debian.or.jp 08/08/98
+- * COLS must be equal to or less than MAXCOLS.
+- */
+-#define MAXCOLS 256
+-
+ #define XA_OK_EXIST	1
+ #define XA_OK_NOTEXIST	2
+ 
diff -Nru minicom-2.8/debian/patches/d090ef81077c733ce5352da6cfe4af9aa20fc34d.diff minicom-2.8/debian/patches/d090ef81077c733ce5352da6cfe4af9aa20fc34d.diff
--- minicom-2.8/debian/patches/d090ef81077c733ce5352da6cfe4af9aa20fc34d.diff	1970-01-01 01:00:00.0 +0100
+++ minicom-2.8/debian/patches/d090ef81077c733ce5352da6cfe4af9aa20fc34d.diff	2021-06-15 05:08:25.0 +0200
@@ -0,0 +1,22 @@
+diff --git a/src/minicom.c b/src/minicom.c
+index 06dd7be5840dc2fca733a6d0c995e52f814ca568..f6c84c85427a04d739fdd3edbfcf0260835d4729 100644
+--- a/src/minicom.c
 b/src/minicom.c
+@@ -377,12 +377,13 @@ const wchar_t *upcase(wchar_t *dest, wchar_t *src)
+  */
+ wchar_t *StrStr(wchar_t *str1, wchar_t *str2, int case_matters)
+ {
+-  wchar_t tmpstr1[MAXCOLS], tmpstr2[MAXCOLS];
+-
+   if (case_matters)
+ return wcsstr(str1, str2);
+-  else
+-return wcsstr(upcase(tmpstr1, str1), upcase(tmpstr2, str2));
++
++  size_t len1 = wcslen(str1) + 1;
++  size_t len2 = wcslen(str2) + 1;
++  wchar_t tmpstr1[len1], tmpstr2[len2];
++  return wcsstr(upcase(tmpstr1, str1), upcase(tmpstr2, str2));
+ }
+ 
+ static void drawcite(WIN *w, int y, int citey, int start, int end)
diff -Nru minicom-2.8/debian/patches/f118eb9efe89672e5c2a75b34960813db493b2ed.diff minicom-2.8/debian/patches/f118eb9efe89672e5c2a75b34960813db493b2ed.diff
--- minicom-2.8/debian/patches/f118eb9efe89672e5c2a75b34960813db493b2ed.diff	1970-01-01 01:00:00.0 +0100
+++ minicom-2.8/debian/patches/f118eb9efe89672e5c2a75b34960813db493b2ed.diff	2021-06-15 0

Bug#951491: tcpflow: cannot handle Q-in-Q and IEEE 802.1ad packets

2020-02-17 Thread Martin Godisch
Package: tcpflow
Version: 1.5.2+repack1-1
Tags: patch

$ tcpflow -v -r x.pcap
reportfilename: ./report.xml
tcpflow: TCPFLOW version 1.5.1
tcpflow: looking for handler for datalink type 1 for interface x.pcap
tcpflow: warning: received ethernet frame with unknown type 0x88a8
tcpflow: warning: received ethernet frame with unknown type 0x88a8
tcpflow: warning: received ethernet frame with unknown type 0x88a8
tcpflow: warning: received ethernet frame with unknown type 0x88a8
[...]

Please add support for VLAN tags 0x9100 and 0x88a8. Patch attached.

Thank you! -- Martin
--- tcpflow-1.5.2+repack1.orig/src/datalink.cpp
+++ tcpflow-1.5.2+repack1/src/datalink.cpp
@@ -97,7 +97,9 @@ void dl_ethernet(u_char *user, const str
 }
 
 /* Handle basic VLAN packets */
-while (ntohs(*ether_type) == ETHERTYPE_VLAN) {
+while (ntohs(*ether_type) == ETHERTYPE_VLAN ||
+		ntohs(*ether_type) == ETH_P_QINQ1 ||
+		ntohs(*ether_type) == ETH_P_8021AD) {
 	//vlan = ntohs(*(u_short *)(p+sizeof(struct ether_header)));
 	ether_type += 2;			/* skip past VLAN header (note it skips by 2s) */
 	ether_data += 4;			/* skip past VLAN header */


Bug#900092: Bug#842896: minicom: diff for NMU version 2.7.1-1.1

2019-12-26 Thread Martin Godisch
On Thu, Dec 26, 2019 at 09:06:22 -0500, Boyuan Yang wrote:

> > Can you explain, please, why minicom needs to build-depend on
> > debhelper
> > instead of autotools-dev?
> 
> I was holding the assumption that your package will eventually migrate
> to be using dh, in which case build-depends on debhelper is necessary.
> It seems that current build scripts in debian/rules indeed does not
> need it and autotools-dev would be enough. Please feel free to revert
> it or cancel this NMU if you find it necessary.

Okay, I'll revert the dependency upon next upload, then.

Thanks for the NMU,

Martin



Bug#900092: Bug#842896: minicom: diff for NMU version 2.7.1-1.1

2019-12-26 Thread Martin Godisch
Hi,

On Sun, Dec 22, 2019 at 21:17:13 -0500, Boyuan Yang wrote:

> +  * debian/control:
> ++ Add missing build-dependency debhelper (with compat level
> +  of 12).

Can you explain, please, why minicom needs to build-depend on debhelper
instead of autotools-dev?

Kind regards,

Martin



Bug#868259: opendkim: systemctl does not create $RUNDIR

2017-07-13 Thread Martin Godisch
retitle 868259 opendkim: please add permissions configuration for $RUNDIR
thanks

It is impossible to configure other permissions than 0750 for $RUNDIR,
since it is hard-coded in /lib/opendkim/opendkim.service.generate.

I need it to grant postfix access to the opendkim unix socket. I cannot
add the postfix user to the opendkim group. opendkim will complain about
postfix being able to read its private key then. opendkim also refuses
to create its socket in /var/spool/postfix/private, as opendmarc,
policy-spf, postgrey etc. do. How to do this with opendkim?

Kind regards,

Martin

On Thu, Jul 13, 2017 at 22:56:06 +0200, Martin Godisch wrote:

> Package: opendkim
> Version: 2.11.0~alpha-10
> Severity: normal
> 
> If $RUNDIDR does not exist, "systemctl start opendkim.service" does not
> create it and fails.
> 
> Kind regards,
> 
> Martin



Bug#868259: opendkim: systemctl does not create $RUNDIR

2017-07-13 Thread Martin Godisch
Package: opendkim
Version: 2.11.0~alpha-10
Severity: normal

If $RUNDIDR does not exist, "systemctl start opendkim.service" does not
create it and fails.

Kind regards,

Martin



Bug#868257: opendkim: opendkim.service.generate fails to generate override.conf

2017-07-13 Thread Martin Godisch
Package: opendkim
Version: 2.11.0~alpha-10
Severity: normal

If /etc/systemd/system/opendkim.service.d/override.conf exists with some
non-standard configuration and /etc/default/opendkim is reset to the
standard configuration then /lib/opendkim/opendkim.service.generate
fails to adjust (or: remove) the non-standard override.conf because of
this condition

if [ "$SOCKET" != "$_SOCKET" ] || [ "$RUNDIR" != "$_RUNDIR" ] || [
"$DAEMON_OPTS" != "" ] ...

which detects a standard setup in /etc/default/opendkim and erroneously
thinks there is nothing to do.

Kind regards,

Martin



Bug#860940: minicom: diff for NMU version 2.7-1.1

2017-04-22 Thread Martin Godisch
On Sat, Apr 22, 2017 at 15:40:48 +0200, Salvatore Bonaccorso wrote:

> > > I've prepared an NMU for minicom (versioned as 2.7-1.1) and
> > > uploaded it to DELAYED/2. Please feel free to tell me if I
> > > should delay it longer.
> > 
> > Thank you! -- Martin
> 
> Thanks for quick feedback! Do you allow me to reshedule it to enter
> faster the archive, or do you want me actually to cancel it and upload
> an own version?

Go ahead, reschedule it.

Kind regards,

Martin



Bug#860940: minicom: diff for NMU version 2.7-1.1

2017-04-22 Thread Martin Godisch
On Sat, Apr 22, 2017 at 11:34:54 +0200, Salvatore Bonaccorso wrote:

> I've prepared an NMU for minicom (versioned as 2.7-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Thank you! -- Martin



Bug#827684: cgoban: please make the build reproducible

2016-08-22 Thread Martin Godisch
On Sat, Aug 20, 2016 at 21:01:27 +0100, Chris Lamb wrote:

> There hasn't seem to be any update on this bug in 62 days, in which
> time the Reproducible Builds effort has come on a long way. :)
> 
> Would you consider applying this patch and uploading?

I'll do it this Saturday. -- Martin



Bug#818344: mdadm: device rescan missing in initrd root device loop

2016-03-16 Thread Martin Godisch
Package: mdadm
Version: 3.3.2-5+deb8u1
Severity: important

I'm running a bunch of Dell PowerEdge FC430 here which contain each two
SSD drives as raid 1. Since there is no hardware raid controller option,
an mdadm raid 1 is configured for a lvm physical volume, the server's
root device is a logical volume in that volume group.

Here is the problem: In about one of two times the server boots into the
initrd prompt since it does not find its root device, probably because
the SSDs are slower initialized at kernel bootup. local_device_setup()
in /usr/share/initramfs-tools/scripts/local takes care of that and tries
again if the root device hasn't shown up yet, but the process doesn't
involve rescanning for raid devices as it probably should in
/usr/share/initramfs-tools/scripts/local-block like
/usr/share/initramfs-tools/scripts/local-block/lvm2. Therefore the raid
device stays absent and rescanning for logical volumes fails again and
again.

Workaround: Copying /usr/share/initramfs-tools/scripts/local-top/mdadm
to /etc/initramfs-tools/scripts/local-block/mdadm solves the problem,
but I'm not sure whether that script is written with repeated execution
in mind.

I tagged this bug important because it makes server reboots
unpredictable. The reboot may be successfull or it may run into the
initrd prompt which would be bad for administrators who try to reboot
without console access.

Please let me know if you need further information. I can test proposed
solutions if necessary.

Kind regards,

Martin



Bug#788673: wmweather segfaults on launch

2015-06-13 Thread Martin Godisch
Hi Nathan,

On Sun, Jun 14, 2015 at 00:50:03 -0400, Nathan Misner wrote:

> I've tried to use wmweather on my setup, however it is unable to
> launch, at least on my machine, and just gives me a segmentation fault
> instead. Because wmweather used to work on my system up until a couple
> days ago,

> I think that a library update may have caused this issue (so it may
> just be that a feature the package used was deprecated or something).
> I've attached my strace of wmweather below.

>  nathan@ThinkPad:~$ strace -eopen wmweather

> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
> +++ killed by SIGSEGV +++
> Segmentation fault

Can you provide a backtrace, please? I can explain how, if necessary.

Kind regards,

Martin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#757729: upload to ftp.eu.upload.debian.org broken

2014-08-10 Thread Martin Godisch
Package: ftp.debian.org

Hi,

uploading to ftp.eu.upload.debian.org is somehow broken:

dupload note: no announcement will be sent.
Checking signatures before upload..signatures are ok
Uploading (ftp) to ftp.eu.upload.debian.org:/pub/UploadQueue/
[ job gnugo_3.8-8_amd64 from gnugo_3.8-8_amd64.changes
 gnugo_3.8-8.debian.tar.gz, size ok, md5sum ok, sha1sum ok, sha256sum ok
 gnugo_3.8-8_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 gnugo_3.8-8.dsc, size ok, md5sum ok, sha1sum ok, sha256sum ok
 gnugo_3.8-8_amd64.changes ok ]
Uploading (ftp) to anonymous (ftp.eu.upload.debian.org)
+ FTP passive mode selected
[ Uploading job gnugo_3.8-8_amd64
 gnugo_3.8-8.debian.tar.gz 36.6 kBdupload fatal error: Can't upload 
gnugo_3.8-8.debian.tar.gz: Could not create file.
 at /usr/bin/dupload line 558

No, gnugo_3.8-8.debian.tar.gz did not already exist. And i didn't change
my ~/.dupload.conf for ages.

$ ftp ftp.eu.upload.debian.org
Connected to coccia.debian.org.
220 ftp.upload.debian.org FTP server
Name (ftp.eu.upload.debian.org:godisch): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> passive
Passive mode on.
ftp> bin
200 Switching to Binary mode.
ftp> cd /pub/UploadQueue/
250 Directory successfully changed.
ftp> dir
227 Entering Passive Mode (5,153,231,11,190,191).
150 Here comes the directory listing.
-rw-r--r--1 3149 1281 1843 Jul 31 22:08 README
226 Directory send OK.
ftp> put gnugo_3.8-8.debian.tar.gz
local: gnugo_3.8-8.debian.tar.gz remote: gnugo_3.8-8.debian.tar.gz
227 Entering Passive Mode (5,153,231,11,158,170).
553 Could not create file.
ftp> put gnugo_3.8-8_amd64.deb
local: gnugo_3.8-8_amd64.deb remote: gnugo_3.8-8_amd64.deb
227 Entering Passive Mode (5,153,231,11,230,214).
553 Could not create file.
ftp> dir
227 Entering Passive Mode (5,153,231,11,109,170).
150 Here comes the directory listing.
-rw-r--r--1 3149 1281 1843 Jul 31 22:08 README
226 Directory send OK.
ftp> ls -al
227 Entering Passive Mode (5,153,231,11,27,88).
150 Here comes the directory listing.
drwxrwsr-x2 1518 1281 4096 Aug 01 09:40 .
drwxr-xr-x3 1518 802  4096 Jul 31 22:07 ..
-rw-r--r--1 3149 1281 1843 Jul 31 22:08 README
226 Directory send OK.
ftp> quit
221 Goodbye.

Successfully uploaded to ftp.upload.debian.org instead.

Kind regards,

Martin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#743164: wrong ${shlibs:Depends} version

2014-03-30 Thread Martin Godisch
Package: libpcre3-dev
Version: 1:8.30-5

Building a program using libpcre3 produces a binary dependency on
libpcre3 (>= 8.10). This is wrong, since the function pcre_free_study()
is not available e.g. in libpcre3 8.12 (in Ubuntu precise).

PCREAPI(3) says:

  When you are finished with a pattern, you can free the memory used for
  the study data by calling pcre_free_study(). This function was added
  to the API for release 8.20.

So I think the dependency should be (>= 8.20).

Kind regards,

Martin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#733350: RM: latrine -- RoM; abandoned upstream

2013-12-28 Thread Martin Godisch
Package: ftp.debian.org

Please remove latrine from testing and unstable. Upstream development
is dead (I'm the upstream maintainer). For this reason the package is
already not present in stable anymore.

Thanks,

Martin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#731793: ITA: rockdodger

2013-12-27 Thread Martin Godisch
retitle 731793 ITA: rockdodger
thanks

I'll adopt this package.

Martin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#698645: latrine: please remove from testing

2013-01-21 Thread Martin Godisch
Package: latrine
Severity: serious
Tags: upstream

Please remove latrine from Debian testing, it is too outdated to go into
wheezy. A new release is upcoming, so there is no need to remove it from
unstable.

Martin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#206729: autolog: hardcoded 1800 seconds daemon sleep

2007-05-11 Thread Martin Godisch
tags 206729 + patch
thanks

Please apply the attached patch.

Thanks! -- Martin
--- autolog-0.40/autolog.c.orig	2007-05-11 08:31:55.0 +0200
+++ autolog-0.40/autolog.c	2007-05-11 08:32:50.0 +0200
@@ -483,8 +483,8 @@
 	idle=c_arr[c_idx].idle;
 	
 /*.. Maybe it is necessary to reduce the max. sleeptime to shortest session. */
-	if (0< c_arr[c_idx].hard && 0

Bug#206729: autolog: hardcoded 1800 seconds daemon sleep

2007-05-10 Thread Martin Godisch
severity 206729 normal
thanks

This is a bug, not a wishlist request. The program clearly misbehaves when
there is a small idle time specified.

Kind regards,

Martin




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]