Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: * Marcelo E. Magallon [EMAIL PROTECTED] [001212 16:39]: [...] and Utah's has some advantages for some people. And the one person who has seemed to be effected thus far did not take the time and effort to put his packages on hold. :-P Why should he? Package: libutahglx1 Replaces: libgl1 Provides: libgl1 Depends: libc6 (= 2.1.2), xlib6g (= 3.3.6-4) Recommends: utah-glx Package: utah-glx Depends: xserver, libc6 (= 2.1.2) Recommends: libutahglx1 Conflicts: xfree86-common(=4.0) Package: xfree86-common Suggests: xserver-xfree86 | xserver apt found a solution for the upgrade, and given the information above it probably meant deinstalling xserver-svga in favour of xserver-xfree86. This is probably a bug in utah-glx. But the question still remains: why should a user put packages on hold before an upgrade? He's got a working configuration, and AFAICS it's possible to keep it. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Marcelo E. Magallon [EMAIL PROTECTED] [001213 00:21]: But the question still remains: why should a user put packages on hold before an upgrade? He's got a working configuration, and AFAICS it's possible to keep it. Using the -u flag with apt would have saved him as much as using = in dselect. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: * Marcelo E. Magallon [EMAIL PROTECTED] [001213 00:21]: But the question still remains: why should a user put packages on hold before an upgrade? He's got a working configuration, and AFAICS it's possible to keep it. Using the -u flag with apt would have saved him as much as using = in dselect. You are missing the point. His problems as a side issue. Problems with unstable are to be expected. The question is if there's a bug with xf4/xf3.3/utah-glx packages in woody. You seem to forget this is not a user's list. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Marcelo E. Magallon wrote: As the gtkglarea maintainer (and since you hinted it's the OpenGL subsystem what broke) I feel this is somehow my fault... could you please elaborate on this? It seems to be that gtk depends on X 4.0.1+, and that caused my working xserver to be purged and replaced. Still, I want to be able to use 3.3.6-18 and utah packages for G400 and G200 - and they're not in woody anymore. My gripe is that I can't do a new install of 3.3 and utah on any machine, or even ( by using debian ) replace the xserver and libs I lost. cheers, Terry -- --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Death is running Debian GNU/Linux| ---
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold wrote: Compared against Utah, at least the last time I looked at it, this is really pretty quick and easy. Whether or not the features supported by Utah are imporant enough to justify the work involved with getting it to go is entirely dependent upon the applications one needs to run. For me, I never missed the features. For mongoose (terry?), he obviously misses the features of Utah, but not enough to ensure they wouldn't be overwritten. So, it is your stance that you will not support cards without DRI drivers - and only support 3d cards by their DRI drivers only? People shouldn't be artificial limited like that from my view. If this was about quick and easy and using drivers that weren't fully functional, then I could be running NT. This is about a policy change that wasn't well thought. Some people will need utah for some time, and not allowing new installs of xservers to support utah seems to artifically impose huge hurtles for users and shops alike. cheers, Terry -- --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Death is running Debian GNU/Linux| ---
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: * Marcelo E. Magallon [EMAIL PROTECTED] [001212 16:39]: [...] and Utah's has some advantages for some people. And the one person who has seemed to be effected thus far did not take the time and effort to put his packages on hold. :-P Why should he? Package: libutahglx1 Replaces: libgl1 Provides: libgl1 Depends: libc6 (= 2.1.2), xlib6g (= 3.3.6-4) Recommends: utah-glx Package: utah-glx Depends: xserver, libc6 (= 2.1.2) Recommends: libutahglx1 Conflicts: xfree86-common(=4.0) Package: xfree86-common Suggests: xserver-xfree86 | xserver apt found a solution for the upgrade, and given the information above it probably meant deinstalling xserver-svga in favour of xserver-xfree86. This is probably a bug in utah-glx. But the question still remains: why should a user put packages on hold before an upgrade? He's got a working configuration, and AFAICS it's possible to keep it. -- Marcelo
Re: [mongoose@users.sourceforge.net: X upgrade policy]
[Don't Cc me, I'm on the list] Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] writes: It seems to be that gtk depends on X 4.0.1+, and that caused my working xserver to be purged and replaced. Still, I want to be able to use 3.3.6-18 and utah packages for G400 and G200 - and they're not in woody anymore. My gripe is that I can't do a new install of 3.3 and utah on any machine, or even ( by using debian ) replace the xserver and libs I lost. You might want to look in /var/backups/dpkg.status.* in order to figure out what pulled the new X server in. Most people complain because this doesn't happen automatically. My first guess would be task-x-window-system-core. At any rate, it can't be libgtk1.2 itself. You might want to take this with the utah-glx maintainer, because it seems it's not possible to install utah-glx on woody right now: ysabell:/home/marcelo# apt-get install utah-glx Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: Sorry, but the following packages have unmet dependencies: utah-glx: Depends: xserver E: Sorry, broken packages xlibs is a different issue. The short version: that's ok. HTH, -- Marcelo
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Marcelo E. Magallon [EMAIL PROTECTED] [001213 00:21]: But the question still remains: why should a user put packages on hold before an upgrade? He's got a working configuration, and AFAICS it's possible to keep it. Using the -u flag with apt would have saved him as much as using = in dselect. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: * Marcelo E. Magallon [EMAIL PROTECTED] [001213 00:21]: But the question still remains: why should a user put packages on hold before an upgrade? He's got a working configuration, and AFAICS it's possible to keep it. Using the -u flag with apt would have saved him as much as using = in dselect. You are missing the point. His problems as a side issue. Problems with unstable are to be expected. The question is if there's a bug with xf4/xf3.3/utah-glx packages in woody. You seem to forget this is not a user's list. -- Marcelo
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, 12 Dec 2000, Terry 'Mongoose' Hendrix II wrote: Who uses dselect anymore? Call me "Mr. Stone-age", but I do still use dselect sometimes. This is about a package maintianers *duty to account for _likely conflicts_. Ok, this gets me a bit upset. There are always unforeseen (or just plain forgotten-about) conflicts that come up. I've been guilty myself of uploading packages that turned out to have horrid bugs in them (which I quickly corrected, but never heard the end of it), but no maintainer that I know purposely releases something maliciously to wreck a user's setup. Also, you seem to forget that us Debian maintainers are VOLUNTEERS. I have sacrificed quite a bit to this project in general, and have spent countless cpu cycles trying to make sure that the new X packages worked well on Alpha (including over 36 hours of patching so far). To say that I have a *duty* to do this is moderately insulting since this work has taken time away from my family, my hobbies, and my other interests. From your argument, if I happen to upload a bad package before going on holiday, I should be flamed to death C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Hi all, Why have you made the upgrade path in X impossible? You can't run utah on 4.0 - yet you blindly install 4.0 over every system by dependcies. You don't even bother checking /proc to see what card is installed. A simple grep of /proc/pci shows I have an AGP G400, not a V3! I have a machine that has half 3.3.6-18 and 4.0 installed now - and I had the utah package installed! You should check for utah before 'upgrading' blindly over it. I told you people not to do this - 3d accel is very important - you shouldn't dissmiss it outright. shouldn't DRI work with a G400 [normal, MAX] right out of the box with the latest 2.2.1x and latest 2.4.0-testx ? At least for me in XF86COnfig with a G400 and 2.4.0-test12-pre8 it seems to be enabled (through looking in the /var/log/XF*.log). So it seems that you just upgrade to the latest kernel, activate AGP Gart in the kernel and the corresponding G400 and you are set. Greetings Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. Grmpf! Do you know what DRI currently supports vs what Utah currently supports in terms of hardware and/or features? I din't think so. DRI's implementation is orders of magnitude cleaner and it *is* a better option for some people (most of the people, probably), but brushing Utah as a thing "in the past" is, at best, cluelessness. If *you* had trouble setting up Utah drivers it doesn't mean that *everyone* will have them. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] writes: pissed off. An overnight upgrade of gtk shouldn't break my x server. As the gtkglarea maintainer (and since you hinted it's the OpenGL subsystem what broke) I feel this is somehow my fault... could you please elaborate on this? -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Marcelo E. Magallon [EMAIL PROTECTED] [001212 14:40]: DRI's implementation is orders of magnitude cleaner and it *is* a better option for some people (most of the people, probably), but brushing Utah as a thing "in the past" is, at best, cluelessness. If *you* had trouble setting up Utah drivers it doesn't mean that *everyone* will have them. Well, I am at least partially correct in the sense that Utah-GLX does not work with 4.0.1. It only works with versions of 3.3.x; a version most decidedly much older than 4.0.1. That is my definition of 'past' -- something that once upon a time worked, but does not work any longer. Under this definition, the transparent cryptographic filesystem is "in the past" -- it worked with Linux kernel 2.0, but not newer releases. It might have been very good, and served the needs of its users well. It still provides functionality that hasn't been supplied by other packages. But it too is in the past, because it requires an older version of software than most people want to run. It seems clear to me that Utah-GLX fits this definition nicely. (Otherwise, Terry wouldn't be pissed right now. :) Whether it is better or worse, I am not prepared to make this sort of value judgement. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: Well, I am at least partially correct in the sense that Utah-GLX does not work with 4.0.1. It only works with versions of 3.3.x; a version most decidedly much older than 4.0.1. That is my definition of 'past' -- something that once upon a time worked, but does not work any longer. Although a very convenient definition, it doesn't work either. The point in question is GL support. Noone is even *thinking* about getting Utah-GLX to work with 4.0 (that would be a major waste of effort), but right now there are people who would prefer to use Utah over GLX for a bunch of different reasons: to name one, DRI's resource management is different than Utah's, and Utah's has some advantages for some people. Whether it is better or worse, I am not prepared to make this sort of value judgement. What value judgement are you talking about? This is a (measurable) technical issue. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Quoting Christopher C. Chimelis ([EMAIL PROTECTED]):
To end this long reply, I suggest this: compile your own Xserver and utah
and install it in /usr/local until things work out to the point where they
are usable again for your setup.
What I did was use the potato 3.3.6 xserver, because xserver-mach64
doesn't get built anymore, and repacked utah-glx without Conflicts:
xfree86-common(=4.0) line.
For some more fun, today I built xserver-mach64 from 3.3.6-18 sources,
with very little problems - added it back to
debian/{control,create-arch-xservers} and to debian/patches/000a*
(whatever it's called). Now I have a xserver-mach64_3.3.6-18, almost
like it still existed in distro. ;-)
Had to do that because there is no DRI for mach64 yet, and I like
those nifty gl screensavers, not to mention tuxracer.
One could file a bug to utah-glx package and request replacing of
Conflicts: xfree86-common(=4.0) with a dependency on
xserver-common-v3, or maybe on any of those xserver packages utah-glx
works with. That would deal with the removal of utah-glx on upgrade.
Zoran
--
menage a trois, n.:
Using both hands to masturbate.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Marcelo E. Magallon wrote: As the gtkglarea maintainer (and since you hinted it's the OpenGL subsystem what broke) I feel this is somehow my fault... could you please elaborate on this? It seems to be that gtk depends on X 4.0.1+, and that caused my working xserver to be purged and replaced. Still, I want to be able to use 3.3.6-18 and utah packages for G400 and G200 - and they're not in woody anymore. My gripe is that I can't do a new install of 3.3 and utah on any machine, or even ( by using debian ) replace the xserver and libs I lost. cheers, Terry -- --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Death is running Debian GNU/Linux| --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold wrote: Compared against Utah, at least the last time I looked at it, this is really pretty quick and easy. Whether or not the features supported by Utah are imporant enough to justify the work involved with getting it to go is entirely dependent upon the applications one needs to run. For me, I never missed the features. For mongoose (terry?), he obviously misses the features of Utah, but not enough to ensure they wouldn't be overwritten. So, it is your stance that you will not support cards without DRI drivers - and only support 3d cards by their DRI drivers only? People shouldn't be artificial limited like that from my view. If this was about quick and easy and using drivers that weren't fully functional, then I could be running NT. This is about a policy change that wasn't well thought. Some people will need utah for some time, and not allowing new installs of xservers to support utah seems to artifically impose huge hurtles for users and shops alike. cheers, Terry -- --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Death is running Debian GNU/Linux| --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] [001211 23:29]: I told the X people months ago not to force out utah - that's why I'm pissed off. An overnight upgrade of gtk shouldn't break my x server. I also think hiding behind the debian stand-by "it's not even supposed to work" is why packages are always broken - no one cares. Why *should* XF86 support Utah? SGI donated GLX, PI integrated it, MetroX donated code to load drivers as modules at run time, the kernel supports the AGPGART driver needed for this new GLX stuff... Don't get me wrong -- the nice people doing the Utah-GLX broke important ground, but trying to support it in 4.0 doesn't seem productive to me. Trying to get Debian to support something upstream doesn't support seems even less productive. And as for broken packages, if one *really* wishes to avoid this situation, one will run one of the stable releases. If I had a company, with important servers, they would all run stable. For a home machine, I am perfectly willing to wonder why on earth something broke, and I even find a level of fun in tracking it down -- so I run unstable. If you don't fit this description, then you have the choice of running stable. *Those* packages *do* work, as evidenced by the large number of people running Debian. No, I've never heard the "it's not even supposed to work" line by anyone other than myself -- and that once was in relation to someone using the woody packages (linked against glibc 2.2.94 or something like that) being run on potato. (To this end, Charl P. Botha has been doing a good job compiling the 4.0.1 source packages for potato. This is supposed to work fine, and from his description (and user's accolades) it does work fine.) As for your recent problems -- welcome to the bleeding edge. When apt offers to remove a bunch of packages for you, while installing a whole bunch, it *does* ask if this is all right with you first. If you discover after installing the new packages that it wasn't right for you, backing out the new packages isn't too bad either. dpkg provides two command line options to this effect, and apt, despite providing only one option, it is usually the option people want. :) Life on the bleeding edge sometimes means giving up on the past. If there are parts of the past you didn't want to give up on, it is easily within your abilities using apt to prevent this, or running a distribution of Debian where the past is what you live in constantly. It isn't horrible -- many people do that. I wouldn't consider anything else for the machines where their continued stability matters. Cheers. :) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Mon, 11 Dec 2000, Joshua Shagam wrote: It would be nice if the XFree 4 packages had a 'Conflicts: utah-glx' in it, but as has been said already, you ARE running Debian *usntable*, and you reap what you sow in that regard... don't take it out on Branden, please. I told the X people months ago not to force out utah - that's why I'm pissed off. An overnight upgrade of gtk shouldn't break my x server. I also think hiding behind the debian stand-by it's not even supposed to work is why packages are always broken - no one cares. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| ---
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Mon, 11 Dec 2000, Seth Arnold wrote: Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. This is about poor forethought. I complained months ago about how the X team was moving to lock out utah-glx. Utah has more users than DRI - why do this? I woke up from an overnight upgrade of gtk to find my X install made unusable. The point is I need utah to delevop and run Open GL apps, until DRI matures - by making utah uninstallable and not accounting for an installed utah - branden has effectively banned it. You might want utah to play tribes2 or run a modeler one day too. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| ---
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, Dec 12, 2000 at 02:38:06AM -0500, Terry 'Mongoose' Hendrix II wrote: On Mon, 11 Dec 2000, Seth Arnold wrote: Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. This is about poor forethought. I complained months ago about how the X team was moving to lock out utah-glx. Utah has more users than DRI - why do this? I woke up from an overnight upgrade of gtk to find my X install made unusable. Well, it was also a poor forethought for you to not issue a package hold on the XFree packages. It's easy enough to use dselect to request that a package not be upgraded... (hint: = key) -- Joshua Shagam /\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] [001211 23:29]: I told the X people months ago not to force out utah - that's why I'm pissed off. An overnight upgrade of gtk shouldn't break my x server. I also think hiding behind the debian stand-by it's not even supposed to work is why packages are always broken - no one cares. Why *should* XF86 support Utah? SGI donated GLX, PI integrated it, MetroX donated code to load drivers as modules at run time, the kernel supports the AGPGART driver needed for this new GLX stuff... Don't get me wrong -- the nice people doing the Utah-GLX broke important ground, but trying to support it in 4.0 doesn't seem productive to me. Trying to get Debian to support something upstream doesn't support seems even less productive. And as for broken packages, if one *really* wishes to avoid this situation, one will run one of the stable releases. If I had a company, with important servers, they would all run stable. For a home machine, I am perfectly willing to wonder why on earth something broke, and I even find a level of fun in tracking it down -- so I run unstable. If you don't fit this description, then you have the choice of running stable. *Those* packages *do* work, as evidenced by the large number of people running Debian. No, I've never heard the it's not even supposed to work line by anyone other than myself -- and that once was in relation to someone using the woody packages (linked against glibc 2.2.94 or something like that) being run on potato. (To this end, Charl P. Botha has been doing a good job compiling the 4.0.1 source packages for potato. This is supposed to work fine, and from his description (and user's accolades) it does work fine.) As for your recent problems -- welcome to the bleeding edge. When apt offers to remove a bunch of packages for you, while installing a whole bunch, it *does* ask if this is all right with you first. If you discover after installing the new packages that it wasn't right for you, backing out the new packages isn't too bad either. dpkg provides two command line options to this effect, and apt, despite providing only one option, it is usually the option people want. :) Life on the bleeding edge sometimes means giving up on the past. If there are parts of the past you didn't want to give up on, it is easily within your abilities using apt to prevent this, or running a distribution of Debian where the past is what you live in constantly. It isn't horrible -- many people do that. I wouldn't consider anything else for the machines where their continued stability matters. Cheers. :) -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, 12 Dec 2000, Joshua Shagam wrote: Well, it was also a poor forethought for you to not issue a package hold on the XFree packages. It's easy enough to use dselect to request that a package not be upgraded... (hint: = key) Who uses dselect anymore? This is about a package maintianers *duty to account for _likely conflicts_. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| ---
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, 12 Dec 2000, Terry 'Mongoose' Hendrix II wrote: I told the X people months ago not to force out utah - that's why I'm pissed off. An overnight upgrade of gtk shouldn't break my x server. I also think hiding behind the debian stand-by it's not even supposed to work is why packages are always broken - no one cares. I don't think anyone is saying it's not even supposed to workwhat I think is the case here is that we're all trying to shake the bugs out of the DRI code using wider-spread testing. Keep in mind that woody will not be released next week, so the transition is actually quite timely and important. We could remain using XF86 v3.3.x forever, but I think that we would hear more about not trying to do the changeover at this point in woody's development. Keep in mind also that, while you may run on ix86, there are MANY of us that don't (I have two sparcs, three alphas, and a mips in my home lab that I run Debian on. This version of X using DRI is much improved on at least Alpha and has the potential (really soon now) to compile and run on my Indy sans huge amounts of patching, unlike any other X version prior. Lastly, the no one cares argument is rather insulting and, in my experience, will not persuade anyone to look into your problems or respect your opinion about the matter (last time someone insulted me, I just walked away...which, I suspect, is pretty common and civilised human behaviour). I can say, as a maintainer of more than four packages for Debian, WE DO CARE, but you have to allow us time to shake out problems. We've all made mistakes and released things that break the norm, but that's part of knowing your package, the future roadmap of the packages involved, and the release cycle timing of unstable. I back Branden's decisions to proceed with the upgrade to DRI. He hosted experimental packages on his own for quite some time, hoping that he would get enough people to test them while trying to fix up the monumental packaging requirements of something this size. Whether he got the feedback he needed or not, he made the decision and I think that unstable is better because of it (now I finally have an X server that runs on my V3 in my main Alpha and a much less buggy X server on the other two). Sure, there's going to be some hiccups and problems, hence the neverending startx is telling me that I'm not allowed to run the X server anymore threads, but things happen in unstable and sometimes, we just have to weather through them or do what we have to do to suit our specific needs. To end this long reply, I suggest this: compile your own Xserver and utah and install it in /usr/local until things work out to the point where they are usable again for your setup. Running unstable means that YMMV, which sounds like an excuse, but it's really the truth and is not meant to discount complaints. Again, things happen, older software sometimes isn't compatible with newer software, etc...either way, the point is, we do care and, if you're looking for stability, stick with potato and just compile the packages from woody that you need yourself until woody is released. C
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, 12 Dec 2000, Terry 'Mongoose' Hendrix II wrote: Who uses dselect anymore? Call me Mr. Stone-age, but I do still use dselect sometimes. This is about a package maintianers *duty to account for _likely conflicts_. Ok, this gets me a bit upset. There are always unforeseen (or just plain forgotten-about) conflicts that come up. I've been guilty myself of uploading packages that turned out to have horrid bugs in them (which I quickly corrected, but never heard the end of it), but no maintainer that I know purposely releases something maliciously to wreck a user's setup. Also, you seem to forget that us Debian maintainers are VOLUNTEERS. I have sacrificed quite a bit to this project in general, and have spent countless cpu cycles trying to make sure that the new X packages worked well on Alpha (including over 36 hours of patching so far). To say that I have a *duty* to do this is moderately insulting since this work has taken time away from my family, my hobbies, and my other interests. From your argument, if I happen to upload a bad package before going on holiday, I should be flamed to death C
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Hi all, Why have you made the upgrade path in X impossible? You can't run utah on 4.0 - yet you blindly install 4.0 over every system by dependcies. You don't even bother checking /proc to see what card is installed. A simple grep of /proc/pci shows I have an AGP G400, not a V3! I have a machine that has half 3.3.6-18 and 4.0 installed now - and I had the utah package installed! You should check for utah before 'upgrading' blindly over it. I told you people not to do this - 3d accel is very important - you shouldn't dissmiss it outright. shouldn't DRI work with a G400 [normal, MAX] right out of the box with the latest 2.2.1x and latest 2.4.0-testx ? At least for me in XF86COnfig with a G400 and 2.4.0-test12-pre8 it seems to be enabled (through looking in the /var/log/XF*.log). So it seems that you just upgrade to the latest kernel, activate AGP Gart in the kernel and the corresponding G400 and you are set. Greetings Michael
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. Grmpf! Do you know what DRI currently supports vs what Utah currently supports in terms of hardware and/or features? I din't think so. DRI's implementation is orders of magnitude cleaner and it *is* a better option for some people (most of the people, probably), but brushing Utah as a thing in the past is, at best, cluelessness. If *you* had trouble setting up Utah drivers it doesn't mean that *everyone* will have them. -- Marcelo
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] writes: pissed off. An overnight upgrade of gtk shouldn't break my x server. As the gtkglarea maintainer (and since you hinted it's the OpenGL subsystem what broke) I feel this is somehow my fault... could you please elaborate on this? -- Marcelo
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Marcelo E. Magallon [EMAIL PROTECTED] [001212 14:40]: DRI's implementation is orders of magnitude cleaner and it *is* a better option for some people (most of the people, probably), but brushing Utah as a thing in the past is, at best, cluelessness. If *you* had trouble setting up Utah drivers it doesn't mean that *everyone* will have them. Well, I am at least partially correct in the sense that Utah-GLX does not work with 4.0.1. It only works with versions of 3.3.x; a version most decidedly much older than 4.0.1. That is my definition of 'past' -- something that once upon a time worked, but does not work any longer. Under this definition, the transparent cryptographic filesystem is in the past -- it worked with Linux kernel 2.0, but not newer releases. It might have been very good, and served the needs of its users well. It still provides functionality that hasn't been supplied by other packages. But it too is in the past, because it requires an older version of software than most people want to run. It seems clear to me that Utah-GLX fits this definition nicely. (Otherwise, Terry wouldn't be pissed right now. :) Whether it is better or worse, I am not prepared to make this sort of value judgement. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Seth Arnold [EMAIL PROTECTED] writes: Well, I am at least partially correct in the sense that Utah-GLX does not work with 4.0.1. It only works with versions of 3.3.x; a version most decidedly much older than 4.0.1. That is my definition of 'past' -- something that once upon a time worked, but does not work any longer. Although a very convenient definition, it doesn't work either. The point in question is GL support. Noone is even *thinking* about getting Utah-GLX to work with 4.0 (that would be a major waste of effort), but right now there are people who would prefer to use Utah over GLX for a bunch of different reasons: to name one, DRI's resource management is different than Utah's, and Utah's has some advantages for some people. Whether it is better or worse, I am not prepared to make this sort of value judgement. What value judgement are you talking about? This is a (measurable) technical issue. -- Marcelo
Re: [mongoose@users.sourceforge.net: X upgrade policy]
* Marcelo E. Magallon [EMAIL PROTECTED] [001212 16:39]: [...] and Utah's has some advantages for some people. And the one person who has seemed to be effected thus far did not take the time and effort to put his packages on hold. :-P Whether it is better or worse, I am not prepared to make this sort of value judgement. What value judgement are you talking about? This is a (measurable) technical issue. Oh no, *time* falls into the equation as well. Getting GL on 4.0.x is quite simple and fast -- recompile kernel to include AGPGART device and the video card kernel module. Load it and the agpgart modules. Have the following Loaded in the XF86Config file: GLcore, dbe, dri, glx. Compared against Utah, at least the last time I looked at it, this is really pretty quick and easy. Whether or not the features supported by Utah are imporant enough to justify the work involved with getting it to go is entirely dependent upon the applications one needs to run. For me, I never missed the features. For mongoose (terry?), he obviously misses the features of Utah, but not enough to ensure they wouldn't be overwritten. Yes, it is a value judgement, based entirely on measurable technical details. -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Quoting Christopher C. Chimelis ([EMAIL PROTECTED]):
To end this long reply, I suggest this: compile your own Xserver and utah
and install it in /usr/local until things work out to the point where they
are usable again for your setup.
What I did was use the potato 3.3.6 xserver, because xserver-mach64
doesn't get built anymore, and repacked utah-glx without Conflicts:
xfree86-common(=4.0) line.
For some more fun, today I built xserver-mach64 from 3.3.6-18 sources,
with very little problems - added it back to
debian/{control,create-arch-xservers} and to debian/patches/000a*
(whatever it's called). Now I have a xserver-mach64_3.3.6-18, almost
like it still existed in distro. ;-)
Had to do that because there is no DRI for mach64 yet, and I like
those nifty gl screensavers, not to mention tuxracer.
One could file a bug to utah-glx package and request replacing of
Conflicts: xfree86-common(=4.0) with a dependency on
xserver-common-v3, or maybe on any of those xserver packages utah-glx
works with. That would deal with the removal of utah-glx on upgrade.
Zoran
--
menage a trois, n.:
Using both hands to masturbate.
[mongoose@users.sourceforge.net: X upgrade policy]
- Forwarded message from Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] - From: "Terry 'Mongoose' Hendrix II" [EMAIL PROTECTED] To: Branden Robinson [EMAIL PROTECTED] Subject: X upgrade policy Date: Mon, 11 Dec 2000 16:05:35 -0500 (EST) Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Sender: mongoose@localhost Reply-To: "Terry 'Mongoose' Hendrix" [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: Pine.LNX.4.10.10012111559520.437-10@localhost Why have you made the upgrade path in X impossible? You can't run utah on 4.0 - yet you blindly install 4.0 over every system by dependcies. You don't even bother checking /proc to see what card is installed. A simple grep of /proc/pci shows I have an AGP G400, not a V3! I have a machine that has half 3.3.6-18 and 4.0 installed now - and I had the utah package installed! You should check for utah before 'upgrading' blindly over it. I told you people not to do this - 3d accel is very important - you shouldn't dissmiss it outright. I'm having to reinstall all my X libs and applications now, and I can't develop my projects while fixing your mistakes. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| --- - End forwarded message - -- G. Branden Robinson| The greatest productive force is human Debian GNU/Linux | selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://deadbeast.net/~branden/ | PGP signature
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. Second, I'm not sure what you mean by ``I have a g400, not a v3'' -- last time I ran the dexter program, it did not automatically assume I had any type of video card -- rather, it allowed me to select my g400 from a list. But then, I haven't run dexter lately. Third, welcome to life running Debian unstable. :) If you want nice stable operating, run potato. It is very good. If you want the latest and greatest (including XF4.0.1's much improved GLX support), then running woody is just fine -- though there will be bumps along the way. Those bumps are part of running woody, until it is declared stable. (Well, heck, bumps might happen then too, but we try to minimize them. :) Fourth, there is no pressing need to email Branden directly -- he is awful busy. Using lists such as debian-user (for most X questions) or debian-x (for questions specific to the debian packaging of X) will usually get responses much faster. Cheers! :) * Branden Robinson [EMAIL PROTECTED] [001211 19:35]: - Forwarded message from Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] - From: "Terry 'Mongoose' Hendrix II" [EMAIL PROTECTED] To: Branden Robinson [EMAIL PROTECTED] Subject: X upgrade policy Date: Mon, 11 Dec 2000 16:05:35 -0500 (EST) Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Sender: mongoose@localhost Reply-To: "Terry 'Mongoose' Hendrix" [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: Pine.LNX.4.10.10012111559520.437-10@localhost Why have you made the upgrade path in X impossible? You can't run utah on 4.0 - yet you blindly install 4.0 over every system by dependcies. You don't even bother checking /proc to see what card is installed. A simple grep of /proc/pci shows I have an AGP G400, not a V3! I have a machine that has half 3.3.6-18 and 4.0 installed now - and I had the utah package installed! You should check for utah before 'upgrading' blindly over it. I told you people not to do this - 3d accel is very important - you shouldn't dissmiss it outright. I'm having to reinstall all my X libs and applications now, and I can't develop my projects while fixing your mistakes. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| --- - End forwarded message - -- G. Branden Robinson| The greatest productive force is human Debian GNU/Linux | selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://deadbeast.net/~branden/ | -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Not to mention that the G400 driver for XFree 4 has 3D acceleration as well. It's currently kinda broken (stencils don't work at all (not even in software fallback - they're borked), and there are some pretty icky persistent texturing bugs, but it's usable. Just not very. Personally, I'm annoyed by the persistent brokenness of the DRI drivers, but I'm making do in my projects, and if I want to verify my code's correctness I can always use an LD_PRELOAD to force software mesa to check accuracy. It would be nice if the XFree 4 packages had a 'Conflicts: utah-glx' in it, but as has been said already, you ARE running Debian *usntable*, and you reap what you sow in that regard... don't take it out on Branden, please. -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Mon, 11 Dec 2000, Joshua Shagam wrote: It would be nice if the XFree 4 packages had a 'Conflicts: utah-glx' in it, but as has been said already, you ARE running Debian *usntable*, and you reap what you sow in that regard... don't take it out on Branden, please. I told the X people months ago not to force out utah - that's why I'm pissed off. An overnight upgrade of gtk shouldn't break my x server. I also think hiding behind the debian stand-by "it's not even supposed to work" is why packages are always broken - no one cares. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Mon, 11 Dec 2000, Seth Arnold wrote: Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. This is about poor forethought. I complained months ago about how the X team was moving to lock out utah-glx. Utah has more users than DRI - why do this? I woke up from an overnight upgrade of gtk to find my X install made unusable. The point is I need utah to delevop and run Open GL apps, until DRI matures - by making utah uninstallable and not accounting for an installed utah - branden has effectively banned it. You might want utah to play tribes2 or run a modeler one day too. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, Dec 12, 2000 at 02:38:06AM -0500, Terry 'Mongoose' Hendrix II wrote: On Mon, 11 Dec 2000, Seth Arnold wrote: Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. This is about poor forethought. I complained months ago about how the X team was moving to lock out utah-glx. Utah has more users than DRI - why do this? I woke up from an overnight upgrade of gtk to find my X install made unusable. Well, it was also a poor forethought for you to not issue a package hold on the XFree packages. It's easy enough to use dselect to request that a package not be upgraded... (hint: = key) -- Joshua Shagam /"\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [mongoose@users.sourceforge.net: X upgrade policy]
On Tue, 12 Dec 2000, Terry 'Mongoose' Hendrix II wrote: I told the X people months ago not to force out utah - that's why I'm pissed off. An overnight upgrade of gtk shouldn't break my x server. I also think hiding behind the debian stand-by "it's not even supposed to work" is why packages are always broken - no one cares. I don't think anyone is saying "it's not even supposed to work"what I think is the case here is that we're all trying to shake the bugs out of the DRI code using wider-spread testing. Keep in mind that woody will not be released next week, so the transition is actually quite timely and important. We could remain using XF86 v3.3.x forever, but I think that we would hear more about not trying to do the changeover at this point in woody's development. Keep in mind also that, while you may run on ix86, there are MANY of us that don't (I have two sparcs, three alphas, and a mips in my "home lab" that I run Debian on. This version of X using DRI is much improved on at least Alpha and has the potential (really soon now) to compile and run on my Indy sans huge amounts of patching, unlike any other X version prior. Lastly, the "no one cares" argument is rather insulting and, in my experience, will not persuade anyone to look into your problems or respect your opinion about the matter (last time someone insulted me, I just walked away...which, I suspect, is pretty common and civilised human behaviour). I can say, as a maintainer of more than four packages for Debian, WE DO CARE, but you have to allow us time to shake out problems. We've all made mistakes and released things that break "the norm", but that's part of knowing your package, the future roadmap of the packages involved, and the release cycle timing of unstable. I back Branden's decisions to proceed with the upgrade to DRI. He hosted experimental packages on his own for quite some time, hoping that he would get enough people to test them while trying to fix up the monumental packaging requirements of something this size. Whether he got the feedback he needed or not, he made the decision and I think that unstable is better because of it (now I finally have an X server that runs on my V3 in my main Alpha and a much less buggy X server on the other two). Sure, there's going to be some hiccups and problems, hence the neverending "startx is telling me that I'm not allowed to run the X server anymore" threads, but things happen in unstable and sometimes, we just have to weather through them or do what we have to do to suit our specific needs. To end this long reply, I suggest this: compile your own Xserver and utah and install it in /usr/local until things work out to the point where they are usable again for your setup. Running "unstable" means that YMMV, which sounds like an excuse, but it's really the truth and is not meant to discount complaints. Again, things happen, older software sometimes isn't compatible with newer software, etc...either way, the point is, we do care and, if you're looking for stability, stick with potato and just compile the packages from woody that you need yourself until woody is released. C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[mongoose@users.sourceforge.net: X upgrade policy]
- Forwarded message from Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] - From: Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] To: Branden Robinson [EMAIL PROTECTED] Subject: X upgrade policy Date: Mon, 11 Dec 2000 16:05:35 -0500 (EST) Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Reply-To: Terry 'Mongoose' Hendrix [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Why have you made the upgrade path in X impossible? You can't run utah on 4.0 - yet you blindly install 4.0 over every system by dependcies. You don't even bother checking /proc to see what card is installed. A simple grep of /proc/pci shows I have an AGP G400, not a V3! I have a machine that has half 3.3.6-18 and 4.0 installed now - and I had the utah package installed! You should check for utah before 'upgrading' blindly over it. I told you people not to do this - 3d accel is very important - you shouldn't dissmiss it outright. I'm having to reinstall all my X libs and applications now, and I can't develop my projects while fixing your mistakes. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| --- - End forwarded message - -- G. Branden Robinson| The greatest productive force is human Debian GNU/Linux | selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://deadbeast.net/~branden/ | pgpWKwjAcmB6U.pgp Description: PGP signature
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Terry, a few quick comments -- first, Utah-glx is in the past. While their work may have been nifty at one point, and for people running 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system. Second, I'm not sure what you mean by ``I have a g400, not a v3'' -- last time I ran the dexter program, it did not automatically assume I had any type of video card -- rather, it allowed me to select my g400 from a list. But then, I haven't run dexter lately. Third, welcome to life running Debian unstable. :) If you want nice stable operating, run potato. It is very good. If you want the latest and greatest (including XF4.0.1's much improved GLX support), then running woody is just fine -- though there will be bumps along the way. Those bumps are part of running woody, until it is declared stable. (Well, heck, bumps might happen then too, but we try to minimize them. :) Fourth, there is no pressing need to email Branden directly -- he is awful busy. Using lists such as debian-user (for most X questions) or debian-x (for questions specific to the debian packaging of X) will usually get responses much faster. Cheers! :) * Branden Robinson [EMAIL PROTECTED] [001211 19:35]: - Forwarded message from Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] - From: Terry 'Mongoose' Hendrix II [EMAIL PROTECTED] To: Branden Robinson [EMAIL PROTECTED] Subject: X upgrade policy Date: Mon, 11 Dec 2000 16:05:35 -0500 (EST) Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Reply-To: Terry 'Mongoose' Hendrix [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Why have you made the upgrade path in X impossible? You can't run utah on 4.0 - yet you blindly install 4.0 over every system by dependcies. You don't even bother checking /proc to see what card is installed. A simple grep of /proc/pci shows I have an AGP G400, not a V3! I have a machine that has half 3.3.6-18 and 4.0 installed now - and I had the utah package installed! You should check for utah before 'upgrading' blindly over it. I told you people not to do this - 3d accel is very important - you shouldn't dissmiss it outright. I'm having to reinstall all my X libs and applications now, and I can't develop my projects while fixing your mistakes. cheers, Terry --- | GooseEgghttp://gooseegg.sourceforge.net | | QuakeForge http://www.quakeforge.net | | Personalhttp://www.westga.edu/~stu7440| | | | Dream is running Debian GNU/Linux| --- - End forwarded message - -- G. Branden Robinson| The greatest productive force is human Debian GNU/Linux | selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://deadbeast.net/~branden/ | -- ``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all really impressed down here, I can tell you.''
Re: [mongoose@users.sourceforge.net: X upgrade policy]
Not to mention that the G400 driver for XFree 4 has 3D acceleration as well. It's currently kinda broken (stencils don't work at all (not even in software fallback - they're borked), and there are some pretty icky persistent texturing bugs, but it's usable. Just not very. Personally, I'm annoyed by the persistent brokenness of the DRI drivers, but I'm making do in my projects, and if I want to verify my code's correctness I can always use an LD_PRELOAD to force software mesa to check accuracy. It would be nice if the XFree 4 packages had a 'Conflicts: utah-glx' in it, but as has been said already, you ARE running Debian *usntable*, and you reap what you sow in that regard... don't take it out on Branden, please. -- Joshua Shagam /\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML/RTF in email www.cs.nmsu.edu/~joshagam X No Word docs in email mp3.com/fluffyporcupine/ \ Respect for open standards
