https://bugzilla.redhat.com/show_bug.cgi?id=1350884 --- Comment #54 from Brandon Nielsen <nielsenb@xxxxxxxxxxx> --- (In reply to Andy Mender from comment #53) > 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. > Interesting. It's more interesting that the built compiler just doesn't really work at all on armv7. > > 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 > Yup, already stumbled across that particular failure. I also really don't like the idea of an architecture specific patch in general, but it's a little more palatable for a test. > > 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. > Okay, looking into this more (also see comment 11, comment 12, comment 13, comment 14), the biggest issue I see is that it should be marked as bundled with gdb and binutils, not gcc. I don't think there's actually a bundled gnulib in gcc. That's probably why I was confused above. Assuming the ChangeLog is correct, I will version it with a date as done in system gdb[0]. > > 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. > As mentioned in comment 32, comment 34, I'm not using the variable, I'm replacing the literal string "$RPM_BUILD_ROOT" in the strip macro. > 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? I'm not entirely sure on that one. Looking into it now. > > > 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. I'm not sure I understand. In comment 23, comment 24, comment 25, and comment 35 it was decided to move everything to the /usr/msp430-elf prefix and symlink prefixed binaries as described in the packaging guidelines[1]. Why are we now moving things back to unprefixed system %{_libdir}? These unprefixed binaries should never come into contact with any non-msp430 compiler, and as far as I can tell getting rid of them breaks compatibility with how "upsteam" (TI, so, more midstream...) intends the compiler to work, which as far as I'm concerned would make this package a little pointless. [0] - https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb.spec#_105 [1] - https://fedoraproject.org/wiki/Packaging_Cross_Compiling_Toolchains#Cross-compiling_GCC_tool-chains -- 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
