[opensuse-factory] latest evolution 3.26.3-1.1 is NOT compatible with latest libwebkit2gtk-4_0-37 2.18.4-1.1
hi, today i updated evolution and libwebkit2gtk for tumbleweed from http://download.opensuse.org/tumbleweed/repo/oss. to my surprise evolution did not start any more after this update. when starting evolution from bash i found out why: evolution: symbol lookup error: /usr/lib64/libwebkit2gtk-4.0.so.37: undefined symbol: _ZThn16_N9Inspector21InspectorRuntimeAgent36getRuntimeTypesForVariablesAtOffsetsERN3WTF6StringERKNS1_8JSONImpl5ArrayERNS 1_6RefPtrINS_8Protoco l5ArrayINS9_7Runtime15TypeDescriptionEEEEE WTF? i managed to download package libwebkit2gtk-4_0-37-2.18.3-lp150.2.5.x86_64.rpm from a leap repository. now evolution starts again. so there is a unresolved dependency/bug regarding evolution and latest libwebkit2gtk. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps Namirial GmbH N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Mon, 2018-01-08 at 10:08 +0000, Rainer Klier wrote:
hi,
today i updated evolution and libwebkit2gtk for tumbleweed from http://download.opensuse.org/tumbleweed/repo/oss.
How? Using zypper dup?
Am Montag, den 08.01.2018, 11:16 +0100 schrieb Dominique Leuenberger / DimStar:
On Mon, 2018-01-08 at 10:08 +0000, Rainer Klier wrote:
hi,
today i updated evolution and libwebkit2gtk for tumbleweed from http://download.opensuse.org/tumbleweed/repo/oss.
How? Using zypper dup?
no. i opened yast and selected both (evolution and libwebkit2gtk) for update. both were updated from the same tumbleweed repo. evolution to version 3.26.3-1.1, and libwebkit2gtk-4_0-37 to version 2.18.4-1.1 no conflict or dependency error was shown. everything was "green" and ok, even after check in yast for any problems. so i continued to install the updates. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Op maandag 8 januari 2018 11:34:53 CET schreef Rainer Klier:
Am Montag, den 08.01.2018, 11:16 +0100 schrieb Dominique Leuenberger / DimStar:
On Mon, 2018-01-08 at 10:08 +0000, Rainer Klier wrote:
hi,
today i updated evolution and libwebkit2gtk for tumbleweed from http://download.opensuse.org/tumbleweed/repo/oss.
How? Using zypper dup?
no.
i opened yast and selected both (evolution and libwebkit2gtk) for update. both were updated from the same tumbleweed repo. evolution to version 3.26.3-1.1, and libwebkit2gtk-4_0-37 to version 2.18.4-1.1
no conflict or dependency error was shown. everything was "green" and ok, even after check in yast for any problems. so i continued to install the updates. --
and that's wrong. TW should *only* be updated through 'zypper dup'. Nothing else. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, den 08.01.2018, 12:08 +0100 schrieb Knurpht - Gertjan Lettink:
Op maandag 8 januari 2018 11:34:53 CET schreef Rainer Klier:
Am Montag, den 08.01.2018, 11:16 +0100 schrieb Dominique Leuenberger / DimStar:
How? Using zypper dup?
no.
i opened yast and selected both (evolution and libwebkit2gtk) for update. both were updated from the same tumbleweed repo. evolution to version 3.26.3-1.1, and libwebkit2gtk-4_0-37 to version 2.18.4-1.1
no conflict or dependency error was shown. everything was "green" and ok, even after check in yast for any problems. so i continued to install the updates.
and that's wrong. TW should *only* be updated through 'zypper dup'. Nothing else.
but why? tumbleweed repos are like every other repos. instead of using the leap repos, or before, the 13.x repos, i now simply use the tumbleweed repos. and additionally some other repos like mozilla, libreoffice, KDE,... i don't want to update everything every day. i still want to update, for example, only evolution to latest version. and normally this also works. i do it this way now for a long time. is the answer to this issue really "only use zypper dup"? i think the dependencies should be solved in yast when selecting the packages. i think it is not ok, that yast does not know or show any dependency problem when selecting single packages, and that it only works, when updating the whole system every time. and if there are really so much packages dependent to each others, it should be shown in yast. so, when selecting, for example, evolution for an update, all the other needed packages should automatically be selected for update, like it is normal and usual in yast. because otherwise for an user it is not understandable why the behaviour is different, if you use the leap or the tumbleweed repos. and nowhere in https://en.opensuse.org/openSUSE:Tumbleweed_upgrade (which is the documentation for how to use/move to the tumblewwed repos) is stated, that from this point on in the future you can't use yast anymore for updates, but have to use "zypper dup". it is however written, that you have to use "zypper dup" to do the switch/upgrade from older/other repos to tumbleweed, but not, that this will be the only supported upgrade path in the future. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH
On Montag, 8. Januar 2018 14:44:19 CET Rainer Klier wrote:
Am Montag, den 08.01.2018, 12:08 +0100 schrieb Knurpht - Gertjan Lettink:
Op maandag 8 januari 2018 11:34:53 CET schreef Rainer Klier:
Am Montag, den 08.01.2018, 11:16 +0100 schrieb Dominique Leuenberger / DimStar:
How? Using zypper dup?
no.
i opened yast and selected both (evolution and libwebkit2gtk) for update. both were updated from the same tumbleweed repo. evolution to version 3.26.3-1.1, and libwebkit2gtk-4_0-37 to version 2.18.4-1.1
no conflict or dependency error was shown. everything was "green" and ok, even after check in yast for any problems. so i continued to install the updates.
and that's wrong. TW should *only* be updated through 'zypper dup'. Nothing else.
but why? tumbleweed repos are like every other repos.
Format wise yes, content wise no. The TW repo from today may contain completely different packages than the one from yesterday. The packages from todays repo are built using the other packages from todays repo. As long as not all upstreams provide correctly versioned libraries, zypper dup is required before installing any new software. Regards, Stefan-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, den 08.01.2018, 13:55 +0000 schrieb Brüns, Stefan:
On Montag, 8. Januar 2018 14:44:19 CET Rainer Klier wrote:
Am Montag, den 08.01.2018, 12:08 +0100 schrieb Knurpht - Gertjan Lettink:
and that's wrong. TW should *only* be updated through 'zypper dup'. Nothing
else.
but why? tumbleweed repos are like every other repos.
Format wise yes, content wise no. The TW repo from today may contain completely different packages than the one from yesterday. The packages from todays repo are built using the other packages from todays repo.
hmm, ok. understood. but i think this should be stated somewhere more prominent. not like "it is best to do zypper dup", but more like "there may be unresolved/unshown/hidden package dependencies in the future, so you MUST use zypper dup at the moment you move to tumbleweed repos!"
As long as not all upstreams provide correctly versioned libraries, zypper dup is required before installing any new software.
ok, this means, in the future, whenever i try to update a single package, and it again fails, then i have to disable all the other repos, so that only the tumbleweed repos are valid any more, and then do a "zypper dup" to resolve the "unknown" issue. this will, of course, downgrade ALL the packages from other repos, where packages from tumblewwed repos are older, and these have to be upgraded then again afterwards.... very very expensive...... :-( -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Mon, 2018-01-08 at 14:13 +0000, Rainer Klier wrote:
ok, this means, in the future, whenever i try to update a single package, and it again fails, then i have to disable all the other repos, so that only the tumbleweed repos are valid any more, and then do a "zypper dup" to resolve the "unknown" issue. this will, of course, downgrade ALL the packages from other repos, where packages from tumblewwed repos are older, and these have to be upgraded then again afterwards....
What other repos do you have enabled? Are you missing packages in TW or do you track devel projects to be 'even faster with updates'? If you miss packages, best to work with the current package maintainers to get things into TW proper; if you have devel prjs added because you are maintainer of those projects, I'd recommend working with repo prios (but I would not recommend this unless you actually KNOW/maintain the content of the repos) In essence: try to keep your repo list for TW as short as possible: not seldom, a lot of devel projects do not catch up with rebuilds when a snapshot is being released (and no, I cannot postpone snapshot releases until 'all of obs is rebuilt' - you would have 1 snapshot a month at best)
Am Montag, den 08.01.2018, 15:21 +0100 schrieb Dominique Leuenberger / DimStar:
On Mon, 2018-01-08 at 14:13 +0000, Rainer Klier wrote:
ok, this means, in the future, whenever i try to update a single package, and it again fails, then i have to disable all the other repos, so that only the tumbleweed repos are valid any more, and then do a "zypper dup" to resolve the "unknown" issue. this will, of course, downgrade ALL the packages from other repos, where packages from tumblewwed repos are older, and these have to be upgraded then again afterwards....
What other repos do you have enabled? Are you missing packages in TW or
some google repos (chrome, earth, musicmanager) some microsoft repos (dotnet, powershell) gcc c_c++ python svn devel tools filesystems games tools games gnome apps graphics KDE applications KDE distro factory KDE extra KDE frameworks5 KDE Qt5 kernel standard libreoffice factory mono factory mozilla factory multimedia apps, libs and photo samba network printing shells virtualization remotedesktop x11 utilities xorg factory vlc packman skype and some home: repos for some exotic packages yes, i know, this is quite much. yes, i know, i would/could also live with only the standard tumbleweed repos. yes, i know, updating becomes more complex with that many repos enabled. but normally it works perfectly, and i have latest versions of everything i need. before using tumbleweed i used 13.2. and my first idea about tumbleweed was, that i have latest version of opensuse, and latest packages available. but not, that i always have to update the WHOLE system......
do you track devel projects to be 'even faster with updates'?
i have only some repos where i want latest version of the packages they contain.
If you miss packages, best to work with the current package maintainers to get things into TW proper; if you have devel prjs added because you
i think most of the packages of the repos mentioned above will sooner or later appear in new version also in TW repos. but i want them, as soon as they are built and available, and don't want to wait for them to appear in TW repo..... and my opinion was, that this is exactly what TW is all about.... i thought that this is the idea behind TW.
In essence: try to keep your repo list for TW as short as possible: not
yes, understood. but it simply should not happen that when i cherry-pick in yast some package from TW repo to be updated, that it updates, does NOT show/warn me about a conflict/dependency and then the application crashes. in a package-manager-world this is the worst thing to happen. this is the reason for using a package-manager, so that such situation can't happen..... -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH
Op maandag 8 januari 2018 16:46:22 CET schreef Rainer Klier:
Am Montag, den 08.01.2018, 15:21 +0100 schrieb Dominique Leuenberger / DimStar:
On Mon, 2018-01-08 at 14:13 +0000, Rainer Klier wrote:
ok, this means, in the future, whenever i try to update a single package, and it again fails, then i have to disable all the other repos, so that only the tumbleweed repos are valid any more, and then do a "zypper dup" to resolve the "unknown" issue. this will, of course, downgrade ALL the packages from other repos, where packages from tumblewwed repos are older, and these have to be upgraded then again afterwards....
What other repos do you have enabled? Are you missing packages in TW or
some google repos (chrome, earth, musicmanager) some microsoft repos (dotnet, powershell) gcc c_c++ python svn devel tools filesystems games tools games gnome apps graphics KDE applications KDE distro factory KDE extra KDE frameworks5 KDE Qt5 kernel standard libreoffice factory mono factory mozilla factory multimedia apps, libs and photo samba network printing shells virtualization remotedesktop x11 utilities xorg factory vlc packman skype and some home: repos for some exotic packages
yes, i know, this is quite much. yes, i know, i would/could also live with only the standard tumbleweed repos. yes, i know, updating becomes more complex with that many repos enabled. but normally it works perfectly, and i have latest versions of everything i need.
before using tumbleweed i used 13.2. and my first idea about tumbleweed was, that i have latest version of opensuse, and latest packages available. but not, that i always have to update the WHOLE system......
do you track devel projects to be 'even faster with updates'?
i have only some repos where i want latest version of the packages they contain.
If you miss packages, best to work with the current package maintainers to get things into TW proper; if you have devel prjs added because you
i think most of the packages of the repos mentioned above will sooner or later appear in new version also in TW repos.
but i want them, as soon as
they are built and available, and don't want to wait for them to appear in TW repo..... and my opinion was, that this is exactly what TW is all about.... i thought that this is the idea behind TW.
In essence: try to keep your repo list for TW as short as possible: not
yes, understood.
but it simply should not happen that when i cherry-pick in yast some package from TW repo to be updated, that it updates, does NOT show/warn me about a conflict/dependency and then the application crashes. in a package-manager-world this is the worst thing to happen. this is the reason for using a package-manager, so that such situation can't happen..... --
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales
DI Rainer Klier
Research & Development, DevOps
_________________________________________________________
Namirial GmbH
You don't have to update the whole system, that's nonsense, you only update the packages that are new in the newly released snapshot. O, stop, not nonsense, it can happen, f.e. on a major gcc version upgrade where all packages were rebuilt and appeared as updates. I think that happened twice in the years that I've been running TW. TW is released over and over again after openQA testing, but with only updated packages, most packages don't chang at all, so will not have to be reinstalled. Even more: if you enable f.e. the Packman repo, and perrform a vendor change on it, i.e. tell zypper you want the packages available from that repo, zypper has a default for TW ( --no-vendor-change ) that respects that choice. The devs have even added an extra warning when using 'zypper up', i.e. that 'zypper dup' should be used. The openSUSE Project wants TW to be a rolling, yet always stable, release, for which openqa.opensuse.org is used. Updated packages are not released until they pass the tests ... A thing one is breaking by replacing the distro packages by those from other repos. Given the current infrastructure and people available it's impossible to include these repos into testing TW. Re. repos: why add any KDE repo if TW mostly serves upstream packages within 24 hours ? -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2018-01-08 at 14:13 -0000, Rainer Klier wrote:
Am Montag, den 08.01.2018, 13:55 +0000 schrieb Brüns, Stefan:
On Montag, 8. Januar 2018 14:44:19 CET Rainer Klier wrote:
Am Montag, den 08.01.2018, 12:08 +0100 schrieb Knurpht - Gertjan Lettink:
and that's wrong. TW should *only* be updated through 'zypper dup'. Nothing else.
That is so.
but why? tumbleweed repos are like every other repos.
Format wise yes, content wise no. The TW repo from today may contain completely different packages than the one from yesterday. The packages from todays repo are built using the other packages from todays repo.
hmm, ok. understood. but i think this should be stated somewhere more prominent. not like "it is best to do zypper dup", but more like "there may be unresolved/unshown/hidden package dependencies in the future, so you MUST use zypper dup at the moment you move to tumbleweed repos!"
Yes, this is true.
As long as not all upstreams provide correctly versioned libraries, zypper dup is required before installing any new software.
ok, this means, in the future, whenever i try to update a single package, and it again fails, then i have to disable all the other repos, so that only the tumbleweed repos are valid any more, and then do a "zypper dup" to resolve the "unknown" issue. this will, of course, downgrade ALL the packages from other repos, where packages from tumblewwed repos are older, and these have to be upgraded then again afterwards....
very very expensive...... :-(
No, you do not need to disable other repos, but it is best not to use them, specially if the packages you want are available on TW main repos (oss, non-oss, and update) You simply have to run "zypper dup" periodically. Often. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpTgX8ACgkQtTMYHG2NR9UgYgCZAdw4u1XnwDSfvI4mqV0nbaLV xCsAniiXcgxkKfHG3k6BgWGwzRLtIULg =AEm+ -----END PGP SIGNATURE-----
Am Montag, den 08.01.2018, 15:34 +0100 schrieb Carlos E. R.:
On Monday, 2018-01-08 at 14:13 -0000, Rainer Klier wrote:
Am Montag, den 08.01.2018, 13:55 +0000 schrieb Brüns, Stefan:
On Montag, 8. Januar 2018 14:44:19 CET Rainer Klier wrote:
Am Montag, den 08.01.2018, 12:08 +0100 schrieb Knurpht - Gertjan Lettink:
and that's wrong. TW should *only* be updated through 'zypper dup'. Nothing else.
That is so.
:-(
but i think this should be stated somewhere more prominent.
not like "it is best to do zypper dup", but more like "there may be unresolved/unshown/hidden package dependencies in the future, so you MUST use zypper dup at the moment you move to tumbleweed repos!"
Yes, this is true.
at least it is then known BEFORE such issues happen.
this will, of course, downgrade ALL the packages from other repos, where packages from tumblewwed repos are older,
and these have to be upgraded then again afterwards....
very very expensive...... :-(
No, you do not need to disable other repos, but it is best not to use them, specially if the packages you want are available on TW main repos (oss, non-oss, and update)
don't like this.
You simply have to run "zypper dup" periodically. Often.
don't like this either. :-( but at least it is now clear to me. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2018-01-08 at 15:21 -0000, Rainer Klier wrote:
Am Montag, den 08.01.2018, 15:34 +0100 schrieb Carlos E. R.:
No, you do not need to disable other repos, but it is best not to use them, specially if the packages you want are available on TW main repos (oss, non-oss, and update)
don't like this.
But the when a package is both in TW/oss and some repo, the repo version is typically experimental. Normally you should not use them.
You simply have to run "zypper dup" periodically. Often.
don't like this either. :-( but at least it is now clear to me.
- -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpUn0gACgkQtTMYHG2NR9XXSgCfZKFFGXJk2x/ntRIaXgD20AWK U+YAn0/FiTo27dUpEmlPKmC/MThw3fGp =+I0S -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/01/2018 12:08, Rainer Klier wrote:
hi,
today i updated evolution and libwebkit2gtk for tumbleweed from http://download.opensuse.org/tumbleweed/repo/oss.
to my surprise evolution did not start any more after this update.
when starting evolution from bash i found out why:
evolution: symbol lookup error: /usr/lib64/libwebkit2gtk-4.0.so.37: undefined symbol: _ZThn16_N9Inspector21InspectorRuntimeAgent36getRuntimeTypesForVariablesAtOffsetsERN3WTF6StringERKNS1_8JSONImpl5ArrayERNS 1_6RefPtrINS_8Protoco l5ArrayINS9_7Runtime15TypeDescriptionEEEEE
WTF?
i managed to download package libwebkit2gtk-4_0-37-2.18.3-lp150.2.5.x86_64.rpm from a leap repository. now evolution starts again.
so there is a unresolved dependency/bug regarding evolution and latest libwebkit2gtk.
This thread seems to have missed the main point: The evolution package that you installed was built against a different version of the libwebkit2gtk that you installed at the same time. If all your packages came from Tumbleweed this could either be a bug or due to the fact that evolution was still building against the newer library. In the latter case waiting the build to finish and installing the newer evolution version will fix the problem. If you have a mix of packages from different repositories then this is not a bug and it is up to you to find the correct library, which you did but this doesn't guarantee that you won't have other problems in the future. Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, den 09.01.2018, 07:34 +0200 schrieb Dave Plater:
On 08/01/2018 12:08, Rainer Klier wrote:
i managed to download package libwebkit2gtk-4_0-37-2.18.3-lp150.2.5.x86_64.rpm from a leap repository.
now evolution starts again.
so there is a unresolved dependency/bug regarding evolution and latest libwebkit2gtk.
This thread seems to have missed the main point:
thank you much, you are right!
The evolution package that you installed was built against a different version of the libwebkit2gtk that you installed at the same time. If all
yes, and both are from same TW repo and would also beeing installed at the same time if i would have done a "zypper dup". i assume....
your packages came from Tumbleweed this could either be a bug or due to the fact that evolution was still building against the newer library. In the latter case waiting the build to finish and installing the newer evolution version will fix the problem. If you have a mix of packages from different repositories then this is not a bug and it is up to you to find the correct library, which you did
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
but this doesn't guarantee that you won't have other problems in the future.
yes, of course. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
your packages came from Tumbleweed this could either be a bug or due to
the fact that evolution was still building against the newer library. In the latter case waiting the build to finish and installing the newer evolution version will fix the problem. If you have a mix of packages from different repositories then this is not a bug and it is up to you to find the correct library, which you did
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Highly doubtful, since there is an openQA test of a duped machine - and I am sure many more would have jumped on the wagon here and shouted 'me too' Anyway, to hopefully get this to an end: what you very likely forgot to update at the same time as libwebkitgtk-4_0-37 was webkit2gtk-4_0- injected-bundles (note: this is an assumption/guess only) Cheers Dominique
Am Dienstag, den 09.01.2018, 09:28 +0100 schrieb Dominique Leuenberger / DimStar:
On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Highly doubtful, since there is an openQA test of a duped machine - and I am sure many more would have jumped on the wagon here and shouted 'me too'
hmm, yes, that seems obvious.
Anyway, to hopefully get this to an end: what you very likely forgot to update at the same time as libwebkitgtk-4_0-37 was webkit2gtk-4_0- injected-bundles (note: this is an assumption/guess only)
thanks, but this didn't solve it. i updated the injected-bundles package also, but it didn't solve it. i now also added the GNOME:Factory repo (juhuuu, another repo to my list.. ;-) to get evolution AND all *webkit* packages from there, and was able to install everything from there. but this also didn't solve this issue. really strange. only the downgrade: rpm -Uhv --force libwebkit2gtk-4_0-37-2.18.3-lp150.2.5.x86_64.rpm libwebkit2gtk3-lang-2.18.3-lp150.2.5.noarch.rpm solves this issue. at least it's a workaround and i can continue to work..... -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH
On Tue, 2018-01-09 at 08:41 +0000, Rainer Klier wrote:
Am Dienstag, den 09.01.2018, 09:28 +0100 schrieb Dominique Leuenberger / DimStar:
On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Highly doubtful, since there is an openQA test of a duped machine - and I am sure many more would have jumped on the wagon here and shouted 'me too'
hmm, yes, that seems obvious.
Anyway, to hopefully get this to an end: what you very likely forgot to update at the same time as libwebkitgtk-4_0-37 was webkit2gtk-4_0- injected-bundles (note: this is an assumption/guess only)
thanks, but this didn't solve it.
i updated the injected-bundles package also, but it didn't solve it.
i now also added the GNOME:Factory repo (juhuuu, another repo to my list.. ;-) to get evolution AND all *webkit* packages from there, and was able to install everything from there. but this also didn't solve this issue.
Urgh - so in order to fix an already polluted system you pollute it more... as the maintainer of GNOME:Factory, I can only say: there should be really no reason at all to add G:F to any machine that is not doing actual devel work on the GNOME packages. Upgrades from G:F moved to TW at a high enough pace - once things are tested on the developers machines. But of course, you are 'free' to do as you wish. Cheers Dominique
Am Dienstag, den 09.01.2018, 09:48 +0100 schrieb Dominique Leuenberger / DimStar:
On Tue, 2018-01-09 at 08:41 +0000, Rainer Klier wrote:
i updated the injected-bundles package also, but it didn't solve it.
i now also added the GNOME:Factory repo (juhuuu, another repo to my list.. ;-) to get evolution AND all *webkit* packages from there, and was able to install everything from there. but this also didn't solve this issue.
Urgh - so in order to fix an already polluted system you pollute it
for a polluted system it works very well for many many years now.... ;-) with the exception of such rare strange issue like this.
more... as the maintainer of GNOME:Factory, I can only say: there should be really no reason at all to add G:F to any machine that is not
ok, already disabled it. ;-) it was just a try.... :-(
doing actual devel work on the GNOME packages. Upgrades from G:F moved to TW at a high enough pace - once things are tested on the developers machines. But of course, you are 'free' to do as you wish.
no, you are right, i avoided GNOME:Factory in the past, because it already created some issues..... so, i agree to you in disabling it. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Tue, 9 Jan 2018, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-01-09 at 08:41 +0000, Rainer Klier wrote:
Am Dienstag, den 09.01.2018, 09:28 +0100 schrieb Dominique Leuenberger / DimStar:
On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Highly doubtful, since there is an openQA test of a duped machine - and I am sure many more would have jumped on the wagon here and shouted 'me too'
hmm, yes, that seems obvious.
Anyway, to hopefully get this to an end: what you very likely forgot to update at the same time as libwebkitgtk-4_0-37 was webkit2gtk-4_0- injected-bundles (note: this is an assumption/guess only)
thanks, but this didn't solve it.
i updated the injected-bundles package also, but it didn't solve it.
i now also added the GNOME:Factory repo (juhuuu, another repo to my list.. ;-) to get evolution AND all *webkit* packages from there, and was able to install everything from there. but this also didn't solve this issue.
Urgh - so in order to fix an already polluted system you pollute it more... as the maintainer of GNOME:Factory, I can only say: there should be really no reason at all to add G:F to any machine that is not doing actual devel work on the GNOME packages. Upgrades from G:F moved to TW at a high enough pace - once things are tested on the developers machines. But of course, you are 'free' to do as you wish.
The real issue is of course false binary compatibility promises made
via not changing the SONAME or using symbol versioning...
Of course it's quite hard to do right, especially with C++, but still
I'd expect "core" libraries to do better here...
Richard.
--
Richard Biener
Am Dienstag, den 09.01.2018, 10:06 +0100 schrieb Richard Biener:
On Tue, 9 Jan 2018, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-01-09 at 08:41 +0000, Rainer Klier wrote:
Am Dienstag, den 09.01.2018, 09:28 +0100 schrieb Dominique Leuenberger / DimStar:
Urgh - so in order to fix an already polluted system you pollute it more... as the maintainer of GNOME:Factory, I can only say: there should be really no reason at all to add G:F to any machine that is not doing actual devel work on the GNOME packages. Upgrades from G:F moved to TW at a high enough pace - once things are tested on the developers machines. But of course, you are 'free' to do as you wish.
The real issue is of course false binary compatibility promises made via not changing the SONAME or using symbol versioning...
exactly.
Of course it's quite hard to do right, especially with C++, but still I'd expect "core" libraries to do better here...
i totally agree. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH
On Tuesday 2018-01-09 10:06, Richard Biener wrote:
The real issue is of course false binary compatibility promises made via not changing the SONAME or using symbol versioning...
Of course it's quite hard to do right, especially with C++, but still I'd expect "core" libraries to do better here...
KDE/Qt can apparently do it for C++ (there is a suitably large rulebook they use), so why can't GNOME do it for C (which needs a lot less rules)? It feels like GNOME software is intentionally wanting to be annoying. (Reported back in https://bugzilla.opensuse.org/903974 ) Maybe we should just, short of symversioning, do libgthread_2_0_la_LDFLAGS = $(GLIB_LINK_FLAGS) \ + -release $(PACKAGE_VERSION) \ $(gthread_win32_res_ldflag) \ -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ -export-dynamic $(no_undefined) $(export_symbols) then those dependency-satisfied-but-unrunnable situations can't happen. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2018-01-09 at 10:24 +0100, Jan Engelhardt wrote:
On Tuesday 2018-01-09 10:06, Richard Biener wrote:
The real issue is of course false binary compatibility promises made via not changing the SONAME or using symbol versioning...
Of course it's quite hard to do right, especially with C++, but still I'd expect "core" libraries to do better here...
KDE/Qt can apparently do it for C++ (there is a suitably large rulebook they use), so why can't GNOME do it for C (which needs a lot less rules)? It feels like GNOME software is intentionally wanting to be annoying.
(Reported back in https://bugzilla.opensuse.org/903974 )
Perfect bug report - especially since the last comment is not about GNOME, but about libxcb running into same issues - talk about 'core libraries'. 'underlying systems' like X don't get 'this right' neither. Still, yes, it would be awesome if upstreams were less opposed to the notion of symbol versioning, but it is soo easy for an upstream to miss adding a new API symbol to the table that it is quickly getting messier than it was before (especially on large code bases like glib/gtk - where maintainers refuse the loudest). glib basically stands with: yes, we want to do it, but only if the map can be auto-generated from source files based on annotations. This of course 'can' - but the respective info-extractor is not written - nobody cared sufficiently for this to happen. Cheers Dominique
On Tue, 9 Jan 2018, Dominique Leuenberger / DimStar wrote:
On Tue, 2018-01-09 at 10:24 +0100, Jan Engelhardt wrote:
On Tuesday 2018-01-09 10:06, Richard Biener wrote:
The real issue is of course false binary compatibility promises made via not changing the SONAME or using symbol versioning...
Of course it's quite hard to do right, especially with C++, but still I'd expect "core" libraries to do better here...
KDE/Qt can apparently do it for C++ (there is a suitably large rulebook they use), so why can't GNOME do it for C (which needs a lot less rules)? It feels like GNOME software is intentionally wanting to be annoying.
(Reported back in https://bugzilla.opensuse.org/903974 )
Perfect bug report - especially since the last comment is not about GNOME, but about libxcb running into same issues - talk about 'core libraries'.
'underlying systems' like X don't get 'this right' neither.
Still, yes, it would be awesome if upstreams were less opposed to the notion of symbol versioning, but it is soo easy for an upstream to miss adding a new API symbol to the table that it is quickly getting messier than it was before (especially on large code bases like glib/gtk - where maintainers refuse the loudest).
glib basically stands with: yes, we want to do it, but only if the map can be auto-generated from source files based on annotations. This of course 'can' - but the respective info-extractor is not written - nobody cared sufficiently for this to happen.
Note that one issue that comes up every now and then is that people
simply export everything. What you already can do is compile
with -fvisibility-default=hidden and mark things you want to be
exported by annotating the source (IIRC also a required thing for
DLLs on windows). IIRC you can't add version information to the
export annotations but at least you'd "know" when you add/remove
stuff.
Richard.
--
Richard Biener
On Tue, 9 Jan 2018, Jan Engelhardt wrote:
On Tuesday 2018-01-09 10:06, Richard Biener wrote:
The real issue is of course false binary compatibility promises made via not changing the SONAME or using symbol versioning...
Of course it's quite hard to do right, especially with C++, but still I'd expect "core" libraries to do better here...
KDE/Qt can apparently do it for C++ (there is a suitably large rulebook they use), so why can't GNOME do it for C (which needs a lot less rules)? It feels like GNOME software is intentionally wanting to be annoying.
The reported missing symbol was clearly a C++ one.
(Reported back in https://bugzilla.opensuse.org/903974 )
Maybe we should just, short of symversioning, do
libgthread_2_0_la_LDFLAGS = $(GLIB_LINK_FLAGS) \ + -release $(PACKAGE_VERSION) \ $(gthread_win32_res_ldflag) \ -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ -export-dynamic $(no_undefined) $(export_symbols)
then those dependency-satisfied-but-unrunnable situations can't happen.
Not sure, IMHO all such issues need to be resolved upstream in the
build machinery like by "fixing" the set of exported symbols by
extracting them and feeding them back via a versioning script. For
any change then do a diff, make sure no symbol vanishes and make sure
to add a new symver for all added symbols.
Anyway, IIRC rpm only extracts symvers for a specific set of libs
and not for all so rpm dependencies would still be broken.
Richard.
--
Richard Biener
On Tuesday 2018-01-09 10:36, Richard Biener wrote:
On Tue, 9 Jan 2018, Jan Engelhardt wrote:
Maybe we should just, short of symversioning, do
libgthread_2_0_la_LDFLAGS = $(GLIB_LINK_FLAGS) \ + -release $(PACKAGE_VERSION) \ $(gthread_win32_res_ldflag) \ -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ -export-dynamic $(no_undefined) $(export_symbols)
then those dependency-satisfied-but-unrunnable situations can't happen.
Not sure, IMHO all such issues need to be resolved upstream in the build machinery like by "fixing" the set of exported symbols by extracting them and feeding them back via a versioning script.
Yes but since they don't do this standard solution, and as a result causes issus for us, I think we are in a position to workaround it our way.
Anyway, IIRC rpm only extracts symvers for a specific set of libs
Link to source? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 9 Jan 2018, Jan Engelhardt wrote:
On Tuesday 2018-01-09 10:36, Richard Biener wrote:
On Tue, 9 Jan 2018, Jan Engelhardt wrote:
Maybe we should just, short of symversioning, do
libgthread_2_0_la_LDFLAGS = $(GLIB_LINK_FLAGS) \ + -release $(PACKAGE_VERSION) \ $(gthread_win32_res_ldflag) \ -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ -export-dynamic $(no_undefined) $(export_symbols)
then those dependency-satisfied-but-unrunnable situations can't happen.
Not sure, IMHO all such issues need to be resolved upstream in the build machinery like by "fixing" the set of exported symbols by extracting them and feeding them back via a versioning script.
Yes but since they don't do this standard solution, and as a result causes issus for us, I think we are in a position to workaround it our way.
Anyway, IIRC rpm only extracts symvers for a specific set of libs
Link to source?
/usr/lib/rpm/find-provides has # # --- Library sonames and weak symbol versions (from glibc). for f in "${solist[@]}"; do soname=$(objdump -p "$f" | awk '/SONAME/ {print $2}') ... objdump -p "$f" | awk ' BEGIN { START=0 ; } /Version definitions:/ { START=1; } /^[0-9]/ && (START==1) { print $4; } /^$/ { START=0; } ' | \ while read symbol ; do echo "$soname($symbol)$slib64" done so it's only in the comments. Might be that they are still not copied to the repository metadata. The rpms seem to have requires like libz.so.1(ZLIB_1.2.0)(64bit) at least. Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2018-01-09 11:00, Richard Biener wrote:
so it's only in the comments. Might be that they are still not copied to the repository metadata. The rpms seem to have requires like libz.so.1(ZLIB_1.2.0)(64bit) at least.
zypper runs a transaction check with rpm, so if it missed selecting some rpms for installation that would otherwise be required to satisfy symver deps, it would have already errored out for someone on the planet, I guess. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2018-01-09 at 10:06 +0100, Richard Biener wrote:
The real issue is of course false binary compatibility promises made via not changing the SONAME or using symbol versioning...
Of course it's quite hard to do right, especially with C++, but still I'd expect "core" libraries to do better here...
That asks for a definition of 'core' library / 'core applications' - but we're getting off-topic quickly there. Yes, it would be nice if C++ would be less of a PITA with symbol mangling, yes, it would be awesome if upstreams would learn about symbol versioning, but no, I don't see this changing anytime soon (but we keep on mentioning over and over - maybe one day; let's not give up hope just yet) Cheers Dominique
I have similar "issue" few days ago with qt5webengine. And even I wrote a bug report(!). But actually problem was in forsaken trash in my /usr/local/lib Maybe you have same old/forgotten libs somewhere: ldd /usr/lib64/libwebkit2gtk-4.0.so.37 |grep -v /usr/lib64/ On 2018-01-09 18:41, Rainer Klier wrote:
Am Dienstag, den 09.01.2018, 09:28 +0100 schrieb Dominique Leuenberger / DimStar:
On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Highly doubtful, since there is an openQA test of a duped machine - and I am sure many more would have jumped on the wagon here and shouted 'me too'
hmm, yes, that seems obvious.
Anyway, to hopefully get this to an end: what you very likely forgot to update at the same time as libwebkitgtk-4_0-37 was webkit2gtk-4_0- injected-bundles (note: this is an assumption/guess only)
thanks, but this didn't solve it.
i updated the injected-bundles package also, but it didn't solve it.
i now also added the GNOME:Factory repo (juhuuu, another repo to my list.. ;-) to get evolution AND all *webkit* packages from there, and was able to install everything from there. but this also didn't solve this issue.
really strange.
only the downgrade: rpm -Uhv --force libwebkit2gtk-4_0-37-2.18.3-lp150.2.5.x86_64.rpm libwebkit2gtk3-lang-2.18.3-lp150.2.5.noarch.rpm
solves this issue.
at least it's a workaround and i can continue to work..... --
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales
DI Rainer Klier
Research & Development, DevOps
_________________________________________________________
Namirial GmbH
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
missed symbols is in libjavascriptcoregtk-4.0.so.18.6.13 (libjavascriptcoregtk-4_0-18 package) On 2018-01-09 18:41, Rainer Klier wrote:
Am Dienstag, den 09.01.2018, 09:28 +0100 schrieb Dominique Leuenberger / DimStar:
On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Highly doubtful, since there is an openQA test of a duped machine - and I am sure many more would have jumped on the wagon here and shouted 'me too'
hmm, yes, that seems obvious.
Anyway, to hopefully get this to an end: what you very likely forgot to update at the same time as libwebkitgtk-4_0-37 was webkit2gtk-4_0- injected-bundles (note: this is an assumption/guess only)
thanks, but this didn't solve it.
i updated the injected-bundles package also, but it didn't solve it.
i now also added the GNOME:Factory repo (juhuuu, another repo to my list.. ;-) to get evolution AND all *webkit* packages from there, and was able to install everything from there. but this also didn't solve this issue.
really strange.
only the downgrade: rpm -Uhv --force libwebkit2gtk-4_0-37-2.18.3-lp150.2.5.x86_64.rpm libwebkit2gtk3-lang-2.18.3-lp150.2.5.noarch.rpm
solves this issue.
at least it's a workaround and i can continue to work..... --
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales
DI Rainer Klier
Research & Development, DevOps
_________________________________________________________
Namirial GmbH
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, den 09.01.2018, 19:07 +1000 schrieb Konstantin Voinov:
missed symbols is in libjavascriptcoregtk-4.0.so.18.6.13 (libjavascriptcoregtk-4_0-18 package)
THAT DID THE TRICK!! thank you very much!!!! you made my day! i also updated libjavascriptcoregtk-4_0-18 and removed orphaned libjavascriptcoregtk-3_0-0 in fact, the common thing was, that i had to upgrade ALL packages where the latest version is 2.18.4 they seem to belong to each other. yes, of course, a "zypper dup" would have done exactly this. but only because it would have updated nearly everything which has a higher verison number. but the dependency would still have been unknown! and that is, in my eyes, the issue here. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales DI Rainer Klier Research & Development, DevOps _________________________________________________________ Namirial GmbH N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
glad to help) On 2018-01-09 19:40, Rainer Klier wrote:
Am Dienstag, den 09.01.2018, 19:07 +1000 schrieb Konstantin Voinov:
missed symbols is in libjavascriptcoregtk-4.0.so.18.6.13 (libjavascriptcoregtk-4_0-18 package)
THAT DID THE TRICK!!
thank you very much!!!! you made my day!
i also updated libjavascriptcoregtk-4_0-18 and removed orphaned libjavascriptcoregtk-3_0-0
in fact, the common thing was, that i had to upgrade ALL packages where the latest version is 2.18.4 they seem to belong to each other.
yes, of course, a "zypper dup" would have done exactly this. but only because it would have updated nearly everything which has a higher verison number.
but the dependency would still have been unknown! and that is, in my eyes, the issue here.
--
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales
DI Rainer Klier
Research & Development, DevOps
_________________________________________________________
Namirial GmbH
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
It does not, it just works. For the record, I only got the PackMan repo configured with lower prio than the offical repos, I've never run into an issue like this. Regards, Dag Jönsson On Tue, 2018-01-09 at 08:15 +0000, Rainer Klier wrote:
your packages came from Tumbleweed this could either be a bug or due to the fact that evolution was still building against the newer library. In the latter case waiting the build to finish and installing the newer evolution version will fix the problem. If you have a mix of packages from different repositories then this is not a bug and it is up to you to find the correct library, which you did
no, both are from TW repo. it would be interesting, what happens to evolution for a user, who cleanly and correctly always did a "zypper dup".... does it also crash?
Namirial GmbH
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Brüns, Stefan -
Carlos E. R. -
Dag Jönsson -
Dave Plater -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Knurpht - Gertjan Lettink -
Konstantin Voinov -
Rainer Klier -
Richard Biener