Hans and all,
I've re-opened the ticket for python-enet (previously pyenet) and made
some changes, including the package name.
*
If anyone can help with the review (I know Tom is a very busy man)
would most welcome; python-enet requires also libenet (ENet) >= 1.3.3;
as I am aware Tom has updated the dependencies already for ENet.
I'm currently uploading the unknown-horizons SRPM and spec also (will
take some time since it's a fat SRPM and my home connection uplink
is... well.... slow... When it's over (20 mins or so) it will be here:
*
Hi,
On 05/13/2012 08:05 PM, Nelson Marques wrote:
>
> 2012/5/13 Hans de Goede<hdegoede(a)redhat.com>:
>>
>> Hi,
>>
>>
>> On 05/12/2012 07:15 PM, Nelson Marques wrote:
>>>
>>>
>>> 2012/5/12 Hans de Goede<hdegoede(a)redhat.com>:
>>
>>
>> <snip>
>>
>>
>>>> First of all, welcome to the Fedora Games mailinglist, and let me say
>>>> that
>>>> we would love to have Unknown Horizons in Fedora.
>>>>
>>>> You mentioned a review request for UH that you closed, which I indeed
>>>> found:
>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=718430
>>>>
>>>> That review request points to this (recently fixed) FIFE bug:
>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=757352
>>>>
>>>> But AFAIK there is no new review request for UH, did I miss it?
>>>
>>>
>>>
>>> I'm going to re-open it (the one you mentioned before) once we have
>>> all the dependencies prepared, let go a bit further:
>>>
>>> 1. Tom (spot) has updated the dependencies required to update ENet
>>> (libenet), which provides the base layer for multiplayer. With ENet
>>> updated, I can continue with my review request for 'python-enet'
which
>>> provides the python bindings used by UH for Multiplayer.
>>>
>>> 2. FIFE - The packaging of FIFE isn't really as I would like to be.
>>> I'm gathering soon with FIFE upstream to propose a packaging model
>>> that upstream can support and hopefully to implement it on the next
>>> release in Fedora (and openSUSE);
>>>
>>
>> Ok.
>>
>>
>>> 3. Guichan - a dependency to build FIFE; This probably the only
>>> blocker as we need to submit a patch which was previously submited to
>>> upstream, but no action was taken on it and upstream from guichan
>>> seems to be masturbating themselves with UTF-8 implementation over the
>>> last 2 years but no real release was made. I'm going to propose this
>>> patch to Fedora guichan, which I don't mind also to co-maintain. If
>>> guichan doesn't fix this, we're (UH upstream) prepared to fork
guichan
>>> so we don't have to strugle with vendors who can distribute UH.
>>
>>
>>
>> As long as the patch does not change the API (extending it is ok),
>> then that should not be a problem.
>
>
>
>
http://gitorious.org/guichan/mainline/commit/90c8966f6cb153d6ab03e146d3ad...
>
> The patch was commited upstream, it's a simple 1 liner, but no release
> was issued after it... So when a release happens we can drop it;
> Now... I don't see why we can't add this patch.
Good News, we (Fedora) are have that patch in our packages :)
Regards,
Hans
--
Nelson Marques
// I've stopped trying to understand sandwiches with a third piece of
bread in the middle...