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

Mon Nov 14 14:53:43 CET 2011

On Sunday, 13 November 2011 23:32:45 Kamil Rytarowski wrote:
+> 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=openSUS
+> >>>> E%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).
+
+[...]
+
+> 
+> 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.
+
+You seem to imply that the only use of GNS3 is with this qemu patch.
+
+But I used GNS3 with just dynamips, and this issue of GNS3 not being usable at 
+all due to missing dynamips can really be solved quite quickly just by 
+shipping dynamips to updates.
+
+But, it looks like someone blindly imported gns3 and dynagen from Mandriva 
+without even understanding the use of these tools:
+
+$ rpm -q --suggests dynagen
+dynamips >= 0.2.8
+xterm
+
+(dynamips isn't explicitly required to be installed on the host with gns3 or 
+dynagen, as the hypervisor can be run on a different host than dynagen/GNS3).
+
+Regards,
+Buchan
+