https://bugzilla.redhat.com/show_bug.cgi?id=1859627 --- Comment #1 from Andy Mender <andymenderunix@xxxxxxxxx> --- > This is my first package so I need a sponsor. If I did anything wrong please point them out. If you need sponsorship, you need to explicitly indicate it by blocking the FE-NEEDSPONSOR bug report: https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR Also, check these docs: - https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group - https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join And regarding general packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/ As for the spec file: > %define target arm-none-eabi > %define gdb_datarootdir %{_datarootdir}/gdb-%{target}-%{version} I see the %{_datarootdir} macro works, but /usr/share is referred to as %{_datadir}. > Name: %{target}-gdb > Version: 9.2 > Release: 1%{?dist} > Summary: GDB for (remote) debugging ARM bare-metal targets > Group: Development/Debuggers > License: GPLv3+ > URL: http://sources.redhat.com/gdb/ - It's a bit safer to use spaces as a separator to avoid tabs being converted to different numbers of spaces. - "Group:" blocks are deprecated - The URL redirects me to: http://www.sourceware.org/gdb/. Should that be the case? > BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) > BuildRequires: texinfo > BuildRequires: ncurses-devel > BuildRequires: python-devel > BuildRequires: texinfo-tex > BuildRequires: expat-devel - Explicitly specifying a buildroot via the "BuildRoot:" block is not preferred anymore. - Dependencies on -devel packages should be specified as "pkgconfig(foo)" like so: BuildRequires: pkgconfig(ncurses) - Python should never be referred to without specifying the version and Python2 is End-of-Life already. > %package devel > Summary: GDB for (remote) debugging ARM targets > Group: Development/Debuggers > Requires: %{name} = %{version}-%{release} Here, it's better to use the more explicit form: Requires: %{name}%{?_isa} = %{version}-%{release} > # Set datarootdir to have target and version in so that we can exist > # side-by-side with other gdb installations of different versions > CFLAGS="$RPM_OPT_FLAGS" ../gdb-%{version}/configure --prefix=%{_prefix} \ > --libdir=%{_libdir} --mandir=%{_mandir} --infodir=%{_infodir} \ > --datarootdir=%{gdb_datarootdir} --disable-rpath \ > --target=%{target} --disable-nls --disable-werror --with-python --without-doc --with-xml --with-expat > make %{?_smp_mflags} You should use %make_build instead of the "make %{?_smp_mflags}" form. > %install > rm -rf $RPM_BUILD_ROOT > cd build > make install DESTDIR=$RPM_BUILD_ROOT - Cleaning the buildroot prior is no longer needed. - Use the %make_install macro instead. > %files > %defattr(-,root,root,-) > %doc gdb-%{version}/{COPYING?,COPYING?.LIB} The %defattr macro is no longer used. > %{_bindir}/%{target}-* > %{_mandir}/man1/%{target}-*.1.gz > %{_mandir}/man5/%{target}-*.5.gz > %dir %{_datarootdir}/gdb-%{target}-%{version} > %{_datarootdir}/gdb-%{target}-%{version}/* - Since you're packaging only GDB, if someone adds GCC for your target later, your wildcards might hijack its files. - Use "%{_datadir}/gdb-%{target}-%{version}/" to properly own the dir instead of the last 2 lines. Currently, your package fails to build in koji and in a mock environment locally. A successful build in a mock environment is needed to run the full review matrix. Please, have a look why the build is failing via mock :). -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
