Re: Xdm trisquel login fails after installing gajim on a fresh guix install (works after rolling back)

[Adonay Felipe Nogueira via]

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



signature.asc
Description: OpenPGP digital signature

Re: Is there something similar to nix overlays in guix?

[Adonay Felipe Nogueira via]

Em 05/03/2021 16:20, Vinícius dos Santos Oliveira escreveu:
> You don't want to be a slave to upstream developers' decisions and
> want to apply out-of-tree patches that automatically propagate to the
> rest of the packages ecosystem.

I don't know the specifics of the non-free software Nix, but by experience I 
think that one of those might suit your case:

a) the (package (source (origin (patches …) …) …) …) definition, where stuff is 
applied right after being unpacked/extracted, before configuring and building. 
If you are dealing with GNU FSDG issues or things which will be upstreamed, 
this would be the perfect place for the patch since you wouldn't be forcing the 
source package to use Guix's store paths or Guix-specific changes. It also 
means that people who do guix build -S will receive the source with patches 
applied;

b) an invocation of GNU patch from (package (arguments (modify-phases …) …) …), 
allowing you to do as (a) but for Guix-specific changes;

c) use of (package (replacement …) …) to your own package definitions to 
provide grafts (see `info guix "Security Updates" ` for the requirements and 
caveats), but note that, since I don't use this option, I don't know much about 
how to implement it;

d) invoking guix build — or those with support for its transformation options — 
with --with-patches=PACKAGE=FILE, to do it like (a);

e) same as (d), but with --with-grafts=PACKAGE=REPLACEMENT, to do it like (c);

f) same as (d), but with --with-latest=PACKAGE, to force a given 
build/install/upgrade to use the latest known version of PACKAGE instead of the 
one from the built package's definition. This of course comes at a price, as 
can be read on `info guix "Package Transformation Options" `


-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: flatpak applications in the gnome applications menu (XDG_DATA_DIRS)

[Adonay Felipe Nogueira via]

Em 07/02/2021 15:59, Christophe Pisteur escreveu:
> I installed Element (1) by flatpak, but applications installed by

First question is: why is Flatpak being distributed by Guix without any patch 
to conform to GNU FSDG?

Perhaps this is another instance of bug #45450 ([1]).

Also, unfortunately it seems that the software in question downloaded from 
there isn`t free/libre either ([2]).


# References


[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45450 .

[2]: https://directory.fsf.org/wiki/Review:Riot.im-REV-ID-1 .

-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: rust: where is cargo?

[Adonay Felipe Nogueira via]

Em 26/12/2020 12:02, Tobias Geerinckx-Rice escreveu:
>> I know that guix approach is to replace package managers
> 
> I don't think that's true.
Also see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45450 .

-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: rust: where is cargo?

[Adonay Felipe Nogueira via]

Em 26/12/2020 12:02, Tobias Geerinckx-Rice escreveu:
>> I know that guix approach is to replace package managers
> 
> I don't think that's true.
It's half true, valid to the extent that, contrary to cargo's default 
repository, Guix's default follows the GNU FSDG, which also requires that every 
other repository referenced in that one or by the community also expresses the 
same commitment. If there is one reference to one which doesn't, then such 
reference should either be replaced, removed or there must be an agreement 
between the parties to fix this in the referenced repository.

The act of removing such reference is sometimes done by not including the 
referrer package, and this is done when there is not much resource left to deal 
with the fact that other repository must be created.

It's common practice for free/libre system distributions to provide a “GNU 
FSDG” bug/issue/task tag/section for cases where they provide packages that 
refer to third-party repositories not committed to the GNU FSDG, along other 
cases not compliant with GNU FSDG. If cargo is indeed included.


-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: ebook reader recommendations?

[Adonay Felipe Nogueira via]

Em 04/12/2020 09:34, Sébastien Lerique escreveu:
> On a side-note, the same Davis also develops RCU 
> , which I would love to manage to package 
> for Guix, but my first attempts have led into deeper waters than I could 
> solve, fixing problems with python-pyside-2. If anyone else is interested in 
> this, let me know and we can get it done!

Don't forget to also make this into a thread on the Guix development mailing 
list and open an issue/task/bug in the tracker so Guix community can better 
organize the efforts. :)


-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: ebook reader recommendations?

[Adonay Felipe Nogueira via]

Em 03/12/2020 05:58, Pierre Neidhardt escreveu:
> I'm looking for an open ebook reader, at least something that runs free
> software.

Perhaps this question should be directed to the team inside FSF responsible for 
doing hardware evaluation, namely, Respects Your Freedom.


-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: Zoom

[Adonay Felipe Nogueira via]

Em 14/11/2020 06:46, Pierre Neidhardt escreveu:
> Turns out IceCat has no trouble with WebRTC, it's only the Jitsi rejects
> the user-agent! :p
> 
> There is a popular "user agent switcher" extension: install it, set the
> user agent to the latest Firefox and you'll be good to go!

Please fill a bug against Jitsi-Meet on it's own issue/task tracker,
good webdesign tests for capabilities, not user-agent (Jitsi-Meet is
like an app inside a website). In the description, provide steps to
counter that at end-user level too. If/when that issue/task is reported,
remember to reference that others so that they can see how to accomplish
that.


-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: Zoom

[Adonay Felipe Nogueira via]

Em 13/11/2020 15:15, Roy Lemmon escreveu:
> Can anyone give me hints on getting Zoom installed with sound ?

Unless I'm mistaken, this is related to the software described in [1],
right?

If that is the case, then the Guix community won't be able to officially
help in this matter.

Computers are somewhat dumb, they understand only 0s and 1s. However,
humans cannot easily tell what these do, they need ways to both inspect
what is being, make changes, share and sell any of these, all of which
is made easy if the copyright holder of the work (Zoom Video
Communications, Inc and many others) were to distribute the source code
in any customary mean of file distribution, along with a license that
guarantees such rights to everyone.

In other words, it's tempting for the copyright holder to keep these
rights to themselves, due to the possibility for abusing the users of
the software. So, in the world of computers, for any work/data that can
be used practically/functionally (not just software), you as a user have
only two possibilities: either you exercise collective control of the
data, so that you can call upon others to help you do so when you're
incapable of; or someone controls the data and can misuse this position
to limit what you can do.

So, the Guix community won't be able to do much here due to the fact
that the copyright holder of Zoom did not give you, and us all, the
essential freedoms of the software, that is: the freedom to use it for
any purpose (freedom 0); to study and adapt it for any purpose, and
reuse de adaptations (freedom 1); to share and sell unlimited copies of
the original (freedom 2); and to do the same as 2, but for modified copies.

Guix being a project and a community committed to the Free System
Distribution Guidelines of the GNU project (GNU FSDG or simply FSDG)
([2]), cannot assist on the matters exclusively related to non-free
functiona/practical work/data, or those not mentioned in this message
that are still mentioned in the FSDG. In short, the official Guix
repositories, documentation, and the community won't be able to help.

However, excluding the kludge made by the copyright holders of Zoom,
there's no technological measures stopping you from using this thing.
It's advisable that you don't foster usage of this stuff by others.


# References


[1]: https://en.wikipedia.org/wiki/Zoom_(software) .

[2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html .


-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: Vanilla Firefox recipe?

[Adonay Felipe Nogueira via]

I came late to this issue, but I think this should have been posted on
development mailing list. It's not good if we use the general help list
to foster non-free software like Firefox or those which are third-party
package managers with no default repository explicitly commited to
following the GNU FSDG.

Furthermore, to ease the sides of both the thread starter and the
community, I'm taking a simplification in that I'm considering the use
of such non-free software for purpose of developing or improving a free
replacement. That means I'm not discussing the merit of whether the
question should or shouldn't have been answered the way it was.

One must be remind though, that the GNU FSDG isn't only about the
packages distributed (software, documentation, text fonts, etc), but
also about the community, and this is one of the things that keep Debian
out of the list of free system distributions.

Em 12/05/2020 16:23, Efraim Flashner escreveu:
> On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:
>>
>> Christopher Lemmer Webber  skribis:
>>
>>> Anyone have a package definition (or channel) for a recent vanilla
>>> firefox?
>>>
>>> I understand the decision to prefer distributing Icecat instead in Guix
>>> proper, but I need a more recent version of things... I suspect others
>>> sometimes do too.  I have a feeling at least someone in the community
>>> has written such a definition... would you mind sharing?
>>>
>>> Thanks!
>>>  - Chris
>>
>> Hi,
>>
>> There is a channel at
>> https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
>> definition for Firefox 74.0.1. I haven't tested it though.
> 
> Other options include using the now official flatpak copy of firefox. If
> you do go that route make sure to use the '--user' flag for flatpak so
> it doesn't segfault while trying to write to /var/lib/flatpak.
> 

-- 
* 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



signature.asc
Description: OpenPGP digital signature

Why did those credit managers start to burn my phone after I visited bank?

[Adonay Felipe Nogueira via]

One thing that might help is switching to free/libre system
distributions for phones[1], there is Replicant in that list currently.
There are somethings that it doesn't protect from, but for that you
should ask them.

Besides, install GNU Icecat to have various other security and software
freedom improvements, besides LibreJS to avoid the JavaScript trap[2] or
have JS entirely disabled and a paranoid browser as default.

Even with that, be careful with ultrasound cross device tracking[3] and
other nasty stuff that autoexecuted JS brings[4] both to browsers and
applications which only download webapage from specific provider to
brand the application as their own (while most of the stuff is really in
the webpage).


# References


[1]: https://www.gnu.org/distros/free-non-gnu-distros.html

[2]: https://www.gnu.org/philosophy/javascript-trap.html

[3]:
https://media.libreplanet.org/u/libreplanet/m/the-surreptitious-assault-on-privacy-security-and-freedom/

[4]:
https://www.fsfla.org/ikiwiki/blogs/lxo/pub/who-is-afraid-of-spectre-and-meltdown

-- 
* 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



signature.asc
Description: OpenPGP digital signature

Re: Way to synchronize files like Dropbox

[Adonay Felipe Nogueira]

Syncthing is good too. I also use rsync, SFTP, or torrents with no 
trackers/publishers. The last one needs an unchanged copy of the files being 
synchronized. SFTP will work friendlier if the file broeser/explorer integrates 
with a copy of GVFS which has SSH SFTP enabled.

Em 16 de abril de 2019 22:29:21 BRT, Benjamin Slade  escreveu:
>I would also recommend syncthing. I use it to synchronize files between
>several computers (including a GuixSD one) as well as mobile. 

-- 
- Página com formas de contato:
  https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do software livre (não confundir com o gratuito). Avaliador
  da liberdade de software e de sites.
- Página com lista de contribuições:
  https://libreplanet.org/wiki/User:Adfeno#Contribs
- Para uso em escritórios e trabalhos, favor enviar arquivos do padrão
  internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e
  correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de
  escritório recomendada para editar tais arquivos.
- Para outros formatos de arquivos, veja:
  https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
  https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
  permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
  (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook
  #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
  #Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
  https://www.defectivebydesign.org/

Re: Best practices for Guix environment variables on foreign distro

[Adonay Felipe Nogueira]

> When I arrive home (I am at work) I will look at the suggestions in

Have you succeeded?

> Thank you in advance.

You're welcome! :D

Re: A few questions about packages

[Adonay Felipe Nogueira]

> Need wiki, not only Manual! :)

Awesome idea! Although I have been experiencing some bad moments with
wikis nowadays, specially since I don't have stable connection to the
Internet, that said, I must note that: manual is like a wiki, with added
benefit that:

a) manual is readable offline, while wiki needs internet;

b) wiki pages might *not* correspond to the version of your local copy
   of the software;

c) both wiki and manual allow contributions, but manual doesn't dictate
   that one has to do so through a web browser, you can even do so by
   sharing files through thumb drives, emails, forum posts,
   NNTP/netnews, whatever;

d) you don't have to have an account in any website to suggest
   contributions to current manual, you can send it to any member of
   project in any means of communication and transfer that the member has
   available.

In any case, both manuals and wikis allow contributions. If there is
something that needs change, then perhaps someone needs to send a patch
to improve the manual.

I hope this helps clarify things. :D

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Best practices for Guix environment variables on foreign distro

[Adonay Felipe Nogueira]

I don't know if this is recommended, but I set all my variables inside
"${HOME}/.profile". Morever, the first thing I do in "${HOME}/.profile"
is to source my user's Guix profile --- `source
"${GUIX_PROFILE}/etc/profile"'.

