Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Mike Miller]

On Fri, Dec 04, 2020 at 18:06:22 -0500, Brendon Higgins wrote:
> The culprit is libreadline8 (and/or readline-common). Octave GUI has no 
> complaints with the prior version 8.0-4, but after upgrading to version 
> 8.1~rc3-1, Octave GUI now complains about "undecodable token: \001b(hex)[?
> 2004h" and messes-up the command interface, as per the original report.
> 
> So, does libreadline8 cause this "bracketed paste mode" to be enabled by 
> default, now? Or perhaps something else is going on - like, perhaps /etc/
> inputrc should have been updated along with readline-common, in which case 
> we're actually getting bitten by bug #504793?

Yes, Readline version 8 enables this setting by default without any
inputrc changes.

If you only use Octave in GUI mode, you might want to use the ~/.inputrc
snippet that Rafael mentioned earlier.

Octave version 6 has modified the GUI command window to silently ignore
these escapes to suppress the "undecodable token" messages.

-- 
mike

Bug#960728: openblas: please consider adding openblas_get_config() to libblas.so.3

[Mike Miller]

Source: openblas
Version: 0.3.9+ds-1
Severity: wishlist

Dear Maintainer,

Please consider including the 'openblas_get_config' extension function
in the libblas.so.3 shared library provided by all OpenBLAS flavors.

In previous versions of the libopenblas-base library package, it was
possible to have a program dynamically load libblas.so.3, then use dlsym
to look for the symbol 'openblas_get_config' to determine if OpenBLAS
was being used and display the version and configuration. As an example,
Octave uses this to determine if the BLAS library in use is OpenBLAS or
MKL or ATLAS or something else. This is no longer possible.

I also plan on adding a fallback to Octave to look for other OpenBLAS
symbols, so it can at least report that it's *some* OpenBLAS.

Thanks for all the great work maintaining OpenBLAS.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#959009: rlwrap: fails to build reproducibly when varying the cpu count

[Mike Miller]

Source: rlwrap
Version: 0.43-1
Severity: wishlist

The configure stage gives different results when running on a system
with one CPU or with multiple CPUs. The reason is a configure feature
test that runs a program in the background and then checks to see that
its state has changed. In a single CPU build environment, it's likely
that the background process is not scheduled, and the check fails.

The feature test could be patched to give hardcoded known answers for
Debian archs, or the test could be completely rewritten to be robust to
changes in the number of CPUs or task scheduling.

No patch at the moment to do either, open to suggestions or patches.

-- 
mike

Bug#925081: Patch didn't add Global Protect to the -gnome packages drop down.

[Mike Miller]

On Thu, Mar 12, 2020 at 08:55:08 +, Luca Boccassi wrote:
> Sure, I'm very happy to help co-maintain as I need this for $dayjob so
> I've got a vested interest. 
> 
> Would you like help with openconnect too?

Yes please!

-- 
mike


signature.asc
Description: PGP signature

Bug#925081: Patch didn't add Global Protect to the -gnome packages drop down.

[Mike Miller]

On Thu, Feb 27, 2020 at 17:12:19 +, Luca Boccassi wrote:
> Any chances we could get 1.2.4-3 uploaded to unstable, so that it can
> sync to Ubuntu?

Please feel free to upload a zero delay nmu to make this happen.

Are you interested in taking over maintenance or co-maintenance? If so,
please also feel free to add yourself to Maintainer or Uploaders.

Thanks,

-- 
mike


signature.asc
Description: PGP signature

Bug#951789: devscripts: origtargz --unpack fails trying to unpack a .asc upstream signature

[Mike Miller]

Package: devscripts
Version: 2.20.2
Severity: normal

Dear Maintainer,

When unpacking the upstream source with origtargz --unpack, the command
fails when an upstream signature file exists.

Example:

$ apt source grep
$ cd grep-3.4
$ origtargz --unpack
Using existing ../grep_3.4.orig.tar.xz
Unpacking ../grep_3.4.orig.tar.xz
Unpacking ../grep_3.4.orig.tar.xz.asc
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
unpacking ../grep_3.4.orig.tar.xz.asc failed

Thanks for your work on this package.

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.38-4
ii  gnupg 2.2.19-1
ii  gpgv  2.2.19-1
ii  libc6 2.29-9
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-2
ii  libmoo-perl   2.003006-1
ii  libwww-perl   6.43-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-9
ii  python3   3.7.5-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.4
pn  at  
ii  curl7.67.0-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2019.12.23
ii  dput-ng [dput]  1.29
ii  equivs  2.2.0
ii  libdistro-info-perl 0.23
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.23-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.42-1
ii  lintian 2.49.0
ii  man-db  2.9.0-2
ii  patch   2.7.6-6
ii  python3-apt 1.8.5
ii  python3-debian  0.1.36
ii  python3-magic   2:0.4.15-3
ii  python3-requests2.22.0-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.26-1
ii  strace  4.26-0.2
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.11
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1+b1
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.9
pn  devscripts-el
ii  diffoscope   136
ii  disorderfs   0.5.8-2
ii  dose-extra   5.0.1-14+b2
pn  duck 
ii  faketime 0.9.7-3
ii  gnuplot  5.2.8+dfsg1-1
ii  gnuplot-qt [gnuplot] 5.2.8+dfsg1-1
ii  how-can-i-help   16
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3100-1
ii  libyaml-syck-perl1.31-1+b2
ii  mailutils [mailx]1:3.7-2
ii  mozilla-devscripts   0.54
ii  mutt 1.13.2-1
ii  openssh-client [ssh-client]  1:8.1p1-5
ii  piuparts 1.1.1
pn  postgresql-client
ii  quilt0.65-3
pn  ratt 
ii  reprotest0.7.12
ii  svn-buildpackage 0.8.7
ii  w3m  0.5.3-37+b1

-- no debconf information

Bug#950699: ubuntu-dev-tools: mk-sbuild --type=file creates a root directory owned by $USER

[Mike Miller]

Package: ubuntu-dev-tools
Version: 0.175
Severity: normal

Dear Maintainer,

The `mk-sbuild --type=file` command creates a chroot in the form of a
compressed tar archive. The root directory inside the tar is owned by
the user that ran mk-sbuild, but should be owned by the root user.

This appears to be because mk-sbuild creates the root directory with
`mktemp -d` without using sudo.

Thanks.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ubuntu-dev-tools depends on:
ii  binutils2.33.90.20200122-2
ii  dctrl-tools 2.24-3+b1
ii  devscripts  2.19.7
ii  diffstat1.63-1
ii  distro-info 0.23
ii  dpkg-dev1.19.7
ii  lsb-release 11.1.0
ii  perl5.30.0-9
ii  python3 3.7.5-3
ii  python3-apt 1.8.5
ii  python3-debian  0.1.36
ii  python3-distro-info 0.23
ii  python3-httplib20.14.0-1
ii  python3-launchpadlib1.10.9-1
ii  python3-lazr.restfulclient  0.14.2-2
ii  python3-ubuntutools 0.175
ii  sensible-utils  0.0.12+nmu1
ii  sudo1.8.29-1

Versions of packages ubuntu-dev-tools recommends:
ii  brz [bzr]3.0.1-6
ii  brz-debian   2.8.32
ii  ca-certificates  20190110
ii  debian-archive-keyring   2019.1
ii  debian-keyring   2019.12.23
ii  debootstrap  1.0.116
ii  dput-ng [dput]   1.29
ii  genisoimage  9:1.1.11-3.1
ii  libwww-perl  6.43-1
ii  lintian  2.48.0
ii  patch2.7.6-6
ii  python3-debianbts3.0.2
ii  python3-dns  3.2.1-1
ii  quilt0.65-3
ii  reportbug7.6.0
ii  sbuild   0.78.1-2
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

Versions of packages ubuntu-dev-tools suggests:
ii  qemu-user-static  1:4.2-1

-- no debconf information

Bug#936806: koji: Python2 removal in sid/bullseye

[Mike Miller]

On Thu, Jan 30, 2020 at 01:36:33 -0500, Sandro Tosi wrote:
> yep i came across all of them starting from python-lzma -- do you know
> what's the status of the "RedHat infrastructure" in debian? many (if
> not all) of those tools are relatively old, not maintained (or just in
> life support mode) and most of all, python2 with no port to python3
> available

Yeah. I was responsible for some of these, but put them up for adoption
about a year ago. You've about captured the status, all rpm-related
packages in Debian are old, unmaintained, Python 2 only. Updating to
Python 3 ports of mock and koji need dnf, yum is abandonware.

I've seen a couple threads about packaging dnf (likely not archived),
but so far no one has committed enough to file an ITP.

