Bug#927221: Note Bug #927291 Files

2019-04-17 Thread 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

2019-04-17 Thread 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

2019-04-17 Thread 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

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

2019-04-17 Thread Ron Lovell
Apologies, that msg was intended for #912528. Pls disregard.

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

2019-04-17 Thread 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

Bug#918984: Comment on Message #15

2019-04-17 Thread 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

Bug#918984: Comment on Message #15

2019-04-17 Thread 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

Bug#927221: Comparisons to Other Distros

2019-04-16 Thread 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 install

Bug#927221: Comparisons to Other Distros

2019-04-16 Thread 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

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

2019-04-16 Thread 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

Bug#927221: gvfs dep on fuse

2019-04-16 Thread 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

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

2019-04-16 Thread 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

Bug#922275: libomp-7-dev

2019-03-12 Thread 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

2019-02-13 Thread 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

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

2019-01-30 Thread 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

2019-01-29 Thread 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

2018-12-28 Thread 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;

Bug#913811: Bug #913811 Correction to previous

2018-11-15 Thread Ron Lovell
Oops. Last one should be: [ -d path ] && [ ! -L path ] -- James Ronald Lovell

Bug#913811: Bug #913811iptables

2018-11-15 Thread 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 ] && [ !

Bug#910251: Bug@910251 Confirmation of Fix

2018-11-02 Thread 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

Bug#910251:

2018-10-08 Thread 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 Lo

Bug#910251:

2018-10-08 Thread 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

2018-10-03 Thread 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

Bug#908799: Confirmation of Fix

2018-09-15 Thread 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

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

2018-09-13 Thread 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

Bug#908120: gnome-terminal: confirmation of fix

2018-09-10 Thread 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

2018-09-07 Thread 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

2018-09-07 Thread 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

2018-07-18 Thread 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

Bug#903945: munge startup fails with timeout

2018-07-17 Thread 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

2018-07-16 Thread 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

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

2018-04-16 Thread 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

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

2018-04-16 Thread 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

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

2018-04-16 Thread 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

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

2018-02-21 Thread 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 a

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

2018-02-19 Thread 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

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

2018-02-16 Thread 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

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

2018-01-22 Thread 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.o

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

2018-01-22 Thread 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

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

2018-01-19 Thread 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

Bug#865471: Correction to Bug Report

2017-06-21 Thread 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. :^) *

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

2017-06-21 Thread 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

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

2017-02-28 Thread 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