The caveat is that every time GNU Guix changes my profile generation, I
have to log out and then back in --- no need to reboot --- for the
changes to take effect or for the variables to be re-instated, because
it seems that, after the changes made by GNU Guix, programs "forget"
some variables or other information.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Installation: Load non-free wifi firmware (iwlwifi)

[Adonay Felipe Nogueira]

> Is it possible to re-enable the feature?
> If not, are there other ways around the issue?

I want to make it clear that the solution seems to be for you to acquire
a copy of the GNU Linux-libre scripts' source code, modify then so that
they don't block that specific non-free part, and then have these
modified scripts run over a copy of the source files for Linux.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Installation: Load non-free wifi firmware (iwlwifi)

[Adonay Felipe Nogueira]

> As far as I understand, linux-libre turns off the ability to load
> non-free firmware.  Why is it so?

It's a bug in the Linux kernel itself, caused by how it actually looks
and loads stuff. See the reply given by Alexandre Oliva ([1]).

[1] .

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: problem with Icecat in GuixSD 0.14.0

[Adonay Felipe Nogueira]

I see... I hope someone can send a detailed report to the original
projects so as to help them fix it. ;)

2017-12-21T13:27:02+0100 Martin Castillo wrote:
> I wasn't asking for help. I just wanted to say that it may be a problem
> outside of guix.

Re: Kodi crashed

[Adonay Felipe Nogueira]

A bug was reported in bug-guix, see bug #29302 in
.

2017-11-14T18:49:36-0600 Caleb Herbert wrote:
> I installed Kodi on a foreign distro and it crashed.
>
> At 4:13 PM CDT, 11/14/17, Ludovic Cortes said  wcdkLFRcyQTeOaQrke:matrix.org/$15106976292331190WWNVd:matrix.org>:
>> CharlieBrown: did it crash while loading addons?
>
> When I installed the addon, it did not crash.  Notifications said that
> addons were being loaded, and Kodi said the addon was installed.  It
> only crashed once I went to "Open" the addon to try it.
>
> After it crashed, I tried restarting Kodi.  It immediately crashed.
>
> cal@leela:~$ kodi
> libEGL warning: DRI3: Screen seems not DRI3 capable
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site.py", line 563, in 
> main()
>   File "/usr/lib/python2.7/site.py", line 545, in main
> known_paths = addusersitepackages(known_paths)
>   File "/usr/lib/python2.7/site.py", line 272, in
> addusersitepackages
> user_site = getusersitepackages()
>   File "/usr/lib/python2.7/site.py", line 247, in
> getusersitepackages
> user_base = getuserbase() # this will also set USER_BASE
>   File "/usr/lib/python2.7/site.py", line 237, in getuserbase
> USER_BASE = get_config_var('userbase')
>   File "/usr/lib/python2.7/sysconfig.py", line 578, in
> get_config_var
> return get_config_vars().get(name)
>   File "/usr/lib/python2.7/sysconfig.py", line 524, in
> get_config_vars
> _init_posix(_CONFIG_VARS)
>   File "/usr/lib/python2.7/sysconfig.py", line 408, in
> _init_posix
> from _sysconfigdata import build_time_vars
>   File "/usr/lib/python2.7/_sysconfigdata.py", line 6, in
> 
> from _sysconfigdata_nd import *
> ImportError: No module named _sysconfigdata_nd
> /gnu/store/b8dkrbr79rj8cygw65f1gwwwig1fdwwg-profile/bin/kodi:
> line 175: 24196 Segmentation fault
> "$LIBDIR/${bin_name}/${bin_name}.bin" $SAVED_ARGS
> Crash report available
> at /home/cal/kodi_crashlog-20171114_180625.log
> 
> Contents of crash report:
>
> ## Kodi CRASH LOG ###
> 
>  SYSTEM INFO 
>  Date: Tue Nov 14 18:06:25 CST 2017
>  Kodi Options: 
>  Arch: x86_64
>  Kernel: Linux 4.4.0-93-generic #116~14.04.1+7.0trisquel1 SMP
> Mon Aug 28 17:01:09 UTC 2017
>  Release: Trisquel GNU/Linux 7.0, Belenos
> ## END SYSTEM INFO ##
> 
> ### STACK TRACE #
> gdb not installed, can't get stack trace.
> # END STACK TRACE ###
> 
> # LOG FILE ##
> 
> 18:06:23.626 T:139876837296256  NOTICE: special://profile/ is
> mapped to: special://masterprofile/
> 18:06:23.626 T:139876837296256  NOTICE:
> 
> ---
> 18:06:23.626 T:139876837296256  NOTICE: Starting Kodi
> (18.0-ALPHA1 Git:20171114-nogitfound). Platform: Linux x86
> 64-bit
> 18:06:23.626 T:139876837296256  NOTICE: Using Release Kodi x64
> build
> 18:06:23.626 T:139876837296256  NOTICE: Kodi compiled Jan  1
> 1970 by GCC 5.4.0 for Linux x86 64-bit version 4.4.47 (263215)
> 18:06:23.626 T:139876837296256  NOTICE: Running on Trisquel
> GNU/Linux Belenos (7.0), kernel: Linux x86 64-bit version
> 4.4.0-93-generic
> 18:06:23.626 T:139876837296256  NOTICE: FFmpeg version/source:
> 3.4
> 18:06:23.626 T:139876837296256  NOTICE: Host CPU: Intel(R)
> Core(TM)2 CPU P8600 @ 2.40GHz, 2 cores available
> 18:06:23.626 T:139876837296256  NOTICE: special://xbmc/ is
> mapped
> to: 
> /gnu/store/6z7533gpqwbghhgpjsaip9wd3hlaxjmr-kodi-18.0_alpha-6-f22d62d/share/kodi
> 18:06:23.626 T:139876837296256  NOTICE: special://xbmcbin/ is
> mapped
> to: 
> /gnu/store/6z7533gpqwbghhgpjsaip9wd3hlaxjmr-kodi-18.0_alpha-6-f22d62d/lib64/kodi
> 18:06:23.626 T:139876837296256  NOTICE: special://xbmcbinaddons/
> is mapped
> to: 
> /gnu/store/6z7533gpqwbghhgpjsaip9wd3hlaxjmr-kodi-18.0_alpha-6-f22d62d/lib64/kodi/addons
> 18:06:23.626 T:139876837296256  NOTICE: special://masterprofile/
> is mapped to: /home/cal/.kodi/userdata
> 18:06:23.626 T:139876837296256  NOTICE: special://envhome/ is
> mapped to: /home/cal
> 18:06:23.626 T:139876837296256  NOTICE: special://home/ is
> mapped to: /home/cal/.kodi
> 18:06:23.626 T:139876837296256  NOTICE: 