There _is_ an ITP for createrepo-c (#912338), a C-only reimplementation,
also a koji dependency, but looks like it may have stalled.

-- 
mike


signature.asc
Description: PGP signature

Bug#940871: openconnect: diff for NMU version 8.02-1.1

[Mike Miller]

On Sat, Jan 18, 2020 at 23:54:53 +0100, Salvatore Bonaccorso wrote:
> I've prepared an NMU for openconnect (versioned as 8.02-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Seems fine to me, thank you!

-- 
mike


signature.asc
Description: PGP signature

Bug#944935: deltarpm: diff for NMU version 3.6+dfsg-1.1

[Mike Miller]

On Mon, Nov 18, 2019 at 20:06:44 -0500, Boyuan Yang wrote:
> I've prepared an NMU for deltarpm (versioned as 3.6+dfsg-1.1) and
> uploaded it to DELAYED/1. Please feel free to tell me if I
> should delay it longer.

No, please continue, thank you for taking care of it. Also feel free to
push a branch to salsa if you have permission.

-- 
mike


signature.asc
Description: PGP signature

Bug#943528: gpaste: 'gpaste-client upload' depends on missing command 'wgetpaste'

[Mike Miller]

Package: gpaste
Version: 3.34.1-1
Severity: normal

Dear Maintainer,

The `gpaste-client upload` command has a hard dependency on a command
called `wgetpaste`, which is expected to be an executable in the user's
PATH. This command is not packaged in Debian as far as I can tell.

The error message looks like this

  Oct 25 11:40:36 localhost gpaste-daemon[17913]: 
g_subprocess_communicate_utf8_async: assertion 'G_IS_SUBPROCESS (subprocess)' 
failed

The package `pastebinit` _is_ packaged in Debian and seems to work as a
drop in replacement. The only requirement seems to be a program that
takes text on stdin and writes out a URL on stdout. This could be solved
with a one line patch and a Suggests: pastebinit.

However, maybe it would make sense for the user to be able to configure
whatever script they want to use to upload text to a pastebin service?

And moreover, maybe this should be disabled by default until the user
explicitly opts in and chooses a paste upload handler and service?

I am open to proposing patches or working with upstream if you think
this should be worked out there instead of Debian patches.

Thanks for maintaining this package!

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gpaste depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  libc62.29-2
ii  libglib2.0-0 2.62.1-1
ii  libgpaste11  3.34.1-1
ii  libgtk-3-0   3.24.12-1

gpaste recommends no packages.

gpaste suggests no packages.

-- no debconf information

Bug#941782: gir1.2-gnomedesktop-3.0 3.34.0-2 breaks gnome-shell

[Mike Miller]

Package: gir1.2-gnomedesktop-3.0
Version: 3.34.0-2
Followup-For: Bug #941782

Affected by this today, gnome-shell is completely non-functional with
the version of gir1.2-gnomedesktop-3.0 now in testing. Confirm that
installing the stable version of the package (3.30.2.1-2) restores it.

-- 
mike

Bug#938874: yum-metadata-parser: Python2 removal in sid/bullseye

[Mike Miller]

On Sun, Sep 22, 2019 at 00:51:34 +0900, Kentaro Hayashi wrote:
> I'm not familiar with yum-metadata-parser at all, but
> I'm not willing to remove createrepo (it depends yum-metadata-parser)
> So, I've tried to fix this issue by adding python3 version.

Adding Python 3 support to yum-metadata-parser will not have much of an
impact. But if you want to proceed with an nmu or adopt this package,
feel free, this package is up for adoption, as well as createrepo.

Much more helpful long term would be to contribute to getting
createrepo_c (#912338) and dnf (no ITP yet) into Debian so these Python
2 packages can be dropped.

-- 
mike


signature.asc
Description: PGP signature

Bug#938875: yum-utils: Python2 removal in sid/bullseye

[Mike Miller]

On Fri, Sep 06, 2019 at 23:34:22 +0200, Thomas Goirand wrote:
> And then I believe yum should also be removed. Your thoughts?

Yes, fully agree.

cheers,

-- 
mike

Bug#936341: createrepo: Python2 removal in sid/bullseye

[Mike Miller]

Control: block -1 with 912338

The upstream replacement for createrepo is createrepo_c. There is
already an ITP filed, set as blocking for this bug.

The reverse dependencies of createrepo are src:koji, src:mock, and
src:open-build-service. All three packages appear to me to already
prefer createrepo_c over createrepo when it is available. So once
createrepo_c is in Debian and those packages have their dependencies
updated, createrepo can be removed.

-- 
mike

Bug#938875: yum-utils: Python2 removal in sid/bullseye

[Mike Miller]

The upstream replacement for the combination of yum + yum-utils (Python
2 only) is dnf (Python 3).

The only reverse dependency of yum-utils is mock. It looks like the
version of mock already in Debian supports either dnf or yum. Once dnf
is in Debian, mock can drop the dependency on yum and yum-utils, and
yum-utils can be removed.

-- 
mike

Bug#912338: ITP: createrepo-c -- tool to create RPM repository metadata (C implementation)

[Mike Miller]

On Tue, Oct 30, 2018 at 16:40:18 +0200, Peter Pentchev wrote:
> I intend to package this tool since it seems to be the preferred
> alternative to the already packaged createrepo Python tool (and many
> thanks to Mike Miller for maintaining that package!) in at least
> the Fedora RPM packaging community.  Thus it might be useful for people
> maintaining their own repositories of RPM-packaged software; there is
> no reason not to be able to do that on a Debian system :)

Hey Peter,

How is your work on this package going? Do you need any help? I am
interested in seeing this completed so that createrepo can be cleanly
removed from the archive.

-- 
mike

Bug#875701: mockchain should depend on createrepo-c

[Mike Miller]

Control: block -1 with 912338

On Mon, Dec 03, 2018 at 17:24:38 +0100, Pierre-Francois CARPENTIER wrote:
> It adds createrepo as a dependency. It also adds python3-requests which is
> also missing.

Note that createrepo is now facing removal from the archive because of
the Python 2 removal effort. It is essentially replaced upstream by
createrepo_c. A far better fix here would be to depend on createrepo-c
after it is packaged.

-- 
mike

Bug#938998: gitpkg: please add git-debcherry to package description

[Mike Miller]

Package: gitpkg
Version: 0.29
Severity: wishlist
Tags: patch

Dear Maintainer,

Please add a git-debcherry summary description to the package
description. Adding the name of the command and its summary will help in
discovery, for example with `apt search debcherry`.

I think it would be ideal if the command summaries in Description were
taken verbatim from the man pages. I also prefer the imperative mood in
the man pages to the indicative mood used currently. I've attached a
patch that does this. However, I find the gitpkg man summary harder to
understand, maybe a new combination of the two could be used in both
places?

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gitpkg depends on:
ii  dpkg-dev  1.19.7
ii  git   1:2.23.0-1

gitpkg recommends no packages.

Versions of packages gitpkg suggests:
ii  devscripts  2.19.6
diff --git a/debian/control b/debian/control
index 040ac8080113..81e908286d21 100644
--- a/debian/control
+++ b/debian/control
@@ -15,8 +15,9 @@ Description: tools for maintaining Debian packages with git
  This package provides tools and automation to assist with maintaining Debian
  packages in git.
  .
-  gitpkg- creates a source package from specified repository versions.
-  git-debimport - creates a git repository from a set of existing packages.
+  gitpkg- export a Debian source package from nominated git revisions
+  git-debcherry - export commits touching upstream source as patches
+  git-debimport - create a git repository from a set of existing Debian 
packages
  .
  No particular repository layout is required for gitpkg to export source from
  it, existing repositories should require no modification.  If there is a valid

Bug#933300: libocatve-dev should not depend on a toolchain

[Mike Miller]

Hi Helmut, Rafael,

On Mon, Jul 29, 2019 at 00:15:39 +0200, Rafael Laboissière wrote:
> * Helmut Grohne  [2019-07-28 22:32]:
> 
> >  Package: liboctave-dev
> >  Version: 4.4.1-6
> >  Tags: patch
> >  User: debian-cr...@lists.debian.org
> >  Usertags: cross-satisfiability
> >  Control: affects -1 + src:mathgl
> > 
> > mathgl fails to satisfy its cross Build-Depends, because its dependency
> > on liboctave-dev is not satisfiable. liboctave-dev depends on toolchain
> > packages such as gcc, g++ or gfortran. This is very unusual. Most
> > commonly, C-libraries can depend on other C-libraries, but users are
> > expected to install their desired toolchain themselves. These
> > dependencies need toolchain dependency translation in order to work for
> > cross building. Unfortunately, toolchain dependency translation is not
> > yet implemented. Thus I think removing these dependencies is required. I
> > looked into debian/changelog for why they were added and couldn't find a
> > reason. Can we simply drop them?
> 
> I think that the reason is historical.  At least since version 2.1.64-3,
> released 14 years ago, g++ and g77 | fort77 appear as dependencies of
> octave2.1-headers. [1] The package octave2.1-headers is the predecessor of
> liboctave-dev.

I think the reason for the dependency is because liboctave-dev also
ships /usr/bin/mkoctfile, which is a wrapper for gcc|g++|gfortran to
compile Octave extensions. Users install liboctave-dev and expect to be
able to run mkoctfile to build native .mex or .oct files.

One solution may be to introduce a new package, say 'octave-dev-tools',
that would ship /usr/bin/mkoctfile and Depends: liboctave-dev. This
might allow the possibility of cross-building with liboctave-dev. This
would have a large impact on documentation, FAQs, and other accumulated
knowledge that tells users to install 'liboctave-dev' to be able to
compile and install packages.

I want to also mention that liboctave-dev includes a small number of
header files in /usr/include that are generated and include
arch-specific contents:

usr/include/octave-5.1.0/octave/mxarray.h
usr/include/octave-5.1.0/octave/octave-config.h
usr/include/octave-5.1.0/octave/version.h

Does this require any specific handling with respect to multi-arch and
cross-building?

-- 
mike


signature.asc
Description: PGP signature

Bug#932940: patch to demonstrate race

[Mike Miller]

Patch attached for real this time.

-- 
mike
--- a/makefile
+++ b/makefile
@@ -52,6 +52,7 @@
 	$(BD)epstest$(EXE)
 
 $(OD)lib.rsp: makefile
+	-sleep 0.1
 	-mkdir $(BINDIR)
 	-mkdir $(OBJDIR)
 	echo "dummy" > $(OD)lib.rsp

Bug#932940: epstool: parallel build may fail due to race condition

[Mike Miller]

Source: epstool
Version: 3.09-1
Severity: normal
Tags: upstream

Dear Maintainer,

The build system of epstool is fragile to building in parallel. The
'epsobj' subdirectory is only created by the 'lib.rsp' rule. But this
rule can run in parallel with building the object files that are also
written to the 'epsobj' subdirectory. An example error:

Assembler messages:
Fatal error: can't create ./epsobj/calloc.o: No such file or directory
make[1]: *** [src/common.mak:83: epsobj/calloc.o] Error 1

I am able to make this race condition more likely to occur with the
attached patch, and building with dpkg-buildpackage -j32. Just to be
very clear, the attached patch is not a fix, it is intended to
demonstrate the race condition by making it more likely.

This race condition can and has appeared in the wild, see for example

- https://trac.macports.org/ticket/40613
- https://github.com/Homebrew/linuxbrew-core/issues/959
- https://github.com/flathub/org.octave.Octave/issues/69

Thank you for your work on this package.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information

Bug#925081: Patch didn't add Global Protect to the -gnome packages drop down.

[Mike Miller]

Control: reopen -1
Control: notfixed -1 network-manager-openconnect/1.2.4-3

On Tue, Jul 02, 2019 at 15:55:13 -0600, Jason Fergus wrote:
> I now have the version installed from experimental, but the new
> protocol isn't in the drop down list.
[…]
> It only lists Cisco Anyconnect and Juniper/Pulse Network Connect.

Thanks.

I looked at the patches more closely, and the changes made so far do
seem to support Global Protect connections, if the connection file is
edited or created manually. I think you're right that the connection
editor dialog does not yet provide the GlobalProtect option.

I've just commented as much on the upstream issue tracker, where this is
still open

  https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/1

-- 
mike

Bug#926204: qscintilla2: debian/watch does not find latest upstream version

[Mike Miller]

Source: qscintilla2
Version: 2.10.4+dfsg-2
Severity: normal

Dear Maintainer,

The debian/watch file for qscintilla2 does not notice the latest
upstream version 2.11.1.

Scraping the upstream homepage gives the latest version

$ curl -sL 
"http://www.riverbankcomputing.co.uk/software/qscintilla/download; \
| perl -n -e 'if (/.*(QScintilla_gpl-[.[0-9]+\.tar\.gz).*/) { print 
"$1\n"; }'
QScintilla_gpl-2.11.1.tar.gz
QScintilla_gpl-2.11.tar.gz
…

But uscan and tracker.d.o only show version 2.10.8

$ uscan --report
uscan: Newest version of qscintilla2 on remote site is 2.10.8, local 
version is 2.10.4+dfsg
 (mangled local version is 2.10.4)
uscan:=> Newer package available from
  https://qa.debian.org/watch/sf.php/pyqt/QScintilla_gpl-2.10.8.tar.gz

Thank you for your work on this package.


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#925081: Add Palo Alto Global Protect support.

[Mike Miller]

Control: forwarded -1 
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/1
Control: tags -1 + confirmed upstream

On Tue, Mar 19, 2019 at 12:02:40 -0600, Jason Fergus wrote:
> There is a patch out there for adding this already, but it would be nice to 
> have the 
> added functionality, since the openconnect currently in testing already 
> supports GP
> protocol.

Sure, thank you, once that is merged upstream, and after buster is
released.

-- 
mike


signature.asc
Description: PGP signature

Bug#865140: Broken with network-manager 1.8.0-5 (at least for split tunnel)

[Mike Miller]

On Mon, Jun 19, 2017 at 09:07:44 -0700, Russ Allbery wrote:
> After upgrading network-manager to 1.8.0-5 from 1.6.2-3, connecting to
> a VPN with network-manager-openconnect still works but doesn't set up
> the routing table entries properly.  (This is a split-tunnel VPN.)  I'm
> guessing something changed in the NetworkManager internals that broke
> part of this plugin.
> 
> The problem went away again after downgrading network-manager back to
> 1.6.2-3.

Unfortunately I can't easily test this to try to reproduce.

Are you still affected by this bug with network-manager 1.14.6-2 and
network-manager-openconnect 1.2.4-2 in testing?

If so, it would be helpful to know if it's fixed in upstream git (it's
been a long time since the last release), if there's an upstream issue,
or what configuration is needed to reproduce this.

Sorry for the delay,

-- 
mike


signature.asc
Description: PGP signature

Bug#914992: network-manager-openconnect-gnome: Unable to select realm when connecting to Juniper VPN

[Mike Miller]

On Thu, Nov 29, 2018 at 10:49:19 +, Jonathan McDowell wrote:
> When trying to login to a Juniper Network Connect VPN using the NM VPN
> login dialog I get a form that provides a drop down "realm" to select as
> well as requesting the username + password. Upon selecting a realm other
> than the default as soon as focus switches away from that form entry the
> realm switches back to the initial entry. This means it's impossible to
> use the graphical login interface for a Juniper VPN.

Does this work for you now with openconnect 8.02-1?

There is an upstream bug report, where it is reported that updating to
openconnect 8 fixed this.

  https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/5

If it still persists for you, can you comment on this upstream report?

Thanks,

-- 
mike


signature.asc
Description: PGP signature

Bug#923442: octave: FTBFS (/bin/sed: can't read libinterp/parse-tree/oct-parse.cc-t: No such file or directory)

[Mike Miller]

On Thu, Feb 28, 2019 at 20:10:46 +0100, Sébastien Villemot wrote:
> If you don't have the time to do the upload today, I will do it
> tomorrow.
> 
> Note that you'll have to create a new git branch, named "buster",
> branching off at 4.4.1-4, since master already contains 5.1.0.

I've done exactly that, successfully tested in sbuild locally. Please
tag and upload when you get a chance.

-- 
mike


signature.asc
Description: PGP signature

Bug#923442: octave: FTBFS (/bin/sed: can't read libinterp/parse-tree/oct-parse.cc-t: No such file or directory)

[Mike Miller]

Control: tags -1 + patch

On Thu, Feb 28, 2019 at 10:08:33 +, Santiago Vila wrote:
> I tried to build this package in buster but it failed:
[…]
> /bin/sed: can't read libinterp/corefcn/oct-tex-parser.cc-t: No such file or 
> directory

Confirmed separately in upstream Octave development, this is caused by
the recent upload of bison 3.3 to unstable/buster.

Octave 4.4 needs this patch to work with bison 3.3

  https://hg.savannah.gnu.org/hgweb/octave/rev/df42ea23502f

I'll try building that a bit later today and push the fix if it works
for me.

-- 
mike


signature.asc
Description: PGP signature

Bug#922361: RFA: createrepo -- tool to generate the metadata for a yum repository

[Mike Miller]

Package: wnpp
Severity: normal

