Re: Cannot run texlive context: permission denied
Hello, Taha Aziz Ben Ali writes: > I've been following the master branch ever since the changes you've > introduced and I was wondering whether there was a particular reason > they haven't been merged yet. Branches are merged in a FIFO order. Two branches are currently located before "tex-team", as pointed out at <https://qa.guix.gnu.org>. I think "gnome-team" will be merged very soon. I have no idea about "core-updates". Meanwhile, I'm polishing "tex-team" so it will be absolutely fantastic (or utterly broken) once merged ;) > If additional testing is required, I'd be happy to help out, but as I > previously pointed out, ConTeXt is working properly now. Thank you for your feedback! For now, waiting is the only thing to do, however. Regards, -- Nicolas Goaziou
Re: Cannot run texlive context: permission denied
Nicolas Goaziou via writes: > Taha Aziz Ben Ali writes: > >>> I think it is fixed in "tex-team" branch. >> >> Thank you Nicolas, >> >> I tried out your changes, and although the "permission denied" error no >> longer shows up, running context in the terminal (user home intact, >> i.e. without my previous configuration hack) yields the following >> message: > > [...] > >> It seems that mtxrun fails to find either files, the same message will >> also appear if invoking context through mtxrun via the --script flag. > > Could you trying clearing out your cache, i.e. > "~/.texlive2023/texmf-var/"? It may contain bogus information. Nevermind! I misread your error message; your cache seems OK. I think you created an incomplete environment, i.e., you used something such as: ./pre-inst-env guix shell texlive-context But `texlive-context' alone is not sufficient. You need at least a scheme or a collection in this environment, as mentioned in the manual, or, if you really want to be minimal, `texlive-bin'. E.g., in decreasing size: ./pre-inst-env guix shell texlive-collection-context or ./pre-inst-env guix shell texlive-scheme-minimal texlive-context or ./pre-inst-env guix shell texlive-bin texlive-context HTH, -- Nicolas Goaziou
Re: Cannot run texlive context: permission denied
Hello, Taha Aziz Ben Ali writes: >> I think it is fixed in "tex-team" branch. > > Thank you Nicolas, > > I tried out your changes, and although the "permission denied" error no > longer shows up, running context in the terminal (user home intact, > i.e. without my previous configuration hack) yields the following > message: [...] > It seems that mtxrun fails to find either files, the same message will > also appear if invoking context through mtxrun via the --script flag. Could you trying clearing out your cache, i.e. "~/.texlive2023/texmf-var/"? It may contain bogus information. Regards, -- Nicolas Goaziou
Re: Cannot run texlive context: permission denied
Hello,
Taha Aziz Ben Ali writes:
> I'm here to tell you that I found a working workaround for making
> ConTeXt work through `mtxrun --script context`.
>
> Create a "texmf/web2c/texmfcnf.lua" file (and preceeding directories)
> under your user's home directory and add the following:
>
>
> return {
> content = {
> variables = {
>TEXMF = os.getenv("GUIX_ENVIRONMENT") .. "/share/texmf-dist"
> },
> },
> }
>
>
> That should be enough to get the ball rolling. Note however that running
> `context` independently from `mtxrun` continues to fail.
>
> These changes should probably be added to the build derivation, it seems
> that Guix' non-standard filesystem don't work well with TeXLive's
> default settings.
I think it is fixed in "tex-team" branch.
Regards,
--
Nicolas Goaziou
Re: LuaTeX/luaotfload doesn't find any fonts (using fontspec) on Guix?
Hello,
I forgot to send a carbon copy to help-guix ML in my last answer, so
I include it here.
Nicolas Goaziou via writes:
> Benjamin Slade writes:
>
>>> This doesn't seem good as the store is not writable.
>>
>>> I read[¹] that "texmf.cnf" and "texmfcnf.lua" might be misconfigured. In
>>> particular, `kpsewhich -var-value=TEXMFCACHE' reports a store location.
>>> At the very least, I think TEXMFCACHE in "texmf.cnf" should be set to
>>> $TEXMFVAR instead of $TEXMFSYSVAR;$TEXMFVAR as it is the case currently.
>>> I'm not sure it will help, tho.
>>
>> I will try to see if there is anything that can be done in terms of
>> local/home configuration.
>>
>> I wonder if there's a reasonable upstream/Guix fix for the luatex
>> package definition.
>
> What I wrote above is actually wrong. $TEXMFSYSVAR does not point to the
> store, but to "{/gnu/...", which means "lualatex" creates a "{"
> directory in the current working directory. It is silly (and has been
> reported already[¹]), but at least the cache can be written to the disk.
>
> I'm not sure yet there's a problem on the Guix side. Font configuration
> can be tricky.
Actually, the problem is on the Guix side, and it will be solved in the
"tex-team" branch.
Meanwhile, the solution is to set OSFONTDIR environment variable to
'{$XDG_DATA_DIRS}'.
With it, the following "test.tex" document compiles correctly:
--8<---cut here---start->8---
\documentclass{article}
\usepackage{fontspec}
\setmainfont{Fantasque Sans Mono}
\begin{document}
Test \textbf{Test} \textit{Test}
\end{document}
--8<---cut here---end--->8---
in the following environment
guix shell --pure texlive-collection-latex texlive-fontspec fontconfig
font-fantasque-sans
with the following command
export OSFONTDIR='{$XDG_DATA_DIRS}'; lualatex test.tex
Thank you for the bug report!
Regards,
--
Nicolas Goaziou
Re: texlive kpathsea ignores TEXMFHOME
Hello,
Fulbert writes:
> Hello ! As the little shell session illustrates below, 'kpathsea' fails
> to search/find files in TEXMFHOME on my “Guix system” setup .
Indeed. I fixed this issue in "tex-team" branch.
Meanwhile, you may set TEXMF environment variable to "'{$TEXMFHOME,$TEXMFDIST}'"
Regards,
--
Nicolas Goaziou
Re: LuaTeX/luaotfload doesn't find any fonts (using fontspec) on Guix?
Hello,
Benjamin Slade writes:
>> This doesn't seem good as the store is not writable.
>
>> I read[¹] that "texmf.cnf" and "texmfcnf.lua" might be misconfigured. In
>> particular, `kpsewhich -var-value=TEXMFCACHE' reports a store location.
>> At the very least, I think TEXMFCACHE in "texmf.cnf" should be set to
>> $TEXMFVAR instead of $TEXMFSYSVAR;$TEXMFVAR as it is the case currently.
>> I'm not sure it will help, tho.
>
> I will try to see if there is anything that can be done in terms of
> local/home configuration.
>
> I wonder if there's a reasonable upstream/Guix fix for the luatex
> package definition.
What I wrote above is actually wrong. $TEXMFSYSVAR does not point to the
store, but to "{/gnu/...", which means "lualatex" creates a "{"
directory in the current working directory. It is silly (and has been
reported already[¹]), but at least the cache can be written to the disk.
I'm not sure yet there's a problem on the Guix side. Font configuration
can be tricky.
[¹] <https://issues.guix.gnu.org/64772>
Regards,
--
Nicolas Goaziou
Re: LuaTeX/luaotfload doesn't find any fonts (using fontspec) on Guix?
Hello,
Benjamin Slade writes:
> I'm having trouble using LuaTeX on Guix.
>
> luaotfload doesn't seem to be able to find any fonts, whether system-wide or
> local (when used with fontspec). I get messages like:
>
> luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font
> "Cardo" not found.
> luaotfload | resolve : sequence of 3 lookups yielded nothing
> appropriate.
> ! Package fontspec Error: The font "Cardo" cannot be found.
>
> I don't have this issue on other distros, or on Guix when using XeTeX instead
> of LuaTeX.
>
> Is there some additional setup or configuration (or another package ?)
> that I need on Guix to get LuaTeX/luatofload to work properly ?
> (pathing issues of some sort ?)
I compiled successfully the following document (test-font.tex):
--8<---cut here---start->8---
\documentclass[11pt,a4paper]{amsart}
\usepackage{unicode-math}
\setmathfont{Asana Math}
\setmainfont{Droid Serif}
\begin{document}
\[(D_e\Phi_{\gamma(s)})^{-1}(\gamma'(s))=\varphi'(s)(D_e\Phi_{\alpha(\varphi(s))})^{-1}(\alpha'(\varphi(s)))\]
\end{document}
--8<---cut here---end--->8---
using the following command:
guix shell texlive-scheme-small texlive-collection-luatex texlive-droid
texlive-asana-math texlive-unicode-math -- lualatex test-font.tex
However, I don't think it takes into consideration the specified fonts.
In the same environment, `luaotfload-tool --help' reports
--8<---cut here---start->8---
The font database will be saved to
{/gnu/store/f1hdawmb5401cldyl6f27lvc3hvxbw8l-profile/share/texmf-dist/luatex-cache/generic/names/luaotfload-names.lua.gz
{/gnu/store/f1hdawmb5401cldyl6f27lvc3hvxbw8l-profile/share/texmf-dist/luatex-cache/generic/names/luaotfload-names.luc
---
FONT CACHE
--cache= operate on font cache, where is
"show", "purge", or "erase"
The font cache will be written to
{/gnu/store/f1hdawmb5401cldyl6f27lvc3hvxbw8l-profile/share/texmf-dist/luatex-cache/generic/fonts/
--8<---cut here---end--->8---
This doesn't seem good as the store is not writable.
I read[¹] that "texmf.cnf" and "texmfcnf.lua" might be misconfigured. In
particular, `kpsewhich -var-value=TEXMFCACHE' reports a store location.
At the very least, I think TEXMFCACHE in "texmf.cnf" should be set to
$TEXMFVAR instead of $TEXMFSYSVAR;$TEXMFVAR as it is the case currently.
I'm not sure it will help, tho.
Regards,
[¹]
<https://tex.stackexchange.com/questions/691039/luaotfload-no-writeable-cache-path-error/691047>
--
Nicolas Goaziou
Re: LaTeX: Need help with packaging a book in GNU Guix
Hello,
"Dr. Arne Babenhauserheide" writes:
> "Artyom V. Poptsov" writes:
>
>> -\usepackage{amssymb}
>> -\usepackage{marvosym}
>> I think that it is not worth the effort to use the "marvosym" package as
>> I can easily draw the single symbol I want from the package myself. But
>> maybe there's a problem with "texlive-marvosym" package as well, don't
>> know for sure though.
>
> Since the switch to split texlive packages, many of my documents don’t
> compile yet (but I did not yet find out why, so I sadly can’t really
> help you) and I also use marvosym. So maybe something more general.
I looked at the "texlive-marvosym" package again, but couldn't spot
anything suspicious.
OTOH, Artyom successfully built their book in a "--pure" shell
environment, so that package may not be the culprit. It more sounds like
an incompatibility between Ubuntu's TeX Live packages and Guix's.
I admit I don't understand the problem, tho.
In any case, feel free to report the errors you encounter with your
documents (without necessarily spending time investigating). This is
a valuable feedback for finding out bugs in modular TeX live.
Regards,
--
Nicolas Goaziou
Re: LaTeX: Need help with packaging a book in GNU Guix
"Artyom V. Poptsov" writes: > Hello Nicolas! > Thanks, that worked out indeed. I've added other LaTeX packages as > well, searching by the required ".sty" files. Great! > /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: > /gnu/store/05770yhxad3d3p4q7rgw8clh0y1gi5sc-texlive-glossaries-66594/bin/makeglossaries: > /usr/bin/env: bad interpreter: No such file or directory > make: *** [Makefile:77: make_glossary] Error 1 > make: *** Waiting for unfinished jobs > --8<---cut here---end--->8--- > > > It looks like "makeglossaries" cannot find "/usr/bin/env" program. It should be fixed on master, if you can guix pull again. > Strangely enough when I add "texlive" to the inputs, the problem is > gone. This is not strange. `texlive' provides `perl' once in its inputs, and all scripts, such as `makeglossaries', have their shebang line updated. In modular TeX Live, packages are responsible for their own script(s); and need to provide `perl', for example, as an input. This is not obvious when the script has no extension, as it is the case here. Regards,
Re: LaTeX: Need help with packaging a book in GNU Guix
"Artyom V. Poptsov" writes: > When I tried to remove "texlive" from inputs, I ran into the following > error: > > --8<---cut here---start->8--- > ! LaTeX Error: File `fontspec.sty' not found. [...] > As you can see, LaTeX cannot find "fontspec.sty" file. I did some > research and found that the file belongs to "texlive" package. So when > I returned "texlive" to inputs the build process went fine. I then suggest to add `texlive-fontspec' (a few kB) instead of `texlive' (3 GB) to the inputs. If you insist on adding `texlive' to the inputs, you can remove every other "texlive-" input instead; it's one or the other. Regards,
Re: LaTeX: Need help with packaging a book in GNU Guix
Hello,
"Artyom V. Poptsov" writes:
> There are lots of examples of LaTeX package definitions in Guix for
> sure, but unfortunately I found no examples of packaged books written in
> LaTeX.
There is `book-faif' in "fsf.scm".
> Then I'm getting errors that "Liberation Serif" font is not found:
>
> --8<---cut here---start->8---
> (/gnu/store/h7iqqr3aajqhjkib2k2g0zipag2ya41s-texlivetexmf-20230313/share/texmf-
> dist/tex/latex/fontspec/fontspec.cfg)))
>
> ! Package fontspec Error: The font "Liberation Serif" cannot be found.
> For immediate help type H .
> ...
>
> l.8 \setmonofont
> {Liberation Mono}
You should add `fontconfig' to native-inputs so Liberation can be found.
You can also remove `texlive' and, probably, `texlive-latex-fonts' and
`texlive-ttf-utils' from your inputs, since you're using XeTeX.
I suggest the following:
--8<---cut here---start->8---
(native-inputs
(list python-pygments
bash-minimal
perl
which
fontconfig))
(inputs
(list font-liberation
git
gnu-make
inkscape
lilypond
texlive-acronym
texlive-adjustbox
texlive-bibtex
texlive-bibtexperllibs
texlive-bigfoot
texlive-circuitikz
texlive-collection-langcyrillic
texlive-glossaries
texlive-lilyglyphs
texlive-minted
texlive-multirow
texlive-pgf
texlive-subfiles
texlive-svg
texlive-t1utils
texlive-textpos
texlive-transparent
texlive-xetex))
--8<---cut here---end--->8---
Note that everything could be moved to native inputs.
Also note that you need un-packaged TeX Live packages, such as `svg'.
I added them just before sending the mail, so you'll need a recent "guix
pull".
> Moreover I see that the build tries to update the font cache but fails
> to do that because the part of the file system it tries to write to is
> read-only:
>
> --8<---cut here---start->8---
> (/gnu/store/h7iqqr3aajqhjkib2k2g0zipag2ya41s-texlivetexmf-20230313/share/texmf-
> dist/tex/latex/base/book.cls
> Document Class: book 2022/07/02 v1.4n Standard LaTeX document class
>
> (/gnu/store/h7iqqr3aajqhjkib2k2g0zipag2ya41s-texlivetexmf-20230313/share/texmf-
> dist/tex/latex/base/bk10.cloFontconfig error: No writable cache directories
> Fontconfig error: No writable cache directories
> ))
> --8<---cut here---end--->8---
This "error" is actually harmless.
Regards,
--
Nicolas Goaziou
Re: documentation in TeX Live collections
Nicolas Goaziou writes: > Emmanuel Beffara writes: >>> In any case, I suggest to write a proper bug report for this. Hopefully, >>> someone with better understanding about the implications of GUIX_TEXMF >>> will be able to solve this. >> >> I can do that for the texdoc behaviour. By the way, I think I fixed `texdoc' utility. Would you care testing it after a fresh `guix pull'?
Re: documentation in TeX Live collections
Emmanuel Beffara writes: > I don't understand how "out" and "doc" are different in this respect. The > "out" output of a collection meta-package has no content of its own and it > only serves to gather the "out" outputs of its inputs. Similarly, the "doc" > output would have no content of its own and only gather the "doc" outputs of > its inputs. How is that inconsistent? > > There may be something I misunderstand about how Guix packages work > here. Outputs are used to split files to be installed after building a package. Since meta-packages do not build anything, there is nothing to install, and therefore, to split. The default output is enough. I imagine it would be possible to bend that concept, and, for example, create a tree of symlinks, pointing to the documentation of the various propagated packages, that would ultimately be moved to a "doc" output. AFAICT, however, no package in Guix does this. Another data point to consider: `texlive-collection-foo' and hypothetical `texlive-collection-foo:doc' would require to propagate two different sets of packages, which may be an argument in favor of creating two different packages in the first place. Please note that I have no strong opinion on that subject anyway. I hope experienced TeX Live users can chime in. >> In any case, I suggest to write a proper bug report for this. Hopefully, >> someone with better understanding about the implications of GUIX_TEXMF >> will be able to solve this. > > I can do that for the texdoc behaviour. Great! Thank you. -- Nicolas Goaziou
Re: documentation in TeX Live collections
Hello,
Emmanuel Beffara writes:
> Yet, as far as I know, most packages in Guix (apart from texlive-* ones) come
> with their documentation, so it feels somewhat inconsistent.
Every texlive-* package comes with its documentation, in a separate
output. "doc" output are not uncommon at all in Guix. Therefore,
I disagree with the inconsistency you're talking about.
> not including the docs in the main outputs can make sense, especially given
> the volume it represents. Anyway, given that there is extensive documentation
> in TeX Live, it seems only natural to have it easily accessible.
Barring the `texdoc' issue, documentation is easily accessible; you just
need to install the "doc" output of the package you're interested in.
>> Would the following definition for texlive-texdoc solve both issues
>> mentioned above? (the warning and the error.)
> [...]
>>(add-after 'link-scripts 'wrap-programs
>> (lambda _
>>(wrap-program (string-append #$output "/bin/texdoc")
>> '("GUIX_TEXMF" = ("${GUIX_TEXMF%:*}"
>
> It would certainly remove the warning but it would make only the first path
> usable by texdoc, while other tools seem to support having several paths in
> GUIX_TEXMF. Besides, I don't understand how GUIX_TEXMF is taken into account
> by the various tools. Web2c and co don't know them, so there must be some
> wrapping or patching somewhere in the package definitions?
It seems some programs do handle it fine, e.g., tlmgr, but not all of
them (e.g., texdoc or chktex). In any case, I don't know enough about
this part of the code to answer this.
> Is there a way to diagnose that kind of thing? I stumbled on a similar
> behaviour in other contexts and was unable to investigate it (in my case, big
> debug versions of Qt libraries are often downloaded, although I neved
> requested any debugging version of anything).
Usually, there is `guix graph --path package1 package2', which explains
why package2 is installed along with package1. I couldn't get any
meaningful result in this case.
>> If that's a common request, we could add a `texlive-collection-foo-doc'
>> package that would propagate all "doc" outputs from all packages
>> included in `texlive-collection-foo'.
>>
>> However, I'm a bit reluctant to add more artificial packages (i.e., not
>> known to TeX Live distribution). Also, it might be as simple to do it in
>> one's own manifest.
>
> I think it would make much more sense to have "doc" outputs also for
> collections and schemes. It would be consistent with the structure of
> individual packages and would not require artificial packages.
I disagree. Collections are meta-packages. There is no documentation,
nor content, attached to them. Moreover Guix meta-packages do nothing
special about the documentation of packages they propagate. This would
be inconsistent.
> Having individual package documentations in one's manifests is of course
> doable but it is contradictory with the approach of collections.
How so?
In any case, I suggest to write a proper bug report for this. Hopefully,
someone with better understanding about the implications of GUIX_TEXMF
will be able to solve this.
Regards,
--
Nicolas Goaziou
Re: documentation in TeX Live collections
a _
(wrap-program (string-append #$output "/bin/texdoc")
'("GUIX_TEXMF" = ("${GUIX_TEXMF%:*}"
(propagated-inputs (list texlive-kpathsea))
(home-page "https://ctan.org/pkg/texdoc";)
(synopsis "Documentation access for TeX Live")
(description
"@command{texdoc} is a Lua script providing easy access to the
documentation in TeX Live: PDF, DVI, plain text files, and more. Viewing and
other configuration can be extensively customized.")
(license license:gpl3+)))
--8<---cut here---end--->8---
> As an attempt to work around this, I tried to add texlive-latex:doc to my home
> profile definition and it did make that documentation available to texdoc.
> Moreover, for some reason, ALL documentation was downloaded:
>
> $ guix home reconfigure home.scm
> ...
> texlive-cm-66594-doc 2KiB
> texlive-etex-66594-doc 189KiB
> texlive-hyphen-complete-66594-doc 783KiB
> texlive-kpathsea-66594-doc 1022KiB
> texlive-pdftex-66594 4.2MiB
> ...
> $ ls -d /gnu/store/*-texlive-*-doc/ | wc
>11051105 82506
>
> Apparently something has triggered the download of documentation for all
> packages `texlive-scheme-medium` depends on but only the one I explicitly
> requested is made available in the profile (which is expected). All these
> other documentation were downloaded but not used and `guix gc` actually
> deletes them all!
I noticed that, too, but I don't have any explanation for it at the
moment.
For example,
./pre-inst-env guix shell texlive-scheme-basic texlive-texdoc
texlive-babel:doc
is enough to trigger a massive download of "doc" outputs.
> So what would be the proper way to install `texlive-scheme-medium` in a home
> profile with the documentation of the packages it includes ?
If that's a common request, we could add a `texlive-collection-foo-doc'
package that would propagate all "doc" outputs from all packages
included in `texlive-collection-foo'.
However, I'm a bit reluctant to add more artificial packages (i.e., not
known to TeX Live distribution). Also, it might be as simple to do it in
one's own manifest.
I'm Cc'ing guix-devel ML.
Regards,
--
Nicolas Goaziou
Re: image converter and resizer
Hello,
Andreas Enge writes:
> I had a quick look at converseen. It requires the qtlinguist package,
> which we do not have in Guix.
qtlinguist belongs to qttools, doesn't it?
The main issue in properly packaging converseen is, IMO, to remove the
(auto)update code all over the place.
For the record, here's a draft, without the check updates cleanup:
--8<---cut here---start->8---
(define-public converseen
(package
(name "converseen")
(version "0.9.11.1")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/Faster3ck/Converseen";)
(commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
(base32
"0nxvac8df47gxg1klqlz0s3rxl0ykrikmciniwkb938bgilmaijm"
(build-system cmake-build-system)
(arguments
(list
#:tests? #false ;no tests
#:phases
#~(modify-phases %standard-phases
(add-after 'unpack 'set-translations-location
;; Fix translations location.
(lambda _
(substitute* "src/translator.cpp"
(("QString\\(\"%1/share/converseen/loc\"\\).arg\\(rootPath\\)")
(string-append "QString(\""
#$output
"/share/converseen/loc\")")
;; (add-after 'unpack 'disable-updates-checks
;; ;; Disable "Check for updates" since there's no use for it
;; ;; in Guix and we don't want software to phone home.
;; (lambda _
;; (error "foo")))
)))
(native-inputs
(list pkg-config qttools-5))
(inputs
(list imagemagick qtbase-5))
(home-page "https://converseen.fasterland.net/";)
(synopsis "Batch image converter and resizer")
(description
"Converseen is an image batch conversion tool. You can resize and
convert images in more than 100 different formats.")
(license license:gpl3+)))
--8<---cut here---end--->8---
Regards,
--
Nicolas Goaziou
Re: Reference a store path of an input?
Hello,
Jim Newsome writes:
> I'm just getting started experimenting with guix and guile
Great!
> I'd like to add some explicit flags to the cmake invocation so that it
> knows where to find glib. What do I substitute in for "get-store-path"
> below? Pointers to how I might have found the appropriate helper or
> approach on my own also appreciated.
You may want to read about G-Expressions in Guix manual. See also
<https://guix.gnu.org/fr/blog/2021/the-big-change/> for addition
insight.
> ```
> (define-public oniontrace
> (package
> (name "oniontrace")
> (build-system cmake-build-system)
> (inputs `(("glib", glib)))
> (arguments
> '(#:configure-flags
> (list (string-append "-DCMAKE_EXTRA_INCLUDES="
> (get-store-path "glib") "/include"
> ...
> ```
I should be:
(arguments
(list
#:configure-flags
#~(list (string-append "-DCMAKE_EXTRA_INCLUDES=" #$glib "/include"
Regards,
--
Nicolas Goaziou
Re: [PATCH] gnu: Update sdlpop.
Hello, phodina writes: > Unfotunately the price executable looks for a diractory DATA in the > directory of argv[0], therefore the prince executable runs only from > the /guix/store/xxx-sdlpop/bin directory. > > The following patch replaces the former location with the latter. > > * gnu/packages/games.scm (sdlpop)[arguments]: Substitute location of > executable. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: How to use emacs-tramp ?
Hello, znavko--- via writes: > Hello! i wish transparently edit php files on remote server with emacs. > i've installed emacs-tramp with 'guix install emacs-tramp' > and required it and configured it with lines in > ~/.emacs as desribed here: > https://www.gnu.org/software/tramp/#Default-Host > > But when I press C-x C-f > and type '-::' and then save this file > emacs just says: "Wrote /home/bob/-::' Shouldn't you type "/" first, i.e., '/-::' ? Regards, -- Nicolas Goaziou
Re: Broken emacs-treemacs package in current Guix
Hello, Gary Johnson writes: > If I try to build the emacs-treemacs package that comes with Guix > (declared in emacs-xyz.scm), this crashes out due to a failing test > during its "make test" phase. This should be now be fixed. Thank you. Regards, -- Nicolas Goaziou
Re: fix chessx
Hello, Adam Kandur via writes: > hi everyone! recently i tried to install chessx on my laptop, there > were errors. then i decided to test in my channel. and, i fixed link > for downloading chessx. hope will be usefull. FWIW, I have no problem building chessx in its current form. In particular, I don't get any error downloading the source tarball. > > diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm > index 63977f9..34eacb3 100644 > --- a/gnu/packages/games.scm > +++ b/gnu/packages/games.scm > @@ -10313,7 +10313,7 @@ and chess engines.") > (source > (origin > (method url-fetch) > - (uri (string-append "mirror://sourceforge/chessx/chessx/" > + (uri (string-append > "https://downloads.sourceforge.net/project/chessx/chessx/"; The mirror should be more general than your specific URL. Maybe it was a transient error. Regards, -- Nicolas Goaziou
Re: CV Assistant
Hello, Jesse Gibbons writes: > Great news! I got cvassistant working! I will send the patch when I > have time. Excellent! > Nicolas Goaziou, I could not have done it without your template, so I > want to include your info in the copyright section of cvassistant.scm. > If that's ok with you, what should I put? Sure, you can add: Copyright © 2019 Nicolas Goaziou Thank you! Regards, -- Nicolas Goaziou
Re: CV Assistant
Hello,
Raghav Gururajan writes:
> I sat to do it several times but could not start it due to the
> situation I am in. I am curious to learn packaging in guix and I am
> confident that I will be doing it someday. It just not the right time
> (hectic situation).
In order to get you, or someone else, started, here is a draft for the
package:
(define-public cvassistant
(package
(name "cvassistant")
(version "3.1.0")
(source (origin
(method url-fetch)
(uri (string-append "mirror://sourceforge/cvassistant/"
"cvassistant-" version "-src.tar.bz2"))
(sha256
(base32
"1y2680bazyiwm50gdhdd4982ckbjscrkbw2mngyk7yw708iadvr7"
(build-system gnu-build-system)
(arguments
`(#:phases
(modify-phases %standard-phases
(add-after 'unpack 'remove-donation-banner
;; Remove dialog box with a donation link, as suggested by
;; the INSTALL file.
(lambda _
(substitute* "controllers/mainwindow.cpp"
(("#(define NO_DONATION_PROMPT)" _ line) line))
#t))
(add-after 'unpack 'fix-quazip-directory
;; Without it, build process fails with "fatal error:
;; quazip/quazipfile.h: No such file or directory".
;;
;; FIXME: insufficient! It fails later with "ld: cannot
;; find -lquazip-qt5".
(lambda _
(substitute* "models/resumedocument.h"
(("quazip(/quazipfile\\.h)" _ suffix)
(string-append "quazip5" suffix)))
#t))
(replace 'configure
(lambda _ (invoke "qmake"))
(inputs
`(("qtbase" ,qtbase)
("quazip" ,quazip)
("zlib" ,zlib)))
(home-page "https://cvassistant.sourceforge.io/";)
(synopsis "Job application organizer")
(description "Whether you're looking for a job or trying to help
a friend to find one, CVAssistant is a tool for you. It helps you by
preparing resumes and cover letters and organizing your job
application process. It:
@itemize
@item Stores all your skills and experiences.
@item Creates resumes tailored for each job you apply.
@item Creates cover letters summarized to match each job
advertisement.
@item Keeps a history of job applications so you are ready when you
receive a phone call.
@item Writes resumes in your language. All languages are supported!
@end itemize")
(license license:gpl3+)))
Unfortunately, it fails to build with "ld: cannot find -lquazip-qt5".
This is probably related to this part of the definition:
(add-after 'unpack 'fix-quazip-directory
;; Without it, build process fails with "fatal error:
;; quazip/quazipfile.h: No such file or directory".
;;
;; FIXME: insufficient! It fails later with "ld: cannot
;; find -lquazip-qt5".
(lambda _
(substitute* "models/resumedocument.h"
(("quazip(/quazipfile\\.h)" _ suffix)
(string-append "quazip5" suffix)))
#t))
I'm quite certain this is not too hard to solve. You may want to
investigate a bit further, or ask for help through IRC, etc.
HTH,
Regards,
--
Nicolas Goaziou
Re: Winetricks
Hello, Pierre Neidhardt writes: > Alright, settled. Some notes: - As another data point, Debian provides winetricks in "contrib/", not in "non-free"; - There is winetricks-libre at <https://github.com/g4jc/winetricks-libre> Regards, -- Nicolas Goaziou
Re: Need some help to remove non-free documentation
Hello, l...@gnu.org (Ludovic Courtès) writes: Thank you for your answer. > What I would do in a ‘snippet’ or the origin is: > > 1. rm -rf doc > > 2. Remove “doc” from the ‘SUBDIRS’ variable of the top-level > Makefile.in. That would remove all documentation. However, only a tiny part of it is non-free. I'm trying to preserve some of it. > That way you won’t need to regenerate the build files. > > Does that make sense or am I too naive? IIUC, this will unfortunately not cut it. > (Besides we should get in touch with the folks at Grenoble University to > see if they would agree to liberating the docs. Perhaps Debian people > already attempted?) Debian encounters the same problem, see <https://salsa.debian.org/science-team/giac/blob/master/debian/giac-doc.README.Debian>. I don't know if they attempted to contact the author, tho. Regards, -- Nicolas Goaziou
Need some help to remove non-free documentation
mbda _
(substitute* (find-files "doc" "^Makefile")
(("/bin/cp") (which "cp")))
#t))
(add-after 'unpack 'disable-failing-test
;; FIXME: Test failing. Not sure why.
(lambda _
(substitute* "check/Makefile.in"
(("chk_fhan11") ""))
#t))
(add-after 'install 'install-doc
;; Setting --docdir to "doc" output isn't sufficient as
;; documentation and examples are scattered throughout the source.
(lambda* (#:key outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(doc (assoc-ref outputs "doc"))
(docdir (string-append doc
"/share/doc/"
(string-append ,name "-" ,version
;; For some reason, the install process moves
;; "share/giac/examples" instead of "share/giac/doc" to
;; "$(docdir)". Clean up the mess and start over.
(delete-file-recursively (string-append doc "/share"))
(mkdir-p docdir)
(with-directory-excursion out
(for-each (lambda (f)
(unless (member f '("." ".."))
(copy-recursively (string-append "share/giac/" f)
(string-append docdir "/" f
(scandir "share/giac"))
(delete-file-recursively "share/giac")))
#t)
(inputs
`(("fltk" ,fltk)
("gmp" ,gmp)
("gsl" ,gsl)
("lapack" ,lapack)
("libao" ,ao)
("libjpeg" ,libjpeg)
("libpng" ,libpng)
("libx11" ,libx11)
("libxinerama" ,libxinerama)
("libxft" ,libxft)
("libxt" ,libxt)
("mesa" ,mesa)
("mpfi" ,mpfi)
("mpfr" ,mpfr)
("ntl" ,ntl)
("perl" ,perl)
("pari-gp" ,pari-gp)
("tcsh" ,tcsh)
("texlive" ,texlive-tiny)))
(native-inputs
`(("autoconf" ,autoconf)
("automake" ,automake)
("libtool" ,libtool)
("readline" ,readline)))
(home-page "https://www-fourier.ujf-grenoble.fr/~parisse/giac.html";)
(synopsis "Computer algebra system")
(description
"Giac/Xcas is a computer algebra system. It has a compatibility mode for
maple, mupad and the TI89. It is available as a standalone program (graphic
or text interfaces) or as a C++ library.")
(license license:gpl3+)))
--8<---cut here---end--->8---
Regards,
--
Nicolas Goaziou
Re: gst-plugins-base: Test suite failed: FAIL: elements/opus
Hello, Pierre Neidhardt writes: > I can't update my packages `guix package -u`, gst-plugins-base fails: [...] > FAIL: elements/opus > === > > Running suite(s): opus > 33%: Checks: 6, Failures: 0, Errors: 4 > gstcheck.c:596:E:general:test_opus_encode_nothing:0: (after this point) > Received signal 11 (Segmentation fault) > gstcheck.c:596:E:general:test_opus_encode_samples:0: (after this point) > Received signal 11 (Segmentation fault) > gstcheck.c:596:E:general:test_opus_encode_properties:0: (after this point) > Received signal 11 (Segmentation fault) > elements/opus.c:429:E:general:test_opus_decode_plc_timestamps_with_fec:0: > (after this point) Received signal 11 (Segmentation fault) > Check suite opus ran in 0.014s (tests failed: 4) > FAIL elements/opus (exit status: 4) [...] > Anyone else? Ditto. It breaks wine upgrade (even wine64). Quick and dirty fix: what about disabling elements/opus test? It doesn't look like a vital part. Regards, -- Nicolas Goaziou0x80A93738
Re: invoking info guix
Hello, Catonano writes: > In a terminal I can issue this command > > ~$ info guix > > and have the guuix manual pop up > > In Emacs I can do > > M-x info > > but then I find myself in a general page, a sort of index and I have to > search through it in order to find the guix "link" > > How can I end up in the Guix manual front page directly even when using > Emacs ? Not directly answering your question, but from the Directory node (the so-called general page), use press `m' then "guix RET". Also, you can bind a key to a command that directly does (info "(guix)"): (global-set-key (kbd "") (lambda () (interactive) (info "(guix)"))) Regards, -- Nicolas Goaziou0x80A93738
