Mailing List Archive

Donnie Berkholz wrote:
> Mike Frysinger wrote:
>> my point though wasnt to knock ati (although it was fun), the point was that i
>> do not believe any closed source driver in our tree should ever be grounds
>> for preventing stabilization of a kernel ebuild
>>
>> so next time dsd (or whoever the ninja kernel maintainer happens to be at the
>> time) says "hey i plan on stabilizing Linux x.y.z" and someone goes "wait,
>> you cant until we get <closed source driver package foo> working", the reply
>> is of course "blow it out your arse^H^H^H^Htalk to the package maintainer,
>> this will not hold up stabilization efforts"
>
> If we're gonna go with this policy here, I'm also going to adopt it for
> X so we don't get stuck in limbo as happened fairly recently.

If we're going to do this, we should just keep the unfree drivers in testing.

Marijn
--
gentoo-dev@gentoo.org mailing list

On Thu, 02 Aug 2007 20:35:18 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> William L. Thomson Jr. wrote:
> > On Thu, 2007-08-02 at 16:55 -0700, Donnie Berkholz wrote:
> >> On Thu, 2 Aug 2007 19:31:09 -0400
> >> Mike Frysinger <vapier@gentoo.org> wrote:
> >>> if the driver blows dead goats and the vendor isnt willing to help
> >>> and no Gentoo dev wants to touch it, what other solution is
> >>> there ?
> >> There's an open-source driver for the r5xx stuff called the avivo
> >> driver [1].
> >>
> >> 1.
> >> http://gitweb.freedesktop.org/?p=avivo/xf86-video-avivo.git;a=summary
> >
> > Still leaves a gap, since the open source radeon driver is not fully
> > supporting R3xx to my knowledge much less r4xx.
>
> Update your knowledge, the normal radeon driver works nice for both.
> =)

I'm not sure I would 100% agree with that. Yeah, it works for most
things, but 2D definitely could use some speed improvements (still no
Render acceleration), and any recent 3d app that needs some serious
horsepower (e.g. doom3) is pretty much useless. In fact, last time I
tried to start doom3 using the open source driver, it flat out refused
to start. Things like ut2003 and ut2004 are also pretty much unplayable.

I will say that this is still a better situation than the closed
drivers, which instantly hard lock my computer the first time I exit X
after the initial startup.

-Steve

On Friday 03 August 2007, Marijn Schouten (hkBst) wrote:
> Donnie Berkholz wrote:
> > Mike Frysinger wrote:
> >> my point though wasnt to knock ati (although it was fun), the point was
> >> that i do not believe any closed source driver in our tree should ever
> >> be grounds for preventing stabilization of a kernel ebuild
> >>
> >> so next time dsd (or whoever the ninja kernel maintainer happens to be
> >> at the time) says "hey i plan on stabilizing Linux x.y.z" and someone
> >> goes "wait, you cant until we get <closed source driver package foo>
> >> working", the reply is of course "blow it out your arse^H^H^H^Htalk to
> >> the package maintainer, this will not hold up stabilization efforts"
> >
> > If we're gonna go with this policy here, I'm also going to adopt it for
> > X so we don't get stuck in limbo as happened fairly recently.
>
> If we're going to do this, we should just keep the unfree drivers in
> testing.

i dont think that logically follows the previous argument
-mike

Donnie Berkholz wrote:
>> so next time dsd (or whoever the ninja kernel maintainer happens to be at the
>> time) says "hey i plan on stabilizing Linux x.y.z" and someone goes "wait,
>> you cant until we get <closed source driver package foo> working", the reply
>> is of course "blow it out your arse^H^H^H^Htalk to the package maintainer,
>> this will not hold up stabilization efforts"
>
> If we're gonna go with this policy here, I'm also going to adopt it for
> X so we don't get stuck in limbo as happened fairly recently.