I request an adopter for the createrepo package.

The package is implemented in Python and is part of the rpm / yum
package software stack. This package will ideally be maintained within
the Debian RPM packaging team [1][2][3].

The team is cc'ed on this RFA, any team members interested in adopting?

The package description is:
 The createrepo tool generates the repodata directory and XML metadata that
 makes up a repository of RPM packages. This repository format is supported
 by apt-rpm, red-carpet(zen), smartpm, up2date, yast, and yum.
 .
 This package is similar to the apt-ftparchive or reprepro commands, but for
 working with RPM repositories.

Although the package has not been updated in several years, there are no
open bug reports, and there is only one patch-level upstream release
that has not been imported yet. The packaging git repository is up to
date and has been migrated to salsa at

 https://salsa.debian.org/pkg-rpm-team/createrepo

[1]: https://wiki.debian.org/Teams/pkg-rpm
[2]: https://tracker.debian.org/teams/pkg-rpm
[3]: https://salsa.debian.org/pkg-rpm-team

-- 
mike


signature.asc
Description: PGP signature

Bug#922362: RFA: deltarpm -- Tools to create and apply deltarpms

[Mike Miller]

Package: wnpp
Severity: normal

I request an adopter for the deltarpm package.

The package is implemented in C and Python and is part of the rpm / yum
package software stack. This package will ideally be maintained within
the Debian RPM packaging team [1][2][3].

The team is cc'ed on this RFA, any team members interested in adopting?

The package description is:
 A deltarpm contains the differences between an old and a new version of
 an RPM. This makes it possible to recreate the new RPM from the
 deltarpm and the old RPM.
 .
 On Debian and derived systems these tools may be useful for creating
 and maintaining repositories of RPM packages.

Although the package has not been updated in several years, there are no
open bug reports and there has been no new upstream release. The
packaging git repository is up to date and has been migrated to salsa at

 https://salsa.debian.org/pkg-rpm-team/deltarpm

[1]: https://wiki.debian.org/Teams/pkg-rpm
[2]: https://tracker.debian.org/teams/pkg-rpm
[3]: https://salsa.debian.org/pkg-rpm-team

-- 
mike


signature.asc
Description: PGP signature

Bug#922363: RFA: yum-metadata-parser -- Fast metadata parser for yum

[Mike Miller]

Package: wnpp
Severity: normal

I request an adopter for the yum-metadata-parser package.

The package is implemented in C and Python and is part of the rpm / yum
package software stack. This package will ideally be maintained within
the Debian RPM packaging team [1][2][3].

The team is cc'ed on this RFA, any team members interested in adopting?

The package description is:
 Python module providing a fast metadata parser for yum implemented in C.
 The sqlitecachec module is used by createrepo and the yum package manager
 to update and query local caches of RPM package repositories.

Although the package has not been updated in several years, there are no
open bug reports and there has been no new upstream release. The
packaging git repository is up to date and has been migrated to salsa at

 https://salsa.debian.org/pkg-rpm-team/yum-metadata-parser

[1]: https://wiki.debian.org/Teams/pkg-rpm
[2]: https://tracker.debian.org/teams/pkg-rpm
[3]: https://salsa.debian.org/pkg-rpm-team

-- 
mike


signature.asc
Description: PGP signature

Bug#922364: RFA: yum-utils -- Utilities based around the yum package manager

[Mike Miller]

Package: wnpp
Severity: normal

I request an adopter for the yum-utils package.

The package is implemented in Python and is part of the rpm / yum
package software stack. This package will ideally be maintained within
the Debian RPM packaging team [1][2][3].

The team is cc'ed on this RFA, as well as Markus Frosch (lazyfrosch),
who has expressed interest in maintaining this package on #921131.

The package description is:
 Yum-utils is a collection of utilities and examples for the yum package
 manager. It includes utilities by different authors that make yum easier and
 more powerful to use. The commands provided are:
 .
  * repo-graph: output a full package dependency graph in dot format
  * repo-rss: generate an RSS feed from one or more yum repositories
  * repoclosure: display a list of unresolved dependencies for a yum repository
  * repodiff: list differences between two or more yum repositories
  * repomanage: list the newest or oldest packages in a yum repository
  * repoquery: query information from yum repositories
  * reposync: synchronize yum repositories to a local directory
  * repotrack: track a package and its dependencies and download them
  * yum-builddep: install missing dependencies for building an RPM package
  * yum-complete-transaction: attempt to complete failed or aborted yum
transactions
  * yum-config-manager: manage yum configuration options and yum repositories
  * yum-groups-manager: create and edit group metadata for a yum repository
  * yumdb: query and alter the yum database
  * yumdownloader: download RPM packages from yum repositories
 .
 On Debian and derived systems, this package can be useful for installing
 and managing chroots or lxc containers of yum-based distributions. The
 utilities for querying and managing yum repositories may also be useful for
 maintaining repositories of RPM packages on a Debian host.

Although the package has not been updated in several years, there are
few open bug reports, one recent CVE, and there has been no new upstream
release. The packaging git repository is up to date and has been
migrated to salsa at

 https://salsa.debian.org/pkg-rpm-team/yum-utils

Markus, if you are added to the team now, feel free to add your changes
to this copy of the git repo and take ownership.

[1]: https://wiki.debian.org/Teams/pkg-rpm
[2]: https://tracker.debian.org/teams/pkg-rpm
[3]: https://salsa.debian.org/pkg-rpm-team

-- 
mike


signature.asc
Description: PGP signature

Bug#921131: CVE-2018-10897

[Mike Miller]

Hi Markus!

On Sun, Feb 10, 2019 at 11:15:35 +0100, Markus Frosch wrote:
> I'm not sure how active Mike is currently.

I'm quite active, but I have not touched the rpm/yum related packages in
years since they haven't seen much upstream activity. I'm also honestly
not very interested in rpm/yum currently. I should have given these
packages up for adoption by now, better late than never.

> Since I'm using the package in a multi distro build system, I would
> proceed with uploading a fix and join as co-maintainer.
> 
> I already created a salsa project:
> https://salsa.debian.org/debian/yum-utils
> 
> @Mike: Can I get a short approval?

There is an RPM packaging team that this package should be maintained
with

  * https://salsa.debian.org/pkg-rpm-team
  * https://tracker.debian.org/teams/pkg-rpm/
  * https://wiki.debian.org/Teams/pkg-rpm

Can you move your imported repository to the team group on salsa?

There used to be a mailing list on lists.alioth.d.o, I don't think there
is a replacement team list.

> Also: Is the experimental upload ready for buster?

I think so, I think it was only experimental because of a freeze.

I suggest I file an RFA for yum-utils and Cc you, we can discuss further
there, ok? Do you have any interest in the related packages createrepo,
deltarpm, and yum-metadata-parser?

Also thank you Holger for the nmu and fixing this bug so quickly.

-- 
mike


signature.asc
Description: PGP signature

Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

[Mike Miller]

On Sun, Feb 03, 2019 at 12:07:20 +, Mo Zhou wrote:
> control: severity -1 important

Severity minor because it is only caused by installation of an unrelated
package from non-free?

