On Sun, 16 Dec 2007, Magnus Holmgren, exim.org @ Pike developers forum wrote:

Hi again, have you read the messages to alain he's willing to upload packages, and since pike and caudium is quite related I say we should syncronise the uploads ?

So I think I'll build agains pike 7.6.112 instead of the "unstable" version in unstable right now 7.6.93 ...

Will you contact alain to accomplish a upload of pike, then I'll adopt caudium with my new version at:

http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package...

//kinneh at #pike irc.freenode.net

Check the last messages from me to this list for the remaining loose ends. But perhaps what I have right now might be good enough to upload, if I only find a sponsor or manage to complete the NM process.

On Wed, Dec 26, 2007 at 03:25:01PM +0000, Magnus Holmgren, exim.org @ Pike developers forum wrote:

As some of you may have seen, a new Debian package of 7.6.112 was uploaded the other day. I hope it will be well tested!

is there a backport to etch available? i don't suppose that pike can be added to backports.org?

greetings, martin.

On Tue, Feb 19, 2008 at 01:22:41PM +0100, Bertrand LUPART wrote:

I've no sid machines, and would like to know the easiest way to get 7.6.112 on etch (mixed system or compilation)

install pbuilder set it up to build for etch default setup should be ok, except for the repository which is default hardcoded to japan, which you may not want.

then add deb-src for sid to your sources.list and apt-get source pike. then build the downloaded result with pbuilder.

no changes are needed to make it build (at least that was the case when i did it last month. as sid evolves that may change)

This may be outdated: http://www.gotpike.org/PikeWiki/index.pike?page=Installing%20Pike

for the most part that still appesrs to be correct.

greetings, martin.

As some of you may have seen, a new Debian package of 7.6.112 was uploaded the other day. I hope it will be well tested!

It failed to build on Alpha, however. Apparently a double free or corruption happened in libjpeg (used by the Image.JPEG module) during autogeneration og the documentation (which, in the best of worlds, should be bypassed by the autobuilders). See http://buildd.debian.org/fetch.cgi?pkg=pike7.6;ver=7.6.112-1;arch=alpha;stamp=1198260298.

I seem to recall having heard of such problems earlier on debian/alpha.

Can anyone tell whether this is the fault of Pike or libjpeg?

From looking at the backtrace, it goes wrong in

libjpeg:jpeg_finiah_compress(). There are three calls to jpeg_finish_compress() in the _Image_JPEG module, unfortunately it seems the backtrace hasn't loaded symbols for the pike modules. Reading the source for extract_autodoc gives that it most likely goes wrong in Image.JPEG.encode(). The code for Image.JPEG.encode() looks correct on inspection (and it works correctly on other LE LP64-architectures (eg ia64)), so the problem is most likely in libjpeg (or even more likely in the compiler that built libjpeg).