libpng-1.4.0 coming soon

[Glenn Randers-Pehrson]

libpng-1.4.0 will be released soon.  I was planning to release it on
this Thursday, October 29, but am a bit disappointed not to hear
(read) any test results.

That means either it's perfect or that no one has tested it, but
I cannot tell which is true.

I think it's important to get 1.4.0 out, for the sake of gaining
the iTXt chunk support.

There is a lot of negative feedback (about libpng in general,
not necessarily about 1.4.0) on SourceForge.  There's no
explanation, though, just "thumbs down" exceeding "thumbs
up".  I am not sure what to make of that or how to improve
the situation.  One person surmised that it was because of
the large number of files (about 5000) that was gumming
up the "show files" script at SourceForge.  I've fixed that
by removing most of the files.

#:-(

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

> That means either it's perfect or that no one has tested it, but
> I cannot tell which is true.

I'm definitely guilty of the latter...

> I think it's important to get 1.4.0 out, for the sake of gaining
> the iTXt chunk support.

I agree.

> There is a lot of negative feedback (about libpng in general,
> not necessarily about 1.4.0) on SourceForge.  There's no
> explanation, though, just "thumbs down" exceeding "thumbs
> up".

I don't know for sure (and I didn't vote), but from comments I've seen on
some Linux sites, libpng's security record is a big part of it--it ranks
right down there with 1990s-era sendmail in a lot of people's minds.

API breakage in some of the earlier 1.2.x releases probably also didn't
help, and there have been several instances of back-to-back releases due
to sloppy editing and poor beta-testing.  Frequent releases in order to
fix mistakes (as opposed to rapid development resulting in new features)
tends to be a bad sign, and it's very hard to overcome a poor initial
impression.

But I think the security issue is probably the main part, and I suspect
that's compounded by the fact that libpng is so widely used.  That means
_lots_ of exposure (and lots of pain in the case of statically linked
apps), with the obvious end result. :-/

What to do about it?  I'd suggest simply not releasing anything but betas
until you get at least 3-5 people's positive feedback on a particular
release.  Outside of security updates, there's absolutely no requirement
to release anything formal; let the beta-testers tell _you_ when it's
time to release.  Until then, just keep puttering away in the git repo
and occasionally making new tarball releases.  I don't think too many
people will mind greatly if it's a year or two between official releases...
(Note that I'm recommending the "beta-driven" part start _after_ 1.4.0
goes out, but even 1.4.0 should be subject to the 3-5 rule.)

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Ralph Giles-2]

On Tue, Oct 27, 2009 at 9:38 PM, Greg Roelofs <newt@...> wrote:

> What to do about it?  I'd suggest simply not releasing anything but betas
> until you get at least 3-5 people's positive feedback on a particular
> release.

Contrariwise, sometimes people just don't test until you make what
looks like a real release. It's what the tiny revision number is for.

> Outside of security updates, there's absolutely no requirement
> to release anything formal; let the beta-testers tell _you_ when it's
> time to release.

Has there been any fuzz testing of the 1.4 branch?

 -r

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

On Wed, Oct 28, 2009 at 12:38 AM, Greg Roelofs <newt@...> wrote:

> What to do about it?  I'd suggest simply not releasing anything but betas
> until you get at least 3-5 people's positive feedback on a particular
> release.

     OK.  Under that scheme we'd be putting out libpng-0.89beta0683 next
     week, and we'd never have released all those security bugs that came
     with 1.0.5/1.0.6.

     Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

I wrote:

>>> What to do about it?  I'd suggest simply not releasing anything but betas
>>> until you get at least 3-5 people's positive feedback on a particular
>>> release.

Ralph wrote:

>> Contrariwise, sometimes people just don't test until you make what
>> looks like a real release. It's what the tiny revision number is for.

That happens, yes, but sooner or later there will be some change that
they need or want, so they'll start testing a particular beta version
because they have no other option.

