11:20 a.m.
I have been working on an update for coq 8.9.0 in Rawhide. A mock
build fails when building the documentation:
Latexmk: applying rule 'makeindex CoqRefMan.idx'...
------------
Running 'internal xindy -L english -C utf8 -M sphinx.xdy -o
"CoqRefMan.ind" "CoqRefMan.idx"'
------------
Latexmk: calling xindy( -L english -C utf8 -M sphinx.xdy -o
"CoqRefMan.ind" "CoqRefMan.idx" )
Can't exec "xindy": No such file or directory at (eval 12) line 14.
The dependency on xindy comes from Sphinx. Take a look at
%{python3_sitelib}/sphinx/texinputs/latexmkrc_t, which is used to
create the latexmkrc for coq that refers to xindy.
As I understand it from looking through bugzilla, the texlive-xindy
package was dropped because it frequently failed to build.
So what is the right thing to do here? Try to debug the xindy
problems so the texlive-xindy package can be resurrected? Disable
xindy support in python-sphinx (if possible)?
--
Jerry James
http://www.jamezone.org/
5:13 a.m.
On 13. 03. 19 17:20, Jerry James wrote:
I have been working on an update for coq 8.9.0 in Rawhide. A mock
build fails when building the documentation:
Latexmk: applying rule 'makeindex CoqRefMan.idx'...
------------
Running 'internal xindy -L english -C utf8 -M sphinx.xdy -o
"CoqRefMan.ind" "CoqRefMan.idx"'
------------
Latexmk: calling xindy( -L english -C utf8 -M sphinx.xdy -o
"CoqRefMan.ind" "CoqRefMan.idx" )
Can't exec "xindy": No such file or directory at (eval 12) line 14.
The dependency on xindy comes from Sphinx. Take a look at
%{python3_sitelib}/sphinx/texinputs/latexmkrc_t, which is used to
create the latexmkrc for coq that refers to xindy.
There should be a configuration option that disbales xindly. Does the
documentation build with it?
latex_use_xindy = False # put it in doc/conf.py or similar
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:17 a.m.
>>>> "MH" == Miro Hrončok
<mhroncok(a)redhat.com> writes:
MH> There should be a configuration option that disbales xindly. Does
MH> the documentation build with it?
Since xindy isn't really something that can be relied upon, is it
possible (or reasonable) to do this globally in our sphinx packages?
Even when it was enabled, it was architecture-limited which would
force that limitation to propagate down to potentially anything that
used sphinx. (xindy is written in LISP and builds with clisp. There's
a certain irony in that Jerry is also a maintainer of clisp.)
I do think that the disabling of xindy was supposed to be only temporary
so I think it could be re-enabled, but having it off probably makes
texlive maintenance easier. The proper solution, I guess, is to fix
clisp to work on s390x and then fix whatever issues prevent xindy from
being enabled all the time. I think it would help to remove it from
texlive-base entirely and let it stand on its own. That way issues with
it wouldn't prevent texlive-base from building.
- J<
10:47 a.m.
On 14. 03. 19 16:17, Jason L Tibbitts III wrote:
>>>>> "MH" == Miro Hrončok
<mhroncok(a)redhat.com> writes:
MH> There should be a configuration option that disbales xindly. Does
MH> the documentation build with it?
Since xindy isn't really something that can be relied upon, is it
possible (or reasonable) to do this globally in our sphinx packages?
I don't think that we build much TeX documentation in our packages.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:51 p.m.
On Thu, Mar 14, 2019 at 9:48 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
I don't think that we build much TeX documentation in our
packages.
I think you mean that the packages you maintain don't build much TeX
documentation. :-) I tend a LOT of packages that use (La)TeX, either
directly or indirectly. I've got two packages, coq and gap, that have
extensive documentation systems that use TeX under the hood, so that
propagates down to every package that depends on them. In my world,
TeX is essential and extensively used.
--
Jerry James
http://www.jamezone.org/
1:47 a.m.
On 15. 03. 19 3:51, Jerry James wrote:
On Thu, Mar 14, 2019 at 9:48 AM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
> I don't think that we build much TeX documentation in our packages.
I think you mean that the packages you maintain don't build much TeX
documentation. :-) I tend a LOT of packages that use (La)TeX, either
directly or indirectly. I've got two packages, coq and gap, that have
extensive documentation systems that use TeX under the hood, so that
propagates down to every package that depends on them. In my world,
TeX is essential and extensively used.
Well I meant TeX docs with Sphinx.
But obviously even that could be wrong, that's why I've used the words
"think"
and "much".
If you think exploring disabling xindy globally in our sphinx package is worth
it, let me know.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:55 p.m.
On Fri, Mar 15, 2019 at 12:48 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Well I meant TeX docs with Sphinx.
But obviously even that could be wrong, that's why I've used the words
"think"
and "much".
Ah, sorry for the misread. No, I think you are correct. Sphinx seems
to be used mostly to build HTML documentation.
If you think exploring disabling xindy globally in our sphinx package
is worth
it, let me know.
Let's first see if we can fix it to be reliable.
--
Jerry James
http://www.jamezone.org/
9:49 p.m.
On Thu, Mar 14, 2019 at 9:18 AM Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
Since xindy isn't really something that can be relied upon, is
it
possible (or reasonable) to do this globally in our sphinx packages?
Even when it was enabled, it was architecture-limited which would
force that limitation to propagate down to potentially anything that
used sphinx. (xindy is written in LISP and builds with clisp. There's
a certain irony in that Jerry is also a maintainer of clisp.)
Yes, I am, and nobody ever mentioned xindy problems to me. There were
no bugs filed against clisp, no email messages to me, nothing. If I'd
known about these problems, I would have helped look into them.
I do think that the disabling of xindy was supposed to be only
temporary
so I think it could be re-enabled, but having it off probably makes
texlive maintenance easier. The proper solution, I guess, is to fix
clisp to work on s390x and then fix whatever issues prevent xindy from
being enabled all the time. I think it would help to remove it from
texlive-base entirely and let it stand on its own. That way issues with
it wouldn't prevent texlive-base from building.
The clisp issue with s390x has been on my TODO list for a long time.
I've been using most of my Fedora time to hunt down bugs that keep
other packages from building at all. I seem to be reaching the end of
that, at last, so I'll try to figure this out next.
--
Jerry James
http://www.jamezone.org/
10:54 p.m.
On Thu, Mar 14, 2019 at 8:49 PM Jerry James <loganjerry(a)gmail.com> wrote:
The clisp issue with s390x has been on my TODO list for a long time.
I've been using most of my Fedora time to hunt down bugs that keep
other packages from building at all. I seem to be reaching the end of
that, at last, so I'll try to figure this out next.
This appears to be caused by the clisp code incorrectly pairing
register and volatile. Still, I find gcc's behavior surprising, which
is why I filed https://bugzilla.redhat.com/show_bug.cgi?id=1689769.
That may very well be closed as NOTABUG, but I would like the gcc
maintainers' input.
I'll work up a patch for clisp, and then we can try building xindy again.
--
Jerry James
http://www.jamezone.org/
10:36 p.m.
On Sun, Mar 17, 2019 at 9:54 PM Jerry James <loganjerry(a)gmail.com> wrote:
This appears to be caused by the clisp code incorrectly pairing
register and volatile. Still, I find gcc's behavior surprising, which
is why I filed https://bugzilla.redhat.com/show_bug.cgi?id=1689769.
That may very well be closed as NOTABUG, but I would like the gcc
maintainers' input.
That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
Sadly, the clisp build is still failing in Rawhide, with failures in
the socket tests:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33879684
An obvious endianness problem, right? Except that the build
*succeeds* when I run it in mock on actual s390x hardware (thanks to
Dan for the account). This has been happening for a couple of days,
across a Rawhide compose.
So now I've got two Lisp implementations, gcl and clisp, that build
successfully in mock and fail to build in koji (for completely
different reasons). I'm traveling for a few days, so figuring this
out will have to wait until I get back. The lack of visibility into
koji is pretty frustrating, though.
--
Jerry James
http://www.jamezone.org/
9:57 a.m.
On Mon, Apr 1, 2019 at 9:36 PM Jerry James <loganjerry(a)gmail.com> wrote:
That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
Sadly, the clisp build is still failing in Rawhide, with failures in
the socket tests:
The failing test attempts to bind to localhost:9090. Apparently
something on the s390x koji builders binds that port. The test is
arguably broken; it should iterate over successive port numbers until
if finds one that is available, rather than picking a single port
number and failing if that port is unavailable. Anyway, I "fixed" it
for now by choosing a different port number. I'll ask upstream to
really fix it.
So clisp has been built for all architectures in Rawhide now. I
cannot build it for F30 yet, because the version of gcc with the s390x
fix has not yet been submitted as an update. Regardless, can somebody
who knows how to build xindy try it in Rawhide and let me know if
there are problems doing so? Or give me instructions on how to build
it myself? Thanks,
--
Jerry James
http://www.jamezone.org/
5:35 p.m.
On Mon, Apr 08, 2019 at 08:57:22AM -0600, Jerry James wrote:
On Mon, Apr 1, 2019 at 9:36 PM Jerry James
<loganjerry(a)gmail.com> wrote:
> That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
> Sadly, the clisp build is still failing in Rawhide, with failures in
> the socket tests:
The failing test attempts to bind to localhost:9090. Apparently
FYI port 9090 is used by cockpit.
--
Brian C. Lane (PST8PDT)
12:46 a.m.
On Mon, Apr 8, 2019 at 4:58 PM Jerry James <loganjerry(a)gmail.com> wrote:
On Mon, Apr 1, 2019 at 9:36 PM Jerry James <loganjerry(a)gmail.com> wrote:
> That was, in fact, an s390x-specific gcc bug, now fixed in Rawhide.
> Sadly, the clisp build is still failing in Rawhide, with failures in
> the socket tests:
The failing test attempts to bind to localhost:9090. Apparently
something on the s390x koji builders binds that port. The test is
arguably broken; it should iterate over successive port numbers until
if finds one that is available, rather than picking a single port
number and failing if that port is unavailable.
No, for that you should bind port zero instead to get a random one in
a race-free manner (e.g. parallel execution of multiple tests for
example).
Dridi
10:02 p.m.
On Tue, Apr 9, 2019 at 11:47 PM Dridi Boukelmoune
<dridi.boukelmoune(a)gmail.com> wrote:
No, for that you should bind port zero instead to get a random one
in
a race-free manner (e.g. parallel execution of multiple tests for
example).
Ah, thanks. I didn't know about the port zero trick. I'll suggest
that to upstream.
--
Jerry James
http://www.jamezone.org/
10:04 p.m.
On Mon, Apr 8, 2019 at 8:57 AM Jerry James <loganjerry(a)gmail.com> wrote:
So clisp has been built for all architectures in Rawhide now. I
cannot build it for F30 yet, because the version of gcc with the s390x
fix has not yet been submitted as an update. Regardless, can somebody
who knows how to build xindy try it in Rawhide and let me know if
there are problems doing so? Or give me instructions on how to build
it myself? Thanks,
Somebody out there has been involved with past attempts to build
xindy. Please, I would like to make progress on this so I can get
back to building the coq stack's new versions. Which package used to
contain xindy? How does one attempt to build it? I would like to see
if there are still build issues with the new clisp.
Thank you,
--
Jerry James
http://www.jamezone.org/
9:41 p.m.
On Thu, Apr 11, 2019 at 9:04 PM Jerry James <loganjerry(a)gmail.com> wrote:
On Mon, Apr 8, 2019 at 8:57 AM Jerry James <loganjerry(a)gmail.com> wrote:
> So clisp has been built for all architectures in Rawhide now. I
> cannot build it for F30 yet, because the version of gcc with the s390x
> fix has not yet been submitted as an update. Regardless, can somebody
> who knows how to build xindy try it in Rawhide and let me know if
> there are problems doing so? Or give me instructions on how to build
> it myself? Thanks,
Somebody out there has been involved with past attempts to build
xindy. Please, I would like to make progress on this so I can get
back to building the coq stack's new versions. Which package used to
contain xindy? How does one attempt to build it? I would like to see
if there are still build issues with the new clisp.
Anybody? Anybody? Bueller?
--
Jerry James
http://www.jamezone.org/
1:18 p.m.
>>>> "JJ" == Jerry James
<loganjerry(a)gmail.com> writes:
JJ> Somebody out there has been involved with past attempts to build
JJ> xindy. Please, I would like to make progress on this so I can get
JJ> back to building the coq stack's new versions. Which package used
JJ> to contain xindy?
It is/was part of texlive-base. Look at line 20 of the texlive-base
spec:
# Not ppc64, not s390x, not aarch64 due to lack of clisp
# code SIGSEGV's on armv7hl
%global xindy_arches empty
JJ> How does one attempt to build it?
Just set that define appropriately. It was disabled in
ac0adc86c6ee1f2559e4313f210b828778388999 because I guess there's some
sort of circular build dependency and I guess it never got turned back
on again. Before that it was set to:
%global xindy_arches %{ix86} x86_64
And before acf14dee9c90d6f8b775adc0c1c5151d7df28642 that included arm:
%global xindy_arches %{arm} %{ix86} x86_64
To go back further you have to go back to the texlive package before
-base was split out.
My suggestion? Package it as an entirely separate package to avoid any
kind of circular build dependency. Call it xindy or texlive-xindy; I've
no preference.
- J<
9:45 p.m.
On Thu, Mar 14, 2019 at 4:13 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
There should be a configuration option that disbales xindly. Does
the
documentation build with it?
latex_use_xindy = False # put it in doc/conf.py or similar
I've got to figure out where to put that option. Coq has its own
documentation builder, coqdoc, so this option will have to be inserted
into it somewhere, I guess. I'll try to figure it out tomorrow.
--
Jerry James
http://www.jamezone.org/
1834
days inactive
1869
days old
17 comments
5 participants
participants (5)
-
Brian C. Lane -
Dridi Boukelmoune -
Jason L Tibbitts III -
Jerry James -
Miro Hrončok