Is https://wiki.ubuntu.com/KernelTeam/KernelMaintenance still correct?

[Stefan Bader]

Nigel Cunningham wrote:
> Hi Stefan.
> 
> On 30/03/10 18:43, Stefan Bader wrote:
>> Nigel Cunningham wrote:
>>> Hi all.
>>>
>>> I started a Lucid TuxOnIce tree today.
>>>
>>> Applying the patch was a no brainer - the vanilla 2.6.32 patch applies
>>> without rejects - but I decided to try and do things the really-o
>>> truly-o Ubuntu way. I've been following
>>>
>>> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
>>>
>>> to the letter, as far as I'm able. I'm trying to follow the "Bumping the
>>> ABI" instructions, but they seem to be out of date. After fakeroot
>>> debian/rules clean, I have:
>>>
>>> nigel at nigel-laptop:/usr/src/cg-ubuntu-lucid$ git add debian
>>> nigel at nigel-laptop:/usr/src/cg-ubuntu-lucid$ git status
>>> # On branch combined
>>> # Changes to be committed:
>>> #   (use "git reset HEAD<file>..." to unstage)
>>> #
>>> #    new file:   debian/changelog
>>> #    new file:   debian/control
>>> #    new file:   debian/control.stub
>>> #    new file:   debian/copyright
>>> #    new file:   debian/rules.d/control.stub.in
>>
>> Hi Nigel,
>>
>> this looks like you added those files. But those should not. And, yes,
>> the
>> document is outdated here for newer releases (Hardy would sill work
>> that way).
>> In essence for newer releases a "debian/rules clean" re-creates all
>> those files
>> as they are not tracked (kept) in git anymore.
> 
> They were added when I ran the Bump ABI script - I guess I did it at the
> wrong time.
> 
>>> # Untracked files:
>>> #   (use "git add<file>..." to include in what will be committed)
>>> #
>>> #    debian.master/control
>>> #    debian.master/control.stub
>>> #    debian.master/d-i/kernel-versions
>>>
>>> Should it be saying the following?
>>>
>>> touch debian.master/rules.d/control.stub.in
>>> fakeroot debian/rules clean
>>> git add debian.master
>>> git commit -s -F debian/commit-templates/bumpabi
>>>
>>
>> For recent series, just
>>
>> 1) change the abi number in debian.master/changelog (for the master
>> branch)
>> 2) git add debian.master/changelog
>> 3) git commit -s -F debian/commit-templates/bumpabi
>> 4) fakeroot debian/rules clean (this is just for your build or
>> creating the
>>     package)
> 
> Thanks. For a PPA build, is it right to pop the ~tuxonice1 in the
> release version while doing step 1?

This would be a simple way, if you are not interested in providing your own
changelog. Otherwise you would create a new release (debian/rules
startnewrelease) and would need to make sure you have the abi files right. The
build always expects a directory with the version of the previous changelog
version in debian.master/abi/... If you bump the abi anyways, you can cheat and
just rename the existing one. Otherwise you would need to download it. I believe
the instructions are somewhere on the KernelTeam wiki page on wiki.ubuntu.com.
(KernelMaintenance).

>>> By the way, is there any way to see exactly what the ABI differences
>>> are? I know TuxOnIce exports extra symbols, but I don't think any of the
>>> existing ones should have changed.
>>
>> If you look at the output of a full build, the abi checker is printing
>> some more
>> elaborate info about it. Otherwise you would need to resort to compare
>> the abi
>> files with something like meld.
> 
> Okay; I've seen the info at the end. I was looking for some way of
> seeing not just the checksums, but the definitions that were being
> compared. I'll try to find some time later to look at how the checksums
> are produced - perhaps that will give me a clue.

That is unfortunately all that the abi checker has to work on. The kernel
generates checksums for functions (which include the checksums for the arguments
and return value). So if that checksum changes something for that function has
changed. Sometimes it is simple and from the function names you can find the
patch. But if some patch changes a highly used interface...

Stefan
> Regards,
> 
> Nigel