- Any particular reasons you're packaging version 0.34 instead of the latest, version 0.91?

 - The update-mime-database scriplets should not be used on Fedora > 23. See the note in https://fedoraproject.org/w/index.php?title=Packaging:Scriptlets&oldid=481889#mimeinfo

 - make %{?_smp_mflags} → %make_build

 - make install DESTDIR=%{buildroot} → %make_install

 - You must validate the .desktop file. See https://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage

desktop-file-validate %{buildroot}/%{_datadir}/applications/%{name}.desktop

 - Headers file should indeed go in a separate -devel subpackage. With %{_libdir}/lib%{name}.so too

 - The main lib in the main package *must* be versionned %{_libdir}/lib%{name}.so.0.n
See https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning :

>In cases where upstream ships unversioned .so library (so this is not needed 
>for plugins, drivers, etc.), the packager MUST try to convince upstream to >start 
>versioning it.
>
>If that fails due to unwilling or unresposive upstream, the packager may start 
>versioning downstream but this must be done with caution and ideally only in 
>rare cases. We don't want to create a library that could conflict with upstream 
>if they later start providing versioned shared libraries. Under no 
>circumstances should the unversioned library be shipped in Fedora.

 - Please make use of pkgconfig for the rest of your devel BR:

# for the local swig
BuildRequires:  autoconf
BuildRequires:  automake
BuildRequires:  pkgconfig(libpcre)

# for the renderdoc itself
BuildRequires:  cmake
BuildRequires:  desktop-file-utils
BuildRequires:  pkgconfig(vulkan)
BuildRequires:  bison
BuildRequires:  pkgconfig(python3)
BuildRequires:  pkgconfig(x11)
BuildRequires:  pkgconfig(xcb)
BuildRequires:  pkgconfig(xcb-keysyms)
BuildRequires:  pkgconfig(gl)
BuildRequires:  pkgconfig(Qt5)
BuildRequires:  pkgconfig(Qt5X11Extras)
BuildRequires:  pkgconfig(Qt5Svg)
BuildRequires:  pkgconfig(xcb-keysyms)
Requires: hicolor-icon-theme

 - BuildRequires: qt5-qtbase is not needed as it will be installed with qt5-qtbase-devel

 - The version is missing from yoir %changelog:

* Mon Jun 19 2017 Christian Kellner <ckellner> - 0.91-1

Follow-up:

 - the patches are not in the srpm?
 - Sorry, you did run desktop-file-validate
 - Source in the SRPM is indeed 0.91' did you give me the wrong SPEC file?

(In reply to Robert-André Mauchin from comment #2)
> Follow-up:
>  - Source in the SRPM is indeed 0.91' did you give me the wrong SPEC file?
Ups! Mea culpa. Forgot to do a "git push" on the repo.

Actually update-desktop-database shoudln't be run on Fedora > 23 either.

https://fedoraproject.org/w/index.php?title=Packaging:Scriptlets&oldid=481889#desktop-database

(In reply to Christian Kellner from comment #3)
> (In reply to Robert-André Mauchin from comment #2)
> > Follow-up:
> >  - Source in the SRPM is indeed 0.91' did you give me the wrong SPEC file?
> Ups! Mea culpa. Forgot to do a "git push" on the repo.

Ok, the review still stands though. Most pressing issui is to convince upstream to provide a versionned library.

Thanks for the review, much appreciated. I filed the versioning issue with upstream, will address the other comments shortly.

Fix external bug id, sorry for the noise.

So apparently librenderdoc.so is a bit of a special library. It is used as part as an internal library, part to use via LD_PRELOAD and maybe as kind of a plugin, i.e. dynamically load it at runtime via dlopen. In the latter case it only exports a single function that (as state by upstream) will never change. I guess it is somewhat of a hybrid between (special) plugin and an internal library. Is that good enough for an exception? Would installing it unversioned into a "private" subdir, e.g. lib/renderdoc/librenderdoc.so be preferred?

> Would installing it unversioned into a "private" subdir, e.g. lib/renderdoc/librenderdoc.so be preferred

I think so if it work the same. Thus there would be no need to run ldconfig.

I have updated the package and hopefully addressed all the issues. Upstream has done a patch for the private lib dir, but only in the master branch, hence I included the change as a patch.

Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=22092274
Spec file: https://github.com/gicmo/spec/blob/master/renderdoc/renderdoc.spec

Forgot to remove ldconfig calls. New build: https://koji.fedoraproject.org/koji/taskinfo?taskID=22092371

Rpmlint is still not happy:

renderdoc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/qrenderdoc ['$ORIGIN', '$ORIGIN/../lib64/renderdoc/']
renderdoc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/renderdoccmd ['$ORIGIN/', '$ORIGIN/../lib64/renderdoc/']

See this to remove Rpath: https://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath

(In reply to Robert-André Mauchin from comment #12)
> Rpmlint is still not happy:
> 
> renderdoc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/qrenderdoc
> ['$ORIGIN', '$ORIGIN/../lib64/renderdoc/']
> renderdoc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/renderdoccmd
> ['$ORIGIN/', '$ORIGIN/../lib64/renderdoc/']

I thought that this should be ok now, because it is to reference the now internal renderdoc library. From See this to remove Rpath:
https://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath

> These libraries are not intended for use outside of the package. When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries. 

Am I reading this correctly?

Yes, you are right.

Package is accepted.

Thanks a lot for the review, highly appreciated!

(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/renderdoc

renderdoc-0.91-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-30340d14db

renderdoc-0.91-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a54f0d5c6f

renderdoc-0.91-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-30340d14db

renderdoc-0.91-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a54f0d5c6f

renderdoc-0.91-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

renderdoc-0.91-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.