> I tried to reproduce this issue in a docker container. It seems that
> the problem only occurs after the installation of libmkl-rt. I feel
> very strange and tried to do some further research:
[…]
> So ... How do I fix such gomp-iomp clashing issue?
> (I guess it's not fixable)

I found this related issue: https://stackoverflow.com/q/25986091/384593

Because Octave builds with '-fopenmp', it always links unconditionally
with libgomp, which in turn makes it incompatible with libiomp5. It
seems to me the most reasonable solution is a README.Debian warning
users not to use Octave with libiomp5 or expect undefined behavior.

-- 
mike


signature.asc
Description: PGP signature

Bug#919740: merge request submitted

[Mike Miller]

Control: tags -1 + patch

I've posted a MR at

  https://salsa.debian.org/lintian/lintian/merge_requests/130

Thanks,

-- 
mike

Bug#919740: lintian: description-too-long text "must not exceed 80 characters" is incorrect

[Mike Miller]

Package: lintian
Version: 2.5.121
Severity: minor

Dear Maintainer,

The tag `description-too-long` says

The first line of the "Description:" must not exceed 80 characters.

which, at least to me, says that exactly 80 characters is allowed. But
the actual section in Policy says that the line must be strictly less
than 80, and the actual lintian check agrees with Policy.

Changing the tag text to

The first line of the "Description:" must be less than 80 characters.

makes this much clearer and correct.

I will submit a MR on salsa once I have a bug number.


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

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

-- no debconf information

Bug#906299: vim-conque: patch

[Mike Miller]

Control: tags -1 + patch

I've been using a local build with the attached change to resolve this
dependency bug, in case a tested minimal patch is helpful.

-- 
mike
From c1e60d13b19d309f3bb93fc08baf124b0c99afac Mon Sep 17 00:00:00 2001
From: Mike Miller 
Date: Sat, 12 Jan 2019 14:55:00 -0800
Subject: [PATCH 1/2] d/control: Add alternative dependency on vim-python3

Closes: #906299

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

diff --git a/debian/control b/debian/control
index 954829b66f4d..e14123f667f7 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Homepage: https://code.google.com/p/conque/
 
 Package: vim-conque
 Architecture: all
-Depends: ${python:Depends},${misc:Depends},vim-nox|vim-python
+Depends: ${python:Depends},${misc:Depends},vim-nox|vim-python|vim-python3
 Recommends: vim-addon-manager
 Description: plugin for running interactive commands in a Vim buffer 
  This package provides a Vim plugin which allows interactive programs such as
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#919028: chrome-gnome-shell: postinst fails on reconfigure or if json already exists

[Mike Miller]

Package: chrome-gnome-shell
Version: 10.1-4
Severity: normal
Tags: patch

Dear Maintainer,

The postinst script fails if

  /etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json

already exists on the system at the time of install. I've been able to
reproduce this two different ways so far:

1. I manually copied the file before upgrading to 10.1-4. The postinst
   attempted to symlink on top of an existing regular file and failed.

2. I ran `dpkg-reconfigure chrome-gnome-shell` after successful install.
   The postinst attempted to symlink on top an an already existing
   symlink that it had created when it was first installed.

There are probably several different ways you could address this, I'm
attaching a suggestion that works for me. In general I would think if
the destination already exists as a file or a symlink, you should avoid
trying to overwrite it at all.

Thanks!


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chrome-gnome-shell depends on:
ii  gnome-shell   3.30.1-2
ii  python3   3.7.1-3
ii  python3-gi3.30.4-1
ii  python3-requests  2.20.0-2

chrome-gnome-shell recommends no packages.

Versions of packages chrome-gnome-shell suggests:
ii  chromium  72.0.3626.7-4
pn  firefox   

-- no debconf information
>From d8be8ae955cf79d0835b40718476561e97d79a9f Mon Sep 17 00:00:00 2001
From: Mike Miller 
Date: Fri, 11 Jan 2019 15:53:55 -0800
Subject: [PATCH] Avoid failing install on link in /etc/opt/chrome

---
 debian/postinst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/postinst b/debian/postinst
index 703dfacc44a7..af0cada8695a 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -5,6 +5,8 @@ set -e
 #DEBHELPER#
 
 mkdir -p /etc/opt/chrome/native-messaging-hosts
-ln -s /usr/share/chrome-gnome-shell/org.gnome.chrome_gnome_shell.json 
/etc/opt/chrome/native-messaging-hosts/
+if [ ! -e 
/etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json ]; then
+  ln -sf /usr/share/chrome-gnome-shell/org.gnome.chrome_gnome_shell.json 
/etc/opt/chrome/native-messaging-hosts/
+fi
 
 exit 0
-- 
2.20.1

Bug#918963: lintian: manual-references contains broken/obsolete URLs for Debian Policy Manual

[Mike Miller]

Package: lintian
Version: 2.5.120
Severity: minor

Dear Maintainer,

I noticed that a link to the Debian Policy Manual from the Lintian tag
page

  https://lintian.debian.org/tags/description-too-long.html

points to

  https://www.debian.org/doc/debian-policy/#the-single-line-synopsis

which references an invalid anchor. The correct URL should now be

  
https://www.debian.org/doc/debian-policy/ch-binary.html#the-single-line-synopsis

I then noticed that all Debian Policy URLs in manual-references use URLs
of the first form, all of which are now invalid.

Maybe these URLs used to be valid, if the Debian Policy Manual used to
be presented as a single HTML page? In its current form all of these
cross references are broken and not helpful to a new user.


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.75+repack-1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

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

-- no debconf information

Bug#918529: openconnect: version 8.01 available upstream

[Mike Miller]

Control: tags -1 + pending

On Sun, Jan 06, 2019 at 22:14:36 -0500, Daniel Kahn Gillmor wrote:
> on the mailing list, i see that openconnect 8.01 is available
> upstream.  it's also tagged in the upstream git repository.
> 
> please package the new version for debian!

Yeah, in progress now, partially done in git, should be in unstable in a
day or two.

Thanks for your interest!

-- 
mike


signature.asc
Description: PGP signature

Bug#918749: libtss2-dev: missing Depends: libgcrypt20-dev, pkg-config --libs tss2-esys lists -lgcrypt

[Mike Miller]

Package: libtss2-dev
Version: 2.1.0-2
Severity: normal

Dear Maintainer,

Installing libtss2-dev and running pkg-config --libs tss2-esys produces

-ltss2-esys -lgcrypt -ltss2-sys -ltss2-mu

The package should therefore declare Depends: libgcrypt20-dev so that
the "-lgcrypt" part of this is satisfied.

Thanks!


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libtss2-dev depends on:
ii  libtss2-esys0  2.1.0-2

libtss2-dev recommends no packages.

libtss2-dev suggests no packages.

-- no debconf information

Bug#918073: git-buildpackage: please document effect of --git-color, --git-notify tristate options

[Mike Miller]

Package: git-buildpackage
Version: 0.9.13
Severity: wishlist

Dear maintainer,

Please document the actual effect of specifying "auto" for tristate
command-line options such as --git-color and --git-notify. For example,
the current documentation

  --git-color=COLOR Whether to use colored output, default is 'auto'

doesn't actually tell the user what the value "auto" means. It can be
inferred if they are familiar with git's color options.

Similarly, with --git-notify set to "auto", the user is left to infer
what is decided automatically. Is it the presence of a terminal? The
presence of an active desktop session? The presence of a particular
Python library? I had to use the source to find the answer, and only
then notice that the suggested python3-notify2 was not installed.

Thank you for your valuable contributions to Debian!


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.10
ii  git1:2.19.2-1
ii  man-db 2.8.4-3
ii  python33.7.1-3
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  40.6.2-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.45
ii  python3-requests  2.20.0-2
ii  sbuild0.77.1-2

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.26-2
ii  unzip6.0-21

-- no debconf information

Bug#916961: octave-symbolic FTBFS: test failures

[Mike Miller]

On Thu, Dec 20, 2018 at 22:29:16 +0200, Adrian Bunk wrote:
> Some recent change in unstable makes octave-symbolic FTBFS:
[…]
> * test
>  % performance: want roughly O(1) not O(n)
>  A = linspace(sym(0), sym(10), 3);  % do one first, avoid caching
>  tic; A = linspace(sym(0), sym(10), 3);   t1 = toc();
>  tic; A = linspace(sym(0), sym(10), 100); t2 = toc();
>  if (t2 >= 10*t1)
>assert (false);
>  end
> ! test failed
> assert (false) failed

This is comparing timing, I guess the results could be fragile and
depend so much on what else the system may be doing. May pass most of
the time but fail randomly. Turn into xtest?

> * test
>  % maple, matrix inputs
>  A = [5.61467232547723663908 20.6144884613920190965];
>  B = pochhammer ([0.9 0.8], [3.1 4.2]);
>  assert (A, B, -eps);
> ! test failed
> ASSERT errors for:  assert (A,B,-eps)
> 
>   Location  |  Observed  |  Expected  |  Reason
> (2)20.6145  20.6145  Rel err 5.1702e-16 exceeds tol 
> 2.2204e-16 by 3e-16

Confirmed in a virtualenv that this is due to the recently released
mpmath version 1.1.0.

Filed upstream issue: https://github.com/cbm755/octsympy/issues/918

Bumping the tolerance seems appropriate.

-- 
mike


signature.asc
Description: PGP signature

Bug#916979: Octave recent build only has grahics toolkit gnuplot; qt and fltk are missing

[Mike Miller]

On Fri, Dec 21, 2018 at 09:05:36 +0100, Sébastien Villemot wrote:
> I think it would make sense to add an autopkgtest for that specific
> issue, to detect it should it appear again.
> 
> The only drawback with respect to putting it as a failure in
> debian/rules is that autopkgtest are only routinely exercised on amd64.

Ok, how about something like the attached? This can be extended to check
for other features (arpack, SuiteSparse, etc) that we want to require.

Could this not also be run in the dh_auto_test target to cover all
arches at least once when they are built?

-- 
mike


octave-features.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

Bug#914373: documenting octave packages need to be loaded

[Mike Miller]

On Wed, Dec 19, 2018 at 20:01:44 +, David Pinto wrote:
> However, this does not happen for chi2inv which is the function
> mentioned on the bug report.  The issue here is that the internal list
> of functions belonging to packages need to be updated in Octave so the
> user gets a message informing that packages need to be loaded
> explicitly.

This is now done for Octave 5 [1], can be cherry-picked to fix #914391.

> This is another issue in Octave.  chi2inv used to be part of Octave
> core but got moved to the statistics package for Octave 4.4 version.
> The Octave manual should no longer be referring chi2inv.

I think the only place it is mentioned is Appendix C Obsolete Functions.
I've filed an upstream bug [2] to address that. Were there any other
mentions I missed?

[1]: https://hg.savannah.gnu.org/hgweb/octave/rev/d41d137af059
[2]: https://savannah.gnu.org/bugs/?55265

-- 
mike


signature.asc
Description: PGP signature

Bug#916979: Octave recent build only has grahics toolkit gnuplot; qt and fltk are missing

[Mike Miller]

On Thu, Dec 20, 2018 at 15:37:55 -0800, Mike Miller wrote:
> something (possibly mesa) was messed up in the archive and resulted in a
> bad build. A binNMU should be sufficient to fix this, but a new source
> upload may be coming soon anyway.

Aside to Debian Octave maintainers - should debian/rules error out if
something like this happens again? Add/patch anything to turn upstream
optional features mandatory? Patch warnings into errors, or grep
config.log for certain warnings? Or is that overkill?

-- 
mike


signature.asc
Description: PGP signature

Bug#916979: Octave recent build only has grahics toolkit gnuplot; qt and fltk are missing

[Mike Miller]

On Thu, Dec 20, 2018 at 14:36:49 -0800, Clinton Winant wrote:
> Having upgraded Debian Buster to octave package (4.4.1-2+b1) I find the qt
> and fltk graphics toolkits are no longer available.
> 
> octave:2> name=graphics_toolkit()name = gnuplotoctave:3>
> available_graphics_toolkitsans ={
>   [1,1] = gnuplot}
> 
>  These are critical components of the octave system.

Thanks for reporting this. After I saw your post [1] and was able to
confirm, I did a little digging and reported what I found [2]. I think
something (possibly mesa) was messed up in the archive and resulted in a
bad build. A binNMU should be sufficient to fix this, but a new source
upload may be coming soon anyway.

[1]: https://stackoverflow.com/q/53856186/384593
[2]: https://lists.debian.org/debian-octave/2018/12/msg0.html

-- 
mike


signature.asc
Description: PGP signature

Bug#906299: vim-conque: please update dependencies to include vim-python3

[Mike Miller]

Package: vim-conque
Version: 2.3-1
Severity: normal

Dear Maintainer,

The latest vim source package has changed from "Provides: vim-python" to
"Provides: vim-python3" to be more explicit. Please update the
corresponding dependencies in vim-conque to include both vim-python and
vim-python3.

Thank you for your work and attention.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim-conque depends on:
ii  python 2.7.15-3
ii  vim-gtk3 [vim-python]  2:8.1.0089-1

Versions of packages vim-conque recommends:
ii  vim-addon-manager  0.5.9

vim-conque suggests no packages.

-- no debconf information

Bug#862884: Disable libnm-glib support

[Mike Miller]

On Sat, Aug 11, 2018 at 17:08:54 +0200, Michael Biebl wrote:
> To finish off the libnm-glib transition (nm-openconnect being the last
> package at [1]), I decided to prepare an NMU and upload to DELAYED/7
> 
> While at it, I've also included the changes for #852705 and #852706.
> Full debdiff attached.
> 
> Please holler if you want me to cancel the NMU and you want to make a
> maintainer upload instead.

No, thank you for taking care of this, looks good.

-- 
mike


signature.asc
Description: PGP signature

Bug#905908: libGL.so.1: cannot open shared object file: No such file or directory when updating to 4.4.1~rc2-3

[Mike Miller]

On Sat, Aug 11, 2018 at 16:00:18 +0200, Kyle Robbertze wrote:
> When updating octave to 4.4.1~rc2-3, I received the following error:
> 
> Setting up octave (4.4.1~rc2-3) ...
> /usr/bin/octave-cli: error while loading shared libraries: libGL.so.1: cannot 
> open shared object file: No such file or directory
> dpkg: error processing package octave (--configure):
>  installed octave package post-installation script subprocess returned error 
> exit status 127
> 
> It appears to be missing a dependency on a package that provides libGL.

That's odd, because that package is exactly

> ii  libgl1 1.0.0+git20180308-4

Can you check the contents of the package on your system?

$ ldconfig -p | grep libGL.so.1
libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so.1
$ ls -lgo /usr/lib/x86_64-linux-gnu/libGL.so.*
lrwxrwxrwx 1 14 Aug  8 03:41 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> 
libGL.so.1.7.0
-rw-r--r-- 1 575816 Aug  8 03:41 /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0
$ dpkg -S /usr/lib/x86_64-linux-gnu/libGL.so.*
libgl1:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1
libgl1:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0

-- 
mike


signature.asc
Description: PGP signature

Bug#900816: cdargs: diff for NMU version 1.35-11.1

[Mike Miller]

On Mon, Jul 23, 2018 at 20:27:04 +0800, David Bremner wrote:
> I've prepared an NMU for cdargs (versioned as 1.35-11.1) and
> uploaded it to DELAYED/05. Please feel free to tell me if I
> should delay it longer.

Thank you for the fix, this is fine with me.

I did get around to installing emacs/experimental so far, but didn't
have time to look into the reason for the error.

-- 
mike


signature.asc
Description: PGP signature

Bug#896438: javahelper: java-vars.mk is not compatible with Java 9 directory layout

[Mike Miller]

Package: javahelper
Version: 0.63
Severity: normal

Dear Maintainer,

The make variables provided by java-vars.mk, specifically JVM_CLIENT_DIR
and JVM_SERVER_DIR, are not compatible with the directory layout used by
Java 9 and newer. The variables always evaluate to an empty string. The
architecture is no longer a component in the file path.


-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages javahelper depends on:
ii  bsdmainutils 11.1.2
ii  dctrl-tools  2.24-2+b1
ii  debhelper11.2.1
ii  devscripts   2.18.1
ii  dpkg-dev 1.19.0.5
ii  libarchive-zip-perl  1.60-1
ii  perl 5.26.1-5

javahelper recommends no packages.

Versions of packages javahelper suggests:
ii  cvs   2:1.12.13+real-26
ii  gawk  1:4.1.4+dfsg-1+b1
pn  tofrodos  

-- no debconf information

Bug#895274: octave and OpenJDK 10

[Mike Miller]

On Mon, Apr 09, 2018 at 10:38:52 +0200, Matthias Klose wrote:
> With the recent java-common upload to experimental, octave would need a
> no-change rebuild/upload in experimental to pick up the new defaults.

I posted the attached patch to the Ubuntu bug tracker. This is an
upstream patch that enables octave configure to detect and build with
OpenJDK 10 and 11.

I can add this to the octave packaging repo if we expect to have a
4.2.2-3 source upload, and if that would be helpful for testing OpenJDK
transitions.

We already have 4.4 release candidates (not yet in experimental) and
expect Octave 4.4 to be stamped in the next week or so, at which point
the patch won't be needed.

-- 
mike
Description: configure: Remove characters after java version string
 Fixes configure detection of Java version with OpenJDK 10 and 11, where some
 text appears after the quoted version number.
Author: Rik <r...@octave.org>
Origin: upstream, https://hg.savannah.gnu.org/hgweb/octave/rev/523298448352
Bug: https://savannah.gnu.org/bugs/?53531
Reviewed-by: Mike Miller <mtmil...@debian.org>
Last-Update: 2018-04-19
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/configure.ac
+++ b/configure.ac
@@ -2759,7 +2759,7 @@
 
   ## Check Java version is recent enough.
   AC_MSG_CHECKING([for Java version])
-  java_version=[`"$JAVA" -version 2>&1 | $SED -n -e 's/^[^ ]* version[^0-9"]*"\([^"]*\)"/\1/p'`]
+  java_version=[`"$JAVA" -version 2>&1 | $SED -n -e 's/^[^ ]* version[^0-9"]*"\([^"]*\)".*/\1/p'`]
   AC_MSG_RESULT([$java_version])
   java_major=[`echo $java_version | $SED -e 's/^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\..*$/\1/'`]
   java_minor=[`echo $java_version | $SED -e 's/^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\..*$/\2/'`]


signature.asc
Description: PGP signature

Bug#862884: Disable libnm-glib support

[Mike Miller]

On Sat, Apr 14, 2018 at 01:02:45 +0200, Michael Biebl wrote:
> I intend to upload a new version of network-manager soonish which will
> drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
> preparation for that.

Thanks for the reminder and lighting a fire, will do.

-- 
mike


signature.asc
Description: PGP signature

Bug#895334: libsundials-nvecparallel-petsc2: uninstallable on current unstable

[Mike Miller]

Package: libsundials-nvecparallel-petsc2
Version: 2.7.0+dfsg-2+b2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since petsc was updated in unstable from 3.7 to 3.8, the
libsundials-nvecparallel-petsc2 package is uninstallable in unstable. It
depends on libpetsc3.7, which no longer exists in the archive.

This is probably easily fixed with a binNMU.

Thanks.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsundials-nvecparallel-petsc2 depends on:
ii  libc62.27-2
ii  libopenmpi2  2.1.1-8
ii  libpetsc3.7.7 [libpetsc3.7]  3.7.7+dfsg1-2+b3

libsundials-nvecparallel-petsc2 recommends no packages.

libsundials-nvecparallel-petsc2 suggests no packages.

-- no debconf information

Bug#895309: octave: Unable to stop running script by ctrl+c when srl_read from instrument-control package is called

[Mike Miller]

On Mon, Apr 09, 2018 at 20:43:33 +0200, marek wrote:
> To reproduce:
> you need serial port device and Internet connection to download instrument-
> control package
> install packages octave and liboctave-dev
> apt-get install octave liboctave-dev
> run Octave gui
> in Octave command line call:
> pkg install -forge instrument-control
[…]
> expected behaviour:
> script onInit is terminated
> 
> actual behaviour:
> in Command Window following line is written for each ctrl+c pressed
> srl_read: Interrupting...
> 
> It is also not possible to terminate GNU Octave gui by closing its window, or
> clicking File/Exit or hitting ctrl+q.

This looks to me like it is not really a bug in Octave, but in the
instrument-control Forge package, which is not yet packaged in Debian.

In particular, the instrument-control package intentionally overrides
Octave's signal handling capabilities to handle interrupts on its own.

Normally, Octave would handle a SIGINT by breaking out of the running
loop or script or function entirely and returning control to the prompt.
But because of the instrument-control package hijacking SIGINT handling,
this normal behavior doesn't happen and Octave continues running.

I would recommend that you close this bug, since it is not a bug in
Octave as packaged by Debian, and work with the instrument-control
package developer to resolve this issue.

-- 
mike


signature.asc
Description: PGP signature

Bug#876410: libgl2ps1: please include support for SOURCE_DATE_EPOCH

[Mike Miller]

On Sat, Mar 24, 2018 at 23:08:25 +0100, Anton Gladky wrote:
> thanks for the bugreport. I do not think, that adding the
> fixed timestamp to all files produced by the gl2os that is
> what the users want.

Thank you for your reply.

Respectfully, I am a user of gl2ps, and I do want to be able to use it
to write deterministic postscript output.

I do think the current behavior should be the default, I am only asking
for an option to create an output with a known timestamp.

If this is not done in gl2ps, then my workarounds include embedding a
patched version of gl2ps.c, using faketime, or post-processing the .ps
files to edit the timestamp strings. None of these are particularly
appealing options.

My original report may have sounded like a "why not?" request. So just
to be clear, I do have a real need for gl2ps to produce postscript files
that are deterministic.

Cheers,

-- 
mike


signature.asc
Description: PGP signature

Bug#876363: octave fetches network resources when network access disabled

[Mike Miller]

On Thu, Apr 05, 2018 at 15:31:06 +0100, D Haley wrote:
> Do we know if there is a particular commit that upstream applied to fix
> this?

FTR, it was fixed in this upstream commit

https://hg.savannah.gnu.org/hgweb/octave/rev/1265c7f0119a

And this fix is included in the upcoming Octave 4.4 release.

-- 
mike


signature.asc
Description: PGP signature

Bug#894348: octave-io's autopkg tests fail, because java9 is not recognized

[Mike Miller]

On Thu, Mar 29, 2018 at 19:09:19 +0800, Matthias Klose wrote:
> autopkgtest [10:19:33]: test ods-default: [---
> Testing default interface for ODS...
> warning:
> Java version too old - you need at least Java 6 (v. 1.6.x.x)

Upstream bug report at https://savannah.gnu.org/bugs/?53510

I am recommending that upstream drop the version check entirely. The
attached patch does just that, works for me with cursory local testing.

-- 
mike
Description: drop version number check for outdated versions of JRE
Author: Mike Miller <mtmil...@debian.org>
Bug: https://savannah.gnu.org/bugs/?53510
Bug-Debian: https://bugs.debian.org/894348
Last-Update: 2018-03-29
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/inst/private/__chk_java_sprt__.m
+++ b/inst/private/__chk_java_sprt__.m
@@ -41,18 +41,8 @@
 ## Now check for proper version (>= 1.6)
 jver = ...
   char (javaMethod ("getProperty", "java.lang.System", "java.version"));
-cjver = strsplit (jver, ".");
-if (sscanf (cjver{2}, "%d") < 6)
-  warning ...
-("\nJava version too old - you need at least Java 6 (v. 1.6.x.x)\n");
-  if (dbug)
-printf ('At Octave prompt, try "!system ("java -version")"');
-  endif
-  return
-else
-  if (dbug > 2)
-printf ("  Java (version %s) seems OK.\n", jver);
-  endif
+if (dbug > 2)
+  printf ("  Java (version %s) seems OK.\n", jver);
 endif
 ## Now check for proper entries in class path. Under *nix the classpath
 ## must first be split up. In java 1.2.8+ javaclasspath is already a cell array


signature.asc
Description: PGP signature

Bug#891465: glpk: prints warnings which lead to failing sagemath tests

[Mike Miller]

Package: libglpk40
Version: 4.65-1
Followup-For: Bug #891465

Hi, I also see this bug affecting octave, although as a minor cosmetic
issue. Octave's glpk unit tests also intentionally set msg_lev to
GLP_MSG_OFF to have no output generated. With glpk 4.65, this same
message is now appearing in the test suite output log.

It would be very helpful if GLP_MSG_OFF suppressed this message as it
does with other messages.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libglpk40 depends on:
ii  libamd2 1:5.1.2-2
ii  libc6   2.26-6
ii  libcolamd2  1:5.1.2-2
ii  libgmp102:6.1.2+dfsg-2
ii  libltdl72.4.6-2
ii  zlib1g  1:1.2.8.dfsg-5

libglpk40 recommends no packages.

Versions of packages libglpk40 suggests:
pn  default-libmysqlclient-dev  
pn  libiodbc2-dev   

-- no debconf information

Bug#874217: rlwrap FTCBFS: /proc//cwd check not cacheable

[Mike Miller]

On Mon, Sep 04, 2017 at 12:17:12 +0200, Helmut Grohne wrote:
> rlwrap fails to cross build from source, because it uses an uncacheable
> AC_CHECK_FILES where the cache variable contains the process id of
> ./configure. After thinking about it, I figured that replacing
> "/proc/$$" with "/proc/self" would be a reasonable compromise making the
> cache variable predictable. Thus it can be provided with a cross build.
> When using the attached patch and providing
> ac_cv_file__proc_self_cwd_cwdcheck (yes for linux-any and kfreebsd-any,
> no for hurd-any), rlwrap cross build successfully. Please consider
> applying the patch.

Thank you for taking the time to write a patch for this problem. In
working on packaging the latest upstream release, I've noticed that the
configure script has diverged from the affected code.

With the 0.43 release (uploading soon to unstable), it should be
possible to cross-build by defining ENABLE_MIRROR_ARGS on linux-any and
kfreebsd-any.

-- 
mike


signature.asc
Description: PGP signature

Bug#891177: vpnc-scripts: please upload new git snapshot (support for systemd-resolved)

[Mike Miller]

On Thu, Feb 22, 2018 at 16:18:12 -0800, Daniel Kahn Gillmor wrote:
> as of 6f87b0fe7b20d802a0747cc310217920047d58d3, upstream vpnc-scripts
> supports communicating with systemd-resolved.  It'd be great to have
> that feature available in debian.

Thanks, will do. I hesitated when this was first added because it wasn't
conditional on whether the user actually wanted to use systemd-resolved
or not. It looks like that has been addressed now.

-- 
mike


signature.asc
Description: PGP signature

Bug#890921: vpnc: make it easy to decline resolv.conf updates

[Mike Miller]

Control: tags -1 + upstream

On Tue, Feb 20, 2018 at 08:18:43 -0800, Daniel Kahn Gillmor wrote:
> There are situations where the user wants to use the routing
> information offered by the VPN, but does not want to use the DNS
> recommendations.
> 
> In this case, it'd be nice to be able to tell vpnc this preference.

I would guess that upstream might suggest creating a local wrapper for
vpnc-script to remove DNS from the environment, for example

#!/bin/sh
unset INTERNAL_IP4_DNS INTERNAL_IP6_DNS
exec /usr/share/vpnc-scripts/vpnc-script

That should have the same effect.

But if you want to propose adding an option, would you mind posting your
patch to the upstream mailing list? Upstream prefers git patches with
Signed-off-by headers.

http://www.infradead.org/openconnect/contribute.html

Thanks,

-- 
mike


signature.asc
Description: PGP signature

Bug#889930: Plot viewer doesn't work properly

[Mike Miller]

On Thu, Feb 15, 2018 at 13:26:34 -0500, Louis-Philippe Véronneau wrote:
> I guess there is a library missing somewhere that I would need to
> install on my openbox machine.

This seems less likely to me now. I installed a clean (unstable) system
without any recommends enabled, ran octave in openbox on a vnc, and
everything worked fine.

Is it possible this is a video driver / OpenGL problem on your system?
Can you try running octave with LIBGL_ALWAYS_SOFTWARE=1 in your
environment? See also https://www.mesa3d.org/envvars.html for other
variables to try.

Best to use gnuplot if your system has problems with the default
GL-based plotting library.

-- 
mike


signature.asc
Description: PGP signature

Bug#889930: Plot viewer doesn't work properly

[Mike Miller]

On Thu, Feb 15, 2018 at 13:26:34 -0500, Louis-Philippe Véronneau wrote:
> I ran the same code with the same version of octave but on a PC running
> Gnome 3 instead of openbox and I did not have this problem...
> 
> I guess there is a library missing somewhere that I would need to
> install on my openbox machine.

Could be. I just installed openbox, started it in a vnc session, and
octave plots appear and behave as expected. I will try to repeat on a
clean system if I get a chance.

-- 
mike


signature.asc
Description: PGP signature

Bug#741097: octave: nox package of Octave

[Mike Miller]

On Thu, Feb 01, 2018 at 12:13:40 -0800, Mike Miller wrote:
> If this bug is still of interest, I think a useful first step would be
> for someone to adapt the octave source package and add the appropriate
> --without-X options. Once there are proof of concept binary packages
> built without any graphical dependencies, then a useful disk usage
> comparison can be done.

Here is an example of what I suggest interested parties can do quite
easily. Modify the source package as in the attached example patch. This
is not an example of a full solution, just a quick and dirty hack to
build octave with no graphical dependencies. Note that this will also be
a slightly crippled octave without any imread or imwrite capability.

With the resulting packages, I can compare the storage requirements in a
clean minbase installation:

# apt install --no-install-recommends octave
…
0 upgraded, 181 newly installed, 0 to remove and 0 not upgraded.
Need to get 88.3 MB of archives.
After this operation, 450 MB of additional disk space will be used.

versus

# apt install --no-install-recommends ./octave_4.2.1-6_amd64.deb \
  ./liboctave4_4.2.1-6_amd64.deb \
  ./octave-common_4.2.1-6_all.deb
…
0 upgraded, 69 newly installed, 0 to remove and 0 not upgraded.
Need to get 29.9 MB/38.9 MB of archives.
After this operation, 167 MB of additional disk space will be used.

So I have saved about 280 MB in storage by dropping all graphical
dependencies. That's about 5 MB in the octave binaries themselves and
the rest in the dropped dependencies. Octave will not have a GUI, will
not be able to plot anything, and will not be able to read or write
image file formats.

Is 0.25-0.3 GB on the order of the savings you are looking for? Is it
worth not being able to work with image files or plot anything, even
headless plotting?

-- 
mike
diff --git a/debian/control b/debian/control
index a98b3afee08d..fc2daca67cd0 100644
--- a/debian/control
+++ b/debian/control
@@ -22,31 +22,22 @@ Build-Depends: automake,
less,
libarpack2-dev,
libblas-dev,
+   libbz2-dev,
libcurl4-gnutls-dev,
libfftw3-dev,
-   libfltk1.3-dev,
-   libfontconfig1-dev,
-   libgl2ps-dev,
libglpk-dev,
-   libgraphicsmagick++1-dev,
libhdf5-dev,
liblapack-dev,
libncurses5-dev,
-   libosmesa6-dev,
libpcre3-dev,
libqhull-dev,
libqrupdate-dev,
-   libqscintilla2-qt5-dev,
-   libqt5opengl5-dev,
libreadline-dev,
librsvg2-bin,
libsndfile1-dev,
libsuitesparse-dev,
-   libxft-dev,
portaudio19-dev,
pstoedit,
-   qtbase5-dev,
-   qttools5-dev-tools,
texinfo,
texlive-generic-recommended,
texlive-fonts-recommended,
diff --git a/debian/rules b/debian/rules
index 5c3161594258..7c16dbf09efe 100755
--- a/debian/rules
+++ b/debian/rules
@@ -49,7 +49,14 @@ endif
 override_dh_auto_configure:
 	# Enforce generic BLAS (in order to avoid tying the binary to OpenBLAS or ATLAS)
 	# Also pass OpenMP flag (#631831)
-	dh_auto_configure -- --with-blas=blas --enable-openmp $(WITH_JAVA_FLAGS) $(JIT_FLAG) $(HDF5_FLAGS) $(DOC_FLAG)
+	dh_auto_configure -- \
+--without-fltk \
+--without-magick \
+--without-opengl \
+--without-OSMesa \
+--without-qt \
+--without-x \
+--with-blas=blas --enable-openmp $(WITH_JAVA_FLAGS) $(JIT_FLAG) $(HDF5_FLAGS) $(DOC_FLAG)
 
 # dh_auto_test tries to run "make test", so override it
 override_dh_auto_test:


signature.asc
Description: PGP signature

Bug#741097: octave: nox package of Octave

[Mike Miller]

If this bug is still of interest, I think a useful first step would be
for someone to adapt the octave source package and add the appropriate
--without-X options. Once there are proof of concept binary packages
built without any graphical dependencies, then a useful disk usage
comparison can be done.

Of course it would be even more helpful if someone were interested
enough to help work on the full packaging changes needed to build octave
both with and without all graphical libraries. I suspect an octave-nox
package might also imply liboctave-noxN and liboctave-nox-dev packages,
and each would have a Conflicts on its counterpart.

-- 
mike


signature.asc
Description: PGP signature

Bug#848102: [octave] crashed with some random typing in octave editor

[Mike Miller]

On Wed, Dec 14, 2016 at 06:44:53 +, lumin wrote:
> Randomly typing something in octave editor will cause
> a crash with SIGSEGV.
> 
> For example, I launched Octave and typed merely "asdfasdf"
> and then octave crashed.

Can you please try with the version of octave currently in testing?
Since this was reported, Octave now uses Qt 5 and it's possible that
this bug only affects an older set of Qt and/or QScintilla libs.

I used to be able to trigger a similar bug by installing qt-at-spi and
setting the QT_ACCESSIBILITY environment variable. But as I understand
it the Qt 5 a11y support has been redesigned.

If octave still crashes for you, please provide your locale, keyboard
layout, and any input method settings.

-- 
mike


signature.asc
Description: PGP signature

Bug#847135: Not fixed by 7.08

[Mike Miller]

On Wed, Dec 13, 2017 at 14:06:03 +0100, Adam Cecile wrote:
> Hello,

Hi,

> 7.08 still have the issue. I cannot push a docker image through openconnect.
> It stalls around 50Mbytes.

Upstream has kindly asked for more information on your issue, can you
please provide a response to
http://lists.infradead.org/pipermail/openconnect-devel/2017-December/004618.html
?

-- 
mike


signature.asc
Description: PGP signature

Bug#878883: patch

[Mike Miller]

On Sat, Nov 04, 2017 at 22:14:22 -0400, Jeremy Bicha wrote:
> Could you do an NMU for this RC bug? I see you've done other uploads
> for this package previously.

I was going to nmu this since I thought it might be holding up the
libtomcrypt transition, but that seems to have gone ahead anyway despite
this bug. And Kevin looks to be taking care of this.

-- 
mike


signature.asc
Description: PGP signature

Bug#878883: patch

[Mike Miller]

Control: tags -1 + patch

I have filed a pull request upstream to fix this FTBFS at
https://github.com/cernekee/stoken/pull/38. I am attaching the patch
here for convenience, which can be applied cleanly to the Debian package
to fix this.

-- 
mike
From ad699a86e0f9d8c19eabccba5610b4746a5e00e3 Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmil...@debian.org>
Date: Wed, 18 Oct 2017 16:10:44 -0700
Subject: [PATCH] stc-tomcrypt: be compatible with libtomcrypt 1.18

In libtomcrypt 1.18 the LTC_LTC_PKCS_1_* constants were renamed to
LTC_PKCS_1_*.  Add an autoconf test for this change and define an alias
to the old name when building against the older API.

Signed-off-by: Mike Miller <mtmil...@debian.org>
---
 configure.ac   | 8 
 src/stc-tomcrypt.c | 7 ++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index f198048a29fa..3b93bc781597 100644
--- a/configure.ac
+++ b/configure.ac
@@ -185,6 +185,14 @@ if test "$with_tomcrypt" != no -a "$with_nettle" != yes; then
 		 EXTRA_PC_LIBS="$EXTRA_PC_LIBS $TOMCRYPT_PC_LIBS"],
 		[AC_MSG_RESULT([no])])
 
