Bug#1052008: gm2-13 Cannot Find Its Libraries At Link Time

[Ron Lovell]

Package: gm2-13
Version: 13.2.0-4
Severity: important
X-Debbugs-Cc: ron163...@startmail.com

Dear Maintainer,

Since the upgrade from gm2-12 to gm2-13, the link step fails:

/usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod
FAILED: topsort_m2
/usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2ios -o topsort_m2 ../topsort.mod
/usr/bin/ld: cannot find -lm2pim: No such file or directory
/usr/bin/ld: cannot find -lm2cor: No such file or directory
/usr/bin/ld: cannot find -lm2iso: No such file or directory
collect2: error: ld returned 1 exit status

As a temporary workaround, I modified my build flags to include the
subdirectories containing links to the shared libraries:

/usr/bin/gm2 -L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2pim/
-L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2cor/ -L/usr/lib/gcc/x86_64-linux-
gnu/13/m2/m2iso/ -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod

The GNU Modula-2 packages installed are:

gm2_4:13.2.0-1_amd64
gm2-13_13.2.004_amd64
libgm2-13-dev_13.2.0-4_amd64
libgm2-18_13.2.0-4_amd64


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

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

Versions of packages gm2-13 depends on:
ii  g++-13 13.2.0-4
ii  gcc-13-base13.2.0-4
ii  libc6  2.37-9
ii  libgcc-s1  13.2.0-4
ii  libgm2-13-dev  13.2.0-4
ii  libgmp10   2:6.3.0+dfsg-2
ii  libisl23   0.26-3
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.1-1
ii  libstdc++6 13.2.0-4
ii  libzstd1   1.5.5+dfsg2-1
ii  zlib1g 1:1.2.13.dfsg-3

gm2-13 recommends no packages.

gm2-13 suggests no packages.

-- no debconf information

Bug#1021603: libpmix2

[Ron Lovell]

Should have said Arch Linux Issue 75727.

On Sun, Oct 16, 2022 at 5:20 PM Ron Lovell  wrote:

> Same issue as Arch issue 279267?
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#1021603: libpmix2

[Ron Lovell]

Same issue as Arch issue 279267?

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: Bug #953139 confirmation of fix

[Ron Lovell]

Update 4.6.3-3 adds a depends for python3-distutils. Thank for the quick
fix!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Info on other distros

[Ron Lovell]

I checked a couple of other distros I run. In Arch Linux distutils/util.py
is provided by the base "python" pkg. In openSUSE Tumbleweed it is provided
by python3-base. So among my installations, Debian Buster and Sid are the
odd ducks in that they require an optional pkg installation to provide
distutils/util.py.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Reply to Msg #20

[Ron Lovell]

Probably "what's different" is just that I decided to test qtconsole on by
Sid guest VM. I would normally run qtconsole on my host Buster system,
where jupyter_core/paths.py does not import from distutils.util, and
besides python3-distutils is already installed since it's needed by other
things I have installed like python3-pip and python3-dev.  I doubt that I
ever removed python3-distutils on Sid, it's just that I never installed
anything that explicitly deps on it.

Still, jupyter_core/paths.py in 4.6.3 does have a runtime dependency on
distutils.util, so I would recommend having python3-jupyter-core depend on
python3-distutils just in case the latter hasn't been brought in by another
dependency.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Update after python 3.8 default

[Ron Lovell]

With the latest python3-talloc update, the upgrade to python3 3.8.2
completed on my Sid host. I temporarily removed python3-distutils to verify
the situation has not changed: "juypter qtconsole" still requires
python3-distutils, and nothing brought it in as a dependency.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: BUG #953139 Correction

[Ron Lovell]

> Should I have python3 installed?

Meant: Should I have python3-all installed?
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#953139: python3-jupyter-core: Sid python3-jupyter-core 4.6.3-2 Needs python3-distutils

[Ron Lovell]

Package: python3-jupyter-core
Version: 4.6.3-2
Severity: important

After recent updates to the jupyter packages and for the Python
3.8 tranision in Sid, I decided to give qtconsole a spin just to
see how it's working. It's not able to load:

$ jupyter qtconsole
Traceback (most recent call last):
  File "/usr/bin/jupyter", line 11, in 
load_entry_point('jupyter-core==4.6.3', 'console_scripts', 'jupyter')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in 
load_entry_point

...

  File "/usr/lib/python3/dist-packages/jupyter_core/command.py", line 25, in 

from . import paths
  File "/usr/lib/python3/dist-packages/jupyter_core/paths.py", line 21, in 

from distutils.util import strtobool
ModuleNotFoundError: No module named 'distutils.util'

I was able to resolve this by installing python3-distutils, which
installs both Python 3.7 and 3.8 versions of distutils.util.

The latest /usr/lib/python3/dist-packages/jupyter_core/paths.py
module from Debian package python3-jupyter-core does import from
distutils.util. The python3-jupyter-core 4.4.0-2 installed on my
Buster host does not.

Should python3-jupyter-core now depend on package python3-distutils?

CAVEATS: The Python 3.8 transition is still a work-in-progress
on my Sid host, as I expect it is on other users'. Upgrades of
python3 libpython3-stdlib python3-minimal from 3.7.5-3 -> 3.8.2-1
are blocked because python3-talloc requires python3 (< 3.8), and
python3-talloc is (ultimately) required by gnome-control-center
via GVFS/Samba dependencies.

Also, I DO NOT have python3-all installed, which would bring in
python3-distutils. Should I have python3 installed?

My sincere apologies if I've jumped the gun and this issue would
have worked itself out as the 3.8 transition progresses. But this
could affect other qtconsole users, so I thought I should report it.

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

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

Versions of packages python3-jupyter-core depends on:
hi  python33.7.5-3
ii  python3-traitlets  4.3.3-2

python3-jupyter-core recommends no packages.

Versions of packages python3-jupyter-core suggests:
pn  python3-pip  

-- no debconf information

Bug#948112: python3-pyqt5: Unstable python3-pyqt5 Is Not Installable With libqt5qui5-gles Installed

[Ron Lovell]

Package: python3-pyqt5
Version: 5.13.2+dfsg-1
Severity: important

Currently in Sid the python3-pyqt5 package has deps:
libqt5gui5 (>= 5.1.0)
libqt5gui5 (>= 5.12.2) | libqt5qui5-gles (>= 5.12.2)

I recently performed the tranition from libqt5gui5 to the -gles variant
just to try it out. I had to remove python3-pyqt5 and and its dependents
(e.g. python3-qtconsole). I expected it might take a while to complete
the ongoing transition, and in fact in the transition tracking web
page pyqt5 still shows as in progress (or whatever orange means). But
after looking over the transition Bug #919218, especially the comments
about a similar dependency in libqt5quick5, I'm wondering if there's
going to be a resolution soon for python3-pyqt5.  If so, I can wait. If
not, I need to go back to libqt5gui5 so I can have jupyter qtconsole.

If I'm just being too impatient (we did just celebrate the holidays),
my apologies.


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

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

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.29-7
ii  libgcc1   1:9.2.1-21
ii  libpython3.7  3.7.6-1
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-5
ii  libqt5dbus5   5.12.5+dfsg-5
pn  libqt5designer5   
ii  libqt5gui5-gles   5.12.5+dfsg-1
pn  libqt5help5   
ii  libqt5network55.12.5+dfsg-5
pn  libqt5printsupport5   
pn  libqt5test5   
ii  libqt5widgets55.12.5+dfsg-5
pn  libqt5xml5
ii  libstdc++69.2.1-21
ii  python3   3.7.5-3
pn  sip-py3api-12.7   

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

NOTE: I have libqt5gui5-gles 5.12.5+dfsg-1 installed.

Bug#945121: Bug #945121 Confirmation of resolution

[Ron Lovell]

I noticed that libopenmpi-dev 4.0.2-3 now depends on libevent-dev.  Thanks!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#945120: Bug #945120 Confirmation of resolution

[Ron Lovell]

Wow, that was fast!  The Open MPI 4.0.2-3 updates appear to resolve the
issue. I say "appear" because I can't really reproduce an upgrade from
3.1.3 to 4.0.2-3.

Upgrading from 4.0.2-2 to 4.0.2-3 worked fine.

In order to test a new installation of Open MPI, I removed all Open MPI and
OpenCoarrays packages, then installed mpi-default-bin and mpi-default-dev
to bring them back. I used apt-get for that in case I needed to capture
some messages. There were no issues reported, and 4.0.2-3 works fine on my
test programs, including Co-Array Fortran tests.

I also noticed that libopenmpi-dev now depends on libevent-dev as I
suggested in Bug #945121.

Great work, guys!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#945121: libopenmpi-dev: Sid The libopenmpi-dev 4.0.x package should probably depend on libevent-dev

[Ron Lovell]

Package: libopenmpi-dev
Version: 4.0.2-2
Severity: normal

While testing the newly upgraded Open MPI 4.0.2-2 packages in Sid I
found that builds with mpicc etc. will be expecting libevent.so and
libevent_pthreads.so, which are provided by libevent-dev.

Starting with 4.0.x, shouldn't libopenmpi-dev depend on or at least
recommend libevent-dev?

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

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libhwloc-dev  1.11.13-1
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-2
ii  openmpi-bin   4.0.2-2
ii  openmpi-common4.0.2-2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.8.0-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#945120: libopenmpi-dev: Sid upgrade to libopenmpi-dev 4.0.2-2 has issues in setup step

[Ron Lovell]

Package: libopenmpi-dev
Version: 4.0.2-2
Severity: important

Dear Maintainer,

The upgrade of Open MPI components from 3.1.3 to 4.0.2-2 did not
complete successfully. During upgrade I got these warnings:

Setting up libopenmpi-dev:amd64 (4.0.2-2) ...
update-alternatives: warning: forcing reinstallation of alternative 
/usr/lib/x86_64-linux-gnu/openmpi/include because link group 
mpi-x86_64-linux-gnu is broken
update-alternatives: warning: skip creation of 
/usr/lib/x86_64-linux-gnu/libmpi++.so because associated file 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so (of link group 
mpi-x86_64-linux-gnu) doesn't exist
update-alternatives: warning: skip creation of 
/usr/lib/x86_64-linux-gnu/libmpi.so because associated file 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (of link group 
mpi-x86_64-linux-gnu) doesn't exist

As installed the libraries were not usable:

$ make
mpicc -O2 -march=native -fpie -std=c11  -D_Linux -D_XOPEN_SOURCE=700  -o 
mpi_mm.o -c mpi_mm.c
mpicc mpi_mm.o  -pie -Wl,-z,now -Wl,-z,relro  -o mpi_mm_c.linux-gnu.x86_64
/usr/bin/ld: cannot find -lmpi
/usr/bin/ld: cannot find -levent
/usr/bin/ld: cannot find -levent_pthreads
collect2: error: ld returned 1 exit status
make: *** [makefile:31: mpi_mm_c.linux-gnu.x86_64] Error 1

I found that the failure to locate -levent and -levent_pthreads was
because libevent-dev needs to be installed.

The -lmpi load failure is because the symlink

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.40.20.2

was missing when setup tried to create the symlinks

/etc/alternatives/libmpi.so-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

and

/usr/lib/x86_64-linux-gnu/libmpi.so -> 
/etc/alternatives/libmpi.so-x86_64-linux-gnu

Running dpkg-query -L libopenmpi-dev shows that

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

should have been created, but it wasn't.

On the off chance that a reinstallation might help, I reinstalled
all the 4.0.2-2 packages.  That time there were no issues reported,
the symlinks appear to be good, and Open MPI 4.0.2 works on my
test programs.

$ showlinks /usr/lib/x86_64-linux-gnu/libmpi.so
lrwxrwxrwx 1 root root 44 Nov 19 18:11 /usr/lib/x86_64-linux-gnu/libmpi.so -> 
/etc/alternatives/libmpi.so-x86_64-linux-gnu
lrwxrwxrwx 1 root root 47 Nov 19 18:11 
/etc/alternatives/libmpi.so-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
lrwxrwxrwx 1 root root 17 Nov 19 05:55 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.40.20.2
-rw-r--r-- 1 root root 1126552 Nov 19 05:55 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so.40.20.2

That's similar to the 3.1.3 scheme that I still have on my Buster host.

Is it possible that the installation script has a sequencing problem
such that it tries to target 

/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so

with a symlink from /etc/alternatives before it's been created?

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

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15]4:9.2.1-3.1
ii  gfortran-9 [gfortran-mod-15]  9.2.1-19
ii  libhwloc-dev  1.11.13-1
ii  libibverbs-dev26.0-2
ii  libopenmpi3   4.0.2-2
ii  openmpi-bin   4.0.2-2
ii  openmpi-common4.0.2-2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.8.0-1

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#922275: Bug #922275 Still Relevant for LLVM/libomp 9

[Ron Lovell]

Although I can no longer install flang-7 on my Sid host since the upgrades
to LLVM 8 and now non-default LLVM 9, the general situation described still
applies to libomp-9-dev. If a user compiles with the -fopenmp= option
(instead of simply -fopenmp), it's much better if  doesn't change from
version to version of the toolchain. It would still be helpful to have the
libomp--dev package install a symlink:

/usr/lib//libomp.so -> libomp5.so

The target libomp5.so is already maintained by libomp--dev to point
into the current  /usr/lib/llvm- directory.

I continue to keep that symlink in place as a workaround, so I'm not
suffering myself so long as I remember to create it on new installations.

Thanks for considering this request.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#933782: Bug #933782 Workaround

[Ron Lovell]

Patrice, thanks for filing the bug report. I was just looking at that bug
myself. The definition of g_tclextlib at line 41 is in new code added since
the version 4.2.2 that's in Buster.

I'm NOT a Tcl programmer or Modules guru. But is "prefix" something that
should be compiled into the modules at build time, or initialized in
/etc/environment-modules/siteconfig.tcl, or maybe in a file
/etc/environment-modules/rc?

As a workaround I edited modulecmd.tcl to replace "${prefix}" with "/usr"
at line 41. That allows /usr/share/modules/init/bash to complete
successfully and define function "module" correctly.

Hope this helps.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#933732: Bug #933732

[Ron Lovell]

Sorry, that comment was intended for Bug #933782. Pls disregard.

On Sat, Aug 3, 2019 at 9:13 AM Ron Lovell  wrote:

> Patrice, thanks for filing the bug report. I was just looking at that bug
> myself. The definition of g_tclextlib at line 41 is in new code added
> since the version 4.2.2 that's in Buster.
>
> I'm NOT a Tcl programmer or Modules guru. But is "prefix" something that
> should be compiled into the modules at build time, or initialized in
> /etc/environment-modules/siteconfig.tcl, or maybe in a file
> /etc/environment-modules/rc?
>
> As a workaround I edited modulecmd.tcl to replace "${prefix}" with "/usr"
> at line 41. That allows /usr/share/modules/init/bash to complete
> successfully and define function "module" correctly.
>
> Hope this helps.
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#933732: Bug #933732

[Ron Lovell]

Patrice, thanks for filing the bug report. I was just looking at that bug
myself. The definition of g_tclextlib at line 41 is in new code added since
the version 4.2.2 that's in Buster.

I'm NOT a Tcl programmer or Modules guru. But is "prefix" something that
should be compiled into the modules at build time, or initialized in
/etc/environment-modules/siteconfig.tcl, or maybe in a file
/etc/environment-modules/rc?

As a workaround I edited modulecmd.tcl to replace "${prefix}" with "/usr"
at line 41. That allows /usr/share/modules/init/bash to complete
successfully and define function "module" correctly.

Hope this helps.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: Bug #930628 Warning to Remove the Symlink Workaround

[Ron Lovell]

If anyone happened to have used my workaround of installed a temporary
symlink flang-mod-33 -> flang-mode-34, be sure the remove that symlink
before doing the update.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: Bug #930628 Confirmation of Fix

[Ron Lovell]

Yep, update 20190329-2 fixes the issue on my system. Thanks for the great
work!
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: Bug #930628 Another Workaround

[Ron Lovell]

Another workaround is to install a symlink:

/usr/lib/x86_64-linux-gnu/fortran/flang-mod-33 -> flang-mod-34

That's easier since it doesn't require changing my build specs.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#930628: flang-7: Flang-7 20190329-1 Does Not See Its Standard Modules

[Ron Lovell]

Package: flang-7
Version: 20190329-1
Severity: important

Dear Maintainer,

A program which uses iso_fortran_env fails to compile using the
20190329-1 build of flang-7 because flang cannot find the module:

flang -Ifortran_characters@exe -I. -I.. -Xclang -fcolor-diagnostics -pipe 
-D_FILE_OFFSET_BITS=64 -Minform=inform -O3 -march=native 
-fstack-protector-strong -std=f2003 -module fortran_characters@exe   -o 
'fortran_characters@exe/globals.f90.o' -c ../globals.f90
F90-F-0004-Unable to open MODULE file iso_fortran_env.mod (../globals.f90: 2)
F90/x86-64 Linux Flang - 1.5 2017-05-01: compilation aborted

The same program compiles successfully using the 20181226-2 build of
flang-7.

The problem can be worked around by adding this compiler option:

-I /usr/lib/x86_64-linux-gnu/fortran/flang-mod-34

In the upgrade from 20181226-2 to 20190329-1 the *.mod files moved from
a subdirectory flang-mod-33 to flang-mod-34. Does something need to be
updated in flang-7 to adjust the default module search path?


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

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

Versions of packages flang-7 depends on:
ii  libc6 2.28-10
ii  libflang-dev  20190329-1
ii  libflang0d-7  20190329-1
ii  libgcc1   1:8.3.0-7
ii  libllvm7  1:7.0.1-8
ii  libomp-7-dev  1:7.0.1-8
ii  libstdc++68.3.0-7

flang-7 recommends no packages.

flang-7 suggests no packages.

-- no debconf information

Bug#927221: Note Bug #927291 Files

[Ron Lovell]

I just filed Bug #927291 against fuse3 to suggest making fuse and fuse3
co-installable. I recommend the Arch Linux approach of adding a fuse-common
file to supply mount.fuse and fuse.conf for both fuse and fuse3.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927291: Correction

[Ron Lovell]

In the leading paragraph, that should have been:

Currently on Buster and Sid the installation of fuse3 requires removal of
fuse.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927291: fuse3: More Work Needed to Make fuse and fuse3 Co-Installable

[Ron Lovell]

Package: fuse3
Version: 3.4.1-1
Severity: wishlist

Dear Maintainer,

Currently on Buster and Sid the installation of fuse requires removal of
fuse. It would be better if they were co-installable, as is the case on
other distros I run.

Currently pkg fuse3 has to have a "breaks" on fuse because they share
files mount.fuse, fusermount, and fuse.conf (possibly others e.g. docs).
Please see Mr. Simon McVittie's comments in Bug #927221. Please also see
my comments in #927221 about how Arch Linux and openSUSE Tumbleweed have
handled the situation so that fuse[2] and fuse3 are co-installable on
those distros.

On the face of it, the Arch approach is appealing. They provide a
fuse-common package which provides fuse.conf and a mount.fuse that works
for fuse2 and fuse3. Their fuse2 supplies fusermount, and their fuse3
supplies fusermount3.

The Arch fuse3 pkg supplies versioned names for man pages, libs, and
/usr/include/fuse3 subdir, so there are no filename conflicts with
fuse2. I can provide pkg file listings if needed.

For convenience, here are the files supplied by Arch fuse-common:

$ pacman -Ql fuse-common
fuse-common /etc/
fuse-common /etc/fuse.conf
fuse-common /usr/
fuse-common /usr/bin/
fuse-common /usr/bin/mount.fuse
fuse-common /usr/lib/
fuse-common /usr/lib/udev/
fuse-common /usr/lib/udev/rules.d/
fuse-common /usr/lib/udev/rules.d/99-fuse3.rules
fuse-common /usr/share/
fuse-common /usr/share/man/
fuse-common /usr/share/man/man8/
fuse-common /usr/share/man/man8/mount.fuse3.8.gz

If that approach is taken, then in Debian both fuse and fuse3 would
be changed to require a new fuse-common package.

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

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

Versions of packages fuse3 depends on:
ii  adduser 3.118
ii  libc6   2.28-8
ii  libfuse3-3  3.4.1-1
ii  lsb-base10.2019031300
ii  mount   2.33.1-0.1
ii  sed 4.7-1

fuse3 recommends no packages.

fuse3 suggests no packages.

-- Configuration Files:
/etc/fuse.conf [Errno 2] No such file or directory: '/etc/fuse.conf'
[Strange but true -- Even though fuse3 should install a /etc/fuse.conf,
there is none, even after reinstallating fuse3.]

-- no debconf information

Bug#921528: More Work Needed to Co-install fuse and fuse3

[Ron Lovell]

Apologies, that msg was intended for #912528. Pls disregard.

Bug#921528: More Work Needed to Co-install fuse and fuse3

[Ron Lovell]

Pls see Bug #927221 against gvfs-fuse, in particular Mr. Simon McVittie's
comments. For fuse and fuse3 to be co-installable, changes need to be made
to handle the file conflicts for mount.fuse,  fusermount, and fuse.conf.
Pls see my comments on how Arch and openSUSE have handled that so that
fuse[2] and fuse3 are co-installable on those distros.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#918984: Comment on Message #15

[Ron Lovell]

I really should learn to look before I speak. I just checked Buster, and
ntfs-3g and exfat-fuse don't require a version of fuse and should coexist
with fuse3. (I have exfat-fuse installed with fuse3 on Sid). Current
gvfs-fuse has a versioned requirement; the update to close #927221 changes
that to unversioned. On my Buster system it appears pkgs archivemount and
zfs-fuse have versioned dep on fuse.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#918984: Comment on Message #15

[Ron Lovell]

Several of the dependent packages including ones you listed could coexist
with fuse3 if the fuse3 package provided a versioned "fuse" instead of the
unversioned "fuse" it provides in 3.4.1-1. Pls see Bug #927221, where
gvfs-fuse is changed to require simply "fuse", but that's the hard way to
do it. Pls see Mr. McVittie's comments in #927221.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927221: Comparisons to Other Distros

[Ron Lovell]

Correction: On Tumbleweed, pkg fuse3 supplies mount.fuse3, not mount.fuse.
On Tue, Apr 16, 2019 at 9:14 PM Ron Lovell  wrote:

> Wow, that was quick.
>
> As a sanity check, I took a look at my Arch Linux and openSUSE Tumbleweed
> installations.  Each has both fuse[2] and fuse3 installed, each has the
> corresponding library installed.
>
> For Arch, a fuse-common pkg supplies /usr/bin/mount.fuse, which happens to
> be dyn linked to libfuse 3 (per ldd(1)).  Pkg fuse2 supplies
> /usr/bin/fusermount, not dyn linked to libfuse per ldd. Pkg fuse3 supplies
> /usr/bin/fusermount3, again not linked.
> gvfsd-fuse requires fuse2 and is linked to libfuse 2. sshfs requires fuse3
> and is linked to libfuse 3.
>
> For Tumbleweed, pkg fuse supplies /usr/sbin/mount.fuse, not linked to
> libfuse per ldd. Pkg fuse3 supplies /usr/sbin/mount.fuse which links to
> libfuse 3. Pkg fuse supplies /usr/bin/fusermount, not linked. Pkg fuse3
> supplies /usr/bin/fusermount3, not linked.
>
> On both systems I was able to use the fuse2 fusermount to unmount an sshfs
> (fuse3) mount, but that doesn't mean much.
>
> So I'm a wee bit worried that not having BOTH fuse and fuse co-installed
> might uncover problems in Debian. Time for lots of testing when the bits
> are available. I'll try to help out there.
>
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>
>

-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#927221: Comparisons to Other Distros

[Ron Lovell]

Wow, that was quick.

As a sanity check, I took a look at my Arch Linux and openSUSE Tumbleweed
installations.  Each has both fuse[2] and fuse3 installed, each has the
corresponding library installed.

For Arch, a fuse-common pkg supplies /usr/bin/mount.fuse, which happens to
be dyn linked to libfuse 3 (per ldd(1)).  Pkg fuse2 supplies
/usr/bin/fusermount, not dyn linked to libfuse per ldd. Pkg fuse3 supplies
/usr/bin/fusermount3, again not linked.
gvfsd-fuse requires fuse2 and is linked to libfuse 2. sshfs requires fuse3
and is linked to libfuse 3.

For Tumbleweed, pkg fuse supplies /usr/sbin/mount.fuse, not linked to
libfuse per ldd. Pkg fuse3 supplies /usr/sbin/mount.fuse which links to
libfuse 3. Pkg fuse supplies /usr/bin/fusermount, not linked. Pkg fuse3
supplies /usr/bin/fusermount3, not linked.

On both systems I was able to use the fuse2 fusermount to unmount an sshfs
(fuse3) mount, but that doesn't mean much.

So I'm a wee bit worried that not having BOTH fuse and fuse co-installed
might uncover problems in Debian. Time for lots of testing when the bits
are available. I'll try to help out there.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Ron Lovell]

On Tue, 16 Apr 2019 14:24:21 +0100 Simon McVittie 
wrote:

> Does fuse3 provide everything that's needed to mount and unmount
older
> FUSE filesystems that are still linked to libfuse2, like gvfs-fuse?
> 
> If it does, then gvfs-fuse can depend on fuse (>= 2.8.4) | fuse3, or
> just depend on plain "fuse" which is provided by fuse3 (since 2.8.4
is

Hello, Simon,

Thanks for your quick reply. Clearly I've been focused on library deps
only and didn't understand the importance of the utility commands. Let
me dig down and understand this better. BTW, I posted the message #15
about co-installability of fuse and fuse3 before I saw your message.
Did #912528 only solve part of the problem? There appears to be a
disconnect between the Bugs database and reality.

Building a modified package locally is something I certainly need to
learn how to do, so I'll work on that. Then I know I can test fuse-
exfat, the existing sshfs 2, and set up a Samba server.

Thanks for your very informative replay.
Best regards,
Ron

Bug#927221: gvfs dep on fuse

[Ron Lovell]

I should have mentioned that I've sidestepped the whole topic of
co-installability of pkgs fuse and fuse3. Despite closure of # 912528, on
my Sid system fuse3 3.4.1-1 has an explicit "breaks" on pkg fuse. At least,
that appears to be why installing fuse3 requires removing fuse. I could be
missing something. Resolution of that situation could make gvfs-fuse
versioned dep on fuse a moot point. My suggestion assumes no resolution of
that situation and just deals with things as they are.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#927221: gvfs-fuse version-specific depend on fuse (>= 2.8.4) blocks trans to fuse3

[Ron Lovell]

Package: gvfs-fuse
Version: 1.38.1-3
Severity: important

Dear Maintainer,

Basically this regards the transition from fuse to fuse3, my primary
motivation being to make the (Debian) world safe for a modern sshfs
(3.5+). As others have pointed out (g.e. Bug #918984), trying to replace
fuse with fuse3 would require removal of gnome-core and
task-gnome-desktop. On my Sid system, at least, it all comes down to
the dependency of gvfs-fuse on fuse (>= 2.8.4). The fuse3 package
provides "fuse", but apparently that doesn't satisfy the
version-specific dependency.

Note that there's no problem (on my system) co-installing libfuse2
and libfuse3-3. So a gvfs-fuse dependency on libfuse2 should not
be a problem.

Is the current dependency of gvfs-fuse on fuse (>=2.8.4) really
necessary? Would a dep on simply 'fuse' suffice? Or dep on libfuse2?

I'm currently working around this issue by removing gvfs-fuse,
gnome-core, and task-gnome-desktop, but manually keeping many of
the otherwise-unused dependencies. I wouldn't want to try to keep
this up long-term.

I agree this sounds more like a wishlist than important issue. But
the transition to fuse3 and sshfs 3+ seems to have hit a logjam,
and I'm just trying to help move things along. Hence the 'important'
severity level. It would be great if we could have sshfs 3.5.1+ in
Buster, or if not, at least in Sid soon.

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

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

Versions of packages gvfs-fuse depends on:
ii  fuse3 [fuse]  3.4.1-1
ii  gvfs  1.38.1-3
ii  libc6 2.28-8
ii  libfuse2  2.9.9-1
ii  libglib2.0-0  2.58.3-1

gvfs-fuse recommends no packages.

gvfs-fuse suggests no packages.

Note: The info about about fuse3 [fuse] 3.4.1-1 is misleading.
gvfs-fuse is not installable with fuse3 installed.

Bug#922275: libomp-7-dev

[Ron Lovell]

Or alternatively have /usr/lib//libomp.so point to libomp5.so so it
won't have to changed with LLVM version. The libomp5.so symlink is already
maintained by libomp-dev, so it will be updated with the libomp-dev release
updates.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#922275: libomp-7-dev: Feature Request To Have libomp-7-dev Install Symlink /usr/lib//libomp.so

[Ron Lovell]

Package: libomp-7-dev
Version: 1:7.0.1-6
Severity: wishlist

Dear Maintainer,

While testing flang-7 for OpenMP programs, I noticed that 'flang
-fopenmp=libomp' doesn't know to link libomp. (clang -fopenmp=libomp
has no problem.) It's easy enough to work around that by using linker
option -L/usr/lib/llvm-7/lib in the case of libomp-7-dev, with some
smarts in my meson.build to adjust to versions other than 7.

But it would be even better if libomp--dev installed a
symlink /usr/lib//libomp.so -> ../llvm-/lib/libomp.so
Then flang and other programs would find it in a standard library
directory.

It does install a /usr/lib//libomp5.so symlink, but Clang
doesn't accept -fopenmp=libomp5.

P.S. Wondering how I'm using Meson to build programs with Flang?
I hacked Meson. Let me know if you're interested.

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

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

Versions of packages libomp-7-dev depends on:
ii  libc6   2.28-7
ii  libgcc1 1:8.2.0-20
ii  libomp5-7   1:7.0.1-6
ii  libstdc++6  8.2.0-20

libomp-7-dev recommends no packages.

Versions of packages libomp-7-dev suggests:
pn  libomp-7-doc  

-- no debconf information

Bug#920882: Confirmation of Fix in libpmix2 3.1.2-2

[Ron Lovell]

My MPI issues were resolved by 3.1.2-2.
Great work, guys.
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#920882: libpmix2 and Open MPI

[Ron Lovell]

The libpmix2 update causes my MPI programs compiled with
gcc/gfortran/clang  to fail at runtime with the same messages.
-- 
James Ronald Lovell 

Bug#917556: mesa: glxinfo Reports Mesa 18.2.7 for After 18.2.8-1 Upgrade

[Ron Lovell]

Source: mesa
Version: 18.2.8-1
Severity: normal

Dear Maintainer,

After upgrading to the Mesa 18.2.8-1 packages, glxinfo(1) still reports
the previous version:

lovelld@ron5sid:~$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: SVGA3D; build: RELEASE;  LLVM;
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 18.2.7
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.2.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Does a version string need to be updated in the source?

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

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

Newly updated Mesa packages include:
libegl1-mesa:amd64 18.2.8-1
libegl1-mesa-dev:amd64 18.2.8-1
libegl-mesa0:amd64 18.2.8-1
libgbm1:amd64 18.2.8-1
libgl1-mesa-dev:amd64 18.2.8-1
libgl1-mesa-dri:amd64 18.2.8-1
libgl1-mesa-glx:amd64 18.2.8-1
libglapi-mesa:amd64 18.2.8-1
libgles2-mesa-dev:amd64 18.2.8-1
libglx-mesa0:amd64 18.2.8-1
libwayland-egl1-mesa:amd64 18.2.8-1
libxatracker2:amd64 18.2.8-1
mesa-common-dev:amd64 18.2.8-1
mesa-va-drivers:amd64 18.2.8-1
mesa-vdpau-drivers:amd64 18.2.8-1
mesa-vulkan-drivers:amd64 18.2.8-1

Bug#913811: Bug #913811 Correction to previous

[Ron Lovell]

Oops. Last one should be:

[ -d path ] && [ ! -L path ]

-- 
James Ronald Lovell 

Bug#913811: Bug #913811iptables

[Ron Lovell]

I still remember the first time that one bit me: "[ -e path]" fails if path
is a dead symlink. There are other pitfalls testing symlinks.  Some idioms
I use:

Does path exist?
[ -e path ] || [ -L path ]

Is path really a regular file?
[ -f path ] && [ ! -L path ]

A directory?
[ -d path ] && [ ! -d path ]
-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#910251: Bug@910251 Confirmation of Fix

[Ron Lovell]

The delays and warning messages for my MPI programs on Sid were resolved by
the workaround fix in libpsm2 11.2.68-2. You can close this one as far as
I'm concerned.

Thanks,
Ron
-- 
James Ronald Lovell 
Huntsville, AL, USA
A distributed system is one in which the failure of a computer you
didn't even know existed can render your own computer unusable.
-Leslie Lamport

Bug#910251:

[Ron Lovell]

That should be libpsm2-2 11.2.68-1, not .78.

On Mon, Oct 8, 2018 at 1:39 PM Ron Lovell  wrote:

> Alastair,
>
> Thanks for the quick update. I see that I upgraded to libpsm2-2 11.2.78-1
> on 01 Oct 2018, so the timing fits.
>
> Thanks,
> Ron
> --
> James Ronald Lovell 
> Huntsville, AL, USA
>


-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#910251:

[Ron Lovell]

Alastair,

Thanks for the quick update. I see that I upgraded to libpsm2-2 11.2.78-1
on 01 Oct 2018, so the timing fits.

Thanks,
Ron
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#910251: libopenmpi3 3.1.2-5 Introduces 15s Delay and hfi_wait_for_device Messages

[Ron Lovell]

Package: libopenmpi3
Version: 3.1.2-5
Severity: normal

Dear Maintainer,

I updated Open MPI and libpmix2 on my Sid X86_64 system this afternoon:
Open MPI 3.1.2-5
libpmix2 3.0.2-2

My simple MPI tests run to completion and give correct results, but
there is an abnormal delay in startup and new warning messages. Example:

INFO:Executing build/mpi_mm_c
mpiexec -np 2 build/mpi_mm_c < mpi_mm_c.in > mpi_mm_c.tmp 2>mpi_mm_c.err
ron5sid.10482hfi_wait_for_device: The /dev/hfi1_0 device failed to appear after 
15.0 seconds: Connection timed out
ron5sid.10483hfi_wait_for_device: The /dev/hfi1_0 device failed to appear after 
15.0 seconds: Connection timed out
mpi_mm has started with 2 tasks.
...
(rest of results are normal)

I did some research online. Red Hat Bug 1408316 from a couple years ago
was to fix libfabric 1.4.1 in RHEL7 to not wait for /dev/hfi* devices if
OPA/HFI hardware is not present. Occurred when system had PSM2 installed
but no OPA/HFI hardware.

My system does have libfabric1-1.6.1-5, which libopenmpi3 depends on.
My system does have libpsm-infinipath1 and libpsm2-2, which libopenmpi3
depends on.

I noticed this note in the "Changes" for openmpi 3.1.2-5:
"* Drop link-libfabric.patch as obsolete"
Relevant? What did the obsolete patch do?

I see in my test results that my MPI tests passed 12 Sep 2018, when 3.1.2-2
or 3.1.2-3 was current. I don't see any record of testing 3.1.2-4.

I'm filing this as "normal" severity, since my programs do run correctly.
It's a slight practical nuisance as my test jobs flag changed output as
possible problems. (Helpful in this case.)

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

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

Versions of packages libopenmpi3 depends on:
ii  libc62.27-6
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libfabric1   1.6.1-5
ii  libgcc1  1:8.2.0-7
ii  libgfortran5 8.2.0-7
ii  libhwloc-plugins 1.11.11-2
ii  libhwloc51.11.11-2
ii  libibverbs1  20.0-1
ii  libpmix2 3.0.2-2
ii  libpsm-infinipath1   3.3+20.604758e7-5
ii  libpsm2-211.2.68-1
ii  libquadmath0 8.2.0-7
ii  libstdc++6   8.2.0-7
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages libopenmpi3 recommends:
ii  openmpi-bin  3.1.2-5

libopenmpi3 suggests no packages.

-- no debconf information

Bug#908799: Confirmation of Fix

[Ron Lovell]

New packages libcoarrays-openmpi-dev and libcaf-openmpi-3 2.2.0-3 do
resolve the issue on my system.

I'm proceeding on the assumption that cafrun(1) (from old package
open-coarrays-bin) might never return to Debian, so I'm switching to
mpiexec(1) on all my Linux VMs (the others being Fedora Rawhide and
openSUSE Tumbleweed). That seems to be working fine for me.

Thanks for the quick fix!
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#908799: libcaf-openmpi-3: Package libcaf-openmpi-3 Should Probably Install in lib Subdir

[Ron Lovell]

Package: libcaf-openmpi-3
Version: 2.2.0-2
Severity: important

Dear Maintainer,

I just updated to the new OpenCoarrays packaging on my x86_64 Sid system.
While updating my meson.build files, I found that the caf-openmpi.pc
pkg-config file installed by package libcoarrays-openmpi-dev assumes the
library will be in /usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib/,
whereas package libcaf-openmpi-3 actually installs it in parent
directory /usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/.  I'm guessing
caf-openmpi.pc is right, and your intention was to have libcaf-openmpi-3
install in the lib subdir. Using a temporary modified caf-openmpi.pc
in my PKG_CONFIG_PATH which sets the -L arg to the actual location, I
was able to compile and link a gfortran test program. I tested execution
using mpiexec(1), as cafrun(1) left with removal of the open-coarrays-bin
package. (Forever? I don't expect it to be an issue for me.)

By the way, I haven't tried the MPICH equivalent OpenCoarrays packages.
They might have the same issue (in libcaf-mipch-3).

I probably should file this next item as a separate wishlist item.
The installation of caf-openmpi.pc in
/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib/pkgconfig/ is
outside pkg-config's default global search path. I added the dir to my
PKG_CONFIG_PATH for testing. For the convenience of users, how about a
symlink in /usr/lib/x86_64-linux-gnu/pkgconfig pointing to the installed
caf-openmpi.pc?  In a similar way that libopenmpi-dev installs a symlink
to the actual ompi.pc file.

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

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

Versions of packages libcaf-openmpi-3 depends on:
ii  libc6 2.27-6
ii  libgcc1   1:8.2.0-6
ii  libgfortran5  8.2.0-6
ii  libopenmpi3   3.1.2-3
ii  libquadmath0  8.2.0-6

libcaf-openmpi-3 recommends no packages.

libcaf-openmpi-3 suggests no packages.

-- no debconf information

Bug#908120: gnome-terminal: confirmation of fix

[Ron Lovell]

libgtk-3-0_3.24.0-2_amd64 does fix the issue on my system. Great work, guys!

Bug#908120: gnome-terminal: Cursor disappears when changing or moving windows

[Ron Lovell]

I just noticed that none of our messages mention that this is an issue only
for Wayland GNOME sessions. So starting an Xorg GNOME session is a
temporary workaround.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#908120: gnome-terminal: Cursor disappears when changing or moving window

[Ron Lovell]

Yeah, me too. Issue appeared evening of 05 Sep 2018 in Sid after a number
of possibly relevant updates:
GLib 2.58.0-2
GTK 3.24.0
GNOME Shell 3.30
Wayland libs 1.16.0
Mutter 3.30

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#903945: munge startup fails with timeout

[Ron Lovell]

After receiving Chris Dunlap's quick reply, I've installed and enabled
haveged on my Linux VMs (Sid, Rawhide, and Tumbleweed where it was already
installed).  I reverted my change to timeout value in the munged unit
file.  All is well so far.  With haveged installed, I don't expect to need
a munge package change for my purposes.

Thanks again Chris for the very useful reply.
Best regards,
Ron

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#903945: munge startup fails with timeout

[Ron Lovell]

I reinstalled the 4.16 kernel to confirm that munged starts normally under
4.16 with the default systemd timeout.  It does.

But now I'm no longer able to reproduce the problem when running the 4.17
kernel.  I dunno.

Has anyone else seen the munged timeout failures?  I'll update as I learn
more.

Bug#903945: munge startup fails with timeout

[Ron Lovell]

Package: munge
Version: 0.5.13-1
Severity: important

Dear Maintainer,

munged fails to start at system boot. From sample journal entries:

Jul 16 22:17:56 ron5sid systemd[1]: munge.service: Start operation timed out. 
Terminating.
Jul 16 22:19:26 ron5sid systemd[1]: munge.service: State 'stop-final-sigterm' 
timed out. Killing.
Jul 16 22:19:26 ron5sid systemd[1]: munge.service: Killing process 723 (munged) 
with signal SIGKILL.
Jul 16 22:19:26 ron5sid systemd[1]: munge.service: Failed with result 'timeout'.
Jul 16 22:19:26 ron5sid systemd[1]: Failed to start MUNGE authentication 
service.

... deleted ...

Jul 16 22:20:21 ron5sid kernel: random: crng init done
Jul 16 22:20:21 ron5sid kernel: random: 7 urandom warning(s) missed due to 
ratelimiting

I've included the latter part because I suspect munged timeout is caused
by too long a delay reading /dev/urandom or /dev/random, causing systemd
to time it out.

As a workaround, I inserted this is the [Service] section of
/lib/systemd/system/munge.service:

TimeoutSec=60s

With that in place, munged starts successfully at boot, at least for the
few restarts I've done. I haven't tried to find a lower timeout value
than 60s.

I don't know how long this problem has been present, but no earlier than
01 July, because I ran some tests under Slurm then.  Perhaps it started
around the time Sid got the 4.17 kernel, which I installed 03 July.
Wasn't there a 4.17 change in kernel random number generation which
might have introduced (more) blocking on early random number fetches?

I'm runing Sid in a VM under VMware Workstation Player 14.1.2 hosted on
Windows 7 on a fairly quick laptop. Other setups and hardware would have
different entropy generation characteristics so maybe not all munge
installations will see this problem.

Severity rating "important" is based on Slurm batch system being useless
without Munge service.

Best regards,
Ron

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

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

Versions of packages munge depends on:
ii  adduser  3.117
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-5
ii  libgcrypt20  1.8.3-1
ii  libmunge20.5.13-1
ii  lsb-base 9.20170808
ii  zlib1g   1:1.2.11.dfsg-1

munge recommends no packages.

munge suggests no packages.

-- no debconf information

Bug#895827: Confirm Fix in Open MPI 3.0.1-5 Build

[Ron Lovell]

 The issue is resolved for my system by the 3.0.1-5 build. I tested
interactively and as part of a Slurm batch job where I let Slurm provide
the task count to mpiexec(1). (No -np option.)

I also confirmed that installation of libpmix2 is not required.

Great work!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#895327: Confirm Fix in Open MPI 3.0.1-5 Build

[Ron Lovell]

The issue is resolved for my system by the 3.0.1-5 build. I tested
interactively and as part of a Slurm batch job where I let Slurm provide
the task count to mpiexec(1). (No -np option.)

I also confirmed that installation of libpmix2 is not required.

Great work!

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#895827: libopenmpi-dev: broken symlink: libpmix.so, and not installed libpmix.so.2.1.1

[Ron Lovell]

I've had the same issue since the upgrade to Open MPI 3.0.1. ompi_info(1)
also shows the problem.  The libpmix.so.2.1.11 library can be provided by
the libpmix2 package. I just updated to libpmix-dev and libpmix2
2.1.1~rc1-2 with the fix for Bug 895772. The reference to libpmix.so.2 gets
resolved for mpiexec(1) and ompi_info(1), but another failure occurs:

$ mpiexec -np 2 build/mpi_mm_c < mpi_mm_c.in > mpi_mm_c.tmp 2>mpi_mm_c.err
[ron5sid:24570] mca_base_component_repository_open: unable to open
mca_pmix_pmix2x:
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix2x.so:
undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version (ignored)
[ron5sid:24570] [[42725,0],0] ORTE_ERROR_LOG: Not found in file
ess_hnp_module.c at line 649
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort
... (more) ...
  opal_pmix_base_select failed
  --> Returned value Not found (-13) instead of ORTE_SUCCESS


$ ompi_info
[ron5sid:24578] mca_base_component_repository_open: unable to open
mca_pmix_pmix2x:
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix2x.so:
undefined symbol: OPAL_MCA_PMIX2X_PMIx_Get_version (ignored)
 Package: Open MPI pbuilder@debian Distribution
Open MPI: 3.0.1rc5
... (more) ...

So, is it intended that libpmix2 always be used with Open MPI 3.0?  In that
case it should probably be a dependency of openmpi-bin or libopenmpi3 or
some other openmpi package.

Are libpmix-dev and libpmix2 2.1.1* ready for Open MPI 3.0?  Or are there
3.0.* versions in the works?

Or maybe Open MPI 3.0 should have been built --with-pmix=internal, as was
done in Fedora when I looked last year. (Apologies if this one is
completely off the mark.)

I'm excited about the Open MPI 3.0 upgrade in Sid. I'll keep testing as
things develop.

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#890844: Fwd: python3-keyrings.alt 2.2-2 module.__file__ is None, causing regrtest.py to fail

[Ron Lovell]

-- Forwarded message --
From: Ron Lovell <ron163...@gmail.com>
Date: Mon, Feb 19, 2018 at 8:45 PM
Subject: python3-keyrings.alt 2.2-2 module.__file__ is None, causing
regrtest.py to fail
To: 890...@bugs.debian.org, 890...@bugs.debian.org


If I'm following correctly, it appears the issue with python3-keyrings.alt
and libpython3.6-testsuite could be resolved with this change to
libregrtest/setup.py:

60c60
< if hasattr(module, '__file__'):
---
> if getattr(module, '__file__', None):

That works as before for missing __file__, and it works as desired for
module object 'keyrings' where __file__ == None when imported to python3.6.

Currently for python3.7 (beta 1) in Sid, no fix is needed in
libpython3.7-testsuite, since module object 'keyrings' has no __file__
attribute when imported to python3.7 beta 1. But to simplify and to handle
future cases, I think you will want to modify the 3.7 regression tests
setup.py as well.

Thanks all for the great work on this.
Ron
-- 
James Ronald Lovell <ron163...@gmail.com>
Huntsville, AL, USA

Bug#890621: python3-keyrings.alt 2.2-2 module.__file__ is None, causing regrtest.py to fail

[Ron Lovell]

If I'm following correctly, it appears the issue with python3-keyrings.alt
and libpython3.6-testsuite could be resolved with this change to
libregrtest/setup.py:

60c60
< if hasattr(module, '__file__'):
---
> if getattr(module, '__file__', None):

That works as before for missing __file__, and it works as desired for
module object 'keyrings' where __file__ == None when imported to python3.6.

Currently for python3.7 (beta 1) in Sid, no fix is needed in
libpython3.7-testsuite, since module object 'keyrings' has no __file__
attribute when imported to python3.7 beta 1. But to simplify and to handle
future cases, I think you will want to modify the 3.7 regression tests
setup.py as well.

Thanks all for the great work on this.
Ron
-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#890621: python3-keyrings.alt 2.2-2 module.__file__ is None, causing regrtest.py to fail

[Ron Lovell]

Package: python3-keyrings.alt
Version: 2.2-2
Severity: important

Dear Maintainer,

When package 'keyrings' from python3-keyrings.alt is imported under
python3.6, the module object has a __file__ attribute with a value None.
This causes early failure of the Python 3.6 regression tests  from
libpython3.6-testsuite.

The problem occurs starting at line 60 of
/usr/lib/python3.6/test/libregrtest/setup.py, within a loop on the
module objects listed in sys.modules.values().  The module object for
'keyrings' has a __file__ attribute, but it is None, so the call to
os.path.abspath() fails with a TypeError on the non-string argument
passed to it.

Please note that when the 'keyrings' package from python3-keyrings.alt is
imported into python3.7 (python3.7_3.7.0~b1-1_amd64), the
'keyrings' module object has no attribute __file__.  Hence the tests
from libpython3.7-testsuite run, even though libregrtest/setup.py
is identical to the 3.6 version.

Note also that when module keyrings.alt (as opposed to package
keyrings) is imported in python3.6, the 'keyrings.alt' module object
has a proper string-valued __file__ attribute.  That doesn't help with
the regression tests, however, since a 'keyrings' module object is
listed in sys.modules.values().

It would appear that initialized module objects from import of
package 'keyrings' should not have a __file__ attribute at all,
which is consistent with python3.7's initialization.

I happen to have python3-keyrings.alt installed because
python3-jupyter-core recs python3-pip, which  recs python3-wheel, which
recs python3-keyrings.alt. I could probably remove the package without
missing it.

But my current workaround, and one you might consider, is to modify
/usr/lib/python3.6/test/libregrtest/setup.py:

60c60
< if hasattr(module, '__file__'):
---
> if hasattr(module, '__file__') and module.__file__ != None:

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

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

Versions of packages python3-keyrings.alt depends on:
ii  python3 3.6.4-1
ii  python3-crypto  2.6.1-8
ii  python3-six 1.11.0-2

python3-keyrings.alt recommends no packages.

Versions of packages python3-keyrings.alt suggests:
ii  gir1.2-gnomekeyring-1.0  3.12.0-1+b2
ii  python3-gi   3.26.1-2

-- no debconf information

Bug#888050: Fwd: [Pkg-utopia-maintainers] Bug#888050: network-manager: Debian Unstable network-manager 1.10.2-3 does not complete processing

[Ron Lovell]

-- Forwarded message --
From: Ron Lovell <ron163...@gmail.com>
Date: Mon, Jan 22, 2018 at 5:11 PM
Subject: Re: [Pkg-utopia-maintainers] Bug#888050: network-manager: Debian
Unstable network-manager 1.10.2-3 does not complete processing
To: Michael Biebl <bi...@debian.org>


Yes indeed, that worked great.  I then did a restart, and status of
NetworkManager looks
normal. Thanks!

That's a problem with us retired folks. We have all that time on our hands,
so we update
too quickly.  It's a pleasure to give back to projects that have been
important to me all
these years.

Again, thanks.


On Mon, Jan 22, 2018 at 5:01 PM, Michael Biebl <bi...@debian.org> wrote:

> Am 22.01.2018 um 23:53 schrieb Ron Lovell:
> > Hi Michael,
> >
> > Thanks for the quick reply. Looks like I updated to 1.10.2-2 earlier in
> > the day yesterday,
> > then the 1.10.2-3 update came later in the day yesterday.  Sounds like
> > it fits. Journal
> > messages for NetworkManager.service startup are quite confusing; looks
> > like it kinda
> > starts but parts fail later.
> >
> > How do I recover?
>
> Sorry for that.
> I quickly made the -3 upload in the hope that not too many users would
> have upgraded to -2 in the mean time.
>
> How do you recover? If you kill the running NetworkManager processes
> manually via "sudo pkill NetworkManager", then manually start NM via
> "sudo systemctl start NetworkManager" and then proceed with the failed
> upgrade via dpkg --configure -a , does it work?
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>


-- 
James Ronald Lovell <ron163...@gmail.com>
Huntsville, AL, USA



-- 
James Ronald Lovell <ron163...@gmail.com>
Huntsville, AL, USA

Bug#888050: network-manager: Debian Unstable network-manager 1.10.2-3 does not complete processing

[Ron Lovell]

Package: network-manager
Version: 1.10.2-3
Severity: important

Dear Maintainer,

The update of network-manager fails to complete. I noticed before
applying the update that several packages would be removed, including
libnm-gtk0, libnm-utils2, and libnm-glib4. The dependencies appeared
to revolve around the update to gnome-shell.  The network-manager
package is currently in partly-configured state ("C"). Otherwise,
system appears to work okay.

Sample output while doing an update with aptitude, showing attempt
to restart NetworkManager.service to complete the network-manager configuration:

Setting up network-manager (1.10.2-3) ...
Job for NetworkManager.service failed because the control process exited with 
error code.
See "systemctl status NetworkManager.service" and "journalctl -xe" for details.
invoke-rc.d: initscript network-manager, action "restart" failed.
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2018-01-22 
16:17:25 CST; 8ms ago
 Docs: man:NetworkManager(8)
  Process: 21857 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=exited, 
status=1/FAILURE)
 Main PID: 21857 (code=exited, status=1/FAILURE)
Tasks: 5 (limit: 19660)
   CGroup: /system.slice/network-manager.service
   ├─546 /usr/sbin/NetworkManager
   └─668 /sbin/dhclient -d -q -sf 
/usr/lib/NetworkManager/nm-dhcp-helper -pf /run/dhclient-ens33.pid -lf 
/var/lib/NetworkManager/dhclient-66793b0c-aedd-4d44-b870-dd8f4b4e7425-ens33.lease
 -cf /var/lib/NetworkManager/dhclient-ens33.conf ens33

Jan 22 16:17:25 ron5sid systemd[1]: NetworkManager.service: Main process 
exited, code=exited, status=1/FAILURE
Jan 22 16:17:25 ron5sid systemd[1]: NetworkManager.service: Failed with result 
'exit-code'.
Jan 22 16:17:25 ron5sid systemd[1]: Failed to start Network Manager.
dpkg: error processing package network-manager (--configure):
 installed network-manager package post-installation script subprocess returned 
error exit status 1

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

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

Versions of packages network-manager depends on:
ii  adduser3.116
ii  dbus   1.12.2-1
ii  libaudit1  1:2.8.2-1
ii  libbluetooth3  5.47-1+b1
ii  libc6  2.26-4
ii  libcurl3-gnutls7.57.0-1
ii  libglib2.0-0   2.54.3-2
ii  libgnutls303.5.17-1
ii  libjansson42.10-1
ii  libmm-glib01.6.8-2
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-1+b1
ii  libnl-3-2003.2.27-2
ii  libnm0 1.10.2-3
ii  libpam-systemd 236-3+b1
ii  libpolkit-agent-1-00.105-18
ii  libpolkit-gobject-1-0  0.105-18
ii  libpsl50.19.1-4
ii  libreadline7   7.0-3
ii  libselinux12.7-2
ii  libsystemd0236-3+b1
ii  libteamdctl0   1.26-1+b1
ii  libudev1   236-3+b1
ii  libuuid1   2.30.2-0.3
ii  lsb-base   9.20170808
ii  policykit-10.105-18
ii  udev   236-3+b1
ii  wpasupplicant  2:2.6-15

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base 2.78-1
ii  iptables 1.6.1-2+b1
ii  iputils-arping   3:20161105-1
ii  isc-dhcp-client  4.3.5-3+b2
ii  modemmanager 1.6.8-2
ii  ppp  2.4.7-1+4

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

-- no debconf information

Bug#887755: open-vm-tools-desktop: Debian Unstable per-session user-owned vmtoolsd segfaults afer upgrade to 2:10.2.0-1

[Ron Lovell]

Package: open-vm-tools-desktop
Version: 2:10.2.0-1
Severity: important

Dear Maintainer,

After upgrade to open-vm-tools[-desktop] 2:10.2.0-1 in Sid, the
per-session user-owned vmtoolsd process segfaults in libgdk while
logging into a Wayland GNOME session. The problem does not occur
for an Xorg GNOME session.

This problem appears to be identical to the known problem reported
in Red Hat Bug 1526952 and (my) SUSE Bug 1073760. Note that in
openSUSE Tumbleweed the problem occurred for open-vm-tools-desktop
10.1.15 as well as 10.2.0, so it might not simply be a bug introduced
with your upgrade. Note that Fedora have released a workaround, and my
understanding is that VMware are working on a permanent fix involving
rework of the plugins to handle Wayland.

For an Xorg session:
lovelld@ron5sid:~$ ps -ef | grep vmtoolsd
root417  1  0 10:30 ?00:00:02 /usr/bin/vmtoolsd
lovelld3442  1  0 10:41 tty2 00:00:02 /usr/bin/vmtoolsd -n vmusr 
--blockFd 3
lovelld4087   3847  0 11:04 pts/200:00:00 grep -d skip --color=auto 
vmtoolsd

For a Wayland session, the process running as me (with the -n vmusr option) is
not present, and the journal shows it segfaults in libgdk. See the Red Hat
and SUSE bugs for further details, including stack traces.


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

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

Versions of packages open-vm-tools-desktop depends on:
ii  fuse 2.9.7-1
ii  libatk1.0-0  2.26.1-2
ii  libatkmm-1.6-1v5 2.24.2-3
ii  libc62.26-4
ii  libcairo-gobject21.15.8-3
ii  libcairo21.15.8-3
ii  libcairomm-1.0-1v5   1.12.2-2
ii  libdrm2  2.4.89-1
ii  libgcc1  1:7.2.0-19
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-1
ii  libglibmm-2.4-1v52.54.1-2
ii  libgtk-3-0   3.22.26-2
ii  libgtkmm-3.0-1v5 3.22.2-2
ii  libice6  2:1.0.9-2
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangomm-1.4-1v5   2.40.1-4
ii  libsigc++-2.0-0v52.10.0-1
ii  libsm6   2:1.2.2-1+b3
ii  libstdc++6   7.2.0-19
ii  libudev1 236-3
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.3-1+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxtst6 2:1.2.3-1
ii  open-vm-tools2:10.2.0-1

Versions of packages open-vm-tools-desktop recommends:
ii  xauth   1:1.0.10-1
pn  xserver-xorg-input-vmmouse  
ii  xserver-xorg-video-vmware   1:13.2.1-1+b1

Versions of packages open-vm-tools-desktop suggests:
ii  xdg-utils  1.1.2-1

-- no debconf information

Bug#865471: Correction to Bug Report

[Ron Lovell]

I had the story wrong about the symlinks in /usr/lib/x86_64-linux-gnu/. The
*.so.20 links were missing, so the

*.so links that pointed to them were dead links.  The workaround doesn't
have to create the *.so links since

they were already in place. It just brought them back to life. :^)

