--define 'check exit 0' breaks generation of debugfiles.list
by Basin Ilya
Hi
It's commonly advised that if .spec file doesn't support `--without
check`, then to skip the check phase run rpmbuild with `--define 'check
exit 0'`. But if I do so, some packages fail with:
debugfiles.list: No such file or directory
That's because `find-debuginfo.sh` not run after %install phase.
Is it possible to skip the check without breaking generation of
debugfiles.list and without editing the .spec file?
7 years, 1 month
Packaging FPGA bitstreams
by Richard W.M. Jones
RISC-V is an open source instruction set architecture (ISA).
I was broadly looking at what it would take to support RISC-V in
Fedora, and as well as the usual things like kernel, GCC, binutils,
maybe cross-compilers, and all the stuff that's the same for any new
architecture, there is one problem which is specific to RISC-V.
Because no hardware implementation of RISC-V exists that you can
buy[1], currently you have to use an FPGA development kit and use one
of the FPGA implementations -- I'm using lowRISC[2]. There are
affordable FPGA kits for around US$150-$320 based on the Xilinx
Artix-7 FPGA which are supported by lowRISC.
The source for the RISC-V CPU core (called "Rocket") is written in
Verilog and is free software (3-clause no advertising BSD).
In FPGA-land, a "bitstream" is kind of like a binary or a firmware
blob.
Unfortunately to compile the source code to a bitstream, things get
very proprietary. For Xilinx, you have to install their proprietary
compiler, Vivado. It's not just proprietary but it has node-locked
licensing so it's user-hostile too.
There is a second sub-problem, but one which is going to be overcome
soon. At the moment there is only a free CPU core. However to talk
to the outside world even on an FPGA, it needs peripherals like a UART
(serial port), SD card reader and some other SPI peripherals. These
are provided by Xilinx and are (of course) proprietary IP. However
lowRISC plan to replace these with free software peripherals later
this year[3].
Once you've compiled your bitstream, you then need to write it to the
FPGA. Writing a bitstream to the FPGA turns the FPGA into a RISC-V
processor and you can boot Linux on it from an SD card.
You can use the proprietary Vivado tool to write the bitstream to the
FPGA, but there are also open source tools to do this. I used
xc3sprog[4] (GPLv2).
This all really works - I've been documenting building everything from
source on my blog[5].
In summary:
- Compiling the Verilog source code to a bitstream requires highly
proprietary tools and will never be possible in Fedora.
- Writing the bitstream to the FPGA is possible with GPL tools.
- There are currently some proprietary bits in the bitstream, but I
hope those will be removed at some point.
Obviously the last point makes this moot right now, but assuming that
can be fixed, here is my question: Can we package these bitstream
files in Fedora? It would allow a more immediate out-of-the-box
experience where you just plug in the development kit and go.
Rich.
[1] Hardware impls do exist, but they are all research projects so
far, or otherwise not for sale.
[2] http://www.lowrisc.org/
[3] https://speakerdeck.com/asb/lowrisc-plans-for-risc-v-in-2016
[4] https://sourceforge.net/p/xc3sprog/
[5] https://rwmj.wordpress.com/?s=RISC-V+on+an+FPGA
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
7 years, 1 month
sse3 optimized and unoptimized library
by Matthew Chan
Hi,
I'm currently packaging a libraries that are nearly identical, except one version is sse3 optimized, and the other is not. (license also changes to GPL from BSD). The performance difference is significant.
What is the correct way to handle this? They both provide the same libraries and headers. Should I use an ExclusiveArch: x86_64 on the sse3 version, and an ExcludeArch: x86_64 on the unoptimized version? Or perhaps even use a conflicts? (Assuming there are x86_64 processors that don't support SSE3? SSE3 seems to have been introduced with Pentium 4 Prescott)
Thanks in advance for your replies,
Matt
7 years, 2 months
Summary/Minutes from today's FPC Meeting (2016-07-14 16:00 - 17:05 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:13 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-07-14/fpc.2016-
07-14-16.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:14)
* Schedule (geppetto, 16:06:21)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/ZBVHJMPOT55DZ2H6O4XD5B5EHYPR5IK5/
(geppetto, 16:06:24)
* #610 Packaging guidelines: Check upstream tarball signatures
(geppetto, 16:06:58)
* #637 approval for a 'docker-latest' package on fedora (geppetto,
16:15:01)
* LINK:
https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_w
ith_the_same_base_name
(orionp, 16:38:33)
* No objections to using other namging than versioned, everyone but
me
seems ok with using docker-latest as the package name too if you
want. (geppetto, 16:47:38)
* Open Floor (geppetto, 16:48:21)
Meeting ended at 17:05:10 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* geppetto (65)
* tibbs (54)
* Rathann (18)
* orionp (17)
* zodbot (11)
* limburgher (9)
* number80 (5)
* misc (1)
* tomspur (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
7 years, 2 months
Schedule for Thursday's FPC Meeting (2016-07-14 16:00 UTC)
by James Antill
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-07-14 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2016-07-14 09:00 Thu US/Pacific PDT
2016-07-14 12:00 Thu US/Eastern EDT
2016-07-14 16:00 Thu UTC <-
2016-07-14 17:00 Thu Europe/London BST
2016-07-14 18:00 Thu Europe/Paris CEST
2016-07-14 18:00 Thu Europe/Berlin CEST
2016-07-14 21:30 Thu Asia/Calcutta IST
------------------new day----------------------
2016-07-15 00:00 Fri Asia/Singapore SGT
2016-07-15 00:00 Fri Asia/Hong_Kong HKT
2016-07-15 01:00 Fri Asia/Tokyo JST
2016-07-15 02:00 Fri Australia/Brisbane AEST
Links to all tickets below can be found at:
https://fedorahosted.org/fpc/report/13
= Followups =
#topic #558 Application/Library distinction and package
splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558
#566 RPM file triggers
#topic #NNN Title of ticket
.fpc 566
https://fedorahosted.org/fpc/ticket/566
#topic #610 Packaging guidelines: Check upstream tarball
signatures
.fpc 610
https://fedorahosted.org/fpc/ticket/610
#topic #637 approval for a 'docker-latest' package on fedora
.fpc 637
https://fedorahosted.org/fpc/ticket/637
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/13
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
7 years, 2 months
How best to handle tools which support multiple Python runtimes
by Avram Lubkin
I'm a co-maintainer for the python-sphinx package. There's a bug [1] I'd
like to address, but I'd like some input on what I was thinking. There was
some discussion about this on FPC ticket [2], but nothing workable really
came out of that. I also attempted to get input [3] from the Sphinx
community, but didn't receive a response.
For background, python-sphinx is available for both Python2 and Python3. It
is primarily a library, but provides four commands for convenience:
sphinx-build, sphinx-quickstart, sphinx-apidoc, sphinx-autogen. Here's an
example of how these commands are currently made available to the user:
/usr/bin/sphinx-build -> sphinx-build-2
/usr/bin/sphinx-build-2 -> sphinx-build-2.7
/usr/bin/sphinx-build-2.7 (#!/usr/bin/python2)
/usr/bin/sphinx-build-3 -> sphinx-build-3.4
/usr/bin/sphinx-build-3.4 (#!/usr/bin/python3)
It should be noted, all of these commands are just used to call entry
points and don't have any of their own logic. Here are their equivalents:
sphinx-build python -m sphinx
sphinx-quickstart python -m sphinx.quickstart
sphinx-apidoc python -m sphinx.apidoc
sphinx-autogen python -m sphinx.ext.autosummary.generate
Sphinx itself isn't Python version specific and maintains compatibility
regardless of what Python version you are using or if you switch back and
forth. Potentially there are some Sphinx extensions that are Python version
dependent, but I am not aware of any.
Use cases for Sphinx are all over the place. For example, I rarely use the
commands and call sphinx through setuptools 99% of the time. Other people
use the commands exclusively, and still others use the makefile created by
sphinx-quickstart as their primary way to call it.
It's this last one is where we are seeing the biggest problem and is
described in the bug. Essentially, sphinx-quickstart-3 is used to create a
makefile which lists sphinx-build as the build command. But sphinx-build is
currently linked to the python2 version, which may not be expected, and
won't necessarily be installed.
It was suggested the makefile should be changed so the Python version that
was used for sphinx-quickstart should be used for sphinx-build.
Unfortunately, that would make the file less portable.
I have two possible fixes:
The first would be to decouple the commands from the libraries. Since the
package name sphinx is already taken by the search engine, something like
python-sphinx-bin may be appropriate. Once separated, the command would
default to python3 since the packaging guidelines say it Python 3 versions
should be preferred when equivalent.
The second option would be to retain the multiple versions, but to manage
the links with alternatives so the unversioned commands will default to
whatever version is installed and again, Python 3 would be preferred if
both were installed.
Does anyone have any preferences, thoughts or alternative approaches?
Avram
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1321413
[2] https://fedorahosted.org/fpc/ticket/612
[3] https://groups.google.com/forum/#!topic/sphinx-dev/vdFeOEj4EKg
7 years, 2 months