+	AC_MSG_CHECKING([whether libtomcrypt uses newer LTC_PKCS_1_V1_5 naming convention])
+	AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include ],
+		[int padding = LTC_PKCS_1_V1_5;])],
+		[AC_MSG_RESULT([yes])],
+		[AC_MSG_RESULT([no])
+		 AC_DEFINE([LIBTOMCRYPT_OLD_PKCS_NAMES], [1],
+			   [libtomcrypt uses the pre-1.18 PKCS #1 constant naming convention])])
+
 	LIBS="$saved_LIBS"
 	CFLAGS="$saved_CFLAGS"
 fi
diff --git a/src/stc-tomcrypt.c b/src/stc-tomcrypt.c
index 45b1bee7faf2..424c7360cd64 100644
--- a/src/stc-tomcrypt.c
+++ b/src/stc-tomcrypt.c
@@ -37,6 +37,11 @@
 #define AES_KEY_SIZE		16
 #define AES256_KEY_SIZE		32
 
+/* Backwards compatibility support for pre-1.18 versions of libtomcrypt */
+#ifdef LIBTOMCRYPT_OLD_PKCS_NAMES
+#define LTC_PKCS_1_V1_5 LTC_LTC_PKCS_1_V1_5
+#endif
+
 int stc_standalone_init(void)
 {
 	/* libtomcrypt init for sdtid BatchSignature generation */
@@ -190,7 +195,7 @@ int stc_rsa_sha1_sign_digest(const uint8_t *privkey_der, size_t privkey_len,
 	if (rsa_import(privkey_der, privkey_len, ) != CRYPT_OK)
 		return ERR_GENERAL;
 	if (rsa_sign_hash_ex(digest, (160 / 8), out, outlen,
-			 LTC_LTC_PKCS_1_V1_5, NULL, 0,
+			 LTC_PKCS_1_V1_5, NULL, 0,
 			 hash_idx, 0, ) != CRYPT_OK)
 		rc = ERR_GENERAL;
 
-- 
2.14.2



signature.asc
Description: PGP signature

Bug#866960: libfreetype6: blank line between characters (regression)

[Mike Miller]

Thanks for persisting on this bug. I've been affected by this as well in
terminator (vte-based) since the libfreetype6 update.

On Sun, Oct 08, 2017 at 11:53:26 +0200, Vincent Lefevre wrote:
> I'm increasing the severity because this is a visible change of
> the behavior of the library that breaks the rendering in various
> applications (at least xterm, GNU Emacs and GNOME Terminal), which
> need to change their code. I suppose that there should have been a
> proper transition, with a SONAME change.

I can confirm this with Gnome Terminal, Terminator, and gvim.

I believe all of these use libfreetype6 via libpangoft2.

> According to the upstream bug, the way some values are rounded has
> changed for the TrueType fonts, which seem to be the most common fonts
> in Debian (apparently the default). In particular, one can now have
> ascend + descend > height, which yields problems with xterm at least
> (GNU Emacs and GNOME Terminal have a similar issue, so that I assume
> that this may come from the same reason). That's a major change of
> behavior since in such a case, it yields an additional line (a blank
> line) between characters.

I scanned the upstream bug report. I don't really follow all the details
yet, but I guess a next step would be to identify packages that may be
affected by this change? So far that looks like Pango and Xft?

I'd be happy to help debug or test or whatever's needed to help resolve
this.

-- 
mike


signature.asc
Description: PGP signature

Bug#877149: octave-interval FTBFS: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?

[Mike Miller]

On Fri, Sep 29, 2017 at 10:50:08 +0300, Adrian Bunk wrote:
> Some recent change in unstable makes octave-interval FTBFS:
[…]
> error: __osmesa_print__: Depth and stencil doesn't match, are you sure you 
> are using OSMesa >= 9.0?

This is due to mesa in unstable using libglvnd now. This appears to
break Octave's attempt to use OSMesa and Mesa in the same executable
context (confirmed on other distributions also using libglvnd).

One workaround is an ugly "LD_PRELOAD=libGLX_mesa.so.0".

Other workaround is to avoid using the OpenGL-based toolkits with
figure("visible", "off").

Octave team may want to discuss whether Octave should be built with
"--without-osmesa" until a proper solution can be found upstream.
Because it's basically a useless feature in Octave now without the
LD_PRELOAD hack.

-- 
mike


signature.asc
Description: PGP signature

Bug#876363: octave fetches network resources when network access disabled

[Mike Miller]

Control: forwarded -1 https://savannah.gnu.org/bugs/?52090

On Thu, Sep 21, 2017 at 23:03:57 +0100, D Haley wrote:
> 1) The GUI should be clear as to what setting the backend is currently
> using. I think it is a concern that there are two settings that have the
> capacity to be "out-of-sync".

I've filed upstream bug https://savannah.gnu.org/bugs/?52090 to resolve
this in Octave, so at least the settings and their behavior will agree.

Feel free to participate there, or reply here if you think I got
something wrong in capturing this problem.

> 2) From a debian user's/policy perspective, I think the GUI should
> default to not using a network connection for an application where this
> might be surprising to an end user. Either querying the user again, or
> defaulting to false would be best

I will try to push for upstream to keep the default value to false. A
compromise position might be to have the first run dialog suggest that
it be enabled, but if the setting is ever deleted manually or corrupted
or unable to read in any way, it should always default to disabled.

-- 
mike


signature.asc
Description: PGP signature

Bug#876363: octave fetches network resources when network access disabled

[Mike Miller]

On Thu, Sep 21, 2017 at 19:56:30 +0100, D Haley wrote:
> It looks like the QT UI does not match what happens internally in Octave
> if the line is absent from the file.
> 
> If the line "allow_web_connection=true" is present, then the web
> connection proceeds, and the network tab in settings reflects the setting.
> 
> If the line "allow_web_connection=false" is present, then the web
> connection does not occur, and the network tab in settings reflects the
> setting.
> 
> However, if the line is entirely absent, then the connection is
> established, however *the UI does not show this*. The item in the menu
> for the network connection is unchecked.

Your analysis seems correct to me.

Is it possible the qt-settings file is created by something other than
Octave on your system? Not that this is a bad thing, but it's also not
entirely well-supported, as we've now seen.

The 'news/allow_web_connection' setting has been present and has been
checked since the GUI was first introduced in 3.8.0, so it is not likely
that this was missing due to an upgrade from a previous version. It's
more likely that the qt-settings file was modified outside of Octave or
was created or pre-seeded by some other tool.

Do you think there is any remaining issue here, or do you consider this
resolved by fixing the configuration file on your end?

Or is the only issue here that the settings dialog implies that the
missing value defaults to 'false', while the actual behavior is to
interpret a missing value as 'true'?

-- 
mike


signature.asc
Description: PGP signature

Bug#876410: libgl2ps1: please include support for SOURCE_DATE_EPOCH

[Mike Miller]

Package: libgl2ps1
Version: 1.3.9-4
Severity: wishlist
Tags: upstream

Dear Maintainer,

All files produced by gl2ps include the current time in the local time
zone. It would be helpful if this could be overridden so that files
produced using gl2ps could be deterministic.

Please consider adding support for the standard SOURCE_DATE_EPOCH
environment variable. If present, it should override the use of the
current time, and should also influence times to be written in a format
that does not depend on the local time zone or locale.

Thanks for your work on gl2ps.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libgl2ps1 depends on:
ii  libc62.24-17
ii  libgl1   0.2.999+git20170802-4
ii  libgl1-mesa-glx  17.2.1-1

libgl2ps1 recommends no packages.

libgl2ps1 suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#876363: octave fetches network resources when network access disabled

[Mike Miller]

On Thu, Sep 21, 2017 at 17:58:04 +0100, D Haley wrote:
> Thanks for getting back so quickly.  That command yields no output (no
> such line) - the file does however exist.
> 
> $ grep allow_web_connection ~/.config/octave/qt-settings
> $

Ok. That indicates that the setting is not actually being saved. It's
possible that Octave is not able to save its settings at all. Can you
check the file permissions and ownership? If you delete the file or move
it out of the way does it work as expected?

-- 
mike


signature.asc
Description: PGP signature

Bug#876363: octave fetches network resources when network access disabled

[Mike Miller]

On Thu, Sep 21, 2017 at 11:50:24 +0100, D Haley wrote:
> I was a little concerned at this message, as in the settings, the option
> "Allow Octave to connect to the Octave web site to display current news
> and information" is unchecked.

This is troubling, thanks for reporting it.

I have looked at the code, and the only way the message you quoted can
appear is indeed if Octave has attempted a web request, either
automatically at startup, or when the menu item under the News menu.

Can you verify that the option is actually disabled? What does

grep allow_web_connection ~/.config/octave/qt-settings

yield?

-- 
mike


signature.asc
Description: PGP signature

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Mike Miller]

On Tue, Sep 19, 2017 at 13:12:27 +0200, Peter P. wrote:
> Thank you Mike, switching to jackd2 does work for me as well! I am a bit
> hesitant to switch my system to jackd2 as there are some other
> applications that depend (more) on jackd1. I wonder if this workaround,
> for which I am very thankful, means that the crash with jackd1 will not
> me looked into further, or if it may be worked on nevertheless.

I also get success with jackd1:

$ jackd -r -d alsa -d hw:1 -D -r 44100 &
[1] 5042
jackd 0.125.0rc1
...
$ octave-cli -q
>> devs = audiodevinfo;  ## no crash
>> devs.output.Name
ans = HDA Intel HDMI: 0 (hw:0,3) (ALSA)
ans = HDA Intel HDMI: 1 (hw:0,7) (ALSA)
ans = HDA Intel HDMI: 2 (hw:0,8) (ALSA)
ans = HDA Intel HDMI: 3 (hw:0,9) (ALSA)
ans = HDA Intel HDMI: 4 (hw:0,10) (ALSA)
ans = hdmi (ALSA)
ans = default (ALSA)
ans = system (JACK Audio Connection Kit)
>> x = audioplayer (y, fs, nbits, 7);  ## jack ID == 7
>> play (x);  ## produces audio

I'm sorry but I use neither jackd1 nor jackd2, so this is probably as
far as I can investigate myself. And as far as I can tell they both work
with Octave. If you can investigate further and find what is causing
this on your system, please do report back. Or if you find that you can
reproduce this on a clean system and give instructions for how to do so,
someone may be able to help. But so far this looks unreproducible to me.

-- 
mike


signature.asc
Description: PGP signature

Bug#875697: arpack: debian versions 3.4.0-1 and 3.5.0-1 are actually upstream version 3.3.0

[Mike Miller]

On Wed, Sep 13, 2017 at 10:51:06 -0700, Mike Miller wrote:
> I noticed that arpack 3.4.0-1 and 3.5.0-1 are actually built from the
> upstream source version 3.3.0. The sources in the Debian archive are
> identical:

I guess this was caused by a buggy filenamemangle rule in debian/watch,
which should also be fixed:

$ uscan --destdir . --download-version 3.3.0
uscan: Newest version of arpack on remote site is 3.3.0, specified download 
version is 3.3.0
$ uscan --destdir . --download-version 3.4.0
uscan: Newest version of arpack on remote site is 3.4.0, specified download 
version is 3.4.0
$ uscan --destdir . --download-version 3.5.0
uscan: Newest version of arpack on remote site is 3.5.0, specified download 
version is 3.5.0
$ ls -lgo arpack*.tar.gz
lrwxrwxrwx 1 18 Sep 13 11:15 arpack_3.3.0.orig.tar.gz -> 
arpack-ng-0.tar.gz
lrwxrwxrwx 1 18 Sep 13 11:15 arpack_3.4.0.orig.tar.gz -> 
arpack-ng-0.tar.gz
lrwxrwxrwx 1 18 Sep 13 11:15 arpack_3.5.0.orig.tar.gz -> 
arpack-ng-0.tar.gz
-rw-r- 1 937287 Sep 13 11:15 arpack-ng-0.tar.gz

-- 
mike


signature.asc
Description: PGP signature

Bug#875697: arpack: debian versions 3.4.0-1 and 3.5.0-1 are actually upstream version 3.3.0

[Mike Miller]

Source: arpack
Version: 3.5.0-1+b1
Severity: important

Dear Maintainer,

I noticed that arpack 3.4.0-1 and 3.5.0-1 are actually built from the
upstream source version 3.3.0. The sources in the Debian archive are
identical:

$ sha256sum arpack_*.orig.tar.gz
ad59811e7d79d50b8ba19fd908f92a3683d883597b2c7759fdcc38f6311fe5b3  
arpack_3.3.0.orig.tar.gz
ad59811e7d79d50b8ba19fd908f92a3683d883597b2c7759fdcc38f6311fe5b3  
arpack_3.4.0.orig.tar.gz
ad59811e7d79d50b8ba19fd908f92a3683d883597b2c7759fdcc38f6311fe5b3  
arpack_3.5.0.orig.tar.gz

Please provide a package built from the true 3.5.0 upstream source.

Please note that this also affects stable.

Thank you for your work on arpack.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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


signature.asc
Description: PGP signature

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Mike Miller]

On Fri, Sep 08, 2017 at 10:55:21 +0200, Peter P. wrote:
> The two other programs I have installed that are using libportaudio2 are
> pure-data and audacity. And they both work with and without jack.

And here's what I just did to test locally. This is admittedly an
absolutely minimal unconfigured jack setup.

$ sudo aptitude install -y --without-recommends jackd2
$ jack_control start
$ octave-cli
>> devs = audiodevinfo;  ## no crash
>> devs.output.Name
ans = HDA Intel HDMI: 0 (hw:0,3) (ALSA)
ans = HDA Intel HDMI: 1 (hw:0,7) (ALSA)
ans = HDA Intel HDMI: 2 (hw:0,8) (ALSA)
ans = HDA Intel HDMI: 3 (hw:0,9) (ALSA)
ans = HDA Intel HDMI: 4 (hw:0,10) (ALSA)
ans = hdmi (ALSA)
ans = default (ALSA)
ans = system (JACK Audio Connection Kit)

Seems to work for me.

-- 
mike


signature.asc
Description: PGP signature

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Mike Miller]

On Thu, Sep 07, 2017 at 18:08:40 +0200, Peter P. wrote:
> Thanks for the clear instructions Mike, here it is:
> 
> ~$ gdb --args octave-cli
> [...]
> Reading symbols from octave-cli...Reading symbols from 
> /usr/lib/debug/.build-id/a7/beba93cf5339eac11d645050513a47c65388a8.debug...done.

Thanks, that looks better.

So a segmentation fault occurs in a jack client thread that must start
as a result of jack_activate, which is called by Pa_Initialize.

I don't have a jack setup to try this on at the moment. It would be
useful to see if someone else can reproduce, and also to see if other
PortAudio-based programs or simple demos work with jack.

-- 
mike


signature.asc
Description: PGP signature

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Mike Miller]

On Wed, Sep 06, 2017 at 16:10:25 +0200, Peter P. wrote:
> The backtrace I provided was already with /usr/bin/octave --no-gui. I hope a
> 'stack trace' is the same thing as a 'backtrace', at least gdb's help
> text tells me so.

But 'octave --no-gui' is not the same thing as 'octave-cli'. I would
like to see the backtrace with this crash occurring in 'octave-cli'.

This backtrace:

> (gdb) bt
> #0  0x7fffd8328bf0 in jack_thread_touch_stack () at thread.c:112
> #1  0x7fffd8328fb9 in jack_thread_proxy (varg=0x7fffd44cfa80) at 
> thread.c:128
> #2  0x744ee494 in start_thread () at 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #3  0x74232abf in clone () at /lib/x86_64-linux-gnu/libc.so.6

