Re: failing packages

[Federico Beffa <beffa@ieee.org>]

Looking further: A macro was removed from TeXLive 2015 because of a
license problem.

I've pushed a fix to generate the fastcap documentation using a different macro.

Regards,
Fede

On Sat, Oct 17, 2015 at 5:20 PM, Federico Beffa <beffa@ieee.org> wrote:
> The problem appears to be with TeXLive 2015 and its 'dvips' command
> being unable to handle some .ps files:
> https://www.tug.org/pipermail/tex-live/2015-June/037013.html
>
> Could you please look into this?
>
> Thanks,
> Fede
>
> On Sat, Oct 17, 2015 at 1:14 PM, Federico Beffa <beffa@ieee.org> wrote:
>> Andreas Enge <andreas@enge.fr> writes:
>>
>>> On Tue, Oct 06, 2015 at 12:48:12PM +0300, Efraim Flashner wrote:
>>>> chicken:
>>>> guix refresh -l chicken: no dependant packages.
>>>> Has not built successfully since early May.
>>>> x86_64: http://hydra.gnu.org/build/701776/nixlog/1 (~1900 lines) runtime tests
>>>> timed out
>>>> armhf: http://hydra.gnu.org/build/701673/nixlog/1 (~4300 lines) tests pass
>>>> (including runtime tests) until ports test
>>>> Error: (line 294) invalid escape-sequence '\x o' => Embedded NUL bytes in
>>>> filenames are rejected.
>>>> mips64el: http://hydra.gnu.org/build/699177/nixlog/1 same as arm
>>>> i686: http://hydra.gnu.org/build/698575/nixlog/1 same as x86_64
>>>
>>> Should we simply drop this? Or would someone like to try an update to the
>>> most recent version 4.10.0?
>>>
>>>> fastcap:
>>>> fails on all hardware targets.
>>>> has not built successfully since August 1st.
>>>
>>> Does the software really date from 1992 as the filename suggests?!
>>> Here only the documentation does not build; maybe the fix-doc phase should
>>> be modified? Is anybody interested in the package, or should we drop it?
>>
>> Yes, the software dates 1992 and works great. Electromagnetism has not
>> changed since then.
>>
>> Why would you want to drop it? The documentation was broken by the
>> last texlive update, it didn't break by itself. It's just a matter to
>> fix some LaTeX macro.
>>
>> Dropping the documentation is a bad idea, because without it, you will
>> not know how to use this complex piece of software.
>>
>> I will look into fixing the documentation of this package.
>>
>> Regards,
>> Fede