Summary: | app-text/xindy keyword request (will be needed for texlive 2008) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexis Ballier <aballier> |
Component: | Current packages | Assignee: | TeX project <tex> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bsd+disabled, common-lisp, ppc64, ppc, sparc |
Priority: | High | Keywords: | KEYWORDREQ |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 196176, 230035 | ||
Bug Blocks: | 237202 |
Description
Alexis Ballier
2008-06-24 15:00:36 UTC
xindy has RDEPEND=" ... >=dev-lisp/clisp-2.44.1-r1 ..." This is a problem for sparc: clisp is '-sparc' because it will not build at all on sparc. For us to proceed, xindy needs an alternate version of lisp (sbcl is good on sparc, for example). I'll leave sparc in CC list so that you can respond. (In reply to comment #1) > xindy has > RDEPEND=" ... >=dev-lisp/clisp-2.44.1-r1 ..." > This is a problem for sparc: clisp is '-sparc' because it will not build at > all on sparc. For us to proceed, xindy needs an alternate version of lisp > (sbcl is good on sparc, for example). The problem is xindy really needs clisp (or that I don't know how to make it use sbcl) :( It builds a clisp module if I remember correctly; the common-lisp people are probably much wiser than me on that side. wrt the >= dep, that's because there was a "bug" in previous clisp ebuilds that allowed portage to strip objects needed to build a module and then the objects became unusable (for some reason some symbols got removed while they are needed when building a module against it). I was expecting such problems, that's why I suggested it will be possible to use.mask it. clisp fails on alpha and ia64, and probably on hppa too(didn't try). However debian uses some flags to skip those failures(related with mmap stuff). And on sparc...debian doesn't have it keyworded, i don't remember exactly what i did, but i got it complaining about some c file missing. Will have a look when i have it fixed for the first two arches. ~alpha/~ia64 done dev-lisp/clisp won't build on HPPA either. For sparc, this is a problem. It looks like dev-lisp/clisp is required for xindy. However, on sparc clisp is marked '-sparc' because last I knew, it would not build at all. Perhaps someone else has better information about clisp, but last time I tried to build it, the failures were fundamental (assembly code related, I think). The app-text/texlive:xindy USE flag is now package.use.masked for HPPA. (In reply to comment #6) > For sparc, this is a problem. It looks like dev-lisp/clisp is required for > xindy. However, on sparc clisp is marked '-sparc' because last I knew, it > would not build at all. Perhaps someone else has better information about > clisp, but last time I tried to build it, the failures were fundamental > (assembly code related, I think). > clisp won't build because of a sparc/sparc64 confusion in arch detection. If you force it to build, it will not run at all. So xindy is really not an option for sparc unless it can use some other lisp interpreter instead. maybe we could close this one as fixed now that it's masked where chances are low that it can run ? (In reply to comment #9) > maybe we could close this one as fixed now that it's masked where chances are > low that it can run ? > From sparc's point of view, it can be closed. Chances are 0 that it will run unless either (1) upstream fixes clisp for sparc/linux, or (2) xindy learns how to use a different lisp interpreter, like sbcl. closing then ppc is done clisp doesn't build on ppc64 afaik bsd has issues with bsdmake + the way clisp builds its modules, i'll try to get that fixed someday... |