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
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
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. :^)
*
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
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
-- 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
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
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.
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: 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
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
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
libgtk-3-0_3.24.0-2_amd64 does fix the issue on my system. Great work, guys!
-- 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
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
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
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
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
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
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
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
Oops. Last one should be:
[ -d path ] && [ ! -L path ]
--
James Ronald 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 ] && [ !
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
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;
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
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
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
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
The libpmix2 update causes my MPI programs compiled with
gcc/gfortran/clang to fail at runtime with the same messages.
--
James Ronald Lovell
My MPI issues were resolved by 3.1.2-2.
Great work, guys.
--
James Ronald Lovell
Huntsville, AL, USA
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
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
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
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
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
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
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
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
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
Apologies, that msg was intended for #912528. Pls disregard.
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
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
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
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
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
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
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
Yep, update 20190329-2 fixes the issue on my system. Thanks for the great
work!
--
James Ronald Lovell
Huntsville, AL, USA
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
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
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
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
I noticed that libopenmpi-dev 4.0.2-3 now depends on libevent-dev. Thanks!
--
James Ronald Lovell
Huntsville, AL, USA
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
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):
> Should I have python3 installed?
Meant: Should I have python3-all installed?
--
James Ronald Lovell
Huntsville, AL, USA
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
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
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
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
Update 4.6.3-3 adds a depends for python3-distutils. Thank for the quick
fix!
--
James Ronald Lovell
Huntsville, AL, USA
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
Same issue as Arch issue 279267?
--
James Ronald Lovell
Huntsville, AL, USA
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
65 matches
Mail list logo
