On ma, 28 joulu 2020, redbaronbrowser wrote: >‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >On Monday, December 28, 2020 6:16 AM, Alexander Bokovoy <abokovoy at redhat.com> wrote: > >> On ma, 28 joulu 2020, redbaronbrowser via CentOS-devel wrote: >> >> > But there is one "magic wand" that can help fix issues without a bug >> > report which is to empower the community with the resources that should >> > come with being the upstream provider. Right now the Stream kernel has >> > four patches which are all for debranding. The 4.18 kernel tar.xz file >> > in the SRPM is 110% the size of a vanilla tar.xz for 4.18. What is >> > that additional 10%? How many patches are there? How many are >> > security patches? How many are bug patches? How many are feature >> > patches? How many patches were added between releases? How does a >> > CentOS Stream contributor roll back individual patches? >> > If killing CentOS 8 before 2022 is part of an effort to close the >> > openness gap and to better address bugs, then let's /REALLY/ do that >> > with a kernel SRPM. It is time to make the patch information fully >> > open to assist the community in fixing bugs. >> > But if the kernel SRPM can be left in the horrific state it currently >> > is, then stop hitting us with all this empty posturing about the >> > so-called positives we get out of killing CentOS 8 early. >> >> These are good questions too. I have no experience working with RHEL >> kernel packaging myself, but looking at the changelogs, I wonder how >> many individual patches would be there. One thing I noticed in past is >> that using tens of thousands of patches in RPM spec file will amount to >> tens of thousands individual invocations of /usr/bin/patch command, each >> with its own cost. What is a cumulative overhead of that? Sadly, I was >> not able to find any performance investigations for GNU Patch. May be >> this can be done as a synthetic test using kernel changesets (5.10 >> development cycle got 16K of non-merge changesets, for example). > >If you run "rpmbuild -bp" against a Stream kernel SRPM and a Fedora >kernel SRPM, you can then see the difference made by running patch only >4 times vs 70 times. 35 patches, as applied in https://kojipkgs.fedoraproject.org//packages/kernel/5.10.2/200.fc33/data/logs/x86_64/build.log $ curl -s https://kojipkgs.fedoraproject.org//packages/kernel/5.10.2/200.fc33/data/logs/x86_64/build.log | grep Applying: | wc -l 35 I don't think that is representative. >In my experience, the prep section of building a kernel always amounts >to less than 1% of the overall build time. There is no time savings by >pre-applying the patches that justifies the lack of time savings. > >If building time is a concern, then rpm-build should stop erasing the >entire rpmroot directory and let make reuse object files based on >source files which didn't change between releases. That would be a major issue with reproducible builds and with security of the build environment. Anyway, it is just my thought on what could be affecting an RPM build with 'too many' patches. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland