Bug#1050782: linux-image-armmp: Please enable the tca8418_keypad module for PocketCHIP support

[Michael Fincham]

Package: linux-image-armmp
X-Debbugs-Cc: mich...@hotplate.co.nz
Version: 6.1.38-4
Severity: normal

Dear Maintainer,

Could we have the module "tca8418_keypad" enabled in the Debian armmp kernel? 

Currently the NTC CHIP board is listed as "Stable untested" on 
https://wiki.debian.org/InstallingDebianOn/Allwinner.

I'm troubleshooting some small issues running Bookworm with the NTC PocketCHIP 
carrier board that was commonly distributed along with the CHIP. The PocketCHIP 
board adds battery, screen and keyboard peripherals to the CHIP similar to a 
Beaglebone cape or Pi hat.

The PocketCHIP keyboard is supported by the tca8418_keypad module. Currently it 
is not enabled in the armmp kernel configuration:

root@djubre:~# grep TCA8418 /boot/config-6.1.0-11-armmp
# CONFIG_KEYBOARD_TCA8418 is not set

If we had this module enabled we would have complete out-of-the-box support for 
all of the PocketCHIP's hardware from Bookworm onwards.

The following output is from a PocketCHIP R8 system running the latest 
linux-image-armmp tainted by building the tca8418_keypad module manually to 
confirm it works:

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 6.1.0-11-armmp (SMP w/1 CPU thread)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-armmp depends on:
ii  linux-image-6.1.0-11-armmp  6.1.38-4

linux-image-armmp recommends no packages.

linux-image-armmp suggests no packages.

-- no debconf information

Bug#939442: Upstream investigating

[Michael Fincham]

On Fri, 6 Sep 2019 17:25:00 +1200 Michael Fincham  
wrote:
> Upstream has advised they're investigating the issue:
> 
> <https://dovecot.org/pipermail/dovecot/2019-September/116999.html>
> 
> Dovecot's reference is DOP-1408.
> 
> -- 
> Michael
> 
> 

Bug#939442: Upstream dropping support for mail-filter

[Michael Fincham]

Hi all,

Seems like upstream is planning to drop support for the mail-filter plugin:

https://dovecot.org/pipermail/dovecot/2020-March/118416.html

-- 
Michael

Bug#939442: Upstream investigating

[Michael Fincham]

Upstream has advised they're investigating the issue:



Dovecot's reference is DOP-1408.

-- 
Michael

Bug#939442: dovecot-core: mail_filter and mail_filter_out broken after upgrade to buster

[Michael Fincham]

Package: dovecot-core
Version: 2.3.4.1-5+deb10u1
Severity: important

Hi Dovecot maintainers,

After upgrading from the latest stretch version of dovecot-core
(2.2.27-3+deb9u5) to buster (2.3.4.1-5+deb10u1) the "mail filter"
interface seems to have broken. This problem is also present in the sid
version (2.3.7.2-1).

Mail filter is used to run the content of messages being stored or
retrieved through an arbitrary process. The interface used for the
external process is described here:
https://wiki.dovecot.org/Plugins/MailFilter

It is expected that the process will be called with the arguments
specific in the configuration then supplied a message body on stdin,
however since upgrading it seems that the arguments are not being
correctly passed, instead being all jammed in to $1 and separated by
tabs, rather than expanded in to argv. Even stranger the first few
lines of the body of the message appear in argv rather than in stdin...

These reproduction steps were carried out on a fresh install of Debian
Buster with the "dovecot-core" package installed initially from stretch
then upgraded to the buster version, however this behaviour has also
been observed on stretch systems after upgrading to buster.

To reproduce, drop this minimalised config in
to /etc/dovecot/conf.d/repro.conf:

# Minimal maildir setup for LDA
first_valid_uid = 0
mail_location = maildir:~/Maildir
userdb {
  driver = static
  args = allow_all_users=yes uid=mail gid=mail home=/tmp/%u
}

# Mail filter configuration
mail_plugins = $mail_plugins mail_filter

plugin {
  mail_filter = mail-filter read %u
  mail_filter_out = mail-filter write %u
}

service mail-filter {
 executable = script /usr/local/bin/mail-filter.sh
 user = dovecot
 unix_listener mail-filter {
   mode = 0666
 }
}

