[Expat-discuss] Time for a new release?

[Dan Nicholson]

On Sun, Jan 18, 2009 at 12:00 PM, Karl Waclawek <karl at waclawek.net> wrote:
> Daniel Leidert wrote:
>>
>> Am Sonntag, den 18.01.2009, 09:45 -0800 schrieb Dan Nicholson:
>>
>>>
>>> Just tried the build again on Linux x86 and x86_64. Everything seemed
>>> fine. I had a look at fedora and debian's expat packages. Here are
>>> some patches they're applying:
>>>
>>>
>>> http://cvs.fedora.redhat.com/viewvc/rpms/expat/devel/expat-1.95.8-pedantic.patch?view=markup
>>> http://patch-tracking.debian.net/package/expat/2.0.1-4
>>>
>>> I cc'd the package maintainers (at least, who I think they are), to
>>> see if they have any specific input on those patches.
>>>
>>
>> Of course I will do. I first mention the patch, followed by a short
>> explanation and the related Debian bug report (the same information can
>> also be found in the patch headers).
>>
>>
>> http://svn.debian.org/wsvn/debian-xml-sgml/packages/expat/trunk/debian/patches/82763_xmlwf_error_out_2.dpatch?op=file&rev=0&sc=0
>>
>> xmlwf exits with status zero in case of an error. It is common to error
>> out with a non-zero exit status. The patch simply makes the application
>> exit with status 2 in case of an error.
>> http://bugs.debian.org/82763
>>
>>
>
> Has this (and other issues) ever been reported to the Expat project on SF?
> For instance, from what I can tell, xmlwf returns non-zero for errors in
> quite a few cases (check the usage() calls, or XML_ProcessFile() in
> xmlfile.c.
>
> So I assume, we have a true bug here. This should be posted to
> https://sourceforge.net/tracker2/?atid=110127&group_id=10127
>
>>
>> http://svn.debian.org/wsvn/debian-xml-sgml/packages/expat/trunk/debian/patches/302191_install_expat_config_h.dpatch?op=file&rev=0&sc=0
>>
>> It seems, some projects (python-4suite) reference the expat_config.h
>> header file. The patch simply adds this file to be installed. I'm *not*
>> sure, that this patch should be accepted upstream. It might be an error
>> to reference expat_config.h in a software source. You should check (I
>> can do this too in a few days), why python-4suite references this header
>> file. Maybe moving some declarations to the installed header files is
>> the solution to go.
>> http://bugs.debian.org/302191
>>
>
> expat_config.h is generated for Unix, on Windows it does not exist. It
> should not generally be needed.

Looking at expat_config.h, I'd guess that an expat binding might want
to know these definitions:

/* Define to specify how much context to retain around the current parse
   point. */
#undef XML_CONTEXT_BYTES

/* Define to make parameter entity parsing functionality available. */
#undef XML_DTD

/* Define to make XML Namespaces functionality available. */
#undef XML_NS

But this is completely speculation, and I would hope that this
information would not be needed externally.

>> http://svn.debian.org/wsvn/debian-xml-sgml/packages/expat/trunk/debian/patches/342684_libtoolize.dpatch?op=file&rev=0&sc=0
>>
>> If you use some recent autotools, you can probably safely ignore this
>> patch. It simply runs the autotools chain on the source to get a newer
>> libtool version to support GNU/kFreeBSD.
>> http://bugs.debian.org/342684
>> http://bugs.debian.org/439127
>>
>
> Expat always seems to be behind on this area, but I have to leave this to
> our Unix experts.

Since the autotools are distributed with the tarball, it really kind
of depends on the person doing the release (you). Typically, you'd
want to do the release from wherever you have the most recent releases
of autoconf/automake/libtool. I don't know what platforms you do expat
development on, but any recent Linux distro would be fine.

Still, I wouldn't worry about this too much. Expat wouldn't be the
first or last package to need autotools updates. Distros know how to
manage this situation.

>> http://svn.debian.org/wsvn/debian-xml-sgml/packages/expat/trunk/debian/patches/412786_xmlwf_man_standard_fix.dpatch?op=file&rev=0&sc=0
>>
>> The SGML file contains a linebreak followed by three dots and and
>> parenthesis. The manual page contains the same linebreak. So the next
>> line in the manual page starts with the dots. But a leading dot has a
>> special meaning. GROFF expects a macro or request name after the dot. So
>> it throws a warning and doesn't print these four characters in the
>> resulting manual page. The patch simply removes the linebreak as an easy
>> solution to the problem.
>>
>> The second part of the patch removes a wrong statement in the BUGS
>> section. There you state, that the XML standard requires the XML
>> declaration for well-formedness. But that's not true. The declaration is
>> optional, as you can see here:
>> http://www.w3.org/TR/2006/REC-xml-20060816/#NT-prolog
>> http://bugs.debian.org/412786
>>
>
> Again, it would be nice to have this reported on the bug page. We do not
> normally Google for Expat bugs reported anywhere else.
> The SGML has not been updated since 2003. Who is actually using it? Anyway,
> a bug report would be useful, but also a review of the overall contents of
> the SGML file. Maybe we should discard it altogether?
>
>>
>> http://svn.debian.org/wsvn/debian-xml-sgml/packages/expat/trunk/debian/patches/485129_fix_underquotation_in_m4.dpatch?op=file&rev=0&sc=0
>>
>> In expat.m4 the AM_WITH_EXPAT macro is underquoted. See the paragraph
>> starting with "Starting with Automake 1.8, aclocal will warn about all
>> underquoted calls to AC_DEFUN [..]":
>> http://sources.redhat.com/automake/automake.html#Extending-aclocal
>> http://bugs.debian.org/485129
>>
>> The patch is trivial and safe.
>>
>
> Hope our build experts will do this.

This patch is definitely fine to commit.

--
Dan