is not very helpful because it only shows a jack thread running, there
is nothing there about what Octave is doing.

Please try with 'octave-cli', with octave dbgsym packages installed as
well, and use 'thread apply all bt' in gdb to be sure to capture all
running threads.

-- 
mike


signature.asc
Description: PGP signature

Bug#874208: octave: audiodevinfo makes octave segfault when jackd is running

[Mike Miller]

On Mon, Sep 04, 2017 at 11:10:46 +0200, Peter P. wrote:
> audiodevinfo makes octave segfault when jackd is running. I don't know
> if the octave audio functions are supposed to support jack.

Octave's audio I/O functions are built on PortAudio, so they should work
with jackd as well as any other PortAudio program. I am pretty sure we
have had one person report success with audioplayer and jackd.

> If they
> don't it would be great if octave could nevertheless survive. Thank you
> for looking into this, I am happy to help where I can.
> 
> Here is the gdb backtrace:

Can you please provide a stack trace showing this error in octave-cli,
to eliminate Qt multithreading, and with the relevant dbgsym packages
installed?

-- 
mike


signature.asc
Description: PGP signature

Bug#873996: [Pkg-octave-devel] Bug#873996: FTBFS with Java 9 due to -source/-target only

[Mike Miller]

On Fri, Sep 01, 2017 at 21:05:45 +0100, Chris West wrote:
> This package fails to build with default-jdk pointing to openjdk-9-jdk.

If/when this needs to be patched in unstable, here is the upstream fix
that can be cherry-picked:

https://hg.savannah.gnu.org/hgweb/octave/rev/20c83f619102

-- 
mike


signature.asc
Description: PGP signature

Bug#872564: gnuplot: description text "This package is for transition" may be outdated and misleading

[Mike Miller]

Package: gnuplot
Version: 5.0.6+dfsg1-1
Severity: minor

Dear Maintainer,

You may want to consider rewriting the description text of the gnuplot
metapackage. It seems misleading to me that it includes the following

  This package is for transition and to install a full-featured gnuplot
  supporting the X11-output.

The phrase "This package is for transition" has been in the description
of the gnuplot metapackage unaltered since gnuplot 4.0.0, when
gnuplot-nox and gnuplot-x11 were introduced. I think this leads users to
believe that the package may go away at some point and that they should
not depend directly on it.

Since this metapackage still exists 13 years later, it seems that this
is not really a transitional package at all. It might help to clarify
the intent by rewording this last paragraph of the description.

Thanks for your work.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages gnuplot depends on:
ii  gnuplot-qt [gnuplot-nox]  5.0.6+dfsg1-1

gnuplot recommends no packages.

Versions of packages gnuplot suggests:
pn  gnuplot-doc  

-- no debconf information


signature.asc
Description: PGP signature

Bug#870690: [Pkg-octave-devel] Bug#870690: BuBug#870690: octave: always rebuild files generated from actual sources

[Mike Miller]

On Sun, Aug 06, 2017 at 14:51:48 +0200, Sébastien Villemot wrote:
> No, I don't think it's worth trying to fix these warnings. There are
> already many such related to dh-autoreconf.

Thanks, I noticed the additional warnings after doing a
build-clean-build cycle, agreed.

Thanks to both of you for your feedback and help. I iterated a few more
times on the list of source files to clean up, and pushed my changes at
last.

-- 
mike


signature.asc
Description: PGP signature

Bug#870690: [pkg-octave/master] d/clean: List files in the source distribution that should be rebuilt.

[Mike Miller]

tag 870690 pending
thanks

Date: Tue Aug 8 08:06:34 2017 -0700
Author: Mike Miller <mtmil...@debian.org>
Commit ID: 78f25cfe2a7d1e654c5c9fdbc015c56d003ee88c
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff;h=78f25cfe2a7d1e654c5c9fdbc015c56d003ee88c
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff_plain;h=78f25cfe2a7d1e654c5c9fdbc015c56d003ee88c

d/clean: List files in the source distribution that should be rebuilt.

Closes: #870690
  

Bug#870690: [Pkg-octave-devel] Bug#870690: Bug#870690: octave: always rebuild files generated from actual sources

[Mike Miller]

On Sat, Aug 05, 2017 at 14:37:54 +0200, Rafael Laboissière wrote:
> What about adding a debian/clean file?

Thanks for the pointer, I haven't used this file before.

> I do not think that is necessary to fiddle with Files-Excluded in
> d/copyright.  This field is actually useful for building "dfsg" tarballs,
> which is not the case here.

Good, thanks.

With debian/clean, I get a successful build. Updated patch attached.

The files AUTHORS, BUGS, and INSTALL.OCTAVE at the top level could be
rebuilt from source, but are not dependencies of the 'all' target, so
I'm leaving them as-is for now.

The plot images in the doc/interpreter directory are built by Octave,
but are best built in a fully functional OpenGL environment, so I'm
leaving them alone.

Now, I get the following messages

