Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On Tue, Jan 17, 2012 at 07:13:49AM +0100, Michael Scherer wrote: > I am not opposed on having the patch in cauldron however. Qemu 1.0 on Cauldron doesn't build. I suspect some kind of gcc problem as it has built on other distributions (fedora, opensuse). Filed https://bugs.mageia.org/show_bug.cgi?id=4164 against gcc (probably wrong, but need an expert). -- Regards, Olav
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
Le samedi 14 janvier 2012 à 21:10 +0100, Kamil Rytarowski a écrit : > Hi! > We have succeed to push the patch upstream > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b > > 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. That's a non bugfix update, so that doesn't fullfill the policy. I am not opposed on having the patch in cauldron however. -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
W dniu 14.11.2011 18:16, Michael Scherer pisze: 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. * 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. ( 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 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. 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". Hi! We have succeed to push the patch upstream http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0e0e7facc775e9bb020314f48751b3d09f316c8b 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.
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
qemu/GNS3 related post @Michael Scherer I've asked today the maintainers. There were patches for qemu since 0.11, and they had problems with Linux and BSD distros - only recently they decided to push it upstream, because only openSUSE was ready to patch qemu against required enhancements. So they started to campaign harder (ask the community to campaign) to include the patch into the upstream release. They have successfully pushed a patch against VirtualBox 4.1 and now they wait for Qemu, and hope to be inside 1.0 (but nobody is sure). My propsition is to patch (I will do that) GNS3 in Mageia1 against patch to disable qemu/qemuwrapper features in GUI and import into Mga1 through updates (by hands of my mentor) dynamips (requirement of GNS3).
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On 16.11.2011 12:53, Kamil Rytarowski wrote: On 16.11.2011 06:44, Buchan Milne wrote: On Wednesday, 16 November 2011 05:30:05 Kamil Rytarowski wrote: On 14.11.2011 14:53, Buchan Milne wrote: ( 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. It's possible to simulate and play without qemu. It should be "Suggested" by GNS3, but then what is the idea of suggesting qemu that isn't working at all? I simply don't know why to distribute a program that provides support in GUI for something that's not working. Uh, because you can use GNS3 for a lot of things without qemu. I used it for simulating a 4-router network with just dynamips. So, either I don't understand what you are trying to achieve, or why you want to *prevent* people from emulating routers with GNS3. If I do *import* dynamips into Mageia then I want to *prevent* people from emulating? No, I want to distribute fullfeatured software, where everything is *well-rounded* - and not *missing*/*broken*. And providing it via 3rd party repo as fullfeatured is much better than via official resources but limited. Is this also preventing? If someone will need it, then will find information how to use GNS3 with Mageia. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On 16.11.2011 06:44, Buchan Milne wrote: On Wednesday, 16 November 2011 05:30:05 Kamil Rytarowski wrote: On 14.11.2011 14:53, Buchan Milne wrote: ( 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. It's possible to simulate and play without qemu. It should be "Suggested" by GNS3, but then what is the idea of suggesting qemu that isn't working at all? I simply don't know why to distribute a program that provides support in GUI for something that's not working. Uh, because you can use GNS3 for a lot of things without qemu. I used it for simulating a 4-router network with just dynamips. So, either I don't understand what you are trying to achieve, or why you want to *prevent* people from emulating routers with GNS3. If I do *import* dynamips into Mageia then I want to *prevent* people from emulating? No, I want to distribute fullfeatured software, where everything is *well-rounded* - and not *missing*/*broken*. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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 hav
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On 14.11.2011 14:53, Buchan Milne wrote: ( 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. It's possible to simulate and play without qemu. (btw newer alpha release version supports in the same way VirtualBox) It should be "Suggested" by GNS3, but then what is the idea of suggesting qemu that isn't working at all? I simply don't know why to distribute a program that provides support in GUI for something that's not working. People can try to waste their time and configure qemuwrapper with our qemu... it's just a matter of time for a bugrequest on our bugzilla. In my opinion if we provide an application with so exposed (visible) support for working with qemu and we don't provide qemu itself then our quality of packages get lower. 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. Yes. 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). In theory yes. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On 14.11.2011 14:47, Buchan Milne wrote: On Saturday, 12 November 2011 22:11:31 Kamil Rytarowski wrote: 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%3 ATools 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...), Well, for me, I upgraded from Mandriva, and AFAIK there has been no new release of dynamips in the past year => grab the package from Mandriva for nwo, and log an enhancement bug (you can assign to me) for dynamips. Dynamips is already imported into Mageia - it needs a review from my mentor. This software is abandoned by its creator(s), and now without a maintainer. It is developed in free time by GNS3 developers. And NO. There was new "community" release in this year. This is officially a fork and de facto considered as the main branch http://sourceforge.net/projects/gns-3/files/Dynamips/0.2.8-RC3-community/ 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. Can you provide a bit more information on what GNS3 feature needs this patched qemu? I have in the past hooked up my kvm VMs to dynamips routers (before GNS3). GNS3 contain qemuwrapper to help emulate connections between multiple PCs through virtual (emulated) router on one single (but not limited to only one) machine. It uses UDP networking. You can chose your ready to use image for qemu - in GNS3 menu - (for example with JunOS - there are downloadable ready to use images with different OS) and immediately have it working. Honestly I haven't been testing it with qemu - I have probably to wait for possible upstream patch or make it finally myself. There are some official images http://sourceforge.net/projects/gns-3/files/Qemu%20Appliances/ Is this for Pix emulation, or just for launching generic virtual machines/emulated hardware as part of your lab? I really don't think the Pix emulation (I have never seen a maintained patch) is ready for anyone to include it ... but I haven't looked recently. For Pix there is as far as I know pemu. Pemu was for afaik for qemu 0.9.x series and it's to old to push to upstream. 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 Did you base it on the existing Mandriva package? I based on Mageia already existing package and then to make it working I based on others distros (especially openSUSE) and FreeBSD ports. and xdotool (this one suggested) - these I can maintain with my mentor, so I ask for patch qemu in stable versus UDP support. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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. > * 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. > > ( 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 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. > > 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". -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
On Saturday, 12 November 2011 22:11:31 Kamil Rytarowski wrote: > 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%3 > >> ATools > >> > >> 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...), Well, for me, I upgraded from Mandriva, and AFAIK there has been no new release of dynamips in the past year => grab the package from Mandriva for nwo, and log an enhancement bug (you can assign to me) for dynamips. > 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. Can you provide a bit more information on what GNS3 feature needs this patched qemu? I have in the past hooked up my kvm VMs to dynamips routers (before GNS3). Is this for Pix emulation, or just for launching generic virtual machines/emulated hardware as part of your lab? I really don't think the Pix emulation (I have never seen a maintained patch) is ready for anyone to include it ... but I haven't looked recently. > > 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 Did you base it on the existing Mandriva package? > and > xdotool (this one suggested) - these I can maintain with my mentor, so I > ask for patch qemu in stable versus UDP support. Regards, Buchan
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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.
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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. 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 ( and given the discussion on ml, it should be soon ) 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, so that's no. And again, maybe people could do more tests before pushing broken rpm to stable ( like gsn3 ). -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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. 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. Regards
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
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. And no patch unless it comes from upstream ( and even, I am not keen on backporting feature, better wait for stable release ). -- Michael Scherer
Re: [Mageia-dev] qemu new upstream release (1.0-rc1) and should we move from qemu-kvm to qemu?
Le 12/11/2011 16:44, Kamil Rytarowski a écrit : > Let me paste from the Arch Linux wiki documentation: > > -- > Difference between qemu and qemu-kvm > > Depending on your needs, you can choose either to install upstream qemu > or qemu-kvm from the official repositories. > > Upstream QEMU is a pure emulator, with no hardware acceleration. qemu > versions < 0.15.0 do have initial KVM support when QEMU is started with > the -enable-kvm parameter, but this implementation is still buggy and > nowhere as complete as in qemu-kvm, as many functions still do not work. > Starting with qemu version 0.15.0, the qemu-kvm tree has been fully > integrated with the qemu tree, and there should not be any difference > between qemu -enable-kvm and qemu-kvm. See the [QEMU changelog] for more > details. > > Upstream QEMU is capable of emulating many different platforms (arm, > i386, m68k, mips, ppc, sparc, x86_64, etc). On the other hand, you have > qemu-kvm, which is qemu (i386 and x86_64 architecture support only) with > KVM (kernel-based virtual machine) additions, allowing you to run > virtual machines at close to native speed. qemu-kvm is the version you > want if you have a CPU that supports hardware virtualization and you > only need to run virtual machines for the i386 and x86_64 architectures > (Linux, Windows, BSD, etc). > > Not all processors support KVM. You will need an x86-based machine > running a recent ( >= 2.6.22 ) Linux kernel on an Intel processor with > VT-x (virtualization technology) extensions or an AMD processor with SVM > (Secure Virtual Machine) extensions (also called AMD-V). Xen has a > complete list of compatible processors. For Intel processors, see also > the Intel® Virtualization Technology List. > > https://wiki.archlinux.org/index.php/QEMU#Difference_between_qemu_and_qemu-kvm > > -- > > > And now from the qemu changelog > ~~ > KVM > Common > > Countless fixes ported over from qemu-kvm, core is now shared with > that tree, i.e. has the same quality > Pimped up threading model, now fully synchronized with qemu-kvm tree > Removed dependency on external kernel headers, all supported KVM > features are now built into the binary > > http://wiki.qemu.org/ChangeLog/0.15#KVM > ~~ > > What do you think? Can we move? > > 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). You should also contact pterjan wo was maintainer for a long time -- Anne http://mageia.org