Re: problem with Icecat in GuixSD 0.14.0

[Adonay Felipe Nogueira]

Perhaps you should tell the developers of GNU IceCat (if you're using
GNU IceCat) or GNU LibreJS (if you're using GNU LibreJS in a browser
other than GNU IceCat).

I don't know if help-guix mailing list will be able to answer as
precisely as the original projects.

2017-12-14T00:06:56+0100 Martin Castillo wrote:
> I have problems with librejs on android. Even if I deactivate it, some
> sites don't work. They work in firefox, though. This might be (part of)
> the problem.
>
> Martin

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: multiple issues with Epiphany in GuixSD 0.14.0

[Adonay Felipe Nogueira]

My message applies to GNU Guix only (the packaage manager which can be
installed in any distro), not the GuixSD (system distribution).

Please, those who know how XDG specifications should be dealt with by/in
GuixSD, please reply.

With all that in mind, here follows my message:

I don't use Epiphany anymore, but I recall that you have to install
Adwaita and Hicolor icon theme from GNU Guix. I don't know if this
applies to GuixSD as well (it might have other ways of dealing with
icons).

Besides, I don't know if this applies to GuixSD, but after installing
the icon themes in GNU Guix, those who use other distros
with a specific issue in Xsession.d scripts have to algment the
XDG_DATA_DIRS variable in a special way (by copying its current value,
inserting the export declaration in the user's profile, but with the
paths suggested by GNU Guix, followed by the manually copied original
values, that is: one can't relly on conditional expansion in the case of
XDG_DATA_DIRS).


Finally, the issue with the website you mentioned will be dealt in a
separate message.

2017-12-10T16:18:42+0100 Marco van Hulten wrote:
> Hi,
>
> In the package epiphany, the icons don't display well, and connecting
> to webpages doesn't work.
>
> guix package -i epiphany
> epiphany &
>
> Screenshot attached.
>
> GNU Icecat does not have these two problems, but I do have an issue
> with the Javascript blocker.  If I disable it for tv.nrk.no,
> the website still complains that I block Javascript.
>
> —Marco
>
>

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: retroarch on Trisquel

[Adonay Felipe Nogueira]

Continuing on this issue, I tried some ROMs by doing what is described in
[1]:

Load Core -> Download Core... -> mupen64plus_libretro.so.zip
Load Core -> mupen64plus_libretro.so
Online Updater -> Core Updater -> mupen64plus_libretro.so.zip
Load Content -> /path/to/Z64/files

And I can at least see the Z64 files. I wonder if in Caleb Herbert's
case they are somewhat naed with a leading dot (".example.z64" or
".z64"), in which case RetroArch will hide these unless you do the
following:

Load Content -> Settings -> Show Hidden Files and Folders = ON

I hope this helps. ;)

[1]
.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: error running emacs installed with guix

[Adonay Felipe Nogueira]

An interesting update:

If you try to make sure that Emacs is rebult, even using the
same/current package definition, then the result works as expected.

In my case, I made a local package definition for Emacs, and changed the
phases or snippet enough to modify the source files a little, like so:

Before:

