[opensuse-factory] openSUSE:Factory - Build fail notification
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at
least 4 weeks. We tried to send out notifications to the
configured bugowner/maintainers of the package(s), but so far no
fix has been submitted. This probably means that the
maintainer/bugowner did not yet find the time to look into the
matter and he/she would certainly appreciate help to get this
sorted.
- gdcm
Unless somebody is stepping up and submitting fixes, the listed
package(s) are going to be removed from openSUSE:Factory.
Kind regards,
DimStar / Dominique Leuenberger
Am Sonntag, 29. März 2020, 00:06:43 CEST schrieb DimStar / Dominique Leuenberger:
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted.
- gdcm
The reason is an API change in a newer version of poppler - that breaks it in TW, but not for Leap. The issue was already reported in Feb to the developer (who did not notice as Debian uses an even older version of poppler). What do you suggest? Any C++ Expert willing to support? Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020/03/29 09:56:22 +0200, Axel Braun wrote:
Am Sonntag, 29. März 2020, 00:06:43 CEST schrieb DimStar / Dominique Leuenberger:
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted.
- gdcm
The reason is an API change in a newer version of poppler - that breaks it in TW, but not for Leap. The issue was already reported in Feb to the developer (who did not notice as Debian uses an even older version of poppler).
Do not use poppler as its API is unstable. And upstream of poppler do not care about others. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
On Sonntag, 29. März 2020 11:21:10 CEST Dr. Werner Fink wrote:
Do not use poppler as its API is unstable. And upstream of poppler do not care about others.
Cut the crap. You have already been told there is a stable API. If programs choose to use private interfaces, its their fault. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Sunday 2020-03-29 12:46, Stefan Brüns wrote:
On Sonntag, 29. März 2020 11:21:10 CEST Dr. Werner Fink wrote:
Do not use poppler as its API is unstable. And upstream of poppler do not care about others.
Cut the crap.
You have already been told there is a stable API. If programs choose to use private interfaces, its their fault.
Qt uses symbol versions to mark its private symbols with the ASCII (sub)string "_PRIVATE", which will then show up in rpm error messages everytime someone fucks up. poppler could try doing the same. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29. 03. 20, 13:56, Jan Engelhardt wrote:
On Sunday 2020-03-29 12:46, Stefan Brüns wrote:
On Sonntag, 29. März 2020 11:21:10 CEST Dr. Werner Fink wrote:
Do not use poppler as its API is unstable. And upstream of poppler do not care about others.
Cut the crap.
You have already been told there is a stable API. If programs choose to use private interfaces, its their fault.
Is Parser or LinkDest a private API? And if so, kill it from public headers.
Qt uses symbol versions to mark its private symbols with the ASCII (sub)string "_PRIVATE", which will then show up in rpm error messages everytime someone fucks up.
And if they are going to use symbol versioning, they can as well mark the symbols as local to be completely invisible... regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2020-03-30 11:13, Jiri Slaby wrote:
On 29. 03. 20, 13:56, Jan Engelhardt wrote:
On Sunday 2020-03-29 12:46, Stefan Brüns wrote:
On Sonntag, 29. März 2020 11:21:10 CEST Dr. Werner Fink wrote:
Do not use poppler as its API is unstable. And upstream of poppler do not care about others.
Cut the crap.
You have already been told there is a stable API. If programs choose to use private interfaces, its their fault.
Is Parser or LinkDest a private API?
And if so, kill it from public headers.
Qt uses symbol versions to mark its private symbols with the ASCII (sub)string "_PRIVATE", which will then show up in rpm error messages everytime someone fucks up.
And if they are going to use symbol versioning, they can as well mark the symbols as local to be completely invisible...
No they cannot. This is C++, and if you have public-interface public-API inline functions that reference private-interface private-API functions, they still need to be exported at the ELF level to be invokable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2020-03-30 11:23, Jan Engelhardt wrote:
Qt uses symbol versions to mark its private symbols with the ASCII (sub)string "_PRIVATE", which will then show up in rpm error messages everytime someone fucks up.
And if they are going to use symbol versioning, they can as well mark the symbols as local to be completely invisible...
No they cannot. This is C++, and if you have public-interface public-API inline functions that reference private-interface private-API functions, they still need to be exported at the ELF level to be invokable.
To be more clear, what I intended to say is "(documented as public) API" class public inline member function invoking a "(documented as private) API" class public/protected/private non-virtual non-inline member function. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 30, Jan Engelhardt wrote:
No they cannot. This is C++, and if you have public-interface public-API inline functions that reference private-interface private-API functions, they still need to be exported at the ELF level to be invokable.
You cannot use a private API from public inline functions. Either the inline functions needs to be private, too, or the private API needs to be public. Everything else will never work with inline functions, it's clearly a design and library bug. Or don't make this functions inline. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In openSUSE we build poppler with passing ENABLE_UNSTABLE_API_ABI_HEADERS=ON (was: enable-xpdf-headers) to cmake, so no surprice that we then get unstable API/ABI back. We do this for historic and real life practical need, as we have several packages needs/expect those headers to be in place. Be aware that we are no different in this respect than ALL other distros. However since there seems to be an abundance of people annoyed by this, I've made a branch where I build poppler without passing the above undable abi/api, and branched every package depending on poppler ref osc whatdependson. There is currently ~13 packages failing, but I bet more will pop up if the current ones get fixed/ported/poppler dep removed, subs for this should ofc be all sent upstream! Please see https://build.opensuse.org/project/show/home:iznogood:factory (Note that target staging:O still have poppler with unstable api/abi while openSUSE_Factory target does not). Looking forward to all your SR's to bring a future without unstable poppler ABI/API! /Bjørn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 30. 03. 20, 21:28, Bjørn Lie wrote:
In openSUSE we build poppler with passing ENABLE_UNSTABLE_API_ABI_HEADERS=ON (was: enable-xpdf-headers) to cmake, so no surprice that we then get unstable API/ABI back.
We do this for historic and real life practical need, as we have several packages needs/expect those headers to be in place. Be aware that we are no different in this respect than ALL other distros.
However since there seems to be an abundance of people annoyed by this, I've made a branch where I build poppler without passing the above undable abi/api, and branched every package depending on poppler ref osc whatdependson.
There is currently ~13 packages failing, but I bet more will pop up if the current ones get fixed/ported/poppler dep removed, subs for this should ofc be all sent upstream!
Please see https://build.opensuse.org/project/show/home:iznogood:factory
(Note that target staging:O still have poppler with unstable api/abi while openSUSE_Factory target does not).
Looking forward to all your SR's to bring a future without unstable poppler ABI/API!
Given the "unstable" API is used that much, it IMNSHO means that the "stable" API, as they call it, is pretty much unusable. /me downloading the cut rpm from your prj Well, I have just opened the rpm and cannot stop staring. Are they serious that only headers in /usr/include/poppler/cpp are considered "stable" and to be used? I seriously doubt we can fix factory or any other distro using only those API/headers. If they mean it, it would be easier to delete that crap from this world completely and start over with something better maintained. No, blaming users for using "unstable" API really won't work, given the "stable" API provides users with exactly equal to nothing. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Dienstag, 31. März 2020 08:20:49 CEST Jiri Slaby wrote:
On 30. 03. 20, 21:28, Bjørn Lie wrote:
In openSUSE we build poppler with passing ENABLE_UNSTABLE_API_ABI_HEADERS=ON (was: enable-xpdf-headers) to cmake, so no surprice that we then get unstable API/ABI back.
We do this for historic and real life practical need, as we have several packages needs/expect those headers to be in place. Be aware that we are no different in this respect than ALL other distros.
However since there seems to be an abundance of people annoyed by this, I've made a branch where I build poppler without passing the above undable abi/api, and branched every package depending on poppler ref osc whatdependson.
There is currently ~13 packages failing, but I bet more will pop up if the current ones get fixed/ported/poppler dep removed, subs for this should ofc be all sent upstream!
Please see https://build.opensuse.org/project/show/home:iznogood:factory
(Note that target staging:O still have poppler with unstable api/abi while openSUSE_Factory target does not).
Looking forward to all your SR's to bring a future without unstable poppler ABI/API!
Given the "unstable" API is used that much, it IMNSHO means that the "stable" API, as they call it, is pretty much unusable.
/me downloading the cut rpm from your prj
Well, I have just opened the rpm and cannot stop staring. Are they serious that only headers in /usr/include/poppler/cpp are considered "stable" and to be used? I seriously doubt we can fix factory or any other distro using only those API/headers. If they mean it, it would be easier to delete that crap from this world completely and start over with something better maintained. No, blaming users for using "unstable" API really won't work, given the "stable" API provides users with exactly equal to nothing.
Its sufficient for okular and evince. Its sufficient for KFileMetadata. And to quote the poppler maintainer:
We have asked third party uses of non public headers to come forward and describe their needs multiple times, we've always got a big silence as answer.
Cheers, Albert
So stop blaming poppler on unrelated mailinglist, but create bug reports. Do you really think poppler developers should start searching the internet for users of the API, try to understand other projects use cases and code? Regards, Stefan. -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On 31. 03. 20, 9:27, Stefan Brüns wrote:
Well, I have just opened the rpm and cannot stop staring. Are they serious that only headers in /usr/include/poppler/cpp are considered "stable" and to be used? I seriously doubt we can fix factory or any other distro using only those API/headers. If they mean it, it would be easier to delete that crap from this world completely and start over with something better maintained. No, blaming users for using "unstable" API really won't work, given the "stable" API provides users with exactly equal to nothing.
Its sufficient for okular and evince. Its sufficient for KFileMetadata.
OK, maybe sufficient for reading... It's broken for more than 6 years anyway.
And to quote the poppler maintainer:
We have asked third party uses of non public headers to come forward and describe their needs multiple times, we've always got a big silence as answer.
If I may quote you: """ You have already been told there is a stable API. If programs choose to use private interfaces, its their fault. """ So they definitely know about the users and blame users for using the unstable API. Instead of making it stable. And texlive being one of the major ones -- is that hard to look into the code? It would take minutes as it did to me when I fixed one of the poppler API woes in texlive during one of the poppler's updates. To be concrete, again: tex uses Parser and it's apparently considered unstable API. You are telling me it's unknown to the developers? thanks, -- js suse labs
participants (8)
-
Axel Braun -
Bjørn Lie -
DimStar / Dominique Leuenberger -
Dr. Werner Fink -
Jan Engelhardt -
Jiri Slaby -
Stefan Brüns -
Thorsten Kukuk