diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-November/009717.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-November/009717.html | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-November/009717.html b/zarb-ml/mageia-dev/2011-November/009717.html new file mode 100644 index 000000000..9e7b67449 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-November/009717.html @@ -0,0 +1,171 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Drakx-net or NetworkManager for Mageia 2 + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Drakx-net%20or%20NetworkManager%20for%20Mageia%202&In-Reply-To=%3C4ECB05DD.6080204%40roadrunner.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="009710.html"> + <LINK REL="Next" HREF="009718.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Drakx-net or NetworkManager for Mageia 2</H1> + <B>Frank Griffin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Drakx-net%20or%20NetworkManager%20for%20Mageia%202&In-Reply-To=%3C4ECB05DD.6080204%40roadrunner.com%3E" + TITLE="[Mageia-dev] Drakx-net or NetworkManager for Mageia 2">ftg at roadrunner.com + </A><BR> + <I>Tue Nov 22 03:15:57 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="009710.html">[Mageia-dev] Drakx-net or NetworkManager for Mageia 2 +</A></li> + <LI>Next message: <A HREF="009718.html">[Mageia-dev] Drakx-net or NetworkManager for Mageia 2 +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#9717">[ date ]</a> + <a href="thread.html#9717">[ thread ]</a> + <a href="subject.html#9717">[ subject ]</a> + <a href="author.html#9717">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 11/21/2011 06:01 PM, Balcaen John wrote: +><i> Le lundi 21 novembre 2011 16:50:35 Frank Griffin a écrit : +</I>><i> [...] +</I>>><i> Sorry, I transposed - should have been 865. +</I>><i> So here the problems here seems to happend when using the *specific* mdv plugin +</I>><i> on mageia 1& not with the native plugin (keyfile). +</I> +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. + +><i> +</I>><i> The bug was reported the 2011-07-15 while nm was updated to the beta 0.9 the +</I>><i> 2011-06-14 by dmorgan. +</I>><i> The support for ifcfg files (aka respect the NM_CONTROLLED=no and what i was +</I>><i> wrongly calling support in sysvinit) was added by blino on 2011-07-31 by +</I>><i> patching the redhat plugin. +</I>><i> > From the log you did past in comment #1 we can see that NM& sysvinit are +</I>><i> trying to put on the same interface. +</I>><i> You never explicity wrote that you have in your nm to control your wifi +</I>><i> interface from what you write& since i can see ifplug running i can expect +</I>><i> that you were using by default sysvinit script& not nm. +</I>><i> So we 're still in the situation « nm is not reading correctly the ifcfg file& +</I>><i> do not respect the NM_CONTROLLED=no solution. +</I>><i> Your solution was to removed nm from your system to ensure that only ifcfg are +</I>><i> used& that nm does not try to bring up your interface. +</I>><i> Regarding your comment #9 it seems their is a bug in the rhplugin& it should +</I>><i> be reported& assigned to blino (since he's the one to code this +</I>><i> functionnality). +</I>><i> Please note that i don't deny there's a problem eventually but if indeed it's +</I>><i> not working correctly with nm explicity with ifcfg- disable (aka only a lo +</I>><i> interface& no etho/wan/whatelse) using the native keyfile plugin (& not the +</I>><i> rh-plugin) we should report it upstream. +</I> +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. + +><i> You never explicity wrote that you have in your nm to control your wifi +</I>><i> interface from what you write& since i can see ifplug running i can expect +</I>><i> that you were using by default sysvinit script& not nm +</I> +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. + +><i> +</I>><i> Then if nm does not respect the NM_CONTROLLED=no (using the rhkeyfile plugin) +</I>><i> then it should be reported& assigned to blino. +</I> +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). + + + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="009710.html">[Mageia-dev] Drakx-net or NetworkManager for Mageia 2 +</A></li> + <LI>Next message: <A HREF="009718.html">[Mageia-dev] Drakx-net or NetworkManager for Mageia 2 +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#9717">[ date ]</a> + <a href="thread.html#9717">[ thread ]</a> + <a href="subject.html#9717">[ subject ]</a> + <a href="author.html#9717">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |