`BuildRequires: /usr/lib/libc.a` fails on epel8 x86_64
by Christoph Erhardt
Hi list,
I'm trying to build mold for epel8. A bunch of mold's unit tests produce
statically linked 32-bit binaries, so on x86_64 we need a build dependency on
a static multilib glibc.
I have learnt that multilib build dependencies are a tricky thing in Koji, and
the only solution I have found to work is to specify a filename-based
dependency:
`BuildDepends: /usr/lib/libc.a`
This works fine for rawhide, f35, f34 and epel9 but fails on epel8:
```
No matching package to install: '/usr/lib/libc.a'
```
Full build log:
https://kojipkgs.fedoraproject.org/work/tasks/2503/81962503/mock_output.log
Any ideas?
Best,
Christoph
2 years, 1 month
sphinx: Intention to orphan package
by Sergio Arroutbi
Hello.
I recently assumed the sphinx package maintenance for Fedora.
When I observed the package structure, I realized it is based on source
code developed in C, with latest stable version available in next link:
http://sphinxsearch.com/downloads/current/
Latest binary versions from previous link (for example, v3.4.1) link to
python base source code.
Once I have inspected the package structure and the upstream project, I
realized Sphinx was migrated to python, and newer versions can be
downloaded via the "pip" tool. Apart from that, there is already a
"python-sphinx" package to handle sphinx tools.
So I guess the correct way to go here is to orphan the C based package
(sphinx), unless there is some detail I am missing to keep it maintained.
Thanks
--
Sergio Arroutbi Braojos
Software Engineer at Red Hat - Special Projects (SECENGSP)
Red Hat <http://redhat.com>
2 years, 1 month
New tool - license-validate
by Miroslav Suchý
Hi.
I have created new tool license-validate
https://pagure.io/copr/license-validate/
And I packaged it for Fedora. Here is the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=2035680
The goal of this tool is to validate the string in the License tag in the spec file. I.e.
LIcense: GPLv2
---------------^^^^ this part only
It doe **not** check if it actually agree with the actual code or even %license file. We have `licensecheck` for that.
The Fedora's package already contains list of license from Licensing:Main and you can run it as
$ license-validate-v'GPLv1 or (MIT and BSD)'
Approved license
or
$ license-validate-v'GPL or (MIT and BSD)'
No terminal defined for 'G' at line 1 col 1
GPL or (MIT and BSD)
...
Not a valid license string
which fails because GPL is not valid short name.
My next goal will be to download all Fedora's spec files, extract the license line and run it through this script. But I
am going to be few days offline, so anyone who want step in QE shoes can do that - I will not be mad :)
Comments are welcomed.
Miroslav
2 years, 1 month
Questions about new free-only FFMPEG in Fedora repos
by Ian McInerney
I noticed in the electron thread that we now have FFMPEG 5.0 in the
official Fedora repos, but this will of course mean that certain codecs are
removed due to legal concerns. This prompts a few questions though:
1) How are these removed codecs handled in the library? Can we link an
upstream application against FFMPEG in Fedora now and have it gracefully
fail when it tries to access a non-free codec that was removed, or does the
removal of these codecs create a different API that upstream applications
would have to code around? e.g. does it mean they have to add conditional
compilation for the specific codecs they need to use from FFMPEG instead of
just around FFMPEG itself?
2) Is there an easily accessible list of the enabled codecs we can point
upstreams to when talking about this?
Thanks,
-Ian
2 years, 1 month