[arch-dev-public] New fglrx drivers - no official package.
Hey guys. AMD's released their new radeon drivers, which are a complete rewrite. Exciting times, however AMD warns that these might not be production ready. After a bit of thought, I've decided to keep the 8.40.4 drivers in the repos for now (especially since this new release doesn't add kernel 2.6.23 or xorg 7.3 support) but make a custom repo for the new drivers for those who want to experiment. In the spirit of not doing things unilaterally, I'm notifying you all here. If there's no objection, I'll be posting an advisory to the forums later (maybe tonight or tomorrow) that will say essentially the following: -8<---8<---8<---8<---8<---8<---8<---8<-- Hi everyone, Today, AMD's 8.41.7 fglrx drivers, which are a complete rewrite of their codebase which they have spent more than a year of work on, were released today. On their release notes page, they offer the following recommendation: [quote]Caution: AMD recommends that this release of the AMD Proprietary Linux software driver not be used for distribution packages. Distributors should continue to use the AMD Proprietary Linux driver version 8.40.4[/quote] After some thought, I've decided to take this warning to heart, and will not be packaging this version of the drivers 'officially'. HOWEVER, tonight or possibly tomorrow I will be making packages for these drivers and a custom repo to obtain them from if you wish to test them out - these will not be 'official' archlinux packages, however, and the 8.40.4 release will remain in the repos until AMD releases a new version which they feel is suitable for general use. I will update this advisory once the new packages are available, and hope you all understand my reasoning on this. -8<---8<---8<---8<---8<---8<---8<---8<-- Any thoughts or suggestions, just reply to this thread. :) Thanks, Travis
2007/9/12, Travis Willard <travis@archlinux.org>:
Today, AMD's 8.41.7 fglrx drivers, which are a complete rewrite of their codebase which they have spent more than a year of work on, were released today.
There's two "today" in once sentence. ;-)
Any thoughts or suggestions, just reply to this thread. :)
Otherwise seems good to me. -- Roman Kyrylych (Роман Кирилич)
In the spirit of not doing things unilaterally, [...]
THANK YOU! Just for that, you get a cookie! http://img.phraktured.net/funny/bunnycookie.jpg Jason
On Wed, 12 Sep 2007 11:36:02 -0400 "Travis Willard" <travis@archlinux.org> wrote:
Any thoughts or suggestions, just reply to this thread. :)
Actually, anyone have any issues with my putting them in unstable? That seems to make the most sense, after thinking about it. If there's no comments in the next 12h or so I'll go ahead and upload them - I don't think there'll be much of a problem with it. -- Travis
Travis Willard wrote:
On Wed, 12 Sep 2007 11:36:02 -0400 "Travis Willard" <travis@archlinux.org> wrote:
Any thoughts or suggestions, just reply to this thread. :)
Actually, anyone have any issues with my putting them in unstable? That seems to make the most sense, after thinking about it.
If there's no comments in the next 12h or so I'll go ahead and upload them - I don't think there'll be much of a problem with it.
-- Travis
Uh, an observation. I've always understood that unstable package names should not clash with names in other repos - hence, mplayer-svn, gimp-devel, etc. This is certainly what we say on the relevant wiki page: http://wiki.archlinux.org/index.php/Official_Repositories and it is also this convention that allows us to state, also on that page, that enabling the unstable repo is safe, because unstable packages will never overwrite current/extra packages. Finally, it allows those who decide to use unstable to install the packages with the standard pacman -Sy foo, rather than the slightly clunkier pacman -Sy repo/foo. Sorry I missed the 12h cut-off, btw - all kinds of crap going wrong around here. :) Tom.
On Sat, 15 Sep 2007 09:04:06 +0100 Tom K <tom@archlinux.org> wrote:
Travis Willard wrote:
On Wed, 12 Sep 2007 11:36:02 -0400 "Travis Willard" <travis@archlinux.org> wrote:
Any thoughts or suggestions, just reply to this thread. :)
Actually, anyone have any issues with my putting them in unstable? That seems to make the most sense, after thinking about it.
If there's no comments in the next 12h or so I'll go ahead and upload them - I don't think there'll be much of a problem with it.
-- Travis
Uh, an observation. I've always understood that unstable package names should not clash with names in other repos - hence, mplayer-svn, gimp-devel, etc. This is certainly what we say on the relevant wiki page: http://wiki.archlinux.org/index.php/Official_Repositories and it is also this convention that allows us to state, also on that page, that enabling the unstable repo is safe, because unstable packages will never overwrite current/extra packages. Finally, it allows those who decide to use unstable to install the packages with the standard pacman -Sy foo, rather than the slightly clunkier pacman -Sy repo/foo.
Sorry I missed the 12h cut-off, btw - all kinds of crap going wrong around here. :)
Tom.
Yeah, Eric emailed me directly about this - I guess I bungled that. I'll think up a fancy name for the unstable packages and re-do 'em. -- Travis
On Sat, 15 Sep 2007 21:14:52 -0400 Travis Willard <travis@archlinux.org> wrote:
On Sat, 15 Sep 2007 09:04:06 +0100 Tom K <tom@archlinux.org> wrote:
Travis Willard wrote:
On Wed, 12 Sep 2007 11:36:02 -0400 "Travis Willard" <travis@archlinux.org> wrote:
Any thoughts or suggestions, just reply to this thread. :)
Actually, anyone have any issues with my putting them in unstable? That seems to make the most sense, after thinking about it.
If there's no comments in the next 12h or so I'll go ahead and upload them - I don't think there'll be much of a problem with it.
-- Travis
Uh, an observation. I've always understood that unstable package names should not clash with names in other repos - hence, mplayer-svn, gimp-devel, etc. This is certainly what we say on the relevant wiki page: http://wiki.archlinux.org/index.php/Official_Repositories and it is also this convention that allows us to state, also on that page, that enabling the unstable repo is safe, because unstable packages will never overwrite current/extra packages. Finally, it allows those who decide to use unstable to install the packages with the standard pacman -Sy foo, rather than the slightly clunkier pacman -Sy repo/foo.
Sorry I missed the 12h cut-off, btw - all kinds of crap going wrong around here. :)
Tom.
Yeah, Eric emailed me directly about this - I guess I bungled that. I'll think up a fancy name for the unstable packages and re-do 'em.
Bah, the more I think about this, the less I want to pollute the package namespace (and replaces, conflicts, provides entries on fglrx* packages) with some gimpy name like fglrx-unstable, and I'd rather just make a custom repo and be done with it. "Early-adopters" have had their shot at a package in unstable. ;) Is it OK if I host a custom repo for the new fglrx in my public_html dir on gerolde? I don't have any better place to put it. -- Travis
Bah, the more I think about this, the less I want to pollute the package namespace (and replaces, conflicts, provides entries on fglrx* packages) with some gimpy name like fglrx-unstable, and I'd rather just make a custom repo and be done with it. "Early-adopters" have had their shot at a package in unstable. ;)
Is it OK if I host a custom repo for the new fglrx in my public_html dir on gerolde? I don't have any better place to put it.
Hmm... I guess it depends on how much usage you expect it to get. If you are expecting alot of bandwidth to be used, then we could probably put it in the ftp folder under /other/. Please don't put it in the root of ftp though.. However, I really think unstable is the right place to put packages that need testing though. I mean... what else will it be used for if not for new packages to test? What benefit does a custom folder have over unstable?
2007/9/16, eliott <eliott@cactuswax.net>:
Bah, the more I think about this, the less I want to pollute the package namespace (and replaces, conflicts, provides entries on fglrx* packages) with some gimpy name like fglrx-unstable, and I'd rather just make a custom repo and be done with it. "Early-adopters" have had their shot at a package in unstable. ;)
Is it OK if I host a custom repo for the new fglrx in my public_html dir on gerolde? I don't have any better place to put it.
Hmm... I guess it depends on how much usage you expect it to get.
If you are expecting alot of bandwidth to be used, then we could probably put it in the ftp folder under /other/. Please don't put it in the root of ftp though..
However, I really think unstable is the right place to put packages that need testing though. I mean... what else will it be used for if not for new packages to test?
What benefit does a custom folder have over unstable?
They are not CVS/SVN/etc. version. /me wonders - why don't put them in Testing? -- Roman Kyrylych (Роман Кирилич)
On Sun, 16 Sep 2007 12:05:15 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
2007/9/16, eliott <eliott@cactuswax.net>:
Bah, the more I think about this, the less I want to pollute the package namespace (and replaces, conflicts, provides entries on fglrx* packages) with some gimpy name like fglrx-unstable, and I'd rather just make a custom repo and be done with it. "Early-adopters" have had their shot at a package in unstable. ;)
Is it OK if I host a custom repo for the new fglrx in my public_html dir on gerolde? I don't have any better place to put it.
Hmm... I guess it depends on how much usage you expect it to get.
If you are expecting alot of bandwidth to be used, then we could probably put it in the ftp folder under /other/. Please don't put it in the root of ftp though..
However, I really think unstable is the right place to put packages that need testing though. I mean... what else will it be used for if not for new packages to test?
What benefit does a custom folder have over unstable?
Well, unstable names aren't supposed to clash with names in extra - if they stay in unstable, I need to rename them. I'd rather not make up some gimpy name for them, because then I'd have to add that to replaces and conflicts in the next release of the drivers that went to [extra], which is kinda ugly for a one-shot thing. A custom repo'd allow me to use the same names.
They are not CVS/SVN/etc. version. /me wonders - why don't put them in Testing?
Well, I suppose it could work - but they'd never leave testing, so it seems kind of odd I guess. Thinking about it, I suppose that would make the most sense if I wanted it in one of the 'official' repos. Also, if I were to put them into testing, I'd have to do a CVS checkin into [extra], and I'm not sure where we stand with checkins to extra yet due to the core repo stuff. -- Travis
participants (5)
-
eliott
-
Jason Chu
-
Roman Kyrylych
-
Tom K
-
Travis Willard