Bug#933185: fai-server: /etc/fai/apt/sources.list should not contain trusted=yes to skip GPG verification

[Christian Seiler]

Hi,

(Sorry, overlooked your email.)

Am 2019-08-12 21:31, schrieb Thomas Lange:

I think we cannot fix it in this way.
gpg --export 2BF8D9FE074BCDE4 may not work, if the key is not already
downloaded and available for gpg. I also do not want to force to
install the package debian-keyring on the fai server.
And we should not create a file when calling fai-make-nfsroot under
/etc which is normally a config file.

The idea is to ship the gpg key directly in the fai-server package.
So I would add the file /etc/fai/apt/trusted.gpg.d/fai-project.gpg to
the package fai-server. What do you think?


Sorry if I wasn't clearer in my bugreport. Yes, I did mean that
you should simply add the fai-project.gpg to the package. The
gpg --export was just a demonstration how to work around this
issue with the current version of FAI.

So yes, if you added the file to the package and removed the
[trusted=yes] in the /etc/fai/apt/sources.list, that would be
perfect.

Thanks!

Best regards,
Christian

Bug#933185: fai-server: /etc/fai/apt/sources.list should not contain trusted=yes to skip GPG verification

[Christian Seiler]

Package: fai-server
Version: 5.8.4
Severity: grave
Tags: security, buster

Dear Maintainer,

fai-server installs /etc/fai/apt/sources.list with the following entry
by default:

deb [trusted=yes] http://fai-project.org/download buster koeln

This is problematic, as the [trusted=yes] part will tell APT to
completely skip cryptographic verification of the repository when
creating the nfsroot. This is extremely bad because the repository is
accessed via unencrypted HTTP, which makes a man-in-the-middle attack
absolutely trivial. True, this only occurs if the NFSROOT is created
and/or updated, but at least updating with make-fai-nfsroot -k should
be a semi-regular thing on well-managed systems.

You should make sure that your APT signing key is added to the
NFSROOT so that APT may check it:

 - Export your GPG signing key in binary (NOT -a!) format:
   gpg --export 2BF8D9FE074BCDE4 > fai-project.gpg

 - Create a directory /etc/fai/apt/trusted.gpg.d

 - Copy the file to the appropriate directory
   cp fai-project.gpg /etc/fai/apt/trusted.gpg.d/

 - Remove the [trusted=yes] part of that line

I've tested this with a pristine FAI install on Debian 10 and during
fai-make-nfsroot the repository is correctly added to the NFSROOT and
the integrity of the signatures is properly checked.

For Debian 9 I don't think this is a critical issue (as the default
configuration does not include the repository, the line is commented
out entirely), but even suggestions in configuration files should
follow established security practices, so I would recommend also
removing the [trusted=yes] comment from the package in Debian 9 (and
also including the key there, or maybe just a comment on how to add
the key), so that inexperienced administrators may avoid the trap that
enabling this repository leads to a security issue.



Best regards,
Christian

-- System Information:
Debian Release: 10.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fai-server depends on:
ii  debootstrap  1.0.114
ii  e2fsprogs1.44.5-1
ii  fai-client   5.8.4
ii  xz-utils 5.2.4-1

Versions of packages fai-server recommends:
pn  isc-dhcp-server   
pn  libproc-daemon-perl   
pn  nfs-kernel-server 
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  openssh-client1:7.9p1-10
ii  openssh-server1:7.9p1-10
pn  tftpd-hpa | atftpd

Versions of packages fai-server suggests:
ii  binutils   2.31.1-16
pn  debmirror  
pn  fai-setup-storage  
pn  grub2  
pn  perl-tk
ii  qemu-utils 1:3.1+dfsg-8~deb10u1
pn  reprepro   
ii  squashfs-tools 1:4.3-12
ii  xorriso1.5.0-1

-- no debconf information

Bug#886263: gtk3-nocsd does not work for python programs

[Christian Seiler]

Control: tags -1 + confirmed

On 01/07/2018 11:08 AM, Allo wrote:

I can confirm, that gtk3-nocsd 3-1 works with evince 3.26.0-2 and does
not work with gajim 1.0.0~alpha2-1 in debian buster, which are the
latest available versions in buster right now.


I can reproduce this in a virtual machine.

Note that evince doesn't appear to use CSDs at all anymore when not on
GNOME (even without gtk3-nocsd), but e.g. gedit can demonstrate nicely
that gtk3-nocsd does work in principle.

I've also tested this on Stretch, and there Gajim does not use CSDs
with gtk3-nocsd, so this was introduced with a change in gtk3 in
Buster. (Presumeably.)

I'll take a look at what exactly changed in Buster regarding CSDs in
the next couple of days.

Regards,
Christian

Bug#883628: ITP: ioport -- direct access to I/O ports from the command line

[Christian Seiler]

On 01/05/2018 03:30 PM, Lubomir Rintel wrote:

On Fri, 5 Jan 2018 12:16:10 +0100 Tobias Frost  wrote:

You keep the Debian revision the same until it is sponsored.


That's what I initially meant to do, but mentors.debian.org won't let
me upload a changed package with the same version number.


You can remove the old package on Mentors via the web interface and
then upload the package in that version again with different contents.

