Bug#1052008: gm2-13 Cannot Find Its Libraries At Link Time
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
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
Same issue as Arch issue 279267? -- James Ronald Lovell Huntsville, AL, USA
Bug#953139: Bug #953139 confirmation of fix
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Apologies, that msg was intended for #912528. Pls disregard.
Bug#921528: More Work Needed to Co-install fuse and fuse3
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
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
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
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
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
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
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
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
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
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
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
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
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
Oops. Last one should be: [ -d path ] && [ ! -L path ] -- James Ronald Lovell
Bug#913811: Bug #913811iptables
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
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
-- Forwarded message -- From: Ron Lovell 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 Huntsville, AL, USA
Bug#890621: python3-keyrings.alt 2.2-2 module.__file__ is None, causing regrtest.py to fail
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
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
-- Forwarded message -- From: Ron Lovell 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 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 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 Huntsville, AL, USA -- James Ronald Lovell Huntsville, AL, USA
Bug#888050: network-manager: Debian Unstable network-manager 1.10.2-3 does not complete processing
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
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
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
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
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