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

Bug#436267: Firewire support in lenny



[ stripping cc list to relevant bug report + devel for general info ]

On Tue, Feb 12, 2008 at 12:31:43PM +0100, Guus Sliepen wrote:
> On Tue, Feb 12, 2008 at 11:49:22AM +0100, maximilian attems wrote:
> 
> 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.

that discussion belongs to another thread, but don't be too pessimistic.
 
[snipp]
> libdc1394 2.0.1 is in unstable: http://packages.debian.org/libdc1394-22

cool.
sorry rmadison wasn't showing it to me yet.
 
> 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.

even with 2.6.24-4 linux images?
please mention the uname of your tests
 
> > 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 you are on amd64 2.6.25-rc1-git2
-> http://photon.itp.tuwien.ac.at/~mattems/
will build i686 during day (takes much longer)

please if 2.6.24 has troubles feedback on that one.
 
> > 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.

you can't have both without blacklisting one otherwise udev loads
randomly from boot to boot other firewire stack. changing blacklist
files in /etc/modprobe.d is trivial.
 



Reply to: