On Tue, Feb 12, 2008 at 11:49:22AM +0100, maximilian attems wrote:
> > I guess that means that lenny will be released with linux kernel
> > 2.6.24.x. If that is so, then I kindly request that the debian kernel
> > packages will be released with the stable Firewire stack modules
> > compiled.
>
> no certainly not, we haven't yet discussed the release kernel.
> options are 2.6.25 or 2.6.26.
Given the pace of kernel releases, I do not believe 2.6.26 is possible
for lenny, but 2.6.25 is possible, although I think it will only be
released a month or two before the final freeze.
> > Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors
> > (kernel packagers) as well as to regular users is: Build only the old
> > IEEE 1394 drivers.
>
> you omit the interesting next paragraph:
> "Building the new drivers is only for advanced users (who for example
> want the better speed of firewire-sbp2 relative to sbp2) - and for
> distributors who know what is required in userspace to make use of the
> new drivers and who can get bugfixes backported and rolled out quickly."
>
> on the kernel side we do backport firewire patches.
> for the userspace side i still see lack of action on libdc1394
> "2008/01/05: The official version 2.0.0 has been released.
> 2008/01/05: A first set of fixes have been released (version 2.0.1)"
>
> why is that not even in unstable/experimental?
libdc1394 2.0.1 is in unstable: http://packages.debian.org/libdc1394-22
My IIDC cameras do not work correctly with a juju-enabled libdc1394
2.0.1. Furthermore, apart from coriander there are no applications that
have migrated from libdc1394 v1 to v2.
> the progress of the juju stack is very nice, there are quite some
> fixes queued for 2.6.25, we will make those snapshots available
> soonest.
That is good to hear.
> if the regression list for 2.6.25 is still high we may reconsider
> there to build the old stack with blacklisted modules.
> that has always been our stated fallback position, currently in the
> development phase we encourage testing of the newer stack
> on latest linux-images.
I do not see why making the old stack available again, but blacklisted
by default, discourages testing of the newer stack. If you have both
available, then yes, users can switch to the new stack more easily, but
at least they will still be using Debian kernel packages, and they can
switch back to the juju stack just as well. If you do not make this
option available, those who have problems with the new stack will have
to compile their own kernels, and then they will not track the Debian
kernel packages anymore.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
Attachment:
signature.asc
Description: Digital signature