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

Bug#326004: reopen the bug



tag 326004 +upstream
thanks

On Thu, Sep 15, 2005 at 11:24:58PM +0200, Ruben Porras wrote:
> El jue, 15-09-2005 a las 18:19 +0900, Horms escribió:
> > On Thu, Sep 15, 2005 at 09:51:15AM +0200, Ruben Porras wrote:
> > > reopen 326004
> > > reassign 326004 linux-image-2.6-686
> > > severity 326004 wishlist
> > > Thanks
> > > 
> > > The bug is real, so I think you shouldn't close it, at least leave it as
> > > wishlist and close it when the linux kernel gets support for my device.
> > > 
> > > Also, would you be so kind of pointing me to somewhere when I can read
> > > what the problem is and its status?
> > 
> > First I'd like to come out and say, as having the BTS as a store
> > for a list of unimplemented features greatly diminishes the
> > useful ness of the BTS as a tool to track what the debian
> > kernel team is working on with regards to the kernel.
> 
> you could use the new user defined tags to mark the bugs you are working
> on, but I suppose you know it already.

A few other people have suggested that, it sounds like a good solution.

> > But thats just my opinion, and the BTS is already has
> > so many bugs its of little use, so one more isn't going
> > to make any difference.
> 
> While I agree with you tat there is no point in filling a bug asking the
> maintainer of your favourite MUA to implement a way to make your mail
> address and name blink in the emails while you read them I think this
> bug is not of little use, only it's really hard to fix, you are right
> that this need to be done upstream.
> 
> <rant>For example, due to this bug I can't install debian using CD-ROM
> without taking especial measures, if we add that the NIC and the WLAN
> didn't work also out of the box...</rant>
> 
> >   SERIAL ATA (SATA) SUBSYSTEM:
> >   P:      Jeff Garzik
> >   M:      jgarzik@pobox.com
> >   L:      linux-ide@vger.kernel.org
> >   S:      Supported
> > 
> > I sent Jeff a mail about this recently, in which he explained
> > that SATA ATAPI was not ready, and it would be enabled when it
> > is. However he did not provide any additional details. I'd suggest
> > the archives of the linux-ide list as a starting point.
> 
> Yes, you are right, it seems thah SATA ATAPI isn't ready, but with my
> hardware its enough to change in include/linux/libata.h
>  
> #undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */ 
> to 
> #define ATA_ENABLE_ATAPI /* define to enable ATAPI support */
> 
> and recompile the Debian kernel. I can read/burn CDs and DVDs. So, its
> enough for me at the moment. I'll try to close the bug when a kernel
> that has ATA_ENABLE_ATAPI activated enters Debian if no one else do it.

I specifically asked Jeff if enabling the option as such in Debian
builds, or providing a configuration option to enable it through
make menuconfig was appropriate. He flatly said no, the code is not
ready, and it is that hard to enable for that reason.

I do sympathise that there are a lot of people that would benifit from
this option. But I can only take Jeff's advice, and leave it off 
for now. He had some farily unplesant remarks to make about
distributions that do turn it on, and frankly, he knows more about this
than I.

Rest assured, as soon as we start shipping a kernel that Jeff feels
can run SATA ATAPI, we will turn it on - well, someone might have
to remind us, things do slip through the craks. But right now
its an upstream issue. I'm tagging it as such in the BTS.
And other than working with upstram to get the code straightened out,
there isn't much that anyone can do about it.

-- 
Horms



Reply to: