incorrect rendering in 0.61.05-5 and -6

[Paul Wise]

On Thu, 2006-06-22 at 16:33 +0300, Fabian Fagerholm wrote:

> Could you store one correct and one incorrect rendering of one of the
> examples somewhere? I'm not sure what I'm supposed to be getting in all
> cases.

I've converted examples/logo.sif to logo.png for the gcc-4.1 and gcc-4.0
compiled versions of synfig:

http://bonedaddy.net/pabs3/files/tmp/debian/synfig-gcc-4.0-logo.png
http://bonedaddy.net/pabs3/files/tmp/debian/synfig-gcc-4.1-logo.png

> Yeah, you're right about the buildd strain being something to watch out
> for. At the same time, if we want people to test and submit bug reports,
> frequent releases are a good thing. As etch comes closer to release, we
> probably should be more conservative and let the buildds work on more
> important packages. So it's about finding the right balance at the given
> moment, and a single fix like the one in -6 was definitely too little.
> Bad call on my side.

Agreed.

> > Todo for -7:
> >       * fix the OOM problem on !i386 with low memory. I think we should
> >         run synfig post-build on one of the example .sif files to test
> >         synfig during the build process.
> 
> Could we automate this by storing md5sums of the expected results in the
> source package, and comparing the md5sums of the actual synfig results
> to the expected results, and complain if they don't match? I presume the
> result is deterministic across all platforms, of course...

Well, the OOM problem separate to incorrect results. It is that when you
run synfig on some platforms it uses huge amounts of RAM and is thus
killed by the kernel OOM killer. You can see the effect in the
synfigstudio buildd logs, when synfig is converting the synfigstudio
icons to png files. The problem is not so much incorrect results as
synfig not being able to complete rendering due to lack of RAM.

http://buildd.debian.org/~jeroen/status/package.php?p=synfigstudio
http://sf.net/tracker/?func=detail&aid=1497893&group_id=144022&atid=757416

About the incorrect results thing, perhaps we can get some md5sums in
the next upload and compare that to known-good and known-bad results on
i386. Hmm, I wonder if PNG embeds the modification time.

Also, committed the ffmpeg fix to debian and upstream.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-synfig-devel/attachments/20060623/063cd621/attachment.pgp