particular problem with a Leap 15.3 system: symbol error when starting kmail
After an update Kontact does not start, however Akonadi the "usual suspect" this time is not the culprit at all and runs flawlessly. I have the suspect the user (which did a zypper up) might have some repo or library that induced a mix between 32 bit and 64 bit. But I am no way sure and honestly I do not know how I could debug the presence of the problem. To make it worse I have only the output in Italian, so please disregard if "non imperial outputs"are politically too incorrect. It is just what I have under hand, but should be quite understandable and is not used with any intent to set whatever "precedent" here. First: the system is Leap 15.3 and should be, procrastination tendencies of the user permitting, soon be updated to 15.4. But I am somewhat prudent to do this now with the error active, as this might then break as well the upgrade. What repos are active: # | Alias | Name | Enabled | GPG Check | Refresh | Type ---+-------------------------------------- +-------------------------------------+-----------+--------------- +---------------+------- 1 | https-download.opensuse.org-44cfee8e | openSUSE:Backports:SLE-15-SP3 | Sì | (r ) Sì | Sì | rpm-md 2 | https-download.opensuse.org-f3464cb7 | security | Sì | (r ) Sì | Sì | rpm-md 3 | opensuse-guide.org-repo | Libdvdcss Repository | Sì | (r ) Sì | Sì | rpm-md 4 | packman | packman | Sì | (r ) Sì | Sì | rpm-md 5 | repo-backports-debug-update | Update repository with updates fo-
| No | ---- | ---- | NONE
6 | repo-backports-update | Update repository of openSUSE Bac-
| Sì | (r ) Sì | Sì | rpm-md
7 | repo-debug | Repository di debug | Sì | (r ) Sì | Sì | rpm-md 8 | repo-debug-update | Repository degli aggiornamenti (D-
| Sì | (r ) Sì | Sì | rpm-md
9 | repo-non-oss | Repository Non-OSS | Sì | (r ) Sì | Sì | rpm-md 10 | repo-oss | Repository principale | Sì | (r ) Sì | Sì | rpm-md 11 | repo-sle-debug-update | Update repository with debuginfo -
| No | ---- | ---- | NONE
12 | repo-sle-update | Update repository with updates fr-
| Sì | (r ) Sì | Sì | rpm-md
13 | repo-source | Source Repository | Sì | (r ) Sì | Sì | rpm-md 14 | repo-source-non-oss | Source Repository (Non-OSS) | Sì | (r ) Sì | Sì | rpm-md 15 | repo-update | Repository principale degli aggio-
| Sì | (r ) Sì | Sì | rpm-md
16 | repo-update-non-oss | Repository degli aggiornamenti (N-
| Sì | (r ) Sì | Sì | rpm-md
What is the error message when the user starts kmail: kmail: symbol lookup error: /usr/lib64/libKF5ContactEditor.so.5: undefined symbol: _ZN9KContacts9Addressee16staticMetaObjectE I came about a reference of a case with Leap in 2018 I think, where the user at the end discovered that he had torn inadvertently a library 32 bit in the 64 bit system. But I did not find a reference how to find which. When I tried and told the user to "zypper in libKF5ContactEditor.so.5 the following endless conflict list produced (unfortunately in Italian). Please scroll down to solution "2" below to come to the point. Problema: libKF5ContactEditor5-20.04.2-bp153.2.2.1.i586 da installare presenta un'architettura inferiore Soluzione 1: Verranno eseguite le azioni indicate: installa libKF5ContactEditor5-20.04.2-bp153.2.2.1.i586 nonostante l'architettura inferiore modifica di architettura di libKF5ContactEditor5-20.04.2-bp153.2.2.1.x86_64 in libKF5ContactEditor5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5AkonadiContact5-20.04.2-bp153.2.2.1.x86_64 in libKF5AkonadiContact5-20.04.2-bp153.2.2.1.i586 installa akonadi-contact-20.04.2-bp153.2.2.1.i586 nonostante l'architettura inferiore installa libKF5AkonadiCore5-20.04.2-bp153.4.2.1.i586 nonostante l'architettura inferiore installa libKF5AkonadiWidgets5-20.04.2-bp153.4.2.1.i586 nonostante l'architettura inferiore installa libKF5AkonadiPrivate5-20.04.2-bp153.4.2.1.i586 nonostante l'architettura inferiore installa libKF5Mime5-20.04.2-bp153.2.2.1.i586 nonostante l'architettura inferiore modifica di architettura di akonadi-contact-20.04.2-bp153.2.2.1.x86_64 in akonadi-contact-20.04.2-bp153.2.2.1.i586 disinstallazione di libKF5IncidenceEditor5-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di libKF5LibkdepimAkonadi5-20.04.2- bp153.2.2.1.x86_64 in libKF5LibkdepimAkonadi5-20.04.2-bp153.2.2.1.i586 disinstallazione di libKF5MailCommon5-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di libKF5PimCommonAkonadi5-20.04.2- bp153.2.2.1.x86_64 in libKF5PimCommonAkonadi5-20.04.2-bp153.2.2.1.i586 disinstallazione di messagelib-20.04.2-bp153.2.2.1.x86_64 disinstallazione di libdigikamcore7-7.1.0-bp153.1.23.x86_64 disinstallazione di libKF5AkonadiCalendar5-20.04.2-bp153.2.2.1.x86_64 disinstallazione di korganizer-20.04.2-bp153.2.2.1.x86_64 disinstallazione di kmail-20.04.2-bp153.3.2.1.x86_64 disinstallazione di kdepim-runtime-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di kdepim-apps-libs-20.04.2-bp153.2.2.1.x86_64 in kdepim-apps-libs-20.04.2-bp153.2.2.1.i586 disinstallazione di kdepim-addons-20.04.2-bp153.2.2.1.x86_64 disinstallazione di kaddressbook-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di akonadi-plugin-contacts-20.04.2- bp153.2.2.1.x86_64 in akonadi-plugin-contacts-20.04.2-bp153.2.2.1.i586 disinstallazione di libKF5EventViews5-20.04.2-bp153.2.2.1.x86_64 disinstallazione di akonadi-import-wizard-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di knotes-20.04.2-bp153.2.2.1.x86_64 in knotes-20.04.2-bp153.2.2.1.i586 disinstallazione di akregator-20.04.2-bp153.2.23.x86_64 disinstallazione di digikam-plugins-7.1.0-bp153.1.23.x86_64 modifica di architettura di libkdepim-20.04.2-bp153.2.2.1.x86_64 in libkdepim-20.04.2-bp153.2.2.1.i586 disinstallazione di libKPimImportWizard5-20.04.2-bp153.2.2.1.x86_64 disinstallazione di mbox-importer-20.04.2-bp153.1.25.x86_64 disinstallazione di pim-data-exporter-20.04.2-bp153.1.25.x86_64 disinstallazione di showfoto-7.1.0-bp153.1.23.x86_64 disinstallazione di libKF5CalendarSupport5-20.04.2-bp153.2.2.1.x86_64 disinstallazione di kontact-20.04.2-bp153.2.2.1.x86_64 disinstallazione di kdepim-addons-lang-20.04.2-bp153.2.2.1.noarch disinstallazione di akonadi-calendar-tools-20.04.2-bp153.2.2.1.x86_64 disinstallazione di mbox-importer-lang-20.04.2-bp153.1.25.noarch disinstallazione di pim-data-exporter-lang-20.04.2-bp153.1.25.noarch disinstallazione di akregator-lang-20.04.2-bp153.2.23.noarch modifica di architettura di libKF5AkonadiCore5-20.04.2-bp153.4.2.1.x86_64 in libKF5AkonadiCore5-20.04.2-bp153.4.2.1.i586 modifica di architettura di libKF5AkonadiWidgets5-20.04.2-bp153.4.2.1.x86_64 in libKF5AkonadiWidgets5-20.04.2-bp153.4.2.1.i586 modifica di architettura di libKF5Mime5-20.04.2-bp153.2.2.1.x86_64 in libKF5Mime5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5AkonadiMime5-20.04.2-bp153.2.2.1.x86_64 in libKF5AkonadiMime5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5AkonadiSearch-20.04.2-bp153.2.2.1.x86_64 in libKF5AkonadiSearch-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5AkonadiXml5-20.04.2-bp153.4.2.1.x86_64 in libKF5AkonadiXml5-20.04.2-bp153.4.2.1.i586 disinstallazione di libKF5AlarmCalendar5-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di libKF5MailImporterAkonadi5-20.04.2- bp153.2.2.1.x86_64 in libKF5MailImporterAkonadi5-20.04.2-bp153.2.2.1.i586 disinstallazione di libKF5MailTransportAkonadi5-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di libKF5AkonadiAgentBase5-20.04.2- bp153.4.2.1.x86_64 in libKF5AkonadiAgentBase5-20.04.2-bp153.4.2.1.i586 disinstallazione di kmymoney-5.1.1-bp153.2.2.1.x86_64 disinstallazione di kmailtransport-20.04.2-bp153.2.2.1.x86_64 disinstallazione di kmail-account-wizard-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di akonadi-server-20.04.2-bp153.4.2.1.x86_64 in akonadi-server-20.04.2-bp153.4.2.1.i586 modifica di architettura di akonadi-search-20.04.2-bp153.2.2.1.x86_64 in akonadi-search-20.04.2-bp153.2.2.1.i586 modifica di architettura di akonadi-plugin-mime-20.04.2-bp153.2.2.1.x86_64 in akonadi-plugin-mime-20.04.2-bp153.2.2.1.i586 disinstallazione di akonadi-plugin-kalarmcal-20.04.2-bp153.2.2.1.x86_64 disinstallazione di akonadi-plugin-calendar-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di libKF5AkonadiPrivate5-20.04.2-bp153.4.2.1.x86_64 in libKF5AkonadiPrivate5-20.04.2-bp153.4.2.1.i586 modifica di architettura di libKPimItinerary5-20.04.2-bp153.2.2.1.x86_64 in libKPimItinerary5-20.04.2-bp153.2.2.1.i586 disinstallazione di libksieve-20.04.2-bp153.2.2.1.x86_64 modifica di architettura di libKF5Mbox5-20.04.2-bp153.2.2.1.x86_64 in libKF5Mbox5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5IMAP5-20.04.2-bp153.2.2.1.x86_64 in libKF5IMAP5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5AkonadiNotes5-20.04.2-bp153.2.2.1.x86_64 in libKF5AkonadiNotes5-20.04.2-bp153.2.2.1.i586 modifica di architettura di kleopatra-20.04.2-bp153.2.2.1.x86_64 in kleopatra-20.04.2-bp153.2.2.1.i586 disinstallazione di kmymoney-lang-5.1.1-bp153.2.2.1.noarch modifica di architettura di libKF5MailImporter5-20.04.2-bp153.2.2.1.x86_64 in libKF5MailImporter5-20.04.2-bp153.2.2.1.i586 downgrade di libKF5CalendarCore5-17.12.3-bp150.2.2.x86_64 a libKF5CalendarCore5-5.76.0-bp153.2.2.1.i586 modifica di architettura di libKF5CalendarCore5-17.12.3-bp150.2.2.x86_64 in libKF5CalendarCore5-5.76.0-bp153.2.2.1.i586 modifica di architettura di libKF5IdentityManagement5-20.04.2- bp153.2.2.1.x86_64 in libKF5IdentityManagement5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5PimCommon5-20.04.2-bp153.2.2.1.x86_64 in libKF5PimCommon5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5PimTextEdit5-20.04.2-bp153.2.2.1.x86_64 in libKF5PimTextEdit5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5CalendarUtils5-20.04.2-bp153.2.2.1.x86_64 in libKF5CalendarUtils5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5Tnef5-20.04.2-bp153.2.2.1.x86_64 in libKF5Tnef5-20.04.2-bp153.2.2.1.i586 disinstallazione di libKPimGAPICalendar5-20.04.2-bp153.3.2.1.x86_64 disinstallazione di libKPimGAPITasks5-20.04.2-bp153.3.2.1.x86_64 modifica di architettura di libKF5Ldap5-20.04.2-bp153.2.2.1.x86_64 in libKF5Ldap5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5Gravatar5-20.04.2-bp153.2.2.1.x86_64 in libKF5Gravatar5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5Libkleo5-20.04.2-bp153.2.2.1.x86_64 in libKF5Libkleo5-20.04.2-bp153.2.2.1.i586 modifica di architettura di kldap-20.04.2-bp153.2.2.1.x86_64 in kldap-20.04.2-bp153.2.2.1.i586 modifica di architettura di kcalutils-20.04.2-bp153.2.2.1.x86_64 in kcalutils-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5GrantleeTheme5-20.04.2-bp153.2.2.1.x86_64 in libKF5GrantleeTheme5-20.04.2-bp153.2.2.1.i586 modifica di architettura di libKF5KontactInterface5-20.04.2- bp153.2.2.1.x86_64 in libKF5KontactInterface5-20.04.2-bp153.2.2.1.i586 Soluzione 2: non chiedere di installare un risolubile che fornisce libKF5ContactEditor.so.5 Which is in plain English: either install all of the above with dependency hell or: do not ask to install a resolution that delivers libKF5ContactEditor.so.5 For what I understand at that point that one of the apps or whatever else program / libraries installed has a requires or? recommend that point to the need of libKF5ContactEditor.so.5, hence Kmail loads that module or whatever when starting up and runs into the conflict and crashes/aborts. Installation of the library is obviously not useful in this 64 bit system given the awful impact that would have. Is there a way to find out which file I have to get rid of in order to neutralize the problem with kmail? I will be thankful for whatever suggestion. P.S. I forgot, below the output when akonadi is started on the CLI, all seems perfect. hermes@azzurro:~> akonadictl status Akonadi Control: running Akonadi Server: running Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin) Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource
On 2022-12-07 22:29, Stakanov wrote:
After an update Kontact does not start, however Akonadi the "usual suspect" this time is not the culprit at all and runs flawlessly. I have the suspect the user (which did a zypper up) might have some repo or library that induced a mix between 32 bit and 64 bit. But I am no way sure and honestly I do not know how I could debug the presence of the problem.
To make it worse I have only the output in Italian, so please disregard if "non imperial outputs"are politically too incorrect. It is just what I have under hand, but should be quite understandable and is not used with any intent to set whatever "precedent" here.
First: the system is Leap 15.3 and should be, procrastination tendencies of the user permitting, soon be updated to 15.4. But I am somewhat prudent to do this now with the error active, as this might then break as well the upgrade.
What repos are active: # | Alias | Name | Enabled | GPG Check | Refresh | Type
---+-------------------------------------- +-------------------------------------+-----------+--------------- +---------------+-------
1 | https-download.opensuse.org-44cfee8e | openSUSE:Backports:SLE-15-SP3 | Sì | (r ) Sì | Sì | rpm-md
Ok, do this. Ask him to run: LC_ALL=en_US.UTF-8 zypper lr --details > somefile.txt can be done as plain user. Then he attach that file to an email to you. And then you attach that file to your reply here to us. Important: attach to email, do not paste inside an email. The lines wrap and become impossible to decipher. If you do not want to attach or can not, then upload to susepaste.org and post the link.
What is the error message when the user starts kmail:
kmail: symbol lookup error: /usr/lib64/libKF5ContactEditor.so.5: undefined symbol: _ZN9KContacts9Addressee16staticMetaObjectE
Please let us see the repository list in the format I asked above first, before continuing the analysis. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
In data giovedì 8 dicembre 2022 00:27:30 CET, Knurpht-openSUSE ha scritto:
Op donderdag 8 december 2022 00:22:03 CET schreef Stakanov:
In attachment list of repos
What we need is the URL produced by
zypper lr -d | susepaste
The attachment does not have all that
nice command, tried it on my tumbleweed. But for us not applicable because the life expectancy of this suse paste is only 59 minutes. Or am I expected to create another suse paste? I asked the user to provide the info as requested and will attach the txt here, but this will take time. As I said, all I have under my hands for now is what you have. As soon as I can you will be provided with more output.
On 2022-12-08 12:26, Stakanov wrote:
In data giovedì 8 dicembre 2022 00:27:30 CET, Knurpht-openSUSE ha scritto:
Op donderdag 8 december 2022 00:22:03 CET schreef Stakanov:
In attachment list of repos
What we need is the URL produced by
zypper lr -d | susepaste
The attachment does not have all that
nice command, tried it on my tumbleweed. But for us not applicable because the life expectancy of this suse paste is only 59 minutes. Or am I expected to create another suse paste? I asked the user to provide the info as requested and will attach the txt here, but this will take time.
Attaching is perfect, easy, fast and accurate. Easy archival. Anyway, you can change the timeout in susepaste. zypper lr -d | susepaste -n "Stakanov" -t "zypper command" -e 10080 It is explained in the manual. -e EXPIRE for how log will be paste stored on the server. Default is 30 minutes, possible values are: 30 30 Minutes 60 1 Hour 360 6 Hours 720 12 Hours 1440 1 Day 10080 1 Week 40320 1 Month 151200 3 Months 604800 1 Year 1209600 2 Years 1814400 3 Years 0 Never But not everybody has susepaste installed, and some times it fails. It may think you are a spammer, for instance. Thus I prefer attachments, it is not really big, just text.
As I said, all I have under my hands for now is what you have. As soon as I can you will be provided with more output.
Good. We'll wait. :-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, Dec 08, 2022 at 12:26:47PM +0100, Stakanov wrote:
In data giovedì 8 dicembre 2022 00:27:30 CET, Knurpht-openSUSE ha scritto:
Op donderdag 8 december 2022 00:22:03 CET schreef Stakanov:
In attachment list of repos
What we need is the URL produced by
zypper lr -d | susepaste
The attachment does not have all that
nice command, tried it on my tumbleweed. But for us not applicable because the life expectancy of this suse paste is only 59 minutes.
You can change the life expectancy with the -e EXPIRE option to susepaste. Value is in minutes. See the last two examples in the manpage, or tweak ~/.susepaste to save a preference. eg: susepaste -e "10080" # stored for 1 week HTH, Daniel
In data giovedì 8 dicembre 2022 12:57:50 CET, Daniel Morris ha scritto:
On Thu, Dec 08, 2022 at 12:26:47PM +0100, Stakanov wrote:
In data giovedì 8 dicembre 2022 00:27:30 CET, Knurpht-openSUSE ha scritto:
Op donderdag 8 december 2022 00:22:03 CET schreef Stakanov:
In attachment list of repos
What we need is the URL produced by
zypper lr -d | susepaste
The attachment does not have all that
nice command, tried it on my tumbleweed. But for us not applicable because the life expectancy of this suse paste is only 59 minutes.
You can change the life expectancy with the -e EXPIRE option to susepaste. Value is in minutes. See the last two examples in the manpage, or tweak ~/.susepaste to save a preference. eg:
susepaste -e "10080" # stored for 1 week
HTH, Daniel Thank you to both you Daniel and Carlos. I did not know the option and will use it in the future when having to paste for my own needs. I ackowledge the idea of archival too, but that info e.g. is not so durable.
I already requested the info and hope to have feedback within tonight.
On 2022-12-08 00:22, Stakanov wrote:
In attachment list of repos
No, sorry, you forgot to use "--details". The list as posted, is useless. Pay attention: LC_ALL=en_US.UTF-8 zypper lr --details > somefile.txt That exact command line. Not any other. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
In data giovedì 8 dicembre 2022 01:19:43 CET, Carlos E. R. ha scritto:
On 2022-12-08 00:22, Stakanov wrote:
In attachment list of repos
No, sorry, you forgot to use "--details". The list as posted, is useless. Pay attention:
LC_ALL=en_US.UTF-8 zypper lr --details > somefile.txt
That exact command line. Not any other.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
l'output as desired (attachment)
On 2022-12-08 19:59, Stakanov wrote:
In data giovedì 8 dicembre 2022 01:19:43 CET, Carlos E. R. ha scritto:
On 2022-12-08 00:22, Stakanov wrote:
In attachment list of repos
No, sorry, you forgot to use "--details". The list as posted, is useless. Pay attention:
LC_ALL=en_US.UTF-8 zypper lr --details > somefile.txt
That exact command line. Not any other.
l'output as desired (attachment)
Thanks. See, the first thing is looking at the URLs, that now are included, and check that all say "15.3". This is crucial, this is why we insisted on "--details" or "-d". We really needed that. But it is not the problem, all the repos are for 15.3. I see he has activated debug repos and source repos. This is not normally needed, unless some cases, like when reporting a crash. The source repos are even more rare for a user. Very probably he can deactivate the source repos (numbers 13 and 14), and quite probably he can deactivate the debug repos (5, 7, 8, 11). Notice, deactivate, not delete. He is not using extra repos. Only packman and dvdcss. Good. But that eliminates the problem of an extra repo disappearing before the distribution being EOL. (I see the security repo, but it is deactivated). Ok, so now we have to examine the update problem directly. What command is he using? I think he is doing "zypper in libKF5ContactEditor.so.5". Change that to: LC_ALL=en_US.UTF-8 zypper in libKF5ContactEditor.so.5 which will make the output be in English. Then he can select the whole text and paste it into webpage <https://susepaste.org/> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2022-12-09 00:23, Stakanov wrote:
LC_ALL=en_US.UTF-8 zypper in libKF5ContactEditor.so.5 security repo: was the repo already deactivated for 15.3?? I had it deactivated now to find out if it was related and to lower the number of
In data giovedì 8 dicembre 2022 21:05:17 CET, Carlos E. R. ha scritto: possible errors.
I can't know when it was deactivated. Maybe the file "/var/log/zypper.log" has the event registered. There is a text similar to this: ... alias : Ext_Packman ... name : EXT: Packman Repository ... enabled : 0 that maybe tells when it was deactivated. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, 8 Dec 2022 21:22:15 -0600, Larry Len Rainey <llrainey15@gmail.com> wrote:
On 12/8/22 21:00, Carlos E. R. wrote:
On 2022-12-09 00:23, Stakanov wrote:
LC_ALL=en_US.UTF-8 zypper in libKF5ContactEditor.so.5 security repo: was the repo already deactivated for 15.3?? I had it deactivated now to find out if it was related and to lower the number of
In data giovedì 8 dicembre 2022 21:05:17 CET, Carlos E. R. ha scritto: possible errors.
I can't know when it was deactivated. Maybe the file "/var/log/zypper.log" has the event registered.
There is a text similar to this: ... alias : Ext_Packman ... name : EXT: Packman Repository ... enabled : 0
that maybe tells when it was deactivated.
You can get the date by "ls -la /etc/zypp/repos.d" It will have the date last modified. [...]
It might be worth it to check that zypper thinks everything is in order according to the repo setup as it is now. 'zypper --non-interactive verify -D > zypper-verify.log 2>&1' -- Robert Webb
On Fri, 9 Dec 2022 04:38:09 +0000 (UTC), Robert Webb <webbdg@verizon.net> wrote:
It might be worth it to check that zypper thinks everything is in order according to the repo setup as it is now.
'zypper --non-interactive verify -D > zypper-verify.log 2>&1'
If the above command shows that zypper wanted to change anything, try it also with the '--solver-focus Installed' option to see the minimum changes needed to make the system consistent with the repos: 'zypper --non-interactive verify -D --solver-focus Installed > zypper-verify-focus_installed.log 2>&1' -- Robert Webb
In data sabato 10 dicembre 2022 02:13:06 CET, Robert Webb ha scritto:
On Fri, 9 Dec 2022 04:38:09 +0000 (UTC), Robert Webb <webbdg@verizon.net> wrote:
It might be worth it to check that zypper thinks everything is in order according to the repo setup as it is now.
'zypper --non-interactive verify -D > zypper-verify.log 2>&1'
If the above command shows that zypper wanted to change anything, try it also with the '--solver-focus Installed' option to see the minimum changes needed to make the system consistent with the repos:
'zypper --non-interactive verify -D --solver-focus Installed > zypper-verify-focus_installed.log 2>&1'
-- Robert Webb
Thank you very much. I will give feedback once the user has a time slot to deliver the info. But also thank you personally because I will make treasure of your commands. very much appreciated. S.
In data venerdì 9 dicembre 2022 04:22:15 CET, Larry Len Rainey ha scritto:
On 12/8/22 21:00, Carlos E. R. wrote:
On 2022-12-09 00:23, Stakanov wrote:
In data giovedì 8 dicembre 2022 21:05:17 CET, Carlos E. R. ha scritto:
LC_ALL=en_US.UTF-8 zypper in libKF5ContactEditor.so.5
security repo: was the repo already deactivated for 15.3?? I had it deactivated now to find out if it was related and to lower the number of possible errors.
I can't know when it was deactivated.
Maybe the file "/var/log/zypper.log" has the event registered.
There is a text similar to this:
... alias : Ext_Packman ... name : EXT: Packman Repository ... enabled : 0
that maybe tells when it was deactivated.
You can get the date by "ls -la /etc/zypp/repos.d"
It will have the date last modified.
Like this from my computer:
ls -la /etc/zypp/repos.d total 72 drwxr-xr-x 4 root root 4096 Dec 3 13:03 . drwxr-xr-x 10 root root 4096 Oct 11 13:09 .. -rw-r--r-- 1 root root 97 Jan 16 2021 adobe.repo -rw-r--r-- 1 root root 115 Oct 12 2021 brave-browser.repo -rw-r--r-- 1 root root 124 Dec 4 07:27 mozilla.repo -rw-r--r-- 1 root root 209 Jul 24 16:56 os-repo-backports-update.repo -rw-r--r-- 1 root root 203 Jun 29 15:28 os-repo-non-oss.repo -rw-r--r-- 1 root root 191 Jun 29 15:28 os-repo-oss.repo -rw-r--r-- 1 root root 205 Jul 24 16:57 os-repo-sle-update.repo -rw-r--r-- 1 root root 193 Jul 24 16:57 os-repo-update-non-oss.repo -rw-r--r-- 1 root root 186 Jul 24 16:58 os-repo-update-oss.repo -rw-r--r-- 1 root root 228 Jun 29 17:44 os-repo-virtual.repo -rw-r--r-- 1 root root 178 Jun 9 20:44 packman.repo -rw-r--r-- 1 root root 182 Oct 12 2021 skype-stable.repo -rw-r--r-- 1 root root 233 Jun 9 20:53 teamviewer.repo
My fault of not being clear. I asked the user after the error appeared to try to deactivate the repo and do zypper up --allow-vendor-change But this might not have been sufficient because if the versions of the security repo are higher then it will still stay on the security ones (which might cause the error). Usual culprits would be a non compatible ClamAv version or a gpg related issue (which would fit with being in use with kontact. So what would I do as command to make sure that all packages originally stemming from "security" are substituted with the normal repo versions (just to eliminate the source of error, not because I think security is not ok. What I originally asked was: has (by openSUSE) the repo been already deactivated for 15.3? I thought the 15.3 have not been set to EOL up to now, did not receive a warning. Thanks.
On 2022-12-09 10:20, Stakanov wrote:
In data venerdì 9 dicembre 2022 04:22:15 CET, Larry Len Rainey ha scritto:
On 12/8/22 21:00, Carlos E. R. wrote:
My fault of not being clear. I asked the user after the error appeared to try to deactivate the repo and do zypper up --allow-vendor-change But this might not have been sufficient because if the versions of the security repo are higher then it will still stay on the security ones (which might cause the error). Usual culprits would be a non compatible ClamAv version or a gpg related issue (which would fit with being in use with kontact.
So what would I do as command to make sure that all packages originally stemming from "security" are substituted with the normal repo versions (just to eliminate the source of error, not because I think security is not ok.
What I originally asked was: has (by openSUSE) the repo been already deactivated for 15.3?
Ah. The command in that case would be "zypper dup --allow-vendor-change". Normally I would say not to do that, but considering the list of repos is limited, it should be no problem.
I thought the 15.3 have not been set to EOL up to now, did not receive a warning.
Yes, the warning was posted days ago. <https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/message/OCJDZIP63AUG4TW4W5JKR6TVWZ6N2TMT/> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [12-09-22 05:41]:
On 2022-12-09 10:20, Stakanov wrote:
In data venerdì 9 dicembre 2022 04:22:15 CET, Larry Len Rainey ha scritto:
On 12/8/22 21:00, Carlos E. R. wrote:
My fault of not being clear. I asked the user after the error appeared to try to deactivate the repo and do zypper up --allow-vendor-change But this might not have been sufficient because if the versions of the security repo are higher then it will still stay on the security ones (which might cause the error). Usual culprits would be a non compatible ClamAv version or a gpg related issue (which would fit with being in use with kontact.
So what would I do as command to make sure that all packages originally stemming from "security" are substituted with the normal repo versions (just to eliminate the source of error, not because I think security is not ok.
What I originally asked was: has (by openSUSE) the repo been already deactivated for 15.3?
Ah.
The command in that case would be "zypper dup --allow-vendor-change". Normally I would say not to do that, but considering the list of repos is limited, it should be no problem.
really not. use "zypper -v dup " and zypper will announce the necessary changes available and <user> can select those appropriate.
I thought the 15.3 have not been set to EOL up to now, did not receive a warning.
Yes, the warning was posted days ago.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2022-12-08 a las 21:05 +0100, Carlos E. R. escribió:
On 2022-12-08 19:59, Stakanov wrote:
In data giovedì 8 dicembre 2022 01:19:43 CET, Carlos E. R. ha scritto:
On 2022-12-08 00:22, Stakanov wrote:
...
Ok, so now we have to examine the update problem directly. What command is he using?
I think he is doing "zypper in libKF5ContactEditor.so.5". Change that to:
LC_ALL=en_US.UTF-8 zypper in libKF5ContactEditor.so.5
which will make the output be in English. Then he can select the whole text and paste it into webpage <https://susepaste.org/>
There is some command that can be used to find out if there are packages that do not belong to 15.3. rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE Leap 15\.3|openSUSE_Leap_15.3|\-lp153|SUSE Linux Enterprise 15" | less -S You can copy paste the command as is, several lines. Notice that the "\" at the end of each line means that the command contiues in the next line. You can also paste it as a single long line removing the "\": rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" | sort | cut --fields="2-" | tee rpmlist | egrep -v "openSUSE Leap 15\.3|openSUSE_Leap_15.3|\-lp153|SUSE Linux Enterprise 15" | less -S Some of the rpms will be correct, but perhaps some of them are not. The command generates a file, "rpmlist", that you can email me off list. Then I analyze it and tell you if I see wrong rpm (if they leap to the eye). There is this other command that Robert Webb suggested: zypper --non-interactive verify -D > zypper-verify.log 2>&1 - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY5NAcxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV6PYAnicZSMD5jwk0na/9W7bC Wd9zq5dgAJwJVxLjlniyenhlex/6hRMSwgxjUw== =3SmX -----END PGP SIGNATURE-----
El 2022-12-08 a las 21:05 +0100, Carlos E. R. escribió: So the problem was in the repo "backports" not maintained anymore or not reachable at least on the selected server. We did deactivate that repo and
In data venerdì 9 dicembre 2022 15:04:35 CET, Carlos E. R. ha scritto: then did a "sudo zypper dup --allow-vendor-change which did change 11 packages to packman and did downgrade (and that did the trick) 15 from Backports to the repos. And now it all works. Thank you all very much for help and input, was very appreciated! S.
participants (7)
-
Carlos E. R. -
Daniel Morris -
Knurpht-openSUSE -
Larry Len Rainey -
Patrick Shanahan -
Robert Webb -
Stakanov