Nothing seems to require libfife.so.0 and only other parts of the fife package require fife. So updating in rawhide shouldn't cause problems. Backporting to F16 or F15 is potentially an issue and I am not sure if more harm than good would be done.

Bruno,

From my side, I have no problem is 0.3.3r2 is only available on rawhide and F17+, that's where Unknown Horizons will become available also.

For Fedora 15 and 16 we can still use the normal repositories we've been using till now on OBS. This to say... Unknown Horizons will enter on Fedora 17, that's where we need FIFE 0.3.3r2.

Hope this helps. We can skip the backport for sure.

NM

Let's see what Simon says. He typically does the version updates. I usually just do rebuilds for soname bumps in other packages. I expect he will support going to 0.3.3r2 for rawhide (f17).

Hi Bruno,

Thanks for looking into this. I also hope he can approve the update, else we have a showstopper for Unknown Horizons.

NM

>else we have a showstopper for Unknown Horizons

I'm working on a fedora-rpm for UH since 2009. The main problem with UH is that a couple of multimedia-files are used without a register from where these files are and under which license the original file is/was released. In this case UH should be looked from fedora as non-free until the project can be prove that !all! files are shipped as free software as it is in our licensing-guidelines described. Similar to the license problems in fife, so fife isn't complete and fedora only shipps the core of this engine. 
In this fact - fife is maintained stepmotherly..

Cool. I'm going to do the following:

1. Inform Chris (UH upstream) about this and report that you are working on UH for Fedora since 2009. Maybe you can explain the Fedora users who asked for this package where they can find it. (or just keep the way it is, provide our binaries through openSUSE build service, yes they work).

2. Inform FIFE upstream on this.

3. Jump ship.

thanks.

I've closed the package submission requests for Fedora and the missing dependencies and striked off the specs and srpms from fedorapeople.org.


My humble apologies it was not intended from my side to overrun previous contributions. Feel free to carry on, and I would _STRONGLY_ advice you to contact upstream regarding the issues that you mentioned before, as they seem to be cleared since 2011.2 already (UH side). 

As a fallback and advertised on Unknown Horizons page, Fedora builds will still be provided through openSUSE Build Service since it seems there isn't really another way of providing them :)

NM

Simon,

Fedora users who like Unknown Horizons have requested us (upstream UH) to make UH available in Fedora. We are unable to do so, not because of licenses, but because of FIFE state in Fedora.

Feel free to update it if you wish... so we might have a shot to deploy UH on Fedora with support from upstream. If you fail to comply, we'll have to think on something else which might not be so pleasant to Fedora users, for example, request them to build the package (FIFE and UH) from source.

Within 48 hours the binary distributions we make for Fedora, RHEL and clones are no more, and Fedora users will become bound to what Fedora through YOU offers, which is pretty much nothing.

I hope this can elevate your thinking to something productive.

Kindest Regards,
NM

The wording of you last comment wasn't polite. You could have just stated that you are dropping support of builds for Fedora because FIFE is too old. You didn't need to make it sound like a threat.

Nothing is likely to happen in the next 48 hours. Eventually I'll probably look at doing it, but I have other Fedora work that is more important to do right now. But Simon or perhaps someone else could take a look at doing this.

Bruno,

It wasn't meant as a threat, neither it makes any sense for it to be that way. It's maybe a cultural adaptation issue regarding to language.

If you look more carefully to the original text of this BZ entry, it's already a request to update it, for which according to one of your previous comments I was led to believe that there were no blockers to perform that update.

I am led to believe based on the what happened in the last 6 months that people actually don't care about this, for which I am deeply sorry.

As you can imagine, if we can't deliever successfully on a platform due to whatever issues, we must ditch it.

From our side:

 1) We have fixed the licensing issues;
 2) Alongside with FIFE, we started working on a new system to use system wide installed fonts (which are provided by Fedora, currently UMing and LinLibertine);
 3) We are opened to fix any potential issues, but we have no reports;

I've spared myself from my own time (just like yourself) to maintain UH. I don't mind maintaining FIFE if that brings value, as I don't mind maintaining GUICHAN or any other dependency. I'm ready to put all the work for it to happen.


Why hasn't it happen? So please enlighten me, why are in this royal mess? What more do you want from me to make this happen... Please name it, I'm sure we'll find a way to make it happen... If we don't we just ditch it... How can that be a threat? It's just plain reality... things either work, or they don't work at all :)

NM

I co-maintain FIFE so that I can do rebuilds when needed because of soname bumps in other packages I maintain. To do a real update would require me getting more familiar with the package and so there would be some start up costs. Also not having anything in Fedora use it makes it harder to test and does not provide motivation for getting it updated. Seeing that UH might actually get packaged changes that quite a bit, but I am spread thin and I really need to fix up an issue with egoboo that is going to suck up a bunch of time.

If you are officially already a packager, then you should be able to contact Simon to indicate what you are planning on doing (update to latest release) and request access in the package database for Simon to approve.

Bruno,

Both UH and FIFE upstreams are the sweetest people you can work with. If you find anything take it to them directly or to me and we have a show going.

Regarding the FIFE package what I can state is the following:

 - Most of the patches you have can be ditched as they are fixed upstream already;
 - Most of the hacks in the spec can be ditched also;
 - You might keep away from the package the stuff that isn't compliant with OSI;

If you need a proof of concept in anyway, feel free to check out the package we made for FIFE and that we use on Fedora and RHEL currently. The FIFE package on OBS is here[1]. It can probably easen up the update.

No I'm not a Fedora packager, reviews are undergoing and Tom is the sponsor. That's why I can't help and have my hands tied up at this stage.


[1] - https://build.opensuse.org/package/show?package=fife&project=games%3Aunknown-horizons

Bruno,

I'm working on the fife package update. I'll attach the spec here once it's done.

Bruno,

I've refactored the .spec file for 0.3.3r3 release, but before submitting it I would like assistance on a few issues:

 1) The current spec file is using Epoch. Why is this? (my personal stance mis that Epoch shouldn't be used lightenly as it most times does more harm than good);

 2) The current packaging model should be reconsidered with the following changes:
    - remove 'static' sub-package as we don't really have any need for static objects on this package;
    - remove the shared objects/public libraries as they are not supported by upstream; clients should use only the internal shared object on the python package (_fife.so);

This are the main the recommendations I would do; I have a working .spec file with those changes I can submit anytime, though I would like feedback first.


Furthermore I would recommend the following:
 
 1) Cease with the sed'ing as much changes from release to release. In my humble opinion the SConstruct file should be patched, even if it needs to be rebased on releases, it's way more cleaner.

 2) Regarding the spec notes:
    - ext/ should be disabled with patch over SConstruct;
    - tests/ should be disabled with patch over SConstruct;
    - tools/ no are no longer under offending licenses; tools/atlas/ is under BSD license.


Now, how can I submit the spec/patches for your consideration ?

Created attachment 581106 [details]
fife.spec proposal

Created attachment 581107 [details]
patch, dont build ext/ and tests/

I've attached a spec file with the following modifications:

- increase relea se;
- remove previous patches (fixed upstream/no longer required);
- add patch not to build ext/ and tests/
  + we use vendor guichan
  + we dont build tests due to pending legal issues
- Add gcc-c++ to BuildRequires (my default build system requires it that way)
- %version uses same version as upstream now, any real blocker for not doing it?
- no more static sub-package; now we should Provides/Obsolete it there somewhere for client smooth transiction; any recommendations?
- shared libraries aren't supported by upstream; none of the existing clients seem to require them, instead they use the python wrapped up stuff;
- re-ordered BRs alphabetically, improved summaries and descriptions, cleaned up some deprecated stuff and commented stuff I can't test.

I dont understand why Epoch is being used, I'm not even sure if I can recall a situation where I would even suggest it to someone (outside the jpackage hell); Why do we use it?

Another thing is that the binaries aren't striped; this can be done easilly in %install, but I suppose this is not the normal behavior; what would be your sugestion ?

So, Nelson, there are issues with your spec.

There is a comment at the top regarding the placement of the unversioned shared library (/usr/lib/libfife.so) which claims that clients are trying to use it? If so, it can't go into -devel.

