Bug#1069349: live-build: Regression in d14306a7 leading to build failures

[Daniel Reichelt]

Package: live-build
Version: git-master
Severity: normal

Hi all,

I recently built a .deb of the current master and noticed build failures like 
this:

---8<--
P: Begin copying binary includes...
/usr/lib/live/build/binary_includes: 36: cd: can't cd to config/includes.binary
E: An unexpected failure occurred, exiting...

---8<--

...since I don't have any files stored in config/includes.binary and since 
commit d14306a7, the check for the exixtence of such files is no longer 
happening.


Partially reverting d14306a7 with respect to binary_includes resolved the issue 
for me.


Cheers

Daniel

Bug#1028088: hostapd.*service: please depend on presence on config file

[Daniel Reichelt]

Package: hostapd
Version: 2:2.9.0-21
Severity: normal

Hi *,

the init scripts used to depend on the presence of /etc/hostapd/hostapd.conf.
systemd however tries to continuously start the units unconditionally.

This additional line in the units would be a simple fix:


[Unit]
ConditionFileNotEmpty=/etc/hostapd/hostapd.conf


Thanks!
Daniel

Bug#844321: unison: Please update to latest upstream version

[Daniel Reichelt]

*bump*


On Mon, 20 May 2019 16:31:05 +0200 =?UTF-8?Q?St=c3=a9phane_Glondu?= 
 wrote:


> Le 20/05/2019 à 16:06, Christoph Groth a écrit :
> > Unison 2.51.2 that has been released in January 2018 has a new feature
> > that is very useful for synchronizing, for example, '.git' directories:
> >
> >> Add a new preference, 'atomic', for specifying directories that should
> >> be treated atomically.
> >
> > It would be great to see this in Debian soon!
>
> Indeed, this new feature looks interesting!
>
> I will look into this when Buster is released.
>
> Cheers,
>
> --
> Stéphane
>
>

Bug#1016067: rpcbind installation fails due to missing user _rpc

[Daniel Reichelt]

Package: rpcbind
Version: 1.2.6-4
Severity: grave
Justification: renders package unusable

Hi,

since the d/postinst file has been removed, on a fresh VM rpcbind can no longer 
be installed:


--8<--
root@kvmsid:~# apt install rpcbind
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  rpcbind
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.9 kB of archives.
After this operation, 164 kB of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian sid/main amd64 rpcbind amd64 1.2.6-5 
[51.9 kB]
Fetched 51.9 kB in 0s (242 kB/s)
Selecting previously unselected package rpcbind.
(Reading database ... 26717 files and directories currently installed.)
Preparing to unpack .../rpcbind_1.2.6-5_amd64.deb ...
Unpacking rpcbind (1.2.6-5) ...
Setting up rpcbind (1.2.6-5) ...

/usr/lib/tmpfiles.d/rpcbind.conf:2: Failed to resolve user '_rpc': No such 
process
^


Created symlink /etc/systemd/system/multi-user.target.wants/rpcbind.service → 
/lib/systemd/system/rpcbind.service.
Created symlink /etc/systemd/system/sockets.target.wants/rpcbind.socket → 
/lib/systemd/system/rpcbind.socket.
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 145.
-->8--


Executing the adduser command from the former postinst script manually and
running `dpkg --configure -a` fixed the problem. Even though the migration path
from postinst might be obsolete, creating the _rpc user isn't.


Thanks,
Daniel

Bug#912717: msg.sock issue still upstream

[Daniel Reichelt]

confirmed on

buster 2:4.9.5+dfsg-5+deb10u1

and

bullseye/sid 2:4.13.5+dfsg-2


cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#986278: live-build now fails for buster when including firmware

[Daniel Reichelt]

Package: live-build
Version: 1:20210330
Severity: normal

Hi,

since 21eff20ea3caec205568e7305732928fedd10b0a I can no longer build buster 
images including firmware:


---8<--
P: Begin scheduling firmware installation...
--2021-04-02 11:19:29--  
http://ftp.de.debian.org/debian//dists/buster/main/Contents-all.gz
Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-04-02 11:19:29 ERROR 404: Not Found.
-->8--

This error also happens when using the main ftp site ftp.d.o. It seems to me
like there simply is no Contents-all.gz prior to bullseye...


Thanks
Daniel




-- Package-specific info:

-- System Information:
Debian Release: 10.9
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldstable'), (99, 'testing'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages live-build depends on:
ii  debootstrap  1.0.119~bpo10+1

Versions of packages live-build recommends:
ii  apt-utils   1.8.2.2
ii  bzip2   1.0.6-9.2~deb10u1
ii  cpio2.12+dfsg-9
ii  file1:5.35-4+deb10u2
ii  live-boot-doc   1:20190614
ii  live-config-doc 11.0.2+dhr1
ii  live-manual 2:20151217.1
ii  live-manual-epub [live-manual]  2:20151217.1
ii  live-manual-html [live-manual]  2:20151217.1
ii  live-manual-odf [live-manual]   2:20151217.1
ii  live-manual-pdf [live-manual]   2:20151217.1
ii  live-manual-txt [live-manual]   2:20151217.1
ii  rsync   3.2.3-3~bpo10+1
pn  systemd-container   
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages live-build suggests:
ii  e2fsprogs  1.46.2-1~bpo10+2
pn  mtd-utils  
ii  parted 3.2-25

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/live/build/binary_iso (from live-build package)

Bug#974684: python3-lxml: Cannot install python3-lxml/buster-backports on bpo-enabled machine

[Daniel Reichelt]

Package: python3-lxml
Version: 4.6.1-1~bpo10+1
Severity: important

Hi,

just tried to apt-get install python3-lxml/buster-backports but it failed as 
follows:


--8<
# apt-get install python3-lxml/buster-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '4.6.1-1~bpo10+1' (Debian Backports:buster-backports [amd64]) 
for 'python3-lxml'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-lxml : Depends: python3 (< 3.6) but 3.7.3-1 is to be installed
E: Unable to correct problems, you have held broken packages.
-->8


The dependencies against python3 are defined as:

in python3-lxml 4.3.2-1 (buster): Depends: python3 (<< 3.8)
in python3-lxml 4.6.1-1~bpo10+1: Depends: python3 (<< 3.6)


Seeing that python3.7 is the default python3 in buster, why (<< 3.6) for /bpo 
instead of (<< 3.7)?


Regards
Daniel



-- System Information:
Debian Release: 10.6
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (99, 
'testing'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Bug#971003: live-config: Console auto-login doesn't work with sysvinit

[Daniel Reichelt]

Package: live-config
Version: 5.20190519
Severity: normal
Tags: patch

Hi,

Sysvinit has been a transitional package since (before?) Jessie. However,
live-config still checks for its presence to determine whether console
auto-login should be enabled via inittab. This patch changes the condition
to look for the presence of sysvinit-core.

Cheers
Daniel


-- System Information:
Debian Release: 10.6
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (99, 
'testing'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages live-config depends on:
ii  live-config-sysvinit [live-config-backend]  5.20190519

Versions of packages live-config recommends:
ii  iproute25.8.0-1~bpo10+1
ii  keyboard-configuration  1.193~deb10u1
ii  live-config-doc 5.20190519
ii  live-tools  1:20171207
ii  locales 2.28-10
ii  sudo1.8.27-1+deb10u2
ii  user-setup  1.81

Versions of packages live-config suggests:
ii  pciutils  1:3.5.2-1
ii  wget  1.20.1-1.1

-- no debconf information
>From 6786f9bf1848993fff68787c9734f6f6b9277c4d Mon Sep 17 00:00:00 2001
From: Daniel Reichelt 
Date: Sat, 26 Sep 2020 07:56:45 +0200
Subject: [PATCH] Fix console auto-login in conjunction with sysvinit

Sysvinit has been a transitional package since (before?) Jessie. However,
live-config still checks for its presence to determine whether console
auto-login should be enabled via inittab. This patch changes the condition
to look for the presence of sysvinit-core.
---
 components/0160-sysvinit | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/components/0160-sysvinit b/components/0160-sysvinit
index 597e510..81c90ab 100755
--- a/components/0160-sysvinit
+++ b/components/0160-sysvinit
@@ -49,7 +49,7 @@ Init ()
esac
 
# Checking if package is installed or already configured
-   if [ ! -e /var/lib/dpkg/info/sysvinit.list ] || \
+   if [ ! -e /var/lib/dpkg/info/sysvinit-core.list ] || \
   [ -e /var/lib/live/config/sysvinit ]
then
exit 0
-- 
2.27.0

Bug#962995: fixed in testssl.sh 3.0.2+dfsg1-2

[Daniel Reichelt]

On 24.07.20 13:04, Daniel Reichelt wrote:
> Thus, I suggest to just remove the dependency on bsdextrautils
> for buster-backports again.


*hng* …make that:

Thus, I suggest to replace the dependency on bsdextrautils by
bsdmainutils for buster-backports.



signature.asc
Description: OpenPGP digital signature

Bug#962995: fixed in testssl.sh 3.0.2+dfsg1-2

[Daniel Reichelt]

Hi all,

the added dependency on bsdextrautils doesn't work for buster-backports
since bsdextrautils is not available there.

The required binary hexdump is still available via bsdmainutils in
buster. Thus, I suggest to just remove the dependency on bsdextrautils
for buster-backports again.

Thanks
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#964956: apt-cache search trips over regex special characters in package names

[Daniel Reichelt]

Nevermind, I should have read the man page more carefully, which clearly
states that it expects a regex as argument for the search sub-command.

Please close, sorry for the noise.

Daniel



signature.asc
Description: OpenPGP digital signature

Bug#964956: apt-cache search trips over regex special characters in package names

[Daniel Reichelt]

Package: apt
Version: 1.8.2.1
Severity: important

Hi,

running `apt-cache search libstdc++5` on a fresh minimal system yields an empty
result. This behaviour is inconsistent with processing of command-line
arguments of the sub-commands pkgnames and show.


Environment:
- minimal buster
- sources.list: deb http://ftp.de.debian.org/debian buster main


This behaviour occurs on jessie through sid.


Here are some example commands an their respective outputs:

-8<
# apt-cache search libstdc++5

# apt-cache search libstdc\+\+5

# apt-cache search libstdc\\+\\+5
libstdc++5 - The GNU Standard C++ Library v3

# apt-cache search "libstdc++5"

# apt-cache search "libstdc\+\+5"
libstdc++5 - The GNU Standard C++ Library v3
->8




However, the pkgnames and show sub-commands are not affected:


-8<
apt-cache pkgnames libstdc++5
libstdc++5

# apt-cache show libstdc++5
Package: libstdc++5
Source: gcc-3.3 (1:3.3.6ds1-30)
Version: 1:3.3.6-30
Installed-Size: 1128
[...]
->8


Let me know if you need more info.

Thanks
Daniel

Bug#953615: fixed 953615 in 1.1.11-1

[Daniel Reichelt]

On 03.05.20 18:40, Andrej Shadura wrote:
> On Sun, May 03, 2020 at 04:58:56PM +0200, Daniel Reichelt wrote:
>> Hi Maintainers,
>>
>> is this going to be backported to stable?
> 
> Yes, see #959661:
> 
> https://bugs.debian.org/959661
> 


Great news, thanks!



signature.asc
Description: OpenPGP digital signature

Bug#953615: fixed 953615 in 1.1.11-1

[Daniel Reichelt]

Hi Maintainers,

is this going to be backported to stable?

Thanks
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#953237: nvidia-settings bpo missing since release of nvidia-driver=440.59-1~bpo10+1

[Daniel Reichelt]

Source: nvidia-settings
Version: 430.64-1~bpo10+1
Severity: normal

Hi,

it seems like nvidia-settings has been forgotten to get backported to buster.
The bullseye-version is not installable on buster due to a versioned dependency
on libc6. A simple re-build of nvidia-settings/bullseye on a buster machine was
enough for me to get it running.

Thanks
Daniel

-- System Information:
Debian Release: 10.3
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable'), (99, 'testing'), (98, 'unstable'), (96, 
'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Daniel Reichelt]

On 08.01.20 09:04, Mike Gabriel wrote:
> I attached a .debdiff that reflects todays regression fix upload to
> buster-pu (I also did one to stretch-pu). I cherry-pick 2 more patches
> from upstream that relate to pthreading in libvncserver. I was able to
> reproduce your x11vnc crash on buster and with libvncserver having the
> attached .debdiff applied the crashes are gone.
> 
> Can you confirm that?

Yep, works. Thanks!

Daniel



signature.asc
Description: OpenPGP digital signature

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Daniel Reichelt]

On 02.01.20 16:39, Daniel Reichelt wrote:
> With 7e63df224aa45a8b541cd63a870594454aba7526 applied, this happens 9
> out of 10 times.

Actually, that's crap.

I noticed a ton of running x11vnc processes and re-tried ~debu10 with
7e63df224aa45a8b541cd63a870594454aba7526 applied.

Result: just the error message about "unknown encoding", so nothing
notably different than w/o said additional patch. (Although the
different behaviour when other x11vnc processes are lingering
is…"interesting"…it's not pertinent to the regression itself.)



signature.asc
Description: OpenPGP digital signature

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Daniel Reichelt]

> Does this upstream commit being added to the patches in +deb10u2 fix
> your issue?
> https://github.com/LibVNC/libvncserver/commit/7e63df224aa45a8b541cd63a870594454aba7526.patch

Not really.

With just ~debu10, 1 out of 10 times, the client window would stay open,
but I wasn't able to transmit any input… just no reaction whatsoever to
kb/mouse.

With 7e63df224aa45a8b541cd63a870594454aba7526 applied, this happens 9
out of 10 times.

A completely working connection couldn't be established at all.



signature.asc
Description: OpenPGP digital signature

Bug#905786: Fix for "libvncserver1: Use-after-free on shutdown[...]" incomplete

[Daniel Reichelt]

Hi all,

the new use-after-free patches introduced in 0.9.11+dfsg-1.3~deb10u2
hurt connections to servers provided by x11vnc.

Previously, a server initiated by

x11vnc -nopw -auth guess -display :0 -forever

was perfectly fine to connect to using tightvncviewer. Now, with
~deb10u2, the remote windows of tightvncviewer comes up for a fraction
of a second and then immediately closes with the message "Unknown
encoding". Nothing changed on the involved systems besides
libvncserver1/libvncclient1.

Reverting only the use-after-free patches, re-building libvncserver1 and
starting x11vnc using that package, tightvncviewer can connect again.

Also, this issue does NOT appear when libvncserver1/testing
(0.9.12+dfsg-5) is installed.


Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#943527: [Pkg-mozext-maintainers] Bug#943527: umatrix unusable

[Daniel Reichelt]

On 21.11.19 19:34, Ximin Luo wrote:
> Julien Aubin:
>> Hi,
>>
>> Same symptoms and same fix observed on my box.
>>
> 
> Do you guys have the same problem with firefox (not esr) version 69 or 70? 
> Umatrix is working fine for me with those versions, after applying the 
> workaround from #919557.
> 
> X
> 

Nope, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=919557;msg=22
and later. They're reporting that replacing symlinks is no longer
sufficient, but the version from a.m.o works.




signature.asc
Description: OpenPGP digital signature

Bug#943527: webext-umatrix: umatrix is unusable with current firefox-esr

[Daniel Reichelt]

Package: webext-umatrix
Version: 1.3.16+dfsg-2
Severity: grave
Justification: renders package unusable

Hi,

since the latest update of firefox-esr from 60.9 to 68.2, umatrix is no longer
usable. I tried v1.4 from addons.mozilla.org which seems to do fine.

Please update to the latest version. Thanks!

Daniel



-- System Information:
Debian Release: 10.1
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable'), (99, 'testing'), (98, 'unstable'), (96, 
'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages webext-umatrix depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  fonts-roboto-unhinted  2:0~20170802-3
ii  libjs-codemirror   5.43.0-1
ii  libjs-punycode 1.3.2-2
ii  publicsuffix   20190415.1030-1

Versions of packages webext-umatrix recommends:
ii  firefox-esr  68.2.0esr-1~deb10u1

webext-umatrix suggests no packages.

-- no debconf information

Bug#935328: libguestfs-tools: virt-sparsify doesn't work if libelogind0 is installed on the host (workaround found)

[Daniel Reichelt]

The attached patch works around the issue for sysvinit/elogind users.

A proper solution however would auto-apply the appropriate version of
the packages file (or supermin.d directory), depending on the state of
the host system.

Cheers
Daniel
--- /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages.orig	2019-08-21 23:05:49.623663071 +0200
+++ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages	2019-08-21 23:05:56.343771343 +0200
@@ -35,7 +35,7 @@
 libhivex0
 libjansson4
 libpcre3
-libsystemd0
+libelogind0
 libxml2
 libyara3
 lsscsi


signature.asc
Description: OpenPGP digital signature

Bug#935328: libguestfs-tools: virt-sparsify doesn't work if libelogind0 is installed on the host

[Daniel Reichelt]

Package: libguestfs-tools
Version: 1:1.40.2-2
Severity: important

Hi,

I'm running buster with sysvinit instead of systemd, so I also have libelogind0
installed instead of libsystemd0. Now, when I run virt-sparsify, it crashes.
Running with export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 shows:


--8<-
[...]
+ date
Wed Aug 21 16:32:35 UTC 2019
+ echo -n 'clocksource: '
clocksource: + cat 
/sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
+ echo -n 'uptime: '
uptime: + cat /proc/uptime
1.89 0.99
+ cmd=guestfsd
++ grep -Eo 'guestfs_channel=[^[:space:]]+' /proc/cmdline
+ eval
+ test x '!=' x
+ test 1 = 1
+ cmd='guestfsd --verbose'
+ test '' = 1
+ false
+ test '' = 1
+ echo guestfsd --verbose
guestfsd --verbose
+ guestfsd --verbose

v
guestfsd: error while loading shared libraries: libsystemd.so.0: cannot open 
shared object file: No such file or directory
^

+ sync
+ test '' = 1
+ reboot -f
/init: line 262: reboot: command not found
[1.981486] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
[1.981486]
[1.982610] CPU: 0 PID: 1 Comm: init Not tainted 4.19.0-5-amd64 #1 Debian 
4.19.37-5+deb10u2
[1.983635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[1.984654] Call Trace:
[1.984970]  dump_stack+0x5c/0x80
[1.985386]  panic+0xe7/0x24a
[1.985844]  do_exit.cold.22+0x26/0x7f
[1.986314]  ? handle_mm_fault+0xda/0x200
[1.986814]  do_group_exit+0x3a/0xa0
[1.987261]  __x64_sys_exit_group+0x14/0x20
[1.987779]  do_syscall_64+0x53/0x110
[1.988237]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1.988858] RIP: 0033:0x7fa55b0559d6
[1.989308] Code: Bad RIP value.
[1.989711] RSP: 002b:7ffda405e4d8 EFLAGS: 0246 ORIG_RAX: 
00e7
[1.990644] RAX: ffda RBX: 7fa55b146760 RCX: 7fa55b0559d6
[1.991518] RDX: 007f RSI: 003c RDI: 007f
[1.992391] RBP: 007f R08: 00e7 R09: ff80
[1.993263] R10: 7ffda405e370 R11: 0246 R12: 7fa55b146760
[1.994139] R13: 0001 R14: 7fa55b14f428 R15: 
[1.995115] Kernel Offset: 0x2a60 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[1.996428] Rebooting in 1 seconds..
libguestfs: child_cleanup: 0x5640500b4ac0: child process died
libguestfs: sending SIGTERM to process 27974
libguestfs: qemu maxrss 152644K
libguestfs: trace: launch = -1 (error)
virt-sparsify: error: libguestfs error: guestfs_launch failed, see earlier
error messages

If reporting bugs, run virt-sparsify with debugging enabled and include the
complete output:
[...]
--8<-



I suppose this renders everything around guestfs involving a supermin 
applicance with guestfsd unusable.

Please let me know if you need more information.


Thanks
Daniel



-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-proposed-updates'), (500, 'testing-debug'), 
(500, 'stable-debug'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldstable-debug'), (500, 'stable'), (500, 
'oldstable'), (99, 'testing'), (98, 'unstable'), (96, 'oldoldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libguestfs-tools depends on:
ii  curl   7.64.0-4
ii  libc6  2.28-10
ii  libconfig9 1.5-0.4
ii  libfuse2   2.9.9-1
ii  libguestfs-perl1:1.40.2-2
ii  libguestfs01:1.40.2-2
ii  libintl-perl   1.26-2
ii  libjansson42.12-1
ii  liblzma5   5.2.4-1
ii  libncurses66.1+20181013-2
ii  libpcre3   2:8.39-12
ii  libreadline7   7.0-5
ii  libstring-shellquote-perl  1.04-1
ii  libsys-virt-perl   5.0.0-1
ii  libtinfo6  6.1+20181013-2
ii  libvirt0   5.0.0-4
ii  libwin-hivex-perl  1.3.18-1
ii  libxml22.9.4+dfsg1-7+b3

Versions of packages libguestfs-tools recommends:
ii  gnupg  2.2.17-3~bpo10+2

libguestfs-tools suggests no packages.

-- no debconf information

Bug#934000: calibre: ebook-viewer no longer opens markdown files

[Daniel Reichelt]

Package: calibre
Version: 3.46.0+dfsg-1~bpo10+1
Severity: important

Hi,

calibre/buster ran fine, since 3.46 entered buster-bpo, it crashes on opening 
markdown files:


-8<--
$ echo "# I'm a heading" > foo.md
$ ebook-viewer foo.md
-8<--


The main windows shown, blocked by a common, modal error dialog, providing this 
stack trace:

-8<--
calibre, version 3.46.0
ERROR: Could not open e-book: Failed to read book, foo.md click "Show Details" 
for more information

Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/utils/ipc/simple_worker.py", line 290, in main
res = {'result':func(*args, **kwargs)}
  File "/usr/lib/calibre/calibre/ebooks/oeb/iterator/book.py", line 64, in 
extract_book
plumber.opts, plumber.input_fmt, log, {}, tdir)
  File "/usr/lib/calibre/calibre/customize/conversion.py", line 246, in __call__
log, accelerators)
  File "/usr/lib/calibre/calibre/ebooks/conversion/plugins/txt_input.py", line 
