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

Sun Nov 13 22:32:45 CET 2011

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.
+
+* 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.
+
+>   ( 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).
+> 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.
+>   so that's no. And again,
+> maybe people could do more tests before pushing broken rpm to stable
+> ( like gsn3 ).
+
+OK. So if gns3 can't be fixed for the stable - than should be removed 
+from the repos (for ISOs is to late).
+
+If we don't provide qemu patch, then gns3 should be removed from 
+Cauldron as well.
+
+I believe removing GNS3 is better than keeping it broken and.. irritate 
+people (I don't count the opinion of our quality). Later some 3rd party 
+repos can provide GNS3 and its dependencies.
+