As discussed before the new SOF audio driver needed for audio to
function properly on recent Intel based laptops needs the
For F32 this has been added to comps, but for F31 and for people
upgrading from F31, we are still getting bug reports that audio
does not work with newer kernels, see e.g. :
So we need to do something for F31 ASAP (and rely on people fully
updating F31 before upgrading to fix upgrades to F32).
My proposal still is to add a:
To the F31 (and F30) kernel-modules sub-package.
If I receive no objections to this I will add this change
to distgit soon , so that it can be picked up by the next
Or even better if the maintainer of the current F30/F31
kernel can do this before the next build, that would be
From: Jeremy Cline <jcline(a)redhat.com>
ARK's master branch tracks Linus's master branch, so drop the check for
a remote named "linus" (which might be wrong anyway) and use the local
master branch to calculate the snapshot.
While this does assume that the local master branch is up-to-date,
that's better than trying to guess the correct remote name and can be
Cc: Frantisek Hrbata <fhrbata(a)redhat.com>
Cc: Rado Vrbovsky <rvrbovsk(a)redhat.com>
Cc: Jeremy Cline <jcline(a)redhat.com>
Cc: Luis Claudio Goncalves <lgoncalv(a)redhat.com>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: "Herton R. Krzesinski" <herton(a)redhat.com>
Cc: Juri Lelli <jlelli(a)redhat.com>
Cc: Jan Stancek <jstancek(a)redhat.com>
Cc: Clark Williams <williams(a)redhat.com>
Signed-off-by: Jeremy Cline <jcline(a)redhat.com>
redhat/Makefile.common | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/redhat/Makefile.common b/redhat/Makefile.common
index a3b16c8a50f2..d980847aacc7 100644
@@ -41,17 +41,11 @@ else
- # In order to do a snapshot properly, we need to have a remote set up
- # to track upstream.
- _HAVE_UPSTREAM_REMOTE:=$(shell git remote | grep -wc linus)
- ifeq ($(_HAVE_UPSTREAM_REMOTE),1)
- MERGE_BASE:=$(shell git merge-base HEAD linus/master)
- TAG:=$(shell git describe $(MERGE_BASE))
- # a snapshot off of a tagged git is of the form [tag]-[cnt]-g[hash]
- SNAPSHOT:=$(shell echo $(TAG) | grep -c '\-g')
+ # master is expected to track mainline.
+ MERGE_BASE:=$(shell git merge-base HEAD master)
+ TAG:=$(shell git describe $(MERGE_BASE))
+ # a snapshot off of a tagged git is of the form [tag]-[cnt]-g[hash]
+ SNAPSHOT:=$(shell echo $(TAG) | grep -c '\-g')
Recently someone else from Red Hat notified me that their dock had
stopped working in Fedora after the recent 5.6 kernel update. It turns
out that Fedora picked up a couple of extra post-5.6 fixes for MST
(these are the F32 shas):
drm/dp_mst: Fix W=1 warnings
drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write()
drm/dp_mst: Fix drm_dp_check_mstb_guid() return code
The first patch in that series regressed a couple of things, and the
second two patches fixed said regressions - but there was still one
issue leftover that I didn't notice and fix until last week. I've
backported that patch so it can be included in F31/32.
Lyude Paul (1):
drm/dp_mst: Fix drm_dp_send_dpcd_write() return code
drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
On Sat, Apr 25, 2020 at 10:21 AM Daiki Ueno <ueno(a)fedoraproject.org> wrote:
> Hello Ondrej,
> Ondrej Mosnacek <omosnace(a)redhat.com> writes:
> > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek <omosnace(a)redhat.com> wrote:
> >> On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek <omosnace(a)redhat.com> wrote:
> >> > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno <ueno(a)fedoraproject.org> wrote:
> >> > > Hello,
> >> > >
> >> > > I am not sure if this deserves a Fedora Change proposal, so I'd like to
> >> > > hear any opinions first before proceeding with the process.
> >> > >
> >> > > NSS (the crypto library used by Firefox) historically supports 2
> >> > > database formats: SQLite and DBM. The latter is considered legacy and
> >> > > we switched the default database format to SQLite in F28. Since then
> >> > > I presume most of the applications have switched to the new format.
> >> > > Therefore we are planning to phase out the support of DBM, targetting
> >> > > F33+.
> >> > >
> >> > > Please let me know if there is any concern.
> >> >
> >> > It seems this broke the kernel build. I did some scratch build today
> >> > to test some patches, but it failed with this:
> >> >
> >> > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir
> >> > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s
> >> > pesign: Could not initialize nss.
> >> > NSS says "The certificate/key database is in an old, unsupported
> >> > format." errno says "No such file or directory"
> >> > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build)
> >> > RPM build errors:
> >> > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build)
> >> > Child return code was: 1
> >> Probably related: https://github.com/rhboot/pesign/issues/34
> > I filed a bug against pesign here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1827902
> Good catch, and thank you for filing the bug. For the meantime I
> reverted the DBM disablement to unblock the kernel package build:
Thanks for that, I know they were working on a fix for pesign on
Friday, but I am not sure what their timeframe is.
I have ThinkPad T480s and after latest kernel upgrades on Rawhide I
see something like:
Right after grub and then system reboots.
I found on the internet that passing `efi=no_disable_early_pci_dma`
could help and it actually did!
Anybody else saw this issue? Any ideas if this could be worked around
in Fedora kernel?
On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno <ueno(a)fedoraproject.org> wrote:
> I am not sure if this deserves a Fedora Change proposal, so I'd like to
> hear any opinions first before proceeding with the process.
> NSS (the crypto library used by Firefox) historically supports 2
> database formats: SQLite and DBM. The latter is considered legacy and
> we switched the default database format to SQLite in F28. Since then
> I presume most of the applications have switched to the new format.
> Therefore we are planning to phase out the support of DBM, targetting
> Please let me know if there is any concern.
It seems this broke the kernel build. I did some scratch build today
to test some patches, but it failed with this:
+ /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir
/etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s
pesign: Could not initialize nss.
NSS says "The certificate/key database is in an old, unsupported
format." errno says "No such file or directory"
error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build)
Child return code was: 1
Here is a clean scratch build from current dist-git master:
At the time of writing it failed on x86_64 with this error and passed
on s390x (it seems pesign is not run there).
>  https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
> Daiki Ueno
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://email@example.com
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
For those that don't know me, my name is Don Zickus, a RHEL kernel engineer
for the last decade or so. I am the group lead of various projects
including the Fedora kernel workflow changes.
I know as Jeremy and Justin have rolled out changes recently there have been
concerns over technical and non-technical issues. While they are happy to
make various tweaks to the workflow that might have broken during the
conversion, I am asking for some of the bigger concerns, folks reach out to
A couple of years ago, I convinced Laura Abbott and Jeremy to pursue this
workflow change with me and they implemented the pieces to make this work.
Laura even gave a talk about this at Flock in 2019.
I am sure there are pieces we overlooked in our attempt to change the
workflow and over the next few months we will try to address what makes
sense. I just ask folks to redirect their concerns to me and work with us
to get them resolved.
The two concerns I am aware that need addressing are:
* broken out patches
* handle drive-by users who know dist-git by not the source git tree
Is there any other large concern with the new workflow?
Why did we go this way?
* The goal was to create a proper development environment and have
developers use the Fedora ecosystem to do their work in a natural way and
easily leverage creating and building rpms, using CI services and any
other Fedora infrastructure. IOW make it easier to use Fedora as the
place to do development.
* Another goal was to respectfully integrate the RHEL kernel workflow
(_without_ removing Fedora freedoms and liberties) such that our partners
and customers can contribute to the stability of this kernel in
preparation for future RHEL kernels. Increasing focus on Fedora kernel
was considered a good thing.
The downside of this approach is the impact on those users who prefer a
The result we have today is what the RHEL development world has looked like
for 10+ years. Is it perfect? No. Is there better ways to do things?
The Fedora kernel is not the only package going in this direction. Dozens
of other packages are looking to packages like the kernel to see what this
world would look like. As a leader in this direction, there will be
unforseen bumps that we need to work through.
However, over time, we would like this new source git tree world to be a new
type of standard and the dist-git world a mechanical back-end process.
We understand not everyone will agree with this change, but are hopeful that
we can work with everyone to address the concerns respectfully and still
achieve our goal of having Fedora be the easiest and most natural way to do
Thanks a lot for everyone who participated in the Kernel 5.6 Test Week
The Test Week was very successful, and we've got:
259 tests ran who actually submitted results.
54 of those were with the newer 5.6.3 kernel showing the advantage of
this being a test week.
10 of those were non x86_64
Thanks Justin Forbes(jforbes) for building the images and all the
folks who helped!
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
This should come as no surprise to those who have been following the
kernel list and/or saw Laura's Flock talk last summer, but there are
some changes to the way the Fedora kernel is maintained coming in the
next couple of weeks.
For those folks who aren't committing directly to the kernel dist-git,
this change won't really impact you, although contributing might be
We're planning to switch from maintaining the kernel directly in the
dist-git to using a kernel source tree along with a set of scripts to
turn the source tree into something that can be automatically checked
into the dist-git. This means anything committed directly to the dist-
git repository will get overwritten on the next update.
The git repository is currently hosted at
https://gitlab.com/cki-project/kernel-ark/. Documentation (still very
rough) for common tasks is at
https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few
outstanding merge requests to get the tree fully synced up with the
current state of the dist-git repository, so if you decide to jump in
and try things out, be aware things might not work.
As part of this, we're going to start bridging merge requests to this
list as emailed patch series for those who prefer email, and turn any
emailed patches to the list into merge requests, so the list is going
to get quite a bit more traffic.
One of my machines did not get a graphical desktop when I tried out the
kernel-5.7.0-0.rc0.git6.2.fc33.x86_64 no debug kernel on a rawhide instance.
kernel-5.6.2-301.fc32.x86_64 worked fine.
lightdm failed to start. Since this is pre-rc1, I'm not too worried about it.
One of the lightdm log files included the following:
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
Build Operating System: 5.5.10-200.fc31.x86_64
Current Operating System: Linux laptop2.wolff.to 5.7.0-0.rc0.git6.2.fc33.x86_64 #1 SMP Mon Apr 6 22:18:33 UTC 2020 x86_64
Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.0-0.rc0.git6.2.fc33.x86_64 root=UUID=8fa8755f-8a4b-4d62-a2d7-f4bac93fc395 ro rd.luks.uuid=luks-0264f9e9-2f5a-49fe-ba11-6d43a5cfa1be rd.luks.uuid=luks-c8fa77dd-e87f-4ad6-ba60-509458156055
Build Date: 30 March 2020 12:00:00AM
Build ID: xorg-x11-server 1.20.8-1.fc33
Current version of pixman: 0.38.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr 8 09:13:34 2020
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) modeset(0): Initializing kms color map for depth 24, 8 bpc.
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
i965: Failed to submit batchbuffer: Bad address