Re: How to call a local function from a mcron job?

2020-12-22 Thread EuAndreh via
That makes sense. I'll try it later and report back.

Thanks!



Re: guix environment shebang interpreter

2020-02-13 Thread EuAndreh via
ml...@posteo.de writes:

> But, one answer there has a possible solution for you:
> https://unix.stackexchange.com/a/399698
>
> --8<---
> #!/bin/sh -
>
> if [ "$1" != "--really" ]; then exec bash --posix -- "$0" --really "$@";
> fi
>
> shift
>
> # Processing continues
> --->8---
>
> It lets the script `exec` itself with the right arguments! So maybe put
>
>  exec guix environment --ad-hoc PKG1 PKG2 ... -- INTERPRETER "$0"
> "$@"
>
> there?

Hmm, I guess that works. It's a bit ugly but does the job. Thanks for
the link.

I also just wanted to check for the existance of such functionality in
Guix already, before pursuing alternatives.

Thanks Moritz :)



Re: Guix as a package manager for Emacs

2020-01-28 Thread EuAndreh via
zimoun  writes:

> Maybe you can give a try to Guix Home Manager. :-)
>
> https://framagit.org/tyreunom/guix-home-manager

H, that looks interesting!

I'll take a look at it, thanks for the link :)


signature.asc
Description: PGP signature


Re: Guix as a package manager for Emacs

2020-01-28 Thread EuAndreh via
zimoun  writes:

> The easiest way to achieve similar is to use a manifest file, IMHO.
>
> Let consider the file below named '/tmp/my-emacs-config.scm', then it
> is easy to create a profile (or environment):
>
>guix package -m /tmp/my-emacs-config.scm -p /tmp/my-profile
>
> and the Emacs living in this very profile should be correctly setup-ed
> for your needs. Therefore let source the profile or whatever and done.
> :-)

At first I though guix would install the packages, but Emacs would be
unable to look them up on the store. I didn't realize the final profile
would setup Emacs to correctly look them up.

So I was missing an 'emacsWithPackage' tool that would do that binding,
but it doesn't actually seem necessary.

Using a manifest seems a good solution, I'll try it out.

Thanks for the code snippet too. Hopefull I'll get it working and
write/blog about it.

:)


signature.asc
Description: PGP signature


Re: Guix as a package manager for Emacs

2020-01-28 Thread EuAndreh via
zimoun  writes:

> The formatting failed! :-(
>
> I let you use Emacs to reformat correctly. :-)

Challenge accepted!


signature.asc
Description: PGP signature


Re: Guix as a package manager for Emacs

2020-01-22 Thread EuAndreh via
Pierre Neidhardt  writes:

> Hi!

Hello :)

> I'm not sure this is the answer you are looking for, but with Guix you
> can simply install the desired "emacs-*" packages.

So if I were to add the 'emacs' and 'emacs-evil-collection' packages, I
could just require the packages? I'll try this next and report back if I
encounter any problem.

I actually considered this possibility, but ruled this out because it
sounded too simple xD.



Guix as a package manager for Emacs

2020-01-21 Thread EuAndreh via
Hi Guix!

How can I get in Guix something similar to Nix's emacsWithPackages:
https://nixos.org/nixpkgs/manual/#sec-emacs-config

It shows how to use Nix's packaging capabilities to setup and configure
Emacs, instead of having "use-package" (or similar tools) downloading
and installing packages.

I found some previous messages and discussions in the lists archives,
but couldn't find guidance on how to proceed.

How can I accomplish it with Guix?

Thanks :)



Re: guix import texlive fails because of svn

2020-01-21 Thread EuAndreh via
Ricardo Wurmus  writes:

> Looking at the strace output I see that SVN complains about the temp
> directory already existing.  This happens in download-svn-to-store in
> guix/svn-download.scm where we generate a temporary directory and pass
> it as an argument to build:svn-fetch.
>
> Yes, this must be a bug.

Hi Ricardo,

This looks like a good opportunity for me to try to start hacking on
Guix itself. I've contributed with some patches to packages before, but
I'd  also like to start working on Guix.

I'll try to fix the issue in the next days and prepare a patch. How does
that sound?

Just saying this so we don't work on the same issue and have duplicate
effort.



Re: guix import texlive fails because of svn

2020-01-20 Thread EuAndreh via
> I'm afraid that I've had no success in getting this working.  I'm still
> unable to 'guix import' packages from TeXlive.  If you find a solution,
> please let me know!

Sure I will!



Re: Files not .gitignored when contributing to Guix

2020-01-20 Thread EuAndreh via
Efraim Flashner  writes:

> IIRC the reason for having it this way is if the .po files are added to
> .gitignore then it messes with the guix snapshots and releases.
> Unfortunately I don't remember more than that.

Snapshots as in release snapshots?



Re: Files not .gitignored when contributing to Guix

2020-01-20 Thread EuAndreh via
Julien Lepiller  writes:

> You should do "git checkout po" after your first make. You won't be annoyed 
> by that anymore afterwards.

Thanks, I'm still familiarizing myself with the GNU Autotools workflow,
and I would do a full git clean every time I wanted to hack on Guix
source code, only realizing later that I shouldn't be running
./bootstrap and ./configure on every git pull.

This way the po/ files would get modified every time.

Thanks :)



guix environment shebang interpreter

2020-01-20 Thread EuAndreh via
Hi Guix!

Is there a Guix equivalent of the nix-shell shebang?

Sample from Nix documentation
(https://nixos.org/nix/manual/#use-as-a-interpreter):

--8<---cut here---start->8---
#!/usr/bin/env nix-shell
#!nix-shell -i perl -p perl perlPackages.HTMLTokeParserSimple perlPackages.LWP

use HTML::TokeParser::Simple;

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

Can I already accomplish this with Guix? If so, how?

I tried searching previous discussions of this topic on Guix mailing
lists, but couldn't find any. If this was disscussed before, could
anyone point me to the thread?

Thanks!



Files not .gitignored when contributing to Guix

2020-01-17 Thread EuAndreh via
Hi Guix!

When running the setup steps to prepare a patch, I find myself with a
dirty repository of changed files. Is this expected behaviour?

I couldn't find guidance regarding that on the manual or the mailing
list archives (only a similar issue[0]), and I wonder if is there a way
to avoid it, or should I just get used to it? Is there something missing
for things being this way that I didn't get yet?

The output of make spits some warning regarding outdated .po files. If
the dirty files are generated, should they even be commited in the
repository if they are derived data? Looking at the diff, it confirms
this hypothesis: the diff of the .po files contain mostly generated
translation strings and timestamps.

The setup steps I use are:
--8<---cut here---start->8---
cd $GUIX_REPO
git clean -ffdx
guix environment guix --ad-hoc help2man git strace
./bootstrap
./configure --localstatedir=/var
make
--8<---cut here---end--->8---

At the end the dirty files are:
--8<---cut here---start->8---
$ git status
Sur la branche master
Modifications qui ne seront pas validées :
  (utilisez "git add ..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore ..." pour annuler les modifications dans le 
répertoire de travail)
modifié : po/guix/cs.po
modifié : po/guix/da.po
modifié : po/guix/de.po
modifié : po/guix/eo.po
modifié : po/guix/es.po
modifié : po/guix/fr.po
modifié : po/guix/hu.po
modifié : po/guix/pl.po
modifié : po/guix/pt_BR.po
modifié : po/guix/sr.po
modifié : po/guix/sv.po
modifié : po/guix/vi.po
modifié : po/guix/zh_CN.po
modifié : po/packages/da.po
modifié : po/packages/de.po
modifié : po/packages/eo.po
modifié : po/packages/es.po
modifié : po/packages/fr.po
modifié : po/packages/hu.po
modifié : po/packages/pl.po
modifié : po/packages/pt_BR.po
modifié : po/packages/sr.po
modifié : po/packages/vi.po
modifié : po/packages/zh_CN.po

aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git 
commit -a")
--8<---cut here---end--->8---

I'm looking to a better way to handle this situation (that I find a bit
of a nuisance right now) or maybe just an explanation behind the way
things currently are.

Thanks :)
EuAndreh

[0]: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00387.html



Re: guix import texlive fails because of svn

2020-01-17 Thread EuAndreh via
Hi Matthew

I had the same problem some days ago:
https://lists.gnu.org/archive/html/help-guix/2020-01/msg00017.html

The logs are really similar, and we both performed the same svn command
successfully.

I still am unable to run the TeX Live importer though. Were you able to
make it work after sending this message to the list?



"guix import texlive fontspec" is broken

2020-01-04 Thread EuAndreh via
Hi Guix!

the Guix TeX Live importer is broken for me:

--8<---cut here---start->8---
$ guix import texlive fontspec
redirection vers « https://ctan.org/xml/1.2/pkg/fontspec »...
Backtrace:
  11 (primitive-load "/home/andreh/.config/guix/current/bin/…")
In guix/ui.scm:
  1806:12 10 (run-guix-command _ . _)
In guix/scripts/import.scm:
   116:11  9 (guix-import . _)
In guix/scripts/import/texlive.scm:
91:19  8 (guix-import-texlive . _)
In guix/memoization.scm:
 98:0  7 (_ # ("fontspec" "latex") _)
In unknown file:
   6 (_ # …)
In guix/store.scm:
   625:10  5 (call-with-store #)
In guix/import/texlive.scm:
   148:23  4 (_ #)
In guix/utils.scm:
664:8  3 (call-with-temporary-directory #)
In guix/svn-download.scm:
   160:14  2 (_ "/tmp/guix-directory.HSWcZg")
In guix/build/svn.scm:
 39:2  1 (svn-fetch _ _ _ #:svn-command _ #:recursive? _ # _ # _)
In guix/build/utils.scm:
652:6  0 (invoke _ . _)

guix/build/utils.scm:652:6: In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
--8<---cut here---end--->8---

I tried running the SVN command that throwed (I tried to guess it from
the error log) and it ran successfully:

--8<---cut here---start->8---
$ svn export --non-interactive --trust-server-cert -r 49435 
svn://www.tug.org/texlive/tags/texlive-2018.2/Master/texmf-dist/source/latex/fontspec
 /tmp/guix-directory.WtLohP
A/tmp/guix-directory.WtLohP
A/tmp/guix-directory.WtLohP/fontspec-api.dtx
A/tmp/guix-directory.WtLohP/fontspec-closing.dtx
A/tmp/guix-directory.WtLohP/fontspec-code-load.dtx
A/tmp/guix-directory.WtLohP/fontspec-code.ltx
A/tmp/guix-directory.WtLohP/fontspec-doc-api.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-enc.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-featset.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-fontsel.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-intro.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-luatex.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-opentype.tex
A/tmp/guix-directory.WtLohP/fontspec-doc-style.sty
A/tmp/guix-directory.WtLohP/fontspec-doc-xetex.tex
A/tmp/guix-directory.WtLohP/fontspec-enc.dtx
A/tmp/guix-directory.WtLohP/fontspec-example.tex
A/tmp/guix-directory.WtLohP/fontspec-feat-aat.dtx
A/tmp/guix-directory.WtLohP/fontspec-feat-opentype.dtx
A/tmp/guix-directory.WtLohP/fontspec-fontload.dtx
A/tmp/guix-directory.WtLohP/fontspec-graphite.dtx
A/tmp/guix-directory.WtLohP/fontspec-interfaces.dtx
A/tmp/guix-directory.WtLohP/fontspec-internal.dtx
A/tmp/guix-directory.WtLohP/fontspec-keyval.dtx
A/tmp/guix-directory.WtLohP/fontspec-lang.dtx
A/tmp/guix-directory.WtLohP/fontspec-lua.dtx
A/tmp/guix-directory.WtLohP/fontspec-math.dtx
A/tmp/guix-directory.WtLohP/fontspec-msg.dtx
A/tmp/guix-directory.WtLohP/fontspec-opening.dtx
A/tmp/guix-directory.WtLohP/fontspec-opentype.dtx
A/tmp/guix-directory.WtLohP/fontspec-patches.dtx
A/tmp/guix-directory.WtLohP/fontspec-scripts.dtx
A/tmp/guix-directory.WtLohP/fontspec-user.dtx
A/tmp/guix-directory.WtLohP/fontspec-vars.dtx
A/tmp/guix-directory.WtLohP/fontspec-xfss.dtx
A/tmp/guix-directory.WtLohP/fontspec.dtx
A/tmp/guix-directory.WtLohP/fontspec.ins
A/tmp/guix-directory.WtLohP/fontspec.ltx
Exported revision 49435.
--8<---cut here---end--->8---

So I would guess the problem would be to the inputs to the build
environment that 'guix import texlive' is using, but I didn't dive into
the source code.

I picked the fontspec package because it is the example used in the
manual for the TeX Live importer, but it failed for me with other
packages too.

Any thoughts on this?


Thanks,
EuAndreh :)