Am Wed, Jan 22, 2025 at 04:20:01PM +0100 schrieb Nicolas Goaziou:
> > I have a local copy of the 4GB file texlive-20240312-texmf.tar.xz in my
> > home directory, which I put into the store with "guix download".
> That’s tantamount to cheating! It is smart, but since G
Hello,
Andreas Enge writes:
> My workflow when updating Guix is as follows:
> I have a local copy of the 4GB file texlive-20240312-texmf.tar.xz in my
> home directory, which I put into the store with "guix download". Then
> "guix shell -D texlive" creates the te
about the
> comparison between using `texlive' and `texlive-scheme-full', as
> I believe the latter can satisfy that user profile.
these are interesting questions, and I thought I would give it a try
again.
My workflow when updating Guix is as follows:
I have a local copy of the 4GB file texl
Hello,
Felix Lechner via "Development of GNU Guix and the GNU System
distribution." writes:
> Thanks for that analysis! I had the innocuous-looking 'texlive' in my
> Guix Home profile. That package pulls in texlivetexmf-${date}. [1] Was
> that my error?
No, it
Hi Nicolas,
On Fri, Jan 10 2025, Nicolas Goaziou wrote:
> don’t need every package in there
Thanks for that analysis! I had the innocuous-looking 'texlive' in my
Guix Home profile. That package pulls in texlivetexmf-${date}. [1] Was
that my error?
Kind regards
Felix
P.S.
ck in the days, it
was the only way to get a proper TeX Live experience within Guix.
It is not the case anymore. However, Andreas Enge (Cc’ed) prefers to
keep it as a no-brainer for anyone who wants to compile TeX documents
and can afford the download cost. I’d love to get feedback about the
compar
Hi Nicolas,
On Sat, Oct 26 2024, Nicolas Goaziou via "Development of GNU Guix and the GNU
System distribution." wrote:
> What TexLive are you talking about?
I am talking about 'texlivetexmf-20240312'.
While I'm lucky that there is a substitute, I can hardly use
Hello,
Felix Lechner writes:
> Should updates to TexLive or its prerequisites fall under the
> core-updates policy (or whatever its successor is)?
>
> My Guix is heavily modified and building TexLive takes an hour and a
> half. Grafting it takes nearly as long. Thanks!
What
Hi,
Should updates to TexLive or its prerequisites fall under the
core-updates policy (or whatever its successor is)?
My Guix is heavily modified and building TexLive takes an hour and a
half. Grafting it takes nearly as long. Thanks!
Kind regards
Felix
Nicolas Goaziou writes:
>>> 2. Some affected packages are also missing propagated inputs (e.g.,
>>>texlive-latex-graphics for texlive-latex-fncychap);
>>
>> Correct. The old importer didn’t know about dependencies. The newer
>> importer uses tlpdb to g
Am Wed, Apr 19, 2023 at 01:47:16PM +0200 schrieb Nicolas Goaziou:
> AFAIU, this is not sufficient. All dependencies do not appear in
> "texlive.tlpbd". For example, `texlive-halloweenmath' has no "depend"
> entry in the tlpbd. Yet, it requires both texlive
e on the same length.
However, some packages do use "#:trivial #t" even though they should
not, e.g., `texlive-latex-marginfix'. My point is that we should not
make "#:trivial #t" the default, assuming that was a possibility
stemming from Simon's question.
>>
Nicolas Goaziou writes:
> Hello,
>
> Simon Tournier writes:
>
>> Other said, any objection to go from this pattern:
>>
>> --8<---cut here---start----->8---
>> (define-public texlive-foo
>> (package
>>
Hello,
Simon Tournier writes:
> Other said, any objection to go from this pattern:
>
> --8<---cut here---start->8---
> (define-public texlive-foo
> (package
> (name "texlive-foo")
> (version (number->string %
the way we are packaging
TeX, quoting Nicolas from [2]:
There are two approaches going on here. `simple-texlive-package' tries
to provide a tessellation of the full texlive, i.e., if you install
(assuming they are defined in Guix) every standalone texlive pa
Hi jgart,
After using LaTeX recently too, I think you don't need texlive-bin, but
rather texlive-base. You can use the example in the manual to
bootstrap.
Best,
--
Josselin Poiret
Hi, after installing texlive-bin I get the following error:
Error: I can't find the format file pdflatex.fmt
This SO says to do the following
sudo texconfig rehash
https://tex.stackexchange.com/questions/64894/error-i-cant-find-the-format-file-pdflatex-fmt
Which sound like it might b
Hello,
The texlive-polyglossia is no longer empty, and works, at least with
XeLaTeX. You can see it in action building the doc of our
'python-ipython-documentation' package.
Closing!
Thanks,
Maxim
Hi Tim,
On Fri, 04 Feb 2022 at 23:20, Timothy Sample wrote:
> Yes. I could add that commit to the database, evaluate it, and load all
> the sources. I’m inclined not to, but I’m open to being convinced. (I
> really like how simple the current system is conceptually.)
I understand. Especiall
Hi,
zimoun writes:
> On Thu, 03 Feb 2022 at 10:46, Timothy Sample wrote:
>
>> The bad news is that 0.75 is not there. At first I was going to
>> apologize for the shortcomings of the sampling approach... until I
>> realized you are trying to trick me! ;) Unless I’m misreading the Git
>> hist
one missing patch–as Maxime pointed it–is there:
https://github.com/archlinux/svntogit-packages/blob/155510dd18d2f290085f40d2a95a3701db4a224d/texlive-bin/repos/extra-x86_64/pdftex-poppler0.75.patch
And SWH contains it:
https://archive.softwareheritage.org/browse/revision/155510dd18d2f290085f40d2a95a370
Hi zimoun,
zimoun writes:
> But the question is if Disarchive dissambles and preserves external
> patches. Timothy?
I have good news and bad news. :)
The good news is that some versions of this patch are in the PoG
database. There’s two versions of 0.76 and one of 0.72. Of those
three, onl
Hi Maxime,
Thanks for the pointer.
On Wed, 2 Feb 2022 at 23:57, Maxime Devos wrote:
>
> zimoun schreef op wo 02-02-2022 om 19:42 [+0100]:
> > 2. How to preserve such patches? Other said, are they part of the
> > Disarchive machinery? For now, some patches are probably missed by
> > sources
zimoun schreef op wo 02-02-2022 om 19:42 [+0100]:
> 2. How to preserve such patches? Other said, are they part of the
> Disarchive machinery? For now, some patches are probably missed by
> sources.json and thus not ingested by SWH.
Can we tell SWH to ingest svntogit-packages, in such a way th
$ guix download texlive-bin/repos/extra-x86_64/pdftex-poppler0.75.patch
/gnu/store/fbvknc65339dnf89aljz8wkbnnms7ydp-pdftex-poppler0.75.patch
1cqpcp7h1qyxyp3wjbpcmx2wgvj9ywpz60hvy280mp9w633yzyg3
^ this is the expected hash!
Greetings,
Maxime.
commit 67290f70d8143b18f24ffd6a1827def9bdc21108
Autho
zimoun schreef op wo 02-02-2022 om 19:42 [+0100]:
> [...]
>
> This asks two questions:
>
> 1. How to get now this patch? Someone? Or is it lost forever?
> 2. How to preserve such patches? Other said, are they part of the
> Disarchive machinery? For now, some patches are probably missed by
ws21jmmcsgnc6wnz5ik7-profile.drv
/gnu/store/d7q819gh181gfv3hk4v38g2c1gq5vfgp-guix-e77412362.drv
[...]
building
/gnu/store/50ib3szgx1h0dyk9rifpsbris7yafgzd-texlive-bin-pdftex-poppler0.75.patch.drv...
\sha256 hash mismatch for
/gnu/store/7c5jx9zbnh8nlapbxqv1wl8056lhhl2l-texlive
On +2021-07-06 15:28:43 -0300, Nathan Benedetto Proença wrote:
> Bengt Richter writes:
>
> > Hi Nathan,
> > Nice writeup!
>
> Thank you!
>
> > On +2021-07-05 11:03:46 -0300, Nathan Benedetto Proença wrote:
> >> Hello!
> >>
> >> I
Thank you Xinglu for letting me know of Thiago's efforts.
And thank you Thiago for your work!
Thiago Jung Bauermann writes:
> Hello,
>
> Em segunda-feira, 5 de julho de 2021, às 14:09:24 -03, Xinglu Chen
> escreveu:
>> FYI, someone else is already workin on upgrading
Bengt Richter writes:
> Hi Nathan,
> Nice writeup!
Thank you!
> On +2021-07-05 11:03:46 -0300, Nathan Benedetto Proença wrote:
>> Hello!
>>
>> I am trying to upgrade the package texlive, first for me, but hopefully
>> for a patch, and I have a question regar
Hi Nathan,
Nice writeup!
On +2021-07-05 11:03:46 -0300, Nathan Benedetto Proença wrote:
> Hello!
>
> I am trying to upgrade the package texlive, first for me, but hopefully
> for a patch, and I have a question regarding Guix policies.
>
> As you can see o
Hello,
Em segunda-feira, 5 de julho de 2021, às 14:09:24 -03, Xinglu Chen
escreveu:
> FYI, someone else is already workin on upgrading Texlive to 2021 on the
> ‘core-updates’ branch (Texlive is already at 2020 on core-updates).
>
> <https://issues.guix.gnu.org/49408>
>
FYI, someone else is already workin on upgrading Texlive to 2021 on the
‘core-updates’ branch (Texlive is already at 2020 on core-updates).
<https://issues.guix.gnu.org/49408>
Maybe you would be interested in helping out?
Hello!
I am trying to upgrade the package texlive, first for me, but hopefully
for a patch, and I have a question regarding Guix policies.
As you can see on
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/texlive.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68
the file
FTP site – and
> > subversion tag texlive-2021.3 – the latest tag in the TeX Live repo.
> >
> > Unfortunately issue 48064¹ still happens. On the bright side, I found a
> > workaround for it that also works with TeX Live 2020 currently in core-
> > updates I will su
;
>> Thank you for having a look! I will certainly submit themt o Guix when I
>> manage to get a working build of TeX Live 2021.
>
> I was able to build the main TeX Live packages with source tarball version
> 20210325 – the latest on the historic TeX Live FTP site – and subversio
ild of TeX Live 2021.
I was able to build the main TeX Live packages with source tarball version
20210325 – the latest on the historic TeX Live FTP site – and subversion
tag texlive-2021.3 – the latest tag in the TeX Live repo.
Unfortunately issue 48064¹ still happens. On the bright side, I
Hi Maxim,
Em sexta-feira, 25 de junho de 2021, às 00:34:23 -03, Maxim Cournoyer
escreveu:
> Thiago Jung Bauermann writes:
> > It’s possible to build texlive-latex-l3kernel with IniTeX (i.e., by
> > calling `pdftex -ini` or `tex -ini`) and docstrip, without any format
> > l
; It’s possible to build texlive-latex-l3kernel with IniTeX (i.e., by calling
> `pdftex -ini` or `tex -ini`) and docstrip, without any format loaded.
It was worth it to ask :-).
> So I made some changes to texlive-build-system to that, and it worked. By
> which I mean: the texlive-latex
eveu:
> >> Does anyone have an idea how to break this dependency loop? Do we need
> >> to have a package definition for a pre-2019-10 version of LaTeX just
> >> to build texlive-latex-l3kernel, and then use that as a dependency
> >> for the actual texlive-latex-bas
version of LaTeX just to
>> build texlive-latex-l3kernel, and then use that as a dependency for the
>> actual texlive-latex-base package?
>
> I’m pursuing this option. I took the definition of texlive-latex-base from
> the master branch (which doesn’t depend on LaTeX3) and added it
Hello,
Em terça-feira, 15 de junho de 2021, às 16:00:51 -03, Thiago Jung Bauermann
escreveu:
> Does anyone have an idea how to break this dependency loop? Do we need to
> have a package definition for a pre-2019-10 version of LaTeX just to
> build texlive-latex-l3kernel, and then use
Hello,
In an attempt to verify whether bug 48064¹ (”texlive-* packages fail to
build non-deterministically”) is fixed by the current TeX Live version, I’ve
been working on updating it to version 2021.1².
Unfortunately I ran into a bootstrapping issue: texlive-latex-base now
depends on texlive
Hello Ricardo,
I've a huge backlog of messages from guix, I've read this thread today
and I just want to say: thank you so much for your work on this!!!
I don't (still) know if this work on modular texlive is done or not,
anyway you solved a lot of issues and - as we can see - te
c/cp227"
>> + (assoc-ref inputs "texlive-kpathsea")
>
> Woow, thumbs up. Not something one could have guessed!
Hah, when I originally added the code to build the fmt files this
problem did stick out to me, but I thought it would be solved
Hi!
Ricardo Wurmus skribis:
> This patch fixes it:
[...]
> + (("translate-file=cp227")
> + (format #f
> "translate-file=~a/share/texmf-dist/web2c/cp227"
> + (assoc-ref inputs "texli
> This is the relevant line from fmtutil.cfg:
>
> pdftex pdftex language.def -translate-file=cp227.tcx *pdfetex.ini
This patch fixes it:
>From a1e4825c71308b40a0a250cdddbabf2cf534c5a0 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus
Date: Sun, 25 Oct 2020 12:01:09 +0100
Subject: [
zimoun writes:
> On Thu, 22 Oct 2020 at 22:35, Ricardo Wurmus wrote:
>
>> So the next step for me is to figure out how I can make pdftex find
>> cp227.tcx.
>
> Adding 'texlive-kpathsea' in the default packages of 'texlive-base' or
> in the '
On Thu, 22 Oct 2020 at 22:35, Ricardo Wurmus wrote:
> So the next step for me is to figure out how I can make pdftex find
> cp227.tcx.
Adding 'texlive-kpathsea' in the default packages of 'texlive-base' or
in the 'texlive-union', is it not enough?
On Thu, 22 Oct 2020 at 22:35, Ricardo Wurmus wrote:
> “warning: Could not open char translation file `cp227.tcx'.” – Oh? It’s
> in the union, but maybe a search path in the configuration file is
> misconfigured.
Oh! Looks like a good clue.
On Thu, 22 Oct 2020 at 22:26, Ricardo Wurmus wrote:
> > I am totally naive here. Is it not one of these disabled formats
> > which should not be?
>
> No, the pdftex formats are:
Ok. I am really dumb here. That was just because the 'pdftex' engine
appears a couple of times, which is not the ca
ex pdftex language.def -translate-file=cp227.tcx *pdfetex.ini
Here’s output from building pdftex.fmt (from the build log of
texlive-latex-base):
--8<---cut here---start->8---
fmtutil [INFO]: --- remaking pdftex with pdftex
fmtutil: running `pdftex -ini -jobname=p
zimoun writes:
> On Thu, 22 Oct 2020 at 21:51, Ricardo Wurmus wrote:
>
>> ;; XXX: We can't build all formats at this point, nor are
>> they
>> ;; part of the LaTeX base, so we disable them. Actually, we
>> ;; should be running this all in a
Hi Ricardo,
Thank you so much for the detailed step by step progress and the deep
investigation.
On Thu, 22 Oct 2020 at 21:51, Ricardo Wurmus wrote:
> ;; XXX: We can't build all formats at this point, nor are
> they
> ;; part of the LaTeX base, so we disable t
Ricardo Wurmus writes:
> 2) we aren’t using XeTeX or LuaTeX with the monolithic “texlive”
> package, so why does pdfTeX behave differently here? I see in the logs
> that the date of the format file differs — does this indicate that our
> pdfTeX format file is wrong? I will com
haracter: There is no ^^a4 in font cmr10!
>>
>> I’m not sure this is correct, because it seems to me that “^^c3” is only
>> part of a longer multi-byte sequence, but this error indicates that
>> individual bytes are looked up in the font.
>
> With the full “texlive
at “^^c3” is only
> part of a longer multi-byte sequence, but this error indicates that
> individual bytes are looked up in the font.
With the full “texlive” package I also see “not defined for Texinfo” in
the logs, but the characters use octal notation instead of double caret
notation. The g
Ludovic Courtès writes:
> Ricardo Wurmus skribis:
>
>> I can now build the French and the German manuals in this environment:
>>
>> guix environment --pure guix --ad-hoc -e '(begin (use-modules (gnu
>> packages tex))(texlive-union (list texlive-epsf te
Hi,
Ricardo Wurmus skribis:
> I can now build the French and the German manuals in this environment:
>
> guix environment --pure guix --ad-hoc -e '(begin (use-modules (gnu
> packages tex))(texlive-union (list texlive-epsf texlive-fonts-ec
> texlive-amsfonts
zimoun writes:
> Hi Ricardo,
>
> On Sat, 17 Oct 2020 at 23:55, Ricardo Wurmus wrote:
>
>> It’s almost certainly due to configuration of the modular texlive.
>> We’re generating a whole bunch of font map files and encoding files
>> already, but something s
Hi Ricardo,
On Sat, 17 Oct 2020 at 23:55, Ricardo Wurmus wrote:
> It’s almost certainly due to configuration of the modular texlive.
> We’re generating a whole bunch of font map files and encoding files
> already, but something somewhere must still be missing.
>
> I embarked on a
cp ~/guix/doc/{guix.fr,os-*,fdl-1.3,contributing.fr,version-fr}.texi .
> cp -R ~/guix/doc/images images
> cp ~/guix/doc/environment-gdb.scm .
> cp ~/guix/doc/package-hello.{scm,json} .
>
> guix environment guix -C \
> --ad-hoc texlive-base texlive-fonts-ec texlive-epsf texlive-tex-
Hi Ricardo,
Thank you for looking at this.
On Fri, 16 Oct 2020 at 22:10, Ricardo Wurmus wrote:
> I can now build the French and the German manuals in this environment:
>
> guix environment --pure guix --ad-hoc -e '(begin (use-modules (gnu
> packages tex))(texlive-union (
Ricardo Wurmus writes:
> zimoun writes:
>
>> Currently it is not easy to produce the PDF of the manual. For
>> reference, see [1]. There are 2 issues:
>>
>> a) the ’texlive’ package.
>> b) the fonts about Russian or Chinese.
>>
>> About t
zimoun writes:
> Currently it is not easy to produce the PDF of the manual. For
> reference, see [1]. There are 2 issues:
>
> a) the ’texlive’ package.
> b) the fonts about Russian or Chinese.
>
> About the a), it is really painful to download the *big* texlive pa
Dear,
Currently it is not easy to produce the PDF of the manual. For
reference, see [1]. There are 2 issues:
a) the ’texlive’ package.
b) the fonts about Russian or Chinese.
About the a), it is really painful to download the *big* texlive package
to be able to compile TeX. Especially when
Hi Ricardo, Hi John,
> Looks good to me. Please push!
Cheers!
Pushed as 735808b12cc23909b421e10e212a07e7aa69a5eb
Best regards,
Paul.
Hi Paul,
> Ok, I have found a fix.
[…]
> The effect is to add a subdirectory to the temporary directory. This
> is used as the target to download the files to. It does not exist
> until created by the 'svn export' command.
Interesting! I think I added this back then and at some point it used
Nice work!
That bug has been around for years I think.
Thanks!
John
Hi Guix,
Ok, I have found a fix.
It turns out that the 'svn export' command throws an error if the
target directory already exists.
Initially I set the 'log' argument of 'download-svn-to-store' to
'current-output-port' to see the error message from svn:
svn: E155000: Destination directory exi
Hi Guix,
I have been able to run the texlive importer after making some changes
to guix/import/texlive.scm:
@@ -148,20 +148,22 @@ expression describing it."
((lst ...) (map string->license lst
(home-page (string-append "http://www.ctan.
Hi Guix,
I have been trying to use the texlive importer to package some TeXLive
packages.
Using the example from the manual, I try:
$ guix import texlive fontspec
I get:
following redirection to `https://ctan.org/xml/1.2/pkg/fontspec'...
Backtrace:
13 (primitive-load "/usr
Hi Tobias,
On Fri, 10 Jul 2020 at 13:04, Tobias Geerinckx-Rice wrote:
> You might be happy with ‘--gc-keep-outputs’.
Thanks. Yeah it seems it is what I need. :-)
Cheers,
simon
Hi Ricardo,
On Fri, 10 Jul 2020 at 14:11, Ricardo Wurmus wrote:
> > I am often annoyed because when I run "guix upgrade", Guix
> > downloads again the heavy texlive-20190410-texmf.tar.xz
>
> could you tell us what bugs in the modular TeX Live packages make the
>
Hi simon,
> I am often annoyed because when I run "guix upgrade", Guix
> downloads again the heavy texlive-20190410-texmf.tar.xz
could you tell us what bugs in the modular TeX Live packages make the
use of the monolithic texlive package necessary?
We should aim to fix t
Simon,
zimoun 写道：
I am often annoyed because when I run "guix upgrade", Guix
downloads again the heavy texlive-20190410-texmf.tar.xz if I
have
forgotten to protect it from "guix gc" using the trick, e.g.,
https://lists.gnu.org/archive/html/help-guix/2020-02/msg00110.h
Dear,
I am often annoyed because when I run "guix upgrade", Guix
downloads again the heavy texlive-20190410-texmf.tar.xz if I have
forgotten to protect it from "guix gc" using the trick, e.g.,
https://lists.gnu.org/archive/html/help-guix/2020-02/msg00110.html
What cou
I won't have time before this weekend, so if you want to beat me to it,
that'd be fantastic! :D
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
st.ARCH, required only by
> collection-fontutils. Contains some 100s files, most of which are
> located in texmf-dist/tex/fontinst/. Our texlive-tex-fontinst-base is
> missing most of those.
>
> - fontinst.ARCH: only contains bin/ARCH/fontinst. Our texlive-bin has them.
>
> So
r TeX packages, I'm stopping
the guessing game and I've looked at tlpdb. So here is the deal:
2 packages:
- fontinst: depends on fontinst.ARCH, required only by
collection-fontutils. Contains some 100s files, most of which are
located in texmf-dist/tex/fontinst/. Our texlive-tex-f
have all
>> the \fontdimen values needed in math symbol fonts.
>
> If only I knew what this means… We could grep for these things in the
> big texlive package and then try to find the equivalent in the modular
> texlive packages.
I find a lot of “setfontdimen” instances in texmf-di
.
If only I knew what this means… We could grep for these things in the
big texlive package and then try to find the equivalent in the modular
texlive packages.
Building the right fonts and configuring them correctly has always been
a problem with the modular texlive packages.
--
Ricardo
The issue is actually much worse than that: "tabular" is broken in LaTeX! :(
Minimal example:
--8<---cut here---start->8---
\documentclass[11pt]{article}
\begin{document}
\begin{tabular}{l}
foo
\end{tabular}
\end{document}
--8<---cut here---
Asymptote fails to build. It used to be working on master 2-3 weeks ago
I think.
--8<---cut here---start->8---
starting phase `install'
...
(./asy-latex.dtx
! Math formula deleted: Insufficient symbol fonts.
\endtabular ->\crcr \egroup \egroup $
ive packages the “source” field is
> insufficient, so we add lots of additional origins as native inputs.
> This makes for very ugly package definitions. (See
> texlive-fonts-txfonts for an example.)
>
> What do you think about adding a new procedure that can fetch sources
> f
Thanks for clarifying this.
Then I 100% agree with your approach.
I should have a little bit more free time in the coming days, so I'll (finally)
get down to write the tlpdb importer :)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Pierre Neidhardt writes:
> Would that still be needed if we implement a tlpdb-based importer?
The importer only helps you generate the initial package definition.
A tlpdb-based importer cannot do magic. The tlpdb file tells it what
files are expected to be provided by the package and what fi
Hi,
Would that still be needed if we implement a tlpdb-based importer?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
, so we add lots of additional origins as native inputs.
This makes for very ugly package definitions. (See
texlive-fonts-txfonts for an example.)
What do you think about adding a new procedure that can fetch sources
from different locations? This might be done by extending SVN-FETCH or
by adding a
Done.
(Oops, missing period in the commit message... I guess I'm having a day off :p)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hello!
Pierre Neidhardt skribis:
> Yup, I went a bit out of my way here, sorry, long and painful day fighting
> TeXlive...
I can sympathize with that. :-)
> Conclusion: I'll just add a mention of TeXlive in the existing paragraph then.
Perfect, thanks! Final nitpick: for pa
o trust your judgment on this. Do as you think
best.
Thanks!
Mark
> Le 13 décembre 2018 22:20:15 GMT+01:00, Pierre Neidhardt
> a écrit :
>>Hevea and texlive are native-inputs for Coq, however they don't seem to
>>be used ever.
>>
>>https://gith
> The text looks fine but I find it a bit long and m
Yeah, it can probably be worked out a bit :p
> more importantly it
> partly duplicates an item that’s just above :-), which mentions ‘guix
> size’ but not ‘texlive’.
Just above? Do you mean this one:
--8<
Hi Pierre!
guix-comm...@gnu.org skribis:
> commit dc56dc025df0b7ea6915ad1061f8d189d641fe35
> Author: Pierre Neidhardt
> Date: Fri Dec 14 23:06:06 2018 +0100
>
> doc: Discourage the use of texlive as input
>
> * doc/contributing.texi (Submitting Patches):
They must have been useful in older versions, but I didn't pay attention. If
they are not needed for anything, please go ahead and remove them!
Thank you!
Le 13 décembre 2018 22:20:15 GMT+01:00, Pierre Neidhardt a
écrit :
>Hevea and texlive are native-inputs for Coq, however they do
Hevea and texlive are native-inputs for Coq, however they don't seem to
be used ever.
https://github.com/coq/coq/blob/V8.8.2/INSTALL does not mention them as
build dependencies either.
Shall we remove them?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Héctor from IPFS just pointed me to
https://build.opensuse.org/package/show/openSUSE%3ALeap%3A15.0/texlive-specs-a
which contains an amazing list of 2000+ TeXlive package recipes!
That could be very useful for Guix ;)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP
Hi!
On 05c62b1e1d34ec8e68de3f1d3d7a7218ef8993d7, texlive-latex-amscls-44591
initially failed to build on i686-linux on berlin (it’s an indirect
dependency of po4a, which Guix now depends on):
--8<---cut here---start->8---
starting phase `patch-generate
Ricardo Wurmus writes:
> This message seems to indicate that:
>
>> svn: E000110: Unable to connect to a repository at URL
>> 'svn://www.tug.org/texlive/tags/texlive-2017.1/Master/texmf-dist/fonts/source/jknappen/ec'
>> svn: E000110: Unknown hostname 'www.t
ate: Sun Jul 9 11:55:23 2017 +0200
>>
>> gnu: Add texlive-fonts-ec.
>>
>> * gnu/packages/tex.scm (texlive-fonts-ec): New variable.
>> ---
[…]
> When I try to update my system, I get this:
>
> --8<---cut here--
1 - 100 of 212 matches
Mail list logo
