Re: [Mageia-dev] [changelog] [RPM] cauldron core/release php-pear-PHPUnit-3.6.3-2.mga2
On 15 November 2011 04:28, Mageia Team wrote: > spuhler 3.6.3-2.mga2: > + Revision: 167905 > - changed suggests into requires since they are needed The new version is now installable but makes mediawiki to be uninstalled due to pear(PHPUnit/Framework.php) now being missing
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
Le lundi 14 novembre 2011 à 19:29 -0300, Balcaen John a écrit : > Le lundi 14 novembre 2011 23:17:32 zezinho a écrit : > > Le lundi 14 novembre 2011 20:23:40, Juan Luis Baptiste a écrit : > > > So what is the final decision about this ? is there going to be an > > > update or not ? > > > > I vote no, let's wait for backports, like all other new versions. > i not agree at all because > - we did it for KDE SC 4.6 (upgrading from 4.6.3 to 4.6.5). > - the list of bug fixes (especially the number of crash & corruption fix) > - it's a *minor* version not a major one The policy is not about minor version, it is bugfixes only. Not everybody make the distinction between minor and major, especially for software developpers. And again, the question of QA is here. Since we didn't detect the regression ( and since there is so much crashes to fix, and sine everybody think that's important enough to bypass our policy, according to people in the thread ), how do people plan to make sure the most obvious one are corrected ? Do we have open bug reports about them, with clear reproducer ? And do at least someone plan to use kdenlive enough to say "this fixed the bug I have been seeing before" ? Or do we plan to do "it started, so it is good enough, let's ship it" ? -- Michael Scherer
Re: [Mageia-dev] (second attempt) suggesting sectool be dropped
Le lundi 14 novembre 2011 à 22:09 -0800, Robert M. Riches Jr. a écrit : > (New list subscriber...needed to fix registered email address to post...) > > I was asked to submit this suggestion to the mailing list: > > As a Mageia user, I believe msec was much better off with_OUT_ > sectool. In its present state, sectool is BADLY broken. It > whines for pages about file permissions that are exactly as they > should be. Can you be more specific ? > It leaves two orphaned gpg-agent processes. Fill bug report about this, that can surely be corrected by upstream. > It > leaves at least three files or directories cluttering up /tmp. Same for that. -- Michael Scherer
[Mageia-dev] (second attempt) suggesting sectool be dropped
(New list subscriber...needed to fix registered email address to post...) I was asked to submit this suggestion to the mailing list: As a Mageia user, I believe msec was much better off with_OUT_ sectool. In its present state, sectool is BADLY broken. It whines for pages about file permissions that are exactly as they should be. It leaves two orphaned gpg-agent processes. It leaves at least three files or directories cluttering up /tmp. I intend to remove sectool from my Mageia 1 system, forcibly if necessary. Until late October, msec functioned very nicely without sectool. On my system, I intend that msec will again have that opportunity. A one-line error message is vastly preferable to multiple pages of sectool's whining and a need to kill orphaned processes and delete orphaned files and/or directories. Thank you for considering this opinion. Robert Riches
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-MultiThread-0.900.0-1.mga2
2011/11/14 Thierry Vignaud > On 14 November 2011 21:30, Mageia Team > wrote: > > This module implements a Pipeline multithreading model. Several > concurrent threads are started -- one for each subroutine in the pipeline. > The subs and other MultiThread objects are daisy-chained together by > queues. The output queue of one step in the pipeline is the input queue of > the following step. > > Too long unwrapped description > Fix submitted.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-Sys-CPU-0.520.0-1.mga2
2011/11/15 Sandro CAZZANIGA > > 2011/11/14 Thierry Vignaud > >> On 14 November 2011 21:20, Mageia Team >> wrote: >> > In responce to a post on perlmonks.org, a module for counting the >> number of >> > CPU's on a system. Support has now also been added for type of CPU and >> > clock speed. While much of the code is from UNIX::Processors, win32 >> support >> > has been added (but not tested). >> >> this has nothing to do in description: >> >> > v0.45 - Corrected solaris support (Thanks Cloyce) >> > >> > EXPORT >> >None by default. >> > >> >> >> -- >> > R : Tu vois ! >> > > Q : Tu crois ? >> > > > R : Ça casse l'ordre chronologique de l'échange. >> > > > > Q : En quoi répondre au dessus est-il gênant ? >> > > OK I fix it. > Done :)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-Sys-CPU-0.520.0-1.mga2
2011/11/14 Thierry Vignaud > On 14 November 2011 21:20, Mageia Team > wrote: > > In responce to a post on perlmonks.org, a module for counting the > number of > > CPU's on a system. Support has now also been added for type of CPU and > > clock speed. While much of the code is from UNIX::Processors, win32 > support > > has been added (but not tested). > > this has nothing to do in description: > > > v0.45 - Corrected solaris support (Thanks Cloyce) > > > > EXPORT > >None by default. > > > > > -- > > R : Tu vois ! > > > Q : Tu crois ? > > > > R : Ça casse l'ordre chronologique de l'échange. > > > > > Q : En quoi répondre au dessus est-il gênant ? > OK I fix it.
Re: [Mageia-dev] HEADSUP: mariadb available for testing
On 11/11/2011 10:17, Maarten Vanraes wrote: > ... > A. provide both but with vendor preference > making sure one of them both is preferred should be ok, since they conflict > anyway, if a user installs the non-preferred one, she knows what she's doing. > ( I think a note could be added here for warning purposes ) > > B. only use mariadb anymore > => That's the easiest and safest option... > _IF_ mariadb works well. (which i'm sure we'll see in our testing) > (IMHO, if it worked for libreoffice, i don't see why not for mariadb) > > any opinions? testings? problems? I'm all for either of these. Especially B) if we can test it well enough. I rebuilt the package on mga1 without issues. Tests fine as well. Does anyone have any idea if the PBXT (Primebase) Storage Engine will be kept in MariaDB 5.5 (as it is in 5.1, 5.2, 5.3)? -- Sam Bailey Cyprix Enterprises Web: cyprix.com.au Em: cyp...@cyprix.com.au Mb: 0425 796 308
Re: [Mageia-dev] HEADSUP: mariadb available for testing
Maarten Vanraes a écrit : Hi all, mariadb-5.5.15-0.mga2 should be hitting the mirrors soon (at cauldron core/updates_testing). It's purpose is to be an alternative to mysql. for that reason, mariadb packages provide also the similar mysql targets. mariadb is intended to be a drop-in replacement for mysql, it goes so far to actually have the same files and ABI's as mysql. after looking at their forking process (it's not actually a full fork, they start from mysql and then patch), i've seen that it's actually very good for a drop-in replacement. There are a few differences ( http://kb.askmonty.org/en/mariadb-versus-mysql-compatibility ) but they are minor. I've done a few minor tests with amarok, akonadi, drupal and phpmyadmin (and of course mysql client). NOTE: mariadb provides actually most storage engines mysql provides as well, but also the original and unpatched MyISAM and InnoDB engines from mysql. On top of that, it has some extra storage engines. XtraDB, which is the drop-in replacement storage engine for Innodb, is essentially an innodb with extra patches from various sources, like google, facebook, etc... ( see http://kb.askmonty.org/en/mariadb-versus-mysql-features ) I've chosen to use mkrel 0 atm, because it's not a released version yet, I've talked extensively to mariadb developers, and they mentioned that they did 5.3 and 5.5 in parallel, so that 5.5 should be released as beta pretty soon. When i talked about our release schedule, they did mention that mariadb-5.5 should be final before februari. My plan is as follows: 1. provide testing package [DONE] 2. clean up spec file from mysql and file some patches upstream [DONE] 3. provide newer testing package when it's released as a alpha/beta 4. if testing is satisfactory (not breaking buildsystem or mysql) submit to core/release and get more testing. 5. if final 5.5 release is on time, have mariadb into mageia2 now there, we have a few options: considering that mariadb is essentially mysql + extra features, if we ship both mysql and mariadb, we should ensure that normal users don't go from mariadb to mysql. (if a storage engine would be used that's NOT in mysql, suddenly a few databases might not work, even though the data is still there.) A. provide both but with vendor preference making sure one of them both is preferred should be ok, since they conflict anyway, if a user installs the non-preferred one, she knows what she's doing. ( I think a note could be added here for warning purposes ) B. only use mariadb anymore => That's the easiest and safest option... _IF_ mariadb works well. (which i'm sure we'll see in our testing) (IMHO, if it worked for libreoffice, i don't see why not for mariadb) any opinions? testings? problems? I think it is a great idea, from all I've read. I've already been thinking of installing it in place of mysql. As for the options, I'm inclined to prefer a choice (option A), since some users could have problems with either, given that there are some (minor) incompatibilities. But if we have only one, at least those preferring the other could always go upstream. As for what was done with Libreoffice/Openoffice, the obsolete forced me to install upstream versions to have both installed. They have no file conflict. One can even have installed (but not run at the same time) different versions of upstream Libreoffice at the same time. (They recommend doing that for testing.) -- André
Re: [Mageia-dev] HEADSUP: mariadb available for testing
Op vrijdag 11 november 2011 00:17:47 schreef Maarten Vanraes: > any opinions? testings? problems? I guess it's perfect then, noone objects :-) I'm gonna wait a bit longer, and then submit to cauldron so it can have (more) testing
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
Le lundi 14 novembre 2011 23:17:32 zezinho a écrit : > Le lundi 14 novembre 2011 20:23:40, Juan Luis Baptiste a écrit : > > So what is the final decision about this ? is there going to be an > > update or not ? > > I vote no, let's wait for backports, like all other new versions. i not agree at all because - we did it for KDE SC 4.6 (upgrading from 4.6.3 to 4.6.5). - the list of bug fixes (especially the number of crash & corruption fix) - it's a *minor* version not a major one If the policy is to *stricly* push only new versions (& minor versions) in backports then it should be wrote somewhere so i won't go on updating KDE SC on next mageia to the last release (especially we won't go to KDE SC 4.8 but stick with KDE SC 4.7 since i won't be able to provide the minor bug fixes release for KDE SC 4.8 ) Regards, -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-MultiThread-0.900.0-1.mga2
On 14 November 2011 21:30, Mageia Team wrote: > This module implements a Pipeline multithreading model. Several concurrent > threads are started -- one for each subroutine in the pipeline. The subs and > other MultiThread objects are daisy-chained together by queues. The output > queue of one step in the pipeline is the input queue of the following step. Too long unwrapped description
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-Sys-CPU-0.520.0-1.mga2
On 14 November 2011 21:20, Mageia Team wrote: > In responce to a post on perlmonks.org, a module for counting the number of > CPU's on a system. Support has now also been added for type of CPU and > clock speed. While much of the code is from UNIX::Processors, win32 support > has been added (but not tested). this has nothing to do in description: > v0.45 - Corrected solaris support (Thanks Cloyce) > > EXPORT > None by default. > > kharec 0.520.0-1.mga2: > + Revision: 167815 > - imported package perl-Sys-CPU -- > R : Tu vois ! > > Q : Tu crois ? > > > R : Ça casse l'ordre chronologique de l'échange. > > > > Q : En quoi répondre au dessus est-il gênant ?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
Le lundi 14 novembre 2011 20:23:40, Juan Luis Baptiste a écrit : > So what is the final decision about this ? is there going to be an > update or not ? I vote no, let's wait for backports, like all other new versions.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
On Wed, Nov 9, 2011 at 5:39 PM, Angelo Naselli wrote: > I mean if someone, like me, spends his time to fix some but can't do an update > that is time lost, and what's worst the bug still stays opened... > Is that good? > I think we should always consider case by case, but also the story a potencial > update had... > So what is the final decision about this ? is there going to be an update or not ? Juancho
Re: [Mageia-dev] New wiki finally online
Le 2011-11-14 12:34, Oliver Burger a écrit : After quite some work in the last weeks the new wiki is finally available! Check it out at https://wiki.mageia.org Until now only the English wiki is online, other will follow soon. We did import all (or most) of the contents from the old wiki and tried to bring some structure into it. As you can see, there is almost no documentation for the end user till now but the documentation team will start changing that. If you would like to help us on that, just join the doc team in its meeting tommorow at 19.00 UTC in #mageia-doc on the Freenode irc netwoork. And please have a look at https://wiki.mageia.org/en/Wiki_and_Documentation#Page_naming before starting to create pages on the new wiki. We do want to keep some kind of order in it... ee also the blog post about it on http://blog.mageia.org/en/ Cheers, Oliver Congrats on all those who put the wiki together. Very elegant and simple to read. You are awesome! Marc
[Mageia-dev] New wiki finally online
After quite some work in the last weeks the new wiki is finally available! Check it out at https://wiki.mageia.org Until now only the English wiki is online, other will follow soon. We did import all (or most) of the contents from the old wiki and tried to bring some structure into it. As you can see, there is almost no documentation for the end user till now but the documentation team will start changing that. If you would like to help us on that, just join the doc team in its meeting tommorow at 19.00 UTC in #mageia-doc on the Freenode irc netwoork. And please have a look at https://wiki.mageia.org/en/Wiki_and_Documentation#Page_naming before starting to create pages on the new wiki. We do want to keep some kind of order in it... ee also the blog post about it on http://blog.mageia.org/en/ Cheers, Oliver
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] [info] texlive on mandriva: what not to do ;)
On Mon, Nov 14, 2011 at 3:00 PM, EatDirt wrote: > Hi guys, > I still have a computer on mandriva cooker, and they did the split of > texlive in many packages (a long standing discussion on cooker as far as > remember due to the size of texlive). > > Now, I don't know if someone there is actually using "texlive", but the > resulting monster is completely unusable. Like, if you want to process a > document, you have to resort to ten of urpmf to find the required files in > independent packages that have names not really related to their content > (and there are literally hundred of them!!). Which means no chance for > normal people to use latex anymore :-/ > > So, from userland, please let's not do that. I am happy to give my user's > experience if someone would like to split texlive of course! > > cheers, > Chris. so maybe we won't follow :) I am still asking myself ( started some weeks ago ) how to proceed well. I think i should contact fedora texlive maintener to know his feeling about texlive packaging. Btw tks giving us your feeling ( this is appreciable ).
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] dos2unix
On 11/14/2011 03:49 AM, José Jorge wrote: We use for now a dos2unix unmaintained since 2008 : http://hany.sk/~hany/_data/hd2u/?C=M;O=D Can I switch to a maintained version, used by Fedora and Debian : http://waterlan.home.xs4all.nl/dos2unix.html zezinho I'm OK with that, but how much maintenance does dos2unix really need ? :-)
[Mageia-dev] [info] texlive on mandriva: what not to do ;)
Hi guys, I still have a computer on mandriva cooker, and they did the split of texlive in many packages (a long standing discussion on cooker as far as remember due to the size of texlive). Now, I don't know if someone there is actually using "texlive", but the resulting monster is completely unusable. Like, if you want to process a document, you have to resort to ten of urpmf to find the required files in independent packages that have names not really related to their content (and there are literally hundred of them!!). Which means no chance for normal people to use latex anymore :-/ So, from userland, please let's not do that. I am happy to give my user's experience if someone would like to split texlive of course! cheers, Chris.
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] Debugging boot times
On 10 November 2011 11:11, Colin Guthrie wrote: >> Should be done automatically in %post. >> See memtest86+ for example > > Well I thought about this, but memtest86+ adds a totally new entry, > should we do the same here, should it only be done for the current > kernel, how would it handle kernel updates, etc. > > At present I'm happy to enable it manually when needed, but if people > want it to be more automatic and appear as a boot entry in grub, then > I'm happy enough to do that. Like we have a "linux safe" entry only for the main entry (the vmlinuz symlink) and not for every installed kernels (multiples instances of multiples favors (main one, tmb, rt, linus, ...)), I think we can have a "linux boot timing" entry too.
Re: [Mageia-dev] Consolidation of the spelling tools in Mageia
Thomas Spuhler writes: > > One other remark: Abiword depends on Enchant for its spellchecking > > capabilities. > I would support using one spell-checker. We don't have the bandwidth to do > both. We still have > 2000 packages without a maintainer. Just to be clear here: Enchant isn't a full-fledged spell checker but a thin wrapper around one or more spell checkers such as aspell or hunspell. As such, it requires very little maintenance in return for very useful functionality. regards, -- Reinout van Schouwen
Re: [Mageia-dev] dos2unix
José Jorge skrev 14.11.2011 10:49: We use for now a dos2unix unmaintained since 2008 : http://hany.sk/~hany/_data/hd2u/?C=M;O=D Can I switch to a maintained version, used by Fedora and Debian : http://waterlan.home.xs4all.nl/dos2unix.html Yep. go for it. -- Thomas
[Mageia-dev] dos2unix
We use for now a dos2unix unmaintained since 2008 : http://hany.sk/~hany/_data/hd2u/?C=M;O=D Can I switch to a maintained version, used by Fedora and Debian : http://waterlan.home.xs4all.nl/dos2unix.html zezinho
