Kernel update missing corresponding linux-restricted-modules update

[Mary Gardiner]

The latest version of linux-restricted-modules-2.6-k7 -- version 2.6.8.1-15 --
depends on a package called linux-restricted-modules-2.6.8.1-5-k7, which is not
available from the Warty security or standard archive.

This is my /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu warty main restricted
deb http://security.ubuntu.com/ubuntu warty-security main restricted universe
multiverse
deb http://archive.ubuntu.com/ubuntu warty-updates main restricted
deb http://archive.ubuntu.com/ubuntu warty universe multiverse

[Chuck Smith (smith.chuck)]

I have precisely the same problem with the newly-release i686-smp LRM package.

[Matt Zimmerman (mdz)]

Checking for source dependency conflicts...
  /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install debhelper
libqt3-mt-dev linux-headers-2.6.8.1-5-386
linux-headers-2.6.8.1-5-686 linux-headers-2.6.8.1-5-686-smp
linux-headers-2.6.8.1-5-k7 linux-headers-2.6.8.1-5-k7-smp module-init-tools rpm
sharutils bzip2
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package linux-headers-2.6.8.1-5-386

The headers packages are built now, so I think it only needs a retry. James/LaMont?

How did this happen, and how can we prevent it the next time?

[Matt Zimmerman (mdz)]

OK, that build log was actually from yesterday, and I was confused.

it looks like a simple case of linux-source-2.6.8.1 being uploaded without a
corresponding linux-restricted-modules.

Martin?

[Matt Zimmerman (mdz)]

Scratch that. The build log was from 2.6.8.1.3-6, which *does* in fact seem to
corresponding to linux-source 2.6.8.1-16.11.

-rw-rw-r-- 1 katie katie 3103 Feb 11 23:50 linux-meta_2.6.8.1-15.dsc
-rw-rw-r-- 1 katie katie 1731 Feb 11 23:50
linux-restricted-modules-2.6.8.1_2.6.8.1.3-6.dsc
-rw-rw-r-- 1 katie katie 2121 Feb 11 23:50
linux-source-2.6.8.1_2.6.8.1-16.11.dsc

[Matt Zimmerman (mdz)]

I did a new source upload to get things built, but it's now waiting in
queue/new, where I don't think I can do anything with it until James wakes up.

James, when you wake up, please process them. If it is possible to pre-seed the
next 10 or so kernel ABIs, please do that as well. ABI changes are seriously in
fashion these days.

[Martin Pitt (pitti)]

(In reply to comment #3)
> OK, that build log was actually from yesterday, and I was confused.
>
> it looks like a simple case of linux-source-2.6.8.1 being uploaded without a
> corresponding linux-restricted-modules.
>
> Martin?

There was a l-r-m upload (2.6.8.1.3-6.dsc), but helena only showed it's source
package. However, there were lots of linux-restricted-modules packages built, so
I thought that were a bug in helena. I'm terribly sorry for this mistake.

I now think I know what the problem was: first, linux-source was uploaded which
built packages for new ABI. Then l-r-m was uploaded which FTBFS because it
build-depends on the new kernel packages. Thus this seems to be a catch-22:
l-r-m can't be built without the new kernel in the archive, but we can't put the
new kernel into the archive without a built l-r-m.

Somehow this worked fine the previous time (I just wonder why).

Is it somehow possible for security builds to also take the packages in the
queue into account?

[Martin Pitt (pitti)]

(In reply to comment #5)
> I did a new source upload to get things built, but it's now waiting in
> queue/new, where I don't think I can do anything with it until James wakes up.
>
> James, when you wake up, please process them. If it is possible to pre-seed the
> next 10 or so kernel ABIs, please do that as well. ABI changes are seriously in
> fashion these days.

This was done, and I now released the packages to the archive. Matt, thanks for
the upload.

However, the remaining question is how this can be solved in the future? (See my
last reply)

[Matt Zimmerman (mdz)]

(In reply to comment #6)
> I now think I know what the problem was: first, linux-source was uploaded which
> built packages for new ABI. Then l-r-m was uploaded which FTBFS because it
> build-depends on the new kernel packages. Thus this seems to be a catch-22:
> l-r-m can't be built without the new kernel in the archive, but we can't put the
> new kernel into the archive without a built l-r-m.

security builds should be able to use packages from the accepted queue, as well
as those in the archive. James, is this not the case, or is there some other
explanation why things didn't happen as expected this time?

[James Troup (elmo)]

(In reply to comment #8)
> (In reply to comment #6)
> > I now think I know what the problem was: first, linux-source was uploaded which
> > built packages for new ABI. Then l-r-m was uploaded which FTBFS because it
> > build-depends on the new kernel packages. Thus this seems to be a catch-22:
> > l-r-m can't be built without the new kernel in the archive, but we can't put the
> > new kernel into the archive without a built l-r-m.
>
> security builds should be able to use packages from the accepted queue, as well
> as those in the archive. James, is this not the case, or is there some other
> explanation why things didn't happen as expected this time?

security builds can see other security builds in queue/accepted - they can't see
stuff in queue/new which is where the l-s-2.6.8.1 binaries ended up. With the
pre-seeding of the next 10 ABI bumps, this should all be a moot point.