Catalyst 8.12 in debian lenny

[the-me]

Just in - The backporting info in debian/README.Debian is not applicable!
After extracting the 8.12 fglrx I went to /usr/src/fglrx/packages/Debian/dists/lenny but the backport instructions don't seem to match the contents. For starters there is no x740 referenced and neither is libglx.so in the preinst. The backport instructions in that README might be valid for something, but definitely not for fglrx 8.12 under Lenny.

It is.

$ apt-get source fglrx-driver
$ cd fglrx-driver....

There you will find the content and for backporting you have to rebuild the package after this.
And you do not need them because it will enter lenny..

[nbi1]

It is.

$ apt-get source fglrx-driver
$ cd fglrx-driver....

There you will find the content and for backporting you have to rebuild the package after this.
And you do not need them because it will enter lenny..

Ok, so I need to add the experimental repository and temporarily disable the main repository so that 8.12 source is retrieved rather than 8.7.3? Any way to do this without modifying etc/apt/sources.list?

Apparently not.

The good news is I managed to acquire the correct fglrx-driver package and it seemed to make the backport modifications upon installation (I guess the pre/post routines figured out a lenny target is requested).

Now how do I "rebuild the package"? There is no "packager" shell script anywhere except in the fglrx extracted from the ATI installer. I even searched all sid fglrx packages for the "packager", but could not find one. Also, what about all the other fglrx packages? Use the binary packages or rebuild from source?

I experimented by installing all the sid fglrx packages via Synaptic, but that results in an unusable configuration as before. Evidently I'm not building correctly. Please be very explicit in explaining what you mean by "rebuild the package". Thanks.

[xaros]

^^ Run "debuild -us -uc" in the fglrx-driver directory . You can use that to build any valid debian package.

[nbi1]

^^ Run "debuild -us -uc" in the fglrx-driver directory . You can use that to build any valid debian package.

Thanks, but that doesn't look like an option. Marking 'devscripts' for install threatens to remove a lot of gnome components and I happen to use gnome.

Just in - I take that back. There was something wrong with the package system. Some package installations were broken. I managed to fix that and was able to successfully build packages using 'debuild'. Now I just need to install and test the debian version of fglrx.

[nbi1]

Nope, it simply will not work. Same problems as my post dated 01-09-2009, 12:03 AM. The fglrx from Catalyst 8.12 is not usable in 64 bit Lenny.

[the-me]

Nope, it simply will not work. Same problems as my post dated 01-09-2009, 12:03 AM. The fglrx from Catalyst 8.12 is not usable in 64 bit Lenny.

It will work. As I noted again and again just wait until 8-12 is in _LENNY_, not experimental stable etc...

http://qa.debian.org/excuses.php?package=fglrx-driver there you will see when it will enter it, now just wait before you break your system.

[nbi1]

It will work. As I noted again and again just wait until 8-12 is in _LENNY_, not experimental stable etc...

http://qa.debian.org/excuses.php?package=fglrx-driver there you will see when it will enter it, now just wait before you break your system.

What do you mean by "it will work"? Please spare us the speculation. If you know firsthand that it does work then clearly say so, otherwise you simply don't know (in which case your earlier posts were wasting my time along with everyone else's).

People - regardless of how close you might be to the development and/or distro packaging process please don't offer speculation as a solution. There are a lot of details to get right in resolving these driver issues. What may seem obvious to you isn't necessarily obvious to the rest of us.

I certainly welcome insights, but when I'm willing to roll up my sleeves and dig in I don't want to be sent on a wild goose chase.

[the-me]

What do you mean by "it will work"? Please spare us the speculation. If you know firsthand that it does work then clearly say so, otherwise you simply don't know (in which case your earlier posts were wasting my time along with everyone else's).

People - regardless of how close you might be to the development and/or distro packaging process please don't offer speculation as a solution. There are a lot of details to get right in resolving these driver issues. What may seem obvious to you isn't necessarily obvious to the rest of us.

I certainly welcome insights, but when I'm willing to roll up my sleeves and dig in I don't want to be sent on a wild goose chase.

Do not think that I am aggressive against you in any case. In this case I noted that fglrx 8-12 will be in the Lenny release and that you might backport it for your PC until it enters it (which takes some days).
Then I saw that you do not know how Debian packaging works (no problem, you do not have to ), so it is better in my opinion, that you live a few more days with those issues, instead of breaking maybe your whole system - I do not think that you or I want this, or not?

[nbi1]

Do not think that I am aggressive against you in any case. In this case I noted that fglrx 8-12 will be in the Lenny release and that you might backport it for your PC until it enters it (which takes some days).
Then I saw that you do not know how Debian packaging works (no problem, you do not have to ), so it is better in my opinion, that you live a few more days with those issues, instead of breaking maybe your whole system - I do not think that you or I want this, or not?

The system in question is a new install and not my production system. So it can be broken (within reason, I don't want to completely reinstall on every problem) due to experimentation. The ultimate goal is to have a working (as in meeting basic video requirements) Debian or Ubuntu platform. Then I can begin migrating away from etch towards this platform.

Don't know what you mean by "how Debian packaging works". I'm fluent with dpkg and apt-get. I can also build .debs. If you're referring to the decision making utilized by Debian packagers (the folks chartered with creating packages) you are correct, I don't know how it works. I neither want to nor should I need to. What matters is whether or not available packages lend themselves towards solving a problem.

Your advice to wait is certainly safe, but it doesn't solve any problems. And in the case of Debian it might not for another 6 months or so and that would be unacceptable. Again, I have no problem with building my own version, but the recipe(s) I'm given need to be sound.

[00marcus]

[QUOTE=Kano;58419]@nbi1

For standard cards (not new chips with extra AGP connector) 2.6.28 works with fglrx not better or worse than other kernels.

Are you saying that the current lenny (or even selfmade) packages will NOT work for 2.6.28 and AGP cards (radeon HD-3650 in my case)?

Which kernel would you recommend?

M