There is no reason for xf86-video-newport to have ~amd64, ~ia64, ~sh, and ~x86 entries in KEYWORDS. This is a clear QA violation, since it is 100% impossible for these arches to have tested this driver. The only devices in existence on which this driver could possibly work are mips.
Stephen, I don't personally think it's necessary to call out the QA violation. Clearly arches are adding ~keywords based on compilation tests for the various modular X drivers. IMHO that's a reasonable expectation for this migration. If you can authoritatively say that this is a mips-only driver (and it sounds like you can) then please go ahead and remove ~ia64. Additionally it would be good to prepend -* to KEYWORDS (since that is supposed to be an indicator to arch devs) and also to change the DESCRIPTION to reflect the nature of this driver. Of the arches in KEYWORDS, I can only speak for ia64, I guess the other arch teams can chime in their agreement/disagreement
http://ftp.x.org/pub/X11R7.0/doc/html/newport.4.html According to the documentation, geoman is right. ~x86 should be pulled as well.
(In reply to comment #1) > Stephen, I don't personally think it's necessary to call out the QA violation. > Clearly arches are adding ~keywords based on compilation tests for the various > modular X drivers. IMHO that's a reasonable expectation for this migration. I have to strongly disagree with you here. We aren't talking about something which should (theoretically) universally work such as xterm, or even the X server itself. Drivers are a very special case, and blindly keywording them ~arch based on the fact that it compiles is a serious QA violation in my opinion. For example, I have been extremely careful to only keyword those drivers ~mips which are known to work on mips, and which I can actually test. This isn't the only case where this is a problem either. Ciaran pointed out that the nv driver had ~sparc (among some others that probably shouldn't be there), and I just noticed that many of the Sun specific drivers had ~x86 and ~amd64. You might come back with the "so what, it is only for migration to modular" purposes, however what happens when these arches start marking things stable once the 30 day limit has passed? The main reason I called everyone out on the newport driver is that I know for a fact that there is no other hardware than certain SGI workstations which support this card. I can't say for certain on some of the other drivers. > If you can authoritatively say that this is a mips-only driver (and it sounds > like you can) then please go ahead and remove ~ia64. Additionally it would be > good to prepend -* to KEYWORDS (since that is supposed to be an indicator to > arch devs) and also to change the DESCRIPTION to reflect the nature of this > driver. Might not be a bad idea. What do the X folks think?
(In reply to comment #3) > What do the X folks think? What do the X folks think about what? This is an arch issue. I'm sure the X folks will be quite happy if the arch teams can just sort it out. Based on the doc halcy0n pointed out, it's clear this ebuild should just be fixed up. I'll go ahead and do the following sometime in the next couple days if nobody has an issue with it: ekeyword ^all -* ~mips *.ebuild sed -i '/^DESC/s/"$/ (mips only)"/' *.ebuild echangelog "Driver is mips-only, remove bogus keywords, update DESCRIPTION #127028" repoman commit -m !$
Good idea. The only reason everything is ~x86 is because I refuse to add anything to the tree without at least compile-testing it. (Although there should be very few drivers that don't work on x86, probably just this and sun*.)
I just went ahead and fixed newport (and sun*) because I want to unmask this soon instead of waiting a couple days. I'll do something about nv later, it will require quite a few changes to the xorg-x11 ebuild because it's one of the 5-6 drivers that were assumed ubiquitous.
