Bug#966338: tomcat9: overrriding JAVA_HOME in /e/d/tomcat9 has changed

[Vincent McIntyre]

Package: tomcat9
Version: 9.0.31-1~deb10u2
Severity: normal
Tags: patch

I'm reporting a change in behaviour from tomcat8 and I'm not sure what the
correct fix is. While I'm reporting against the buster version, the issue
still seems to exist in current git (1ac6d044 Update changelog).

The gist is trying to override JAVA_HOME in the /etc/defaults/tomcat9 file
now _requires_ an export statement. This was not the case for tomcat8.

Gory details:

I found this on a machine upgraded from stretch to buster.
The old java version was the default and tomcat8 was still running:

% update-alternatives --display java
java - manual mode
  link best version is /usr/lib/jvm/java-11-openjdk-amd64/bin/java
  link currently points to /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
  link java is /usr/bin/java
  slave java.1.gz is /usr/share/man/man1/java.1.gz
/usr/lib/jvm/java-11-openjdk-amd64/bin/java - priority 
  slave java.1.gz: /usr/lib/jvm/java-11-openjdk-amd64/man/man1/java.1.gz
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java - priority 1069
  slave java.1.gz: /usr/lib/jvm/java-8-openjdk-amd64/jre/man/man1/java.1.gz


When I tried to start tomcat9 under java 11,
I did made the usual change in /etc/default/tomcat9

  #JAVA_HOME=/usr/lib/jvm/java-8-openjdk
 +JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

But when tomcat9 starts, it reports it is running under java 8
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server 
version name:   Apache Tomcat/9.0.31 (Debian)
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server 
built:  Jul 15 2020 11:43:33 UTC
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server 
version number: 9.0.31.0
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: 
  Linux
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:  
  4.19.0-9-amd64
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log 
Architecture:  amd64
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home:   
  /usr/lib/jvm/java-8-openjdk-amd64/jre
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 
  1.8.0_252-8u252-b09-1~deb9u1-b09
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:  
  Oracle Corporation
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log 
CATALINA_BASE: /var/lib/tomcat9
 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log 
CATALINA_HOME: /usr/share/tomcat9


This seems to be because there is no export of JAVA_HOME when it is overridden,
i.e. this configuration in /etc/default/tomcat9 works correctly:

  #JAVA_HOME=/usr/lib/jvm/java-8-openjdk
 +JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
 +export JAVA_HOME

The 'export' was not necessary in tomcat8 because the init script takes
care of it

 81 # Look for the right JVM to use
 82 for jdir in $JDK_DIRS; do
 83 if [ -r "$jdir/bin/java" -a -z "${JAVA_HOME}" ]; then
 84 JAVA_HOME="$jdir"
 85 fi
 86 done
 87 export JAVA_HOME

Where the startup sequence loses track of a JAVA_HOME override is when
  /usr/libexec/tomcat9/tomcat-start.sh
execs into
  "/usr/share/tomcat9/bin/catalina.sh run"
and that script sources
   /usr/share/tomcat9/bin/setclasspath.sh

In that script this test fails and JAVA_HOME is set to /usr
 24 # Make sure prerequisite environment variables are set
 25 if [ -z "$JAVA_HOME" ] && [ -z "$JRE_HOME" ]; then
 26   if $darwin; then
...
 34   else
 35 JAVA_PATH=`which java 2>/dev/null`
 36 if [ "x$JAVA_PATH" != "x" ]; then
 37   JAVA_PATH=`dirname "$JAVA_PATH" 2>/dev/null`
 38   JRE_HOME=`dirname "$JAVA_PATH" 2>/dev/null`
 39 fi


The squence of events leading up to this is
systemd calls
  /usr/libexec/tomcat9/tomcat-start.sh
which sources
  /etc/default/tomcat9
and then sources
  /usr/libexec/tomcat9/tomcat-locate-java.sh

This script does the same job as the init script code above,
but the important difference is that it only exports JAVA_HOME
if it updates it; if JAVA_HOME is already set then the script
does not export it.

Before, that hunk of code exported JAVA_HOME unconditionally.

Then we exec into catalina.sh and the not-exported JAVA_HOME override is lost.


Possible fixes:

 * tweak the example override in /etc/default/tomcat9
   - #JAVA_HOME=/usr/lib/jvm/java-8-openjdk
   + #JAVA_HOME=/usr/lib/jvm/java-8-openjdk; export JAVA_HOME

 * unconditionally export JAVA_HOME

--- tomcat-locate-java.sh   2020-07-27 16:13:45.903064630 +1000
+++ tomcat-locate-java.sh.new   2020-07-27 16:14:09.283692229 +1000
@@ -40,10 +40,11 @@
 JAVA_HOME="$jdir"
 fi
 done
-export JAVA_HOME
 fi

 if [ -z "$JAVA_HOME" ]; then
 echo "<2>No JDK or JRE found - Please set the JAVA_HOME variable or 
install the default-jdk package"
 exit 1

Bug#959219: davmail: minor backporting issues

[Vincent McIntyre]

Subject: davmail: minor backporting issues
Package: davmail
Version: 5.5.1.3299-2
Severity: wishlist
Tags: patch

I was trying to build this on buster and hit a couple of small issues.
Not sure how many of these qualify as 'bugs' vs 'features' but thought
I would report just in case some need addressing.

First, the dependency 'debhelper-compat (=12)' seems to lead to an
error

 % dpkg-buildpackage -us -uc
 dpkg-buildpackage: info: source package davmail
 dpkg-buildpackage: info: source version 5.5.1.3299-2
 dpkg-buildpackage: info: source distribution UNRELEASED
 dpkg-buildpackage: info: source changed by Debian Janitor 
 dpkg-buildpackage: info: host architecture amd64
  dpkg-source --before-build .
 dpkg-source: info: using patch list from debian/patches/series
 dpkg-source: info: applying 0001-no-windows-service.patch
 dpkg-source: info: applying 0006-Disable-the-check-for-a-new-release.patch
  fakeroot debian/rules clean
 dh clean --with javahelper
debian/rules override_dh_auto_clean
 make[1]: Entering directory '/var/tmp/git/clones/davmail'
 test -d lib || mkdir lib
 dh_auto_clean
 ant -propertyfile ./debian/ant.properties clean
 Buildfile: /var/tmp/git/clones/davmail/build.xml

 clean:

 BUILD SUCCESSFUL
 Total time: 0 seconds
 make[1]: Leaving directory '/var/tmp/git/clones/davmail'
jh_clean
 dpkg-query: package 'debhelper-compat' is not installed
 Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
 jh_linkjars: dpkg -L "debhelper-compat" returned exit code 1
dh_clean
  dpkg-source -b .
 dpkg-source: info: using source format '3.0 (quilt)'
 dpkg-source: info: building davmail using existing 
./davmail_5.5.1.3299.orig.tar.gz
 dpkg-source: info: using patch list from debian/patches/series
 dpkg-source: warning: ignoring deletion of directory src/data
 dpkg-source: info: building davmail in davmail_5.5.1.3299-2.debian.tar.xz
 dpkg-source: info: building davmail in davmail_5.5.1.3299-2.dsc
  debian/rules build
 dh build --with javahelper
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
jh_linkjars
 dpkg-query: package 'debhelper-compat' is not installed
 Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
 jh_linkjars: dpkg -L "debhelper-compat" returned exit code 1
 make: *** [debian/rules:5: build] Error 1
 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


I worked around this like so

diff --git a/debian/control b/debian/control
index e0972dde..efe2adc0 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Alexandre Rossi 
Uploaders: Geert Stappers 
Section: net
Priority: optional
-Build-Depends: debhelper-compat (=12),
+Build-Depends: debhelper (>= 12),
   default-jdk,
   ant,
   ant-optional,

as well as reinstating the debian/compat file

 echo 12 >debian/compat

After a bit of digging it seems this was fixed in javahelper-0.72.10
(see #933715). So probably nothing needs to be done here.


When it came to installation, I got this error

 adduser: Please enter a username matching the regular expression configured
 via the NAME_REGEX configuration variable.  Use the `--force-badname'
 option to relax this check or reconfigure NAME_REGEX.
 dpkg: error processing package davmail (--install):

Which this patch fixes

index e3185b58..7bcaad57 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -6,7 +6,7 @@ if ! pidof systemd > /dev/null; then
USER=_davmail

if ! getent passwd $USER > /dev/null; then
-adduser --quiet --system --no-create-home --home /var/lib/$USER $USER
+adduser --quiet --system --no-create-home --force-all --home 
/var/lib/$USER $USER
fi

for i in /var/log/davmail /var/lib/$USER;


Note that --force-badname is deprecated, according to dpkg-statoverride;
I get this warning if I use -force-badname

 : warning: deprecated --force option; use --force-all instead

I briefly poked around in the adduser git but I don't see where this warning
is coming from.

Kind regards
Vince


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-71
ii  init-system-helpers   1.56+nmu1
ii  jarwrapper0.72.9
ii  libcommons-codec-java 1.11-1
ii  libcommons-httpclient-java3.1-15
ii  

Bug#946126: lintian: Please complain about debian/NEWS.Debian

[Vincent McIntyre]

Package: lintian
Version: 2.39.0
Severity: wishlist

Dear Maintainer,

unison (2.48.4-3) was released without an important note in the NEWS file.
The note was in the package source, but not included in the binary package.
See bug 946041.

The reason for this appears to be longstanding, see bug 429510.

Perhaps lintian could warn about this?
If debian/NEWS.Debian exists, remind the packager that the file should
be called debian/NEWS. Not sure if debian/.NEWS is allowed.

There may already be a similar check for debian/[README|TODO].Debian

This issue may go away with a later debhelper compatibility level
but since it's been around since 2007, perhaps it's worth a lintian rule.

-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'oldstable-debug')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.18.25
ii  dpkg-dev  1.18.25
ii  file  1:5.30-1+deb9u3
ii  gettext   0.19.8.1-2+deb9u1
ii  gnupg [gpg]   2.1.18-8~deb9u4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1+deb9u1
ii  libberkeleydb-perl0.55-1+b2
ii  libcapture-tiny-perl  0.44-1
ii  libcgi-pm-perl4.35-1
ii  libclass-accessor-perl0.34-1
ii  libclass-xsaccessor-perl  1.19-2+b7
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.25
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libfile-find-rule-perl0.34-1
ii  libio-async-loop-epoll-perl   0.20-1~bpo9+1
ii  libio-async-perl  0.71-1
ii  libipc-run-perl   0.94-1+deb9u1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libmldbm-perl 2.05-2
ii  libmoo-perl   2.002005-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.100-1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  libtry-tiny-perl  0.28-1
ii  libtype-tiny-perl 1.05-1
ii  liburi-perl   1.71-1
ii  libxml-simple-perl2.22-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-3+deb9u5
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#870448: hw-detect - stop using modprobe -l

[Vincent McIntyre]

On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> On Wed, 2017-08-02 at 12:26 +1000, Vincent McIntyre wrote:
> > Package: hw-detect
> > Version: 1.124
> > Severity: normal
> > Tags: patch
> > 
> > I keep seeing this in installer logs, back to jessie.
> > 
> > Aug  2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option -- 
> > 'l'
> > 
> > 
> > I rated this normal rather than minor because the way it is working
> > now the is_available() function always returns 1 (failure)
> > 
> > My suggestion is to use modinfo instead.
> > This will return multiline output inside the quotes but
> > a couple of tests suggests that is ok.
> > It does fail with some modules (nvidia), not sure if we care.
> >
> > diff --git a/hw-detect.sh b/hw-detect.sh
> > index 7977814..d8196c1 100755
> > --- a/hw-detect.sh
> > +++ b/hw-detect.sh
> > @@ -43,7 +43,7 @@ is_not_loaded() {
> >  }
> >  
> >  is_available () {
> > -   [ "$(modprobe -l $1)" ] || return 1
> > +   [ "$(modinfo $1)" ] || return 1
> >  }
> 
> But this still prints error messages for missing modules.  I think the
> function should be implemented as:
> 
> is_available () {
>   modprobe -qn "$1"
> }
> 

That seems much better, can someone please apply Ben's version?
Thanks for tickling this Holger.

Cheers
Vince

Bug#916663: libc6-udeb segfaults in buster alpha 4

[Vincent McIntyre]

Package: libc6-udeb
Version: 2.28-2
Severity: important

Trying to install with the netinst image from [1]

The hardware is a Dell Optiplex with 64-bit Intel processor.
There is an old install of jessie on the disk, which is two
SSDs in software raid-1. One partition for /, the rest is LVM.

I am doing the interactive install.
Set country = AU, keyboard = US, TZ location = New South Wales
Set up root password and default user account.
Set mirror to: ftp.au.debian.org, also tried deb.debian.org.

Right after libc6-udeb is downloaded I get a segfault.

Below is a transcription of the console (alt-f4) at the point
where the failure occurs. Once the segfault starts, I can't
run any commands at all, not even --.

Dec 16 23:59:50 anna-install: Installing partman-auto-lvm
Dec 16 23:59:50 anna[4872] DEBUG: retrieving libc6-udeb 2.28-2
Dec 16 23:59:51 anna[4072] 2018-12-16 23:59:21 
URL:http://cdn-fastly.deb.debian.org/debian//pool/main/glibc/libc6_udeb_2.28-2_amd64.udeb
 [1323560/1323560] -> 
"/var/cache/anna/_fetch-url_libc6-udeb_2.28-2_amd64.udeb.4878" [1]
Dec 16 23:59:51 kernel: [  149.467327] sh[4906]: segfault at 401d2460 ip 
7175b54b207 sp 7ffdf4711990 error 4 in libc-2.28.so[7f75b54a7000+148000]
Dec 16 23:59:51 kernel: [  149.467332] Code: 66 45 85 c0 0f 84 71 01 00 00 4c 
8b 41 10 4d 85 6d 01 00 00 4c 39 cd 0f 84 70 01 00 00 0f 1f 00 48 83 c7 04 83 
c0 01  47 fc 01 75 83 89 c1 48 8d 0c 49 49 8d 0c ca 44 0f b7 41 06 66

In case this is a repeat of whatever 837123 was (it seems different)
I tried booting a stretch netinst image on the same hardware, using
the same tftp server, deb.debian.org as mirror. All seems fine, the
installer dropped me into the partitioner so I left it at that.

I tried on different hardware, to check.
This was similar to the first system (Dell Optiplex 990),
but running stretch. Single 1Tb SATA disk, separate / and the rest LVM.
I see the same segfault at the same point the installation process.

Kind regards
Vince

[1] 
http://ftp.us.debian.org/debian/dists/buster/main/installer-amd64/current/images/netboot/debian-installer/amd64

-- 

Bug#301953: retry mostly works now

[Vincent McIntyre]

Version: 1:1.3.4-2.1

nfs-common version 1:1.3.4-2.1
kernel linux-image-4.9.0-8-amd64 4.9.130-2 

It takes a little longer than the advertised 60s.
It tries 10 times and gives up.

% /usr/bin/time -p sudo mount - -t nfs -o vers=3,retry=1 192.168.30.1:/blah 
/mnt
mount.nfs: timeout set for Sat Dec 15 21:04:10 2018
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
imount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: Connection timed out
Command exited with non-zero status 32
real 65.87
user 0.02
sys 0.04

Same for vers=2
% /usr/bin/time -p sudo mount - -t nfs -o vers=2,retry=1 192.168.30.1:/blah 
/mnt
mount.nfs: timeout set for Sat Dec 15 21:05:58 2018
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=2,retry=1,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=2, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=2, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: Connection timed out
Command exited with non-zero status 32
real 65.77
user 0.02
sys 0.04


Setting retry=2 does indeed double the time to timeout.

% /usr/bin/time -p sudo mount - -t nfs -o vers=3,retry=2 192.168.30.1:/blah 
/mnt
mount.nfs: timeout set for Sat Dec 15 21:09:13 2018
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 13, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Timed out
mount.nfs: trying text-based options 'vers=3,retry=2,addr=192.168.30.1'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Timed 

Bug#756171: duplicate

[Vincent McIntyre]

This seems to be a duplicate of 756170 and should be merged or closed.

Kind regards
Vince
-- 

Bug#857043: mountstats?

[Vincent McIntyre]

Hello Pere

does

 # /usr/sbin/mountstats /path/to/mount

do what you are looking for?
the code does seem to have some reporting of timeouts
if there are retries occurring.

Kind regards
Vince

Bug#860264: ifquery behaviour

[Vincent McIntyre]

# grep auto /etc/network/interfaces
auto lo
# grep hotplug /etc/network/interfaces
allow-hotplug enp0s31f6

# ifquery --read-environment --list --exclude=lo  # as in unit file
#
# ifquery --read-environment --list --exclude=lo --allow auto
#
# ifquery --read-environment --list --exclude=lo --allow hotplug
enp0s31f6

But if I convert enp0s31f6 to auto
# grep /etc/network/interfaces
auto lo
auto enp0s31f6

# ifquery --read-environment --list --exclude=lo --allow hotplug
#  (as expected)
# ifquery --read-environment --list --exclude=lo --allow auto
enp0s31f6
# ifquery --read-environment --list --exclude=lo
enp0s31f6

So with the interface set to auto, the ifquery in the unit file
picks it up. With the interface set to allow-hotplug, it doesn't.

I think this is part of the puzzle, but there is more to it.
I think that there are some issues arising from how ifupdown
and systemd (fail to) communicate about when exactly the network
interface is fully up and working (particularly in the dhcp case).
If you look at the work that has gone into ifupdown since the
stretch release, it seems like there are some issues there that
have now, hopefully, been resolved.

Kind regards
Vince

Bug#756170: mount option timeo - in deciseconds, or seconds?

[Vincent McIntyre]

I think this report is incorrect.
If you agree, please close it.
If not, please offer some evidence for your belief.
My evidence is below.

I looked in the upstream git of nfs-utils.
The 'deciseconds' has been in there since the start of git history
(2007, commit id 16db99b56a532bf56fa27618a6ef30763cd9006f).
 
There is no direct use of the 'timeo' field of the NFS data structure
in nfs-utils so we have to look at the kernel code.
 
In linux/fs/nfs/client.c there is this function

/*  
 * Initialise the timeout values for a connection   
 */ 
void nfs_init_timeout_values(struct rpc_timeout *to, int proto, 
int timeo, int retrans) 
{   
to->to_initval = timeo * HZ / 10;   
...

which is called from this function in the same module

static int nfs_init_server(struct nfs_server *server,   
   const struct nfs_parsed_mount_data *data,
   struct nfs_subversion *nfs_mod)  
{   
struct rpc_timeout timeparms;   
struct nfs_client_initdata cl_init = {  
.hostname = data->nfs_server.hostname,  
.addr = (const struct sockaddr *)>nfs_server.address, 
.addrlen = data->nfs_server.addrlen,
.nfs_mod = nfs_mod, 
.proto = data->nfs_server.protocol, 
.net = data->net,   
.timeparms = ,
};  
struct nfs_client *clp; 
int error;  

nfs_init_timeout_values(, data->nfs_server.protocol,  
data->timeo, data->retrans);
if (data->flags & NFS_MOUNT_NORESVPORT) 
set_bit(NFS_CS_NORESVPORT, _init.init_flags);


I think this makes it reasonably  clear 'timeo' is in deciseconds,
although the manpage could take a few words to explain how it comes
to use that peculiar unit.

Kind regards
Vince

Bug#895384: fixed in git?

[Vincent McIntyre]

This seems to have been addressed by Laurent recently (thanks!)

https://salsa.debian.org/debian/nfs-utils/commit/cd79aec324fe58a240b29d53445de33147eb166b

Laurent, perhaps the changelog line could have
 (Closes: #895384)
appended? I'm not sure what the protocol is here.

Kind regards
Vince

Bug#892654: duplicate of 857912?

[Vincent McIntyre]

Thanks for your report.
It looks very like a duplicate of 857912.
If you agree, could you close this bug or merge it?

Kind regards
Vince

Bug#868099: is this still an issue?

[Vincent McIntyre]

For rkhunter 1.4.2-6+deb9u1

% cat /var/lib/dpkg/info/rkhunter.conffiles
/etc/apt/apt.conf.d/90rkhunter
/etc/cron.daily/rkhunter
/etc/cron.weekly/rkhunter
/etc/logcheck/ignore.d.server/rkhunter
/etc/logrotate.d/rkhunter
/etc/rkhunter.conf

% dpkg -S /etc/default/rkhunter
dpkg-query: no path found matching pattern /etc/default/rkhunter

# debconf-get-selections | grep rkhunter
 # Automatically update rkhunter's file properties database?
 rkhunterrkhunter/apt_autogenboolean true
 # Activate weekly update of rkhunter's databases?
 rkhunterrkhunter/cron_db_update boolean true
 # Activate daily run of rkhunter?
 rkhunterrkhunter/cron_daily_run boolean true


If I build 1.4.6-4 from git, the conffiles list is the same.

The file is still heavily used by the maintainer scripts but
managed by ucf - I don't see how it is marked as a conffile.

Cheers
Vince

Bug#914256: lintian: conflict between no-template-description and untranslatable-debconf-templates

[Vincent McIntyre]

On Thu, Nov 22, 2018 at 12:24:19PM -0500, Chris Lamb wrote:
> Hi Vincent,
> 
> > E: hello source: not-using-po-debconf
> > E: hello: no-template-description hello/all-languages
> > E: hello: unknown-field-in-templates hello/all-languages _description
> > 
> > So still the same problem.
> 
> Sorry, please let us know exactly versions of Lintian you are using
> rather than "the source package" or similar. It is very easy to get
> them all mixed up and accidentally waste others time, alas.

Apologies.
The tests I just related above with "still the same problem"
were for lintian 2.5.112~bpo9+1.
I was using the source package for version 2.5.112~bpo9+1,
downloaded with 'apt-get source lintian'.
I didn't have any other version of lintian installed.

> > Still unclear why the lintian test cases are not failing.
> 
> I suspect it is something to do with debian/po/ or something like
> that but, again, debconf & translations thereof are not something
> I've ever really played with, sorry.
> 

If I get time to run it down I will update the bug but in the meantime
input from any passing experts would be appreciated.

Kind regards
Vince

Bug#914308: ifenslave: typo in bonding example

[Vincent McIntyre]

Package: ifenslave
Version: 2.9
Severity: normal
Tags: patch


(sorry for the mess Guus)

diff --git a/debian/examples/two_hotplug_ethernet 
b/debian/examples/two_hotplug_ethernet
index 4d7f75f..9012e15 100644
--- a/debian/examples/two_hotplug_ethernet
+++ b/debian/examples/two_hotplug_ethernet
@@ -14,7 +14,7 @@ iface eth0 inet manual
bond-primary eth0 eth1

 allow-hotplug eth1
-iface eth0 inet manual
+iface eth1 inet manual
bond-master bond0
bond-primary eth0 eth1

Bug#914256: lintian: conflict between no-template-description and untranslatable-debconf-templates

[Vincent McIntyre]

> Hm, I can't seem to reproduce this in the lintian testsuite. After adding:
> 
>   --- a/t/tests/legacy-debconf/debian/debian/debconf-test.templates
>   +++ b/t/tests/legacy-debconf/debian/debian/debconf-test.templates
>   @@ -99,3 +99,15 @@ Type: boolean
>_Description: Decide, lintian
> Using "no longer" should no longer be detected as 
> making-assumptions-about-interfaces-in-templates by lintian.
>   +
>   +Template: debconf/no-underscore
>   +Type: boolean
>   +Default: false
>   +Description: This has no underscore?
>   + This has no underscore.
>   +
>   +Template: debconf/with-underscore
>   +Type: boolean
>   +Default: false
>   +_Description: This has an underscore?
>   + This has an underscore.
> 

I added this to a copy of the source package and ran
  fakeroot debian/rules runtests
but it didn't run the legacy-debconf tests as far as I can see...

Oh. Had to install debhelper from backports also, which pulled in
 cmake cmake-data debhelper dh-autoreconf quilt dwz librhash0
and it wanted
 dh-elpa
as well.

% grep -n underscore 
debian/test-out/tests/debconf/debconf-1~rc1/debian/debconf-test.templates |grep 
Desc
106:Description: This has no underscore?
112:_Description: This has an underscore?

% grep -n untranslatable-debconf-templates 
debian/test-out/tests/debconf/tags.debconf
2:E: debconf source: untranslatable-debconf-templates debconf-test.templates: 
106
3:E: debconf source: untranslatable-debconf-templates debconf-test.templates: 47
4:E: debconf source: untranslatable-debconf-templates debconf-test.templates: 58

% egrep -e '(no|with)-underscore' debian/test-out/tests/debconf/tags.debconf
I: debconf-test: unused-debconf-template debconf/no-underscore
I: debconf-test: unused-debconf-template debconf/with-underscore

Which reproduces your result.



So back to the hello package hacking

% grep Desc debian/templates
Description: Use all available languages?

E: hello source: untranslatable-debconf-templates templates: 4
E: hello source: not-using-po-debconf

% grep Desc debian/templates
_Description: Use all available languages?

E: hello source: not-using-po-debconf
E: hello: no-template-description hello/all-languages
E: hello: unknown-field-in-templates hello/all-languages _description

So still the same problem.


What if I configure po-debconf?
% man po-debconf
#hm, not so scary after all

% mkdir debian/po
% cat > debian/po/POTFILES.in
[type: gettext/rfc822deb] templates
^D

% debconf-updatepo
% ls debian/po/
total 8
4 POTFILES.in  4 templates.pot

% grep Desc debian/templates
_Description: Use all available languages?

% lintian --version
Lintian v2.5.112~bpo9+1

% debuild -us -uc
... No errors.


Still unclear why the lintian test cases are not failing.

Vince

Bug#914256: lintian: conflict between no-template-description and untranslatable-debconf-templates

[Vincent McIntyre]

On Wed, Nov 21, 2018 at 03:38:01AM -0500, Chris Lamb wrote:
> Hi Vincent.
> 
> > Version: 2.5.50.4
> […]
> > I also had a look at the git repository and could not see recent
> > work related to either of the tags involved here.
> 
> Granted and will try and reproduce later but just an FYI that
> 2.5.112~bpo9+1 is in stretch-backports so it should be easy to
> install and reconfirm with the latest version.
> 

Great idea, I gave it a try. libxml-simple-perl and lintian
were installed. I tried a few permutations.

% grep -n Description debian/templates 
4:Description: Use all available languages?

Result:
E: hello source: untranslatable-debconf-templates templates: 4
E: hello source: not-using-po-debconf



% grep Description debian/templates 
_Description: Use all available languages?

Result:
E: hello source: not-using-po-debconf
E: hello: no-template-description hello/all-languages
E: hello: unknown-field-in-templates hello/all-languages _description



% grep Description debian/templates 
Description-en: Use all available languages?

Result:
E: hello: no-template-description hello/all-languages


% grep Description debian/templates  
_Description-en: Use all available languages?

Result:
E: hello: no-template-description hello/all-languages
E: hello: unknown-field-in-templates hello/all-languages _description-en



It is also warning about ancient-standards-version 3.9.6
but I don't see how that could be the cause of the problem.

Thanks for taking the time to look at this
Cheers
Vince

Bug#914256: lintian: conflict between no-template-description and untranslatable-debconf-templates

[Vincent McIntyre]

Package: lintian
Version: 2.5.50.4
Severity: normal

   * What led up to the situation?

(The issue is independent of the 'hello' package, I just used it to make
 reproduction easier.)

$ apt-get source hello

$ cd hello-2.10

$ cat > debian/templates
Template: hello/all-languages
Type: boolean
Default: false
Description: Use all available languages?
 This program can speak in many languages.

$ cat >debian/config
#!/bin/sh -e
# This may ask for config info but should not change anything
# Postinst should change things.

# Source debconf library.
. /usr/share/debconf/confmodule

db_title "hello" || true


$ debuild -us -uc
...
Now running lintian...
...
E: hello source: untranslatable-debconf-templates templates: 4
...

So far, so good.
But if I do what seems to be the recommended thing I get told off again:

$ sed -i -e 's/^Desc/_Desc/' debian/templates
$ debuild -us -uc
...
Now running lintian...
...
E: hello: no-template-description hello/all-languages
E: hello: unknown-field-in-templates hello/all-languages _description

I did try putting both a Description: and _Description: field in but that
did not work either.

This seems like a bug, but if I'm missing some templating magic spell
I would be happy to help document it better.

I've already consulted the sources below:
 - https://manpages.debian.org/stretch/debconf-doc/debconf-devel.7.en.html
 - 
https://www.debian.org/doc/debian-policy/ch-binary.html#prompting-in-maintainer-scripts
 - https://www.debian.org/doc/packaging-manuals/debconf_specification.html

I also had a look at the git repository and could not see recent
work related to either of the tags involved here.

Kind regards
Vince

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

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

Versions of packages lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  file  1:5.30-1+deb9u2
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1+deb9u1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.25
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1+deb9u1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-3+deb9u4
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.25
pn  libperlio-gzip-perl  
ii  perl 5.24.1-3+deb9u4
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-3+deb9u4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.25
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#913207: mytop: depends on libconfig-inifiles-perl but package does not Depend on it

[Vincent McIntyre]

Package: mariadb-client-10.1
Version: 10.1.26-0+deb9u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   
$ mytop
Can't locate Config/IniFiles.pm in @INC (you may need to install the 
Config::IniFiles module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
/usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/bin/mytop 
line 18.
BEGIN failed--compilation aborted at /usr/bin/mytop line 18.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

$ dpkg -S /usr/bin/mytop
mariadb-client-10.1: /usr/bin/mytop

$ apt-cache show mariadb-client-10.1| egrep '(Dep|Rec|Sug)'
Depends: debianutils (>= 1.6), mariadb-client-core-10.1 (>= 10.1.26-0+deb9u1), 
perl:any, libaio1 (>= 0.3.93), libc6 (>= 2.17), libjemalloc1 (>= 2.1.1), 
libpcre3, libstdc++6 (>= 5.2), libsystemd0, zlib1g (>= 1:1.2.0)
Recommends: libdbd-mysql-perl (>= 1.2202), libdbi-perl, libterm-readkey-perl

I was expecting the mariadb-client package would have
libconfig-inifiles-perl set as a Dependency.

Please can you fix this in the stable version?

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

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

Versions of packages mariadb-client-10.1 depends on:
ii  debianutils   4.8.1.1
ii  libaio1   0.3.110-3
ii  libc6 2.24-11+deb9u3
ii  libjemalloc1  3.6.0-9.1
ii  libpcre3  2:8.39-3
ii  libstdc++66.3.0-18+deb9u1
ii  libsystemd0   232-25+deb9u4
ii  mariadb-client-core-10.1  10.1.26-0+deb9u1
ii  perl  5.24.1-3+deb9u4
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-client-10.1 recommends:
ii  libdbd-mysql-perl 4.041-2
ii  libdbi-perl   1.636-1+b1
ii  libterm-readkey-perl  2.37-1

mariadb-client-10.1 suggests no packages.

-- no debconf information

-- 

Bug#906904: a workaround

[Vincent McIntyre]

Installing the following file and rebooting allows the nvidia drivers
to retain control of the console.

% cat /etc/modprobe.d/i915.conf 
# This module conflicts with the nvidia drivers & blacklisting does not work
install i915 /bin/true

This workaround is probably only useful for similar hardware,
that wants to load the i915 driver. In my case it is

% lspci | grep -i vga|grep -iv nvidia
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)

Bug#907837: suggested patch

[Vincent McIntyre]

Not quite sure about the wording, but a first try:

diff --git a/en/install-methods/install-tftp.xml 
b/en/install-methods/install-tftp.xml
index 868c70155..7236fa836 100644
--- a/en/install-methods/install-tftp.xml
+++ b/en/install-methods/install-tftp.xml
@@ -178,7 +178,10 @@ For PXE booting, everything you should need is set up in 
the
 netboot/netboot.tar.gz tarball. Simply extract this
 tarball into the tftpd boot image directory. Make sure
 your dhcp server is configured to pass pxelinux.0
-to tftpd as the filename to boot.
+to tftpd as the filename to boot. For UEFI machines,
+you will need to pass an appropriate EFI boot image name (such as
+/debian-installer/amd64/bootnetx64.efi).
+
 
 
 
diff --git a/en/install-methods/tftp/dhcp.xml b/en/install-methods/tftp/dhcp.xml
index 6982c2a98..97a9ab878 100644
--- a/en/install-methods/tftp/dhcp.xml
+++ b/en/install-methods/tftp/dhcp.xml
@@ -90,5 +90,22 @@ is a boot loader, not a kernel image (see 
 below).
 
 
+
+
+If your machine uses UEFI to boot, you will have to specify a boot loader
+appropriate for UEFI machines, for example
+
+
+group {
+  next-server 192.168.1.3;
+  host tftpclient {
+# tftp client hardware address
+  hardware ethernet  00:10:DC:27:6C:15;
+  filename "debian-installer/amd64/bootnetx64.efi";
+ }
+}
+
+
+

   

-- 

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

On a system where I have been successfully mixing stable & backports
I hit the same dependency problem. So I think this is a recent change.
I tried to dig a bit further to see if I could flush out the cause.

TL;DR libegl1-glvnd-nvidia, which I previously installed from backports,
  is only in stable and not (any longer) in stretch-backports.

Does this imply the dependencies of the backported nvidia-egl-icd
need to be tweaked (drop libegl1-glvnd-nvidia)?

Gory details:

# apt -t stretch-backports install nvidia-egl-icd
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:
 nvidia-egl-icd : Depends: libegl1 (>= 0.2.999) but it is not going to be 
installed or
   libegl1-glvnd-nvidia but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.

# apt-cache show nvidia-egl-icd | grep Depend | sed -e 's/, /\n/g'
Depends: nvidia-egl-common
libegl1 (>= 0.2.999) | libegl1-glvnd-nvidia
libegl-nvidia0 (= 390.77-1~bpo9+1)
Depends: nvidia-egl-common
libegl1xxx (>= 0.2.999) | libegl1-glvnd-nvidia
libegl-nvidia0 (= 390.48-2~bpo9+3)
Depends: nvidia-egl-common
libegl1 (>= 0.2.999) | libegl1-glvnd-nvidia
libegl-nvidia0 (= 384.130-1)

# dpkg -l libegl1 libegl-nvidia0 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  libegl-nvidia0:amd64   390.48-2~bpo9+3  amd64NVIDIA binary EGL 
library
un  libegl1  (no description 
available)

# dpkg -l libegl1xxx  libegl1-glvnd-nvidia
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  libegl1-glvnd-nvidia:a 390.48-2~bpo9+3  amd64Vendor neutral GL 
dispatch library -- libEGL
un  libegl1xxx   (no description 
available)


So as a starting point I have libegl1-glvnd-nvidia installed,
instead of libegl1xxx or libegl1 (neither of which were ever installed).

It seems that for some reason apt now wants libegl1 in preference
to libegl1-glvnd-nvidia, despite the latter being the latest version.
The preferences scoring comes out like this:

# apt-cache policy libegl1
libegl1:
  Installed: (none)
  Candidate: 1.0.0+git20180308-2~bpo9+1
  Version table:
 1.0.0+git20180308-2~bpo9+1 200
200 http://debian-archive.atnf.csiro.au:/debian 
stretch-backports/main amd64 Packages

# apt-cache policy  libegl1-glvnd-nvidia
libegl1-glvnd-nvidia:
  Installed: 390.48-2~bpo9+3
  Candidate: 390.48-2~bpo9+3
  Version table:
 *** 390.48-2~bpo9+3 100
100 /var/lib/dpkg/status
 384.130-1 990
990 http://debian-archive.atnf.csiro.au:/debian stretch/non-free 
amd64 Packages

So it looks like libegl1-glvnd-nvidia has been removed from the
backports suite?

I checked what explicitly installing all the packages that can be
upgraded would do, which may be of interest.

# apt --simulate -t stretch-backports install `cat upgradable`
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libdrm-amdgpu1
  libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl1
  libegl1-mesa libgl1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles2
  libgles2-mesa libglvnd0 libglx-mesa0 libglx0 libllvm6.0 libwayland-egl1
  libwayland-egl1-mesa update-glx
Recommended packages:
  libcuda1-i386 nvidia-settings nvidia-driver-libs-i386 libopengl0
  | libopengl0-glvnd-nvidia libgles-nvidia2 nvidia-egl-wayland-icd
  nvidia-vulkan-icd
The following packages will be REMOVED:
  libegl1-glvnd-nvidia libgl1-glvnd-nvidia-glx libglvnd0-nvidia
  libglx0-glvnd-nvidia
The following NEW packages will be installed:
  libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1
  libegl1 libgl1 libgl1-mesa-dri libgles2 libglvnd0 libglx-mesa0 libglx0
  libllvm6.0 libwayland-egl1
The following packages will be upgraded:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions 

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

On Wed, Aug 22, 2018 at 03:57:51PM +0100, Luca Boccassi wrote:
> 
> Because I suspect something on your system is causing some packages to
> be picked from backports and some from stable. That's what's breaking.
> So try and remove any custom configuration you have for apt and then it
> should work.
> 

I broke down and read apt_preferences(5) again and found this:

  If the target release has been specified then APT uses the following
  algorithm to set the priorities of the versions of a package. Assign:
  ...
  priority 990
  to the versions that belong to the target release.
  The highest of those priorities whose description matches the version
  is assigned to the version.

So I think my apt configuration is ok.

I did the experiment (comment out default-release setting)
but it still falls over:

# apt-cache policy nvidia-driver
nvidia-driver:
  Installed: (none)
  Candidate: 384.130-1
  Version table:
 390.77-1~bpo9+1 200
200 http://debian-archive.atnf.csiro.au:/debian 
stretch-backports/non-free amd64 Packages
 384.130-1 500
500 http://debian-archive.atnf.csiro.au:/debian stretch/non-free 
amd64 Packages

# apt-get install nvidia-driver
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:
 nvidia-driver : Depends: nvidia-driver-libs (= 384.130-1) but it is not going 
to be installed or
  nvidia-driver-libs-nonglvnd (= 384.130-1) but it is 
not going to be installed
E: Unable to correct problems, you have held broken packages.



This preferences tweak kind of fixes the issue for me

# cat /etc/apt/preferences.d/backports
Explanation: Low priority to avoid installation unless explicitly required
Package: *
Pin: release a=stretch-backports
Pin-Priority: 200
Explanation: Negative priority; mixing stable & backports not supported
Package: nvidia* libnvidia* libegl* libgl* glx-*
Pin: release a=stretch-backports
Pin-Priority: -1

# apt-cache policy nvidia-driver
nvidia-driver:
  Installed: (none)
  Candidate: 384.130-1
  Version table:
 390.77-1~bpo9+1 -1
100 http://debian-archive.atnf.csiro.au:/debian 
stretch-backports/non-free amd64 Packages
 384.130-1 990
990 http://debian-archive.atnf.csiro.au:/debian stretch/non-free 
amd64 Packages

# apt-get install nvidia-driver
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl-nvidia0
  libegl1-glvnd-nvidia libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
  libglvnd0-nvidia libglx-nvidia0 libglx0-glvnd-nvidia libnvidia-eglcore
  libnvidia-glcore libnvidia-ml1 nvidia-alternative nvidia-driver-bin
  nvidia-driver-libs nvidia-egl-common nvidia-egl-icd nvidia-installer-cleanup
  nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-support
  nvidia-legacy-check nvidia-modprobe nvidia-support nvidia-vdpau-driver
  update-glx xserver-xorg-video-nvidia
Recommended packages:
  nvidia-settings nvidia-persistenced nvidia-driver-libs-i386 libopengl0
  | libopengl0-glvnd-nvidia libgles-nvidia1 libgles-nvidia2 libnvidia-cfg1
  nvidia-egl-wayland-icd nvidia-vulkan-icd
The following NEW packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl-nvidia0
  libegl1-glvnd-nvidia libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
  libglvnd0-nvidia libglx-nvidia0 libglx0-glvnd-nvidia libnvidia-eglcore
  libnvidia-glcore libnvidia-ml1 nvidia-alternative nvidia-driver
  nvidia-driver-bin nvidia-driver-libs nvidia-egl-common nvidia-egl-icd
  nvidia-installer-cleanup nvidia-kernel-common nvidia-kernel-dkms
  nvidia-kernel-support nvidia-legacy-check nvidia-modprobe nvidia-support
  nvidia-vdpau-driver update-glx xserver-xorg-video-nvidia
0 upgraded, 29 newly installed, 0 to remove and 8 not upgraded.
Need to get 29.7 MB of archives.
After this operation, 119 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

Thanks for your help with this
Vince

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

On Wed, Aug 22, 2018 at 11:04:19PM +0200, Andreas Beckmann wrote:
> On 2018-08-22 04:31, Vincent McIntyre wrote:
> > # apt-cache policy nvidia-driver
> > nvidia-driver:
> >   Installed: (none)
> >   Candidate: 384.130-1
> >   Version table:
> >  390.77-1~bpo9+1 200
> > 200 http://debian-archive.atnf.csiro.au:/debian 
> > stretch-backports/non-free amd64 Packages
> >  384.130-1 990
> > 990 http://debian-archive.atnf.csiro.au:/debian 
> > stretch/non-free amd64 Packages
> 
> We have had this before ... having both stretch and stretch-backports
> enabled and trying to track stretch does not work currently for the
> nvidia driver ... too many changes w.r.t. libglvnd etc.


Thanks Andreas

I disabled the backports package source and - voila.

# apt-get install nvidia-driver
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl-nvidia0
  libegl1-glvnd-nvidia libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
  libglvnd0-nvidia libglx-nvidia0 libglx0-glvnd-nvidia libnvidia-eglcore
  libnvidia-glcore libnvidia-ml1 nvidia-alternative nvidia-driver-bin
  nvidia-driver-libs nvidia-egl-common nvidia-egl-icd nvidia-installer-cleanup
  nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-support
  nvidia-legacy-check nvidia-modprobe nvidia-support nvidia-vdpau-driver
  update-glx xserver-xorg-video-nvidia
Recommended packages:
  nvidia-settings nvidia-persistenced nvidia-driver-libs-i386 libopengl0
  | libopengl0-glvnd-nvidia libgles-nvidia1 libgles-nvidia2 libnvidia-cfg1
  nvidia-egl-wayland-icd nvidia-vulkan-icd
The following NEW packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl-nvidia0
  libegl1-glvnd-nvidia libgl1-glvnd-nvidia-glx libgl1-nvidia-glvnd-glx
  libglvnd0-nvidia libglx-nvidia0 libglx0-glvnd-nvidia libnvidia-eglcore
  libnvidia-glcore libnvidia-ml1 nvidia-alternative nvidia-driver
  nvidia-driver-bin nvidia-driver-libs nvidia-egl-common nvidia-egl-icd
  nvidia-installer-cleanup nvidia-kernel-common nvidia-kernel-dkms
  nvidia-kernel-support nvidia-legacy-check nvidia-modprobe nvidia-support
  nvidia-vdpau-driver update-glx xserver-xorg-video-nvidia
0 upgraded, 29 newly installed, 0 to remove and 7 not upgraded.
Need to get 29.7 MB of archives.
After this operation, 119 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

Turn backports on again and it also works if I specify backports

# apt-get -t stretch-backports install nvidia-driver
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libdrm-common
  libdrm2 libegl-nvidia0 libegl1 libegl1-mesa libgl1 libgl1-mesa-glx
  libgl1-nvidia-glvnd-glx libglapi-mesa libgles2 libgles2-mesa libglvnd0
  libglx-mesa0 libglx-nvidia0 libglx0 libnvidia-eglcore libnvidia-glcore
  libnvidia-ml1 libwayland-egl1-mesa nvidia-alternative nvidia-driver-bin
  nvidia-driver-libs nvidia-egl-common nvidia-egl-icd nvidia-installer-cleanup
  nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-support
  nvidia-legacy-check nvidia-modprobe nvidia-support nvidia-vdpau-driver
  update-glx xserver-xorg-video-nvidia
Recommended packages:
  nvidia-settings nvidia-persistenced nvidia-driver-libs-i386 libopengl0
  | libopengl0-glvnd-nvidia libgles-nvidia2 libnvidia-cfg1
  nvidia-egl-wayland-icd nvidia-vulkan-icd
The following NEW packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libdrm-common
  libegl-nvidia0 libegl1 libgl1 libgl1-nvidia-glvnd-glx libgles2 libglvnd0
  libglx-mesa0 libglx-nvidia0 libglx0 libnvidia-eglcore libnvidia-glcore
  libnvidia-ml1 nvidia-alternative nvidia-driver nvidia-driver-bin
  nvidia-driver-libs nvidia-egl-common nvidia-egl-icd nvidia-installer-cleanup
  nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-support
  nvidia-legacy-check nvidia-modprobe nvidia-support nvidia-vdpau-driver
  update-glx xserver-xorg-video-nvidia
The following packages will be upgraded:
  libdrm2 libegl1-mesa libgl1-mesa-glx libglapi-mesa libgles2-mesa
  libwayland-egl1-mesa
6 upgraded, 32 newly installed, 0 to remove and 113 not upgraded.
Need to get 30.2 MB of archives.
After this operation, 117 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.

The diff of the installed packages is like so:
--- stable.sort 2018-08-23 09:02:51.880118125 +1000
+++ backports.sort  2018-08-23 09:02:51.880118125 +1000
@@ -1,16 +1,25 @@
 glx-alternative-mesa
 glx-alternative-nvidia
 glx-diversions
-libegl1-glvnd-nvidia
+libdrm2
+libdrm-common
+libegl1
+libegl1-mesa
 libe

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

On Wed, Aug 22, 2018 at 11:09:51AM +0100, Luca Boccassi wrote:
> Control: tags -1 moreinfo
> 

I tried to dig deeper into the source of the conflict.
The crude script below tries to pull out any conflicts
that the recursive dependencies of nvidia-egl-icd have
and looks for overlap with the dependencies of vlc.
It suggests that some variant of libegl1 is the issue,
but it's unclear why.
The results it gives are confused by apt-cache displaying
both the backports and stable versions of each package.

The other clue I have to offer is that a simulated install of
nvidia-egl-icd removes vlc and vlc-plugin-video-output, so I
assume some dependency of the latter is the cause.
It wants libegl1-mesa | libegl1-x11. libegl1-mesa is installed,
libegl1-x11 is a virtual package which libegl1-mesa Provides:.

#!/bin/sh

TMPDIR=`mktemp -d /tmp/XX`
CONF="$TMPDIR/conflicts"
DEPS="$TMPDIR/dependencie"

# nvidia-egl-icd conflicts list
apt-rdepends nvidia-egl-icd | grep -v '^ ' | \
( while read p
  do
  [ "X" = "X$p" ] && continue;
  apt-cache show $p | grep '^Conflicts:' | sed -e 's/Conflicts://' | \
 awk -F, '{for (i=1;i<=NF;i++){print $i;};}'
  done
) | sort | uniq > "$CONF"

# vlc dependency list
apt-rdepends vlc | grep -v '^ ' | \
( while read p
  do
  [ "X" = "X$p" ] && continue;
  apt-cache show $p | grep '^Depends:' | sed -e 's/Depends://' | \
 awk -F, '{for (i=1;i<=NF;i++){print $i;};}'
  done
) | sort | uniq > "$DEPS"

while read pkg ver
do
grep -w "$pkg" "$DEPS"
done < "$CONF"

rm -rf "$TMPDIR"

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

> 
> Are you sure? Your first email showed the priority of one pkg as "990"
> rather than the default 500

I agree it is strange but apt-cache priority scores
never make any sense to me.

$ /bin/ls /etc/apt/preferences.d/
backports

I tried the obvious experiment
$ cat /etc/apt/preferences.d/stable
Package: *
Pin: release a=stretch
Pin-Priority: 500

$ apt-cache policy nvidia-driver
nvidia-driver:
  Installed: (none)
  Candidate: 384.130-1
  Version table:
 390.77-1~bpo9+1 200
200 http://debian-archive.atnf.csiro.au:/debian 
stretch-backports/non-free amd64 Packages
 384.130-1 990
990 http://debian-archive.atnf.csiro.au:/debian stretch/non-free 
amd64 Packages


So you see why I don't spend much time trying to understand
prority scores.


Perhaps something in apt.conf is causing the score to come out higher?

$ grep -v '^#' /etc/apt/apt.conf
APT::Default-Release "stretch";
APT::Cache-Limit "5250";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::Clean-Installed "false";
Acquire::Pdiffs "false"; 
Periodic::Update-Package-Lists "false";
Aptitude::Install-Recommends "false";
Aptitude::Install-Suggests "false";
Aptitude::Keep-Recommends "true";
Aptitude::Keep-Suggests "true";
Aptitude::Delete-Unused "false";
Aptitude::Remove-Unused "false";
Aptitude::Show-Deps "true";
Aptitude::Show-Size-Changes "true";
Aptitude::Verbose 0;
Aptitude::Recommends-Important "false";
Aptitude::Suggests-Important "false";

Vince

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

On Wed, Aug 22, 2018 at 11:09:51AM +0100, Luca Boccassi wrote:
> Control: tags -1 moreinfo
> 
> 
> Hi,
> 
> From your logs, it seems you have a non-standard /etc/apt/preferences*
> files. Can you please share them?

# cat /etc/apt/preferences.d/backports 
Explanation: Low priority to avoid installation unless explicitly required
Package: *
Pin: release a=stretch-backports
Pin-Priority: 200

This is the only one I have in place.

Thanks
Vince
-- 

Bug#906904: nvidia-driver: No tty display after nvidia-modeset

[Vincent McIntyre]

Package: nvidia-driver
Version: 384.130-1
Severity: important

   * What led up to the situation?

   # apt-get install nvidia-driver nvidia-egl-icd

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

 Rebooted system after driver installation, with the 'quiet' option
 removed from tbe kernel boot line

   * What was the outcome of this action?

 The system boots but the console stops displaying anything after:

 [2.206678] nvidia-nvlink: Nvlink Core is being initialized, major 
device numbe
r 246
[2.207214] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,
decodes=none:owns=io+mem
[2.207472] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  384.130  
Wed Mar 21
 03:37:26 PDT 2018 (using threaded interrupts)
[2.216896] nvidia-modeset: Loading NVIDIA Kernel Mode Setting 
Driver for UNIX platforms  384.130  Wed Mar 21 02:59:49 PDT 2018

   * What outcome did you expect instead?

   The system to display progress throughout the boot and then
   show a login prompt on /dev/tty1 (and tty2-6 as well)

   getty is running and trying to solicit input.
   The systemd default target is set to multi-user.target, not graphical.target.
   The system works fine with the nouveau drivers.
   The problem is the nvidia driver.

   * What do you want the maintainer to do?

   Get the driver to support the text console mode for this hardware,
   or provide an explanation as to why it won't work.

-- Package-specific info:
uname -a:
Linux mayhem 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u3 (2018-08-19) x86_64 
GNU/Linux

/proc/version:
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u3 (2018-08-19)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  384.130  Wed Mar 21 03:37:26 
PDT 2018
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:1912] (rev 06) (prog-if 00 [VGA controller])
Subsystem: Dell HD Graphics 530 [1028:06b9]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 
745] [10de:1382] (rev a2) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation GM107 [GeForce GTX 745] [10de:1065]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.00] Console: colour VGA+ 80x25
[0.255516] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=none,locks=none
[0.255641] vgaarb: setting as boot device: PCI::01:00.0
[0.255751] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.255873] vgaarb: loaded
[0.255979] vgaarb: bridge control possible :01:00.0
[0.256088] vgaarb: no bridge control possible :00:02.0
[0.550233] Linux agpgart interface v0.103
[2.197984] nvidia: loading out-of-tree module taints kernel.
[2.198099] nvidia: module license 'NVIDIA' taints kernel.
[2.206678] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 246
[2.207214] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[2.207472] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  384.130  Wed Mar 
21 03:37:26 PDT 2018 (using threaded interrupts)
[2.216896] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  384.130  Wed Mar 21 02:59:49 PDT 2018
[2.239918] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver
[2.335374] [drm] Replacing VGA console driver
[2.366606] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[3.063823] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[3.065532] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13

Device node permissions:
crw-rw 1 root video 226,   0 Aug 22 12:03 /dev/dri/card0
crw-rw 1 root video 226,   1 Aug 22 12:03 /dev/dri/card1
crw-rw 1 root video 226,  64 Aug 22 12:03 /dev/dri/controlD64
crw-rw 1 root video 226, 128 Aug 22 12:03 /dev/dri/renderD128
crw-rw 1 root video 226, 129 Aug 22 12:03 /dev/dri/renderD129
video:x:44:

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Aug 22 12:02 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Aug 22 12:02 

Bug#906903: nvidia-driver: broken(?) dependencies

[Vincent McIntyre]

Package: nvidia-driver
Version: 384.130-1 990
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   I had a working stretch system using nouveau.
   I wanted to try the nvidia drivers, since I had used them in jessie,
   on the same hardware.

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

# apt-cache policy nvidia-driver
nvidia-driver:
  Installed: (none)
  Candidate: 384.130-1
  Version table:
 390.77-1~bpo9+1 200
200 http://debian-archive.atnf.csiro.au:/debian 
stretch-backports/non-free amd64 Packages
 384.130-1 990
990 http://debian-archive.atnf.csiro.au:/debian 
stretch/non-free amd64 Packages

   # apt-get install nvidia-driver

   * What was the outcome of this action?

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:
 nvidia-driver : Depends: nvidia-driver-libs (= 384.130-1) but it is 
not going to be installed or
  
nvidia-driver-libs-nonglvnd (= 384.130-1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

   * What outcome did you expect instead?

   I expected the driver stack to be installed

   * Things I tried

# apt-get install nvidia-driver-libs
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:
 nvidia-driver-libs : Depends: nvidia-egl-icd (= 384.130-1) but it is 
not going to be installed
E: Unable to correct problems, you have held broken packages.

# apt-mark showhold |wc
  0   0   0

# apt-get install nvidia-driver-libs-nonglvnd
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer 
required:
  dkms
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  glx-alternative-nvidia glx-diversions libegl-nvidia0 libegl1-nvidia 
libgl1-nvidia-glx libnvidia-eglcore libnvidia-glcore
  nvidia-alternative nvidia-support
Suggested packages:
  nvidia-driver nvidia-kernel-dkms | nvidia-kernel-source
Recommended packages:
  nvidia-kernel-dkms | nvidia-kernel-384.130 
nvidia-driver-libs-nonglvnd-i386 libglx-nvidia0 libgles-nvidia1 libgles-nvidia2
  libnvidia-cfg1 nvidia-egl-wayland-icd nvidia-nonglvnd-vulkan-icd
The following NEW packages will be installed:
  glx-alternative-nvidia glx-diversions libegl-nvidia0 libegl1-nvidia 
libgl1-nvidia-glx libnvidia-eglcore libnvidia-glcore
  nvidia-alternative nvidia-driver-libs-nonglvnd nvidia-support
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
Need to get 961 kB/14.8 MB of archives.
After this operation, 63.3 MB of additional disk space will be used.
^C

I have no idea what nvidia-driver-libs-nonglvnd is
(how would I find out if I should be selecting it?),
and bug 887063 has a comment
   (nvidia-driver-libs-nonglvnd is still buggy there ...)
So I tried another option

# apt-get install nvidia-driver nvidia-egl-icd
[sudo] password for mci156: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  liba52-0.7.4 libaa1 libass5 libavc1394-0 libbasicusageenvironment1 
libcaca0
  libdc1394-22 libdca0 libdvbpsi10 libdvdnav4 libdvdread4 libebml4v5
  libglapi-mesa libgles2-mesa libgroupsock8 libkate1 liblivemedia57 
liblua5.2-0
  libmad0 libmatroska6v5 libmicrodns0 libmpcdec6 libmpeg2-4 libnfs8
  libopenmpt-modplug1 libpostproc54 libprotobuf-lite10 libqt5x11extras5
  libraw1394-11 libresid-builder0c2a libsdl-image1.2 libsdl1.2debian
  

Bug#580312: multipath-tools: multipathd segfaults when restarted

[Vincent McIntyre]

On Sat, Aug 11, 2018 at 05:09:58PM +0200, Chris Hofstaedtler wrote:
> 
> Do you still see this in current versions?

No, have not seen this occur again like this that I can recall;
we would have followed up to this bug if we had.
 
I think this bug can probably be closed, the code has improved
enormously since this occurred and nobody else seems to have hit it.

Kind regards
Vince

Bug#902565: autofs not migrated to salsa.d.o(?)

[Vincent McIntyre]

Package: autofs
Severity: normal

I was trying to find the autofs source on salsa and was unable to
after a fair bit of rummaging around.

The old alioth repo is archived at [1].
Is it possible to migrate it to salsa, from that tar ball?

Kind regards
Vince

[1] https://alioth-archive.debian.org/git/collab-maint/autofs.git.tar.xz

Bug#799781: ping

[Vincent McIntyre]

Hi

just checking why this was still open -
I see that the jessie tree now contains the patch
'libmultipath: use a shared lock to co-operate with udev'
and is tagged 0.5.0-6+deb8u3.
But it seems to have missed the 8.10 point release,
and is not lurking in jessie-proposed-updates;
0.5.0-6+deb8u2 is the latest available for jessie.

Does something need a nudge?
AFAICT this would close #799781 and #843953

Cheers
Vince
-- 

Bug#826570: possible fix

[Vincent McIntyre]

There is a possible resolution here
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=02628413ca99648e70e38406384be69e20a2a6ce

which just takes out a workaround for a now-resolved bug.

I have not tested this as I have only ever seen this issue on one host,
quite some time ago.

Vince

Bug#884423: web interface to git repo not working

[Vincent McIntyre]

Package: cron
Severity: minor

Problem statement:

If I follow one of the links in the web interface to the git repo,
e.g.
https://anonscm.debian.org/gitweb/?p=pkg-cron/pkg-cron.git;a=commit;h=3a0e758b85d03dd2e8fca02d95f67dce1dcbc47f

I get this error

Bad object id:

and the URL displayed in the browser is
https://anonscm.debian.org/cgit/pkg-cron/pkg-cron.git/commit/?id=


I am not sure if this a problem for the pkg-cron team or the alioth
maintainers, so I thought I would start here.

Cloning the repository from the https url
https://alioth.debian.org/anonscm/git/pkg-cron/pkg-cron.git
works fine and has this as the most recent commit:

commit 77fdd0b00e1568c2a6041832951dbaff1b842c0c
Author: Jakub Wilk 
Date:   Mon Aug 29 04:52:32 2016

cron.8: Fix typo "have to be pass"

Closes: #819832
.

Regards
Vince

Bug#882766: Proposal: reinstate automated device selection, blacklisting d-i?

[Vincent McIntyre]

It would be good to make this change.

Is there some reason to not include a build stamp in the installer
initrd at, say, /build-stamp? This would be the same string as in
boot-screens/f1.txt (e.g. 20170615+deb9u2).

Regards
-- 

Bug#879792: nvidia-detect: misses nvidia tesla p100 (GP100GL)

[Vincent McIntyre]

On Thu, Oct 26, 2017 at 11:47:00AM +0100, Luca Boccassi wrote:
>
> Hi,
>
> Is the Tesla series compatible with the Geforce series drivers that we
> package?
>
> They are sorted separately on Nvidia's website at least:
>
> http://www.nvidia.co.uk/download/driverResults.aspx/124885/en-uk
>
> But I've never used them so I'm not sure.
>

I'm a bit confused by this question. My understanding is that
nvidia-detect looks up the card PCI ID in the various
/usr/share/nvidia/*.ids files and reports a positive match.

Are you saying those files may contain IDs that aren't supported
by the drivers? How are those files maintained? I poked around
the repository briefly and it seems it's mostly manual edits,
which seems fine apart from the risk of the odd typo.

In this case the drivers you package (thank you!) do support the card,
so the *.ids files seem to have the correct information.

 $ dmesg|tail |sed -e 's/^[^ ]*//'
 nvidia: loading out-of-tree module taints kernel.
 nvidia: module license 'NVIDIA' taints kernel.
 Disabling lock debugging due to kernel taint
 nvidia-nvlink: Nvlink Core is being initialized, major device number 243
 NVRM: loading NVIDIA UNIX x86_64 Kernel Module  375.82  Wed Jul 19 21:16:49 
PDT 2017 (using threaded interrupts

 $ nvidia-smi
 Fri Oct 27 09:24:05 2017
 +-+
 | NVIDIA-SMI 375.82 Driver Version: 375.82|
 |---+--+--+
 | GPU  NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC |
 | Fan  Temp  Perf  Pwr:Usage/Cap| Memory-Usage | GPU-Util  Compute M. |
 |===+==+==|
 |   0  Tesla P100-PCIE...  Off  | :04:00.0 Off |0 |
 | N/A   31CP026W / 250W |  0MiB / 16276MiB |  0%  Default |
 +---+--+--+
 |   1  Tesla P100-PCIE...  Off  | :82:00.0 Off |0 |
 | N/A   33CP027W / 250W |  0MiB / 16276MiB |  2%  Default |
 +---+--+--+

 +-+
 | Processes:   GPU Memory |
 |  GPU   PID  Type  Process name   Usage  |
 |=|
 |  No running processes found |
 +-+

Cheers
Vince

Bug#879792: nvidia-detect: misses nvidia tesla p100 (GP100GL)

[Vincent McIntyre]

Package: nvidia-detect
Version: 375.82-6
Severity: normal
Tags: patch
thanks

Also found in
375.82-1~deb9u1
375.82-4~bpo9+1
384.90-1

I have a system with a nvidia tesla p100 GPU:
# lspci -v -s 04:00

04:00.0 3D controller: NVIDIA Corporation GP100GL (rev a1)
Subsystem: NVIDIA Corporation GP100GL
Flags: fast devsel, IRQ 113, NUMA node 0
Memory at 9100 (32-bit, non-prefetchable) [size=16M]
Memory at 3b8 (64-bit, prefetchable) [size=16G]
Memory at 3bc (64-bit, prefetchable) [size=32M]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [250] Latency Tolerance Reporting
Capabilities: [258] L1 PM Substates
Capabilities: [128] Power Budgeting 
Capabilities: [420] Advanced Error Reporting
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 

Capabilities: [900] #19
Kernel modules: nouveau

# lspci -n -s 04:00
04:00.0 0302: 10de:15f8 (rev a1)

The nvidia-detect script does not detect there is support for this
unless I supply the PCI ID, which is inconvenient for automation.

# nvidia-detect
No NVIDIA GPU detected.

# nvidia-detect 10de:15f8
Checking driver support for PCI ID [10de:15f8]
Your card is supported by the default drivers.
It is recommended to install the
nvidia-driver
package.

The fix looks straightforward, allow the processing of lspci -mn to
match the appropriate device class:

# diff -u /usr/bin/nvidia-detect{,.new}
--- /usr/bin/nvidia-detect  2017-10-26 08:43:02.568875942 +0800
+++ /usr/bin/nvidia-detect.new  2017-10-26 08:42:42.792830644 +0800
@@ -215,7 +215,7 @@
exit 1
fi

-   NV_DEVICES=$(lspci -mn | awk '{ gsub("\"",""); if ($2 == "0300" && ($3 
== "10de" || $3 == "12d2")) { print $1 } }')
+   NV_DEVICES=$(lspci -mn | sed -e's/"//g'| awk '$2 ~ /^030[0-2]$/{ if ( 
($3 == "10de" || $3 == "12d2")) { print $1 } }')

if [ -z "$NV_DEVICES" ]; then
echo "No NVIDIA GPU detected."

#  /usr/bin/nvidia-detect.new
Detected NVIDIA GPUs:
04:00.0 3D controller [0302]: NVIDIA Corporation GP100GL [10de:15f8] (rev a1)
82:00.0 3D controller [0302]: NVIDIA Corporation GP100GL [10de:15f8] (rev a1)

Checking card:  NVIDIA Corporation GP100GL (rev a1)
Your card is supported by the default drivers.
It is recommended to install the
nvidia-driver
package.

Checking card:  NVIDIA Corporation GP100GL (rev a1)
Your card is supported by the default drivers.
It is recommended to install the
nvidia-driver
package.



The bit I am unsure about is which classes should be matched.
https://pci-ids.ucw.cz/read/PD/03 lists these subclasses:
  00VGA compatible controller   
  01XGA compatible controller   
  023D controller   
  80Display controller

So I think my suggested change is ok but there may be other considerations
I am not aware of.

Comments?

Kind regards
Vince


-- Package-specific info:
uname -a:
Linux testbox 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux

/proc/version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)

lspci 'VGA compatible controller [0300]':
0a:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. 
G200eR2 [102b:0534] (rev 01) (prog-if 00 [VGA controller])
Subsystem: Dell G200eR2 [1028:0600]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: mgag200
Kernel modules: mgag200

dmesg:

Device node permissions:
crw-rw 1 root video 226,  0 Oct 25 11:36 /dev/dri/card0
crw-rw 1 root video 226, 64 Oct 25 11:36 /dev/dri/controlD64
video:x:44:

OpenGL and NVIDIA library files installed:

/etc/modprobe.d:
total 12
drwxr-xr-x  2 root root 4096 Oct 25 12:19 .
drwxr-xr-x 95 root root 4096 Oct 26 08:40 ..


/etc/modules-load.d:
-rw-r--r-- 1 root root  195 Oct 25 11:20 /etc/modules

/etc/modules-load.d/:
total 8
drwxr-xr-x  2 root root 4096 Oct 25 11:20 .
drwxr-xr-x 95 root root 4096 Oct 26 08:40 ..
lrwxrwxrwx  1 root root   10 Jul  6 04:31 modules.conf -> ../modules


Files from nvidia-installer:

Config and logfiles:

<< Xorg (journald) >>
^^ Xorg (journald) ^^

Kernel modules: nvidia.ko


lsmod:
Module  Size  Used by
mpt3sas   217088  1
raid_class 16384  1 mpt3sas
scsi_transport_sas 45056  1 mpt3sas
mptctl 36864  1
mptbase77824  1 mptctl
dell_rbu   16384  0
ipmi_devintf   20480  2
intel_rapl 20480  0
sb_edac24576  0
edac_core

Bug#676472: cups: please suggest a compatible inet server (for lpd support)

[Vincent McIntyre]

> As of 2017, I tend to think that lpd support should disappear for Buster. Iff 
> we'd want to keep it, having cups-bsd get a 
>   Suggests: inetutils-inetd | inet-superserver, update-inetd
> _could_ make sense.
> 
> I'm not going to investigate more than that; so if someone wants that in 
> 2017's CUPS, please answer to this bug by saying so and confirming the above 
> strategy makes sense.
> 

Thanks for revisiting this old bug.
We definitely have a use-case for lpd support, so
please count my reply as being in favour of your strategy.

Kind regards
Vince

Bug#872890: [patch] initialise loop variable in rescan-scsi-bus.sh

[Vincent McIntyre]

Package: sg3-utils
Version: 1.42-2
Severity: normal
Tags: patch

thanks

Using rescan-scsi-bus.sh is scary enough at the best of times,
but when it prints things like this it's even scarier

  /usr/bin/rescan-scsi-bus.sh: line 257: test: !=: unary operator expected

That line reads
257   if test $ctr != 0; then white_out; fi

and comes right after a loop with this loop condition
245   while test $RC = 2 -o $RC = 6 && test $ctr -le 30; do

In the enclosing function (testonline), nothing initialises $ctr ;
it is only updated within the loop
248 let ctr+=1

Given this situation, the loop condition at line 245 always fails
(on the second test) and the code jumps to line 257, where $ctr
is still not defined.

This patch initialises $ctr and appears to make the code run as
intended. The only question is whether 0 is the right starting value.

diff --git a/scripts/rescan-scsi-bus.sh b/scripts/rescan-scsi-bus.sh
index e45caf3..fa8c1ae 100755
--- a/scripts/rescan-scsi-bus.sh
+++ b/scripts/rescan-scsi-bus.sh
@@ -242,6 +242,7 @@ testonline ()
   RC=$?
 
   # Handle in progress of becoming ready and unit attention
+  local ctr=0
   while test $RC = 2 -o $RC = 6 && test $ctr -le 30; do
 if test $RC = 2 -a "$RMB" != "1"; then echo -n "."; let LN+=1; sleep 1
 else sleep 0.02; fi

Kind regards
Vince

Bug#872524: git-buildpackage: documenting import from upstream git

[Vincent McIntyre]

Package: git-buildpackage
Version: 0.8.18
Severity: minor
Tags: patch

thanks

Hi,
I was looking in the manual for information on starting from scratch
with an upstream git and found it a little terse for newbies like me.
Please would you consider applying the attached patches.
The published version [1] was tagged 0.9.0~exp3 but the text
is the same in the sid version.

I was not quite sure what to say about the --no-checkout argument;
something like this seems appropriate

   The debian/sid branch will start
   empty. Over time only debian packaging changes will be added here,
   usually just the debian/ directory.

but I may be misunderstanding.

I also have a related question. The upstream repository has no tags;
what should one tell gpb to do in this case?
One can invent versions like 0~yymmdd [2] and apply such tags
locally but that doesn't seem quite right.


Kind regards
Vince

[1] 
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT
[2] https://www.debian.org/doc/manuals/maint-guide/first.en.html#namever
>From 5fedfb4801933d80bbef804106971d288ea17169 Mon Sep 17 00:00:00 2001
From: mci156 
Date: Fri, 18 Aug 2017 15:46:12 +1000
Subject: [PATCH 1/2] Add paragraph break

---
 docs/chapters/import.sgml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/docs/chapters/import.sgml b/docs/chapters/import.sgml
index d45522d..f8432e3 100644
--- a/docs/chapters/import.sgml
+++ b/docs/chapters/import.sgml
@@ -338,7 +338,10 @@ upstream-tag = v%(version%.%_)s
 
 	  The above makes sure we have debian/sid for the  packaging. We didn't create
 	  any upstream/* branches; they're not needed for the packaging and only need to be
-	  kept up to date. After adding the  packaging, we build the package. This assumes you're using 
+	  kept up to date.
+  
+
+  After adding the  packaging, we build the package. This assumes you're using 
 	  and upstream uses a version number format as described above:
 
   gbp buildpackage --git-pristine-tar --git-pristine-tar-commit --git-upstream-tag='v%(version)s' --git-debian-branch=debian/sid
-- 
2.1.4

>From 7bc2c824164c6953956269822d6ee7c9b718bde2 Mon Sep 17 00:00:00 2001
From: mci156 
Date: Fri, 18 Aug 2017 15:58:54 +1000
Subject: [PATCH 2/2] Explain the v1.0 

---
 docs/chapters/import.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/chapters/import.sgml b/docs/chapters/import.sgml
index f8432e3..2e9c97f 100644
--- a/docs/chapters/import.sgml
+++ b/docs/chapters/import.sgml
@@ -338,7 +338,7 @@ upstream-tag = v%(version%.%_)s
 
 	  The above makes sure we have debian/sid for the  packaging. We didn't create
 	  any upstream/* branches; they're not needed for the packaging and only need to be
-	  kept up to date.
+	  kept up to date. We started the branch at the commit corresponding to the tag v1.0.
   
 
   After adding the  packaging, we build the package. This assumes you're using 
-- 
2.1.4

Bug#870574: lowmem: naming of main-menu.d item

[Vincent McIntyre]

Package: lowmem
Version: 1.45
Severity: normal

Poking around an install environment I looked in /lib/main-menu.d
and found these files:
10rescue
5lowmem

Then I found the original commit message:

commit b9741a97a349f9ed4364b3411c3ab8afc590e385
Author: Joey Hess 
Date:   Fri May 6 01:30:00 2005

- Set a "low memory mode" info message (rescue mode comes after and
  beats this message). Requires cdebconf-udeb 0.75 and main-menu 1.03.

So the file lowmem/main-menu.d/5lowmem
should be   lowmem/main-menu.d/05lowmem

should it not?

Vince

Bug#870448: hw-detect - stop using modprobe -l

[Vincent McIntyre]

On Wed, Aug 02, 2017 at 07:58:05PM +0100, Ben Hutchings wrote:
> 
> But this still prints error messages for missing modules.  I think the
> function should be implemented as:
> 
> is_available () {
>   modprobe -qn "$1"
> }
> 

I agreee, much better!

Bug#870448: hw-detect - stop using modprobe -l

[Vincent McIntyre]

Package: hw-detect
Version: 1.124
Severity: normal
Tags: patch

I keep seeing this in installer logs, back to jessie.

Aug  2 01:52:11 main-menu[193]: (process:224): modprobe: invalid option -- 'l'


I rated this normal rather than minor because the way it is working
now the is_available() function always returns 1 (failure)

My suggestion is to use modinfo instead.
This will return multiline output inside the quotes but
a couple of tests suggests that is ok.
It does fail with some modules (nvidia), not sure if we care.

diff --git a/hw-detect.sh b/hw-detect.sh
index 7977814..d8196c1 100755
--- a/hw-detect.sh
+++ b/hw-detect.sh
@@ -43,7 +43,7 @@ is_not_loaded() {
 }
 
 is_available () {
-   [ "$(modprobe -l $1)" ] || return 1
+   [ "$(modinfo $1)" ] || return 1
 }
 
 # Module as first parameter, description of device the second.

Kind regards
Vince

Bug#759553: suggested patch

[Vincent McIntyre]

Tags: patch
Thanks


Can this be fixed please? I wasted an hour tracking this down
while trying to resolve another issue.


--- lib/auto-lvm.sh.org 2017-08-02 10:24:35.773321165 +1000
+++ lib/auto-lvm.sh 2017-08-02 10:24:49.709392154 +1000
@@ -302,7 +302,7 @@
defvgname="$RET"
 
# Check that the volume group name is not in use
-   if ! vg_get_info "$defvgname" && ! stat "/dev/$defvgname"; then
+   if ! vg_get_info "$defvgname" && [ ! -e "/dev/$defvgname" ]; 
then
break
fi
noninteractive="bail_out vg_exists"

Kind regards
Vince

Bug#820983: ok to close

[Vincent McIntyre]

this bug can be closed since the omission was addressed not long after.

samba (2:4.2.10+dfsg-0+deb8u3) jessie-security; urgency=high

...

  [ Andrew Bartlett ]
  * Add back better NEWS item for 2:4.2.10+dfsg-0+deb8u1

...

 -- Salvatore Bonaccorso   Wed, 01 Jun 2016 17:05:31 +0200

I verified this on verison 2:4.2.14+dfsg-0+deb8u7
thanks Andrew and Salvatore

Vince

Bug#866179: patch

[Vincent McIntyre]

Tags: patch
thanks

A bit of trawling turned up the d-d-a posts and the wiki pages.
Please consider this for inclusion.

Index: whats-new.dbk
===
--- whats-new.dbk   (revision 11691)
+++ whats-new.dbk   (working copy)
@@ -432,6 +432,19 @@
 
 
 
+
+  GCC versions
+
+  
+Debian stretch includes only version 6 of the GNU GCC compiler,
+which may impact users expecting version 4.x or 5.x to be available.
+See the https://wiki.debian.org/GCC5;>GCC5 and
+https://wiki.debian.org/GCC6;>GCC6 wiki pages
+for more information about the transition.
+  
+
+
+
 
   MariaDB replaces MySQL
   

Bug#866179: [stretch] old versions of gcc not available

[Vincent McIntyre]

Package: release-notes
Severity: wishlist

Hi

it appears that, in contrast to previous releases, stretch does not
come with the gcc available in the previous release. I think this
should be noted in the release notes along with a pointer to any
discussion about the reason for this.

Can anyone help with the pointer? I am happy to draft a patch.

Kind regards
Vince

Bug#864857: [patch] avoid blhc warning about -fPIE

[Vincent McIntyre]

Package: autofs
Severity: wishlist
Version: 5.1.2-2
Tags: patch

thanks

Not sure this one is needed, use it or not as you please.

Signed-off-by: mci156 <vincent.mcint...@csiro.au>
---
 debian/patches/hardening-flags.patch | 20 
 debian/patches/series|  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 debian/patches/hardening-flags.patch

diff --git a/debian/patches/hardening-flags.patch 
b/debian/patches/hardening-flags.patch
new file mode 100644
index 000..f6e2350
--- /dev/null
+++ b/debian/patches/hardening-flags.patch
@@ -0,0 +1,20 @@
+Last Updated: 2017-06-16
+Author: Vincent McIntyre <vincent.mcint...@csiro.au>
+Forwarded: no
+Description: Avoid warning about -fPIE from blhc
+
+This is probably not entirely necessary since all modules are
+compiled with -fPIE, but it avoids a warning.
+Index: autofs-5.1.2/daemon/Makefile
+===
+--- autofs-5.1.2.orig/daemon/Makefile
 autofs-5.1.2/daemon/Makefile
+@@ -30,7 +30,7 @@ endif
+ all: automount
+ 
+ automount: $(OBJS) $(AUTOFS_LIB)
+-   $(CC) $(DAEMON_LDFLAGS) -o automount $(OBJS) $(LDFLAGS) $(AUTOFS_LIB) 
$(LIBS)
++   $(CC) $(DAEMON_CFLAGS) $(DAEMON_LDFLAGS) -o automount $(OBJS) 
$(LDFLAGS) $(AUTOFS_LIB) $(LIBS)
+$(STRIP) automount
+ 
+ clean:
diff --git a/debian/patches/series b/debian/patches/series
index 91208ef..e8163b9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+hardening-flags.patch
 11default_automaster_location.patch
 12disable_default_auto_master.patch
 15auto_net_nfs4.patch
-- 
2.1.4

Bug#864853: [patch] fix lintian warning about man/autofs.8

[Vincent McIntyre]

Package: autofs
Severity: wishlist
Version: 5.1.2-2
Tags: patch

thanks

This fixes the warning but the manpage heading now looks pretty ugly
thanks to the infelicitous line-
break

Perhaps removing the @@initdir@@@/ part of the line would be ok?


Signed-off-by: mci156 <vincent.mcint...@csiro.au>
---
 debian/patches/fix-whatis.patch | 18 ++
 debian/patches/series   |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 debian/patches/fix-whatis.patch

diff --git a/debian/patches/fix-whatis.patch b/debian/patches/fix-whatis.patch
new file mode 100644
index 000..386015d
--- /dev/null
+++ b/debian/patches/fix-whatis.patch
@@ -0,0 +1,18 @@
+Author: Vincent McIntyre <vincent.mcint...@csiro.au>
+Forwarded: no
+Description: Reinstate - separator in NAME section, to satisfy lintian
+
+Upstream presumably dropped reference to the init script
+because the page now describes both that and the systemd
+.service file.
+Index: autofs-5.1.2/man/autofs.8.in
+===
+--- autofs-5.1.2.orig/man/autofs.8.in
 autofs-5.1.2/man/autofs.8.in
+@@ -1,5 +1,6 @@
+ .TH AUTOFS 8 "9 Sep 1997"
+ .SH NAME
++@@initdir@@/autofs, autofs.service \-
+ Service control for the automounter
+ .SH SYNOPSIS
+ If a SysV init script system is being used:
diff --git a/debian/patches/series b/debian/patches/series
index 91208ef..6f6cf7a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+fix-whatis.patch
 11default_automaster_location.patch
 12disable_default_auto_master.patch
 15auto_net_nfs4.patch
-- 
2.1.4

Bug#864852: [patch] fix missing dependency on lsb-base

[Vincent McIntyre]

Package: autofs
Severity: normal
Version: 5.1.2-2
Tags: patch

thanks

Lintian marks this as an error, may as well fix it.

Signed-off-by: mci156 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9501d97..0bbca56 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,7 @@ VCS-Git: 
https://anonscm.debian.org/git/collab-maint/autofs.git
 Package: autofs
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, ucf
+Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, lsb-base (>=3.0-6)
 Provides: autofs5
 Breaks: autofs5 (<< 5.0.6-1~)
 Replaces: autofs5 (<< 5.0.6-1~)
-- 
2.1.4

Bug#864849: [patch] fix watch file

[Vincent McIntyre]

Package: autofs
Severity: normal
Version: 5.1.2
Tags: patch

thanks mate


This patch makes uscan do something useful again.

--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
 version=3
-ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5/autofs-(5[^-]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
+https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/refs/ 
.*tag/\?h=release_(\d)_(\d)_(\d)


% uscan --report --verbose --watchfile debian/watch
-- In debian/watch, processing watchfile line:
   https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/refs/ 
.*tag/\?h=release_(\d)_(\d)_(\d)
-- Found the following matching hrefs:
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_3 (5.1.3)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_2 (5.1.2)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_1 (5.1.1)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_0 (5.1.0)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_9 (5.0.9)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_8 (5.0.8)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_7 (5.0.7)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_6 (5.0.6)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_5 (5.0.5)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_4 (5.0.4)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_3 (5.0.3)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_2 (5.0.2)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_1 (5.0.1)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_1 (4.1.1)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_2 (4.1.2)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_3 (4.1.3)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_4 (4.1.4)
Newest version on remote site is 5.1.3, local version is 5.1.2
 => Newer version available from

https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_3

Kind regards
Vince

Bug#864476: [patch] lintian appeasement

[Vincent McIntyre]

Package: multipath-tools
Version: 0.6.4-5
Severity: wishlist
Tags: patch


This series quells some lintian warnings.
I hope it is helpful. If not, just wontfix.

Vincent McIntyre (4):
  Add more shlib-symlink overrides, following previous example
  Silence bogus warning about undefined macro
  Silence one of the linebreak warnings
  Fix lintian complaint about bad whatis entry

 debian/multipath-tools.lintian-overrides   | 3 +++
 libmpathpersist/mpath_persistent_reserve_in.3  | 2 +-
 libmpathpersist/mpath_persistent_reserve_out.3 | 2 +-
 multipath/multipath.conf.5 | 3 ++-
 multipathd/multipathd.8| 2 +-
 5 files changed, 8 insertions(+), 4 deletions(-)

-- 
>From 3c67a8e54baabbb4f689b24226d58cd0843627ab Mon Sep 17 00:00:00 2001
From: Vincent McIntyre <vincent.mcint...@csiro.au>
Date: Fri, 9 Jun 2017 16:41:18 +1000
Subject: [PATCH 1/4] Add more shlib-symlink overrides, following previous
 example

Signed-off-by: Vincent McIntyre <vincent.mcint...@csiro.au>
---
 debian/multipath-tools.lintian-overrides | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/multipath-tools.lintian-overrides b/debian/multipath-tools.lintian-overrides
index 5efa3c8..f2d35f9 100644
--- a/debian/multipath-tools.lintian-overrides
+++ b/debian/multipath-tools.lintian-overrides
@@ -6,4 +6,7 @@
 multipath-tools: no-symbols-control-file lib/libmpathpersist.so.0
 multipath-tools: no-symbols-control-file lib/libmultipath.so.0
 multipath-tools: non-dev-pkg-with-shlib-symlink lib/libmpathpersist.so.0 lib/libmpathpersist.so
+multipath-tools: non-dev-pkg-with-shlib-symlink lib/libmpathcmd.so.0 lib/libmpathcmd.so
+multipath-tools: non-dev-pkg-with-shlib-symlink lib/libmpath.so.0 lib/libmpath.so
+multipath-tools: non-dev-pkg-with-shlib-symlink lib/libmultipath.so.0 lib/libmultipath.so
 multipath-tools: package-name-doesnt-match-sonames libmpathpersist0 libmultipath0
-- 
2.1.4

>From 791c7886e9f543dec1db7eeb38dd27a965b46139 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre <vincent.mcint...@csiro.au>
Date: Fri, 9 Jun 2017 16:43:53 +1000
Subject: [PATCH 2/4] Silence bogus warning about undefined macro

Signed-off-by: Vincent McIntyre <vincent.mcint...@csiro.au>
---
 multipathd/multipathd.8 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/multipathd/multipathd.8 b/multipathd/multipathd.8
index 4c765af..cf90176 100644
--- a/multipathd/multipathd.8
+++ b/multipathd/multipathd.8
@@ -122,7 +122,7 @@ Show the current multipath topology. Same as '\fImultipath \-ll\fR'.
 .B list|show map|multipath $map topology
 Show topology of a single multipath device specified by $map, for example
 36005076303ffc56210aa. This map could be obtained from
-'\fIlist maps\fR'.
+ '\fIlist maps\fR'.
 .
 .TP
 .B list|show wildcards
-- 
2.1.4

>From 87679c75bbb68785e45fc680f80f9e21d4c18e49 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre <vincent.mcint...@csiro.au>
Date: Fri, 9 Jun 2017 16:45:08 +1000
Subject: [PATCH 3/4] Silence one of the linebreak warnings

Signed-off-by: Vincent McIntyre <vincent.mcint...@csiro.au>
---
 multipath/multipath.conf.5 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
index b7d7e59..04ff03d 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -869,7 +869,8 @@ The following keywords are recognized:
 Regular expression of the device nodes to be excluded.
 .RS
 .TP
-Default value is: \fB^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9]\fR, \fB^(td|hd|vd)[a-z]\fR and \fB^nvme\fR
+Default value is: \fB^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9]\fR,
+\fB^(td|hd|vd)[a-z]\fR and \fB^nvme\fR
 .RE
 .TP
 .B wwid
-- 
2.1.4

>From 7c6ea59bb0860cce3d2e4af38fc86edee71df251 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre <vincent.mcint...@csiro.au>
Date: Fri, 9 Jun 2017 16:47:45 +1000
Subject: [PATCH 4/4] Fix lintian complaint about bad whatis entry

Signed-off-by: Vincent McIntyre <vincent.mcint...@csiro.au>
---
 libmpathpersist/mpath_persistent_reserve_in.3  | 2 +-
 libmpathpersist/mpath_persistent_reserve_out.3 | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libmpathpersist/mpath_persistent_reserve_in.3 b/libmpathpersist/mpath_persistent_reserve_in.3
index 5ed0779..4691bde 100644
--- a/libmpathpersist/mpath_persistent_reserve_in.3
+++ b/libmpathpersist/mpath_persistent_reserve_in.3
@@ -12,7 +12,7 @@
 .SH NAME
 .\" 
 .
-mpath_persistent_reserve_in
+mpath_persistent_reserve_in \- send PRIN command to DM device
 .
 .
 .\" 
diff --git a/libmpathpersist/mpath_persistent_reserve_out.3 b/libmpathpersist/mpath_persistent_reserve_out.3
index e11eb57..55b00b0 100644
--- a/libmpathpersist/mpath_persistent_reserve_out.3
+++ b/libm

Bug#814363: update to uscan file

[Vincent McIntyre]

tags: patch
thanks mate

I noticed a new upstream version (0.7.1) so I thought I would try
to make uscan notice as well. This seems to work reliably:


--- debian/watch.orig   2017-06-06 16:48:45.205127553 +1000
+++ debian/watch2017-06-06 17:18:16.788922857 +1000
@@ -1,3 +1,4 @@
 # format version number, currently 3; this line is compulsory!
 version=3
-http://christophe.varoqui.free.fr/multipath-tools/multipath-tools-([\d\.]*)\.tar\.bz2
+http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=tags 
.*a=log;h=refs/tags/(\d[\d\.]*[^\s]*)
+

% uscan --report --verbose --watchfile debian/watch
-- In debian/watch, processing watchfile line:
   http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=tags 
.*a=log;h=refs/tags/(\d[\d\.]*)
-- Found the following matching hrefs:
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.7.1 (0.7.1)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.7.0 (0.7.0)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.6.4 (0.6.4)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.6.3 (0.6.3)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.6.2 (0.6.2)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.6.1 (0.6.1)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.6.0 (0.6.0)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.5.0 (0.5.0)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.9 (0.4.9)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.8 (0.4.8)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.7 (0.4.7)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.6 (0.4.6)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.5 (0.4.5)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.5-pre4 
(0.4.5-pre4)
 /gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.4.5-pre3 
(0.4.5-pre3)
Newest version on remote site is 0.7.1, local version is 0.6.4
 => Newer version available from

http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=log;h=refs/tags/0.7.1

Cheers
Vince

Bug#864192: multipath-tools: Typo in README.Debian

[Vincent McIntyre]

Source: multipath-tools
Version: Typo in README.Debian
Severity: minor

Bug 8217322 does not exist.

@@ -5,7 +5,7 @@
 I see a lot of "io_setup failed" message using the directio checker
 
 
-Debian Bug #8217322
+Debian Bug #827322
 
 The directio path checker makes use of the asynchronous I/O API (aio) provided
 by modern Linux systems. Asynchronous I/O allows an application to submit I/O


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

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

Bug#751993: upload?

[Vincent McIntyre]

Hi

there have been a couple of stable point releases (8.7,8.8) since
this and #799781 were tagged as pending, but they haven't made it in.
Could you check what's up please?

Vince

Bug#767946: updated patch

[Vincent McIntyre]

Tags: patch
Thanks

The attached version of lshw-common.patch avoids those warnings.
Kind regards
Vince
Added paths to look for device idsIndex: lshw-02.14/src/core/pci.cc
===
Index: lshw-02.18/lshw-B.02.18/src/core/pci.cc
===
--- lshw-02.18.orig/lshw-B.02.18/src/core/pci.cc
+++ lshw-02.18/lshw-B.02.18/src/core/pci.cc
@@ -18,7 +18,7 @@ __ID("@(#) $Id$");
 
 #define PROC_BUS_PCI "/proc/bus/pci"
 #define SYS_BUS_PCI "/sys/bus/pci"
-#define PCIID_PATH DATADIR"/pci.ids:/usr/share/lshw/pci.ids:/usr/local/share/pci.ids:/usr/share/pci.ids:/etc/pci.ids:/usr/share/hwdata/pci.ids:/usr/share/misc/pci.ids"
+#define PCIID_PATH DATADIR"/pci.ids:/usr/share/lshw-common/pci.ids:/usr/local/share/pci.ids:/usr/share/pci.ids:/etc/pci.ids:/usr/share/hwdata/pci.ids:/usr/share/misc/pci.ids"
 
 #define PCI_CLASS_REVISION  0x08  /* High 24 bits are class, low 8 revision */
 #define PCI_VENDOR_ID   0x00/* 16 bits */
Index: lshw-02.18/lshw-B.02.18/src/core/usb.cc
===
--- lshw-02.18.orig/lshw-B.02.18/src/core/usb.cc
+++ lshw-02.18/lshw-B.02.18/src/core/usb.cc
@@ -27,7 +27,7 @@
 
 #define PROCBUSUSBDEVICES "/proc/bus/usb/devices"
 #define SYSKERNELDEBUGUSBDEVICES "/sys/kernel/debug/usb/devices"
-#define USBID_PATH DATADIR"/usb.ids:/usr/share/lshw/usb.ids:/usr/local/share/usb.ids:/usr/share/usb.ids:/etc/usb.ids:/usr/share/hwdata/usb.ids:/usr/share/misc/usb.ids"
+#define USBID_PATH DATADIR"/usb.ids:/usr/share/lshw-common/usb.ids:/usr/local/share/usb.ids:/usr/share/usb.ids:/etc/usb.ids:/usr/share/hwdata/usb.ids:/usr/share/misc/usb.ids"
 
 #define USB_CLASS_PER_INTERFACE 0 /* for DeviceClass */
 #define USB_CLASS_AUDIO 1

Bug#860970: release-notes: MariaDB vs MySQL section 2.2.3 needs clarifying on how to perform the upgrade

[Vincent McIntyre]

Hi Paul
 
If I understand correctly, you are suggesting this change:

  MariaDB is now the default MySQL variant in Debian, at version 10.1.
  The Stretch release introduces a new mechanism for switching the
  default variant, using metapackages created from the
  mysql-defaults source package.
  For example, installing the metapackage
  default-mysql-server will install
  mariadb-server-10.1.
- Users who had
+ For upgrading from jessie, it is recommended to install
+ this metapackage from the jessie-backports archive so that
+ users who have
  mysql-server-5.5 or mysql-server-5.6 will have it
  removed and replaced by the MariaDB equivalent.
  Similarly, installing default-mysql-client will install
  mariadb-client-10.1.

I don't think the release team want upgrades to depend on backports,
so I don't that's a viable option here.

But let's go back a step - you're saying that
if:   you have a jessie system with mysql-server-5.x
  and you dist-upgrade,
  without explicitly installing default-mysql-server
then: mysql-server-5.x gets uninstalled
  and no mariadb-server-* package gets installed ?

If correct, that's a big problem.

What the text is trying to tell people to do is to dist-upgrade,
then install default-mysql-server. That second action should
initiate the uninstall of mysql-server-5.x and then install
mariadb-server-10.1. Is that what you took from the text?
If not, can you think of a way to make it clearer?

Cheers
Vince

Bug#855656: release-notes: update on mysql/mariadb for stretch

[Vincent McIntyre]

On Sun, Feb 26, 2017 at 05:58:08PM +0100, Baptiste Jammet wrote:
> 
> I add an  for the note about binary data file formats
> not backwards compatible, and choose to add default-mysql-* next
> to virtual-mysql-*.
> Updated patch attached, for clarity.

Good idea. I added a 'for example' to the sentence about installing
default-mysql-server. Otherwise this seems ready to me.


Index: en/whats-new.dbk
===
--- en/whats-new.dbk(r??vision 11372)
+++ en/whats-new.dbk(copie de travail)
@@ -302,17 +302,15 @@
 3.16 series
 4.8 series
   
-
   
MySQLMySQL
5.5
-   5.6
+   removed
   
   
NginxNginx
@@ -431,6 +429,46 @@
   
 
 
+
+
+  MariaDB replaces MySQL
+  
+MariaDB is now the default MySQL variant in Debian, at version 10.1.
+The  release introduces a new mechanism for switching the
+default variant, using metapackages created from the
+mysql-defaults source package.
+For example, installing the metapackage
+default-mysql-server
+will install
+mariadb-server-10.1.
+Users who had
+mysql-server-5.5 or
+mysql-server-5.6 will have it
+removed and replaced by the MariaDB equivalent.
+Similarly, installing
+default-mysql-client
+will install
+mariadb-client-10.1.
+
+
+Note that the database binary data file formats are not backwards
+compatible, so once you have upgraded to MariaDB 10.1 you will
+not be able to switch back to any previous version of MariaDB or
+MySQL unless you have a proper database dump. Therefore, before
+upgrading, please make backups of all important databases with
+an appropriate tool such as mysqldump.
+
+
+The virtual-mysql-* and
+default-mysql-* packages
+will continue to exist. MySQL continues to be maintained in Debian,
+in the unstable release.
+See the https://wiki.debian.org/Teams/MySQL;>Debian MySQL Team
+wiki page for current information about the mysql-related
+software available in Debian.
+  
+
+
 
   
   A new archive for debug symbols




-- 

Bug#855656: release-notes: update on mysql/mariadb for stretch

[Vincent McIntyre]

On Tue, Feb 21, 2017 at 09:56:44AM +0100, Baptiste Jammet wrote:
> Hello,
> 
> Le 21/02/2017 01:09, Vincent McIntyre a écrit :
> 
> >this is a start on the notes needed regarding mysql/mariadb.
> >[...]
> >Comments welcome.
> Thanks for the patch. Here are some comments:
> 
> >   
> > MySQLMySQL
> > 5.5
> >-5.6
> >+-
> Maybe we could remove the entire line instead.
> Or mark the second column with removed.
> 

Sure, removed seens fine to me.

> >+ Installing the metapackage XX will pull in YY
> s/will pull in/will install/ ?
> 
> >+The virtual-mysql-* packages
> >+will continue to exist.
> I don't find any package named like this. Could you explain, please ?

This was taken from an email thread of the mysql packagers and it
was not all that clear to me either. I found an explanation here
   https://wiki.debian.org/Teams/MySQL/virtual-mysql-server

Since this seems to be something that only matters to packagers
of mysql-related software, perhaps the sentence should be dropped?

> 
> >+See the http://wiki.debian.org/Teams/MySQL;>Debian MySQL
> >Team
> >+wiki page
> s/http/https/
> 
> >+software availble in Debian.
> typo : available
> 

Agree on these

-- 

Bug#855656: release-notes: update on mysql/mariadb for stretch

[Vincent McIntyre]

Package: release-notes
Severity: normal
Tags: patch


Hello

this is a start on the notes needed regarding mysql/mariadb.
This has been developed in consultation with the mysql package
maintainers. It is probably missing a few pieces that should go
in other chapters, such as upgrading.dbk. Comments welcome.

Index: en/whats-new.dbk
===
--- en/whats-new.dbk(revision 11370)
+++ en/whats-new.dbk(working copy)
@@ -302,17 +302,17 @@
 3.16 series
 4.8 series
   
-
+
   
MySQLMySQL
5.5
-   5.6
+   -
   
   
NginxNginx
@@ -431,6 +431,40 @@
   
 
 
+
+
+  MariaDB replaces MySQL
+  
+MariaDB is now the default MySQL variant in Debian, at version 10.1.
+The  release introduces a new mechanism for switching the
+default variant, using metapackages created from the
+mysql-defaults source package.
+Installing the metapackage 
+default-mysql-server
+will pull in 
+mariadb-server-10.1.
+Users who had
+mysql-server-5.5 or
+mysql-server-5.6 will have it
+removed and replaced by the MariaDB equivalent.
+Similarly, installing
+default-mysql-client
+will pull in
+mariadb-client-10.1.
+Note that the database binary data file formats are not backwards
+compatible, so once you have upgraded to MariaDB 10.1 you will
+not be able to switch back to any previous version of MariaDB or
+MySQL unless you have a proper database dump. Therefore, before
+upgrading, please make backups of all important databases with
+an appropriate tool such as mysqldump.
+The virtual-mysql-* packages
+will continue to exist. MySQL continues to be maintained in Debian,
+in the unstable release.
+See the http://wiki.debian.org/Teams/MySQL;>Debian MySQL Team
+wiki page for current information about the mysql-related
+software availble in Debian.
+  
+
 
   
   A new archive for debug symbols

-- 

Bug#843953: multipath-tools: LVM on internal disks + multipath-toosl = no multipaths

[Vincent McIntyre]

On Fri, Nov 11, 2016 at 04:06:44PM +0530, Ritesh Raj Sarraf wrote:
> > Related notes:
> > 
> >    On some reboots the system log shows multipath timing out. Below is 
> > 'sdd'.
> >    The timeout occurs 33 seconds after the disk was attached.
> >    I was unable to determine the cause of this or reproduce consistently.
> > 
> >    Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] 25769805824 512-byte logical
> > blocks: (13.1 TB/12.0 TiB)
> >    Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Write Protect is off
> >    Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Mode Sense: 97 00 10 08
> >    Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Write cache: enabled, read
> > cache: enabled, supports DPO and FUA
> >    Nov 11 11:11:53  kernel:  sdd: sdd1
> >    Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Attached SCSI disk
> >    ...
> >    Nov 11 11:12:25  systemd-udevd[346]: timeout '/sbin/multipath -v0 
> > /dev/sdd'
> >    Nov 11 11:12:26  systemd-udevd[346]: timeout: killing '/sbin/multipath 
> > -v0
> > /dev/sdd' [459]
> >    Nov 11 11:12:26  systemd-udevd[346]: '/sbin/multipath -v0 /dev/sdd' [459]
> > terminated by signal 9 (Killed)
> > 
> 
> This is mostly the locking issue which you mentioned in the other bug.

This still occurs, but the system is able to recover from it.
I'll send you the log out of band.

> > Requests:
> > 
> > Can we please have sg3-utils v1.42 added to a stable point release?
> > Also multipath-tools needs to depend on sg3-utils-udev.
> > 
> 
> So as I understand, for now, you've already picked the fixed
> versions from testing for your setup.
 
Yes, that's the best way to summarise it.

> For this issue, multipath-tools doesn't really have any code
> change. The change is required in sg3-utils. For the stable
> release, I'm not sure what to do. 
> 
> 1. New releases are not allowed in stable
> 2. Backports could cover this case, but I really can't commit
>right now, on when I can get this done.
 
I understand. Probably backports, since it is hard to know what could
happen on systems that work already without the package.

> > It seems a shame to not include the shared lock patch as it avoids
> > a known deadlock and the system still works fine with it included.
> > 
> 
> Indeed. But, as I mentioned in other bug report, it was submitted
> upstream very recently only. And unless something is committed
> upstream, I don't pick it as a fix for Debian Stable.

Oh. I thought the link I gave was to the upstream repository...hm.
That's the repo Christoph's page links to.
I can see the commit in the master branch, what am I missing?

> I'd suggest, you pick the contents of sg3-utils-udev, for now.
> There's nothing other than the udev rules, in that package.
 
I've pretty much done that. I'll stick with the newer sg3-utils too.

> PS: You may also want to make plans for Stretch now. There are
> many more changes in multipath in the Stretch version. Having
> a test setup and reporting bugs in the development phase helps
> much more.

I am planning on this. I had some 'adventures' with 0.6.3 and the
4.7 backport kernel before trying the path I've described.

You may as well close this bug as wontfix, the workaround is just
install sg3-utils-udev.

Vince

Bug#843953: multipath-tools: LVM on internal disks + multipath-toosl = no multipaths

[Vincent McIntyre]

Package: multipath-tools
Version: 0.5.0-6+deb8u2
Severity: important

   * What led up to the situation?

   Upgrade working wheezy system to jessie
   Apply patch to fix multipath segfault, see #751993

   The system boots off an internal physical disk
   That disk has one / partition and an LVM partition
   /usr is one of the LVs on that disk
   There are two other internal disks, LVM is not used on these.
   The multipath devices are connected via a qlogic ISP2432-based card,
   through a FC switch to two Promise VTrak units.
   LVM is not used on the multipath devices.


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

   Cold-plug FC connection to external storage, boot system.

   * What was the outcome of this action?

   multipath -l shows no devices. no related device maps in /dev/mapper.

   The FC and SCSI layers all worked fine, I see lots of /dev/sdX devices.

   multipath -l -v3 shows the /dev/sdX devices as blacklisted
 ...
 sdd: blacklisted, udev property missing
 sde: blacklisted, udev property missing
 sdp: blacklisted, udev property missing
 ...etc

   * What outcome did you expect instead?

   usable multipaths to the configured devices
   /dev/mapper populated, including kpartx partitions

Related notes:

   On some reboots the system log shows multipath timing out. Below is 'sdd'.
   The timeout occurs 33 seconds after the disk was attached.
   I was unable to determine the cause of this or reproduce consistently.

   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] 25769805824 512-byte logical 
blocks: (13.1 TB/12.0 TiB)
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Write Protect is off
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Mode Sense: 97 00 10 08
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Write cache: enabled, read cache: 
enabled, supports DPO and FUA
   Nov 11 11:11:53  kernel:  sdd: sdd1
   Nov 11 11:11:53  kernel: sd 1:0:0:4: [sdd] Attached SCSI disk
   ...
   Nov 11 11:12:25  systemd-udevd[346]: timeout '/sbin/multipath -v0 /dev/sdd'
   Nov 11 11:12:26  systemd-udevd[346]: timeout: killing '/sbin/multipath -v0 
/dev/sdd' [459]
   Nov 11 11:12:26  systemd-udevd[346]: '/sbin/multipath -v0 /dev/sdd' [459] 
terminated by signal 9 (Killed)

   On some reboots, there was a bad interaction between LVM and multipathd
   and/or udev. On the console systemd showed it was waiting for tasks to
   complete for both of these.
   device-mapper would try to handle the multipath devices before the LVM
   ones, which sometimes caused the system to fail to boot; it went into
   emergency mode.
   I was unable to determine the cause of this or reproduce it consistently.
   I don't know where the multipath-tools-boot line comes from, that
   package is not even installed.

   You can however see the two running contemporaneously
   # journalctl |egrep -i -e '(multipath|lvm|-udev)'
   Nov 11 16:52:57 systemd[1]: Starting LVM2 metadata daemon socket.
   Nov 11 16:52:57 systemd[1]: Listening on LVM2 metadata daemon socket.
   Nov 11 16:52:57 systemd-udevd[317]: starting version 215
   Nov 11 16:52:58 systemd[1]: Starting LSB: early multipath boot script...
   Nov 11 16:52:58 kernel: device-mapper: multipath: version 1.7.0 loaded
   Nov 11 16:52:59 multipath-tools-boot[633]: Discovering and coalescing 
multipaths...done.
   Nov 11 16:52:59 systemd[1]: Started LSB: early multipath boot script.
   Nov 11 16:52:59 systemd[1]: Starting system-lvm2\x2dpvscan.slice.
   Nov 11 16:52:59 systemd[1]: Created slice system-lvm2\x2dpvscan.slice.
   Nov 11 16:52:59 systemd[1]: Starting LVM2 PV scan on device 8:2...
   Nov 11 16:52:59 systemd[1]: Starting Activation of LVM2 logical volumes...
   Nov 11 16:52:59 systemd[1]: Started LVM2 PV scan on device 8:2.
   Nov 11 16:52:59 lvm[676]: 10 logical volume(s) in volume group "testbox" now 
active
   Nov 11 16:53:00 systemd[1]: Started Activation of LVM2 logical volumes.
   Nov 11 16:53:00 systemd[1]: Starting Activation of LVM2 logical volumes...
   Nov 11 16:53:01 lvm[854]: 10 logical volume(s) in volume group "testbox" now 
active
   Nov 11 16:53:01 systemd[1]: Started Activation of LVM2 logical volumes.
   Nov 11 16:53:01 systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots 
etc. using dmeventd or progress polling...
   Nov 11 16:53:01 lvm[928]: 10 logical volume(s) in volume group "testbox" 
monitored
   Nov 11 16:53:01 systemd[1]: Started Monitoring of LVM2 mirrors, snapshots 
etc. using dmeventd or progress polling.
   Nov 11 16:53:09 systemd[1]: Starting LSB: multipath daemon...
   Nov 11 16:53:10 multipath-tools[1190]: Starting multipath daemon: multipathd.
   Nov 11 16:53:10 systemd[1]: Started LSB: multipath daemon.
   Nov 11 16:53:10 multipathd[1288]: path checkers start up



Further work:

First I applied the patch discussed in #799781 (shared lock with udev).
This didn't fix things but may have helped.

Then after reviewing #782487, I built sg3-utils v1.42 and installed it,
including 

Bug#799781: found the upstream commit

[Vincent McIntyre]

On Sun, 27 Sep 2015 20:04:06 +0530, Ritesh Raj Sarraf wrote:

> I have a problem here.
> 
> The fix, that you mentioned for the Shared Lock, does not seem to be
> committed upstream. Neither master, nor Hannes's suse-fixes branch.

It is there, please see

http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=5ec07b3af8d1c3a6c7ba1680af20b80ddce4f962
libmultipath: use a shared lock to co-operate with udev

That line of code is still there in the latest git.

Regards
Vince

Bug#751993: another instance

[Vincent McIntyre]

On Wed, Nov 09, 2016 at 04:27:40PM +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Wed, 2016-11-09 at 09:15 +1100, Vincent McIntyre wrote:
> > This is a problem because I need to blacklist DELL,
> > multipath -l -v 3 gives me the listing below.
> > Note that at this point I have no fibre channel links plugged in,
> > I don't trust this package that far yet.
> > 
> > Farther below, backtrace for the segfaulting configuration.
> > I also tried blacklisting the 'product' (PERC 6/i) instead of
> > 'vendor', that segfaulted too.
> > It would appear the segfault only occurs on a blacklist match.
> > 
> > Please consider upgrading the severity of this again.
> 
> Hello Vincent, 
> 
> Are you in a position to build debian packages by yourself ?
> If so, can you cherry-pick this [1] commit and try it on top of the Jessie
> version of multipath-tools ?
> 
> [1] 
> https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=5195a
> bd56cdfbc12c32c0ad3127a32643d11db4b

Thanks for the fast response. 

First, try the existing package with a product as well:

# grep -v ^# /etc/multipath.conf
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"

device {
vendor DELL
product "PERC H800"
}
}

# multipath -l -v 3
Nov 10 10:22:08 | libdevmapper version 1.02.90 (2014-09-01)
Nov 10 10:22:08 | DM multipath kernel driver v1.11.0
Nov 10 10:22:08 | loading /lib/multipath/libcheckdirectio.so checker
Nov 10 10:22:08 | loading /lib/multipath/libprioconst.so prioritizer
Nov 10 10:22:08 | sda: blacklisted, udev property missing
Nov 10 10:22:08 | sdb: udev property ID_WWN whitelisted
Nov 10 10:22:08 | sdb: not found in pathvec
Nov 10 10:22:08 | sdb: mask = 0x21
Nov 10 10:22:08 | sdb: dev_t = 8:16
Nov 10 10:22:08 | sdb: size = 11717836800
Nov 10 10:22:08 | sdb: vendor = DELL
Nov 10 10:22:08 | sdb: product = PERC 6/i
Nov 10 10:22:08 | sdb: rev = 1.22
Nov 10 10:22:08 | sdb: h:b:t:l = 0:2:1:0
Nov 10 10:22:08 | sdb: path state = running
Nov 10 10:22:08 | sdc: udev property ID_WWN whitelisted
Nov 10 10:22:08 | sdc: not found in pathvec
Nov 10 10:22:08 | sdc: mask = 0x21
Nov 10 10:22:08 | sdc: dev_t = 8:32
Nov 10 10:22:08 | sdc: size = 39059456000
Nov 10 10:22:08 | sdc: vendor = DELL
Nov 10 10:22:08 | sdc: product = PERC H800
Nov 10 10:22:08 | sdc: rev = 2.10
Nov 10 10:22:08 | sdc: h:b:t:l = 2:2:0:0
Nov 10 10:22:08 | (null): (DELL:PERC H800) vendor/product blacklisted
Nov 10 10:22:08 | sr0: blacklisted, udev property missing
Nov 10 10:22:08 | loop0: blacklisted, udev property missing
Nov 10 10:22:08 | loop1: blacklisted, udev property missing
Nov 10 10:22:08 | loop2: blacklisted, udev property missing
Nov 10 10:22:08 | loop3: blacklisted, udev property missing
Nov 10 10:22:08 | loop4: blacklisted, udev property missing
Nov 10 10:22:08 | loop5: blacklisted, udev property missing
Nov 10 10:22:08 | loop6: blacklisted, udev property missing
Nov 10 10:22:08 | loop7: blacklisted, udev property missing
Nov 10 10:22:08 | dm-0: blacklisted, udev property missing
Nov 10 10:22:08 | dm-1: blacklisted, udev property missing
Nov 10 10:22:08 | dm-10: blacklisted, udev property missing
Nov 10 10:22:08 | dm-11: blacklisted, udev property missing
Nov 10 10:22:08 | dm-12: blacklisted, udev property missing
Nov 10 10:22:08 | dm-13: blacklisted, udev property missing
Nov 10 10:22:08 | dm-2: blacklisted, udev property missing
Nov 10 10:22:08 | dm-3: blacklisted, udev property missing
Nov 10 10:22:08 | dm-4: blacklisted, udev property missing
Nov 10 10:22:08 | dm-5: blacklisted, udev property missing
Nov 10 10:22:08 | dm-6: blacklisted, udev property missing
Nov 10 10:22:08 | dm-7: blacklisted, udev property missing
Nov 10 10:22:08 | dm-8: blacklisted, udev property missing
Nov 10 10:22:08 | dm-9: blacklisted, udev property missing
= paths list =
uuid hcildev dev_t pri dm_st chk_st vend/prod/rev dev_st 
 0:2:1:0 sdb 8:16  -1  undef undef  DELL,PERC 6/i running
Nov 10 10:22:08 | params = 0 0 1 1 service-time 0 1 2 8:16 1 1 
Nov 10 10:22:08 | status = 2 0 0 0 1 1 A 0 1 2 8:16 A 0 0 1 
Nov 10 10:22:08 | 36782bcb0091105001b7d74a00b7be1cb: disassemble map [0 0 1 1 
service-time 0 1 2 8:16 1 1 ]
Nov 10 10:22:08 | 36782bcb0091105001b7d74a00b7be1cb: disassemble status [2 0 0 
0 1 1 A 0 1 2 8:16 A 0 0 1 ]
36782bcb0091105001b7d74a00b7be1cb dm-2 DELL,PERC 6/i
size=5.5T features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
  `- 0:2:1:0 sdb 8:16 active undef running
Nov 10 10:22:08 | params = 0 0 1 1 service-time 0 1 2 8:32 1 1 
Nov 10 10:22:08 | status = 2 0 0 0 1 1 A 0 1 2 8:32 A 0 0 1 
Nov 10 10:22:08 | 36c81f660d4620f001b7c65f99ab4cfb8: disassemble map [0 0 1 1 
service-time 0 1 2 8:3

Bug#610282: partman-lvm/confirm boolean true does not suppress "Before the Logical Volume ..."

[Vincent McIntyre]

(we were discussing having a branch of manual for each stable release)

This appears to have happened - thanks Samuel!

https://anonscm.debian.org/viewvc/d-i/branches/manual/jessie/

I think it would be worth mentioning the existence of this
in the trunk README - suggested patch below. Please let me know
if I should open another bug for this or cross-reference to an
existing one.

Index: README
===
--- README  (revision 70307)
+++ README  (working copy)
@@ -17,4 +17,10 @@
 All help is welcome! Send suggestions to the debian-boot list. Patches
 can be submitted against the package installation-guide.
 
-Last update: 09 July 2006
+Patches should normally be submitted against the 'trunk' version of
+the manual, so they will be included in the next stable release.
+However there are some cases where it is appropriate to update the
+stable release also: such patches should be made against the branch
+for the relevant stable release codename: ^/branches/manual/.
+
+Last update: 27 September 2016

-- 

Bug#838948: [patch] preseed appendix of d-i manual: use_autoconfig

[Vincent McIntyre]

Package: installation-guide
Severity: minor
Tags: d-i patch
thanks
 
(resending as a bug, my post to -boot didn't elicit any replies)


For some years the disable_autoconfig preseed has been shown
in the appendix on preseeding. However setting that just sets
use_autoconfig appropriately. Yet use_autoconfig is not even
mentioned in the appendix, ever.

There might be something I'm missing here, such as disable_autoconfig
is the only thing that works if you pass it on the boot command line.
I might also be misinterpreting 'manual configuration' as meaning
'set up an "iface ethX inet static" stanza in /etc/network/interfaces'.

If not, is it time to start deprecating use of disable_auotconfig?
I realise it was needed in the past but the code has been fixed.

--- preseed.xml (revision 70296)
+++ preseed.xml (working copy)
@@ -882,6 +882,10 @@
 
 # If you prefer to configure the network manually, uncomment this line and
 # the static network configuration below.
+#d-i netcfg/use_autoconfig boolean false
+
+# The following also forces manual configuration, but is deprecated
+# for end user preseed files. It will set use_autoconfig to false.
 #d-i netcfg/disable_autoconfig boolean true
 


Cheers
Vince
-- 

Bug#838946: [patch] preseed appendix of d-i manual: use_autoconfig

[Vincent McIntyre]

Package: debian-installer-manual
Version: Head
Severity: minor
Tags: d-i patch
thanks

(resending as a bug, my post to -boot didn't elicit any replies)


For some years the disable_autoconfig preseed has been shown
in the appendix on preseeding. However setting that just sets
use_autoconfig appropriately. Yet use_autoconfig is not even
mentioned in the appendix, ever.

There might be something I'm missing here, such as disable_autoconfig
is the only thing that works if you pass it on the boot command line.
I might also be misinterpreting 'manual configuration' as meaning
'set up an "iface ethX inet static" stanza in /etc/network/interfaces'.

If not, is it time to start deprecating use of disable_auotconfig?
I realise it was needed in the past but the code has been fixed.

--- preseed.xml (revision 70296)
+++ preseed.xml (working copy)
@@ -882,6 +882,10 @@
 
 # If you prefer to configure the network manually, uncomment this line and
 # the static network configuration below.
+#d-i netcfg/use_autoconfig boolean false
+
+# The following also forces manual configuration, but is deprecated
+# for end user preseed files. It will set use_autoconfig to false.
 #d-i netcfg/disable_autoconfig boolean true
 


Cheers
Vince
-- 

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Wed, Sep 14, 2016 at 08:59:52AM +0200, Aurelien Jarno wrote:
> 
> > More details.
> > The target system is pxe booted and next-server takes it to a (debian)
> > system running tftpd-hpa. The defaults.cfg has lots of boot targets
> > but the one I have been testing with is the netboot image, in manual
> > install mode. The only boot options it is given are 
> >  'append vga=normal initrd=yadayada'
> > It also falls over if I feed it a preseed file, where we use
> >  'append auto=true priority=critical vga=normal initrd=yadayda 
> >   url=blahdeblah'
> 
> Thanks for the details. Here in a QEMU VM, both work fine.

I learned today that this whole goose chase started when
a colleague hit this using qemu and bridged networking.
Before today I thought it was real hardware.

I tried this with vmware fusion, setting next-server to the pxe
server used above and the manual/interactive installer target.
I was using NATted networking here; resolv.conf lists only the
vmware nameserver (172.16.119.2).

busybox segfaults at the same time and in the same way.
If I test with wget or ping, I get a segfault unless I use IP
addresses or add the hostname I want to resolve to /etc/hosts.

I tried patching the initrd so that the hostname and lookup
could be pre-configured. /etc/nsswitch.conf comes through
unscathed but /etc/hosts is overwritten. When I hit the segfault
I added the necessary /etc/hosts entry and retried. That worked;
I was able to do a complete installation.

I also figured out how to use netcat to get the log file.
I've attached the syslog up to the first segfault,
with DEBCONF_DEBUG=5.
 
Vince


syslog.debug=5.gz
Description: application/gzip

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Wed, Sep 14, 2016 at 09:01:20AM +0200, Aurelien Jarno wrote:
> > ...
> > warning: Can't read pathname for load map: Input/output error.
> > 
> > warning: Could not load shared library symbols for 4 libraries, e.g. 
> > /lib/libc.so.6.
> > Use the "info sharedlibrary" command to see the complete listing.
> > Do you need "set solib-search-path" or "set sysroot"?
> > Core was generated by `ping ftp.au.debian.org'.
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x7f826609d0ca in ?? ()
> > (gdb) bt full
> > #0  0x7f826609d0ca in ?? ()
> > No symbol table info available.
> > #1  0x in ?? ()
> > No symbol table info available.
> > (gdb) q
> 
> Have you installed libc6-dbg on this wheezy machine? Anyway I am afraid
> that gdb is confused as the libc6 in debian-installer got some symbols
> removed...

I hadn't in the example above but it makes no difference if I have
libc6-dbg installed, the bt is the same.

Vince

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Wed, Sep 14, 2016 at 09:29:18AM +1000, Vincent McIntyre wrote:
> > Also you might want to use the console (alt+f2) to run wget by hand and
> > see if the issue happen with all hosts or only some of them.
> 
> I tried to wget pages from a few web sites from the alt+f2 console.
> It segfaulted every time when I used a DNS name in the URL,
> but worked if I used an IP address in the URL.
> ping does the same thing; segfaults only when using domain names.
> 
> If I put an entry in /etc/hosts and try to access that hostname,
> wget and ping also segfault, until I add this line to nsswitch.conf:
> 
>   hosts: files dns
> 
> Then they both work for that hostname.
> The only other nsswitch.conf lines are for passwd, group & shadow.
> 

I was able to netcat busybox & the coredump to a wheezy machine
and got this backtrace, which does not look like it is much help...

% gdb ./ping ./ping.core
GNU gdb (GDB) 7.4.1-debian
...
warning: Can't read pathname for load map: Input/output error.

warning: Could not load shared library symbols for 4 libraries, e.g. 
/lib/libc.so.6.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `ping ftp.au.debian.org'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f826609d0ca in ?? ()
(gdb) bt full
#0  0x7f826609d0ca in ?? ()
No symbol table info available.
#1  0x in ?? ()
No symbol table info available.
(gdb) q


Vince
-- 

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Tue, Sep 13, 2016 at 11:03:19PM +0200, Aurelien Jarno wrote:

...

> > If all of that makes no difference, what would be the next step?
> 
> What would be interesting would be to try to reproduce the issue in
> qemu or virtualbox, with as many things as possible close to your
> system.
> 

Just to clarify - you mean try to run the installer using a qemu VM
as the target for installation? I can certainly try that.

More details.
The target system is pxe booted and next-server takes it to a (debian)
system running tftpd-hpa. The defaults.cfg has lots of boot targets
but the one I have been testing with is the netboot image, in manual
install mode. The only boot options it is given are 
 'append vga=normal initrd=yadayada'
It also falls over if I feed it a preseed file, where we use
 'append auto=true priority=critical vga=normal initrd=yadayda 
  url=blahdeblah'

> Also you might want to use the console (alt+f2) to run wget by hand and
> see if the issue happen with all hosts or only some of them.

I tried to wget pages from a few web sites from the alt+f2 console.
It segfaulted every time when I used a DNS name in the URL,
but worked if I used an IP address in the URL.
ping does the same thing; segfaults only when using domain names.

If I put an entry in /etc/hosts and try to access that hostname,
wget and ping also segfault, until I add this line to nsswitch.conf:

  hosts: files dns

Then they both work for that hostname.
The only other nsswitch.conf lines are for passwd, group & shadow.

> > My concern is there's a segfault still lurking in the stretch
> > version. If we can squash it here that fix could be forward-ported.
> 
> This is very unlikely, as both debian-installer and glibc are quite
> different in stretch and do not use the shared library reduction
> anymore.

Ok that's good to know.

Bug#775541: tests of new packages

[Vincent McIntyre]

On Mon, Sep 12, 2016 at 02:38:32PM +1000, Vincent McIntyre wrote:

A brief note on the client side of things.

At step 3, after installing your packages but before tweaking
nfs-server.service, the critical chain for the client mount is

usr-local.mount +1.145s
└─remote-fs-pre.target @7.493s
  └─nfs-client.target @2.362s

After (step 4.x) it is somewhat different

usr-local.mount +1.141s
└─remote-fs-pre.target @10.207s
  └─nfs-server.service @10.193s +12ms
└─rpc-statd.service @10.342s +18ms
  └─nss-lookup.target @10.340s

The 'list-dependencies' output is the same for both
Dependencies for usr-local.mount
usr-local.mount
● ├─-.mount
● ├─system.slice
● ├─usr.mount
● └─network-online.target

Not sure why nfs-client has dopped out of the picture.
Nonetheless, the mount works fine.

Cheers
Vince

Bug#775541: tests of new packages

[Vincent McIntyre]

On Fri, Sep 09, 2016 at 10:22:25AM +0200, Andreas Henriksson wrote:
> Hello Vincent McIntyre.
> 
> Thanks for your thurough testing and useful feedback.
> 
> Let me start with a disclaimer: I'm not maintaining nfs (and I'm
> not even using it myself so my knowledge is very limited). My only
> involvement here is trying to squash some RC bugs and unblocking
> work elsewhere by importing native systemd units.

That is fine with me and highly appreciated.

> On Fri, Sep 09, 2016 at 11:57:34AM +1000, Vincent McIntyre wrote:
> > 
> > Thanks Andreas for those new packages.
> > I did some testing of the 1.2.8-9.2 packages on a clean jessie install.
> > They are pretty close but I found an issue with NFS exports in one case.
> > 
> > I used the attached check.sh script to show the state of various targets
> > as I changed things. The attached results.tar shows the output from it.
> > Between each major stage below, the system is rebooted.
> > Then I log in and run check.sh before doing anything else.
> > Throughout, /etc/network/interfaces contained:
> >   source /etc/network/interfaces.d/*
> >   auto lo
> >   iface lo inet loopback
> >   allow-hotplug eth0
> 
> I think this  is problematic and unfortunately spoils my interest
> in the rest of your testing.
> 
> From what I've been told one of the main differences between "auto"
> and "allow-hotplug" is that allow-hotplug will not block your bootup
> so services will run wild and start up ASAP. This means they can and
> likely will start up before your network connection is up. Specially
> if using dhcp which takes time to configure the interface and extra
> so if you're using a network device (eg. usb dongle) which takes a
> long time to initialize.
> 
> I assume eth0 was involved in your tests, and if so it would be
> very useful to know what difference it makes if you use auto
> instead.
> 

Thanks for that. I've repeated with a slightly different numbering.
The short version is that the client mounts and exports all work
with your packages and 'auto eth0' BUT one change is needed to make
exports work at boot time:

  /lib/systemd/system/nfs-mountd.service

 - After=network.target local-fs.target   
 + After=rpcbind.target network.target local-fs.target

There might be a more elegant way to this but this seems to work.

I did a quick check of your packages with 'auto eth0' and a static
address setup in /etc/network/interfaces. That worked also but
to get the exports working at boot the change above was required.

Detailed results:

step 1 - jessie system with nfs packages 1.2.8-9
 one fstab mount, no exports. no changes to /etc/default/nfs-*
 The fstab mount works ok; it politely waits for dhcp to finish
 before trying to mount. It works in all the other tests so
 I won't mention it further.

step 2 - as above but export one filesystem.
 Tried a few different ways to do the exports
   - wildcard host (step2.1)
   - point the export at a single host (step2.2)
   - point the export at a netgroup (step2.3)
  All of these work with no problem.
   
step 3 - jessie system with nfs packages 1.2.8-9.2
 one fstab mount, one exported directory.
 
 rpc.mountd fails to start because it wants rpcbind to be there,
 but rpcbind has not been started yet. showmount -e fails:
 # showmount -e
 clnt_create: RPC: Program not registered
 
step3.1 - modify  /lib/systemd/system/nfs-mountd.service,
- After=network.target local-fs.target
+ After=rpcbind.target network.target local-fs.target
   run systemd daemon-reload
   but don't reboot.
   The exports are still not there
   # showmount -e
   clnt_create: RPC: Program not registered
 
   re run exports, it fails
   # exportfs -rav
   exporting @all_hosts:/data/INSTALL_1
   # showmount -e
   clnt_create: RPC: Program not registered
   #

step 4 - reboot after step3.1:
 All of the exports work now.
 I don't need to insert any 30s waits anywhere, yay.
 

Without the tweak to nfs-mountd.service, the critical chain is:
nfs-mountd.service +33ms
└─network.target @7.453s
  └─networking.service @2.349s +5.103s
└─local-fs.target @2.345s
  └─data-INSTALL_1.mount @2.212s +132ms
└─systemd-fsck@dev-mapper-libra\x2ddata.service @2.193s +16ms
  └─dev-mapper-libra\x2ddata.device @2.192s

With the tweak in place
nfs-mountd.service +19ms
└─rpcbind.target @10.169s
  └─rpcbind.service @10.126s +42ms
└─network-online.target @10.123s
  └─network.target @10.123s
└─networking.service @1.289s +8.833s
  └─local-fs.target @1.285s
└─data-INSTALL_1

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Mon, Sep 12, 2016 at 12:28:55PM +1000, Vincent McIntyre wrote:
> 
> >  - make sure all ipv6 related options are disabled
> >and no ipv6 DNS entries exist for the target host
> 
>Didn't try it. The failure happens really early, before the
>preseed file is downloaded.

Incorrect. The preseed is downloaded ok but it doesn't matter, as far
as I can see, the fault happens before any network configuration
directives in the preseed file can be used.

Vince

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Sat, Sep 10, 2016 at 11:30:32AM +1000, Vincent McIntyre wrote:
> 
> You've given me a few things to try out
>  - tell DHCP to supply different DNS servers (running bind)

   Makes no difference. These servers are not configured for v6,
   while the first ones I used were. There are no v6 entries for
   the host in any case.

>  - make sure all ipv6 related options are disabled
>and no ipv6 DNS entries exist for the target host

   Didn't try it. The failure happens really early, before the
   preseed file is downloaded.

>  - make sure all ipv6 related options are enabled
>and valid ipv6 DNS entries exist for the target host
 
   Didn't try
 
> Also I can try installing oldstable with the jessie installer.
  
  This worked. Even with mirror/udeb/suite set to 'stable'.
  For anyone who comes along later, the udeb versions were
anna 1.52
base-installer 1.154
libc6-udeb 2.19-18+deb8u4
netcfg 1.131+deb8u1

I think this bug can probably be downgraded until someone else can
reproduce it, or at least marked as 'not found' in the later version
of libc6-udeb. If I get time I will try with the daily installer and
report on that.

Vince

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Fri, Sep 09, 2016 at 03:59:17PM +0200, Aurelien Jarno wrote:
> 
> I don't talk about the software running on your DNS servers, but
> rather how they behave when they get queried. It might depends on
> many other things, like if your network has IPv6 or not.
> 
> Note that's only one explanation, not sure it's the right one, but
> given I am unable to reproduce the issue, it's the only one that
> come to my mind.

Thank you for explaining. I am struggling with this idea since AFAIK
the DNS servers have not been changed in the last six months or more
so I can think of no reason for the behaviour to have changed.
That history is what makes me think something must have changed in
the installer around the time of the last point release (May).
But from what you say that isn't the case.

You've given me a few things to try out
 - tell DHCP to supply different DNS servers (running bind)
 - make sure all ipv6 related options are disabled
   and no ipv6 DNS entries exist for the target host
 - make sure all ipv6 related options are enabled
   and valid ipv6 DNS entries exist for the target host

Also I can try installing oldstable with the jessie installer.
 
If all of that makes no difference, what would be the next step?
I assume I'd have to build a debug version of the installer
and try to get a backtrace?
My concern is there's a segfault still lurking in the stretch
version. If we can squash it here that fix could be forward-ported.

Kind regards
Vince

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

On Fri, Sep 09, 2016 at 11:46:30AM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2016-09-09 10:27, Vincent McIntyre wrote:
> > 
> > Package: libc6-udeb
> > Version: 2.13-38+deb7u10
> > Severity: grave
> > Justification: breaks installation entirely
> > 
> > The wheezy installer fails with anna reporting a segfault:
> >
> > ...
> > anna[5033]: DEBUG: retrieving libc6-udeb 2.13-38+deb7u10
> > anna[5033]: DEBUG: retrieving finish-install 2.41wheezy1
> > anna[5033]: DEBUG: Segmentation fault
> > anna[5033]: WARNING **: package retrieval failed
> > kernel: [   66.427372] wget[5382]: segfault a 0 ip 7176c922c0ca sp 
> > 7ffc8ca83890 error 6 in libresolv-2.13.so[7f76c9222000+13000]
> > 
> > This occurs shortly after libc6-udev is downloaded,
> > according to the installer interactive display.
> 
> Unfortunately I am not able to reproduce the issue here. Given it
> involves name resolving, I wouldn't be surprised it depends on the DNS
> servers being used.

Seriously??? I have to use the exactly right flavour of DNS server?
I think this would have been using microsoft DNS servers.
I preseume you're using BIND?

Could this be a locale thing?

> > The core of the issue is probably screwed up libc6 versions,
> > see bugs 740068, 833432
> 
> It indeeds looks like that, that said the build logs actually show
> that debian-installer 20130613+deb7u3+b2 has been built against
> glibc
> 2.13-38+deb7u10, so there is no version skew in this case.
> 
> Unfortunately, without being able to reproduce the problem, it
> will be very difficult to debug it.

Lovely. Thanks for bothering to reply.
Vince

Bug#775541: tests of new packages

[Vincent McIntyre]

I found one further issue which is related to  #738063.

I wanted to limit the exports to supporting version 2 and 3.

I first set RPCMOUNTDOPTS="--manage-gids --no-nfs-version 4"
as explained in /etc/default/nfs-kernel-server.
But I found I also needed add the following to that file:

   RPCNFSDPRIORITY=0

 + # other options for nfsd
 + # To disable NFSv4 on the server, specify '--no-nfs-version 4' here also
 + RPCNFSDOPTS="--no-nfs-version 4"


I discovered this by reading the source of the new script
/usr/lib/systemd/scripts/nfs-utils_env.sh
which constructs the RPCNFSDARGS variable used in
the /lib/systemd/system/nfs-server.service file.

If you upload a new version of this package, could you add an
empty definition of RPCNFSDOPTS to /etc/default/nfs-kernel-server,
so people can find it?

Users of the init script would also benefit from this change.

Thanks
Vince

Bug#775541: tests of new packages

[Vincent McIntyre]

Thanks Andreas for those new packages.
I did some testing of the 1.2.8-9.2 packages on a clean jessie install.
They are pretty close but I found an issue with NFS exports in one case.

I used the attached check.sh script to show the state of various targets
as I changed things. The attached results.tar shows the output from it.
Between each major stage below, the system is rebooted.
Then I log in and run check.sh before doing anything else.
Throughout, /etc/network/interfaces contained:
  source /etc/network/interfaces.d/*
  auto lo
  iface lo inet loopback
  allow-hotplug eth0
  iface eth0 inet dhcp
and /etc/network/interfaces.d/ was empty.

step 1 - jessie system with nfs packages 1.2.8-9
 one fstab mount, no exports. no changes to /etc/default/nfs-*.
 The fstab mount works ok; it tries to mount it way too early
 but we invoke it with the 'bg' option so eventually it works.

step 2 - as above but with the _netdev option added to the fstab entry.
 System still tries to mount too early, before dhclient is done,
 but it works in the end.

step 3 - as above but export one filesystem.
 The fstab mount works, as above.
 Tried a few different ways to do the exports
   - wildcard host (step3.1)
 This works ok.
   - point the export at a single host (step3.2)
 This tries to start mountd to early, before it can resolve
 the hostname given in the exports file.
 As a result we end up with an empty export list:
 # showmount -e
 Export list for install:
 #
 Restarting the service once the system is fully booted works
 # systemctl restart nfs-kernel-server.service
 # showmount -e
 Export list for install:
 /data/INSTALL_1 mayhem.atnf.CSIRO.AU
 #
   - point the export at a netgroup (step3.3)
 This works, even though the netgroup cannot be resolved
 (there's no definition for it).
 # showmount -e
 Export list for install:
 /data/INSTALL_1 @all_hosts
 #

NB nfs-kernel-server starts before dhclient
Sep 08 17:04:46 install nfs-kernel-server[657]: Exporting directories for NFS 
kernel daemon
Sep 08 17:04:46 install kernel: NFSD: Using /var/lib/nfs/v4recovery as the 
NFSv4 state recovery directory
Sep 08 17:04:46 install kernel: NFSD: starting 90-second grace period (net 
818ba280)
...
Sep 08 17:04:46 install rpc.mountd[738]: Version 1.2.8 starting
Sep 08 17:04:46 install nfs-kernel-server[657]: Starting NFS kernel daemon: 
nfsd mountd.
Sep 08 17:04:46 install acpid[734]: starting up with netlink and the input layer
Sep 08 17:04:46 install acpid[734]: 1 rule loaded
Sep 08 17:04:46 install acpid[734]: waiting for events: event logging is off
...
Sep 08 17:04:49 install kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: None
Sep 08 17:04:49 install kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link 
becomes ready
Sep 08 17:04:50 install dhclient[532]: DHCPDISCOVER on eth0 to 255.255.255.255 
port 67 interval 6
...
Sep 08 17:04:56 install ifup[522]: Starting rpcbind (via systemctl): 
rpcbind.service.
Sep 08 17:04:56 install ifup[522]: Starting nfs-common (via systemctl): 
nfs-common.service.
Sep 08 17:04:56 install kernel: Key type dns_resolver registered
Sep 08 17:04:56 install kernel: NFS: Registering the id_resolver key type
Sep 08 17:04:56 install kernel: Key type id_resolver registered
Sep 08 17:04:56 install kernel: Key type id_legacy registered


step3.4 - install new nfs packages but don't reboot yet.
  I didn't analyse this step carefully

step 4 - jessie system with nfs packages 1.2.8-9.2
 one fstab mount, one exported directory.

 rpc.mountd fails to start because it wants rpcbind to be there,
 but rpcbind has not been started yet. showmount -e fails:
 # showmount -e
 clnt_create: RPC: Program not registered

step4.1 modify  /lib/systemd/system/nfs-mountd.service,
   - After=network.target local-fs.target
   + After=rpcbind.target network.target local-fs.target
run systemd daemon-reload
but don't reboot.
The exports are still not there
# showmount -e
clnt_create: RPC: Program not registered

re run exports, it fails
# exportfs -rav
exporting @all_hosts:/data/INSTALL_1
# showmount -e
clnt_create: RPC: Program not registered
#

step 5 - reboot after step4.1:

 usr-local.mount starts a little (1-2s) later. It starts
 just after ifup, but before dhclient has gotten an answer
 so it can't resolve the server hostname, but eventually
 the mount does work.

 Exports also work, in some cases:
 - wildcard case is OK (step5.1)
 # showmount -e
 Export list for install:
 

Bug#837123: ([anna] segfault in wheezy installer)

[Vincent McIntyre]

I just realised this went to the libc maintainers;
I was expecting it would go to the debian-installer team.

This might be an issue in the way libc6-udeb is being used
within debian-installer, rather than libc6-udeb itself.

I don't know how to figure out if that is the case;
if it is the case, please do reassign.

Kind regards
Vince

Bug#837123: [anna] segfault in wheezy installer

[Vincent McIntyre]

Package: libc6-udeb
Version: 2.13-38+deb7u10
Severity: grave
Justification: breaks installation entirely

The wheezy installer fails with anna reporting a segfault:

...
anna[5033]: DEBUG: retrieving libc6-udeb 2.13-38+deb7u10
anna[5033]: DEBUG: retrieving finish-install 2.41wheezy1
anna[5033]: DEBUG: Segmentation fault
anna[5033]: WARNING **: package retrieval failed
kernel: [   66.427372] wget[5382]: segfault a 0 ip 7176c922c0ca sp 
7ffc8ca83890 error 6 in libresolv-2.13.so[7f76c9222000+13000]

This occurs shortly after libc6-udev is downloaded,
according to the installer interactive display.

Background
--
I was trying to reinstall an older system with wheezy.
I was using the PXE install image available on 2016-09-08 UTC, at
ftp.au.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot

The mirror shows the last update timestamp as 2016-05-31.
debian-installer/amd64/boot-screens/f1.txt has the fairly useless
build date stamp 20130613+deb7u3+b2.

This installation method was working fine with earlier installer
versions. The breakage has been there some months I'd say.
I only became fully aware of it yesterday.

I don't think the mirror is out of date; I got the same result
with the netboot installer image downloaded from ftp.us.debian.org.


The log above was copied by eye from the console,
I was unable to install the openssh-client=udeb to copy the logs,
thanks to the segfault.

The core of the issue is probably screwed up libc6 versions,
see bugs 740068, 833432

Other package versions that may be of interest
 base-installer: 1.130
 cdebconf-udeb: 0.182
 di-utils: 1.92+deb7u1
 libc6-udeb: 2.13-38+deb7u10
 anna: 1.44+deb7u1

It's really unfortunate to have the oldstable installer break like this.
I hope it can be fixed, age notwithstanding.

Kind regards
Vince
-- 

Bug#775541: NFS mounts fail at boot after Debian 8.5 upgrade

[Vincent McIntyre]

Hello Paul

I read your feedback on this issue with interest.
Could you provide a bit more information about the package versions
on your system?

dpkg -l rpcbind nfs-common nfs-kernel-server systemd

Also I think the output of these commands would be helpful

systemd-analyze critical-path remote-fs-pre.target
systemd-analyze critical-path nfs-kernel-server.service

As to your question about After=rpcbind.service vs rpcbind.target,
I think rpcbind.target is correct as you're trying to express
that you want mounting remote filesystems to wait until everything
to do with getting rpcbind going is complete. But I'm far from sure.

Kind regards
Vince

Bug#835067: libpam-passwdqc: improvements(?) to password prompting

[Vincent McIntyre]

Package: libpam-passwdqc
Version: 1.3.0-1
Severity: minor
Tags: patch

I noticed some repeated text and somewhat tortured wording in the
prompts for new passwords. Please consider the attached patch.

It defines a couple of extra text slugs to make the prompt wording
more consistent across the different password class cases, and
changes the wording to avoid constructs like this

  params.qc.min[4] == 8 || params.qc.min[4] == 11 ? "n" : "",

Kind regards,
Vince

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

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

Versions of packages libpam-passwdqc depends on:
ii  libc6   2.19-18+deb8u4
ii  libpam-runtime  1.1.8-3.1+deb8u1
ii  libpam0g1.1.8-3.1+deb8u1+b1
ii  libpasswdqc01.3.0-1

Versions of packages libpam-passwdqc recommends:
ii  passwdqc  1.3.0-1

libpam-passwdqc suggests no packages.

-- no debconf information

-- 
Define a couple of extra text fragments and use them to regularise
the password prompting. Also tweak the wording so we don't need to
decide whether 'a' or 'an' needs to be printed.

--- a/pam_passwdqc.c
+++ b/pam_passwdqc.c
@@ -69,30 +69,32 @@ typedef lo_const void *pam_item_t;
 	"\nYou can now choose the new password.\n"
 #define MESSAGE_INTRO_BOTH \
 	"\nYou can now choose the new password or passphrase.\n"
-#define MESSAGE_EXPLAIN_PASSWORD_1CLASS \
+#define MESSAGE_EXPLAIN_CHAR_CLASSES \
 	"A good password should be a mix of upper and lower case letters,\n" \
-	"digits, and other characters.  You can use a%s %d character long\n" \
-	"password.\n"
-#define MESSAGE_EXPLAIN_PASSWORD_CLASSES \
-	"A valid password should be a mix of upper and lower case letters,\n" \
-	"digits, and other characters.  You can use a%s %d character long\n" \
-	"password with characters from at least %d of these 4 classes.\n" \
+	"digits, and other characters.\n"
+#define MESSAGE_EXPLAIN_DOES_NOT_COUNT \
 	"An upper case letter that begins the password and a digit that\n" \
 	"ends it do not count towards the number of character classes used.\n"
+#define MESSAGE_EXPLAIN_PASSWORD_1CLASS \
+	MESSAGE_EXPLAIN_CHAR_CLASSES \
+	"You can use a password with %d or more characters.\n" \
+	MESSAGE_EXPLAIN_DOES_NOT_COUNT
+#define MESSAGE_EXPLAIN_PASSWORD_CLASSES \
+	MESSAGE_EXPLAIN_CHAR_CLASSES \
+	"You can enter a password with %d or more characters,\n" \
+	"with characters from at least %d of these 4 classes.\n" \
+	MESSAGE_EXPLAIN_DOES_NOT_COUNT
 #define MESSAGE_EXPLAIN_PASSWORD_ALL_CLASSES \
-	"A valid password should be a mix of upper and lower case letters,\n" \
-	"digits, and other characters.  You can use a%s %d character long\n" \
-	"password with characters from all of these classes.  An upper\n" \
-	"case letter that begins the password and a digit that ends it do\n" \
-	"not count towards the number of character classes used.\n"
+	MESSAGE_EXPLAIN_CHAR_CLASSES \
+	"You can enter a password with %d or more characters from\n" \
+	"all of these classes.\n" \
+	MESSAGE_EXPLAIN_DOES_NOT_COUNT
 #define MESSAGE_EXPLAIN_PASSWORD_ALT \
-	"A valid password should be a mix of upper and lower case letters,\n" \
-	"digits, and other characters.  You can use a%s %d character long\n" \
-	"password with characters from at least 3 of these 4 classes, or\n" \
-	"a%s %d character long password containing characters from all the\n" \
-	"classes.  An upper case letter that begins the password and a\n" \
-	"digit that ends it do not count towards the number of character\n" \
-	"classes used.\n"
+	MESSAGE_EXPLAIN_CHAR_CLASSES \
+	"You can enter password with %d or more characters from at least 3\n" \
+	"of these 4 classes, or a pasword with %d or more characters\n" \
+	"containing characters from all the classes.\n" \
+	MESSAGE_EXPLAIN_DOES_NOT_COUNT
 #define MESSAGE_EXPLAIN_PASSPHRASE \
 	"A passphrase should be of at least %d words, %d to %d characters\n" \
 	"long, and contain enough different characters.\n"
@@ -364,25 +366,20 @@ retry:
 	if (!randomonly && params.qc.min[0] == params.qc.min[4])
 		status = say(pamh, PAM_TEXT_INFO,
 		MESSAGE_EXPLAIN_PASSWORD_1CLASS,
-		params.qc.min[4] == 8 || params.qc.min[4] == 11 ? "n" : "",
 		params.qc.min[4]);
 	else if (!randomonly && params.qc.min[3] == params.qc.min[4])
 		status = say(pamh, PAM_TEXT_INFO,
 		MESSAGE_EXPLAIN_PASSWORD_CLASSES,
-		params.qc.min[4] == 8 || params.qc.min[4] == 11 ? "n" : "",
 		params.qc.min[4],
 		params.qc.min[1] != params.qc.min[3] ? 3 : 2);
 	else if (!randomonly && params.qc.min[3] == INT_MAX)
 		status = say(pamh, PAM_TEXT_INFO,
 		MESSAGE_EXPLAIN_PASSWORD_ALL_CLASSES,
-		params.qc.min[4] == 8 || params.qc.min[4] == 11 ? "n" : "",
 		params.qc.min[4]);
 	else if (!randomonly)
 		status = say(pamh, PAM_TEXT_INFO,
 		

Bug#831985: [patch] fix default for 'prio' in manpage

[Vincent McIntyre]

On Fri, Jul 22, 2016 at 10:20:54PM +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Control: tag -1 +pending, fixed-upstream
> 
> 
> Hello Vincent,
> 
> THank you for your patch and care for ensuring documentation is
> intact.
> 
> With today's release of 0.6.2, your patch did not apply. As it
> looks, all of what you reported was corrected upstream too.
> 

So what now?
 If it's fixed-upstream, you might as well close this.

Regards
Vince

Bug#831985: Acknowledgement ([patch] fix default for 'prio' in manpage)

[Vincent McIntyre]

I've found a couple of other nits that could be fixed,
see attached patch.

There was one item I was unsure about so I left it out of the patch.
The manual page says the default is

  reassign_maps = yes

but libmultipath/defaults.h says

  #define DEFAULT_REASSIGN_MAPS0

This gets used like so
multipath/config.c:  conf->reassign_maps = DEFAULT_REASSIGN_MAPS;

and in multipath/main.c:
} else if (conf->reassign_maps) {
condlog(3, "%s: Reassign existing device-mapper"
" devices", ompp->alias);
dm_reassign(ompp->alias);
}

so it looks like the code default is 'no'.

Vince
Tweaks to the manual page

Fixed default for prio, taken from libmultipath/prio.h:
  #define DEFAULT_PRIO "const"

Additions, taken from libmultipath/defaults.h
path_selector
  #define DEFAULT_SELECTOR"service-time 0"
fast_io_fail_tmo
  #define DEFAULT_FAST_IO_FAIL5

Added a pointer to the precedence rules related to queue_if_no_path.

diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
index 2ff88c4..87d5621 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -139,6 +139,8 @@ Send the next bunch of IO down the path with the least 
amount of outstanding IO.
 .B "service-time 0"
 Choose the path for the next bunch of IO based on the amount of outstanding IO
 to the path and its relative throughput.
+.TP
+Default value is \fBservice-time 0\fR.
 .RE
 .TP
 .B path_grouping_policy
@@ -217,7 +219,7 @@ Generate a random priority between 1 and 10.
 Generate the path priority based on the regular expression and the 
 priority provided as argument. requires prio_args keyword.
 .TP
-Default value is \fBnone\fR.
+Default value is \fBconst\fR.
 .RE
 .TP
 .B prio_args
@@ -256,9 +258,12 @@ Possible values for the feature list are
 .RS
 .TP 12
 .B queue_if_no_path
-Queue IO if no path is active; identical to the
+Queue IO if no path is active; identical to setting the
 .I no_path_retry
-keyword.
+keyword to 
+.I queue.
+See also \fBKNOWN ISSUES\fR.
+.
 .TP
 .B no_partitions
 Disable automatic partitions generation via kpartx.
@@ -382,7 +387,7 @@ Specify the number of seconds the scsi layer will wait 
after a problem has been
 detected on a FC remote port before failing IO to devices on that remote port.
 This should be smaller than dev_loss_tmo. Setting this to
 .I off
-will disable the timeout.
+will disable the timeout. Default is 5.
 .TP
 .B dev_loss_tmo
 Specify the number of seconds the scsi layer will wait after a problem has

Bug#831985: [patch] fix default for 'prio' in manpage

[Vincent McIntyre]

Package: multipath-tools
Version: 0.6.1-3
Priority: minor

I noticed the manpage documents the wrong default for 'prio'.
At least, it seems that way from this check:

$ grep DEFAULT_PRIO libmultipath/prio.h
#define DEFAULT_PRIO "const"
#define DEFAULT_PRIO_ARGS ""

Now that upstream ditched the example configs, having the manpage
correct is more important than before.

Kind regards
Vince

diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
 index cf5bec0..256ba76 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -190,7 +190,7 @@ Generate a random priority between 1 and 10.
 Generate the path priority based on the regular expression and the 
 priority provided as argument. requires prio_args keyword.
 .TP
-Default value is \fBnone\fR.
+Default value is \fBconst\fR.
 .RE
 .TP
 .B prio_args
-- 

Bug#831875: linux-image-3.16.0-0.bpo.4-amd64: endless "NMI backtrace" loop

[Vincent McIntyre]

Package: src:linux
Version: 3.16.7-ckt25-2+deb8u3~bpo70+1
Severity: normal

The system is running the wheezy release.

After some fibre channel multipathing issues, my system ended up
endlessly printing messages like the one below for each of 32 cpus,
every 3 sec. However the problem occurs in more common situations
than this - it sometimes occurs during boot-up, both from cold start
and warm reboot.

This seems to be worse in the 3.16 kernels, we never had issues like
this with 3.2 but had to move up to 3.16 for other issues related to
power management.

The BIOS has been adjusted to turn off all C state support,
the system runs at maximum performance.

Do you have any advice on measures to track this down more precisely?


-- Package-specific info:
** Version:
Linux version 3.16.0-0.bpo.4-amd64 (debian-ker...@lists.debian.org) (gcc 
version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.16.7-ckt25-2+deb8u3~bpo70+1 
(2016-07-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-0.bpo.4-amd64 
root=UUID=084a5068-b421-47bb-8eb3-f62516498242 ro console=ttyS0,9600n8 
console=tty0

** Not tainted


[205127.516687] NMI backtrace for cpu 28
[205127.516692] CPU: 28 PID: 0 Comm: swapper/28 Not tainted 
3.16.0-0.bpo.4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3~bpo70+1
[205127.516693] Hardware name: Dell Inc. PowerEdge R820/04K5X5, BIOS 1.5.0 
03/08/2013
[205127.516695] task: 880c0ea20310 ti: 880c0ea2c000 task.ti: 
880c0ea2c000
[205127.516697] RIP: 0010:[]  [] 
intel_idle+0xcc/0x160
[205127.516702] RSP: 0018:880c0ea2fe18  EFLAGS: 0046
[205127.516704] RAX: 0030 RBX: 0010 RCX: 
0001
[205127.516705] RDX:  RSI: 880c0ea2ffd8 RDI: 
001c
[205127.516706] RBP: 0005 R08:  R09: 
5d20
[205127.516707] R10:  R11: 0001030e17d1 R12: 
0030
[205127.516708] R13: 0004 R14: 0005 R15: 
880c0ea2c000
[205127.516710] FS:  () GS:880c3fbc() 
knlGS:
[205127.516712] CS:  0010 DS:  ES:  CR0: 80050033
[205127.516713] CR2: 7f6452f3de30 CR3: 01811000 CR4: 
000407e0
[205127.516714] Stack:
[205127.516715]   001c00f38f2d 8101e085 
e8f4003c0308
[205127.516718]  babd0c6ce19b 8189b6f0 8189b520 
8140e8e1
[205127.516720]   00f38f2d d740 
818e0540
[205127.516723] Call Trace:
[205127.516724]  [] ? read_tsc+0x5/0x20
[205127.516729]  [] ? cpuidle_enter_state+0x51/0xf0
[205127.516732]  [] ? cpu_startup_entry+0x34a/0x4b0
[205127.516736]  [] ? start_secondary+0x218/0x2d0
[205127.516739] Code: 31 d2 65 48 8b 34 25 48 b8 00 00 48 89 d1 48 8d 86 38 c0 
ff ff 0f 01 c8 48 8b 86 38 c0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <65> 48 
8b 04 25 48 b8 00 00 f0 80 a0 3a c0 ff ff df 0f ae f0 48

** Model information
sys_vendor: Dell Inc.
product_name: PowerEdge R820
product_version:
chassis_vendor: Dell Inc.
chassis_version:
bios_vendor: Dell Inc.
bios_version: 1.5.0
board_vendor: Dell Inc.
board_name: 04K5X5
board_version: A06

** Loaded modules:
autofs4
nfsd
nfsv3
nfs_acl
rpcsec_gss_krb5
auth_rpcgss
oid_registry
nfsv4
dns_resolver
nfs
lockd
sunrpc
fscache
xfs
libcrc32c
dm_round_robin
loop
dm_multipath
scsi_dh
x86_pkg_temp_thermal
intel_powerclamp
intel_rapl
coretemp
kvm_intel
kvm
crct10dif_pclmul
crc32_pclmul
ttm
drm_kms_helper
aesni_intel
drm
aes_x86_64
iTCO_wdt
mei_me
lrw
i2c_algo_bit
iTCO_vendor_support
gf128mul
sb_edac
glue_helper
lpc_ich
mei
i2c_core
ioatdma
dcdbas
mfd_core
edac_core
ablk_helper
pcspkr
evdev
joydev
processor
shpchp
acpi_pad
ipmi_si
tpm_tis
button
thermal_sys
dca
cryptd
ipmi_msghandler
wmi
acpi_power_meter
tpm
ext4
crc16
mbcache
jbd2
dm_mod
hid_generic
usbhid
hid
sg
sr_mod
cdrom
sd_mod
ehci_pci
crc_t10dif
ehci_hcd
crct10dif_common
ahci
qla2xxx
libahci
usbcore
usb_common
scsi_transport_fc
tg3
libata
megaraid_sas
scsi_tgt
ptp
crc32c_intel
scsi_mod
pps_core
libphy




Vince
-- 

Bug#810219: confirmation

[Vincent McIntyre]

We also hit this with Dell Optiplex 7040 desktops

% cat /etc/debian_version
8.5
% uname -v
#1 SMP Debian 3.16.7-ckt25-2+deb8u2 (2016-06-25)

% lspci
00:00.0 Host bridge: Intel Corporation Device 191f (rev 07)
00:01.0 PCI bridge: Intel Corporation Device 1901 (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Device 1912 (rev 06)
00:14.0 USB controller: Intel Corporation Device a12f (rev 31)
00:14.2 Signal processing controller: Intel Corporation Device a131 (rev 31)
00:16.0 Communication controller: Intel Corporation Device a13a (rev 31)
00:16.3 Serial controller: Intel Corporation Device a13d (rev 31)
00:17.0 SATA controller: Intel Corporation Device a102 (rev 31)
00:1c.0 PCI bridge: Intel Corporation Device a110 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device a146 (rev 31)
00:1f.2 Memory controller: Intel Corporation Device a121 (rev 31)
00:1f.3 Audio device: Intel Corporation Device a170 (rev 31)
00:1f.4 SMBus: Intel Corporation Device a123 (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM 
(rev 31)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 745] 
(rev a2)
01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1)
02:00.0 PCI bridge: Texas Instruments XIO2001 PCI Express-to-PCI Bridge

# lspci -n -s 00:1f.3
00:1f.3 0403: 8086:a170 (rev 31)

# lspci -vvv -s 00:1f.3
00:1f.3 Audio device: Intel Corporation Device a170 (rev 31)
Subsystem: Dell Device 06b9
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

Bug#821811: samba: badlock patch breaks trust relationship

[Vincent McIntyre]

I can confirm that after downgrading these packages

   samba samba-common samba-common-bin libwbclient0 
 smbclient samba-tools

to version 2:3.6.6-6+deb7u7 and then upgrading with

   apt-get -t santiago-wheezy install samba samba-common \
samba-common-bin libwbclient0 smbclient samba-tools

the system continued to work without issue; it remained joined to
the domain and users could connect as normal.

Note that this system was not running winbind, it was not installed.

Vince

Bug#823372: winbind: segfault on first login attempt

[Vincent McIntyre]

Package: winbind
Version: 2:3.6.6-6+deb7u9
Severity: normal

possibly-related bugs: 820981

We have not used winbind in our setup until the badlock patches
came along (2:3.6.6-6+deb7u9). We follwed the recommendation in
#820981. The environment is MS AD, we are running a "member server"
serving a few shares. There are no Samba DCs.

When I restart winbind, and then attempt to authenticate with
smbclient on a different host, the first attempt fails, but the
second attempt succeeds.  The impact of this for us is minor but
I thought I should report the issue.

The first attempt fails with this error message
% smbclient //myserv/myshare -U joe
Enter joe's password: 
session setup failed: NT_STATUS_MORE_PROCESSING_REQUIRED
did you forget to run kinit?

The backtrace that came via email is shown below.
Also the contents of log.wb-CORP at the time the segfault occurs.

The second connection attempt succeeds with no errors.

Other observations.

When I restart winbind, and on the first connection attempt
I hit  (i.e. enter a null password)
I get a normal NT_STATUS_ACCESS_DENIED error and no segfault.
If I then try again, actually entering a password, the segfault occurs.

When I restart winbind, and on the first connection attempt
I enter the wrong password
I get a normal NT_STATUS_ACCESS_DENIED error and no segfault.
If I then try again, actually entering a password, the segfault occurs.

I guess these are the same case and handled before reaching
the segfaulting code.

Kind regards
Vince

-- testparm -s output: ---
[global]
workgroup = CORP
realm = CORP.COM
server string =  %h UNIX Server (Samba %v)
security = DOMAIN
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n 
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
ntlm auth = No
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
name resolve order = host wins
client signing = required
deadtime = 10
lpq cache time = 20
printcap name = cups
os level = 24
domain master = No
dns proxy = No
wins server = 1.2.3.4, 1.2.4.4, 1.2.5.4
panic action = /usr/share/samba/panic-action %d
winbind use default domain = Yes
idmap config * : backend = tdb
create mask = 0600
directory mask = 0700
hosts allow = 1.2.3.0/255.255.255.0, 1.2.4.0/255.255.255.0, 
1.2.5.0/255.255.255.0
case sensitive = No
blocking locks = No
strict locking = No


-- backtrace.txt -

The Samba 'panic action' script, /usr/share/samba/panic-action,
was called for PID 32399 (/usr/sbin/winbindd).

This means there was a problem with the program, such as a segfault.
Below is a backtrace for this process generated with gdb, which shows
the state of the program at the time the error occurred.  The Samba log
files may contain additional information about the problem.

If the problem persists, you are encouraged to first install the
samba-dbg package, which contains the debugging symbols for the Samba
binaries.  Then submit the provided information as a bug report to
Debian.  For information about the procedure for submitting bug reports,
please see http://www.debian.org/Bugs/Reporting or the reportbug(1)
manual page.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f9b57f80a3e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x7f9b57f80a3e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f9b57f12949 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7f9b5acb0ba9 in smb_panic (why=why@entry=0x7f9b5b07716e "internal 
error") at lib/util.c:1123
#3  0x7f9b5aca1d34 in fault_report (sig=) at lib/fault.c:53
#4  sig_fault (sig=) at lib/fault.c:76
#5  
#6  cm_connect_lsa_tcp (domain=domain@entry=0x7f9b5bb83e30, 
mem_ctx=mem_ctx@entry=0x7f9b5bbc4400, cli=cli@entry=0x7fff59308b18) at 
winbindd/winbindd_cm.c:2420
#7  0x7f9b5abf116e in winbindd_lookup_sids 
(mem_ctx=mem_ctx@entry=0x7f9b5bbc4400, domain=domain@entry=0x7f9b5bb83e30, 
num_sids=num_sids@entry=1, sids=0x7f9b5bbc2910, 
domains=domains@entry=0x7fff59308ba0, names=names@entry=0x7fff59308ba8, 
types=types@entry=0x7fff59308bb0) at winbindd/winbindd_msrpc.c:1093
#8  0x7f9b5abf1520 in msrpc_sid_to_name (domain=0x7f9b5bb83e30, 
mem_ctx=0x7f9b5bbc4400, sid=, domain_name=0x7fff59308cc0, 
name=0x7fff59308cc8, type=0x7fff59308cbc) at winbindd/winbindd_msrpc.c:295
#9  0x7f9b5abf3e24 in sid_to_name (domain=0x7f9b5bb83e30, 
mem_ctx=0x7f9b5bbc4400, sid=0x7f9b5bbc2910, domain_name=0x7fff59308cc0, 
name=0x7fff59308cc8, type=) at winbindd/winbindd_reconnect.c:162
#10 0x7f9b5abf40ee in sid_to_name (domain=, 
mem_ctx=, sid=, domain_name=, 
name=, 

Bug#784743: updated patch

[Vincent McIntyre]

Tags: patch

The perl patching command given by Edmund results in this change:

--- debian/patches/linker-specific-changes.orig 2011-11-19 16:45:51.0
+1100
+++ debian/patches/linker-specific-changes  2015-08-03 14:16:16.518331208
+1000
@@ -65,7 +65,7 @@
  grtv00.o : $(DRVDIR)/imdef.h
  pgxwin.o : $(DRVDIR)/pgxwin.h
 -pndriv.o : ./png.h ./pngconf.h ./zlib.h ./zconf.h
-+pndriv.o : /usr/include/png.h /usr/include/pngconf.h /usr/include/zlib.h
/usr/include/zconf.h
++pndriv.o :
  
  x2driv.o figdisp_comm.o: $(DRVDIR)/commands.h
  

zconf.h moved from /usr/include/ to /usr/include/arch-os-compiler/
e.g. /usr/include/x86_64-linux-gnu/zconf.h.

I think what is needed here is a revised version of

   debian/patches/linker-specific-changes

which I have attached to this message.
  
-- 
Description: correct linker variables
 This patch set sets all the linker-specific variables correctly

---

Last-Update: 2011-11-18

Index: pgplot5-5.2.2/makemake
===
--- pgplot5-5.2.2.orig/makemake
+++ pgplot5-5.2.2/makemake
@@ -658,6 +658,8 @@ CPGPLOT_LIB=$CPGPLOT_LIB
 #
 SHARED_LIB=$SHARED_LIB
 SHARED_LD=$SHARED_LD
+SHARED_LD_PGPLOT_OPTS=$SHARED_LD_PGPLOT_OPTS
+SHARED_LD_CPGPLOT_OPTS=$SHARED_LD_CPGPLOT_OPTS
 #
 # The libraries that the shared PGPLOT library depends upon.
 # This is for systems that allow one to specify what libraries
@@ -667,6 +669,7 @@ SHARED_LD=$SHARED_LD
 # libraries when they link their executables.
 #
 SHARED_LIB_LIBS=$SHARED_LIB_LIBS
+SHARED_LIB_CPGPLOT_LIBS=$SHARED_LIB_CPGPLOT_LIBS
 #
 # Ranlib command if required
 #
@@ -806,7 +809,8 @@ grexec.o: grexec.f
 # libraries.
 #---
 
-lib : libpgplot.a $(SHARED_LIB)
+#lib : libpgplot.a $(SHARED_LIB)
+lib : libpgplot.a
 
 libpgplot.a : $(PG_ROUTINES) $(PG_NON_STANDARD) $(GR_ROUTINES) \
   $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES)
@@ -816,6 +820,16 @@ libpgplot.a : $(PG_ROUTINES) $(PG_NON_ST
$(DRIVERS) $(SYSTEM_ROUTINES) | sort | uniq`
$(RANLIB) libpgplot.a
 
+#shared: $(PG_ROUTINES) $(PG_NON_STANDARD) $(GR_ROUTINES) \
+# $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES)
+# $(SHARED_LD)
+
+shared: $(PG_ROUTINES) $(PG_NON_STANDARD) \
+   $(GR_ROUTINES) $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES)
+   $(SHARED_LD) $(SHARED_LD_PGPLOT_OPTS) `ls $(PG_ROUTINES) \
+   $(PG_NON_STANDARD) $(GR_ROUTINES) $(DISPATCH_ROUTINE) \
+   $(DRIVERS) $(SYSTEM_ROUTINES) | sort | uniq` $(SHARED_LIB_LIBS)
+
 EOD
 
 # Emit the shared library dependency if requested.
@@ -824,7 +838,7 @@ if test -n $SHARED_LIB -a -n $SHARED_
 cat  makefile  \EOD
 $(SHARED_LIB): $(PG_ROUTINES) $(PG_NON_STANDARD) \
$(GR_ROUTINES) $(DISPATCH_ROUTINE) $(DRIVERS) $(SYSTEM_ROUTINES)
-   $(SHARED_LD) `ls $(PG_ROUTINES) \
+   $(SHARED_LD) $(SHARED_LD_PGPLOT_OPTS) `ls $(PG_ROUTINES) \
$(PG_NON_STANDARD) $(GR_ROUTINES) $(DISPATCH_ROUTINE) \
$(DRIVERS) $(SYSTEM_ROUTINES) | sort | uniq` $(SHARED_LIB_LIBS)
 EOD
@@ -1019,13 +1033,15 @@ EOD
 
 cat  makefile  \EOD
 
+DEB_HOST_MULTIARCH=$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
 # Miscellaneous include files required by drivers
 
 griv00.o : $(DRVDIR)/gadef.h $(DRVDIR)/gmdef.h $(DRVDIR)/gphdef.h
 grivas.o : $(DRVDIR)/gadef.h
 grtv00.o : $(DRVDIR)/imdef.h
 pgxwin.o : $(DRVDIR)/pgxwin.h
-pndriv.o : ./png.h ./pngconf.h ./zlib.h ./zconf.h
+pndriv.o : /usr/include/png.h /usr/include/pngconf.h /usr/include/zlib.h 
/usr/include/$(DEB_HOST_MULTIARCH)/zconf.h
 
 x2driv.o figdisp_comm.o: $(DRVDIR)/commands.h
 
@@ -1039,6 +1055,8 @@ cpg:  libcpgplot.a cpgplot.h cpgdemo
@echo 'will be needed.'
@echo ' '
 
+cpg-shared: libcpgplot.so
+
 pgbind: $(SRC)/cpg/pgbind.c
$(CCOMPL) $(CFLAGC) $(SRC)/cpg/pgbind.c -o pgbind
 
@@ -1050,6 +1068,13 @@ libcpgplot.a cpgplot.h: $(PG_SOURCE) pgb
$(RANLIB) libcpgplot.a
rm -f cpg*.o
 
+libcpgplot.so: $(PG_SOURCE) pgbind
+   ./pgbind $(PGBIND_FLAGS) -w $(PG_SOURCE)
+   $(CCOMPL) -c $(CFLAGC) cpg*.c
+   rm -f cpg*.c
+   $(SHARED_LD) $(SHARED_LD_CPGPLOT_OPTS) cpg*.o $(SHARED_LIB_CPGPLOT_LIBS)
+   rm -f cpg*.o
+
 cpgdemo: cpgplot.h $(SRC)/cpg/cpgdemo.c libcpgplot.a
$(CCOMPL) $(CFLAGD) -c -I. $(SRC)/cpg/cpgdemo.c
$(FCOMPL) -o cpgdemo cpgdemo.o $(CPGPLOT_LIB) $(LIBS)

Bug#789604: release-notes: 'halt' behaviour changed without notice

[Vincent McIntyre]

On Thu, Jun 25, 2015 at 11:38:58AM +0100, Justin B Rye wrote:
 Vincent McIntyre wrote:
  I'm submitting this patch on the advice of the systemd maintainers.
  Could this be applied to the jessie release notes?
 
 It's good, but I've got a couple of English usage nitpicks:

And I'm happy to have you pick the nits off my contribution :)
Would you care to peruse #789652, which is related?

 Index: en/issues.dbk
 ===
 --- en/issues.dbk (revision 10955)
 +++ en/issues.dbk (working copy)
 @@ -586,7 +586,21 @@
  bug #784720/ulink
/para
  /section
 +section id=systemd-halt-behavior
 +  !-- Wheezy to Jessie (#760923) --
 +  titlesystemd: behavior of 'halt' command/title
 +  para
 +The systemitem role=packagesysvinit/systemitem implementation
 +of the commandhalt/command command powered off the machine as well.
 +The systemitem role=packagesystemd-sysv/systemitem implementation
 +halts the system, but does not power off the machine. To halt the
 +machine and turn it off, use the commandpoweroff/command command.
 +  /para
 +  para
 +See also ulink url=url-bts;760923Debian bug #760923/ulink
 +  /para
  /section
 +/section
  
  section id=required-kernel-config-options
!-- Wheezy to Jessie --

This version looks good enough to commit.

Thanks
Vince
-- 


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

Bug#789652: v2 patch

[Vincent McIntyre]

On Thu, Jun 25, 2015 at 05:51:02PM +0100, Justin B Rye wrote:
 Vincent McIntyre wrote:
  Justin B Rye wrote:
  It's good, but I've got a couple of English usage nitpicks:
  
  And I'm happy to have you pick the nits off my contribution :)
  Would you care to peruse #789652, which is related?
 
 Hmm, well, I've never proofread the installation-guide as a whole.  I
 ought to get round to doing that some time.
 
 Okay, your patch introduces another example of un-American behaviour,
 but I would actually suggest rephrasing that bit: it's not obvious
 what newly introduced behavio(u)r it's talking about.
 
 Also, it's not strictly true that it was introduced by systemd in
 Jessie.  Distinguishing halt from poweroff was already a feature of
 systemd on Wheezy - and Upstart too, unless I'm misreading
 https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/532366;.
 
 So:
 
  [...]
  Use commandreboot/command to reboot the system.
  Use commandhalt/command to halt the system without powering it off
  footnote
  
  para
   Under the SysV init system commandhalt/command had the same
   effect as commandpoweroff/command, but with systemd as init
   system (the default in jessie) their effects are different.
  /para
 
  /footnote.
  To power off the machine, use commandpoweroff/command or
  commandshutdown -h now/command.
 
 (and drop the final sentence about systemctl).
 
 I use SysV init and systemd above because we don't mean
 packagesysvinit/package or (especially)
 packagesystemd/package, we mean those software frameworks as a
 whole, referred to by brand name.  And it's jessie because we
 don't mean whatever releasename; currently resolves to, we mean
 Debian 8 (and using lowercase because apparently releasename; follows
 that standard).

Thanks for the review Justin. I agree with most of your comments.
I do think it is important to mention systemctrl because things like
/sbin/reboot are implemented as symlinks to /bin/systemctrl.

version 2:

Index: post-install/shutdown.xml
===
--- post-install/shutdown.xml   (revision 69984)
+++ post-install/shutdown.xml   (working copy)
@@ -21,11 +21,26 @@
 keycapCtrl/keycap keycapAlt/keycap keycapDel/keycap /keycombo
 phrase arch=powerpc or keycombo keycapControl/keycap
 keycapShift/keycap keycapPower/keycap /keycombo on Macintosh
-systems/phrase. A last option is to log in as root and type one of the
-commands commandpoweroff/command, commandhalt/command or
-commandshutdown -h now/command if either of the key combinations do not
-work or you prefer to type commands; use commandreboot/command to reboot
-the system.
+systems/phrase.
+If the key combinations do not work, a last option is to log in as root
+and type the necessary commands.
+Use commandreboot/command to reboot the system.
+Use commandhalt/command to halt the system without powering it off
+footnote
 
+ para
+  Under the SysV init system commandhalt/command had the same
+  effect as commandpoweroff/command, but with systemd as init
+  system (the default in jessie) their effects are different.
+ /para
+
+/footnote.
+To power off the machine, use commandpoweroff/command
+or commandshutdown -h now/command.
+The systemd init system provides additional commands that perform
+the same functions; for example commandsystemctl reboot/command
+or commandsystemctl poweroff/command.
+
+
 /para
  /sect1


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

Bug#760923: tentative patch

[Vincent McIntyre]

On Wed, Jun 24, 2015 at 09:47:35PM +0200, Marco d'Itri wrote:
 On Jun 23, Martin Pitt mp...@debian.org wrote:
 
  This sounds confusing -- systemd has never changed the behaviour of
  halt; sysvinit misimplemented halt, so the change is between
  changing init systems, not upgrading any particular version.

 I think that either we can update the release notes for jessie or there 
 is no point in clarifying this since most Debian systems (and almost 
 all jessie systems) already use systemd and show this behaviour.
 

I've opened #789652 for installation-guide but no responses yet.
Perhaps the release notes need this as well, I'll send a note to
debian-boot. Thanks for your advice.

Vince


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

Bug#789604: release-notes: 'halt' behaviour changed without notice

[Vincent McIntyre]

Package: release-notes
Tags: patch
thanks

Hi,
I'm submitting this patch on the advice of the systemd maintainers.
Could this be applied to the jessie release notes?

I sent a separate patch for the installation-guide, #789652
Cheers
Vince

Index: issues.dbk
===
--- issues.dbk  (revision 10955)
+++ issues.dbk  (working copy)
@@ -586,7 +586,22 @@
 bug #784720/ulink
   /para
 /section
+section id=systemd-halt-behaviour
+  !-- Wheezy to Jessie (#760923) --
+  titlesystemd: behaviour of 'halt' command/title
+  para
+The systemitem role=packagesysvinit/systemitem implementation
+of the commandhalt/command command powered off the machine as well.
+The systemitem role=packagesystemd-sysv/systemitem implementation
+of the commandhalt/command halts the system, but does not power off
+the machine. To halt the machine and turn it off,
+use the commandpoweroff/command command.
+  /para
+  para
+See also ulink url=url-bts;760923Debian bug #760923/ulink
+  /para
 /section
+/section
 
 section id=required-kernel-config-options
   !-- Wheezy to Jessie --
-- 


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

Bug#789604: release-notes: 'halt' behaviour changed without notice

[Vincent McIntyre]

Control: tag 789604 patch


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

Bug#760923: tentative patch

[Vincent McIntyre]

On Tue, Jun 23, 2015 at 02:24:10AM +0200, Marco d'Itri wrote:
 On Jun 23, Vincent McIntyre vincent.mcint...@csiro.au wrote:
 
  +systemd (221-1) UNRELEASED; urgency=medium
 This has not changed in 221: even if we really want to document this in 
 NEWS.Debian then the message must not be displayed to everybody who has 
 already installed a version of systemd which has this behaviour.
 

Thanks for the reply.
My intention was mainly to supply some text that might be helpful.

I see the problem with using the NEWS file so naively.
Would README.Debian be sufficient (patch below)? 
If not, I don't know how to implement a warning displayed only
to those without systemd already installed.

index 1090041..8efb73c 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -46,3 +46,13 @@ see what's currently being run, or systemctl to find units 
which are not in
 the expected state (e. g. failed for boot or still active during shutdown),
 and then get more detailled information with systemctl status -l foo.service
 to get a service foo's status and recent logging.
+
+The behaviour of 'halt' has changed
+===
+
+systemd changes the behaviour of the 'halt' command.
+This command halts the machine but no longer turns off the power -
+to do that, use 'shutdown -h' or 'poweroff'.
+The old behaviour is regarded as a bug by upstream and won't be changed
+in this package, so as to maintain compatibility with other Linux distros.
+

Kind regards
Vince


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

Bug#760923: tentative patch

[Vincent McIntyre]

On Tue, Jun 23, 2015 at 09:58:28AM +0200, Martin Pitt wrote:
 
 This sounds confusing -- systemd has never changed the behaviour of
 halt; sysvinit misimplemented halt, so the change is between
 changing init systems, not upgrading any particular version.
 
 How about something like
 
 halt behaviour
 
 Under SysV init the halt command erroneously powered off the
 machine, same as poweroff. Under systemd the halt command does not
 turn off the power -- to do that, use shutdown -h or poweroff.
 

I agree my attempt was sub-optimal. I'm still getting my head round systemd.
What you suggest will do the job fine, as far as I can see.

Cheers
Vince


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

Bug#760923: tentative patch

[Vincent McIntyre]

Tags: patch
thanks mate

diff --git a/debian/systemd-sysv.NEWS b/debian/systemd-sysv.NEWS
new file mode 100644
index 000..07b
--- /dev/null
+++ b/debian/systemd-sysv.NEWS
@@ -0,0 +1,9 @@
+systemd (221-1) UNRELEASED; urgency=medium
+
+  * systemd changes the behaviour of the 'halt' command.  
+This command halts the machine but no longer turns off the power -
+use shutdown -h or poweroff for that.
+The old behaviour is regarded as a bug by upstream and won't be changed
+in this package so as to maintain compatibility with other Linux distros.
+
+ -- Vincent McIntyre vincent.mcint...@csiro.au  Tue, 23 Jun 2015 08:53:39 
+1000


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

Bug#760923: tentative patch

[Vincent McIntyre]

Control: tag 760923 patch


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