[Bug 1885421] New: Review Request: marcsabatella-campania-fonts -
Font for Roman numeral analysis (music theory)
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1885421
Bug ID: 1885421
Summary: Review Request: marcsabatella-campania-fonts - Font
for Roman numeral analysis (music theory)
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: loganjerry(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Spec URL:
https://jjames.fedorapeople.org/marcsabatella-campania-fonts/marcsabatell...
SRPM URL:
https://jjames.fedorapeople.org/marcsabatella-campania-fonts/marcsabatell...
Fedora Account System Username: jjames
Description: This font is inspired by the work of Florian Kretlow and the
impressive Figurato font he developed for figured bass, as well as the work of
Ronald Caltabiano and his pioneering Sicilian Numerals font. This version of
Campania is not directly based on either of these, however. Instead, it uses
the glyphs from Doulos and adds some relatively straightforward contextual
substitutions and positioning rules to allow you to enter the most common
symbols just by typing naturally.
If anybody knows a way around adding the symlink in %check, please let me know.
Without the symlink, xmllint complains that it cannot find fonts.dtd, which
looks like bug 624201.
--
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
3 years, 5 months
[Bug 1350884] Review Request: mspgcc - Rebase of GCC for the MSP430
to TI / Red Hat upstream
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1350884
--- Comment #55 from Andy Mender <andymenderunix(a)gmail.com> ---
> 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].
I checked the regular gcc package and yes, it's not there:
https://src.fedoraproject.org/rpms/gcc/blob/master/f/gcc.spec
It's bundled with gdb, however:
https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb.spec#_105
> 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.
Yes, you're right. Apologies for my previous comment. I confused myself. The
way it is right now makes more sense, of course. Let's keep that part as it is
now.
--
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
3 years, 5 months
[Bug 1350884] Review Request: mspgcc - Rebase of GCC for the MSP430
to TI / Red Hat upstream
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1350884
--- Comment #54 from Brandon Nielsen <nielsenb(a)jetfuse.net> ---
(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...
--
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
3 years, 5 months
[Bug 547655] Review Request: perl-Module-Install-RTx - RT extension
installer
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=547655
Jitka Plesnikova <jplesnik(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jplesnik(a)redhat.com
Flags| |needinfo?(xavier(a)bachelot.o
| |rg)
--- Comment #13 from Jitka Plesnikova <jplesnik(a)redhat.com> ---
Do you want to finish the review?
If yes, please use the latest version of the module and update the spec due to
new guidelines.
--
You are receiving this mail because:
You are always notified about changes to this product and component
3 years, 5 months