Bug 126734 - Malformed patch for IA64 and Alpha
Summary: Malformed patch for IA64 and Alpha
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Glide3
Version: rawhide
Hardware: ia64
OS: Linux
medium
low
Target Milestone: ---
Assignee: Alan Cox
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-25 14:44 UTC by Mike Barnes
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version: FC4
Clone Of:
Environment:
Last Closed: 2005-06-12 19:00:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Fixed Glide3-gcc3.patch (39.03 KB, patch)
2004-06-26 07:02 UTC, Mike Barnes
no flags Details | Diff

Description Mike Barnes 2004-06-25 14:44:26 UTC
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.

Comment 1 Mike A. Harris 2004-06-26 00:14:05 UTC
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.



Comment 2 Mike Barnes 2004-06-26 07:00:26 UTC
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)

Comment 3 Mike Barnes 2004-06-26 07:02:45 UTC
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.

Comment 4 Mike A. Harris 2004-07-06 00:37:21 UTC
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!



Comment 5 Warren Togami 2004-07-07 04:38:14 UTC
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.

Comment 6 Mike A. Harris 2004-07-07 05:35:20 UTC
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.


Comment 7 Alan Cox 2004-10-15 16:10:40 UTC
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

Comment 8 Mike Barnes 2004-10-16 09:56:00 UTC
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.

Comment 9 Hans de Goede 2005-05-01 07:59:59 UTC
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.

Comment 10 Hans de Goede 2005-06-12 10:23:49 UTC
This is fixed for FC4 and in current rawhide, close please.



Note You need to log in before you can comment on or make changes to this bug.