Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #365319 > unrolled thread

Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’

Back to article view | Back to linux.debian.bugs.rc

Contents

  Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’ Lucas Nussbaum <lucas@debian.org> - 2024-06-16 15:00 +0200
    Processed: Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22:  error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’ "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-16 18:50 +0200
    Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’ Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-06-16 19:10 +0200
    Bug#1073313: another libxml2 ABI break, might need RM attention (Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’) Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-06-16 19:20 +0200
    Bug#1073508: libxml2: just another API+ABI break; please bump soname Aron Xu <aron@debian.org> - 2024-06-17 09:50 +0200
      Bug#1073508: libxml2: just another API+ABI break; please bump soname Thorsten Glaser <t.glaser@qvest-digital.com> - 2024-06-17 16:50 +0200
    Processed: Re: libxml2: just another API+ABI break; please bump  soname "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-17 09:50 +0200
    Bug#1073313: marked as done (gnustep-base: FTBFS: GSXML.m:2674:22:  error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-19 11:30 +0200
    Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-11 16:30 +0200
      Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Bo YU <tsu.yubo@gmail.com> - 2024-08-16 09:50 +0200
    Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-17 08:30 +0200
    Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue Aron Xu <aron@debian.org> - 2024-08-17 14:10 +0200

#365319 — Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’

Source: gnustep-base
Version: 1.29.0-7
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lucas@debian.org
Usertags: ftbfs-20240615 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> gcc GSXML.m -c \
>       -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wdeclaration-after-statement -DNO_GNUSTEP=1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fconstant-string-class=NSConstantString -I../. -I../ -I../../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/local/include/GNUstep -I/usr/local/include/GNUstep -I/usr/include/GNUstep -I/usr/include/libxml2 -I/usr/include/libxml2 -I/usr/include/p11-kit-1 \
>        -o obj/Additions.obj/GSXML.m.o
> GSXML.m: In function ‘getEntityDefault’:
> GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
>  2674 |               if (ret->checked == 0)
>       |                      ^~
> GSXML.m:2676:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
>  2676 |                   ret->checked = 1;
>       |                      ^~
> GSXML.m: In function ‘hasInternalSubsetFunction’:
> GSXML.m:2968:7: warning: ‘__htmlDefaultSAXHandler’ is deprecated [-Wdeprecated-declarations]
>  2968 |       has = TREEFUN(hasInternalSubset, (ctx));
>       |       ^~~
> In file included from /usr/include/libxml2/libxml/parser.h:13,
>                  from /usr/include/libxml2/libxml/tree.h:17,
>                  from GSXML.m:82:
> /usr/include/libxml2/libxml/xmlversion.h:499:27: note: declared here
>   499 |     attrs XMLPUBFUN type *__##name(void);
>       |                           ^~
> /usr/include/libxml2/libxml/HTMLparser.h:91:16: note: in expansion of macro ‘XML_DECLARE_GLOBAL’
>    91 | #define XML_OP XML_DECLARE_GLOBAL
>       |                ^~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/HTMLparser.h:86:5: note: in expansion of macro ‘XML_OP’
>    86 |     XML_OP(htmlDefaultSAXHandler, xmlSAXHandlerV1, XML_DEPRECATED)
>       |     ^~~~~~
> /usr/include/libxml2/libxml/HTMLparser.h:92:1: note: in expansion of macro ‘XML_GLOBALS_HTML’
>    92 | XML_GLOBALS_HTML
>       | ^~~~~~~~~~~~~~~~
> GSXML.m:2968:7: warning: ‘__xmlDefaultSAXHandler’ is deprecated [-Wdeprecated-declarations]
>  2968 |       has = TREEFUN(hasInternalSubset, (ctx));
>       |       ^~~
> /usr/include/libxml2/libxml/xmlversion.h:499:27: note: declared here
>   499 |     attrs XMLPUBFUN type *__##name(void);
>       |                           ^~
> /usr/include/libxml2/libxml/parser.h:885:16: note: in expansion of macro ‘XML_DECLARE_GLOBAL’
>   885 | #define XML_OP XML_DECLARE_GLOBAL
>       |                ^~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/parser.h:875:5: note: in expansion of macro ‘XML_OP’
>   875 |     XML_OP(xmlDefaultSAXHandler, xmlSAXHandlerV1, XML_DEPRECATED)
>       |     ^~~~~~
> /usr/include/libxml2/libxml/parser.h:883:3: note: in expansion of macro ‘XML_GLOBALS_PARSER_SAX1’
>   883 |   XML_GLOBALS_PARSER_SAX1
>       |   ^~~~~~~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/parser.h:886:1: note: in expansion of macro ‘XML_GLOBALS_PARSER’
>   886 | XML_GLOBALS_PARSER
>       | ^~~~~~~~~~~~~~~~~~
> GSXML.m: In function ‘hasExternalSubsetFunction’:
> GSXML.m:2982:7: warning: ‘__htmlDefaultSAXHandler’ is deprecated [-Wdeprecated-declarations]
>  2982 |       has = TREEFUN(hasExternalSubset, (ctx));
>       |       ^~~
> /usr/include/libxml2/libxml/xmlversion.h:499:27: note: declared here
>   499 |     attrs XMLPUBFUN type *__##name(void);
>       |                           ^~
> /usr/include/libxml2/libxml/HTMLparser.h:91:16: note: in expansion of macro ‘XML_DECLARE_GLOBAL’
>    91 | #define XML_OP XML_DECLARE_GLOBAL
>       |                ^~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/HTMLparser.h:86:5: note: in expansion of macro ‘XML_OP’
>    86 |     XML_OP(htmlDefaultSAXHandler, xmlSAXHandlerV1, XML_DEPRECATED)
>       |     ^~~~~~
> /usr/include/libxml2/libxml/HTMLparser.h:92:1: note: in expansion of macro ‘XML_GLOBALS_HTML’
>    92 | XML_GLOBALS_HTML
>       | ^~~~~~~~~~~~~~~~
> GSXML.m:2982:7: warning: ‘__xmlDefaultSAXHandler’ is deprecated [-Wdeprecated-declarations]
>  2982 |       has = TREEFUN(hasExternalSubset, (ctx));
>       |       ^~~
> /usr/include/libxml2/libxml/xmlversion.h:499:27: note: declared here
>   499 |     attrs XMLPUBFUN type *__##name(void);
>       |                           ^~
> /usr/include/libxml2/libxml/parser.h:885:16: note: in expansion of macro ‘XML_DECLARE_GLOBAL’
>   885 | #define XML_OP XML_DECLARE_GLOBAL
>       |                ^~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/parser.h:875:5: note: in expansion of macro ‘XML_OP’
>   875 |     XML_OP(xmlDefaultSAXHandler, xmlSAXHandlerV1, XML_DEPRECATED)
>       |     ^~~~~~
> /usr/include/libxml2/libxml/parser.h:883:3: note: in expansion of macro ‘XML_GLOBALS_PARSER_SAX1’
>   883 |   XML_GLOBALS_PARSER_SAX1
>       |   ^~~~~~~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/parser.h:886:1: note: in expansion of macro ‘XML_GLOBALS_PARSER’
>   886 | XML_GLOBALS_PARSER
>       | ^~~~~~~~~~~~~~~~~~
> GSXML.m: In function ‘-[GSHTMLSAXHandler _initLibXML]’:
> GSXML.m:3865:7: warning: ‘__htmlDefaultSAXHandler’ is deprecated [-Wdeprecated-declarations]
>  3865 |       memcpy(lib, &htmlDefaultSAXHandler, sizeof(htmlSAXHandler));
>       |       ^~~~~~
> /usr/include/libxml2/libxml/xmlversion.h:499:27: note: declared here
>   499 |     attrs XMLPUBFUN type *__##name(void);
>       |                           ^~
> /usr/include/libxml2/libxml/HTMLparser.h:91:16: note: in expansion of macro ‘XML_DECLARE_GLOBAL’
>    91 | #define XML_OP XML_DECLARE_GLOBAL
>       |                ^~~~~~~~~~~~~~~~~~
> /usr/include/libxml2/libxml/HTMLparser.h:86:5: note: in expansion of macro ‘XML_OP’
>    86 |     XML_OP(htmlDefaultSAXHandler, xmlSAXHandlerV1, XML_DEPRECATED)
>       |     ^~~~~~
> /usr/include/libxml2/libxml/HTMLparser.h:92:1: note: in expansion of macro ‘XML_GLOBALS_HTML’
>    92 | XML_GLOBALS_HTML
>       | ^~~~~~~~~~~~~~~~
> gcc GSFunctions.m -c \
>       -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wdeclaration-after-statement -DNO_GNUSTEP=1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fconstant-string-class=NSConstantString -I../. -I../ -I../../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/local/include/GNUstep -I/usr/local/include/GNUstep -I/usr/include/GNUstep -I/usr/include/libxml2 -I/usr/include/libxml2 -I/usr/include/p11-kit-1 \
>        -o obj/Additions.obj/GSFunctions.m.o
> make[6]: *** [/usr/share/GNUstep/Makefiles/rules.make:534: obj/Additions.obj/GSXML.m.o] Error 1


The full build log is available from:
http://qa-logs.debian.net/2024/06/15/gnustep-base_1.29.0-7_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240615;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20240615&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

[toc] | [next] | [standalone]

#365395 — Processed: Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’

Processing control commands:

> fixed -1 1.30.0-1
Bug #1073313 [src:gnustep-base] gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
Marked as fixed in versions gnustep-base/1.30.0-1.
> tags -1 + pending
Bug #1073313 [src:gnustep-base] gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
Added tag(s) pending.

-- 
1073313: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073313
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#365397

On Sun, 16 Jun 2024, Yavor Doganov wrote:

>IMVHO removing a public struct member constitutes an API break.

Definitely. I just took a peek at this.

>It is also an ABI break, because if a program or a library accesses
>such member and is compiled against an old libxml2 version that is
>supposed to be ABI-compatible (like 2.9.14+dfsg-1.3 in trixie), it
>will crash at runtime with the new library version.

I thought “could be, could be not” from:

@@ -56,10 +58,8 @@ struct _xmlEntity {
     struct _xmlEntity     *nexte;      /* unused */
     const xmlChar           *URI;      /* the full URI as computed */
     int                    owner;      /* does the entity own the childrens */
-    int                         checked;       /* was the entity content checked */
-                                       /* this is also used to count entities
-                                        * references done from that entity
-                                        * and if it contains '<' */
+    int                    flags;       /* various flags */
+    unsigned long   expandedSize;       /* expanded size */
 };
 
 /*

… but then I looked at the git history and saw:

commit f34f184f8e957e6f9a6eda9859ce85e883c77e5f
Author: Nick Wellnhofer <wellnhofer@aevum.de>
Date:   Mon Dec 19 15:24:53 2022 +0100

    entities: Add "flags" member to struct xmlEntity
    
    This will hold various flags and eventually replace the "checked"
    member.

[…]
--- a/include/libxml/entities.h
+++ b/include/libxml/entities.h
@@ -60,6 +60,7 @@ struct _xmlEntity {
                                        /* this is also used to count entities
                                         * references done from that entity
                                         * and if it contains '<' */