261, in convert
input_mi, html = convert_markdown_with_metadata(txt, extensions=[x.strip() 
for x in options.markdown_extensions.split(',') if x.strip()])
  File "/usr/lib/calibre/calibre/ebooks/txt/processor.py", line 148, in 
convert_markdown_with_metadata
md = create_markdown_object(extensions)
  File "/usr/lib/calibre/calibre/ebooks/txt/processor.py", line 114, in 
create_markdown_object
from markdown import Markdown
  File "/usr/lib/calibre/calibre/startup.py", line 69, in load_module
return import_module(fullname[len('calibre.ebooks.'):])
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ValueError: Empty module name
-8<--


The package list below is from my main machine (buster+bpo), however this also 
happens on an up-to-date sid vm.

Let me know if you need more information!


Thanks
Daniel


-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'stable'), (500, 'oldstable'), (99, 'testing'), (98, 
'unstable'), (96, 'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages calibre depends on:
ii  calibre-bin  3.46.0+dfsg-1~bpo10+1
ii  fonts-liberation 1:1.07.4-9
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1
ii  poppler-utils0.71.0-5
ii  python-apsw  3.24.0-r1-1
ii  python-bs4   4.7.1-1
ii  python-chardet   3.0.4-3
ii  python-cherrypy3 8.9.1-2
ii  python-css-parser1.0.4-1
ii  python-cssselect 1.0.3-1
ii  python-cssutils  1.0.2-2
ii  python-dateutil  2.7.3-3
ii  python-dbus  1.2.8-3
ii  python-feedparser5.2.1-1
ii  python-html5-parser  0.4.5-1
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.3.2-1
ii  python-markdown  3.0.1-3
ii  python-mechanize 1:0.2.5-3
ii  python-msgpack   0.5.6-1+b1
ii  python-netifaces 0.10.4-1+b1
ii  python-pil   5.4.1-2
ii  python-pkg-resources 40.8.0-1
ii  python-pyparsing 2.2.0+dfsg1-2
ii  python-pyqt5 5.11.3+dfsg-1+b3
ii  python-pyqt5.qtsvg   5.11.3+dfsg-1+b3
ii  python-pyqt5.qtwebkit5.11.3+dfsg-1+b3
ii  python-regex 0.1.20190207-1
ii  python-routes2.4.1-1
ii  python2.72.7.16-2
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
ii  python-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python-unrardll  

-- no debconf information

Bug#933388: urlview: TAGs for handler invocation not working as advertised

[Daniel Reichelt]

Package: urlview
Version: 0.9-21
Severity: normal
Tags: patch

Hi,

the tags PW and XT are not working as advertised in the header of
url_handler.sh. Instead of nohup'ing or suppressing STDERR, all handlers are
executed as "$prg $url".

The attached patch fixes the handling of these tags and some informational echo
statements.


Cheers
Daniel




-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable'), (99, 'testing'), (98, 'unstable'), (96, 
'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages urlview depends on:
ii  libc6   2.28-10
ii  libncurses6 6.1+20181013-2
ii  libtinfo6   6.1+20181013-2
ii  sensible-utils  0.0.12

Versions of packages urlview recommends:
ii  chromium [www-browser] 73.0.3683.75-1
ii  elinks [www-browser]   0.13~20190125-3
ii  firefox-esr [www-browser]  60.8.0esr-1~deb10u1
ii  lynx [www-browser] 2.8.9rel.1-3
ii  netsurf-gtk [www-browser]  3.6-3.2

Versions of packages urlview suggests:
ii  lftp  4.8.4-2
ii  mutt  1.10.1-2.1
ii  wget  1.20.1-1.1

-- no debconf information
--- /etc/urlview/url_handler.sh.orig2019-07-30 08:23:46.026881530 +0200
+++ /etc/urlview/url_handler.sh 2019-07-30 08:59:13.672789766 +0200
@@ -56,14 +56,14 @@
prog=${ele%%:*}
if [ -x $prog ]; then
case $tag in
-   PW) [ -n "$DISPLAY" ] && echo "P:$prog" && return 0
+   PW) [ -n "$DISPLAY" ] && echo "PW:$prog" && return 0
;;
XW)
-   [ -n "$DISPLAY" ] && echo "X:$prog" && return 0
+   [ -n "$DISPLAY" ] && echo "XW:$prog" && return 0
;;
XT)
[ -n "$DISPLAY" ] && [ -x "$XTERM" ] && \
-   echo "X:$XTERM -e $prog" && return 0
+   echo "XT:$XTERM -e $prog" && return 0
echo "$prog" && return 0
;;
VT)
@@ -131,9 +131,9 @@
 esac
 
 if [ -n "$prg" ]; then
-   if [ "${prg%:*}" = "P" ]; then
+   if [ "${prg%:*}" = "PW" ]; then
 nohup ${prg#*:} $url 2>/dev/null 1>/dev/null &
-   elif [ "${prg%:*}" = "X" ]; then
+   elif [ "${prg%:*}" = "XT" ]; then
 ${prg#*:} $url 2>/dev/null &
else
 $prg $url

Bug#933295: squid: Race-condition in start script when cache dir structure doesn't exist

[Daniel Reichelt]

Package: squid
Version: 4.6-1
Severity: normal
Tags: patch

Hi,

first of all: I'm running sysvinit-core instead of systemd.

When squid starts and the cache directory structure below /var/spool/squid
doesn't exist yet, /etc/init.d/squid calls `squid -z -f $CONFIG` to create the
directories and start-stop-daemon thereafter for the actual launch. `squid -z`
however seems to fork to the background, making start-stop-daemon think it's
already running (return code 1).

Adding -N to `squid -z` (No daemon mode) solved the issue for me: `squid -z`
only returns after the directory structure has been created, letting
start-stop-daemon do its job.


Cheers
Daniel


-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Bug#932775: [Pkg-net-snmp-devel] Bug#932775: snmpd: init script does not respect /etc/default/snmpd

[Daniel Reichelt]

Hi Craig,

> It's a little more complicated than that. The defaults are loaded in>
> by init-d-script but are then overwritten by the snmp init script.

Whoops…I totally missed the usage of init-d-script. Shouldn't be writing
bug reports that late…



> Actually looking at the init script, it does check SNMPOPTS is set
> and this is the only variable in the default file. What exactly is
> not getting picked up or overwritten?

My /etc/defaults/snmpd looks like this:

--8<-
SNMPDOPTS='-LS5d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I
-smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'
--8<-

Notice -Ls5d versus the default of -Lsd...this doesn't get picket up and
snmpd is started with the defaults.


Here's my analysis using a somewhat fresher head:

- user calls /etc/init.d/snmpd
- init-d-script is sourced
- init-d-script does its magic and itself sources /etc/init.d/snmpd again
- this time around init-d-script does not get called and snmpd actually
executes DAEMON_ARGS="$SNMPDOPTS -p $PIDFILE". However, at this point,
$SNMPDOPTS has not been set yet.
- snmpd continues, declares do_start_prepare()
- init-d-script continues and only *now* /etc/default/snmpd gets
sourced, thereby picking up on my custom $SNMPDOPTS...which doesn't get
used any more.
- init-d-script calls do_start_prepare() <-- this one's important for
the fix
- init-d-script calls do_start_cmd(), which calls start-stop-daemon with
DAEMON_ARGS still containing the wrong SNMPDOPTS


My new fix is to move the assignment of DAEMON_ARGS into
do_start_prepare(). That way, the assignment happens *after* $SNMPDOPTS
possibly got set by /etc/default/snmpd.



I compiled bash with the fix for CVE-2016-7543 ($PS4 vulnerability)
reverted and got a much more informative trace than I got before just by
running the original bash -x under root.

Please find attached two traces. First, I set PS4:

# export PS4='\t:${BASH_SOURCE}:${LINENO}:${FUNCNAME[0]}
[${SHLVL},${BASH_SUBSHELL}, $?] '

Then I created the traces by invoking

# bash-vulnerable-PS4 -x /etc/init.d/snmpd start

twice. The orig.log contains the trace running the unchanged init
script, while patched.log contains a trace running it having the
attached patch applied. This should make thinks clearer.


Hauler if you have questions!


Cheers
Daniel
/etc/init.d/snmpd:3:  [2,0, 0] '[' true '!=' '' ']'
/etc/init.d/snmpd:4:  [2,0, 0] set /etc/init.d/snmpd start
/etc/init.d/snmpd:4:  [2,0, 0] INIT_D_SCRIPT_SOURCED=true
/etc/init.d/snmpd:4:  [2,0, 0] . /lib/init/init-d-script
//lib/init/init-d-script:6:  [2,0, 0] __init_d_script_name=/etc/init.d/snmpd
//lib/init/init-d-script:7:  [2,0, 0] shift
//lib/init/init-d-script:12:  [2,0, 0] . /lib/lsb/init-functions
lib/lsb/init-functions:428:  [2,1, 0] run-parts --lsbsysinit --list /lib/lsb/init-functions.d
///lib/lsb/init-functions:428:  [2,0, 0] for hook in $(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 2>/dev/null)
///lib/lsb/init-functions:429:  [2,0, 0] '[' -r /lib/lsb/init-functions.d/20-left-info-blocks ']'
///lib/lsb/init-functions:429:  [2,0, 0] . /lib/lsb/init-functions.d/20-left-info-blocks
///lib/lsb/init-functions:432:  [2,0, 0] FANCYTTY=
///lib/lsb/init-functions:433:  [2,0, 0] '[' -e /etc/lsb-base-logging.sh ']'
///lib/lsb/init-functions:433:  [2,0, 1] true
//lib/init/init-d-script:17:  [2,0, 0] PATH=/sbin:/usr/sbin:/bin:/usr/bin
//lib/init/init-d-script:18:  [2,0, 0] export PATH
//lib/init/init-d-script:159:  [2,0, 0] '[' '' = true ']'
//lib/init/init-d-script:163:  [2,0, 0] SCRIPTNAME=/etc/init.d/snmpd
///lib/init/init-d-script:164:  [2,1, 0] basename /etc/init.d/snmpd
//lib/init/init-d-script:164:  [2,0, 0] scriptbasename=snmpd
//lib/init/init-d-script:165:  [2,0, 0] '[' snmpd '!=' init-d-script ']'
//lib/init/init-d-script:166:  [2,0, 0] . /etc/init.d/snmpd
///etc/init.d/snmpd:3:  [2,0, 0] '[' true '!=' true ']'
///etc/init.d/snmpd:19:  [2,0, 0] DESC='SNMP Services'
///etc/init.d/snmpd:20:  [2,0, 0] DAEMON=/usr/sbin/snmpd
///etc/init.d/snmpd:21:  [2,0, 0] PIDFILE=/run/snmpd.pid
///etc/init.d/snmpd:24:  [2,0, 0] OLD_MIBS_DIR=/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
///etc/init.d/snmpd:25:  [2,0, 0] MIBS_DIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf
///etc/init.d/snmpd:26:  [2,0, 0] export MIBDIRS=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
///etc/init.d/snmpd:26:  [2,0, 0] MIBDIRS=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
///etc/init.d/snmpd:28:  [2,0, 0] DEFAULT_SNMPDOPTS='-Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf'
///etc/init.d/snmpd:29:  [2,0, 0] '[' -z '' ']'
///etc/init.d/snmpd:29:  [2,0, 0] 

Bug#932775: snmpd: init script does not respect /etc/default/snmpd

[Daniel Reichelt]

Package: snmpd
Version: 5.7.3+dfsg-5
Severity: important

Hi,

first of all, I'm running sysvinit, not systemd.

The init script shipped with snmpd is broken as it does not respect 
/etc/default/snmpd. The code which handled this in the stretch version is 
missing from the buster version:

-8<--
# Reads config file (will override defaults above)
[ -r /etc/default/snmpd ] && . /etc/default/snmpd
-8<--


Thanks,

Daniel

-- System Information:
Versions of packages snmpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libmariadb31:10.3.15-1
ii  libsnmp-base   5.7.3+dfsg-5
ii  libsnmp30  5.7.3+dfsg-5
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

Bug#932724: lvm2: vg/lv not recognized after cryptsetup open

[Daniel Reichelt]

Package: lvm2
Version: 2.03.02-3
Severity: normal

Hi,

first of all: I'm running buster with sysvinit, not systemd.

On sdb1, there's a LUKS volume containing a PV:

# lsblk /dev/sdb
NAME  MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sdb 8:16   1  1.8T  0 disk
└─sdb1  8:17   1  1.8T  0 part
  └─cvgsrv253:60  1.8T  0 crypt
└─vgsrv-lvsrv 253:70  1.8T  0 lvm   /srv

After `cryptsetup luksOpen cvgsrv /dev/sdb1`, the VG vgsrv and its LV is not 
recognized anymore, this worked automatically on stretch. Now I have to issue 
`vgchange -ay` for symlinks to the VG/LV to appear under /dev/mapper.


I could track down the issue to 69-lvm-metad.rules. With the following patch 
applied, the VG gets recognized automatically after luksOpen again.



--- /usr/lib/udev/rules.d/69-lvm-metad.rules.orig   2019-07-21 
23:30:07.383409274 +0200
+++ /usr/lib/udev/rules.d/69-lvm-metad.rules2019-07-21 23:30:07.371409238 
+0200
@@ -88,7 +88,7 @@
 # --(enable|disable)-udev-systemd-background-jobs to "configure".
 # On modern distributions with recent systemd, it's "systemd_background";
 # on others, "direct_pvscan".
-GOTO="systemd_background"
+GOTO="direct_pvscan"
 
 LABEL="systemd_background"
 


It seems to me like there's no run-time detection implemented whether to use 
the systemd or direct_pvscan part of the rules file.


Thanks
Daniel



-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'stable'), (500, 'oldstable'), (99, 'testing'), (98, 
'unstable'), (96, 'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-3
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-5
ii  libudev1  241-5
ii  lsb-base  10.2019051400

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2.1

lvm2 suggests no packages.

-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/udev/rules.d/69-lvm-metad.rules (from lvm2 package)

Bug#932473: shorewall6 init script inoperational

[Daniel Reichelt]

Package: shorewall6
Version: 5.2.3.2-1
Severity: normal
Tags: patch

Hi,

running sysvinit instead of systemd, I'm relying on the packages init script to 
work. However:

8<--
# /etc/init.d/shorewall6 start
/etc/init.d/shorewall6: line 20: test: /sbin/shorewall: binary operator expected
8<--


Line 20 reads:
8<--
test -x $SRWL || exit 0
8<--

with $SRWL being set to '/sbin/shorewall -6' in line 15.

Reverting SRWL to /sbin/shorewall6, everything works fine again.



Thanks
Daniel





-- System Information:
Debian Release: 10.0
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable'), (99, 'testing'), (98, 'unstable'), (96, 
'oldoldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages shorewall6 depends on:
ii  debconf [debconf-2.0]1.5.71
ii  iproute2 4.20.0-2
ii  iptables 1.8.2-4
ii  libio-socket-inet6-perl  2.72-2
ii  lsb-base 10.2019051400
ii  shorewall5.2.3.2-1

shorewall6 recommends no packages.

shorewall6 suggests no packages.


-- debconf information excluded

Bug#928497: nvidia-persistenced: Error in nvidia-persistenced source (postinst)

[Daniel Reichelt]

Hi Andreas,


> I can reproduce this (on a systemv system) with a (deliberately)
> mismatching kernel module loaded:

this also happens on systems w/o nvidia hardware, i.e. when the module
isn't loaded at all. That situation produces similar syslog entries than
yours, except the messages prefixed NVRM are missing, of course.

--8<--
May  7 23:37:08 testhost nvidia-persistenced: Started (19591)
May  7 23:37:08 testhost nvidia-persistenced: Failed to query NVIDIA
devices. Please ensure that the NVIDIA device files (/dev/nvidia*)
exist, and that user 145 has read and write permissions for those files.
May  7 23:37:08 testhost nvidia-persistenced: Shutdown (19591)
May  7 23:37:58 testhost nvidia-persistenced: Started (19744)
May  7 23:37:58 testhost nvidia-persistenced: Failed to query NVIDIA
devices. Please ensure that the NVIDIA device files (/dev/nvidia*)
exist, and that user 145 has read and write permissions for those files.
May  7 23:37:58 testhost nvidia-persistenced: Shutdown (19744)
May  7 23:38:04 testhost nvidia-persistenced: Started (19823)
May  7 23:38:04 testhost nvidia-persistenced: Failed to query NVIDIA
devices. Please ensure that the NVIDIA device files (/dev/nvidia*)
exist, and that user 145 has read and write permissions for those files.
May  7 23:38:04 testhost nvidia-persistenced: Shutdown (19823)
-->8--


Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#927128: live-build: [PATCH] replaced tar with rsync as it is much more efficient in both space and time

[Daniel Reichelt]

I should have looked at Depends: prior to replying.
1) live-build doesn't depend on bash, but plain sh

2) all other tools are either in coreutils or get installed into the
chroot during the build


