Co-maintainers for my ham packages
by Matt Domsch
Due to an impending move to NYC and related downsizing of my house into a
2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't
be able to test any of the Fedora packages I maintain with actual
hardware. Would anyone be interested in maintaining or co-maintaining
these?
- direwolf - Sound Card-based AX.25 TNC
- CubicSDR - Cross-Platform Software-Defined Radio Panadapter
- liquid-dsp - Digital Signal Processing Library for Software-Defined Radios
- sdrpp - SDRPlusPlus bloat-free SDR receiver software
- SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library
- soapy-rtlsdr - SoapySDR module for RTL-SDR hardware
Thanks,
Matt N5MLD
1 week, 4 days
F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec|
The spec file contains:
<pre>
Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog
</pre>
Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}
Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.
== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])
* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)
* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.
* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning
** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutori...
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Rpmautospec is already used by a decent number of packages, so any
issues are already being seen and need to be fixed anyway.
== How To Test ==
* Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers
restart at `-1`.
* Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm
-qp --changelog`).
* Do builds in koji. Verify correctness of version-release and the changelog.
* For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
* Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use
rpmautospec tooling correctly.
== User Experience ==
No changes visible to end users.
== Dependencies ==
None.
== Contingency Plan ==
If it turns out that the rpmautospec workflows have unknown problems,
we can revert changes to documentation.
* Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
This page and any changes to Packaging Guidelines and other documents.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 month, 1 week
Thoughts welcome: interface between automated test gating and the
"critical path"
by Adam Williamson
Hi folks!
I have one of those definitional quandaries and I figured I'd throw it
at the lists for some input.
Right now, we kind of take advantage of the "critical path" concept for
automated update testing and gating via openQA.
openQA does not test all updates, only critical path updates plus
updates containing any package on a short allowlist.
Bodhi and Greenwave do not gate all updates on the openQA tests since
not all updates are tested; again we use the critpath definition. If an
update is critical path, it gets gated on the openQA tests. If it
isn't, it doesn't.
If you've been paying attention, that means there's a bit of a hole:
the packages on the 'allowlist'. These are tested, but not gated.
What's on the allowlist? Basically, FreeIPA-related packages. We have a
good set of FreeIPA tests in openQA, and both I and the FreeIPA team
wanted relevant updates to be tested with them. But those packages are
not on the critical path. So I set up this 'allowlist' mechanism.
However, the lack of gating kinda sucks. I would much prefer if we
could gate these updates as well as just testing them.
The obvious thing to do is add the FreeIPA-related packages to the
critical path, but that really is not supported by the critical path
definition:
https://fedoraproject.org/wiki/Critical_path_package
which defines it as packages required to "perform the most fundamental
actions on a system", with a list of specific areas, none of which is
"run a domain server".
So...what to do?
I can think of I guess four options:
1. Broaden the definition of the "critical path" somehow. We could just
write in that it includes FreeIPA functionality, I guess, though that
seems special purpose. We could broaden it to include any functionality
covered by the release criteria, which would be quite a big increase
but seems like a reasonable and concise definition. Or we could write
in that it includes any functionality that is exercised by the gating
openQA tests, though that seems a bit arbitrary - there's no
particularly great organizing principle to the openQA tests we choose
to run on updates, if I'm honest, it's a sort of grab bag I came up
with.
2. Keep the current "critical path" concept but define a broader group
of "gated packages" somewhere (could be comps or somewhere else). This
would require engineering work - we'd have to touch probably the openQA
scheduler, Bodhi, and greenwave configs. It's also another maintenance
burden.
3. Add gating config to each allowlisted package repo's gating.yml one
by one. I don't really like this option. It'd be a chunk of work to do
initially, and multiples the maintenance required when the list of
tests to gate on changes for some reason.
4. Do nothing, just keep only gating things that are "critical path" on
the current definition. In a utopian future, we'd manage to deploy
openQA in the cloud or get a giant pile of super fast servers so we
could test and gate *every* update, and this wouldn't be an issue any
more.
What do folks think? Any preferences? Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
3 months, 2 weeks
Packaging a cross-compilation environment (wasi-libc)
by Jan Staněk
Hi list,
in order to be able to compile WASM natively on Fedora,
I'm trying to package wasi-libc[1] to provide the Web Assembly System
Interface.
[1]: https://github.com/WebAssembly/wasi-libc
My trouble is that this is in essence a cross-compilation environment,
and I have zero experience in trying to package these.
Also, I did not have much luck in trying to find any related
documentation.
Some issues I have run into so far:
- This is a libc implementation, which would probably conflict with the
glibc package by default. Looking at musl, the solution seems to be to
install into `/usr/{target}` prefix (i.e. `/usr/wasm32-wasi/include`).
Not really sure how this works, any pointers appreciated.
- Clang seems to have issue with `-fstack-clash-protection` flag for the
`wasm32-wasi` target. What's the proper way to adjust these?
Any additional tips on cross-compilation support in Fedora would also be
appreciated :)
Thanks in advance for any help!
--
Jan Staněk
Software Engineer, Red Hat
jstanek(a)redhat.com irc: jstanek
3 months, 3 weeks
libarrow (Apache Arrow) soname bump in Rawhide
by Kaleb Keithley
Hi,
Apache Arrow 10.0.0 has been released.
At present nobody is using libarrow except Ceph. (Which I am the maintainer
of.)
I will be rebasing libarrow to 10.0.0 within the next couple of days.
--
Kaleb
4 months, 1 week
F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email: <tagoh(a)redhat.com>
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
<pre>
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272</pre>
<pre>
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
</pre>
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your
language>` and `fc-match monospace:lang=<your language>`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for most languages will be Google Noto fonts instead
of DejaVu, to keep consistency on the text rendering and to provide
better quality among languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
5 months
Plan / proposal: enable openQA update testing and potentially
gating on Rawhide updates
by Adam Williamson
Hi folks!
We've had openQA testing of updates for stable and branched releases,
and gating based on those tests, enabled for a while now. I believe
this is going quite well, and I think we addressed the issues reported
when we first enabled gating - Bodhi's gating status updates work more
smoothly now, and openQA respects Bodhi's "re-run tests" button so
failed tests can be re-triggered.
A few weeks ago, I enabled testing of Rawhide updates in the openQA
lab/stg instance. This was to see how smoothly the tests run, how often
we run into unexpected failures or problems, and whether the hardware
resources we have are sufficient for the extra load.
So far this has been going more smoothly than I anticipated, if
anything. The workers seem to keep up with the test load, even though
one out of three worker systems for the stg instance is currently out
of commission (we're using it to investigate a bug). We do get
occasional failures which seem to be related to Rawhide kernel slowness
(e.g. operations timing out that usually don't otherwise time out), but
on the whole, the level of false failures is (I would say) acceptably
low, enough that my current regime of checking the test results daily
and restarting failed ones that don't seem to indicate a real bug
should be sufficient.
So, I'd like to propose that we enable Rawhide update testing on the
production openQA instance also. This would cause results to appear on
the Automated Tests tab in Bodhi, but they would be only informational
(and unless the update was gated by a CI test, or somehow otherwise
configured not to be pushed automatically, updates would continue to be
pushed 'stable' almost immediately on creation, regardless of the
openQA results).
More significantly, I'd also propose that we turn on gating on openQA
results for Rawhide updates. This would mean Rawhide updates would be
held from going 'stable' (and included in the next compose) until the
gating openQA tests had run and passed. We may want to do this a bit
after turning on the tests; perhaps Fedora 37 branch point would be a
natural time to do it.
Currently this would usually mean a wait from update submission to
'stable push' (which really means that the build goes into the
buildroot, and will go into the next Rawhide compose when it happens)
of somewhere between 45 minutes and a couple of hours. It would also
mean that if Rawhide updates for inter-dependent packages are not
correctly grouped, the dependent update(s) will fail testing and be
gated until the update they depend on has passed testing and been
pushed. The tests for the dependent update(s) would then need to be re-
run, either by someone hitting the button in Bodhi or an openQA admin
noticing and restarting them, before the dependent update(s) could be
pushed.
In the worst case, if updated packages A and B both need the other to
work correctly but the updates are submitted separately, both updates
may fail tests and be blocked. This could only be resolved by waiving
the failures, or replacing the separate updates with an update
containing both packages.
All of those considerations are already true for stable and branched
releases, but people are probably more used to grouping updates for
stable and branched than doing it for Rawhide, and the typical flow of
going from a build to an update provides more opportunity to create
grouped updates for branched/stable. For Rawhide the easiest way to do
it if you need to do it is to do the builds in a side tag and use
Bodhi's ability to create updates from a side tag.
As with branched/stable, only critical path updates would have the
tests run and be gated on the results. Non-critpath updates would be
unaffected. (There's a small allowlist of non-critpath packages for
which the tests are also run, but they are not currently gated on the
results).
I think doing this could really help us keep Rawhide solid and avoid
introducing major compose-breaking bugs, at minimal cost. But it's a
significant change and I wanted to see what folks think. In particular,
if you find the existing gating of updates for stable/branched releases
to cause problems in any way, I'd love to hear about it.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
5 months, 2 weeks
Future of BIOS RAID support in the installer
by Vojtech Trefny
Hi, I am planning to change how we support BIOS RAID (sometimes also
called Firmware or Fake RAID) in the installer in the future. I plan
to go through the official Fedora change process for Fedora 38, but
I'd like to get some feedback first.
We are currently using dmraid to support these types of RAIDs in
blivet[1] (storage library the Anaconda installer uses) and we would
like to replace it with mdadm. The main reason is that dmraid is no
longer actively maintained, but it will also mean one less dependency
for the installer (we use mdadm for the software RAID support) and one
less service running during boot (dmraid-activation.service).
The potential issue here is that mdadm doesn't support all BIOS RAID
types. mdadm supports only Common RAID Disk Data Format standard[2]
(DDF) and Intel Matrix Storage Technology (IMSM) so by switching to
mdadm we would remove support for some of the older formats that
existed before DDF was standardized. I am not sure how many people are
still using these older RAIDs and the main reason for sending this
email is to find out. So if you are using a BIOS RAID on your system,
can you check what kind? You can find out simply by checking the
filesystem type on the underlying disk(s) reported by for example
`lsblk -f`. Types supported by mdadm are "ddf_raid_member" and
"isw_raid_member". Types supported only by dmraid are
"adaptec_raid_member", "hpt***_raid_member", "jmicron_raid_member",
"lsi_mega_raid_member", "nvidia_raid_member",
"silicon_medley_raid_member" and "via_raid_member". So if you have one
of the latter ones and you'd be impacted by this change, please let me
know so we can reconsider this change. Note that this would affect
only the installation process, I know some external and NAS drives use
BIOS RAID and these won't be affected, dmraid is not being removed
from the repositories (at least I am not aware of this right now, some
distributions are already planning to remove dmraid completely).
[1] https://github.com/storaged-project/blivet
[2] https://www.snia.org/tech_activities/standards/curr_standards/ddf
Regards
Vojtech Trefny
vtrefny(a)redhat.com
5 months, 2 weeks