diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-January/011362.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-January/011362.html | 185 |
1 files changed, 185 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-January/011362.html b/zarb-ml/mageia-dev/2012-January/011362.html new file mode 100644 index 000000000..55184899a --- /dev/null +++ b/zarb-ml/mageia-dev/2012-January/011362.html @@ -0,0 +1,185 @@ +<!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=%3C4F11E121.9020103%40gmx.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="011361.html"> + <LINK REL="Next" HREF="011408.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=%3C4F11E121.9020103%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>Sat Jan 14 21:10:09 CET 2012</I> + <P><UL> + <LI>Previous message: <A HREF="011361.html">[Mageia-dev] Working bug-buddy/abrt-like software? +</A></li> + <LI>Next message: <A HREF="011408.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#11362">[ date ]</a> + <a href="thread.html#11362">[ thread ]</a> + <a href="subject.html#11362">[ subject ]</a> + <a href="author.html#11362">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>W dniu 14.11.2011 18:16, Michael Scherer pisze: +><i> Le dimanche 13 novembre 2011 à 22:32 +0100, Kamil Rytarowski a écrit : +</I>>><i> On 13.11.2011 10:58, Michael Scherer wrote: +</I>>>><i> Le samedi 12 novembre 2011 à 21:11 +0100, Kamil Rytarowski a écrit : +</I>>>>><i> On 12.11.2011 20:20, Michael Scherer wrote: +</I>>>>>><i> Le samedi 12 novembre 2011 à 16:44 +0100, Kamil Rytarowski a écrit : +</I>>>>>><i> +</I>>>>>>><i> There is also one important patch missed in Mageia - +</I>>>>>>><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>>>>>>><i> dependency for the GNS3 simulator. OpenSUSE already includes it +</I>>>>>>><i> <A HREF="https://build.opensuse.org/package/files?package=qemu&project=openSUSE%3ATools">https://build.opensuse.org/package/files?package=qemu&project=openSUSE%3ATools</A> +</I>>>>>>><i> +</I>>>>>>><i> If nobody is against I will do it and contact the maintainer (misc). +</I>>>>>><i> I prefer to wait on the stable release ( ie, no rc1 ). +</I>>>>>><i> We will wait on stable version of qemu. +</I>>>>><i> OK +</I>>>>>><i> And no patch unless it comes from upstream ( and even, I am not keen on +</I>>>>>><i> backporting feature, better wait for stable release ). +</I>>>>>><i> +</I>>>>><i> GNS3 is already in stable! This package is broken - no dynamips (=no +</I>>>>><i> router emulation at all...), no patched qemu (no virtualization support +</I>>>>><i> at all...) According to the developers and their online documentation +</I>>>>><i> for package maintainers <A HREF="http://forum.gns3.net/post11571.html">http://forum.gns3.net/post11571.html</A> UDP patched +</I>>>>><i> Qemu is dependency/very important. +</I>>>><i> The fact that someone pushed a broken package is not a good reason to +</I>>>><i> add patches to qemu. +</I>>><i> OK, but I don't understand this. +</I>>><i> +</I>>><i> Why to keep defunct packages (this could be at least "major+ issue" on +</I>>><i> our bugzilla) in stable and don't even want to fix, ignore this academic +</I>>><i> software (with maybe overall 1 000 000* downloads and 100 000 regular +</I>>><i> users), and to support... the inadvisable opinion of Mageia around.. at +</I>>><i> least the GNS3 users. +</I>><i> Let me rephrase again. Everybody sooner or later think "that soft is +</I>><i> great, but why do not add just a small patch there". That's just one +</I>><i> patch, where is the problem ? +</I>><i> +</I>><i> The problem appear just after a few months, when the patch is still not +</I>><i> upstream, and that someone who do not know C, python whatever has to +</I>><i> take the software and maintain it. Or when someone who know how to +</I>><i> program lose time rediffing the patch instead of doing something more +</I>><i> useful. We face bugs that cannot be reproduced upstream, security +</I>><i> problem that could be added in non reviewed patch by devs. Fragmentation +</I>><i> in linux distributions are also caused by differents features, due to +</I>><i> patchs. +</I>><i> +</I>><i> All of this need to be avoided, and I think we have enough problems with +</I>><i> stuff that people do not want to take care of it to not add more burden, +</I>><i> be it under the form of a small patch. All big collections start by one +</I>><i> little stuff. +</I>><i> +</I>><i> +</I>>><i> * 799 968 Windows Downloads (just from the sourceforge mirrors) of the +</I>>><i> latest Windows binary of GNS3 (source +</I>>><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>>><i> +</I>>>><i> We have too many patches on a general scale, and I +</I>>>><i> do not want to end with a 2nd package like gdb. +</I>>>><i> +</I>>>><i> Patches make harder to upgrade, harder to make sure security is done +</I>>>><i> correctly, and harder to ensure stuff are working ( since we are on our +</I>>>><i> own when we patch something ). +</I>>>><i> So for the patches, make sure it is upstream +</I>>><i> It's not qemu upstream, it's GNS3 and its community upstream. +</I>><i> If you want to have a feature in qemu, the road is "push it upstream". +</I>><i> Once accepted upstream, it will sooner or later be in our packages. +</I>><i> +</I>>>><i> ( and given the discussion +</I>>>><i> on ml, it should be soon ) +</I>>><i> When I ask the developers, they don't know if qemu will include the +</I>>><i> patch at all and when (now or after one year) and they suggested to do +</I>>><i> the openSUSE way (today the most recommended and full featured Linux +</I>>><i> distro for GNS3). +</I>><i> Maybe we are not talking of the same patch, but I am talking of this +</I>><i> one : +</I>><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> +</I>><i> AFAIK, the patch have been accepted, just not committed yet. The last +</I>><i> mail were from 1 week ago. The only issue is that they are in freeze for +</I>><i> now, and the git web interface is down, and I do see the commit in my +</I>><i> checkout about it so far. +</I>><i> +</I>>>><i> and then in a tarball ( again, given that's a +</I>>>><i> rc 1, that should be ok soon ). +</I>>>><i> +</I>>>>><i> We must fix the package and provide at least not so heavy broken ones... +</I>>>>><i> +</I>>>>><i> I've prepared new version of GNS3, included into svn dynamips and +</I>>>>><i> xdotool (this one suggested) - these I can maintain with my mentor, so I +</I>>>>><i> ask for patch qemu in stable versus UDP support. +</I>>>><i> Updates are not supposed to get new features, +</I>>><i> Well this is a special case - the bugfix provides the feature, or the +</I>>><i> feature provides the bugfix. +</I>><i> People will always tell "it is a special case". We can always say that +</I>><i> any feature is a bugfix, provided we say that the bug is "I cannot do +</I>><i> that". +</I>><i> +</I>><i> +</I>Hi! +We have succeed to push the patch upstream +<A HREF="http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b">http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b</A> +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. +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="011361.html">[Mageia-dev] Working bug-buddy/abrt-like software? +</A></li> + <LI>Next message: <A HREF="011408.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#11362">[ date ]</a> + <a href="thread.html#11362">[ thread ]</a> + <a href="subject.html#11362">[ subject ]</a> + <a href="author.html#11362">[ 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> |