Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13

[Lukas Schwaighofer]

Hi Philipp,

thanks for the pointers, I'll try to test the alternative patch you've
suggested within the week.


On Sun, 16 Oct 2022 09:20:37 +
Philipp Kern  wrote:

> Apparently I cannot test this within qemu OVMF (per [3] and it also
> didn't boot for me).

Interesting – this is how I tested syslinux efi builds in the past.
When filing this bug I was able to successfully boot with OVMF using
the builds currently installed in the archives, but not with the
freshly built versions.

Regards
Lukas

Bug#1004250: contents of syslinux binary package don't match syslinux-common

[Lukas Schwaighofer]

Hi Vangelis,

thanks for your report!

On Sun, 23 Jan 2022 17:32:34 +0200
Vangelis Koukis  wrote:

> After installing syslinux on a FAT32 fs:
> (...)
> I see the md5sum of ldlinux.c32 doesn't match the md5sum of
> /usr/lib/syslinux/modules/bios/ldlinux.c32:
> (...)
> 
> I don't know where syslinux/ldlinux.c32 comes from, I assume it's
> embedded in /usr/bin/syslinux, but
> /usr/lib/syslinux/modules/bios/syslinux.c32 comes from the
> syslinux-common binary package.

Your assumption is correct: ldlinux.c32 is embedded into the syslinux
installer binary and the embedded copy is copied into the target folder
during the installation.

syslinux.c32 does not get copied automatically by the installer. It
must have been copied either manually or by some other script from
/usr/lib/syslinux/modules/bios/syslinux.c32 (and thus the files are the
same).

> I understand there was a recent binary-only upload, which means the
> contents of the syslinux package no longer match the contents of
> the syslinux-common package.
> (...)
> The problem is that syslinux-common *also* contains binaries [the
> syslinux modules], and they no longer match.

I looked into this and found two more things that will cause the
ldlinux.c32 embedded into the installer to be different from the copy
shipped in the syslinux-common package even without the binary-only
non-maintainer upload (binNMU) you mentioned:

* Currently the debug symbols are stripped from the .c32 files after
  the build (dh_strip).  However the ldlinux.c32 copy that's
  embedded into the installer binaries gets included before the
  stripping and still includes the debug symbols.  This is arguably a
  bug.

* The syslinux-common package is an Architecture: all package. That
  means on both amd64 and i386 the same syslinux-common package is
  installed.  I don't believe the toolchains on both systems yield
  exactly the same .c32 files, and currently the Architecture: all
  packages seem to always get built on amd64.

> I think it makes sense to upload all syslinux binary packages from the
> same build to the repository, so everything aligns.

I hope to be able to make a new upload fairly soon (recently picked up
working on https://bugs.debian.org/994274 again), but for the reasons
above there will still be a mismatch between the files.

My understanding so far is that this is a cosmetic issue:  Both the
files built into the installer as well as the c32 module in
syslinux-common work.  Is there something more to this problem that I'm
missing?

Thanks and kind regards
Lukas


pgpZVS85X2Hkr.pgp
Description: OpenPGP digital signature

Bug#998515: arpwatch generates malformed emails.

[Lukas Schwaighofer]

Thanks for providing the details!  Unfortunately I still don't have a
good idea of what could be causing the broken/truncated mails you're
seeing.  I have a very similar setup and things are working fine here.


The way arpwatch creates and sends reports is roughly as follows:

* Create a temporary file in /tmp, immediately unlink it (but keep the
  file descriptor open).
* Write the report to that file descriptor.  The report has all the
  headers first, followed by two newlines and finally the body.
* Once finished writing the report, seek the file descriptor back to
  position 0, launch sendmail and pass the file descriptor to it as
  standard input.


Looking at the broken e-mails you attached, it appears that sendmail
doesn't receive the complete content of the report but it starts at
some offset (not always exactly the same).  I'm not yet sure how that
can happen.

Can you check that your filesystem in /tmp isn't (almost) full?  Also
make sure no other filesystem is (almost) full (I believe postfix
spools e-mails to somewhere in /var).


If that doesn't help, my best ideas are:

1. Launch arpwatch by hand using the `-d` flag but with otherwise same
   parameters. That should print the reports to standard error so we
   can see if those are truncated as well.

2. Write a dummy sendmail replacement that just copies the reports
   somewhere, then direct arpwatch to use that instead. Then check if
   those reports are truncated as well.

I'm happy to help with (2) if we're still uncertain after all the other
steps.

Thanks & regards
Lukas

Bug#998515: arpwatch generates malformed emails.

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Yanko,

thanks for your report!  Please help me to understand what's happening
by providing the following information:

* How exactly is arpwatch invoked? Please provide the output of
  `ps -U arpwatch -F` or (in case that doesn't show any processes)
  `ps -eF | grep arpwatch`.

* The output of `dpkg -S /usr/lib/sendmail` so I know which Debian
  package is providing the /usr/lib/sendmail binary installed in your
  system.

Thanks
Lukas

Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13

[Lukas Schwaighofer]

Source: syslinux
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: serious
Tags: ftbfs


With the new version of gnu-efi that was recently uploaded [1] to
unstable, syslinux fails to build from source.

So far I tried applying a simple fix from the upstream mailing list [2]
which result in a successful build, but the efi binaries from that
build are unbootable.


[1] 
https://tracker.debian.org/news/1257850/accepted-gnu-efi-3013git20210716269ef9d-2-source-into-unstable/
[2] https://www.syslinux.org/archives/2020-March/026621.html


pgpoVtnQq972G.pgp
Description: OpenPGP digital signature

Bug#994271: lintian: superfluous-file-pattern should not be issued for Files-Excluded in debian/copyright

[Lukas Schwaighofer]

Package: lintian
Version: 2.106.0
Severity: normal


Dear lintian maintainers,

running lintian 2.106.0 against syslinux I'm getting the following
warnings:

W: syslinux source: superfluous-file-pattern debian/copyright bios 
(Files-Excluded, line 8)
W: syslinux source: superfluous-file-pattern debian/copyright doc/rfc5071.txt 
(Files-Excluded, line 8)
W: syslinux source: superfluous-file-pattern debian/copyright efi32 
(Files-Excluded, line 8)
W: syslinux source: superfluous-file-pattern debian/copyright efi64 
(Files-Excluded, line 8)
W: syslinux source: superfluous-file-pattern debian/copyright gnu-efi 
(Files-Excluded, line 8)

These patterns are not superflous however, since they are read by uscan
and I'm using them exclude non-DFSG conforming files from the
upstream tarball.

Thanks
Lukas


pgpaZ58Ay3oyl.pgp
Description: OpenPGP digital signature

Bug#994088: lintian: dsc files from cwd are not processed correctly

[Lukas Schwaighofer]

Package: lintian
Version: 2.105.0
Severity: important


Dear maintainer,

I noticed that invoking lintian on a .dsc file in the current working
directory does not work in version 2.105.0:

$ lintian librtr_0.8.0-1.dsc
Warning in processable librtr_0.8.0-1.dsc: Use of uninitialized value $base in 
pattern match (m//) at /usr/share/lintian/lib/Lintian/Check/Fields/Source.pm 
line 54.
Warning in processable librtr_0.8.0-1.dsc: Use of uninitialized value $stem in 
string ne at /usr/share/lintian/lib/Lintian/Check/Fields/Source.pm line 56.
Warning in processable librtr_0.8.0-1.dsc: Use of uninitialized value $stem in 
concatenation (.) or string at 
/usr/share/lintian/lib/Lintian/Check/Fields/Source.pm line 56.
Warning in processable librtr_0.8.0-1.dsc: Source field does not match package 
name librtr !=  at /usr/share/lintian/lib/Lintian/Check/Fields/Source.pm line 
56.
warning: cannot run fields/source check on package source:librtr_0.8.0-1
skipping check of source:librtr_0.8.0-1

$ echo $?
1

It works as long as the path contains any `/`:

$ lintian ./librtr_0.8.0-1.dsc
$ echo $?
0

The issue seems to be a regex [1] that doesn't match an empty string
before the to be exracted basename.

Regards
Lukas

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/4dafe580d8403d1ca0de7bd82184a187ada2039c/lib/Lintian/Check/Fields/Source.pm#L53


pgppux6Rksrpe.pgp
Description: OpenPGP digital signature

Bug#993738: udev: symlink creation race condition can cause log delays

[Lukas Schwaighofer]

Hi,

> Thanks for finding that! I'll report back once I've had a chance to
> try this.

The attached PR is quite large and I wasn't able to apply it against
the version now in bullseye, and I don't want to change to a different
systemd/udev altogether. Carefully reading the descriptions I'm
confident that this is indeed the same issue. I have a workaround in
place now that doesn't have any drawbacks for me. I'll just stick with
that for now.

Thanks for your help
Lukas


pgpki4K5ItXCE.pgp
Description: OpenPGP digital signature

Bug#993738: udev: symlink creation race condition can cause log delays

[Lukas Schwaighofer]

Hi Michael,

thanks a lot for your quick response.

On Sun, 5 Sep 2021 19:44:15 +0200
Michael Biebl  wrote:

> So you create a lot of partitions which all have the same label?
> 
> Isn't this asking for trouble anyway as you can't be certain, which 
> device the /dev/disk/by-label/dummy will point to?

I'm using this in a virtualization setup. The LVs I use have a label of
"root", "var", etc. Within the VMs those are unique and are used
in /etc/fstab..  I don't care about these labels on the host system but
I'd like my system to not break if possible :) .

> Sounds like
> https://github.com/systemd/systemd/issues/20212
> 
> You might give the linked PR
> https://github.com/systemd/systemd/pull/20603
> a try

Thanks for finding that! I'll report back once I've had a chance to try
this.

Regards
Lukas


pgpXz6VYZdwMP.pgp
Description: OpenPGP digital signature

Bug#993725: cryptsetup-initramfs: LV activation disregards activation/auto_activation_volume_list setting

[Lukas Schwaighofer]

Hi Guilhem,

thanks for your quick response.

On Sun, 5 Sep 2021 17:04:06 +0200
Guilhem Moulin  wrote:

> Which concrete problem does this fix?  At initramfs stage only
> required devices (holding /, /usr, the resume device, or those
> explicitely marked ‘initramfs’) are unlocked and we *do* need to
> activate LVs in order to mount these.  So it's unclear to me what's
> the benefit of checking /etc/lvm/lvm.conf is — and a misconfigured
> LVM configuration file could lead to an unbootable system with this
> patch no?

Without the suggested patch it's impossible to prevent some LVs that
share the same volume group as e.g. the root partition from being
activated automatically. Concretely I was trying to work around a
different bug [1] by avoiding automatically opening some LVs using the
`auto_activation_volume_list` option in the lvm.conf. I was surprised
to still see all my LVs activated (and thus the bug triggered,
rendering my system unbootable).

Indeed, if somebody changed their `auto_activation_volume_list` to not
contain the necessary partitions during boot, that would render their
system unbootable.  I believe this is the correct behavior, and this
would also happen in a pure LVM setup since the script from the LVM2
package uses the `-a ay` flag [2].

I've since found a different work around for the original bug I've been
trying to solve, so this is no longer critical for me. I understand you
have to weight the risk of rendering systems unbootable vs having an
option not work exactly as documented, so feel free to close this if
you feel it's not appropriate.

Thanks
Lukas

[1] https://bugs.debian.org/993738
[2] 
https://salsa.debian.org/lvm-team/lvm2/-/blob/master/debian/initramfs-tools/lvm2/scripts/local-top/lvm2#L23


pgpyb0ZI5hPqo.pgp
Description: OpenPGP digital signature

Bug#993738: udev: symlink creation race condition can cause log delays

[Lukas Schwaighofer]

Package: udev
Version: 247.3-6
Severity: important


Dear systemd/udev Maintainers,

I've noticed a race condition with udev symlink creation, that can
cause long delays when activating logical volumes in LVM. Steps to
reproduce the problem (needs root):

# prepare
truncate -s 1G test.img
loop="$(losetup --show -f test.img)"
echo "Loop device used: $loop"
pvcreate "$loop"
vgcreate vgtest "$loop"
# create 50 LVs with an ext4 fs, all with same label
# (increase the number to make the problem more sever)
for i in `seq 0 49` ; do
  lvcreate -L 4M -n dummy-${i} vgtest
  mkfs.ext4 -L dummy /dev/vgtest/dummy-${i}
done
# set all LVs in vgtest as inactive
vgchange -an vgtest

# trigger the problem by activating all lvs with the same label at
# once (run `journalctl -f` in a different shell to see log
# messages)
vgchange -ay vgtest
# can be repeated by setting as inactive and then active again

# cleanup
vgchange -an vgtest
losetup -d "$loop"
rm test.img


Observe that the activation takes a very long time. The log is flodded
with messages like

dm-??: Failed to update device symlinks: Too many levels of symbolic links

The devices are opened only very slowly (observe by running
`ls /dev/vgtest` while the activation is in progress).  This has
rendered one of my systems unbootable (wait for one of the necessary
volumes times out during boot).

I've temporarily worked around the issue by disabling the "by-label"
symlinks in udev for device mapper devices:

sed '/by-label/ s/^/#/' \
  /lib/udev/rules.d/60-persistent-storage-dm.rules \
  > /etc/udev/rules.d/60-persistent-storage-dm.rules
udevadm control --reload

Notice how the activation now is very fast. To undo this workaround
remove /etc/udev/rules.d/60-persistent-storage-dm.rules and reload udev
rules again.

The same issue is *not* present in the udev version from buster
(241-7~deb10u8).

Thank you
Lukas Schwaighofer


pgp7lJETh0lyP.pgp
Description: OpenPGP digital signature

Bug#993725: cryptsetup-initramfs: LV activation disregards activation/auto_activation_volume_list setting

[Lukas Schwaighofer]

Package: cryptsetup-initramfs
Version: 2:2.1.0-5+deb10u2
Severity: important
Tags: patch


Dear Maintainer,

I noticed that LV activation done as part of the provided initramfs
scripts disregards the activation/auto_activation_volume_list setting
in /etc/lvm/lvm.conf.

To fix the issue please consider applying the attached patch. Quoting
from man lvchange(8) to explain the change:

> ay specifies autoactivation, in which case an LV is activated only if
> it matches an item in lvm.conf
> activation/auto_activation_volume_list. If the list is not set, all
> LVs are considered to match, and if if the list is set but empty, no
> LVs match. Autoactivation should be used during system boot to
> make it possible to select which LVs should be automatically
> activated by the system.  See lvmlockd(8) for more information
> about activation options ey and sy for shared VGs.

Thank you
Lukas Schwaighofer
diff --git a/debian/initramfs/scripts/local-top/cryptroot b/debian/initramfs/scripts/local-top/cryptroot
index 1da5ad1f..c348cf7f 100644
--- a/debian/initramfs/scripts/local-top/cryptroot
+++ b/debian/initramfs/scripts/local-top/cryptroot
@@ -189,7 +189,7 @@ setup_mapping() {
 return 1
 elif vg="$(lvm pvs --noheadings -o vg_name --config 'log{prefix=""}' -- "$dev")"; then
 # activate the VG held by the PV we just unlocked
-lvm lvchange -a y --sysinit -- "$vg"
+lvm lvchange -a ay --sysinit -- "$vg"
 fi
 fi
 


pgp6VF67rk7CZ.pgp
Description: OpenPGP digital signature

Bug#957858: syslinux GCC-10 patch

[Lukas Schwaighofer]

I was kindly pointed to
  https://bugzilla.suse.com/show_bug.cgi?id=1166605#c5
privately (thanks!), which explains that __builtin_strlen is not
actually a "builtin" and relying on that without providing a strlen
implementation is not correct (and in fact broken with GCC-10).

I'm updating the patch's description accordingly and will upload this
to unstable.


pgpExDJ9Njld8.pgp
Description: OpenPGP digital signature

Bug#920356: postfix: "man lmtp" fails with "man: can't open /usr/share/man/man8/smtp.8: No such file or directory"

[Lukas Schwaighofer]

Control: reopen -1 !
Control: notfixed -1 3.3.2-2

Dear Maintainer,

this was redirected to "smtp.8debian" instead of "smtp.8postfix" so the
issue is still present:

$ man lmtp
man: can't open /usr/share/man/man8/smtp.8debian: No such file or
directory No manual entry for lmtp

Thanks
Lukas

Bug#944679: extlinux: Visual bugs while editing a long kernel command line

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Mikhail,

apologies for the long delay, there was a lot going on the before winter
holidays.

On Wed, 13 Nov 2019 17:59:13 +0100
Mikhail Morfikov  wrote:

> My current kernel command line is about 400-character long. When it
> was shorter, I didn't have any issues when I wanted to edit this line
> in the bootloader screen by selecting some entry and pressing "E".
> 
> I recently added some other kernel parameters to the cmd line, and I
> noticed many visual bugs in the bootloader screen. Basically with
> each cursor movement (back and forth), I get an extra text line in
> the screen output (copy of the current line scrolled up). Also
> characters in the cmd line disappear or change when I move the cursor
> back. The visual bugs make it almost impossible to edit the kernel
> cmd line. Also When I press the backspace key (or the back arrow key)
> for a longer period of time (let's assume I want to delete some
> parameters entirely from the line), I hear the hardware beeper which
> is really annoying.
> 
> I found out that the problem appears when I have more than 4 lines of
> text on the screen when editing the cmd line. So fifth (and next
> ones) will trigger the visual bugs, while 4 (and less) won't.

I'll look into this and try to reproduce this within the next few days.
To speed things up, can you provide me with your configuration?

If you're able to perform some test, can you check whether the
behavior is consistent when using a different UI modules (menu.c32 or
vesamenu.c32).

Thanks
Lukas

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

On Wed, 30 Oct 2019 22:41:48 +0100
Sven Joachim  wrote:

> On 2019-10-30 21:03 +0100, Lukas Schwaighofer wrote:
> > I'm suspecting that there is somehow a mismatch between the version
> > of syslinux/extlinux used while installing (i.e. running `extlinux
> > -i`) and the c32 files installed on the medium.  
> 
> Indeed, this was the case.  While the version of syslinux installed in
> the boot sector was the one from Debian, the support files in the
> boot/syslinux directory came from the grml iso.  After replacing them
> with the files from /usr/lib/syslinux/modules/bios/ everything was
> fine.
> 
> > Can you check whether the c32 files installed on the medium
> > (probably in /boot/syslinux or /boot/extlinux) match the one
> > from /usr/lib/syslinux/modules/bios on the host system? If they do
> > match, can you re-run the syslinux installation from the host system
> > and then try again?  
> 
> They do not match, but I have a question: how would I get those files
> onto the boot medium with syslinux commands?  The naive command
> "syslinux -d boot/syslinux /dev/sdc1" (or whatever device instead of
> /dev/sdc1) does not do that, yet grml2usb apparently relies on it.

Unfortunately syslinux does not offer any "installer" to do that (nor
does the Debian package).  The admittedly poorly documented installation
procedure is more or less to run the installer and copy any modules you
need yourself to the correct folder.

`syslinux -d boot/syslinux /dev/sdc1` does not install any c32 modules.
This means any c32 modules present on your medium were copied by
grml2usb.  I don't know the details of how grml2usb installs syslinux,
but they need to make sure whatever is installed to the volume boot
record (`syslinux` or `extlinux` command) is consistent with the c32
modules.  Either both must come from the host system or both from the
installed medium.

Regards
Lukas

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Sven,

thanks for your report!

On Wed, 30 Oct 2019 18:58:12 +0100
Sven Joachim  wrote:

> Today I built myself a USB stick with grml on it (see #943838 for the
> problems I had with that).  When booting an old 32-bit laptop with
> this stick syslinux threw some error messages before its prompt:
> 
> ,
> | Undef symbol FAIL: x86_init_fpu
> | Failed to load libcom32.c32
> | Failed to load COM32 file vesamenu.c32
> | boot:
> `

I'm unable to reproduce this at the moment using the syslinux version
3:6.04~git20190206.bf6db5b4+dfsg1-1 .

I'm suspecting that there is somehow a mismatch between the version of
syslinux/extlinux used while installing (i.e. running `extlinux -i`)
and the c32 files installed on the medium.

Can you check whether the c32 files installed on the medium
(probably in /boot/syslinux or /boot/extlinux) match the one
from /usr/lib/syslinux/modules/bios on the host system? If they do
match, can you re-run the syslinux installation from the host system
and then try again? Is the image bootable when using `qemu-system-i386`?

If all of the above does not help narrow down the problem, can you
provide me with the necessary commands to build a similarly broken image
myself?

Thanks for your help
Lukas

Bug#930919: dovecot: dsync broken for sieve filters

[Lukas Schwaighofer]

Hi James,

On Fri, 6 Sep 2019 11:07:20 +0100
James Beck  wrote:

> I tested a local build with that patch and I don't think it is a
> complete fix.  In our setup, it stalls replication for our webmail
> users who use the Roundcube sieve plugin:
> 
> Sep 05 23:21:04  dovecot[12574]: doveadm: Error:
> Exporting mailbox INBOX failed: Mailbox attribute
> vendor/vendor.dovecot/pvt/server/sieve/files/roundcube lookup failed:
> Mailbox attributes not enabled

I also got this error when migrating my configuration from stretch to
buster and added the following setting to my 10-mail.conf:

mail_attribute_dict = file:~/dovecot-attributes

Not sure why that setting is needed in my setup to be honest, and the
dovecot-attributes file doesn't ever seem to get created. But the error
was gone after adding it.

> It's possible that our Roundcube configuration is doing something odd
> with sieve, but sieve filter replication with this setup worked before
> this bug was introduced.


I just tested creating, editing and removing a sieve config via
roundcube's sieve plugin (using roundcube from Debian buster) and
everything went smoothly.

I'm running a custom build of dovecot with the referenced patch
cherry-picked for a few weeks now (I recently updated it to version
1:2.3.4.1-5+deb10u1 because of the security fix). I haven't noticed any
issues.

Regards
Lukas

Bug#931544: Arpwatch not working properly (bug) on Debian 10.0 (Buster)

[Lukas Schwaighofer]

Hi,

thanks for your report.

On Tue, 06 Aug 2019 01:58:43 +1100
Dev  wrote:

> Arpwatch not working properly (bug) on Debian 10.0 (Buster)
> (...)

There has been an intentional change on how arpwatch is started in
buster.  From the NEWS file (you should have seen the content of this
during the upgrade):

  Starting with version 2.1a15-3, arpwatch ships with systemd unit
  files.  The change requires manual steps after the upgrade.

  The `/etc/arpwatch.conf` file, which can be used to specify different
  configuration options for multiple interface, is replaced by
  individual configuration files for each interface.  If you have
  configured arpwatch using `/etc/arpwatch.conf` file, you need to
  convert this to the new format.  See `/etc/arpwatch/README` for
  details.

  After the upgrade, arpwatch will not be started by default. You need
  to specify the interface(s) to run on, see `/etc/default/arpwatch` for
  instructions.  If your database file in `/var/lib/arpwatch/` is called
  `arp.dat` you need to rename it to `IFACE.dat` (where IFACE is the
  name of the interface you configured arpwatch to run on) if you want
  to keep your current arp database.  Also, make sure to drop the `-i`
  option from ARGS if you were using that to specify the interface.

The instructions from /etc/default/arpwatch that have already been
quoted in this bug are:

# when using systemd you have to enable arpwatch explicitly for each
# interface  you want to run it on by running:
# systemctl enable arpwatch@IFACE
# systemctl start arpwatch@IFACE

> 1) File " /VAR/LIB/ARPWATCH/ARP.DAT " is not created
> (...)
> 2) /etc/init.d/arpwatch status display "service is running" but it's
> not running
> (...)

Reverting the changes you made to the systemd unit file and following
the instructions above to enable arpwatch on the interface(s) you want
should solve both your issues.

Regards
Lukas

Bug#933299: isohybrid.pl should not be architecture dependent

[Lukas Schwaighofer]

Hi Timothy,

thanks for reporting.  The whole file organization of syslinux (both
which file is in which package, as well as the location of files) needs
improvement.  This is something I intend to work on during the bullseye
cycle.

As part of that, I'll also look into whether we need both the perl
script and the binary of "isohybrid" and in which package they should
be placed.  It'll still be a while until I get to it though (most
likely towards the end of this year).


@Thomas: If I remember correctly, isohybrid.pl only needs perl-base
(which is an essential package and does not require a dependency).
I'll double check that too.

Regards
Lukas

Bug#930919: dovecot: dsync broken for sieve filters

[Lukas Schwaighofer]

Source: dovecot
Version: 1:2.3.2-1
Severity: important
Tags: upstream patch

Dear Maintainer,

starting with Debian version 1:2.3.2-1, dsync no longer syncs sieve
filters.  Incoming syncs for sieve changes made on older servers (e.g.
using dovecot from stretch) are still synced, but changes made on
broken versions are not synced to any other server.

All newer versions, including 1:2.3.4.1-5, are affected. The problem has
been fixed upstream with the following commit:
https://github.com/dovecot/pigeonhole/commit/0e91911d22d43621c820d7f5b28be671050fd290

I've just re-built and tested the 1:2.3.4.1-5 package with that patch
applied and confirmed that it fixes the problem (sieve script sync works
both ways again).

Thanks
Lukas

Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'

[Lukas Schwaighofer]

Control: tags -1 + confirmed patch

Hi Andreas,

On Fri, 3 May 2019 14:21:06 +0200
Andreas Steinel  wrote:

> In version 6.04~git20190206.bf6db5b4+dfsg1-1, the bug that was closed
> in 6.04~git20171011.af7e95c3+dfsg1-6 is back - at least in the 64-bit
> UEFI part, legacy works fine:
> 
> Full log is:
> 
> Undef symbol FAIL: memset
> Failed to load libcom32.c32
> Failed to load COM32 file vesamenu.c32

Thanks for your report.  I've looked at it and can confirm that this
error is back :( .  The good news is only the backports version is
affected and not the version in buster (CC-ing Holger who is the
backports maintainer).

The problem is that the syslinux.efi binary uses the memset and memcpy
implementation from gnu-efi which are incompatible and cause the error
above. It should use the implementation from syslinux instead.

Since the linker has two symbols to choose from, I had added the
`-zmuldefs` flag.  My guess is that the linker from stretch picks the
"wrong" symbol.  I expected the linker would always pick the first one
it encounters which would be the "right" symbol (and that's what
happens in buster).

I've attached a modification of the 0005-gnu-efi-version-compatibility
patch.  Instead of using `-zmuldefs` I'm stripping the memset and memcpy
symbols from gnu-efi so there are no longer any duplicate symbols.
Using that I was able to build a version without that bug for backports.


Holger: Can you take care of updating the backports version? I've run
my little hacky regression-testing script on the modified backports
build and it passed all my tests.

Regards
Lukas
Repack libefi.a to not contain the memset and memcpy symbols to make sure the
implementation from syslinux is used and no multiple symbol definitions are
present.
---
 efi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/efi/Makefile
+++ b/efi/Makefile
@@ -43,8 +43,10 @@
 	fs/pxe/pxe.o fs/pxe/tftp.o fs/pxe/urlparse.o fs/pxe/dhcp_option.o \
 	fs/pxe/ftp.o fs/pxe/ftp_readdir.o fs/pxe/http.o fs/pxe/http_readdir.o)
 
+LIBEFI_STRIPPED = $(objdir)/libefi_stripped.a
+
 LIB_OBJS = $(addprefix $(objdir)/com32/lib/,$(CORELIBOBJS)) \
-	$(LIBEFI)
+	$(LIBEFI_STRIPPED)
 
 CSRC = $(sort $(wildcard $(SRC)/*.c))
 OBJS = $(subst $(SRC)/,,$(filter-out %wrapper.o, $(patsubst %.c,%.o,$(CSRC
@@ -73,6 +75,13 @@
 syslinux.so: $(OBJS) $(CORE_OBJS) $(LIB_OBJS)
 	$(LD) $(LDFLAGS) --strip-debug -o $@ $^ -lgnuefi -lefi
 
+$(LIBEFI_STRIPPED): $(LIBEFI)
+	cp $(LIBEFI) $(LIBEFI_STRIPPED)
+	ar x $(LIBEFI_STRIPPED) init.o
+	strip -N memset -N memcpy init.o
+	ar r $(LIBEFI_STRIPPED) init.o
+	rm init.o
+
 # We need to rename the .hash section because the EFI firmware
 # linker really doesn't like it.
 # $(OBJCOPY) --rename-section .gnu.hash=.sdata,load,data,alloc $^ $@

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

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Wolfgang,

thanks for reporting!

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

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

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

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

Regards
Lukas

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

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

[Lukas Schwaighofer]

On Sun, 9 Dec 2018 12:48:30 +0100
Lukas Schwaighofer  wrote:

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

I messed up the patch formatting, corrected below.  Sorry for the noise.


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

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

[Lukas Schwaighofer]

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


Dear Maintainer,

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

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

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


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


Thanks
Lukas

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

[Lukas Schwaighofer]

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

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

[Lukas Schwaighofer]

Hi Marco,

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

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

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

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

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

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

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

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

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

[Lukas Schwaighofer]

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

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

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

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

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

[Lukas Schwaighofer]

Hi,

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

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

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

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

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

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

[Lukas Schwaighofer]

Hi,

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


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

Regards
Lukas

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

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Santiago,

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

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

Thanks for your report
Lukas

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

[Lukas Schwaighofer]

Hello Alexander,

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

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

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

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


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

Sorry I'm not able to offer more help.

Have a nice weekend
Lukas

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

[Lukas Schwaighofer]

Hello Roland,

thanks for your report!

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

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

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

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

Thanks & regards
Lukas


pgp3Vf_tVu0cn.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Hi again,

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

#!/bin/sh

set -e

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

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

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

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

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

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

[Lukas Schwaighofer]

Hi Laurent,

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

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

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

Hi Christian,

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

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

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

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

Thanks
Lukas

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

[Lukas Schwaighofer]

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

Hi Julian,

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

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

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

Thank you
Lukas

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

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

[Lukas Schwaighofer]

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

Dear release team,

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

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

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

Thank you
Lukas

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


pgpAzL2gJ0DSE.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

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

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

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

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


Dear release team and other involved parties,

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

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

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

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

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

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

Thank you for your time and consideration
Lukas

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

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


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


pgpJPmd3tH00c.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Hi Marek,

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

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

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

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

Regards
Lukas

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

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

[Lukas Schwaighofer]

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

Hi,

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

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

Regards
Lukas


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

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

[Lukas Schwaighofer]

Hi Thomas,

thanks for pushing this forward :) .

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

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

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

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

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

Well, deb package can be downloaded from 

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

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Marek & Peter,

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

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

Regards
Lukas

Bug#805268: Adoption of syslinux

[Lukas Schwaighofer]

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

Hi,

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

Regards
Lukas

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

[Lukas Schwaighofer]

Package: devscripts
Version: 2.17.10
Severity: minor

Hi,

the uscan(1) man page states:

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

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

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

Thanks
Lukas

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

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

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

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

All the best
Lukas

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

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Regards
Lukas

Bug#876667: RFS: pragha/1.3.3-1

[Lukas Schwaighofer]

Hi Gabriel,

thanks for improving upon our suggestions.

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

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

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

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

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

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

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

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

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

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


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

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

Package: nm.debian.org
Severity: important

Hi,

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

Thanks
Lukas

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

[Lukas Schwaighofer]

Package: nm.debian.org
Severity: minor

Hi,

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

Thanks
Lukas

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

[Lukas Schwaighofer]

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


Dear libpcap maintainer,

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

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

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

Thanks
Lukas

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

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

[Lukas Schwaighofer]

Hi,

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

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

Regards
Lukas

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

[Lukas Schwaighofer]

Hi Timo,

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

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

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

Thank you
Lukas

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

Bug#772731: nmap -O causes occasional kernel panic

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Gary,

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

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

Thanks
Lukas

Bug#535441: nmap fails on large range scan

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Miguel,

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

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

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

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

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

Regards
Lukas

Bug#396062: nmap does not work on distant host

[Lukas Schwaighofer]

Control: tags -1 + moreinfo unreproducible

Hi Fabrice,

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

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

Thanks & regards
Lukas

Bug#501371: nmap: failed to determine route

[Lukas Schwaighofer]

Hi Michael,

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


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

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


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

Thanks & Regards
Lukas

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

[Lukas Schwaighofer]

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

Hi Sheridan,

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

Thanks
Lukas

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

[Lukas Schwaighofer]

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

Dear maintainer,

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

I've added a suggestion as patch.

Thank you
Lukas Schwaighofer

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


pgpnWunSc87O_.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Hi Adrian,

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

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

Indeed.

> A fix is attached.

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

 mount.o: mount.h

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

Hopefully that fixes all the parallel FTBFS now…

Thanks & Regards
Lukas


pgp9YjhQHOklz.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

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

Hi,

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

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

Regards
Lukas

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


pgpLTWoFSa3ar.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Control: severity -1 wishlist

Hi Thomas,

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

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

I'm lowering the severity to wishlist.

Regards
Lukas

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

[Lukas Schwaighofer]

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

My last commit accidentally increased the Debian version, corrected.


pgpDeA3pvxDKQ.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

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

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

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

Thanks & Regards
Lukas


pgpI2mSSVlRxa.pgp
Description: OpenPGP digital signature

Bug#862149: arpwatch starts before networking is ready

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi again,

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

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

Regards
Lukas


pgpwYK8L3bNnx.pgp
Description: OpenPGP digital signature

Bug#862149: arpwatch starts before networking is ready

[Lukas Schwaighofer]

Hi,

thanks for reporting this issue.

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

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


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


Thanks & regards
Lukas


pgpvtnuPrw5Lx.pgp
Description: OpenPGP digital signature

Bug#861800: unblock: hydra/8.3-3

[Lukas Schwaighofer]

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

Hi,

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

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

The changelog entry is:

hydra (8.3-3) unstable; urgency=medium

  * Team upload.

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

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

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

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

Thank you
Lukas Schwaighofer


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

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

[Lukas Schwaighofer]

Hi,

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


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


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

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


Regards
Lukas



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


pgpHZjSyiSTra.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

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

Hi Ivan,

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

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


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


Regards
Lukas


pgpRVPjNuusuN.pgp
Description: OpenPGP digital signature

Bug#551350: arpwatch: restart option

[Lukas Schwaighofer]

Hi Stephan,

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

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

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

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

Regards
Lukas


pgpAo45NZQZiM.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

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

Hi,

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

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

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

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

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

unblock dsniff/2.4b1+debian-25


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

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

[Lukas Schwaighofer]

Control: tags -1 + pending

Hi,

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

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

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

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

Thanks
Lukas


pgpZtQQW5atbR.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Hi,

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


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

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


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

Bug#852360: Cross compiling and Bug#852360

[Lukas Schwaighofer]

Hello Helmut,

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

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

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

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

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

Regards
Lukas


pgpgfBiVDxv_5.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Philippe,

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

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

Thanks
Lukas

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


pgpoLJUzJq3p0.pgp
Description: OpenPGP digital signature

Bug#852360: Cross compiling and Bug#852360

[Lukas Schwaighofer]

Hi Debian cross team,

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

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

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

Thanks in advance
Lukas


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


pgpajcAbvrJ8f.pgp
Description: OpenPGP digital signature

Bug#410008: arpwatch: override for flip flop detection

[Lukas Schwaighofer]

Control: severity -1 wishlist

Hi Brian,

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

Regards
Lukas


pgpm6Nwc3YkG0.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

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

Hi,

thanks for your bug report.

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


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

Regards
Lukas


pgprdEDJt80Wt.pgp
Description: OpenPGP digital signature

Bug#551350: arpwatch: restart option

[Lukas Schwaighofer]

Hi Stephen,

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

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


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

Would you be fine with that?


Thank you
Lukas


pgpq9q83d7_Av.pgp
Description: OpenPGP digital signature

Bug#782057: arpwatch problems

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi,

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


In your bug report you described two different problems.

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

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


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

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

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

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


Thank you
Lukas


pgpd25LZIRqIb.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

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

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

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

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

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

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

Thanks
Lukas


pgpkMsTnydSJO.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

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

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


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


Thanks
Lukas


pgp1UBMO546rn.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Christian,

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

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

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


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

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

Thanks
Lukas

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


pgphWjqJgLtYU.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

thanks again for the review and the comments!

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

Ok, I will revert that override.

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

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

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

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

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

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

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


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


Regards
Lukas


pgplxYA1nteYj.pgp
Description: OpenPGP digital signature

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi Hugo,

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

Some further questions and comments follow inline below.

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

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

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

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

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

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

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

> * There's no copyright entry for you

Fixed.

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

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

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

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

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

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

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

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

Ok, I removed the pre-dependenciy.

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

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


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

Fixed.

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

Bug#858860: RFS: arpwatch [ITA]

[Lukas Schwaighofer]

Hi security tools packaging team,

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

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

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

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


Thanks
Lukas


pgpml4vQjvHGW.pgp
Description: OpenPGP digital signature

Bug#857767: found workaround

[Lukas Schwaighofer]

Hi,

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

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


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

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


Regards
Lukas

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

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

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

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

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


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


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


Regards
Lukas Schwaighofer


pgpcIQFw6iuR0.pgp
Description: OpenPGP digital signature

Bug#857065: fixed in gmrun 0.9.2-2.2

[Lukas Schwaighofer]

Hi Martin,

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

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

Regards
Lukas

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


pgpB6QS_Mq1OJ.pgp
Description: OpenPGP digital signature

Bug#858105: unblock: gmrun/0.9.2-2.2

[Lukas Schwaighofer]

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

Hi,

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

gmrun (0.9.2-2.2) unstable; urgency=medium

  * Non-maintainer upload.

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

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

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

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


pgptH5MPUQK0c.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

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

It builds those binary packages:

  gmrun - Featureful CLI-like GTK+ application launcher

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

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


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

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


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

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


Thank you
Lukas Schwaighofer


pgpbMW6tLeZc7.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

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

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

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

Thanks
Lukas Schwaighofer


pgpJiwbQ4Bbsi.pgp
Description: OpenPGP digital signature

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

[Lukas Schwaighofer]

Package: chromium
Version: 57.0.2987.98-1
Severity: minor

Hi,

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

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

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

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


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

"sync_promo": {
  "show_on_first_run_allowed": false
}


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

Thank you
Lukas Schwaighofer


pgp6v9EMRoKXL.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

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

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

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

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

Thanks
Lukas

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hi,

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

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

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


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

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


Thanks
Lukas Schwaighofer

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


pgpTyX54gBSWk.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hi Mateusz,

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

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

Regards
Lukas Schwaighofer


pgpW8Ylq8FPe1.pgp
Description: OpenPGP digital signature

Bug#857065: gmrun: Segfault after recent upgrades

[Lukas Schwaighofer]

Hello Andreas,

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

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

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

Regards
Lukas Schwaighofer


pgpG9zn2TAp7l.pgp
Description: OpenPGP digital signature