Keep in mind that there needs to be a point to official releases.  If
no one particularly cares (other than security fixes), then there is
absolutely _no_ reason to have _any_ more official releases.  That's
not necessarily a bad thing, either--do you see anybody complaining
about zlib?

Glenn wrote:

>      OK.  Under that scheme we'd be putting out libpng-0.89beta0683 next
>      week, and we'd never have released all those security bugs that came
>      with 1.0.5/1.0.6.

That doesn't really follow.  At some point the feature load (or even
aggregate fixes) becomes large enough that people start clamoring for
a release, and then you can switch to stabilization mode and actually
start getting serious beta-tester feedback for a change.  (And if those
who were doing the clamoring fail to report feedback, then they can do
without a release until they do provide it.  Releases are a means, not
an end.)

What we have now is a never-ending sequence of minor changes providing
essentially no extra benefit (but always risk!) to 95% or 99% of the
user base, which means they're pure overhead.  Of _course_ no one wants
to test them.  (Once you've tested one 1.2 release, you've tested 'em
all... ;-) )

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Wed, 28 Oct 2009, Greg Roelofs wrote:
> absolutely _no_ reason to have _any_ more official releases.  That's
> not necessarily a bad thing, either--do you see anybody complaining
> about zlib?

Yes, I would like to complain about zlib.  Where do I complain and who
do I complain to?

My complaint is that zlib writes uninitialized data to its output
which gives valgrind fits and makes libpng look bad.  The workaround
has been to tell zlib to use my own memory allocator which zeros
memory.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

> Yes, I would like to complain about zlib.  Where do I complain and who
> do I complain to?

Presumably the indicated e-mail address on the home page:

        http://zlib.net/

> My complaint is that zlib writes uninitialized data to its output
> which gives valgrind fits and makes libpng look bad.  The workaround
> has been to tell zlib to use my own memory allocator which zeros
> memory.

Does it do that for valid zlib streams or only those that violate the
zlib/deflate spec?  There was a fuss when browsers upgraded from 1.1.3
to 1.2.x and discovered that a class of images no longer displayed
correctly because they made invalid assumptions about the sliding
window that 1.1.3 happened to honor.  1.2.x was stricter and either
rejected or simply decoded improperly those streams.

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Ralph Giles-2]

On Wed, Oct 28, 2009 at 3:55 PM, Greg Roelofs <newt@...> wrote:

> What we have now is a never-ending sequence of minor changes providing
> essentially no extra benefit (but always risk!) to 95% or 99% of the
> user base, which means they're pure overhead.  Of _course_ no one wants
> to test them.  (Once you've tested one 1.2 release, you've tested 'em
> all... ;-) )

No reason to "release early" when one has a public repository?

I suppose there might be something to the "beta who cried wolf"
effect. I know it's been difficult for me to keep up with all the
different libpng versions and the three simultaneously maintained
branches. Some clear descriptions on the main libpng page might help
there.

More seriously, I do get the impression that the 'release and
volunteers will give feedback' scheme doesn't work as well as it used
to. Too much free software competing for our attention maybe? A lot of
projects I'm involved in have been developing internal testing
automation the past couple of years, so it's easier to directly find
problems and verify new code. That's why I asked about fuzz testing.

 -r

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Wed, 28 Oct 2009, Greg Roelofs wrote:

>> My complaint is that zlib writes uninitialized data to its output
>> which gives valgrind fits and makes libpng look bad.  The workaround
>> has been to tell zlib to use my own memory allocator which zeros
>> memory.
>
> Does it do that for valid zlib streams or only those that violate the
> zlib/deflate spec?  There was a fuss when browsers upgraded from 1.1.3

The valgrind complaints I see seem to be only while compressing.  It
happens for every use of zlib in GraphicsMagick (without the "calloc"
fix).  I have verified that the complaints have nothing to do with the
provided user data by doing a memset() of the user data.  With the
zlib workaround, GraphicsMagick is to the point that it produces no
valgrind complaints at all under Debian Lenny.