That said, I'm not sure if it's really worth it to add a new dependency.
How about a pipe instead?

tar cf - . | Chroot chroot "tar -xvf - --no-same-owner
--keep-directory-symlink --overwrite"


Haven't tried that, though, and I'm not sure if Chroot() supports that.


Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#927128: live-build: [PATCH] replaced tar with rsync as it is much more efficient in both space and time

[Daniel Reichelt]

On 15.04.19 12:16, Ronny Standtke wrote:
> I replaced this code block with a simple rsync
> call which is much more efficient in both space and time (see attached
> patch).

I believe this violates the original intention of live-build only
requiring bash (and all the other tools it uses... *cough*).

If one were to accept rsync as dependency (I'm not opposed), please also
add rsync to live-build's Depends: field.

Thanks
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#910627: closed by Louis-Philippe Véronneau (Bug#910627: fixed in nostalgy 0.2.36-1.1)

[Daniel Reichelt]

On 19.01.19 22:06, Debian Bug Tracking System wrote:
> It has been closed by Louis-Philippe Véronneau .

Thanks, Louis-Philippe,
one less package I have to take care about in a private repository.
Great work. Thanks so much!!!

Best,
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#916899: linux-image-4.18.0-0.bpo.3-amd64: NULL pointer dereference in i915

[Daniel Reichelt]

Package: src:linux
Version: 4.18.20-2~bpo9+1
Severity: important

Hi,

since the upgrade to 4.18.0-0.bpo.3-amd64=4.18.20-2~bpo9+1, my Dell Latitude
E6410 fails to boot (everything was fine with
linux-image-4.18.0-0.bpo.1-amd64=4.18.6-1~bpo9+1). It hangs right the second
the i915 module gets loaded: The screen is blanked, still in text mode at
80/25, cursor blinking in the top left corner (I'm running GRUB in text-only
mode, so no VESA involved). I tried the sysrq keys s-u-b and, behold, it
worked. Please find at the very end of this report a dump from the serial
console (luckyly my docking station still has a plain old RS232). As a
workaround, I moved the i915 module out of the way and the machine boots fine
again.

I think this is the same thing than what's been reported at [1].

Thanks!
Daniel


[1] https://bugs.freedesktop.org/show_bug.cgi?id=108850


-- Package-specific info:
** Version:
Linux version 4.18.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.18.20-2~bpo9+1 
(2018-12-08)

** Command line:
BOOT_IMAGE=/vmlinuz-4.18.0-0.bpo.3-amd64 root=/dev/mapper/[...] ro panic=0 
rootdelay=8 cryptopts=[...] net.ifnames=0

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Latitude E6410
product_version: 0001
chassis_vendor: Dell Inc.
chassis_version:
bios_vendor: Dell Inc.
bios_version: A17
board_vendor: Dell Inc.
board_name: 04373Y
board_version: A03

[...]

** PCI devices:
[...]
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor 
Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA 
controller])
Subsystem: Dell Latitude E6410 [1028:040a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: i915

[...]

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'testing'), (500, 'oldstable'), (98, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-4.18.0-0.bpo.3-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.18.0-0.bpo.3-amd64 recommends:
ii  apparmor 2.11.0-3+deb9u2
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.18.0-0.bpo.3-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20171011.af7e95c3+dfsg1-5~bpo9+1
ii  grub-pc 2.02~beta3-5+deb9u1
ii  linux-doc-4.18  4.18.20-2~bpo9+1

Versions of packages linux-image-4.18.0-0.bpo.3-amd64 is related to:
ii  firmware-amd-graphics 20180825+dfsg-1~bpo9+1
ii  firmware-atheros  20180825+dfsg-1~bpo9+1
ii  firmware-bnx2 20180825+dfsg-1~bpo9+1
ii  firmware-bnx2x20180825+dfsg-1~bpo9+1
ii  firmware-brcm8021120180825+dfsg-1~bpo9+1
ii  firmware-cavium   20180825+dfsg-1~bpo9+1
ii  firmware-intel-sound  20180825+dfsg-1~bpo9+1
ii  firmware-intelwimax   20180825+dfsg-1~bpo9+1
ii  firmware-ipw2x00  20180825+dfsg-1~bpo9+1
ii  firmware-ivtv 20180825+dfsg-1~bpo9+1
ii  firmware-iwlwifi  20180825+dfsg-1~bpo9+1
ii  firmware-libertas 20180825+dfsg-1~bpo9+1
ii  firmware-linux-nonfree20180825+dfsg-1~bpo9+1
ii  firmware-misc-nonfree 20180825+dfsg-1~bpo9+1
ii  firmware-myricom  20180825+dfsg-1~bpo9+1
ii  firmware-netxen   20180825+dfsg-1~bpo9+1
ii  firmware-qlogic   20180825+dfsg-1~bpo9+1
ii  firmware-realtek  20180825+dfsg-1~bpo9+1
ii  firmware-samsung  20180825+dfsg-1~bpo9+1
ii  firmware-siano20180825+dfsg-1~bpo9+1
ii  firmware-ti-connectivity  20180825+dfsg-1~bpo9+1
pn  xen-hypervisor

-- no debconf information

-- debsums errors found:
debsums: missing file 
/lib/modules/4.18.0-0.bpo.3-amd64/kernel/drivers/gpu/drm/i915/i915.ko (from 
linux-image-4.18.0-0.bpo.3-amd64 package)

*** /home/dhr/tmp/serialconsole.txt
Begin: Running /scripts/local-premount ... [   46.906057] Btrfs loaded, 
crc32c=crc32c-intel
Scanning for Btrfs filesystems
umount: can't umount /dev/pts: Device or resource busy
done.
Begin: Will now check root file system ... fsck from 

Bug#916461: kicad: Keyboard shortcuts from main Place menu don't match actually working shortcuts

[Daniel Reichelt]

> I can reproduce this behavior in testing with Gnome3 and X11 in 5.0.1-1 too.
> What Desktop Environment do you use?

I'm running Stretch's XFCE, the xfwm4 package is 4.12.4-1.



signature.asc
Description: OpenPGP digital signature

Bug#916461: kicad: Keyboard shortcuts from main Place menu don't match actually working shortcuts

[Daniel Reichelt]

Package: kicad
Version: 5.0.1+dfsg1-3~bpo9+1
Severity: normal

Hi,

on a clean installation (i.e. rm -rf ~/.config/kicad) all the keyboard
shortcuts in the main menu "Place" are shown as [Shift]+[], i.e.
[Shift]+[A] for "Place symbol". However, none of them work. What actually works
is just pressing the letter key, without shift.

Thanks
Daniel


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'testing'), (500, 'oldstable'), (98, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kicad depends on:
ii  libc6   2.24-11+deb9u3
ii  libcairo2   1.14.8-1
ii  libcurl37.52.1-5+deb9u8
ii  libfreeimage3   3.17.0+ds1-5
ii  libfreetype62.6.3-3.2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgl1  1.1.0-1~bpo9+1
ii  libgl1-mesa-glx 18.1.9-1~bpo9+1
ii  libglew2.0  2.0.0-3+b1
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libngspice0 29-1~bpo9+1
ii  liboce-foundation10 0.17.2-2
ii  liboce-modeling10   0.17.2-2
ii  liboce-ocaf-lite10  0.17.2-2
ii  liboce-ocaf10   0.17.2-2
ii  liboce-visualization10  0.17.2-2
ii  libpixman-1-0   0.34.0-1
ii  libpython2.72.7.13-2+deb9u3
ii  libssl1.1   1.1.0j-1~deb9u1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libwxbase3.0-0v53.0.4+dfsg-4~bpo9+1
ii  libwxgtk3.0-0v5 3.0.4+dfsg-4~bpo9+1
ii  libx11-62:1.6.4-3+deb9u1
ii  libxext62:1.3.3-1+b2
ii  python  2.7.13-2
ii  python-wxgtk3.0 3.0.2.0+dfsg-4

Versions of packages kicad recommends:
ii  kicad-demos  5.0.1+dfsg1-3~bpo9+1
ii  kicad-libraries  5.0.1+dfsg1-3~bpo9+1
ii  xsltproc 1.1.29-2.1

Versions of packages kicad suggests:
ii  extra-xdg-menus   1.0-4
ii  kicad-doc-en  5.0.1+dfsg1-3~bpo9+1
pn  kicad-packages3d  

-- no debconf information

Bug#865795: radvd blocks when started over ssh

[Daniel Reichelt]

Eversince I opened this bug, I used my own patched package. Only now I
just tried 1:2.17-1~bpo9+1 and can confirm that the bug is no longer
present.

Thanks
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#844321: unison: Please update to latest upstream version

[Daniel Reichelt]

Hi,

can we please get the latest upstream version into Buster?

I do realize, there's been a 2.48.4-1 release since I opened this bug.
However, that release is over a year old and upstream has included some
bugfixes since. The current upstream version is 2.48.15.

Thanks,
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#912718: network-manager: SIM PIN queried although it's stored in the system connection profile

[Daniel Reichelt]

Package: network-manager
Version: 1.14.4-2~bpo9+1
Severity: normal

Hi,

when I want to connect via UMTS, I get queried for a SIM PIN, although it's
stored in the system connection profile like so:

-8<--
[gsm]
apn=mygreatAPNname
number=*99#
pin=1234
pin-flags=0
->8--


After I hit  on the PIN dialog, the PIN gets read correctly from the
connection profile and it work's as expected. It's just really annoying...


Thanks
Daniel


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'testing'), (500, 'oldstable'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.26-0+deb9u1
ii  libaudit1  1:2.6.7-2
ii  libbluetooth3  5.43-2+deb9u1
ii  libc6  2.24-11+deb9u3
ii  libcurl3-gnutls7.52.1-5+deb9u8
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u4
ii  libjansson42.9-1
ii  libmm-glib01.6.4-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.19-1+b1
ii  libnm0 1.14.4-2~bpo9+1
ii  libpam-systemd 232-25+deb9u4
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libpsl50.17.0-3
ii  libreadline7   7.0-3
ii  libselinux12.6-3+b3
ii  libsystemd0232-25+deb9u4
ii  libteamdctl0   1.26-1+b1
ii  libudev1   232-25+deb9u4
ii  libuuid1   2.29.2-1+deb9u1
ii  lsb-base   9.20161125
ii  policykit-10.105-18
ii  udev   232-25+deb9u4
ii  wpasupplicant  2:2.4-1+deb9u2

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.76-5+deb9u2
ii  iptables 1.6.2-1.1~bpo9+1
ii  isc-dhcp-client  4.3.5-3+deb9u1
ii  modemmanager 1.6.4-1
ii  ppp  2.4.7-1+4

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#912717: samba: Samba should clean up sockets in /var/lib/samba/private/msg.sock/

[Daniel Reichelt]

Package: samba
Version: 2:4.5.12+dfsg-2+deb9u3
Severity: normal

Hi,

stopping/starting samba, it leaves a mess in /var/lib/samba/private/msg.sock/.
I can reproduce this on every machine I run samba on by simply doing:



# service samba stop ; rm -fv /var/lib/samba/private/msg.sock/* ; service samba 
start ; service samba stop ; ls -l /var/lib/samba/private/msg.sock
[ ok ] Stopping Samba AD DC daemon: samba.
[ ok ] Stopping SMB/CIFS daemon: smbd.
[ ok ] Stopping NetBIOS name server: nmbd.
removed '/var/lib/samba/private/msg.sock/2583'
removed '/var/lib/samba/private/msg.sock/2584'
removed '/var/lib/samba/private/msg.sock/2611'
removed '/var/lib/samba/private/msg.sock/2614'
removed '/var/lib/samba/private/msg.sock/2615'
[ ok ] Starting NetBIOS name server: nmbd.
[ ok ] Starting SMB/CIFS daemon: smbd.
[ ok ] Stopping Samba AD DC daemon: samba.
[ ok ] Stopping SMB/CIFS daemon: smbd.
[ ok ] Stopping NetBIOS name server: nmbd.
total 0
srwxrwxrwx 1 root root 0 Nov  3 09:07 2846
srwxrwxrwx 1 root root 0 Nov  3 09:07 2847
srwxrwxrwx 1 root root 0 Nov  3 09:07 2875
srwxrwxrwx 1 root root 0 Nov  3 09:07 2878
srwxrwxrwx 1 root root 0 Nov  3 09:07 2879



Happy to provide more info when requested. Right now I just don't know what you 
need...


Thanks
Daniel


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'testing'), (500, 'oldstable'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.25
ii  init-system-helpers  1.48
ii  libbsd0  0.8.3-1
ii  libc62.24-11+deb9u3
ii  libldb1  2:1.1.27-1+b1
ii  libpam-modules   1.1.8-3.6
ii  libpam-runtime   1.1.8-3.6
ii  libpopt0 1.16-10+b2
ii  libpython2.7 2.7.13-2+deb9u3
ii  libtalloc2   2.1.9-2~bpo9+1
ii  libtdb1  1.3.11-2
ii  libtevent0   0.9.31-1
ii  libwbclient0 2:4.5.12+dfsg-2+deb9u3
ii  lsb-base 9.20161125
ii  procps   2:3.3.12-3+deb9u1
ii  python   2.7.13-2
ii  python-dnspython 1.15.0-1
ii  python-samba 2:4.5.12+dfsg-2+deb9u3
ii  python2.72.7.13-2+deb9u3
ii  samba-common 2:4.5.12+dfsg-2+deb9u3
ii  samba-common-bin 2:4.5.12+dfsg-2+deb9u3
ii  samba-libs   2:4.5.12+dfsg-2+deb9u3
ii  tdb-tools1.3.11-2
ii  update-inetd 4.44

Versions of packages samba recommends:
ii  attr1:2.4.47-2+b2
ii  logrotate   3.11.0-0.1
ii  samba-dsdb-modules  2:4.5.12+dfsg-2+deb9u3
ii  samba-vfs-modules   2:4.5.12+dfsg-2+deb9u3

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p10+dfsg-3+deb9u2
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information

Bug#908924: possible fix

[Daniel Reichelt]

> I have not tried it, though.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=200709#c6
> https://lkml.org/lkml/2018/10/14/62
> 

I've tried it and can confirm this fixes the issue for me.

Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#908924: git-bisected

[Daniel Reichelt]

FYI: https://bugzilla.kernel.org/show_bug.cgi?id=200709#c5



signature.asc
Description: OpenPGP digital signature

Bug#910627: xul-ext-nostalgy: Please update to upstream 0.2.36 to be compatible with TB 60+

[Daniel Reichelt]

Package: xul-ext-nostalgy
Version: 0.2.34-1
Severity: important

Hi,

please update to the latest version available at [1] so it can be used again
with the version of Thunderbird (60+) shipped in Stretch.

Thanks!
Daniel

[1] https://addons.thunderbird.net/en-US/thunderbird/addon/nostalgy/

Bug#887668: linux-image-4.14.0-rc3-amd64: MosChip MCS9922 serial+parallel port PCI-e card no longer working

[Daniel Reichelt]

>>From [1], I tested all amd64 linux-image packages from 4.13.13-1 (last working
> one) through 4.15~rc8-1~exp1 (still broken).


Sorry I got my references wrong. This should have read:




From [3], I tested all amd64 linux-image packages from 4.13.13-1 (last
working one) through 4.15~rc8-1~exp1 (still broken).


[3] http://snapshot.debian.org/package/linux/



signature.asc
Description: OpenPGP digital signature

Bug#887668: linux-image-4.14.0-rc3-amd64: MosChip MCS9922 serial+parallel port PCI-e card no longer working

[Daniel Reichelt]

Package: linux-image-4.14.0-rc3-amd64
Version: 4.14~rc3-1~exp1
Severity: normal

Hi,

since linux-image-4.14.0-rc3-amd64 my DeLock 4xSerial/1xParallel PCI-e card is
no longer working. lspci recognizes it, but there is no kernel driver shown and
the expected ttyS* device nodes aren't created. The card contains two chips
with the lables MCS9900CV-AA and MCS9922CV-AA.

>From [1], I tested all amd64 linux-image packages from 4.13.13-1 (last working
one) through 4.15~rc8-1~exp1 (still broken).

Attached are the outputs of 'lspci -vv' and 'dmesg' from 4.13.13-1 and
4.14.7-1~bpo9+1


working-dmesg.txt:507 shows the mainboard's serial port as ttyS0, ttyS1-3 are 3
of the 4 serial ports of theDeLock card. (The error in line 511 doesn't concern
me as I only need three ports anyways.)

working-lspci.txt shows "serial" as driver in use. No kernel driver is shown
for the last MosChip device, which is the parallel port. No idea if it actually
works, never needed it, thus untested.


kaputt-dmesg.txt only shows the mainboard's ttyS0 in line 507, the DeLock
card's are missing.

kaputt-lspci.txt does show the MosChips, but no "driver in use".




I was able to get the card running again under 4.14.x with the driver [1]
listed at [2]. Contrary to the archive's readme, a simple 'make' followed by an
'insmod ./99xx.ko' was enough to get it running.

Nonetheless, it would be really nice if this chip was continued to be supported
by the packaged kernel (preventing the need for fooling around with out-of-tree
module builds...).


Thanks
Daniel



[1] 
http://www.asix.com.tw/FrootAttach/driver/MCS99xx_LINUX_Driver_v3.1.0_Source.tar.gz
[2] http://www.asix.com.tw/products.php?op=pItemdetail=122;74;110


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'testing'), (500, 'oldstable'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
[0.00] random: get_random_bytes called from start_kernel+0x3d/0x456 
with crng_init=0
[0.00] Linux version 4.13.0-0.bpo.1-amd64 
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) 
#1 SMP Debian 4.13.13-1~bpo9+1 (2017-11-22)
[0.00] Command line: BOOT_IMAGE=vmlinuz initrd=/initrd.img 
net.ifnames=0 panic=1 vga=791 
initrd=../debian-live-mylive-router2/initrd.img-4.13.0-0.bpo.1-amd64
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbfed] usable
[0.00] BIOS-e820: [mem 0xbfee-0xbfee2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbfee3000-0xbfee] ACPI data
[0.00] BIOS-e820: [mem 0xbfef-0xbfef] reserved
[0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. EP45-DS3/EP45-DS3, BIOS F9 
09/22/2008
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x24 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect
[0.00]   CE000-E uncachable
[0.00]   F-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F write-back
[0.00]   1 base 0C000 mask FC000 uncachable
[0.00]   2 base 1 mask F write-back
[0.00]   3 base 2 mask FC000 write-back
[0.00]   4 base 0BFF0 mask 0 uncachable
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] e820: update [mem 0xbff0-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xbfee0 

Bug#887522: borgbackup: borgfs doesn't work due to broken handling of include/exclude patterns

[Daniel Reichelt]

Package: borgbackup
Version: 1.1.4-1~bpo9+1
Severity: important

Hi,

borgfs is completely unusable since 1.1.4-1~bpo9+1 since it throws an exception
during invocation, no matter the parameters.

For details, please refer to the upstream github issue I've created at [1].

Given the severity and impact, this bug report is meant to track a possible fix
by a patch in debian/ instead of waiting for a new testing release to migrate
to bpo.


Thanks
Daniel


[1] https://github.com/borgbackup/borg/issues/3551



-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'testing'), (500, 'oldstable'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages borgbackup depends on:
ii  fuse   2.9.7-1
ii  libacl12.2.52-3+b1
ii  libb2-10.97+git20171226-2~bpo9+1
ii  libc6  2.24-11+deb9u2
ii  liblz4-1   0.0~r131-2+b1
ii  libssl1.1  1.1.0f-3+deb9u1
ii  python33.5.3-1
ii  python3-llfuse 1.2+dfsg-1
ii  python3-msgpack0.4.8-1
ii  python3-pkg-resources  33.1.1-1

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
ii  borgbackup-doc  1.1.4-1~bpo9+1

Bug#884827: phpmyadmin: dpkg-reconfigure fails when a custom DB name is specified for PMA

[Daniel Reichelt]

Package: phpmyadmin
Version: 4:4.6.6-4
Severity: normal

Hi,

running dpkg-reconfigure phpmyadmin on a Stretch machine, telling it to 
reinstall the database while
specifying a custom DB name other than phpmyadmin, fails like this:

-8<---
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf
checking privileges on database sys_phpmyadmin for sys_phpmyadmin@localhost: 
user creation needed.
granting access to database sys_phpmyadmin for sys_phpmyadmin@localhost: 
success.
verifying access for sys_phpmyadmin@localhost: success.
dbconfig-common: dumping mysql database sys_phpmyadmin to 
/var/tmp/phpmyadmin.sys_phpmyadmin.2017-12-20-04.23.mysql.6Ur1Cg.
dbconfig-common: dropping old mysql database sys_phpmyadmin.
dropping database sys_phpmyadmin: success.
verifying database sys_phpmyadmin was dropped: success.
creating database sys_phpmyadmin: success.
verifying database sys_phpmyadmin exists: success.
populating database via sql...  error encountered populating database:
mysql said: ERROR 1044 (42000) at line 20: Access denied for user 
'sys_phpmyadmin'@'localhost' to database 'phpmyadmin'
->8---


NB: 'phpmyadmin' in the last line althtough the DB name specified was
'sys_phpmyadmin', which did get respected in the prior lines.


dbconfig-common uses /usr/share/dbconfig-common/data/phpmyadmin/install/mysql
to bootstrap the PMA database, which contains at the very top these interfering
statements:

-8<---
CREATE DATABASE IF NOT EXISTS `phpmyadmin`[...];
USE phpmyadmin;
->8---



After I commented-out both statements (not required since dbconfig-common
handles DB creation itself anyway), dpkg-reconfigure ran through and PMA was
correctly configured to use the custom-named  DB.



Thanks

Daniel




-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'testing'), (500, 'oldstable'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages phpmyadmin depends on:
ii  dbconfig-common 2.0.9~bpo9+1
ii  dbconfig-mysql  2.0.9~bpo9+1
ii  debconf [debconf-2.0]   1.5.61
ii  libjs-sphinxdoc 1.4.9-2
ii  perl5.24.1-3+deb9u2
ii  php 1:7.0+49
ii  php-mbstring1:7.0+49
ii  php-mysql   1:7.0+49
ii  php-php-gettext 1.0.12-0.1
ii  php-phpseclib   2.0.4-1
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.19-1
ii  php7.0-cli [php-cli]7.0.19-1
ii  php7.0-json [php-json]  7.0.19-1
ii  php7.0-mbstring [php-mbstring]  7.0.19-1
ii  php7.0-xml [php-xml]7.0.19-1
ii  ucf 3.0036

Bug#881941: Please consider to let live-build add file /.disk/mkisofs to the ISO

[Daniel Reichelt]

On 12/06/2017 09:04 PM, Thomas Schmitt wrote:
> Raphaël, are you aware that the change in live-build
>   
> https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=ff71712590a809d0f7ba680e787a9f091ed853b2
> did not work and caused
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881941
> ?

He already merged the patch in live-build's git [1]



> Depending on when "binary.sh" gets finally executed
> this architectural change might cause undesired effects.

Do you have a conrete example of when the patch fails?



>  DISK_MKISOFS="$(echo "xorriso -as mkisofs ${XORRISO_OPTIONS} -o ${IMAGE} 
> binary" | sed -e s"/'/'"'"'"'"'"'"'/g")"

That's illegible, difficult to understand and therefore impractical to
maintain.


I moved the HERE-document back to binary_iso because the generated
script initially was supposed to be a wrapper script around xorriso and
I didn't see a specific need for the creation of the cmdline file to be
wrapped as well. If that change causes trouble, I'd deem it much more
practical to move the generation back into the wrapper script, sticking
with the HERE-document.


Cheers
Daniel

(CC'ing #881941)


[1]
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=9f3e5fe8d968f79fbd1f4c60fb6b020758fe8510



signature.asc
Description: OpenPGP digital signature

Bug#882196: ssh: apt-get install ssh broken for i386

[Daniel Reichelt]

Package: ssh
Version: 1:6.7p1-5+deb8u4
Severity: normal

Hi,

on a pure-jessie-vm `apt-get install ssh` currently fails with:
--8<
# apt-get install ssh
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ssh : Depends: openssh-client (>= 1:6.7p1-5+deb8u4) but 1:6.7p1-5+deb8u3 is to 
be installed
Depends: openssh-server (>= 1:6.7p1-5+deb8u4) but 1:6.7p1-5+deb8u3 is 
to be installed
E: Unable to correct problems, you have held broken packages.

-->8


I suspect this stems from yesterday's upload [1] containing only .debs for
amd64 and the ssh_6.7p1-5+deb8u4_all.deb, the latter depending on currently
unavailable openssh-(client|server)_6.7p1-5+deb8u4_i386.deb...

In fact I suspect `apt-get install ssh` on jessie currently would fail on ANY
arch except amd64.


Cheers
Daniel


[1] https://packages.qa.debian.org/o/openssh/news/20171119T224745Z.html



-- System Information:
Debian Release: 8.9
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ssh depends on:
ii  dpkg1.17.27
ii  openssh-client  1:6.7p1-5+deb8u3
ii  openssh-server  1:6.7p1-5+deb8u3

ssh recommends no packages.

ssh suggests no packages.

-- no debconf information

Bug#881941: live-build: Creation of .disk/mkisofs is broken

[Daniel Reichelt]

Package: live-build
Version: 1:20170920
Severity: normal
Tags: patch

Hi,

currently .disk/mkisofs gets created by appending an echo statement to
the temporary script binary.sh whicht gets executed to actually run xorriso.

However this creates the following error in build.log:

---8<---
[...]
[2017-11-16 20:52:38] lb binary_checksums
P: Begin creating binary md5sum.txt...
[2017-11-16 20:52:38] lb binary_iso
P: Begin building binary iso image...
The following NEW packages will be installed:
  isolinux libburn4{a} libisoburn1{a} libisofs6{a} libjte1{a} xorriso
The following packages are RECOMMENDED but will NOT be installed:
  syslinux-common
0 packages upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 1154 kB of archives. After unpacking 2367 kB will be used.
Get: 1 http://ftp.debian.org/debian stretch/main amd64 isolinux all 
3:6.03+dfsg-14.1 [94.0 kB]
Get: 2 http://ftp.debian.org/debian stretch/main amd64 libburn4 amd64 1.4.6-1 
[156 kB]
Get: 3 http://ftp.debian.org/debian stretch/main amd64 libjte1 amd64 1.20-2+b1 
[28.4 kB]
Get: 4 http://ftp.debian.org/debian stretch/main amd64 libisofs6 amd64 1.4.6-1 
[198 kB]
Get: 5 http://ftp.debian.org/debian stretch/main amd64 libisoburn1 amd64 
1.4.6-1+b1 [379 kB]
Get: 6 http://ftp.debian.org/debian stretch/main amd64 xorriso amd64 1.4.6-1+b1 
[299 kB]
Fetched 1154 kB in 0s (2760 kB/s)
[...]
Setting up libisofs6:amd64 (1.4.6-1) ...
Setting up libisoburn1:amd64 (1.4.6-1+b1) ...
Setting up xorriso (1.4.6-1+b1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...

xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level 3 
-isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -A Debian 
Live -p live-build 1:20170920
binary.sh: 4: binary.sh: https://debian-live.alioth.debian.org/live-build 
-publisher Live: not found
binary.sh: 4: binary.sh: https://debian-live.alioth.debian.org/: not found
binary.sh: 4: binary.sh: debian-l...@lists.debian.org -V Debian: not found
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.
[...]
--->8---





binary.sh, as generated by binary_iso, contains:
---8<---
# cat chroot/binary.sh
#!/bin/sh

mkdir -p binary/.disk
echo "xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level 3 
-isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -A "Debian 
Live" -p "live-build 1:20170920; 
https://debian-live.alioth.debian.org/live-build; -publisher "Live Systems 
project; https://debian-live.alioth.debian.org/; debian-l...@lists.debian.org" 
-V "Debian stretch 20171116-20:52" --modification-date=2017111619114000 -b 
isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 
-boot-info-table -eltorito-alt-boot  -e boot/grub/efi.img -no-emul-boot 
-isohybrid-gpt-basdat -isohybrid-apm-hfsplus -o live-image-amd64.hybrid.iso 
binary" > binary/.disk/mkisofs
xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level 3 
-isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -A "Debian 
Live" -p "live-build 1:20170920; 
https://debian-live.alioth.debian.org/live-build; -publisher "Live Systems 
project; https://debian-live.alioth.debian.org/; debian-l...@lists.debian.org" 
-V "Debian stretch 20171116-20:52" --modification-date=2017111619114000 -b 
isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 
-boot-info-table -eltorito-alt-boot  -e boot/grub/efi.img -no-emul-boot 
-isohybrid-gpt-basdat -isohybrid-apm-hfsplus -o live-image-amd64.hybrid.iso 
binary
--->8---


As you can see, the pairs of quotes in the echo line don't match up as
intended:


echo "xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level \
 ^--- open #1



[...] -partition_offset 16 -A "Debian Live" -p "live-build 1:20170920;[...]
  close #1 ---^   open#2--^^---close #2
 \v/
   interpreted by sh



Subsequently, the generated .disk/mkisofs is empty.






The attached patch moves the generation of .disk/mkisofs out of binary.sh and
back to the enclosing binary_iso, replacing echo by a HERE document which is
not prone to this kind of issue.






With this patch applied, build.log no longer shows "not found" errors and the
generated .disk/mkisofs contains:

---8<---
xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level 3 
-isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -A "Debian 
Live" -p "live-build 1:20170920; 
https://debian-live.alioth.debian.org/live-build; -publisher "Live Systems 
project; https://debian-live.alioth.debian.org/; debian-l...@lists.debian.org" 
-V "Debian stretch 20171116-21:12" --modification-date=2017111620114500 -b 
isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot 

Bug#881921: nvidia-legacy-340xx-driver: Compile error when building module for stretch-bpo kernel (currently 4.13.0-0-bpo.1-amd64)

[Daniel Reichelt]

> If you install the kernel from backports, then you also need to pick
> the drivers from backports. Mix-and-match is never guaranteed to work
> as updates to stable are much rarer and slower, so they can't possibly
> keep up with new kernels coming out.
> 

Thanks for your quick reply and the hint! I didn't even think of that m(

I just retried on a pure buster box, and it worked fine. Seeing that
there is no nvidia-legacy-340xx-driver package in stretch/bpo, am I
right to assume that the combination of a bpo-kernel with 340xx-legacy
currently just won't work?



signature.asc
Description: OpenPGP digital signature

Bug#881921: nvidia-legacy-340xx-driver: Compile error when building module for stretch-bpo kernel (currently 4.13.0-0-bpo.1-amd64)

[Daniel Reichelt]

Package: nvidia-legacy-340xx-driver
Version: 340.102-1
Severity: important

Hi,

on a stretch system which has (only) the current bpo-kernel installed,
nvidia-legacy-340xx-driver fails to compile the nvidia module.

Please find attached the console log of

`apt-get -y install nvidia-legacy-340xx-driver 2>&1 | tee console.log`

and dkms'

/var/lib/dkms/nvidia-legacy-340xx/340.102/build/make.log .

Hauler if you need more info.


Thanks
Daniel



-- Package-specific info:
uname -a:
Linux host-151 4.13.0-0.bpo.1-amd64 #1 SMP Debian 4.13.4-2~bpo9+1 (2017-10-17) 
x86_64 GNU/Linux

/proc/version:
Linux version 4.13.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.13.4-2~bpo9+1 
(2017-10-17)
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libegl1-nvidia-legacy-340xx libegl1-nvidia-legacy-340xx:i386
  libgl1-nvidia-legacy-340xx-glx libgl1-nvidia-legacy-340xx-glx:i386
  libgles1-nvidia-legacy-340xx libgles1-nvidia-legacy-340xx:i386
  libgles2-nvidia-legacy-340xx libgles2-nvidia-legacy-340xx:i386
  libnvidia-legacy-340xx-cfg1 libnvidia-legacy-340xx-cfg1:i386
  libnvidia-legacy-340xx-eglcore libnvidia-legacy-340xx-eglcore:i386
  libnvidia-legacy-340xx-glcore libnvidia-legacy-340xx-glcore:i386
  libnvidia-legacy-340xx-ml1 nvidia-legacy-340xx-alternative
  nvidia-legacy-340xx-driver-bin nvidia-legacy-340xx-driver-libs
  nvidia-legacy-340xx-driver-libs:i386
  nvidia-legacy-340xx-driver-libs-i386:i386 nvidia-legacy-340xx-kernel-dkms
  nvidia-legacy-340xx-kernel-support nvidia-legacy-340xx-vdpau-driver
  nvidia-settings-legacy-340xx xserver-xorg-video-nvidia-legacy-340xx
The following NEW packages will be installed:
  libegl1-nvidia-legacy-340xx libegl1-nvidia-legacy-340xx:i386
  libgl1-nvidia-legacy-340xx-glx libgl1-nvidia-legacy-340xx-glx:i386
  libgles1-nvidia-legacy-340xx libgles1-nvidia-legacy-340xx:i386
  libgles2-nvidia-legacy-340xx libgles2-nvidia-legacy-340xx:i386
  libnvidia-legacy-340xx-cfg1 libnvidia-legacy-340xx-cfg1:i386
  libnvidia-legacy-340xx-eglcore libnvidia-legacy-340xx-eglcore:i386
  libnvidia-legacy-340xx-glcore libnvidia-legacy-340xx-glcore:i386
  libnvidia-legacy-340xx-ml1 nvidia-legacy-340xx-alternative
  nvidia-legacy-340xx-driver nvidia-legacy-340xx-driver-bin
  nvidia-legacy-340xx-driver-libs nvidia-legacy-340xx-driver-libs:i386
  nvidia-legacy-340xx-driver-libs-i386:i386 nvidia-legacy-340xx-kernel-dkms
  nvidia-legacy-340xx-kernel-support nvidia-legacy-340xx-vdpau-driver
  nvidia-settings-legacy-340xx xserver-xorg-video-nvidia-legacy-340xx
0 upgraded, 26 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/39.4 MB of archives.
After this operation, 216 MB of additional disk space will be used.
Selecting previously unselected package nvidia-legacy-340xx-alternative.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 446332 files and directories currently installed.)
Preparing to unpack .../00-nvidia-legacy-340xx-alternative_340.102-1_amd64.deb 
...
Unpacking nvidia-legacy-340xx-alternative (340.102-1) ...
Selecting previously unselected package libnvidia-legacy-340xx-glcore:i386.
Preparing to unpack .../01-libnvidia-legacy-340xx-glcore_340.102-1_i386.deb ...
Unpacking libnvidia-legacy-340xx-glcore:i386 (340.102-1) ...
Selecting previously unselected package libgl1-nvidia-legacy-340xx-glx:i386.
Preparing to unpack .../02-libgl1-nvidia-legacy-340xx-glx_340.102-1_i386.deb ...
Unpacking libgl1-nvidia-legacy-340xx-glx:i386 (340.102-1) ...
Selecting previously unselected package libnvidia-legacy-340xx-glcore:amd64.
Preparing to unpack .../03-libnvidia-legacy-340xx-glcore_340.102-1_amd64.deb ...
Unpacking libnvidia-legacy-340xx-glcore:amd64 (340.102-1) ...
Selecting previously unselected package libgl1-nvidia-legacy-340xx-glx:amd64.
Preparing to unpack .../04-libgl1-nvidia-legacy-340xx-glx_340.102-1_amd64.deb 
...
Unpacking libgl1-nvidia-legacy-340xx-glx:amd64 (340.102-1) ...
Selecting previously unselected package libnvidia-legacy-340xx-eglcore:amd64.
Preparing to unpack .../05-libnvidia-legacy-340xx-eglcore_340.102-1_amd64.deb 
...
Unpacking libnvidia-legacy-340xx-eglcore:amd64 (340.102-1) ...
Selecting previously unselected package libegl1-nvidia-legacy-340xx:amd64.
Preparing to unpack .../06-libegl1-nvidia-legacy-340xx_340.102-1_amd64.deb ...
Unpacking libegl1-nvidia-legacy-340xx:amd64 (340.102-1) ...
Selecting previously 

Bug#881189: dwww-index++: make sleep time after each file configurable

[Daniel Reichelt]

Package: dwww
Version: 1.13.3+b1
Severity: normal
Tags: patch

Hi,

presumably to keep a machine's load low during indexing, dwww-index++ sleeps
0.15s before feeding the next file to index to index++.

During the generation of live-images, a huge amount of time is just wasted when
running dwww-index++ from a hook script. The attached patch allows for
configuration of the sleep time via dwww.conf.

For my build system (the build root residing on a tmpfs) and live-image package
list, this reduces the execution time of dwww-index++ from ~40min to 20s. \o/



The second patch solves a problem I stumbled upon while I created the first
one: any config variable containing a value that evaluates to boolean false
in a ternary expression would get ignored, its hard-coded default value taking
effect instead.

The patch changes the check to rely on defined($var) instead of the variable's
specific content.




Cheers

Daniel
>From 3406a2866a209f2686bb123723c813e29fd3a3b9 Mon Sep 17 00:00:00 2001
From: Daniel Reichelt <deb...@nachtgeist.net>
Date: Wed, 8 Nov 2017 18:25:20 +0100
Subject: [PATCH 2/2] Allow for config values which evaluate to boolean false

Setting e.g. DWWW_INDEX_FULL_SLEEP_TIME to 0 would be evaluated to false
and thus cause the corresponding default value from $cfgvars to be used.

This changes the check to not rely on the specific contents of variables
and to check whether they are defined instead.
---
 perl/Debian/Dwww/Initialize.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl/Debian/Dwww/Initialize.pm b/perl/Debian/Dwww/Initialize.pm
index 9c633ed..114784e 100644
--- a/perl/Debian/Dwww/Initialize.pm
+++ b/perl/Debian/Dwww/Initialize.pm
@@ -18,7 +18,7 @@ sub DwwwInitialize($) {
 my $cfgvars  = ReadConfigFile($filename);
 my $dwwwvars = {};
 
-map +{ $dwwwvars->{$_} = $cfgvars->{$_}->{'cfgval'} ? 
$cfgvars->{$_}->{'cfgval'}
+map +{ $dwwwvars->{$_} = defined($cfgvars->{$_}->{'cfgval'}) ? 
$cfgvars->{$_}->{'cfgval'}
: 
$cfgvars->{$_}->{'defval'} }, keys %$cfgvars;
 
 umask (022);
-- 
2.14.2

>From 406a428249f71fed8ed1228360846373f2e4a76b Mon Sep 17 00:00:00 2001
From: Daniel Reichelt <deb...@nachtgeist.net>
Date: Wed, 8 Nov 2017 18:25:20 +0100
Subject: [PATCH 1/2] dwww-index++: make sleep time after each file
 configurable

---
 man/dwww.7 | 8 
 perl/Debian/Dwww/ConfigFile.pm | 5 +
 scripts/dwww-index++   | 6 +++---
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/man/dwww.7 b/man/dwww.7
index 68d066a..8b6962b 100644
--- a/man/dwww.7
+++ b/man/dwww.7
@@ -230,6 +230,14 @@ If this variable is set to
 .BR dwww\-index++ (8)
 will generate index of registered documentation.
 .\"
+.IP DWWW_INDEX_FULL_SLEEP_TIME
+In order to not impede regular server operation,
+.BR dwww\-index++ (8)
+sleeps for the specified amount of time (in seconds) before feeding the next 
file path to index to
+.BR index++ (1).
+The default value is
+.BR 0.15 .
+.\"
 .IP DWWW_INDEX_FULL_TIME_INTERVAL
 Specifies how often (in days) 
 .BR dwww\-index++ (8)
diff --git a/perl/Debian/Dwww/ConfigFile.pm b/perl/Debian/Dwww/ConfigFile.pm
index 664180f..c75cd51 100644
--- a/perl/Debian/Dwww/ConfigFile.pm
+++ b/perl/Debian/Dwww/ConfigFile.pm
@@ -96,6 +96,11 @@ sub ReadConfigFile($) {
 defval => 28,
 descr  => 'How often (in days) dwww-index++(8) will generate full 
index of documentation.'
 },
+'DWWW_INDEX_FULL_SLEEP_TIME' => {
+sort   => 50,
+defval => 0.15,
+descr  => 'How long (in seconds) dwww-index++ should sleep after 
each file in order to not impact regular server operation.'
+},
 'DWWW_INDEX_INCREMENTAL_TIME_INTERVAL'  => {
 sort   => 50,
 defval => 7,
diff --git a/scripts/dwww-index++ b/scripts/dwww-index++
index 59e3ab1..1e49350 100755
--- a/scripts/dwww-index++
+++ b/scripts/dwww-index++
@@ -218,9 +218,9 @@ sub WriteListOfFilesToIndex($$ ) { # {{{
my $do_sleep= shift;
 
foreach my $f (sort keys %new_files_hash) {
-   syswrite $FH, "$new_files_hash{$f}\n";
-   # sleep 150 ms
-select(undef, undef, undef, 0.15) if $do_sleep;
+   syswrite $FH, "$new_files_hash{$f}\n";
+   # sleep the configured amount of time, if $do_sleep
+   select(undef, undef, undef, $dwwwconf->{'DWWW_INDEX_FULL_SLEEP_TIME'}) 
if $do_sleep;
}
 } # }}}
 
-- 
2.14.2

Bug#879771: init-system-helpers: update-rc.d falsly creates K-symlinks on installation which breaks switching init systems later

[Daniel Reichelt]

Package: init-system-helpers
Version: 1.50
Severity: important
Tags: patch

Hi,

Assume this environment:

- debootstrap sid
- chroot apt-get install openssh-server


With init-system-helpers <1.50 you would now find S-symlinks in
etc/rc?.d. However with init-system-helpers 1.50, you'll see erroneously
created K-symlinks - which doesn't matter, systemd being used for init -
but...

...if you were now to switch the init system to sysv-rc or openrc,
update-rc.d would see the kill-symlinks, think they had been disabled by
the user and not touch them any further. This most likely leaves any
server system unusable after a reboot, ifupdown (/etc/init.d/networking)
or any other init-script-carrying package being affected as well.


Please find attached a patch for the update-rc.d script.

The initial discussion is available at [1].


Cheers

Daniel





[1] https://lists.debian.org/debian-devel/2017/10/msg00439.html
--- init-system-helpers-1.50/script/update-rc.d 2017-10-13 01:16:13.0 
+0200
+++ patched/scriptsupdate-rc.d  2017-10-25 17:59:18.290021026 +0200
@@ -110,7 +110,7 @@
 
 # for "defaults", parse Default-{Start,Stop} and create these links
 my ($lsb_start_ref, $lsb_stop_ref) = 
parse_def_start_stop("/etc/init.d/$scriptname");
-my $start = $action = "defaults-disabled" ? "K" : "S";
+my $start = $action eq "defaults-disabled" ? "K" : "S";
 foreach my $lvl (@$lsb_start_ref) {
 make_path("/etc/rc$lvl.d");
 my $l = "/etc/rc$lvl.d/${start}01$scriptname";

Bug#877439: lintian: script-needs-depends-on-sensible-utils triggers although depends on sensible-utils is present

[Daniel Reichelt]

Package: lintian
Version: 2.5.53~bpo9+1
Severity: normal

Hi,

since I updated lintian from 2.5.51~bpo9+1 to 2.5.53~bpo9+1 I keep
geeting a false positive of script-needs-depends-on-sensible-utils, even
after I added a dependency on sensible-utils.

Please find attached a minimal PoC-package, which, when dpkg-build'ing and
lintian'ing yields:


8<
$ dpkg-buildpackage -uc -us ; lintian ../*deb
dpkg-buildpackage: info: source package lintian-sensible-utils-test-package
dpkg-buildpackage: info: source version 0.1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Daniel Reichelt 
<deb...@nachtgeist.net>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build lintian-sensible-utils-test-package-0.1
 fakeroot debian/rules clean
dh clean
   dh_auto_clean
   dh_clean
 dpkg-source -b lintian-sensible-utils-test-package-0.1
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building lintian-sensible-utils-test-package in
lintian-sensible-utils-test-package_0.1.tar.xz
dpkg-source: info: building lintian-sensible-utils-test-package in
lintian-sensible-utils-test-package_0.1.dsc
 debian/rules build
dh build
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
   dh_auto_test
 fakeroot debian/rules binary
dh binary
   dh_testroot
   dh_prep
   dh_auto_install
   dh_install
   dh_installdocs
   dh_installchangelogs
   dh_lintian
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   dh_gencontrol
dpkg-gencontrol: warning: Depends field of package
lintian-sensible-utils-test-package: unknown substitution variable
${shlibs:Depends}
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'lintian-sensible-utils-test-package' in
'../lintian-sensible-utils-test-package_0.1_amd64.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges  >../lintian-sensible-utils-test-package_0.1_amd64.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build lintian-sensible-utils-test-package-0.1
dpkg-buildpackage: info: full upload; Debian-native package (full source is
included)


E: lintian-sensible-utils-test-package: script-needs-depends-on-sensible-utils
usr/bin/testscript (line 2)
^^^


N: 1 tag overridden (1 warning)
   ^--- This one stems from an overridden binary-without-manpage
>8





Thanks

Daniel


lintian-sensible-utils-test-package_0.1.tar.xz
Description: application/xz

Bug#877182: logcheck: command-line option -D advertised but not recognized

[Daniel Reichelt]

Package: logcheck
Version: 1.3.18
Severity: normal

Hi,


8<
# sudo -u logcheck logcheck -to -D some_path
/usr/sbin/logcheck: illegal option -- D
usage: logcheck [-c CFG] [-d] [-h] [-H HOST] [-l LOG] [-L CFG] [-D DIR] [-m 
MAIL] [-o]
[-r DIR] [-s|-p|-w] [-R] [-S DIR] [-t] [-T] [-u]
 -c CFG   = override default configuration file
 -d   = debug mode
[...]
>8


The attached patch fixes the getopt options string.



Thanks,

Daniel
--- /usr/sbin/logcheck.orig 2017-09-29 16:02:27.026934660 +0200
+++ /usr/sbin/logcheck  2017-09-29 16:02:34.374951541 +0200
@@ -47,7 +47,7 @@
 ATTACK=0
 
 # Set the getopts string
-GETOPTS="c:dhH:l:L:m:opr:RsS:tTuvw"
+GETOPTS="c:dhH:l:L:D:m:opr:RsS:tTuvw"
 
 # Get the details for the email message
 DATE="$(date +'%Y-%m-%d %H:%M %z')"

Bug#876898: manpages: versioned dependency "<< 4.13-3" in Breaks field is too restrictive for stretch-backports

[Daniel Reichelt]

4.13-3~bpo9+2 works fine now.

Thanks, Tobias!




signature.asc
Description: OpenPGP digital signature

Bug#876898: manpages: versioned dependency "<< 4.13-3" in Breaks field is too restrictive for stretch-backports

[Daniel Reichelt]

Package: manpages
Version: 4.13-3~bpo9+1
Severity: normal

Hi,

upgrading manpages and manpages-dev to stretch-bpo doesn't work on
my stretch machine:

8<
# apt-get install manpages/stretch-backports manpages-dev/stretch-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '4.13-3~bpo9+1' (Debian Backports:stretch-backports [all]) for 
'manpages'
Selected version '4.13-3~bpo9+1' (Debian Backports:stretch-backports [all]) for 
'manpages-dev'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 manpages : Breaks: manpages-dev (< 4.13-3) but 4.13-3~bpo9+1 is to be installed
Breaks: manpages-dev:i386 (< 4.13-3)
 manpages-dev : Breaks: manpages (< 4.13-3) but 4.13-3~bpo9+1 is to be installed
Breaks: manpages:i386 (< 4.13-3)
E: Unable to correct problems, you have held broken packages.
>8



I'm not familiar with the dpkg/apt internals and how exactly versions are
compared to each other, but it seems to me like

"Breaks: [...] manpages (<< 4.13-3)"

gets rated higher than the package's version in stretch-backports
(4.13-3~bpo9+1).


So I guess, at least for the bpo-build, Breaks needs to be somewhat relaxed.



Cheers

Daniel

Bug#848982: wpasupplicant fails to connect to WPA Enterprise network with 2.6-2

[Daniel Reichelt]

I'm suffering the very same problem than the OP with my employer's WiFi
network.


> If I downgrade libssl1.0.2 to 1.0.2j-1 then I can connect to the
> WPA-EAP network without problem.

Good catch downgrading openssl! I can confirm the WiFi connection to
work up to libssl1.0.2-4 [1], so I guess the fix for #736687 is to blame
for this [2]:

 * Mark RC4 and 3DES as weak which removes them from the SSL/TLS
protocol (Closes: #736687).



As a *dirty* workaround, I

- re-upgraded to libssl1.0.2ll-2/stretch
- renamed /sbin/wpa_supplicant and put a wrapper script in its place
- which sets LD_LIBRARY_PATH to a location containing libssl.so.1.0.2
from [1] and then starts the renamed wpa_supplicant binary with the
original command-line parameters.



HTH,

Daniel



[1]
http://snapshot.debian.org/package/openssl1.0/1.0.2j-4/#libssl1.0.2_1.0.2j-4

[2]
https://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/openssl1.0/debian/patches/Mark-3DES-and-RC4-ciphers-as-weak.patch?revision=865=markup=log



signature.asc
Description: OpenPGP digital signature

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

On 08/30/2017 12:18 AM, Ben Hutchings wrote:
> I can't reproduce this.  What driver is used for eth0 (ethtool -i shows
> this)?

Ben,

you're on to something:


# ethtool -i eth0
driver: vif
version:
firmware-version:
expansion-rom-version:
bus-info: vif-0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no



Indeed, this only happens in XEN guests running on a jessie host (didn't
get around yet to test whether a stretch host makes the difference).

On any other hw I own (a couple of e1000e and a r8169), ethtool always
exits 0, with changes to offloading having been made or not.

Sorry for not mentioning the fact about VMs earlier...just didn't think
of it.


Cheers
Daniel




signature.asc
Description: OpenPGP digital signature

Bug#871645: virtualbox: NatNetwork doesn't allow connections beyond the host due to VBoxNetNAT missing the suid bit

[Daniel Reichelt]

Package: virtualbox
Version: 5.1.26-dfsg-2
Severity: normal

Dear Maintainer,

when creating VMs, each with a NatNetwork NIC, the VMs can happily talk
to each other but network access beyond the virtualbox host is not
possible. Conventional NAT mode is not affected and works perfeclty
fine.




Fix:

# chmod u+s /usr/lib/virtualbox/VBoxNetNAT

…and kill off possibly lingering VBoxNetNAT processes and restart the
VMs --> network access beyond the vbox host should work now.




I just confirmed that the generic linux installer package from
virtualbox.org installs the VBoxNetNAT binary as suid.


Cheers
Daniel


-- System Information:
Debian Release: 9.1
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'testing'), 
(500, 'oldstable'), (98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Bug#868559: live-boot: httpfs does not work due to util-linux's mount being used

[Daniel Reichelt]

Package: live-boot
Version: 1:20170623
Severity: normal

Hi,

when building a stretch live image which includes httpfs/buster for the created
live-image's initramfs to support live-boot's httpfs switch, the boot process
fails in a way similar to what has been reported in #823856.

Special handling for ${FUSE_MOUNT}s (httpfs, curlftps) was added to use
util-linux's mount instead of the klibc's in such cases. I tested the use of a
FUSE-based rootfs in conjunction with klibc's mount, and it seems, nowadays the
both of them work together.

So, the conditional incorporation and replacement of the mount command is both
no longer necessary, and has become harmful. The attached patch against
live-boot's current tag 1%20170623 removes it.


Cheers

Daniel
>From 3891e35f1df321e44e51347df95938346c108ef4 Mon Sep 17 00:00:00 2001
From: Daniel Reichelt <deb...@nachtgeist.net>
Date: Sun, 16 Jul 2017 17:15:46 +0200
Subject: [PATCH] use klibc's mount again for ${FUSE_MOUNT}s

---
 backend/initramfs-tools/live.hook | 4 
 components/9990-mount-http.sh | 6 --
 2 files changed, 10 deletions(-)

diff --git a/backend/initramfs-tools/live.hook b/backend/initramfs-tools/live.hook
index 1ce922d..c5d7266 100755
--- a/backend/initramfs-tools/live.hook
+++ b/backend/initramfs-tools/live.hook
@@ -149,10 +149,6 @@ then
 	copy_exec /usr/bin/eject /bin
 fi
 
-# Program: mount
-# fuse does not work with klibc mount
-copy_exec /bin/mount /bin/mount.util-linux
-
 [ "${QUIET}" ] || echo -n " utils"
 
 # Feature: Verify Checksums
diff --git a/components/9990-mount-http.sh b/components/9990-mount-http.sh
index 2e68fe6..f58c3a3 100755
--- a/components/9990-mount-http.sh
+++ b/components/9990-mount-http.sh
@@ -54,12 +54,6 @@ do_httpmount ()
 			FUSE_MOUNT="httpfs"
 		fi
 
-		if [ -n "${FUSE_MOUNT}" ] && [ -x /bin/mount.util-linux ]
-		then
-			# fuse does not work with klibc mount
-			ln -f /bin/mount.util-linux /bin/mount
-		fi
-
 		modprobe fuse
 		$FUSE_MOUNT "${url}" "${dest}"
 		ROOT_PID="$(minips h -C "$FUSE_MOUNT" | { read x y ; echo "$x" ; } )"
-- 
2.1.4

Bug#865795: radvd blocks when started over ssh

[Daniel Reichelt]

> But I will spent my time on packaging 2.17-rc1 or 2.17


All the better, thanks.

Does that mean you're going to upload 2.17 to stretch as well?



signature.asc
Description: OpenPGP digital signature

Bug#865795: radvd blocks when started over ssh

[Daniel Reichelt]

Hi again,

upstream solved this issue [1], [2] by always closing
stdin/stdout/stderr when daemonizing.

Please find attached a git commit against your tag debian/1%2.15-2
adding a quilt patch.


Cheers
Daniel



[1] https://github.com/reubenhwk/radvd/pull/72
[2]
https://github.com/reubenhwk/radvd/commit/5cfc48b9ed75eb5f5e127b0d24a18b728b20e9af
From 47e162d9c75253abef86e25a41808ab5230a3168 Mon Sep 17 00:00:00 2001
From: Daniel Reichelt <deb...@nachtgeist.net>
Date: Sun, 2 Jul 2017 12:21:18 +0200
Subject: [PATCH] add patch to always close STD* FDs on daemonizing

fixes #865795
---
 ...ose_std_file_descriptors_when_daemonizing.patch | 81 ++
 debian/patches/series  |  1 +
 2 files changed, 82 insertions(+)
 create mode 100644 debian/patches/always_close_std_file_descriptors_when_daemonizing.patch

diff --git a/debian/patches/always_close_std_file_descriptors_when_daemonizing.patch b/debian/patches/always_close_std_file_descriptors_when_daemonizing.patch
new file mode 100644
index 000..4a6e291
--- /dev/null
+++ b/debian/patches/always_close_std_file_descriptors_when_daemonizing.patch
@@ -0,0 +1,81 @@
+Index: radvd/radvd.c
+===
+--- radvd.orig/radvd.c
 radvd/radvd.c
+@@ -82,7 +82,7 @@ static int check_conffile_perm(const cha
+ static int drop_root_privileges(const char *);
+ static int open_and_lock_pid_file(char const * daemon_pid_file_ident);
+ static int write_pid_file(char const * daemon_pid_file_ident, pid_t pid);
+-static pid_t daemonp(int nochdir, int noclose, char const * daemon_pid_file_ident);
++static pid_t daemonp(char const * daemon_pid_file_ident);
+ static pid_t do_daemonize(int log_method, char const * daemon_pid_file_ident);
+ static struct Interface * main_loop(int sock, struct Interface *ifaces, char const *conf_path);
+ static struct Interface *reload_config(int sock, struct Interface *ifaces, char const *conf_path);
+@@ -106,7 +106,7 @@ static void version(void);
+ /* daemonize and write pid file.  The pid of the daemon child process
+  * will be written to the pid file from the *parent* process.  This
+  * insures there is no race condition as described in redhat bug 664783. */
+-static pid_t daemonp(int nochdir, int noclose, char const * daemon_pid_file_ident)
++static pid_t daemonp(char const * daemon_pid_file_ident)
+ {
+ 	int pipe_ends[2];
+ 
+@@ -138,28 +138,24 @@ static pid_t daemonp(int nochdir, int no
+ 			exit(-1);
+ 		}
+ 
+-		if (nochdir == 0) {
+-			if (chdir("/") == -1) {
+-perror("chdir");
+-exit(1);
+-			}
++		if (chdir("/") == -1) {
++			perror("chdir");
++			exit(1);
+ 		}
+-		if (noclose == 0) {
+-			close(STDIN_FILENO);
+-			close(STDOUT_FILENO);
+-			close(STDERR_FILENO);
+-			if (open("/dev/null", O_RDONLY) == -1) {
+-flog(LOG_ERR, "unable to redirect stdin to /dev/null");
+-exit(-1);
+-			}
+-			if (open("/dev/null", O_WRONLY) == -1) {
+-flog(LOG_ERR, "unable to redirect stdout to /dev/null");
+-exit(-1);
+-			}
+-			if (open("/dev/null", O_RDWR) == -1) {
+-flog(LOG_ERR, "unable to redirect stderr to /dev/null");
+-exit(-1);
+-			}
++		close(STDIN_FILENO);
++		close(STDOUT_FILENO);
++		close(STDERR_FILENO);
++		if (open("/dev/null", O_RDONLY) == -1) {
++			flog(LOG_ERR, "unable to redirect stdin to /dev/null");
++			exit(-1);
++		}
++		if (open("/dev/null", O_WRONLY) == -1) {
++			flog(LOG_ERR, "unable to redirect stdout to /dev/null");
++			exit(-1);
++		}
++		if (open("/dev/null", O_RDWR) == -1) {
++			flog(LOG_ERR, "unable to redirect stderr to /dev/null");
++			exit(-1);
+ 		}
+ 	} else {
+ 		/* Parent.  Make sure the pid file is written before exiting. */
+@@ -591,11 +587,7 @@ static pid_t do_daemonize(int log_method
+ {
+ 	pid_t pid = -1;
+ 
+-	if (L_STDERR_SYSLOG == log_method || L_STDERR == log_method) {
+-		pid = daemonp(1, 1, daemon_pid_file_ident);
+-	} else {
+-		pid = daemonp(0, 0, daemon_pid_file_ident);
+-	}
++	pid = daemonp(daemon_pid_file_ident);
+ 
+ 	if (-1 == pid) {
+ 		flog(LOG_ERR, "unable to daemonize: %s", strerror(errno));
diff --git a/debian/patches/series b/debian/patches/series
index 33ebe29..287f3b1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
 #  so cleaning up the debian/patches/ directory
 #
 kfreebsd.patch
+always_close_std_file_descriptors_when_daemonizing.patch
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

Bug#865795: radvd blocks when started over ssh

[Daniel Reichelt]

> ssh returns immediately as expected when I run one of these:

Of course, when I tested the redirection to /dev/null happened on the
router, I forgot to type the quotes:

ssh router "radvd -u radvd -p /var/run/radvd/radvd.pid >/dev/null"
ssh router "radvd -u radvd -p /var/run/radvd/radvd.pid -d3"




signature.asc
Description: OpenPGP digital signature

Bug#865795: radvd blocks when started over ssh

[Daniel Reichelt]

Package: radvd
Version: 1:2.15-2
Severity: normal

Hi Geert,

radvd shows some strange behavior when it's started over ssh: even in
daemon-mode, ssh would block indefinitely when you execute something
that would be executed by the init script as well:

ssh router "radvd -u radvd -p /var/run/radvd/radvd.pid"



ssh returns immediately as expected when I run one of these:

ssh router radvd -u radvd -p /var/run/radvd/radvd.pid >/dev/null
ssh router radvd -u radvd -p /var/run/radvd/radvd.pid -d3



git-bisect'ing revealed the culprit as 5294e6f, see [1].

I've also opened an upstream bug report at [2].

Cheers
Daniel



[1] 
https://github.com/reubenhwk/radvd/commit/5294e6fc0cc033a8dde64d51eefdc4c1f80e4244
[2] https://github.com/reubenhwk/radvd/issues/71


-- System Information:
Debian Release: 9.0
  APT prefers proposed-updates
  APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 'testing'), 
(98, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages radvd depends on:
ii  adduser   3.115
ii  libc6 2.24-11+deb9u1
ii  lsb-base  9.20161125

radvd recommends no packages.

radvd suggests no packages.

-- no debconf information


$ dpkg -l | grep sysvinit
ii  live-config-sysvinit  5.20170112
ii  sysvinit-core 2.88dsf-59
ii  sysvinit-utils2.88dsf-59

Bug#864386: live-build: Keyboard shortcut for "Advanced options" missing in some syslinux-based menus

[Daniel Reichelt]

Package: live-build
Version: 1:20170213
Severity: minor
Tags: patch


Hi,

the attached patch streamlines the missing keyboard shortcut "A" for the
"Advanced options" entry in the syslinux-based boot menu configs.


Thanks

Daniel
diff --git a/share/bootloaders/extlinux/menu.cfg b/share/bootloaders/extlinux/menu.cfg
index d2daa80..9368260 100644
--- a/share/bootloaders/extlinux/menu.cfg
+++ b/share/bootloaders/extlinux/menu.cfg
@@ -6,7 +6,7 @@ include stdmenu.cfg
 include live.cfg
 include install.cfg
 menu begin advanced
-	menu title Advanced options
+	menu title ^Advanced options
 	include stdmenu.cfg
 	label mainmenu
 		menu label ^Back..
diff --git a/share/bootloaders/isolinux/menu.cfg b/share/bootloaders/isolinux/menu.cfg
index d2daa80..9368260 100644
--- a/share/bootloaders/isolinux/menu.cfg
+++ b/share/bootloaders/isolinux/menu.cfg
@@ -6,7 +6,7 @@ include stdmenu.cfg
 include live.cfg
 include install.cfg
 menu begin advanced
-	menu title Advanced options
+	menu title ^Advanced options
 	include stdmenu.cfg
 	label mainmenu
 		menu label ^Back..
diff --git a/share/bootloaders/pxelinux/menu.cfg b/share/bootloaders/pxelinux/menu.cfg
index d2daa80..9368260 100644
--- a/share/bootloaders/pxelinux/menu.cfg
+++ b/share/bootloaders/pxelinux/menu.cfg
@@ -6,7 +6,7 @@ include stdmenu.cfg
 include live.cfg
 include install.cfg
 menu begin advanced
-	menu title Advanced options
+	menu title ^Advanced options
 	include stdmenu.cfg
 	label mainmenu
 		menu label ^Back..

Bug#864385: live-boot: fix file duplication in initramfs-tools hook

[Daniel Reichelt]

Package: live-boot
Version: 1:20170112
Severity: minor
Tags: patch

Hi,

live-boot's initramfs-hook contains these lines ([1], [2]), which put
live-boot's /lib/live/boot/ twice into the initramfs image: the latter one at
/lib/live/boot/ and the former one - wrongly - also at /bin/boot/).


The duplication was introduced by [3] and is fixed by this patch to read

8<-
cp -a /bin/live-boot "${DESTDIR}/bin"
>8-


There were no problems in multiple testing scenarios (including booting from
the ISO and via PXE).


Thanks,

Daniel




[1]
https://anonscm.debian.org/cgit/debian-live/live-boot.git/tree/backend/initramfs-tools/live.hook#n31

[2]
https://anonscm.debian.org/cgit/debian-live/live-boot.git/tree/backend/initramfs-tools/live.hook#n34

[3]
https://anonscm.debian.org/cgit/debian-live/live-boot.git/commit/backend/initramfs-tools/live.hook?id=0aa07bd386f516176364e710e8b9132036c72986
diff --git a/backend/initramfs-tools/live.hook b/backend/initramfs-tools/live.hook
index 54a566f..889809a 100755
--- a/backend/initramfs-tools/live.hook
+++ b/backend/initramfs-tools/live.hook
@@ -28,7 +28,7 @@ fi
 [ "${QUIET}" ] || echo -n " core"
 
 mkdir -p "${DESTDIR}/bin"
-cp -a /bin/live-boot /lib/live/boot "${DESTDIR}/bin"
+cp -a /bin/live-boot "${DESTDIR}/bin"
 
 mkdir -p "${DESTDIR}/lib/live"
 cp -a /lib/live/boot "${DESTDIR}/lib/live"

Bug#684691: pulseaudio creates .config/pulse in a root directory

[Daniel Reichelt]

> If you want your comments on a bug to be sent to the maintainer and
> recorded in the bug's web-visible record, please send your message to the
> bug address (in this case 684691@) and not just the special control@
> address. In particular, when reopening a bug please send the justification
> for reopening to the bug address.
> 
> Quoting all relevant text below for reference.

oops...thanks!



> It looks as though the instances of the root cause of this bug bug involving
> alsactl invocations have been solved, but those involving aumix invocations
> have not. Does that seem a correct summary to you?

ACK


Daniel



signature.asc
Description: OpenPGP digital signature

Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

[Daniel Reichelt]

PS: a very crude workaround for this:

# cat /etc/default/NetworkManager
if [ -z "$(ip -4 addr list dev eth0)" ] && [ -n "$(ip -6 addr list dev
eth0)" ]
then
ip link set down dev eth0
ip addr flush dev eth0
fi



signature.asc
Description: OpenPGP digital signature

Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

[Daniel Reichelt]

Hi folks,

here are some more insights into this mystery:

My "victim" box:

- kvm-guest: jessie, task-xfce-desktop, sysvinit instead of systemd
- running with -net nic,model=rtl8139 -net tap
- connected to br0 of the kvm host which also contains the host's eth0
- the guest's /etc/network/interfaces or NM-config were left unchanged
after jessie-netinstall


In the guest, I did:

# touch /etc/.legacy-bootordering

and tweaked /etc/init.d/rc to display `ip addr list` and a debug login
shell after the execution of every single init script. Now, after
/etc/rcS.d/S03udev got executed, udev modprobe'd 8139too/8139cp for the
virtual Realtec nic.

What *really* surprised me: The output of `ip addr list` after S03udev
finished showed different link states across different boot processes.
AFAICT the Realtek's link state after modprobing is determined by fair
dice roll. I couldn't infer any relation between the link state after
modprobing and

- a freshly invoked kvm guest
- shutdown -r from within the guest
- echo b >/proc/sysrq-trigger from within the guest
- "system_reset" sent to the qemu_system-x86_64 process's control socket

- the link state prior to any of these four variants to reboot



As a consequence I could observe:

- When the link state was DOWN after modprobing, of course no v6 SLAAC
happened and NM configured eth0 just fine with both v4 and v6.

- When the link state was UP after modprobing, SLAAC happened which
triggered NM's "undesired behavior" to "connection-assume" eth0.
(This case then easily becomes a race-condition with concurrent
execution of the init scripts.)



Judging whether this is an error in this specific driver or in the Linux
networking layer goes way over my head. At the very least I can say that
I'm completely baffled by this observation.



Cheers

Daniel



signature.asc
Description: OpenPGP digital signature

Bug#860305: staticsite: Dependency on python3-tz missing

[Daniel Reichelt]

Package: staticsite
Version: 0.4-1
Severity: normal

Hi Enrico,

on my system, ssite failed complaining it couldn't find pytz.
apt-get install python3-tz fixed it.

Cheers

Daniel


-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'testing-proposed-updates'), (99, 'testing'), (98, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages staticsite depends on:
ii  python3-jinja2  2.7.3-1
ii  python3-livereload  2.2.2-1
ii  python3-markdown2.5.1-2
ii  python3-toml0.9.1-1
ii  python3-unidecode   0.04.16-1
pn  python3:any 

Versions of packages staticsite recommends:
ii  libjs-bootstrap  3.2.0+dfsg-1
ii  libjs-jquery 1.7.2+dfsg-3.2

staticsite suggests no packages.

-- no debconf information

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

> 8<-
> pre-up ethtool --offload $IFACE tx off
> >8-



Copy/paste error. The workaround should have read:

8<-
pre-up ethtool --offload $IFACE tx on
>8-




signature.asc
Description: OpenPGP digital signature

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

found 851825 ethtool/1:3.16-1
found 851825 ethtool/1:3.16-1


jessie is also affected



signature.asc
Description: OpenPGP digital signature

Bug#851825: ethtool: ifdown/ifup sequence fails if offload_tx off is set in iface stanza

[Daniel Reichelt]

Package: ethtool
Version: 1:4.8-1
Severity: normal

Hi,

in network/interfaces I have set the option "offload_tx off" for eth0. This
causes `ifdown eth0 ; ifup eth0` to fail when offloading already
was set to off.

The culprit is ethtool, which inconsistently exits 0 or 1 when offloading is
enabled/disabled repeatedly:


8<-
# offloading initially off
# ethtool --offload eth0 tx on ; echo $?
Actual changes:
tx-checksum-ipv6: on
tcp-segmentation-offload: on
tx-tcp6-segmentation: on
0
# ethtool --offload eth0 tx on ; echo $?
0
# ethtool --offload eth0 tx on ; echo $?
0

# ^--- repeated enabling returns no error


# ethtool --offload eth0 tx off ; echo $?
Actual changes:
tx-checksum-ipv6: off
tcp-segmentation-offload: off
tx-tcp6-segmentation: off [requested on]
0

# ^--- initial disabling is ok

# ethtool --offload eth0 tx off ; echo $?
Could not change any device features
1
# ethtool --offload eth0 tx off ; echo $?
Could not change any device features
1

# ^--- repeated disabling returns 1
>8-





For now I'm using this workaround in the eth0 stanza:

8<-
pre-up ethtool --offload $IFACE tx off
>8-



Cheers

Daniel


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ethtool depends on:
ii  libc6  2.24-9

ethtool recommends no packages.

ethtool suggests no packages.

-- Configuration Files:
/etc/network/if-up.d/ethtool changed [not included]

-- no debconf information

Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Daniel Reichelt]

> Incidentally, if anyone *has* a link to the old deb package
> for 1:20151215 so I could verify this, that'd help.

Jason,

have a look at http://snapshot.debian.org/



Cheers
Daniel





signature.asc
Description: OpenPGP digital signature

Bug#784621: cgit: file not shown if no lexer found

[Daniel Reichelt]

Package: cgit
Version: 1.0+git2.8.3-3~bpo8+1
Followup-For: Bug #784621

Hi,

I just stumbled over this issue as well. The attached patch fixes this.


Cheers

Daniel


-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'proposed-updates'), (990, 
'stable'), (500, 'testing-proposed-updates'), (99, 'testing'), (98, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages cgit depends on:
ii  libc62.19-18+deb8u6
ii  liblua5.1-0  5.1.5-7.1
ii  libssl1.0.0  1.0.1t-1+deb8u5
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages cgit recommends:
ii  apache2 [httpd]  2.4.10-10+deb8u7

Versions of packages cgit suggests:
ii  highlight 3.18-3
ii  python3   3.4.2-2
pn  python3-docutils  
ii  python3-markdown  2.5.1-2
ii  python3-pygments  2.0.1+dfsg-1.1+deb8u1

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/cgit/filters/syntax-highlighting.py (from cgit 
package)
--- /usr/lib/cgit/filters/syntax-highlighting.py.orig	2016-11-17 23:42:23.992555420 +0100
+++ /usr/lib/cgit/filters/syntax-highlighting.py	2016-11-17 23:42:20.000547312 +0100
@@ -41,7 +41,10 @@
 except ClassNotFound:
 	# check if there is any shebang
 	if data[0:2] == '#!':
-		lexer = guess_lexer(data)
+		try:
+			lexer = guess_lexer(data)
+		except ClassNotFound:
+			lexer = TextLexer()
 	else:
 		lexer = TextLexer()
 except TypeError:

Bug#844321: unison: Please update to latest upstream version

[Daniel Reichelt]

Source: unison
Version: 2.48.3-1
Severity: wishlist

Please update the packaging to the latest upstream version at [1].

Changelog: [2]

Thanks!
Daniel


[1] https://github.com/bcpierce00/unison
[2] 
https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#news

Bug#844318: makeself: Please update packaging to current upstream git

[Daniel Reichelt]

Package: makeself
Version: 2.2.0-1
Severity: wishlist

Please update the package to the latest upstream git version.

It contains several bug fixes and enhancements. [1], [2]

Most notably:

- fixed handling of spaces for startup_script and parameters [3], [4]
- encrypting the archive with gpg or openssl [5]
- use different compressors [6], [7]



Thanks!

Daniel



[1] https://github.com/megastep/makeself/pulls?q=is:pr+is:closed
[2] https://github.com/megastep/makeself/issues?q=is:issue+is:closed
[3] https://github.com/megastep/makeself/pull/39
[4] https://github.com/megastep/makeself/pull/42
[5] https://github.com/megastep/makeself/pull/43
[6] https://github.com/megastep/makeself/pull/45
[7] https://github.com/megastep/makeself/pull/67




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

Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

makeself depends on no packages.

makeself recommends no packages.

Versions of packages makeself suggests:
ii  bzip2  1.0.6-7+b3

-- no debconf information

Bug#842645: grub-common: GRUB_DISABLE_LINUX_UUID=true ignored in 10_linux and 20_linux_xen

[Daniel Reichelt]

Package: grub-common
Version: 2.02~beta3-1
Severity: important
Tags: patch

Hi,

in Stretch setting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub is
no longer respected during creation of linux menu entries.

The culprits are the checks in 10_linux:66-68 and 20_linux_xen:54:56
(identical in both scripts).

This was working fine until the new AND'ed check `uses_abstraction ...`
was added. This additional check actually requires a pair of hyphens to
have the desired effect with respect to operator precedence:

--8<-
if [ "x${GRUB_DEVICE_UUID}" = "x" ] || [ "x${GRUB_DISABLE_LINUX_UUID}" = 
"xtrue" ] \
|| ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" \
|| (test -e "${GRUB_DEVICE}" && uses_abstraction "${GRUB_DEVICE}" lvm); then
-->8-



Cheers

Daniel



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages grub-common depends on:
ii  gettext-base0.19.8.1-1
ii  libc6   2.24-5
ii  libdevmapper1.02.1  2:1.02.133-1
ii  libfreetype62.6.3-3+b1
ii  libfuse22.9.7-1
ii  liblzma55.2.2-1.2

Versions of packages grub-common recommends:
pn  os-prober  

Versions of packages grub-common suggests:
ii  console-setup  1.152
pn  desktop-base   
pn  grub-emu   
pn  multiboot-doc  
pn  xorriso

-- no debconf information

Bug#842609: xen-create-image: Inconsistent handling of --nopygrub parameter

[Daniel Reichelt]

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

Hi Axel,

when --nopygrub is passed to xen-create-image, the hooks called during
installation act as if --pygrub were passed.

This setting gets exported to the hooks' environments as pygrub=0|1. The hooks
however do a check like

`if [ ${pygrub} ]; then`

which in sh/bash always yields true (non-empty string). This only works if
$pygrub were set to literal "true"|"false". The attached patch changes these
checks to

`if [ "${pygrub}" = "1" ]; then`


The patch applies cleanly to both jessie an stretch verions of the xen-tools
package.



Cheers

Daniel




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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages xen-tools depends on:
ii  debootstrap   1.0.67
ii  libconfig-inifiles-perl   2.83-3
ii  libdata-validate-domain-perl  0.10-1
ii  libdata-validate-ip-perl  0.24-1
ii  libdata-validate-uri-perl 0.06-1
ii  libfile-slurp-perl.19-4
ii  libfile-which-perl1.09-1
ii  libterm-ui-perl   0.42-1
ii  libtext-template-perl 1.46-1
ii  openssh-client1:6.7p1-5+deb8u3
ii  perl  5.20.2-3+deb8u6

Versions of packages xen-tools recommends:
ii  libexpect-perl   1.21-1
ii  rinse3.0.9
ii  xen-hypervisor-4.4-amd64 [xen-hypervisor-amd64]  4.4.1-9+deb8u7
ii  xen-utils-4.4 [xen-utils]4.4.1-9+deb8u7

Versions of packages xen-tools suggests:
ii  btrfs-tools3.17-1.1
pn  cfengine2  
ii  reiserfsprogs  1:3.6.24-1
ii  xfsprogs   3.2.1

-- no debconf information
--- a/hooks/common/80-install-modules-deb	2016-10-30 19:52:53.662077321 +0100
+++ b/hooks/common/80-install-modules-deb	2016-10-30 19:54:14.378190647 +0100
@@ -31,7 +31,7 @@
 #
 logMessage Script $0 starting
 
-if [ ${pygrub} ]; then
+if [ "${pygrub}" = "1" ]; then
 logMessage "pygrub set, skipping module install"
 else
 #
--- a/hooks/common/82-install-grub-legacy	2016-10-30 19:53:00.534086963 +0100
+++ b/hooks/common/82-install-grub-legacy	2016-10-30 19:54:14.386190659 +0100
@@ -26,7 +26,7 @@
 #
 logMessage Script $0 starting
 
-if [ ${pygrub} ]; then
+if [ "${pygrub}" = "1" ]; then
 
 #
 #  Install the grub 0.9x package ("grub-legacy" on Debian, "grub" on Ubuntu)
--- a/hooks/debian/80-install-kernel	2016-10-30 19:53:13.878105687 +0100
+++ b/hooks/debian/80-install-kernel	2016-10-30 19:54:14.390190665 +0100
@@ -21,7 +21,7 @@
 . ./hooks/common.sh
 fi
 
-if [ "${pygrub}" ]; then
+if [ "${pygrub}" = "1" ]; then
 #
 # Log our start
 #
--- a/hooks/edgy/80-install-kernel	2016-10-30 19:53:28.134125699 +0100
+++ b/hooks/edgy/80-install-kernel	2016-10-30 19:54:14.394190670 +0100
@@ -27,7 +27,7 @@
 
 logMessage Script $0 starting
 
-if [ "${pygrub}" ]; then
+if [ "${pygrub}" = "1" ]; then
 
 #
 # Attempt to install a xen kernel, if that fails, then install a normal one
--- a/hooks/intrepid/80-install-kernel	2016-10-30 19:53:37.250138498 +0100
+++ b/hooks/intrepid/80-install-kernel	2016-10-30 19:54:14.398190675 +0100
@@ -27,7 +27,7 @@
 
 logMessage Script $0 starting
 
-if [ "${pygrub}" ]; then
+if [ "${pygrub}" = "1" ]; then
 
 #
 # Attempt to install a xen kernel, if that fails, then install a normal one
--- a/hooks/karmic/80-install-kernel	2016-10-30 19:53:49.302155421 +0100
+++ b/hooks/karmic/80-install-kernel	2016-10-30 19:54:14.402190681 +0100
@@ -26,7 +26,7 @@
 
 logMessage Script $0 starting
 
-if [ "${pygrub}" ]; then
+if [ "${pygrub}" = "1" ]; then
 
 #
 # The type of kernel that we will be installing

Bug#841360: libmotif-common stuck at 2.3.4-10 in sid (src:motif is 2.3.4-11)

[Daniel Reichelt]

Package: libmotif-common
Version: 2.3.4-10
Severity: normal

Hi,

on a freshly installed sid (just now) I noticed the package ddd is not
installable due to a dependency error:

ddd --> libxm4 (which currently resolves to version 2.3.4-11 in sid)
libxm4 --> libmotif-common (resolving to 2.3.4-*10*)

[1] confirms this, however the link to the .dsc file already points to
2.3.4-11.

I was able to dpkg-buildpackage src:motif on said sid host and manually
install the yielded libmotif-common_2.3.4-11_all.deb which in turn
enabled the installation of ddd.

So I assume this is just an upload-related issue...


Thanks

Daniel




[1] https://packages.debian.org/sid/libmotif-common




-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.7.0-1-686-pae (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libmotif-common depends on:
ii  x11-common  1:7.7+16

libmotif-common recommends no packages.

libmotif-common suggests no packages.

-- no debconf information

Bug#838110: live-tools: exclude initrd backup files

[Daniel Reichelt]

Hi Ronny,

just a minor thing but I think you should anchor your grep to the end of
the filename:
grep -v "old-dkms$"


Cheers
Daniel


On 09/17/2016 02:13 PM, Ronny Standtke wrote:
> Package: live-tools
> Version: 1:20151214+nmu1
> Severity: important
> Tags: patch
> 
> On my Debian Live system update-initramfs fails with the following error 
> message:
> 
> cp: cannot stat '/boot/vmlinuz-.old-dkms': No such file or 
> directory
> 
> Please find attached a patch that fixes this issue.
> 
> Cheers
> 
> Ronny
> 

Bug#827370: closed by Ondřej Surý <ond...@debian.org> (Bug#827370: fixed in php5 5.6.22+dfsg-2)

[Daniel Reichelt]

Hi,

I saw this got fixed (only?) in 5.6.22+dfsg-2.

When will this fix hit jessie/security?

Thanks
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#827370: [php-maint] Bug#827370: php5-common: mail clutter from sessionclean cronjob

[Daniel Reichelt]

(forwarding this to the bug list for referece)

On 06/15/2016 04:23 PM, Ondřej Surý wrote:
> Hi Daniel,
> 
> could you please apply this patch:
> 
> $ git diff
> diff --git a/debian/sessionclean b/debian/sessionclean
> index 237b033..816528a 100644
> --- a/debian/sessionclean
> +++ b/debian/sessionclean
> @@ -22,7 +22,7 @@ while IFS=: read -r conf_dir proc_name; do
>  done
>  # first find all open session files and touch them (hope it's not
>  massive amount of files)
>  for pid in $(pidof $proc_names); do
> -find "/proc/$pid/fd" -ignore_readdir_race -lname
> "$save_path/sess_\*" -exec touch -c {} \;
> +if [ -d "/proc/$pid/fd" ]; then find "/proc/$pid/fd"
> -ignore_readdir_race -lname "$save_path/sess_\*" -exec touch -c {} \;;
> fi
>  done
>  } ) | sort -rn -t: -k2,2 | sort -u -t: -k 1,1 | while IFS=: read -r
>  save_path gc_maxlifetime; do
>  # find all files older then maxlifetime and delete them
> 
> This won't eliminate all the race conditions (as the PID might shutdown
> between test -d and find run), but it should eliminate most of them.
> 
> Most probably you haven't seen this messages as the sessionclean script
> was not touching any of those files at all, see #799155. So while it's
> not regression per se, because the sessionclean script was broken
> before.
> 
> Cheers,
> 

Bug#827370: [php-maint] Bug#827370: php5-common: mail clutter from sessionclean cronjob

[Daniel Reichelt]

> could you please apply this patch:

Thanks Ondrej. I'd already tried s.th. similar in the meantime, and, as
you presumed as well, this already ran into another race, causing mail
clutter.


So, how about a different approach and simply filter those messages:

I'd deem just appending "2>/dev/null" to that find command too crude, as
it would possibly hide other, "real" errors. So I diverted find's
STDERR, grep'ping -v just those "No such file or directory" messages and
(re-diverting to STDERR) let the rest pass.

Since the process substition I used is a bashism, the attached patch
also changes the shebang to bash.


Cheers
Daniel

--- /usr/lib/php5/sessionclean.orig
+++ /usr/lib/php5/sessionclean
@@ -1,4 +1,4 @@
-#!/bin/sh -e
+#!/bin/bash -e
 
 SAPIS="apache2:apache2\napache2filter:apache2\ncgi:php5\nfpm:php5-fpm\n"
 
@@ -22,7 +22,8 @@
 done
 # first find all open session files and touch them (hope it's not massive amount of files)
 for pid in $(pidof $proc_names); do
-find "/proc/$pid/fd" -ignore_readdir_race -lname "$save_path/sess_\*" -exec touch -c {} \;
+find "/proc/$pid/fd" -ignore_readdir_race -lname "$save_path/sess_\*" -exec touch -c {} \; \
+	2> >(grep -v "^find: \`/proc/[0-9]\+/fd': No such file or directory$" >&2)
 done
 } ) | sort -rn -t: -k2,2 | sort -u -t: -k 1,1 | while IFS=: read -r save_path gc_maxlifetime; do
 # find all files older then maxlifetime and delete them

Bug#827370: php5-common: mail clutter from sessionclean cronjob

[Daniel Reichelt]

Package: php5-common
Version: 5.6.22+dfsg-0+deb8u1
Severity: normal

Hi,

since the most recent security upgrade, I keep receiving cronjob mails saying

8<-
find: `/proc/14918/fd': No such file or directory
8<-

The count of these entries variies of course, and whether or not that
race-conditions triggers depends on the server load. At least during daytime
it's pretty constant - and annoying...



Thanks
Daniel


8<-

-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
cli
cgi
apache2

 PHP 5 Extensions (php5query -M -v): 
mysqlnd (Enabled for cli by maintainer script)
mysqlnd (Enabled for cgi by maintainer script)
mysqlnd (Enabled for apache2 by maintainer script)
apcu (Enabled for cli by maintainer script)
apcu (Enabled for cgi by maintainer script)
apcu (Enabled for apache2 by maintainer script)
mysql (Enabled for cli by maintainer script)
mysql (Enabled for cgi by maintainer script)
mysql (Enabled for apache2 by maintainer script)
pdo (Enabled for cli by maintainer script)
pdo (Enabled for cgi by maintainer script)
pdo (Enabled for apache2 by maintainer script)
pspell (Enabled for cli by maintainer script)
pspell (Enabled for cgi by maintainer script)
pspell (Enabled for apache2 by maintainer script)
json (Enabled for cli by maintainer script)
json (Enabled for cgi by maintainer script)
json (Enabled for apache2 by maintainer script)
mysqli (Enabled for cli by maintainer script)
mysqli (Enabled for cgi by maintainer script)
mysqli (Enabled for apache2 by maintainer script)
gd (Enabled for cli by maintainer script)
gd (Enabled for cgi by maintainer script)
gd (Enabled for apache2 by maintainer script)
opcache (Enabled for cli by maintainer script)
opcache (Enabled for cgi by maintainer script)
opcache (Enabled for apache2 by maintainer script)
curl (Enabled for cli by maintainer script)
curl (Enabled for cgi by maintainer script)
curl (Enabled for apache2 by maintainer script)
mcrypt (Enabled for cli by maintainer script)
mcrypt (Enabled for cgi by maintainer script)
mcrypt (Enabled for apache2 by maintainer script)
pdo_mysql (Enabled for cli by maintainer script)
pdo_mysql (Enabled for cgi by maintainer script)
pdo_mysql (Enabled for apache2 by maintainer script)
intl (Enabled for cli by maintainer script)
intl (Enabled for cgi by maintainer script)
intl (Enabled for apache2 by maintainer script)

 Configuration files: 
 /etc/php5/mods-available/pdo.ini 
extension=pdo.so

 /etc/php5/mods-available/opcache.ini 
zend_extension=opcache.so


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages php5-common depends on:
ii  libc6   2.19-18+deb8u4
ii  lsof4.86+dfsg-1
ii  psmisc  22.21-2
ii  sed 4.2.2-4+b1
ii  ucf 3.0030

php5-common recommends no packages.

Versions of packages php5-common suggests:
ii  php5-apcu [php5-user-cache]  4.0.7-1

Versions of packages php5-cli depends on:
ii  libbz2-1.01.0.6-7+b3
ii  libc6 2.19-18+deb8u4
ii  libcomerr21.42.12-1.1
ii  libdb5.3  5.3.28-9
ii  libedit2  3.1-20140620-2
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2
ii  libk5crypto3  1.12.1+dfsg-19+deb8u2
ii  libkrb5-3 1.12.1+dfsg-19+deb8u2
ii  libmagic1 1:5.22+15-2+deb8u1
ii  libonig2  5.9.5-3.2
ii  libpcre3  2:8.35-3.3+deb8u4
ii  libqdbm14 1.8.78-5+b1
ii  libssl1.0.0   1.0.1t-1+deb8u2
ii  libxml2   2.9.1+dfsg1-5+deb8u2
ii  mime-support  3.58
ii  php5-json 1.3.6-1
ii  tzdata2016d-0+deb8u1
ii  ucf   3.0030
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages php5-cli recommends:
pn  php5-readline  

Versions of packages php5-cli suggests:
ii  php-pear  5.6.22+dfsg-0+deb8u1

Versions of packages libapache2-mod-php5 depends on:
ii  apache2 2.4.10-10+deb8u4
ii  apache2-bin [apache2-api-20120211]  2.4.10-10+deb8u4
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u4
ii  libcomerr2  1.42.12-1.1
ii  libdb5.35.3.28-9
ii  libgssapi-krb5-21.12.1+dfsg-19+deb8u2
ii  libk5crypto31.12.1+dfsg-19+deb8u2
ii  libkrb5-3   1.12.1+dfsg-19+deb8u2
ii  libmagic1   1:5.22+15-2+deb8u1
ii  libonig25.9.5-3.2
ii  libpcre32:8.35-3.3+deb8u4
ii  libqdbm14   1.8.78-5+b1
ii  libssl1.0.0 1.0.1t-1+deb8u2
ii  libstdc++6  

Bug#824686: ifupdown: dad-attempts 0 should cause nodad confflag to be passed to ip -6 addr add

[Daniel Reichelt]

Package: ifupdown
Version: 0.8.11
Severity: normal
Tags: ipv6

Hi,

I'm trying to configure a tap-device using a inet6 static stanza, but it ends
up unusable:

/etc/network/interfaces:
---8<-
iface tap1 inet6 static
dad-attempts0
privext 2
pre-up  tunctl -t $IFACE; ip addr flush dev $IFACE
address fd00:1::/128
post-down   tunctl -d $IFACE
-->8--



Turns out, after an `ifup tap1`, the v6 address shows up as tentative, even
though dad-attempts is set to 0:

---8<-
# ifup --verbose tap1

Configuring interface tap1=tap1 (inet6)
tunctl -t $IFACE; ip addr flush dev $IFACE
Set 'tap1' persistent and owned by uid 0
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/uml-utilities
/sbin/modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.
/sbin/sysctl -q -e -w net.ipv6.conf.tap1.use_tempaddr=2

/sbin/sysctl -q -e -w net.ipv6.conf.tap1.autoconf=0

/bin/ip link set dev tap1  up
/bin/ip -6 addr add fd00:1::/128  dev tap1

/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/addresses
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/nslcd
Sending network state change signal to nslcd...done.
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/proxy-setup
run-parts: executing /etc/network/if-up.d/uml-utilities
run-parts: executing /etc/network/if-up.d/upstart

# ip addr list dev tap1
15: tap1:  mtu 1500 qdisc pfifo_fast state
DOWN group default qlen 1000
link/ether 3a:de:89:d6:47:15 brd ff:ff:ff:ff:ff:ff
inet6 fd00:1::/128 scope global tentative  <
   valid_lft forever preferred_lft forever

# ping6 -c1 fd00:1::
PING fd00:1::(fd00:1::) 56 data bytes
>From fd00:4818::216:3eff:fe00:36 icmp_seq=1 Destination unreachable: Address
unreachable

--- fd00:1:: ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
-->8--




Doing the same thing in a "manual" stanza and calling `ip -6 addr add` with the
nodad confflag set, another tap device ends up in a usable state:

/etc/network/interfaces:
---8<-
iface tap3 inet6 manual
dad-attempts0
privext 2
pre-up  tunctl -t $IFACE; ip addr flush dev $IFACE
post-up ip -6 addr add dev $IFACE fd00:3::/128 nodad
post-down   tunctl -d $IFACE
-->8--



---8<-
# ifup --verbose tap3

Configuring interface tap3=tap3 (inet6)
tunctl -t $IFACE; ip addr flush dev $IFACE
Set 'tap3' persistent and owned by uid 0
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/uml-utilities


/bin/ip link set dev tap3 up 2>/dev/null || true
ip -6 addr add dev $IFACE fd00:3::/128 nodad
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/addresses
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/nslcd
Sending network state change signal to nslcd...done.
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/proxy-setup
run-parts: executing /etc/network/if-up.d/uml-utilities
run-parts: executing /etc/network/if-up.d/upstart

# ip addr list dev tap3
16: tap3:  mtu 1500 qdisc pfifo_fast state
DOWN group default qlen 1000
link/ether ea:90:c4:b2:12:a4 brd ff:ff:ff:ff:ff:ff
inet6 fd00:3::/128 scope global nodad 
   valid_lft forever preferred_lft forever

/# ping6 -c1 fd00:3::
PING fd00:3::(fd00:3::) 56 data bytes
64 bytes from fd00:3::: icmp_seq=1 ttl=64 time=0.028 ms

--- fd00:3:: ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.028/0.028/0.028/0.000 ms
-->8--



Thanks

Dnaiel




-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages ifupdown depends on:
ii  adduser  3.114
ii  init-system-helpers  

Bug#815564: borgbackup: activate unittests during build

[Daniel Reichelt]

On 02/23/2016 08:15 PM, Danny Edel wrote:

> Can you reproduce the build failure in a freshly created pbuilder?
> 
> 
> 
> I created mine with:
> 
> DIST=jessie-backports git-pbuilder create
> 
> and I checked my build with:
> 
> git add -u && \
> gbp buildpackage --git-pbuilder --git-dist=jessie-backports \
>   --git-export=INDEX --git-ignore-new
> 
> 
> Its quite possible there is something™ different with the way you set up
> your chroot, but debomatic and git-pbuilder seem to agree with me so far.

After it didn't work with gbp on my jessie64 VM either, I tested gbp on
stretch64 and it worked?!


> This should say python3.4 -m **pytest**, not unittest.  That's what the
> 'export PYBUILD_TEST_PYTEST=1' in d/rules is supposed to trigger.

Then I noticed this line missing in my d/rules. Turns out I messed up
the git fetch on the jessie machine. Shame on me!


→ Green lights from my end, git/master-testing-enabled builds went
through just fine.


Sorry for the confusion and thanks for your patience and your work on
this :)


Daniel

Bug#815564: borgbackup: activate unittests during build

[Daniel Reichelt]

Hi everyone,


On 02/22/2016 03:45 PM, Danny Edel wrote:
> I have prepared a patch, and verified it against a jessie-backports
> cowbuilder, but I'm not merging it into master without checking in
> with you this time : )

Interesting. On a current jessie (plain + git/master-testsuite-enabled's
build-deps from bpo) I get an error about python3.4's unittest not
recognizing arguments from PYBUILD_TEST_ARGS - see attached build.log.

Which version of libpython3.4-stdlib ends up being used within your
chroot? (mine is 3.4.2-1)



> My motivation for activating the testsuite is to ensure that the
> libraries in Debian are compatible with the ones upstream expects --
> this will get more relevant for stable-backports, once sid is 1-2 years
> different from stable.
> In general, I'd rather get errors at build time than from users after
> they upgrade their machine, and running the upstream test suite seems
> like a good start into this direction.

Sure, big bold +1!



Daniel
dpkg-buildpackage: source package borgbackup
dpkg-buildpackage: source version 1.0.0~rc1-2
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Gianfranco Costamagna 
 dpkg-source --before-build borg
dpkg-buildpackage: host architecture amd64
dpkg-source: info: applying privacy/0001-Remove-codecov.io-and-travis-ci.org-badges.patch
dpkg-source: info: applying privacy/0002-README.rst-Replace-img-src-with-text-link.patch
dpkg-source: info: applying 0003-disable-llfuse-tests-on-Debian.patch
 fakeroot debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python3.4 setup.py clean 
your setuptools is too old (<12)
setuptools_scm functionality is degraded
running clean
removing '/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build' (and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.4' does not exist -- can't clean it
   dh_clean -O--buildsystem=pybuild
 debian/rules build
dh build --with python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:170: python3.4 setup.py config 
your setuptools is too old (<12)
setuptools_scm functionality is degraded
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:170: /usr/bin/python3 setup.py build 
your setuptools is too old (<12)
setuptools_scm functionality is degraded
running build
running build_py
creating /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/helpers.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/fuse.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/hash_sizes.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/upgrader.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/remote.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/lrucache.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/key.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/xattr.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/platform.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/archive.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/_version.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/shellpattern.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/__main__.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/archiver.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/locking.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/logger.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/__init__.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/cache.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/repository.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
creating /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/helpers.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/compress.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/upgrader.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/lrucache.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/key.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/xattr.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/platform.py -> 

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Daniel Reichelt]

version: 1.0.0~rc1-2
thanks


Hi Danny,


On 02/19/2016 09:42 AM, Danny Edel wrote:
> 1.0.0~rc1 is in Debian unstable now, with the testsuite deactivated for
> now.  

BFS on jessie32/64 worked fine here, thx!



> Regarding coordination, I'm happy enough with the debian bugtracking
> service and the github tracker for upstream-relevant stuff, so unless
> there's a specific reason to implement (and maintain) another system,
> I'd prefer to stick with those.

I didn't even know about the PTS lists until Gianfranco mentioned them
here. Thanks for that, too :)



Cheers
Daniel

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Daniel Reichelt]

Thanks, Danny.

Hauler if you require manpower to test the packaging.

Thomas Waldmann gave his ok to use the upstream ML for coordination "if
they behave" ;-))

I think in the long run, borg-dev and borg-users lists on l.d.o would be
helpful.


Cheers

Daniel

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Daniel Reichelt]

I previously replied only to Gianfranco instead of to the bug address.
Here's the missing message I sent only to Gianfranco instead of to the
bug address, which lead up to message #15 above:


---8<-
On 02/08/2016 07:47 PM, Gianfranco Costamagna wrote:
> Actually the reason for not having a -2 in unstable, is because we
> can't run the testsuite on jessie.

Could you elaborate on this? With respect to a potential backport of -2
to jessie, sure. But I don't see the connection between unstable and
running tests on stable...
---8<-

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Daniel Reichelt]

On 02/08/2016 09:17 PM, Gianfranco Costamagna wrote:
> Hi, because I do no-change backports, and I want the version in unstable to 
> be "backportable" easily.
> 
> cheers,
> 
> Gianfranco


Shouldn't the focus in unstable lie on currentness instead of on
backportability?

AFAICS that's the whole point of having stable-backports: to *have* a
namespace, where additional changes to testing/unstable packages *can*
be made, so a packge plays nice within stable. Not to *avoid* them.

If a maintainer can't/won't do that extra backporting work (for whatever
reason) is another topic. But IMO that's no argument against unstable
uploads.

Just my $0.02...

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Daniel Reichelt]

Package: borgbackup
Version: 0.30.0-1~bpo8+1

Hi *,

trying to build git tag 0.30.0-2 on Jessie, I just ran into these issues:

- Option -k is only present in pytest of dh-python/stretch, so the build
  failed. Either the build-dep on it needs to be versioned (and dh-python needs
  to be backported as well) or the tests should be excluded via
@unittest.skip("some reason")
  like it's already done by upstream for some cases.

- fuse is missing in build-deps: the fusermount command is required during
  testing

- Two unittests are still failing. I couldn't figure out yet what's wrong here,
  see the attached logfile. (I adjusted debian/rules so pytest runs only the
  failing tests.)


Reportbug automatically added "severity: serious" after I classified this
report as FTBS (virtual). I removed that, since 0.30.0-2 is not in the archives
yet.


Cheers
Daniel




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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages borgbackup depends on:
ii  libacl12.2.52-2
ii  libc6  2.19-18+deb8u2
ii  liblz4-1   0.0~r122-2
ii  libssl1.0.01.0.1k-3+deb8u2
ii  python33.4.2-2
ii  python3-msgpack0.4.6-1~bpo8+1
ii  python3-pkg-resources  5.5.1-1

Versions of packages borgbackup recommends:
ii  python3-llfuse  0.40-2+b2

Versions of packages borgbackup suggests:
ii  borgbackup-doc  0.30.0-1~bpo8+1

-- no debconf information
$ dpkg-buildpackage -uc -us -b
dpkg-buildpackage: source package borgbackup
dpkg-buildpackage: source version 0.30.0-2
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Danny Edel 
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build borg
 fakeroot debian/rules clean
dh clean --with python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:184: python3.4 setup.py clean
your setuptools is too old (<12)
setuptools_scm functionality is degraded
running clean
removing '/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build' (and everything 
under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.4' does not exist -- can't clean it
   dh_clean -O--buildsystem=pybuild
 debian/rules build
dh build --with python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:184: python3.4 setup.py config
your setuptools is too old (<12)
setuptools_scm functionality is degraded
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python3 setup.py build
your setuptools is too old (<12)
setuptools_scm functionality is degraded
running build
running build_py
creating /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/helpers.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/fuse.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/hash_sizes.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/upgrader.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/remote.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/lrucache.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/key.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/xattr.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/platform.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/archive.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/_version.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/shellpattern.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/__main__.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/archiver.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/locking.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/logger.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/__init__.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/cache.py -> /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
copying borg/repository.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg
creating /home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/helpers.py -> 
/home/dhrdev/tmp/borg/.pybuild/pythonX.Y_3.4/build/borg/testsuite
copying borg/testsuite/compress.py -> 

Bug#812358: debian-live: Please add gparted

[Daniel Reichelt]

Hi Don,

> However, when I go to https://github.com/debian-live/live-images.git I cannot 
> find a branch that contains the old rescue build configuration.

said repository is quite correct, however the files got removed from the
tree by [1].


> Is this configuration laying around somewhere I can use as a starting point?

The package lists are available until [2]

Cheers
Daniel



[1]
https://github.com/debian-live/live-images/commit/4c1911124c2ae128312ae6d256c8322d944d258f

[2]
https://github.com/debian-live/live-images/tree/3de5ad45b9fd2d3a6874bb4757288299a3e3b01a/images/rescue/config/package-lists

Bug#807001: [Pkg-xfce-devel] Bug#807001: lightdm fails to register user-sessions

[Daniel Reichelt]

Note to self and other affected users: this is a *nasty*, yet feasible
workaround until this is fixed:


 8< /etc/inittab ---
rldm:a:once:/etc/init.d/lightdm restart
 8< 

Run `init q` to have it re-examine the inittab and from now on lightdm
can be restarted by running `init a`. (This does not change the
runlevel, see man init.)


Cheers

Daniel

Bug#807001: [Pkg-xfce-devel] Bug#807001: lightdm fails to register user-sessions

[Daniel Reichelt]

On 12/07/2015 01:30 PM, Yves-Alexis Perez wrote:
> On sam., 2015-12-05 at 17:59 +0100, Daniel Reichelt wrote:
>> Up until now I thought, lightdm failed to correctly register a
>> user-session, when really it failed to register one at all...
> 
> It might very well be because it reuses the ssh session or something. I think
> it'd help to remove this from the equation.
> 
> Regards,
> 

Right, it does re-use the session from the shell `service lightdm
restart` was invoked from. But there's no difference if that shell comes
from a ssh- or from a local login.

Here's `loginctl show-session` after I did the service restart from tty1:

8<
Id=3
Name=root
Timestamp=Mon 2015-12-07 22:22:43 CET
TimestampMonotonic=77192700
VTNr=1
TTY=/dev/tty1
Remote=no
Service=login
Scope=session-3.scope
Leader=6813
Audit=3
Type=tty
Class=user
Active=no
State=online
IdleHint=no
IdleSinceHint=1449523377884000
IdleSinceHintMonotonic=91836528
8<




And here goes another experiment: To circumvent that whole systemd
session hullabaloo, I added /bin/bash to /etc/inittab like this:
8<
8:S2:respawn:/bin/bash -il >/dev/tty8 2>&1 

Bug#807001: [Pkg-xfce-devel] Bug#807001: Bug#807001: lightdm fails to register user-sessions

[Daniel Reichelt]

> Yes it's a wrapper, but it's a needed one, it'll especially filter stuff in
> the environment. It would help to show the logind session before and after
> restart. I seem to remember that when you restart like that, the lightdm
> process will inherit the console session or something like that, and it'll
> mess up the permissions.
> 
> Try, on a fresh start:
> 
> loginctl
> service lightdm restart
> loginctl
> 
> and again report back.


Sure, here it is:

-8<---console --
### ssh prompt after fresh boot
# loginctl
   SESSIONUID USER SEAT
c1142 lightdm  seat0
 2  0 root

2 sessions listed.
# loginctl show-session c1
Id=c1
Name=lightdm
Timestamp=Sa 2015-12-05 17:39:23 CET
TimestampMonotonic=25179163
VTNr=7
Display=:0
Remote=no
Service=lightdm-greeter
Scope=session-c1.scope
Leader=6205
Audit=0
Type=x11
Class=greeter
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
# service lightdm restart
[ ok ] Stopping Light Display Manager: lightdm.
[ ok ] Starting Light Display Manager: lightdm.
# loginctl
   SESSIONUID USER SEAT
 2  0 root
-8<---end console --


I think you're on to something: after this, I logged in to lightdm (sure
enough, a broken session again) and noticed, that there's no new
session, but it "inherited" the session from the ssh login:
-8<---console --
$ echo $XDG_SESSION_ID
2
-8<---end console --


And, just for the sake of completeness, the data for the ssh-prompt:
-8<---console --
# loginctl show-session 2
Id=2
Name=root
Timestamp=Sa 2015-12-05 17:39:50 CET
TimestampMonotonic=51388061
VTNr=0
Remote=yes
RemoteHost=enterprise.startrek.nachtgeist.net
Service=sshd
Scope=session-2.scope
Leader=6806
Audit=2
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
-8<---end console --


Up until now I thought, lightdm failed to correctly register a
user-session, when really it failed to register one at all...



Daniel