Note that in my experience reuploading an existing version to Mentors
worked when done via FTP, but not via HTTP. (But that may be outdated
information, I haven't tried that in forever.)

Regards,
Christian

Bug#886263: gtk3-nocsd does not work for python programs

[Christian Seiler]

Control: severity -1 important
Control: tags -1 + buster sid

On 01/03/2018 04:26 PM, Alexander Schier wrote:

Dear Maintainer,
gtk3-nocsd seems not to work for python programs like gajim (1.x). Probably
the preloaded lib is not used for the interpreter / the gtk lib loaded
by python or similar.
Is there a possible fix or workaround?


It should work for Python programs (and it does on Stretch), so I
assume this is because of changes in GTK in Buster/sid that are
now incompatible with gtk3-noscsd.

1.Could you give me the precise Debian versions of gajim as well
as the GTK library it uses (both the version of the Python package
as well as the C package)?

2. Are you on X11 or Wayland? What Desktop environment or Window
manager are you using?

3. What does "does not work" mean? Program crashes? Or does it
still use CSDs? If so, could you perhaps attach a screenshot?

Thanks!

Regards,
Christian

Bug#885069: stretch-pu: package open-iscsi/2.0.874-3~deb9u1

[Christian Seiler]

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

Dear release team,

I'd like to ask for a stable update for open-iscsi in Stretch to fix
#885021, which was marked no-DSA by the security team. I've CC'd
debian-boot@ and KiBi as the package builds udebs (though the change
itself does not affect udebs, as 'iscsiuio' is not included in d-i).

I've fixed the bug in unstable in 2.0.874-5.

debdiff against stretch is attached.

I've built and tested the package in Stretch itself. Note, however,
that the affected program, iscsiuio, is there to enable support for
special hardware that neither I nor Ritesh have access to. The patches
themselves come directly from upstream, and a review appears to
indicate they are sane, but - in the interest of full transparency - I
cannot guarantee 100% that they don't introduce a regression. If you'd
like to wait and see if sid/testing users report regressions before
accepting this p-u I'd understand, though I would like to note that
open-iscsi is one of those packages where next to no users actually use
it outside of stable itself, so most reports we get are actually from
users of stable, and not testing/sid.

The 'jessie' package doesn't build iscsiuio though it contains the
source for it, and even if people built iscsiuio from Jessie's source
directly, that was broken in a lot of other ways (which is why it was
disabled again before the release of Jessie and only properly enabled
in Stretch), so I don't think it makes sense to update Jessie.

Regards,
Christian

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru open-iscsi-2.0.874/debian/changelog 
open-iscsi-2.0.874/debian/changelog
--- open-iscsi-2.0.874/debian/changelog 2017-06-18 23:06:16.0 +0200
+++ open-iscsi-2.0.874/debian/changelog 2017-12-23 13:09:13.0 +0100
@@ -1,3 +1,10 @@
+open-iscsi (2.0.874-3~deb9u2) stretch; urgency=high
+
+  * [4b930f8] Fix multiple security issues in iscsiuio. (CVE-2017-17840)
+(Closes: #885021)
+
+ -- Christian Seiler   Sat, 23 Dec 2017 13:09:13 +0100
+
 open-iscsi (2.0.874-3~deb9u1) stretch; urgency=medium
 
   * [8de3092] udeb: don't update initramfs when iSCSI is not used.
diff -Nru 
open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
 
open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
--- 
open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
  1970-01-01 01:00:00.0 +0100
+++ 
open-iscsi-2.0.874/debian/patches/security/Check-for-root-peer-user-for-iscsiuio-IPC.patch
  2017-12-23 13:09:13.0 +0100
@@ -0,0 +1,122 @@
+From e313bd648a4c8a9526421e270eb597a5de1e0c7f Mon Sep 17 00:00:00 2001
+From: Lee Duncan 
+Date: Fri, 15 Dec 2017 10:36:11 -0800
+Subject: [PATCH 1/8] Check for root peer user for iscsiuio IPC
+
+This fixes a possible vulnerability where a non-root
+process could connect with iscsiuio. Fouund by Qualsys.
+---
+ iscsiuio/src/unix/Makefile.am  |  3 ++-
+ iscsiuio/src/unix/iscsid_ipc.c | 47 ++
+ 2 files changed, 49 insertions(+), 1 deletion(-)
+
+--- a/iscsiuio/src/unix/Makefile.am
 b/iscsiuio/src/unix/Makefile.am
+@@ -20,7 +20,8 @@ iscsiuio_SOURCES =   build_date.c\
+   nic_utils.c \
+   packet.c\
+   iscsid_ipc.c\
+-  ping.c
++  ping.c  \
++  ${top_srcdir}/../utils/sysdeps/sysdeps.c
+ 
+ iscsiuio_CFLAGS = $(AM_CFLAGS)\
+   $(LIBNL_CFLAGS) \
+--- a/iscsiuio/src/unix/iscsid_ipc.c
 b/iscsiuio/src/unix/iscsid_ipc.c
+@@ -37,6 +37,8 @@
+  *
+  */
+ 
++#define _GNU_SOURCE
++
+ #include 
+ #include 
+ #include 
+@@ -47,6 +49,8 @@
+ #include 
+ #include 
+ #include 
++#include 
++#include 
+ 
+ #define PFX "iscsi_ipc "
+ 
+@@ -61,6 +65,7 @@
+ #include "iscsid_ipc.h"
+ #include "uip.h"
+ #include "uip_mgmt_ipc.h"
++#include "sysdeps.h"
+ 
+ #include "logger.h"
+ #include "uip.h"
+@@ -102,6 +107,7 @@ struct iface_rec_decode {
+   uint16_tmtu;
+ };
+ 
++#define PEERUSER_MAX  64
+ 
+ 
/**

Bug#885021: open-iscsi: CVE-2017-17840: buffer overflow in process_iscsid_broadcast()

[Christian Seiler]

Hi Salvatore,

On 12/23/2017 01:17 PM, Salvatore Bonaccorso wrote:
> On Sat, Dec 23, 2017 at 12:32:32PM +0100, Christian Seiler wrote:
>> Thanks for reporting this. It wasn't mentioned on the official
>> open-iscsi mailing list, and the fact that I've missed the pull
>> request alerted me to the fact that I wasn't watching the upstream
>> github repository. (Which I've now rectified.)
>>
>> I've now uploaded -5 that includes all patches in the pull request
>> you've mentioned.
> 
> And thanks for fixing that so quickly :)

Well, it's a security issue after all. :)

>> I've seen in the security tracker you've marked this no-DSA, so I
>> assume I should ask the Release team for a p-u to get this fixed
>> in Stretch?
> 
> That is right, I think the issue is not severe enough that we would
> issue a DSA for it.

Ok, I'm currenty preparing the package for that and will open a
p-u bug once I've finished.

>> Note: neither Wheezy nor Jessie include iscsiuio (this was added
>> in Stretch), so they are not affected by this bug, so only
>> Stretch is also vulnerable. (stretch-backports is vulnerable,
>> which I'll fix once a fix for stretch has been uploaded.) It
>> would be great if you could update the security tracker to reflect
>> this.
> 
> Yes that's a bit tricky. We are interested to track source package
> status, and in fact, the code looks there in jessie, so 
> would not be technically fully correct. I though changed the status to
> , that is, we will not further look into it, neither has the
> maintainer, and added a note/explanation of "Minor issue, iscsiuio not
> built in this version, source affected)".

Ok, that's fine. Wheezy is completely unaffected though as there
iscsiuio was not present in the source code.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#885021: open-iscsi: CVE-2017-17840: buffer overflow in process_iscsid_broadcast()

[Christian Seiler]

Control: tags -1 + stretch

Hello,

On 12/22/2017 11:37 PM, Salvatore Bonaccorso wrote:
> the following vulnerability was published for open-iscsi, whilest only
> "one" of the issues from the qualys report has a CVE, cf. [1], all
> fixes from [2] should preferably be applied. Cf. as well [3].

Thanks for reporting this. It wasn't mentioned on the official
open-iscsi mailing list, and the fact that I've missed the pull
request alerted me to the fact that I wasn't watching the upstream
github repository. (Which I've now rectified.)

I've now uploaded -5 that includes all patches in the pull request
you've mentioned.

I've seen in the security tracker you've marked this no-DSA, so I
assume I should ask the Release team for a p-u to get this fixed
in Stretch?

Note: neither Wheezy nor Jessie include iscsiuio (this was added
in Stretch), so they are not affected by this bug, so only
Stretch is also vulnerable. (stretch-backports is vulnerable,
which I'll fix once a fix for stretch has been uploaded.) It
would be great if you could update the security tracker to reflect
this.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#880576: targetcli-fb: Cannot create PSCSI backend for SCSI tape drive

[Christian Seiler]

Hi,

On 11/10/2017 05:37 PM, Herbert Nachtnebel wrote:
> I can confirm that using the tape drive from another host does work
> like a charm after manually creating the pscsi backend using
> configfs, yeah!

Fantastic!

> Thanks Christian for your input solving this issue!
> If you already have a patch for targetcli to use sysfs'
> /bus/scsi/devices/... for detecting the real device paths, I am eager
> to test it.

I don't have one yet because I wanted to wait for your feedback (and
was quite busy with other things this week), but I'll work on one
during the weekend. I'll post an update to this bug report once I've
got a fixed package, and if you say it works for you I'll take care
of getting that into Debian.

Regards,
Christian

Bug#880576: targetcli-fb: Cannot create PSCSI backend for SCSI tape drive

[Christian Seiler]

Hi there,

On 11/09/2017 09:24 AM, Herbert Nachtnebel wrote:
> Thank you very much for the walk through to create the device!
> Indeed, with these instruction I could create a backend for the
> target. For completeness, one further step was missing: setting the
> udev_path before enabling the device:
> 
> echo /dev/nst0 > /sys/kernel/config/target/core/pscsi_0/tape/udev_path

Oh, I believed that was optional, that's why I didn't mention
it... ;-)

But great to hear that this just appears to be a problem with the
user space tooling and not the kernel itself - that makes it quite
a bit easier to fix.

Anyway, great that that appears to work, and I'll wait for your
functional tests. If those do work out (i.e. you can use that device
from an initiator) I'll work on a patch for the targetcli command.

Regards,
Christian

Bug#880576: targetcli-fb: Cannot create PSCSI backend for SCSI tape drive

[Christian Seiler]

Control: tags -1 + confirmed upstream

Hi,

On 11/02/2017 02:29 PM, Herbert Nachtnebel wrote:
> exporting a local SCSI tape drive using targetcli is not possible. The used
> SCSI tape
> drive is an older HP Ultrium-2 SCSI drive connected via a Adaptec 29320ALP 
> U320
> PCIe
> SCSI controller to the host.  The host is a freshly set up Debian 9.2 system.

Thanks for the detailed bug report! Unfortunately I don't have a SCSI
tape drive with which I can test this (I only have disks and CD drives,
which do work according to your report), so I can't reproduce this
myself.

That said, I've looked at the code, and the current pscsi interface
in the targetcli GUI can only export block devices, but tape drives
are actually character devices - that's why it doesn't find anything,
because it looks for devices in /sys/block in the sysfs structure, and
the tape drive doesn't exist there.

Now I'm not currently sure whether this is just a but in targetcli
because it assumes block devices and that tape device export would
actually work on the kernel side, or if this also has problems with
the kernel.

Could you perhaps try to add this manually via the configfs interface?

1. Ensure that rtslib-fb-targetctl.service is started. (To make sure
   the configfs filesystem for LIO is mounted.)

2. Run the following commands to try to create the backstore manually:

# Create backstore ('tape' is just the name here, you can also call
# it something else if you like; the other part of the path is fixed
# though)
mkdir -p /sys/kernel/config/target/core/pscsi_0/tape

# Generate a unique WWN
uuidgen > /sys/kernel/config/target/core/pscsi_0/tape/wwn/vpd_unit_serial

# Add the device (IDs taken from your lsscsi output)
echo scsi_host_id=2,scsi_channel_id=0,scsi_target_id=0,scsi_lun_id=0 \
 > /sys/kernel/config/target/core/pscsi_0/tape/control

# Enable the backstore
echo 1 > /sys/kernel/config/target/core/pscsi_0/tape/enable

# Check kernel logs
# Check 'targetcli ls' output

If that works and the device is added you _should_ be able to export
it via targetcli. If that also works you should be able to use the
tape device from an iSCSI initiator.

What most likely won't work is targetctl being able to reload the
configuration when the system reboots, so this is only temporary. [1]

But if the export of the device actually does work on your system I
could create a patch for targetctl (and possibly targetcli) that
should fix this, and if that does work I'll ask the release team
whether I can get that into the next point release of Stretch.

Regards,
Christian

[1] Note: targetctl is the command used to restore configuration at
boot, targetcli is the shell to configure it.

Bug#877949: Package description: do you really mean "offload"?

[Christian Seiler]

Hi,

On 10/07/2017 10:56 PM, Martin Eberhard Schauer wrote:
> Package: iscsiuio
> Version: 2.0.874-3~deb9u1
> Severity: wishlist
> X-Debbugs-CC: debian-l10n-engl...@lists.debian.org
> 
> the last paragraph of the package description [1] and its short
> description sound strange to me.
> 
>   "This package is required to offload iSCSI onto these devices."
> 
> Not being a native English speaker, I found [2]. Thus I believe that
> "offload" and "onto" don't fit together.

I'm not a native speaker either, but the link you mentioned does
actually use "offload onto" in the example. To quote your link [2]
:

   [Definition]
  get rid of something that you do not want by giving it to someone
  else

   [Example]
  I managed to offload some of our old furniture onto a friend who
  just bought a house.

This does fit the package; iscsiuio enables offloading of the work
required to process and generate iSCSI packets onto the network card
itself. (Some network cards capable of iSCSI offloading don't require
iscsiuio for that functionality to work, but those in the package
description do.)

The term "offload" is also used widely in similar contexts in the
network stack, for example when it comes to calculating TCP checksums:
https://en.wikipedia.org/wiki/TCP_offload_engine

That said, I am open to wording improvements to help clarify this, but:

> Perhaps
>   "You need this package|software to make these devices work with iSCSI"?

Sorry, but this is completely wrong on a technical level. The devices
we are talking about here are network cards (NICs). There have been
drivers in the Linux kernel for these network cards for years now, you
don't need iscsiuio to make them work at all.

You also don't need iscsiuio to make iSCSI work over them: the standard
software iSCSI stack on Linux will work perfectly fine over any network
card.

What iscsiuio does here is that it provides a part of the functionality
required to have the network cards take over the processing of the
iSCSI sessions. This means that the processing of data packets (reading
and writing from/to iSCSI disks) is now not done by the kernel on the
CPU, but done by the network card itself. This reduces the CPU load on
the host system and improves performance with iSCSI. But you don't
actually need to use those features of your network card if you just
want to get iSCSI to work.

If you want to go further into more detail, iscsiuio is actually a
really ironic thing. The QLogic (formerly Broadcom) cards that iscsiuio
supports are cards that for some reason unknown to me separate the
actual network capabilities and the offloading capabilities. But they
also only support the actual iSCSI protocol over TCP, but no other IP
protocols (such as ARP or DHCP) that are actually required to
successfully have a link. Therefore it is up to the software to provide
DHCP / ARP functionality for the part of the card that handles the
iSCSI offloading, which is kind of a reverse offloading for the ARP
functionality. And the driver authors for these cards have decided
that they want to provide that via a userspace daemon. In fact, once
the offloaded iSCSI session over a QLogic/Broadcom card has been
established and if you don't care about the ability to be able to
reconnect in case the link goes down, you can actually shut down the
iscsiuio daemon completely, you only need it while you're establishing
the iSCSI session to provide ARP and possibly DHCP functionality.

Also note that there are other networking cards that don't use this
logic. The Chelsio cards that were first supported in Linux for iSCSI
offloading don't separate the regular network interface from the
offloading part, so there you can just configure the network interface
normally and open-iscsi can directly tell the kernel driver to perform
the offloading, without any need for iscsiuio.



Hope that clarifies a bit what this package does.


I'm open to improving the package description, but I do want to keep
the work "offload" in a prominent position there, as that is the
standard technical term in this field, and people who want to use that
functionality will search for that word.

Regards,
Christian

Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Christian Seiler]

On 09/30/2017 09:10 PM, Sean Whitton wrote:
> On Sun, Oct 01 2017, Pirate Praveen wrote:
>> Packaging of rollup is stuck [1] and I can make progress with gitlab
>> package with node-d3-color in contrib. Quite a lot of work can happen
>> even with gitlab in contrib, like making sure everything is configured
>> correctly, making sure update from previous version is working, people
>> can test and report bugs while we are working on getting all
>> dependencies in main etc. If I simply wait for rollup to arrive in
>> main, I can't do any of those.
> 
> Okay, I see how this would be useful -- thanks for the explanation.
> 
> I am still very uneasy about serving our users -- even our users of
> Debian unstable -- with packages that are built using material pulled
> from the net.  I think that people who add 'contrib' to their
> sources.list do not expect this kind of thing.

Ack. Wouldn't it be preferable to just include a copy of the prebuilt
node-d3-color "binary" alongside its actual source tarball and have
debian/rules just copy the prebuilt "binary" for now? That would
fulfill one of the widely accepted use cases for contrib (needs
something currently not in Debian to build, but is otherwise free
software - see e.g. the VirtualBox BIOS requiring a non-free
compiler) much closer than downloading stuff from the network.

I think that requiring network access during build is a big no-no in
general, regardless of where the software is sorted into. For
example it fails the dissident test. And it ensures that that what's
in the Debian source package is that what you actually get in the
end, not subject to the whim of server operators outside of Debian
during build time (which may be at any point as there are binNMUs).

Regards,
Christian

Bug#876840: fseeko() on reference file: Invalid argument (Was: Bug#876840: staden-io-lib FTBFS on non-i386 32bit: FAIL: java)

[Christian Seiler]

Hi Andreas,

On 09/26/2017 10:08 PM, Andreas Tille wrote:
> I need to admit I have no idea why
> 
>fseeko() on reference file: Invalid argument
> 
> is happening on some architectures.

According to the manpage of fseek(), which is identical to fseeko()
apart from the offset data type:

ERRORS
   [...]
   EINVAL The whence argument to fseek() was not SEEK_SET,
   SEEK_END, or SEEK_CUR.  Or: the resulting file offset would
   be negative.

I suspect that something is calling fseeko() with a negative offset.

I'd recommend doing an strace on the specific test binary that
fails on a porterbox (e.g. armhf) + on amd64 for comparison and
then look for the offending fseeko() call. That might help isolate
the issue.

Regards,
Christian

debian-bugs-dist@lists.debian.org

[Christian Seiler]

On 09/26/2017 10:06 PM, Andreas Tille wrote:
>> ...
>> In file included from bgzip.c:56:0:
>> bgzip.c: In function 'gzi_index_dump':
>> ../io_lib/os.h:127:10: error: invalid operands to binary & (have 'uint64_t * 
>> {aka long long unsigned int *}' and 'long long int')
>>  (((x & 0x00ffLL) << 56) + \
>>   ^
>> ../io_lib/os.h:185:20: note: in expansion of macro 'iswap_int8'
>>  #define le_int8(x) iswap_int8((x))
>> ^~
>> bgzip.c:190:16: note: in expansion of macro 'le_int8'
>>  if (fwrite(le_int8(&n), sizeof(n), 1, idx_f) != 1)
>> ^~~

This code is completely wrong.

le_int8 appears to do a 64 bit byte order swap to adjust the
endianness of a quantity. What bgzip.c does at this point is the
following (removed if() for clarity):

uint64_t n = idx->n;
fwrite(le_int8(&n), sizeof(n), 1, idx_f);

&n is the pointer to the 'n' variable, but you really don't want
to byte swap a pointer to a local variable before passing it to
a function that reads that pointer (also note that the pointer
could be 32 bit on 32 bit systems!).

What you presumably want to do is byte swap the _contents_ of the
pointer (especially since n is a 64 bit integer). If you look at
the read code in the same file this is actually what happens:

if (8 != fread(&n, 1, 8, fp))
goto err;
n = le_int8(n);

So what you'd rather want to have is the following code:

uint64_t n = le_int8(idx->n);
fwrite(&n, sizeof(n), 1, idx_f);

Or, if I adjust the entirety of that section in the original write
code:

int i;
uint64_t n = le_int8(idx->n);
if (fwrite(&n), sizeof(n), 1, idx_f) != 1)
goto fail;
for (i=0; in; i++) {
uint64_t nn;
nn = le_int8(idx->c_off[i]);
if (fwrite(&nn, sizeof(nn), 1, idx_f) != 1)
goto fail;
nn = le_int8(idx->u_off[i]);
if (fwrite(&nn, sizeof(nn), 1, idx_f) != 1)
goto fail;
}

That should fix the compiler error you're seeing.

The only reason that doesn't fail on Little Endian is because the
le_int8(x) function is a no-op on those systems and just passes
through the original pointer.

Regards,
Christian

Bug#874845: Is there any sensible way to know what qt5 devel packages might be needed as build-depends

[Christian Seiler]

Hi Andreas,

Am 2017-09-26 17:41, schrieb Andreas Tille:

I try to port clonalframe[1] to Qt5 and I somehow wild-guessed what
Build-Depends might be needed.  Anyway I got

  qmake: could not find a Qt installation of ''

I've got this totally unhelpful message in another package - what
is a sensible approach to find the needed packages?


Since the project is using qmake as it's build system, you could
try:

find . -name "*.pro" -o -name "*.pri" -print0 | \
   xargs -0 grep -A 3 -E "QT.*="

to find all the lines of the type

QT += core gui widgets

and the such. Then you could go through those and see if there is
a "libqt5XXX5-dev" package (replace XXX with the module) available.
Some things are in qtbase5-dev directly (such as the 3 examples I
have above) though.

It could also be that some modules of Qt aren't packaged yet at
all. For example - and I may be mistaken about that - I don't
believe there's a libqt5datavisualization5-dev for that module in
Debian yet.

Regards,
Christian

Bug#865628: [Pkg-iscsi-maintainers] Bug#865628: Please add information about this incompatibility to the installation/upgrading guide

[Christian Seiler]

Control: reassign 865628 release-notes
Control: forcemerge 865632 865628

Hi,

On 09/24/2017 06:41 PM, Jurij Smakov wrote:
> I hit this issue as well after upgrading to Stretch, and I don't
> consider mentioning such a major incompatibility in the bug only to
> be appropriate. I have actually read the relevant parts of the
> upgrading guide,> 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html
> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html
> 
> but it did not mention anything about iscsitarget being deprecated,
> so the resulting service interruption came as a surprise.
> 
> At a minimum, please make sure that this deprecation information is
> added to the documentation above, to prevent others from hitting the
> same issue unexpectedly.

I had already opened a bug report against the 'release-notes'
pseudo-package to ask for this information to be included in the
release notes back in June, including a proposed wording, which
was then improved upon by someone else:

https://bugs.debian.org/865632

Unfortunately this hasn't been added to the SVN repository yet.
I'm merging this report to avoid further confusion and I'm CC'ing
the release team to bump the priority of this issue.

Regards,
Christian

Bug#853568: Nanopolish: gcc-7 issue solved, but immintrin.h missing on most architectures

[Christian Seiler]

Hi Andreas,

On 09/18/2017 01:54 PM, Andreas Tille wrote:
> Strangely enough on i386 the build fails with
> 
>/usr/bin/ld: cannot find -lhdf5
> 
> which I do not understand as well ...

You add the following to the linker flags:

-L/usr/lib/$(shell dpkg-architecture -qDEB_TARGET_GNU_TYPE)/hdf5/serial

This is wrong on i386: DEB_TARGET_GNU_TYPE expands to i686-linux-gnu,
while Debian uses i386-linux-gnu. Also, DEB_TARGET_* is definitely
wrong unless you are _building_ a cross-compiler. What you want here is
DEB_HOST_MULTIARCH - that will be correct even if you are _using_ a
cross compiler.

Also, if the package requires intrinsics, you should depend on
sse-support on i386 (but not on amd64, where SSE1 is always part of
the base ISA).

Regards,
Christian

Bug#875563: Proposed fix

[Christian Seiler]

Control: clone -1 -2
Control: severity -2 wishlist
Control: retitle -2 Properly support multi-device btrfs setups in tiny-initramfs
Control: tags -1 + confirmed pending
Control: tags -2 + confirmed

On 09/12/2017 10:54 AM, Free Ekanayaka wrote:
> I've pushed a fix-btrfs-device-discover-875563 branch to the Alioth git
> repository of tiny-initramfs, based on debian/master and with this
> single commit:
> 
> https://anonscm.debian.org/cgit/collab-maint/tiny-initramfs.git/commit/?h=fix-btrfs-device-discover-875563&id=fb124b6f73902eecddd88422e5c5ed82dd44a423

Thanks for the patch! I don't have a setup that uses both tiny-initramfs
_and_ btrfs here; I'll assume that your changes work for you. (The code
looks good upon review, and I've tested that it doesn't cause any
regressions in my test setup with ext4.)

I'll upload the fixed version in the next couple of minutes to sid.

> This solves the situation for the single-device case. I did not test the
> multi-device case, but it would probably require a bit more changes,
> this the current code in add_modules_for() assumes that there is only
> one block device to handle.

Yes, and mounting might potentially require some changes as well. I
have hence cloned the bug report to separate this specific sub-issue
out.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#870465: stretch-pu: package tiny-initramfs/0.1-3

[Christian Seiler]

On 08/06/2017 03:40 PM, Jonathan Wiltshire wrote:
> On Wed, Aug 02, 2017 at 11:41:37AM +0200, Christian Seiler wrote:
>> I'd like to perform a stable update for tiny-initramfs that fixes
>> #869668: tiny-initramfs-core was missing a dependency on cpio,
>> causing it to fail with very minimalistic systems.
>>
>> Proposed source debdiff is attached.
>>
>> I've tested the package in a clean stretch VM.
> 
> Please go ahead.

Thanks & uploaded.

Regards,
Christian

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Hi,

On 08/05/2017 02:06 PM, Michael Tokarev wrote:
> 05.08.2017 15:02, Christian Seiler wrote:
>>>> xhci-guard-xhci_kick_epctx-against-recursive-calls-CVE-2017-9375.patch
>>>
>>> What's the complete qemu command line?
>>
>> It's quite long (generated from libvirt), I posted that in the initial
>> bug report:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869807#5
>>
>>> Does it include nec-xhci?
>>
>> Yes, it does:
>>
>> -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5
>>
>> (I did configure XHCI in libvirt to be able to pass through
>> USB 3 devices.)
>>
>> And indeed, if I change that back to USB 2.0 in libvirt's configuration,
>> and install +deb9u1, the VM now boots again.
> 
> This is #869945, and the actual problem is not what you've
> posted but the xhci assertion failure.

Yeah, I just noticed that the __kvm_hv_spinlocks error also occurs if the VM
is started successfully - and is in fact only a warning message.
Unfortunately, due to the way libvirtd invokes qemu I don't see any assertion
failure in the logs (or I just don't know which log to look at).

> I'll merge this bug with #869945.

Yes, I can verify that the VM boots again with +deb9u2. (I had kept the
package on hold via apt-mark until I knew the problem was resolved.) Sorry
for providing a red herring with the CPU flag.

And many thanks for your work!

Regards,
Christian

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Hi,

On 08/05/2017 01:55 PM, Michael Tokarev wrote:
> 05.08.2017 11:48, Christian Seiler wrote:
> 
>> xhci-guard-xhci_kick_epctx-against-recursive-calls-CVE-2017-9375.patch
> 
> What's the complete qemu command line?

It's quite long (generated from libvirt), I posted that in the initial
bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869807#5

> Does it include nec-xhci?

Yes, it does:

-device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5

(I did configure XHCI in libvirt to be able to pass through
USB 3 devices.)

And indeed, if I change that back to USB 2.0 in libvirt's configuration,
and install +deb9u1, the VM now boots again.

Regards,
Christian

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Hi,

On 08/04/2017 01:56 AM, Christian Seiler wrote:
> Any ideas? My guess would be to selectively enable different
> patches in debian/patches/series and try to figure out which
> once of these actually causes the issue. (Could take me a
> while though.) Or do you have any better suggestions?

I've now built qemu 7 times, selectively enabling only one of
the patches in +deb9u1 each time. (I noticed in git that you
already noticed yourself that the 8th patch mentioned in the
changelog was not included in d/patches/series.)

I found the culprit: all variants boot my system except for
the one where this patch is enabled, which precisely produces
the symptoms described in this bug.

xhci-guard-xhci_kick_epctx-against-recursive-calls-CVE-2017-9375.patch
https://anonscm.debian.org/cgit/pkg-qemu/qemu.git/tree/debian/patches/xhci-guard-xhci_kick_epctx-against-recursive-calls-CVE-2017-9375.patch?id=73d4f3ee4989908f1fc00bc82972352d59f3c688

But looking at the patch: I really don't get it. It appears to
have nothing to do with CPU flags at all.

Any ideas? I'm not very familiar with qemu's source code, but
am quite comfortable with a debugger. If you have any idea on
how I could investigate this further...

Regards,
Christian

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Hi,

On 08/02/2017 11:58 PM, Christian Seiler wrote:
>  - first of all I'll try to upgrade qemu and then reboot
>the entire system before restarting the VM (to make sure
>it's not some caching issue you mentioned)

Rebooting after upgrading qemu doesn't change anything.

>  - recompile both 1:2.8+dfsg-6 and 1:2.8+dfsg-6+deb9u1
>in a clean Stretch build environment and see if I can
>reproduce the issue with self-built packages

I've recompiled both 1:2.8+dfsg-6 and 1:2.8+dfsg-6+deb9u1 in a
clean stretch sbuild environment (I can provide sbuild logs if
necessary) and I get the same results:

 - the version without +deb9u1 works

 - the version with +deb9u1 has precisely this bug

This is really weird. I even debdiff'd the source packages (to
see if perhaps the uploaded package didn't correspond to the
git repo, but the source package in the archive is fine) - and
I really don't understand it: nothing in the debdiff touches
any file that has to do with CPU features, as far as I can
tell...

Any ideas? My guess would be to selectively enable different
patches in debian/patches/series and try to figure out which
once of these actually causes the issue. (Could take me a
while though.) Or do you have any better suggestions?

Regards,
Christian

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Christian Seiler]

On 08/03/2017 08:58 PM, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
>> Do the MIA team also track MIA teams?
> 
>> My concern is that packages without maintainers may go unnoticed when 
>> none of its previously active maintainers were tracked individually.
> 
>> For such detection of abandonment we need not track _all_ active 
>> maintainers, but at least one - as individual.
> 
> Or track MIA teams, which in a lot of ways is a much easier problem, and
> seems like a worthwhile problem to solve anyway.
> 
> I don't feel like dropping the Uploaders field for team-maintained
> packages if the team so chooses will make MIA tracking substantially
> harder, or will make orphaned package tracking substantially harder.

I wonder whether we are framing this in the right way anyway. There
are two orthogonal questions in my mind:

 - is a specific person MIA?

 - is a package still maintained?

There is not necessarily a direct relation between both questions.
Take for example a person who someone in this thread called
"partially MIA" (I don't like that term btw.): they still actively
maintain a bunch of packages, but have dropped the ball on another
package.

On the other hand you could have a package that has
Maintainer: some team and Uploaders: some person, where "some
person" is actually MIA, but the rest of the team is still actively
maintaining the package.

The main problem I see with Uploaders: is that it's often not really
up to date. So I do think that it might be a good idea to track the
people who are responsible for a package outside of the package
itself in some kind of central database that is not tied to package
uploads. This could also make it easy to query that database. On the
other hand I would not want to maintain a team membership list for
this purpose, but track by package, because while there are small
teams where everyone is responsible for every single package, there
are also larger teams where not everyone cares about every single
package that the team maintains. So I don't think the Uploaders:
field in a package is useless, I just think the current way of
storing that information is not the best way to do so. But until
such a central database is ready for usage, I don't think it would
be wise to drop Uploaders: at the moment, because otherwise that
information can't be tracked at all.

To help with the question of whether a package is still being
actively maintained, let me frame it in this way: I think it is
not completely unreasonable to say that _most_ packages will be
updated at least once every 12 months in sid or experimental. (The
precise number is subject to bikeshedding.) Of course that's not
true for every package, there are some packages which don't require
updates that often. So what one could do is the following: a
package is considered to be actively maintained if a maintainer (or
team) upload has happened in the last 12 months. (NMUs don't count.)
If that is not the case, after 12 months an email is automatically
sent to the maintainer/uploaders to ask whether they are still
actively maintaining the package. They then have 3 months to respond
by either uploading a new version to sid or experimental, or
replying to that email that "yes, the package is still being
actively maintained, there was just no reason to update it recently".
Then there could be a clear way of determining what packages are
candidates for orphanning (while the email + reply logic should be
automatic, the orphanning should only be done after a human looks
that over). Obviously the precise amount of time can be bikeshedded,
but I do believe that the general concept is something sensible.
Becuase if one is indeed actively maintaining a package, then they
should be able to reply to an email every year or so. (Especially
if just doing "reply" + "send" is sufficient, like with mailing
list confirmations.)

Just to throw some ideas out there.

Regards,
Christian

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Hi,

Thanks for your response!

On 08/02/2017 11:42 PM, Michael Tokarev wrote:
> The thing is that there are no changes in +deb9u1 which
> can lead to anything like that, at all.

Yes, I noticed that myself, which makes it really weird.

> Unless, which is
> also a possibility, there's a bug in my build environment
> (I use regular sbuild stretch chroot for that).

Does qemu embed anything from its Build-Dependencies so that
the change was perhaps not in qemu but in something else and
+deb9u1 just happened to pick it up because it was compiled
later?

> I've no idea what can cause this, and where this 'feature'
> come from to start with - it smells like some libvirt thing,
> but I'm not sure.

Well, to be honest I was surprised to see all of these CPU
flags specified by libvirt. I would have expected it to
just have Skylake-Client as the cpu, plus potentially one 
or two flags to support the IOMMU passthrough of devices,
but not these many.

> But your environment is quite a bit unusual,

In some sense yes. But in some other sense it isn't that
weird. I set it up in the following way:

 - Stretch system (while it was still frozen but close to
   the release)
 - used virt-manager to create a new VM. Selected Windows 10
   as OS, then before installing the OS I made sure that the
   processor was not the Host CPU, but a Skylake (by selecting
   it from the CPU list provided by libvirt); I did this to
   make sure I could at a later point in time migrate the VM
   to a different system without having to reactive Windows
 - after installing the QEMU Guest Agent on the OS I changed
   the hard disks + NIC to use virtio (for performance)
 - later on after installing the aforementioned PCIe card in
   the computer itself, I just added a PCI Host Device in
   virt-manager to the VM image

That causes libvirt to run qemu with all of these options.

> Did you try to restart libvirtd to start with

If I remember correctly I did a reboot of the computer to
check that the BIOS settings were still all OK. (i.e. VT-x
and VT-d enabled) But I'm not completely sure about that.

I might not get to that before Monday, but I'll try the
following next:

 - first of all I'll try to upgrade qemu and then reboot
   the entire system before restarting the VM (to make sure
   it's not some caching issue you mentioned)

 - recompile both 1:2.8+dfsg-6 and 1:2.8+dfsg-6+deb9u1
   in a clean Stretch build environment and see if I can
   reproduce the issue with self-built packages

I'll update this bug report once I know more.

Regards,
Christian

Bug#870465: stretch-pu: package tiny-initramfs/0.1-3

[Christian Seiler]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal

Dear release team,

I'd like to perform a stable update for tiny-initramfs that fixes
#869668: tiny-initramfs-core was missing a dependency on cpio,
causing it to fail with very minimalistic systems.

Proposed source debdiff is attached.

I've tested the package in a clean stretch VM.

Regards,
Christian

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru tiny-initramfs-0.1/debian/changelog 
tiny-initramfs-0.1/debian/changelog
--- tiny-initramfs-0.1/debian/changelog 2016-11-28 00:43:01.0 +0100
+++ tiny-initramfs-0.1/debian/changelog 2017-08-02 11:24:02.0 +0200
@@ -1,3 +1,9 @@
+tiny-initramfs (0.1-4~deb9u1) stretch; urgency=medium
+
+  * Add Depends: cpio to tiny-initramfs-core. (Closes: #869668)
+
+ -- Christian Seiler   Wed, 02 Aug 2017 11:24:02 +0200
+
 tiny-initramfs (0.1-3) unstable; urgency=medium
 
   * debian/control: enable Vcs-Git/Vcs-Browser fields.
diff -Nru tiny-initramfs-0.1/debian/control tiny-initramfs-0.1/debian/control
--- tiny-initramfs-0.1/debian/control   2016-11-28 00:43:01.0 +0100
+++ tiny-initramfs-0.1/debian/control   2017-08-02 11:24:02.0 +0200
@@ -24,7 +24,7 @@
 Package: tiny-initramfs-core
 Architecture: linux-any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: cpio, ${shlibs:Depends}, ${misc:Depends}
 Built-Using: ${Built-Using}
 Description: Minimalistic initramfs implementation (core tools)
  A very minimalistic initramfs implementation for booting Linux
diff -Nru tiny-initramfs-0.1/debian/gbp.conf tiny-initramfs-0.1/debian/gbp.conf
--- tiny-initramfs-0.1/debian/gbp.conf  2016-11-28 00:43:01.0 +0100
+++ tiny-initramfs-0.1/debian/gbp.conf  2017-08-02 11:24:02.0 +0200
@@ -2,7 +2,7 @@
 pristine-tar = True
 color = auto
 upstream-branch = upstream/master
-debian-branch = debian/master
+debian-branch = debian/stretch
 
 [git-import-orig]
 dch = True

Bug#869807: qemu: [regression] unknown CPU feature __kvm_hv_spinlocks after upgrade to +deb9u1

[Christian Seiler]

Package: qemu-system-x86
Version: 1:2.8+dfsg-6+deb9u1
Severity: important
X-Debbugs-Cc: secur...@debian.org

Dear maintainers, dear security team,

after performing the security upgrade to 1:2.8+dfsg-6+deb9u1 a virtual
machine (managed via libvirt) does not start anymore.

Underlying CPU is an Intel Kaby Lake Core i7-7700. VT-x and VT-d are
enabled in the BIOS. Kernel cmdline has intel_iommu=on. Latest
microcode update is installed.

KVM configuration: Machine of guest is set to pc-i440fx-2.8, CPU is set
to Skylake-Client. A PCIe framegrabber card (in x16 slot, but card is
x4 or x8, I don't remember exactly) is passed through to the guest.

With 1:2.8+dfsg-6 the guest boots just fine.

With 1:2.8+dfsg-6+deb9u1 the guest doesn't start properly. In the
journal I can find the following message every time I try to start the
guest:

libvirtd[964]: ...: 984: error : x86FeatureInData:780 : internal error: 
unknown CPU feature __kvm_hv_spinlocks
libvirtd[964]: ...: 964: error : qemuMonitorIO:695 : internal error: End 
of file from qemu monitor


To get this working again I downgraded qemu-kvm, qemu-system-common
and qemu-system-x86 back to 1:2.8+dfsg-6.

The full command that is used to start qemu by libvirt is the
following (UUIDs and MAC addresses censored):

qemu-system-x86_64
-enable-kvm
-name guest=win10,debug-threads=on
-S
-object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-win10/master-key.aes

-machine pc-i440fx-2.8,accel=kvm,usb=off,vmport=off,dump-guest-core=off
-cpu 
Skylake-Client,+ds,+acpi,+ss,+ht,+tm,+pbe,+dtes64,+monitor,+ds_cpl,+vmx,+smx,+est,+tm2,+xtpr,+pdcm,+osxsave,+tsc_adjust,+clflushopt,+pdpe1gb,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff

-m 16384
-realtime mlock=off
-smp 4,sockets=4,cores=1,threads=1
-uuid 
-no-user-config
-nodefaults
-chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-win10/monitor.sock,server,nowait

-mon chardev=charmonitor,id=monitor,mode=control
-rtc base=localtime,driftfix=slew
-global kvm-pit.lost_tick_policy=delay
-no-hpet
-no-shutdown
-global PIIX4_PM.disable_s3=1
-global PIIX4_PM.disable_s4=1
-boot strict=on
-device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6
-drive 
file=/var/lib/libvirt/images/win10.qcow2,format=qcow2,if=none,id=drive-virtio-disk0
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive 
file=/var/lib/libvirt/images/win10_data.qcow2,format=qcow2,if=none,id=drive-virtio-disk1
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1

-drive if=none,id=drive-ide0-0-1,readonly=on
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1
-netdev tap,fd=25,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=...,bus=pci.0,addr=0x3
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0

-device usb-tablet,id=input0,bus=usb.0,port=1
-spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2

-device intel-hda,id=sound0,bus=pci.0,addr=0x4
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0
-chardev spicevmc,id=charredir0,name=usbredir
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2
-chardev spicevmc,id=charredir1,name=usbredir
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3
-device vfio-pci,host=02:00.0,id=hostdev0,bus=pci.0,addr=0xa
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
-msg timestamp=on

I did take a look at the patches in the git repository:

https://anonscm.debian.org/cgit/pkg-qemu/qemu.git/log/?id=refs/heads/debian-stretch

But I'm very confused because none of these patches actually touch the
CPU flags or any other part of virtualization.

Regards,
Christian

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20161027.b991c67-1
ii  libaio1 0.3.110-3
ii  libasound2  1.1.3-5
ii  libbluetooth3   5.43-2
ii  libbrlapi0.65.4-7
ii  libc6   2.24-11+deb9u1
ii  libcacard0  1:2.5.0-3
ii  libfdt1 1.4.2-1
ii  libgcc1 1:6.3.0-18
ii  libglib2.0-02.50.3-2
ii  libgnutls30 3.5.8-5+deb9u2
ii  libjpeg62-turbo 1:1.5.1-2
ii  libncursesw56.0+20161126-1
ii  libnettle6  3.3-1+b1
ii  libnuma1   

Bug#869668: AW: Bug#869668: tiny-initramfs-core: Missing dependency on cpio

[Christian Seiler]

Am 2017-07-26 09:55, schrieb Tobias Doerffel:

May I ask what you changed? Because if it's something that could
 be interesting to other users this might be added to the package
in general. Also, as I'm upstream for it, I'm always a bit curios what
use cases people have for the package.


The use case for us is to implement a (read-only) live system boot for
an embedded system. For this to work we need to mount a tmpfs, mount a
vfat partition which contains the rootfs as squashfs image, mount the
squashfs image and merge it with the tmpfs via overlayfs into the
final root - nothing the kernel is able to do OOTB. The required
changes to tiny-initramfs are very specific (filenames, paths etc.)
thus likely not suitable for upstream.


But the general principle does sound like a use case that other
people might also have. As I said in the upstream README: especially
for embedded applications I'd be interested in adding support for
things people do in that field.

So to recap in a more generic sense, you'd need (from the top of my
head):

 - support pre-mounting arbitrary things an arbitrary amount of
   times (1. mount vfat, 2. mount squashfs, 3. mount tmpfs)
 - loopback support for mounting the squashfs image

I think this could easily be implemented generically (without
using too much space) in the following manner:

 - initramfs CPIO archive must contain directories where the
   stuff is mounted to

 - parse an option tirfs.premount=what:/where:type:options (name
   subject to bikeshedding) from the kernel command line

Then you could do the following:

 - add /vfat /squashfs /tmpfs /tmpfs.work to the initramfs CPIO
   archive

 - pass the following additional command line options to the
   kernel:

 tirfs.premount=/dev/somedevice:/vfat:vfat
 tirfs.premount=/vfat/squashfs.image:/squashfs:squashfs:loop
 tirfs.premount=none:/tmpfs:tmpfs:size=...
 tirfs.premount=none:/tmpfs.work:tmpfs:size=...
 root=overlay rootfstype=overlay
 rootflags=lowerdir=/squashfs,upperdir=/tmpfs,workdir=/tmpfs.work

And then it should just work.[tm]

(I wrote this down off the top of my head, there are likely some
details that aren't right there.)

If I added this kind of generic support to tiny-initramfs, would
that be useful to you?


We used initramfs-tools with a
custom local script before but this generated a 2 MB initrd whereas
the size with tiny-initramfs is just 10 KB :-)


:-)

Regards,
Christian

Bug#869668: tiny-initramfs-core: Missing dependency on cpio

[Christian Seiler]

Control: tags -1 + stretch

Yes, I'll do that. Since you're reporting this from Stretch: are you 
using this package on Stretch systems?
If so, I'd also ask the release team if they'd consider a stable 
update of the package for the next point release of Stretch (9.2).


Yes we use Stretch here even though we use our own customized version
of tiny-initramfs.


May I ask what you changed? Because if it's something that could be
interesting to other users this might be added to the package in
general. Also, as I'm upstream for it, I'm always a bit curios what
use cases people have for the package.


However the invalid initrd could render systems unusable for other
users so it's definitely worth a stable update.


Ok, thanks for the feedback, will take care of that.

Regards,
Christian

Bug#869668: tiny-initramfs-core: Missing dependency on cpio

[Christian Seiler]

Control: severity -1 serious
Control: tags -1 + confirmed buster sid

Hi,

Am 2017-07-25 15:49, schrieb Tobias Doerffel:
when using mktirfs from the tiny-initramfs-core package within a 
minimal

environment it fails due to cpio being missing:

/usr/sbin/mktirfs: 219: /usr/sbin/mktirfs: cpio: not found


Oh, I was under the mistaken assumption that cpio was an essential
package - but I just checked and indeed, it is not, it's "just"
Priority: important. I must confess that I've never tested
tiny-initramfs on _that_ minimal of an environment. I'm upgrading the
bug severity to 'serious' as a missing dependency clearly violates
Debian policy.


Please add cpio as dependency similar
to initramfs-tools-core.


Yes, I'll do that. Since you're reporting this from Stretch: are you
using this package on Stretch systems? If so, I'd also ask the release
team if they'd consider a stable update of the package for the next
point release of Stretch (9.2).

Regards,
Christian

Bug#868378: RFS: nlohmann-json/2.1.1-1

[Christian Seiler]

Hi Muri,

On 07/16/2017 10:05 PM, Muri Nicanor wrote:
> On 07/16/2017 08:47 AM, Christian Seiler wrote:
>> This will likely break builds of reverse dependencies because they
>> might not find the header anymore. Did you test all of the reverse
>> dependencies of nlohmann-json in the archive that they'll find the
>> header in the new location? If some of them don't, you should file
>> bugs against those packages (ideally with patches) that the
>> maintainers know about this change. [1]
> There are two reverse dependencies atm, usbguard and mkvtoolnix. I've
> removed the build-dependency from usbguard, because it was not needed
> anymore and i've filed bug #868573 against mkvtoolnix and attached a patch.
> 
> Not sure if that qualifies as a library transition if its only one
> package, especially as mkvtoolnix doesn't FTBFS with the new
> nlohmann-json package (because it ships its own copy os the json.hpp
> file which it falls back to if the system one is not found...)

Since mkvtoolnix doesn't immediately FTBFS with the new library
package of yours and it really is just the one package, then yes,
I would agree that you probably don't need a transition slot for
just that.

Thanks for being so quick about filing the bug against the rdep!

Apart from that: even though I can't sponsor, I did a quick
review of the packaging (I did NOT check the upstream changes to
the version already in the archive); the package looks to be in
a very good shape in general. Some minor nitpicks that you might
want to fix (although those are really minor, they can wait for
a newer version):

 - (found by check-all-the-things [1]) you use "MIT" as the
   abbreviation, instead of the recommended "Expat" for that
   license

 - the package is still on debhelper compat 9 (10 is current,
   but see the debhelper docs for information on what defaults
   changed between those versions before changing d/compat)

Otherwise: it builds fine in sbuild, is lintian clean, hardening
is enabled, the packaging looks sane.

(While looking at the build log I did stumble upon another
issue, but that's in debhelper's CMake integration not keeping
up with semi-recent CMake features. I've reported that issue
in #868584, in case you're interested.)

Anyway, hope my review helps you in getting the package
sponsored sooner.

Regards,
Christian

[1] This takes a _long_ time with this package as you have huge
test data in JSON form within the package, and if you do
run it, redirect its output into a file, otherwise your
terminal will be swamped with messages.
(Also note that check-all-the-things has some false
positives in your case, e.g. it checks for correct JSON as
one of its checks, and your package has some intentionally
broken JSON as unit tests.)

Bug#868584: debhelper: please disable user package registry for CMake builds

[Christian Seiler]

Package: debhelper
Version: 10.2.5
Severity: important
Control: affects -1 cmake
X-Debbugs-Cc: pkg-cmake-t...@lists.alioth.debian.org

Dear debhelper Maintainers,
(Cc'ing CMake packaging list as this affects them)

I just stubmled upon a feature added to CMake 3.x that allows packages
to register in a "package registry" via the export() CMake command.
This causes CMake to write into the home dirctory of a user. I believe
this is not desireable when building Debian packages - the registry in
the home directory should be ignored. When looking for packages only
the system registry should be queried (but that does need to happen,
otherwise builds may break), and the export() command should be
disabled completely.

Documentation for this:

https://cmake.org/cmake/help/v3.9/manual/cmake-packages.7.html#package-registry
https://cmake.org/cmake/help/v3.0/command/export.html
https://cmake.org/cmake/help/v3.9/manual/cmake-packages.7.html#disabling-the-package-registry
https://cmake.org/Bug/view.php?id=14849

It should be sufficient to pass

  -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
  -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON

to the CMake invocation. (Though I haven't gotten around to testing
this yet, hence no patch attached here so far.)

If you look for packages that use CMake as their build system _and_
have export(PACKAGE in any CMakeLists.txt file [1], then you will find
that the current build logs already show a warning message that the
non-existent home directory of the buildd user on the autobuilders
couldn't be written to. Some examples of this:

https://buildd.debian.org/status/fetch.php?pkg=mapserver&arch=arm64&ver=7.0.6-2&stamp=1498513871&raw=0
https://buildd.debian.org/status/fetch.php?pkg=avogadro&arch=amd64&ver=1.2.0-2&stamp=1499360655&raw=0
https://buildd.debian.org/status/fetch.php?pkg=freerdp2&arch=amd64&ver=2.0.0%7Egit20161130.1.e60d0d5%2Bdfsg1-1&stamp=1482840273&raw=0
https://buildd.debian.org/status/fetch.php?pkg=armadillo&arch=arm64&ver=1%3A7.950.1%2Bdfsg-1&stamp=1497978266&raw=0
https://buildd.debian.org/status/fetch.php?pkg=octomap&arch=arm64&ver=1.8.1%2Bdfsg-1&stamp=1485272067&raw=0
https://buildd.debian.org/status/fetch.php?pkg=yaml-cpp&arch=arm64&ver=0.5.2-4&stamp=1476324483&raw=0
https://buildd.debian.org/status/fetch.php?pkg=orocos-kdl&arch=arm64&ver=1.3.1%2Bdfsg-1&stamp=1468048292&raw=0
https://buildd.debian.org/status/fetch.php?pkg=libwebsockets&arch=arm64&ver=2.0.3-2&stamp=1478209995&raw=0
https://buildd.debian.org/status/fetch.php?pkg=vtk-dicom&arch=arm64&ver=0.7.10-1%2Bb2&stamp=1487960322&raw=0
https://buildd.debian.org/status/fetch.php?pkg=gli&arch=all&ver=0.8.2.0%2Bds1-2&stamp=1484226906&raw=0
https://buildd.debian.org/status/fetch.php?pkg=diskscan&arch=arm64&ver=0.19-4&stamp=1484043493&raw=0

(Look for "Cannot create package registry file:" in the log.)

Additionally, _all_ packages that use CMake and call find_package()
(the vast majority of CMake-using packages) will be affected if a user
has entries in their local user registry that have the same name as
system packages.

Regards,
Christian

PS: I'm unsure about the severity of this bug. I believe this should
qualify as RC (policy violation: writing to home directories), but
I've left it at "important" for now.

[1] Codesearch expression:

  path:.*/CMakeLists.txt export\(PACKAGE

Note that there are false positives if you use that expression, as
sometimes unused bundled libraries are shown, and sometimes the package
is built within Debian with a different build system (e.g. autotools)
instead of CMake. (If the package supports multiple build systems.)

-- System Information:
Debian Release: 9.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.24
ii  dpkg-dev 1.18.24
ii  file 1:5.30-1
ii  libdpkg-perl 1.18.24
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information

Bug#868378: RFS: nlohmann-json/2.1.1-1

[Christian Seiler]

Hi there,

(not a DD, can't sponsor, but a quick comment:)

On 07/15/2017 12:05 PM, Muri Nicanor wrote:
>   * Switched build system to cmake, library is now installed in
> /usr/include/nlohmann, which is upstream default (Closes: #868112)

This will likely break builds of reverse dependencies because they
might not find the header anymore. Did you test all of the reverse
dependencies of nlohmann-json in the archive that they'll find the
header in the new location? If some of them don't, you should file
bugs against those packages (ideally with patches) that the
maintainers know about this change. [1]

Also, if the current packages can't auto-detect the new location
(i.e. they start to FTBFS with your new package), then this is
technically a library transition, so you should follow the
guidelines for those:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Regards,
Christian

[1] List of reverse depends (since this is a header-only library):
grep-dctrl -s Package -F Build-Depends,Build-Depends-Indep \
nlohmann-json-dev /var/lib/apt/lists/*Sources
(You need sid in your sources.list and a recent apt-get update
to ensure this is up to date.)

Bug#868450: Make usage of fstab-decode optional

[Christian Seiler]

Hi Michael,

On 07/15/2017 11:10 PM, Michael Biebl wrote:
> thanks a lot for your detailed reply!
> 
> I've CCed the pkg-systemd-maintainers m-l and Wouter, as the maintainer
> of nbd.
> 
> You raise some good points. Maybe this is something you could bring up
> on the upstream mailing list?

I assume you mean the upstream systemd mailing list?

Ok, I'll do that in the next couple of days once I find some time
to write this up better from a more generic perspective. (Because
I think this could also be useful in other cases.)

Regards,
Christian

Bug#868450: Make usage of fstab-decode optional

[Christian Seiler]

Control: tags -1 + moreinfo

Hi Michael,

On 07/15/2017 03:36 PM, Michael Biebl wrote:
> I'm currently investigating whether it would be possible to make
> fstab-decode non-essential and move it out of sysvinit-utils into the
> initscripts package where it is used by /etc/init.d/umountfs and
> /etc/init.d/umountnfs.sh.
> 
> According to codesearch.d.n, open-iscsi is the only other package which
> makes use of fstab-decode.

Which probably means there are a few packages out there that are broken
in corner cases. ;-)

fstab-decode makes sure that arguments passed to commands in scripts
are properly decoded according to the fstab encoding rules.

If you look at open-iscsi, it only uses fstab-decode in the script
umountiscsi.sh that is run on shutdown. Usages:

fstab-decode mountpoint -q "$path"
fstab-decode umount "$path"

So if you have a space in your mountpoint (which appears as \040 in
/proc/self/mountinfo and /etc/fstab) not using fstab-decode will make
this fail.

> Please consider dropping this dependency on fstab-decode or making it
> optional.

While I don't think spaces are all that nice in path names, we do
currently support them, and I really don't want to drop that support
later on. So I don't really see how to get rid of that dependency
easily (without reimplementing it, which I don't think is a useful
use of my time) without potentially breaking people's existing
systems.

That all said:

1. I wouldn't be pleased with it, but I wouldn't mind depending on
   'initiscripts' in open-iscsi, if you do decide to move the binary.

   This is not great, as open-iscsi provides native systemd services
   (since Stretch), so I wouldn't be too happy about it depending on
   initscripts on systemd systems, but I don't have a huge dog in that
   fight.

2. More importantly, I consider umountiscsi.sh to be a hack. A
   necessary one, because there's no alternative at the moment, but a
   hack nonetheless.

In the long term I'd really, really like to not have to use
umountiscsi.sh on systemd systems - because it's a huge layering
violation.

I really think this is something that systemd should provide
natively. To explain the background of the script:

At boot we log in to iSCSI targets after networking has been set up.
This causes the kernel to make new block devices (e.g. /dev/sdb)
available in the system. Then, if LVM is used, lvmetad will pick up LVM
volumes on these devices and new LV devices (/dev/VG/LV) will then
appear. Once block devices required for /etc/fstab entries have
appeared, systemd will mount those block devices and make the
filesystems available.

On shutdown we need to umount all of that stuff. Now for things in
/etc/fstab systemd will do that for us (and we do order properly
against remote-fs-pre.target) - but that still leaves two problems
with that:

  a) systemd usually doesn't recognize manually mounted iSCSI
 filesystems as network filesystems unless the administrator
 explicitly specifies -o _netdev for the mount command (which
 nobody actually does), so anything not in /etc/fstab manually
 mounted by the administrator will not be unmounted at the right
 time by systemd. (The reason is that iSCSI devices look like
 normal block devices, so you can use e.g. ext4 or btrfs on top of
 them.)

  b) If one uses LVM, for example, the LVM volumes do not get properly
 shutdown. Same goes for LUKS, dm-raid, multipath, and any other
 block device layering you can think of.

That's why we still run that script: to make sure that the underlying
iSCSI block devices are not used anymore at all when we issue the
logout command. Furthermore I had started to implement a mechanism
to not logout from iSCSI if something failed to dismantle properly,
but that still lacks integration into e.g. ifupdown to actually work
properly. (The "don't logout if we couldn't dismantle everything" part
already works, but ifupdown will still kill the networking.)


What I would really like to see here in the long run is the following:


 - There's some way for open-iscsi to tell systemd that block devices
   that come from iSCSI are dependent on the 'open-iscsi.service'
   unit.

 - There's some way for LVM, LUKS, etc. to tell systemd how each
   logical device they generate actually relates to other devices on
   the system (e.g. the LUKS volume depends on the underlying block
   device, the LVM LVs depend on their corresponding PVs, etc.).

 - There's some way for LVM, LUKS, etc. to tell systemd how to
   dismantle a specific device.

 - On shutdown systemd then will properly order all mounts and
   storage dismantling operations according to this dependency logic.

 - We don't need to run umountiscsi.sh on systemd systems anymore,
   but can rely on systemd itself to properly provide that, so
   open-iscsi.service just does the logout from iSCSI volumes.

 - Ideally some kind of error logic that can tell systemd "yeah,
   something didn't shut down properly, so keep iSCSI logins ac

Bug#865057: stretch-pu: package open-iscsi/2.0.874-2

[Christian Seiler]

Hi,

On 06/27/2017 04:51 AM, Cyril Brulebois wrote:
> Control: tag -1 confirmed
> 
> Cyril Brulebois  (2017-06-20):
>> Cyril Brulebois  (2017-06-19):
>>> After a quick review, that looks good to me. Thanks for keeping the
>>> changes minimal in unstable, which indeed can help test this further.
>>>
>>> Also thanks for keeping track of this without my chasing you with my 9.1
>>> todo list. ;)
>>>
>>> I'll report back once I've tested this change from unstable, just to be
>>> sure; release team: please wait a bit before letting this go through pu.
>>
>> Release team: looks good to me.
> 
> Grabbing my release assistant hat: looks good to me, feel free to upload.

Thanks, uploaded and accepted into the policy queue. Sorry for the delay.

Regards,
Christian

Bug#866213: open-iscsi: iBFT network setup does not populate PROTO (e.g. PROTO=dhcp, or static) in /run/net-*.conf

[Christian Seiler]

Control: tags -1 + confirmed
Control: severity -1 important
Control: found -1 open-iscsi/2.0.874-2

Thanks for your detailed bug report!

Am 2017-06-28 13:35, schrieb Trent Lloyd:

When booting with iBFT, the network configuration is performed by
open-iscsi as part of initramfs.local-top instead of by klibc-ipconfig
as it would be during for example a PXE boot.  This includes populating
/run/net-*.conf which is consumed among other things, by cloud-init.

Currently no attempt to determine PROTO is made, and PROTO=none is hard
coded into the file which cloud-init does not recognise and crashes 
out.


Ouch, that's really bad. I've tested iBFT booting, but just in a simple
manually set up libvirt/KVM VM - never with any cloud images. To be
honest, I didn't even know /run/net-*.conf was actually used by any
package after the initramfs, I just thought it was a convenience file
for the administrator to use with their own scripts.


The approach I took is simply to take the output from iscsistart (which
as best I can tell will be either 'dhcp' or 'static' and then pipe it
through 'tr' to lowercase it to match the output created by
klibc-ipconfig.


iscsistart -f will always print either "DHCP" or "STATIC" here at the
moment:
http://sources.debian.net/src/open-iscsi/2.0.874-3/utils/fwparam_ibft/fw_entry.c/?hl=233#L211-L215

I like your 'tr' solution, but currently open-iscsi only Recommends:
busybox, which is where 'tr' in the initramfs comes from, it doesn't
Depends: on it. I'll have to test whether busybox is required or not,
but I don't believe so. I'd therefore rather not enforce that type of
dependency, but rather do an additional case statement inside to map
this.

I'm raising the severity of this bug to 'important', as it's really
bad if cloud-init breaks because of this.


This requires a new-ish (last couple years) version of open-iscsi but
that is already in debian unstable [would only matter if someone
attempted to backport this functionality, probably irrelevant for this
bug]


Well, I do plan on asking the release team to update Stretch,
because I do want to support cloud images - which won't be a problem,
as Stretch and unstable are practically identical at the moment. But
first I'll upload a fix for this issue to unstable later today.

Regards,
Christian

Bug#865632: release-notes: document that 'iscsitarget' was dropped in Stretch

[Christian Seiler]

Hi,

On 06/23/2017 04:30 PM, Justin B Rye wrote:
> Just nitpicking the phrasing and adding markup.

Many thanks! Your version is definitely better. :-)

Regards,
Christian

Bug#865632: release-notes: document that 'iscsitarget' was dropped in Stretch

[Christian Seiler]

Package: release-notes
Severity: important
X-Debbugs-Cc: debian-rele...@lists.debian.org

Dear release team & release notes editors,

I recently received a bug report from a person using the 'iscsitarget',
which was dropped in Stretch, as it hasn't seen any update upstream
since 2014 - and the kernel module doesn't compile anymore with recent
kernels.

See: https://bugs.debian.org/865628

The alternative in Stretch is to use the LIO stack to configure a
software iSCSI target, but there is no automated upgrade path (it's a
completely different piece of software, unrelated to IET), and the
configuration is different.

Unfortunately the release notes don't mention this - so if at all
possible, I would propose to add a section to the release notes of
Stretch that document this.

I propose the following language (feel free to adjust this in any way
you'd want to):

   iSCSI Enterprise Target (IET) no longer part of Stretch

   The iSCSI Enterprise Target (IET), packaged in the 'iscsitarget'
   package in previous Debbian versions, is not part of Debian
   Stretch anymore, as it will not work with recent kernel versions,
   and the project has seen no development activity in recent years.

   Users of IET are encouraged to switch to the LIO stack that is
   fully supported in Debian Stretch. The 'targetcli-fb' provides
   the configuration utility for the LIO iSCSI target.

   As the LIO stack was developed independently of the IET, the
   configuration has to be migrated manually.

Regards,
Christian

-- System Information:
Debian Release: 9.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#865057: stretch-pu: package open-iscsi/2.0.874-2

[Christian Seiler]

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

Dear release team,
(Cc'd KiBi & debian-boot as this is about the installer.)

as discussed before the release, I'd like to fix the spurious call
to update-initramfs in open-iscsi's udeb. I've tested the updated
udeb with the Stretch installer (wget && udpkg -i before the end
of the installation) and it works in the following two
constellations:

 - installing in a VM without iSCSI will now _not_ call
   update-initramfs spuriously at the end of the installation

 - installing in a VM with iSCSI will still call update-initramfs
   at the end of the installation to ensure that things will
   still boot if iSCSI is used

I've just uploaded the same fix (and just the fix) to unstable,
so if you want to do some additional tests with the installer in
sid before accepting this, that'll be possible. (I don't plan on
uploading a new open-iscsi package to sid until this pu gets
accepted unless a critical bug is found.)

Source debdiff against Stretch is attached.

Regards,
Christian

-- System Information:
Debian Release: 9.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru open-iscsi-2.0.874/debian/changelog 
open-iscsi-2.0.874/debian/changelog
--- open-iscsi-2.0.874/debian/changelog 2017-01-25 13:12:44.0 +0100
+++ open-iscsi-2.0.874/debian/changelog 2017-06-18 23:06:16.0 +0200
@@ -1,3 +1,10 @@
+open-iscsi (2.0.874-3~deb9u1) stretch; urgency=medium
+
+  * [8de3092] udeb: don't update initramfs when iSCSI is not used.
+(Closes: #863435)
+
+ -- Christian Seiler   Sun, 18 Jun 2017 23:06:16 +0200
+
 open-iscsi (2.0.874-2) unstable; urgency=medium
 
   [ Christian Seiler ]
diff -Nru open-iscsi-2.0.874/debian/gbp.conf open-iscsi-2.0.874/debian/gbp.conf
--- open-iscsi-2.0.874/debian/gbp.conf  2017-01-25 13:12:44.0 +0100
+++ open-iscsi-2.0.874/debian/gbp.conf  2017-06-18 23:06:16.0 +0200
@@ -1,6 +1,7 @@
 [DEFAULT]
 pristine-tar = True
 color = auto
+debian-branch = stretch
 
 [import-orig]
 dch = True
diff -Nru open-iscsi-2.0.874/debian/open-iscsi-udeb.finish-install 
open-iscsi-2.0.874/debian/open-iscsi-udeb.finish-install
--- open-iscsi-2.0.874/debian/open-iscsi-udeb.finish-install2017-01-25 
13:12:44.0 +0100
+++ open-iscsi-2.0.874/debian/open-iscsi-udeb.finish-install2017-06-18 
23:06:16.0 +0200
@@ -4,6 +4,11 @@
 
 got_iscsi=
 for f in /etc/iscsi/*; do
+   # Ignore iscsid.conf, as that will always be present, even if
+   # iSCSI is not used. (See Debian bug #863435.)
+   if [ x"$f" = x"/etc/iscsi/iscsid.conf" ] ; then
+   continue
+   fi
[ -e "$f" ] || continue
got_iscsi=1
break

Bug#863309: curvedns RFS

[Christian Seiler]

Hi,

Am 17. Juni 2017 12:51:17 MESZ schrieb Gianfranco Costamagna 
:
>I think it might be worth to ask on debian-mentors mail list why PIE
>flag is not
>injected anymore by debhelper...


It's not because -fPIE is the default for GCC from Stretch onwards.  This is a 
false positive from BLHC. See also:

https://bugs.debian.org/845339

Regards,
Christian

Bug#863435: open-iscsi-udeb: finish-install script always thinks that iSCSI is used

[Christian Seiler]

Package: open-iscsi-udeb
Version: 2.0.874-2
Severity: important
Affects: debian-installer
X-Debbugs-Cc: debian-b...@lists.debian.org, k...@debian.org
Control: tags -1 + stretch sid

Dear Maintainer,

As reported on debian-release@/debian-boot@ recently, a
recent change in how the initiator name was generated in
the package causes finish-install to assume iSCSI is
always used.

This has two consequences:

 - update-initramfs -k all -u is needlessly called on
   all Debian installations, even those without iSCSI
   (looses a couple of seconds time, on _really_ slow
   systems possibly even a minute)

 - clutters every new installation with
   /etc/iscsi/initiatorname.iscsi, even those that don't
   use iSCSI

This is harmless (nothing breaks), but can be annoying.
Also, for Buster this risks that other installer components
start relying on the fact that the initramfs is regenerated
late in the installation process - which they shouldn't.
It probably hasn't affected anything in Stretch yet, but
this should be fixed really early in the Buster cycle to
avoid any such problems.

KiBi said that for Stretch this should be fixed in the
first point release, so the plan is to open a p-u bug
once this is fixed in sid after the Stretch release.

Regards,
Christian

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 
'experimental-debug')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-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
Init: systemd (via /run/systemd/system)

Bug#863108: RFS: minecraft-installer/0.1-1 [ITP] -- Unofficial way to easily install game

[Christian Seiler]

On 05/22/2017 02:14 PM, Carlos Donizete Froes wrote:
> This package contains "contrib/games" in 'd/control'.

Hmmm, then mentors doesn't show that, because it just says
"Section: games" on that page. Well, I just noticed it does show it,
but only in the URL to the dsc file that I overlooked when I saw
this message.

Sorry for the noise. :-(

Regards,
Christian

Bug#863108: RFS: minecraft-installer/0.1-1 [ITP] -- Unofficial way to easily install game

[Christian Seiler]

Hi,

(Resending, got the address for debian-mentors wrong. Sorry for the noise.)

Can't sponsor myself and didn't look at it in detail, but a quick comment:


Am 21. Mai 2017 22:49:54 MESZ schrieb Carlos Donizete Froes 
:
>  https://mentors.debian.net/package/minecraft-installer

The package itself is free software (I presume), but it is for downloading a 
non-free game. For this reason it should be in contrib, not main. You should 
hence change the section from 'games' to 'contrib/games'.

Regards,
Christian

Bug#863108: RFS: minecraft-installer/0.1-1 [ITP] -- Unofficial way to easily install game

[Christian Seiler]

Hi,

Can't sponsor myself and didn't look at it in detail, but a quick comment:


Am 21. Mai 2017 22:49:54 MESZ schrieb Carlos Donizete Froes 
:
>  https://mentors.debian.net/package/minecraft-installer

The package itself is free software (I presume), but it is for downloading a 
non-free game. For this reason it should be in contrib, not main. You should 
hence change the section from 'games' to 'contrib/games'.

Regards,
Christian

Bug#861754: libpll: FTBFS on non-x86: x86intrin.h: No such file or directory

[Christian Seiler]

Hi,

a small comment on the patch:

On 05/16/2017 01:28 PM, James Cowgill wrote:
>  override_dh_auto_configure:
> - ./autogen.sh
> -ifeq ($(DEB_BUILD_ARCH),i386)
> - ./autogen.sh --disable-avx --disable-sse
> - dh_auto_configure -- --disable-avx --disable-sse
> +ifneq ($(filter $(DEB_HOST_ARCH_CPU), amd64 i386),)
> + dh_auto_configure
>  else
> - ./autogen.sh --disable-avx
> - dh_auto_configure -- --disable-avx
> + dh_auto_configure -- --disable-sse --disable-avx --disable-avx2
>  endif

At first glance this appears to be wrong, as SSE2 is part of the
amd64 base ISA. However, --disable-sse actually disables SSE3
(not part of amd64 base ISA), so it's not actually wrong - you'd
probably want to add a comment to d/rules that indicates that
--disable-sse is for SSE3 though.

Also, you should add x32 to the list of archs next to amd64 and
i386 where SSE3 and higher should be disabled.

Regards,
Christian

Bug#861639: ITP: node-elliptic -- fast elliptic curve cryptography in pure javascript

[Christian Seiler]

On 05/02/2017 10:13 PM, Bastien ROUCARIES wrote:
> On Tue, May 2, 2017 at 8:44 PM, Chris Lamb  wrote:
>> Christian Seiler wrote:
>>
>>> As with the other pure JS crypto package ITP here recently [1]: has
>>> this library been designed with timing attacks in mind?
>>
>> JFTR I filed #860939 to track (and prevent a testing migration of) the
>> parallel issue in node-diffie-hellman.
> 
> I will prefer this king of aproach let package the stuff and do not
> try to diverge from upstream.
> 
> Fill RC bug and try to solve this before next debian version

Sure. When I voiced my concerns I wasn't trying to hinder anyone's
progress, I just wanted to make sure that people are aware of
these concerns. If my responses to the ITPs came across differently,
I apologize.

Regards,
Christian

Bug#861639: ITP: node-elliptic -- fast elliptic curve cryptography in pure javascript

[Christian Seiler]

Hi there,

On 05/02/2017 07:49 AM, Pirate Praveen wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pirate Praveen 
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-elliptic
>   Version : 6.4.0
>   Upstream Author : Fedor Indutny 
> * URL : https://github.com/indutny/elliptic
> * License : Expat
>   Programming Lang: JavaScript
>   Description : faster elliptic curve cryptography in pure javascript
> 
>  Fast elliptic-curve cryptography in a plain javascript implementation.
>  Incentive for Elliptic: ECC (another library with comparable features) is
>  much slower than regular RSA cryptography, the JS implementations are even
>  more slower.

As with the other pure JS crypto package ITP here recently [1]: has
this library been designed with timing attacks in mind? In contrast
to the first example, where upstream says that it's so slow that
nobody is probably going to use it in real life anyway [2], this
library claims to be quite fast - in which case the chance of the
library being used in actual real-life applications is higher. And
it uses the same bignum library that the other package is also
using, which doesn't appear to have been designed with timing
considerations in mind. (Which is fine for a bignum library not
intended for crypto purposes.)

As with the previous package, the README of the project and the
other documentation does not discuss timing attacks at all, which
doesn't give me confidence that the author of the library has
thought about these issues.

A couple of pointers:

 - For curves that are not Edwards curves there is a very trivial
   timing attack, which is really hard to mitigate, where it is
   trivially possible to extract the private key through a side
   channel near-instantaneously.

   The library supports all sorts of types of curves, and while I
   haven't tested it, I'd be extremely surprised if it wasn't
   susceptible to this type of attack for non-Edwards curves.

 - For curves that are Edwards curves, the trivial timing attacks
   described above are mitigated. However, I don't have any
   confidence (especially since this is pure Javascript, where
   I imagine mitigating this to be extremely difficult) that the
   code doesn't contain any other side channels. Again, I didn't
   test that, but there is no documentation even mentioning side
   channels, and no comment in the code either. (If you grep
   through e.g. OpenSSL's source code, you'll see lots of
   comments discussing side channels and timing attacks. And even
   OpenSSL has advisories on side channel attacks every now and
   then, because someone comes up with something very clever that
   they didn't think of. [3])

I understand you're probably packaging this because it's a
dependency of something else, but I'm seriously concerned about
any package that uses this library for real-world applications
other than generating key pairs.

Regards,
Christian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860771#10
[2] 
https://github.com/crypto-browserify/diffie-hellman/issues/22#issuecomment-296645560
[3] Look at CVE-2013-4576 to see how creative these side channel
attacks can become.

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Christian Seiler]

On 04/20/2017 11:09 AM, Bastien ROUCARIES wrote:
> I have planned to add a big fat warning about safety of
> browserify-crypto. I am myself unease to use it but it is needed for
> browserify.
> 
> Do you prefer a README.debian per pure js crypto package ?

Maybe also add something along the lines of

| For security considerations of this package please consult
| README.Debian.

to the package's extended description? (Or is that against
policy?)

> I plan to patch browserify and add a flag in order to use the crypto API.

Isn't browserify a JS minifier? Why would that need DH key
exchange anyway? I'm a bit confused here...

Regards,
Christian

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Christian Seiler]

On 04/19/2017 11:36 PM, Bastien ROUCARIES wrote:
> Package: wnpp
> Severity: wishlist
> Owner: ro...@debian.org
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: node-diffie-hellman
>   Version : 5.0.2
>   Upstream Author : Calvin Metcalf
> * URL : https://github.com/crypto-browserify/diffie-hellman
> * License : Expat
>   Programming Lang: JavaScript
>   Description : pure js diffie-hellman key exchange
> 
>  Diffie–Hellman key exchange (D–H)  is a specific method of securely
>  exchanging cryptographic keys over a public channel. The
> Diffie–Hellman key exchange method allows two parties that have no
> prior knowledge of each other to jointly establish a shared secret key
> over an insecure channel. This key can then be used to encrypt
> subsequent communications using a symmetric key cipher.
>  .
>  Node.js is an event-based server-side JavaScript engine.

Is this timing safe? From the github page it uses a pure-JS
BigNum implementation (bn.js) for the complicated stuff, but
the README of that code doesn't mention timing at all. And
from perusing the source code of bn.js, it doesn't appear to
be the case that their implementation of exponentiation in
a prime field is geared towards constant-time execution (when
the sizes are the same).

If you look at e.g. OpenSSL's source code (bn_exp.c), there's
a specific function (bn_mod_exp_mont_consttime) in there that
takes great care of making sure that the operation runs in
constant time - down to how the memory layout is organized. I
wouldn't know how you'd even do that in an interpreted
language such as JavaScript, but even if that's possible, I'd
suspect that a lot of brain power would need to go into
designing that [1], while bn.js's implementation of the
Red.pow function seems rather straight-forward. (Which is
fine, bn.js appears to have the goal to be a generic bignum
library, and not targeted at crypto.)

What I'm saying is: while not having tested that, I believe
that this implementation of DH is going to be susceptible to
timing attacks. (And if it isn't, the author should really
provide some rationale why not, with some test results. The
README is rather sparse, though.) Which would be fine if you
just wanted to use this library to generate the DH prime
itself (that is not timing critical), or just use it in an
academic context (to let people play around with DH), but
I'd not want to use this for real-world applications of the
actual key exchange protocol.

Regards,
Christian

[1] Especially if this is to be run in browsers, with
different JITs etc. Designing algorithms in pure JS
for these environments that are timing-safe looks rather
daunting to me.

Bug#860259: release-notes: please mention switch to libinput-based driver in Xorg

[Christian Seiler]

Package: release-notes
Severity: normal
X-Debbugs-Cc: debia...@lists.debian.org

Dear release team,

there was a question on debian-user right now about input
configuration options not working anymore on Stretch that have
previously been working (for a _long_ time):

https://lists.debian.org/debian-user/2017/04/msg00400.html

The reason is that Xorg now uses a libinput-based driver by default
and not the evdev one (though that was is still available IIRC),
and the configuration options are named differently in the
libinput-based driver.

This should be mentioned in the release notes, perhaps also with
a snippet for how to go back to the evdev-based driver.

In case it might be useful to link the manpage of the libinput
driver:
https://manpages.debian.org/testing/xserver-xorg-input-libinput/libinput.4.en.html

Regards,
Christian

Bug#859947: unblock: open-isns/0.97-2

[Christian Seiler]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-Cc: pkg-iscsi-maintain...@lists.alioth.debian.org

Please unblock package open-isns.

This package adds a new debconf translation for Portuguese. It
has been built successfully on all release architectures.
Source debdiff is attached.

Thanks!

unblock open-isns/0.97-2

-- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-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
Init: systemd (via /run/systemd/system)
diff -Nru open-isns-0.97/debian/changelog open-isns-0.97/debian/changelog
--- open-isns-0.97/debian/changelog 2017-01-25 10:37:36.0 +0100
+++ open-isns-0.97/debian/changelog 2017-04-09 12:58:39.0 +0200
@@ -1,3 +1,10 @@
+open-isns (0.97-2) unstable; urgency=medium
+
+  [ Rui Branco ]
+  * Add Portuguese translations of debconf messages (Closes: #858746)
+
+ -- Christian Seiler   Sun, 09 Apr 2017 12:58:39 +0200
+
 open-isns (0.97-1) unstable; urgency=medium
 
   [ Christian Seiler ]
diff -Nru open-isns-0.97/debian/copyright open-isns-0.97/debian/copyright
--- open-isns-0.97/debian/copyright 2017-01-25 10:37:36.0 +0100
+++ open-isns-0.97/debian/copyright 2017-04-09 12:58:39.0 +0200
@@ -33,6 +33,10 @@
 Copyright: 2016 Adriano Rafael Gomes 
 License: LGPL-2.1+
 
+Files: debian/po/pt.po
+Copyright: 2017 Rui Branco 
+License: LGPL-2.1+
+
 License: LGPL-2.1+
  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
diff -Nru open-isns-0.97/debian/po/pt.po open-isns-0.97/debian/po/pt.po
--- open-isns-0.97/debian/po/pt.po  1970-01-01 01:00:00.0 +0100
+++ open-isns-0.97/debian/po/pt.po  2017-04-09 12:58:39.0 +0200
@@ -0,0 +1,212 @@
+# Portuguese translation for open-isns debconf messages.
+# This file is distributed under the same license as the open-isns package.
+# Rui Branco , 2017.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: open-isns 0.97-1\n"
+"Report-Msgid-Bugs-To: open-i...@packages.debian.org\n"
+"POT-Creation-Date: 2017-03-14 21:54+\n"
+"PO-Revision-Date: 2017-03-14 22:45+\n"
+"Last-Translator: Rui Branco \n"
+"Language-Team: Portuguese \n"
+"Language: pt\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.8.11\n"
+"Plural-Forms: nplurals=2; plural=(n != 1);\n"
+
+#. Type: string
+#. Description
+#: ../open-isns-discoveryd.templates:1001
+msgid "iSNS server name:"
+msgstr "Nome do servidor iSNS:"
+
+#. Type: string
+#. Description
+#: ../open-isns-discoveryd.templates:1001
+msgid "The iSNS discovery daemon will connect to an iSNS server at startup."
+msgstr ""
+"O 'daemon' de descoberta iSNS irá ligar-se ao servidor iSNS no arranque."
+
+#. Type: string
+#. Description
+#: ../open-isns-discoveryd.templates:1001
+msgid ""
+"If left blank, the discovery daemon will not be started after package "
+"installation, and you will have an opportunity to modify the configuration "
+"file, /etc/isns/isnsdd.conf."
+msgstr ""
+"Se deixado em branco o 'daemon' de descoberta não será iniciado depois da "
+"instalação do pacote e terá oportunidade de modificar o ficheiro de "
+"configuração /etc/isns/isnsdd.conf."
+
+#. Type: string
+#. Description
+#: ../open-isns-discoveryd.templates:2001
+msgid "iSNS server public key file:"
+msgstr "Ficheiro da chave pública do servidor iSNS:"
+
+#. Type: string
+#. Description
+#: ../open-isns-discoveryd.templates:2001
+msgid ""
+"When authentication is enabled, the iSNS discovery daemon needs to know the "
+"public key of the iSNS server. Please provide a file name that contains the "
+"public key. It will then be copied to /etc/isns/server_key.pub."
+msgstr ""
+"Quando a autenticação está activada, o 'daemon' de descoberta iSNS necessita "
+"da chave pública do servidor iSNS. Por favor forneça um nome de ficheiro que "
+"contenha a chave pública. A mesma será copiada para /etc/isns/server_key.pub."
+
+#. Type: string
+#. Description
+#: ../open-isns-discoveryd.templates:2001
+msgid ""
+"Alternatively, you may copy the server's public key to that location "
+"yourself."
+msgstr ""
+"Alternativamente poderá copi

Bug#858860: RFS: arpwatch [ITA]

[Christian Seiler]

On 04/06/2017 02:51 PM, Lukas Schwaighofer wrote:
> 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? 

Oh, ok, then I was wrong about that. I had in mind that dh binary first
runs dh_auto_install and then all of the other dh_* things required to
actually create the binary package. But if your call to dh shows
differently, then that won't happen, and I was simply wrong about that.

(TBH, I've only ever used dirs for creating empty directory that are
required by the packaged software during runtime.)

Sorry for the noise.

Regards,
Christian

Bug#858860: RFS: arpwatch [ITA]

[Christian Seiler]

On 04/05/2017 07:02 PM, Lukas Schwaighofer wrote:
> On Wed, 5 Apr 2017 18:25:04 +0200
> Hugo Lefeuvre  wrote:
>>> 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?

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.

You should probably just patch the build system to create the install
directory if it doesn't exist. (Maybe just use install -D to copy the
file, that will auto-create the directories leading up to the target.)

Regards,
Christian

Bug#858533: rtslib-fb-targetctl: doesn't work with sysvinit due to missing configfs mount

[Christian Seiler]

On 03/29/2017 03:31 PM, Harald Dunkel wrote:
> I agree about mounting configfs in the init script, but please
> note that /sys/kernel/config *is* mounted early at boot time.
> Its just not available yet.

No, it isn't mounted early at boot time, at least not from
sysvinit, due to a bug (see below).

> Maybe the LSB header is bad, or the timeout in rtslib-fb-targetctl
> has to be increased.

So apparently something else mounts configfs in your case that
is run in parallel to LIO. But the LSB headers of targetctl
clearly indicate that it's a standard service that's run _way_
later than early-boot services, even after $remote_fs - so
/etc/init.d/mountkernfs.sh will definitely have been run already
at that point.

The problem with mountkernfs.sh in sysvinit is that it will only
mount configfs if /sys/kernel/config exists, which will only
exist if the configfs module is loaded, which will only happen
after mountkernfs.sh is started on sysvinit. (systemd in contrast
loads modules before mounting things such as configfs nowadays;
it also got that wrong in the past though.) This bug in sysvinit
(or more accurately the initscripts package) is the bug I
referenced:

https://bugs.debian.org/840356

If in your case after boot configfs is mounted anyway, there's
another service that does that for you. Could you grep for
configfs in /etc/init.d? You'll probably fine something other
than targetctl or mountkernfs.sh that will mount it at a later
point in boot - but that's definitely not something I'd rely
on.

The proper way to fix this is to fix the initscripts package to
load modules before mounting configfs. Since targetctl is not
an early-boot service, ordering will automatically be correct
then and your use case will work.

However, that's something you'll have to take up with the
sysvinit/initscripts maintainers, because it clearly is a bug
in those packages.

(Actually, this is the first time I've looked at the targetctl
init script, and the loop in there waiting for configfs to be
mounted really should NOT be there, that is just plain wrong.
configfs availability should be done via ordering, not waiting
in the packground for stuff to start - because that really is
non-deterministic. And the ordering is actually correct
already; the other package that mounts configfs in the init
script is buggy in my eyes because it does something it should
not, as well as sysvinit for not properly mounting configfs in
the first place.)

The only "workaround" would be to mount configfs ourselves in
the targetctl init script, but to me this really not
advisable, because if something else is already mounting
configfs in the background, then the mount command could be
issued twice - which shouldn't happen, and can cause some
unexpected issues (appearing in /proc/mounts or
/proc/self/mountinfo twice for the same mount point could break
some scripts that don't expect that, for example. And since
the mount command being issued twice depends on a race
condition, this would be non-deterministic and very difficult
to debug).

Regards,
Christian

Bug#858746: open-isns: [INTL:pt] Portuguese translation for debconf messages

[Christian Seiler]

Control: tags -1 + confirmed

Hi,

On 03/25/2017 11:18 PM, TRADUZ - DebianPT wrote:
> Updated Portuguese translation for open-isns's debconf messages.
> Translator: Rui Branco 
> Feel free to use it.

Many thanks for the translation. As far as I understand it, the
Stretch freeze policy does allow for translation updates, so I'll
try to get this into Stretch.

However, I'll wait a while before applying this, in case another
serious or important bug is reported in the open-isns package
that also needs fixing, so I don't have to request an unblock
from the release team twice. In case no other bug is reported in
the next two weeks, I'll upload just the translation.

Regards,
Christian

Bug#858533: rtslib-fb-targetctl: doesn't work with sysvinit due to missing configfs mount

[Christian Seiler]

Control: block -1 by 840356
Control: retitle -1 rtslib-fb-targetctl: doesn't work with sysvinit due to 
missing configfs mount

Hi,

Christophe actually reported this issue in sysvinit last year, it
just hasn't been fixed yet:
https://bugs.debian.org/840356

I seem to think that it's not the job of individual init scripts to
make sure that something as essential as configfs (which is used in
many things other than LIO iSCSI targets) is mounted, that should be
the job of the init system. And even the sysvinit maintainers seemed
to think so, because mountkernfs.sh does have code to mount configfs,
it just doesn't work properly, see the linked bug report.

I hence don't think anything should be done from the perspective of
the rtslib-fb package, this should rather be fixed properly in the
sysvinit/initscripts package.

I'm explicitly not merging the bug reports but rather blocking this
bug by the one in sysvinit to make it easier to find if other people
have the same problem.

Regards,
Christian

Bug#858459: [linux-target-packaging] Bug#858459: targetcli-fb: backup files not written unless dir exists

[Christian Seiler]

On 03/24/2017 11:01 AM, Harald Dunkel wrote:
> On 03/23/17 19:49, Christian Seiler wrote:
>>
>> The issue has now been fixed upstream:
>>
>> https://github.com/open-iscsi/targetcli-fb/commit/8011ea6a741d494c145b4906f7a7865c8b74c6a7
>>
> 
> I highly appreciate your fast response and fix on this
> problem.

My question now would be: you also reported #858434 in targetcli,
which I can't reproduce. I now have two option:

 - I could either upload a new version now with the fix for
   #858459 (this bug).

 - I could wait until we've zeroed in on the second issue and
   upload a package with both fixes.

Since the release team has to manually review each change at this
point in the freeze, I'd prefer not ask twice. On the other hand,
if you are yourself having trouble figuring out how to reproduce
the second problem and this could take a while, perhaps it's
better to fix the backup issue first to get that out of the way.

> Do you think that #858533 should be linked to this report?

No, that's a separate issue (separate package), but thanks for
making me aware of it, I'll take a look. (You could link the
report to the package targetcli-fb though, see [1].)

> I have no idea why rtslib-fb-targetctl is managed by the
> Openstack maintainers.

Because OpenStack uses LIO to export volumes to VM instances, and
they use rtslib-fb internally. Plus, the OpenStack team was first
to package the rtslib-fb package. (The non-fb rtslib package was
packaged by Ritesh earlier, but we decided to switch away from
the non-fb LIO branch only after OpenStack already had that
package in Debian.)

There were some discussions recently about rtslib-fb changing
maintenance to the LIO team, but that hasn't happened yet, and
it definitely won't happen officially for Stretch.

That said: I'll be happy to take a look at that other bug report.

Regards,
Christian

[1] https://www.debian.org/Bugs/server-control#affects

Bug#858459: targetcli-fb: backup files not written unless dir exists

[Christian Seiler]

Control: tags -1 + pending fixed-upstream

On 03/23/2017 02:42 PM, Christian Seiler wrote:
> I've now also reported the issue in the upstream bugtracker.

The issue has now been fixed upstream:

https://github.com/open-iscsi/targetcli-fb/commit/8011ea6a741d494c145b4906f7a7865c8b74c6a7

I've cherry-picked the fix and updated the Debian packaging repository,
the fix will be part of the next upload:
https://anonscm.debian.org/cgit/linux-target/targetcli-fb.git/commit/?id=41db9d4d373904f4f47c06d535c01f73807890db

Regards,
Christian

Bug#858459: targetcli-fb: backup files not written unless dir exists

[Christian Seiler]

Control: forwarded -1 https://github.com/open-iscsi/targetcli-fb/issues/80

I've now also reported the issue in the upstream bugtracker.

On 03/23/2017 07:58 AM, Harald Dunkel wrote:
> I would suggest to add the directory to the package or to create
> it by the postinst script.

Sure, that'd work around the immediate problem in Debian. OTOH, I'd rather
like to fix it properly, so that the user is never shown an incorrect
message here.

Once I hear back from upstream what direction they'd like to go here (that
is if they want to try to autocreate the backup directory or not), I'd
also upload a fixed Debian package. (Well, I'd also wait for your response
on #858434, because I'd rather like to fix both things in one go.)

Regards,
Christian

Bug#858434: LUNs have been created, but ls / doesn't show

[Christian Seiler]

Control: tags -1 + moreinfo

On 03/22/2017 12:27 PM, Harald Dunkel wrote:
> Package: targetcli-fb
> Version: 2.1.43-1
> 
> After creating 2 new LUNs in the target I have to restart
> targetcli to make them show up. Sample session: [...]

I cannot reproduce the problem in a test VM using the fileio backend.
I followed the same steps you did and the problem did not appear for
me.

Could you help me narrow this problem down a bit more? Does this
occur only with very large devices (the ones you want to add are
2 TiB in size)? Or is the size of the device added irrelevant? Does
this also occur for disk images (fileio backstore)?

Regards,
Christian

Bug#858459: targetcli-fb: backup files not written unless dir exists

[Christian Seiler]

Control: retitle -1 targetcli-fb: backup files not written unless dir exists
Control: severity -1 important
Control: tags -1 + confirmed upstream

On 03/22/2017 04:21 PM, Harald Dunkel wrote:
> Package: targetcli-fb
> Version: 2.1.43-1
> 
> targetcli claims to write backups on exit (using the default
> configuration), but it doesn't:
> 
> :
> /> exit
> Info: Global pref auto_save_on_exit=true
> Info: Last 10 configs saved in /etc/rtslib-fb-target/backup.
> Info: Configuration saved to /etc/rtslib-fb-target/saveconfig.json
> root@nasl003b:~# ls -al /etc/rtslib-fb-target
> total 32
> drwxr-xr-x   2 root root  4096 Mar 22 16:17 .
> drwxr-xr-x 101 root root 12288 Mar 20 14:28 ..
> -rw---   1 root root 14323 Mar 22 16:17 saveconfig.json

Yes, indeed, that's unfortunately true. The problem here is that
it will only store backups if the backup directory exists. (You
can manually create that directory as a workaround at the
moment.)

Increasing bug severity as the command line message is very, very
misleading and could lull users into a false sense of security.

Thanks for reporting this!

Regards,
Christian

Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.

[Christian Seiler]

Hi again,

On 03/20/2017 07:43 AM, Christian Seiler wrote:
> And while that shouldn't be part of the package description later on,
> a short comment in the ITP why a fork was required would also be nice.
> Did the original project just not want to merge this? What's the use
> case for these changes that can't be supported by the original?

I've done some digging in the mailing list for the original upstream
project and found this thread:

https://lists.zx2c4.com/pipermail/password-store/2017-February/thread.html#2728

Specifically take a look at this message from the author of the original
tool:
https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html

The fork appears to have happened after that, but wasn't mentioned at
all on the upstream mailing list.

I haven't looked at the changes specifically, so I can't comment on the
issue of code quality at all, but that a relatively new user [1] forks
the entire project immediately after being shot down a bit for a patch
series (where the response was maybe a bit harsh, but not entirely
negative) doesn't instill me with a lot of confidence in the fork,
especially since the author of the fork hasn't mentioned any specific
use case why the changed functionality is needed at all, as far as I
can tell. (And making --help show extensions was something that devs of
the original project were interested in including regardless.)

Just my 2¢.

Regards,
Christian

[1] https://lists.zx2c4.com/pipermail/password-store/2017-January/002664.html

Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.

[Christian Seiler]

On 03/20/2017 06:18 AM, Adrian Alves wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Adrian Alves 
> 
> * Package name: passh
>   Version : 1.7.1
>   Upstream Author : Ivan Ariel Barrera Oro 
> * URL : https://github.com/HacKanCuBa/passh
> * License : GPL-3
>   Programming Lang: bash
>   Description : passh: a pass fork - stores, retrieves, generates, and 
> synchronizes passwords securely.
> 
> Pass is a simple password store. This fork changes a few
> things while trying to maintain most of it intact,
> specially the core idea. I will keep pulling pass commits,
> and also pushing my modifications to them.

It would be great if you could go into a bit more detail why this
fork is needed? "changes a few things" is _very_ unspecific.

I've had a look at the upstream website, and found this:
https://github.com/HacKanCuBa/passh#user-content-changes-from-pass-master
So apparently the only real difference (apart from branding) is
extension handling. This should definitely go in the package
description to allow people to decide which one they'd want to
install.

And while that shouldn't be part of the package description later on,
a short comment in the ITP why a fork was required would also be nice.
Did the original project just not want to merge this? What's the use
case for these changes that can't be supported by the original?

Also, a minor note, unrelated to Debian packaging: the fork claims in
https://github.com/HacKanCuBa/passh#license 
that the original is GPL-2 and that the fork is GPL-3+. If that were
actually true, the fork would be a license violation. Luckily for the
fork from reading the COPYING file of the original, that is is actually
licensed under GPL-2+ (not just GPL-2), so forking as GPL-3+ is fine.
(That said, while I generally like the GPL-3, forking a GPL-2+ project
under GPL-3+ does not allow the original project to easily merge back
changes made in the fork, they'd first have to get explicit
permission.)

Regards,
Christian

Bug#855459: Handling of libowfat/arm64 (+ rdeps)

[Christian Seiler]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Dear release team,
(not user-tagging because I'm unsure about the category)

After having fixed the last RC bug in dietlibc, I've gone back and
looked at what packages might need rebuilds (since dietlibc is a
statically linked library).

Luckily none are required, since this only affects packages that
link binaries against -lpthread and dietlibc, of which none exist
in Debian. (This also applies to the other recent RC bugs fixed.)

However, one rdep links against -lpthread for its tests (which
aren't installed): libowfat. An earlier RC bug in dietlibc (fixed
before the freeze, see #850276) caused libowfat to FTBFS on arm64.
However, since no previous binary package of libowfat was built on
arm64 (previously to dietlibc supporting arm64 at all libowfat
was B-D-Uninstallable on that arch) it could migrate to testing
regardless.

(Side note: libowfat is orphaned, but it has one non-orphaned
rdep, gatling, which is both in sid and Stretch.)

With #850276 now fixed in Stretch (for a while now, actually),
libowfat does now build on arm64 (I've verified that on a
porterbox) - it just hasn't yet, as it's in the Build-Attempted
state.

I believe the simplest way of handling this is to simply give
back libowfat on arm64. Otherwise any update to libowfat
(including a security update) will introduce a new binary package
into Stretch on an architecture that previously didn't have it,
and it's probably better to do that before the release then
while doing a security update.

However, since gatling B-D: on libowfat-dev [1], once that
becomes available in arm64, wanna-build will then start building
that and I suspect that will succeed. (Haven't tried it though.)

So what I propose is the following:

gb libowfat_0.30-2 . arm64

And then, after having verified that both libowfat and gatling
build on arm64, unblock the arm64 binaries of these packages so
that they can also migrate to testing.

Regards,
Christian

PS: Side note 2: gatling is not build against dietlibc in Debian,
but against glibc, but since libowfat only builds if both
variants of it succeed, gatling has always been B-D-Uninstallable
on arm64 so far.

Bug#855456: unblock: dietlibc/0.34~cvs20160606-6

[Christian Seiler]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Dear release team,

please unblock package dietlibc.

This fixes an RC bug (#851379) and updates the maintainer information.
debdiff is attached.

unblock dietlibc/0.34~cvs20160606-6

Thanks,
Christian
diff -Nru dietlibc-0.34~cvs20160606/debian/changelog dietlibc-0.34~cvs20160606/debian/changelog
--- dietlibc-0.34~cvs20160606/debian/changelog	2017-01-25 22:25:27.0 +0100
+++ dietlibc-0.34~cvs20160606/debian/changelog	2017-02-18 12:10:09.0 +0100
@@ -1,3 +1,14 @@
+dietlibc (0.34~cvs20160606-6) unstable; urgency=medium
+
+  [ Héctor Orón Martínez ]
+  * debian/control: drop myself from maintainers field.
+
+  [ Christian Seiler ]
+  * arm64: fix accidental register reuse in __testandset (Closes: #851379)
+  * Add Thorsten Glaser to Uploaders.
+
+ -- Christian Seiler   Sat, 18 Feb 2017 12:10:09 +0100
+
 dietlibc (0.34~cvs20160606-5) unstable; urgency=medium
 
   * hppa: fix pthread_atfork() and getsockopt() FTBFS bugs
diff -Nru dietlibc-0.34~cvs20160606/debian/control dietlibc-0.34~cvs20160606/debian/control
--- dietlibc-0.34~cvs20160606/debian/control	2017-01-25 22:25:27.0 +0100
+++ dietlibc-0.34~cvs20160606/debian/control	2017-02-18 12:10:09.0 +0100
@@ -2,8 +2,8 @@
 Section: devel
 Priority: optional
 Homepage: http://www.fefe.de/dietlibc/
-Maintainer: Hector Oron 
-Uploaders: Christian Seiler 
+Maintainer: Christian Seiler 
+Uploaders: Thorsten Glaser 
 Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9), dh-exec
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/dietlibc.git
diff -Nru dietlibc-0.34~cvs20160606/debian/patches/bugfixes/arm64-testandset.diff dietlibc-0.34~cvs20160606/debian/patches/bugfixes/arm64-testandset.diff
--- dietlibc-0.34~cvs20160606/debian/patches/bugfixes/arm64-testandset.diff	1970-01-01 01:00:00.0 +0100
+++ dietlibc-0.34~cvs20160606/debian/patches/bugfixes/arm64-testandset.diff	2017-02-18 12:10:09.0 +0100
@@ -0,0 +1,26 @@
+Description: Fix register reuse in __testandset on arm64
+ In the case where the stlxr instruction fails on arm64 (either due to
+ another thread having accesed that memory location or spuriously) the
+ register x2 (which stores the pointer to the memory location) is now
+ useless because the original implementation reused it (which it should
+ not have).
+ .
+ Just use the unused w3 register for the status result instead.
+Author: Christian Seiler 
+Bug-Debian: https://bugs.debian.org/851379
+Last-Update: 2017-02-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/aarch64/__testandset.S
 b/aarch64/__testandset.S
+@@ -8,8 +8,8 @@ FUNC_START	__testandset
+ 	 * for details why we want to use ldxr (instead of ldaxr) here and a full memory
+ 	 * barrier afterwards. */
+ 1:	ldxr	w0, [x2]
+-	stlxr	w2, w1, [x2]
+-	cbnz	w2, 1b
++	stlxr	w3, w1, [x2]
++	cbnz	w3, 1b
+ 	dmb	ish
+ 	ret
+ FUNC_END	__testandset
diff -Nru dietlibc-0.34~cvs20160606/debian/patches/series dietlibc-0.34~cvs20160606/debian/patches/series
--- dietlibc-0.34~cvs20160606/debian/patches/series	2017-01-25 22:25:27.0 +0100
+++ dietlibc-0.34~cvs20160606/debian/patches/series	2017-02-18 12:10:09.0 +0100
@@ -11,11 +11,12 @@
 bugfixes/s390x-testandset.diff
 bugfixes/parisc-getsockopt.diff
 bugfixes/parisc-atfork.diff
-
-# Debian-specific patches (not for upstream)
 bugfixes/thread-self-vs-tcb.diff
 bugfixes/alpha-testandset.diff
+bugfixes/arm64-testandset.diff
 alpha-setjmp.diff
+
+# Debian-specific patches (not for upstream)
 debian/sparc32-mcpu-v9.diff
 debian/native-x32.diff
 debian/buildflags.diff

Bug#854197: systemd: please handle the case where socket activation leads to restart loop better

[Christian Seiler]

Package: systemd
Version: 232-15
Severity: wishlist

Dear maintainers,

while helping out on debian-mentors@ with #854192 I noticed that systemd
doesn't appear to handle the case very well when dbus is installed but not
configured properly (this was due to a bug in the usbguard package that
missed a dependency on dbus), trying to start a Type=dbus service (that
does DBus requests) will cause a nasty restart loop that you can only get
out of if you stop dbus.socket - but it's very non-obvious that that is
what you should do.

Steps to reproduce:

 - install a stretch system, minimal (tasksel empty), no DBus
 - Recreate a broken DBus installation:
  apt-get download libdbus-1-3 dbus
  dpkg --install libdbus-1-3_*.deb
  dpkg --unpack dbus_*.deb
 - Create a dummy service:
  cat > /etc/systemd/system/dummy.service
  [Service]
  BusName=org.example.dummy
  ExecStart=/usr/bin/dbus-monitor --system
  (Ctrl+D)
 - Try to start that service
  systemctl daemon-reload
  systemctl start dummy

The dbus-monitor startup will cause dbus.socket to be triggered, which
in turn will cause systemd to try to start dbus.service. Problem here is
that dbus's postinst won't have run yet, so the "messagebus" user won't
exist, so dbus-daemon won't start up propery.

Problem: this creates a restart loop, since systemd tries to restart
the service over and over again because there's data on the DBus socket.
I'm pretty sure you could also reproduce that with other services that
are socket activated, but this definitely reproduces this.

Doing systemctl stop dummy or systemctl stop dbus doesn't help here;
masking dbus.service or dummy.service doesn't either. journalctl doesn't
say anything useful except "Looping too fast" being printed every 1s or
so. systemctl daemon-reexec has no effect (it does reexec though). The
only way to get out of this problem is to stop dbus.socket, which is
not very obvious to a user - even I didn't think of that immediately,
and rebooted my test VM a couple of times while figuring this out. I
suspect users with less knowledge of systemd than I will not fare
better.

What I would like to see is: systemd could maybe print a message when
a service (repeatedly) fails to start as a result of socket activation
(including which socket is responsible), so that users have an idea of
what they could do to make systemd cooperate again. Also once could
think about a mode where a socket is stopped (in failed state)
automatically after the service associated with it has failed to start
more than N times (configurable in the socket's unit file), with N
defaulting to 30 or something similar. This would really help in this
kind of situation.

Not sure about the severity of this bug, because the current behavior
of systemd does indeed work as designed (data on the socket -> try to
start service -> service fails -> service marked inactive -> systemd
looks at socket again -> data on the socket -> rinse and repeat ...),
but the consequences are rather nasty IMHO. I've filed it under
wishlist for now because of the "works as designed" argument, but my
annoyance level with this bug would easily make this 'normal' or
'important'. I'll leave this up to you.

Regards,
Christian

Bug#854192: serious bug in usbguard installation

[Christian Seiler]

On 02/04/2017 11:25 PM, Christian Seiler wrote:
> That said: I just tried this in a VM, and systemd appears to be
> quite broken if you try to start a Type=dbus unit when DBus is
> installed, but not properly configured. And while that is not
> normally the case, I couldn't get systemd to work properly again
> without rebooting it, not even a daemon-reexec worked. So I think
> this would also qualify as a systemd bug here - it should just
> fail the Type=dbus unit at this point, and not go into an endless
> loop. I'll report that separately.

Ok, you can break the endless loop by stopping dbus.socket, so
systemd actually works as expected here.

Regards,
Christian

Bug#854192: serious bug in usbguard installation

[Christian Seiler]

On 02/04/2017 10:09 PM, Muri Nicanor wrote:
> i just found a bug (#854192) in the installation procedure of usbguard:
> when i install usbguard on a minimal stretch system, the installation
> stalls and never ends successfully. apparently it has something to do
> with dbus being a dependency of usbguard. if i install dbus *before*
> installing usbugard, everything works fine. this is probably, why it
> didn't come up before. if i don't, the installations procedure stalls at
>> /var/lib/dpkg/info/usbguard.postinst configure
> 
> and the journal says
>> Feb 04 13:11:04 debian dbus-daemon[1200]: Unknown username
>> "usbguard-dbus" in message bus configuration file
>> Feb 04 13:11:04 debian dbus-daemon[1200]: Failed to start message
>> bus: Could not get UID and GID for username "messagebus"

Problem is that DBus fails to start, and systemd requires DBus to be
running (and configured properly) if Type=dbus is used.

The problem is that your package doesn't have Depends: dbus, so it
doesn't depend on the DBus daemon being available, so APT configures
dbus after usbguard (it's allowed to do that w/o an explicit Depends),
which is bad, since dbus's postinst creates the 'messagebus' user,
without which the DBus daemon doesn't start.

Fix is simple: add that dependency. :-) If you look at other DBus
services, they all have that dependency explicitly.

That said: I just tried this in a VM, and systemd appears to be
quite broken if you try to start a Type=dbus unit when DBus is
installed, but not properly configured. And while that is not
normally the case, I couldn't get systemd to work properly again
without rebooting it, not even a daemon-reexec worked. So I think
this would also qualify as a systemd bug here - it should just
fail the Type=dbus unit at this point, and not go into an endless
loop. I'll report that separately.

Regards,
Christian

Bug#851379: dietlibc FTBFS on arm64: Bus error when running tst-calloc.c

[Christian Seiler]

On 01/26/2017 10:17 PM, Thorsten Glaser wrote:
> Christian Seiler dixit:
>> -g, and generate a backtrace? That might already help me to figure
>> out what's going on...
> 
> Recursive calls; the SIGBUS is likely a stack underflow.

So it looked at this yesterday evening and I couldn't really make heads
or tails from the backtrace, so let's try this again with a fresh pair
of eyes.

I would expect stack exhaustion to cause a SIGSEGV, but not a SIGBUS.
Example:

void foo()
{
  char a[8192];
  a[0] = '\0';
  // Prevent tail-recursion optimization by the compiler:
  void (* volatile bar)() = &foo;
  bar();
  (void) a;
}

int main()
{
  foo();
  return 0;
}

This segfaults, but doesn't generate SIGBUS.

> (gdb) set pagination off
> (gdb) r
> Starting program: /home/tg/dietlibc-0.34~cvs20160606/debian/unittests/ttt
> [Inferior 1 (process 29556) exited normally]
> (gdb) r
> Starting program: /home/tg/dietlibc-0.34~cvs20160606/debian/unittests/ttt
> 
> Program received signal SIGBUS, Bus error.
> 0x00401740 in __testandset ()
> (gdb) bt
> #0  0x00401740 in __testandset ()
> #1  0x004016a0 in __pthread_lock ()
> #2  0x004016a0 in __pthread_lock ()
> #3  0x004016a0 in __pthread_lock ()
> #4  0x004016a0 in __pthread_lock ()
> #5  0x004016a0 in __pthread_lock ()

I don't think this is stack exhaustion; I think the stack frame
is being corrupted here and that's why gdb can't figure out the
proper stack frame.

> (sid_arm64-dchroot)tg@asachi:~/dietlibc-0.34~cvs20160606$ gdb 
> debian/unittests/ttt
> Breakpoint 1, 0x00401674 in __pthread_lock ()
> (gdb) bt
> #0  0x00401674 in __pthread_lock ()
> #1  0x00400858 in __thread_find_ ()
> #2  0x00400894 in __thread_self ()
> #3  0x0040059c in malloc ()
> #4  0x0040059c in malloc ()
> #5  0x0040059c in malloc ()
> #6  0x0040059c in malloc ()
> #7  0x0040059c in malloc ()
> […]

This would also indicate stack frame corruption (and hence gdb
being unable to properly trace this), because malloc() (see
libpthread/pthread_sys_alloc.c) does _not_ call itself directly.

> Your debian/patches/bugfixes/thread-self-vs-tcb.diff replaces the inline
> assembly implementation of __thread_self with one ending up recursively
> calling a chain malloc → __thread_self → __thread_find_ → __pthread_lock
> probably because it uses some structure that needs to be malloc(3)ed to
> work, but is needed for malloc(3) to function.

No, because __thread_self and __thread_find_ and __pthread_lock
never call malloc().

If that were the case, you'd see that loop in the stack trace,
and not just the same function repeated over and over again.

Whether this is a stack exhaustion or not can easily be seen:

Print the current stack pointer in gdb:
print $sp

Look at /proc/$PID/maps to see in which range the stack resides.
I'd be surprised if $sp was even close to the lower end of that
address range.

Unfortunately, if the stack frame really is corrupted, I'd really
need to look at this on the porterbox directly (because I don't
think it's a productive use of both of our time to do this via
email), so I'll have to wait until I get my account.

Regards,
Christian

Bug#851379: dietlibc FTBFS on arm64: Bus error when running tst-calloc.c

[Christian Seiler]

On 01/26/2017 09:27 PM, Thorsten Glaser wrote:
>> Christian Seiler dixit:
> 
>>> Could you do me a favor, if you're on the porterbox anyway?
>>
>> … that’s a lengthy process, but I’ll do anyway…
> 
> Surprise!

Yay for nondeterminism...

> (sid_arm64-dchroot)tg@asachi:~/dietlibc-0.34~cvs20160606$ dpkg -l | fgrep 
> dietlibc
> ii  dietlibc-dev:arm64 0.34~cvs20160606-5   arm64diet libc - 
> a libc optimized for small size
> (sid_arm64-dchroot)tg@asachi:~/dietlibc-0.34~cvs20160606$ diet -v -Os gcc 
> -nostdinc -fstack-protector-strong -static \
>> -o debian/unittests/ttt test/stdlib/tst-calloc.c \
>> -lpthread # sollte eigentlich -pthread sein AFAIK
> gcc -nostdlib -static -L/usr/lib/aarch64-linux-gnu/diet/lib-aarch64 
> -L/usr/lib/diet/lib /usr/lib/aarch64-linux-gnu/diet/lib-aarch64/start.o 
> -nostdinc -fstack-protector-strong -static -o debian/unittests/ttt 
> test/stdlib/tst-calloc.c -lpthread -isystem 
> /usr/lib/aarch64-linux-gnu/diet/include -D__dietlibc__ -Os 
> -fomit-frame-pointer /usr/lib/aarch64-linux-gnu/diet/lib-aarch64/libc.a -lgcc
> test/stdlib/tst-calloc.c: In function 'random_test':
> test/stdlib/tst-calloc.c:71:19: warning: implicit declaration of function 
> 'random' [-Wimplicit-function-declaration]
>int n = 1 + random () % 10;
>^~
> /usr/lib/aarch64-linux-gnu/diet/lib-aarch64/libc.a(vfprintf.o): In function 
> `vfprintf':
> (.text+0x5c): warning: warning: the printf functions add several kilobytes of 
> bloat.
> /usr/lib/aarch64-linux-gnu/diet/lib-aarch64/libc.a(stderr.o): In function 
> `__fflush_stderr':
> (.text+0x8): warning: warning: your code uses stdio (7+k bloat).
> (sid_arm64-dchroot)tg@asachi:~/dietlibc-0.34~cvs20160606$ 
> ./debian/unittests/ttt
> Bus error

If you have time, could you install gdb, compile the binary with
-g, and generate a backtrace? That might already help me to figure
out what's going on...

Regards,
Christian

Bug#851379: dietlibc FTBFS on arm64: Bus error when running tst-calloc.c

[Christian Seiler]

On 01/26/2017 08:35 PM, Thorsten Glaser wrote:
> Christian Seiler dixit:
> 
>> Unfortunately I still haven't heard back from Front Desk about
>> a porterbox account (I'm a DM) for arm64, and I really can't
>> reproduce the issue in qemu on my system and I don't have
>> ARMv8 hardware.
> 
> I just did that for you,

Oh, thanks! :-)

> and it’s fine on the porterbox as well
> (so your workaround to expect a failure is actually not a problem):
>   test/stdlib/tst-calloc.c   : build: OKrun: OK

But the test still fails on the buildd:

https://buildd.debian.org/status/fetch.php?pkg=dietlibc&arch=arm64&ver=0.34%7Ecvs20160606-5&stamp=1485384794&raw=0

  test/stdlib/tst-calloc.c   : build: OKrun: ERROR
> Test was expected to fail, ignoring.

RUN ERROR for test/stdlib/tst-calloc.c in variant pthreads (rc = 135), test 
output is:

Bus error


So the bug is still there...

Could you do me a favor, if you're on the porterbox anyway?
Could you install dietlibc-dev from sid in an schroot there,
and then compile tst-calloc.c with the diet built on the buildd?

diet -v -Os gcc -nostdinc -fstack-protector-strong -static \
   -o debian/unittests/ttt test/stdlib/tst-calloc.c \
   -lpthread
./debian/unittests/ttt

> Now, an alpha porterbox would be nice… (there’s none listed).

Yeah, especially since it builds fine in qemu-user alpha. (Well
the latest upload does, after I fixed a ton of alpha-related
bugs.) OTOH alpha is not a primary port, so I'm going to wait until
after the release of Stretch to take care of that. The arm64 issue
I would like to have fixed before the release.

Regards,
Christian

Bug#851379: dietlibc FTBFS on arm64: Bus error when running tst-calloc.c

[Christian Seiler]

Control: retitle -1 dietlibc: arm64: tst-calloc.c -lpthread fails with Bus error
Control: found -1 dietlibc/0.34~cvs20160508-1~exp3

Unfortunately I still haven't heard back from Front Desk about
a porterbox account (I'm a DM) for arm64, and I really can't
reproduce the issue in qemu on my system and I don't have
ARMv8 hardware.

Since this is not a regression (the bug was present also in the
current package in testing, there we just didn't run the unit
tests), I've done two things:

 - The latest upload expects the unit test to fail on arm64,
   so the package builds now.

 - I'm marking the bug as found in the first version of
   dietlibc that had arm64 support.

This way the package will be able to migrate and the other bug
fixes (RC and otherwise, both in -4 and -5) will be able to
get into testing before the freeze.

I do think 'serious' is an appropriate severity here though,
since the calloc test failing is really bad and could easily
break other software out there, so I"m keeping that.

Once I do get a porterbox account I'll debug this issue and
then coordinate with the release team during the freeze to
make sure this bug is properly fixed.

Regards,
Christian

Bug#850211: open-iscsi: Boot with systemd hangs for iSCSI+LUKS+LVM volume

[Christian Seiler]

Control: severity -1 important
Control: clone -1 -2
Control: reassign -2 systemd 230-7
Control: affects -1 cryptsetup
Control: affects -2 open-iscsi cryptsetup
Control: retitle -1 open-iscsi: No support for disabling LUKS volumes on 
shutdown
Control: retitle -2 systemd: cryptsetup-generator does not support LUKS on 
network devices
Control: tags -1 + confirmed stretch sid
Control: tags -2 + upstream

First of all, sorry for the late reply, but I was ill for a while and
then I was quite busy with catching up with other stuff.

The immediate bug you're experiencing is a problem with systemd, so I
am cloning the bug report and reassigning it to the systemd package.
However, in reviewing your setup I've also noticed that there is a
separate problem for your kind of setup in open-iscsi.

I'm including the main part of your bug report for the systemd
maintainers' benefit.

> This is how I setup my volume:
> 
> # The iSCSI part works fine.
> iscsiadm … --login
> 
> # Device shows up as /dev/sdb; I create a /dev/sdb1 partition using
> # fdisk, of type 8e.
> 
> # Create encrypted LUKS volume on /dev/sdb1, open and map as
> # /dev/mapper/sdb1_crypt.
> cryptsetup luksFormat /dev/sdb1
> cryptsetup luksOpen /dev/sdb1 sdb1_crypt \
> --key-file /root/blackbird-ullu
> 
> # Set up LVM PV, VG, and LV mapped to /dev/mapper/blackbird-ullu,
> # with an ext4 filesystem on top.
> pvcreate /dev/mapper/sdb1_crypt
> vgcreate blackbird /dev/mapper/sdb1_crypt
> lvcreate -n ullu -l 100%VG blackbird
> mkfs.ext4 /dev/mapper/blackbird-ullu
> 
> mount /dev/mapper/blackbird-ullu /media/nas
> 
> I have an entry in /etc/crypttab like this:
> 
> sdb1_crypt UUID=ae6b9263-d63c-4515-b7ce-51e5cc4caa9f /root/blackbird-ullu 
> luks
> 
> And an entry in /etc/fstab like this (I've tried various variants here,
> see below):
> 
> /dev/mapper/blackbird-ullu /media/nas ext4 defaults,nofail,_netdev 0 6
> 
> There are three devices involved:
> 
> - /dev/disk/by-uuid/: is the iSCSI target (/dev/sdb)
> - /dev/mapper/sdb1_crypt: result of cryptsetup luksOpen /dev/sdb1 
> - /dev/mapper/blackbird-ullu: LV built on top of sdb1_crypt
> 
> Now I suffer from the 90s wait on startup (before network-online), where
> systemd waits for the dev-mapper-blackbird\x2dullu.device to become
> available, along with dev-disk-by\x2duuid-.device and
> dev-mapper-sdb1_crypt.device.

The problem here is that the cryptsetup-generator in systemd only
supports local block devices, and the dependencies it generates
assume that everything orders indirectly before the local
filesystems.

This causes systemd to wait for the block device underlying the
LUKS encryption _before_ open-iscsi is even started.

This can clearly also be seen by the ordering cycle that's
generated if you manually force the dependencies:

> open-iscsi.service: Found ordering cycle on open-iscsi.service/start
> open-iscsi.service: Found dependency on network-online.target/start
> open-iscsi.service: Found dependency on networking.service/start
> open-iscsi.service: Found dependency on local-fs.target/start
> open-iscsi.service: Found dependency on lvm2-activation.service/start
> open-iscsi.service: Found dependency on cryptsetup.target/start
> open-iscsi.service: Found dependency on 
> systemd-cryptsetup@sdb1_crypt.service/start
> open-iscsi.service: Found dependency on 
> dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device/start
> open-iscsi.service: Found dependency on open-iscsi.service/start

Here you see that systemd-cryptsetup@sdb1_crypt.service depends
on open-iscsi.service (because of your manual dependency), but that
cryptsetup.target depends on systemd-cryptsetup@sdb1_crypt.service,
local-fs.target depends on cryptsetup.target and open-iscsi.service
(correctly) depends on local-fs.target.

Your trick in lowering the device timeout to 1s instead of the explicit
ordering makes this "work" because it causes systemd to immediately
fail systemd-cryptsetup@sdb1_crypt.service immediately at early boot
(before open-iscsi.service is started), and systemd will then start it
again once the device actually appears after open-iscsi logs in to the
target.

Ideally one would want to have an option like _netdev also for
/etc/crypttab, so that it's clear that this specific block device
will only appear later. Unfortunately that doesn't exist yet. [1] So
your workaround in explicitly lowering the device timeout (you can
just do that for
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device
btw., you don't need to set it for other devices) is the only thing
that will make this "work" currently though.





As for the open-iscsi bug I also noticed: on shutdown open-iscsi
tries to tear down all mounts on iSCSI, including layers such as LVM
or multipath, but it doesn't detect LUKS yet, so data may not be
written to disk properly once the iSCSI logout happens.

I plan on doing an upload of open-

Bug#852451: ITP: rname -- invoke a program under a different name

[Christian Seiler]

On 01/24/2017 04:19 PM, Peter Pentchev wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Peter Pentchev 
> 
> * Package name: rname
>   Version : 1.0.2
>   Upstream Author : Peter Pentchev 
> * URL : https://devel.ringlet.net/sysutils/rname/
> * License : BSD-2-clause
>   Programming Lang: C
>   Description : invoke a program under a different name
> 
> The rname utility invokes a specified program, passing a different name
> instead of the name of the program executable.  This could be useful in
> a number of cases, both during software development, testing, and in
> production use.  There are many programs that do different things based
> on what name they have been invoked under; the rname utility avoids
> the need to e.g. create ephemeral symlinks to run these programs in
> some conditions when they have not been completely installed.
> 
> I originally wrote this tool in 2000 and I'm resurrecting it now for
> the purpose of writing unit and integration tests for just such
> a multifaceted program.

This is definitely useful (I've needed this myself at multiple times),
but wouldn't it be better if this were part of coreutils or util-linux
or something similar?

Because say if I wanted to use that functionality in a package of mine
(for unit tests or similar), I'd probably not want to depend on a tiny
package just for this, especially since there are ways of doing the
very same thing with packages that are installed on most systems:

/bin/bash -c "exec -a $argv0 $progname $args"
perl -e 'exec {shift} @ARGV' $progname $argv0 $args
python3 -c 'import os, sys; os.execvp(sys.argv[1], sys.argv[2:])' \
$progname $argv0 $args

(The shell needs to be bash, mksh, zsh or similar to work; dash and
others don't support -a for exec.)

I would prefer a standalone program for this of course, but the pain
of the other solutions is not large enough for me that the trade-off
in depending on something non-standard makes sense to me.

Of course that's just my personal assessment, YMMV, and I'm not
opposed to you packaging this (what you provide is definitely useful),
but maybe this email gives you some food for thought about how to
best provide this functionality.

Regards,
Christian

Bug#851379: dietlibc FTBFS on arm64: Bus error when running tst-calloc.c

[Christian Seiler]

Control: tags -1 + confirmed

On 01/14/2017 02:30 PM, Adrian Bunk wrote:
> Source: dietlibc
> Version: 0.34~cvs20160606-4
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=dietlibc&arch=arm64&ver=0.34~cvs20160606-4&stamp=1483685322
> 
> ...
>   test/stdlib/testrand.c : build: OKrun: OK
>   test/stdlib/tst-calloc.c   : build: OKrun: ERROR
>   test/stdlib/tst-system.c   : build: OKrun: OK
> 
> RUN ERROR for test/stdlib/tst-calloc.c in variant pthreads (rc = 135), test 
> output is:
> 
> Bus error
> 

Yeah, I noticed that earlier. I've tried to reproduce this here, but
I don't have ARM hardware. (Not ARMv8 anyway.) I can't reproduce it
in qemu-user chroots and I've now tried to setup a full VM (via
qemu-system) but the test works there as well.

I suspect that "Bus error" stems from an unaligned memory access;
but this is one area where qemu is less strict than the CPU it
emulates...

I'll try to figure this out on a porterbox.

Regards,
Christian

Bug#844781: dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64

[Christian Seiler]

Control: tags -1 + pending

On 01/05/2017 12:17 PM, Christian Seiler wrote:
>> The correct solution is to change the name of the function to
>> __libc_waitpid in __waitpid.c and to define a weak alias for
>> waitpid there. I'm already working on this (saw your initial email
>> where you reassigned this), and will do an upload soon together
>> with regression tests for this.

Well, this was a rabbit hole. After also compiling the unit tests
against -lpthread I found a lot of other bugs on various
architectures. I'm now uploading a version that should most of
these issues (and work around the rest for now), so that this
immediate bug report can be closed, but there will have to be a
follow-up later to fix some of the other issues properly.

Regards,
Christian

Bug#850060: 2.0.874-2~exp1 issues

[Christian Seiler]

On 01/05/2017 07:10 PM, Andrew Patterson wrote:
> On 01/04/2017 04:11 PM, Christian Seiler wrote:
>> OTOH, initramfs should write to /run/initramfs only, so maybe
>> we should pass -p /run/initramfs/iscsiuio.pid to iscsiuio
>> instead as well.
> 
> Yes. I believe that will work. I wonder why this option is not in the
> man-page.

-ENOTIME on part of the developers perhaps. ;-)

>> The ideal solution would be to mirror the check that is done
>> for -b in -N. In that case we'd either configure the host
>> interface (and use software iSCSI), or configure offloading
>> (and use hardware iSCSI), but never both, and never neither.
>> So instead of the current patch for #850057 I would suggest
>> to do that instead. That should then also be upstream-able. I
>> can prepare a patch for that tomorrow.
> 
> That was my thought. However, I don't think you can programaticaly
> determine whether the card is configured for iscsi offload.

Well, according to the commit message I referenced in my
previous email [1], we have the following situation:

 - cxgb*i: always use offloading (which will apparently work,
   since offloading will reuse the MAC address)

 - bnx2*i: look at the MAC address to see if the MAC address
   from iBFT matches the offloading mac: if so, assume
   offloading, if not, assume software

 - otherwise: always assume software

This is what the code bracketed by -DOFFLOAD_BOOT_SUPPORTED
checks for, and we just need to mirror that code (or better:
extract into an own function and call it from both places)
for -b.

I'll prepare a patch, you can then test it.

[1] 
https://github.com/open-iscsi/open-iscsi/commit/ee115be828362653478e6fe7cd4c6ee3318223ff

> It looks like iscsuio is complaining about a missing libgcc:
> 
> writev(2, [{"libgcc_s.so.1 must be installed "..., 59]], 1) = 59
> 
> which is indeed missing.  I think pthreads needs libgcc, but shouldn't
> copy_exec take care of this?

Nope, since libgcc_s.so is dlopened() by pthread_cancel. So
the automatic library dependency detection doesn't work
properly.

We are not the only ones with that problem; luckily someone
already wrote a patch that does just this for btrfs, we can
just steal that:
https://bugs.debian.org/830883

I'll work on an updated package.

Regards,
Christian

Bug#850276: dietlibc: libpthread overrides __errno_location even with TLS enabled

[Christian Seiler]

Control: retitle -1 dietlibc: libpthread overrides __errno_location even with 
TLS enabled

I've now tracked this down: libpthread apparently overrode
__errno_location to point it to td->errno, where td is POSIX
thread descriptor. This is just plain wrong, because errno is
now a (TLS) variable, while in ancient dietlibc versions it
used to be defined as the dereference of said function.

However, syscalls still use that function to set the errno,
so any code checking errno would fail in that case.

Once I've made sure #844781 is fixed (and no other problems
have arisen in the mean time), this will be part of the next
upload.

Regards,
Christian

Bug#844781: dietlibc: waitpid broken w/ -lpthread on s390, s390x, mips64, ia64

[Christian Seiler]

Control: clone -1 -2
Control: retitle -2 Various regressions in unit tests when linking against 
-lpthread

On 01/05/2017 12:17 PM, Christian Seiler wrote:
> The correct solution is to change the name of the function to
> __libc_waitpid in __waitpid.c and to define a weak alias for
> waitpid there. I'm already working on this (saw your initial email
> where you reassigned this), and will do an upload soon together
> with regression tests for this.

So I now started to run the test suite by also linking against -lpthread
and found two test suite failures already on amd64 (haven't tried the
other platforms yet) if just -lpthread is added. Since none of the
test suite run uses pthreads directly, this is because weak symbol
overrides in the pthreads library cause unrelated functions to fail.
Yikes.

I'm cloning this bug report to track that problem separately.

Regards,
Christian

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

On 01/05/2017 01:18 PM, Martin Bagge / brother wrote:
> On 2017-01-05 13:04, Christian Seiler wrote:
>> The official package description appears to be:
> 
>> "Is retry allowed for Error?"
> 
>> And while that is still a bit vague, it does at least give an 
>> indication what the module does, while I have no idea what "my
>> prime module" is supposed to mean?
> 
>> I would urge you to use upstream's description when packaging this
>> module.
> 
> Well. They did.
> 
> https://github.com/floatdrop/is-retry-allowed/blob/8ca0d01b/package.json
> #L4
> reads
> 
> "description": "My prime module",

Yikes. My apologies, then at least now I get where that comes
from.

Still, the description on the github link appears to be the
one that's preferable to "my prime module". So thanks for
intending to fix this.

Regards,
Christian

Bug#850255: ITP: node-is-retry-allowed -- My prime module

[Christian Seiler]

Hi there,

Let me nitpick a bit: ;-)

On 01/05/2017 12:52 PM, saurabhagra...@disroot.org wrote:
> * URL : https://github.com/floatdrop/is-retry-allowed#readme
>   Description : My prime module

The official package description appears to be:

"Is retry allowed for Error?"

And while that is still a bit vague, it does at least give an
indication what the module does, while I have no idea what
"my prime module" is supposed to mean?

I would urge you to use upstream's description when packaging
this module.

Regards,
Christian

Bug#844781: #844781: libowfat FTBFS on s390x and mips64el: undefined reference to `__libc_waitpid'

[Christian Seiler]

Control: retitle -1 dietlibc: waitpid broken w/ -lpthread on s390, s390x, 
mips64, ia64
Control: tags -1 + confirmed
Control: tags -1 - patch

Thanks for reassigning this.

On 01/05/2017 11:48 AM, latinovic wrote:
> Both archs (s390x and mips64el) do not support waitpid, wait4 is used instead.
> (https://github.com/ensc/dietlibc/blob/master/s390x/__waitpid.c)
> As there is no waitpid system call for these archs, undefined reference to 
> `__libc_waitpid' appears.
> 
> In order to fix this it is needed to use wait4 syscall instead in 
> syscalls.s/waitpid.S.

Unfortunately, this is wrong, because then the flags parameter for
wait4 would be undefined and depend on the previous state of
program execution.

Also, dietlibc would then contain two copies of waitpid() on these
platforms, because that doesn't remove __waitpid.c from there.

Furthermore, ia64 is also affected because that contains a carbon
copy of s390's __waitpid.c. (Don't know which one was first.)

The correct solution is to change the name of the function to
__libc_waitpid in __waitpid.c and to define a weak alias for
waitpid there. I'm already working on this (saw your initial email
where you reassigned this), and will do an upload soon together
with regression tests for this. (The unit tests for dietlibc
do already do check for a working waitpid(), but unfortunately they
don't link against -lpthread.)

Regards,
Christian

Bug#850060: 2.0.874-2~exp1 issues

[Christian Seiler]

Control: reopen -1

Hi,
(reopening the bug report since iscsiuio doesn't actually work
according to what you're telling me)

On 01/04/2017 11:30 PM, Andrew Patterson wrote:
> 1. In debian/extra/initramfs.local-top and
> debian/extra/initramfs.local-bottom /sbin/iscsuio creates a pid file
> in /run/iscsiuio.pid. You cannot override it on the command-line. The
> --pidfile option for start-stop-daemon should point to this location
> instead of /run/initramfs/iscsiuio.pid.

Gah. I thought I had fixed that before the upload. :-(
A good thing there's experimental...

OTOH, initramfs should write to /run/initramfs only, so maybe
we should pass -p /run/initramfs/iscsiuio.pid to iscsiuio
instead as well.

> 2. The /sbin/iscsiuio deamon is trying to create a logfile in
> /var/log/iscsiuio.log. The /var/log directory does not exist in the
> initramfs.

Unfortunately that's hardcoded. OTOH from reading the code
this shouldn't be an issue.

> 3. The iscsiuio daemon is dieing before or during iscsistart -b. I am
> investigating why. It works fine when run after boot.

This is weird, on my test VM (no offloading NIC though) it
does start (and shut down again).

Question: does the network card require firmware for offloading
to work? If that's the case we might need to add the firmware
to the initramfs or this to work properly...

> 4. The commit 02c3051 "Don't ignore offloading NICs in iscsistart"
> will cause the interface to be configured in both iscsistart -N and in
> iscsistart -b for cards with iscsi hardware offload. I suspect we
> instead need a flag in iscsistart to bring up the NIC in iscsistart
> regardless if the NIC uses an offloadable driver. The local-top script
> can use this flag if /sbin/iscsiuio is not present, e.g.,
> 
> ISCSISTART_FLAGS=""
> if [ ! -x /sbin/iscsiuio ] ; then
>ISCSISTART_FLAGS="-S"
> fi

Hmm, now I see what you mean. I also dug up this commit which
gives a little insight.

https://github.com/open-iscsi/open-iscsi/commit/ee115be828362653478e6fe7cd4c6ee3318223ff

However, I think the solution is different from what you suggest: the
"fix" for #850057 is wrong I believe.

Debian sid package (w/o -DOFFLOAD_BOOT_SUPPORTED):

 - cxgb*i: iscsistart -N ignores interface
   iscsistart -b doesn't configure offloading
   => won't work

 - bnx2i (any mode): iscsistart -N ignores interface
 iscsistart -b doesn't configure offloading
   => won't work

Current upstream situation (w/ -DOFFLOAD_BOOT_SUPPORTED):

 - cxgb*i: iscsistart -N ignores interface
   iscsistart -b configures offloading 
   => should work
  (but don't have hardware)
  (also: remind me to check whether we copy the
  module into the initramfs)

 - bnx2i non-hba: iscsistart -N ignores it
  iscsistart -b doesn't configure offloading
   => won't work

 - bnx2i hba: iscsistart -N ignores it
  iscsistart -b configures offloading
   => should work (once iscsiuio is running)

"Fix" for 850057 (in experimental):

 - cxgb*i: iscsistart -N configures interface on host
   iscsistart -b configures offloading
 => no idea what happens thereafter
(since MAC address is the same on these cards: is
this a problem if they have the same IP?)

 - bnx2i non-hba: iscsistart -N configures interface
  iscsistart -b doesn't configure offloading,
but enables software iSCSI
  => should work

 - bnx2i hba: iscsistart -N configures interface
  iscsistart -b configures offloading
  => same IP, different MAC addresses
  => will cause trouble

The ideal solution would be to mirror the check that is done
for -b in -N. In that case we'd either configure the host
interface (and use software iSCSI), or configure offloading
(and use hardware iSCSI), but never both, and never neither.
So instead of the current patch for #850057 I would suggest
to do that instead. That should then also be upstream-able. I
can prepare a patch for that tomorrow.

That still leaves us with the question why iscsiuio doesn't
appear to work in the initramfs on your system. You could
just add strace to your initramfs and call iscsiuio in a
detached strace, a la

old:
start-stop-daemon ... /sbin/iscsiuio

new:
start-stop-daemon ... /bin/strace -- -D -f \
   -o /run/initramfs/iscsiuio.trace  -- /sbin/iscsiuio

(The first -- is for start-stop-daemon, the second one for
strace itself.)

Regards,
Christian

Bug#850060: open-iscsi initramfs scripts do not start up iscsiuio deamon

[Christian Seiler]

Hello,

Thanks for testing this, also for the long 13h test with
disabled iscsiuio. That gives me plenty of confidence that we
can just kill it in local-bottom and not care about it until
the system boots up - which makes our life _so_ much easier.

On 01/04/2017 06:53 PM, Andrew Patterson wrote:
> On 01/03/2017 03:47 PM, Christian Seiler wrote:
>> That said: your initial tests are sufficient for me to upload
>> a version of open-iscsi that includes support for this to
>> the 'experimental' suite, so I'll do that either tomorrow or
>> on Thursday, depending on when I'll find time for that. If you
>> could then test this (and write down how you set this up so
>> we can add it to README.Debian), and give me feedback on the
>> "iscsiuio is offline for longer" test, then I'd be fine with
>> uploading this to unstable so it makes it into Stretch.
>>
> 
> I would be happy to test it.

I've uploaded a version 2.0.874-2~exp1 to experimental that
contains these changes. I've tested this on a VM with rootfs on
iSCSI (no offloading) and that still works as before.

This should hit experimental soon and I expect that the
package will be available in about 2 - 3 hours after the next
dinstall run. (Later on some mirrors maybe.)

The changes seem mostly harmless to me, so I'm very confident
that this won't break existing use cases at the very least,
but an independent review and some testing would be very much
appreciated before I upload this to unstable.

Also, if this really does work, could you write a paragraph or
so for README.Debian on how to use iscsiuio offloading in the
initramfs?

Many thanks!

Regards,
Christian

PS: It's much too late in the Stretch release cycle for that,
but at the beginning of the Buster release cycle I'd like to
get support for ISCSI_AUTO into the Debian installer, as that
is likely to be the most common way that rootfs on iSCSI is
going to be set up. Plus maybe support iscsiuio in the
installer. With both of these changes, offloading should then
work out of the box.

Bug#850060: open-iscsi initramfs scripts do not start up iscsiuio deamon

[Christian Seiler]

On 01/03/2017 10:51 PM, Andrew Patterson wrote:
> On 01/03/2017 01:27 PM, Christian Seiler wrote:
>> On 01/03/2017 09:10 PM, Andrew Patterson wrote:
>>>> How does the rest of the boot process proceed then? What happens
>>>> when iscsiuio is to be started regularly at boot from the systemd
>>>> service / init script?
>>>> Is the iscsiuio from the initramfs required
>>>> to be running at all times during the iSCSI session or can it be
>>>> restarted, as long as the time during which that happens is brief
>>>> enough? Is it required to be kept around during shutdown if it's
>>>> on iSCSI?
>>>
>>> I don't believe it needs to be running to support traffic, just when
>>> doing logins. I will test to confirm.
>>
>> That would be ideal. :)
> 
> I tried running a load with a data integrity check while starting and
> stopping iscsiuio numerous times. I did not see any issues either
> with performance or data integrity.

Did you try stopping iscsiuio for longer periods of time? For
example more than 20 minutes? I would like to know what happens
if you hit ARP timeouts.

>> As far as I can tell from skimming the source iscsiuio is also
>> responsible for doing ARP and responding to ICMP  - but even
>> then it wouldn't be a problem for restarting in that case, as
>> long as the MAC address of the target (or a router on the way
>> to the target) doesn't change during restart.
>>
> 
> It this likely to be an issue in the one or two seconds between
> transitioning between the initramfs and sysvinit/systemd?

It's only a couple of seconds if there's no fsck running for
another partition. Then it could easily be minutes or even
longer, depending on the partition size, the number of files
and the filesystem in question.

>>>> Does it follow systemd's process name convention to make
>>>> sure systemd doesn't kill it during shutdown?
> 
> I don't see any special handling of iscsiuio in systemd shutdown.

I meant this:

https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/
(The @-stuff is only relevant if the binary is _not_ started
via a systemd service.)

OTOH, since iscsiuio is apparently not required to be running
while data is transferred, killing it at shutdown deosn't
seem to be that big of a deal.

> It looks like we can use start-stop-daemon in local-top and
> local-bottom to gracefully start and stop the daemon.

Yes, that appears to be the case.

>>>> Before I add the aforementioned steps 1 & 2 I'd like to be sure that
>>>> this actually works properly beyond the initramfs. So any
>>>> information related to that would be appreciated.
>>>
> 
> Is my current testing enough or do we need to do more? If the later,
> what sort of test would you like me to run?

See my request above: if after 20 minutes of iscsiuio being
offline everything is still fine, I'd be fine with it. If it's
less, it depends on how much less.

That said: your initial tests are sufficient for me to upload
a version of open-iscsi that includes support for this to
the 'experimental' suite, so I'll do that either tomorrow or
on Thursday, depending on when I'll find time for that. If you
could then test this (and write down how you set this up so
we can add it to README.Debian), and give me feedback on the
"iscsiuio is offline for longer" test, then I'd be fine with
uploading this to unstable so it makes it into Stretch.

Other than #850057: does iscsistart need additional changes to
work with iscsiuio? One would probably need to pass
-P iface.transport_name=bnx2i -P iface.net_ifacename=eth0
-P iface.hwaddress=aa:bb:cc:dd:ee:ff or similar, right?

Regards,
Christian

Bug#850060: open-iscsi initramfs scripts do not start up iscsiuio deamon

[Christian Seiler]

On 01/03/2017 09:10 PM, Andrew Patterson wrote:
>> How does the rest of the boot process proceed then? What happens
>> when iscsiuio is to be started regularly at boot from the systemd
>> service / init script?
>> Is the iscsiuio from the initramfs required
>> to be running at all times during the iSCSI session or can it be
>> restarted, as long as the time during which that happens is brief
>> enough? Is it required to be kept around during shutdown if it's
>> on iSCSI?
> 
> I don't believe it needs to be running to support traffic, just when
> doing logins. I will test to confirm.

That would be ideal. :)

As far as I can tell from skimming the source iscsiuio is also
responsible for doing ARP and responding to ICMP  - but even
then it wouldn't be a problem for restarting in that case, as
long as the MAC address of the target (or a router on the way
to the target) doesn't change during restart.

>> Does it follow systemd's process name convention to make
>> sure systemd doesn't kill it during shutdown?
>>
> 
> I am looking into this. One thought is to start the daemon, do the
> login, and then kill it. Then the normal sysvinit/upstart/systemd
> scripts can restart it normally.

If it's really just for logins: yes, we can do that. If it also
does ARP and such, I'd rather only kill it as close to the restart
as possible. But having the init script / systemd service (there
was never a native upstart job for it) kill the initramfs one
right before starting the own binary is easy, so if that's required
then that would also be fine.

It's going to be a lot trickier if we can't restart it at all.

>> Before I add the aforementioned steps 1 & 2 I'd like to be sure that
>> this actually works properly beyond the initramfs. So any
>> information related to that would be appreciated.
> 
> I am going to look at other package code to see how they handle daemon
> startup. NFS comes to mind.

NFS doesn't actually need a daemon running after the initial NFS
login, at least temporarily:

 - NFSv3 needs the to have portmap running on the client side, so
   that locking works. However, you can spoof that, which is what
   klibc does:

   
http://sources.debian.net/src/klibc/2.0.4-9/usr/kinit/nfsmount/README.locking/

   Basically you don't need the portmapper to be running at all
   until and actual file lock is taken.

 - NFSv4 doesn't need anything running on the client side to mount
   with sec=sys with raw UIDs. For idmapping you can use the
   request-key / nfsidmap kernel upcalls instead of idmapd (which
   is deprecated on the client side), so nothing needs to be
   running there either.

 - NFSv4 + Kerberos needs rpc.gssd running, but I've never seen
   root on Kerberized NFSv4 even being advertised. (You'd also
   need to have credentials with which you can get a Kerberos
   ticket in the initramfs + the tools to get the ticket for
   that to work.)

Regards,
Christian

Bug#850060: open-iscsi initramfs scripts do not start up iscsiuio deamon

[Christian Seiler]

Control: tags -1 + confirmed moreinfo
Control: severity -1 wishlist

On 01/03/2017 06:02 PM, Andrew Patterson wrote:
> Version 2.0.874 of the open-iscsi package requires that the iscsiuio
> daemon to be running before iscsi hardware offload cards can login to
> a LUN. The initramfs scripts used by open-iscsi to support boot from
> iSCSI do no start up this daemon resulting in a failed boot.

I'd really like to support this setup. My idea how this could work
would be along the lines of the following:

 1. In the local-top hook start iscsiuio before calling iscsistart -b
or iscsistart $params if the binary is present in the initramfs.

 2. In the iscsiuio package install a initramfs hook that copies the
iscsiuio binary (luckily it doesn't depend on any library) into
the initramfs.

Together that should start iscsiuio in the initramfs and allow
login to the targets there - but if iscsiuio is not installed, the
user won't see a difference from today.

However, there are still some questions I'd like to have answered
before proceeding - and since I don't have the corresponding hardware
I have no idea what the right answers are:

How does the rest of the boot process proceed then? What happens
when iscsiuio is to be started regularly at boot from the systemd
service / init script? Is the iscsiuio from the initramfs required
to be running at all times during the iSCSI session or can it be
restarted, as long as the time during which that happens is brief
enough? Is it required to be kept around during shutdown if it's
on iSCSI? Does it follow systemd's process name convention to make
sure systemd doesn't kill it during shutdown?

Before I add the aforementioned steps 1 & 2 I'd like to be sure that
this actually works properly beyond the initramfs. So any
information related to that would be appreciated.

Regards,
Christian

Bug#850057: iscsistart -N skips offload NICs causing boot to fail

[Christian Seiler]

Control: tags -1 + confirmed upstream

On 01/03/2017 05:38 PM, Andrew Patterson wrote:
> The debian initramfs uses the IBFT support in iscsistart to log
> into the root volume. The initramfs script uses iscsistart -N to
> bring up the NICs before logging in with iscsstart -b. This
> process works fine when using non-offload NICs, but fails when
> using NICs using the bnx2, bnx2x, cxgb3, and cxgb4 drivers due to
> the following code in
> utils/fwparam_ibft/fw_entry.c:fw_setup_nics():
> 
> list_for_each_entry(context, &targets, list) {
> /* if it is a offload nic ignore it */
> if (!net_get_transport_name_from_netdev(context->iface,
> transport))
> continue
> 
> 
> Which does a lookup in the table in usr/iscsi_net_util.c
> 
> static struct iscsi_net_driver net_drivers[] = {
> {"cxgb3", "cxgb3i" },
> {"cxgb4", "cxgb4i" },
> {"bnx2", "bnx2i" },
> {"bnx2x", "bnx2i"},
> {NULL, NULL}
> };
> 
> 
> to see if -N should skip this NIC.

Since I don't see how this would negatively affect setups that
work currently, I'd be willing to carry a patch in Debian that
simply removes this check, even if upstream hasn't decided on
a best course of action yet - especially since I didn't see
anybody on the upstream mailing list discouraging this.

Unless you beat me to it, I'll prepare a patch for this in the
Debian package.

Regards,
Christian

Bug#826215: Bug #826214: Bug #826215: init-d-script and systemd: solution

[Christian Seiler]

On 12/29/2016 01:59 PM, Petter Reinholdtsen wrote:
> [Martin Pitt]
>> "service", not invoke-rc.d, but I do agree that it would be better to
>> completely drop that magic. This would be a nice way to gradually teach 
>> people
>> about the init system neutral APIs, and also find/fix places which hardcode
>> calling /etc/init.d/.
> 
> Will service respect policy-rc.d?

No, by definition it won't (neither on sysvinit nor on systemd) - just like
/etc/init.d/foo start also does not respect policy-rc.d.

service is a tool for admins, and as such shouldn't be governed by
policy-rc.d. invoke-rc.d is a tool for maintainer scripts and as such
will be governed by policy-rc.d.

invoke-rc.d is basically the following logic (pseudo-shell):

if action is allowed for script by policy-rc.d ; then
  if [ -d /run/systemd/system ] ; then
systemctl action scriptname.service
  elif ... upstart ... ; then
...
  else
/etc/init.d/scriptname action
  fi
fi

service is basically the following logic (pseudo-shell):

if [ -d /run/systemd/system ] ; then
  systemctl action scriptname.service
elif ... upstart ...
  ...
else
  in_relatively_clean_context /etc/init.d/scriptname action
fi

> I believe I saw some systemd service
> failing to respect policy-rc.d in one of my chroots, and wonder if it
> was a bug in some package or not

In that case it's very likely a bug in the package's maintainer
script.

> For the record, I believe the /etc/init.d/ scripts should keep working
> also in the future, because I believe most of the around 1000 packages
> with init.d scripts in Debian do not need to have their scripts replaced
> and it is an advantage to have one common script across all the kernels
> Debian supports.

I don't think this is in question for now - but there are multiple layers
here:

 - what to do when only an init script is available and the service is
   to be started (e.g. at boot)

 => systemd will call the init script (and that will stay for a
long time, even systemd upstream is not going to remove
support for this anytime soon)

 - what to do when /etc/init.d/script action is called on the command
   line (instead of service script action or invoke-rc.d script action)

 => at the moment systemd installs some glue code to redirect this
to systemctl, but that fails at the moment for init-d-script
(this is #826214)

> It thus make me happy to see someone have time to work on improving the
> init-d-script approach. :

Pure egoism ;-) I really don't want to maintain boilerplate code in
my packages, so I like the idea behind init-d-script a lot, because it
makes it very easy for me to provide init scripts in additino to
systemd services (that nowadays are often provided by upstream).

Anyway, patches for #826214 and other issues will soon follow.

Regards,
Christian

Bug#826214: Bug #826214: Bug #826215: init-d-script and systemd: solution

[Christian Seiler]

Hi Andreas,


Sorry for not replying earlier, but I wanted to mull this over some
before answering.

On 12/27/2016 10:49 AM, Andreas Henriksson wrote:
> On Sun, Dec 25, 2016 at 01:34:41PM +0100, Christian Seiler wrote:
>> Hi there,
>> (Cc'd a lot of people, so that hopefully everybody relevant
>> is included.)
> [...]
> 
> The problem I pointed you to where only one out of many symptoms of the
> breakage introduced by using init-d-script. I think just attacking one
> specific symptom of one specific LSB hook is wrong.

So after reading your arguments I believe I agree with you.

> Following Martins advice and pushing this back into the original
> init-d-script is better, because that means this is confined in a single
> place.

Yes.

> I also have to point out that I completely disagree with you on
> minimal systems not being relevant to anyone.

I think you misunderstood me a bit, I'm not against making
the Debian base smaller (I use containers myself and them
requiring less stuff is definitely something I look forward
to) - but since that was in support of an argument for
something I'm now convinced it's not the right way, I'm
going to leave it at that.





After reading the other emails, maybe we can converge on the
following consensus / compromise?

For stretch:

 - I'll provide a patch for #826214 against init-d-script
   that will restore the original arguments while sourcing
   /lib/lsb/init-functions. This will make systemctl
   redirection work again for Stretch when using
   init-d-script.

 - We'll ignore #826215 for Stretch and scripts shipping an
   init-d-script based init script will hard-depend on
   sysvinit-utils regardless of systemd service
   availability. (As they do now.)

 - Add a warning to the output in systemd's
   /lib/lsb/init-functions.d/40-systemd and mention that
   calling init scripts directly on systemd systems is
   deprecated. (I can provide a patch.)

For Buster:

 - We revisit #826215 and say that packages that provide a
   init-d-script that has the same name as a systemd service
   need not depend on sysvinit-utils, and that if people
   want init-d-scripts called directly in /etc/init.d
   (when a corresponding systemd service also exists) to
   work on systemd systems, they also have to install
   sysvinit-utils, otherwise this just breaks.

   People using service / invoke-rc.d will not have any
   trouble, and people who really want to call the script
   directly via /etc/init.d have to install an additional
   package. (Or use sysvinit as the init system.)

For either Buster or Buster + 1:

 - Revisit init.d script redirection entirely and perhaps
   get rid of it. (Or not, we'll have to see.)

Would at least the Stretch part of that be agreeable for
everyone involved here?

Regards,
Christian

PS: I've also gone through the bug list against init-d-script
and have been working on fixing a couple of other issues. I
haven't posted anything in that regard yet because I wanted to
wait what came out of this discussion here first, because this
is the most important issue at the moment.

Bug#826215: Bug #826214: Bug #826215: init-d-script and systemd: solution

[Christian Seiler]

Hello Martin,

On 12/25/2016 09:18 PM, Martin Pitt wrote:
> Christian Seiler [2016-12-25 13:34 +0100]:
>> I think I have a solution to both issues - and my solution
>> does not require any change to any individual init script,
>> and best of all it doesn't even require changes to any
>> sysvinit-related package (we get to have our cake and eat
>> it too):
> 
> Thanks for working on this!
> 
>> The systemd package could install a diversion of /lib/init/init-d-script and
>> install its own wrapper.
> 
> I don't like this approach, to be honest. (1) This diversion would be present
> on practically all installs anyway, as it would (necessarily) be in the
> "systemd" binary, not the "systemd-sysv" one. (2) I don't want to maintain 
> this
> SysV stuff in the systemd package forever, AND still have someone else 
> maintain
> the non-diverted variant in sysvinit-utils. I'd much prefer to just change the
> "master" copy in sysvinit-utils, and packages which use that should grow a
> dependency to that (so that it can become non-essential).

But the reason why you want to make sysvinit-utils non-essential is to
be able to remove the package. But if a lot of packages now depend on
it, then this will be installed on most installs regardless, so there's
no point in making the effort of making it non-essential. (Unless you
are really only interested in minimalistic base systems that aren't
really useful to anybody.)

What's the alternative? Michael proposed to go back to the old
template for init scripts in the initial bug report and basically drop
init-d-script from packages. As someone who maintains packages that
contain daemons, I strongly disagree: one of the appeals of systemd
(which I use and like btw.) is that service files are easy to read.
Same goes for init scripts that use init-d-script instead of what was
there previously, they are much easier to read than the horrible mess
that was there previously. His alternative proposal is much better,
but apparently not something the init-d-script people want, for
understandable reasons, and in addition both suggestions would
require that lots of consumers of init-d-script change their code.

In the end, you're just distributing a single additional script with
the systemd package. The maintenance burden is going to be essentially
zero, because the interface of init-d-script can't change without all
of the consumers having to be updated. I think the whole integration
that makes shutdown while switching init systems work is probably a
lot more work than shipping this file + the diversion, even if that
diversion is going to be installed on most systems. (Which I don't
consider to be a problem, just look at the fact that /bin/sh is a
diversion on nearly all installed Debian systems, which is a lot more
essential to a running system than init-d-script.)

Also, consider the following: with how I wrote this wrapper, if _all_
installed init scripts use init-d-script _and_ have native systemd
service equivalents, then /lib/lsb/init-functions and
/lib/init/vars.sh also don't have to be installed on systemd systems,
because the wrapper will also work in those cases and properly
redirect to systemctl there. You can then get rid of all of the
sysvinit packages in that case - and just carry two files in the
systemd package, /lib/lsb/init-functions.d/40-systemd and the
wrapper I created, for compatibility reasons. This will make it quite
a bit easier to reduce the amount of installed packages on the system.

> I. e. use your script but patch the current one instead of duplicating it.

Well, my script doesn't duplicate the init-d-script logic at all. It is
just some glue code hat hooks up the upcall to systemctl (but reuses
existing code for that), and falls back to the original implementation
if systemd isn't used (or another corner case is hit).

> If the SysV init maintainers don't want to carry this either, then there's
> still the option to just drop the systemd integration, and break calling
> /etc/init.d/foo directly under systemd. WDYT?

I don't think that we should break that as long as we provide init
scripts in packages.

That all said: if you just want to fix #826214, I can also provide
a patch for the systemd package that updates
/lib/lsb/init-functions.d/40-systemd to properly work with
init-d-script - without you having to modify init-d-script or any
consumer thereof itself. But that won't help for #826215, when it
comes to how packages acquire dependencies on sysvinit-utils.

Regards,
Christian

Bug#826214: Bug #826214: Bug #826215: init-d-script and systemd: solution

[Christian Seiler]

Hi there,
(Cc'd a lot of people, so that hopefully everybody relevant
is included.)

Andreas Henriksson recently pointed me to the fact that there
are several problems with the current init-d-script in Debian
(which I use in my own packages to handle the non-systemd
cases), and he most prominently mentioned the problem that
with init-d-script systemctl redirection via direct calls to
the init script doesn't work properly (in contrast to normal
init scripts, where it does).

What bothered me is that many people (including Andreas) have
started suggesting not to use init-d-script because of its
problems but to rather use the previous template. I think
this is the wrong approach, because I'm perfectly happy in
maintaining something like:

http://sources.debian.net/src/open-isns/0.96-5/debian/open-isns-server.isnsd.init/
http://sources.debian.net/src/open-isns/0.96-5/debian/open-isns-discoveryd.isnsdd.init/

in my packages, but I would hate to have to maintain all of
the boilerplate code.

For this reason I promised Andreas that I'd take a closer look
at those and see what I can do.

I think I have a solution to both issues - and my solution
does not require any change to any individual init script,
and best of all it doesn't even require changes to any
sysvinit-related package (we get to have our cake and eat
it too):

The systemd package could install a diversion of
/lib/init/init-d-script and install its own wrapper. The
wrapper could check for systemd being run and properly handle
the redirect-to-systemctl case. On systems that have systemd
installed but are booted with something else the wrapper
would just source the original wrapper.

This has two distinct advantages:

 - diversions now work properly for init-d-scripts
   (fixes #826214)

 - scripts that use init-d-script _and_ have a native systemd
   service with the same name _and_ do _not_ implement custom
   verbs in the init script (do_unknown) don't need to depend
   on sysvinit-utils anymore. At the same time the entire
   init-d-script logic does _not_ need to be installed on
   such systems. (init-d-script packages without a native
   services still need the dependency though, as expected.)
   (fixes #826215)

I've developed a patch against current sid of the systemd
package and tested that on both systemd and sysvinit systems
extensively and made sure all of the code paths work.

The wrapper itself doesn't have much code, but I've added a
lot of comments to make sure that the corner cases (that are
all handled properly) are understood, so people modifying it
don't break it accidentally.

For the sysvinit people, to make it clear thst it doesn't
harmfully affect non-systemd systems: the basic structure of
the wrapper is the following:

#!/bin/sh
if [ -d /run/systemd/system ] ; then
  # do systemd-specific stuff
fi
. /lib/init/init-d-script.sysv
exit $?

I have tested the following (with real live packages):

 - systems booted with systemd, sysvinit-utils installed:
   redirection works as expected, custom verbs are still
   handled by init-d-script. The usage message is printed
   by the original init-d-script.

 - systems booted with systemd, sysvinit-utils not installed:
   redirection works as expected, the usage message is
   printed by the wrapper

 - systems booted with sysvinit, systemd not installed:
   everything still works

 - systems booted with sysvinit, systemd installed: the
   wrapper is a noop that just redirects to the original
   init-d-script

 - systems booted with sysvinit: installing a daemon,
   calling the init script, installing systemd (the package),
   calling the init script again, purging systemd, calling
   the init script yet again

I've done these tests multiple times with various different
packages and made sure I was hitting every code path of the
added code.

I've attached a git am'able patch against systemd's
debian/232-8 tag in git. Feedback welcome.

Regards,
Christian

PS: There is one corner case that is still open when it comes
to init-d-script and systemd, which is technically neither of
these bugs, but I feel I should mention it: if no native
systemd service is provided in addition to the init-d-script
init script, then systemd still doesn't properly detect
whether reload is possible for that service. I don't think
this is a huge issue, because that can easily be worked
around by providing a native systemd service in addition to
the init script. One could detect this properly by adding
support to detect this to systemd's sysv-generator (or add an
additional new generator), but I don't think that is worth
the effort.
From 63b96c5399280c22f58eb69c8b5eb874d4a2b497 Mon Sep 17 00:00:00 2001
From: Christian Seiler 
Date: Sun, 25 Dec 2016 10:36:51 +0100
Subject: [PATCH] Add wrapper for init-d-script

Divert the original /lib/init/init-d-script to init-d-script.sysv in
the same directory. An own wrapper is installe

Bug#780522: init-system-helpers: deb-systemd-helper doesn't handle drop-ins and is inconsistent w/ systemd w.r.t. lists

[Christian Seiler]

Version: 1.34
Control: tags -1 - moreinfo

On 12/21/2016 01:53 PM, Felipe Sateler wrote:
> Control: tags -1 moreinfo
> On Sun, 15 Mar 2015 15:23:38 +0100 Christian Seiler  
> wrote:
>> Package: init-system-helpers
>> Version: 1.22
>> Severity: important
>> Tags: patch
>>
>> deb-systemd-helper doesn't handle drop-ins at all (only the main
>> service file is parsed) and it doesn't treat lists properly: when
>> creating links for Alias=, it doesn't properly treat multiple entries
>> in the same line ($1 instead of $_ used), when removing links for
>> Also=, it assumes that there's only ever one entry per line, and it
>> doesn't support systemd's syntax to reset a list to empty (which native
>> systemd supports for the [Install] section entries).
> 
> So, lets recap. Upstream considers ignoring dropins in the [Install]
> section a feature. I think we should follow upstream here (if they
> change we should also change of course). Given that, there is only
> minor benefit to handling empty lists (it's unlikely a single file
> will reset a list defined the previous line). However, handling
> multiple words per line is important. However, since the fix in
> #820359 landed, I think we should be OK here.
> 
> So, should this be marked as done, or am I missing something more your
> patch does?

Yes, you're right. I was hoping to be able to work on a patch for
upstream to support drop-ins in this case, but I didn't get to
that.

Since I agree that this should follow upstream, I'm closing this
bug report for now. Should I be able to create a patch for upstream
that does this and get upstream to accept this, I'll reopen this
bug report.

Regards,
Christian

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Christian Seiler]

Hi there,

sorry for the formatting, writing this on my phone.


Am 23. Dezember 2016 10:18:52 MEZ, schrieb Andreas Henriksson 
:
>On Fri, Dec 23, 2016 at 12:12:17AM +0100, Christian Seiler wrote:
>>  - init.d: this file name works with dh_installinit, but is not
>>documented, so I'd recommend using llmnrd.init as the file name
>
>I see you're already credited by upstream so I assume you have
>already established a good relationship with your upstream.
>That's very good and very useful. Keep your upstream happy.
>Upstreams like contributions. You have a golden opportunity 
>on upstream issue #2.

I'm not sure that'll work. In contrast to systemd services init scripts are 
necessarily very distro-dependent. You can hack together something that's 
cross-distro, but that's really ugly.

Also, Debian (+ derivatives) is just about the only major distro that still 
supports traditional init scripts, except for maybe Slackware: Gentoo always 
had their own thing that wasn't compatible.

RH had /etc/sysconfig instead of /etc/default and had different includes for 
helper functions, just to give an idea what differences there are. SuSE hat yet 
another include library. RH didn't support LSB headers but had similar headers 
based on chkconfig to express dependencies.

>>  - init.d: any particular reason you don't use init-d-script? (See
>>current /etc/init.d/skeleton for how this works; it will
>>automatically source /etc/default/$scriptname and interpret the
>>DAEMON_ARGS variable, so your init script could probably be just
>>a couple of lines that set the name of the executable)
>
>I'd recommend *against* "init-d-script". It has several outstanding
>issues, is unmaintained/orphaned/unproven and AIUI that also means the
>init script becomes debian-only.

IMHO init scripts are distro-dependent anyway (see above). I didn't know about 
the issues in init-d-script and since I use that in my own packages, I'll look 
into that. Any pointers?


>>  - any reason you don't install the systemd service provided by
>>upstream in addition to the init script?
>
>Please do. Please also consider improving the systemd service
>shipped by upstream. (Another golden opportunity for upstream
>contributions.)
>Most importantly have a look at the User= directive as it seems
>like running unprivilegied is preferred (see upstream issue #4).
>See also the Restrict*= directives provided by systemd which
>would also be nice to limit the potential attack surface.

Ack.

>>  - you should probably add a line "export Q =" to debian/rules to
>>disable silent builds. While these look nicer, automated build
>>log scanners such as blhc aren't able to catch problems.
>
>debhelper today automatically disables silent rules when building
>on buildds. Using Q environment variables isn't the normal thing
>though.
>Even better than to explicitly disable silent build would be to
>hook up Q to the automatic debhelper version (V=1?).


Yeah, probably do something like

ifneq($(V),1)
Q?=@
endif

instead of just

Q?=@

in upstream's Makefile.

That said: I concur that these are all minor issues that can be fixed later and 
that d/copyright is the only blocker for an upload. And if this is to go into 
Stretch, the upload needs to happen today.

Since Andreas is willing to sponsor I'd recommend fixing that issue immediately 
and after Jan. 5th when it is in Stretch to fix the rest.

Regards,
Christian

Bug#849172: ondir: don't override Makefile variables, pass CFLAGS as environment variables instead

[Christian Seiler]

Package: ondir
Version: 0.2.3+git0.55279f03-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: Gianfranco Costamagna 

CFLAGS etc. should be passed in via environment variables (so that
dh_auto_build etc. work out of the box without an override), but
that needs changes to upstream's Makefile.

Once ondir has entered Stretch I plan on sending a pull request
upstream that updates the Makefile, and to package a new version
with a simpler debian/rules. Maybe that will even happen in time
before the Stretch freeze, but that is unclear.

Regards,
Christian

Bug#849173: ondir: FTBFS on hurd due to PATH_MAX

[Christian Seiler]

Package: ondir
Version: 0.2.3+git0.55279f03-1
Severity: important
Tags: confirmed

(Recording this so I don't forget it.)

ondir FTBFS on Hurd because it uses PATH_MAX, which isn't available
there (Hurd has no path limit).

Build log:
https://buildd.debian.org/status/fetch.php?pkg=ondir&arch=hurd-i386&ver=0.2.3%2Bgit0.55279f03-1&stamp=1482457296

I plan on doing an update for this at the beginning of the Buster
release cycle. (I don't want to mess things up by patching this in
Stretch so close to the freeze.)

Regards,
Christian

Bug#848993: RFS: llmnrd/0.2-1 [ITP]

[Christian Seiler]

Hi,

as announced on IRC, I'm just doing a review, since I'm not a DD
and can't sponsor:

 - packaging in a VCS would be nice to have (plus the appropriate
   Vcs-Browser / Vcs-... headers in d/control)

 - debian/copyright:

 * Tobias Klauser wasn't just active in 2016, the earliest
   copyright notice of his I could find in the package is
   from 2014; so s/2016/2014-2016/ there

 * missing mention of Copyright (C) 2012 Christoph Jaeger
   for pkt.h

 * missing mention of Copyright (C) 2009-2012 Daniel
   Borkmann for util.[ch]

 - debian/compat: why only 9? compat 10 is considered stable now
   and unless you have a good reason I would recommend that any new
   package should use compat 10. (please read the debhelper manual
   though for information on what changed between 9 and 10)

 - init.d: this file name works with dh_installinit, but is not
   documented, so I'd recommend using llmnrd.init as the file name

 - init.d: any particular reason you don't use init-d-script? (See
   current /etc/init.d/skeleton for how this works; it will
   automatically source /etc/default/$scriptname and interpret the
   DAEMON_ARGS variable, so your init script could probably be just
   a couple of lines that set the name of the executable)

 - any reason you don't install the systemd service provided by
   upstream in addition to the init script?

 - debian/rules: nice and clean, I like it

 - upstream's build system does git id to get the git revision of
   the current source - but that will clash if you have the packaging
   in git (which can happen implicitly when someone checks out the
   package source via e.g. dgit)

   Minor cosmetic thing, but makes the package non-reproducible
   depending on whether you build from unpacked .dsc or from a git
   environment

 - lintian warnings:
   W: llmnrd: binary-without-manpage usr/bin/llmnr-query
   W: llmnrd: binary-without-manpage usr/sbin/llmnrd


 - you should probably add a line "export Q =" to debian/rules to
   disable silent builds. While these look nicer, automated build
   log scanners such as blhc aren't able to catch problems.

 - Building in sbuild appears to work fine.

 - Package appears to work fine (though I don't have any llmnr
   device running at the moment, so I could only test name
   resolution of my own system)

Regards,
Christian

Bug#846306: RFS: ondir/0.2.3+git0.55279f03-1 [ITP]

[Christian Seiler]

Control: tags -1 - moreinfo

Hi Gianfranco,

I've uploaded an updated version of the package to mentors (and
also to git on alioth) that fixes these issues.

On 12/22/2016 12:29 PM, Christian Seiler wrote:
> On 12/22/2016 12:05 PM, Gianfranco Costamagna wrote:
>> 1) chmod a-x debian/ondir/usr/share/ondir/integration/*
>>
>> why no dh_fixperms override?
> 
> I forgot about dh_fixperms, will change that in the next iteration.

Done.

>> 2) 
>> CFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CPPFLAGS) $(shell 
>> dpkg-buildflags --get CFLAGS) -DVERSION=\"$(VERSION)\" 
>> -DGLOBAL_CONF=\"/etc/onddirrc\"
>>
>> I prefer CFLAGS and then CPPFLAGS
>> LDFLAGS_FOR_MAKEFILE=$(shell dpkg-buildflags --get CFLAGS) $(shell 
>> dpkg-buildflags --get LDFLAGS)
>>
>> why CFLAGS in LDFLAGS?

That wasn't actually required, so I dropped it. Additionally,
after thinking about what Peter said in this thread, I removed
the -DVERSION=... from this line and rather added it to a
DEB_CPPFLAGS_MAINT_APPEND, which seems cleaner to me.

>> 3) please ask upstream about the "+" in license
> 
> I've sent upstream an email about this.

I've done so, received a quick response that v2 or later is ok,
and added a comment to d/copyright.

Updated package available under:

https://mentors.debian.net/package/ondir
https://mentors.debian.net/debian/pool/main/o/ondir/ondir_0.2.3+git0.55279f03-1.dsc
gbp clone https://anonscm.debian.org/git/collab-maint/ondir.git

Regards,
Christian