Do other people not see these gripes?

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Wed, 28 Oct 2009, Greg Roelofs wrote:
>
> Does it do that for valid zlib streams or only those that violate the
> zlib/deflate spec?  There was a fuss when browsers upgraded from 1.1.3
> to 1.2.x and discovered that a class of images no longer displayed
> correctly because they made invalid assumptions about the sliding
> window that 1.1.3 happened to honor.  1.2.x was stricter and either
> rejected or simply decoded improperly those streams.

I see

   http://zlib.net/zlib_faq.html#faq36

The reasoning seems bogus to me.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

> I see

>    http://zlib.net/zlib_faq.html#faq36

[Specifically, "Valgrind (or some similar memory access checker) says that
 deflate is performing a conditional jump that depends on an uninitialized
 value. Isn't that a bug?

 "No. That is intentional for performance reasons, and the output of
 deflate is not affected. This only started showing up recently since
 zlib 1.2.x uses malloc() by default for allocations, whereas earlier
 versions used calloc(), which zeros out the allocated memory."]

> The reasoning seems bogus to me.

Depends on the specific cases.  I've seen a number of cases in software
at work where valgrind gives that warning, and all of the ones that
referred to software components under our control were bogus (or else
were fixed immediately, but there are always a bunch of bogus ones).

That said, I haven't tried the most recent version, so maybe it's gotten
better.  Either way, you can argue it with Mark, but if he believes
correctness is unaffected but performance is, you're unlikely to make
much progress.

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Wed, 28 Oct 2009, Greg Roelofs wrote:
>
> Depends on the specific cases.  I've seen a number of cases in software
> at work where valgrind gives that warning, and all of the ones that
> referred to software components under our control were bogus (or else
> were fixed immediately, but there are always a bunch of bogus ones).

In the many tens of thousands of valgrind gripes I have addressed, I
have yet to find a "bogus" one.  In a few cases it took a number of
years to figure out the cause.  Several cases took about four years.
They took that long since the cause was quite removed from where it
was reported due to stdio buffering and because the uninitialized data
was hidden in a padded structure.  Valgrind will complain if
uninitialized structure padding is included in a structure written to
a stream.

Similar to compiler warnings, it is best to eliminate all valgrind
complaints if at all possible.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Mark Adler]

On Oct 28, 2009, at 5:46 PM, Greg Roelofs wrote:
> Either way, you can argue it with Mark, but if he believes
> correctness is unaffected but performance is, you're unlikely to make
> much progress.

Greg and Bob,

Indeed correctness is unaffected but performance is, as compared to  
initializing all of that memory ahead of time.  Despite that I have  
mitigated it in an as yet undistributed beta.  I found a way to  
initialize just the bytes that deflate is actually using for lookahead  
that don't happen to have been initialized already, with a negligible  
performance hit.  I did this even though it adds risk by modifying  
code that has been working perfectly fine in countless invocations for  
over a decade, and even though the change has no purpose other than to  
avoid a warning about a possible problem that is in fact not a  
problem!  I forget what chain of emails motivated me to take this  
rather imprudent action, but there it is.

The note in the ChangeLog says:

- Clear bytes after deflate lookahead to avoid use of uninitialized data

By the way, I have no idea what Bob is referring to as "bogus".

Mark


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

> No reason to "release early" when one has a public repository?

