Hi Simon,
On Sat, Dec 19 2020, zimoun wrote:
I am not sure to agree. The unexpected (by you :-)) behaviour
at hand is about Emacs and "M-x shell"; and I will not speak "in
general".
Let's avoid using the word "expected", because that word in this
context can mean different things. I don't
Hi Jorge,
On Sat, Dec 19 2020, Jorge P. de Morais Neto wrote:
It is a pity though that this workaround needs writing manual
wrappers for every affected program.
In this particular case, we can actually fix Emacs. When Emacs
spawns a child process it passes the environment as specified in
Hi Pierre,
I just wanted to share that I've experienced the same on an x200 laptop
(closing the lid no longer puts it into suspend mode).
It seems a regression; we should try to bisect which commit introduced
it. elogind? kernel? All bets are off!
Maxim
Pierre,
Pierre Neidhardt 写道：
I tried
--8<---cut
here---start->8---
(elogind-service-type config =>
(elogind-configuration
(inherit config)
(handle-lid-switch-external-power
>which is a bit more than that. Guix doesn't ship bcache-tools
(yet); are you using your own package? If so, please consider
sharing :-)
I could try to make a package.
>Have you tried this?
Yes.
On Fri, Dec 18, 2020 at 8:13 AM Tobias Geerinckx-Rice wrote:
>
> Nathan,
>
> You may well be the
Hi,
Ricardo Wurmus writes:
> Dr. Arne Babenhauserheide writes:
>
>> Carlo Zancanaro writes:
>>> One may argue that the system is functioning correctly, and this is an
>>> unfortunate consequence of the way that Guix works. I would still
>>> consider the faulty behaviour a bug - even if it is
Hi Carlo.
Em [2020-12-18 sex 20:36:11+1100], Carlo Zancanaro escreveu:
> This is true if they are in the same address space, but in this
> case evince runs as a separate process. There's no reason it has
> to load the same libraries as emacs, or have the same GTK_PATH
> variable. You should be
Nathan,
You may well be the first to (try to) use bcache on Guix System.
Nathan Dehnel 写道：
The manual https://www.kernel.org/doc/Documentation/bcache.txt
states
that udev is necessary, and it is enabled:
It says:
--8<---cut here---start->8---
I have just installed unison via Guix and on my Pi's and Mint 20 desktop
and it is working :)
I cannot see a unison-gtk option to download a graphical front end for
it, and if I install from repositories I get a version mismatch. Is
there a way to install a front end or do I have to run it
Hi Ricardo,
On Fri, 18 Dec 2020 at 13:56, Ricardo Wurmus wrote:
> It is a difficult but, in my opinion, necessary project, to prefix all
> these variables and to patch packages to use the prefixed variables for
> augmentation, while also making sense of the unprefixed variables
> (e.g. setting
Pierre,
Pierre Neidhardt 写道：
Since I've reconfigured my system some weeks ago, I've noticed a
change
with my laptop: when the power cable is in, closing the lid no
longer
suspends the machine.
Interesting that it ever did: according to the manual (and AFAIK)
the default
Hi,
On Fri, 18 Dec 2020 at 12:37, Carlo Zancanaro wrote:
> My point is: Guix manipulates environment variables in a way that
> can, and does, break "foreign" programs when Guix's programs
> launch "foreign" programs. We should consider this a bug. This bug
> might be hard, or even impossible,
Since I've reconfigured my system some weeks ago, I've noticed a change
with my laptop: when the power cable is in, closing the lid no longer
suspends the machine.
I'd like to get the old behaviour back. Any idea?
I'm on cebfb29abb151ede95696181d2446c63504593d7
with Linux 5.9.12.
--
Pierre
Hi Simon,
On Fri, Dec 18 2020, zimoun wrote:
Is your point that:
...
My point is: Guix manipulates environment variables in a way that
can, and does, break "foreign" programs when Guix's programs
launch "foreign" programs. We should consider this a bug. This bug
might be hard, or even
Carlo Zancanaro writes:
> One may argue that the system is functioning correctly, and this is an
> unfortunate consequence of the way that Guix works. I would still
> consider the faulty behaviour a bug - even if it is a result of
> intentional decisions made in Guix's design. Running evince
Hi,
On Fri, 18 Dec 2020 at 20:36, Carlo Zancanaro wrote:
> On Fri, Dec 18 2020, zimoun wrote:
>> Maybe I miss something and I have not dove into all the details
>> so I could be totally wrong. However, from my understanding, A
>> is built against the shared library C1, and B is built against
Carlo Zancanaro writes:
> I run into a similar problem where my window manager (awesomewm) sets
> LD_LIBRARY_PATH, which then propagates to everything I run from my
> session. It's quite a pain. I thought there was an open issue for
> this, but I can't seem to find it at the moment.
Hi Simon,
On Fri, Dec 18 2020, zimoun wrote:
Maybe I miss something and I have not dove into all the details
so I could be totally wrong. However, from my understanding, A
is built against the shared library C1, and B is built against
the shared library C2, and nothing says that C1 and C2
Hi,
On Fri, 18 Dec 2020 at 15:03, Carlo Zancanaro wrote:
> On Fri, Dec 18 2020, zimoun wrote:
>>> When I launch Debian's Evince from Guix's emacs-maint, Evince
>>> cannot find my local printer. Look at the messages when I open
>>> Evince in an Emacs shell and open Evince's print dialog:
>>
>>
19 matches
Mail list logo
