Sorry, I forgot to subscribe to the bug and didn't see the previous comments.
I think your figure looks right to me. Many of the examples are for cellular
responses and they aren't going to look like physical waves. I've been
actively testing the package I remade and all the numerics look correct.
On Wednesday 28 February 2007 04:33, Neil Williams wrote:
> > # 64 Bit machines must use a different parser code.
> > # In the OBJECTS section, replace parser2.o with parserslow2.o
> > # it is not really that much slower so don't have a cow
> > #
> >
> > I modified the Makefile in the source package and the error
> > has gone away. Sorry I don't know patch syntax to give a patch, but
> > the change is easy.
>
> The change would be easy if packages for each architecture were built
> by hand but Debian uses automated buildd's that rely on the package
> configuring itself to handle the architecture. xppaut doesn't include
> the ./configure script that would normally take care of this which
> makes a normal patch difficult.
>
> I'm experimenting with making a copy of 'Makefile' as 'Makefile.64' and
> using a patch to debian/rules to use that Makefile when a 64bit arch is
> detected. My problem is that I now need some code to test so that I can
> determine whether the fix creates a usable binary on amd64.
>
> Added to debian/rules:12
>
> DEB_BUILD_GNU_CPU ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_CPU)
>
> # method copied from db4.2
> USE_64PARSER_CPUS = zx86_64z
>
> ifeq (,$(findstring z$(DEB_BUILD_GNU_CPU)z,$(USE_64PARSER_CPUS)))
> ${CP} Makefile.64 Makefile
> endif
>
> (Only testing with amd64 so far).
>
> Can you provide some examples of how to test the package for the bug
> you found?
>
> --
>
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
