[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linux 3.11



On Mon, 2013-11-18 at 12:14 +0100, Jérôme Vouillon wrote:
> Hi,
> 
> Le 17/11/2013 23:18, Niels Thykier a écrit :
> > On 2013-11-17 20:32, Ben Hutchings wrote:
> >> On Sun, 2013-11-17 at 20:01 +0100, Niels Thykier wrote:
> >>> On 2013-11-17 19:30, Ben Hutchings wrote:
> >>>> Linux 3.11 has at last successfully built on all architectures.
> >>>>
> >>>> The latest version (3.11.8-1) has only been in unstable for 2 days, but
> >>>> it has many important fixes and we really should get this into testing
> >>>> before moving on to Linux 3.12.
> >>>>
> >>>> Please force/hint as necessary so that linux, linux-latest and
> >>>> linux-tools can propagate into testing.
> >>>>
> >>>> Ben.
> >>>>
> >>>
> >>> Urgented linux and linux-latest. AFAICT, linux-tools is ready on its
> >>> own.
> >>
> >> Right, it's just that linux-tools had to wait for linux.
> >>
> >>> It looks like it might need an easy hint.  For now, I am leaving
> >>> that to the auto-hinter.  :)
> >>
> >> Thanks.
> >>
> >> Ben.
> >>
> >
> > Okay, that didn't work because linux have out of date binaries on
> > kfreebsd apparently...
> >
> > out of date on kfreebsd-amd64: linux-support-3.11-1 (from 3.11.6-2)
> > out of date on kfreebsd-i386: linux-support-3.11-1 (from 3.11.6-2)
> >
> > ... which looks a bit strange considering that linux-support-3.11-1
> > appears to be an arch:all package.  Ansgar promised on IRC that he would
> > take care of it, so hopefully linux et al. will migrate in the "morning"
> > run tomorrow.
> 
> There seems to be other issues.
> 
> In testing, nvidia-kernel-3.10-3-486  depends on linux-image-3.10-3-486. 
> Hence, I think source package nvidia-graphics-modules needs to be 
> updated (see http://coinst.irill.org/report/p/linux.html).

Or removed from testing.  Non-free crap should not block the kernel.

(There is a new nvidia-graphics-modules in NEW which should fix this.)

> Packages linux-headers-3.11-* do not provide linux-headers any
> longer. Hence, there is an issue with package oss4-dkms on non-intel 
> architectures, as it depends on "linux-headers-686-pae | 
> linux-headers-amd64 | linux-headers-generic | linux-headers".

#728267

I doubt anyone uses it on non-Intel architectures, so who cares?

> There is a 
> similar issue with blktap-dkms and blcr-dkms, that depend on 
> "linux-headers-generic | linux-headers", on all architectures.

#728266, #728264

I just made NMUs to fix these.  However, blcr-dkms will still not build
against Linux 3.10.

> In fact, there seems to be several other packages in the same situation 
> as oss4-dkms (package dkms, for instance), but because they are 
> arch:all, Britney will not consider this as an issue.

I think I already opened bugs against all of those.

> It might be possible to temporarily remove nvidia-graphics-modules and 
> blktap-dkms (together with blktap, xcp-storage-managers, and 
> xen-api-libs). Source packages oss4 and blcr are more problematic: many 
> packages depend on liboss4-salsa2 on kfreebsd architectures; openmpi 
> depends on blcr libraries.

Considering the release schedule (see the News section
<http://crd.lbl.gov/groups-depts/ftg/projects/current-projects/BLCR/>)
and the deep hackiness of BLCR, it is quite likely that blcr-dkms cannot
be included in a stable release.  In fact this is what happened last
time.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: