where is "detailed report" from update errors?

Hi,

I often have dependency resolution fails when I update.

These error messages that pop up are quite brief, but they refer to a “detailed report”.
Where is this detailed report? I just can’t find it.

Searching the forums it seems that a few people wondered where it is.

Best
Marc

What repos do you use?
Please post a list:

zypper lr -d

There shouldn’t be dependency problems with the standard ones…

These error messages that pop up are quite brief, but they refer to a “detailed report”.
Where is this detailed report? I just can’t find it.

Probably in /var/log/pk_backend_zypp.
But it might be easier to just run “sudo zypper up” in a terminal window and check the output.

no, it’s no standard repo,

marc@TheD:~> zypper lr -d

| Alias | Name | Aktiviert | GPG-Überprüfung | Aktualisieren | Priorität | Typ | URI | Dienst

—±------------------------------------±--------------------------------------------------------±----------±----------------±--------------±----------±-------±--------------------------------------------------------------------------------------------±------
1 | download.opensuse.org-non-oss | Haupt-Repository (NON-OSS) | Ja | (r ) Ja | Ja | 99 | yast2 | http://download.opensuse.org/distribution/leap/42.1/repo/non-oss/ |
2 | download.opensuse.org-non-oss_1 | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/42.1/non-oss/ |
3 | download.opensuse.org-oss | Haupt-Repository (OSS) | Ja | (r ) Ja | Ja | 99 | yast2 | http://download.opensuse.org/distribution/leap/42.1/repo/oss/ |
4 | download.opensuse.org-oss_1 | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/42.1/oss |
5 | http-download.opensuse.org-29331b2e | home:Sauerland | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_42.1/ |
6 | http-download.opensuse.org-53f44a1e | openSUSE:Leap:42.1 | Ja | (r ) Ja | Ja | 99 | yast2 | http://download.opensuse.org/distribution/leap/42.1/repo/oss/ |
7 | http-download.opensuse.org-6b62d099 | openSUSE:Leap:42.1 | Ja | (r ) Ja | Ja | 99 | yast2 | http://download.opensuse.org/distribution/leap/42.1/repo/oss/ |
8 | http-download.opensuse.org-90fbc023 | home:beyerle:IAC | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/home:/beyerle:/IAC/openSUSE_Leap_42.1/ |
9 | openSUSE-42.1-0 | openSUSE-42.1-0 | Nein | ---- | Nein | 99 | yast2 | cd:///?devices=/dev/disk/by-id/ata-VBOX_CD-ROM_VB2-01700376 |
10 | openSUSE_42.1 | openSUSE_42.1 | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/devel:/languages:/R:/released/openSUSE_Leap_42.1/ |
11 | packman.inode.at-suse | Packman Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | Index of /pub/linux/misc/packman/suse/openSUSE_Leap_42.1/ |
12 | repo-non-oss | openSUSE-Leap-42.1-Non-Oss | Nein | ---- | Ja | 99 | NONE | http://download.opensuse.org/distribution/leap/42.1/repo/non-oss/ |
13 | repo-oss | openSUSE-Leap-42.1-Oss | Ja | (r ) Ja | Ja | 99 |p://download.opensuse.org/distribution/leap/42.1/repo/oss/ |
14 | repo-source | openSUSE-Leap-42.1-Source | Ja | (r ) Ja | Ja | 99 |p://download.opensuse.org/source/distribution/leap/42.1/repo/oss/ |
15 | repo-tuxedo-computers | TUXEDO Computers - openSUSE leap | Ja | (r ) Ja | Ja | 99 |p://rpm.tuxedocomputers.com/opensuse/leap |
16 | repo-update | openSUSE-Leap-42.1-Update | Ja | (r ) Ja | Ja | 99 |p://download.opensuse.org/update/leap/42.1/oss/ |
17 | repo-update-non-oss | openSUSE-Leap-42.1-Update-Non-Oss | Ja | (r ) Ja | Ja | 99 |p://download.opensuse.org/update/leap/42.1/non-oss/ |

I ran zypper up and 3 of 4 errors are gone. (These were ffmpeg updates)

The last one remaning is:
openSUSE-2016-37(1) security update

Nevertheless I would be interested in how to show this “detailed report”

I’ve never been able to find that “detailed report”. The update applet should tell us where to find it (IMO). So I see this as a flaw in that applet. However, I have not reported as a bug, since I prefer to turn off the update applet and use Yast and zypper, which do give better messages.

Ok, that’s likely the reason for your update problems.
I don’t see anything particularly wrong there, except some duplicates, #1 to #7 in particular.
You could remove them but they shouldn’t cause a problem either.

But especially in case of updates it might take a while until they propagate to those other repos.

And some repos might be setup to build against openSUSE:Leap:42.1 standard instead of openSUSE:Leap:42.1:Update, which can “break” them if there are updates. That’s up to the maintainers of the particular repos though.

