summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-November/009575.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/2011-November/009575.html')
-rw-r--r--zarb-ml/mageia-dev/2011-November/009575.html260
1 files changed, 260 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-November/009575.html b/zarb-ml/mageia-dev/2011-November/009575.html
new file mode 100644
index 000000000..5a1314720
--- /dev/null
+++ b/zarb-ml/mageia-dev/2011-November/009575.html
@@ -0,0 +1,260 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20qemu%20new%20upstream%20release%20%281.0-rc1%29%20and%20should%20we%0A%20move%20from%20qemu-kvm%20to%20qemu%3F&In-Reply-To=%3C4EC338FB.8030504%40gmx.com%3E">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="009526.html">
+ <LINK REL="Next" HREF="009588.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?</H1>
+ <B>Kamil Rytarowski</B>
+ <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20qemu%20new%20upstream%20release%20%281.0-rc1%29%20and%20should%20we%0A%20move%20from%20qemu-kvm%20to%20qemu%3F&In-Reply-To=%3C4EC338FB.8030504%40gmx.com%3E"
+ TITLE="[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?">n54 at gmx.com
+ </A><BR>
+ <I>Wed Nov 16 05:15:55 CET 2011</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="009526.html">[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
+</A></li>
+ <LI>Next message: <A HREF="009588.html">[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#9575">[ date ]</a>
+ <a href="thread.html#9575">[ thread ]</a>
+ <a href="subject.html#9575">[ subject ]</a>
+ <a href="author.html#9575">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>On 14.11.2011 18:16, Michael Scherer wrote:
+&gt;<i> Le dimanche 13 novembre 2011 &#224; 22:32 +0100, Kamil Rytarowski a &#233;crit :
+</I>&gt;&gt;<i> On 13.11.2011 10:58, Michael Scherer wrote:
+</I>&gt;&gt;&gt;<i> Le samedi 12 novembre 2011 &#224; 21:11 +0100, Kamil Rytarowski a &#233;crit :
+</I>&gt;&gt;&gt;&gt;<i> On 12.11.2011 20:20, Michael Scherer wrote:
+</I>&gt;&gt;&gt;&gt;&gt;<i> Le samedi 12 novembre 2011 &#224; 16:44 +0100, Kamil Rytarowski a &#233;crit :
+</I>&gt;&gt;&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> There is also one important patch missed in Mageia -
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> <A HREF="http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html">http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00787.html</A> it's
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> dependency for the GNS3 simulator. OpenSUSE already includes it
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> <A HREF="https://build.opensuse.org/package/files?package=qemu&amp;project=openSUSE%3ATools">https://build.opensuse.org/package/files?package=qemu&amp;project=openSUSE%3ATools</A>
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;&gt;&gt;&gt;<i> If nobody is against I will do it and contact the maintainer (misc).
+</I>&gt;&gt;&gt;&gt;&gt;<i> I prefer to wait on the stable release ( ie, no rc1 ).
+</I>&gt;&gt;&gt;&gt;&gt;<i> We will wait on stable version of qemu.
+</I>&gt;&gt;&gt;&gt;<i> OK
+</I>&gt;&gt;&gt;&gt;&gt;<i> And no patch unless it comes from upstream ( and even, I am not keen on
+</I>&gt;&gt;&gt;&gt;&gt;<i> backporting feature, better wait for stable release ).
+</I>&gt;&gt;&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;&gt;<i> GNS3 is already in stable! This package is broken - no dynamips (=no
+</I>&gt;&gt;&gt;&gt;<i> router emulation at all...), no patched qemu (no virtualization support
+</I>&gt;&gt;&gt;&gt;<i> at all...) According to the developers and their online documentation
+</I>&gt;&gt;&gt;&gt;<i> for package maintainers <A HREF="http://forum.gns3.net/post11571.html">http://forum.gns3.net/post11571.html</A> UDP patched
+</I>&gt;&gt;&gt;&gt;<i> Qemu is dependency/very important.
+</I>&gt;&gt;&gt;<i> The fact that someone pushed a broken package is not a good reason to
+</I>&gt;&gt;&gt;<i> add patches to qemu.
+</I>&gt;&gt;<i> OK, but I don't understand this.
+</I>&gt;&gt;<i>
+</I>&gt;&gt;<i> Why to keep defunct packages (this could be at least &quot;major+ issue&quot; on
+</I>&gt;&gt;<i> our bugzilla) in stable and don't even want to fix, ignore this academic
+</I>&gt;&gt;<i> software (with maybe overall 1 000 000* downloads and 100 000 regular
+</I>&gt;&gt;<i> users), and to support... the inadvisable opinion of Mageia around.. at
+</I>&gt;&gt;<i> least the GNS3 users.
+</I>&gt;<i> Let me rephrase again. Everybody sooner or later think &quot;that soft is
+</I>&gt;<i> great, but why do not add just a small patch there&quot;. That's just one
+</I>&gt;<i> patch, where is the problem ?
+</I>&gt;<i>
+</I>&gt;<i> The problem appear just after a few months, when the patch is still not
+</I>&gt;<i> upstream, and that someone who do not know C, python whatever has to
+</I>&gt;<i> take the software and maintain it. Or when someone who know how to
+</I>&gt;<i> program lose time rediffing the patch instead of doing something more
+</I>&gt;<i> useful. We face bugs that cannot be reproduced upstream, security
+</I>&gt;<i> problem that could be added in non reviewed patch by devs. Fragmentation
+</I>&gt;<i> in linux distributions are also caused by differents features, due to
+</I>&gt;<i> patchs.
+</I>&gt;<i>
+</I>&gt;<i> All of this need to be avoided, and I think we have enough problems with
+</I>&gt;<i> stuff that people do not want to take care of it to not add more burden,
+</I>&gt;<i> be it under the form of a small patch. All big collections start by one
+</I>&gt;<i> little stuff.
+</I>&gt;<i>
+</I>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:
+
+&gt;<i> The problem appear just after a few months, when the patch is still not
+</I>&gt;<i> upstream, and that someone who do not know C, python whatever has to
+</I>&gt;<i> take the software and maintain it. Or when someone who know how to
+</I>&gt;<i> program lose time rediffing the patch instead of doing something more
+</I>&gt;<i> useful
+</I>
+and ALSO
+
+&gt;<i> We face bugs that cannot be reproduced upstream
+</I>
+//Well I am more aware in this case due to lack o features/broken
+GUI/GNS3 then security problems...
+
+I like this point:
+
+&gt;<i> All of this need to be avoided, and I think we have enough problems with
+</I>&gt;<i> stuff that people do not want to take care of it to not add more burden,
+</I>&gt;<i> be it under the form of a small patch. All big collections start by one
+</I>&gt;<i> little stuff
+</I>
+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.
+&gt;&gt;<i> * 799 968 Windows Downloads (just from the sourceforge mirrors) of the
+</I>&gt;&gt;<i> latest Windows binary of GNS3 (source
+</I>&gt;&gt;<i> <A HREF="http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/">http://sourceforge.net/projects/gns-3/files/GNS3/0.7.4/</A>)
+</I>&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> We have too many patches on a general scale, and I
+</I>&gt;&gt;&gt;<i> do not want to end with a 2nd package like gdb.
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;<i> Patches make harder to upgrade, harder to make sure security is done
+</I>&gt;&gt;&gt;<i> correctly, and harder to ensure stuff are working ( since we are on our
+</I>&gt;&gt;&gt;<i> own when we patch something ).
+</I>&gt;&gt;&gt;<i> So for the patches, make sure it is upstream
+</I>&gt;&gt;<i> It's not qemu upstream, it's GNS3 and its community upstream.
+</I>&gt;<i> If you want to have a feature in qemu, the road is &quot;push it upstream&quot;.
+</I>&gt;<i> Once accepted upstream, it will sooner or later be in our packages.
+</I>&gt;<i>
+</I>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.
+
+
+&gt;&gt;&gt;<i> ( and given the discussion
+</I>&gt;&gt;&gt;<i> on ml, it should be soon )
+</I>&gt;&gt;<i> When I ask the developers, they don't know if qemu will include the
+</I>&gt;&gt;<i> patch at all and when (now or after one year) and they suggested to do
+</I>&gt;&gt;<i> the openSUSE way (today the most recommended and full featured Linux
+</I>&gt;&gt;<i> distro for GNS3).
+</I>&gt;<i> Maybe we are not talking of the same patch, but I am talking of this
+</I>&gt;<i> one :
+</I>&gt;<i> <A HREF="http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html">http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.html</A>
+</I>I'm talking about the same one that is tried to push upstream -here is
+even a special repo for this patch: <A HREF="http://code.gns3.net/qemu-patches/log/7">http://code.gns3.net/qemu-patches/log/7</A>
+
+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.
+
+&gt;<i> AFAIK, the patch have been accepted, just not committed yet. The last
+</I>&gt;<i> mail were from 1 week ago. The only issue is that they are in freeze for
+</I>&gt;<i> now, and the git web interface is down, and I do see the commit in my
+</I>&gt;<i> checkout about it so far.
+</I>&gt;<i>
+</I>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.
+&gt;&gt;&gt;<i> and then in a tarball ( again, given that's a
+</I>&gt;&gt;&gt;<i> rc 1, that should be ok soon ).
+</I>&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;&gt;<i> We must fix the package and provide at least not so heavy broken ones...
+</I>&gt;&gt;&gt;&gt;<i>
+</I>&gt;&gt;&gt;&gt;<i> I've prepared new version of GNS3, included into svn dynamips and
+</I>&gt;&gt;&gt;&gt;<i> xdotool (this one suggested) - these I can maintain with my mentor, so I
+</I>&gt;&gt;&gt;&gt;<i> ask for patch qemu in stable versus UDP support.
+</I>&gt;&gt;&gt;<i> Updates are not supposed to get new features,
+</I>&gt;&gt;<i> Well this is a special case - the bugfix provides the feature, or the
+</I>&gt;&gt;<i> feature provides the bugfix.
+</I>&gt;<i> People will always tell &quot;it is a special case&quot;. We can always say that
+</I>&gt;<i> any feature is a bugfix, provided we say that the bug is &quot;I cannot do
+</I>&gt;<i> that&quot;.
+</I>&gt;<i>
+</I>
+</PRE>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="009526.html">[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
+</A></li>
+ <LI>Next message: <A HREF="009588.html">[Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#9575">[ date ]</a>
+ <a href="thread.html#9575">[ thread ]</a>
+ <a href="subject.html#9575">[ subject ]</a>
+ <a href="author.html#9575">[ author ]</a>
+ </LI>
+ </UL>
+
+<hr>
+<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
+mailing list</a><br>
+</body></html>