[pkg-php-pear] php-xml-beautifier

Mathias Ertl mati at fsinf.at
Mon Mar 19 18:47:45 UTC 2012


Hi,

I have been able to get rid of all warnings related to xml-beautifier.

However, I have been totally unable to fix the issues left (stripped
CDATA sections, bad formatting, etc.). Given
* The extremely bad documentation of XML_Parser
* The fact that upstream seems to treat this as PHP4 only and actively
marks tickets that improve PHP5 compatabilty as WONTFIX (sorry I have
only discovered this now)

... I hereby retract my RFS for the package.

I still want to contribute a different package (phpdocumentor2 [1]) in
the future, so I hope I stay part of the team.

greetings, Mati

[1] http://www.phpdoc.org/

On 2012-03-19 17:58, Mathias Ertl wrote:
> On 2012-03-19 11:35, Thomas Goirand wrote:
>> On 03/19/2012 04:20 AM, Mathias Ertl wrote:
>>> Hmm, I'm not sure I understand. Output may break my package, but the bug
>>> is in php-xml-parser, not my package - right? I am not sure there is
>>> anything I can do to fix the issue.
>>
>> Well, sure the issue isn't in your package, but what if this renders
>> your package not usable at all? We all need to have a look into the
>> issue, and I'd appreciate if you were as well.
> 
> You are of course right that it might render my (and other) packages
> unusable. I was just not sure if you were telling me to look into
> php-xml-beautifier on that.
> 
>> I know how to fix the double definition of the constructor, that's an
>> easy one. I'm less sure for the Pear::RaiseError() thing. Do you know?
>> Maybe you know where to find some docs?
> 
> I will research the issue.
> 
>>> I did the examples found in /usr/share/doc/php-xml-beautifier/examples
>>> and they seemed find. The example*.php scripts do print warnings, but
>>> the resulting xml-files are valid.
>>
>> What warning did you see? Again, warning *must* be fixed for packages
>> that are producing XML documents.
> 
> All where PHP Strict Standards messages, like
> 
> "PHP Strict Standards:  Non-static method XML_Util::replaceEntities()
> should not be called statically, assuming $this from incompatible
> context in /usr/share/php/XML/Util.php on line 419"
> 
> Most warnings where in that file, which belongs to php-pear. A few
> select messages where in files belonging to xml-beautifier, for which I
> will write a patch (and report upstream).
> 
>>> I am more than happy to maintain my packages there. My last request to
>>> join there has been ignored. Please sign me up!
>>
>> I just added you with the "PEAR Packager" rights. Please upload your Git
>> repository to /git/pkg-php. Note that I've written a small script for that:
>>
>> http://thomas.goirand.fr/blog/
>>
>> The important bit is the one that is giving group access rights to the
>> Git repository (eg: find /git/${DEST_PROJECT}/${PKG_NAME}.git -exec
>> chmod g+w {} \\;").
>>
>> Others pointed out that it's better to push each individual branches
>> rather than uploading a tarball including all branches, but frankly, I
>> don't think it's very important. It does work very well at least.
> 
> Is it not possible to just configure the alioth repo as a remote and do
> git push?
> 
>> On 03/19/2012 04:31 AM, Mathias Ertl wrote:
>>> On 2012-03-18 16:48, Thomas Goirand wrote:
>>>> Also, when testing it, it always removed the XML header of the XML
>>>> documents:
>>>> <?xml version="1.0" encoding="iso-8859-1"?>
>>>>
>>>> I don't think that's right. Can you have a look into this issue?
>>>
>>> I don't think either. I found this bugreport:
>>>
>>> 	http://pear.php.net/bugs/bug.php?id=5450
>>>
>>> ... that unfortunately does not have a fix included. I am unsure how to
>>> progress with this issue?
>>
>> Well, we got to fix this before the upload. Also, remember that, at
>> least for simple stuff like PEAR packages, it's our duty as maintainers
>> to fix issues in the packages we maintain.
>>
>> If it's *yet another* issue in php-xml-parser, then we should both focus
>> on fixing it. This XML_Parser package is really badly maintained, yet a
>> lot of other PEAR packages depend on it. I will see if it is possible to
>> register as a contributor and fix it directly upstream.
> 
> This also relates to the recent RFH on this list: Its not the package,
> its the whole PHP eco-system (not just on Debian, in general!) thats
> badly maintained :-(
> 
> I will try to find a fix for this issue.
> 
>> Does anyone (you included, Mathias) know about the process of upstream
>> maintenance of PEAR packages? Is there an upstream Git or something?
> 
> No. I considered making a PHP library into a PEAR package but refrained
> from doing it because of they only let you choose from a very
> restrictive set of licenses.
> 
> greetings, Mati
> 
> 
> 
> 
> _______________________________________________
> pkg-php-pear mailing list
> pkg-php-pear at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pear


-- 
twitter: @mathiasertl | soup: http://soup.er.tl | xing: Mathias Ertl
I only read plain-text mail!  I prefer signed/encrypted mail!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4572 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20120319/f0ece651/attachment.bin>


More information about the pkg-php-pear mailing list