As a side-note: next time please post something like this in

 tags (''#" button in the editor's toolbar) instead of QUOTE's, so that the URLs don't get truncated. Makes it easier for people trying to help you... ;)


> I ran zypper up and 3 of 4 errors are gone. (These were ffmpeg updates)

Ok, so those were probably just "timing" issues, the update should have worked now with the desktop's updater as well I suppose.



> The last one remaning is: 
> openSUSE-2016-37(1) security update

Hard to say without the explicit error message.
Can you please post that?

I'm not (yet) running Leap 42.1 myself and have no idea what the "openSUSE-2016-37(1) security update" is about.


> Nevertheless I would be interested in how to show this "detailed report"

Well, I already told you all that I know about it.

Hi
I think they mean packagekit…


pkcon -v get-details openSUSE-2016-37

18:45:28    PackageKit          Verbose debugging enabled (on console 1)
18:45:28    PackageKit          filter=(null), filters=0
18:45:28    PackageKit          resolving 1 packages
18:45:28    PackageKit          role now resolve
Resolving                                              ] (0%)  18:45:29    PackageKit          adding state 0x557e8b8040d0
18:45:29    PackageKit          role now get-details
                              =========================]         
Getting details               =========================]         
Querying                                               ] (0%)  18:45:29    PackageKit          notify::connected
18:45:29    PackageKit          skipping as the same
                              =========================]         
Finished                                               ] (0%)  18:45:29    PackageKit          remove state 0x557e8b8040d0
                              =========================]         
Package description
  package:     openSUSE-2016-37-1.noarch
  summary:     
  license:     
  group:       unknown
  description: 
This update for libebml, libmatroska fixes the following security issues:

Vulnerabilities fixed in libebml:

