[Mageia-dev] Drakx-net or NetworkManager for Mageia 2

Tue Nov 22 03:15:57 CET 2011

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).
+
+
+
+