Re: Start Xorg server using xinit manually

2021-03-22 Thread Bone Baboon
Gary Johnson writes:

>   I run EXWM under Guix System.

It is good to hear that someone else is able to successfully use EXWM
with Guix.

> You don't need to manually start Xorg
> with xinit, startx, or any other command. First, make sure that you are
> installing emacs and emacs-exwm into your packages list. Also make sure
> that your services list includes %desktop-services. Here's a skeleton
> operating-system definition to build off of:
>
> (operating-system
>  ...
>  (packages (cons* nss-certs   ; HTTPS access
>   emacs
>   emacs-exwm
>   %base-packages))
>
>  (services (cons* whatever-else
>   you-want
>   %desktop-services)))
>
> Start by installing this operating-system definition with the usual
> `sudo guix system reconfigure my-config.scm`.
>
> Then update your $HOME/.xsession file to include this at the end:
>
> # Start Emacs with the script here: /run/current-system/profile/bin/exwm
> exwm
>
> Finally, update $HOME/.exwm to include all your EXWM-specific Emacs Lisp
> code.
>
> When you reboot your machine, you'll be presented with a simple
> graphical login screen. Just type in your username and password for the
> user account with the updated $HOME/.xsession and $HOME/exwm files and
> log in. X will start up, your $HOME/.xsession file will be read, which
> will launch exwm. This will start up a full screen emacs instance that
> evaluates your $HOME/.exwm file and then your $HOME/.emacs.d/init.el
> file.
>
> That's all there is to it. Now you've got a fully graphically enabled
> Emacs instance running as a tiling window manager over X.

Thank you for the detailed instructions.

When I follow the instruction and boot I am taken to vt7 which has only
a blinking cursor. I never get a graphical login for X. The system is
responsive and I can switch to other virtual terminals.

On vt1 there is output like this:

New session c1 of user gdm.
Removed session c1.
New session c2 of user gdm.
Removed session c2.
New session c3 of user gdm.
Removed session c3.
...



Re: Start Xorg server using xinit manually

2021-03-22 Thread Leo Famulari
On Mon, Mar 22, 2021 at 10:11:57PM -0400, nylxs wrote:
> or it could be not broken,

Thanks for the hint!



Re: cannot "guix pull"

2021-03-22 Thread Sergiu Ivanov
Thus quoth  Leo Famulari  on Mon Mar 22 2021 at 01:11 (+0100):
> I'm happy to help, but unfortunately, the paste that included the error
> messages is no longer online:
>
> https://lists.gnu.org/archive/html/help-guix/2021-03/msg00184.html
>
> This illustrates why it is important to include all relevant details of
> a problem in the email, rather than linking to external sites.
>
> Can any of you share the error messages, to refresh my memory?

I attach the complete error log as the plain text file
original-error-message.  It's the message I got today, but I think I got
the same or a very similar message a couple of days ago.  (And I didn't
save it because I thought it was transient.)

> I was hoping to use the following info to see if you were using a
> version of Guix that preceded a bug fix, but now I can't tell. I do
> think your bug has been fixed recently, and that `guix pull && sudo guix
> system reconfigure ...` will fix your problem, but I wanted to be sure.

Yaay!  It worked!

Not directly though: I did a `guix gc` first, because I seemed stuck on
the same error message all the time, then I had to run `guix pull`
multiple times, because I was getting different error messages.
I attach the files transient-error-1 and transient-error-2 to give some
examples, but I got about 5 or 6 of them in total.

guix pull did manage to finish successfully though, so I'm quite happy,
and I can live with occasional transient network issues.

`sudo guix system reconfigure /etc/config.scm` has showed some download
errors, but they consistently went away when I retried the command, so
that's fine.

Thank you the Guix team for working hard!

> Here are some general observations and advice:

Thank you very much for taking your time!

