Bug#581505: trousers: --chuid is not the problem

[Lukas Schwaighofer]

Package: trousers
Version: 0.3.9-3
Followup-For: Bug #581505

Hi,

I came across the same bug as Taisuke Yamada and digged into the
problem (running as root is not an option for me):

What happens is the following:
1. The unpacking process creates /lib/udev/rules.d/45-trousers.rules
   (which sets the permissions for /dev/tpm[0-9]*
2. Udev imediately examines this. Since the user and group tss do not
   exist at that point, a warning is issued to syslog
   (udevd: specified user 'tss' unknown)
3. After unpacking postinst is executed, which creates user and group
   tss and executes 'udevadm trigger --sysname-match=tpm[0-9]*'

Because udev examines the rule too early (and doesn't reexamine it
once the tss user and group are created) the udevadm trigger will
actually cause the device to be owned by root. This prevents the daemon
from being started and, thus, causes the init-script to fail.

One of these two solutions should fix the problem:
1. Create the tss user and group during preinst instead of postinst
2. Ask udev to reexamine the rules again by executing
   'udevadm control --reload-rules' before executing
   'udevadm trigger ...'

The first method seems cleaner to me.

Regards,
Lukas Schwaighofer


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

Bug#701910: kvm: Wrong packagename in description of kvm package

[Lukas Schwaighofer]

Package: kvm
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

the long description of the kvm package says the following:

This transitional package helps users transition from the kvm package to
the kvm-qemu package.  Once this package and its dependencies are
installed you can safely remove it.

However, the name of the package is qemu-kvm and not kvm-qemu (it's
correct in the short description).

Thanks
Lukas

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRL5TOAAoJEMqNQAGevU6T1SwQAJf+/nAUAto1LSZLaBWJIDYT
XDG/sn9IhwAcGzjgI8GGzQrEtN3WLCq3+/64eeKjXlkuRqje9ExfBB4mIvoZylcf
so4iLv2VUOVqG2qkufAHV5uKmmFuRQXHfgCCn7usi/xhv1SQkJs6aQfeRihW9CrG
nHIcPMO8lxSaqDFR+BS5jMPY0ys56V0Do978o+b4jIeR+aPFX8WlADgbyueq7oFI
s0LKdBRSpDyWr793z2GPHxTn550bcJBz16QxTwfnX15veWBujNTxxNySCupNzLXZ
bw1xpIiEm/dQk4llUdh3ILKmuIDVl3lvXEsrOPWWyMvcTTl8D23h42f1XV7krL/u
LBb5+yhdiCQNXrBGvS+bgtHzosmISbzrVr+ty9ugrsSRdw5OV0ul3eMkLqBGPfUT
bzfm4/94B8XFdTOuLH1xx7gdiBas96DjjirtH7GAe5hofqhHpbV3AZ74ih3yxu5E
FLNFraAqMfc5WlRCWSeqilrJE/aWPICNL4tx4hiHT0zZYS0rtuoeALihL7g7iySw
sJySUcd+isFN8lRBur5z+3BMJSCD23T1xY6grfOZfVP7JPmgj2AAC7lyB8SSrTlK
KIP+Uax/HjB2C13PwwhrHbD3ejC49gSqKoqdug8R9SjEyCRX6rY7XMpWKA78r9Ei
6jJMPtjTFl+u9OMNtLaf
=yWR8
-END PGP SIGNATURE-


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

Bug#699554: util-linux: default /etc/adjtime as written by /etc/init.d/hwclock.sh is missing a newline

[Lukas Schwaighofer]

Package: util-linux
Version: 2.20.1-5.3
Severity: minor


Hi,

/etc/init.d/hwclock.sh writes a default /etc/adjtime if it doesn't exist
using the following command:

printf 0.0 0 0.0\n0\nUTC  /etc/adjtime

however, hwclock seems to expect a final newline in the file, otherwise a
warning is issued.

Steps to reproduce:

# rm /etc/adjtime
# invoke-rc.d hwclock.sh start
# hwclock
hwclock: Warning: unrecognized third line in adjtime file
(Expected: `UTC' or `LOCAL' or nothing.)

Adding a \n to the printf string solves the problem.

Regards,
Lukas Schwaighofer


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

Bug#581505: trousers: Package doesn't install cleanly on wheezy

[Lukas Schwaighofer]

Package: trousers
Version: 0.3.9-3
Severity: important
Followup-For: Bug #581505

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi again,

I'm raising the severity to important, because the package is not
installable on wheezy (at least for non tech-savvy users) under certain
conditions (a TPM chip is available and the kernel modules are loaded).

Regards,
Lukas Schwaighofer

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRD4GQAAoJEMqNQAGevU6ToMEP/1APRzzDXajAwIrZ3/QmxqeL
dGu1IkpDcMVXSLfcyv4bUZGFfGTbfJqC1z5E10b4BZlQ21gcudlDGMmZj12bV2S1
h7D/UwCE3eff5xd42ZGtVkUDC+vphVk7u4oL9tdACuu5/0W80njiYXxIwu55CG6U
k5nZvMtjiR8hxI6ZRPLYsVF2LSDTpZO04d57o97bpGLTAbYRdlNfblJg5iJN8xBw
v5r3t33ujAL0wA+16ir3aM2MZMW67hLeJs9f/ygs0chIrT8bvnuA67V0+5jIPgiG
PA3G/7YaVwrWhqWH7BCQD6LUGS9dm9sQAJbJsBDRPcQwpijfP8dzNdS/aTbBU0YY
Upqc3KMoN1W/y2fKeRuEHF5/qsWHayJPkoQPrZo+qXibVkzJ6rgxYaj7pIESPDjZ
7oNtC1wrH7cGwAWs8K3LjVwkE/b9NeksvtGgDjPtKJYL2MgKm6q9bEJxJ8SuG9N2
Sa0tYYpQMZhkYOhQnQN1RtnJOit1Za6nhB6FfOYuF4wTJ+QtHQ43unrdSbQLcO8d
ZBTX38SZ9vthuExChse/3TpumWvvjnpW/lFyFadOJY1QjsHKX1pZuaOtRKpLaEfG
1twmHnIi370sBoCbD3ApX/9unV39F8PDD0pR/dTgo/wMhMGgzFk1ReUv2iToSq4+
LNZd3r1OrZVN64XC13eL
=BREX
-END PGP SIGNATURE-


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

Bug#700197: grub-common: /etc/grub.d/20_linux_xen should use module --nounzip for initrd

[Lukas Schwaighofer]

Package: grub-common
Version: 1.99-26
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

Boot entries generated by /etc/grub.d/20_linux_xen look like this
(unnecessary parts omitted):

multiboot /boot/xen-4.1-amd64.gz placeholder
module /boot/vmlinuz-3.2.0-4-amd64 placeholder [...]
module /boot/initrd.img-3.2.0-4-amd64

This causes the last module, which is the initramdisk, to be unzipped by
grub (and not by the linux kernel, which happens when booting without
xen, using the 'linux' and 'initrd' directives).

While this usually isn't a problem, the initramdisk may in fact contain
multiple concatenated archives (see
http://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt
for details). If that's the case and the first initrd is gzipped, grub
tries to unzip the whole initrd resulting in an error (and an unbootable
system).

I strongly suggest adding --nounzip to the module directive of the
initramdisk. The boot entries should look like this:

multiboot /boot/xen-4.1-amd64.gz placeholder
module /boot/vmlinuz-3.2.0-4-amd64 placeholder [...]
module --nounzip /boot/initrd.img-3.2.0-4-amd64


Kind regards,
Lukas Schwaighofer

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRFqjJAAoJEMqNQAGevU6TBbwQAJtUnV41UZT4weL5ovTUwjL1
hMjmUqCQmr/7Q6MLwRjWJoWwATLzW+SVSK1rEzpqhTTwro281t+zLhCLXT6kJQTS
hzckUxDBpRbvvNHCsQIlwrCQ73ja7Sh/bmgyPScdlkHmEQ9a92WDVWQdHVinJpHa
PFDu+htGA1dZmonjVzyPIlcZYx6USxz4xyqJcMyHvzs90o/YualCsMGEf059fhf6
p9egpRoRNevLRfLc0zFqrXDIR1eE8XeAxvoxU75aLQCwFs5FEuZ/zSj+eWhZoHUD
h2JZ7jlrdoEbxmCwC5fXa2MgL2sHvda9m1yIysAzhL50lio03F3iqGnE1YslC7bR
6RsLhdiDp5VzeTM2tPSwil731E8DbBiMnPD+tffDZWGPAmXtZvWgBOrtT1bJtI0m
R5NMGj6JPZr5UeI9F5bn3HRqT/+e+4pQiPDyToZlI+9sjXRGoJ/PAuAHcyyXAN/C
QmFNgkip83wcqng1LgBgexE8DYbtljmp3aSo1PO4XVGOoMD69yxyIdjynI5diSa+
35cfbyLizm8ezSjmzx0kPrXttfzhWR+/LCJaOHwl9Vk+OdxCnzrcwmNZmK3EMwDH
hLLRouZkNFkuWoUC5ZpjSIMF5piH2M9Jpy7D2uBIrZsIeIv2jWXGoyO4OEeDPrZC
/waZrsPSiiYv2rYjrqcj
=qy1U
-END PGP SIGNATURE-


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

Bug#697275: ebtables: gives warning on installation

[Lukas Schwaighofer]

Package: ebtables
Version: 2.0.10.4-1
Followup-For: Bug #697275

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I encountered the same problem, attached the (trivial) patch.

Regards
Lukas


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRI8RzAAoJEMqNQAGevU6TozcP/0XklEOu4zExgxRqWqZQphdU
YWIPiU3Hw/pCOJh7JpUeJgmXMYUYrmwXrVKJT6zWSqr3wo2U87Sb4dYQsOKs+r1f
wZUwnV0XJsC2XcPQoiSwKDhZB4yacxUIuJtP3K7D6HCbs/oHqyP/JgwmXN3iv07D
xyCr+vEHMQelVpzm4zb+LUd3JFvLuFRVl2WABK0fs2KOsQ1WJny95B1sfJU92xBC
8PaYNokN2uULVIC1nPxTquzBxa2weScSeRuzLAZU1O9WgxJPYsk7dQ0/F9v8lNb+
1r/qJPHp7Di1ThBp2yprPICBV6jaLS9FnSzC1rvAKu8nMIqPohvX5BJ03E1F+WSc
XUra45LyH3Ei2P/TzvGf5keMvtI7xSGEiF18WwDu9V+YV0xYI/yzipQHcM4K7llw
Pn9kC5hcmxZVB478PALrxKYB3k1D1Y2itiy8RdodlYLF4lbM+d+/QlPGVCkNPMmx
2GFIqvzXqcj6wfKmIDRL4zlE3VglagfDdsD5npmyzlETFqwtXH3jHLOBwBbI9TKx
n43Y2w5CFuyYmsrWBFRg+SQBAhsCis4tfmya/Mk+SBeqQxzOMJ1N/mJr36mV/OR4
a5mPOuxp+0OjzKV/YMwSIekJC827z4ww6lvNuPL5G4uoHhW+OQH3m90proRbUaVK
AqYzXsGfgQFNfNeANU8B
=E6et
-END PGP SIGNATURE-
Description: Supply correct values for update-rc.d legacy mode
Author: Lukas Schwaighofer lu...@schwaighofer.name
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,8 @@
 CFLAGS+=$(HARDENING_CFLAGS) -fstack-protector-all
 LDFLAGS+=$(HARDENING_LDFLAGS)
 
+DEB_DH_INSTALLINIT_ARGS:=-- start 20 S . stop 80 0 1 6
+
 build/ebtables::
 	make CFLAGS=$(CFLAGS) $(MAKE_PATH_REDIRECTIONS)
 

Bug#701672: xen-utils-4.1: add xfs support to pygrub

[Lukas Schwaighofer]

Package: xen-utils-4.1
Version: 4.1.4-2
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Dear Maintainer,

Please consider adding xfs support to pygrub in xen-utils-4.1. The
version from xen-utils-4.2 from upstream supports xfs and the required
changes are minimal. I am attaching a patch which was constructed by
squashing the following commits together:

5fa9d87e8f1adada24fcaa4f3a8a905defda54cf
393375e7271d4a5576ad740a304f9874d6958990
69698ae65775e8f7a2b789400421cb38dbacced0
321e74e4bc96b34c687b17d5dcb2734f2651eabb

I rebuilt the package on my amd64 system after applying the patch and
it's working for me.

Thanks
Lukas Schwaighofer

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRK9wFAAoJEMqNQAGevU6TkdMQAKvnbHKKAJ2BcPPSN3xGc7PF
KwrdP0uHK00ryr0XIzll/1P5BXVkCaExlpK4We9DmbRuo2rJCgb2He8W3/Hm+oPs
aaT2l2ZDyNCtbk7I8rznW8rWM7weG1x1XAt4U/JLxUfQI0CZCwmjDyCYrF2A+XVZ
PgnvfO+MMJz/6O7CpFbpsbOftw7M2OVcX9Wko3hkVO6pNm6Sxhhr+CJqOkQFt0Pu
HPPwrVBGfZ57997p9n0aHVx/R0km81cELg5KB7JuN3ZGhEboe1E5eDfW3l5XsLBG
DFMpnEJ/1IE2JwLQLW9VWtQ6GqhvZ9ROlUCQjbOxQ7lAPh3g4qmDdDUMsheZzgkH
aeuwpyJdBET/V7w1eEHGKrdlUFQ3zuU5Cv1FG+24gOUm8U6/WSJ7E14po3nh6+Rt
jRqgQ2il7prbHTorydtYZApVewbB7SqrtAn0Cf7C2gjWR57SbLtaNehmreNMsGe8
FRI33n9TkTMXpZmjp915YcWcVdcz1CIQTEil+OeQO8olcSvsafu3AA4PUOwSRXrX
44HLxTiQvrzVszRGKTvDJLbUrJF1p3hyW4A0OExTt53jvw+ip5bl/WnjjV4oZGSO
fiiP6+Tn0St0gal+ejOCB3t5E/b8giIrGNjGPCoqQKMEc1ZXmdNVZf+fhKSjTno7
NDR/3mNjhORpmxo+5z8Z
=hYlQ
-END PGP SIGNATURE-
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -2,6 +2,7 @@ XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC=$(CC) ./check-libext2fs)
 
 .PHONY: all clean install
--- /dev/null
+++ b/tools/libfsimage/xfs/Makefile
@@ -0,0 +1,13 @@
+XEN_ROOT = $(CURDIR)/../../..
+
+LIB_SRCS-y = fsys_xfs.c
+
+FS = xfs
+
+.PHONY: all
+all: fs-all
+
+.PHONY: install
+install: fs-install
+
+include $(XEN_ROOT)/tools/libfsimage/Rules.mk
--- /dev/null
+++ b/tools/libfsimage/xfs/fsys_xfs.c
@@ -0,0 +1,637 @@
+/* fsys_xfs.c - an implementation for the SGI XFS file system */
+/*  
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2001,2002,2004  Free Software Foundation, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include fsimage_grub.h
+#include xfs.h
+
+#define MAX_LINK_COUNT	8
+
+typedef struct xad {
+	xfs_fileoff_t offset;
+	xfs_fsblock_t start;
+	xfs_filblks_t len;
+} xad_t;
+
+struct xfs_info {
+	int bsize;
+	int dirbsize;
+	int isize;
+	unsigned int agblocks;
+	int bdlog;
+	int blklog;
+	int inopblog;
+	int agblklog;
+	int agnolog;
+	unsigned int nextents;
+	xfs_daddr_t next;
+	xfs_daddr_t daddr;
+	xfs_dablk_t forw;
+	xfs_dablk_t dablk;
+	xfs_bmbt_rec_32_t *xt;
+	xfs_bmbt_ptr_t ptr0;
+	int btnode_ptr0_off;
+	int i8param;
+	int dirpos;
+	int dirmax;
+	int blkoff;
+	int fpos;
+	xfs_ino_t rootino;
+};
+
+static struct xfs_info xfs;
+
+#define dirbuf		((char *)FSYS_BUF)
+#define filebuf		((char *)FSYS_BUF + 4096)
+#define inode		((xfs_dinode_t *)((char *)FSYS_BUF + 8192))
+#define icore		(inode-di_core)
+
+#define	mask32lo(n)	(((xfs_uint32_t)1  (n)) - 1)
+
+#define	XFS_INO_MASK(k)		((xfs_uint32_t)((1ULL  (k)) - 1))
+#define	XFS_INO_OFFSET_BITS	xfs.inopblog
+#define	XFS_INO_AGBNO_BITS	xfs.agblklog
+#define	XFS_INO_AGINO_BITS	(xfs.agblklog + xfs.inopblog)
+#define	XFS_INO_AGNO_BITS	xfs.agnolog
+
+static inline xfs_agblock_t
+agino2agbno (xfs_agino_t agino)
+{
+	return agino  XFS_INO_OFFSET_BITS;
+}
+
+static inline xfs_agnumber_t
+ino2agno (xfs_ino_t ino)
+{
+	return ino  XFS_INO_AGINO_BITS;
+}
+
+static inline xfs_agino_t
+ino2agino (xfs_ino_t ino)
+{
+	return ino  XFS_INO_MASK(XFS_INO_AGINO_BITS);
+}
+
+static inline int
+ino2offset (xfs_ino_t ino)
+{
+	return ino  XFS_INO_MASK(XFS_INO_OFFSET_BITS);
+}
+
+static inline xfs_uint16_t
+le16 (xfs_uint16_t x)
+{
+	__asm__(xchgb %b0,%h0	\
+		: =Q (x) \
+		:  0 (x)); \
+		return x;
+}
+
+static inline xfs_uint32_t
+le32 (xfs_uint32_t x)
+{
+#if 0
+/* 386 doesn't have bswap.  */
+	__asm__(bswap %0 : =r (x) : 0 (x));
+#else
+	/* This is slower but this works on all x86 architectures.  */
+	__asm__(xchgb %b0, %h0 \
+		\n\troll $16, %0 \
+		\n\txchgb %b0, %h0 \
+		: =Q (x

Bug#725786: bridge-utils: Improving the bridge_hw option in /etc/network/interfaces

[Lukas Schwaighofer]

Package: bridge-utils
Version: 1.5-6
Severity: wishlist
Tags: patch


Dear Maintainer,


I came into the situation where I wanted to assign a specific hw address
to a bridge device.  However, using the bridge_hw option didn't work for
me as I wasn't adding any interfaces to the bridge (the bridge is used
for attaching virtualbox VMs which somehow magically work without `brctl
show` displaying any interfaces).  Changing the mac address with
`ip link set address … dev br0` after the bridge was created caused it
to change its state from UNKNOWN to DOWN which make it unfunctional for
virtualbox.  Manually changing the state to UP didn't work either.


While reading the ip-link.8 man page I noticed that this can also be
used to create bridge devices with the option of specifying a mac
address.  After some testing, I ask you to consider using this way to
create bridge interfaces in conjunction with the bridge_hw option, as
the hw address stays the same even after interfaces are added and
removed.  See the following sample output of some commands (I've tried
it with the mac addresses for br0 being both larger and smaller compared
to eth0).

# ip link add br0 address fc:cc:cc:cc:cc:cc type bridge
# ip a s dev br0
27: br0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN group default
link/ether cc:cc:cc:cc:cc:cc brd ff:ff:ff:ff:ff:ff
# brctl addif br0 eth0
# ip a s dev eth0
3: eth0: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast master br0
state DOWN group default qlen 1000
link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
# ip a s dev br0
27: br0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN group default
link/ether cc:cc:cc:cc:cc:cc brd ff:ff:ff:ff:ff:ff
# brctl delif br0 eth0
# ip a s dev eth0
3: eth0: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast state DOWN
group default qlen 1000
link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
# ip a s dev br0
27: br0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN group default
link/ether cc:cc:cc:cc:cc:cc brd ff:ff:ff:ff:ff:ff
# brctl delbr br0

As far as I can tell using `ip link add …` without the address yields
the same behavior as using brctl addbr, so I wrote a (trivial) patch to
/lib/bridge-utils/ifupdown.sh implementing the change suggested above.
Of course the man page would also need an update if the change was accepted.


Regards
Lukas Schwaighofer


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages bridge-utils depends on:
ii  libc6  2.17-93

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown   0.7.44
ii  net-tools  1.60-25

-- no debconf information
--- ifupdown.sh.orig2013-10-08 10:52:10.436394216 +0200
+++ ifupdown.sh.new 2013-10-08 10:58:57.283961964 +0200
@@ -27,7 +27,11 @@
 
 # Previous work (create the interface)
 if [ $MODE = start ]  [ ! -d /sys/class/net/$IFACE ]; then
-  brctl addbr $IFACE || exit 1
+  BROPTS=
+  if [ $IF_BRIDGE_HW ] ; then
+BROPTS=$BROPTS address $IF_BRIDGE_HW
+  fi
+  ip link add $IFACE $BROPTS type bridge || exit 1
 # Wait for the ports to become available
   if [ $IF_BRIDGE_WAITPORT ]
   then
@@ -66,10 +70,6 @@
   if [ -x /etc/network/if-pre-up.d/vlan ]; then
 env IFACE=$port /etc/network/if-pre-up.d/vlan
   fi
-  if [ $IF_BRIDGE_HW ]
-  then
- ifconfig $port down; ifconfig $port hw ether $IF_BRIDGE_HW
-  fi
   if [ -f /proc/sys/net/ipv6/conf/$port/disable_ipv6 ]
   then
 echo 1  /proc/sys/net/ipv6/conf/$port/disable_ipv6


signature.asc
Description: OpenPGP digital signature

Bug#728914: grub-pc: grub rescue with raid1 root on 4TB device

[Lukas Schwaighofer]

Hi,

the only thing that comes to my mind (but you most likely did this
properly): is the correct core.img installed on *both* sda and sdb (i.e.
you executed 'grub-install /dev/sda' and 'grub-install /dev/sdb')?

Regards
Lukas Schwaighofer



signature.asc
Description: OpenPGP digital signature

Bug#725786: bridge-utils: Improving the bridge_hw option in /etc/network/interfaces

[Lukas Schwaighofer]

Hi,

thank you for looking into this! Sorry for not responding to your
previous mail (I really didn't have anything to add at that point
though).

On Sat, 7 Dec 2013 01:35:37 +0100
Santiago Garcia Mantinan ma...@debian.org wrote:

 While I was investigating your suggestion I realised that if I set
 the hw address with
   ip link set dev br0 address whatever
 then the address is preserved no matter what cards are attached to the
 bridge, thus doing what you want without needing to change the way on
 which we create the bridge.

I agree that this would be the preferable way.

 So, what I'm thinking on doing is to set the hardware address like
 that on the next version of the package, instead of playing with the
 address of the nics, which was a little bit dirty anyway.
 
 Can you check if this works for you?

Unfortunately it doesn't, see the output below:

# brctl addbr br2
# ip link set br2 up 
# ip address show dev br2
16: br2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
UNKNOWN group default link/ether e6:0f:87:cc:8b:a6 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e40f:87ff:fecc:8ba6/64 scope link
valid_lft forever preferred_lft forever

The bridge interface reports state UNKNOWN, but is really up (and also
has an IPv6 link-local address).

# brctl addbr br2
# ip link set address fe:9e:82:a8:a0:4b dev br2
# ip link set br2 up
# ip address show dev br2
17: br2: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue
state DOWN group default link/ether fe:9e:82:a8:a0:4b brd
ff:ff:ff:ff:ff:ff

The specified MAC address is correctly set to the bridge interface, but
the state is DOWN (and no IPv6 link-local address is present). In this
state the bridge is unusable for VirtualBox VMs.

# ip link add br2 address fe:9e:82:a8:a0:4b type bridge
# ip link set br2 up
# ip address show dev br2
18: br2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state
UNKNOWN group default link/ether fe:9e:82:a8:a0:4b brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc9e:82ff:fea8:a04b/64 scope link 
   valid_lft forever preferred_lft forever

This reassembles the output of the initial set of commands with the
correct MAC address set. This way my VirtualBox VMs can use the bridge
without any problems.

We'd probably have to look at the kernel code to find out the reason to
this (seemingly strange) behavior. My guess is that the VirtualBox
kernel module is really to blame because the VMs can use the bridge but
`brctl show` doesn't show any associated interfaces. This could mean
that the kernel isn't properly informed that the bridge is actually
being used. But again, I'm just guessing here.


I can understand that you are reluctant to change the way the bridge
interfaces are created. I initially opened this wishlist bug not only
because I could solve my (probably not very common) problem but also
because `man 5 bridge-utils-interfaces` suggests that the maintainer is
unhappy with the way the bridge_hw option works. Your proposed solution
makes a lot more sense compared to setting the hw address of all
participating NICs. So if you're happy with that feel free to implement
it. I can easily implement my workaround by using the pre-up/post-down
options to create/destroy the bridge using the iproute2 tools.

I hope this information is helpful to you. Thanks again for your time
and effort!

Regards
Lukas


signature.asc
Description: PGP signature

Bug#725786: bridge-utils: Improving the bridge_hw option in /etc/network/interfaces

[Lukas Schwaighofer]

Hi,

On Sun, 8 Dec 2013 10:37:14 +0100
Santiago Garcia Mantinan ma...@debian.org wrote:

 So... the question would be... on your setup do you have a network
 card attached?

I have no interface attached to the bridge (as you can see from my
commands I didn't use any »ip link set … master br2« or add »brctl
addif br2 …« commands). I know your proposed solution works once you
attach a slave interface to the bridge.

 I was wondering if it would make sense to upload my new version
 anyway, as I believe that it doesn't go wrong with real hardware (I'm
 using it right now and it has a ipv6 added and all the stuff), that
 way you could test it on your setup.  Plus I like this solution
 better than changing all cards hw address. What do you think?

I agree that this will be an improvement over the current setup.

However, if the bridge is just used to communicate with the VirtualBox
VMs (and thus both »bridge_ports none« and »bridge_hw …« are used
for setting the bridge up in /etc/network/interfaces) I'm pretty sure it
won't work.


After doing some more reading I learned that brctl uses ioctl (just
like ifconfig) and will probably be deprecated at some point in the
(far away) future. A lot bridge functionality is available within the
version of the iproute2 package available in jessie (»ip link« for
adding bridge interfaces and enslaving devices, »bridge« for setting
various properties). Some kernel bridging functionality (like bridges
with vlan filters) can to my knowledge currently only be accessed using
the »bridge« utility.

With this newly learned information I think it is good practice to
prefer iproute2 commands over commands using ioctl (in our case brctl).
Also I think that other people will run into the same problem that I
had. So I would still suggest adding and removing bridge interfaces
with the iproute2 commands, directly setting the mac address on
interface creation if the »bridge_hw« option is given.


If you don't want to do this, just go ahead and upload your new
version. I can live with using pre-up and post-down commands to create
the bridge in a way that works for me.

Thanks
Lukas


signature.asc
Description: PGP signature

Bug#686754: Is there any hope that this bug will be fixed?

[Lukas Schwaighofer]

Hi Karsten,

On Wed, 15 Jan 2014 10:35:55 +0100
Karsten Malcher deb...@dct.mine.nu wrote:
 Calling os-prober only give this information:
 # os-prober
 /dev/sda2:Debian GNU/Linux (7.2):Debian:linux
 /dev/sda3:Debian GNU/Linux (jessie/sid):Debian1:linux

For type linux os-prober calles linux-boot-prober next with the
partition as a parameter. For /dev/sda3 it would call
# linux-boot-prober /dev/sda3
See /usr/share/doc/os-prober/README for more information.

 It seems not to merge the information with the UUID of the partitions.
 I found an other interesting effect, which explains that this bug has
 not been found. Now an grub-update produces the correct grub.cfg.
 (...)
 
 What i did in the history:
 1. I unpacked an backup of /dev/sdb1 (Grub partition with Debian
 wheezy) to /dev/sda3
 2. I altered the fstab of the copy and run update-grub (After this i
 got this wrong grub.cfg)
 3. I boot from /dev/sda3 and made an system-upgrade from wheezy to
 jessie
 4. After the upgrade i run update-grub again from /dev/sdb1 to
 actualize the new kernel on /dev/sda3 (Now grub.cfg is correct)
 
 Is it possible that the (wrong) information is extraced from
 initrd.img ?

To my knowledge linux-boot-prober does the following:
* Mount the given partition read-only to a temporary directory
* Read the /etc/fstab of this partition to check if /boot is on a
  separate partition. If so, it is also mounted.
* Read and parse the boot loader configuration from the temporary
  directory. For grub2 that is boot/grub/grub.cfg. The parameters to
  the linux kernel (the root=… directive that was wrong in your case)
  should be directly taken from this file.
* Unmount everything again

So your report from your message #15 makes sense, if
the /boot/grub/grub.cfg file on sda3 (I'm assuming you do not have a
separate boot partition) previously contained the wrong parameters for
the Linux kernel
(root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single).

Regards
Lukas


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

Bug#725786: bridge-utils: Improving the bridge_hw option in /etc/network/interfaces

[Lukas Schwaighofer]

On Wed, 18 Dec 2013 01:36:41 +0100
Santiago Garcia Mantinan ma...@debian.org wrote:

 First tests went really wrong.
 
 I have this setup:
 
 auto br0
 iface br0 inet static
 address X.X.X.X
 netmask 255.255.255.0
 bridge_ports all
 bridge_fd 2
 bridge_stp on
 bridge_hw XX:XX:XX:XX:XX:XX
 
 Can you test something like this (I had just one ethernet card on the
 bridge) on your systems to see if it works?
 
 I had different behaviours, sometimes it didn't even learn arps,
 others it did learn arps but ping and other things wouldn't work. I
 believe the difference may be that I'm using stp.

You are right, it doesn't work for me either. I did some additional
testing and will try to summarize my findings. The two ways I created
bridges during testing were:

A)
# ip link add brX address XX:XX:XX:XX:XX:XX type bridge

