Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Guido Günther]

781232 +tags patch
thanks

Hi,
On Sun, Sep 06, 2015 at 11:34:49AM +0200, Guido Günther wrote:
> Hi Aron,
> On Sat, Sep 05, 2015 at 02:35:49PM +0200, Guido Günther wrote:
> > tags 781232 +patch
> > thanks
> > 
> > Hi Salvatore, Hi Aron,
> > On Mon, Aug 31, 2015 at 11:02:48AM +0200, Salvatore Bonaccorso wrote:
> > > Hi Aron,
> > > 
> > > Specific for the issue now seen for #781232: Looked shortly at
> > > https://bugzilla.gnome.org/show_bug.cgi?id=731063#c1 According to that
> > > comment the original patch lead to more issues (e.g.  the one which we
> > > see now) and more patches were applied. I have though not tried to
> > > skim trough to check which are required.
> > 
> > Attached patch resolves the libvirt related regression for me. It's a
> > straight cherry pick from upstream commit
> > 
> > beb7281055dbf0ed4d041022a67c6c5cfd126f25
> > 
> > Can we have this in sid please? It would also be great to have this
> > backported to Jessie since libvirt is there affected as well. (And yes,
> > I do think the severity is correct).
> 
> I've uploaded a NMU to delayed 7days so in case nobody has time to take
> care of it it will get fixed eventually. We can always dcut it.
> 
> Let me know if I should take care of stable as well?

Attached is the diff from the NUM announced above.
Cheers,
 -- Guido
