Re: [Mageia-dev] [changelog] [RPM] cauldron core/release arj-3.10.22-7.mga2
Le lundi 21 novembre 2011 00:19:32, Thierry Vignaud a écrit : On 20 November 2011 21:43, Mageia Team buildsystem-dae...@mageia.org wrote: zezinho zezinho 3.10.22-7.mga2: + Revision: 170079 - use fedora and debian patches to fix build - imported package arj Are there still usages for that 30 years after :-) ? I've got a HD floppy (yes, HD: 1.44MB, letters meaning change over time) with some old DOS things packed with it. So yes, I have the usage ;-) And it is more 20 than 30 years...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release arj-3.10.22-7.mga2
On 21 November 2011 09:18, zezinho lists.jjo...@free.fr wrote: zezinho zezinho 3.10.22-7.mga2: + Revision: 170079 - use fedora and debian patches to fix build - imported package arj Are there still usages for that 30 years after :-) ? I've got a HD floppy (yes, HD: 1.44MB, letters meaning change over time) with some old DOS things packed with it. So yes, I have the usage ;-) And it is more 20 than 30 years... Guess it depends on people's usages... Last times I'd used it was around 1992-3... Argh you're right, that means 20 years :-(
Re: [Mageia-dev] Changing default media names
Le 21/11/2011 01:51, Maarten Vanraes a écrit : in short: let rpmdrake show this short description (which looks more or less like the current name, but clearer) where the current name is now and i'm ok with this proposal. Better formulation: let's use different strings for different purposes, instead of a single generic media 'name' with unclear semantic: - an identifier for computer, without any metacharacter, to be used in command line - a description for humans, to be displayed in GUIs, without any kind of character restriction -- BOFH excuse #368: Failure to adjust for daylight savings time.
Re: [Mageia-dev] Changing default media names
Le lundi 21 novembre 2011 09:57:20, Guillaume Rousse a écrit : Le 21/11/2011 01:51, Maarten Vanraes a écrit : in short: let rpmdrake show this short description (which looks more or less like the current name, but clearer) where the current name is now and i'm ok with this proposal. Better formulation: let's use different strings for different purposes, instead of a single generic media 'name' with unclear semantic: - an identifier for computer, without any metacharacter, to be used in command line - a description for humans, to be displayed in GUIs, without any kind of character restriction That's it :) Samuel
Re: [Mageia-dev] Changing default media names
On Mon, 21 Nov 2011, Samuel Verschelde wrote: Le lundi 21 novembre 2011 09:57:20, Guillaume Rousse a écrit : Le 21/11/2011 01:51, Maarten Vanraes a écrit : in short: let rpmdrake show this short description (which looks more or less like the current name, but clearer) where the current name is now and i'm ok with this proposal. Better formulation: let's use different strings for different purposes, instead of a single generic media 'name' with unclear semantic: - an identifier for computer, without any metacharacter, to be used in command line - a description for humans, to be displayed in GUIs, without any kind of character restriction That's it :) Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ?
Re: [Mageia-dev] Changing default media names
2011/11/21 nicolas vigier bo...@mars-attacks.org: Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? +1
Re: [Mageia-dev] Changing default media names
Le lundi 21 novembre 2011 à 10:32 +0100, nicolas vigier a écrit : On Mon, 21 Nov 2011, Samuel Verschelde wrote: Le lundi 21 novembre 2011 09:57:20, Guillaume Rousse a écrit : Le 21/11/2011 01:51, Maarten Vanraes a écrit : in short: let rpmdrake show this short description (which looks more or less like the current name, but clearer) where the current name is now and i'm ok with this proposal. Better formulation: let's use different strings for different purposes, instead of a single generic media 'name' with unclear semantic: - an identifier for computer, without any metacharacter, to be used in command line - a description for humans, to be displayed in GUIs, without any kind of character restriction That's it :) Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? Yeah, let's stop abusing identifier as a user friendly description. -- Michael Scherer
Re: [Mageia-dev] Changing default media names
Le lundi 21 novembre 2011 10:32:11, nicolas vigier a écrit : Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? Yes.
[Mageia-dev] Fail during boot process - depricated config file . .
Using latest Cauldron - I get a boot error on three different machines: boot.log:Mounting local filesystems: WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log:WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. boot.log:WARNING: All config files need .conf: /etc/modprobe.d/lockd.drakx, it will be ignored in a future release. boot.log:WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log:WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. boot.log:WARNING: All config files need .conf: /etc/modprobe.d/lockd.drakx, it will be ignored in a future release. boot.log.1:modprobe: WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log.1:modprobe: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. I could not find a bug report in bugzilla - should I make one?? Thx, R.Fox
Re: [Mageia-dev] Fail during boot process - depricated config file . .
Le lundi 21 novembre 2011 à 12:10 +0100, Robert Fox a écrit : Using latest Cauldron - I get a boot error on three different machines: boot.log:Mounting local filesystems: WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log:WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. boot.log:WARNING: All config files need .conf: /etc/modprobe.d/lockd.drakx, it will be ignored in a future release. boot.log:WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log:WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. boot.log:WARNING: All config files need .conf: /etc/modprobe.d/lockd.drakx, it will be ignored in a future release. boot.log.1:modprobe: WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log.1:modprobe: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. I could not find a bug report in bugzilla - should I make one?? Really ? https://bugs.mageia.org/buglist.cgi?quicksearch=%2Fetc% 2Fmodprobe.conf :) and this one in the list https://bugs.mageia.org/show_bug.cgi?id=2784 Thx, R.Fox -- Manuel Hiebel http://netiquette.fr/
Re: [Mageia-dev] Fail during boot process - depricated config file . .
Am 21.11.2011 12:10, schrieb Robert Fox: Using latest Cauldron - I get a boot error on three different machines: boot.log:Mounting local filesystems: WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log:WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. boot.log:WARNING: All config files need .conf: /etc/modprobe.d/lockd.drakx, it will be ignored in a future release. boot.log:WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log:WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. boot.log:WARNING: All config files need .conf: /etc/modprobe.d/lockd.drakx, it will be ignored in a future release. boot.log.1:modprobe: WARNING: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d boot.log.1:modprobe: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. I could not find a bug report in bugzilla - should I make one?? Thx, R.Fox These are no Fails these are warnings, and not only for bootup, but also during urpmi usage, f.ex. when installing a new kernel ... Has already been reported: https://bugs.mageia.org/show_bug.cgi?id=2784
Re: [Mageia-dev] Changing default media names
On Mon, 21 Nov 2011, Luc Menut wrote: Le 20/11/2011 19:43, nicolas vigier a écrit : I suggest we replace them on Cauldron and later versions with names like this : cauldron/x86_64/core/release cauldron/x86_64/debug/core/release cauldron/x86_64/core/updates cauldron/x86_64/debug/core/updates cauldron/x86_64/core/backports cauldron/x86_64/nonfree/release cauldron/i586/core/release cauldron/i586/core/updates ... I assume that they are only templates and not the real unique identifiers. If not, how do you plan to manage multiple servers for a same media? This is the default names that will be used when using urpmi.addmedia --distrib. If the name is already used, urpmi.addmedia currently prepend a number to the name. It is also possible to specify a name when using urpmi.addmedia --distrib. In that case, a string like this is prepended : (nameN) with N a number incremented for each media. Maybe this could be changed to prefix with name- instead.
Re: [Mageia-dev] Changing default media names
On Mon, 21 Nov 2011, nicolas vigier wrote: On Mon, 21 Nov 2011, Luc Menut wrote: Le 20/11/2011 19:43, nicolas vigier a écrit : I suggest we replace them on Cauldron and later versions with names like this : cauldron/x86_64/core/release cauldron/x86_64/debug/core/release cauldron/x86_64/core/updates cauldron/x86_64/debug/core/updates cauldron/x86_64/core/backports cauldron/x86_64/nonfree/release cauldron/i586/core/release cauldron/i586/core/updates ... I assume that they are only templates and not the real unique identifiers. If not, how do you plan to manage multiple servers for a same media? This is the default names that will be used when using urpmi.addmedia --distrib. If the name is already used, urpmi.addmedia currently prepend a number to the name. It is also possible to specify a name when using urpmi.addmedia --distrib. In that case, a string like this is prepended : (nameN) with N a number incremented for each media. Maybe this could be changed to prefix with name- instead. s/prepend/append/
[Mageia-dev] perl-ExtUtils-XSpp-0.160.200-2.mga2
hi, If someone have the time in the afternoon, we have a little bug in /usr/binxspp (which is a part of perl-ExtUtils-XSpp): */usr/bin/xspp : /usr/bin/perl5.14.1 : mauvais interpréteur: Aucun fichier ou dossier de ce type* As you can see, it's just a bad interpreter error. I think that we can replace it by *#!/usr/bin/perl* (I can do it myself, but I am at the University today, so only http protocol can go in/out ...). Thanks.
Re: [Mageia-dev] perl-ExtUtils-XSpp-0.160.200-2.mga2
hi, On 11/11/21 15:12 +0100, Sandro CAZZANIGA wrote: If someone have the time in the afternoon, we have a little bug in /usr/binxspp (which is a part of perl-ExtUtils-XSpp): */usr/bin/xspp : /usr/bin/perl5.14.1 : mauvais interpréteur: Aucun fichier ou dossier de ce type* As you can see, it's just a bad interpreter error. I think that we can replace it by *#!/usr/bin/perl* (I can do it myself, but I am at the University today, so only http protocol can go in/out ...). no, that's not the correct fix. the correct fix is to just rebuild the package: the installed script will then use the path to the interpreter that was present on the bs, which is the latest one. i just re-submitted it. jérôme
Re: [Mageia-dev] perl-ExtUtils-XSpp-0.160.200-2.mga2
Le 21/11/2011 15:23, Jerome Quelin a écrit : hi, On 11/11/21 15:12 +0100, Sandro CAZZANIGA wrote: If someone have the time in the afternoon, we have a little bug in /usr/binxspp (which is a part of perl-ExtUtils-XSpp): */usr/bin/xspp : /usr/bin/perl5.14.1 : mauvais interpréteur: Aucun fichier ou dossier de ce type* As you can see, it's just a bad interpreter error. I think that we can replace it by *#!/usr/bin/perl* (I can do it myself, but I am at the University today, so only http protocol can go in/out ...). no, that's not the correct fix. the correct fix is to just rebuild the package: the installed script will then use the path to the interpreter that was present on the bs, which is the latest one. I wouldn't call this a better fix. Hardcoding a specific interpreter path is a bit pointless, and force us to rebuild the package foreach new perl minor release. -- Un chômeur en fin de droit pendu dans le Maine-et-Loire, C'est un trader à New York qui reprend espoir.
[Mageia-dev] alpha 1 release info preparation
Hi there, alpha1 ISOs are on their way for this Friday (Nov. 25th) and we need to gather and prepare info about: - what ISOs will be available, - what's new and how to handle it (systemd, but not only) - what's is already known not to work, - what to test and how to report bugs. So please see https://wiki.mageia.org/en/Mageia_2_alpha1 as the canvas and update as you see fit. This will serve as a basis for the release announcement. I'll see with marcom and web teams for the other parts of the release. Thanks! Romain
Re: [Mageia-dev] [packages-commits] [170580] imported package deskbar-applet
2011/11/21 r...@mageia.org: Revision 170580 Author kamil Date 2011-11-21 19:23:20 +0100 (Mon, 21 Nov 2011) Log Message imported package deskbar-applet May I ask why? IIUC it's dead upstream, there isn't even a git repo anymore in Gnome's GIT..
[Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Hi, I was reading cooker ML a few days ago (yes I know, it's a strange idea) when I've read that Mandriva has stopped using (and thereof developing it). They have switched to NetworkManager (you all know this tool). What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? Just a precision, I use Networkmanager with mageia1 on my laptop (due to the VPN we use at work) Regards -- Marianne Lombard (Jehane) Mageia User - Mageia french translation team Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett
Re: [Mageia-dev] [packages-commits] [170580] imported package deskbar-applet
On 21.11.2011 19:41, Jani Välimaa wrote: 2011/11/21r...@mageia.org: Revision 170580 Author kamil Date 2011-11-21 19:23:20 +0100 (Mon, 21 Nov 2011) Log Message imported package deskbar-applet May I ask why? IIUC it's dead upstream, there isn't even a git repo anymore in Gnome's GIT.. Yes you are right, I was suggested by the already existing resources on-line, even link to the git repo (but I hadn't try to access it). I've checked now their mailing list and the author has declared to stop development of it (due to the newer Gnome desktop environment). I'm going to remove it. Thanks!
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. And if you look in bug 2160, it appears that we have no maintainer for it.
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 21 November 2011 20:02, Frank Griffin f...@roadrunner.com wrote: On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. And if you look in bug 2160, it appears that we have no maintainer for it. It has serious problems with wireless - then I guess that that means that drakx-net is still in the mental asylum. Its handling of all things wireless for me has been infinitely more polished than drakx-net
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Le lundi 21 novembre 2011 à 15:02 -0500, Frank Griffin a écrit : On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Or just google for NM problems (there's a ton of people having trouble with it). But we have also a lot a bugs against drakx-net (I guess the maintainer is busy like all us) https://bugs.mageia.org/buglist.cgi?query_format=advancedfield0-0-0=cf_rpmpkgbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtype0-0-0=substringvalue0-0-0=drakx-net -- Manuel Hiebel http://netiquette.fr/
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
2011/11/21 Frank Griffin f...@roadrunner.com: On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Bug 856 is grub related so i guess we can forget this one ;o) Bug 2416 was submitted when nm 0.9 (well beta) was not patched to support our sysvinit script, we'll still waiting for an answer of the initial report. So 2160 is the only bug remaining here but i think it's probably the same bug aka it was reported when nm was not supporting sysvinit Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. It's happening with the *current* networkmanager of with the beta when the patch was not applied because blino did fix the patch now nm respect the ifcfg- command line. And if you look in bug 2160, it appears that we have no maintainer for it. Well there's a lot of packages without maintainer ... -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 21/11/11 20:15, John Balcaen wrote: 2011/11/21 Frank Griffinf...@roadrunner.com: On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Bug 856 is grub related so i guess we can forget this one ;o) Bug 2416 was submitted when nm 0.9 (well beta) was not patched to support our sysvinit script, we'll still waiting for an answer of the initial report. So 2160 is the only bug remaining here but i think it's probably the same bug aka it was reported when nm was not supporting sysvinit Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. It's happening with the *current* networkmanager of with the beta when the patch was not applied because blino did fix the patch now nm respect the ifcfg- command line. And if you look in bug 2160, it appears that we have no maintainer for it. Well there's a lot of packages without maintainer ... If NM is adopted could we also package a tainted pppd capable of connecting to PPTP VPN's please. Thankyou Claire
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Am 21.11.2011 21:02, schrieb Frank Griffin: On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. And if you look in bug 2160, it appears that we have no maintainer for it. I see this completely differently - I changed to NetworkManager, as I had massive problems with wireless connections (or actually no connections) with drax-net - NetworkManager works fine for me over here (Atheros with ath9k drivers)
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On Mon, Nov 21, 2011 at 8:14 PM, Marianne Lombard maria...@tuxette.fr wrote: Hi, I was reading cooker ML a few days ago (yes I know, it's a strange idea) when I've read that Mandriva has stopped using (and thereof developing it). They have switched to NetworkManager (you all know this tool). What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? Just a precision, I use Networkmanager with mageia1 on my laptop (due to the VPN we use at work) Regards This is too late for mageia 2 and i think we have enough work to do because of stuffs like systemd. IF we do this i think this should be for magea 3-4 as this will require tweaks in the installer at least. I am in favor or starting discussing this for mageia 3 minimum. my 2cts
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
In data lunedì 21 novembre 2011 20:14:15, Marianne Lombard ha scritto: Hi, I was reading cooker ML a few days ago (yes I know, it's a strange idea) when I've read that Mandriva has stopped using (and thereof developing it). They have switched to NetworkManager (you all know this tool). Funny one of the things made me remove mdv 2011 was NM, i set it up after the upgrade to manage my 3g usb card, and it worked, but from that point on i could not use my ethernet card any more it was always disconnected... but was what nm thought... What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? Well i believe there are only two distros in which it works really -that i tested of course- Fedora and Ubuntu. I believe we should go on of course, but before leaving drakconnect we should be very sure nm works for the most -maybe studying fedora more than mandriva here- My 2 € cents, -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 11/21/2011 03:12 PM, Manuel Hiebel wrote: But we have also a lot a bugs against drakx-net (I guess the maintainer is busy like all us) https://bugs.mageia.org/buglist.cgi?query_format=advancedfield0-0-0=cf_rpmpkgbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtype0-0-0=substringvalue0-0-0=drakx-net If you look through that list, not one of them involves the inability to activate a wireless interface that we think Linux supports.
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 11/21/2011 03:15 PM, John Balcaen wrote: 2011/11/21 Frank Griffinf...@roadrunner.com: On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Bug 856 is grub related so i guess we can forget this one ;o) Sorry, I transposed - should have been 865. Bug 2416 was submitted when nm 0.9 (well beta) was not patched to support our sysvinit script, we'll still waiting for an answer of the initial report. If you look at comment #6 in this bug, you'll see that this is another case of the same bug reported with NM in several other distros (disconnected for local ... (reason=3)). I'm not sure what that would have to do with sysvinit script support. So 2160 is the only bug remaining here but i think it's probably the same bug aka it was reported when nm was not supporting sysvinit Please explain about nm not supporting sysvinit, or point me to the relevant bug report. 2160 documented a case where the kernel reports a no link beat detected a second or so before reporting link beat detected, and apparently NM sees the first and aborts trying to bring up the interface. In the bug, I called this aggressive timeout, but it may just be that NM is misinterpreting the events it sees. Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. It's happening with the *current* networkmanager of with the beta when the patch was not applied because blino did fix the patch now nm respect the ifcfg- command line. I'll be doing a fresh install on the laptop experiencing the problem in the next couple of days, and I'll check to see whether the problem(s) still occur(s). Since no one ever posted to the bug report that it might be fixed, I've simply been removing the package whenever it gets reinstalled or on fresh installs. I'll wait to do the test to say this for sure, but IIRC I would occasionally not notice that some urpmi --auto-update had reinstalled NM until the wireless stopped coming up, and this was well after seeing your posts about blino's patch. And if you look in bug 2160, it appears that we have no maintainer for it. Well there's a lot of packages without maintainer ... Well, if we're considering doing something that has the potential of breaking peoples' systems, it would make sense (at least to me) to tread carefully unless we have someone on hand that can deal with the problems, no ?
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On Mon, Nov 21, 2011 at 4:25 PM, Angelo Naselli anase...@linux.it wrote: Well i believe there are only two distros in which it works really -that i tested of course- Fedora and Ubuntu. Add OpenSUSE to the list, I have been using it with my work laptop for more than seven months without any issues. juancho
Re: [Mageia-dev] drop php-ffmpeg
'Twas brillig, and Thomas Spuhler at 19/11/11 19:34 did gyre and gimble: On Saturday, November 19, 2011 11:26:22 am Colin Guthrie wrote: What do I need to do to get it dropped? Just svn rmadress_sv_ssh/cauldron/pkg/current I think. And commit And commit :) If you pass in the full URL rather than just using the working tree then commit is implied In fact as you'd want to remove the pkg folder too, then this is likely the better way to do it. Col Would you mind to check if I did this correct? Well I can't access this URL: http://svnweb.mageia.org/packages/cauldron/php-ffmpeg/ so I presume all is well :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On Mon, 21 Nov 2011 16:51:12 -0500 Juan Luis Baptiste juan...@mageia.org wrote: On Mon, Nov 21, 2011 at 4:25 PM, Angelo Naselli anase...@linux.it wrote: Well i believe there are only two distros in which it works really -that i tested of course- Fedora and Ubuntu. Add OpenSUSE to the list, I have been using it with my work laptop for more than seven months without any issues. And it is working for me pretty fine in Mageia Cauldron, specially for wireless networks, in 3 or 4 laptops. I finally have been able to do things that I had never managed to set up with net-applet: - have a zillion (well, really like 5 or 6) wifi network setups in /etc/NetworkManager/system-connections and let the daemon pick one without the need to rewrite ifcfg-wlan0 (even automagically) - have a wireless network being started and connected without a user logged in, just at system boot - restart daemons like gmond, that do not play fine on network ups and downs from /etc/NetworkManager/dispatcher.d Setting all those things is easy from the point of view of a cli admin, you can even copy many things from one system to another and have it working. I vote for going to NM, and use a setup tool that writes files into /etc/NetworkManager/system-connection for wired system connections. And I really think that NM plays much nicer with the rest of systemd environment than current scripts. Just my 2 cents...
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 11/21/2011 05:25 PM, JA Magallon wrote: And it is working for me pretty fine in Mageia Cauldron, specially for wireless networks, in 3 or 4 laptops. I finally have been able to do things that I had never managed to set up with net-applet: OK, since it seems that it's working well for lots of folks, I look forward to testing it again in the next few days, and I'll provide detailed feedback.
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Am Montag, 21. November 2011, 23:32:43 schrieb Frank Griffin: On 11/21/2011 05:25 PM, JA Magallon wrote: And it is working for me pretty fine in Mageia Cauldron, specially for wireless networks, in 3 or 4 laptops. I finally have been able to do things that I had never managed to set up with net-applet: OK, since it seems that it's working well for lots of folks, I look forward to testing it again in the next few days, and I'll provide detailed feedback. Me, too. Last time I tried (which was one week ago), when nm was installed, my wifi didn't work any more. After uninstalling it again, it worked again. If this didn't change in the last 7 days, I vote against nm... I'll check the next days. Oliver
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Le lundi 21 novembre 2011 16:50:35 Frank Griffin a écrit : [...] Sorry, I transposed - should have been 865. So here the problems here seems to happend when using the *specific* mdv plugin on mageia 1 not with the native plugin (keyfile). Bug 2416 was submitted when nm 0.9 (well beta) was not patched to support our sysvinit script, we'll still waiting for an answer of the initial report. If you look at comment #6 in this bug, you'll see that this is another case of the same bug reported with NM in several other distros (disconnected for local ... (reason=3)). I'm not sure what that would have to do with sysvinit script support. This bug report is against nm not respecting the NM_CONTROLLED=no cf comment #1 We can expect problem when 2 system are trying to interfere with the same hardware. So 2160 is the only bug remaining here but i think it's probably the same bug aka it was reported when nm was not supporting sysvinit Please explain about nm not supporting sysvinit, or point me to the relevant bug report. 2160 documented a case where the kernel reports a no link beat detected a second or so before reporting link beat detected, and apparently NM sees the first and aborts trying to bring up the interface. In the bug, I called this aggressive timeout, but it may just be that NM is misinterpreting the events it sees. The bug was reported the 2011-07-15 while nm was updated to the beta 0.9 the 2011-06-14 by dmorgan. The support for ifcfg files (aka respect the NM_CONTROLLED=no and what i was wrongly calling support in sysvinit) was added by blino on 2011-07-31 by patching the redhat plugin. From the log you did past in comment #1 we can see that NM sysvinit are trying to put on the same interface. You never explicity wrote that you have in your nm to control your wifi interface from what you write since i can see ifplug running i can expect that you were using by default sysvinit script not nm. So we 're still in the situation « nm is not reading correctly the ifcfg file do not respect the NM_CONTROLLED=no solution. Your solution was to removed nm from your system to ensure that only ifcfg are used that nm does not try to bring up your interface. Regarding your comment #9 it seems their is a bug in the rhplugin it should be reported assigned to blino (since he's the one to code this functionnality). Please note that i don't deny there's a problem eventually but if indeed it's not working correctly with nm explicity with ifcfg- disable (aka only a lo interface no etho/wan/whatelse) using the native keyfile plugin ( not the rh-plugin) we should report it upstream. [...] I'll be doing a fresh install on the laptop experiencing the problem in the next couple of days, and I'll check to see whether the problem(s) still occur(s). Since no one ever posted to the bug report that it might be fixed, I've simply been removing the package whenever it gets reinstalled or on fresh installs. I'll wait to do the test to say this for sure, but IIRC I would occasionally not notice that some urpmi --auto-update had reinstalled NM until the wireless stopped coming up, and this was well after seeing your posts about blino's patch. Then if nm does not respect the NM_CONTROLLED=no (using the rhkeyfile plugin) then it should be reported assigned to blino. [...] Well there's a lot of packages without maintainer ... Well, if we're considering doing something that has the potential of breaking peoples' systems, it would make sense (at least to me) to tread carefully unless we have someone on hand that can deal with the problems, no ? Here our bug triager team looks directly @ the commits to find someone which might be able to help on that (because if we're looking @ http://pkgsubmit.mageia.org/data/unmaintained.txt there's a lot of problematic packages without maintainer like at least grub :p ) Regards, -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release module-init-tools-3.16-7.5.8.mga2
On Mon, 21 Nov 2011 19:30:13 +0100 (CET) Mageia Team buildsystem-dae...@mageia.org wrote: Name: module-init-toolsRelocations: (not relocatable) Version : 3.16 Vendor: Mageia.Org Release : 7.5.8.mga2Build Date: Mon Nov 21 19:25:57 2011 Just a couple things I noticed: + Revision: 170576 - reduce number of runtime warnings - drop kernel 2.4 - 2.6 module mapping which is uneeded for long time - 00_modprobe.conf still does: include /lib/module-init-tools/modprobe.compat [1] -?\194?\160drop patch 3 and move modprobe.default in modprobe.d - should not 00_modprobe.conf be called something like 00_default.conf, in case /etc/modprobe.conf is moved to /etc/modprobe.d, as some errors claim ? [1] - drop patch 6 and move ldetect-lst in modprobe.d (still read before kernel aliases list) - should not that end also in .conf ? - document remaining patches - patch 9: rename warn() as mod_warn() (mga#3309): - patch 10: API for quiet mode in ldetect [1] werewolf:~# bootloader-config --action rebuild-initrds perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : No such file or directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory ...
Re: [Mageia-dev] Changing default media names
Op maandag 21 november 2011 10:32:11 schreef nicolas vigier: [...] Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? yes.
Re: [Mageia-dev] Changing default media names
nicolas vigier bo...@mars-attacks.org writes: Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? Also, we could probably use tabs to make the default interface for drakrpm-edit-media simpler: - one tab for release + updates media (i.e. the most useful for average users) - one tab for backports media - one tab for testing media - one tab for debug + sources media This would remove a lot of clutter from the current interface -- Olivier Blin - blino
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Frank Griffin f...@roadrunner.com writes: On 11/21/2011 02:14 PM, Marianne Lombard wrote: What will Mageia team do ? Continue to maintain and enhance drakx-net or follow all others distributions with NetworkManager ? There are a number of serious problems with NM that have not, to my knowledge, been dealt with. It's particularly bad with wireless (which is what Mageia tends to use it for the most); see bugs 856, 2160, 2416. Or just google for NM problems (there's a ton of people having trouble with it). One of the annoying things about it is that you can say no to it in the ifcfg file, but it will try to handle the interface anyway. And if you look in bug 2160, it appears that we have no maintainer for it. Well, there was also a bug in drakx-net about that, and I've finally found time to fix it. This has been introduced by the NM support added by Mandriva (revision 271832), which we carelessly imported initially :-/ Basically, if a NM_CONTROLLED setting was present in an ifcfg file, it would always be rewritten as yes... This bugfix was worth a big release bump, welcome drakx-net 1.0! -- Olivier Blin - blino
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 21.11.2011 22:51, Juan Luis Baptiste wrote: On Mon, Nov 21, 2011 at 4:25 PM, Angelo Nasellianase...@linux.it wrote: Well i believe there are only two distros in which it works really -that i tested of course- Fedora and Ubuntu. Add OpenSUSE to the list, I have been using it with my work laptop for more than seven months without any issues. juancho + Debian, no problems with Gnome But! From my experience it's harder to setup NM (wasted time for configuration..) in a simple Window Manager, so I prefer drakx-net.
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 11/21/2011 06:01 PM, Balcaen John wrote: Le lundi 21 novembre 2011 16:50:35 Frank Griffin a écrit : [...] Sorry, I transposed - should have been 865. So here the problems here seems to happend when using the *specific* mdv plugin on mageia 1 not with the native plugin (keyfile). Well, it uses whatever the Mageia install puts there. I didn't change anything from the defaults, much less anything specific to NM, about which I know next to nothing. And all of this goes to Cauldron, not 1. I have never done an install of 1, but always Cauldron with daily updates and periodic (~ every three weeks or so ) fresh installs. The bug was reported the 2011-07-15 while nm was updated to the beta 0.9 the 2011-06-14 by dmorgan. The support for ifcfg files (aka respect the NM_CONTROLLED=no and what i was wrongly calling support in sysvinit) was added by blino on 2011-07-31 by patching the redhat plugin. From the log you did past in comment #1 we can see that NM sysvinit are trying to put on the same interface. You never explicity wrote that you have in your nm to control your wifi interface from what you write since i can see ifplug running i can expect that you were using by default sysvinit script not nm. So we 're still in the situation « nm is not reading correctly the ifcfg file do not respect the NM_CONTROLLED=no solution. Your solution was to removed nm from your system to ensure that only ifcfg are used that nm does not try to bring up your interface. Regarding your comment #9 it seems their is a bug in the rhplugin it should be reported assigned to blino (since he's the one to code this functionnality). Please note that i don't deny there's a problem eventually but if indeed it's not working correctly with nm explicity with ifcfg- disable (aka only a lo interface no etho/wan/whatelse) using the native keyfile plugin ( not the rh-plugin) we should report it upstream. Just to clarify, none of these errors is specific to system startup. All of them and all of the doc I included in my bugreports was taken from attempts to activate the interface *after* bootup. So I still don't see what sysvinit would have to do with it. You never explicity wrote that you have in your nm to control your wifi interface from what you write since i can see ifplug running i can expect that you were using by default sysvinit script not nm I'm not sure what you mean by this. in your nm would imply that I modified some NM-specific config file, which I assure you I did not. I have never done anything NM-specific to control NM. The only things not done indirectly by NM itself or net-applet were my settings of NM_CONTROLLED and NEEDHOSTNAME in the ifcfg. If there's an NM config option here that's out-of-line, it's Mageia that's putting it there, not me. Then if nm does not respect the NM_CONTROLLED=no (using the rhkeyfile plugin) then it should be reported assigned to blino. I agree but realize that if I have to use this to begin with, there's an NM bug that is potentially severe enough to prevent distro deployment. Really, guys, I sympathize with the desire to move to something newer supported by others. But you have to be ready to deal with the issue of back-breakage. We already went through this in Mandriva with system-config-printer, which on day one screwed up most of printerdrake's existing function. It's new is not an excuse for breaking 50% of what the replaced component did and then pointing fingers at upstream for the shortfall. If it isn't ready, then it isn't ready, period. Work with upstream until it is, and *then* dump it into Cauldron. It doesn't have to be perfect, but it has to be good enough that it leaves systems functional enough to do meaningful testing with it to provide feedback, which is the whole point of Cauldron. Blowing away the wireless capability of a significant portion of the community and then sitting back and saying stuff like well it was a beta or we have to wait for upstream to fix that doesn't cut it. This isn't just a blind rebuild of some stable package that doesn't warrant preliminary testing. It's a major piece of the distro infrastructure, and you shouldn't be doing changes like that unless a) you're able and prepared to dedicate the resource to attack the problems as they occur or b) you're prepared to back the packages out if you can't do (a).
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
2011/11/21 Frank Griffin f...@roadrunner.com: On 11/21/2011 06:01 PM, Balcaen John wrote: Le lundi 21 novembre 2011 16:50:35 Frank Griffin a écrit : [...] Sorry, I transposed - should have been 865. So here the problems here seems to happend when using the *specific* mdv plugin on mageia 1 not with the native plugin (keyfile). Well, it uses whatever the Mageia install puts there. I didn't change anything from the defaults, much less anything specific to NM, about which I know next to nothing. I did not say anything else. I personally don't use the rhplugin or the mdv before but always switch to keyfile. And all of this goes to Cauldron, not 1. I have never done an install of 1, but always Cauldron with daily updates and periodic (~ every three weeks or so ) fresh installs. On this initial bug report Mageia was providing the « old » 0.8.x version which in fact was only available in mageia 1 since dmorgan updated it to the 0.9 beta series once he started the migration to gnome3. The bug was reported the 2011-07-15 while nm was updated to the beta 0.9 the 2011-06-14 by dmorgan. The support for ifcfg files (aka respect the NM_CONTROLLED=no and what i was wrongly calling support in sysvinit) was added by blino on 2011-07-31 by patching the redhat plugin. From the log you did past in comment #1 we can see that NM sysvinit are trying to put on the same interface. You never explicity wrote that you have in your nm to control your wifi interface from what you write since i can see ifplug running i can expect that you were using by default sysvinit script not nm. [...] Just to clarify, none of these errors is specific to system startup. All of them and all of the doc I included in my bugreports was taken from attempts to activate the interface *after* bootup. So I still don't see what sysvinit would have to do with it. Add said earlier i wrongly used the term of sysvinit when talking abouf the ifcfg-. You never explicity wrote that you have in your nm to control your wifi interface from what you write since i can see ifplug running i can expect that you were using by default sysvinit script not nm I'm not sure what you mean by this. in your nm would imply that I modified some NM-specific config file, which I assure you I did not. I have never done anything NM-specific to control NM. The only things not done indirectly by NM itself or net-applet were my settings of NM_CONTROLLED and NEEDHOSTNAME in the ifcfg. I wrote too fast here. I meant that you never wrote somewhere that you choose to use nm (especially since i can notice that ifplugd was playing with nm in the logs). If there's an NM config option here that's out-of-line, it's Mageia that's putting it there, not me. Then if nm does not respect the NM_CONTROLLED=no (using the rhkeyfile plugin) then it should be reported assigned to blino. I agree but realize that if I have to use this to begin with, there's an NM bug that is potentially severe enough to prevent distro deployment. I do understand that's why i suggested you to use the keyfile plugin in #865 instead of the « ifcfg-mdv plugin not maintained anymore in 0.8.x » or the rh plugin which also lacks some functionnality. Really, guys, I sympathize with the desire to move to something newer supported by others. But you have to be ready to deal with the issue of back-breakage. I personally don't care if Mageia wants to switch to nm or stick to drakx-net, i was here to comment some bugs linked by you here. Nm is provided by mageia and it's far than enough for me because i'm able to use it without problem since Mageia 1. So as long as we have someone to deal/maintain with drakx-net we can still follow this road. [...] Blowing away the wireless capability of a significant portion of the community and then sitting back and saying stuff like well it was a beta or we have to wait for upstream to fix that doesn't cut it. This isn't just a blind rebuild of some stable package that doesn't warrant preliminary testing. It's a major piece of the distro infrastructure, and you shouldn't be doing changes like that unless Again here could you please test with the *keyfile* plugin if it's still broken with the native plugin report it upstream so we can get a bug fix for it ? (yes yet another fingers @ upstream :p ) -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
On 11/21/2011 09:41 PM, John Balcaen wrote: I did not say anything else. I personally don't use the rhplugin or the mdv before but always switch to keyfile. Please understand that I have *never* modified any Mageia-installed NM configuration file. I don't know what you mean by the mdv/rh/keyfile reference. I've been through enough of this to understand that there's an NM config file that specifies a shell script file that comes in an *rh* (RedHat) and an *mdv* versions. I have no idea what keyfile refers to.in this context. And all of this goes to Cauldron, not 1. I have never done an install of 1, but always Cauldron with daily updates and periodic (~ every three weeks or so ) fresh installs. On this initial bug report Mageia was providing the « old » 0.8.x version which in fact was only available in mageia 1 since dmorgan updated it to the 0.9 beta series once he started the migration to gnome3. Fine. I'm just pointing out that I wasn't testing with backlevelled code, but with Cauldron as current at the time. I wrote too fast here. I meant that you never wrote somewhere that you choose to use nm (especially since i can notice that ifplugd was playing with nm in the logs). Umm, no, I never had to write that anywhere for the simple reason that I *didn't* choose to use NM. Mageia chose to use it for me, because GNOME 3 required it. I didn't do one blessed thing to encourage the use of NM in any way. I agree but realize that if I have to use this to begin with, there's an NM bug that is potentially severe enough to prevent distro deployment. I do understand that's why i suggested you to use the keyfile plugin in #865 instead of the « ifcfg-mdv plugin not maintained anymore in 0.8.x » or the rh plugin which also lacks some functionnality. Which, referring to the same bug report, I did and reported the results. If there was a lesson to be learned there, it didn't get fixed in whatever version of the plugin Mageia uses by default. Really, guys, I sympathize with the desire to move to something newer supported by others. But you have to be ready to deal with the issue of back-breakage. I personally don't care if Mageia wants to switch to nm or stick to drakx-net, i was here to comment some bugs linked by you here. Nm is provided by mageia and it's far than enough for me because i'm able to use it without problem since Mageia 1. So as long as we have someone to deal/maintain with drakx-net we can still follow this road. [...] I'm fine with that... Again here could you please test with the *keyfile* plugin if it's still broken with the native plugin report it upstream so we can get a bug fix for it ? (yes yet another fingers @ upstream :p ) I'll include that test in my next round.
Re: [Mageia-dev] Drakx-net or NetworkManager for Mageia 2
Le mardi 22 novembre 2011 00:11:49, Frank Griffin a écrit : On 11/21/2011 09:41 PM, John Balcaen wrote: I did not say anything else. I personally don't use the rhplugin or the mdv before but always switch to keyfile. Please understand that I have *never* modified any Mageia-installed NM configuration file. I don't know what you mean by the mdv/rh/keyfile reference. I've been through enough of this to understand that there's an NM config file that specifies a shell script file that comes in an *rh* (RedHat) and an *mdv* versions. I have no idea what keyfile refers to.in this context. Ok so in fact you did not follow my suggestion here https://bugs.mageia.org/show_bug.cgi?id=865#c1 ? [...] Umm, no, I never had to write that anywhere for the simple reason that I *didn't* choose to use NM. Mageia chose to use it for me, because GNOME 3 required it. I didn't do one blessed thing to encourage the use of NM in any way. I never wrote that you choose nm simply that you get affected by the « non support » of ifcfg-mdv initially. After seems like you also hit a bug in drakx-net which switch to nm per default ( fixed since today by blino) I agree but realize that if I have to use this to begin with, there's an NM bug that is potentially severe enough to prevent distro deployment. I do understand that's why i suggested you to use the keyfile plugin in #865 instead of the « ifcfg-mdv plugin not maintained anymore in 0.8.x » or the rh plugin which also lacks some functionnality. Which, referring to the same bug report, I did and reported the results. If there was a lesson to be learned there, it didn't get fixed in whatever version of the plugin Mageia uses by default. hum ? The only comment here was that : 1) ifcfg-mdv plugin was broken ( now in fact dead in mageia 2+) 2) try ifcfg-rh to see if it's also affected ( https://bugs.mageia.org/show_bug.cgi?id=865#c6 ) you did not try arguing that the maintainer should report it upstream. ( https://bugs.mageia.org/show_bug.cgi?id=865#c8 ) which is quite difficult if the maintainer (well in this case there is no maintainer so it's even more difficult) is not able to reproduce simply because for example he does not have the same wifi card. That's why i suggest you to report it upstream since you should be able to answer questions from upstream if needed. 3) keyfile is not affected by the hostname bug in #865 However when i suggested to switch to keyfile (on irc indeed not on mageia mailing list) instead of the ifcfg-rh plugin or (any others non native plugins) i was told that we need to support ifcfg (which is right indeed) So in summary we have a working plugin (keyfile) but we're not able to use it because we need to support ifcfg- files so we're stick with the redhat plugin for now until we found someone able to fix the missing functionnalities in this plugin. -- Balcaen John Jabber-ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Changing default media names
Olivier Blin a écrit : nicolas vigierbo...@mars-attacks.org writes: Ok, so everybody agree with changing the names with the proposal I made, and adding an optional description line in media.cfg on the mirrors and /etc/urpmi/urpmi.cfg for each media, to be displayed by rpmdrake in a description column in drakrpm-edit-media near the name ? +1 Also, we could probably use tabs to make the default interface for drakrpm-edit-media simpler: - one tab for release + updates media (i.e. the most useful for average users) - one tab for backports media - one tab for testing media - one tab for debug + sources media This would remove a lot of clutter from the current interface Good idea :) A lot better than having to scroll though what seems like 100 lines. -- André
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release module-init-tools-3.16-7.5.8.mga2
On 22 November 2011 00:06, JA Magallon jamagal...@ono.com wrote: On Mon, 21 Nov 2011 19:30:13 +0100 (CET) + Revision: 170576 - reduce number of runtime warnings - drop kernel 2.4 - 2.6 module mapping which is uneeded for long time - 00_modprobe.conf still does: include /lib/module-init-tools/modprobe.compat [1] I forgot to copy back the altered patch, already fixed -?\194?\160drop patch 3 and move modprobe.default in modprobe.d - should not 00_modprobe.conf be called something like 00_default.conf, in case /etc/modprobe.conf is moved to /etc/modprobe.d, as some errors claim ? [1] - drop patch 6 and move ldetect-lst in modprobe.d (still read before kernel aliases list) - should not that end also in .conf ? .alias is fine - document remaining patches - patch 9: rename warn() as mod_warn() (mga#3309): - patch 10: API for quiet mode in ldetect [1] werewolf:~# bootloader-config --action rebuild-initrds perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : No such file or directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory we need to alter drakxtools generate-modprobe.conf first before moving that one
