Bug 1544193 - Error: Failed to synchronize cache for repo 'fedora-cisco-openh264-debuginfo'
Summary: Error: Failed to synchronize cache for repo 'fedora-cisco-openh264-debuginfo'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-repos
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1558064 (view as bug list)
Depends On:
Blocks: F28BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2018-02-11 07:42 UTC by Chris Murphy
Modified: 2018-03-20 18:45 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-20 18:45:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Chris Murphy 2018-02-11 07:42:57 UTC
Description of problem:

Trying to get coredumpctl gdb backtraces for things, and I get recommendations what debuginfos to install, those work. But then I get these "separate debuginfo" ones to install and they fail with this error every time.


Example:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libxkbcommon-x11.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/3d/ac0662c124730b3e94431c59cbe900fe808d2a.debug
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007efcddaacff4 in meta_window_actor_is_destroyed (self=0x5645247547f0) at compositor/meta-window-actor.c:911
911	  return self->priv->disposed || self->priv->needs_destroy;
[Current thread is 1 (Thread 0x7efce04a0100 (LWP 1358))]
(gdb) quit
[chris@localhost-live ~]$ sudo dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/3d/ac0662c124730b3e94431c59cbe900fe808d2a.debug
Error: Failed to synchronize cache for repo 'fedora-cisco-openh264-debuginfo'
[chris@localhost-live ~]$ 


Version-Release number of selected component (if applicable):
dnf-2.7.5-5.fc28.noarch

How reproducible:
Pretty much always there's a need for a "separate debuginfo" and it always fails with this error.

Steps to Reproduce:
1. Run the recommended command to install separate debug info
2.
3.

Actual results:

fails with error

Expected results:

should work or give some meaningful message how to work around it

Additional info:


[chris@localhost-live ~]$ sudo dnf -v --enablerepo='*debug*' install /usr/lib/debug/.build-id/3d/ac0662c124730b3e94431c59cbe900fe808d2a.debug
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repograph, repomanage, reposync
DNF version: 2.7.5
cachedir: /var/cache/dnf
Cannot download 'https://codecs.fedoraproject.org/openh264/28/x86_64/debug/': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried.
Error: Failed to synchronize cache for repo 'fedora-cisco-openh264-debuginfo'
[chris@localhost-live ~]$

Comment 1 Igor Gnatenko 2018-02-11 08:39:32 UTC
Unfortunately, DNF can't make repository to appear ;) It's just openh264-debuginfo which doesn't exist in this world.

Comment 2 Fedora End Of Life 2018-02-20 15:35:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 3 Kevin Fenzi 2018-03-03 21:51:58 UTC
Dennis was working on making this repo exist...

Comment 4 Kalev Lember 2018-03-15 09:49:12 UTC
I'll nominate this as a F28 Beta blocker.

Right now we don't have fedora-cisco-openh264 repo metadata for F28. This is somewhat OK for dnf as the repo is enabled=0 so it's skipped for regular 'dnf update'. However, the repo is also enabled_metadata=1, together with a flag that marks it as required (skip_if_unavailable=False) which makes libdnf/packagekitd error out when adding the openh264 repo.

This makes gnome-software completely unusable in F28: there's no metadata, .repo file marks the repo as required, so packagekit treats it as so, and gnome-software doesn't see any repos at all as one of the required repos is missing. 

Here's a few ways how to fix it:

1) add empty openh264 repo metadata, so that we can get gnome-software quickly working without having to ship the rpm updates to cisco
2) remove skip_if_unavailable=False from fedora-cisco-openh264.repo -- this would make packagekit skip over the repo instead of erroring out
3) ship the new F28 rpms to cisco and add actual metadata

One (or more) of this needs to happen for F28 Beta, otherwise gnome-software doesn't work at all.

In addition, we need to have something so that this doesn't keep breaking every time we branch. I'd suggest having (1) in mass branching SOP, and possibly doing (2) as well, as the repo isn't really a core fedora repo and is somewhat out of our control.

P.S. the gnome 3.28.0 megaupdate that I've proposed as FE separately improves this situation by making the missing repo metadata errors correctly show up in gnome-software, instead of just silently failing.

P.P.S I filed https://pagure.io/fedora-repos/pull-request/69 to implement (2), but Dennis thought it would be better to do (1) instead.

Comment 5 Adam Williamson 2018-03-16 22:50:19 UTC
It does affect other stuff too, btw - e.g. it affects the packagekit-command-not-found thingy we have installed by default, that's meant to install commands you try and run that aren't installed. That fails for the same reason.

I'm +1 blocker on this. 1) is the way we've usually resolved this before (it happens every cycle, the real packages are never ready by Alpha/Beta).

Comment 6 Patrick Uiterwijk 2018-03-16 22:52:04 UTC
+1 for blocker.

Comment 7 Kevin Fenzi 2018-03-16 23:45:36 UTC
+1 blocker, way 1 would be best... and best added to the branching SOP checklist so we do it every time.

Comment 8 Dennis Gilmore 2018-03-16 23:46:07 UTC
The repo will exist as soon as the syncing process runs.

Comment 9 Dennis Gilmore 2018-03-16 23:51:06 UTC
but +1 blocker

