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

Wed Nov 16 05:15:55 CET 2011

On 14.11.2011 18:16, Michael Scherer wrote:
+> 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.
+>
+I see your point, but then tell why to keep GNS3 in our repos? What 
+would you do? Patch GNS3 to cut the features from GUI? Then we will have 
+next version of GNS3 (0.8.x is already in its way..).. well I quote what 
+EXACTLY will happen:
+
+>  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
+
+and ALSO
+
+>  We face bugs that cannot be reproduced upstream
+
+//Well I am more aware in this case due to lack o features/broken 
+GUI/GNS3 then security problems...
+
+I like this point:
+
+>  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
+
+But then what to do? Leave a broken package as it is - and just wait for 
+bugs on our bugzilla - and support our quality - or remove it from the 
+official repos?
+
+Please remember that GNS3 is already in Mageia 1 and we still DO provide 
+support of Mga1 for dozen of months.
+
+We can of course hope that nobody will complain about it as long as we 
+DO support Mga1 and wait for patch for Mga2 from upstream (very possible 
+patch).
+
+BTW. I had facied similar case before. Upstream of newer Xboard provides 
+support for many chess variants, but lacks support for pieces in every 
+board size. So I decided to patch the source myself to disable the 
+partly supported board sizes - to make sure that the end user will have 
+EVERYTHING working for sure. So I would also provide a special patch to 
+cut qemuwrapper from GUI of GNS3 for our stable and hope to have it 
+already fixed by qemu upstream for Mga2.
+>> * 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.
+>
+This road if for developers not for package maintainers and users.
+
+But the developers already are trying hard to push it upstream, with the 
+support of community.
+
+
+>>>    ( 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
+I'm talking about the same one that is tried to push upstream -here is 
+even a special repo for this patch: http://code.gns3.net/qemu-patches/log/7
+
+The developers are preoccupied with the development of GNS3 and don't 
+have manpower to submit patches for every software they rely on, so they 
+ask community to do so, and they also use already patched (by the 
+community!) qemu under Windows/MacOS for everyday.
+
+> 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.
+>
+I don't follow the development of qemu/gns3/qemu-patches/kvm/etc to know 
+everything what when and how many times it was submitted or accepted by 
+upstream. So I rely on the words of the developers of GNS3, and there 
+really don't know if it will be finally in qemu 1.0.x or 1.1.x or later.
+>>> 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".
+>
+
+