https://fedoraproject.org/wiki/Changes/SofDefaultForIntelLpe
== Summary ==
Intel LPE audio hardware has 2 drivers in the mainline kernel the SST
driver and the SOF driver, switch the default driver from SST to SOF.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
Intel x86 hardware based on the Bay Trail-T and Cherry Trails SoCs
does not come with the standard Intel HDA audio hardware. Instead it
has an audio block called the Low Power Engine or LPE. The LPE block
needs to have firmware loaded into it to function. There are 2
firmwares available the old proprietary SST firmware and recently the
open source SOF firmware has been released for the LPE engine.
There are also 2 kernel drivers for the LPE block, one for each
firmware, so we have a SST driver and a SOF driver. The upstream Intel
developers of these drivers, who are also part of the SOF team want to
deprecate and eventually remove the old SST driver in favor of the SOF
driver. Starting with the 5.11 kernel it is possible to build both
drivers into a single kernel and select which one will actually bind
to the LPE block using a kernel commandline parameter.
ATM the upstream default is the old SST driver, to avoid regressions.
This Fedora change will entail carrying a downstream patch which flips
the default to the SOF driver. This is being done in conclave with the
upstream devs who would like to see more testing of the SOF driver.
The upstream devs believe that the SOF driver is ready to replace the
SST driver, but they would appreciate this being tested by Fedora
first, before they flip the default for everyone.
== Benefit to Fedora ==
By consciously making the switch now, with extensive testing and
monitoring the situation we can safely make the switch without
regressions hitting users of the Fedora stable releases. Whereas if we
just wait for upstream to flip the default, then this may very well
land in the middle of a stable release when we rebase the kernel.
This helps strengthen our relationship with the upstream developers
and falls under the "First" part of the "Four Foundations".
This stops us from depending in the proprietary SST firmware-blobs,
replacing them with the Open Source SOF firmware, matching the
"Freedom" part of the "Four Foundations".
== Scope ==
* Proposal owners: This will require a small downstream kernel patch
to change the default driver when both are built (or an upstream patch
to make the default configurable). That's it, no other changes are
required.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This falls under the "First" part of the
"Four Foundations".
== Upgrade/compatibility impact ==
The switch will automatically be made when booting a Fedora 34 kernel.
== How To Test ==
I (Hans de Goede) have an extensive collection of affected hardware.
The audio setup on these devices consists of the LPE block itself
combined with an external audio-codec. There are a number of
audio-codecs used / supported on these boards. The LPE block has 2
audio-links (called SSP0 and SSP2) and some of the codecs have 2
audio-links (called AIF1 and AIF2) not each board uses the same
audio-link on each side.
I plan to run the below test-plan on devices with the following SoC /
codec / link combinations:
* Bay Trail (CR) / RT5640 / SSP0<->AIF1
* Bay Trail (CR) / RT5640 / SSP0<->AIF2
* Bay Trail / RT5640 / SSP2<->AIF1
* Cherry Trail / RT5640 / SSP2<->AIF1
* Cherry Trail / RT5645 / SSP2
* Bay Trail (CR) / RT5651 / SSP0<->AIF1
* Cherry Trail / RT5651 / SSP2<->AIF1
* Bay Trail / RT5672 / SSP2
* Bay Trail (CR) / ESS8316 / SSP0
* Cherry Trail / ESS8316 / SSP2
* Cherry Trail / NAU8824 / SSP2
Each of these will be tested according to the following test-plan:
# Test speakers.
# Test internal mic.
# Plugin headset, test headphones.
# Test headset-mic
# Stop all audio, suspend + resume, test speakers.
# suspend + resume while playing audio, audio should resume playing
after resume.
Users who want to test this and who have the affected hardware can
also use this test-plan to test.
== User Experience ==
The SST driver has some suspend/resume problems around suspending with
audio playing. The SOF driver resolves these. Other then that the
user-experience should be unchanged.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
We can simply drop the patch flipping the default to get back to the
F33 state of things.
* Contingency mechanism: Revert the change
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
FIXME: TODO
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).
== Owner ==
* Name: [[User:clime| Michal Novotný]]
* Email: clime(a)fedoraproject.org
== Detailed Description ==
There is a recently added feature into mock:
[https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocess…
the rpkg preprocessor] which, if enabled, introduces an intermediate
step just before srpm building. This step consists of running the spec
file through a text preprocessing engine that includes an already
present library of macros designed specifically for rpm spec file
generation from git metadata. This library is called
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros]. The macros there allow packagers to have their
`%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
automatically generated from dist-git repository data and metadata.
The library can be easily extended in future to support more packager
use-cases or even a completely new library can be developed that
doesn't look at git metadata at all and instead, for example, analyses
already present tarball content to render spec file based on upstream
information. This doesn't mean it will happen but the framework is
generic enough to support that. There is also support for user-defined
macros that are loaded on-demand from a file placed alongside the
package sources, maintained by packager. This feature wouldn't be
enabled by this change from start but it's an example of freedom that
the preprocessing framework is able to provide. Enabling this change
should be very easy, basically adding:
<pre>
config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
</pre>
into mock configuration of Koji builders and using at least mock 2.7.
Some very minor change may be also needed in Koji regarding the spec
file lookup.
Even if the change is enabled on the infrastructure level like this,
the packager will still need to opt-in to use the preprocessor. The
opting-in is done by placing `rpkg.conf` file into the package
top-level directory with the following content:
<pre>
[rpkg]
preprocess_spec = True
</pre>
When this is done by a packager, the preprocessor will be finally
enabled for the given package.
Alongside, there is an ongoing work to add the preprocessor support
into the `rpkg` python library so that a packager can easily work with
the spec files containing the preprocessor (rpkg) macros:
https://pagure.io/rpkg/pull-request/530
The macros are supported since epel6 until the most latest Fedora
(preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
spec preprocessing step in mock happens in a target chroot just before
the srpm build.
== Benefit to Fedora ==
This change offers solution to some long-standing issues in Fedora
around packaging (i.e. automatic release and changelog generation)
while also offering some interesting future options (for example
unpacked dist-git repos). The big advantage of this approach is that
it is explicit. Spec file stays the source of truth and by looking
inside one, you will be able to determine how the text will expand for
a certain git repository state.
== Scope ==
* Proposal owners:
For the very basic support, probably a small patch in Koji is needed
to be able to lookup not only `.spec` files but also `.spec.rpkg`
files (the `.spec.rpkg` extension explicitly states that the spec file
is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
be tweaked to be compatible with spec files using the macros.
* Other developers:
Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be welcome.
* Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a
check of an impact with Release Engineering is needed)
Enabling the rpkg_preprocessor plugin in mock config for Koji builders.
* Policies and guidelines:
The new macro support should be mentioned or even described in the
packaging guidelines. We should decide if the full power of the
rpkg-macros library should be allowed from start (i.e. even unpacked
repos).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Because of the opt-in nature on packager side, there should be no
compatibility issues.
== How To Test ==
Once the feature is enabled, one can test it by providing the
`rpkg.conf` file with the required content in a package repository and
use some rpkg macro in the spec file: e.g.
<pre>
Name: {{{ git_dir_name }}}
</pre>
to generate the name of the package from the repository name (this
should actually produce the original text as package names should be
the same as the repository basenames).
To try it out first without committing to dist-git, one can use `rpkg`
command-line tool from
https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ or even
fedpkg's koji scratch build after
[https://pagure.io/rpkg/pull-request/530 the work in the pyrpkg]
library is finished.
One can also currently use Copr's SCM "rpkg" build method where the
macros are enabled but the rpkg-macros there are in version 2 whereas
this change is about introducing the
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html version 3
rpkg-macros]. However, while there are some differences between v2 and
v3, the idea and most of the working is the same.
== User Experience ==
This change is intended for packagers. It should help to make a bit of
their work easier and offer them some new interesting options.
== Dependencies ==
N/A
== Contingency Plan ==
Packagers can opt-out on individual basis by removing the `rpkg.conf`
file or just setting the `preproces_spec` property to `False`. On
infrastructure level, the rpkg_preprocessor plugin could be disabled
again.
== Documentation ==
- [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocess…
Mock's rpkg_preprocessor plugin]
- [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros reference (the library of macros ready to be used in spec
files)]
== Release Notes ==
Currently N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
What's wrong with s390x koji builder?
I always see this error:
Child return code was: -11
EXCEPTION: [Error()]
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py",
line 93, in trace
result = func(*args, **kw)
File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600,
in do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command,
output), child.returncode)
mockbuild.exception.Error: Command failed:
Other arches are OK.
https://koji.fedoraproject.org/koji/taskinfo?taskID=60085705
Need to fix it.
--
Best regards,
Vasiliy Glazov
Hi guys,
I am confused about the official guidelines for merging of packages in Fedora.
From my POV, when I merge some packages and the functionality is preserved,
the Obsoletes and Provides should be set and kept for 2 release cycles.
So there is not problem with dependencies, etc. However, I've just realized
that regarding guidelines only Obsoletes should be set.
Was it changed and is it really correct? From that point, I already have
a reported broken deps for git-remote-hg because of the missing provides
after the merge of some packages - I will fix it, but I am curious whether
this is really expected. Can you guys put a light on that? Or the guideline
needs to be fixed?
Thank you!
[0] https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splittin…
--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Senior Software Engineer
Red Hat Czech s.r.o.
Hello all,
My name is Serhei Makarov. I've contributed to the SystemTap project for several years
and I have an interest in various kinds of debugging and developer tools.
Recently one of my side-projects (https://github.com/serhei/oc-inject) matured somewhat,
enough to start shipping it as a standalone tool. So I'm hoping to get into Fedora packaging
and I'm sending this self-introduction in connection with that (as suggested by the Fedora Wiki).
All the best,
Serhei
http://serhei.io / https://github.com/serhei / FAS account name 'serhei'
Hi all,
In 2020 I made an update of https://fedrtc.org and the updated
reSIProcate packages are mostly complete, so people can run it or adapt
it as they please.
I can see that 68 people have created accounts there and tried it.
Would anybody have time to test it and give me feedback if it works for
you or not?
It asks you to authenticate with FAS and then you need to create a
different password (not FAS password) just for SIP. The passwords are
hashed but please imagine they are not, don't use the same password you
use for FAS or anything else, I'm genuinely not interested in harvesting
your passwords.
Other people can also call you anonymously from https://freephonebox.net
- they need to use the address user(a)fedrtc.org not user(a)fedoraproject.org
You can give people URLs like this, replacing USER with your login:
https://freephonebox.net/?dial=USER%40fedrtc.org&video=true
Regards,
Daniel
The BuildRequires for dnet is gone now - https://src.fedoraproject.org/rpms/open-vm-tools/c/36c7fb8dfde3767b21438564….
Thanks,
Ravindra
________________________________
From: Oliver Falk <oliver(a)linux-kernel.at>
Sent: Tuesday, January 19, 2021 3:30 AM
To: Ravindra Kumar <ravindrakumar(a)vmware.com>
Cc: Richard W.M. Jones <rjones(a)redhat.com>; cavery(a)redhat.com <cavery(a)redhat.com>; libdnet-owner(a)fedoraproject.org <libdnet-owner(a)fedoraproject.org>; devel(a)lists.fedoraproject.org <devel(a)lists.fedoraproject.org>; open-vm-tools-owner(a)fedoraproject.org <open-vm-tools-owner(a)fedoraproject.org>
Subject: Re: libdnet in Fedora
Hey!
Right, now that you mention it, I remember I've read this already somewhere, but thanks for pointing that out!
Oliver
On Sat, Jan 16, 2021 at 1:16 AM Ravindra Kumar <ravindrakumar(a)vmware.com<mailto:ravindrakumar@vmware.com>> wrote:
Thanks Rich and Oliver.
FWIW, open-vm-tools 11.0.0 onwards have removed libdnet dependency - https://kojipkgs.fedoraproject.org//packages/open-vm-tools/11.0.0/2.fc32/da…<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkojipkgs.…>. My bad I forgot to remove libdnet from open-vm-tools.spec when I updated to 11.0.0. If no one else gets to it before me, I will remove it when I package the new open-vm-tools version 11.2.5.
Thanks,
Ravindra
________________________________
From: Oliver Falk <oliver(a)linux-kernel.at<mailto:oliver@linux-kernel.at>>
Sent: Thursday, January 14, 2021 5:53 AM
To: Richard W.M. Jones <rjones(a)redhat.com<mailto:rjones@redhat.com>>
Cc: cavery(a)redhat.com<mailto:cavery@redhat.com> <cavery(a)redhat.com<mailto:cavery@redhat.com>>; Ravindra Kumar <ravindrakumar(a)vmware.com<mailto:ravindrakumar@vmware.com>>; libdnet-owner(a)fedoraproject.org<mailto:libdnet-owner@fedoraproject.org> <libdnet-owner(a)fedoraproject.org<mailto:libdnet-owner@fedoraproject.org>>; devel(a)lists.fedoraproject.org<mailto:devel@lists.fedoraproject.org> <devel(a)lists.fedoraproject.org<mailto:devel@lists.fedoraproject.org>>; open-vm-tools-owner(a)fedoraproject.org<mailto:open-vm-tools-owner@fedoraproject.org> <open-vm-tools-owner(a)fedoraproject.org<mailto:open-vm-tools-owner@fedoraproject.org>>
Subject: Re: libdnet in Fedora
Hey!
OK... Could be that it's still in the devel branch... I'll check later!
Oliver
On Thu, Jan 14, 2021 at 2:51 PM Richard W.M. Jones <rjones(a)redhat.com<mailto:rjones@redhat.com>> wrote:
Thanks - it all seemed to go OK.
Interestingly the libdnet SONAME did not change.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones<https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fpeople.redha…>
Read my programming and virtualization blog: http://rwmj.wordpress.com<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Frwmj.wordp…>
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibguestfs…>