Help the kernel team help you

Talk given by Ben Hutchings at Minidebconf Hamburg 18
https://meetings-archive.debian.net/pub/debian-meetings/2018/miniconf-hamburg/2018-05-20/help_kernel_help.webm

Without further ado

the first talk this morning is by

our beloved kernel maintainer Ben Hutchings

about "Help the kernel team
to help you".

Hi.

[Applause]

As Michael said, I'm one of the kernel
maintainers.

I've been on the kernel team
for about ten years now.

So, I'm going to talk about

what Debian users and developers can do

when interacting with the kernel team

to make us more effective, more able
to deal with your requests quickly.

We're quite busy.

There are about a dozen people

on the kernel team, but

most of us have other responsibilities
within Debian.

Most of us are not paid to work
on Debian either,

so we only have a few hours a week
to spend on it.

We get a constant stream of bug reports.

Some of which we can handle,

some of which unfortunately we can't.

There's a large backlog of bug reports

that probably won't get dealt with
in Debian.

They might get fixed upstream, but

we won't get them.

One of the first things you can do
to make our life easier is

report bugs upstream.

If you're running a recent kernel, and
that doesn't have to be absolutely

the latest version that Linus released
yesterday.

Any version in testing, unstable,
or experimental

or the current XXX
in backport suite

should be recent enough.

If you're running one of those versions,

then the upstream kernel developers
would probably be quite pleased to

receive your bug report.

Some subsystems in the kernel use
a bugtracker like Bugzilla

and many do not.

They just want bug reports XXX

to their development mailing list.

There's a documentation file called
MAINTAINERS

which we package.

You're gonna find it in the linux top package

and that lists for each area of the kernel

the email addresses of maintainers,

the address of any relevant development
mailing list

and in some cases it will say they use a
bugtracker at this URL.

That doesn't mean that you shouldn't
report a bug in Debian as well.

If you report a bug in Debian and upstream,

then use the standard 'forwarded' command
to link them together

and we should be able to see
status changes

if you reported in Bugzilla upstream.

Secondly, report bugs with the right
information.

The kernel packages we build include
some hook scripts

for the 'reportbug' command

so it can gather some diagnostic
information

and we generally expect that if your are
reporting a bug that is about

"This doesn't work on my machine."

then we want some diagnostict information
about your machine.

Running some commands might be useful,

it's not usually as good as XXX
diagnostic commands

that are in these scripts.

So the right way to report a bug
in the currently running kernel

is just 'reportbug kernel'.

Reportbug knows how to look up
the correct package for that.

Otherwise, you should report against
the specific version package

for example,
'linux-image-4.9.0.6-amd64'

would be the current kernel package
if you're running Stretch

on a 64 bits PC.

Don't file a bug against metapackages
like linux-image-amd64

because those are basically just some
metadata saying

"This is the current version of the kernel
and you should install that."

Don't report bugs against firmware packages

unless you're really sure the bug is
in firmware

rather than the driver.

This may seem obvious but people do
those things.

Adding features.

We do have some long-standing patches
in the kernel and the linux package.

We don't really want to add to those.

Most of those really ought to get
cleaned up and sent upstream

but it requires time
to do that.

So, new features should always
be added upstream.

As soon as they're accepted upstream,

we're happy to add them into the earlier
versions that we have in Debian

because we know that they've accepted
upstream,

then as soon as we get to that new
upstream version

we can drop that patch,

so it's not adding to the long term
burden of maintainance.

I've got a link there to the documentation
on how to contribute to the kernel.

We would be very happy, well I would
be very happy

if people would volunteer to work
on those long standing patches

and get them into a state where they would
be accepted upstream.

So, you reported a bug upstream,
and it got fixed.

That's great.

But quite often that fix isn't going
to get into a stable release

of the kernel for several months.

If the bug was actually found
in a stable release,

rather than unstable or testing

then that fix might not get
automatically into a stable update at all.

So, you probably want to tell us
what the fix is

so that we can apply it now.

If you give a reference to the specific
commit if you know that,

that is absolutely ideal.

We can easily then dig out that commit
and add it.

There's a patch tracking system used by
many of the kernel mailing lists

called "patchwork" and that will gather
together a patch and

all the discussion about it.

XXX to get a patch series
which is useful

if a fix takes multiple steps.

If you tell us the patch was discussed
on a mailing list and

link to an archive,

that can work, but mailing archives often
mangle patches

so then we need to undo the mangling

so that takes longer to deal with.

If you send the patch,
simply send the patch to the bug tracker

without any link to "oh this is where it
came from upstream",

that's actually kind of a problem because

we don't know whether that's really
what you say it is.

If it's a signed mail
from a Debian Developer

Ok, yeah, we can probably trust it.

If it's not a signed mail or it's from
a Debian user,

then we don't know.

So we need to look upstream to see

"This is the version that got commited."

If you want to do a backport from upstream
to whatever is the current version,

that's great, but you need to include
the upstream reference as well.

Talk to us as a team.

From time to time, I will get mail
directly to me, saying

"Oh there's this bug." or
"Can you help me with this?"

or occasionally a company saying

"Ok, we want to update the support for
our hardware."

They should not be mailing just me,

they should always, almost always be
sending bug reports

to the regular Debian bug tracker

and all the mail should go to the
Debian kernel mailing list.

We also have a development IRC channel,
#debian-kernel on irc.debian.org

and some things can be discussed there.

Usually it's best to send longer messages
as email.

The only reason you would want to
not use one of those public…

The only reason you should not use these
public channels is

if you're discussing a security issue
that's currently not public

and shouldn't be made public until
it's fixed

and in that case, do contact me directly

but also the Debian security team.

If you want to contribute to the packaging
rather than

if you don't want to touch the kernel code
itself

but you want to contribute
to the packaging

maybe you want to change the configuration

maybe you want to make the packaging
more suitable for its use

by downstreams, derivatives

If you simply want to improve
the packaging in Debian

Patches to that are OK,
merge requests are wonderful.

Since we moved to Salsa, I can take
merge requests

through the Gitlab software.

I found I can review and comment on
and apply these changes

pretty quickly.

It also helps so we get so we get
a notification

for all the new merge requests on IRC

so that's pretty much instant.

If a team member is looking at
the IRC channel and

has time available then they can
deal with that

in minutes sometimes.

So, in the last…

I checked back in the git history and
found in the last four weeks

that we used Alioth,

there appears to be only one patch
to the linux package

that wasn't either picked from upstream
or done by a team member.

And the last four weeks up to yesterday,

we accepted 14 merge requests on Salsa.

So, this is a massive improvement to
the productivity of the team and

our ability to accept outside contributions.

I want again remind that feature patches
for the kernel code itself

do need to go to upstream first.

So, that's about it.

I've got about five minutes for questions.

[Applause]

Are there questions?

[Q] Hi Ben, thanks for the lecture.

I am wondering what are those long
standing patches you mentioned.

Can you give a few examples for that?

[Ben] One of the things that actually
require the most work

when moving to a new kernel version is

we have a patch to, firstly, add specific
log messages to the firmware loader

so whenever a firmware file is missing

it will log that in a standard format.

This is useful for the installer,
which uses that to detect missing firmware

and warn you.

And then, because many drivers also

log firmware errors in inconsistent ways

there's a second patch that removes
those redundant log messages

and that one keeps getting conflicts
when we update.

So really, these ought to get cleaned up
a bit and sent upstream.

Further questions?

Well, if not, then let's thank Ben again.