QEMU info
by Jilayne Lovejoy
Hi all,
As Richard and I go through the legal/licensing related wiki pages,
we've come across some info that is clearly not legal or licensing related.
The info on QEMU (pasted below) is one example. Seems like this would be
more appropriately suited for a page related to technical requirements
for packaging?
I'm not sure where that would be - could someone maybe take the info
below and make sure it gets to a proper location in packaging (or other)
docs??
Thanks!
Jilayne
"QEMU ROMs
Whenever possible, ROMS implementing BIOS or Firmware for QEMU system
targets must be built from source on the intended architecture. However,
in many situations, this is not practical or possible. As a special
exception for those situations where it is not practical or possible,
prebuilt binary ROMS implementing BIOS or Firmware for QEMU system
targets may be included in Fedora Packages, as long as the corresponding
source code is also included in the Source RPM package.?
1 year, 9 months
- 1
- 0
Schedule for Thursday's FPC Meeting (2022-07-14 16:00 UTC)
by James Antill
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2022-07-14 16:00 UTC in #fedora-meeting-1 on
irc.libera.chat.
Local time information (via. uitime):
================= Day: Thursday ==================
2022-07-14 09:00 PDT US/Pacific
2022-07-14 12:00 EDT --> US/Eastern <--
2022-07-14 16:00 UTC UTC
2022-07-14 17:00 BST Europe/London
2022-07-14 18:00 CEST Europe/Berlin
2022-07-14 18:00 CEST Europe/Paris
2022-07-14 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2022-07-15 00:00 HKT Asia/Hong_Kong
2022-07-15 00:00 +08 Asia/Singapore
2022-07-15 01:00 JST Asia/Tokyo
2022-07-15 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
= Followup Actions =
#topic #pr-814
* mhroncok
talk to authors again, having a working example might help a lot
= Followup Issues =
#topic #886 Enable BRP for detecting RPATH
.fpc 886
https://pagure.io/packaging-committee/issue/886
#topic #907 Which %__foo macros for executables are acceptable?
.fpc 907
https://pagure.io/packaging-committee/issue/907
#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058
#topic #1132 Mark comments as scriplets for Sources (automation)
.fpc 1132
https://pagure.io/packaging-committee/issue/1132
#topic #1150 request for clarification wrt. base version / compat package naming
.fpc 1150
https://pagure.io/packaging-committee/issue/1150
#topic #1159 Ban use of %configure in %prep
.fpc 1159
https://pagure.io/packaging-committee/issue/1159
= Followup Pull Requests =
#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814
#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045
#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071
#topic #pr-1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097
#topic #pr-1163 Sources: Add section about conditionalization
https://pagure.io/packaging-committee/pull-request/1163
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* 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.
1 year, 9 months
- 1
- 0
Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}
by Miro Hrončok
Hello Pythonistats, packagers,
A handful of Fedora Python packages uses pytest-xdist to run tests in parallel
like this:
%pytest -n auto
-n auto means pytest will spawn a number of workers processes equal to the
number of available CPUs.
In the spirit of other packaging guidelines, I believe we should use this instead:
%pytest -n %{_smp_build_ncpus}
This means the same thing in most of the ceases, but will limit the number of
workers depending on other constraints in the spec or in the environment.
Should I do this in a mass change? Not so many packages use pytest -n auto in
the spec:
$ rg -l -- '(-n|--numprocesses)(\s*|=)auto(\s|$)'
ansible-bender.spec
azure-cli.spec
ocrmypdf.spec
python-cartopy.spec
python-GridDataFormats.spec
python-hypothesis.spec
python-matplotlib.spec
python-mplcairo.spec
python-rpmautospec.spec
python-sqlalchemy.spec
python-tox.spec
python-xarray.spec
python-zstandard.spec
pythran.spec
scipy.spec
(Other packages have that in tox.ini or pytest config file, but I am not aiming
at changing that here.)
And, considering many other packages might want to benefit from that, should
this be:
1) encouraged in the Python packaging guidelines
2) macronized (I was thinking %pytest_parallel, but TBD)
?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 9 months
- 1
- 0