This is how it has been for a while, and not only closed source drivers.
We have many open source kernel drivers/filesystems in the tree which
regularly break with new kernel releases. When these packages break in
this way, it is a bug in such packages, not in the kernel.

[.For those wondering why the kernel keeps changing, see
Documentation/stable-api-nonsense.txt : it is by design, maintaining
kernel code outside of the kernel is discouraged for this reason,
solution is get it in the kernel]

Maintainers of these packages got unhappy that they didn't really have
warning when new kernels were going stable, so I started announcing that
(and usually giving more notice on gentoo-dev than this time around,
sorry about that). That helped, but trying to encourage maintainers to
fix their stuff every few weeks gets old and some maintainers become
less responsive. Kernels go stable anyway and so users complain.

I now take it a step further, and create package regression tracker bugs
for each kernel release. bug #184683 is the 2.6.22 one, a little smaller
than usual.

For each bug that gets added to the tracker, I comment on any patches
that have been posted (e.g. "that's the correct fix") or if there aren't
already patches, I explain how to fix the code based on the compile
error. This is work I'd rather not do (I really don't care about your
package), but seems to work relatively well.

There are times when after I 'approve' a patch, another developer asks
me to commit it. I think that's a little unreasonable. I'm not prepared
to go *that* far at the moment, especially as I usually can't test the
package in question.

The model seems to work relatively well. One associated challenge is
making sure maintainers fix their packages in the stable tree (not only
unstable) before stabilization takes place, but that has certainly been
improving lately, e.g. Stefan did a great job fixing up many external
wireless drivers this time around, and I didn't have to reopen any of
the bugs :)

All that aside, my advice for developers considering maintaining kernel
code in portage outside of the kernel still remains as "don't do it".
Your package grows bugs overnight. It's a continual challenge trying to
keep up, and it's a headache for me trying to poke you into action. Or,
if you really must do this, never mark your package stable (that way I
can ignore it).

Daniel
--
gentoo-dev@gentoo.org mailing list

On Friday 03 August 2007, Daniel Drake wrote:
> All that aside, my advice for developers considering maintaining kernel
> code in portage outside of the kernel still remains as "don't do it".
> Your package grows bugs overnight. It's a continual challenge trying to
> keep up, and it's a headache for me trying to poke you into action. Or,
> if you really must do this, never mark your package stable (that way I
> can ignore it).

i pity the foo who doesnt listen to dsd !
-mike

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:

> so next time dsd (or whoever the ninja kernel maintainer happens to be at the
> time) says "hey i plan on stabilizing Linux x.y.z" and someone goes "wait,
> you cant until we get <closed source driver package foo> working", the reply
> is of course "blow it out your arse^H^H^H^Htalk to the package maintainer,
> this will not hold up stabilization efforts"
> -mike

They can always use the previous kernel version that worked too, it's
not like "OMG BBQ i'm not on the latest bleeding edge version!!1111one".

- --
Gustavo Zacarias
Gentoo/SPARC monkey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGs2nuV3G/IBCn/JARAsaeAJ9i+hH8cv16jRSlMLruC7X8jpG0lACbBxGi
N8lgqzbyJUxVokrhWeANtrg=
=MTXP
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Thu, 2007-08-02 at 20:35 -0700, Donnie Berkholz wrote:
> William L. Thomson Jr. wrote:
> > FYI, the patches in bug #183480 [1] allow one to use the most current
> > ati-drivers with a 2.6.22 kernel. As I am now while I am composing this
> > message. Having applied said patches and bumped ebuild locally. Just
> > needs to happen in tree :)
>
> 01 Aug 2007; Jeff Gardner <je_fro@gentoo.org>
> +files/8.37.6/fix-ioctl-for-2.6.22.patch, ati-drivers-8.37.6-r1.ebuild:
> Add patch to allow compilation with 2.6.22 kernels. See bug #182597.

Thanks, hope I didn't come off as bitching about it needing to be
committed. Just pointing it out :) But we are all good know, I should
have grown a pair and committed it myself :)

--
William L. Thomson Jr.
Gentoo/Java

On Fri, 2007-08-03 at 00:14 -0400, Mike Frysinger wrote:
> On Thursday 02 August 2007, William L. Thomson Jr. wrote:
> > On Thu, 2007-08-02 at 20:05 -0400, Mike Frysinger wrote:
> > > sounds good to me ... so to tie back to the source of the thread, crappy
> > > closed source vendor drivers are not a valid reason to hold up
> > > stabilization of a kernel
> >
> > Who ever said they were crappy? Maybe the documentation on usage is
> > crappy, but drivers have consistently gotten much better. These days
> > pretty solid IMHO for my uses.
>
> last time i used the drivers they sucked hard ... maybe it's gotten better; i
> dont know -- i tossed all my ati in favor of nvidia

Well ati's stuff has gotten much better over the last year. But really
IMHO from my experience. It's entirely about your xorg.conf. Wrong
config or etc and it will totally blow. In that regard nVidia seems to
be way more tolerant, and maybe detects stuff at runtime, ati requires
to be configed in xorg.conf.

> my point though wasnt to knock ati (although it was fun), the point was that i
> do not believe any closed source driver in our tree should ever be grounds
> for preventing stabilization of a kernel ebuild

Yes, I don't like that it's closed source either. But closed or open
source. It seems odd to have packages in our stable tree that don't work
with each other? Doesn't that kinda go against the point of our stable
tree?

I personally don't use genkernel, but I believe those updating their
systems via emerge world, and then running genkernel later against the
new kernel. Will likely have it fail, and then report bugs against our
stable tree.

--
William L. Thomson Jr.
Gentoo/Java

On Saturday 04 August 2007, William L. Thomson Jr. wrote:
> On Fri, 2007-08-03 at 00:14 -0400, Mike Frysinger wrote:
> > my point though wasnt to knock ati (although it was fun), the point was
> > that i do not believe any closed source driver in our tree should ever be
> > grounds for preventing stabilization of a kernel ebuild
>
> Yes, I don't like that it's closed source either. But closed or open
> source. It seems odd to have packages in our stable tree that don't work
> with each other? Doesn't that kinda go against the point of our stable
> tree?

then dont stabilize the closed source packages, problem solved

> I personally don't use genkernel, but I believe those updating their
> systems via emerge world, and then running genkernel later against the
> new kernel. Will likely have it fail, and then report bugs against our
> stable tree.

boy thats sure a pickle when we cant do s**t about it (maybe *this* time we
can fix it, but that is not always the case)
-mike

On Thu, 2007-08-02 at 20:35 -0700, Donnie Berkholz wrote:
>
> Update your knowledge, the normal radeon driver works nice for both. =)

I will I was following radeon developmen for a while. But last I looked
a few months ago, they were still a ways off from having DRI fully
supported with my hardware. Which is now ruffly 2-3 years old
Xpress200m. So I am sticking with ati-drivers, and only use radeon if
and when I have problems there. Which has been quite some time.

--
William L. Thomson Jr.
Gentoo/Java

Stephen P. Becker wrote:
> I will say that this is still a better situation than the closed
> drivers, which instantly hard lock my computer the first time I exit X
> after the initial startup.

Perhaps this might help you --
http://www.thinkwiki.org/wiki/Problems_with_fglrx#Hardlock_on_X_logout

Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth

On Sun, 05 Aug 2007 16:26:50 +0200
Jan Kundrát <jkt@gentoo.org> wrote:

> Stephen P. Becker wrote:
> > I will say that this is still a better situation than the closed
> > drivers, which instantly hard lock my computer the first time I
> > exit X after the initial startup.
>
> Perhaps this might help you --
> http://www.thinkwiki.org/wiki/Problems_with_fglrx#Hardlock_on_X_logout
>

Nope, I've been through all of that numerous times, read that page and
others, and nothing seems to help.

-Steve