dpkg-source: warning: ignoring deletion of file etc/icons/octave-logo.ico, 
use --include-removal to override
dpkg-source: warning: ignoring deletion of file scripts/DOCSTRINGS, use 
--include-removal to override
…

Should I also look at adding corresponding file patterns to
extend-diff-ignore in debian/source/options to avoid these warnings?
This file is also new to me.

Thanks for your help,

-- 
mike


signature.asc
Description: PGP signature

Bug#870690: octave: always rebuild files generated from actual sources

[Mike Miller]

Source: octave
Version: 4.2.1-2
Severity: normal

In the interest of always rebuilding from the preferred form of the
upstream source using the tools and libraries packaged in Debian,
several files in the octave source distribution should be rebuilt.

The attached change adds missing Build-Depends. It also adds a hack to
d/rules to delete most of the affected files to force them to be built
by make as a proof of concept.

There are probably more elegant ways to prune the source distribution,
such as the Files-Excluded field of d/copyright (which I don't have any
experience with), suggestions welcome.

There are certainly more files that could be properly regenerated at
build time, but I think I've covered all files that end up as compiled
code.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

-- no debconf information
From e24d9cadaf022577d709c2e04af50b33689afee9 Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmil...@debian.org>
Date: Thu, 3 Aug 2017 15:06:06 -0700
Subject: [PATCH] wip: test to force rebuild distributed files

---
 debian/control |  4 
 debian/rules   | 13 +++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index fc301f4415fa..0d26b706d4b5 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Uploaders: Sébastien Villemot <sebast...@debian.org>,
 Section: math
 Priority: optional
 Build-Depends: automake,
+   bison,
debhelper (>= 10),
default-jdk,
desktop-file-utils,
@@ -15,6 +16,8 @@ Build-Depends: automake,
gfortran,
ghostscript,
gnuplot-nox,
+   gperf,
+   icoutils,
javahelper,
less,
libarpack2-dev,
@@ -37,6 +40,7 @@ Build-Depends: automake,
libqt4-dev,
libqt4-opengl-dev,
libreadline-dev,
+   librsvg2-bin,
libsndfile1-dev,
libsuitesparse-dev,
libxft-dev,
diff --git a/debian/rules b/debian/rules
index 377a69e3..e9eee4f809ee 100755
--- a/debian/rules
+++ b/debian/rules
@@ -51,8 +51,17 @@ endif
 override_dh_auto_configure:
 	# override normal dh_auto_configure call to pass OpenMP flag to it (#631831)
 	dh_auto_configure -- --enable-openmp $(WITH_JAVA_FLAGS) $(JIT_FLAG) $(HDF5_FLAGS) $(DOC_FLAG)
-	# Avoid triggering the build of oct-gperf.h
-	touch libinterp/parse-tree/oct-gperf.h libinterp/parse-tree/oct-parse.h
+	# hack to force rebuild of certain built files in source distribution
+	rm -f doc/interpreter/doc-cache libinterp/DOCSTRINGS scripts/DOCSTRINGS
+	rm -f libinterp/corefcn/*-opts.cc
+	rm -f libinterp/corefcn/oct-tex-*.cc libinterp/corefcn/oct-tex-*.h
+	rm -f libinterp/corefcn/oct-tex-lexer.ll
+	rm -f libinterp/corefcn/oct-tex-parser.yy
+	rm -f libinterp/parse-tree/lex.cc libinterp/parse-tree/oct-gperf.h
+	rm -f libinterp/parse-tree/oct-parse.cc libinterp/parse-tree/oct-parse.h
+	rm -f libinterp/parse-tree/oct-parse.yy
+	rm -f etc/icons/octave-logo*.ico etc/icons/octave-logo*.png
+	rm -f scripts/java/octave.jar
 
 # dh_auto_test tries to run "make test", so override it
 override_dh_auto_test:
-- 
2.13.2



signature.asc
Description: PGP signature

Bug#870657: [pkg-octave/master] d/control: drop useless Build-Depends on libftgl-dev.

[Mike Miller]

tag 870657 pending
thanks

Date: Thu Aug 3 12:48:47 2017 -0700
Author: Mike Miller <mtmil...@debian.org>
Commit ID: e9f204d1c39bb54ab15e37909373370230660368
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff;h=e9f204d1c39bb54ab15e37909373370230660368
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff_plain;h=e9f204d1c39bb54ab15e37909373370230660368

d/control: drop useless Build-Depends on libftgl-dev.

Closes: #870657
  

Bug#870657: octave: drop unused Build-Depends: libftgl-dev

[Mike Miller]

Successful build confirmed, no problems here.

Updated change with bug number attached.

-- 
mike
From e9f204d1c39bb54ab15e37909373370230660368 Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmil...@debian.org>
Date: Thu, 3 Aug 2017 12:48:47 -0700
Subject: [PATCH] d/control: drop useless Build-Depends on libftgl-dev.

Closes: #870657
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 71dc16208c30..fc301f4415fa 100644
--- a/debian/control
+++ b/debian/control
@@ -23,7 +23,6 @@ Build-Depends: automake,
libfftw3-dev,
libfltk1.3-dev,
libfontconfig1-dev,
-   libftgl-dev,
libgl2ps-dev,
libglpk-dev,
libgraphicsmagick++1-dev,
-- 
2.13.2



signature.asc
Description: PGP signature

Bug#870657: octave: drop unused Build-Depends: libftgl-dev

[Mike Miller]

Source: octave
Version: 4.2.1-2
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Octave has not needed the FTGL library to build for a very long time.
This change drops the libftgl-dev package from Build-Depends. Building
locally to test but I expect no consequences.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEEjM8i8+X7hnRontVHj+du6+d1fSwFAlmDgm8UHG10bWlsbGVy
QGRlYmlhbi5vcmcACgkQj+du6+d1fSxXUxAApth9azGhQO7YGLGpg0q/0DrcD51c
sICRo0d81S72OceKd17k99J1pmKqtrFOOk4fTzLBiP2kgyBl4ab+OwNS984i2V6k
JiY/yr44/KfUAF83lRIBHkkrCA1G11DuHW28Gs3VEXEO/bTwPoqibWFN7/veWW++
3bkdE3WQb5TGf5tQXFtoDKoZEeyifEi7UGP/Yi1PD1DR8AAwIojWoO7BPl14fOB4
5MFEljacVBU2W6DXENuzgBGVzwB+Nm7KqFXv3NEywSh6eQW9XqxPTu5pqiVl7bBU
oqUk8QZn0E9hBI6F0BZ55+xr9IaQXYi/sRo3z5rof0f5mq9CBTKNXx1wTC5Ip84v
qfmbyiUteU4CF4dNPQNrWINyNvbj/cGF0MIpkuUt8jmsI9l8xWstJnrMju/8IVUp
4XsVL8nc2i6YofzNTi9V9rjNSeWycRWGnJeRr3kS8Q+0ePlEURaHyJnN+7QFw5xO
N/1WDmgmvaEv4O0evQyPcnnO2SuMgZ50pTAEMeW+FkLWoNPsBZaTVhqB1EPb5DAf
A44UYo+BE7zP50hgDhkwvPXNyeBriLyqD7Il+V8ZpYnq2ru5AAejG+LBnzV0pqxo
LuHG/NL1jJSE8lUbDeAr2s2+u/pJEeye1a5woZeY9pzG35qgF7dQ4RyFuwYTwX8S
eomYoMluGsz+chM=
=Y1Bh
-END PGP SIGNATURE-
>From fd4dd9427c5abe8502bf2db7ddbed216dffa1adb Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmil...@debian.org>
Date: Thu, 3 Aug 2017 12:48:47 -0700
Subject: [PATCH] d/control: drop useless Build-Depends on libftgl-dev.

---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 71dc16208c30..fc301f4415fa 100644
--- a/debian/control
+++ b/debian/control
@@ -23,7 +23,6 @@ Build-Depends: automake,
libfftw3-dev,
libfltk1.3-dev,
libfontconfig1-dev,
-   libftgl-dev,
libgl2ps-dev,
libglpk-dev,
libgraphicsmagick++1-dev,
-- 
2.13.2

Bug#869792: Can only save either none or all passwords

[Mike Miller]

On Wed, Jul 26, 2017 at 15:34:58 +0200, Sven Bartscher wrote:
> When connecting to a VPN with juniper I get asked for a username and
> password and get the option to "Save passwords". The particular VPN
> I'm connecting to requires me to first enter a username and a password
> and afterwards asks me for a one-time password.
> 
> While it makes sense for me to save the first username and password,
> saving the one-time password doesn't make sense. Unfortunately the
> "Save passwords" option seems to affect all entered passwords at once,
> so I can either save all entered passwords or none of them.
> 
> I can work around this by just saving the one-time password. NM then
> tries to connect using the saved passwords, notices that the one-time
> password got rejected and asks me for it again. This works, but has
> the unfortunate side effect of making an unsuccessful authentication
> attempt on every connect, which causes me to get locked out of the VPN
> temporarily if I connect too often in a short amount of time.
> 
> It would be really great if it were possible to choose whether to save
> or not save for each password individually.

Thanks for your bug report. This has been reported and is being
discussed upstream, take a look at [1].

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=782480

-- 
mike


signature.asc
Description: PGP signature

Bug#868293: misguesses veth name in stretch

[Mike Miller]

On Mon, Jul 17, 2017 at 14:06:46 +0200, Marc Haber wrote:
> 3: veth0@tun0-vpnssh0:  mtu 1500 qdisc noop state 
> DOWN mode DEFAULT group default qlen 1000
> link/ether 42:0e:d1:a9:40:93 brd ff:ff:ff:ff:ff:ff
> 4: tun0-vpnssh0@veth0:  mtu 1500 qdisc noop state 
> DOWN mode DEFAULT group default qlen 1000
> link/ether 16:c0:48:f5:f1:6a brd ff:ff:ff:ff:ff:ff

I don't doubt that your system is doing this. That doesn't make it
right.

If I were you I would want to know why this is, when the kernel is
explicitly asked to create device names tun0-vpnssh0 and tun0-vpnssh1.

I can only reproduce what your system is doing with the following:

ip link add dev foo type veth peer

I suppose in this case the "peer" keyword tells the kernel that the peer
device will be fully specified, but the dev or name options are missing,
so it is named the default veth0.

If the "peer" keyword is not given, the kernel derives the names of both
devices from the same string. Your kernel appears to be breaking that
contract.

I can only hypothesize at this point

  - maybe the kernel is misreading the info sent by iproute2
  - maybe some udev/systemd device rename is happening

-- 
mike

Bug#868293: misguesses veth name in stretch

[Mike Miller]

On Sun, Jul 16, 2017 at 11:32:02 +0200, Marc Haber wrote:
> I am a quite active user of the lastest vanilla kernels and iproute, and
> have never seen an incompatibility. What kernel option would be a
> possible culprit?

I have no idea, only noticing that the one obvious difference with your
system is a local kernel. I don't follow kernel development too closely,
but I did see some small changes in the veth driver in the 4.12 release.

> Wouldn't it be a better idea to adapt the script to handle both cases?

Sure, if this is indeed a legitimate behavior. It doesn't look that way
to me yet. The command

ip link add dev tun0-vpnssh%d type veth

shouldn't create a device named veth0.

-- 
mike

Bug#868293: misguesses veth name in stretch

[Mike Miller]

On Fri, Jul 14, 2017 at 11:29:04 +0200, Marc Haber wrote:
> in stretch the vpnc-script-sshd doesn't work any more. After a while of
> debugging, I found out that the script expects the REMOTEDEV to be named
> $TUNDEV-vpnssh1, which is no longer the case in stretch's iproute.
> 
> The following patch changes the name of REMOTEDEV to veth0, which fixes
> the issue.

Hm, unable to reproduce here. I installed a fresh stretch system to test
on. As expected, the script creates a veth pair named tun0-vpnssh0 and
tun0-vpnssh1.

Are you using vpnc-script-sshd with openconnect or vpnc?

Is it possible your local kernel is incompatible with iproute2 4.9.0?
Can you test with the stock stretch kernel, or install iproute2 4.12?

-- 
mike

Bug#867230: octave-image: possible unnecessary dependency on imagemagick

[Mike Miller]

Package: octave-image
Version: 2.6.1-2
Severity: minor

I suspect the Depends: imagemagick is outdated and no longer necessary.
>From what I can tell, octave-image used to contain image functions that
called the "convert" command line utility directly. That no longer seems
to be the case. The Build-Depends does not contain imagemagick, and the
full test suite runs without it.

Does anyone know whether functions in this package still require the
imagemagick command line interface to be installed?

If it can be removed, Description making reference to ImageMagick should
also be updated / revised.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages octave-image depends on:
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libc62.24-12
ii  libgcc1  1:7.1.0-7
pn  liboctave3v5 
ii  liboctave4   4.2.1-2
ii  libstdc++6   7.1.0-7
ii  octave   4.2.1-2

octave-image recommends no packages.

octave-image suggests no packages.