This below error I am getting
$ blueman-manager
718s
blueman-manager version 2.1.4 starting
Traceback (most recent call last):
File
"/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-2.1.4/lib/python3.8/site-packages/blueman/main/Manager.py",
line 111, in on_dbus_name_appeared
check_bluetooth_status(_("Bluetooth needs to be turned on for the
device manager to function"),
File
"/gnu/store/894nlym6bvmn3cza9q775pg4f1gvixxa-blueman-2.1.4/lib/python3.8/site-packages/blueman/Functions.py",
line 73, in check_bluetooth_status
if "PowerManager" not in applet.QueryPlugins():
File
"/gnu/store/qrpkvnya5z5q2n1lc024wbxb27p9wrzq-python-pygobject-3.34.0/lib/python3.8/site-packages/gi/overrides/Gio.py",
line 351, in __call__
result = self.dbus_proxy.call_sync(self.method_name, arg_variant,
gi.repository.GLib.Error: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.blueman.Applet was not provided by any .service files (2)
(thanks for support)
On Fri, 14 May 2021 at 03:25, Leo Prikler <leo.prik...@student.tugraz.at>
wrote:
> Am Donnerstag, den 13.05.2021, 19:56 +0530 schrieb Shyam Saran:
> > many packages become nonfunctional if not install in fixed profiles
> > (e.g. ~/.guix-profile)
> While this is true, there is not necessarily a common cause for all
> such instances. Even among packages, that hardcode ~/.guix-profile,
> there might be differences, so it's better to focus on specific
> instances or groups of instances, in which one fix can be applied to
> all of them.
>
> > 1. blueman
> Please provide more information on blueman.
> > 2. font-conf so most of font like font-lohit will not be available
> This one has a history. Instead of exposing itself to the dangers of
> environment variables, fontconfig took the reasonable approach of
> letting itself be controlled by XML files, so if you want it to work
> differently from how it usually behaves, you have to edit those.
>
> > I had noticed that fixed profiles have become part of many
> > packages/services definition which could be the reason that many of
> > these packages/services become dependent on these fixed profiles.
> Which packages/services in particular?
>
> > It can be checked with
> >
> > $ ag --scheme '.guix-profile'
> > $ grep -r '.guix-profile'
> >
> > in code
> I find 65 matches including documentation. Even assuming every one of
> them was a package, it would affect about 1% of packages, many of which
> would probably be leaf packages. So while this number is definitely
> large enough to intimidate those who want to quickly fix a number of
> them, it is also smaller in scale than the report would imply.
>
> >
> > Also
> >
> > We provides necessary services through putting environment variables
> > in each profiles
> >
> > PROFILE_PATH/etc/profile
> >
> > like for pidgin/purple
> > PURPLE_PLUGIN_PATH
> >
> > for libraries
> > LIBRARY_PATH
> >
> >
> > As suggestion
> >
> > We could first provide augment all variables with guix specific
> > prefix e.g. GUIX_PEV_...
> > (PVS profile environment variables.)
> >
> > So these all variables will become
> >
> >
> > GUIX_PEV_PURPLE_PLUGIN_PATH
> > GUIX_PEV_LIBRARY_PATH
> >
> > then we could or could not (left to user) to set them
> > PURPLE_PLUGIN_PATH=$GUIX_PEV_PURPLE_PLUGIN_PATH
> > LIBRARY_PATH=$GUIX_PEV_LIBRARY_PATH
> >
> >
> > So with prefixed env vars, in first look one will know it is coming
> > from guix related profiles.
> > maybe it will also help in removing dependencies on fixed profiles.
> Guix already prefixes some environment variables, that might cause
> issues if they are read by all variants of a package with GUIX_. I
> don't think this needs to be done for every search path, however.
> Again, specific instances like GUIX_PYTHONPATH can (and should be)
> discussed, but I don't think this solves the relation to fixed
> profiles.
>
> Regards,
> Leo
>
>