* Cisco TALOS-CAN-0036: Invalid memory access when reading from a UTF-8 string resulted in a heap information leak (bsc#961031).
* Cisco TALOS-CAN-0037: Deeply nested elements with infinite size use-after-free and multiple free (bsc#961031).
* Invalid mempry access resulted in heap information leak

Vulnerabilities fixed in libmatroska:
* invalid memory access when reading specially crafted data lead to a heap information leak.

  size:        0 bytes
  url:

Maybe it provides other info on error…

The ‘detailed report’ message is also seen when the kde crash reporter pops up. If I am unable to load the requested debug files the reporter says refer to the ‘detailed report’. I’ve looked at /var/log/pk_backend_zypp and don’t find it informative regarding this situation. When the reporter attempts to download debug files it opens a terminal window and writes a few lines to the screen and then closes so fast that terminal window and leaves me ‘in the dark’ as to what was written to the screen.

When I get time to play with this again I’m going to set up a camera and try to capture the output. I should not need to do that. Since the purpose of debugging is to find out what is wrong I would think that if there is a problem the terminal window should remain open so the user can see what is wrong and then prompt the user to close it.

Or a log file should be created when the crash reporter appears.

jon

All right, then it’s likely this problem:
http://bugzilla.opensuse.org/show_bug.cgi?id=961994

An update to fix the dependencies is on the way.

The KDE bug reporter tool doesn’t use PackageKit at all, it uses zypper directly (the KF5 version opens a Konsole for that as you describe).
So obviously you won’t find any info in PackageKit’s log.

I’m not sure at the moment what happens when the debuginfo files are not found, but for this to work you have to enable repo-debug and repo-debug-update in YaST->Software Repositories.
There was a problem with Leap’s debug-update repo though (it contained the wrong files), I’m not sure if this has been fixed already.

When I get time to play with this again I’m going to set up a camera and try to capture the output. I should not need to do that. Since the purpose of debugging is to find out what is wrong I would think that if there is a problem the terminal window should remain open so the user can see what is wrong and then prompt the user to close it.

Well, that terminal window is not supposed to let you do some debugging. You have the “Debug with GDB” button for that. :wink:
The terminal window is only used to run zypper to install the debuginfo packages.

Btw, this is handled by a (distribution specific) shell script: /usr/bin/installdbgsymbols.sh

Feel free to improve it and submit a better version.

That’s exactly the point.

A detailed error message would help here. And the applet refers to a detailed report. However, it doesn’t provide it.

No, it’s not.
I asked about zypper’s output.

A detailed error message would help here. And the applet refers to a detailed report. However, it doesn’t provide it.

Yes. But as I wrote already, the only PackageKit log I am aware of is /var/log/pk_backend_zypp, maybe this is what it refers too.
And that log depends on the PAckageKit backend in use (PackageKit is distribution agnostic and provides backends for the different distributions/package management systems).

That’s the one I posted above.
If you mean “zypper up” there were no errors, the openSUSE-2016-37(1) package is not mentioned there.

Best
Marc

Hi
Try the patch option then;


zypper -t patch

aha now I have something useful:


marc@TheD:~> sudo zypper -t patch
root's password:
Daten des Repositories laden ...
Installierte Pakete lesen ...
Paketabhängigkeiten auflösen ...

Problem: vlc-noX-2.2.1-305.1.x86_64 benötigt libmatroska.so.6(V_1.4.1)(64bit), kann jedoch nicht zur Verfügung gestellt werden
Lösung 1: Folgende Aktionen werden ausgeführt:
  Downgrade von vlc-noX-2.2.1-305.1.x86_64 zu vlc-noX-2.2.1-131.3.x86_64
  Downgrade von vlc-2.2.1-305.1.x86_64 zu vlc-2.2.1-131.3.x86_64
  Downgrade von vlc-qt-2.2.1-305.1.x86_64 zu vlc-qt-2.2.1-131.3.x86_64
  Downgrade von libvlccore8-2.2.1-305.1.x86_64 zu libvlccore8-2.2.1-131.3.x86_64
Lösung 2: patch:openSUSE-2016-37-1.noarch nicht installieren
Lösung 3: vlc-noX-2.2.1-305.1.x86_64 durch Ignorieren einiger Abhängigkeiten brechen


which means there is a conflict with vlc-noX-2.2.1-305.1.x86_64 which needs libmatroska.so.6(V_1.4.1)(64bit) but can’t be provided.

I can 1. either downgrade some vlc stuff, 2. not install the patch, or 3. break vlc by ignoring dependencies.

1, 2 or 3? suggestions?

Best
Marc

Neither of them. Just wait until this is fixed.

As I wrote already, this is a known problem with that update, another update is on the way.

I went with 1 (the downgrade). That was followed by another conflict dialog, where I again went with the downgrade.

See my reply in another thread, where I went into more detail on my reasoning.

A vlc update has been released meanwhile to fix the conflict, and it was not a problem in Packman yesterday already.
AFAICS, the VideoLAN vlc package has not been updated yet, so will still give a conflict.

But, I noticed a very strange version number in the posted conflict message:

Problem: vlc-noX-2.2.1-305.1.x86_64 benötigt libmatroska.so.6(V_1.4.1)(64bit), kann jedoch nicht zur Verfügung gestellt werden
Lösung 1: Folgende Aktionen werden ausgeführt:
  Downgrade von vlc-noX-2.2.1-305.1.x86_64 zu vlc-noX-2.2.1-131.3.x86_64
  Downgrade von vlc-2.2.1-305.1.x86_64 zu vlc-2.2.1-131.3.x86_64
  Downgrade von vlc-qt-2.2.1-305.1.x86_64 zu vlc-qt-2.2.1-131.3.x86_64
  Downgrade von libvlccore8-2.2.1-305.1.x86_64 zu libvlccore8-2.2.1-131.3.x86_64

There is no 2.2.1-305.1 in any repo, so this is likely some old version.
In this case it is indeed the correct (and best) option to choose Solution 1 and “downgrade” vlc.

I did the same thing, too. Sounds reasonable.

Using Leap I have these issues with OpenSUSE-2016-23(1) and OpenSUSE-2016-37(1)

using:~ # zypper -t patch
Retrieving repository 'openSUSE BuildService - devel:languages:python' m[done]
Building repository 'openSUSE BuildService - devel:languages:python' cac[done]
Loading repository data...
Reading installed packages...
Resolving package dependencies...
2 Problems:
Problem: vlc-noX-2.2.1-301.2.x86_64 requires libmatroska.so.6(V_1.4.1)(64bit), but this requirement cannot be provided
Problem: calligra-extras-okular-2.9.8-62.2.x86_64 requires libokularcore.so.6()(64bit), but this requirement cannot be provided

Problem: vlc-noX-2.2.1-301.2.x86_64 requires libmatroska.so.6(V_1.4.1)(64bit), but this requirement cannot be provided
 Solution 1: Following actions will be done:
  downgrade of vlc-noX-2.2.1-301.2.x86_64 to vlc-noX-2.2.1-132.2.x86_64
  downgrade of vlc-2.2.1-301.2.x86_64 to vlc-2.2.1-132.2.x86_64
  downgrade of vlc-qt-2.2.1-301.2.x86_64 to vlc-qt-2.2.1-132.2.x86_64
 Solution 2: do not install patch:openSUSE-2016-37-1.noarch
 Solution 3: break vlc-noX-2.2.1-301.2.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c] (c):

As has been written already a few times, you have an old vlc version installed (which had a higher rebuild number).
Choose “Solution 1” and “downgrade” vlc.

The calligra-extras-okular unfortunately is not compatible with the latest okular 15.12. You might want to file a bug report about this to get an update.

Workarounds for now:
Either uninstall calligra-extras-okular (but then you won’t be able to view Calligra documents in Okular), or install calligra from KDE:Extra.

I filed a bug report about this myself now:
https://bugzilla.opensuse.org/show_bug.cgi?id=963570

I’m gonna submit an update as soon as the maintenance team give their ok…