Justin, many thx for your detailed answer.
On 14.02.22 19:14, Justin Forbes wrote:
On Mon, Feb 14, 2022 at 5:15 AM Thorsten Leemhuis
<fedora(a)leemhuis.info> wrote:
>
> On 12.02.22 06:21, Neal Gompa wrote:
>> On Fri, Feb 11, 2022 at 11:25 AM Justin Forbes <jforbes(a)redhat.com> wrote:
>>> On Fri, Feb 11, 2022 at 8:07 AM Thorsten Leemhuis
<fedora(a)leemhuis.info> wrote:
>>>> On 08.02.22 20:24, Donald Zickus wrote:
> My problem: with SRPMs it's easy to do this for thousands of
packages in
> Fedora without known anything about the particular package:
>
> - verify the sources are pristine
> - update to a newer version
> - add or remove patches
> Kernel-ark broke all that from where I stand:
>
> - the sources included in kernel.spec don't match upstream and it's not
> obvious from reading the spec file how to verify them
The source matches upstream in that they are a tarball made from
linus' branch (and nothing else). While we did previously download and
verify the signature of a tarball from
kernel.org for actual releases,
the rc patches and such were generated from git before as well. As
kernel.org does use signatures for releases, you can verify those
signatures in our clone just the same. Using git log
--show-signature' will show you the signatures on commits if they
exist.
How about adding a short comment to the spec file explaining this,
otherwise it might look suspicions for people not familiar with
kernel-ark/git.
> - if you want to manually update stable kernel.spec from say
5.16.5 to
> 5.16.6 you now have to modify the version number in iirc *four*
> different places; this like that would never pass a package review in
> Fedora. And even if you did that: then you still have to deal with the
> kabi stuff, which is not of interest for Fedora either iirc.
This is somewhere that definitely needs improvement, but it has not
made it up on my priority list. More importantly, changing a release
should not change the sources required.
Yeah. And yes, it's not urgent, but these small annoyances are likely
among the reasons why I haven't come on good terms with kernel-ark yet. :-/
> - building a near vanilla kernel that still applied patches
needed to
> get things things building (like the gcc12 patches in rawhide recently)
> used to be pretty easy, now it's hard (as can be seen by the mailing
> list post about this a few days ago; I had trouble as well, but was able
> to deal with them myself)
This is an issue we are working to address. Right now, if things are
building in rawhide, and not for you, the best bet is to look for
merge requests labeled "Include in releases" The hope is to get these
types of patches merged quickly now, though in the gcc12 case, there
was some discussion upstream and both of those patches have gone
through revisions, one as recently as yesterday.
https://gitlab.com/cki-project/kernel-ark/-/merge_requests?scope=all&...
Many thx for working on this.
>> If we're going to have RHEL configs in kernel-ark
(remember, "ark" is
>> really "rhel"), would other downstream configs be allowed? Can the
>> testing apparatus be extended to build and test them? How far can we
>> go here?
Every set of configs is another list of things that take time to
process, require care and feeding to maintain, and must be reviewed
and set. I don't see any value in adding too many additional
downstream configs. The mechanism already exists with
config-overrides to maintain separate configs in a branch, and it is
not particularly difficult to add another set of configs without
overrides. I am looking to drop configs (i686, armv7), not add more.
BTW, what also would help a lot from my side to get on better terms for
kernel-ark: some more (a lot more?) and better documentation for
kernel-ark, as things like that (or the "include in releases" tag) are
hard to find for outsiders. It afaics would also be helpful to have some
more docs for Fedora users (in the Fedora wiki?) that need/want to do
fiddle with the kernel somehow, for example adding or removing a patch
to test something.
>>> While there is a defined workflow, there are improvements
being made
>>> over time, and we are still looking at places the current process can
>>> be improved. This is why the thread was started. Is the mailing list
>>> interaction where it should be from an automation point of view? Are
>>> we sending too much? Not enough?
>
> Not sure. I for one missed that you added patches to make gcc12 builds
> work. Did I miss them in the noise (then some tags might help to
> distinguish RHEL and Fedora specific stuff -- or do we have those?) or
> are those patches not mentioned on the list when they get applied (I
> would like that, but maybe that's just me)?
There should be no fedora specific patches,
Sorry, you are of course right, poorly expressed myself here.
the GCC bits apply to
both. All gcc patches were delivered to this list at the time that
the MRs were opened. [...]
Yeah, then I missed them, which brings us back to the "Are we sending
too much? Not enough?" part, as I have a better answer to it now:
The amount of mail itself is not a problem for me, but a lot of them
afaics are irrelevant for users like me that mainly care about Fedora.
Those mails thus create a noise in which I easily miss the things I'm
interested in. Hence for me it would be helpful if RH/CentOS specific
things like "Sync support status with RHEL9 and updates to new
messaging", "configs: enable LOGITECH_FF for RHEL/CentOS too", or
"Add
Partner Supported taint flag" could be tagged for local filtering or get
sent to a entirely different list.
Anyway, thx again for your reply.
Ciao, THorsten