unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Adonay Felipe Nogueira via <help-guix@gnu.org>
To: help-guix@gnu.org
Subject: Re: Xdm trisquel login fails after installing gajim on a fresh guix install (works after rolling back)
Date: Wed, 2 Jun 2021 10:30:17 -0300	[thread overview]
Message-ID: <2532c485-266a-567b-2990-30e258d6bf3b@hyperbola.info> (raw)
In-Reply-To: <7757a79872315af6468022b36685bc9a6bdc398d.camel@metani.info>


[-- Attachment #1.1: Type: text/plain, Size: 4139 bytes --]

Hi there,


Em 02/06/2021 05:16, David Lecompte escreveu:
> One small remark though: at various times, there are messages
> recommending to set PATH, GUIX_PATH or GUIX_LOCPATH but these variables
> are actually set automatically as part of the installation process, so
> these messages are a bit misleading.

Indeed they are. It seems that the environment with which Guix daemon was called didn't emerge from "/etc/profile.d/guix.sh" , but ultimately it seems to work OK for the user since theirs did pass through that script.

> Then, when I asked to install the Guix gajim package, to my surprise,
> the output said it needs to download more than 100 MB and a crazy number
> of packages were processed, among which texlive or xorg, it took at lest
> as long as all the previous steps and both cores of my CPU were at 100%
> for more than 30 minutes. I'd love to provide some log of the output but

It might not be enough, but did you enable build substitutes when you were asked by the guix installation script?

I said that it might not be enough because, if there is no substitute for a given package definition, Guix will try to build it anyways.

> I didn't redirect it to a file and I don't know if that is kept
> somewhere.

In general, you don't need to look those up unless a build process insists on failing or has another bug of some sort. The process I did came up to find those is somewhat complex, but still if you do want to follow mine, please read on.

Most logs are kept at "/var/log/guix/drvs", but I do agree that you might need to do some searching, like this (lines starting with "$" are command lines):

$ LC_TIME=C guix package -l | grep '^[^[:space:]]'

Assuming a Guix upgrade was successful and was what caused an issue, look at the previous generation from the current one, and take the date column (since columns are separated with tabs, we want the second). However if the upgrade was not finished/registered, take the date column of the current generation.

With that said, do something like this:

$ find "/var/log/guix" -type f -newermt "[Insert date here, without these brackets]" -print

This will print a list of files (`-type f`) that were modified after said time (`-newermt`). Since "/var/log/guix" holds logs, these are all log files.

This process doesn't work well if there are other users of Guix in the same computer (including root), since all logs are printed.

Again, this is my way of doing it, other Guix users may have better options.

> When it was finished, I logged out and logged in using the default
> Trisquel xdm, my password is accepted but after maybe 30s, I get back to
> the login screen and any further attempt to log in has the same result.

I think this is related to the XDG_DATA_DIRS environment variable. While "/etc/profile.d/guix.sh" does have some directions to set it, I had to put the following into my ~/.profile file in order to login:

---- Start of text ----
export XDG_DATA_DIRS="/usr/local/share:/usr/share/${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
---- End of text ----

I did not have time to research ways to avoid this, but I guess that I'll have to fiddle with "/etc/profile.d/guix.sh" itself in order to test it more effectively.


-- 
* Ativista do software livre
	* https://libreplanet.org/wiki/User:Adfeno
	* Membro dos grupos avaliadores de
		* Software (Free Software Directory)
		* Distribuições de sistemas (FreedSoftware)
		* Sites (Free JavaScript Action Team)
	* Não sou advogado e não fomento os não livres
* Sempre veja o spam/lixo eletrônico do teu e-mail
	* Ou coloque todos os recebidos na caixa de entrada
* Sempre assino e-mails com OpenPGP
	* Chave pública: vide endereço anterior
	* Qualquer outro pode ser fraude
	* Se não tens OpenPGP, ignore o anexo "signature.asc"
* Ao enviar anexos
	* Docs., planilhas e apresentações: use OpenDocument
	* Outros tipos: vide endereço anterior
* Use protocolos de comunicação federadas
	* Vide endereço anterior
* Mensagens secretas somente via
	* XMPP com OMEMO
	* E-mail criptografado e assinado com OpenPGP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2021-06-02 13:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02  8:16 Xdm trisquel login fails after installing gajim on a fresh guix install (works after rolling back) David Lecompte
2021-06-02 13:30 ` Adonay Felipe Nogueira via [this message]
2021-06-02 17:35   ` David Lecompte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2532c485-266a-567b-2990-30e258d6bf3b@hyperbola.info \
    --to=help-guix@gnu.org \
    --cc=adfeno@hyperbola.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).