https://bugzilla.redhat.com/show_bug.cgi?id=1350884 --- Comment #53 from Andy Mender <andymenderunix@xxxxxxxxx> --- Extra Koji build from the latest SRPM: https://koji.fedoraproject.org/koji/taskinfo?taskID=55638767 Fails on s390x, but I don't think it's the SRPMs fault. > It now carries a patch file, 2 actually, to work around issues with the GDB tests. There are actually lots of failures with the GDB tests, so I limited the suite to gdb.base to make it more workable. There were additional issues with GDB ix86 tests, so that carries an additional patch. I think patching conditionally based on architecture is okay? rpmlint has mixed feelings about this, but I think it's okay: > msp430-elf-toolchain.src: W: %ifarch-applied-patch Patch1: msp430-elf-toolchain_i386_testfix.patch I found this, though: https://listman.redhat.com/archives/fedora-devel-list/2007-September/msg01515.html > Provides: bundled(gnulib) Didn't notice this before, but rpmlint complains that this should be versioned: > msp430-elf-toolchain.src:61: W: unversioned-explicit-provides bundled(gnulib) Which does make sense, because without versioning it's impossible to tell which gnulib it is. Unless, it's not possible to ascertain, because the source is a tarball and not much more. > case $a in > # Prevent brp-strip* from trying to handle foreign binaries > */brp-strip*) > b=$(basename $a) > sed -e 's,find "*$RPM_BUILD_ROOT"*,find "$RPM_BUILD_ROOT" -not -path "%{buildroot}%{_prefix}/%{target}/lib/gcc/%{target}/%{gcc_version_base}/*" -not -path "%{buildroot}%{_prefix}/%{target}/%{target}/lib/*",' $a > $b > chmod a+x $b > ;; > esac > done Is it possible to use %{buildroot} instead of $RPM_BUILD_ROOT in the sed call? Both should expand to the same path. rpmlint also complains about quite a lot of header files in the main subpackages: > msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libgcc.a > msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libgcov.a > msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_16.a > msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_32.a > msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_f5.a > msp430-elf-gcc.x86_64: W: devel-file-in-non-devel-package /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/430/exceptions/libmul_none.a > [...] I'm guessing these are needed by the main packages and the lines can be ignored? Not sure about these, though: > msp430-elf-gcc.x86_64: W: dangling-relative-symlink /usr/lib/.build-id/3d/b4b5215ce578d5b13456988092f30187ac4beb ../../../../usr/msp430-elf/libexec/gcc/msp430-elf/9.2.0/cc1plus This symlink doesn't look valid. Is it an artifact from the build? > msp430-elf-binutils.x86_64: W: non-standard-dir-in-usr msp430-elf > Additionally, unprefixed symlinks to the executables are now made in /usr/msp430-elf/msp430-elf/bin as their presence is expected by the generated msp430-elf-gcc. I don't fully understand why. This eliminates the need for the -B/usr/bin/msp430-elf- compile option, maintaining better compatibility with Makefiles. Again, I'm sure there's a better way but I don't know it. Yeah, rpmlint complains about that, too. This is a bit of a deal breaker. Things should go into %{_libdir} typically. -- 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
