Bug 435898

the only reason we even have the beta version of nant is that the current stable
nant doesn't build on ppc.. I bumped the build to please the ppc arch team in
Pauls absence. 

I say we revert to a 0.85 based nant, 0.86 has turned out to be a lot more
painful than initial testing showed and the only gain is the ability to build on
ppc which frankly just isn't a worthwhile tradeoff given that the freeze is
coming up.. 

(In reply to comment #1)
> the only reason we even have the beta version of nant is that the current stable
> nant doesn't build on ppc.. I bumped the build to please the ppc arch team in
> Pauls absence. 
> 
> I say we revert to a 0.85 based nant, 0.86 has turned out to be a lot more
> painful than initial testing showed and the only gain is the ability to build on
> ppc which frankly just isn't a worthwhile tradeoff given that the freeze is
> coming up.. 

I don't know whether it's actually possible to downgrade with introducing the
dreaded "Epoch:" tag which is awkward, see:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines

Created attachment 299299 [details]
patch nant 0.85 for api changes

Paul, since you are the maintainer you get to decide what is the best course of
action here. However I have attached a little patch that makes the old nant
compile against what we have in Rawhide and it would be my recommendation to
rollback to that.

Comment on attachment 299299 [details]
patch nant 0.85 for api changes

Fixed MIME type.  This really should be opened as a nant bug, or this bug
should be moved to the nant component.

(In reply to comment #3)
> Created an attachment (id=299299) [edit]

> Paul, since you are the maintainer you get to decide what is the best course of
> action here. However I have attached a little patch that makes the old nant
> compile against what we have in Rawhide and it would be my recommendation to
> rollback to that.

Is this bug supposed to be applied to nant 0.86 or are you proposing rolling
back the whole nant package to 0.85?  In which case you need to introduce the
dreaded epoch (see comment #2).

Lastly I seem to recall that Paul was reducing his involvement with Fedora
packages except for mono related ones, so I'm not sure if this is package that
he is following carefully.  If no response is made within a week or, I'll try
and fix things so at least there are no broken deps in rawhide, since this
really should be fixed before F-9 final.

I am suggesting rolling back to 0.85, with the patch applied (it fixes a little
api change that caused the nant build to fail). 

It's the only sane thing to do, nant 0.86 is still in beta has has been since
early December, no real progress seems to be made in their CVS. I am not
comfortable risking shipping F9 with a beta of nant with this kind of bug
present and I doubt I have the technical skills to fix it myself. 0.85 worked
well, the only problem is lacking PPC support - Instead of trying to please the
arch team with this update I suggest that problem with handed off to them. I
have no ppc hardware and frankly I don't care about ppc as it has caused me
nothing but grief. 

Paul does tend to go away for extended periods so maybe it would be worth
getting a proper Mono SIG together and sharing ownership. It would help in
streamlining Mono support in Fedora, help us push for the same mono stack across
all supported platforms and aid in getting new mono packages into Fedora (I
currently have at least 3 mono based packages in need of review and nobody seems
comfortable doing the reviews since Mono specing is a little possessed skill).

Can you prepare a patch for the spec file to do the rollback, i.e. with the
Epoch tag and/or just push a rawhide build?   Then I can rebuild boo.  

This is going to be painful. :(

Ping?  David, are you willing to do the rollback, or do you want me to do it?

go ahead, I sadly have little time to get this done and tested due to other
Fedora work right now and it has been broken far to long.

(In reply to comment #9)
> go ahead, I sadly have little time to get this done and tested due to other
> Fedora work right now and it has been broken far to long.

OK, rolling back to 0.85 using Epoch.  Add the 0.85 API patch.  We'll see how
that goes.

I can't even get this damn thing to compile using the old 0.85 release:

http://koji.fedoraproject.org/koji/buildinfo?buildID=45460

which patches are now necessary and what order should I apply them in?  Here's
the spec file diff:

http://cvs.fedoraproject.org/viewcvs/rpms/nant/devel/nant.spec?r1=1.15&r2=1.18

On i386 the patches appear to apply, but it fails later in the build.  On x86_64
it fails upon applying the same patch, even though I'm rolling back to what
seemed to work in previous rawhide builds for 0.85.

You would need to first change:

-sed -i -e "s/@LIB@/%{_lib}/" NAnt.build
+sed -i -e "s/@LIBDIR@/%{_lib}/" NAnt.build

then rollback the app patch to the last version that worked:

http://cvs.fedoraproject.org/viewcvs/rpms/nant/devel/nant-app.patch?rev=1.3&view=markup

Since the one you are using appears to be for 0.86-beta1 not 0.85

Note I don't currently have a working F9 setup to test that with but it would
seem to work from a glance

(In reply to comment #14)
> Note I don't currently have a working F9 setup to test that with but it would
> seem to work from a glance

You can create an SRPM using:

make srpm

then do a koji scratch build:

koji build --scratch dist-f9 <path-to-srpm>.srpm

(In reply to comment #13)
> You would need to first change:
> 
> -sed -i -e "s/@LIB@/%{_lib}/" NAnt.build
> +sed -i -e "s/@LIBDIR@/%{_lib}/" NAnt.build

I think I did that.

> then rollback the app patch to the last version that worked: 
>
http://cvs.fedoraproject.org/viewcvs/rpms/nant/devel/nant-app.patch?rev=1.3&view=markup
> 
> Since the one you are using appears to be for 0.86-beta1 not 0.85

I believe I did that too: i.e. rollback the patch to the previous one.  I tested
that it applied correctly (and it does apply correctly on i386, but somehow
fails on x86_64).

OK, finally built:

http://koji.fedoraproject.org/koji/buildinfo?buildID=45460

Looks like I had pulled the patch from the F-8 branch rather than the previous
version from the F-9 branch.  The whole series of patches is pretty messy and
should probably be rationalized at some point, but at least it builds.  

I'll rebuild boo against it and request rel-eng to add it (and boo) to the final
F-9 release if possible.

so we might finally close this.. I'll uncock the champagne

boo-0.8.1.2865-3.fc9 rebuilt successfully:

http://koji.fedoraproject.org/koji/buildinfo?buildID=41174

(In reply to comment #17)
> so we might finally close this.. I'll uncock the champagne

Maybe... ;)  If you get a chance, can you test nant and/or boo?  (I've actually
never used it)

Does anything else use/compile against nant in rawhide?  i.e. anything that
would expect the previous (0.86) version of nant?

nothing springs to mind

(In reply to comment #21)
> nothing springs to mind

Looks like there are further issues with nant shipping things it shouldn't and
messing up Provides:  bug #441517.  I've Cc'ed you.

With new mono stack and nant (finally!) re-built and tagged f9-final, the boo
broken dep has gone away.  booish also appears to work fine for me.

So closing bug.

http://koji.fedoraproject.org/koji/buildinfo?buildID=46070