+    int                    flags;       /* various flags */
 };
 
 /*

This is not the first time in *very* recent history that libxml2
has an ABI break (e.g. LibreOffice ran into that), and… I wonder
what kind of shitshow upstream runs when they commit things like
that‽

commit ce76ebfd1312459951d555ad9d87fb9a89eede55
Author: Nick Wellnhofer <wellnhofer@aevum.de>
Date:   Mon Dec 19 20:56:23 2022 +0100

    entities: Stop counting entities
    
    This was only used in the old version of xmlParserEntityCheck.

[…]
--- a/include/libxml/entities.h
+++ b/include/libxml/entities.h
@@ -56,10 +56,6 @@ struct _xmlEntity {
     struct _xmlEntity     *nexte;      /* unused */
     const xmlChar           *URI;      /* the full URI as computed */
     int                    owner;      /* does the entity own the childrens */
-    int                         checked;       /* was the entity content checked */
-                                       /* this is also used to count entities
-                                        * references done from that entity
-                                        * and if it contains '<' */
     int                    flags;       /* various flags */
     unsigned long   expandedSize;       /* expanded size */
 };

Looking at the other context in that commit, the “flags” member
definitely does *not* replace the “checked” member in a compatible
way. Rather, the functionality that used to be behind “checked”
is gone in its entirety.

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

[toc] | [prev] | [next] | [standalone]

#365399 — Bug#1073313: another libxml2 ABI break, might need RM attention (Re: Bug#1073313: gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’)

On Sun, 16 Jun 2024, Thorsten Glaser wrote:

>Better prevent this from landing in trixie until the package
>gets its soname bumped.

In fact, unless someone has the tuits to diff every single
API and ABI surface of the package between trixie (ideally
bookworm) and sid versions, it would be best if any package
built against libxml2 >2.12 be binNMU’d in trixie, and once
2.12 is renamed to libxml3 or something, they are to be rebuilt
in sid anyway.

Who knows what other API and ABI breaks are hiding herein…

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

[toc] | [prev] | [next] | [standalone]

#365435 — Bug#1073508: libxml2: just another API+ABI break; please bump soname

Control: tags -1 - pending

Hi,

On Sun, 16 Jun 2024 19:10:57 +0200 (CEST) Thorsten Glaser
<t.glaser@qvest-digital.com> wrote:
> On Sun, 16 Jun 2024, Thorsten Glaser wrote:
>
> >Better prevent this from landing in trixie until the package
> >gets its soname bumped.
>
> In fact, unless someone has the tuits to diff every single
> API and ABI surface of the package between trixie (ideally
> bookworm) and sid versions, it would be best if any package
> built against libxml2 >2.12 be binNMU’d in trixie, and once
> 2.12 is renamed to libxml3 or something, they are to be rebuilt
> in sid anyway.
>
> Who knows what other API and ABI breaks are hiding herein…
>
> bye,
> //mirabilos
>

It looks that this libxml2 update is causing more troubles than
expected, I would like to ask for your opinion whether it's better to
revert to an older version for the moment?

The LibreOffice break stuff isn't a real API/ABI break, it was caused
by default build options being changed so that some features were
intentionally disabled by upstream... I can try to dig further about
the surface of API/ABI changes, but I have to say that would take some
time to complete.

Thanks,
Aron

[toc] | [prev] | [next] | [standalone]

#365450 — Bug#1073508: libxml2: just another API+ABI break; please bump soname

On Mon, 17 Jun 2024, Aron Xu wrote:

>Control: tags -1 - pending

Oops, right.

>It looks that this libxml2 update is causing more troubles than
>expected, I would like to ask for your opinion whether it's better to
>revert to an older version for the moment?

Might be useful while you ask upstream what they’re doing there
with regards to both API and ABI, and/or someone diffs the API
and ABI surface of the old and new version and figures out whether
there are any other such surprises. Security fixes might need
backporting though.

Maybe they haven’t realised themselves and decide they need to
bump to libxml3 upstream at some point.

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

[toc] | [prev] | [next] | [standalone]

#365436 — Processed: Re: libxml2: just another API+ABI break; please bump soname

Processing control commands:

> tags -1 - pending
Bug #1073508 [libxml2] libxml2: just another API+ABI break; please bump soname
Removed tag(s) pending.

-- 
1073508: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073508
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#365560 — Bug#1073313: marked as done (gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Wed, 19 Jun 2024 09:19:43 +0000
with message-id <E1sJrTj-004oun-5s@fasolo.debian.org>
and subject line Bug#1073313: fixed in gnustep-base 1.29.0-8
has caused the Debian Bug report #1073313,
regarding gnustep-base: FTBFS: GSXML.m:2674:22: error: ‘xmlEntity’ {aka ‘struct _xmlEntity’} has no member named ‘checked’
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1073313: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073313
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#369464 — Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

Hi,

On Sun, Aug 11, 2024 at 10:21 PM Paul Gevers <elbrus@debian.org> wrote:
>
> Hi Aron,
>
> On 14-07-2024 07:37, Paul Gevers wrote:
> > On 28-06-2024 5:44 a.m., Aron Xu wrote:
> >> Would like to know if such steps would help resolve the issue better:
> >>   - revert to a previous version which does not have API/ABI breakage
> >>   - apply/port security patches on a best effort basis
> >>   - help upstream to check and fix API/ABI changes
> >
> > I think all three would help, where the first one is the quickest one to
> > get things moving again. Given the severity of the security issue
> > mentioned in the changelog I think you could even consider ignoring item
> > number two for now, but maybe you mean going forward.
> >
> >> Or do you have any recommendations?
> >
> > There is the option to do a Debian specific SONAME bump, but if the
> > break was not intended and might get reverted that's probably a bad
> > idea. And if the changes are here to stay, upstream should bump SONAME
> > themselves.
>
> While the upstream bug about the soname breakage seems to have halted,
> can we please get some resolution in Debian please? The fact that
> libxml2 can't migrate as-is is hurting more and more (particularly the
> creation of a useful testing for riscv64).
>
> If upstream is really reluctant to bump SONAME when they should, maybe
> you should prepare for a maintenance scheme to do that in Debian when
> needed. Ideally the scheme should be designed such that when upstream
> bumps SONAME, you can follow them again.
>

Thanks for pinging again!

I was busy with $dayjob during the last week, will come up with a
solution this week and possibly talk to you on IRC/email about my
plan.

Regards,
Aron

[toc] | [prev] | [next] | [standalone]

#369861 — Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

[Multipart message — attachments visible in raw view] — view raw

Hi,
On Sun, Aug 11, 2024 at 10:23:43PM +0800, Aron Xu wrote:
>Hi,
>
>On Sun, Aug 11, 2024 at 10:21 PM Paul Gevers <elbrus@debian.org> wrote:
>>
>> Hi Aron,
>>
>> On 14-07-2024 07:37, Paul Gevers wrote:
>> > On 28-06-2024 5:44 a.m., Aron Xu wrote:
>> >> Would like to know if such steps would help resolve the issue better:
>> >>   - revert to a previous version which does not have API/ABI breakage
>> >>   - apply/port security patches on a best effort basis
>> >>   - help upstream to check and fix API/ABI changes
>> >
>> > I think all three would help, where the first one is the quickest one to
>> > get things moving again. Given the severity of the security issue
>> > mentioned in the changelog I think you could even consider ignoring item
>> > number two for now, but maybe you mean going forward.
>> >
>> >> Or do you have any recommendations?
>> >
>> > There is the option to do a Debian specific SONAME bump, but if the
>> > break was not intended and might get reverted that's probably a bad
>> > idea. And if the changes are here to stay, upstream should bump SONAME
>> > themselves.
>>
>> While the upstream bug about the soname breakage seems to have halted,
>> can we please get some resolution in Debian please? The fact that
>> libxml2 can't migrate as-is is hurting more and more (particularly the
>> creation of a useful testing for riscv64).
>>
>> If upstream is really reluctant to bump SONAME when they should, maybe
>> you should prepare for a maintenance scheme to do that in Debian when
>> needed. Ideally the scheme should be designed such that when upstream
>> bumps SONAME, you can follow them again.
>>
>
>Thanks for pinging again!
>
>I was busy with $dayjob during the last week, will come up with a
>solution this week and possibly talk to you on IRC/email about my
>plan.

If there is a lot of more extra work here, I am happy to take on some
work if I can help.

Thanks,

BR,
Bo

>
>Regards,
>Aron
>

-- 
Regards,
--
   Bo YU

[toc] | [prev] | [next] | [standalone]

