Re: How to delete per-user profiles

2023-08-30 Thread Jorge P . de Morais Neto
Thanks 宋文武 and Roman!  I have then deleted
`/var/guix/profiles/per-user/jorge-morais' and then invoked `sudo -i
guix gc -d'.  It went as expected.  If any error appears later, I will
inform this list.

Regards!

-- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 



[PATCH] Fix for --with-branch=emacs-next=master

2022-09-25 Thread Jorge P. de Morais Neto
>From d70da533ddd0152f7d358854b184855932d6390c Mon Sep 17 00:00:00 2001
From: "Jorge P. de Morais Neto" 
Date: Sat, 24 Sep 2022 19:58:21 -0300
Subject: [PATCH] Undo 97b928ce09d6034ebcb541fb548e5d4862302add for Guix

The aforementioned commit breaks Guix's emacs recipe.  The recipe
could trivially be fixed by Guix developers, but for a user this patch
is more convenient.
---
 lisp/emacs-lisp/comp.el | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index abab9107ae..eee25f2557 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -178,8 +178,7 @@ native-comp-compiler-options
   :type '(repeat string)
   :version "28.1")
 
-(defcustom native-comp-driver-options (when (eq system-type 'darwin)
-'("-Wl,-w"))
+(defcustom native-comp-driver-options nil
   "Options passed verbatim to the native compiler's back-end driver.
 Note that not all options are meaningful; typically only the options
 affecting the assembler and linker are likely to be useful.
-- 
2.37.3


Hi.  I have versionitis---obsession with running the current version of
my favorite packages.  So I install emacs-next with the following
package transformation option:
--with-branch=emacs-next=master

I have a script that excludes emacs-next from regular `guix upgrade',
because upgrading from Git master every day would be too much.  I
upgrade emacs-next every fortnight.

Most often this builds and works correctly, but, yesterday,
Guix-installed emacs-next stopped working with native compilation.  I
traced the problem to Emacs commit
97b928ce09d6034ebcb541fb548e5d4862302add
which changes the default value of option `native-comp-driver-options'.

That change is not beneficial to GNU/Linux and breaks Guix's emacs-next
recipe.  The recipe could be trivially fixed by Guix developers, but for
Guix users I find it more convenient to install emacs-next with the
attached patch.  I will later report the problem to guix-devel so they
fix the recipe.

Meanwhile, those who want a fresh emacs-next can save the attached patch
in their computer and install emacs-next like this:

guix install --with-branch=emacs-next=master --with-patch=emacs-next=PATCH 
emacs-next

Where PATCH is the path to the patch in your computer.

Hope this helps!

Regards,
  Jorge
-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.


Re: Why Emacs is echoing message for each installed Emacs package while startup

2022-07-23 Thread Jorge P . de Morais Neto
Hi!  I reply below:

Em [2022-05-22 dom 17:26:55+0600], Akib Azmain Turja escreveu:
> Thanks a lot.  Just a question, where should I send the patch?
> guix-devel?

Did you send the patch?  I have searched debbugs and have not found any
such submission.  I care because:

1. It significantly pollutes the *Messages* buffer, which can mask
   important warnings such as when Emacs loads a .elc byte compiled file
   that is older than its source code.
2. For people who byte-compile Elisp files from a Makefile, these
   messages causes significant pollution, masking byte-compilation warnings.
3. For people who use the nativecomp feature (from a guix channel),
   the native compilation of *each* Emacs package yields loading messages
   for *every* Guix-installed Emacs package, resulting in O(n^2) growth.

Regards

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"



Re: Does Guix provide security support for Python2? For how long?

2021-01-15 Thread Jorge P . de Morais Neto
Hi.

Em [2021-01-15 sex 19:17:41+0100], dario escreveu:

> I don't know the answer to your question and you are probably aware of
> that option, but I just wanted to mention that you could consider
> switching to mbsync, which (I think) also has better performance than
> offlineimap.  It's a bit annoying to migrate the configuration, but it
> does not require that much time (I made that switch some time ago).

Continuing in OfflineIMAP would have the advantage of not having to
redownload 1.6GB of email, but I thank you for the recommendation.  In
fact, a few minutes ago I have asked for mail fetcher recommendations on
the notmuch mailing list.  I want to hear many recommendations and make
a final decision.  I will take into account yours and any others I
receive in this thread.

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: Does Guix provide security support for Python2? For how long?

2021-01-15 Thread Jorge P . de Morais Neto
Hi.

Em [2021-01-15 sex 18:07:40+0100], zimoun escreveu:

> As far as I know, Guix provides the security support that upstream
> releases.

I too suppose so in general.  But I would like a more authoritative
answer for the specific case of Python2.  And, in fact, this should be
publicly documented---in the manual or in the website, as well as the
description of the python2 package and maybe also in the description of
all python2-.* packages.

> Using the Guix time-machine, the code that works now should work
> exactly the same in the future, even if Python 2 is removed in the
> future Guix releases.  Does it make sense?

The problem is that OfflineIMAP is Internet software, and therefore, I
believe, it is important to have security support for it (including its
dependencies).

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Does Guix provide security support for Python2? For how long?

2021-01-15 Thread Jorge P. de Morais Neto
Hi.  I use Guix on a foreign distro---Debian buster (current stable).  I
want to upgrade Debian to bullseye (current testing), but bullseye does
not provide security support for Python 2.  I still use Python 2 for
OfflineIMAP.  There is a Python 3 port of OfflineIMAP, but it was done
very recently and I fear it is probably be buggy.  So I would like to
install Guix Python 2 atop Debian bullseye just for OfflineIMAP.  Would
that work fine?  Does Guix, unlike Debian bullseye, still provide
security support for Python 2?  For how long?

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: Can I easily install GNU Emacs 27.1.50 via Guix?

2020-12-18 Thread Jorge P . de Morais Neto
Hi Carlo.

Em [2020-12-18 sex 20:36:11+1100], Carlo Zancanaro escreveu:

> This is true if they are in the same address space, but in this
> case evince runs as a separate process. There's no reason it has
> to load the same libraries as emacs, or have the same GTK_PATH
> variable. You should be able to show this by replacing evince with
> a script that unsets GTK_PATH before invoking the system evince. I
> have attached such a wrapper, if you want to add it to your path
> to check on a foreign distribution (it makes the print dialog in
> evince work for me, even when I run evince from within Guix's
> emacs).

I confirm that, with your wrapper, Debian's Evince (launched from Guix's
Emacs) can find the printers and indeed it can print.  It is a pity
though that this workaround needs writing manual wrappers for every
affected program.

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: Can I easily install GNU Emacs 27.1.50 via Guix?

2020-12-17 Thread Jorge P . de Morais Neto
Em [2020-12-17 qui 19:54:18-0300], Jorge P. de Morais Neto escreveu:

> Show I report these problems as two bugs?

I forgot to mention that I have already (quickly) searched the Guix bugs
database and found no preexisting bug report related to either of these
two problems.

Regards

-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: <https://www.fsf.org/free-software-supporter>
- If an email of mine arrives at your spam box, please notify me.



Re: Can I easily install GNU Emacs 27.1.50 via Guix?

2020-12-17 Thread Jorge P . de Morais Neto
Hi Pierre and Simon!  Thank you both for your tips and encouragement.  I
ended up studying Guix and then I wrote an `emacs-maint' package that
builds from the emacs-27 branch.  I currently use commit
2dbc95063b5ee3d48aceff05f89e63a134df86ed and I intend to refresh it
monthly.  I have however hit two problems:

* GTK+ search path

When I launch Debian's Evince from Guix's emacs-maint, Evince cannot
find my local printer.  Look at the messages when I open Evince in an
Emacs shell and open Evince's print dialog:

--8<---cut here---start->8---
$ evince&
[1] 22463
jorge@jorge--inspiron-5570:~/unison/STJ/repos/usuários_arriscados_AD$ 
(evince:22463): Gtk-WARNING **: 19:41:17.738: Theme parsing error: 
gtk-keys.css:1:0: Failed to import: Error opening file 
/gnu/store/gazmlv80882hgkdnfdzl50b4m8xxj1bz-gtk+-3.24.23/share/themes/Emacs/gtk-3.0/gtk-keys.css:
 Permission denied
! SyncTeX Error : No file?

(evince:22463): Gtk-WARNING **: 19:41:41.121: 
/gnu/store/gazmlv80882hgkdnfdzl50b4m8xxj1bz-gtk+-3.24.23/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-file.so:
 cannot open shared object file: Permission denied

(evince:22463): Gtk-WARNING **: 19:41:41.122: 
/gnu/store/gazmlv80882hgkdnfdzl50b4m8xxj1bz-gtk+-3.24.23/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-file.so:
 cannot open shared object file: Permission denied

(evince:22463): Gtk-WARNING **: 19:41:41.122: 
/gnu/store/gazmlv80882hgkdnfdzl50b4m8xxj1bz-gtk+-3.24.23/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so:
 cannot open shared object file: Permission denied

(evince:22463): Gtk-WARNING **: 19:41:41.122: 
/gnu/store/gazmlv80882hgkdnfdzl50b4m8xxj1bz-gtk+-3.24.23/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so:
 cannot open shared object file: Permission denied
--8<---cut here---end--->8---

I suppose this is caused by the following environment variable that
exist in Emacs environment:

GTK_PATH=/gnu/store/gazmlv80882hgkdnfdzl50b4m8xxj1bz-gtk+-3.24.23/lib/gtk-3.0

This error does not occur when I launch Debian's evince from a manually
compiled Emacs 27.1.50.

* Time zone data

In Guix emacs-maint (as well as in Guix emacs), Emacs wrongly evaluates
the following function call:
(current-time-zone nil "America/Sao_Paulo")
It returns `(0 "America")'.  In a manually compiled 27.1.50 I get the
correct result.

I have tried installing the tzdata Guix package and restarting my
notebook but the error persisted.

Show I report these problems as two bugs?

And here is the package definition:

--8<---cut here---start->8---
(define-module (jorge-packages emacs-maint)
  #:use-module (guix packages)
  #:use-module (guix git-download)
  #:use-module (gnu packages emacs)
  #:use-module (guix utils))

(define-public emacs-maint
  (let ((commit "2dbc95063b5ee3d48aceff05f89e63a134df86ed")
(revision "1"))
(package/inherit emacs-next
  (name "emacs-maint")
  (version (git-version "27.1.50" revision commit))
  (source
   (origin
 (inherit (package-source emacs-next))
 (uri (git-reference
   (url "https://git.savannah.gnu.org/git/emacs.git/;)
   ;; (url "https://github.com/emacs-mirror/emacs;)
   (commit commit)))
 (file-name (git-file-name name version))
 (sha256
  (base32 "1qcak1abd20wikpvmp7xns59xgxh1rnz70p4crpv8vf2dn2zmfk1"
  (native-inputs `(,@(package-native-inputs emacs-next)))
  (native-search-paths
   (list (search-path-specification
  (variable "EMACSLOADPATH")
  ;; The versioned entry is for the Emacs' builtin libraries.
  (files (list "share/emacs/site-lisp"
   (string-append "share/emacs/"
  (version-major+minor+point version)
  "/lisp"
 (search-path-specification
  (variable "INFOPATH")
  (files '("share/info"
--8<---cut here---end--->8---

Regards
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- 
- 



Can I easily install GNU Emacs 27.1.50 via Guix?

2020-12-09 Thread Jorge P. de Morais Neto
Hi.  For GNU Emacs I manually compile the latest code from the emacs-27
branch (and install it with GNU Stow).  That's because I want the latest
features and fixes, but I fear that the master branch could be
unreliable when used together with certain external packages such as
Notmuch.  When there's a pretest version of emacs-28, I intend to switch
to it---before it is stable---but first I'll ask on the Notmuch mailing
list.

The problem with locally compiling Emacs is that it doesn't see
Guix-installed Elisp packages.  I currently get packages from ELPA (GNU,
Org, Melpa and Melpa-Stable) but the last two have ethical problems, so
I would prefer to get my packages via Guix.  I haven't yet studied Guix
packaging, however, so I need an easy solution.  So is it possible and
easy to get Emacs 27.1.50 via Guix?

Regards

-- 
- 
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: Guix's enchant misreports numerals on Debian---both buster and bullseye

2020-08-22 Thread Jorge P . de Morais Neto
> Maybe you could use hunspell directly as your enchant?  Not sure if
> that works, I'm not an emacs user.

Emacs does support several other spell checkers, but I want to use
enchant in order to share the user dictionary with other applications
that use enchant.

> With these, on Guix System, I was able to reproduce the behavior of
> debian's enchant.  Numerals are not marked as incorrect anymore.

Yes, same here.  Thank you!

> Hunspell itself doesn't flag "doesn" as incorrect, whereas enchant
> does, despite using the same dictionary.  If this is also the case on
> Debian, we might have found a bug in enchant.

The command-line tool enchant-2 misreports "doesn't", but Gedit, which
very probably uses Enchant, correctly accepts "doesn't and four other
contractions I tested.  It seems Gedit calls the enchant library in a
different way than Enchant's own command-line tool.

The reason to believe that Gedit uses Enchant are:
1. Wikipedia says so
2. Gedit's spell checker correctly accepts every word I have in the
   Enchant user dictionary.

Best regards

-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- 
- 



Re: Guix's enchant misreports numerals on Debian---both buster and bullseye

2020-08-20 Thread Jorge P . de Morais Neto
Em [2020-08-20 qui 15:35:00-0300], Jorge P. de Morais Neto escreveu:

> So enchant 2.2.8 (either from APT or from Guix) does not understand
> "doesn't"; and, what's worse, enchant-2.2.8 from Guix reports every
> numeral as a misspelling.

I now reread my experiment and realized enchant from Guix does
understand "doesn't".  So enchant 2.2.8 from Guix gets "doesn't"
correctly, but not numerals, and enchant 2.2.8 from APT gets numerals
correctly, but not "doesn't".  Could enchant get both numerals and
"doesn't" correctly?  That would be ideal.  Failing that, APT's enchant
situation is much preferable than Guix's enchant.

Regards

-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Guix's enchant misreports numerals on Debian---both buster and bullseye

2020-08-20 Thread Jorge P. de Morais Neto
Hello.  I reported Emacs bug#42248 and I and the Emacs developers
realized at least part of the problem is with Guix version of Enchant.

On an updated Debian bullseye, enchant 2.2.8 from Guix misreports
numerals.  The same enchant upstream version, when installed from APT,
does not have this problem.  Guix enchant 2.2.8 on Debian buster also
misreports numerals.

See (on Debian bullseye):

$ enchant-2 -v
@(#) International Ispell Version 3.1.20 (but really Enchant 2.2.8)
$ which enchant-2
/usr/bin/enchant-2
$ enchant-2 -l -d en_US /tmp/enchant-test.txt
Doesn
Amarelou

$ guix install enchant; hash enchant-2
[...]
$ enchant-2 -v
@(#) International Ispell Version 3.1.20 (but really Enchant 2.2.8)
$ which enchant-2
/home/jorge/.guix-profile/bin/enchant-2
$ enchant-2 -l -d en_US /tmp/enchant-test.txt
2015
Casa
42
Amarelou
2018

The file /tmp/enchant-test.txt:
--8<---cut here---start->8---
Doesn't 2015
Casa 42
Amarelou 2018
--8<---cut here---end--->8---

So enchant 2.2.8 (either from APT or from Guix) does not understand
"doesn't"; and, what's worse, enchant-2.2.8 from Guix reports every
numeral as a misspelling.

Regards

-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: 
- If an email of mine arrives at your spam box, please notify me.



Enchant from Guix misreports numerals on both Debian buster and bullseye

2020-08-20 Thread Jorge P. de Morais Neto
Hello.  I reported Emacs bug#42248 and I and the Emacs developers
realized at least part of the problem is with Guix version of Enchant.

On an updated Debian bullseye, enchant 2.2.8 from Guix misreports
numerals.  The same enchant version, when installed from APT, does not
have this problem.  Guix enchant 2.2.8 on Debian buster also misreports
numerals.  See (on Debian bullseye):

$ enchant-2 -v
@(#) International Ispell Version 3.1.20 (but really Enchant 2.2.8)
$ which enchant-2
/usr/bin/enchant-2
$ enchant-2 -l -d en_US /tmp/enchant-test.txt
Doesn
Amarelou

$ guix install enchant; hash enchant-2
[...]
$ enchant-2 -v
@(#) International Ispell Version 3.1.20 (but really Enchant 2.2.8)
$ which enchant-2
/home/jorge/.guix-profile/bin/enchant-2
$ enchant-2 -l -d en_US /tmp/enchant-test.txt
2015
Casa
42
Amarelou
2018

The file /tmp/enchant-test.txt:
--8<---cut here---start->8---
Doesn't 2015
Casa 42
Amarelou 2018
--8<---cut here---end--->8---

So enchant 2.2.8 (either from APT or from Guix) does not understand
"doesn't"; and, what's worse, enchant-2.2.8 from Guix reports every
numeral as a misspelling.

Regards

-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- 
- 



Re: Environment variables on GNOME on foreign distro (Debian)

2020-02-29 Thread Jorge P . de Morais Neto
Em [2020-02-24 seg 12:49:32+0800], 宋文武 escreveu:

> Hello, I'd say it's not a solved problem in general.

Sad to hear.

For now, I continue to set GUIX environment variables (including
sourcing "${GUIX_PROFILE}/etc/profile") from ~/.profile.  To avoid the
GIO_EXTRA_MODULES problem, I have moved Gnucash from my default profile
to a separate Guix profile.  This way my default
"${GUIX_PROFILE}/etc/profile" does not export GIO_EXTRA_MODULES.  Then
to launch Gnucash I created an executable Bash script in ~/bin/gnucash
with the following contents:

--8<---cut here---start->8---
#!/usr/bin/env bash

GIO_PROFILE=~/".guix-extra-profiles/GIO_EXTRA_MODULES/GIO_EXTRA_MODULES"
eval $(guix package -p "${GIO_PROFILE}" --search-paths)
gnucash
--8<---cut here---end--->8---

I also copied
~/.guix-extra-profiles/GIO_EXTRA_MODULES/GIO_EXTRA_MODULES/share/applications/gnucash.desktop
into ~/.local/share/applications/gnucash.desktop and changed the Exec
line to

Exec=/home/jorge/bin/gnucash %f

It seems to be working, but I have tested it only lightly.

Regards

-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- 
- 



Re: WebP in GIMP

2020-02-01 Thread Jorge P . de Morais Neto
Em [2020-02-01 sáb 14:16:34-0500], Leo Famulari escreveu:

> On Fri, Jan 31, 2020 at 07:54:22PM -0300, Jorge P. de Morais Neto wrote:
> I added WebP support in commit 5a8adc6dfcf16ad9284d70e68da0dc320eb5af63.

Thank you.  It works.  It is a pity though that GIMP has a bare-bones
WebP export dialog.  I assumed it would be as flexible as the JPEG
export dialog.  I now realized the WebP export dialog lacks the
flexibility of cwebp and, since it also lacks live preview (which would
be its greatest advantage over cwebp), I think I will export to lossless
WebP from GIMP then reencode (in lossy manner) with cwebp.

Regards
-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



WebP in GIMP

2020-01-31 Thread Jorge P. de Morais Neto
Hi.  It seems Guix's GIMP does not support WebP.  Is there a fix for
that?

Regards
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: How to use foreign-distro fonts without symlink hack?

2020-01-06 Thread Jorge P . de Morais Neto
Em [2020-01-05 dom 19:34:24+0100], Pierre Neidhardt escreveu:

> jorge+l...@disroot.org (Jorge P. de Morais Neto) writes:
>
>> 1. Could this symlink cause problems for Debian applications?
>
> Should be fine.
>
>> 2. Why does not Guix `fc-cache' look in `/usr/share/fonts'?
>
> Because Guix does not know about files outside the store or the home
> directory.  This is by design.

Thank you for clarifying.

Regards
-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



How to use foreign-distro fonts without symlink hack?

2020-01-05 Thread Jorge P. de Morais Neto
Hi.  I use an updated Guix atop Debian buster on an x86-64 notebook.  I
had font problems in GNU Emacs.  I took hours to recognize them as such
and find the cause: Emacs was not using the fonts from Debian in
`/usr/share/fonts'.  I then worked around the problem by symlinking
/usr/share/fonts to `~/.local/share/fonts' and invoking `fc-cache'
(don't remember the exact parameters I used).  Then additional fonts
appeared in the output of `fc-list' and were indeed available to Emacs.
Two questions:

1. Could this symlink cause problems for Debian applications?
2. Why does not Guix `fc-cache' look in `/usr/share/fonts'?

Regards
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: Cannot build libdbi-drivers: "dbd_mysql.c:54:10: fatal error: mysql.h: No such file or directory"

2019-12-19 Thread Jorge P . de Morais Neto
Hello.

Em [2019-12-18 qua 22:38:13+0100], Marius Bakke escreveu:

> This is fixed with commit 9077cf68ec57c0303ef7746e203c3fe5ed041add.

I confirm the problem is solved.  A few minutes ago I have invoked
~guix pull~ and then I was able to build Gnucash.  Then I fired up
Gnucash and it showed its welcome dialog.

Thank you!
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Cannot build libdbi-drivers: "dbd_mysql.c:54:10: fatal error: mysql.h: No such file or directory"

2019-12-17 Thread Jorge P. de Morais Neto


4fqq5isxpmlcx215vqwlbj7ig8vs5q-libdbi-drivers-0.9.0.drv.bz2
Description: Binary data

For more than a week I have been unable to update Gnucash.  One of its
dependencies, libdbi-drivers, fails to build.  I have attached the build
log.

Regards
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]


Re: guix pull behind proxy not working

2019-08-16 Thread Jorge P . de Morais Neto
Em 2019-08-15T21:20:27+0200, Marius Bakke escreveu:
> I think you also need these variables in the environment that invokes
> the 'guix' command.  Does it work if you export these variables before
> running guix, in addition to having them in the daemon environment?

I think that makes no difference, as the Guix manual in
[[info:guix#Proxy Settings]] says:

Substitutes are downloaded over HTTP or HTTPS. The ‘http_proxy’
environment variable can be set in the environment of ‘guix-daemon’
and is honored for downloads of substitutes.  Note that the value of
‘http_proxy’ in the environment where ‘guix build’, ‘guix package’,
and other client commands are run has _absolutely no effect_.

Anyway I verified I had those environment variables in the environment
of guix pull, and I got "Connection timed out".

I should add that I configured Gnome to use my workplace automatic proxy
configuration; but for applications (such as GNU Emacs) that do not
integrate with Gnome proxy settings I have set up ntlmaps, which is why
the http{,s}_proxy environment variables point to localhost.  This works
fine with Emacs, both for package installation and for the EWW web
browser.  Even ~git clone https://git.savannah.gnu.org/git/guix.git~
(outside of guix pull) works.  In fact, is there a convenient way to
tell guix to use a repository I have pulled myself, with git?

Regards
-- 
- I am Brazilian.  I hope my English is correct and I welcome feedback
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z
- Free/libre software for Android: https://f-droid.org/
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]



Re: guix pull behind proxy not working

2019-08-15 Thread Jorge P . de Morais Neto
Em 2019-07-04T11:05:35+0200, mar...@famic.de escreveu:

> However, calling `guix pull` and `guix system reconfigure` still fails
> due to unreachable network.  Does it need different proxy settings?
> What can I do?

I have the same problem on a Debian buster foreign distro.  I have
configured the proxy in
/etc/systemd/system/guix-daemon.service.d/override.conf

It contains the following lines:

Environment="http_proxy=http://localhost:3128;
Environment="https_proxy=http://localhost:3128;

And I confirmed with ~systemctl show~ that both variables are correct in
the environment of Guix daemon.