Hi,
Am Dienstag, den 18.05.2021, 13:44 +0530 schrieb Shyam Saran:
Toggle quote (22 lines)
> This below error I am getting
>
> 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)
That's a problem with DBus not finding your .service file. You can
work around that by manually starting the service from a Guix
environment (`$GUIX_ENVIRONMENT/share/dbus-1/services` should list
them) or directly from store.
FWIW launching blueman-applet directly leads to another, more confusing
DBus error. I'm not sure whether adding the dbus package to your
environment fixes any of it, but it's worth a try.
Toggle quote (96 lines)
>
> On Fri, 14 May 2021 at 03:25, Leo Prikler <
> leo.prikler@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
> >