Comment 10 Adam Williamson 2018-03-16 23:58:38 UTC
That's +4, setting accepted. And ON_QA as the repo is being created.

Comment 11 Kalev Lember 2018-03-19 12:31:48 UTC
Looks like the newly created empty repo metadata is missing signatures. I'm getting this from PK/gnome-software now:

"cannot update repo 'fedora-cisco-openh264': repomd.xml GPG signature verification error: Signature verify error - no signatures"

Comment 12 Dennis Gilmore 2018-03-19 16:02:16 UTC
that has to be a bug in packagekit or gnome-software 
https://codecs.fedoraproject.org/openh264/28/x86_64/repodata/repomd.xml.asc is the signed file that matches what is in f27 and all other releases

Comment 13 Adam Williamson 2018-03-19 16:40:24 UTC
sgallagh notes this also affects domain joining via realmd (which is blocking for Server):

<sgallagh> adamw, kparal: FYI, the cisco repo kerfuffle makes it so domain-joining doesn't work either.
<sgallagh> Because realmd tries to use DNF to pull the necessary packages for the join
<sgallagh> https://paste.fedoraproject.org/paste/3ZPsO4ah1Lgv3xsaj9epzg

Comment 14 Kalev Lember 2018-03-19 17:05:00 UTC
DNF fails with the same error:

# dnf --enablerepo=fedora-cisco-openh264 update -v
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repograph, repomanage, reposync
DNF version: 2.7.5
cachedir: /var/cache/dnf
Unknown configuration option: keepcache = 0 in /etc/yum.repos.d/rhpkg.repo
repo: using cache for: adobe-linux-x86_64
not found deltainfo for: Adobe Systems Incorporated
not found updateinfo for: Adobe Systems Incorporated
adobe-linux-x86_64: using metadata from Sat 24 Feb 2018 05:20:09 AM CET.
repo: using cache for: bluejeans
not found deltainfo for: Blue Jeans Network, Inc. - x86_64 software and updates
not found updateinfo for: Blue Jeans Network, Inc. - x86_64 software and updates
bluejeans: using metadata from Thu 29 Sep 2016 12:21:40 PM CEST.
Importing GPG key 0x9DB62FB1:
 Userid     : "Fedora 28 (28) <fedora-28>"
 Fingerprint: 128C F232 A937 1991 C8A6 5695 E08E 7E62 9DB6 2FB1
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-28-x86_64
Is this ok [y/N]: y
repo fedora-cisco-openh264: imported key 0xE08E7E629DB62FB1.
Cannot download 'https://codecs.fedoraproject.org/openh264/28/x86_64/': repomd.xml GPG signature verification error: Signature verify error - no signatures.
Error: Failed to synchronize cache for repo 'fedora-cisco-openh264'

Comment 15 Dennis Gilmore 2018-03-19 17:51:40 UTC
[root@anubis ~]# rm -rf /var/cache/dnf/*
[root@anubis ~]# dnf --disablerepo=* --enablerepo=fedora-cisco-openh264 update -v
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repograph, repomanage, reposync, system-upgrade
DNF version: 2.7.5
cachedir: /var/cache/dnf
Importing GPG key 0xF5282EE4:
 Userid     : "Fedora 27 (27) <fedora-27>"
 Fingerprint: 860E 19B0 AFA8 00A1 7518 81A6 F55E 7430 F528 2EE4
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-27-primary
¿Está de acuerdo [s/N]?:s
repo fedora-cisco-openh264: imported key 0xF55E7430F5282EE4.
Fedora 28 openh264 (From Cisco) - x86_64                                                                                                                                                                    7.6 kB/s | 2.8 kB     00:00    
not found deltainfo for: Fedora 28 openh264 (From Cisco) - x86_64
not found updateinfo for: Fedora 28 openh264 (From Cisco) - x86_64
fedora-cisco-openh264: usando metadatos de vie 24 mar 2017 13:17:23 CDT.
Última comprobación de caducidad de metadatos hecha hace 0:00:00, el lun 19 mar 2018 12:51:21 CDT.
Missing file *modules.yaml in metadata cache dir: /var/cache/dnf/fedora-cisco-openh264-94af0d6c80009071
Completion plugin: Generating completion cache...
--> Comenzando resolución de dependencias
--> Resolución de dependencias finalizada
Dependencias resueltas.
Nada por hacer.
¡Listo!

Comment 16 Dennis Gilmore 2018-03-19 17:56:50 UTC
I had hardcoded in 27 in the repo. working to see whats gone wrong.

Comment 17 Dennis Gilmore 2018-03-19 19:35:33 UTC
all fixed, I had used the wrong signing method.

Comment 18 Adam Williamson 2018-03-19 19:45:40 UTC
OK. Can affected folks confirm that dnf and PackageKit (e.g. GNOME Software) now work correctly? If so we can close this.

Comment 19 Adam Williamson 2018-03-19 21:18:11 UTC
*** Bug 1558064 has been marked as a duplicate of this bug. ***

Comment 20 Kalev Lember 2018-03-20 10:07:14 UTC
Looks fixed to me now, thanks Dennis!

Comment 21 Adam Williamson 2018-03-20 18:45:55 UTC
Closing, then. Re-open if we still have issues with this somehow.


Note You need to log in before you can comment on or make changes to this bug.