RPM build error: empty %files file debugfiles.list

Question

Problem and environment

Korora 23 (Fedora 23)
rpmbuild --version RPM version 4.13.0-rc1

I am trying to make a local package of freefilesync for myself. The site offers an openSUSE version which I'm trying to package for Fedora.

My spec file.

The error

Processing files: freefilesync-8.2-1.fc23.x86_64
Provides: config(freefilesync) = 8.2-1.fc23 freefilesync = 8.2-1.fc23 freefilesync(x86-64) = 8.2-1.fc23
Requires(interp): /bin/sh /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires(post): /bin/sh
Requires(postun): /bin/sh
Requires: libX11.so.6()(64bit) libXxf86vm.so.1()(64bit) libatk-1.0.so.0()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.10)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.6)(64bit) libcairo.so.2()(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libexpat.so.1()(64bit) libfontconfig.so.1()(64bit) libfreetype.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgthread-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit) libpng16.so.16()(64bit) libpng16.so.16(PNG16_0)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.2)(64bit) libstdc++.so.6(CXXABI_1.3.3)(64bit) libstdc++.so.6(CXXABI_1.3.5)(64bit) libstdc++.so.6(CXXABI_1.3.9)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.11)(64bit) libstdc++.so.6(GLIBCXX_3.4.14)(64bit) libstdc++.so.6(GLIBCXX_3.4.15)(64bit) libstdc++.so.6(GLIBCXX_3.4.18)(64bit) libstdc++.so.6(GLIBCXX_3.4.19)(64bit) libstdc++.so.6(GLIBCXX_3.4.20)(64bit) libstdc++.so.6(GLIBCXX_3.4.21)(64bit) libstdc++.so.6(GLIBCXX_3.4.9)(64bit) libz.so.1()(64bit) libz.so.1(ZLIB_1.2.0)(64bit)
Processing files: freefilesync-debuginfo-8.2-1.fc23.x86_64
error: Empty %files file /home/bgstack15-local/rpmbuild/BUILD/freefilesync-8.2/debugfiles.list


RPM build errors:
    Empty %files file /home/bgstack15-local/rpmbuild/BUILD/freefilesync-8.2/debugfiles.list

What I've already tried

Per https://lists.opensuse.org/opensuse-buildservice/2015-11/msg00016.html I've already tried adding this line to my spec as you can see, but it didn't help:

%global debug_package %{nil}

For some reason this page is not providing me with useful info. Maybe I'm reading it wrong? https://fedoraproject.org/wiki/Packaging:Debuginfo

Extra info

I don't actually program. I just package binaries already provided by the firm and package things for myself for my home deployments of GNU/Linux.

Solution 1

In RPM, the order of sections and macros matters. Especially for the %define-s and %global-s ("global definitions").

Moving (or adding it if you don't already have it) the %global debug_package %{nil} above the %prep and %setup sections should do the job.

Solution 2

In case you do not want to tamper with the spec file, you can run the command as:

rpmbuild -ba -D 'debug_package %{nil}' package_name.spec

Solution 3

My problem was solved by moving the %global directive to just beneath the %description directive. I don't know why placement matters.

Comments

[Jakuje]

Your spec file have several issues. Changelog should be certainly the last section, your rpm is missing build section and so further. The debug was just a noise I guess. With this spec (and official source), I can move on to the build (which is failing). It will still need some care (dependencies, or build the bundled stuff too)

[bgStack15]

Wow, same time. Thanks for the information about spec files. I taught myself about spec files reading man pages. Somehow this has never come up before!

[k_rus]

@bgStack15 can you post your spec file into the issue? It is not available at the link any more.

[bgStack15]

Sorry, I wouldn't have that spec file in that format anymore. The biggest deal was that I had the sections out of order, per the accepted answer by Jakuje.