On 8/25/19 2:50 PM, Pierre Labastie via blfs-support wrote:
On 25/08/2019 20:09, DJ Lucas via blfs-support wrote:
On 8/23/2019 7:56 PM, Ken Moffat via blfs-support wrote:
On Fri, Aug 23, 2019 at 09:39:41PM +0200, Pierre Labastie via blfs-support
wrote:
Will try using obconf in lxde.
Pierre
Hi Pierre,
not sure if https://issues.guix.info/issue/35118 might help for gdm.
Some of the details look to be very specific to guix, but in patch 2
localed is extracted from systemd and an xkeyboard patch is added.
But all the wiring-up seems to be specific to how guix do things.
Well, that seems like an interesting approach, and was fairly easy to do (took
me about 20m...less time than it took for me to write this email in fact), but
the Guix solution just uses "GUIX_XKB_*" environment variables. I hacked up a
patch to elogind to mimic what Guix did if you want to fiddle with it and see.
It does introduce a hard dependency on xkb-common. I renamed the workaround
environment variables without the GUIX_ prefix. I haven't done any testing
other than verifying that it builds and installs correctly (into DESTDIR, so
at least no linking issues with elogind). The additional source files in the
locale directory were taken directly from systemd-241. The variables that need
to make their way into GDM's environment are
XKB_{LAYOUT,MODEL,VARIANT,OPTIONS} (without configured /etc/vconsole.conf
anyway), so it's a lot of systemd cruft left for just a simple workaround, but
if it works, I could put a bit more time into it. Despite comment #6 in the
above thread, it really wouldn't be _that_ difficult to decouple from elogind,
but elogind would require a couple of small changes already in the patch below
(or the handful of reintroduced functions added directly to the targets or a
tiny libelocaled, but I'd much rather get these back into elogind and just
depend on it).
http://www.linuxfromscratch.org/~dj/elogind-241.3-add_localed-1.patch
--DJ
First, no joy trying to tweak greeter-dconf-defaults. This could have been
expected, since the source seems to rely on org.freedesktop.locale1
Will try the patch, to confirm that problems come from the lack of localed,
but I fear that we may encounter another problem: GNOME sets the local time to
UTC, and while I can open the time-date configuration, I cannot save the
settings, and it falls back to UTC on a minute change. I suspect the lack of
datetimed...
The same thing happens with Plasma actually. It's because we operate
with /etc/localtime being a file instead of a symbolic link in SysV.
With a symbolic link to the user's time zone (from /etc/localtime to
/usr/share/zoneinfo/<x>/<y>), the GNOME and KDE settings centers and
clocks both will reflect the correct time instead of UTC.
I'd like to suggest a change for that, but I know it'll probably be met
with opposition because we still support a split /usr system. We could
do this to work around it though:
cp -v /usr/share/zoneinfo/<x>/<y> /etc/timezone
ln -sv timezone /etc/localtime
(Or something similar, I was gone for a couple days and will be again
for a short period this afternoon, so I'm trying to catch up on email.
This may have already been addressed, and if it has, I apologize for the
noise)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