B)
# ip link add brX type bridge
# ip link set brX address XX:XX:XX:XX:XX:XX

With A) the bridge is unable to communicate via enslaved network
devices (probably other things fail too, haven't checked). Only once
the bridge device itself is put into promiscuous mode (which shouldn't
be necessary), e.g. by starting tcpdump (without -p) or wireshark,
things start to work.

Witch B) the bridge seems to works fine, at least in simple scenarios
(I did no extensive testing).

I was trying to find any difference between the two created bridges
but I couldn't find any. I looked at netlink communication via `bridge
monitor`/`ip monitor` and I checked all the parameters of the bridge
in /proc/sys/net/ipv{4,6}/{conf,neigh}/brX/* .

As of now I couldn't find out what is responsible for the bad behavior
in A). By now I agree with your suggestion to use
ip link set brX address XX:XX:XX:XX:XX:XX
after the interface was created (with either brctl or iproute2). I'm
still interested why A) doesn't work; if I find the time I will look
into this more extensively. If you have any ideas that might help
tracing this problem please let me know. As for my “special” problem,
I will try to work around it by attaching a dummy interface to the
bridge.


Thanks for your effort and sorry for suggesting something that doesn't
work with ”real“ bridges.

Lukas


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

Bug#725786: Revisiting this...

[Lukas Schwaighofer]

Hi,

sorry, I really don't have anything valuable to add (and I have no idea
which kernel versions changed the behavior). However, if you want me to
try out a new solution at some point I'll be happy to do so.

Just for the record, I use the following configuration which works fine
for my case:

iface br0 inet static
address 10.1.2.3/24
pre-up ip link add $IFACE address 02:01:00:03:04:05 type bridge
post-down ip link delete $IFACE type bridge

Thanks
Lukas


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

Bug#774976: xen-tools: disableStartStopDaemon does not handle dpkg updates

[Lukas Schwaighofer]

Package: xen-tools
Version: 4.5-1
Severity: normal
Tags: patch


Hello again,

I had an issue with enableStartStopDaemon and disableStartStopDaemon
after the security update of dpkg in June 2014 [1]. The upgrade of the
dpkg package after enableStartStopDaemon was called caused the stub
starter to be overwritten. This resulted in some services being started
in my dom0. Also /sbin/start-stop-daemon was reverted to the version
prior to the security update by disableStartStopDaemon.

I have worked around the issue using dpkg-divert, patch attached. If
you feel this is the wrong way to fix the issue for any reason feel
free to disregard the patch. I am using the patched version since June
and it seems to work fine. If I didn't make a mistake, this approach
should only fail if a starter is already dpkg-diverted or the
${daemonfile}.REAL file I'm diverting to already exists (which both
shouldn't be the case for a new install).

Sorry for not reporting this earlier, I only remembered it after
reporting the other issue earlier today. Thank you for developing and
maintaining xen-tools!

Regards
Lukas

[1] https://lists.debian.org/debian-security-announce/2014/msg00133.html
diff --git a/hooks/common.sh b/hooks/common.sh
index 02668ec..0c0841e 100755
--- a/hooks/common.sh
+++ b/hooks/common.sh
@@ -272,16 +272,14 @@ disableStartStopDaemon ()
local prefix=$1
assert $LINENO ${prefix}
for starter in start-stop-daemon initctl; do
-  local daemonfile=${prefix}/sbin/${starter}
+  local daemonfile=/sbin/${starter}
 
-  if [ -e ${daemonfile} ]; then
- mv ${daemonfile} ${daemonfile}.REAL
- echo '#!/bin/sh'  ${daemonfile}
- echo echo \Warning: Fake ${starter} called, doing nothing\  ${daemonfile}
+  chroot ${prefix} dpkg-divert --divert ${daemonfile}.REAL --local --rename ${daemonfile}
+  echo '#!/bin/sh'  ${prefix}${daemonfile}
+  echo echo \Warning: Fake ${starter} called, doing nothing\  ${prefix}${daemonfile}
 
- chmod 755 ${daemonfile}
- logMessage ${starter} disabled / made a stub.
-  fi
+  chmod 755 ${prefix}${daemonfile}
+  logMessage ${starter} disabled / made a stub.
done
 }
 
@@ -295,15 +293,14 @@ enableStartStopDaemon ()
local prefix=$1
assert $LINENO ${prefix}
for starter in start-stop-daemon initctl; do
-  local daemonfile=${prefix}/sbin/${starter}
-
-  #
-  #  If the disabled file is present then enable it.
-  #
-  if [ -e ${daemonfile}.REAL ]; then
-  mv ${daemonfile}.REAL ${daemonfile}
-  logMessage ${starter} restored to working order.
+  local daemonfile=/sbin/${starter}
+
+  #  remove the local diversion if it is in place
+  if [ `chroot ${prefix} dpkg-divert --listpackage ${daemonfile}`a = LOCALa ]; then
+  rm -f ${prefix}${daemonfile}
+  chroot ${prefix} dpkg-divert --rename --remove ${daemonfile}
   fi
+  logMessage ${starter} restored to working order.
done
 }
 


pgp1sX70ugSHe.pgp
Description: OpenPGP digital signature

Bug#774936: xen-tools: removeDebianPackage function in common.sh uses nonexistent variable

[Lukas Schwaighofer]

Package: xen-tools
Version: 4.5-1
Severity: normal
Tags: patch


Dear Maintainer,

the removeDebianPackage function uses ${package} which is unset (and
thus the entire command fails when using `set -o nounset`).  The
following trivial patch should fix the problem:


--- a/hooks/common.sh
+++ b/hooks/common.sh
@@ -322,7 +322,7 @@ removeDebianPackage ()
 #
 # Log our options
 #
-logMessage Purging Debian package ${package} from prefix ${prefix}
+logMessage Purging Debian package $@ from prefix ${prefix}
 
 #
 #  We require a prefix


Thank you
Lukas


pgpJvn8TME2p5.pgp
Description: OpenPGP digital signature

Bug#783079: libexosip2-11: Non-existing NAPTR handled incorrectly

[Lukas Schwaighofer]

Package: libexosip2-11
Version: 4.1.0-2
Severity: important

Dear maintainers,

I experience problems calling certain SIP URIs with linphone. If the
callee's domain doesn't have a NAPTR entry, libexosip2-11 erroneously
uses the domain's A/ record with port 5060 instead of doing SRV
lookups as it should (RFC 3263, Section 4.1). I confirmed this by both
looking at both the packet capture and the output of `linphonec -d 6`:

ortp-message-eXosip_dnsutils_naptr_lookup: About to ask for 'example.com NAPTR'
ortp-error-eXosip_dnsutils_naptr_lookup: res_query failed ('example.com NAPTR')
ortp-message-DNS resolution with example.com:5060

(The packet capture confirms that after the NAPTR query no further DNS
queries are sent out.)


When trying to debug the problem I read in the README of the source tree
of the libexosip2-11 package: You should install c-ares before for much
better DNS management!

After installing libc-ares-dev and rebuilding the package linphone works
as expected. The debug output now shows:

ortp-error-_naptr_callback: example.com DNS server returned answer with no data
ortp-message-_naptr_callback: NO NAPTR DNS // SRV record created manually 
-49/49/_sips._udp.example.com
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for 
'_sip._udp.example.com SRV'
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for 
'_sip._tcp.example.com SRV'
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for 
'_sips._tcp.example.com SRV'
ortp-message-eXosip_dnsutils_srv_lookup: About to ask for 
'_sips._udp.example.com SRV

The packet capture also confirms that the SRV lookups are done after the
NAPTR lookup. So if using c-ares is an option, that would work around
the problem. I wasn't able to find the bug that's causing the wrong
behavior in libexosip when c-ares isn't used.

Thank you
Lukas Schwaighofer



pgpvzdG_saA7u.pgp
Description: OpenPGP digital signature

Bug#803938: extlinux: boot from xfs partition not working

[Lukas Schwaighofer]

Package: extlinux
Version: 3:6.03+dfsg-10
Severity: important


Dear Maintainer,


I can't seem to get extlinux to boot from an xfs formated partition. 
I've built myself a little script to create a clean image (attached).
It works just fine if I use `mkfs.ext4` or `mkfs.btrfs` (i.e. it greets
me with a "boot:" prompt).  However, if I use `mkfs.xfs` I only get
"Missing OS".


The results stay the same when using a DOS partition table (and
mbr.bin) instead.  Only the error message when trying to boot from xfs
is slightly different:

  Failed to load ldlinux.c32
  Boot failed: please change disks and press a key to continue.


The version in jessie is also affected by this problem.


Thank you
Lukas Schwaighofer


test_extlinux.sh
Description: application/shellscript


pgpiMkIC2n77d.pgp
Description: OpenPGP digital signature

Bug#799359: live-config: Variables in config files not exported

[Lukas Schwaighofer]

Control: tags -1 + patch

Hi again,

I'd suggest setting the allexport shell option for reading the
configuration files to address the problem. I've added a patch against
the debian-next branch of the live-config repository.

I've also added a slight modification to the man page as a separate
patch, because the configuration files actually do need the ».conf«
suffix.

Regards
Lukas Schwaighofer
From 09ccaf34b1d30f95f324e3685a9400cd8db7034b Mon Sep 17 00:00:00 2001
From: Lukas Schwaighofer <lu...@schwaighofer.name>
Date: Wed, 23 Sep 2015 13:04:41 +0200
Subject: config files actually require the .config suffix

---
 manpages/en/live-config.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/manpages/en/live-config.7 b/manpages/en/live-config.7
index ee53b0f..1cd1041 100644
--- a/manpages/en/live-config.7
+++ b/manpages/en/live-config.7
@@ -112,7 +112,7 @@ Enables debug output in live\-config.
 .PP
 Configuration files can be placed either in the root filesystem itself (/etc/live/config.conf, /etc/live/config.conf.d/*.conf), or on the live media (live/config.conf, live/config.conf.d/*.conf). If both places are used for a certain option, the ones from the live media take precedence over the ones from the root filesystem.
 .PP
-Although the configuration files placed in the configuration directories do not require a particular name or suffix, it is suggested for consistency reasons to either use 'vendor.conf' or 'project.conf' as a naming scheme (whereas 'vendor' or 'project' is replaced with the actual name, resulting in a filename like 'progress\-linux.conf').
+Although the configuration files placed in the configuration directories do not require a particular name, it is suggested for consistency reasons to either use 'vendor.conf' or 'project.conf' as a naming scheme (whereas 'vendor' or 'project' is replaced with the actual name, resulting in a filename like 'progress\-linux.conf').
 .PP
 The actual content of the configuration files consists of one or more of the following variables.
 
-- 
2.1.4

From ba6c618bbd6a18eae826471394c6bbe50fad8a1f Mon Sep 17 00:00:00 2001
From: Lukas Schwaighofer <lu...@schwaighofer.name>
Date: Wed, 23 Sep 2015 13:05:03 +0200
Subject: export variables set in config files

if the variables are not exported, they are not available in the
components
---
 frontend/live-config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/frontend/live-config b/frontend/live-config
index 8c70c71..f934f26 100755
--- a/frontend/live-config
+++ b/frontend/live-config
@@ -41,6 +41,7 @@ export _IP_SEPARATOR _PROC_OPTIONS
 _COMPONENTS="$(ls /lib/live/config/*)"
 
 # Reading configuration files from filesystem and live-media
+set -o allexport
 for _FILE in /etc/live/config.conf /etc/live/config.conf.d/*.conf \
 	 /lib/live/mount/medium/live/config.conf /lib/live/mount/medium/live/config.conf.d/*.conf
 do
@@ -49,6 +50,7 @@ do
 		. "${_FILE}"
 	fi
 done
+set +o allexport
 
 Cmdline ()
 {
-- 
2.1.4



pgp8ButBxSu1T.pgp
Description: OpenPGP digital signature

Bug#799359: live-config: Variables in config files not exported

[Lukas Schwaighofer]

Package: live-config
Version: 4.0.4-1
Severity: important


Dear Live System Maintainers,

many variables (e.g. LIVE_KEYBOARD_*, LIVE_TIMEZONE, LIVE_LOCALES) do
not work if put in the /etc/live/config/* configuration files.  After
some debugging I found that the `live-config` frontend does not export
them and thus they are not set when the components are run.

I had a look at the current version in git and it appears to me the bug
is still present there (although I did not try it out).

My current workaround is to directly export the variables in the
/etc/live/config/* files which works fine.

Thank you
Lukas Schwaighofer


pgpGL7BVKpLJf.pgp
Description: OpenPGP digital signature

Bug#840995: certbot: package new upstream version (support dns-01 challenge)

[Lukas Schwaighofer]

Package: certbot
Severity: wishlist

Dear Maintainer,

the new upstream version (0.9.2) includes support for the dns-01
challenge. Packaging that in time for stretch would really help me.

Thank you
Lukas Schwaighofer


pgpVeOjPgRckI.pgp
Description: OpenPGP digital signature

Bug#857767: found workaround

[Lukas Schwaighofer]

Hi,

in case anybody else is frustrated about this, I've found a
workaround (as root):

mkdir -p /etc/skel/.config/chromium/Default
touch "/etc/skel/.config/chromium/First Run"
echo "{}" > /etc/skel/.config/chromium/Default/Preferences


The lines responsible for this mess in the code seem to be (although I
did not verify since I found a suitable workaround):

$ sed -n '986,987p' chrome/browser/profiles/profile_manager.cc
  if (profile->IsNewProfile() || first_run::IsChromeFirstRun())
profile->GetPrefs()->SetBoolean(prefs::kHasSeenWelcomePage, false);


Regards
Lukas

Bug#858860: RFS: arpwatch/2.1a15-3 [ITA]

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

thanks for the help you have provided so far. I am now officially
looking for a sponsor for the arpwatch package, which I intend to
adopt. I've uploaded my current packaging work to mentors:
  https://mentors.debian.net/package/arpwatch

I've done the work in git. If you want to look at the git history,
you can clone the repository from
  https://git.somlen.de/arpwatch.git
and checkout the staged-changes branch. (I have not yet tagged the
Debian version because I'm quite sure there will be some iterations
before we can actually release…)

If possible I would like to keep the "official" packaging git (Vcs-Git)
on collab-maint; I suppose once I find a sponsor, she or he can push
there for me?


Because of the changes I have made to for native systemd
integration, the upgrade needs a few manual steps (documented in
NEWS). I would be happy if someone has ideas how to avoid that.


Gianfranco suggested also asking the pkg-security-team for possible
sponsors. It would be great if one of you could have a look and provide
guidance! If team maintenance is be possible, I'd like that very
much.


Regards
Lukas Schwaighofer


pgpcIQFw6iuR0.pgp
Description: OpenPGP digital signature

Bug#857767: chromium: allow disabling chrome://welcome on first run

[Lukas Schwaighofer]

Package: chromium
Version: 57.0.2987.98-1
Severity: minor

Hi,

I'm using chromium in a live system deployed in a lab room.  Since the
last upgrade, chrome always displays the "chrome://welcome" page on
first run (which asks the students to sign in with their google
account).

I want to keep the previous behavior, i.e. show the start page of our
lab when they start the computers.  I have the following policy
settings:

$ cat /etc/chromium/policies/managed/ilab.json
{
"PasswordManagerEnabled": false,
"DefaultBrowserSettingEnabled": false,
}

$ cat /etc/chromium/policies/recommended/ilab.json
{
"ShowHomeButton": false,
"BookmarkBarEnabled": false,
"RestoreOnStartup": 4,
"RestoreOnStartupURLs": ["https://OUR-LAB-STARTPAGE/;, 
"https://startpage.com/;],
"DefaultSearchProviderName": "Startpage",
"DefaultSearchProviderKeyword": "startpage.com",
"DefaultSearchProviderSearchURL": 
"https://startpage.com/do/search?q={searchTerms};
}


The only way I have found to disable this behavior is to add the
following to /usr/share/chromium/master_preferences:

"sync_promo": {
  "show_on_first_run_allowed": false
}


It would be nice if you could either disable this sync promotion by
default or provide a way to disable it (without requiring dpkg-divert).

Thank you
Lukas Schwaighofer


pgp6v9EMRoKXL.pgp
Description: OpenPGP digital signature

Bug#857767: Acknowledgement (chromium: allow disabling chrome://welcome on first run)

[Lukas Schwaighofer]

> The only way I have found to disable this behavior is to add the
> following to /usr/share/chromium/master_preferences:
> (...)

Sorry, it seems I got confused and did not remove the chromium profile
before trying. The provided settings do not prevent the dialog from
appearing on first run.

I have not found a way to disable the dialog :( . As this seems to be
an upstream bug feel free to close.

Thanks
Lukas Schwaighofer


pgpJiwbQ4Bbsi.pgp
Description: OpenPGP digital signature

Bug#858105: unblock: gmrun/0.9.2-2.2

[Lukas Schwaighofer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Hi,

Please unblock the package gmrun. The automatic update ("recompiled with
PIC") broke the package (because of API changes in gtk2, it only
produces segmentation faults). The uploaded package includes the patch
extracted from the Fedora project (provided by Andreas Henriksson) to
fix the issue and makes the package usable again. The changelog entry
is:

gmrun (0.9.2-2.2) unstable; urgency=medium

  * Non-maintainer upload.

[ Andreas Henriksson ]
  * fix return type of gtk_completion_line_get_type (Closes: #857065)

 -- Lukas Schwaighofer <lu...@schwaighofer.name>  Sun, 12 Mar 2017 23:49:46 
+0100

I've attached the debdiff between the version in testing and in
unstable.

Thank you
Lukas Schwaighofer
diff -Nru gmrun-0.9.2/debian/changelog gmrun-0.9.2/debian/changelog
--- gmrun-0.9.2/debian/changelog	2010-07-17 19:05:43.0 +0200
+++ gmrun-0.9.2/debian/changelog	2017-03-12 23:49:46.0 +0100
@@ -1,3 +1,12 @@
+gmrun (0.9.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Andreas Henriksson ]
+  * fix return type of gtk_completion_line_get_type (Closes: #857065)
+
+ -- Lukas Schwaighofer <lu...@schwaighofer.name>  Sun, 12 Mar 2017 23:49:46 +0100
+
 gmrun (0.9.2-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru gmrun-0.9.2/debian/patches/return-type-gtk_completion_line_get_type.patch gmrun-0.9.2/debian/patches/return-type-gtk_completion_line_get_type.patch
--- gmrun-0.9.2/debian/patches/return-type-gtk_completion_line_get_type.patch	1970-01-01 01:00:00.0 +0100
+++ gmrun-0.9.2/debian/patches/return-type-gtk_completion_line_get_type.patch	2017-03-12 23:49:46.0 +0100
@@ -0,0 +1,45 @@
+From: Andreas Henriksson <andr...@fatal.se>
+Date: Wed, 8 Mar 2017 23:21:15 +0100
+Subject: fix return type of gtk_completion_line_get_type
+
+Patch originally downloaded from
+https://src.fedoraproject.org/cgit/rpms/gmrun.git/plain/gmrun-0.9.2-f12.patch
+
+slighly modified (parts dropped, fuzz fixed) to apply on top of debian
+package
+
+Closes: #857065
+---
+ src/gtkcompletionline.cc | 4 ++--
+ src/gtkcompletionline.h  | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/gtkcompletionline.cc b/src/gtkcompletionline.cc
+index 90897f7..c247994 100644
+--- a/src/gtkcompletionline.cc
 b/src/gtkcompletionline.cc
+@@ -77,9 +77,9 @@ static gboolean
+ on_key_press(GtkCompletionLine *cl, GdkEventKey *event, gpointer data);
+ 
+ /* get_type */
+-guint gtk_completion_line_get_type(void)
++GtkType gtk_completion_line_get_type(void)
+ {
+-  static guint type = 0;
++  static GtkType type = 0;
+   if (type == 0)
+   {
+ GtkTypeInfo type_info =
+diff --git a/src/gtkcompletionline.h b/src/gtkcompletionline.h
+index 5e14cd7..caed4c7 100644
+--- a/src/gtkcompletionline.h
 b/src/gtkcompletionline.h
+@@ -76,7 +76,7 @@ extern "C++" {
+ void (* cancel)(GtkCompletionLine *cl);
+   };
+ 
+-  guint gtk_completion_line_get_type(void);
++  GtkType gtk_completion_line_get_type(void);
+   GtkWidget *gtk_completion_line_new();
+ 
+   void gtk_completion_line_last_history_item(GtkCompletionLine*);
diff -Nru gmrun-0.9.2/debian/patches/series gmrun-0.9.2/debian/patches/series
--- gmrun-0.9.2/debian/patches/series	2010-07-17 19:05:49.0 +0200
+++ gmrun-0.9.2/debian/patches/series	2017-03-12 23:49:46.0 +0100
@@ -9,3 +9,4 @@
 90-window_placement.patch
 100-gmrunrc.patch
 debian-changes-0.9.2-2.1
+return-type-gtk_completion_line_get_type.patch


pgptH5MPUQK0c.pgp
Description: OpenPGP digital signature

Bug#857065: fixed in gmrun 0.9.2-2.2

[Lukas Schwaighofer]

Hi Martin,

the package is already in the debian archive (as part of the "unstable"
release) and the release team has approved the unblock request [1]. You
can monitor the transition to stretch here:
  https://tracker.debian.org/pkg/gmrun

The current migration status is:
  Too young, only 2 of 5 days old
If no new bugs surface I expect the package to migrate to stretch on
Thursday.

Regards
Lukas

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858105


pgpB6QS_Mq1OJ.pgp
Description: OpenPGP digital signature

Bug#857856: RFS: gmrun/0.9.2-2.2 [RC, NMU]

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "gmrun".

* Package name: gmrun
  Version : 0.9.2-2.2
  Upstream Author : Mihai Bazon <mis...@infoiasi.ro>
* URL : https://sourceforge.net/projects/gmrun/
* License : GPLv2
  Section : x11

It builds those binary packages:

  gmrun - Featureful CLI-like GTK+ application launcher

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/gmrun


Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gmrun/gmrun_0.9.2-2.2.dsc


The automatic update ("recompiled with PIC") broke the package (because
of API changes in gtk2, it now only produces sgementation faults). The
uploaded package includes the patch extracted from the Fedora project
(provided by Andreas Henriksson) to fix the issue.

There was some discussion if there should be more changes to the package
(standads version, debhelper compatibility level, additional hardening
options) in 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857065
and we basically agreed to only fix the RC bug and make further changes
to the package in buster (and possibly experimental) only.


Thank you
Lukas Schwaighofer


pgpbMW6tLeZc7.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

thanks a lot for looking at this.  I have made some changes to the
package based on your feedback, pushed them to my git repository and
uploaded the new version to mentors:
https://mentors.debian.net/package/arpwatch

Some further questions and comments follow inline below.

On Tue, 4 Apr 2017 12:29:09 +0200
Hugo Lefeuvre  wrote:

> https://git.somlen.de/arpwatch.git/ returns 403 Forbidden :)

I do not have a web based git viewer installed on my server, however
  git clone https://git.somlen.de/arpwatch.git
should work. Remember to switch to the `staged-changes` branch.

(I should probably create a page explaining that this is a git only url
instead of displaying a 403…)

> Quick review:
> 
> * lintian reports
> 
>   P: arpwatch source: source-contains-data-from-ieee-data-oui-db
> ethercodes.dat 
> 
>   but it looks like you already fixed it. If this warning is not
> relevant anymore please override it.  

Well, I did not really fix it. ethercodes.dat is still part of the
source package, it's just no longer put into the binary package. But, as
it is small and it does not violate the DFSG, Christian Seiler suggested
on debian-mentors not to repack [1].

I have not previously overridden that tag because I was not sure if it
is best practice to override lintian pediantic tags at all (only quite
few packages seem to do it) as they also don't show up on the
tracker.debian.org page. Anyways, I've now overridden the following two
pedantic tags, together with a justification as comment:
* source-contains-data-from-ieee-data-oui-db
* debian-watch-may-check-gpg-signature

> * There's no copyright entry for you

Fixed.

> Nitpicking:
> 
> in debian/changelog: why "remove dmassagevendor" ? This changelog
> entry could be more verbose.  

Right, I have a longer justification in the git history; I have expanded
on the changelog entry.

> $ cme check dpkg
> [...]
> Warning in 'dirs:0' value 'usr/sbin': Make sure that this directory is 
> actually needed. See 
> L for 
> details
> Warning in 'dirs:1' value 'var/lib/arpwatch': Make sure that this
> directory is actually needed. See
> L
> for details  

If I remove `usr/sbin` from dirs, buildpackage fails complaining that
the directory does not exist (so something in the build system is
slightly broken).

`var/lib/arpwatch` is an empty directory created by the package that is
populated with ethercodes.db during postinst (and then with interface
specific database files once arpwatch is started). Should I create the
directory during postinst instead? Creating the empty directory as part
of the package seems nicer since dpkg will take care of the `rmdir` and
warn the user if the directory is not empty on uninstall.

> [...]
> Warning in 'control source Vcs-Git' value 
> 'git://anonscm.debian.org/collab-maint/arpwatch.git': An unencrypted
> transport protocol is used for this URI. It is recommended to use a
> secure transport such as HTTPS for anonymous read-only access.
> 
> Warning in 'control source Vcs-Git' value 
> 'git://anonscm.debian.org/collab-maint/arpwatch.git': URL is not the
> canonical one for repositories hosted on Alioth.  

I had that on my TODO list but decided to wait and see how I get the
package sponsored before changing the Url. I've now pointed it to what I
expect to become its new home in case you are willing to sponsor the
package:
  https://anonscm.debian.org/cgit/pkg-security/arpwatch.git
  https://anonscm.debian.org/git/pkg-security/arpwatch.git
I've also adjusted debian/control to what I think it should be for team
maintenance (maintainer is pkg-security-team, added myself as uploader).

> Warning in 'control binary:arpwatch Pre-Depends:0' value 'dpkg (>= 1.16.1)': 
> unnecessary versioned dependency: dpkg (>= 1.16.1).
> Debian has oldstable -> 1.16.18; stable -> 1.17.27; unstable -> 1.18.23; 
> testing -> 1.18.23;  

Ok, I removed the pre-dependenciy.

In order to setup the file based trigger I followed man deb-triggers(5)
from dpkg-dev version 1.18.23 (most recent version in unstable) which
states:
> The “-noawait” variants are only supported since dpkg 1.16.1, and will
> lead to errors if used with an older dpkg. It is thus recommended to
> add a “Pre-Depends: dpkg (>= 1.16.1)” to any package that wish to use
> those directives.

Should I file a bug against the dpkg-dev package that this
recommendation should be dropped?


> Warning in 'copyright Format' value
> 'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/':
> Format uses insecure http protocol instead of https  

Fixed.

> $ codespell *
> aclocal.m4:784: seperate  ==> separate
> aclocal.m4:787: independantly  ==> independently
> aclocal.m4:788: dependancies  ==> dependencies
> arp2ethers:8: occurance  ==> occurrence
> config.sub:1161: nto  ==> not  | disable due to \n
> debian/changelog:129: wont  ==> won't, wont
> 

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

On Wed, 5 Apr 2017 18:25:04 +0200
Hugo Lefeuvre  wrote:

> Are you already a member of the team ? If yes, could you move your git
> repository to
> https://anonscm.debian.org/git/pkg-security/arpwatch.git ?

I've now officially joined the team, the repository is available at
that URL.

I've also uploaded the updated package to mentors (not sure if you need
that, probably you will use the git repo instead).

> If needed, I can remove the old one on collab-maint.

If you can do that, after the upload, that would be great.

Thanks
Lukas


pgpkMsTnydSJO.pgp
Description: OpenPGP digital signature

Bug#551350: arpwatch: restart option

[Lukas Schwaighofer]

Hi Stephen,

I recently took over maintenance of arpwatch as part of the
pkg-security team, sorry for reviving this more than 7 years old bug.

Thanks for reporting the bug regarding the restart functionality and
providing a patch. As you probably know (or knew 7 years ago), the
restart functionality only works when arpwatch is run as root. I would
like to discourage anyone from running arpwatch as root, so I'm not
really in favor of implementing nice features that only work when
running as root.


Instead of merging your patch I propose the following:
* we drop the restart functionality altogether; it was introduced in
  Debian and is not part of upstream, so this would reduce the delta
  carried by Debian
* we change the systemd unit file to restart arpwatch automatically if
  it exits uncleanly

Would you be fine with that?


Thank you
Lukas


pgpq9q83d7_Av.pgp
Description: OpenPGP digital signature

Bug#782057: arpwatch problems

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi,

sorry for reviving such an old bug report.  I recently took over
maintenance of arpwatch as part of the pkg-security-team.


In your bug report you described two different problems.

1. Arpwatch does not start properly after startup, requires manual
   restart

Is this issue still present?  If it is, could you check if version
2.1a15-3, which was just uploaded to experimental, fixes the problem?
This new version has native systemd unit files and the startup is quite
different.


2. The arp.dat database was cleared (at least once)

Has this happened more often and/or can you reproduce this problem? I
can think of two reasons why this might have happened:

* two arpwatch instances are accidentally started using the same
  database file and there is a race condition with reading/writing the
  file
* the postinstall script, which used to copy the database around until
  version 2.1a15-1.3, might have cleared it (e.g. due to a
  dpkg-reconfigure)

Neither these two problems can happen any more with version 2.1a15-3,
but maybe your problem is something else.  If you have any further
information please let me know.


Thank you
Lukas


pgpd25LZIRqIb.pgp
Description: OpenPGP digital signature

Bug#439015: arpwatch: allow suppressing well known flip flop messages

[Lukas Schwaighofer]

Control: retitle -1 arpwatch: allow specific IPs to be used by multiple MAC 
addresses without generating flip flop messages
Control: severity -1 wishlist

Hi,

thanks for your bug report.

Unfortunately, suppressing specific flip flop messages is not
implemented in arpwatch.  Normally we would forward such feature
requests to upstream, but arpwatch's upstream has been dead for a long
time.


I'm lowering the severity of this feature request to wishlist.  I
currently do not plan on implementing it.

Regards
Lukas


pgprdEDJt80Wt.pgp
Description: OpenPGP digital signature

Bug#410008: arpwatch: override for flip flop detection

[Lukas Schwaighofer]

Control: severity -1 wishlist

Hi Brian,

thanks for your bug report. Unfortunately, arpwatch's upstream is dead
so we cannot forward the feature request. I'm lowering the severity to
wishlist. I currently do not plan on implementing exceptions for the
flip flop detection.

Regards
Lukas


pgpm6Nwc3YkG0.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi security tools packaging team,

On Mon, 27 Mar 2017 23:03:19 +0200
Lukas Schwaighofer <lu...@schwaighofer.name> wrote:

> Gianfranco suggested also asking the pkg-security-team for possible
> sponsors. It would be great if one of you could have a look and
> provide guidance! If team maintenance is be possible, I'd like that
> very much.

I think arpwatch would be a good fit for the team.  Is there somebody
willing to review my packaging work?

There is, of course, no rush.  I would just like to know if somebody
from pkg-security plans to look at the package eventually or if I should
start looking someplace else for reviewers/sponsors.


Thanks
Lukas


pgpml4vQjvHGW.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Christian,

On Thu, 6 Apr 2017 14:30:24 +0200
Christian Seiler  wrote:
> The problem is that dirs is only interpreted by dh_installdirs, which
> is typically run after dh_auto_install, so that wouldn't actually
> solve your problem.

It does solve the problem (i.e. the error is gone if `usr/sbin` is
present in the `dirs` file).  According to the Debian New Maintainers'
Guide guide, creating directories that are not created by
`make install DESTDIR=...` as invoked by dh_auto_install is exactly
what the dirs file is for [1].

Also, running `dh binary --no-act` in the arpwatch packaging dir yields:
$ dh binary --no-act
   (...)
   dh_installdirs
   dh_auto_install
   (...)


Can you explain in which situations dh_installdirs will be run after
dh_auto_install? 

I'd like to avoid messing with the upstream build system more than
required.  If dh_installdirs isn't the correct approach, maybe I can
create an override_dh_auto_install target and create the directory
there before calling dh_auto_install…?

Thanks
Lukas

[1] https://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs


pgphWjqJgLtYU.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

On Thu, 6 Apr 2017 15:24:04 + (UTC)
Gianfranco Costamagna  wrote:
> -   $(INSTALL) -m 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
> +   $(INSTALL) -Dm 555 -o bin -g bin arpwatch $(DESTDIR)$(BINDEST)
> 
> 
> this should work too (as said above) and is less invasive :)  

As everybody here prefers patching Makefile.in instead of using `dirs`,
I'll go with your recommendation.


Moving forward:
* Does somebody have a recommendation regarding the version for
  experimental (add ~exp1 or just increase the version once more when
  uploading to unstable after stretch was released)?
* Is there a procedure to join (or apply for joining) the
  pkg-security-team? I did not find any information regarding that
  online.


Thanks
Lukas


pgp1UBMO546rn.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

thanks again for the review and the comments!

On Wed, 5 Apr 2017 18:25:04 +0200
Hugo Lefeuvre  wrote:
> > * debian-watch-may-check-gpg-signature  
> 
> I wouldn't override debian-watch-may-check-gpg-signature btw.

Ok, I will revert that override.

> > If I remove `usr/sbin` from dirs, buildpackage fails complaining
> > that the directory does not exist (so something in the build system
> > is slightly broken).  
> 
> The error message is
> 
> /usr/bin/install -c -m 555 -o bin -g bin
> arpwatch /build/arpwatch-2.1a15/debian/arpwatch/usr/sbin /usr/bin/install:
> cannot create regular file
> '/build/arpwatch-2.1a15/debian/arpwatch/usr/sbin': No such file or
> directory Makefile:114: recipe for target 'install' failed 
> 
> looks like the Makefile installs files under usr/sbin, but doesn't
> create the directory if it doesn't exist. This is rather a Makefile
> bug.

With "build system" I meant this process of autotools creating the
Makefile, and `make install` doing something slightly wrong.  Anyway,
that means keeping `usr/sbin` in the dirs file is the correct "fix",
right?

> If the dpkg documentation recommends to do so, then, fine, forget
> about this warning.

But it also makes sense to drop dpkg version constraints at some point.
I wonder if it's not better to ask the dpkg maintainers if that
recommendation still holds…

> Are you already a member of the team ? If yes, could you move your git
> repository to
> https://anonscm.debian.org/git/pkg-security/arpwatch.git ?

I'm not a member of the team yet, where can I apply? :)
Disclaimer: this is my first package…

When pushing to the repository, should the changes go into a separate
branch for experimental (e.g. debian/experimental instead of
debian/master)?
Also I'm uncertain if I should add ~exp1 to the version number. Some
packages seem to do it for experimental uploads, others don't and just
increment the version number once when uploading to unstable later. Do
you have a recommendation?


I have the following on my TODO list which I would like to resolve
before the upload:
* decide on whether to add ~exp1 to version number
* remove the override for debian-watch-may-check-gpg-signature
* update debian/changelog timestamp (which I forgot to do after
  yesterday's changes)
* git-tag the release and push the git repository to its new home


Regards
Lukas


pgplxYA1nteYj.pgp
Description: OpenPGP digital signature

Bug#667655: arpwatch: fails to start the first time

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Philippe,

I recently took over arpwatch maintenance and I'm working through the
list of open bugs. I'm writing you regarding a bug report about
arpwatch not starting you filed back in 2012 [1].

Is this issue still present in the version of arpwatch in Debian
jessie? I've been using arpwach on Debian jessie myself and did not
encounter the problem you described.

Thanks
Lukas

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667655


pgpoLJUzJq3p0.pgp
Description: OpenPGP digital signature

Bug#852360: Cross compiling and Bug#852360

[Lukas Schwaighofer]

Hi Debian cross team,

I have a question regarding Bug#852360 and cross compiling dsniff.

The bug report mentions moving to a more recent autotools fixes the
problem as well. Since the package uses debhelper 10 (which enables the
autoreconf sequence by default), the configure script is regenerated
with a newer version of autotools before being called.

Does that mean that the snippet
> include /usr/share/dpkg/architecture.mk
> ifeq ($(origin CC),default)
> export CC := $(DEB_HOST_GNU_TYPE)-gcc
> endif
can be removed again from debian/rules? I tried to cross compile for
armhf without that snipped using pbuilder (following the instructions
from https://wiki.debian.org/CrossCompiling) which worked: The correct
compiler was called and the binaries had the same sha512sum thanks
to reproducible builds.

Thanks in advance
Lukas


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852360


pgpajcAbvrJ8f.pgp
Description: OpenPGP digital signature

Bug#852360: Cross compiling and Bug#852360

[Lukas Schwaighofer]

Hello Helmut,

On Thu, 13 Apr 2017 22:05:02 +0200
Helmut Grohne  wrote:

> > Does that mean that the snippet  
> > > include /usr/share/dpkg/architecture.mk
> > > ifeq ($(origin CC),default)
> > > export CC := $(DEB_HOST_GNU_TYPE)-gcc
> > > endif  
> > can be removed again from debian/rules? I tried to cross compile for
> > armhf without that snipped using pbuilder (following the
> > instructions from https://wiki.debian.org/CrossCompiling) which
> > worked: The correct compiler was called and the binaries had the
> > same sha512sum thanks to reproducible builds.  
> 
> I think you perfectly answered your own question. Performing a test
> build under sbuild or pbuilder and looking at which compiler is being
> used is a good approach to answer it. There isn't anything more to it.
> Your own analysis clearly says that exporting CC is no longer
> necessary.

Thanks for clarifying.  I was unsure because the version the bug was
filed against had already switched to debhelper 10 (so this shouldn't
have been a problem in the first place).

> I'm also happy that apparently cross building using pbuilder is no
> longer too hard for the uninitiated. Good work, Mattia! :)

I agree.  This was my first time cross compiling anything, and the
process was very smooth.  Thanks for that!

Regards
Lukas


pgpgfBiVDxv_5.pgp
Description: OpenPGP digital signature

Bug#860795: unblock: dsniff/2.4b1+debian-25

[Lukas Schwaighofer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

Please unblock the package dsniff.  It FTBFS on machines with many cores
because the Makefile did not ensure the correct build order (see
#860611). The newly included patch fixes the problem.  The changelog
entry is:

dsniff (2.4b1+debian-25) unstable; urgency=medium

  * debian/control: Added myself to Uploaders.
  * Make sure libmissing.a is built before PROGS (Closes: #860611).

 -- Lukas Schwaighofer <lu...@schwaighofer.name>  Wed, 19 Apr 2017 20:15:27 
+0200

The source debdiff between the versions 2.4b1+debian-24 and
2.4b1+debian-25 is attached.

unblock dsniff/2.4b1+debian-25


Thank you
Lukas Schwaighofer
diff -Nru dsniff-2.4b1+debian/debian/changelog dsniff-2.4b1+debian/debian/changelog
--- dsniff-2.4b1+debian/debian/changelog	2017-03-13 18:34:19.0 +0100
+++ dsniff-2.4b1+debian/debian/changelog	2017-04-19 21:55:26.0 +0200
@@ -1,3 +1,10 @@
+dsniff (2.4b1+debian-25) unstable; urgency=medium
+
+  * debian/control: Added myself to Uploaders.
+  * Make sure libmissing.a is built before PROGS (Closes: #860611).
+
+ -- Lukas Schwaighofer <lu...@schwaighofer.name>  Wed, 19 Apr 2017 20:15:27 +0200
+
 dsniff (2.4b1+debian-24) unstable; urgency=medium
 
   * Fix FTCBFS: Pass triplet-prefixed CC to configure.
diff -Nru dsniff-2.4b1+debian/debian/control dsniff-2.4b1+debian/debian/control
--- dsniff-2.4b1+debian/debian/control	2017-03-06 11:17:50.0 +0100
+++ dsniff-2.4b1+debian/debian/control	2017-04-19 21:55:26.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Debian Security Tools Packaging Team <pkg-security-t...@lists.alioth.debian.org>
-Uploaders: Marcos Fouces <mfou...@yahoo.es>
+Uploaders: Marcos Fouces <mfou...@yahoo.es>, Lukas Schwaighofer <lu...@schwaighofer.name>
 Standards-Version: 3.9.8
 Build-Depends: libdb-dev (>= 4.7), libpcap0.8-dev, libnids-dev, libssl-dev, libxmu-dev, libnet1-dev, debhelper (>= 10)
 Homepage: http://www.monkey.org/~dugsong/dsniff/
diff -Nru dsniff-2.4b1+debian/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch dsniff-2.4b1+debian/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch
--- dsniff-2.4b1+debian/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch	1970-01-01 01:00:00.0 +0100
+++ dsniff-2.4b1+debian/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch	2017-04-19 21:55:26.00000 +0200
@@ -0,0 +1,90 @@
+From: Lukas Schwaighofer <lu...@schwaighofer.name>
+Date: Wed, 19 Apr 2017 10:12:11 +0200
+Subject: make sure libmissing.a is built before PROGS
+
+Add libmissing.a as a dependency to each of the PROGS to ensure it is
+built before them (fixes FTBFS in some environments).
+
+Closes: #860611
+---
+ Makefile.in | 32 
+ 1 file changed, 16 insertions(+), 16 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 1b1621d..ada5412 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -75,7 +75,7 @@ CONFIGS	= dsniff.magic dsniff.services dnsspoof.hosts
+ .c.o:
+ 	$(CC) $(CFLAGS) $(INCS) -c $(srcdir)/$*.c
+ 
+-all: libmissing.a $(PROGS)
++all: $(PROGS)
+ 
+ mount.c: mount.x
+ 	rpcgen -h mount.x -o mount.h
+@@ -92,49 +92,49 @@ libmissing.a: $(LIBOBJS)
+ 	ar -cr $@ $(LIBOBJS)
+ 	$(RANLIB) $@
+ 
+-dsniff: $(HDRS) $(SRCS) $(OBJS)
++dsniff: $(HDRS) $(SRCS) $(OBJS) libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB) $(DBLIB) $(SSLLIB)
+ 
+-arpspoof: arpspoof.o arp.o
++arpspoof: arpspoof.o arp.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ arpspoof.o arp.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-dnsspoof: dnsspoof.o pcaputil.o
++dnsspoof: dnsspoof.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ dnsspoof.o pcaputil.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-filesnarf: nfs_prot.o filesnarf.o pcaputil.o rpc.o
++filesnarf: nfs_prot.o filesnarf.o pcaputil.o rpc.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ filesnarf.o nfs_prot.o pcaputil.o rpc.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-macof: macof.o
++macof: macof.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ macof.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-mailsnarf: mailsnarf.o buf.o pcaputil.o
++mailsnarf: mailsnarf.o buf.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ mailsnarf.o buf.o pcaputil.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-msgsnarf: msgsnarf.o buf.o pcaputil.o
++msgsnarf: msgsnarf.o buf.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ msgsnarf.o buf.o pcaputil.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-sshmitm: sshmitm.o buf.o hex.o record.o ssh.o sshcrypto.o
++sshmitm: sshmitm.o buf.o hex.o record.o ssh.o sshcrypto.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ sshmitm.o buf.o hex.o record.o ssh.o sshcrypto.o $(LIBS) $(LNETLIB) $(DBLIB) $(SSLLIB)
+ 
+-sshow: sshow.o pcaputil.o
++sshow: sshow.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ sshow.o pcaputil.o $(LIB

Bug#860611: dsniff: FTBFS: ld: cannot find -lmissing

[Lukas Schwaighofer]

Control: tags -1 + pending

Hi,

On Wed, 19 Apr 2017 15:36:07 +0200
Marcos Fouces  wrote:
> Maybe you should create a "debian/stretch" branch from
> 2.4b1+debian-24 tag and commit your patch here. If you want, you can
> add yourself as uploader and tag it as "2.4b1+debian-25" release.
> Later we will merge it with "debian/master" branch.

I've pushed the fix in the newly created debian/stretch branch (based
on version 2.4b1+debian-25). I've also added myself to Uploaders as you
suggested.

@pkg-security DDs: Can one of you look at the debian/stretch branch and
sponsor the upload?

I will request an unblock once the package has been uploaded.

Thanks
Lukas


pgpZtQQW5atbR.pgp
Description: OpenPGP digital signature

Bug#551350: arpwatch: restart option

[Lukas Schwaighofer]

Hi Stephan,

thanks for your reply, I'll make the discussed changes.

On Sat, 22 Apr 2017 15:00:29 +0200
Stephen Kitt  wrote:

> What’s the situation with upstream arpwatch? Is there an upstream now?

Unfortunately not… but as there are still use cases for this software
and no better alternative exists to my knowledge, I still consider it
worthwhile to get the Debian package in shape.

Regards
Lukas


pgpAo45NZQZiM.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hi Andreas,

thanks for looking into this and finding the bug from fedora to fix
this!

As I want this to stay in stretch and no one has stepped up yet I have
uploaded an nmu to mentors:
https://mentors.debian.net/package/gmrun
I hope this is the correct way to proceed (I did not intend to offend
the maintainer snatch this upload away from somebody else).


I have made some small changes from your attached debdiff:
* the line numbers appeared to be off by two lines
* I adjusted the changelog

Please let me know if the uploaded source package is ok or if anything
should be changed. I would be happy if you could sponsor the upload.

Once the package has been uploaded I will file an unblock request for
the release team.


Thanks & Regards
Lukas Schwaighofer


pgpi8fVejjtOr.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hi,

On Fri, 10 Mar 2017 21:02:04 +0100
Mateusz Łukasik <mat...@linuxmint.pl> wrote:  
> Package needs more attention. NMU is correct, a few things should
> be change at first better is change revision to 2.2, +nmu is good
> but is prefer to native packages.
> Second package have a few lintian warning easy to fix:
> 
> W: gmrun source: package-uses-deprecated-debhelper-compat-version 7
> W: gmrun source: ancient-standards-version 3.8.4 (current is 3.9.8)
> I: gmrun: hardening-no-bindnow usr/bin/gmrun
> 
> I would fix all lintian warnings and upload tomorrow NMU with
> DELAYED/3.  

Since there was no update yet I've created a new package and uploaded
it to mentors:
https://mentors.debian.net/debian/pool/main/g/gmrun/gmrun_0.9.2-2.2.dsc

I had misunderstood Mateusz (I thought he has upload rights) and did
not notice he had also uploaded gmrun to mentors with the same version
(so I have now overwritten what Mateusz uploaded, sorry for that).


I've left the standards version and the debhelper compat level
untouched as Andreas suggested.  However, I've enabled the hardening
options (although what the wiki [1] provided for hardening with
older debhelper compat versions did not work, as the output from
  dpkg-buildflags --export=configure
are environment variables; I used  the `env` binary instead to pass
those to dh_auto_configure). I've confirmed that the resulting
binary now has both PIE and BIND_NOW enabled (and still works properly).

I'm not sure if enabling BIND_NOW in addition to PIE is considered a
trivial enough change, or if we should stick to only fixing the bug so
it can get unblocked by the release team.


Thanks
Lukas Schwaighofer

[1] https://wiki.debian.org/HardeningWalkthrough


pgpTyX54gBSWk.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

On Sun, 12 Mar 2017 23:11:39 +0100
Mateusz Łukasik  wrote:

> I think now package should stay untouched only RC bug need be fixed.
> After that I suggest making package orphaned and upload as QA to 
> experimental with more fixes.

That sounds reasonable. I've uploaded a version which just contains the
necessary patch as NMU (with correct version number) to mentors:
https://mentors.debian.net/debian/pool/main/g/gmrun/gmrun_0.9.2-2.2.dsc

Andreas: Are you still willing to sponsor this upload or should I file
an RFS-bug as Mateusz suggested?

Thanks
Lukas

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hello Andreas,

On Fri, 10 Mar 2017 14:10:15 +0100
Andreas Henriksson <andr...@fatal.se> wrote:
> On Fri, Mar 10, 2017 at 01:36:06PM +0100, Lukas Schwaighofer wrote:
> > On Fri, 10 Mar 2017 13:14:57 +0100
> > Andreas Henriksson <andr...@fatal.se> wrote:  
> > > Either way I think we should take the time to investigate the
> > > maintenance status and either give the package to Debian QA team
> > > if noone is interested in adopting it while we're doing an upload
> > > here.  
> > 
> > What is the proper course of action? I've just read through some of
> > the pages from the QA team and it seems like an email to
> > m...@qa.debian.org might be the first step [3] .  
> 
> There's an offical way and there's what I'd say you can do with
> gmrun...
> 
> On gmrun I think you can just set yourself as maintainer in the
> package and update debian/changelog to version it as a maintainer
> upload rather than a NMU. If you want to be nice, send out an "intent
> to hijack" to debian-devel list. Also give 2 weeks time for the
> maintainer to reply. (I think we can consider this mail conversion as
> a notice to the maintainer of your intent. I also think there's too
> little evidence of any actual maintenance done on gmrun for the
> current maintainer to claim his ownership... we could just go
> straight for upload without doing the extra "nice" steps.)
> Don't forget to send me the new .dsc url once you've updated the
> package with you as maintainer. (Official way to get sponsorship is
> to file a RFS bug against sponsorship-requests in the bug tracking
> system. I won't promive to sponsor all your future uploads, but
> hopefully you'll find someone else who can help you out with that when
> I don't have time to help you out.)
> 
> If you want to be extra nice to Debian you might want to also
> investigate if Alexandre has gone fully MIA and have his other
> packages be marked as orphaned. I'm looking at
> https://contributors.debian.org/contributor/adedommelin-guest@alioth/
> and it indeed seems he's no longer active in Debian and you could
> contact the MIA team to help get him removed from
> Maintainers/Uploaders in all packages he's listed in

Thanks for explaining that. I think I would be more comfortable with
doing this as a NMU now and do a proper maintainer transition (giving
Alexendre enough time to react) with a first upload for buster. That
will also allow me to create a first upload as maintainer which
actually contains work done by me.

However, if you think it's better to the maintainer transition right
away, I will follow your advice and prepare a new upload (but I would
like to avoid the 2 weeks delay, so it would end up not being the
"nice" version of your suggestion).

Regards
Lukas Schwaighofer


pgpG9zn2TAp7l.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hi Mateusz,

On Fri, 10 Mar 2017 21:02:04 +0100
Mateusz Łukasik <mat...@linuxmint.pl> wrote:
> Package needs more attention. NMU is correct, a few things should be
> change at first better is change revision to 2.2, +nmu is good but is
> prefer to native packages.
> Second package have a few lintian warning easy to fix:
> 
> W: gmrun source: package-uses-deprecated-debhelper-compat-version 7
> W: gmrun source: ancient-standards-version 3.8.4 (current is 3.9.8)
> I: gmrun: hardening-no-bindnow usr/bin/gmrun
> 
> I would fix all lintian warnings and upload tomorrow NMU with
> DELAYED/3.

Sounds good to me, thanks for taking care of this!

Regards
Lukas Schwaighofer


pgpW8Ylq8FPe1.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hi Andreas,

On Fri, 10 Mar 2017 13:14:57 +0100
Andreas Henriksson <andr...@fatal.se> wrote:
> Please post the full .dsc url (so I can simply dget it, and I don't
> care much about you using mentors or not that's mainly a thing
> to allow you to practise the signing and dput way that you'll need
> to be aquanted with once you get credentials to do official uploads).

Here is the dsc URL:
https://mentors.debian.net/debian/pool/main/g/gmrun/gmrun_0.9.2-2.1+nmu1.dsc

> I have to wonder though if this package really is maintained at all?
> (The officially listed maintainer hasn't touched the package since
> 2010.) Would you consider adopting it if not?

Yes, I would consider adopting it. Ubuntu also has a bug report on a
similar problem [1] and a more extensive patch that seems to address
more outdated API calls [2]. I wanted to keep this upload minimal
because stretch is already frozen, but going forward to buster this is
definitely something I would look at.

> Either way I think we should take the time to investigate the
> maintenance status and either give the package to Debian QA team if
> noone is interested in adopting it while we're doing an upload here.

What is the proper course of action? I've just read through some of the
pages from the QA team and it seems like an email to m...@qa.debian.org
might be the first step [3] .

Thank you
Lukas Schwaighofer

[1] https://bugs.launchpad.net/ubuntu/+source/gmrun/+bug/1633505
[2] https://launchpadlibrarian.net/298206968/gmrun-tdp-patch.diff
[3] https://wiki.debian.org/Teams/MIA



pgpzrFliaT6Zo.pgp
Description: OpenPGP digital signature

Bug#860611: dsniff: FTBFS: ld: cannot find -lmissing

[Lukas Schwaighofer]

Hi,

I just checked the build log. I think the problem is that the Makefile
does not properly enforce the correct build order: PROGS actually
depend on libmissing.a. The build log shows that, at the time of the
build error, libmissing.a is not yet build (but tried to link against).
I suspect the problem surfaced due to the level of parallelism on the
buildd (-j 64).


I've prepared a minimal patch against version 2.4b1+debian-24
(currently in stretch) that should be suitable for an unblock, see
attachment.

If you want I can push that into our git repo, tag it as new release
and then merge that commit into our development branch (bumping the
version for the newer changes when merging the commit log).


Thanks
Lukas
diff --git a/debian/changelog b/debian/changelog
index 668cd49..388ae33 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dsniff (2.4b1+debian-25) unstable; urgency=medium
+
+  * Team upload.
+  * Make sure libmissing.a is built before PROGS (Closes: #860611).
+
+ -- Lukas Schwaighofer <lu...@schwaighofer.name>  Wed, 19 Apr 2017 10:14:38 +0200
+
 dsniff (2.4b1+debian-24) unstable; urgency=medium
 
   * Fix FTCBFS: Pass triplet-prefixed CC to configure.
diff --git a/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch b/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch
new file mode 100644
index 000..640a9b7
--- /dev/null
+++ b/debian/patches/34_make-sure-libmissing.a-is-built-before-PROGS.patch
@@ -0,0 +1,90 @@
+From: Lukas Schwaighofer <schwa...@in.tum.de>
+Date: Wed, 19 Apr 2017 10:12:11 +0200
+Subject: make sure libmissing.a is built before PROGS
+
+with enough paralellism, the package will FTBFS because the
+correct build order is not ensured by make
+
+Closes: #860611
+---
+ Makefile.in | 32 
+ 1 file changed, 16 insertions(+), 16 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 1b1621d..ada5412 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -75,7 +75,7 @@ CONFIGS	= dsniff.magic dsniff.services dnsspoof.hosts
+ .c.o:
+ 	$(CC) $(CFLAGS) $(INCS) -c $(srcdir)/$*.c
+ 
+-all: libmissing.a $(PROGS)
++all: $(PROGS)
+ 
+ mount.c: mount.x
+ 	rpcgen -h mount.x -o mount.h
+@@ -92,49 +92,49 @@ libmissing.a: $(LIBOBJS)
+ 	ar -cr $@ $(LIBOBJS)
+ 	$(RANLIB) $@
+ 
+-dsniff: $(HDRS) $(SRCS) $(OBJS)
++dsniff: $(HDRS) $(SRCS) $(OBJS) libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB) $(DBLIB) $(SSLLIB)
+ 
+-arpspoof: arpspoof.o arp.o
++arpspoof: arpspoof.o arp.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ arpspoof.o arp.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-dnsspoof: dnsspoof.o pcaputil.o
++dnsspoof: dnsspoof.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ dnsspoof.o pcaputil.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-filesnarf: nfs_prot.o filesnarf.o pcaputil.o rpc.o
++filesnarf: nfs_prot.o filesnarf.o pcaputil.o rpc.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ filesnarf.o nfs_prot.o pcaputil.o rpc.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-macof: macof.o
++macof: macof.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ macof.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-mailsnarf: mailsnarf.o buf.o pcaputil.o
++mailsnarf: mailsnarf.o buf.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ mailsnarf.o buf.o pcaputil.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-msgsnarf: msgsnarf.o buf.o pcaputil.o
++msgsnarf: msgsnarf.o buf.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ msgsnarf.o buf.o pcaputil.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-sshmitm: sshmitm.o buf.o hex.o record.o ssh.o sshcrypto.o
++sshmitm: sshmitm.o buf.o hex.o record.o ssh.o sshcrypto.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ sshmitm.o buf.o hex.o record.o ssh.o sshcrypto.o $(LIBS) $(LNETLIB) $(DBLIB) $(SSLLIB)
+ 
+-sshow: sshow.o pcaputil.o
++sshow: sshow.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ sshow.o pcaputil.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-tcpkill: tcpkill.o pcaputil.o
++tcpkill: tcpkill.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ tcpkill.o pcaputil.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-tcpnice: tcpnice.o pcaputil.o
++tcpnice: tcpnice.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ tcpnice.o pcaputil.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-tcphijack: tcphijack.o pcaputil.o
++tcphijack: tcphijack.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ tcphijack.o pcaputil.o $(LIBS) $(PCAPLIB) $(LNETLIB)
+ 
+-urlsnarf: urlsnarf.o base64.o buf.o pcaputil.o
++urlsnarf: urlsnarf.o base64.o buf.o pcaputil.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ urlsnarf.o base64.o buf.o pcaputil.o $(LIBS) $(NIDSLIB) $(PCAPLIB) $(LNETLIB)
+ 
+-webmitm: webmitm.o base64.o buf.o decode_http.o record.o
++webmitm: webmitm.o base64.o buf.o decode_http.o record.o libmissing.a
+ 	$(CC) $(LDFLAGS) -o $@ webmitm.o base64.o buf.o decode_http.o record.o $(LIBS) $(LNETLIB) $(DBLIB) $(SSLLIB)
+ 
+-webspy: webspy.o base64.o buf.o remote.o
++webspy: webspy.o base64.o buf.o remote.o libmissing.a
+ 	$(C

Bug#861058: hydra: on resume, children die with "double free or corruption"

[Lukas Schwaighofer]

Control: found -1 hydra/8.3-2
Control: tags -1 + upstream

Hi Ivan,

thanks for reporting this bug.  I was able to reproduce the problem
(also for the version 8.3-2 from Debian stretch).  The bug is also
already known upstream:
  https://github.com/vanhauser-thc/thc-hydra/issues/27

I've just looked into the problem and I think I found the cause. I've
created a pull request
  https://github.com/vanhauser-thc/thc-hydra/pull/209
which seemed to fix the problem for me.  However, I'd like to wait for
feedback from the author and possibly other affected users before
applying the fix to the Debian version.


If you need a workaround until the issue has been properly fixed: The
issue does not affect the i386 version of the software (as also
confirmed by the original author in one of his messages to the github
issue).  You can try to add the i386 architecture to dpkg and then
install the hydra:i386 package (let me know if you need help with that).


Regards
Lukas


pgpRVPjNuusuN.pgp
Description: OpenPGP digital signature

Bug#870518: dh-autoreconf: please update dh-autoreconf(7) man page

[Lukas Schwaighofer]

Package: dh-autoreconf
Version: 14
Severity: wishlist
Tags: patch

Dear maintainer,

please update the dh-autoreconf man page to reflect recent changes:
* it no longer needs to be enabled explicitly when using debhelper 
  compatibility levels >= 10
* the debhelper commands provided by autotools-dev are being superseded
  by the dh_update_autotools_config debhelper command [1]

I've added a suggestion as patch.

Thank you
Lukas Schwaighofer

[1] 
http://lists.alioth.debian.org/pipermail/debhelper-devel/2017-August/006303.html
diff --git a/dh-autoreconf.pod b/dh-autoreconf.pod
index b3647d3..e7683ae 100644
--- a/dh-autoreconf.pod
+++ b/dh-autoreconf.pod
@@ -4,8 +4,9 @@ dh-autoreconf - debhelper add-on to run autoreconf during build
 
 =head1 DESCRIPTION
 
-The dh-autoreconf package provides a sequence addon for debhelper 7 which
-can be used in the following way:
+The dh-autoreconf package provides a sequence addon for debhelper 7 and is
+enabled by default since compatibility level 10. For earlier compatibility
+levels it can be enabled in the following way:
 
 #!/usr/bin/make -f
 %:
@@ -34,9 +35,6 @@ You can add support for -Wl,--as-needed to ltmain.sh (at least for those
 ltmain.sh scripts changed during autoreconf) by passing the argument
 B<--as-needed> to dh_autoreconf, as demonstrated in the following example:
 
-#!/usr/bin/make -f
-%:
-dh $@ --with autoreconf
 override_dh_autoreconf:
 dh_autoreconf --as-needed
 
@@ -63,10 +61,11 @@ Or, if you use CDBS:
 
 =head1 CAVEATS
 
-dh_autoreconf is mostly a superset of the autotools-dev debhelper addons, so
-you do not need --with=autotools_dev if you use --with=autoreconf, as long
-as your autoreconf updates the config.guess and config.sub files. If it does
-not, feel free to use both together.
+dh_autoreconf is mostly a superset of the dh_update_autotools_config debhelper
+command included in debhelper since version 9.20160115. When using the dh
+sequencer, dh_update_autotools_config is run before dh_autoreconf and updates
+the config.guess and config.sub files. This is required in cases where
+autoreconf does not update config.guess and config.sub itself.
 
 From time to time, there might be a short breakage for those using
 automatic ltmain.sh patching, when the patch no longer applies to


pgpnWunSc87O_.pgp
Description: OpenPGP digital signature

Bug#720672: gmrun should respect xdg directory base specification (~/.config/gmrun/config)

[Lukas Schwaighofer]

Control: severity -1 wishlist

Hi Thomas,

> it would be nice if gmrun would read its configuration file according
> to the xdg base directory specification and thus not clutter my $HOME:
> http://wiki.debian.org/XDGBaseDirectorySpecification

I agree that this would be desirable.  Unfortunately upstream is dead
and, according to the link you provided, "Debian packages should not be
patched for conformance to avoid unnecessary deviation from upstream
and other distributions."

I'm lowering the severity to wishlist.

Regards
Lukas

Bug#868677: libopenvas9: radius support is not compiled within, so the radius options will fail

[Lukas Schwaighofer]

Control: reopen -1
control: tags -1 + upstream
Control: forwarded -1 
https://wald.intevation.org/tracker/index.php?func=detail=6929_id=29=220
Control: severity -1 wishlist

Hi,

since radcli is source compatible with freeradius-client we shouldn't
have to drop this functionality.  I've created a small patch [1] that
adds support for linking against radcli and submitted an enhancement
request upstream [2].  In case that patch gets merged we can re-enable
the feature in Debian.  If it isn't we can also consider adding the
patch locally…

I've re-opened the bug so we can track this. Feel free to close
again if you disagree.

Regards
Lukas

[1] 
https://wald.intevation.org/tracker/download.php/29/220/6929/1821/openvas-libraries-radcli.patch
[2] 
https://wald.intevation.org/tracker/index.php?func=detail=6929_id=29=220


pgpLTWoFSa3ar.pgp
Description: OpenPGP digital signature

Bug#869086: dsniff sometimes FTBFS due to missing Makefile dependency

[Lukas Schwaighofer]

Hi Adrian,

On Thu, 20 Jul 2017 14:57:46 +0300
Adrian Bunk  wrote:

> dsniff sometimes FTBFS in parallel builds: (...)
> The problem is a race condition where decode_mountd.c includes
> mount.h before rpcgen has finished generating it.

Indeed.

> A fix is attached.

Thanks a lot for debugging this already.  I had another FTBFS with your
patch applied, because `make` was trying to build mount.o without having
generated mount.h first.  I ended up inserting another dependency

 mount.o: mount.h

so that the ".c.o" rule would not try to build mount.o before
generating mount.h.  I also found another similar dependency between
nfs_prot.h and filesnarf.o which I resolved in the same way.

Hopefully that fixes all the parallel FTBFS now…

Thanks & Regards
Lukas


pgp9YjhQHOklz.pgp
Description: OpenPGP digital signature

Bug#867147: RFS: gmrun/0.9.2-4 [ITA]

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for the gmrun package, which I intend to
adopt. I've uploaded the current state to mentors:
  https://mentors.debian.net/package/gmrun

I've done the packaging using git.  You can access my repository from
  https://git.somlen.de/gmrun.git
and checkout the debian/master branch.  The above URL is git only, I
don't have a web-based git viewer installed on my server.

I would prefer to host the repository on collab-maint and I have
already set the Vcs-* control fields accordingly.  I hope my sponsor
can either push it there on my behalf or help me get access myself.

Thanks & Regards
Lukas


pgpI2mSSVlRxa.pgp
Description: OpenPGP digital signature

Bug#867147: RFS: gmrun/0.9.2-3 [ITA]

[Lukas Schwaighofer]

Control: retitle -1 RFS: gmrun/0.9.2-3 [ITA]

My last commit accidentally increased the Debian version, corrected.


pgpDeA3pvxDKQ.pgp
Description: OpenPGP digital signature

Bug#862149: arpwatch starts before networking is ready

[Lukas Schwaighofer]

Hi,

thanks for reporting this issue.

On Mon, 08 May 2017 21:40:06 -0700
jmol...@swoncology.net wrote:
> Arpwatch seems to start before the networking is really ready. In this
> case, we are listening on a bridge interface, so that might have
> something to do with it.
> 
> This might be a problem with systemd/networking/bridging/etc. Feel
> free to pass the bug along to whoever is really at fault.

I think it's the LSB init script's fault, as it does not list
$network as a runtime dependency (should be added to Required-Start).  I
will try to reproduce your setup and check if adding that fixes the
problem (probably won't get to it before the weekend though).


I see that you are using unstable.  If you want to do me a favor, you
could try installing the version from experimental.  Amongst other
things it provides systemd service files which depend on the network
being up.  Feedback on that version would be appreciated.


Thanks & regards
Lukas


pgpvtnuPrw5Lx.pgp
Description: OpenPGP digital signature

Bug#862149: arpwatch starts before networking is ready

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi again,

I can confirm that arpwatch does indeed start too early when capturing
on bridge devices. I have also verified that adding $network to the
Required-Start field in the LSB header fixes the problem.

I will push the fix into our git repository soon, but I will defer an
upload to unstable until after Debian stretch is released.

Regards
Lukas


pgpwYK8L3bNnx.pgp
Description: OpenPGP digital signature

Bug#861800: unblock: hydra/8.3-3

[Lukas Schwaighofer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

Please unblock package hydra.  The updated package fixes a problem
observed on amd64: Restoring a session using `hydra -R` will sometimes
cause all forked processes to die with a "double free or corruption"
error.

The newly included patch (also merged by upstream) allocates the
required size to store pointers (which is not generally sizeof(int))
correctly, fixing the bug described above.  The patch is quite small
(only changes three lines) and fixes Debian bug #861058 which has
severity important.  The upload also includes a minor update to the man
page.

The changelog entry is:

hydra (8.3-3) unstable; urgency=medium

  * Team upload.

  [ Gianfranco Costamagna ]
  * Fix newline in manpage (Closes: #853807)

  [ Lukas Schwaighofer ]
  * Allocate required pointer size correctly.  This fixes an issue with
session restore (`hydra -R`) causing the forked hydra processes to die
with a "double free or corruption" error. (Closes: #861058)

 -- Lukas Schwaighofer <lu...@schwaighofer.name>  Wed, 03 May 2017 19:06:30 
+0200

The source debdiff between the versions 8.3-2 and 8.3-3 is attached.

Thank you
Lukas Schwaighofer


unblock hydra/8.3-3
diff -Nru hydra-8.3/debian/changelog hydra-8.3/debian/changelog
--- hydra-8.3/debian/changelog	2016-11-27 17:17:26.0 +0100
+++ hydra-8.3/debian/changelog	2017-05-03 20:47:26.0 +0200
@@ -1,3 +1,17 @@
+hydra (8.3-3) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Gianfranco Costamagna ]
+  * Fix newline in manpage (Closes: #853807)
+
+  [ Lukas Schwaighofer ]
+  * Allocate required pointer size correctly.  This fixes an issue with
+session restore (`hydra -R`) causing the forked hydra processes to die
+with a "double free or corruption" error. (Closes: #861058)
+
+ -- Lukas Schwaighofer <lu...@schwaighofer.name>  Wed, 03 May 2017 19:06:30 +0200
+
 hydra (8.3-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru hydra-8.3/debian/patches/10_fix_typos_in_manpage.diff hydra-8.3/debian/patches/10_fix_typos_in_manpage.diff
--- hydra-8.3/debian/patches/10_fix_typos_in_manpage.diff	2016-11-27 17:17:26.0 +0100
+++ hydra-8.3/debian/patches/10_fix_typos_in_manpage.diff	2017-04-26 00:38:31.0 +0200
@@ -1,5 +1,6 @@
 Description: Fix typos in manpage
-Forwarded: no
+Forwarded: https://github.com/vanhauser-thc/thc-hydra/pull/188
+   https://github.com/vanhauser-thc/thc-hydra/pull/187
 Author: Daniel Echeverry <epsilo...@gmail.com>
 Last-Update: 2016-06-16
 --- a/xhydra.1
diff -Nru hydra-8.3/debian/patches/11_fix_man_typo.patch hydra-8.3/debian/patches/11_fix_man_typo.patch
--- hydra-8.3/debian/patches/11_fix_man_typo.patch	1970-01-01 01:00:00.0 +0100
+++ hydra-8.3/debian/patches/11_fix_man_typo.patch	2017-04-26 00:38:31.0 +0200
@@ -0,0 +1,16 @@
+Description: Fix typo preventiing -d from being correctly displayed
+Author: Gianfranco Costamagna <locutusofb...@debian.org>
+Bug-Debian: https://bugs.debian.org/853807
+
+Forwarded: https://github.com/vanhauser-thc/thc-hydra/pull/186
+
+--- hydra-8.3.orig/hydra.1
 hydra-8.3/hydra.1
+@@ -105,6 +105,7 @@ prefer IPv4 (default) or IPv6 addresses
+ .TP
+ .B \-v / \-V 
+ verbose mode / show login+pass combination for each attempt
++.TP
+ .B \-d
+ debug mode
+ .TP
diff -Nru hydra-8.3/debian/patches/12_allocate-pointer-size-correctly.path hydra-8.3/debian/patches/12_allocate-pointer-size-correctly.path
--- hydra-8.3/debian/patches/12_allocate-pointer-size-correctly.path	1970-01-01 01:00:00.0 +0100
+++ hydra-8.3/debian/patches/12_allocate-pointer-size-correctly.path	2017-05-03 20:47:26.00000 +0200
@@ -0,0 +1,46 @@
+Author: Lukas Schwaighofer <lu...@schwaighofer.name>
+Date: Tue, 25 Apr 2017 23:31:39 +0200
+Description: do not assume that sizeof(int) is the same as the pointer size
+Bug: https://github.com/vanhauser-thc/thc-hydra/issues/27
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861058
+Forwarded: https://github.com/vanhauser-thc/thc-hydra/pull/209
+
+Allocate required pointer size correctly.  This fixes an issue with session
+restore (`hydra -R`) causing the forked hydra processes to die with a "double
+free or corruption" error.
+
+---
+ hydra.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/hydra.c b/hydra.c
+index 0704f49..1a49d30 100644
+--- a/hydra.c
 b/hydra.c
+@@ -929,7 +929,7 @@ void hydra_restore_read() {
+   }
+   if (debug)
+ printf("[DEBUG] reading restore file: Step 11 complete\n");
+-  hydra_heads = malloc((hydra_options.max_use + 2) * sizeof(int) + 16);
++  hydra_heads = malloc(sizeof(hydra_head*) * hydra_options.max_use);
+   for (j = 0; j < hydra_options.max_use; j++) {
+ hydra_heads[j] = malloc(sizeof(hydra_head));
+ fck = (int) fread(hydra_heads[j], sizeof(hydra_head), 1, f);
+@

Bug#861108: live-build: stretch image produced with default configuration does not boot

[Lukas Schwaighofer]

Hi,

I think the problem reported by Antonio is because the default RAM size
of kvm is too little.


Antonio: Can you retry with `-m 256M` or even `-m 512M` to have more
than the default of 128M RAM?


Yves: I cannot reproduce the problems reported by you. In particular,
microcode packages should not be installed by default (as they are in
non-free).  If you have installed any of the microcode packages,
the initrd follows a special format (see [1]): The initrd consists of
an uncompressed cpio archive only holding the microcode updates
followed by a compressed cpio archive with the remainder of the
initrd.  This is a little bit tricky to uncompress, so when unpacking
it it may seem like the initrd is broken. You can try the following to
unpack the whole initrd into your current working directory:

(cpio -id --no-absolute-filenames; zcat | cpio -id --no-absolute-filenames) < 
/path/to/initrd.img


Regards
Lukas



[1] https://www.kernel.org/doc/Documentation/x86/early-microcode.txt


pgpHZjSyiSTra.pgp
Description: OpenPGP digital signature

Bug#876123: libpcap0.8-dev: `pcap-config --libs` output starting with a space may cause FTBFS

[Lukas Schwaighofer]

Package: libpcap0.8-dev
Version: 1.8.1-4
Severity: important
X-Debbugs-CC: pkg-security-t...@lists.alioth.debian.org


Dear libpcap maintainer,

the fix for Bug#760370 [1] has caused the output of
pcap-config --libs
to start with a space.  This appears to be a problem for applications
using the output of that directly with cmake.  At least for
openvas-libraries (manged by the pkg-security-team I've put in CC), the
change results in a FTBFS [2] with cmake reporting:

  Target "openvas_misc_shared" links to item " -lpcap" which has
  leading or trailing whitespace.  This is now an error according to
  policy CMP0004.

While we can fix this for the openvas-libraries package, this may
affect other projects using libpcap and cmake as well.

Thanks
Lukas

[1] https://bugs.debian.org/760370
[2] https://bugs.debian.org/876093

Bug#876093: openvas-libraries FTBFS on amd64: override_dh_auto_configure failed

[Lukas Schwaighofer]

Hi,

while I'm not against introducing the patch, in my opinion we should
file a bug against libpcap0.8-dev instead (or at least in addition).
The starting space in the output of
pcap-config --libs
is due to Debian specific changes to the pcap-config tool.  This
starting space in the output might also break other projects using
libpcap and cmake.

What do you think?  If you want I can take care of filing that bug.

Regards
Lukas

Bug#714925: nmap: [REGRESSION 5.00-3 -> 6.00-0.3] -sP fails with "nexthost: failed to determine route to X.X.X.X"

[Lukas Schwaighofer]

Hi Timo,

thanks for the very thorough bug report and for discussing it with
upstream.  I'm doing a bit of housekeeping of the nmap bugs and tried
to determine if this bug is still present.

According to upstream [1], this issue might have been mitigated by
newer versions of the Linux kernel, in particular since Linux version
3.9.  I also wasn't able to reproduce the issue myself (using nmap
7.60-1 and Linux 4.12).

Do you still have a similar setup and would you mind checking if that
problem is still present?

Thank you
Lukas

[1] http://seclists.org/nmap-dev/2013/q3/247

Bug#876395: nm.debian.org: Unexpected account deletion after 30 days

[Lukas Schwaighofer]

Package: nm.debian.org
Severity: minor

Hi,

I was surprised to find my account at nm.debian.org deleted after 30
days.  As account deletion also means losing the short biography, I
think the system should either
* warn the user (possibly as part of the confirmation mail) that the
  account will be deleted after 30 days unless she/he starts a process
  or
* upon deletion, notify the user via an e-mail that contains all the
  data saved in the system.

Thanks
Lukas

Bug#876394: nm.debian.org: Wrong `Reply-To: t...@example.com` header in confirmation mail

[Lukas Schwaighofer]

Package: nm.debian.org
Severity: important

Hi,

the confirmation e-mail for newly created entries/accounts on
https://nm.debian.org contains a `Reply-To: t...@example.com` header.
This header should be removed.

Thanks
Lukas

Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

[Lukas Schwaighofer]

Hi Thomas,

thanks for pushing this forward :) .

On Sat, 14 Oct 2017 19:53:46 +0200
"Thomas Schmitt"  wrote:

> now that a new set of SYSLINUX packages is announced by
> (...)
> what to do with this bug report ?
> Re-assign to package "syslinux" and then close it ?

Well, that bug is only solved once we have CD images that are no longer
affected by this bug.  The first weekly testing images will be
available earliest in two weeks time (since I've set the testing
migration to 10 days and assuming no new RC bugs are discovered during
that period).

After that we still need to decide whether we also want to fix this for
the next point release.  If I understand the CD build process
correctly, the images for the next point release will only get the fix
if we also update syslinux in stretch.

> Is there a way to obtain that package and extract the file with
> vanilla tools which are not debian-specific ?

Well, deb package can be downloaded from 

http://ftp.debian.org/debian/pool/main/s/syslinux/isolinux_6.03+dfsg1-1_all.deb
though the link will no longer work after a newer version of syslinux
is uploaded to unstable.

Since deb is an ar-archive (containing more archives), you can extract
the file as follows on any *nix systems which have ar and tar commands:

ar p isolinux_6.03+dfsg1-1_all.deb data.tar.xz | \
tar xJOf - ./usr/lib/ISOLINUX/isohdpfx.bin > isohdpfx.bin

Regards
Lukas

Bug#833057: extlinux: cannot boot from ext4 filesystems with 64bit feature enabled

[Lukas Schwaighofer]

Control: retitle -1 extlinux: cannot boot from ext4 filesystems with 64bit 
feature enabled
Control: tags -1 - moreinfo + confirmed upstream

Hi,

thanks for reporting and working on this issue.  I'm certain the
experienced problem is due to the 64bit feature in ext4, which is set by
default when using `mkfs.ext4` since Debian stretch but not yet
supported by syslinux (as Peter has already pointed out).  I'm adjusting
the bug accordingly.

There is also good news:  Upstream pushed a fix for this problem
yesterday [1], I will test the fix and prepare a new Debian version
soon.

Regards
Lukas


[1] 
http://git.zytor.com/syslinux/syslinux.git/commit/?id=af7e95c32cea40c1e443ae301e64b27f068b4915

Bug#396062: nmap does not work on distant host

[Lukas Schwaighofer]

Control: tags -1 + moreinfo unreproducible

Hi Fabrice,

I'm doing a bit of housekeeping of old nmap bugs.  Are you still able
to reproduce the bug you reported here more than 10 years ago:
https://bugs.debian.org/396062

I cannot reproduce the problem myself.  I suspect that this problem is
either related to something unique in your setup or has been fixed by a
newer nmap release since you reported it.

Thanks & regards
Lukas

Bug#535441: nmap fails on large range scan

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Miguel,

sorry for reviving the old bug report
https://bugs.debian.org/535441
you filed a few years ago, I'm doing a bit of housekeeping.

Do you still have the same setup and does the problem still persist?
If that's the case, I will need your help in determining the cause of
the problem.  Can you capture the traffic of your nmap scan using
tcpdump. The command should be something like (as root):

tcpdump -npi YOUR_INTERFACE_NAME -w nmap-scan.pcap \
'tcp and (port 515 or port 631 or port 9100)'

You need to start this tcpdump command before you start the nmap scan
and terminate it (using CTRL+C) after nmap has finished.  Afterwards
please compress the output using `xz nmap-scan.pcap` and send me the
resulting nmap-scan.pcap.xz file.

This file will contain all network traffic from and to your machine
that involves one of the listed port and the TCP protocol.  So it may
also contain something that is not related to the scan (which could be
sensitive information).  Thus I would recommend only sending the file
to me directly and not to the bug report so this file does not get
published.

Regards
Lukas

Bug#772731: nmap -O causes occasional kernel panic

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Gary,

you reported this bug regarding nmap induced kernel panics a few years
ago: https://bugs.debian.org/772731

Do you still experience this bug?  If so, can you provide any
information regarding the kernel panic (e.g. picture of the backtrace
printed by the kernel) so we can investigate?

Thanks
Lukas

Bug#501371: nmap: failed to determine route

[Lukas Schwaighofer]

Hi Michael,

sorry for reviving this almost 9 year old bug, I'm trying to do a bit
of housekeeping :) .


I suspect that what you experienced is a limitation of libdnet (the
library that nmap uses to query the routing table) in combination with
policy routing: It looks like the "default" table is not read, while
the "main" table is.  If I put my routes into the "default" routing
table and remove them from "main", the routes disappear from
`nmap --iflist`.

What I don't understand is why you can't put your default route into
the "main" table (instead of the "default" table).  From my
understanding, this should not make a difference for any application
using the kernel to determine the correct route. "main" is just looked
at first, and "default" after if there is still no match.  Since your
"main" table is empty, moving the contents of "default" to "main"
should be fine.


I also tested performing nmap scans with my routes moved from the
"main" to the "default" table.  It turns out that both scans using
normal TCP sockets (tested with `nmap -sT`) as well as those using raw
sockets (tested with `nmap -sS`) worked correctly, even though the
routes used were not present in `nmap --iflist`.  So I suspect your
original bug is fixed, at least in nmap 7.60 I'm using now.  Would
you mind checking if the problem still exists?

Thanks & Regards
Lukas

Bug#548006: arpon needs to understand that networking devices are dynamic

[Lukas Schwaighofer]

Control: severity -1 wishlist
Control: tags -1 + upstream

Hi Sheridan,

thanks for your bug report.  While I agree that this might be a useful
feature, it's outside the scope of packaging.  If you want arpon to
deal with changes in network interfaces gracefully, you should try to
convince the upstream authors to add it (or provide them with a patch),
so it will eventually make its way into Debian.

Thanks
Lukas

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

it seems you are getting the knack of it quickly :) .  I don't have
any additional feedback.  I hope you're able to find a sponsor soon.

You can also look at the available packaging teams [1].  For your
package it looks like the Debian Multimedia team [2] would be the most
suitable one.  I joined a packaging team for "my" first package about
half a year ago and this worked out really well for me.

All the best
Lukas

[1] https://wiki.debian.org/Teams
[2] https://wiki.debian.org/DebianMultimedia

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

thanks for improving upon our suggestions.

On Sun, 24 Sep 2017 15:15:41 -0300
"Gabriel F. T. Gomes"  wrote:
> Lukas,
> In that same message [1], you suggested the use of a version control
> system, but I don't know where to make it public (I know that alioth
> is being discontinued, so I'm a bit lost with this).

I hope someone here will have a suggestion where your repository can
live.

> I think I solved all other problems you pointed out.

Looks like it.  I just took another look and saw a few more minor
things:

* The upstream tarball you uploaded to mentors is not exactly the same
  one as on github:

$ cmp pragha-1.3.3.tar.gz pragha_1.3.3.orig.tar.gz 
pragha-1.3.3.tar.gz pragha_1.3.3.orig.tar.gz differ: byte 5, line 1

  If you use git and git-buildpackage, make sure to use the
  "pristine-tar" feature.  When using this, a small delta file will be
  added to a special pristine-tar branch.  This allows to reconstruct
  the original tarball exactly as it was.

* In the debian/watch file you should replace "" with
  "pragha" (it also works as is, but then the downloaded tarball is
  called "-1.3.3.tar.gz" before the symlink is created).

* in debian/patches/fix-appstream-errors.patch:
  - referencing the ITP bug here does not make sense; you should only
use "Bug-Debian" if there is a bug in the Debian BTS that is
related to the patch (for example, if someone reported in the
Debian BTS that the appstream xml data is wrong)
  - Instead here you should record the URL of your pull request:

  Bug: https://github.com/pragha-music-player/pragha/pull/125


> Last but not least, I sent this message to debian-mentors (the right
> place to ask question, right?).  Please let me know if I got this
> wrong.

I think you got everything right.  The debian-mentors list will
automatically receive messages sent to the RFS bug, so there is no need
to explicitly CC it (but it doesn't hurt either).

I'm not a Debian Developer so I cannot sponsor your upload.  I hope you
find a sponsor soon!

Regards
Lukas

Bug#877104: uscan: Wrong information regarding OpenPGP fingerprints in man page

[Lukas Schwaighofer]

Package: devscripts
Version: 2.17.10
Severity: minor

Hi,

the uscan(1) man page states:

Please note that the short keyid 72543FAF is the last 4 Bytes, the
long keyid C77E2D6872543FAF is the last 8 Bytes, and the finger
print is the last 20 Bytes of the public key in hexadecimal form.
(...)

However, the fingerprint is not the last 20 Bytes of the public key,
but instead (for V4 keys) the hexadecimal representation of the SHA-1
hash of the public key (and some additional data [1]).

The short/long keyids are the last 4/8 Bytes of the same hash in hex.

Thanks
Lukas

[1] https://tools.ietf.org/html/rfc4880#section-12.2

Bug#805268: Adoption of syslinux

[Lukas Schwaighofer]

Control: owner -1 Debian CD Group 
Control: retitle -1 ITA: syslinux -- collection of bootloaders (DOS FAT and 
NTFS bootloader)

Hi,

I intend to work on syslinux as part of the Debian CD Group.  I'm open
to team maintenance and will probably need help every now and then
anyways, so if you read this and also want to step in just let me
know :) .

Regards
Lukas

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

thanks for the git link, makes things easier for me.

> Where did you get pragha-1.3.3.tar.gz from?
> I got it from
> https://github.com/pragha-music-player/pragha/archive/v1.3.3.tar.gz.

I got the same one (but I used `uscan -dd` to download, which uses the
debian/watch file and also renames it according to the rules in that
file).

> The files are not exactly the same, as you mentioned, but their
> contents, after extraction, are identical.

Technically I think it's sufficient if the contents is the same.
However, if you need to release a 1.3.3-2 version of pragha later, your
source package (.dsc) needs to reference (by hash) exactly the same orig
tarball you used for the 1.3.3-1 upload (see last paragraph of policy
5.6.21 [1]).

When using git and multiple computers, that means you pretty much have
to use pristine-tar anyways to satisfy this requirement, and I
personally prefer the tarball distributed with Debian to match exactly
the upstream one.

[1] https://www.debian.org/doc/debian-policy/#files

> >  If you use git and git-buildpackage, make sure to use the
> >  "pristine-tar" feature.  When using this, a small delta file will
> > be added to a special pristine-tar branch.  This allows to
> > reconstruct the original tarball exactly as it was.  
> 
> I wasn't aware of git-buildpackage, so I was making the tarball by
> hand and building with debuild.  Thanks for pointing this out.  On
> the other hand, I still do not understand how git-buildpackage
> works.  All my attempts to use it still resulted in a source tarball
> (.orig.tar.gz) that is not exactly the same as the tarball from
> upstream.

If you want to keep using git-buildpackage, I'd suggest you do the
following:

Add a file debian/gbp.conf with the following contents and commit it:
===
[DEFAULT]
pristine-tar = True
upstream-tag = upstream/v%(version)s

[buildpackage]
ignore-branch = True
===
this allows you to use the gbp commands without specifying the same
parameters over and over.  It also makes working with the repository
easier for someone else.

Then, to make use of pristine-tar, do the following from the root of
your git repository:
* Remove the orig.tar.gz from the parent directory (if present), e.g.:
  rm -f ../pragha_1.3.3.orig.tar.gz
* Re-download it from github, e.g. using your debian/watch file via
  uscan: `uscan -v -dd` (the -v is just so you see what's going on).
  If you download it manually you need to rename it.
* Now, add the pristine-tar delta files:
  pristine-tar commit ../pragha_1.3.3.orig.tar.gz

That's it (and it is only required once); if you build the package now
using git-buildpackage, it will reconstruct the original tarball
exactly as it is on github. :)


And, for the future, if you want to update to a new version of pragha
you can use `gbp import-orig --uscan`. This will use debian/watch to
download the newest version from github, update the upstream branch,
tag it, merge it with your packaging branch and also update the
pristine-tar branch.

Regards
Lukas

Bug#865462: extlinux: fails to boot from Btrfs filesystem

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Marek & Peter,

thanks a lot for not only reporting this issue but also finding and
testing the fix.  I can also reproduce the problem and confirm that the
mentioned commit fixes the issue.

I am in the process of adopting syslinux as part of the debian-cd
team.  A fixed version will probably be uploaded to unstable soon.  I
will also try to get this included in the next point release (9.3),
but we're obviously careful about changes to bootloader code so I can't
promise anything.

Regards
Lukas

Bug#803938: extlinux: boot from xfs partition not working

[Lukas Schwaighofer]

Hi Marek,

I've recently taken over maintenance of syslinux/exlinux as part of
the Debian CD Group, so I it's time to have a look at my own bug report.
Thanks for providing the link to the upstream changelog :) .

I've just compiled the most recent version of syslinux from git.  It
turns out that even this version can only boot from XFS partitions if
an MBR partition scheme is used.  With a GPT partition scheme, booting
is still not possible (same error as above).  I only then noticed that,
according to the wiki [1], syslinux only supports booting from XFS in
MBR partition schemes:

As of Syslinux 6.03, an XFS partition in an "MBR" partition scheme
is supported.

I've cloned the bug to track the MBR [2] and GPT [3] problems
separately.  I should be able to close the XFS+MBR problem eventually.
Since XFS+GPT is not yet supported upstream and it doesn't look like
anyone is actively working on that at the moment, I doubt that can be
fixed anytime soon.

Regards
Lukas

[1] http://www.syslinux.org/wiki/index.php?title=Filesystem#XFS
[2] https://bugs.debian.org/803938
[3] https://bugs.debian.org/879543

Bug#880506: gnu-efi: Please package new upstream version (3.0.6)

[Lukas Schwaighofer]

Source: gnu-efi
Version: 3.0.4-2
Severity: wishlist

Hi Julian,

please update gnu-efi to the latest upstream version (3.0.6).

It appears that upstream made a few small API changes from
3.0.4 → 3.0.5, which at least for syslinux will cause a FTBFS [1]
(patches are available).  I think it's a good idea to update this early
in the release cycle so all Build-Dependencies have enough time to
update in case they need to.

Making an orderly transition will be difficult, as it seems like
syslinux-efi is the only binary package in my the unstable amd64
package list that has a Built-Using dependency on gnu-efi…

Thank you
Lukas

[1] http://www.syslinux.org/archives/2017-June/025816.html

Bug#866343: extlinux: Files in /etc/kernel/ not removed during upgrade

[Lukas Schwaighofer]

Hi again,

I just checked the contents of the
 /etc/kernel/post{inst,rm}.d/zz-extlinux
files which are identical:

#!/bin/sh

set -e

# Exit if extlinux was removed (!= purged)
if [ -x /usr/sbin/extlinux-update ]
then
# Update extlinux configuration
extlinux-update
fi

Since the file is harmless enough when /usr/sbin/extlinux-update does
not exist, I think removing the file in sid/testing will be good enough.

Sorry for the noise, should have checked that file earlier.

Regards
Lukas

Bug#866343: extlinux: Files in /etc/kernel/ not removed during upgrade

[Lukas Schwaighofer]

Hi Laurent,

thanks for reporting this problem.  Leftover files in /etc/kernel/*.d
are bad…  I made a bit of research and found out the following, all of
which happened during the jessie release cycle:

0. The syslinux installer is part of the syslinux binary package
1. Version 3:6.03~pre1+dfsg-2: The installer was moved from the
   extlinux binary package to a newly introduced syslinux-stuff binary
   package
2. Version 3:6.03~pre19+dfsg-1: The syslinux-stuff binary package was
   dropped (completely removing the extlinux installer from Debian)

So, as far as I can tell, every system that has syslinux since
pre-jessie (and was never reinstalled since) will have those leftover
files.

Fixing this now in unstable feels somewhat in vain… I will ask for
advise on how to best deal with this issue.  For now I wanted to
document my findings.

Regards
Lukas

Bug#866343: extlinux: Files in /etc/kernel/ not removed during upgrade

[Lukas Schwaighofer]

On Tue, 7 Nov 2017 21:48:04 +0100
Lukas Schwaighofer <lu...@schwaighofer.name> wrote:

> 0. The syslinux installer is part of the syslinux binary package

That should have been:
0. The syslinux installer is part of the *extlinux* binary package

Bug#814459: pxelinux: doesn't use gPXE/iPXE anymore to load files

[Lukas Schwaighofer]

Hi Christian,

thanks for reporting this problem.  I've only recently taken over
maintenance of syslinux/pxelinux in the Debian CD Group.  Sorry you had
to wait more than a year for a response…

We recently uploaded a pre-release of syslinux 6.04 to Debian
experimental. Amongst other things the changelog mentions:

core: Re-add gPXE/iPXE support for HTTP on pxelinux.0 (Gene Cumm).

So I hope the problem has been resolved, but I didn't verify that yet.
In case you still have a suitable setup, would you mind testing the
version in experimental?

Thanks
Lukas

Bug#880086: snoopy: root parent name is extracted incorrectly, causing test suite fails (FTBFS) when building from tmux

[Lukas Schwaighofer]

Package: snoopy
Version: 2.4.6-1
Severity: important
Tags: upstream
Forwarded: https://github.com/a2o/snoopy/pull/126

Process names are extracted incorrectly by snoopy when they contain
colons (:) and incorrectly by the test suite when they contain
white-space characters.

The parent process name of any process run from tmux is "tmux: server".
This triggers both issues noted above and causes the
`datasource_rpname.sh` test to fail (resulting in FTBFS).

Previous discussion about this bug on pkg-security can be found here:
https://lists.alioth.debian.org/pipermail/pkg-security-team/Week-of-Mon-20171023/002209.html

Regards
Lukas

Bug#879773: stretch-pu: package syslinux/3:6.03+dfsg-14.1+deb9u1

[Lukas Schwaighofer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org, debian-b...@lists.debian.org, 
k...@debian.org


Dear release team and other involved parties,

I hereby ask for permission to update the syslinux package in stretch.
There has been a short discussion about this on debian-cd already [1].
The request is about fixing the following three problems:

1. Booting from ext4 filesystems created with Debian stretch does not
   work, because ext4's 64bit feature is enabled by default (since
   Debian stretch) and not supported by syslinux [2].
2. Booting from btrfs does not work either for a similar reason [3].
3. A bug in the isolinux isohybrid MBR causing boot failures with some
   old BIOS [4].

[1] https://lists.debian.org/debian-cd/2017/10/msg00032.html
[2] https://bugs.debian.org/833057
[3] https://bugs.debian.org/865462
[4] https://bugs.debian.org/879004

Problems 1 and 2 are regressions from jessie (due to changes in default
options when creating ext4/btrfs filesystems), while problem 3 affects
jessie as well.  The fix for each of the three bugs has been
cherry-picked from upstream and has a reasonably sized diff.  Debian
testing and unstable already have the fixes.

I've tested the proposed version.  In those tests, the problems 1 and 2
were solved as expected.  As for problem 3, I've verified that the
isohdpfx.bin image built is identical to a known good and tested
version.  Additionally we got a report that the debian-cd images for
testing (which are built using the fixed isohdpfx.bin) boot correctly on
affected hardware [5].

A debdiff of the proposed update is attached.  Alternatively it's also
available from the debian/stretch branch of the git repository [6].

Thank you for your time and consideration
Lukas

PS: If this request gets ACKed, I also intend to fix the isohybrid MBR
in jessie (as advised by Steve McIntyre).

[5] https://bugs.debian.org/857597#117
[6] https://anonscm.debian.org/git/debian-cd/syslinux.git


syslinux_6.03+dfsg-14.1+deb9u1.debdiff
Description: Binary data


pgpJPmd3tH00c.pgp
Description: OpenPGP digital signature

Bug#880123: jessie-pu: package syslinux/3:6.03+dfsg-5+deb8u1

[Lukas Schwaighofer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org, debian-b...@lists.debian.org, 
k...@debian.org

Dear release team,

I hereby ask for permission to update the syslinux package in jessie as
well.  The update fixes a bug in the isolinux isohybrid MBR causing boot
failures with some old BIOS [1].

The bug is already fixed in unstable/testing and the update for stretch,
which also includes this fix, has just been approved [2].

I tested the build in an sbuild jessie chroot and the updated package
builds the correct isohdpfx.bin file (identical to the one currently in
unstable/testing).  The debdiff is attached.

Thank you
Lukas

[1] https://bugs.debian.org/879004
[2] https://bugs.debian.org/879773
diff -Nru syslinux-6.03+dfsg/debian/changelog syslinux-6.03+dfsg/debian/changelog
--- syslinux-6.03+dfsg/debian/changelog	2015-08-18 17:23:09.0 +0200
+++ syslinux-6.03+dfsg/debian/changelog	2017-10-29 19:12:43.0 +0100
@@ -1,3 +1,11 @@
+syslinux (3:6.03+dfsg-5+deb8u2) jessie; urgency=medium
+
+  * Add patch from upstream to fix boot problem for old BIOS firmware from
+around 2005 by correcting the C/H/S order (thanks Thomas Schmitt,
+Closes: #879004).
+
+ -- Lukas Schwaighofer <lu...@schwaighofer.name>  Sun, 29 Oct 2017 19:12:43 +0100
+
 syslinux (3:6.03+dfsg-5+deb8u1) jessie; urgency=low
 
   * Cherry-pick upstream patches that fix booting on some Chromebooks
diff -Nru syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch
--- syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch	1970-01-01 01:00:00.0 +0100
+++ syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch	2017-10-29 19:12:43.0 +0100
@@ -0,0 +1,50 @@
+From: Martin Str|mberg <a...@ludd.ltu.se>
+Date: Sun, 26 Mar 2017 07:32:11 -0400
+Subject: mbr/isohdpfx.S: correct stack for heads/sectors
+
+Heads and sectors were pushed in reverse order per isolinux.asm
+(bb519a95 reversed the order of heads/sectors on the stack).
+
+If anything goes wrong, clear CX in case it contains garbage.
+
+Signed-off-by: Gene Cumm <gene.c...@gmail.com>
+
+Bug-Debian: https://bugs.debian.org/879004
+Origin: upstream, quashed two commits together:
+ http://git.zytor.com/syslinux/syslinux.git/commit/?id=32c09027423f61c305e2423e52f5f69ecad8e2c0
+ http://git.zytor.com/syslinux/syslinux.git/commit/?id=8739e2ff9ba3f92652c8df846924fd00e1ce2753
+---
+ mbr/isohdpfx.S | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S
+index 17e1efe..4b107e4 100644
+--- a/mbr/isohdpfx.S
 b/mbr/isohdpfx.S
+@@ -167,20 +167,22 @@ next:
+ 	   read_sector_cbios: movb $0x42, %ah ;  jmp read_common */
+ 	movl	$0xeb42b4+((read_common-read_sector_cbios-4) << 24), \
+ 		(read_sector_cbios)
+-	jmp	1f
++	jmp	2f
+ 1:
++	xor	%cx, %cx	/* Clear EBIOS flag. */
++2:
+ 	popw	%dx
+ 	pushw	%cx		/* EBIOS flag */
+ 
+ 	/* Get (C)HS geometry */
+ 	movb	$0x08, %ah
+ 	int	$0x13
+-	andw	$0x3f, %cx	/* Sector count */
+ 	popw	%bx		/* EBIOS flag */
+-	pushw	%cx		/* -16: Save sectors on the stack */
+ 	movzbw	%dh, %ax	/* dh = max head */
+ 	incw	%ax		/* From 0-based max to count */
+-	pushw	%ax		/* -18: Save heads on the stack */
++	pushw	%ax		/* -16: Save heads on the stack */
++	andw	$0x3f, %cx	/* Sector count */
++	pushw	%cx		/* -18: Save sectors on the stack */
+ 	mulw	%cx		/* Heads*sectors -> sectors per cylinder */
+ 
+ 	pushw	%bx		/* -20: EBIOS flag */
diff -Nru syslinux-6.03+dfsg/debian/patches/series syslinux-6.03+dfsg/debian/patches/series
--- syslinux-6.03+dfsg/debian/patches/series	2015-08-18 17:13:25.0 +0200
+++ syslinux-6.03+dfsg/debian/patches/series	2017-10-29 19:12:43.0 +0100
@@ -4,3 +4,4 @@
 0004-gnu-efi-git.patch
 0005-load-linux-correct-type.patch
 0006-load-linux-protected-mode.patch
+0017-isohdpfx.S-correct-heads-sectors.patch


pgpAzL2gJ0DSE.pgp
Description: OpenPGP digital signature

Bug#886635: arpwatch: tries to start before network is up

[Lukas Schwaighofer]

Hello Roland,

thanks for your report!

On Mon, 8 Jan 2018 10:50:49 +0100
Roland Rosenfeld  wrote:

> I use arpwatch via systemd, but had to notice, that arpwatch tries to
> start up before the network interface is fully up (some spanning tree
> issue).  This leads to arpwatch failing and not correctly starting up.
> 
> [log snippet removed]
> 
> I think that arpwatch should wait until the interface is up, so I
> created the following
> /etc/systemd/system/arpwatch@eth0.service.d/override.conf which fixes
> the issue for me:
> 
> [Unit]
> After=network-online.target
> 
> [Install]
> Wants=network-online.target
> 
> Maybe it would be a good idea to add something like this to
> /lib/systemd/system/arpwatch@.service

You are right, the current state definitely needs fixing.  Currently
the per-instance unit file doesn't even wait for network.target (which
was what I had originally intended, but PartOf does not actually do
that).  But since arpwatch reads the interface's configuration,
network-online makes sense.

I'll add the network-online.target dependency to the arpwatch@.service
file as you suggested.  Note that the "Wants=" directive should also be
part of the [Unit] section as per documentation.

Thanks & regards
Lukas


pgp3Vf_tVu0cn.pgp
Description: OpenPGP digital signature

Bug#221616: arpwatch behaviour inlogical wrt to flipflop/new station

[Lukas Schwaighofer]

Hello Alexander,

thank you for your report.  Unfortunately I'll have to disappoint:
I've no plans on extending arpwatch to be able to "follow" ethernet
addresses.  I also don't want to merge #527251, as it adds quite a bit
of code that we would need to support.  Substantial changes like that
are typically done in the upstream project before they can make their
way into Debian.  However, in the arpwatch case, upstream has been
inactive for a long time so I consider it very unlikely this will
happen…

Arpwatch has always only "followed" IPv4 addresses (and never ethernet
addresses), meaning if it sees an ARP message containing an
IPv4/ethernet "binding" it will lookup previous ethernet address(es)
using that IPv4 address.  As you can probably imagine, changing the code
to "follow" ethernet addresses too would be a substantial change.

I wasn't aware the documentation is wrong in that regard.  Thanks for
pointing that out.  I will probably change the wording to something
similar to:

  new station: "There are no previous known ethernet addresses for this
IPv4 address"


So much for the bad news, I also have something that might help you:
Since Debian version 2.1a15-4 (unfortunately not in stretch) arpwatch
supports filters to ignore certain packets.  So if you are happy with
completely ignoring your Laptop's ethernet address in arpwatch (and
after upgrading to that version), you could add add a filter to do that.

Sorry I'm not able to offer more help.

Have a nice weekend
Lukas

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

Hi,

On Fri, 17 Aug 2018 21:43:50 +0200
Lukas Schwaighofer  wrote:

> Matthias: As the binutils maintainer, can you provide any help? I
> don't really know how to proceed… and since this was broken by a
> Debian revision, it's probably not an upstream problem? Thanks!

I've made some progress: If I discard the .note.gnu.property section
(which was not added since before binutils 2.31.1-2) I'm able to build
the package again. I've attached a patch to the linker scripts for
reference.

Unfortunately my tests shows that with this new build the efi binary no
longer works (at least when testing tianocore).  I have not yet
determined if this is also related to binutils and I suspect this is
actually a different issue. I'll keep you posted.
Author: Lukas Schwaighofer 
Description: Strip the .note.gnu.property section for the mbr. This section is
 added since binutils Debian version 2.31.1-2 and causes mbr.bin to grow in
 size beyond what can fit into the master boot record.
---
 mbr/i386/mbr.ld   | 1 +
 mbr/x86_64/mbr.ld | 1 +
 2 files changed, 2 insertions(+)

diff --git a/mbr/i386/mbr.ld b/mbr/i386/mbr.ld
index d14ba80..5368346 100644
--- a/mbr/i386/mbr.ld
+++ b/mbr/i386/mbr.ld
@@ -70,4 +70,5 @@ SECTIONS
   .debug_typenames 0 : { *(.debug_typenames) }
   .debug_varnames  0 : { *(.debug_varnames) }
   /DISCARD/ : { *(.note.GNU-stack) }
+  /DISCARD/ : { *(.note.gnu.property) }
 }
diff --git a/mbr/x86_64/mbr.ld b/mbr/x86_64/mbr.ld
index ae27d49..b8c0d89 100644
--- a/mbr/x86_64/mbr.ld
+++ b/mbr/x86_64/mbr.ld
@@ -69,4 +69,5 @@ SECTIONS
   .debug_typenames 0 : { *(.debug_typenames) }
   .debug_varnames  0 : { *(.debug_varnames) }
   /DISCARD/ : { *(.note.GNU-stack) }
+  /DISCARD/ : { *(.note.gnu.property) }
 }

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

On Sat, 18 Aug 2018 12:42:45 +0200
Lukas Schwaighofer  wrote:

> Unfortunately my tests shows that with this new build the efi binary
> no longer works (at least when testing tianocore).  I have not yet
> determined if this is also related to binutils and I suspect this is
> actually a different issue. I'll keep you posted.

That one was also a problem that was caused by a different binutils
version, but I managed to solve it as well :) . Will upload a new
version shortly.

[still wondering why the BTS ate my last message…]

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Santiago,

I can confirm the build failures. The same error also happens when
building syslinux on buster from upstream's git repository.

I'll try to find out which dependency change caused the size of mbr.bin
to grow and will then probably need to work with upstream to get this
fixed.

Thanks for your report
Lukas

Bug#728206: ITP: librtr -- Library implementing the client-side of the RPKI-RTR Protocol.

[Lukas Schwaighofer]

Control: owner -1 debian-security-to...@lists.debian.org
Control: retitle -1 ITP: librtr -- Library implementing the client-side of the 
RPKI-RTR Protocol.

This library has been gaining more popularity recently, e.g.
https://github.com/FRRouting/frr. Packaging it will enable more
software to be easily packageable/buildable/usable from Debian.

I intend to maintain this as part of the Debian Security Tools
Packaging Team.

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

Hi,

the problem started with the upgrade from binutils 2.31.1-1 to
2.31.1-2. If I download the following 4 packages and install them, I
can build syslinux just fine:
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/binutils-x86-64-linux-gnu_2.31.1-1_amd64.deb
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/binutils-common_2.31.1-1_amd64.deb
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/binutils_2.31.1-1_amd64.deb
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/libbinutils_2.31.1-1_amd64.deb


Matthias: As the binutils maintainer, can you provide any help? I don't
really know how to proceed… and since this was broken by a Debian
revision, it's probably not an upstream problem? Thanks!

Regards
Lukas

Bug#907805: syslinux.efi uses the TFTP server IP for the HTTP domain

[Lukas Schwaighofer]

Hi Marco,

On Sun, 2 Sep 2018 14:08:09 +0200
Marco d'Itri  wrote:

> When providing to syslinux.efi an http URL in option 67:
> 
> dhcp-option=option:bootfile-name,http://pxe.example.net/EFI/SYSLINUX/syslinux.efi
> 
> then it will try to download the modules like ldlinux.e64, the 
> configuration file and the payload by sending an HTTP request to the 
> TFTP server address (with pxe.example.net as virtual host) instead of 
> resolving pxe.example.net and using that IP as expected.

I checked the source code and found that efi network support was added
here:
http://repo.or.cz/syslinux.git/commit/fe283b78c973268f2d1f0309826ceeb5c9e8978d
The commit mentions in the TODO part that DNS resolve code is still
missing.

This still seems to be the case, since the pxe_dns function in efi/pxe.c
in the current HEAD
(http://repo.or.cz/syslinux.git/blob/HEAD:/efi/pxe.c, lines 38-49) will
`return 0` in all cases.

The connection to your TFTP server address is the fallback behavior
that's implemented for DNS resolve failures in core/fs/pxe/pxe.c
(http://repo.or.cz/syslinux.git/blob/HEAD:/core/fs/pxe/pxe.c, lines
251-256).

I will do a bit of testing and then forward your report to upstream.

Regards
Lukas

Bug#914732: lists.debian.org: Request for new mailing list: debian-dug-muc

[Lukas Schwaighofer]

Seconded, we could really use a working Munich list again.

Bug#918915: syslinux-common: Undef symbol FAIL: exp in libgpl.c32 when trying to load hdt.c32

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Wolfgang,

thanks for reporting!

On Thu, 10 Jan 2019 15:27:07 +0100
Wolfgang Scheicher  wrote:

> After switching from stretch to buster i realized that the
> Hardware Detection Tool (HDT) in the Advanced options Boot menu fails
> with this error:
> 
> Undef symbol FAIL: exp
> Failed to load libgpl.c32
> Failed to load COM32 file hdt.c32
> boot:

This problem seems to have been introduced by compiling syslinux with a
newer GCC version.  There was a mail about this to the syslinux
Mailinglist containing a patch in August [1] which I somehow missed
(despite being subscribed…).

I've just built libgpl.c32 with the patch applied and based on the
`readelf` output I believe the patch fixes the problem.  I'll do an
actual test soon and if everything checks out upload a fixed version.

Regards
Lukas

[1] https://www.syslinux.org/archives/2018-August/026159.html

Bug#916009: sbuild: sbuild-createchroot --setup-only option is unusable due to empty directory checking

[Lukas Schwaighofer]

Package: sbuild
Version: 0.77.1-2
Severity: normal
Tags: patch


Dear Maintainer,

the sbuild-createchroot --setup-only option is designed to perform setup
tasks on an existing chroot.  Thus the check for non-empty directories
introduced in

https://salsa.debian.org/debian/sbuild/commit/53e250cdeb0035663833fa0c8ce80adf96d31c03
needs to be disabled when that option is in use.

I've fixed this for my need with the following change:


diff -u /usr/bin/sbuild-createchroot sbuild-createchroot
--- /usr/bin/sbuild-createchroot»   2018-11-13 16:07:19.0
+0100 +++ sbuild-createchroot»2018-12-09 11:41:56.634681576 +0100
@@ -288,7 +288,7 @@
 # has more entries than just "." and ".." and must thus not be
empty. readdir $dh;
 readdir $dh;
-die "$target is not empty" if (readdir $dh);
+die "$target is not empty" if (readdir $dh and !$conf->get('SETUP_ONLY')); 
} else {
 # Create the target directory in advance so abs_path (which is
buggy) # won't fail.  Remove if abs_path is replaced by something
better.


Thanks
Lukas