#369926 — Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 17, 2024 at 2:06 PM Rene Engelhard <rene@debian.org> wrote:
>
> Hi,
>
> Am 17.08.24 um 05:58 schrieb Aron Xu:
> > After some research, I prefer making a t64-like transition for libxml2
> > for the following reasons:
> >   - Upstream is not prepared to bump the SONAME to something like
> > libxml3. Given the long history of this function library, determining
> > which APIs should be public and which should be private is
> > challenging.
> > [...]
> > I've prepared a preliminary debdiff and tested locally. What do you think?
> -       dh_makeshlibs -plibxml2 -V 'libxml2 (>= 2.9.11)' -- -c4
> +       dh_makeshlibs -plibxml2n -V 'libxml2 (>= 2.9.11)' -- -c4
>
> Look wrong to me, should be libxml2 in the version, too.
>
>
> --- libxml2-2.13.3+dfsg/debian/libxml2n.symbols 1970-01-01 08:00:00.000000000 +0800
> +++ libxml2-2.13.3+dfsg/debian/libxml2n.symbols 2024-08-16 22:13:37.000000000 +0800
> @@ -0,0 +1,146 @@
> +libxml2.so.2 libxml2 #MINVER#
> [...]
>
> here, too.
>
>
> Otherwise stuff built against the NEW ABI still gets dependencies fullfillable by old ones.
>

OK for the above two.

>
> For the same reason
>
> +Provides: libxml2 (= ${binary:Version})
>
> is bad, that is the other way round and stuff using the old ABI will happily install with libxml2n.
>
> (That Provides: was there in t64 where the ABI didn't change, aka all 64bit + i386)
>

This was stealed from ${t64:Provides} and I agree should be dropped here.

>
> And I *think* you need Breaks/Conflicts in addition to Replaces at the new libxml2n.
>

There is a Breaks, one line above Replaces, "libxml2 (<< ${source:Version}),".

So I'm attaching an updated debdiff, with an additional fix to
lintian-overrides.

Regards,
Aron

[toc] | [prev] | [next] | [standalone]

#369948 — Bug#1073508: Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue

On Sat, Aug 17, 2024 at 5:15 PM Paul Gevers <elbrus@debian.org> wrote:
>
> Hi,
>
> [Disclaimer: I'm not the most experienced person on transitions in the
> team, so I'd like for Graham, Emilio and/or Sebastian to check if they
> agree with me.]
>
> Thanks for working on this.
>
> On 17-08-2024 05:58, Aron Xu wrote:
> > After some research, I prefer making a t64-like transition for libxml2
> > for the following reasons:
>
> I'm a bit curious in how far you think this looks like a t64-like
> transition as apposed to a regular c-library transition. Is it because
> the libraries will not be co-installable, you don't bump SONAME and just
> rename the binary package name? Even with all the work that went into
> the t64 transition, we're starting to see hidden bugs [0] (although I
> think this can happen with any transition).
>

Doing this through a t64-like transition would:
1. Make package build with new libxml2 depends on new package
2. Still potentially break user built binaries using older versions

The most undetectable bugs are lying in binaries using data types that
have changed, which is not tracked by upstream.

> >   - Upstream is not prepared to bump the SONAME to something like
> > libxml3. Given the long history of this function library, determining
> > which APIs should be public and which should be private is
> > challenging.
>
> That's why earlier I proposed a Debian specific SONAME, "in between" 2
> and 3. Upstream (I think) even suggested that [1].
>

I'm not sure whether upstream really means everyone should really make
their own SONAME, I think it's more like a disclaimer that it's not
his opinion to bump SONAME but feel free if there are people who
insist on doing so.


> >   - The potential for breaking locally built software is minimal.
> > Although abi-compliance-checker raises many issues, most of them are
> > not used in the real world.
>
> Isn't the fact that we *caught* an issue in Debian the proof that it's
> not just academic?
>

And it is a case of accessing changed data type, which is the case not
tracked by upstream.

> >   - This approach is significantly easier and safer.
>
> I'm hesitant because we have well established procedures to handle ABI
> breakage with SONAME bumps and how to handle them in Debian. Can you
> elaborate on the easier and safer parts? Because I mostly see risks to
> deviate from established paths as the corner cases on them are less known.
>

Well I would like to know if it's really desirable to divert from
upstream, to bump to something like libxml2.1?

> > I've prepared a preliminary debdiff and tested locally. What do you think?
>
> Also just curious, why the letter n?

This is just picked randomly.

>
> Paul
>
> [0] https://lists.debian.org/msgid-search/Zr57AYhXiL3oi8_d@per
> [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/751#note_2157870
> (second to last paragraph)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web