Repository or beta tarballs, yes.  (I'm not suggesting Glenn should stop
doing the latter; there are many people who don't want to futz with a new
version-control system, or even an old one.  For example, it's very rare
that I'm willing to do a CVS or Subversion pull of any project, and I still
don't even have git installed.)

> I suppose there might be something to the "beta who cried wolf"
> effect. I know it's been difficult for me to keep up with all the
> different libpng versions and the three simultaneously maintained
> branches. Some clear descriptions on the main libpng page might help
> there.

Yeah, if only...  I'm so backlogged on everything, it's becoming an
epic tragedy. :-(

> More seriously, I do get the impression that the 'release and
> volunteers will give feedback' scheme doesn't work as well as it used
> to. Too much free software competing for our attention maybe?

Yup, that was my conclusion already a decade back w.r.t. Info-ZIP development.

> A lot of
> projects I'm involved in have been developing internal testing
> automation the past couple of years, so it's easier to directly find
> problems and verify new code. That's why I asked about fuzz testing.

Fuzz-testing, regression testing, unit tests, ...  I'd love to see any
or all of it.  But it's another kind of development, and good suites
that don't require manual intervention tend to be a fair bit of work to
put together.  (Of course, any amount is better than none; obviously it
can improve over time rather than attempt perfection from the get-go.)

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Wed, 28 Oct 2009, Mark Adler wrote:

>
> Indeed correctness is unaffected but performance is, as compared to
> initializing all of that memory ahead of time.  Despite that I have mitigated
> it in an as yet undistributed beta.  I found a way to initialize just the
> bytes that deflate is actually using for lookahead that don't happen to have
> been initialized already, with a negligible performance hit.  I did this even
> though it adds risk by modifying code that has been working perfectly fine in
> countless invocations for over a decade, and even though the change has no
> purpose other than to avoid a warning about a possible problem that is in
> fact not a problem!  I forget what chain of emails motivated me to take this
> rather imprudent action, but there it is.

Excellent!  Probably the chain of emails was long and rude (like
mine). :-)

> The note in the ChangeLog says:
>
> - Clear bytes after deflate lookahead to avoid use of uninitialized data
>
> By the way, I have no idea what Bob is referring to as "bogus".

I was thinking that by carefully initializing only the bytes which
would not be initialized already, that the valgrind warning could be
eliminated with a negligible performance hit.  That made the claim
that there would be a noticeable performance impact and therefore the
issue should not be resolved "bogus".

It is always scary when modifying complex code which is already
executing perfectly.

The world will be a happier place when the valgrind-clean zlib is
released since so many programs use zlib and people are now also using
valgrind heavily.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Vincent Torri-2]

On Wed, 28 Oct 2009, Greg Roelofs wrote:

> Fuzz-testing, regression testing, unit tests, ...  I'd love to see any
> or all of it.  But it's another kind of development, and good suites
> that don't require manual intervention tend to be a fair bit of work to
> put together.  (Of course, any amount is better than none; obviously it
> can improve over time rather than attempt perfection from the get-go.)

The gstreamer folks have some huge unit testing (using the 'check'
framework). Maybe it would be interesting to see how they do it, as it is
close to what libpng would need (testing a set of png image files instead
of video or audio files).

Vincent Torri

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Ralph Giles-2]

On Wed, Oct 28, 2009 at 7:20 PM, Greg Roelofs <newt@...> wrote:

>> No reason to "release early" when one has a public repository?
>
> Repository or beta tarballs, yes.  (I'm not suggesting Glenn should stop
> doing the latter; there are many people who don't want to futz with a new
> version-control system, or even an old one.  For example, it's very rare
> that I'm willing to do a CVS or Subversion pull of any project, and I still
> don't even have git installed.)

And I'm the other way around, so I guess that's a 'no' except in the
sense that beta tarballs aren't really releases. :-)

> Fuzz-testing, regression testing, unit tests, ...  I'd love to see any
> or all of it.  But it's another kind of development, and good suites
> that don't require manual intervention tend to be a fair bit of work to
> put together.  (Of course, any amount is better than none; obviously it
> can improve over time rather than attempt perfection from the get-go.)

Yes, it's all work. Even getting started with fuzz testing requires a
few things like disabling the CRC check. Still it's not hard to leave
zzuf running for a few weeks on the test suite and some wild files. I
was just curious what had been done.

 -r

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[glennrp-2]

----- Original Message -----
From: "Ralph Giles" <giles@...>
> I was just curious what had been done.

      People give the public releases a pretty good hammering with
      flayer, coverity, valgrind, and whatnot.  I don't know
      if they pay any attention to the betas and rcs though.

      Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement