The user's arguments "I don't want to break my system" and "I don't like the idea of running unstable packages" made me smile, you know :)

I thought you guys were dealing with users with a more than average IQ.

I wrote some page for Gentoo Wiki with evaluates some stable XMMS replacements. The situation doesn't look very good at the moment, but I think it will improve.

http://gentoo-wiki.com/Xmms_replacement

> If they can't handle criticism maybe they should quit.

All Gentoo developers are volunteers, as I have said many times. People don't volunteer to be flamed by users who can't be bothered to contribute themselves and just want developers to cater to their every need. People should be thanking people like Flameeyes for all the work he does for free rather than flaming him.

If Gentoo developers quit every time someone criticized them, or they quit whenever some belligerent asshole pissed them off, there would be no Gentoo developers and hence no Gentoo.

If they can't handle criticism maybe they should quit.

As long as bug #152890 is sorted, I'm happy. (-:

No, it's at 8.

err...7 PM.

> The Gentoo BOFS at the Ottawa Linux Symposium will be taking place at 8:00PM in Room "A".

What day, Friday or today?

Info on the Linux Symposium: http://www.linuxsymposium.org/2006/
I'll be attending and I'm willing to help in any way needed.

For some reason this post has been getting a lot of comment spam lately so I am closing comments here.

There is nothing I can do than to agree with Patrick McLean's comments!!!!

BTW, thanks for the info on what packages to mask.

> Then perhaps Xorg, et al. might concentrate their efforts on
> providing open source drivers that are as fast as their
> closed source counterparts.

Sure, everyone would love to, dig in if you can help. Obviously some kind of info about how the hardware works would be helpful, or even some old driver code.

*other whining about breakage*

Don't run ~arch then, you should know the risks. If you didn't before, you do now...

> Then perhaps Xorg, et al. might concentrate their efforts on
> providing open source drivers that are as fast as their
> closed source counterparts.

Video card companies don't provide any documentation on writing drivers. It's almost impossible to write a good video driver, the only reason the r300 project got anywhere is because they had a starting point (older, supported ATI cards). The "nv" driver is little better than binary code and was written by nvidia.

We would have excellent open source drivers, if companies actually provided documentation on how to write decent drivers.

> I don't think any open source project should be forced to hold back their
> development simply because some hardware company refuses to release open source
> drivers or at least specifications.

Then perhaps Xorg, et al. might concentrate their efforts on providing open source drivers that are as fast as their closed source counterparts.

>> insert your favorite meaningless, mealy-mouthed open source advocacy here

bleh -- I mean ">=" changed to "<".

Maybe it's just me, but it seems inelegant to *unmask* all those Xorg deps and then *remask* the 7.1 ones. Why not just put Patrick's list of atoms in package.keywords (with ">=" changed to "

I just commented out nvidia in the make.conf video cards section.. oh wait.. I also switched to the nv driver.. and I'm also typing this message on the same machine.. just booted to windows... :(

I think it wouldn't be that much harder to have a more in-depth requirements list, something other than a "hard block", or hard upgrade...

I should be able to specify my world file, my make.conf, and be done with it.

So, yes.. it was good that we got bit while it was in ~arch. Next, we need to find a way to make ourselves not get bit again.

We should very rarely come across a block because of a newer version loosing compatibility. We should have a note: can't upgrade these packages until fat-arse over there gets off his butt, upgrade everything else? y/n

Oh wait... portage will not be interactive by design... and I'm thinking of Debian apt or BSD ports...

interactive ain't bad... it should just take place in one sitting and build... download the options list, go through a wizard, have the wizard check for things that will break, then download and compile everything.

-AP

There is no reason why the company needs a fully updated driver, they simply need to recompile the current driver against the current X.org release.

nVidia and ATI are dragging their feet most likely because they simply don't care all that much about the open source world, it represents a small percentage of their market hence they don't see a reason to put a lot of work into supporting it.

Also, the new X.org release currently affects ~arch users, who (should) know they are running packages that may break. If you want a system that never breaks, you should not be running ~arch. There is also the fact the open source drivers still work, there is no reason that they can't use the "nv" driver if they absolutely must run a full ~arch system. This was not an "error", the X team knew full well that there were no proprietary drivers for the new X release when they unmasked it.

Hi,
thanks for your post. It helped.

>I don't think any open source project should be forced to hold back >their development simply because some hardware company refuses to >release open source drivers or at least specifications.

I can't agree with that. It is not the issue whether some one is forced to do something in this case. With this action hardware companies are maybe also forced now to release their drivers earlier. Is that okay? I guess they have reasons for for their later driver delivery.
The point is that an emerge -uD world leaves an incurrupt system on my machine and my xserver is not running correct anymore. That is just an error and don't looks like high-quality. Well shit happens it is okay but please don't try to legitimate it.
I think for the next time it would be better to put it into ~arch after nvidia/ati has driver for it.

Kevin, I mask everything that deps on the new xorg-x11 to avoid the upgrade/downgrade cycles that sometimes crop up.