And create the example script in /usr/local/bin/mail-filter.sh with
executable permissions:

#!/bin/bash

echo "arguments were: $@" 1>&2
tempfile=$(mktemp)
cat > "${tempfile}"
cat "${tempfile}"
rm "${tempfile}"

This script simply logs the arguments it recieves, writes stdin to a
file then retrieves it again from the file.

Here's a sample session of me using dovecot-lda to pass a message
through this script, then retrieve it again with doveadm:

root@scratch-b6fd8bdd:~# /usr/lib/dovecot/dovecot-lda -d 
fincham@scratch-b6fd8bdd -f 'Test ' < /root/test.eml 
root@scratch-b6fd8bdd:~# doveadm fetch -u 'fincham@scratch-b6fd8bdd' hdr 
subject Test
hdr:
To: Test 
From: Test 
Subject: This is the test e-mail

root@scratch-b6fd8bdd:~# tail /var/log/syslog | grep mail-filter
Sep  5 00:07:48 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
write fincham@scratch-b6fd8bdd
Sep  5 00:07:50 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
read fincham@scratch-b6fd8bdd

However after upgrading dovecot to the buster version this process no
longer works, and the logged argv of the example script is very strange:

root@scratch-b6fd8bdd:~# apt dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  liblua5.3-0 libsodium23 ssl-cert
The following packages will be upgraded:
  dovecot-core
[...]

root@scratch-b6fd8bdd:~# /usr/lib/dovecot/dovecot-lda -d 
fincham@scratch-b6fd8bdd -f scratch-b6fd8bdd < /root/test.eml 
Aborted
root@scratch-b6fd8bdd:~# doveadm fetch -u 'fincham@scratch-b6fd8bdd' hdr 
subject Test
hdr:
Hello!
doveadm(fincham@scratch-b6fd8bdd): Error: Mailbox INBOX: UID=1: read() failed: 
Cached message size larger than expected (115 > 7, box=INBOX, UID=1) (read 
reason=mail stream)
doveadm(fincham@scratch-b6fd8bdd): Error: Corrupted record in index cache file 
/tmp/fincham@scratch-b6fd8bdd/Maildir/dovecot.index.cache: UID 1: Broken 
physical size in mailbox INBOX: read() failed: Cached message size larger than 
expected (115 > 7, box=INBOX, UID=1)
doveadm(fincham@scratch-b6fd8bdd): Error: read() failed: Cached message size 
larger than expected (115 > 7, box=INBOX, UID=1)
doveadm(fincham@scratch-b6fd8bdd): Error: fetch(hdr) failed for box=INBOX 
uid=1: read() failed: Cached message size larger than expected (115 > 7, 
box=INBOX, UID=1)
root@scratch-b6fd8bdd:~# tail /var/log/syslog | grep mail-filter
Sep  5 00:07:48 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
write fincham@scratch-b6fd8bdd
Sep  5 00:07:50 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
read fincham@scratch-b6fd8bdd
Sep  5 00:12:11 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
write#011fincham@scratch-b6fd8bdd#011 To: Test  From: 
Test  Subject: This is the test e-mail
Sep  5 00:12:14 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
read#011fincham@scratch-b6fd8bdd#011 To: Test  From: 
Test  Subject: This is the test e-mail

-- Package-specific info:

dovecot configuration
-
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-5-cloud-

Bug#837509: installation-reports: Partial success on Novena (no USB during install)

[Michael Fincham]

Hi all,

On Sat, 24 Jun 2017 20:36:04 +0200, Cyril Brulebois wrote: 
> Can you please attach lsmod's output from the installed system?

Here's lsmod from a freshly installed stretch 20170615+deb9u3 installer build. 
This is with the
standard supplied WiFi / bluetooth card installed.

Module  Size  Used by
binfmt_misc 9306  1
joydev  9536  0
imx_ipuv3_crtc 10765  0
ath3k   7893  0
btusb  31088  0
btrtl   5113  1 btusb
btbcm   5955  1 btusb
btintel 7295  1 btusb
arc41958  2
asix   31435  0
snd_soc_imx_es8328  4039  0
usbnet 25926  1 asix
mii 4166  2 usbnet,asix
bluetooth 464225  5 btrtl,btintel,btbcm,ath3k,btusb
sg 23445  0
stmpe_ts4057  0
snd_soc_es8328_i2c  1536  1
imx_ipu_v3 76309  1 imx_ipuv3_crtc
snd_soc_es8328 16632  1 snd_soc_es8328_i2c
mma845215298  0
industrialio_triggered_buffer 1742  1 mma8452
kfifo_buf   2714  1 industrialio_triggered_buffer
ath9k  89781  0
industrialio   47740  3 mma8452,industrialio_triggered_buffer,kfifo_buf
sbs_battery 8266  0
snd_soc_imx_audmux  4970  1 snd_soc_imx_es8328
ath9k_common   22634  1 ath9k
ath9k_hw  419253  2 ath9k,ath9k_common
ath18696  3 ath9k_hw,ath9k,ath9k_common
snd_soc_fsl_ssi14648  2
imx_pcm_dma 1244  1 snd_soc_fsl_ssi
imx_pcm_fiq 5167  1 snd_soc_fsl_ssi
imx_ldb 8343  0
mac80211  584961  1 ath9k
snd_soc_core  146641  6
snd_soc_fsl_ssi,snd_soc_es8328_i2c,snd_soc_es8328,snd_soc_imx_es8328,imx_pcm_dma,imx_pcm_fiq
snd_pcm_dmaengine   3583  1 snd_soc_core imx2_wdt4228  0
snd_pcm83540  5
snd_soc_fsl_ssi,snd_pcm_dmaengine,snd_soc_es8328,snd_soc_core,imx_pcm_fiq 
snd_timer
20381  1 snd_pcm snd55441  4 
snd_timer,snd_soc_es8328,snd_soc_core,snd_pcm
imx_keypad  5683  0
soundcore   5571  1 snd
matrix_keymap   2339  1 imx_keypad
cfg80211  479516  4 mac80211,ath9k,ath,ath9k_common
rfkill 16819  3 bluetooth,cfg80211
spi_imx12565  0
dw_hdmi_imx 3203  0
imxdrm  5486  2 imx_ldb,imx_ipuv3_crtc
dw_hdmi14266  1 dw_hdmi_imx
drm_kms_helper117682  5 imx_ldb,imx_ipuv3_crtc,dw_hdmi,imxdrm
etnaviv66373  0
evdev  12804  1
leds_gpio   3390  0
drm   276542  8
imx_ldb,imx_ipuv3_crtc,etnaviv,dw_hdmi,dw_hdmi_imx,imxdrm,drm_kms_helper pwm_bl
4989  0 ip_tables  12425  0
x_tables   14864  1 ip_tables
autofs433093  2
ext4  553026  2
crc16   1274  2 bluetooth,ext4
jbd2   94340  1 ext4
crc32c_generic  1862  4
fscrypto   15434  1 ext4
ecb 2191  0
mbcache 5508  3 ext4
dm_mod103473  6
sd_mod 33243  2
pfuze100_regulator 13107  1
ahci_imx6207  1
libahci_platform6494  1 ahci_imx
libahci23377  2 libahci_platform,ahci_imx
libata193250  3 libahci_platform,libahci,ahci_imx
ci_hdrc_imx 7000  0
ci_hdrc35271  1 ci_hdrc_imx
extcon_core13057  1 ci_hdrc
ehci_hcd   65926  1 ci_hdrc
udc_core   26904  1 ci_hdrc
scsi_mod  188563  3 sd_mod,libata,sg
sdhci_esdhc_imx12223  0
sdhci_pltfm 3338  1 sdhci_esdhc_imx
sdhci  39644  2 sdhci_pltfm,sdhci_esdhc_imx
usbcore   199268  6 usbnet,ehci_hcd,ath3k,btusb,asix,ci_hdrc
usb_common  3659  3 udc_core,usbcore,ci_hdrc
i2c_imx15628  0
usbmisc_imx 6696  1 ci_hdrc_imx
phy_mxs_usb 6462  2
anatop_regulator4712  1
micrel  9942  1

-- 
Michael


pgpvick1Z6TlE.pgp
Description: PGP signature

Bug#872063: ipcalc: Option "-c" overloaded for two different functions, only one works

[Michael Fincham]

Package: ipcalc
Version: 0.41-5
Severity: normal
Tags: upstream

Dear Maintainer,

In the help output from ipcalc the program claims that '-c' performs two 
different functions:

$ ipcalc --help | grep -- '-c'
 -c --colorDisplay ANSI color codes (default).
 -c --classJust print bit-count-mask of given address.

It seems that only the '--color' variant works. I suggest we either remove the 
short version of the '--class' option, or ideally rename it to something that 
is more appropriate with the removal of "classes" from the codebase in #872061.

Happy to produce a patch to do either if some guidance can be given on what is 
desired.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ipcalc depends on:
ii  perl  5.24.1-3+deb9u1

ipcalc recommends no packages.

ipcalc suggests no packages.

-- no debconf information

Bug#872061: ipcalc: Still gives networks "classes" even though this is an anachronism

[Michael Fincham]

Package: ipcalc
Version: 0.41-5
Severity: normal
Tags: upstream

Dear Maintainer,

ipcalc included in Stretch still produces output containing network "classes", 
a concept that has not been valid since the early 90s and the introduction of 
CIDR (https://tools.ietf.org/html/rfc1519).

For example:

$ ipcalc 192.0.2.0/24 | grep Class
Hosts/Net: 254   Class C
$ ipcalc 10.0.0.0/24 | grep Class
Hosts/Net: 254   Class A, Private Internet

I will prepare a patch to remove this output from the program.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ipcalc depends on:
ii  perl  5.24.1-3+deb9u1

ipcalc recommends no packages.

ipcalc suggests no packages.

-- no debconf information

Bug#797962: [PKG-Openstack-devel] Bug#797962: openstack-debian-images: Built images do not include aptitude

[Michael Fincham]

Hi Gaudenz,

I should have been more verbose in my original report :)

On Thu, 17 Sep 2015 18:36:55 +0200, Gaudenz Steinlin  wrote:
>  You don't say which documentation you are refering to. Is this
> current documentation for jessie from Debian? If so it should be fixed.

When I said "previously" I meant:

From at least some time in 2006/2007 until August of 2010, 
 contained 
the phrase (I've just checked this with archive.org).

Some of us who made the switch to aptitude when this was the advice have just 
continued using it - it was only recently I discovered that the recommendation 
has changed to apt-get.

> Aptitude is not part of the Debian default install anymore and thus
> should not be part of the OpenStack images either.

I've just installed a fresh Jessie VM with all the defaults and it does still 
come with aptitude installed, thus my surprise that it was missing from the 
cloud image.

It's not a big deal, I just thought its omission might have been accidental!

-- 
Michael


pgpa9K3tJ1rER.pgp
Description: PGP signature

Bug#797962: openstack-debian-images: Built images do not include aptitude

[Michael Fincham]

Package: openstack-debian-images
Version: 1.4
Severity: normal

Dear maintainer,

Previously the phrase "Aptitude is the current preferred package management 
tool for the Debian system." appeared in the Debian documentation.

Is the omission of aptitude from the images built by openstack-debian-image an 
accident? If so, can it be added?

Thanks,
-Michael

Bug#779813: installation-reports: KMS results in blank screen after installation on Acer eM350

[Michael Fincham]

On Thu, 5 Mar 2015 04:18:50 +0100, Cyril Brulebois wrote:
> I'd recommend filing a bug report against the linux kernel.

No need, I updated to 3.16.7-ckt7-1 today and the workaround is no longer 
required :)

Cheers,
-- 
Michael


pgp2GRGPVvPWg.pgp
Description: PGP signature

Bug#779813: installation-reports: KMS results in blank screen after installation on Acer eM350

[Michael Fincham]

Package: installation-reports
Severity: important
Tags: d-i

Installation proceeds smoothly on this machine however on boot after being
prompted for my LUKS password the screen blanks and does not recover.

This can be fixed by changing /etc/default/grub to specify the video mode:

  GRUB_CMDLINE_LINUX_DEFAULT="quiet video=LVDS-1:1024x600"

Everything else seems to work OK except changing the backlight brightness is
flickery - it seems like the hardware might be fighting with Gnome during
changes.



-- Package-specific info:

Boot method: USB
Image version: 
http://cdimage.debian.org/cdimage/jessie_di_rc1/amd64/iso-cd/debian-jessie-DI-rc1-amd64-netinst.iso
Date: 

