Fedora Core 4 Test Update: NetworkManager-0.5.1-1.FC4.1

[David Woodhouse]

On Fri, 2005-10-21 at 09:19 -0400, Christopher Aillon wrote:
>  > cd builds/rpms/NetworkManager/FC-4
>  > grep wireless-tools NetworkManager.spec
> NetworkManager.spec:20:Requires: wireless-tools >= 28-0.pre9
> NetworkManager.spec:31:BuildRequires: wireless-tools >= 28-0.pre9
>  >
> 
> I'm not sure how that is failing for your version.  That is there in the 
> spec file... Suggestions as to how to fix are appreciated.

Hm, strange. Yet I can reproduce it on another clean FC4 box...

baythorne /home/dwmw2 # rpm -q wireless-tools
wireless-tools-28-0.pre4.3
baythorne /home/dwmw2 # yum --enablerepo=updates-testing install NetworkManager
Setting up Install Process
Setting up repositories
livna                     100% |=========================|  951 B    00:00
base-local                100% |=========================|  951 B    00:00
updates-testing           100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
updates-released          100% |=========================|  951 B    00:00
emacs-cvs-testing         100% |=========================|  951 B    00:00
base                      100% |=========================|  951 B    00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for NetworkManager to pack into transaction set.
NetworkManager-0.5.1-1.FC 100% |=========================|  18 kB    00:00
---> Package NetworkManager.i386 0:0.5.1-1.FC4.1 set to be updated
--> Running transaction check
--> Processing Dependency: dhcdbd for package: NetworkManager
--> Processing Dependency: caching-nameserver for package: NetworkManager
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for dhcdbd to pack into transaction set.
dhcdbd-1.9-1.FC4.i386.rpm 100% |=========================| 5.2 kB    00:00
---> Package dhcdbd.i386 0:1.9-1.FC4 set to be updated
---> Downloading header for caching-nameserver to pack into transaction set.
caching-nameserver-7.3-3. 100% |=========================| 6.8 kB    00:00
---> Package caching-nameserver.noarch 0:7.3-3 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 NetworkManager          i386       0.5.1-1.FC4.1    updates-testing   257 k
Installing for dependencies:
 caching-nameserver      noarch     7.3-3            base-local         22 k
 dhcdbd                  i386       1.9-1.FC4        updates-testing    63 k

Transaction Summary
=============================================================================
Install      3 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 343 k
Is this ok [y/N]: n
Exiting on user Command
Complete!

Seth?
  
> Before, we used to store the WEP keys in plain text on the disk.  Now we 
> use gnome-keyring-manager which encrypts the passwords, and in theory is 
> a better experience.  Having to enter your keyring password is a 
> "regression" in that sense, I suppose.  There's a bug filed in gnome CVS 
> I believe to get the keyring to not require login if the user has "log 
> me in to GNOME automatically" enabled.

The WEP key is stored in plain text on the disk anyway --
in /etc/sysconfig/network-scripts/keys-eth1. It's readable only by root,
and mere users cannot read it. For many situations, that is the most
appropriate behaviour.

Perhaps the dialog box which allows me to enter the WEP key should have
a 'Set this system-wide' checkbox, which would then ask me for the root
password and store it somewhere appropriate instead of in my own
personal settings?

On a separate note, the 'connect with dialup' option is very nice for
_connecting_ but then doesn't actually show that the connection is made,
and doesn't offer me a 'disconnect' option.

Any pointers on adding Bluetooth support? Bluetooth devices are detected
in sysfs as one might expect, the 'scan' procedure is what's implemented
in the 'pand' tool in bluez-utils (search for other hosts, then search
for PAN capability on each host found), and connection involves creating
up a virtual Ethernet device over the Bluetooth and then treating that
as a normal Ethernet device. I can do all that, but interfacing it to NM
looks complex (to me).

-- 
dwmw2