> On Sun, Mar 21, 2021 at 09:27:12AM +0100, Sergiu Ivanov wrote:
>> Thus quoth  Leo Famulari  on Sat Mar 20 2021 at 23:10 (+0100):
>> > $ guix describe
>> 
>> Generation 5Mar 16 2021 10:31:09(current)
>>   [blurred]
>>   guix db87d6d
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: db87d6ddafd26c5ad657178cf7fdab524d05c522
>
> Okay. This is a recent version of Guix.
>
>> > $ sudo --login guix describe
>> 
>> Generation 1 Feb 02 2021 10:36:19(current)
>>   [blurred]
>>   guix 625708b
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: 625708b03a37fc2a33c437b8e27856ca76965f43
>
> This is probably the Guix at '/root/.config/guix/current/bin/guix'. That
> is the root user's Guix command, created and updated with `guix pull` as
> root. It's from early February.

Ah, just reading this paragraph fixed things in my brain.  I moved the
directory /root/.config/guix to some temporary place from where I will
delete it soon.

>>   $ sudo su
>>   $ guix describe
>> 
>> which gave me
>> 
>> guix c8887a5
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: c8887a5c6e8f6a19d54ffa428c6fe88a797b867a
>
> This is probably the system's Guix command, at
> '/run/current-system/profile/bin/guix'. It's recent.

Yes!  After moving /root/.config/guix away, both `sudo --login guix
describe` and first doing `sudo su` and then `guix describe` give me the
same results, probably because both are running the same system's
Guix command.

I was quite confused by getting different results in these two cases,
and I really happy to have sorted this out.  (Also, later in this
message I learnt something about sudo and su :-))

> Based on this, I guess you are updating the system by `guix pull` as
> your regular user and then `sudo guix system reconfigure ...`. Is that
> correct?

Yes, exactly.

I once accidentally did `sudo guix pull`, which brought in that extra
Guix in /root/.config/guix, but I don't normally do that.

> The different results between those two sudo commands shows an important
> and confusing issue with privilege elevation on Linux:
>
> There is a difference between plain `sudo` and `sudo --login`.
>
> `su` is an entirely different command, and it also does something
> different than `su --login`.
>
> Basically, plain `sudo` and `su` put the user into an incomplete and
> typically unexpected environment, as compared to using the "--login"
> options. One could say they turn you into "nobody", but with privileges.
>
> In general, I recommend to learn the difference between them and use
> them accordingly.
>
> On old-school distros, there is not usually a big problem, but on Guix
> it really matters, because we use the login shell initialization to
> export some environment variables, and the resulting environment is what
> provides the per-user view of installed packages. 
>
> So, if you don't login when elevating privileges, you get a weird
> environment and your view of Guix will be unexpected. As you noticed,
> the environment you got from `sudo su` lacked any user's packages or
> channels.

Thank you very much for the explanation!  I have just c

Re: Start Xorg server using xinit manually

2021-03-22 Thread Leo Famulari
On Mon, Mar 22, 2021 at 07:34:25PM +0100, Vincent Legoll wrote:
> Hello Gary,
> 
> On Mon, Mar 22, 2021 at 5:49 PM Gary Johnson  wrote:
> > [...] Nicely described stuff
> 
> I think this would make a nice additional recipe for the cookbook.
> 
> WOGT ? (What Other Guixers Think)

Absolutely! People ask about this subject at least a few times each
year.



Re: Start Xorg server using xinit manually

2021-03-22 Thread Vincent Legoll
Hello Gary,

On Mon, Mar 22, 2021 at 5:49 PM Gary Johnson  wrote:
> [...] Nicely described stuff

I think this would make a nice additional recipe for the cookbook.

WOGT ? (What Other Guixers Think)

-- 
Vincent Legoll



Re: Start Xorg server using xinit manually

2021-03-22 Thread Leo Famulari
On Sun, Mar 21, 2021 at 07:21:06PM -0400, nylxs wrote:
> Becuse he wants to.
>   This is always a loaded question making an excuse to avoid answering
> it.  It should just work from the command line, no excuses, because the
> user wants it that way.

It has never been simple on Guix System to use xinit / startx, and we
have always recommended that users instead use the relevant Guix
services in order to launch a graphical system.

If it's very important that plain `xinit` should work on Guix System, we
invite helpers :)



Re: Start Xorg server using xinit manually

2021-03-22 Thread Gary Johnson
> March 21, 2021 6:31 PM, "Bone Baboon"  wrote:
>
> I am trying to manually run `xinit` so that I can use Emacs X Window
> Manager (EXWM). I have EXWM configured in my Emacs configuration file.
> I have a small number of important graphical applications I want to
> run in EXWM (web browser, Jami, qTox, ...).

Hi Bone,

  I run EXWM under Guix System. You don't need to manually start Xorg
with xinit, startx, or any other command. First, make sure that you are
installing emacs and emacs-exwm into your packages list. Also make sure
that your services list includes %desktop-services. Here's a skeleton
operating-system definition to build off of:

(operating-system
 ...
 (packages (cons* nss-certs   ; HTTPS access
  emacs
  emacs-exwm
  %base-packages))

 (services (cons* whatever-else
  you-want
  %desktop-services)))

Start by installing this operating-system definition with the usual
`sudo guix system reconfigure my-config.scm`.

Then update your $HOME/.xsession file to include this at the end:

# Start Emacs with the script here: /run/current-system/profile/bin/exwm
exwm

Finally, update $HOME/.exwm to include all your EXWM-specific Emacs Lisp
code.

When you reboot your machine, you'll be presented with a simple
graphical login screen. Just type in your username and password for the
user account with the updated $HOME/.xsession and $HOME/exwm files and
log in. X will start up, your $HOME/.xsession file will be read, which
will launch exwm. This will start up a full screen emacs instance that
evaluates your $HOME/.exwm file and then your $HOME/.emacs.d/init.el
file.

That's all there is to it. Now you've got a fully graphically enabled
Emacs instance running as a tiling window manager over X.

Have fun and happy hacking!
 ~Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
===
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



Re: Start Xorg server using xinit manually

2021-03-22 Thread Bone Baboon


Thanks for your reply.

jbra...@dismail.de writes:

> March 21, 2021 6:31 PM, "Bone Baboon"  wrote:
>
> May I ask why you are trying to manually run xinit?  Is your favorite wm
> or desktop environment not packaged as a service in Guix?  Ahh, I see you
> are just trying to start Emacs.  Very awesome!

I am trying to manually run `xinit` so that I can use Emacs X Window
Manager (EXWM).  I have EXWM configured in my Emacs configuration file.
I have a small number of important graphical applications I want to run
in EXWM (web browser, Jami, qTox, ...).

> If all you are wanting is to use Emacs, you could always just launch Emace
> from the virtual console, and not have mouse support.

If I run `emacs` from a virtual terminal in the *Messages* buffer it
says "[EXWM] Not running under X environment".

I am currently working without `xorg` in virtual terminals or in Emacs
with `emacsclient --tty`.  I am really appreciating `eww` as a browser
that is in Emacs.



Re: Start Xorg server using xinit manually

2021-03-22 Thread nylxs
On 3/21/21 7:05 PM, jbra...@dismail.de wrote:
> May I ask why you are trying to manually run xinit?


Becuse he wants to.
  This is always a loaded question making an excuse to avoid answering
it.  It should just work from the command line, no excuses, because the
user wants it that way.




Re: error: corrupt input while restoring archive from socket

2021-03-22 Thread Fulbert
Le Tue, Mar 09, 2021 at 08:48:25AM +0100, Fulbert a écrit :
> For the past few days… maybe a couple of weeks (not sure when
> it started exactly), I have had frequent errors with
> substitutions. Those errors are not [always] reproducible as
> another [or more] installation attempt succeed on the same [set of]
> file[s].

For the past few `guix pull`… within a couple of days, I've been abble
to upgrade guix and all my profiles with no errors.

Whatever caused it seems to be fixed ! Thanks to the unknown working in
the shadows ;)