[ 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
