2009/2/16 James Rayner :

Hi

The release beta cycle wasn't working well for netcfg. Small changes, bugs and many FR's got held up far too long while other work happened. To try and help get netcfg development going smoothly again I've uploaded some netcfg git PKGBUILDs  to the AUR to use instead of -beta releases.

This way I can make those small changes, push it to git, and it can be tested immediately, while larger things can be safely done in another branch locally. When it's ready, rc's will be released.

http://aur.archlinux.org/packages.php?ID=23953 http://aur.archlinux.org/packages.php?ID=23954

There's some fairly substantial changes in this release.  - Moving from net-tools to iproute     - iproute is the way forward. net-tools is long unmaintained, nor as capable.  - Moving from wireless_tools to pure wpa_supplicant     - More reliable, less quirks required. Hopefully more stable.     - As part of this, wireless moves into netcfg-wireless (dependency issues)

Both of these require config changes. Once they're both stabilised I can release 2.2.x to give people time to migrate, and eventually 2.5 which will use them by default. There are example configs included.

More details on the wiki: http://wiki.archlinux.org/index.php/Network_Profiles_development

The wpa_supplicant move needs a significant amount of testing. I havn't tested WEP (testing hardware is gone), and net-auto may not work presently. WPA and custom WPA configs work in my testing.

If there's any criticisms or comments about the way this is going, the code, netcfg, etc, please let me know. I'd like to make 2.2 a good release and I think these changes are important. I'm hoping they'll make netcfg simpler and more reliable.

Cheers, James

Hi, i just tested netcfg-git. It didn't work. I have broadcom BCM4312 chip and i'm using the broadcom-wl driver. netcfg-git failed with "- eth1 is not a valid wireless interface." because of this block in /usr/lib/network/connections/wireless : if [[ ! -d /sys/class/net/$INTERFACE/phy80211 ]]; then err_append "$INTERFACE is not a valid wireless interface." return 1 fi the wl.ko module doesn't provide phy80211 directory in the sys filesystem it seems. Or at least i don't have it. I tried to comment the test to see what happens. In this case netcfg just hanged trying to bring the connection up. netcfg 2.1.x is working fine. -- BRS Atanas Zhelev

2009/2/16 James Rayner :

Hi

The release beta cycle wasn't working well for netcfg. Small changes, bugs and many FR's got held up far too long while other work happened. To try and help get netcfg development going smoothly again I've uploaded some netcfg git PKGBUILDs  to the AUR to use instead of -beta releases.

This way I can make those small changes, push it to git, and it can be tested immediately, while larger things can be safely done in another branch locally. When it's ready, rc's will be released.

http://aur.archlinux.org/packages.php?ID=23953 http://aur.archlinux.org/packages.php?ID=23954

There's some fairly substantial changes in this release.  - Moving from net-tools to iproute     - iproute is the way forward. net-tools is long unmaintained, nor as capable.  - Moving from wireless_tools to pure wpa_supplicant     - More reliable, less quirks required. Hopefully more stable.     - As part of this, wireless moves into netcfg-wireless (dependency issues)

Both of these require config changes. Once they're both stabilised I can release 2.2.x to give people time to migrate, and eventually 2.5 which will use them by default. There are example configs included.

More details on the wiki: http://wiki.archlinux.org/index.php/Network_Profiles_development

The wpa_supplicant move needs a significant amount of testing. I havn't tested WEP (testing hardware is gone), and net-auto may not work presently. WPA and custom WPA configs work in my testing.

If there's any criticisms or comments about the way this is going, the code, netcfg, etc, please let me know. I'd like to make 2.2 a good release and I think these changes are important. I'm hoping they'll make netcfg simpler and more reliable.

It's a good idea. I'm installing them to do some test. -- Andrea `BaSh` Scarpino Arch Linux Developer