Re: [gentoo-user] KDE reboot not preserving running applications
On Tue, 28 Aug 2018 20:51:06 -0400, Andrew Udvare wrote: > Was it ever perfect? I have given up on relying on this feature > especially since Chromium does not even launch after logging in again > (has not happened in a long time). I just have keyboard shortcuts set > up to get things back to how I want them (tiled in various ways, like > 50% width, 25% width/height top-left/bottom-left/..., etc). Chromium never did, so I dropped its desktop file into ~/.config/autostart. It was only when you posted this that I remember Chromium wasn't being started by the session manager -- Neil Bothwick Top Oxymorons Number 24: New classic pgps5JtHk1oEE.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Cellphone VFAT datestamps versus linux datestamps
On Tue, 28 Aug 2018 22:39:51 -0400, Walter Dnes wrote: > Given this info, I can cobble together a short script. A "for" loop > cycles through "*.jpg". Read "CreateDate" from the EXIF data, and feed > it into the "touch" command, which would reset the physical file > datestamp. You don't even need that, exiftool has a FileModifyDate tag, which is the filesystem date not an EXIF tag, so you can simply set FileModifyDate to CreateDate for each file. exiftool '-FileModifyDate pgpAHsNvIxrZW.pgp Description: OpenPGP digital signature
Re: [gentoo-user] KDE reboot not preserving running applications
On Wednesday, 29 August 2018 01:51:06 BST Andrew Udvare wrote: > > On 2018-08-28, at 18:24, Daniel Frey wrote: > > > > On 08/28/18 02:57, Peter Humphrey wrote: > >> Hello list, > >> > >> After a reboot I get "Too many clients" from the remote krells, the > >> local krell is absent (and if I restart it it comes up in the centre > >> of the screen) and Firefox attempts to run two instances. I have to > >> pkill the lot and start them again. > >> > >> If I stop these programs before rebooting, all is well when I restart > >> them later, so I suspect the KDE/plasma setup is the guilty party. > >> > >> I've reinstalled the complete system on bare silicon, created new > >> accounts for myself, and anything else I can think of, just to be sure > >> that I have nothing untoward hanging about. > >> > >> Is anyone else having this problem? > > Was it ever perfect? Always, up to the recent onset of misbehaviour. > I have given up on relying on this feature especially since Chromium does > not even launch after logging in again (has not happened in a long time). I don't often use Chromium so that doesn't bother me. > I just have keyboard shortcuts set up to get things back to how I want > them (tiled in various ways, like 50% width, 25% width/height top-left/ > bottom-left/..., etc). Perhaps I should look into that. Meanwhile it's reassuring that I'm not going ga-ga and imagining this. -- Regards, Peter.
Re: [gentoo-user] libGL symlinks vs `eselect opengl`
Hi! On Wed, 22 Aug 2018 20:33:00 +0200 Davyd McColl wrote: > The other day I installed Celestia for the entertainment of my son, who is > delighted with anything stellar / planetary. Celestia wouldn't start up, > and, long-story-short, I tracked down the issue to the symlinks: > > /usr/lib64/libGL.so > /usr/lib64/libGL.so.1 > > which ultimately point to > > /usr/lib64/libGL.so.1.2.0, > > provided by media-libs/mesa. Naturally, I assumed I'd made a mistake with > `eselect` at some point, so I checked with `eselect opengl list` and found > that, as expected, my selected opengl implementation was nvidia. Just in > case, I switched over to xorg-x11 (mesa) and back again, but this didn't > fix the problem. > > Manually redirecting these to /usr/lib64/opengl/nvidia/lib/libGL.so > (provided by x11-drivers/nvidia-drivers) works, however, of course, portage > doesn't know anything about this, so the update I received today for > media-libs/mesa reverted these symlinks back to pointing at mesa libs. > > So the questions I have are these: > 1) Am I reasonable in expecting `eselect opengl` to maintain these > symlinks? I feel like it's a reasonable expectation, but perhaps there's > just yet another thing I have to learn / understand. No, eselect opengl works differently. It uses /etc/env.d to alter LDPATH and OPENGL_PROFILE environment variables. It also changes xorg.conf. So you may need to restart your X server and source /etc/profile in active shells for changes to take effect. > 2) Should I be logging a bug (against eselect, or perhaps celestia, since > this is the only app which seems to have suffered this fate -- games like > Torchlight 2 and utils like glxgears work just fine; glxinfo reports NVIDIA > extensions), or is there just something I've fundamentally missed or messed > up here? If glxinfo reports correct data and glxgears works fine, then this may be a bug and please report it. You may CC both celestia and opengl since right now it is not obvious which is the culprit. Best regards, Andrew Savchenko pgpBED_xijwSA.pgp Description: PGP signature
Re: [gentoo-user] libGL symlinks vs `eselect opengl`
Thanks for getting back to me. I'd really like to not make a useless bug report, so please bear with me: 1. Am I correct that I should report here: https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux 2. I ask the above because I'm not entirely clear on how to CC opengl and celestia at the above url. If that's the right place (and it looks to be right), please let me know how to apply the correct CCs such that the right people get eyes on this and I'm not spamming the wrong people (: Thanks -d On Wed, 29 Aug 2018 at 18:19, Andrew Savchenko wrote: > Hi! > > On Wed, 22 Aug 2018 20:33:00 +0200 Davyd McColl wrote: > > The other day I installed Celestia for the entertainment of my son, who > is > > delighted with anything stellar / planetary. Celestia wouldn't start up, > > and, long-story-short, I tracked down the issue to the symlinks: > > > > /usr/lib64/libGL.so > > /usr/lib64/libGL.so.1 > > > > which ultimately point to > > > > /usr/lib64/libGL.so.1.2.0, > > > > provided by media-libs/mesa. Naturally, I assumed I'd made a mistake with > > `eselect` at some point, so I checked with `eselect opengl list` and > found > > that, as expected, my selected opengl implementation was nvidia. Just in > > case, I switched over to xorg-x11 (mesa) and back again, but this didn't > > fix the problem. > > > > Manually redirecting these to /usr/lib64/opengl/nvidia/lib/libGL.so > > (provided by x11-drivers/nvidia-drivers) works, however, of course, > portage > > doesn't know anything about this, so the update I received today for > > media-libs/mesa reverted these symlinks back to pointing at mesa libs. > > > > So the questions I have are these: > > 1) Am I reasonable in expecting `eselect opengl` to maintain these > > symlinks? I feel like it's a reasonable expectation, but perhaps there's > > just yet another thing I have to learn / understand. > > No, eselect opengl works differently. It uses /etc/env.d to alter > LDPATH and OPENGL_PROFILE environment variables. It also changes > xorg.conf. > > So you may need to restart your X server and source /etc/profile in > active shells for changes to take effect. > > > 2) Should I be logging a bug (against eselect, or perhaps celestia, since > > this is the only app which seems to have suffered this fate -- games like > > Torchlight 2 and utils like glxgears work just fine; glxinfo reports > NVIDIA > > extensions), or is there just something I've fundamentally missed or > messed > > up here? > > If glxinfo reports correct data and glxgears works fine, then this > may be a bug and please report it. You may CC both celestia and > opengl since right now it is not obvious which is the culprit. > > Best regards, > Andrew Savchenko > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM_uPMY *Quidquid latine dictum sit, altum sonatur. *
[gentoo-user] [SOLVED] Cellphone VFAT datestamps versus linux datestamps
On Wed, Aug 29, 2018 at 08:22:31AM +0100, Neil Bothwick wrote > On Tue, 28 Aug 2018 22:39:51 -0400, Walter Dnes wrote: > > > Given this info, I can cobble together a short script. A "for" loop > > cycles through "*.jpg". Read "CreateDate" from the EXIF data, and feed > > it into the "touch" command, which would reset the physical file > > datestamp. > > You don't even need that, exiftool has a FileModifyDate tag, which is the > filesystem date not an EXIF tag, so you can simply set FileModifyDate to > CreateDate for each file. > > exiftool '-FileModifyDate I don't run "desktop environments"; I run useful applications