There is no need for a "-shared" subpackage. Those files should go into "fife". If static files are needed, they can go into a "-static".

Also, rpmlint doesn't really need to be a BuildRequires, does it?

> There is a comment at the top regarding the placement of the unversioned shared
> library (/usr/lib/libfife.so) which claims that clients are trying to use it?
> If so, it can't go into -devel.

Wrong, none of the clients uses the public shared objects that typically go into %_libdir; There is no need of having those public libraries at all, furthermore, they are not even supported by upstream.

Everything the clients require is the python package and the internal shared object (_fife.so). That comment if from the original spec and maintainer. It was left there for 'historical purposes'.

> 
> There is no need for a "-shared" subpackage. Those files should go into "fife".
> If static files are needed, they can go into a "-static".

Like I said previously, upstream does not support the public shared objects and they are not required by clients. Clients use the _fife.so (internal shared object) on the python package.

This has been confirmed to me by upstream... I've left that package there because, well... the maintainer of the package did package them... My honest position is that, public static and shared objects shoudnt even be packaged.

> 
> Also, rpmlint doesn't really need to be a BuildRequires, does it?

True... it can be removed. It's just for my own stuff under my chroot cage.

Advice on procedures ? I can wipe the unwanted stuff and made the relevant changes, should I go for it ?

Okay, so I still think that killing off the -shared subpackage and having them in "fife" makes sense. If upstream really doesn't want people to use that library, they really should rework the source such that they're not generated at all in either shared or static config.

I'll go ahead and commit that version to Rawhide just to get things moving here.

Do you have a pregenerated source tarball somewhere? If not, I can just make it again.

(In reply to comment #20)
> Okay, so I still think that killing off the -shared subpackage and having them
> in "fife" makes sense. If upstream really doesn't want people to use that
> library, they really should rework the source such that they're not generated
> at all in either shared or static config.

I believe it's possible to disable the install for those build targets (shared and static); I will investigate for a future version; If I'm wrong on this, I'll ping upstream to fix this for the next version.

> I'll go ahead and commit that version to Rawhide just to get things moving
> here.
> 
> Do you have a pregenerated source tarball somewhere? If not, I can just make it
> again.

I've used the normal tarball available from download from one of the sourceforge mirrors:
 - http://sourceforge.net/projects/fife/files/active/src/fife_0.3.3r3.tar.gz/download?use_mirror=kent

For further reference: http://wiki.fifengine.net/index.php?title=Download_section

Tom, thanks for working this out... I will then request one more update (guichan) to insert a patch to enable UTF-8, and then we're cool to re-open UH.

0.3.3r3-1 is in rawhide now.

Tom,

We all know you are most likely a busy person, you have our gratitude for unblocking this situation. I'm gathering all the data to submit one more requst, this time I will provide a git formated patch for the spec file for another package,then we're good to go :)

I will re-open today or tomorrow the UH review once more so we can deploy :)

NM

One issue that should probably be addressed is that fife-static is not obsoleted and will block automated updates of the other fife packages. If fife-static is being permanently dropped, it would be good to obsolete it.

Bruno,

Agree... I'm not familiar on how Fedora does this, but I would assume it's through the traditional usage of Provides/Obsoletes pair... In the main package:

(...)
Provides: fife-static = %{epoch}:%{version}-%{release}
Obsoletes: fife-static < %{epoch}:%{version}-%{release}
(...)

If this is correct I can provide a git patch against the spec if needed or maybe if you can rebuild it with the changes would be assome. Totally agree with you on this.

Provides would only be used if it makes sense. In this case I am not sure that it does. But there should definitely be a versioned obsolete unless fife-static is going to come back soon.

I've suggested the Provides because I'm not sure if Fedora has currently any package with an explicit dependency on fife-static; If such cenario exists, Provides should be must... If such cenario doesn't exist, it doesn't harm to have it there also, and in 1 or 2 updates can be removed... This would assure a smooth transiction to clients...

Either way, I leave that call to the maintainer or someone which can ensure if such dependencies exist or not in Fedora currently.