RFC: Adding "Requires: alsa-sof-firmware" to F31 kernel-modules pkgs
by Hans de Goede
Hi All,
As discussed before the new SOF audio driver needed for audio to
function properly on recent Intel based laptops needs the
alsa-sof-firmware package.
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. :
https://bugzilla.redhat.com/show_bug.cgi?id=1806334
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:
Requires: alsa-sof-firmware
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
kernel build.
Or even better if the maintainer of the current F30/F31
kernel can do this before the next build, that would be
great.
Regards,
Hans
3 years
[OS-BUILD PATCH] Drop the requirement to have a remote called linus
by Gitlab Bridge
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
easily scripted.
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
--- a/redhat/Makefile.common
+++ b/redhat/Makefile.common
@@ -41,17 +41,11 @@ else
VERSION_ON_UPSTREAM:=0
endif
ifeq ($(VERSION_ON_UPSTREAM),1)
- # 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')
- else
- SNAPSHOT:=0
- endif
+ # 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')
else
SNAPSHOT:=0
endif
--
2.26.2
3 years, 1 month
[PATCH 0/1] Fix MST regressions picked up in the Fedora kernel
by Lyude Paul
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):
* 7012f01efd65461c1adc93bfcdc015d95a940672
drm/dp_mst: Fix W=1 warnings
* 0cf94a193d2219c75d666c55abc8b5270550f87d
drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write()
* 89c111383b8bd08c6fed3c35f1a9c2bda7dd1c4b
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(-)
--
2.25.3
3 years, 1 month
Re: dropping NSS DBM format support in F33+
by Justin Forbes
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[1]. 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:
> https://src.fedoraproject.org/rpms/nss/c/fc0174ead16bac476cce55fb2918fbfd...
>
Thanks for that, I know they were working on a fix for pesign on
Friday, but I am not sure what their timeframe is.
Justin
3 years, 1 month
Re: dropping NSS DBM format support in F33+
by Ondrej Mosnacek
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[1]. 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
Here is a clean scratch build from current dist-git master:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43737486
At the time of writing it failed on x86_64 with this error and passed
on s390x (it seems pesign is not run there).
>
> Footnotes:
> [1] https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
>
> Regards,
> --
> 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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
3 years, 1 month
Fedora kernel workflow feedback
by Don Zickus
Hi,
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
me.
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
dist-git world.
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?
Absolutely.
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
upstream development.
Thanks!
Cheers,
Don
3 years, 1 month
[Fedora Test Week] Kernel 5.6 Test Week Results
by Sumantro Mukherjee
Aloha Testers!
Thanks a lot for everyone who participated in the Kernel 5.6 Test Week
last week[0].
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!
[0] https://fedoraproject.org/wiki/Test_Day:2020-04-13_Kernel_5.6_Test_Week
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
3 years, 1 month
Upcoming Fedora kernel workflow changes
by Jeremy Cline
Hi folks,
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
easier.
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.
Regards,
Jeremy
3 years, 1 month