*   Ron

Bug#865471: libopenmpi2: Missing Symlinks to Open MPI Libraries

[Ron Lovell]

Package: libopenmpi2
Version: 2.1.1-4
Severity: important
Tags: newcomer

Dear Maintainer,

After upgrade to libopenmpi2_2.1.1-4_amd64, libopenmpi-dev_2.1.1-4_amd64
etc. my programs failed to compile because the compiler and linker
(using mpicc and mpifort provided by libopenmpi-dev)
could not locate MPI libraries. I found that several symlinks in
/usr/lib/x86_64-linx-gnu were dead links:
libmca_common_sm.so.20
libmpi_mpifh.so.20
libopen-pal.so.20
libopen-rte.so.20

By following the example of working links, I was able to manually
set up the needed links pointing to /usr/lib/x86_64-linux-gnu/openmpi/lib/
and then link lib*.so.20 to those links. The commands (as root) were:

ln -s openmpi/lib/libopen-pal.so.20.10.1 
/usr/lib/x86_64-linux-gnu/libopen-pal.so.20.10.1
ln -s libopen-pal.so.20.10.1 /usr/lib/x86_64-linux-gnu/libopen-pal.so.20
ln -s openmpi/lib/libopen-rte.so.20.10.1 
/usr/lib/x86_64-linux-gnu/libopen-rte.so.20.10.1
ln -s libopen-rte.so.20.10.1 /usr/lib/x86_64-linux-gnu/libopen-rte.so.20
ln -s openmpi/lib/libmca_common_sm.so.20.10.1 
/usr/lib/x86_64-linux-gnu/libmca_common_sm.so.20.10.1
ln -s libmca_common_sm.so.20.10.1 
/usr/lib/x86_64-linux-gnu/libmca_common_sm.so.20
ln -s openmpi/lib/libmpi_mpifh.so.20.11.0 
/usr/lib/x86_64-linux-gnu/libmpi_mpifh.so.20.11.0
ln -s libmpi_mpifh.so.20.11.0 /usr/lib/x86_64-linux-gnu/libmpi_mpifh.so.20

