[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?

[Kamil Rytarowski]

W dniu 14.11.2011 18:16, Michael Scherer pisze:
> Le dimanche 13 novembre 2011 à 22:32 +0100, Kamil Rytarowski a écrit :
>> On 13.11.2011 10:58, Michael Scherer wrote:
>>> Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit :
>>>> On 12.11.2011 20:20, Michael Scherer wrote:
>>>>> Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit :
>>>>>
>>>>>> There is also one important patch missed in Mageia -
>>>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html it's
>>>>>> dependency for the GNS3 simulator. OpenSUSE already includes it
>>>>>> https://build.opensuse.org/package/files?package=qemu&project=openSUSE%3ATools
>>>>>>
>>>>>> If nobody is against I will do it and contact the maintainer (misc).
>>>>> I prefer to wait on the stable release ( ie, no rc1 ).
>>>>> We will wait on stable version of qemu.
>>>> OK
>>>>> And no patch unless it comes from upstream ( and even, I am not keen on
>>>>> backporting feature, better wait for stable release ).
>>>>>
>>>> GNS3 is already in stable! This package is broken - no dynamips (=no
>>>> router emulation at all...), no patched qemu (no virtualization support
>>>> at all...) According to the developers and their online documentation
>>>> for package maintainers http://forum.gns3.net/post11571.html UDP patched
>>>> Qemu is dependency/very important.
>>> The fact that someone pushed a broken package is not a good reason to
>>> add patches to qemu.
>> OK, but I don't understand this.
>>
>> Why to keep defunct packages (this could be at least "major+ issue"  on
>> our bugzilla) in stable and don't even want to fix, ignore this academic
>> software (with maybe overall 1 000 000* downloads and 100 000 regular
>> users), and to support... the inadvisable opinion of Mageia around.. at
>> least the GNS3 users.
> Let me rephrase again. Everybody sooner or later think "that soft is
> great, but why do not add just a small patch there". That's just one
> patch, where is the problem ?
>
> The problem appear just after a few months, when the patch is still not
> upstream, and that someone who do not know C, python whatever has to
> take the software and maintain it. Or when someone who know how to
> program lose time rediffing the patch instead of doing something more
> useful. We face bugs that cannot be reproduced upstream, security
> problem that could be added in non reviewed patch by devs. Fragmentation
> in linux distributions are also caused by differents features, due to
> patchs.
>
> All of this need to be avoided, and I think we have enough problems with
> stuff that people do not want to take care of it to not add more burden,
> be it under the form of a small patch. All big collections start by one
> little stuff.
>
>
>> * 799 968 Windows Downloads (just from the sourceforge mirrors) of the
>> latest Windows binary of GNS3 (source
>> http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/)
>>
>>> We have too many patches on a general scale, and I
>>> do not want to end with a 2nd package like gdb.
>>>
>>> Patches make harder to upgrade, harder to make sure security is done
>>> correctly, and harder to ensure stuff are working ( since we are on our
>>> own when we patch something ).
>>> So for the patches, make sure it is upstream
>> It's not qemu upstream, it's GNS3 and its community upstream.
> If you want to have a feature in qemu, the road is "push it upstream".
> Once accepted upstream, it will sooner or later be in our packages.
>
>>>    ( and given the discussion
>>> on ml, it should be soon )
>> When I ask the developers, they don't know if qemu will include the
>> patch at all and when (now or after one year) and they suggested to do
>> the openSUSE way (today the most recommended and full featured Linux
>> distro for GNS3).
> Maybe we are not talking of the same patch, but I am talking of this
> one :
> http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html
>
> AFAIK, the patch have been accepted, just not committed yet. The last
> mail were from 1 week ago. The only issue is that they are in freeze for
> now, and the git web interface is down, and I do see the commit in my
> checkout about it so far.
>
>>> and then in a tarball ( again, given that's a
>>> rc 1, that should be ok soon ).
>>>
>>>> We must fix the package and provide at least not so heavy broken ones...
>>>>
>>>> I've prepared new version of GNS3, included into svn dynamips and
>>>> xdotool (this one suggested) - these I can maintain with my mentor, so I
>>>> ask for patch qemu in stable versus UDP support.
>>> Updates are not supposed to get new features,
>> Well this is a special case - the bugfix provides the feature, or the
>> feature provides the bugfix.
> People will always tell "it is a special case". We can always say that
> any feature is a bugfix, provided we say that the bug is "I cannot do
> that".
>
>
Hi!
We have succeed to push the patch upstream 
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b 
It took 2 months.. It will be shipped with the next version of Qemu so 
no need to take care of the patch for next releases.
Can I now patch the old Qemu in Mga1 to ship UDP support and therefore 
be usable within GNS3? I will then fix GNS3 and its requirements too.