kernel September 2019

kernel@lists.fedoraproject.org

14 participants
14 discussions

custom kernel build with patch
by Damian Ivanov 10 Sep '19

10 Sep '19

Hello, I am trying to build the fedora kernel with the muqss patch and the patches for the surface devices. To start I tried to build it only with the muqss patch. So tried as well with fedpkg as well as a plain rpmbuild but both hang at the same stage. I enpacked the kernel.src.rpm, fetched the latest muqss patch and added it in the kernel.spec. Also I did set %define with_baseonly 1 to build only non-debug x86_64 Trying to build the kernel with rpmbuild -ba kernel.spec will fail at the stage of process_configs.sh that compains about config options being unset (and .git/rebase-apply/patch:7590: space before tab in indent. cpu = i; .) So I try to add them to all config's but when building I get: Error: Mismatches found in configuration files Found CONFIG_RQ_ALL=is not set after generation, had CONFIG_RQ_ALL=n in Source tree Found CONFIG_RQ_SMP=is not set after generation, had CONFIG_RQ_SMP=n in Source tree Found CONFIG_RQ_SMT=is not set after generation, had CONFIG_RQ_SMT=n in Source tree Found CONFIG_RQ_NONE=is not set after generation, had CONFIG_RQ_NONE=n in Source tree What is the correct way to build the fedora kernel with a custom patch added? * tried this as well https://fedoramagazine.org/building-fedora-kernel/ Thanks in advance. Damian

3 5

Re: Discussion: what would not blocking on btrfs look like?
by Josef Bacik 09 Sep '19

09 Sep '19

On Mon, Sep 09, 2019 at 01:43:00PM -0400, David Lehman wrote: > On Thu, 2019-09-05 at 18:01 -0700, Adam Williamson wrote: > > On Tue, 2019-09-03 at 13:38 -0400, David Lehman wrote: > > > On Fri, 2019-08-23 at 12:16 -0700, Adam Williamson wrote: > > > > Hey folks! > > > > > > Hi Adam! Thanks for bringing this up again. > > > > > > > So...what should we do? Here are the options as I see 'em: > > > > > > > > 1. Keep supporting btrfs > > > > 2. Just modify the criterion with a btrfs exception, even if it's > > > > weird > > > > 3. Rewrite the criterion entirely > > > > 4. Keep btrfs support in the installer (and blivet-gui) but hide > > > > it > > > > as > > > > we used to - require a special boot argument for it to be visible > > > > 5. Drop btrfs support from the installer > > > > > > I like option 3 most. The current criteria have always seemed, to > > > me, > > > too vague. I'd be happy to help hash out the details if/when it > > > happens. > > > > Thanks for the offer. > > > > So aside from the 'fun' of drafting very specific rules, my concern > > with #3 is we would then potentially be shipping an installer that > > presents things as roughly equal choices which are not in fact > > equally > > supported. You can pick 'btrfs' or 'ext4' from the dropdown...but one > > of those we commit to making sure is working, one of them we don't. > > > That to me is concerning; in this scenario I'd prefer we indicate > > somehow, somewhere, that all the choices are not equally guaranteed > > to > > be reliable. WDYT? > > > Two off-the-cuff ideas: > > 1. every fs (and device?) type in the combo/dropdown has "(Supported)" > or "(Unsupported)" postfix, eg: "xfs (Supported)" or "BTRFS > (Unsupported)" > 2. every unsupported fs type has a corresponding kernel arg, eg: > "inst.btrfs" or "inst.fs.btrfs" which is required to get that > unsupported fs type in the GUI list > > I could live with either, personally. > Why bother hiding it at all? I get that there's no btrfs expertise at Red Hat, but there's not any reason to indicate that it's bad for the user to choose it. Suse ships it, all of Facebook is on it, it's not like we're talking about hfs+ here or anything. I get the discussions around wether it's a release blocker, I don't really understand why the installer needs to be changed? Thanks, Josef

1 0

[PATCH] enable driver for accessing HMC CD/DVD drive
by Dan Horák 04 Sep '19

04 Sep '19

--- configs/fedora/generic/s390x/CONFIG_HMC_DRV | 1 + kernel-s390x-debug.config | 2 +- kernel-s390x.config | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) create mode 100644 configs/fedora/generic/s390x/CONFIG_HMC_DRV diff --git a/configs/fedora/generic/s390x/CONFIG_HMC_DRV b/configs/fedora/generic/s390x/CONFIG_HMC_DRV new file mode 100644 index 000000000..fc68dc34b --- /dev/null +++ b/configs/fedora/generic/s390x/CONFIG_HMC_DRV @@ -0,0 +1 @@ +CONFIG_HMC_DRV=m diff --git a/kernel-s390x-debug.config b/kernel-s390x-debug.config index 61d06297a..eb0cd3526 100644 --- a/kernel-s390x-debug.config +++ b/kernel-s390x-debug.config @@ -1758,7 +1758,7 @@ CONFIG_HIGH_RES_TIMERS=y # CONFIG_HIPPI is not set CONFIG_HIST_TRIGGERS=y # CONFIG_HMC6352 is not set -# CONFIG_HMC_DRV is not set +CONFIG_HMC_DRV=m CONFIG_HOLTEK_FF=y # CONFIG_HOSTAP is not set CONFIG_HOTPLUG_CPU=y diff --git a/kernel-s390x.config b/kernel-s390x.config index 696652ba9..0d3be1ed5 100644 --- a/kernel-s390x.config +++ b/kernel-s390x.config @@ -1741,7 +1741,7 @@ CONFIG_HIGH_RES_TIMERS=y # CONFIG_HIPPI is not set CONFIG_HIST_TRIGGERS=y # CONFIG_HMC6352 is not set -# CONFIG_HMC_DRV is not set +CONFIG_HMC_DRV=m CONFIG_HOLTEK_FF=y # CONFIG_HOSTAP is not set CONFIG_HOTPLUG_CPU=y -- 2.21.0

