From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8 Description of problem: The patch applied on IA64 and Alpha architectures (glide-ia64.patch) causes a dubious situation to occur when the Glide3-gcc3.patch is applied later. This causes the rpmbuild process to pause while "patch" queries about a reversed or previously applied patch. Hitting enter continues the build without incident (on Alpha, at least). This makes things tricky in an automated rebuild situation, though. Version-Release number of selected component (if applicable): Glide3-20010520-31 How reproducible: Always Steps to Reproduce: On either Alpha or IA64 (patch is conditional with %ifarch - won't occur on x86): rpmbuild --rebuild Glide3-20010520-31.src.rpm (current version in Rawhide) Actual Results: [rpm build output snipped] Patch #11 (Glide3-gcc3.patch): + patch -p1 -b --suffix .gcc3 -s Reversed (or previously applied) patch detected Assume -R [n] Apply anyway [n] 1 out of 1 hunk ignored -- saving rejects to file h3/glide3/src/fxcmd.h.rej error: Bad exit status from /var/tmp/rpm-tmp.25477 (%prep) Additional info: It appears that the ia64 patch is setting off a strange situation in the Glide3-gcc3.patch file. One section appears to be removing and re-adding the same line. Open up Glide3-gcc3.patch in an editor, search for "1312". Not sure how that section got there, unless it's a difference in whitespace or something. I'm not mad - there's no change made there, right? Removing that section from the gcc3 patch allows the rebuild to proceed without incident. I'd supply a patch, but it seems a little wrong to create a diff of a diff.
It might be best for us to do one of the following: 1) Update Glide3 to the current Glide3 upstream which is quite different from our current Glide3. Then have any bugs fixed directly upstream for future, to minimize patch cruft in our rpms. or 2) Relegate Glide3 to be a Fedora Extras package. X doesn't require Glide3 to be present at build time anymore since 4.2.0, so people who install Glide3 from Fedora Extras can still get 3D on tdfx hardware. These are longterm thoughts about Glide3 in general though, and not just for this specific problem. It's building on our currently supported architectures right now, but if someone is interested in fixing the problem to keep Glide3 building on unsupported architectures, we can review patches for consideration.
The easiest course right now, given the state of things as you mentioned, would be to drop the offending section out of Glide3-gcc.patch. Given that it doesn't seem to actually do anything, it shouldn't break anything on an existing platform, and allow building on IA64 and Alpha. I'll attach a version of the patch file that applies cleanly - the following it what's been removed - apart from that, it's no different. This is from the section applying to h3/ glide3/src/fxcmd.h. -- @@ -1312,7 +1312,7 @@ #define REG_GROUP_SETF_CLAMP(__regBase, __regAddr, __val) \ do { \ const FxU32 fpClampVal = FP_FLOAT_CLAMP(__val); \ - REG_GROUP_ASSERT(__regAddr, fpClampVal, FXTRUE); \ + REG_GROUP_ASSERT(__regAddr, fpClampVal, FXTRUE); \ SET(((FxU32*)(__regBase))[offsetof(SstRegs, __regAddr) >> 2], fpClampVal); \ GR_INC_SIZE(sizeof(FxU32)); \ } while(0)
Created attachment 101434 [details] Fixed Glide3-gcc3.patch This is identical to the existing Glide3-gcc3.patch with one section removed that didn't seem to do anything.
The hunk that seems like it isn't doing anything, is actually removing some unnecessary trailing whitespace which causes compiler warnings. If you rework the ia64/alpha patch to account for this however, and move patch0 to position at patch50, reworking any changes needed, I'll apply the patch to rawhide builds. We should probably move Glide3 from Fedora Core into Fedora Extras, and let someone in the community take over maintaining the package as it is getting rather crufty. It might also be a good idea if we did that, for it to be updated to the newer more experimental and cutting edge Glide3 from CVS devel branch. Would you be interested at all in maintaining a Glide3 package at fedora.us? If so, let me and warren know. Thanks in advance!
I have no objections to it, but a package maintainer would need to be "owner" for Extras bugzilla. I already own a few hundred too many.
Makes sense, you're a busy guy. ;o) I don't mind updating Glide3 to Borca's latest bits as it's probably a lot cooler stuff for tdfx users than what we ship. The main reason I've never done so before is because Glide3 died for over 2 years, and what we ship barely ever got any bug reports anymore. It was "stable" so to speak (despite some known issues), so it was low-cost to keep shipping it, however upgrading to bits of unknown stability stood a chance of adding bugs, and causing a demand for a lot more engineering resources than we would be able to justify spending on maintaining the package due to the ever increasing obsolescence of the hardware. I've booted Glide3 out a few times now, but someone has fixed it and I softened up and brought it back. ;o) I think it really belongs to spend it's retirement days in Fedora Extras though, catching some nice sun rays and enjoying the beach. ;o) If someone in the community expresses an interest in taking over the package, I'll spend the time to update it to the latest bits in CVS and pass on the baton. Our tdfx driver will still work even in it's abscence, so no compat problems should result if it's missing by default. One just needs to drop it in place.
Current Glide3 status is "apparently works again". That means later updates and any fixes for IA64/Alpha may well need redoing. We don't support these platforms so if you want them running Glide3 then a patch versus the devel glide3 would be good otherwise it's a WONTFIX as a simple manpower decision
Thanks - I just got my hands on an old Voodoo card, so I'll do a fresh build during the week and see how it goes. If it looks like too much work, I'd be tempted to just drop it from my Alpha tree anyway. Will get back with status report fairly soon so this case can be closed one way or another.
Hi, I'm currently working on a Glide3 package for Fedora Extras as Glide3 will move to Fedora Extras for FC4. My current package has modified versions of both patches involved in this bug and should compile cleanly on alpha. You can check out the current version in Fedora Extras CVS see cvs.fedora.redhat.com for anon access instructions if you don't have Extras CVS access. Any comments would be appreciated. The current package is still based on the old Glide3 code + fixes. Looking at and, if better, switching to the sourceforge Glide3 code is planned for the future.
This is fixed for FC4 and in current rawhide, close please.