Machine: Acer eMachines eM350
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20150107"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux hopper 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx DMI Bridge [8086:a010]
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: agpgart-intel
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom 
Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011]
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a012]
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family 
High Definition Audio Controller [8086:27d8] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 1 [8086:27d0] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI 
Express Port 2 [8086:27d2] (rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #1 [8086:27c8] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #2 [8086:27c9] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #3 [8086:27ca] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB UHCI Controller #4 [8086:27cb] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family 
USB2 EHCI Controller [8086:27cc] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI 
Bridge [8086:2448] (rev e2)
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation NM10 Family LPC 
Controller [8086:27bc] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation NM10/ICH7 Family 
SATA Controller [AHCI mode] [8086:27c1] (rev 02)
lspci -knn: Subsystem: Acer Incorporated [ALI] Device [1025:0349]
lspci -knn: Kernel driver in use: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation NM10/ICH7 Family SMBus 
Controller [8086:27da] (rev 02)
lspci -k

Bug#777706: A couple of patches

[Michael Fincham]

I've attached here two debdiffs for a couple of options which may be
helpful.

It looks like the underlying bug has been fixed between versions 1.1
and 1.2 of NUT-Monitor, as the configuration directory is now being
created with a sensible mode (0700).

The attached patch `fix-permissions-on-start.debdiff' causes
NUT-Monitor to detect and correct unsafe permissions on ~/.nut-monitor
automatically when it is started. It also includes a NEWS item
explaining this.

The second patch, `just-warn.debdiff' merely includes a NEWS item
explaining the problem and suggesting a fix.

Hopefully one of these approaches may be sufficient.

-- 
Michael Fincham
Catalyst


fix-permissions-on-start.debdiff
Description: Binary data


just-warn.debdiff
Description: Binary data


pgpKU9VLZRsEZ.pgp
Description: PGP signature

Bug#776282: iperf: Unable to send more than ~ 70, 000 packets per second in UDP mode since 2.0.5

[Michael Fincham]

Package: iperf
Version: 2.0.5-3
Severity: important
Tags: upstream

Dear Maintainer,

Troubleshooting the cause of unexpectedly poor benchmarking at high packet-per-
second rates of UDP it was found that the iperf package included in squeeze
(2.0.4) performed significantly better than that which is included in wheezy
(2.0.5).

This behaviour was verified across several machines and can be replicated using
the loopback adapter, eliminating network cards and drivers.

While iperf 2.0.4 in squeeze is capable of generating large numbers of packets
per second in UDP mode (we have observed over half a million), 2.0.5 in wheezy
consistently transmits at 70,000 packets per second (or thereabouts) and no
more, in an otherwise identical scenario. This makes the results given by iperf
unexpectedly misleading in these situations (e.g. where the combination of
requested bandwidth and packet size requires high packet rates).

This behaviour was observed with the iperf packages from both wheezy and
unstable, built both with and without the included Debian patches.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When running iperf 2.0.4 (built from the squeeze source package):

# iperf -u -c 127.0.0.1 -l 32 -b 1000M -t 60

Client connecting to 127.0.0.1, UDP port 5001
Sending 32 byte datagrams
UDP buffer size:   224 KByte (default)

[  3] local 127.0.0.1 port 53255 connected with 127.0.0.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-60.0 sec698 MBytes  97.6 Mbits/sec
[  3] Sent 22886425 datagrams

In 60 seconds, 22886425 datagrams were generated, for an average of approx.
381440 packets per second. However while running iperf 2.0.5 included with
wheezy:

# iperf -u -c 127.0.0.1 -l 32 -b 1000M -t 60

Client connecting to 127.0.0.1, UDP port 5001
Sending 32 byte datagrams
UDP buffer size:  224 KByte (default)

[  3] local 127.0.0.1 port 39531 connected with 127.0.0.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-60.0 sec   126 MBytes  17.7 Mbits/sec
[  3] Sent 4144058 datagrams

Only 4144058 datagrams were generated in the same time period, averaging
approx. 69068 packets per second. This number seems to be a hard limit across
many machines, including a machine with dual 10-core Xeon processors.

The behaviour seen with 2.0.4 is the expected behaviour - that iperf generates
as many packets as possible given the hardware and so on on which it is run.

One hypothesis as to the cause of this problem is that the timing mechanism
used to generate the packets at the specified rate has changed between
versions, introducing this regression.



-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages iperf depends on:
ii  libc6   2.13-38+deb7u6
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5

iperf recommends no packages.

iperf suggests no packages.

-- no debconf information


all-iperf-output-across-versions.tar.gz
Description: GNU Zip compressed data

Bug#706590: Add penfing tags

[Michael Fincham]

On Fri, 17 May 2013 14:03:16 +0400, Konstantin Khomoutov wrote:
> Michael, could you please check the commit [1] which updates
> README.Debian and NEWS.Debian?   (You could click the "diff" links to
> view the added content.)  Does their wording appear sensible to you?

Looks good, except there's a typo:

+  This release adds support for the SCRAM-SHA-1 authentication mecnahism.

The last word should be "mechanism".

Thanks,
-- 
Michael Fincham


pgpg8awvFLgOA.pgp
Description: PGP signature

Bug#678133: [CVE-2012-2742] Limits effective password length to 32 characters

[Michael Fincham]

On Sat, 1 Sep 2012 14:42:03 +0200, Olivier Berger wrote:
> I'm not sure but it seems that revelation 0.4.14 implements a new file format 
> supposedly more secure, which may also mean that this is fixed in that 
> release.

I've backported 0.4.14 from <http://oss.codepoet.no/revelation/src>
using mostly unmodified the current package setup from stable and can
confirm it does fix the 32 character limit, and probably even more
importantly, the encryption key derivation algorithm flaw.

From the upstream bug it seems like the key derivation algorithm used
in 0.4.13 is dangerously weak.

"A new encryption system has been implemented using PBKDF2.

The user will be informed that a the old system is non-secure and
advice to save the file with the new format if it opens an old formated
file."

This was on 2012-06-24, more than a year ago. I suspect this may
deserve some more urgent attention to protect the users of Revelation
in Debian.

-- 
Michael Fincham


pgpajPoXmgoqg.pgp
Description: PGP signature

Bug#706590: ejabberd: documentation should mention new "fqdn" option to fully resolve #654853

[Michael Fincham]

Package: ejabberd
Version: 2.1.10-4
Severity: important

Dear Maintainer,

A patch was applied in bug #654853 to fix the handling of DIGEST-MD5 against
Pidgin in wheezy.

In order for this patch to be effective an additional option needs to be set in
the configuration file specifying the correct fqdn to use in computing the
DIGEST-MD5 hashes, however this is not mentioned in the bug or changelog.

Speaking to Konstantin Khomoutov it seems the best course of action is for the
README.Debian and NEWS.Debian files in the package to be updated with some
brief instructions on the use of the new "fqdn" configuration file option.

This configuration change and patch is required for wheezy Pidgin clients
(2.10.6-3) to continue to connect to ejabberd servers so is likely to be of
interest to quite a number of people.

--
Michael Fincham



-- 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/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#607156: ITP: whatmask -- Whatmask is a small program to help with calculating a range of network settings

[Michael Fincham]

Package: wnpp
Owner: Michael Fincham 
Severity: wishlist

  Package name: whatmask
  Version : 1.2
  Upstream Author : Joe Laffey 
  URL : <http://www.laffeycomputer.com/whatmask.html>
  License : GPL
  Programming Lang: C
  Description : Whatmask is a small program to help with
calculating a range of network settings

Whatmask can work in two modes. The first mode is to invoke Whatmask
with only a subnet mask as the argument. In this mode Whatmask will
echo back the subnet mask in four formats, plus the number of useable
addresses in the range.

To use Whatmask in its second mode execute Whatmask with any ip address
within the subnet, followed by a slash ('/'), followed by the subnet
mask in any format. (e.g. 192.168.0.23/255.255.255.224, or
192.168.0.23/27)

Whatmask will echo back the following:

* The netmask in the following formats: CIDR, Netmask, Netmask
  (Hex) Wildcard Bits
* The Network Address
* The Broadcast Address
* The number of Usable IP Addresses
* The First Usable IP Address
* The Last Usable IP Address

-- System Information:
Debian Release: 5.0.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



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