2 1

Re: Discussion: what would not blocking on btrfs look like?
by Neal Gompa 03 Sep '19

03 Sep '19

On Thu, Aug 29, 2019 at 4:23 AM <jkonecny(a)redhat.com> wrote: > > On Tue, 2019-08-27 at 14:59 -0700, Adam Williamson wrote: > > On Tue, 2019-08-27 at 13:25 -0400, David Cantrell wrote: > > > > Josh, to be fair, I can see Neal's point here. In a way you seem > > > > to be > > > > kinda sending him in circles here: "anaconda team doesn't have > > > > the > > > > time/resources to invest in btrfs development, but you can help > > > > by > > > > sending them pull requests. Oh, you sent them a pull request and > > > > they > > > > rejected it? Well, it's because they don't have time/resources > > > > for > > > > btrfs development..." You're right that one rejected PR doesn't > > > > necessarily indicate a contribution model problem, but putting > > > > the > > > > wider issue aside, a very simple one-liner with a major impact on > > > > btrfs > > > > functionality being rejected *does* seem to say a lot about the > > > > prospects of any btrfs-related work being accepted. > > > > > > > > Putting myself in Neal's shoes, given my experience with that PR > > > > and > > > > other attempts to help out with btrfs in anaconda, why would I > > > > invest > > > > my time and effort to write another one when it seems extremely > > > > likely > > > > it would be rejected? > > > > > > There's an assumption here that when someone is asked to send a PR, > > > it > > > will always be accepted. > > > > No, that's not what I'm assuming, but if we (Red Hat) tell people > > that > > it would be a good idea to send PRs, we should at least be > > *potentially* willing to accept them. We should not be saying 'send > > PRs' if there is no chance of them being accepted. And it would be > > nicest if we gave people a roadmap: here are the specific things you > > can do that would be acceptable to us as a way to continue including > > btrfs handling in the installer. > > Sorry but I have to react on this. It's killing me how many of you > people here are telling Anaconda does not accept patches. That is > really not true. We have smaller amount of contributions from community > that is partially our fault because of a lack of documentation but > mainly it's really hard to develop & test Anaconda and most users see > it just once in a few years so it's not bothering them so much. I guess > most of the installers are in the same situation. > I sat on this for a few days, as I wanted to cool down and think about how to reply to this. As of this moment, I have directly and indirectly contributed to both the Red Hat and SUSE installers, and yes it's definitely true that both installers have some of the worst interaction models for contributors I've ever seen. YaST's contribution model and process seems to be somewhat better, because their team has components being used by other people. Their libyui components are used by Fedora and Mageia for dnfdragora, and the rest of ManaTools in Mageia uses it too. The YaST control center is a cornerstone in the user experience in SUSE distributions, so there are contributors from their community who do work on the main YaST components. The Calamares installer stack has a pretty healthy community, but our community has an interesting aversion to all things Qt/KDE even though the installer works fine on Fedora... But the point I'm trying to make is there is no reason for Anaconda to be so difficult. Unfortunately, it is. > Please before any of you will tell again that Anaconda team is not > accepting patches, please look on the last few years history. How many > patches were "rejected" and how many were accepted. There are just a > few patches which weren't accepted and basically only a few PR (I would > even say the only one) for BTRFS. That is unfortunate but it's not all > our contributions. > I also took the opportunity look back at over the last 400 merged pull requests by paging through GitHub. Now I don't exactly have firm numbers, but in the past 400 pull requests, I saw less than a dozen pull requests merged from non-RHers. Half of them were from Pat from the Scientific Linux team. One of them was a documentation fix from some person I don't recognize with no clear affiliation. If I page back *slightly more* then the next PR from a non Red Hatter that was merged was *mine* fixing Anaconda's package exclusion feature for kickstarts (which was nearly two years old when it was merged). Of the 42 currently open pull requests, 4 are from people I could clearly identify as not from Red Hatters. Of the ones that are from Red Hatters, 7 appear to not be from members of the Red Hat Installer team or the Red Hat Bootloader team as I know of them. The lag time to response *is* improving. It's gone down from years to months, with the most recent pull request getting a comment within a week, and then stalling out after that. So it may even improve to weeks! As Adam pointed out, there's literally no reason for me to attempt more sophisticated changes to Anaconda if a simple one-liner can't get merged. And I didn't even make that fix, I've just been trying to shepherd it in for over a year! I only gave up trying and focusing on other things when it became clear I'd be dogged with non-answers forever. > Please stop saying all the time that Anaconda is not accepting > contributions or that users doesn't have a chance to get the > contributions in. > You guys brought it upon yourselves by having terrible documentation and contribution policies, unclear ownership or responsibilities of projects that are clearly related (pykickstart, which by the way guys, changed hands *again* and now is basically in a brand new black hole!), oh, and lets not forget the oh-so-joyous aspect of the CI that is forbidden to be accessed by non-Red Hatters. Honestly, I shouldn't have expected better. When I noticed that the Anaconda mailing lists never moved from the Red Hat lists to lists.fedorahosted.org, I should have realized that Red Hat wasn't treating it like a community project. Every dysfunctional RH/Fedora ecosystem project seems to have that as a common property. It's emblematic of the deeper problem that it's not treated as a project where the community is valued. OpenShift, Spacewalk, and Anaconda are all projects where I've suffered these problems. That's not to say RH projects not hosted on the Red Hat lists can't be dysfunctional too, but people seem to try to be better when they aren't. Maybe it's an attitude difference? A different approach to the project? I don't know. But something is wrong and it needs to be fixed. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel September 2019