The package works on my AMD64-platform very well - glxgears, fgl_glxgears and all that stuff works without any errors. Also, it should get unmasked ASAP because of that many new notebooks have the ATI Xpress 200-chipset and only 8.16.20 (or higher ;)) "know" this chipset!
Changing to ASSIGNED since I got a mail in which I could read that someone changed the topic and due to the fact that "Assigned to: AMD64 Porting Team" is stated above..
Please unmask on amd64. We have numerous reports of it working, and it works for me as well.
Excuse me if I'm wrong, but why do you change the status from "ASSIGNED" to "NEW"?!
It works great for me here too, I really think that this should have the ~amd64 keyword added. In many ways it works better on the newer cards and is a definite advantage.
(In reply to comment #3) > Excuse me if I'm wrong, but why do you change the status from "ASSIGNED" to "NEW"?! See the bugzilla help page This is the default behaviour when bugs are re-assigned (in this case re-assigned from amd64@g.o to lu_zero@g.o Jim
Oh, ok.. ;) But why did you re-assign it? - What does the guy (or woman?) behind "lu_zero@g.o" do? *** Changed bug to ASSIGNED *** (I hope, this is correct. :))
I got too many mixed experience about this driver and I cannot test it on amd64 for now. igp/xpress200 users could unmask it since this driver works fine just for them. since the issue got reported and hopefully corrected by upstream the next driver will solve the issues without causing major problems to the other users. If the amd64 team could test it a bit more and is confident that on amd64 it will work as should I have no problem in unmasking it. As I said I got too many mixed reports and on my x86 system the driver doesn't work.
(In reply to comment #7) > I got too many mixed experience about this driver and I cannot test it on amd64 > for now. > > igp/xpress200 users could unmask it since this driver works fine just for them. > > since the issue got reported and hopefully corrected by upstream the next driver > will solve the issues without causing major problems to the other users. > > If the amd64 team could test it a bit more and is confident that on amd64 it > will work as should I have no problem in unmasking it. As I said I got too many > mixed reports and on my x86 system the driver doesn't work. Well, could you explain some of these experiences so that I could test them on my AMD64-platform and then report it here? Doing so could IMHO speed up the procedure of getting the package into stable-status. :) Nevertheless, I still can't figure out why emerge keeps telling me about that 8.13.14-r5-package and wants to downgrade. - And yes, I got ">=media-video/ati-drivers-8.16.20-r1 -*" inside my /etc/portage/package.keywords-file.. So why doesn't emerge recognize this and stops to annoying me with this downgrade?! :(
It's masked as well as -* keyworded. It needs an entry in /etc/portage/package.unmask
(In reply to comment #9) > It's masked as well as -* keyworded. It needs an entry in > /etc/portage/package.unmask Just as I stated right above your comment: > And yes, I got ">=media-video/ati-drivers-8.16.20-r1 -*" > inside my /etc/portage/package.keywords-file.. And AFAIK, package.keywords takes priority above package.mask and package.unmask. But I've found out that the problem is not related to emerge directly.. - doing "emerge -uDav world" will recognize my package.keywords-file. The problem is related to kuroo which I'm mostly using..
No, package.mask and keywords are completely separate. You need both an unmasked package (either no entry in package.mask or an entry in package.unmask), *and* a keyword for the ebuild to emerge.
(In reply to comment #11) > No, package.mask and keywords are completely separate. You need both an > unmasked package (either no entry in package.mask or an entry in > package.unmask), *and* a keyword for the ebuild to emerge. Oh, then it's my fault. I'm really sorry for that. Anyway, excuse me, but isn't this a little bit senseless? - If I want to mask a package, I need *one* edit. But doing the other way takes *two* edits? This is not really locical - don't you think so, too? :) And I got another question: doing your way enables me to emerge the "ati-drivers"-package. But if I do so with the "ati-drivers-extra"-package emerge tells me something about (un-) masking?! I'd like to get the 8.16.20-version of that package and emerge won't let me - although I got it in package.unmask *AND* package.keywords! The same goes for the "xvidtune"-package.. :(
we're currently testing a new alias system, sorry for the bugspam
(In reply to comment #13) > we're currently testing a new alias system, sorry for the bugspam Excuse me, but what's the relation between my post above yours, the topic of this bug and your comment?! - I can't see on at all.. :(
(In reply to comment #14) > Excuse me, but what's the relation between my post above yours, the topic of > this bug and your comment?! - I can't see on at all.. :( It's related to the change from CC=amd64@gentoo.org to CC=amd64-test@gentoo.org.
(In reply to comment #15) > It's related to the change from CC=amd64@gentoo.org to CC=amd64-test@gentoo.org. Oops.. - I've missed that mail. Sorry.. :) But please: could you answer my questions in comment #12? - It's really annoying me and I can't emerge that package.. :(
no, since you didn't provide the exact "error" message. i'd suggest you read man portage to verify you've chosen the correct syntax for both files, i'm pretty sure it'll work then oh, and please don't discuss more than necessary in bugs reports, it makes them harder to read
(In reply to comment #17) > no, since you didn't provide the exact "error" message. i'd suggest you read man > portage to verify you've chosen the correct syntax for both files, i'm pretty > sure it'll work then > > oh, and please don't discuss more than necessary in bugs reports, it makes them > harder to read To paragraph 1: Well, the correct error message was (and even is) this: Masked by: missing keyword But in fact, I got ">=media-video/ati-drivers-extra-8.16.20 -*" inside both, package.keywords and package.unmask. So why is this still preventing me from emerging?! To paragraph 2: Of course, I will do so as good as I can - but the "ati-drivers-extra"-package is IMHO related to the "normal" "ati-drivers"-package, right? ;)
> But in fact, I got ">=media-video/ati-drivers-extra-8.16.20 -*" inside both that's why it doesn't work. there's currently no keyword, so you'll have to add it yourself. just create an overlay, copy the ebuild there, open it and change KEYWORDS to -* ~amd64
(In reply to comment #19) > that's why it doesn't work. there's currently no keyword, so you'll have to add > it yourself. just create an overlay, copy the ebuild there, open it and change > KEYWORDS to -* ~amd64 Oh, I'm sorry.. I didn't know that.. :) Anyway: I only know "overlay" in case of the directory for local ebuilds. Or did you mean this and I should download the available ebuild and move it to my overlay-directory for editing? Also (to come a bit more back to the main topic of this bug-report ;)), I'd like to know what's the progress of the ebuild-status? When will those drivers finally be at least "testing"-marked? :) And if you got a minute of free time: is there a way to become an AMD64-platform-tester and if so: how do I do this? :)
Check out http://www.gentoo.org/proj/en/base/amd64/tests/index.xml, then hop on #gentoo-amd64 and ping me (dang).
(In reply to comment #21) > Check out http://www.gentoo.org/proj/en/base/amd64/tests/index.xml, then hop on > #gentoo-amd64 and ping me (dang). Thanks a lot.. - I'm going to read it at the weekend.. :)
8.18.6 in portage as ~, please test
Works without any bugs since more than 4 weeks now - also with games (UT-GOTY in my case ;))..