--8<---cut here---start->8---
   (with-output-to-file (string-append lisp-dir "/site-start.el")
 (lambda ()
   (display
(string-append "(when (require 'guix-emacs nil t)\n"
   "  (guix-emacs-autoload-packages))\n"
--8<---cut here---end--->8---

After:

--8<---cut here---start->8---
   (with-output-to-file (string-append lisp-dir "/adfeno-dummy.el")
 (lambda ()
   (display
(string-append "(print \"adfeno\")\n"
   (with-output-to-file (string-append lisp-dir "/site-start.el")
 (lambda ()
   (display
(string-append "(when (require 'guix-emacs nil t)\n"
   "  (guix-emacs-autoload-packages))\n"
--8<---cut here---end--->8---

Notice that I didn't change the "before" part, I just added a code that
simply creates a file called "adfeno-dummy.el".

Now, I wonder how to tell `guix package' to install what was just built?

At any case, I hope this helps. ;)

2017-11-12T11:56:43-0800 Mason Hock wrote:
> I have installed emacs with Guix. When I try to run it I get
>
> Gtk-Message: Failed to load module "canberra-gtk-module"
> Gtk-Message: Failed to load module "topmenu-gtk-module"
>
> followed by many
>
> (emacs-25-3:7212): Gtk-WARNING **: Theme parsing error:*
>
> messages, and then
>
> GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings
> will not be saved or shared with other applications.
> Fatal error 6: Aborted
> Backtrace:
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x81393ec]

[...]

> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> ...
> Aborted (core dumped)
>
>
> Does anyone know what to make of this?
>
> Thanks,
>
> Mason

Re: error running emacs installed with guix

[Adonay Felipe Nogueira]

Just for the record, the date ranges are indeed right, no need to make
the leftmost date flexible --- at least if you take into account only
Guix's repository.

There is a related item in help-guix ([1]), and there was an attempt made
by me to get a backtrace and a strace --- although I still have to find
out how to install debug symbols for GNU Emacs.

As I replied there ([2]), it might be due to a change between
2017-10-10T08:25 BRT and 2017-10-30T16:27 BRST --- either in a Guix
package definition or in the upstreams.

As Mekeor Melire ([1] and Daniel Pimentel ([2]) pointed out it, might be
an issue related to GTK+. But I also don't discard related components.

One could list commits between the given dates by doing:

--8<---cut here---start->8---
git log --after="2017-10-10T08:25 BRT" --before="2017-10-30T16:27 BRST"
--8<---cut here---end--->8---

Now we must test by making local copies of the possibly affected package
definitions, reverting the commits, and building our Emacs locally.

[1] <https://lists.gnu.org/archive/html/help-guix/2017-11/msg00079.html>.

[2] <https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00313.html>.

2017-11-13T12:44:59-0200 Adonay Felipe Nogueira wrote:
> If you don't mind, I took the liberty to also try following your
> suggestion.
>
> Just to clarify: I'm currently using Emacs 25.3 from an old `guix pull'
> --- the working derivation was created in my computer in
> 2017-10-10T08:25 BRT (Brasília Time, which is UTC -03:00) ---. The
> problematic GNU Guix revision for Emacs seems to come from a commit
> before 2017-10-30T16:27 BRST (Brasília Summer Time, currently UTC
> -02:00), but not too far behind.
>
> It's too bad that the current package definition for Emacs doesn't
> follow the "release.revision-commit" versioning suggested in the
> documentation for GNU Guix ([1]). We could have a chance to get the exact
> revision if that versioning were present.
>
> For the record, I don't know if this helps, but I noticed that my normal
> user's profile generation "manifest" file changed the output of Emacs
> version 25.3:
>
> - working Emacs 25.3:
>   /gnu/store/b1nbgnpifkisz4szmasxrwzqlgqagy8w-emacs-25.3
>
> - problematic Emacs 25.3:
>   /gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3
>
> Again, problematic Emacs 25.3 comes from a commit between
> 2017-10-10T08:25 BRT and 2017-10-30T16:27 BRST --- although I think it
> would be a good idea to add some dates before the initial part of the
> range so as to accommodate the time it takes for the Emacs derivation to
> be made.
>
> Now for the attempt to use GDB.
>
> It's one of the fewer times I used GDB. I don't exactly know how to use
> it efficiently, because I'm not a programmer, so forgive me for being
> naive.
>
> Attempting to use GDB to debug
> "/gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3/bin/emacs"
> directly (be that with or without "./core") makes GDB complain the
> executable format isn't recognized. I found that the "emacs" in question
> is a wrapper script that uses yet another wrapper script (which
> strangely seems to do/set the exact same variables as the parent
> wrapper) which finally runs the real Emacs. This "double-wrapper" is
> also present in the *working* Emacs 25.3.
>
> So I had to attempt to simulate the wrapper scripts by making a text
> file with the corresponding commands for GDB. The script is attached to
> this message. The commented parts (those starting with "#") are the
> parts I was unable to simulate --- because I know little about
> GDB. Besides in the `set env' commands I kept the Bash-specific
> ${VARIABLE:+:} syntax, but I don't know if GDB supports it.
>
> Having that GDB script ready, now I set the maximum size of core files
> to "unlimited" for the current shell (just in case):
>
> --8<---cut here---start->8---
> ulimit -c unlimited
> --8<---cut here---end--->8---
>
>
> And run:
>
> --8<---cut here---start->8---
> gdb -iex "set logging on gdb_emacs.log.txt" \
> -iex "set pagination off" \
> -iex "set args -Qnw" \
> -x "gdb_cmds.txt" \
> -ex "run" \
> -ex "generate-core-file emacs_core_dump" \
> -ex "continue" \
> -ex "target core emacs_core_dump" \
> -ex "backtrace" \
> -ex "quit" \
> 
> "/gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3/bin/.emacs-25.3-real"
> --8&

Re: Upgrading an old GuixSD installation.

[Adonay Felipe Nogueira]

Also, I don't know if this helps, but some time ago I found out that
root user's profile doesn't need to have guile-git installed. While the
normal users have to.

nee  writes:

> Hello, I have an old guixsd installation that I haven't upgraded for a
> few months.
> When I run guix pull it tells me to install guile-git, but that fails,
> both from normal guix and ./pre-inst-env
>
> ./pre-inst-env guix package -i guile-git
> guix package: error: build failed: getting attributes of path
> `/gnu/store/aiz8db2gni401wc9fgidmcggxyb1czis-guile-bootstrap-2.0': No
> such file or directory
>
> The same thing happens when I run guix package -u
>
> Does anyone have an idea what's happening here?

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: error running emacs installed with guix

[Adonay Felipe Nogueira]

Indeed, I experienced the same issues when I followed his instructions
literally.

This happens because, apparently, the system distribution he's currently
using has `ulimit -c unlimited' already run for his current shell and
"/proc/sys/kernel/core_pattern" with the phrase/word "core" inside.

You can either do something similar to what I described in my reply to
his suggestion or do as I just told in the previous paragraph, like so:

--8<---cut here---start->8---
sudo -i
echo "core" > "/proc/sys/kernel/core_pattern"
exit
ulimit -c unlimited
emacs
# ... and now it crashes and "core" is dumped at your current working
# directory --- your user's home by default.
# Now I suggest you to exit this shell, this will set
# `ulimit -c' back to 0, disabling "core dumps".
--8<---cut here---end--->8---

Just to note that, in the reply I gave to his message, I forgot to
mention that I had to copy the contents of the first "wrapper" script to
a place where I can edit it, so I could make something similar to the
"gdb_cmds.txt" file.

The first "wrapper" script can be found by doing:

--8<---cut here---start->8---
which emacs
--8<---cut here---end--->8---

Mason Hock  writes:

> Thanks for your response.
>
> I get
>
>> gdb $(which emacs) ./core
> "/home/mason/.guix-profile/bin/emacs": not in executable format: File
> format not recognized
> /home/mason/./core: No such file or directory.
>
>> (gdb) bt
> No stack.
>
> Mason

Re: error running emacs installed with guix

[Adonay Felipe Nogueira]

Indeed, I also experienced this issue...

Even starting Emacs with `-Q' option doesn't help.

Mason Hock  writes:

> I have installed emacs with Guix. When I try to run it I get
>
> Gtk-Message: Failed to load module "canberra-gtk-module"
> Gtk-Message: Failed to load module "topmenu-gtk-module"
>
> followed by many
>
> (emacs-25-3:7212): Gtk-WARNING **: Theme parsing error:*
>
> messages, and then
>
> GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings
> will not be saved or shared with other applications.
> Fatal error 6: Aborted
> Backtrace:
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x81393ec]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8121e63]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x813947c]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e75]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176cce]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176cce]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x817705f]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176c9e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176cce]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x817705f]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176cce]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x817705f]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x81770fd]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x817841e]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e7f]
> /gnu/store/5jfh7wlrkc0lhrfdaijsjgz8w9bwqxvf-emacs-25.3/bin/emacs-
> 25.3[0x8176e5d]
> ...
> Aborted (core dumped)
>
>
> Does anyone know what to make of this?
>
> Thanks,
>
> Mason

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Application Setup on Trisquel

[Adonay Felipe Nogueira]

An addendum: as was pointed out the default values for $XDG_DATA_HOME
and $XDG_DATA_DIRS are only assumed if these are unset.

Besides, in the short-term solution that suggests appending values to
$XDG_DATA_DIRS to the environment/shell's profile, I emphasize the need
to do it manually.

Solutions such as:

--8<---cut here---start->8---
[Additional value.]:${XDG_DATA_DIRS:+:}${XDG_DATA_DIRS}
--8<---cut here---end--->8---

Or even:

--8<---cut here---start->8---
if [ $XDG_DATA_DIRS ]
then
export XDG_DATA_DIRS="[Additional value.]:$XDG_DATA_DIRS"
else
export XDG_DATA_DIRS="[Additional value.]"
fi
--8<---cut here---end--->8---

... will both lead only to "[Additional value.]" inside $XDG_DATA_DIRS
--- because the Xsession.d scripts that set the foreign distro's value
for $XDG_DATA_DIRS are run *after* the environment/shell's profile is
read and as far as I can tell, before the user logs in the desktop
environemnt.

Adonay Felipe Nogueira <adf...@hyperbola.info> writes:

> I might have some information that might help understand how
> ${XDG_DATA_DIRS} interferes in case of GNU Guix in foreign distros.
>
> Reading the XDG Base Directory Specification ([1]):
>
> --8<---cut here---start->8---
> [...]
>
> * Basics
>
> The XDG Base Directory Specification is based on the following concepts:
>
> - There is a single base directory relative to which user-specific data
>   files should be written. This directory is defined by the environment
>   variable $XDG_DATA_HOME
>
>   [...]
>
> - There is a set of preference ordered base directories relative to
>   which data files should be searched. This set of directories is
>   defined by the environment variable $XDG_DATA_DIRS
>
>   [...]
>
> * Environment variables
>
> $XDG_DATA_HOME defines the base directory relative to which user
> specific data files should be stored. If $XDG_DATA_HOME is either not
> set or empty, a default equal to $HOME/.local/share should be used
>
> [...]
>
> $XDG_DATA_DIRS defines the preference-ordered set of base directories to
> search for data files in addition to the $XDG_DATA_HOME base
> directory. The directories in $XDG_DATA_DIRS should be seperated with a
> colon ':'.
>
> If $XDG_DATA_DIRS is either not set or empty, a value equal to
> /usr/local/share/:/usr/share/ should be used.
>
> [...]
>
> The order of base directories denotes their importance; the first
> directory listed is the most important. When the same information is
> defined in multiple places the information defined relative to the more
> important base directory takes precedent. The base directory defined by
> $XDG_DATA_HOME is considered more important than any of the base
> directories defined by $XDG_DATA_DIRS. The base directory defined by
> $XDG_CONFIG_HOME is considered more important than any of the base
> directories defined by $XDG_CONFIG_DIRS
>
> [...]
> --8<---cut here---end--->8---
>
>
> This, as far as I can understand means that $XDG_DATA_HOME (or assumed
> default value) is the user defined "data" directory. While
> $XDG_DATA_DIRS (or assumed default value) is a preference list that
> comes *after* $XDG_DATA_HOME. Inside the list, entries are sorted from
> "most preferred" to "last resort".
>
> The combination forms a preference queue, like so:
>
> XDG_DATA_HOME XDG_DATA_DIRS
>
> Where, if there are various values for the same information, the first
> appearance takes the lead, and the remaining conflicting values are
> discarded. The following quote taken from [1] contributes to this:
>
> --8<---cut here---start->8---
> [...]
>
> * Referencing this specification
>
> Other specifications may reference this specification by specifying the
> location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies
> that:
>
> - Such file should be installed to $datadir/subdir/filename with
>   $datadir defaulting to /usr/share.
>
> - A user specific version of the data file may be created in
>   $XDG_DATA_HOME/subdir/filename, taking into account the default
>   value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set.
>
> - Lookups of the data file should search for ./subdir/filename
>   relative to all base directories specified by $XDG_DATA_HOME and
>   $XDG_DATA_DIRS . If an environment variable is either not set or
>   empty, its default value as defined by this specification should be
>   used instead.
>
> [

Re: Application Setup on Trisquel

[Adonay Felipe Nogueira]

I might have some information that might help understand how
${XDG_DATA_DIRS} interferes in case of GNU Guix in foreign distros.

Reading the XDG Base Directory Specification ([1]):

--8<---cut here---start->8---
[...]

* Basics

The XDG Base Directory Specification is based on the following concepts:

- There is a single base directory relative to which user-specific data
  files should be written. This directory is defined by the environment
  variable $XDG_DATA_HOME

  [...]

- There is a set of preference ordered base directories relative to
  which data files should be searched. This set of directories is
  defined by the environment variable $XDG_DATA_DIRS

  [...]

* Environment variables

$XDG_DATA_HOME defines the base directory relative to which user
specific data files should be stored. If $XDG_DATA_HOME is either not
set or empty, a default equal to $HOME/.local/share should be used

[...]

$XDG_DATA_DIRS defines the preference-ordered set of base directories to
search for data files in addition to the $XDG_DATA_HOME base
directory. The directories in $XDG_DATA_DIRS should be seperated with a
colon ':'.

If $XDG_DATA_DIRS is either not set or empty, a value equal to
/usr/local/share/:/usr/share/ should be used.

[...]

The order of base directories denotes their importance; the first
directory listed is the most important. When the same information is
defined in multiple places the information defined relative to the more
important base directory takes precedent. The base directory defined by
$XDG_DATA_HOME is considered more important than any of the base
directories defined by $XDG_DATA_DIRS. The base directory defined by
$XDG_CONFIG_HOME is considered more important than any of the base
directories defined by $XDG_CONFIG_DIRS

[...]
--8<---cut here---end--->8---

This, as far as I can understand means that $XDG_DATA_HOME (or assumed
default value) is the user defined "data" directory. While
$XDG_DATA_DIRS (or assumed default value) is a preference list that
comes *after* $XDG_DATA_HOME. Inside the list, entries are sorted from
"most preferred" to "last resort".

The combination forms a preference queue, like so:

XDG_DATA_HOME XDG_DATA_DIRS

Where, if there are various values for the same information, the first
appearance takes the lead, and the remaining conflicting values are
discarded. The following quote taken from [1] contributes to this:

--8<---cut here---start->8---
[...]

* Referencing this specification

Other specifications may reference this specification by specifying the
location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies
that:

- Such file should be installed to $datadir/subdir/filename with
  $datadir defaulting to /usr/share.

- A user specific version of the data file may be created in
  $XDG_DATA_HOME/subdir/filename, taking into account the default
  value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set.

- Lookups of the data file should search for ./subdir/filename
  relative to all base directories specified by $XDG_DATA_HOME and
  $XDG_DATA_DIRS . If an environment variable is either not set or
  empty, its default value as defined by this specification should be
  used instead.

[...]

A specification that refers to $XDG_DATA_DIRS or $XDG_CONFIG_DIRS should
define what the behaviour must be when a file is located under multiple
base directories. It could, for example, define that only the file under
the most important base directory should be used or, as another example,
it could define rules for merging the information from the different
files.

[...]
--8<---cut here---end--->8---

Note that from the last paragraph of the quote, one can see that each
project is responsible for dealing with cases where a file *with the
same relative path* is found in various entries in $XDG_DATA_DIRS (note
that we are not talking about $XDG_DATA_HOME here).

For example, suppose I have $XDG_DATA_DIRS *expanded* as follows:

/home/adfeno/.guix-profile/share:/usr/share

We see two entries here, and unfortunatelly, suppose I have two "gnome"
icon themes, one in each entry:

/home/adfeno/.guix-profile/share/icons/gnome
/usr/share/icons/gnome

Both have an "index.theme", so according to the Icon Theme Specification
([2]), the first (in "/home/adfeno/.guix-profile/share") should be used,
as according to [2]:

--8<---cut here---start->8---
[...]

In at least one of the theme directories there must be a file called
index.theme that describes the theme. The first index.theme found while
searching the base directories in order is used. This file describes the
general attributes of the theme. 

[...]
--8<---cut here---end--->8---

Also according to [2], a fallback theme called "hicolor" is assumed in
almost all cases and application authors should install at 

Re: Application Setup on Trisquel

[Adonay Felipe Nogueira]

For the case of themes not matching and buttoms not showing up, perhaps
one can try the suggestion I made to that same thread ([1]).

[1] 
.

Caleb Herbert  writes:

> I have a better way.  This did not work for me on Trisquel.
>
> My experience: Apps appeared in the main menu, but GNOME was not aware
> of them.  Icons were missing, Emacs would never show up in "Open With",
> and I couldn't launch Mumble from Run Application (Alt+F2).
>
> Solution:
> https://trisquel.info/en/forum/guix-trisquel#comment-122789
> (Thanks, ADFENO!)
>
> GNOME sees apps and icons now!
>
> Remaining hurdles:
>   * Buttons don't show up, themes don't match:
> https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png
>   * Fcitx Mozc input method for Japanese does not work in Guix apps

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Should I upgrade root user's guix too?

[Adonay Felipe Nogueira]

I think root profile doesn't have 0 (zero) packages installed. It has
guix. ;)

As a personal preference, I always do:

# guix pull && guix package -u

... as root, and then:

$ guix pull && guix package -u

... as normal user

Chris Marusich  writes:

>
> I see.  I incorrectly assumed you were using GuixSD.  It sounds like
> you've followed the steps described in the manual under "(guix) Binary
> Installation".  I see that you're running Guix on a foreign distro.
>
>
> The reason you should still run "guix pull" as root in this case is to
> ensure that when your system boots and starts guix-daemon, it starts an
> up-to-date version of the daemon, including any security patches and the
> like for any dependencies guix-daemon uses.  If you've followed the
> manual correctly, then I believe your system should be starting the
> guix-daemon executable that is installed in root's profile.  Because the
> executable lives in root's profile, if you don't run "guix pull" as root
> and then run "guix package -u ." (or equivalent) as root to update the
> guix-daemon that is installed there, you will never wind up using a more
> up-to-date version of guix-daemon.
>
> The package definitions are independent of which version of the
> guix-daemon is being used.  When a non-privileged user alice runs a
> command like "guix package -i hello" to install GNU Hello, she is using
> the package definitions that were installed by the latest "guix pull"
> that was run as the alice user (these package definitions live in the
> store, in a directory pointed to by the ~alice/.config/guix/latest
> symlink).  When alice invokes the guix command to install the hello
> package, the guix command essentially translates the package definition
> into a derivation, and then asks the guix-daemon (via remote procedure
> calls) to build that derivation.
>
> The translation from package definition to derivation happens in alice's
> "guix" process, which is independent of the "guix-daemon" process.  Her
> "guix" process communicates only via remote procedure calls with the
> "guix-daemon" process.  The guix-daemon has no knowledge of the
> "package" abstraction, and it doesn't need to know about packages.  For
> this reason, the guix-daemon doesn't necessarily need to be updated in
> order to build more up-to-date packages.  The guix-daemon just knows how
> to do basic things related to the store like add files, build
> derivations, perform garbage collection, etc.  It is the package
> definitions that are deployed to alice's home directory (via her latest
> invocation of "guix pull") that will determine which versions of
> packages get installed when alice runs "guix package -i", regardless of
> which version of the guix-daemon happens to be running.  The same is
> true for any other user (including root, actually).
>
>
> No, the order does not matter.  If alice runs those commands before root
> does, then alice will simply be able to install up-to-date packages
> before root can.  That is normal and expected for the reasons described
> above.  With Guix, each user independently manages their own
> installation of Guix.  If two users run "guix pull" at different times,
> they might very well wind up using different package definitions.  The
> ability for two different un-privileged users to independently install
> different versions of software at the same time without conflict is a
> feature of Guix (and Nix) that other package managers usually don't
> provide.
>
>
> Yes, you should restart the guix-daemon process.  One way to do that is
> to reboot.  However, for the reasons described above, alice will be able
> to install up-to-date software after running "guix pull" even if the
> guix-daemon process is old or hasn't yet been restarted.  And the only
> reason you ought to run "guix pull && guix package -u ." as root is to
> ensure that the guix-daemon - which happens to be installed in root's
> profile - is up-to-date.  If root had zero packages installed in root's
> profile, then there would be no point in running "guix pull && guix
> package -u ." as root at all.
>
> I hope that helps clarify things!  I also found this topic a bit
> confusing at first.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: various packaging issues

[Adonay Felipe Nogueira]

Yes, we do know who he is! :)

Still, that issue is somewhat not clear to me, neither is the submission
which started it all back in 2002.


-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
- Contato: [[https://libreplanet.org/wiki/User:Adfeno#vCard]]
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: developing software with guix environment

[Adonay Felipe Nogueira]

Thank you very much for the information. :)

Re: various packaging issues

[Adonay Felipe Nogueira]

Regarding the meaning of the license list: I see what you mean
now. Thanks. :)

About own opinions and blocked contributions: Since you commented on a
contribution to a GNU project, I wonder if the issue was taken to the
FSF's Licensing and Compliance Lab and also to copyright-related
lawyers? Remember that the second one is usually the best option if they
are indeed lawyers known not to be biased towards non-free software
(this also includes some "open source" practices).

Optionally, if you really want to, we could discuss the blocked
contribution either privately or with the libreplanet-discuss mailing
list. Currently, the description you gave me seems to vague do draw any
consideration. Keep in mind that it's often a good idea to re-read what
was the resulting consideration of that blocking and perhaps even
discuss the points in more detail and with more people.

Re: various packaging issues

[Adonay Felipe Nogueira]

About the license field notation, I don't know if this is indeed what
the GNU Guix project interpretes about it, but for me I always see a
list of licenses as being connected with a series of "or"'s.

One thing to note however, and I often find it simpler to do, is that:
at least in *my* opinion, the license field is used to list the license
in which the resulting package is under, not to list each and every
license found inside the package nor to list each and every license of
the package's dependencies/recommendations/suggestions.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: Help neeeded to package guile-wiredtiger and microkanren

[Adonay Felipe Nogueira]

Oh, I see.

Thanks for the information, I first thought this was overlooked. :)

Re: Help neeeded to package guile-wiredtiger and microkanren

[Adonay Felipe Nogueira]

Hi Amirouche! :)

What is the status of this?

- Was there any previous attempt?

  - What are the findings so far?

- Does it need a system service to be running?

- Since your last message, is there someone working on this now?

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: GuixSD in virtualbox

[Adonay Felipe Nogueira]

Which break down is related to GuixSD and Python?

Please tell us so that we can help out.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: GuixSD in virtualbox

[Adonay Felipe Nogueira]

You might want to make sure that the version of VirtualBox that you have
is fully free/libre though.

The current versions of it, as far as I know, aren't, so I think Guix
should avoid recommending it.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: GuixSD in a VM is so nice

[Adonay Felipe Nogueira]

The documentation section (the reference I gave earliear), not the wiki
page (the reference you just gave), tells the solution for the problem
described in the wiki page. The wiki page also mentions the solution but
it's implicit. That wiki page tells you that you have to provide options
that identify the host's network in order for the QEMU system to make
use of it.

Re: GuixSD in a VM is so nice

[Adonay Felipe Nogueira]

I don't know if this is right, but at least according to
[[https://qemu.weilnetz.de/doc/qemu-doc.html#Network-options]], I see no
way to tell `-net default` to QEMU.

Re: GuixSD in a VM is so nice - once you actually have control over your mouse, that is.

[Adonay Felipe Nogueira]

I don't know what is the issue exactly, but from the QEMU documentation
I can see that, in order for it to grab or release mouse and keyboard,
one has to press Ctrl + Alt.

Lastly, strangely enough, I as a non-tech user understand QEMU as a
VM. But of course, no non-tech user's opinion replaces thechnical
ones. :)

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: pgmodeler

[Adonay Felipe Nogueira]

NOTE I'm not a developer, but I just happen to search for the issue some
more and happened to find a similar issue.

In the issue, the problem is "libpq", not "libpq" --- but I do know that
it was probably a typo ---, furthermore, there is a similar issue that
should provide us with some hints:
[[https://github.com/pgmodeler/pgmodeler/issues/43]].

However, that issue doesn't seem to indicate if the suggested .pc file
was ever added, so perhaps we must ask upstream to do so now.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: A short story about containers

[Adonay Felipe Nogueira]

Indeed... That story is a good one. :)

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: libxsl reprise

[Adonay Felipe Nogueira]

You're welcome! :)

I'm glad it worked well.

Re: libxsl reprise

[Adonay Felipe Nogueira]

Try:

(chdir "libxsl")

The reason for this suggestion is that "source" is already
traversed/changed-to after "unpack" phase. Because Guix already tries to
change to first directory it finds in the source.

If it still doesn't work, revert the one I just recommended, and add:

... before the "configure" phase:

(display (string-append "Current working directory before configure phase is: "
(getcwd) "\n"))

This line will print which directory is being worked on before the error.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  Ring, ou Tox. Quer outras formas de contato? Adicione o vCard que
  está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.
- "People said I should accept the world. Bullshit! I don't accept the
  world."
 --- Richard Stallman

Re: artanis ?

[Adonay Felipe Nogueira]

I also got the same problem, but I don't know how to solve it yet.

The following issues seem to be related:

- [[http://lists.gnu.org/archive/html/artanis/2016-05/msg1.html]]
- [[http://lists.gnu.org/archive/html/help-guix/2016-02/msg00025.html]]

However, I don't exactly know how to fix this, both because I'm not a
Scheme programmer, and also because I'm not a programmer at all.

There is one ugly workaround though:

Make sure that the shell variables $GUILE_LOAD_PATH and
$GUILE_LOAD_COMPILED_PATH have the Guile paths from your current Guix
profile included, it should be something like this:

GUILE_LOAD_PATH="$GUIX_PROFILE/share/guile/site:${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"

Try to see if "$GUIX_PROFILE/share/guile/site" exists and has Artanis
inside, if not try the following ones (do not point to Artanis
directly):

- "$GUIX_PROFILE/share/guile/2.0/site"
- "$GUIX_PROFILE/share/guile/site/2.0"

However, as I said earliear, this doesn't seem to be a fix, it's more
like a workaround, since (as far as the previous references point to),
it's the Artanis project's code that has to be fixed.