woody packages on potato systems (was: Upgrading to Xfree 4.01)
Hm. I have a woody system, so that's not really important for me, but.. Seth Arnold <[EMAIL PROTECTED]> writes: > Emmanuel, 4.0.1 is *not* for potato. If you want to run 4.0.1 on potato, > please search for Charl P. Botha's packages built for potato. Shouldn't all Debian-Packages work always as long as their dependencies are fulfilled? (At least any Debian System should be upgradeable with a simple "apt-get dist-upgrade" from the previous version. Or am I wrong in this point!?) > If things break, recognize that is because 4.0.1 was *never meant* for > potato. If it works, then it is magic. If it breaks, that is to be > expected. My opinion is: If it breaks, the dependencies where not correct. If it's really as Seth says, it would mean that it's impossible (or pure luck) to use a mixture of a stable/unstable Debian system. I used to do this for a long time with slink/potato, however. Sometimes there were problems because Debian unstable is unstable. But usually all those difficulties were fixed after a few days by doing a fresh "apt-get install". [The price to install a woody-XF4.0.1 on a potato is machine is at least a new libc6, of course. So if you don't want to upgrade libc6, you should definitely use Charl P. Botha's potato packages.] jojo P.S.: Maybe this should be discussed on debian-devel!? -- Quitting vi is the most important command of that editor, and should be bound to something easy to type and available in all modes, for example the space bar. -- Per Abrahamsen
woody packages on potato systems (was: Upgrading to Xfree 4.01)
Hm. I have a woody system, so that's not really important for me, but.. Seth Arnold <[EMAIL PROTECTED]> writes: > Emmanuel, 4.0.1 is *not* for potato. If you want to run 4.0.1 on potato, > please search for Charl P. Botha's packages built for potato. Shouldn't all Debian-Packages work always as long as their dependencies are fulfilled? (At least any Debian System should be upgradeable with a simple "apt-get dist-upgrade" from the previous version. Or am I wrong in this point!?) > If things break, recognize that is because 4.0.1 was *never meant* for > potato. If it works, then it is magic. If it breaks, that is to be > expected. My opinion is: If it breaks, the dependencies where not correct. If it's really as Seth says, it would mean that it's impossible (or pure luck) to use a mixture of a stable/unstable Debian system. I used to do this for a long time with slink/potato, however. Sometimes there were problems because Debian unstable is unstable. But usually all those difficulties were fixed after a few days by doing a fresh "apt-get install". [The price to install a woody-XF4.0.1 on a potato is machine is at least a new libc6, of course. So if you don't want to upgrade libc6, you should definitely use Charl P. Botha's potato packages.] jojo P.S.: Maybe this should be discussed on debian-devel!? -- Quitting vi is the most important command of that editor, and should be bound to something easy to type and available in all modes, for example the space bar. -- Per Abrahamsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mesa Problem?
Travis Whitton <[EMAIL PROTECTED]> writes: > I'm using linux 2.4.0-test8 with DRI support and the r128 module(for my > Rage 128 card). Whenever I run any Mesa based applications, they flicker > constantly and improperly render certain parts of the screen. A good > example of this behavior can be seen by running any of the xlock GL > hacks. Same here. If your run (for example) gears as screen saver it looks like the back buffer is displayed instead of the front buffer. (Something like this :) gears in a window looks fine, is fast and doesn't flicker. > Branden, I know that these packages aren't for general use, and that this > problem probably falls somewhere in the "low priority" section. I also > understand that you're very busy, so I don't expect this to be fixed > right away. ACK. jojo -- Quitting vi is the most important command of that editor, and should be bound to something easy to type and available in all modes, for example the space bar. -- Per Abrahamsen
Re: Mesa Problem?
Travis Whitton <[EMAIL PROTECTED]> writes: > I'm using linux 2.4.0-test8 with DRI support and the r128 module(for my > Rage 128 card). Whenever I run any Mesa based applications, they flicker > constantly and improperly render certain parts of the screen. A good > example of this behavior can be seen by running any of the xlock GL > hacks. Same here. If your run (for example) gears as screen saver it looks like the back buffer is displayed instead of the front buffer. (Something like this :) gears in a window looks fine, is fast and doesn't flicker. > Branden, I know that these packages aren't for general use, and that this > problem probably falls somewhere in the "low priority" section. I also > understand that you're very busy, so I don't expect this to be fixed > right away. ACK. jojo -- Quitting vi is the most important command of that editor, and should be bound to something easy to type and available in all modes, for example the space bar. -- Per Abrahamsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tried X 4 - doesn't work
Jean-Philippe Guerard <[EMAIL PROTECTED]> writes: > I am trying to set up X 4, but the xf86cfg > program end up with an error message, It seems I have exactly the same problem here. At least my log output from xf86cfg is almost identical to yours: Many unresolved symbols in .../modules/drivers/tdfx_drv.o and--just before the end of the file-- these lines: | This should not happen! | An unresolved function was called! | | Fatal server error: | | | Are there any known problems with Voodoo3 video cards (I've got a Voodoo3 2000) that could have something to do with it? Or do I (we) need some extra 3dfx-related files in addition to the phase2v4-debs? TIA jojo -- Okay, Okay -- I admit it. You didn't change that program that worked just a little while ago; I inserted some random characters into the executable. Please forgive me. You can recover the file by typing in the code over again, since I also removed the source.
Re: Tried X 4 - doesn't work
Jean-Philippe Guerard <[EMAIL PROTECTED]> writes: > I am trying to set up X 4, but the xf86cfg > program end up with an error message, It seems I have exactly the same problem here. At least my log output from xf86cfg is almost identical to yours: Many unresolved symbols in .../modules/drivers/tdfx_drv.o and--just before the end of the file-- these lines: | This should not happen! | An unresolved function was called! | | Fatal server error: | | | Are there any known problems with Voodoo3 video cards (I've got a Voodoo3 2000) that could have something to do with it? Or do I (we) need some extra 3dfx-related files in addition to the phase2v4-debs? TIA jojo -- Okay, Okay -- I admit it. You didn't change that program that worked just a little while ago; I inserted some random characters into the executable. Please forgive me. You can recover the file by typing in the code over again, since I also removed the source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