After making those changes, my MPI programs compile, link, and execute
normally.

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

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

Versions of packages libopenmpi2 depends on:
ii  libc6   2.24-12
ii  libfabric1  1.4.0-1
ii  libgcc1 1:7.1.0-7
ii  libgfortran36.3.0-19
ii  libhwloc-plugins1.11.5-1
ii  libhwloc5   1.11.5-1
ii  libibverbs1 1.2.1-2
ii  libpsm-infinipath1  3.3+19.g67c0807.open-3
ii  libquadmath07.1.0-7
ii  libstdc++6  7.1.0-7

Versions of packages libopenmpi2 recommends:
ii  openmpi-bin  2.1.1-4

libopenmpi2 suggests no packages.

-- no debconf information

Bug#856429: open-vm-tools: vgauth.service Unit File is Missing VGAuthService Option -s

[Ron Lovell]

Package: open-vm-tools
Version: 2:10.1.5-5055683-1
Severity: normal
Tags: newcomer

Dear Maintainer,

   * What led up to the situation?
 After a recent update added the vgauth.service unit file, I checked
 the status of vgauthd.service.  While it apparently starts, I noticed
 there was no logging to /var/log/vmware-vgauthsvc.log.0. Comparing
 the setup to my Rawhide and Tumbleweed installations,
 I noticed that unlike Rawhide and Tumbleweed, Debian's
 /lib/systemd/system/vgauth.service does not use the -s option to
 VGAuthService. According to the program's help info, -s causes
 it to run in daemon mode. Note that the current Debian setup is
 consistent with the sample unit file provided in BUG#855337, which
 also omits the -s option.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I modified /lib/systemd/system/vgauth.service to add the -s option
 on the ExecStart line: ExecStart=/usr/bin/VGAuthService -s

   * What was the outcome of this action?
 The service starts, and (significantly) it logs to
 /var/log/vmware-vgauthsvc.log.0.

   * What outcome did you expect instead?
 The workaround was as expected.

 NOTE: I'm afraid I don't have a vSphere setup to test how the vgauth
 service is working.  It is possible that without the -s option, the
 service won't work.  It is also possible that the omission was for a
 good reason that I don't know about.

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

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

Versions of packages open-vm-tools depends on:
ii  init-system-helpers1.47
ii  libc6  2.24-9
ii  libdumbnet11.12-7+b1
ii  libfuse2   2.9.7-1
ii  libgcc11:6.3.0-8
ii  libglib2.0-0   2.50.3-1
ii  libicu57   57.1-5
ii  libmspack0 0.5-1
ii  libprocps6 2:3.3.12-3
ii  libssl1.0.21.0.2k-1
ii  libstdc++6 6.3.0-8
ii  libxerces-c3.1 3.1.4+debian-2
ii  libxml-security-c17v5  1.7.3-4
ii  pciutils   1:3.5.2-1

Versions of packages open-vm-tools recommends:
ii  ethtool  1:4.8-1
ii  fuse 2.9.7-1
ii  lsb-release  9.20161125
ii  zerofree 1.0.4-1

Versions of packages open-vm-tools suggests:
ii  open-vm-tools-desktop  2:10.1.5-5055683-1

-- Configuration Files:
/etc/vmware-tools/tools.conf changed:
[The file is empty, as shipped.]

-- no debconf information