diff --git a/debian/changelog b/debian/changelog
index f7ec7e5..b670771 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libxml2 (2.9.2+really2.9.1+dfsg1-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix a problem unparsing URIs without a host part like qemu:///system.
+This unbreaks libvirt, libsys-virt-perl and others
+(Closes: #781232)
+
+ -- Guido Günther   Sun, 06 Sep 2015 11:16:48 +0200
+
 libxml2 (2.9.2+really2.9.1+dfsg1-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/Fix-a-problem-properly-saving-URIs.patch b/debian/patches/Fix-a-problem-properly-saving-URIs.patch
new file mode 100644
index 000..71c4261
--- /dev/null
+++ b/debian/patches/Fix-a-problem-properly-saving-URIs.patch
@@ -0,0 +1,125 @@
+From: Daniel Veillard 
+Date: Fri, 3 Oct 2014 19:22:39 +0800
+Subject: Fix a problem properly saving URIs
+
+As written by Martin Kletzander :
+Since commit 8eb55d782a2b9afacc7938694891cc6fad7b42a5, when you parse
+and save an URI that has no server (or similar) part, two slashes
+after the 'schema:' get lost.  It means 'uri:///noserver' is turned
+into 'uri:/noserver'.
+
+basically
+   foo:///only/path
+
+means a host of "" while
+
+   foo:/only/path
+
+means no host at all
+
+  So the best fix IMHO is to fix the URI parser to record the first
+case and an empty host string and the second case as a NULL host string
+
+ I would not revert the initial patch, we should not 'invent' those
+slash, but we should instead when parsing keep the information that
+it's a host based path and that foo:/// means the presence of a host
+but an empty one.
+
+Once applied the resulting patch below, all cases seems to be saved
+properly:
+
+thinkpad:~/XML -> ./testURI uri:/noserver
+uri:/noserver
+thinkpad:~/XML -> ./testURI uri:///noserver
+uri:///noserver
+thinkpad:~/XML -> ./testURI uri://server/foo
+uri://server/foo
+thinkpad:~/XML -> ./testURI uri:/noserver/foo
+uri:/noserver/foo
+thinkpad:~/XML -> ./testURI uri:///
+uri:///
+thinkpad:~/XML -> ./testURI uri://
+uri://
+thinkpad:~/XML -> ./testURI uri:/
+uri:/
+thinkpad:~/XML ->
+
+  If you revert the initial patch that last case fails
+
+The problem is that I don't want to change the xmlURI structure to
+minimize ABI breakage, so I could not extend the field. The natural
+solution is to denote that uri:/// has an empty host by making
+the uri server field an empty string which works very well but breaks
+applications (like libvirt ;-) who blindly look at uri->server
+not being NULL to try to reach it !
+Simplest was to stick the port to -1 in that case, instead of 0
+application don't bother looking at the port of there is no server
+string, this makes the patch more complex than a 1 liner, but
+is better for ABI.
+
+Closes: #781232
+---
+ uri.c | 34 +++---
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/uri.c b/uri.c
+index d4dcd2f..ff47abb 100644
+--- a/uri.c
 b/uri.c
+@@ -759,6 +759,8 @@ xmlParse3986HierPart(xmlURIPtr uri, const char **str)
+ cur += 2;
+ 	ret = xmlParse3986Authority(uri, );
+ 	if (ret != 0) return(ret);
++	if (uri->server == NULL)
++	uri->port = -1;
+ 	ret = xmlParse3986PathAbEmpty(uri, );
+ 	if (ret != 0) return(ret);
+ 	*str = cur;
+@@ -1106,7 +1108,7 @@ xmlSaveUri(xmlURIPtr uri) {
+ 	}
+ 	}
+ } else {
+-	if (uri->server != NULL) {
++	if ((uri->server != NULL) || (uri->port == -1)) {
+ 	if (len + 3 >= max) {
+ temp = xmlSaveUriRealloc(ret, );
+ if (temp == NULL) goto mem_error;
+@@ -1143,22 

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

On Fri, 04 Sep 2015, Raphael Hertzog wrote:
> I did that because I believe that this was the correct course of action
> given the lack of proper fix upsream, not because it was an easy solution.

For the record, upstream pushed a "proper" fix now:
https://git.gnome.org/browse/libxml2/commit/?id=ef709ce2f7b792d5fb69ed142796d743fb1eb388

So you can package a snapshot of the upstream git + the latest security
patches if you prefer.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

On Mon, Sep 7, 2015 at 3:54 PM, Thorsten Glaser  wrote:
> On Sat, 5 Sep 2015, Vincent Lefevre wrote:
>
>> I'm not the maintainer, but I think that it is probably cleaner to
>> have testing version = stable version until this bug is fixed (it
>
> No, absolutely not. We’re in the midst of a hell of a transition,
> holding back packages just for fun isn’t helping.
>

I'm not being freak for keeping the same version, but I'm against
reverting to old version for this specific odd package.

>> On 2015-09-05 08:49:35 +0200, Raphael Hertzog wrote:
>
>> > This just proves that you don't know how Debian works. A fix for testing
>> > must come via unstable not from stable.
>>
>> First, I haven't said that a fix for testing must come from stable,
>> just that it was easy to fix testing too (because this would be the
>> same patch). And no, a fix for testing does not necessarily come
>> via unstable:
>
> This is the absolute exception; all uploads to testing should come
> via unstable if at all possible. The exception is for when people
> used unstable as experimental, preventing migration, but there are
> really urgent issues to be fixed in testing. Only. The paragraph
> you cited allows maintainers to deviate from the normal “via un‐
> stable” rule in such cases, it doesn’t make it the norm. This is
> how Debian works.
>

Yep, and testing's security support isn't a priority at this moment
(non-frozen) IMHO, even it's really nice to have.

> Same goes for stable: If there is a to-be-fixed-in-stable-too bug
> in the package, first fix it in unstable, then (while waiting for
> it to migrate to testing, or even after that) fix it in stable.
> This ensures we don’t have bugs fixed in stable that are reintroduced
> in later Debian versions (there even has been a package which had
> this for two subsequent Debian releases, people really don’t like
> to see this).
>

Agreed on fixing unstable first if possible, but it's only ideal case
that we really want to wait it migrate to testing. Stable is for
production, not another testing for testing that need to wait for
testing.

Regards,
Aron

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Guido Günther]

Hi Aron,
On Mon, Sep 07, 2015 at 04:07:38PM +0800, Aron Xu wrote:
[..snip..]
> Agreed on fixing unstable first if possible, but it's only ideal case
> that we really want to wait it migrate to testing. Stable is for
> production, not another testing for testing that need to wait for
> testing.

We need to fix this bug in unstable first if we want to have this fixed
in stable via a point release, otherwise the release managers will very
likely reject it.

Cheers,
 -- Guido

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Thorsten Glaser]

On Sat, 5 Sep 2015, Vincent Lefevre wrote:

> I'm not the maintainer, but I think that it is probably cleaner to
> have testing version = stable version until this bug is fixed (it

No, absolutely not. We’re in the midst of a hell of a transition,
holding back packages just for fun isn’t helping.

> On 2015-09-05 08:49:35 +0200, Raphael Hertzog wrote:

> > This just proves that you don't know how Debian works. A fix for testing
> > must come via unstable not from stable.
> 
> First, I haven't said that a fix for testing must come from stable,
> just that it was easy to fix testing too (because this would be the
> same patch). And no, a fix for testing does not necessarily come
> via unstable:

This is the absolute exception; all uploads to testing should come
via unstable if at all possible. The exception is for when people
used unstable as experimental, preventing migration, but there are
really urgent issues to be fixed in testing. Only. The paragraph
you cited allows maintainers to deviate from the normal “via un‐
stable” rule in such cases, it doesn’t make it the norm. This is
how Debian works.

Same goes for stable: If there is a to-be-fixed-in-stable-too bug
in the package, first fix it in unstable, then (while waiting for
it to migrate to testing, or even after that) fix it in stable.
This ensures we don’t have bugs fixed in stable that are reintroduced
in later Debian versions (there even has been a package which had
this for two subsequent Debian releases, people really don’t like
to see this).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-07 12:26:22 +0200, Guido Günther wrote:
> On Mon, Sep 07, 2015 at 11:41:55AM +0200, Vincent Lefevre wrote:
> > Well, stable is not affected by this bug, but by other security
> > problems. The patches are available here, so that I don't see any
> > problem.
> 
> Stable is affected by this bug.

No, this must be a different bug.

$ apt-show-versions -a libxml2
libxml2:amd64 2.9.2+really2.9.1+dfsg1-0.1 install ok installed
libxml2:amd64 2.9.1+dfsg1-5   stable   ftp.fr.debian.org
No stable-updates version
libxml2:amd64 2.9.1+dfsg1-5   testing  ftp.fr.debian.org
libxml2:amd64 2.9.2+really2.9.1+dfsg1-0.1 unstable ftp.fr.debian.org
No experimental version
libxml2:amd64/unstable 2.9.2+really2.9.1+dfsg1-0.1 uptodate

stable has 2.9.1+dfsg1-5, which is not affected. This bug appeared
in 2.9.2.

However stable and unstable are affected by bug 754424, which is
annoying too, but much less.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Guido Günther]

On Mon, Sep 07, 2015 at 11:41:55AM +0200, Vincent Lefevre wrote:
> On 2015-09-07 10:25:02 +0200, Guido Günther wrote:
> > Hi Aron,
> > On Mon, Sep 07, 2015 at 04:07:38PM +0800, Aron Xu wrote:
> > [..snip..]
> > > Agreed on fixing unstable first if possible, but it's only ideal case
> > > that we really want to wait it migrate to testing. Stable is for
> > > production, not another testing for testing that need to wait for
> > > testing.
> > 
> > We need to fix this bug in unstable first if we want to have this fixed
> > in stable via a point release, otherwise the release managers will very
> > likely reject it.
> 
> Well, stable is not affected by this bug, but by other security
> problems. The patches are available here, so that I don't see any
> problem.

Stable is affected by this bug.
 -- Guido

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-07 10:25:02 +0200, Guido Günther wrote:
> Hi Aron,
> On Mon, Sep 07, 2015 at 04:07:38PM +0800, Aron Xu wrote:
> [..snip..]
> > Agreed on fixing unstable first if possible, but it's only ideal case
> > that we really want to wait it migrate to testing. Stable is for
> > production, not another testing for testing that need to wait for
> > testing.
> 
> We need to fix this bug in unstable first if we want to have this fixed
> in stable via a point release, otherwise the release managers will very
> likely reject it.

Well, stable is not affected by this bug, but by other security
problems. The patches are available here, so that I don't see any
problem.

I've asked upstream if they could release a new version based on
2.9.1 with security fixes and a non-regression test for this bug:

  https://bugzilla.gnome.org/show_bug.cgi?id=737840#c8

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-07 13:39:57 +0200, Guido Günther wrote:
> I'm talking about #781232 only since this is the bug this thread is
> attached to and stable is affected by that one (see the version
> information of this bug). I filed that bug initially.

OK, I didn't remember that two unrelated bugs were discussed in the
same thread.

For #766884, I think that it should be closed after a non-regression
test is added in the Debian package (to make sure that it doesn't
reappear silently) if this is not already done. After all, the
problem is on the upstream side now.

> That said. We have a fix and there's a NMU in the delayed queue so can't
> we just fix this one in all suites and move on?

And handle #781232 in a similar way: fix + non-regression test, then
the bug can be closed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Guido Günther]

Hi,
On Mon, Sep 07, 2015 at 12:42:32PM +0200, Vincent Lefevre wrote:
> On 2015-09-07 12:26:22 +0200, Guido Günther wrote:
> > On Mon, Sep 07, 2015 at 11:41:55AM +0200, Vincent Lefevre wrote:
> > > Well, stable is not affected by this bug, but by other security
> > > problems. The patches are available here, so that I don't see any
> > > problem.
> > 
> > Stable is affected by this bug.
> 
> No, this must be a different bug.
> 
> $ apt-show-versions -a libxml2
> libxml2:amd64 2.9.2+really2.9.1+dfsg1-0.1 install ok installed
> libxml2:amd64 2.9.1+dfsg1-5   stable   ftp.fr.debian.org
> No stable-updates version
> libxml2:amd64 2.9.1+dfsg1-5   testing  ftp.fr.debian.org
> libxml2:amd64 2.9.2+really2.9.1+dfsg1-0.1 unstable ftp.fr.debian.org
> No experimental version
> libxml2:amd64/unstable 2.9.2+really2.9.1+dfsg1-0.1 uptodate
> 
> stable has 2.9.1+dfsg1-5, which is not affected. This bug appeared
> in 2.9.2.

I'm talking about #781232 only since this is the bug this thread is
attached to and stable is affected by that one (see the version
information of this bug). I filed that bug initially.

That said. We have a fix and there's a NMU in the delayed queue so can't
we just fix this one in all suites and move on?

Cheers,
 -- Guido

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Guido Günther]

Hi Aron,
On Sat, Sep 05, 2015 at 02:35:49PM +0200, Guido Günther wrote:
> tags 781232 +patch
> thanks
> 
> Hi Salvatore, Hi Aron,
> On Mon, Aug 31, 2015 at 11:02:48AM +0200, Salvatore Bonaccorso wrote:
> > Hi Aron,
> > 
> > Specific for the issue now seen for #781232: Looked shortly at
> > https://bugzilla.gnome.org/show_bug.cgi?id=731063#c1 According to that
> > comment the original patch lead to more issues (e.g.  the one which we
> > see now) and more patches were applied. I have though not tried to
> > skim trough to check which are required.
> 
> Attached patch resolves the libvirt related regression for me. It's a
> straight cherry pick from upstream commit
> 
> beb7281055dbf0ed4d041022a67c6c5cfd126f25
> 
> Can we have this in sid please? It would also be great to have this
> backported to Jessie since libvirt is there affected as well. (And yes,
> I do think the severity is correct).

I've uploaded a NMU to delayed 7days so in case nobody has time to take
care of it it will get fixed eventually. We can always dcut it.

Let me know if I should take care of stable as well?

Cheers,
 -- Guido

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

On Sat, Sep 5, 2015 at 2:49 PM, Raphael Hertzog  wrote:
> On Sat, 05 Sep 2015, Vincent Lefevre wrote:
>> My argument is that:
>>
>> 1. stable must not have security issues, i.e. all security issues
>>should be fixed ASAP. AFAIK, security issues in stable are
>>generally fixed before unstable.
>
> No, that's not the general case. And feel free to fix stable.
> I fixed unstable because it was the right thing to do given
> that I was going to upload something to unstable.
>

You are welcomed to "feel free" to fix stable.

>> 2. Given (1), if testing version = stable version, it is as easy to
>>fix testing.
>
> This just proves that you don't know how Debian works. A fix for testing
> must come via unstable not from stable.
>

Wonders where is such a rule?

>> On the other hand, is it really necessary to have unstable migrate
>> to testing right now?
>
> It's the recommended way to get fixes in testing.
>
> This is my last answer in this thread because it's getting ridiculous.
>

Ah, ;-)

Cheers,
Aron

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-05 08:49:35 +0200, Raphael Hertzog wrote:
> On Sat, 05 Sep 2015, Vincent Lefevre wrote:
> > 2. Given (1), if testing version = stable version, it is as easy to
> >fix testing.
> 
> This just proves that you don't know how Debian works. A fix for testing
> must come via unstable not from stable.

First, I haven't said that a fix for testing must come from stable,
just that it was easy to fix testing too (because this would be the
same patch). And no, a fix for testing does not necessarily come
via unstable:

https://wiki.debian.org/Status/Testing

  From the Debian Security FAQ:

  The Debian testing security team handles issues for testing. They
  will make sure that the fixed packages enter testing in the usual
  way by migration from unstable (with reduced quarantine time), or,
  if that still takes too long, make them available via the normal
  http://security.debian.org infrastructure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

On Sat, 05 Sep 2015, Vincent Lefevre wrote:
> My argument is that:
> 
> 1. stable must not have security issues, i.e. all security issues
>should be fixed ASAP. AFAIK, security issues in stable are
>generally fixed before unstable.

No, that's not the general case. And feel free to fix stable.
I fixed unstable because it was the right thing to do given
that I was going to upload something to unstable.

> 2. Given (1), if testing version = stable version, it is as easy to
>fix testing.

This just proves that you don't know how Debian works. A fix for testing
must come via unstable not from stable.

> On the other hand, is it really necessary to have unstable migrate
> to testing right now?

It's the recommended way to get fixes in testing.

This is my last answer in this thread because it's getting ridiculous.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Guido Günther]

tags 781232 +patch
thanks

Hi Salvatore, Hi Aron,
On Mon, Aug 31, 2015 at 11:02:48AM +0200, Salvatore Bonaccorso wrote:
> Hi Aron,
> 
> Specific for the issue now seen for #781232: Looked shortly at
> https://bugzilla.gnome.org/show_bug.cgi?id=731063#c1 According to that
> comment the original patch lead to more issues (e.g.  the one which we
> see now) and more patches were applied. I have though not tried to
> skim trough to check which are required.

Attached patch resolves the libvirt related regression for me. It's a
straight cherry pick from upstream commit

beb7281055dbf0ed4d041022a67c6c5cfd126f25

Can we have this in sid please? It would also be great to have this
backported to Jessie since libvirt is there affected as well. (And yes,
I do think the severity is correct).

Cheers,
 -- Guido
>From 8bd5340bdcea5df2c0673221fdf50b52e2c4b42b Mon Sep 17 00:00:00 2001
Message-Id: <8bd5340bdcea5df2c0673221fdf50b52e2c4b42b.1441456272.git@sigxcpu.org>
From: =?UTF-8?q?Guido=20G=C3=BCnther?= 
Date: Sat, 5 Sep 2015 13:35:34 +0200
Subject: [PATCH] Fix a problem properly saving URIs

Closes: #781232
---
 debian/changelog   |   8 ++
 .../Fix-a-problem-properly-saving-URIs.patch   | 125 +
 debian/patches/series  |   1 +
 3 files changed, 134 insertions(+)
 create mode 100644 debian/patches/Fix-a-problem-properly-saving-URIs.patch

diff --git a/debian/changelog b/debian/changelog
index f7ec7e5..0c54181 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libxml2 (2.9.2+really2.9.1+dfsg1-0.2~1.gbp02bf46) UNRELEASED; urgency=medium
+
+  ** SNAPSHOT build @02bf46806799417854809144e36379558c906a6b **
+
+  * [02bf468] Fix a problem properly saving URIs (Closes: #781232)
+
+ -- Guido Günther   Sat, 05 Sep 2015 13:41:54 +0200
+
 libxml2 (2.9.2+really2.9.1+dfsg1-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/Fix-a-problem-properly-saving-URIs.patch b/debian/patches/Fix-a-problem-properly-saving-URIs.patch
new file mode 100644
index 000..71c4261
--- /dev/null
+++ b/debian/patches/Fix-a-problem-properly-saving-URIs.patch
@@ -0,0 +1,125 @@
+From: Daniel Veillard 
+Date: Fri, 3 Oct 2014 19:22:39 +0800
+Subject: Fix a problem properly saving URIs
+
+As written by Martin Kletzander :
+Since commit 8eb55d782a2b9afacc7938694891cc6fad7b42a5, when you parse
+and save an URI that has no server (or similar) part, two slashes
+after the 'schema:' get lost.  It means 'uri:///noserver' is turned
+into 'uri:/noserver'.
+
+basically
+   foo:///only/path
+
+means a host of "" while
+
+   foo:/only/path
+
+means no host at all
+
+  So the best fix IMHO is to fix the URI parser to record the first
+case and an empty host string and the second case as a NULL host string
+
+ I would not revert the initial patch, we should not 'invent' those
+slash, but we should instead when parsing keep the information that
+it's a host based path and that foo:/// means the presence of a host
+but an empty one.
+
+Once applied the resulting patch below, all cases seems to be saved
+properly:
+
+thinkpad:~/XML -> ./testURI uri:/noserver
+uri:/noserver
+thinkpad:~/XML -> ./testURI uri:///noserver
+uri:///noserver
+thinkpad:~/XML -> ./testURI uri://server/foo
+uri://server/foo
+thinkpad:~/XML -> ./testURI uri:/noserver/foo
+uri:/noserver/foo
+thinkpad:~/XML -> ./testURI uri:///
+uri:///
+thinkpad:~/XML -> ./testURI uri://
+uri://
+thinkpad:~/XML -> ./testURI uri:/
+uri:/
+thinkpad:~/XML ->
+
+  If you revert the initial patch that last case fails
+
+The problem is that I don't want to change the xmlURI structure to
+minimize ABI breakage, so I could not extend the field. The natural
+solution is to denote that uri:/// has an empty host by making
+the uri server field an empty string which works very well but breaks
+applications (like libvirt ;-) who blindly look at uri->server
+not being NULL to try to reach it !
+Simplest was to stick the port to -1 in that case, instead of 0
+application don't bother looking at the port of there is no server
+string, this makes the patch more complex than a 1 liner, but
+is better for ABI.
+
+Closes: #781232
+---
+ uri.c | 34 +++---
+ 1 file changed, 19 insertions(+), 15 deletions(-)
+
+diff --git a/uri.c b/uri.c
+index d4dcd2f..ff47abb 100644
+--- a/uri.c
 b/uri.c
+@@ -759,6 +759,8 @@ xmlParse3986HierPart(xmlURIPtr uri, const char **str)
+ cur += 2;
+ 	ret = xmlParse3986Authority(uri, );
+ 	if (ret != 0) return(ret);
++	if (uri->server == NULL)
++	uri->port = -1;
+ 	ret = xmlParse3986PathAbEmpty(uri, );
+ 	if (ret != 0) return(ret);
+ 	*str = cur;
+@@ -1106,7 +1108,7 @@ xmlSaveUri(xmlURIPtr uri) {
+ 	}
+ 	}
+ } else {
+-	if (uri->server != NULL) {
++	if ((uri->server != NULL) || (uri->port == -1)) {
+ 	if (len + 3 >= max) {
+ 

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

Control: severity 766884 serious

Please don't change the severity level and no ping-pong game please.

On Thu, Sep 3, 2015 at 3:47 PM, Raphael Hertzog  wrote:
> Control: severity 766884 important
>
> Hi Aron,
>
> please keep me in copy as I'm not subscribed to
> debian-xml-sgml-p...@lists.alioth.debian.org... I just discovered your
> reply by chance.
>
> On Mon, 31 Aug 2015, Aron Xu wrote:
>> Let's reopen #766884 for tracking, it's not really fixed, but just
>> avoided. Unfortunately #781232 is opened. I would like to block this
>> version to testing as it's not the proper way of fixing the problem
>> (but it is indeed the most straightforward way of avoiding it).
>
> Why don't you want to let this version in testing?
>
> The release team has made it clear that they prefer to have the same
> version in unstable and in testing... and the version in unstable is not
> worse than the version in testing.
>

It's not a reason that you just revert back to an older version
because it's easy to do so. If you want to make it the same version,
choose the harder but more correct way as libxml2 is not a trivial
package with low impact.

>> The proper way of working this bug around would be bisecting and
>> patching which is quite time consuming. I haven't yet managed to get
>> it done and help is welcomed, but if no one step up I'll do it
>> eventually (or cross finger for finding a proper fix, :D).
>
> Someone already did this that in the upstream bug tracker:
> https://bugzilla.gnome.org/show_bug.cgi?id=737840
>
> So if you want you can try to revert this commit:
> https://git.gnome.org/browse/libxml2/commit/?id=a16eb968075a82ec33b2c1e77db8909a35b44620
>
> But Daniel Veillard made it clear that this commit
> was not at fault, it was only making the problem visible:
> https://bugzilla.gnome.org/show_bug.cgi?id=737840#c2
>
> So yes, maybe switching to 1.9.2 and reverting this
> one would be better until a proper fix is available.
>

Yep.

> But this bug should not prevent the migration of the package to testing
> since the package in sid does not exhibit the problem currently. So
> I'm reducing its severity to important in particular since you do not seem
> to want to close it until a proper fix is available upstream.
>

I don't want to close it, nor I want make this version to testing, so
please don't lower the severity, as said above.

> I just added another commit on request of Julien Cristau.  Whatever you
> decide, you need to make a new upload so that the "icu" migration can be
> completed in unstable.
>

Thanks for that, :)

Cheers,
Aron

> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> severity 766884 serious
Bug #766884 [libxml2] libxml2: "validity error : ID ... already defined" errors 
with xmllint --noent
Bug #796031 [libxml2] publican: FTBFS: validity:513 in Test_DB5_Book.xml on 
line 11: ID We_Need_Feedback already defined
Ignoring request to change severity of Bug 766884 to the same value.
Ignoring request to change severity of Bug 796031 to the same value.

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
781232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781232
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> severity 766884 serious
Bug #766884 [libxml2] libxml2: "validity error : ID ... already defined" errors 
with xmllint --noent
Bug #796031 [libxml2] publican: FTBFS: validity:513 in Test_DB5_Book.xml on 
line 11: ID We_Need_Feedback already defined
Severity set to 'serious' from 'important'
Severity set to 'serious' from 'important'

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hello,

On Fri, 04 Sep 2015, Aron Xu wrote:
> It's not a reason that you just revert back to an older version
> because it's easy to do so. If you want to make it the same version,
> choose the harder but more correct way as libxml2 is not a trivial
> package with low impact.

Hey, don't give me lessons. I'm not the libxml2 maintainer who left
#766884 unattended since october last year...

And I announced my plans in the bug report and I had no response from
you until a few days ago.

I did not pick an easy solution, mind you, I spent multiple hours to
prepare the upload as I had to re-introduce patches that you did
push through via a testing-proposed-updades upload.

I did that because I believe that this was the correct course of action
given the lack of proper fix upsream, not because it was an easy solution.

Adding a single patch to revert the change that triggered the bug would
have been easier and in retrospect, it's probably what I should have done.
But even then it's just hiding the bug under the carpet. The real bug
is still waiting to be fixed...

> > But this bug should not prevent the migration of the package to testing
> > since the package in sid does not exhibit the problem currently. So
> > I'm reducing its severity to important in particular since you do not seem
> > to want to close it until a proper fix is available upstream.
> 
> I don't want to close it, nor I want make this version to testing, so
> please don't lower the severity, as said above.

Why don't you want this version into testing?

That doesn't forbid you to push 2.9.2 with the problematic commit reverted
later on. And have this one reach testing too.

Anything that is in unstable should go into testing, otherwise you should
use experimental.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> On Fri, 04 Sep 2015, Aron Xu wrote:
> > I don't want to close it, nor I want make this version to testing, so
> > please don't lower the severity, as said above.
> 
> Why don't you want this version into testing?

I'm not the maintainer, but I think that it is probably cleaner to
have testing version = stable version until this bug is fixed (it
would be different if testing had already diverged from stable).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hi,

On Fri, 04 Sep 2015, Vincent Lefevre wrote:
> On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> > On Fri, 04 Sep 2015, Aron Xu wrote:
> > > I don't want to close it, nor I want make this version to testing, so
> > > please don't lower the severity, as said above.
> > 
> > Why don't you want this version into testing?
> 
> I'm not the maintainer, but I think that it is probably cleaner to
> have testing version = stable version until this bug is fixed (it
> would be different if testing had already diverged from stable).

"I think it's cleaner" is a bit light in arguments.

The stable and testing versions have 3 open security issues.
The unstable one has none. 

https://security-tracker.debian.org/tracker/source-package/libxml2

And for the rest, both versions are almost identical:
$ debdiff libxml2_2.9.1+dfsg1-5.dsc libxml2_2.9.2+really2.9.1+dfsg1-0.1.dsc 
|diffstat
 changelog   |   46 
++
 control |9 
 libxml2.symbols |8 
 patches/0056-Stop-parsing-on-entities-boundaries-errors.patch   |   28 
+
 patches/0057-Cleanup-conditional-section-error-handling.patch   |   45 
++
 patches/0058-Fix-upstream-bug-299127.patch  |   99 
+
 patches/0059-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch |  172 
++
 patches/series  |4 
 rules   |4 
 9 files changed, 405 insertions(+), 10 deletions(-)

So why would you want to keep a version that fixes 3 security issues out of
testing?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-04 21:36:53 +0200, Raphael Hertzog wrote:
> On Fri, 04 Sep 2015, Vincent Lefevre wrote:
> > On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> > > On Fri, 04 Sep 2015, Aron Xu wrote:
> > > > I don't want to close it, nor I want make this version to testing, so
> > > > please don't lower the severity, as said above.
> > > 
> > > Why don't you want this version into testing?
> > 
> > I'm not the maintainer, but I think that it is probably cleaner to
> > have testing version = stable version until this bug is fixed (it
> > would be different if testing had already diverged from stable).
> 
> "I think it's cleaner" is a bit light in arguments.
> 
> The stable and testing versions have 3 open security issues.
> The unstable one has none. 

My argument is that:

1. stable must not have security issues, i.e. all security issues
   should be fixed ASAP. AFAIK, security issues in stable are
   generally fixed before unstable.

2. Given (1), if testing version = stable version, it is as easy to
   fix testing.

On the other hand, is it really necessary to have unstable migrate
to testing right now?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

On Saturday, September 5, 2015, Raphael Hertzog  wrote:

> Hi,
>
> On Fri, 04 Sep 2015, Vincent Lefevre wrote:
> > On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> > > On Fri, 04 Sep 2015, Aron Xu wrote:
> > > > I don't want to close it, nor I want make this version to testing, so
> > > > please don't lower the severity, as said above.
> > >
> > > Why don't you want this version into testing?
> >
> > I'm not the maintainer, but I think that it is probably cleaner to
> > have testing version = stable version until this bug is fixed (it
> > would be different if testing had already diverged from stable).
>
> "I think it's cleaner" is a bit light in arguments.
>
> The stable and testing versions have 3 open security issues.
> The unstable one has none.
>
> https://security-tracker.debian.org/tracker/source-package/libxml2
>
>
Then please help fix stable instead of rushing in unstable.

Cheers,
Aron


>

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Control: severity 766884 important

Hi Aron,

please keep me in copy as I'm not subscribed to
debian-xml-sgml-p...@lists.alioth.debian.org... I just discovered your
reply by chance.

On Mon, 31 Aug 2015, Aron Xu wrote:
> Let's reopen #766884 for tracking, it's not really fixed, but just
> avoided. Unfortunately #781232 is opened. I would like to block this
> version to testing as it's not the proper way of fixing the problem
> (but it is indeed the most straightforward way of avoiding it).

Why don't you want to let this version in testing?

The release team has made it clear that they prefer to have the same
version in unstable and in testing... and the version in unstable is not
worse than the version in testing.

> The proper way of working this bug around would be bisecting and
> patching which is quite time consuming. I haven't yet managed to get
> it done and help is welcomed, but if no one step up I'll do it
> eventually (or cross finger for finding a proper fix, :D).

Someone already did this that in the upstream bug tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=737840

So if you want you can try to revert this commit:
https://git.gnome.org/browse/libxml2/commit/?id=a16eb968075a82ec33b2c1e77db8909a35b44620

But Daniel Veillard made it clear that this commit
was not at fault, it was only making the problem visible:
https://bugzilla.gnome.org/show_bug.cgi?id=737840#c2

So yes, maybe switching to 1.9.2 and reverting this
one would be better until a proper fix is available.

But this bug should not prevent the migration of the package to testing
since the package in sid does not exhibit the problem currently. So
I'm reducing its severity to important in particular since you do not seem
to want to close it until a proper fix is available upstream.

I just added another commit on request of Julien Cristau.  Whatever you
decide, you need to make a new upload so that the "icu" migration can be
completed in unstable.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> severity 766884 important
Bug #766884 [libxml2] libxml2: "validity error : ID ... already defined" errors 
with xmllint --noent
Bug #796031 [libxml2] publican: FTBFS: validity:513 in Test_DB5_Book.xml on 
line 11: ID We_Need_Feedback already defined
Severity set to 'important' from 'grave'
Severity set to 'important' from 'grave'

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

Control: reopen 766884

Let's reopen #766884 for tracking, it's not really fixed, but just
avoided. Unfortunately #781232 is opened. I would like to block this
version to testing as it's not the proper way of fixing the problem
(but it is indeed the most straightforward way of avoiding it).

Maintenance status of libxml2 upstream is a little bit complicated
because the code base tend to have quite some issues that can easily
trigger new bugs, so that fix for one particular bug may lead to
another new one. Reverting to older version isn't a solution because I
believe not all of the memory related fixes can be ignored even for
the case of security, that's the reason why I tend to carry quite a
lot of patches for stable releases.

The proper way of working this bug around would be bisecting and
patching which is quite time consuming. I haven't yet managed to get
it done and help is welcomed, but if no one step up I'll do it
eventually (or cross finger for finding a proper fix, :D).


Thanks,
Aron


On Wed, Aug 26, 2015 at 5:52 AM, Raphael Hertzog  wrote:
> Hi,
>
> On Thu, 20 Aug 2015, Vincent Lefevre wrote:
>> I completely agree that libxml2 should be reverted to 2.9.1 (I have
>> never used 2.9.2 due to this bug).
>
> I just did this.
>
>> And IMHO, the new package should probably break libxml-libxml-perl
>> 2.0116+dfsg-4 due to an annoying and useless test of the versions
>> in the Perl module (bug 783610). So, libxml-libxml-perl should be
>> rebuilt against libxml2 2.9.1, which would make bug 783610 no longer
>> appear in most cases.
>
> But not this. We should just ask for bin-NMU of libxml-libxml-perl once
> the new libxml2 is built. Can you take care of this?
>
> https://wiki.debian.org/binNMU
>
> (You can do it immediately if you combine it with appropriate dep-wait)
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> reopen 766884
Bug #766884 {Done: Raphaël Hertzog } [libxml2] libxml2: 
"validity error : ID ... already defined" errors with xmllint --noent
Bug #796031 {Done: Raphaël Hertzog } [libxml2] publican: 
FTBFS: validity:513 in Test_DB5_Book.xml on line 11: ID We_Need_Feedback 
already defined
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions libxml2/2.9.2+really2.9.1+dfsg1-0.1.
No longer marked as fixed in versions libxml2/2.9.2+really2.9.1+dfsg1-0.1.

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> reopen 766884
Bug #766884 [libxml2] libxml2: "validity error : ID ... already defined" errors 
with xmllint --noent
Bug #796031 [libxml2] publican: FTBFS: validity:513 in Test_DB5_Book.xml on 
line 11: ID We_Need_Feedback already defined
Bug 766884 is not marked as done; doing nothing.

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
781232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781232
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Salvatore Bonaccorso]

Hi Aron,

Specific for the issue now seen for #781232: Looked shortly at
https://bugzilla.gnome.org/show_bug.cgi?id=731063#c1 According to that
comment the original patch lead to more issues (e.g.  the one which we
see now) and more patches were applied. I have though not tried to
skim trough to check which are required.

Regards,
Salvatore

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hi,

On Thu, 20 Aug 2015, Vincent Lefevre wrote:
 I completely agree that libxml2 should be reverted to 2.9.1 (I have
 never used 2.9.2 due to this bug).

I just did this.

 And IMHO, the new package should probably break libxml-libxml-perl
 2.0116+dfsg-4 due to an annoying and useless test of the versions
 in the Perl module (bug 783610). So, libxml-libxml-perl should be
 rebuilt against libxml2 2.9.1, which would make bug 783610 no longer
 appear in most cases.

But not this. We should just ask for bin-NMU of libxml-libxml-perl once
the new libxml2 is built. Can you take care of this?

https://wiki.debian.org/binNMU

(You can do it immediately if you combine it with appropriate dep-wait)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hello libxml2 maintainers,

I'm somewhat annoyed at the fact that libxml2 has been broken for months
with the bug 766884. It does not look like upstream will fix it soon.
In the mean time we have unbuildable packages in sid (I'm affected with
publican) so I would like you to consider uploading a
2.9.2+really2.9.1+dfsg1 to revert to the older upstream version until this
bug can be fixed upstream.

Can you take care of that? Do you want someone else to handle it?

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-08-20 13:54:49 +0200, Raphael Hertzog wrote:
 Hello libxml2 maintainers,
 
 I'm somewhat annoyed at the fact that libxml2 has been broken for months
 with the bug 766884. It does not look like upstream will fix it soon.
 In the mean time we have unbuildable packages in sid (I'm affected with
 publican) so I would like you to consider uploading a
 2.9.2+really2.9.1+dfsg1 to revert to the older upstream version until this
 bug can be fixed upstream.

I completely agree that libxml2 should be reverted to 2.9.1 (I have
never used 2.9.2 due to this bug).

And IMHO, the new package should probably break libxml-libxml-perl
2.0116+dfsg-4 due to an annoying and useless test of the versions
in the Perl module (bug 783610). So, libxml-libxml-perl should be
rebuilt against libxml2 2.9.1, which would make bug 783610 no longer
appear in most cases.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)