Out for vacation for a week
I'll be back on Tuesday June 28th. jklimes can take care of anything that needs doing 'cause he rocks. Cheers, Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Howto debug OpenVPN connection?
On Tue, 2011-06-21 at 00:58 -0400, Eric B. wrote: > On 06/21/2011 12:53 AM, Dan Williams wrote: > > On Mon, 2011-06-20 at 23:35 -0400, Eric B. wrote: > >> Hi, > >> > >> I am fairly new to the NetworkManager, and am trying to understand how > >> to enable additional debug information for a failing OpenVPN connection. > >> > >> I've installed the OpenVPN plugin, but I am not getting enough > >> information in /var/log/messages and would like to see if there is a way > >> to enable additional information. Is there some configuration flag > >> somewhere that I can enable for this? > > > > killall -TERM nm-openvpn-service > > /path/to/nm-openvpn-service --debug --persist > > > > that works for newer versions of nm-openvpn (like 0.8.1 and later); for > > earlier versions you may need to: > > > > killall -TERM nm-openvpn-service > > OPENVPN_DEBUG=1 /path/to/nm-openvpn-service --persist > > > > where of course /path/to/ gets replaced with where that binary lives; > > for non-Debian systems it's usually /usr/libexec otherwise I'm not sure > > where it lives. > > > > Dan > > > Thanks for the quick response. Am running Fedora 14 and have > NetworkManager-openvpn-0.8.1-1.fc14.i686 installed. > > When I try your suggestions, I get the following messages (non-root > account): > > [eric@eric-laptop ~]$ killall -TERM > nm-openvpn-servicenm-openvpn-service: no process found That's fine, seems the service isn't running which is normal if the VPN is disconnected. > [eric@eric-laptop ~]$ /usr/libexec/nm-openvpn-service --debug --persist > ** (process:8434): WARNING **: constructor(): Connection > ":1.134" is not allowed to own the service > "org.freedesktop.NetworkManager.openvpn" due to security policies in the > configuration file Oops; you need to run it as root via something like: sudo /usr/libexec/nm-openvpn-service --debug --persist Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless Keys stored unencrypted?
On Mon, 2011-06-20 at 17:18 +0530, Ritesh Khadgaray wrote: > Hi > > > On Sat, Jun 18, 2011 at 7:57 AM, Darren Albers wrote: > > While doing some research I noticed that wireless keys are located > > unencrypted in /etc/sysconfig/network-scripts It even does this when > > I set the wireless to not be a system-connection. It used to be that > > wireless keys were stored in the keyring which seems much safer to me > > than storing them locally unencrypted. > > interesting, I am not an nm developer but this seems to stem from keyfile > plugin > and relies on file selinux label/permission for protection. > > I also do not see an option to not save the password. Correct, the passwords are not encrypted because there is no user available to provide passwords. The passwords are, however, only visible too 'root' and thus should be protected; if your root user is compromised you're hosed. This is also how existing system have worked for years, so NM certainly isn't a regression here. You can also opt to keep your secrets in the user keyring, which is accomplished by "secret flags". For example, if you set 'psk-flags=0x1' in the keyfile for a WPA-PSK connection, then NM will ask a user agent (like nm-applet) for the password instead of keeping it in /etc. This option is only exposed for 802.1x and LEAP passwords though (via the "Always ask for this password" checkbox) because only those password types are really personal passwords; a WPA-PSK or WEP key really isn't personal. VPN connections also default to having secrets owned by the user's session in a keyring. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] settings: add support for mac-blacklists for wifi and ethernet
On Fri, 2011-06-17 at 00:04 +0200, Thomas Bechtold wrote: > Hi, > > i missed the blacklist check in real_check_connection_compatible() for > ethernet and wifi. Patch attached. Looks good; in the future we should have get_best_auto_connection() call check_connection_compatible() and remove the redundant code; but we dont' have to do that now. Jiri can you test these, squash them into one with git rebase -i or something and push them? I'm on vacation for a bit. Thanks! Dan > > Cheers, > > Tom > > On Thu, 2011-06-16 at 23:41 +0200, Thomas Bechtold wrote: > > Hi, > > > > i created a patch to support MAC address blacklists for Ethernet/Wifi > > connections. With this patch it's possible to disable a connection for a > > given list of mac-addresses. > > > > I created this patch for the NM 0.8 branch and i have not tested this > > for 0.9 and i don't know if it's difficult to port this patch to NM 0.9. > > > > Cheers, > > > > Tom > > ___ > > networkmanager-list mailing list > > networkmanager-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/networkmanager-list > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Howto debug OpenVPN connection?
On 06/21/2011 12:53 AM, Dan Williams wrote: On Mon, 2011-06-20 at 23:35 -0400, Eric B. wrote: Hi, I am fairly new to the NetworkManager, and am trying to understand how to enable additional debug information for a failing OpenVPN connection. I've installed the OpenVPN plugin, but I am not getting enough information in /var/log/messages and would like to see if there is a way to enable additional information. Is there some configuration flag somewhere that I can enable for this? killall -TERM nm-openvpn-service /path/to/nm-openvpn-service --debug --persist that works for newer versions of nm-openvpn (like 0.8.1 and later); for earlier versions you may need to: killall -TERM nm-openvpn-service OPENVPN_DEBUG=1 /path/to/nm-openvpn-service --persist where of course /path/to/ gets replaced with where that binary lives; for non-Debian systems it's usually /usr/libexec otherwise I'm not sure where it lives. Dan Thanks for the quick response. Am running Fedora 14 and have NetworkManager-openvpn-0.8.1-1.fc14.i686 installed. When I try your suggestions, I get the following messages (non-root account): [eric@eric-laptop ~]$ killall -TERM nm-openvpn-servicenm-openvpn-service: no process found [eric@eric-laptop ~]$ /usr/libexec/nm-openvpn-service --debug --persist ** (process:8434): WARNING **: constructor(): Connection ":1.134" is not allowed to own the service "org.freedesktop.NetworkManager.openvpn" due to security policies in the configuration file Any suggestions / ideas? Thanks, Eric ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Getting NM to re-try DHCP
On Fri, 2011-06-17 at 12:58 +0200, Jirka Klimes wrote: > On Thursday 26 of May 2011 20:22:26 Dan Williams wrote: > > > > > > A patch doing that is in the attachment. > > > > A few concerns with the patch; it might get more complicated because of > > them. First, if the connection is deleted before the idle handler runs, > > we'll be left with garbage. So we'd need to do g_object_weak_ref() on > > the connection object, cache the idle ID, and run g_source_remove() on > > that idle ID from the weak ref callback. Next, in > > reset_connection_retries() we'd want to remove that weak ref when > > freeing the ResetRetriesData structure. > > > > Second, if the connection gets activated again manually by the user > > while we're waiting the 5 minutes then we should g_source_remove() the > > idle ID. That gets more complicated. > > > > Perhaps a simpler approach would be to have a single, global idle > > handler in the NMPolicy that runs over the connection list and resets > > the retries as appropriate? First, in device_state_changed() we could > > attach the current seconds-since-epoch time to the object using > > g_object_set_data() when its # retries reaches 0, and then if no reset > > idle handler was scheduled, schedule one for 300 seconds later. > > (otherwise allow the existing idle handler to run earlier since > > presumably it was scheduled by an earlier failed connection we want to > > reset). > > > > Then, when the reset idle handler does run, iterate over each > > connection, save the earliest reset timestamp, and reschedule the idle > > handler for that timestamp + 300 seconds. During this iteration of > > course we reset the retries count for every connection that has a reset > > timestamp earlier than now. > > > > If the connection gets activated, nm-policy.c's signal handlers can > > listen for that and clear out the invalid timestamp data too. > > > > If that would all work, that would allow us to avoid doing all the > > alloc/dealloc of a custom data structure, plus we only have to manage > > one idle handler. Plus we don't have to care too much about stuff like > > connection deletion and activation happening before our idle handler > > runs since those will be easier to deal with. > > > > Thoughts? > > > > Dan > > Please find the reworked patch is the attachment. Looks good, though for completeness we'd want to g_source_remove() the timeout's ID in nm_policy_destroy() too. It won't really have an effect since nm_policy_destroy() is only called when NM is exiting though. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Howto debug OpenVPN connection?
On Mon, 2011-06-20 at 23:35 -0400, Eric B. wrote: > Hi, > > I am fairly new to the NetworkManager, and am trying to understand how > to enable additional debug information for a failing OpenVPN connection. > > I've installed the OpenVPN plugin, but I am not getting enough > information in /var/log/messages and would like to see if there is a way > to enable additional information. Is there some configuration flag > somewhere that I can enable for this? killall -TERM nm-openvpn-service /path/to/nm-openvpn-service --debug --persist that works for newer versions of nm-openvpn (like 0.8.1 and later); for earlier versions you may need to: killall -TERM nm-openvpn-service OPENVPN_DEBUG=1 /path/to/nm-openvpn-service --persist where of course /path/to/ gets replaced with where that binary lives; for non-Debian systems it's usually /usr/libexec otherwise I'm not sure where it lives. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Howto debug OpenVPN connection?
Hi, I am fairly new to the NetworkManager, and am trying to understand how to enable additional debug information for a failing OpenVPN connection. I've installed the OpenVPN plugin, but I am not getting enough information in /var/log/messages and would like to see if there is a way to enable additional information. Is there some configuration flag somewhere that I can enable for this? Thanks! Eric ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Slow mobile broadband detection
On Wed, 2011-06-15 at 00:30 +0200, Aleksander Morgado wrote: > So, this modem is reported as being a ZTE modem, and therefore uses the > ZTE plugin in ModemManager. > > 3 ports are found, (ttyUSB0,ttyUSB1 and ttyUSB2): > * Opening ttyUSB2 port doesn't take any time. > * Opening ttyUSB1 and ttyUSB0 need 15s each, and as they are done one > after the other, before even starting to probe the first port, it > consumed already 40s. This 15s delays opening the ports are likely to be > kernel issues. > > I actually have similar issues, even worse, with a Huawei modem in > Natty: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/772577 > > Then, probing ttyUSB1 and ttyUSB2, which are both AT ports, takes ~22s. > Closing the ports also seem to take long here, up to 5s each. > > But the modem is not fully exported until all ports are probed, and > ttyUSB0 is not an AT port, so it takes much much longer: needs to > timeout all AT commands sent to it (including extra ATE0+CPMS? in the > case of the ZTE plugin), until the QCDM ones are sent. > > So the overall modem detection needs up to 113s in your case, which > really is a lot, and mainly caused by the open/close port delays from > the kernel. Without these huge delays, the modem detection should take > around 20-25 max (guessing from the max time the QCDM port needs to get > detected). yeah , also my report of a slow modem detection is a ZTE. As reported seems to work on ttyUSB2, but reviewing my old scripts , I can assure that unlock PIN on ttyUSB0 with command: /usr/bin/comgt PIN -d /dev/ttyUSB0 And on wvdial.conf, modem always was ttyUSB0. cat wvdial.conf Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Modem Type = Analog Modem ; Phone = ISDN = 0 ; Username = Init1 = ATZ ; Password = Modem = /dev/ttyUSB0 Baud = 460800 [Dialer tmn] Init2 = ATZ Init3 = AT+CGDCONT=1,"ip","internet" Stupid Mode = 1 ISDN = 0 Phone = *99***1# Ask Password = 0 Modem = /dev/ttyUSB0 Username = tmn Dial Command = ATD Password = tmn Baud = 460800 So my ZTE works or worked on /dev/ttyUSB0 Hope that information can help. Btw, about news: my new HUAWEI mobile broadband rocks :) , the detection is quite fast and nm-applet also show the signal strength, on ZTE signal strength never change. Best regards, -- Sérgio M. B. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Automagically restart wifi connection
What kind of connection loss do you have? Can you still ping the access point for example? Is there any error in system log or dmesg? I have encountered similar problems with some AP's, and sometimes it was a bug in AP. On Monday 20 June 2011 10:51:11 Mauricio Tavares wrote: > I have here a machine that is connected to the internet through > wireless. Every so often it will loose connection to the router. And > to get it back I have to maually go into Network Manager, disable the > connection, and then re-enable it. Is there a way to tell network > manager if it loses its connection it should do something like that? > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Alex Pyattaev, Researcher, Tampere University of Technology, Finland ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to Test NetworkManager 0.9
On Mon, Jun 20, 2011 at 3:27 AM, Alex Pyattaev wrote: > David, > I'm a gentoo user too, and I was thinking maybe we could cooperate on this > thing. For example, I have 2 nice ebuilds that compile NM and applet from the > source tree unpacked somewhere in your system. This way you do not have to > bother with dangling files and you can always see what's installed. Both are > attached. > Don't forget to run ebuild ... digest before installing. > And do not put those to portage tree directly, just run ebuild, this way they > will not get erased upon next emerge --sync. > If you have any preliminary data on supplicant interface, I'd be happy to try > it too ASAP! > Thank you, > Alex Awesome, I'll follow this up with you through private e-mail before we get too Off-Topic, and maybe we can find ways to make it easier to do tests for NM 0.9. Thanks! David E. Narvaez ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Automagically restart wifi connection
I have here a machine that is connected to the internet through wireless. Every so often it will loose connection to the router. And to get it back I have to maually go into Network Manager, disable the connection, and then re-enable it. Is there a way to tell network manager if it loses its connection it should do something like that? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ModemManager: new 'iridium' plugin
Hoola,
So, finished developing a new 'iridium' [1] plugin for ModemManager.
Nothing prevents you now from easily connecting to the Internet from
anywhere in the Earth :-) (through the Iridium satellite network). The
plugin works with the "Iridium 9522B Satellite Transceiver" RS232 modem
[2], and should probably work with similar or newer modems. This plugin
is a bit special, as it simulates a GSM modem while it really isn't one.
Most AT commands are the standard ones for GSM modems, but of course we
cannot play with changing bands or trying to enable/disable 3G, and we
are limited to GSM-only-like circuit-switched connections.
Iridium-specific features like SBD (Short Burst Data) are not covered.
Some of the specific things that needed to take care of for this modem
to work:
* Minor fixes w.r.t how the modem writes the replies, like allowing no
whitespaces before the CPIN? reply, or allowing leading zeroes in
numbers in CREG responses.
* Customized SMS storage setup, flow control setup, and signal quality
retrieval commands.
* Allowed mode and Network technology handling, simulating a GSM-only
device.
* Skipped ICCID/IMSI check, not available in the Iridium SIM cards.
* Modified the generic implementation so that plugins can specify if
they support PS network, so that all GPRS network registration status
and PDP context handling commands can be skipped.
* Modified the generic implementation so that plugins can implement
their own Operator name and code retrieval (fixed to "Iridium" and
"90103" respectively in this plugin).
* Generic initialization fully changed, so that ATZ is sent alone and a
500ms graceful time is given to the modem before sending remaining
initialization commands.
* Modified both MM and NM so that plugins can specify how much time NM
should wait for the IP setup in pppd. This value is fixed to 20s by
default, but we need a larger value in case of Iridium (200s is given
here).
* The Iridium modem doesn't seem to like the generic disconnection
process where just port flashing is done once pppd hanged up the call.
Closing and opening again the port after some short time seems to deal
with that issue.
Attached is also a python script that creates a new Iridium connection
in NM (0.8) and tries to enable it. You may want to remove
'ignore-auto-routes', 'ignore-auto-dns' and 'never-default' options in
the IPv4 section, which were added mainly for testing purposes. You
should also be able to create a new connection with
nm-connection-editor: New 'Broadband' connection, set Country as not
listed, manually set provider as 'Iridium' (GSM), and place an empty
APN. Then remove *99# and set the new number to dial: 00881625.
This development is ready for review in the 'plugin-iridium' branch in
the following Gitorious repository [3]:
git://gitorious.org/lanedo/modemmanager.git
The NetworkManager changes needed (just 1 commit) are available in the
'08-mm-ip-timeout' branch in the following Gitorious repository [4]:
git://gitorious.org/lanedo/networkmanager.git
This branch is based on NM_0_8, but the commit [5] can be cherry-picked
to git master without conflict.
Cheers!
[1] I wanted to call the plugin 'dysprosium', but jokes that need to be
explained are not funny :-P
[2] http://www.iridium.com/products/Iridium9522SatelliteTransceiver.aspx
[3] https://gitorious.org/lanedo/modemmanager
[4] https://gitorious.org/lanedo/networkmanager
[5]
https://gitorious.org/lanedo/networkmanager/commit/4e2d10816d0cfbbbebd3502718664e1116385dae
--
Aleksander
#!/bin/env python
# -*- Mode: Python; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
#
# Copyright (C) 2009 Red Hat, Inc.
# Copyright (C) 2011 Aleksander Morgado
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
import dbus
import glib
import sys
import posix
import time
uuid = "aabbccddeeffaabbccddeeffaabbccddeeff"
s_con = { 'id': 'Iridium',
'uuid':uuid,
'type':'gsm',
'autoconnect': False }
s_gsm = { 'number': '00881625' }
s_ip4 = { 'method': 'auto',
'ignore-auto-routes': True,
'ignore-auto-dns':True,
'never-default': True }
s_ser = { 'baud': 9600L }
s_ppp = {}
con = { 'connection': s_con,
'gsm': s_gsm,
'ipv4': s_ip4,
Re: Wireless Keys stored unencrypted?
Hi On Sat, Jun 18, 2011 at 7:57 AM, Darren Albers wrote: > While doing some research I noticed that wireless keys are located > unencrypted in /etc/sysconfig/network-scripts It even does this when > I set the wireless to not be a system-connection. It used to be that > wireless keys were stored in the keyring which seems much safer to me > than storing them locally unencrypted. interesting, I am not an nm developer but this seems to stem from keyfile plugin and relies on file selinux label/permission for protection. I also do not see an option to not save the password. > > Thank you! > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list > -- -- Ritesh Khadgaray LinuX N Stuff Ph: +919970164885 Eat Right, Exercise, Die Anyway. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to Test NetworkManager 0.9
David,
I'm a gentoo user too, and I was thinking maybe we could cooperate on this
thing. For example, I have 2 nice ebuilds that compile NM and applet from the
source tree unpacked somewhere in your system. This way you do not have to
bother with dangling files and you can always see what's installed. Both are
attached.
Don't forget to run ebuild ... digest before installing.
And do not put those to portage tree directly, just run ebuild, this way they
will not get erased upon next emerge --sync.
If you have any preliminary data on supplicant interface, I'd be happy to try
it too ASAP!
Thank you,
Alex
On Sunday 19 June 2011 10:59:27 David Narvaez wrote:
> On Mon, Jun 13, 2011 at 10:11 AM, David Narvaez
>
> wrote:
> > I'll find that out today about that patch and fix the D-Bus issue
> > which should get me up and running with NM 0.9.
>
> Hi all, now posting from my laptop with NM 0.9 finally!
>
> Thanks Dan for pointing me in the direction of the new DBus interface
> for wpa_supplicant.
>
> Lamarque, I'd like to know if I could reach you through private e-mail
> to clarify some stuff before documenting this process as I think I did
> some extra work that was not needed (at least not in Gentoo-based
> distros).
>
> Thanks again.
>
> David E. Narvaez
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Alex Pyattaev,
Researcher,
Tampere University of Technology,
Finland# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/net-misc/networkmanager/networkmanager-0.8.4.0-r1.ebuild,v
1.2 2011/06/09 01:41:03 sping Exp $
EAPI="2"
inherit autotools eutils gnome.org linux-info
MY_SRC_DIR="/opt/net-misc/networkmanager/NetworkManager"
DESCRIPTION="Network configuration and management in an easy way. Desktop
environment independent."
HOMEPAGE="http://www.gnome.org/projects/NetworkManager/";
SRC_URI=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~arm ~ppc ~ppc64 ~x86"
RDEPEND=">=sys-apps/dbus-1.2"
DEPEND="${RDEPEND}"
#S=${WORKDIR}/${MY_P}
src_prepare() {
# backported ifnet patches
#epatch "${FILESDIR}/${P}-shared-connection.patch"
#epatch "${FILESDIR}/${P}-fix-tests.patch"
#epatch "${FILESDIR}/${P}-ifnet-smarter-write.patch"
cp -r ${MY_SRC_DIR} ${S}
eautoreconf
}
src_configure() {
ECONF="--disable-more-warnings
--localstatedir=/var
--with-distro=gentoo
--with-dbus-sys-dir=/etc/dbus-1/system.d
--with-udev-dir=/lib/udev
--with-iptables=/sbin/iptables
$(use_enable doc gtk-doc)
$(use_with doc docs)
$(use_with resolvconf)"
# default is dhcpcd (if none or both are specified), ISC dchclient
otherwise
if use dhclient ; then
if use dhcpcd ; then
ECONF="${ECONF} --with-dhcpcd --without-dhclient"
else
ECONF="${ECONF} --with-dhclient --without-dhcpcd"
fi
else
ECONF="${ECONF} --with-dhcpcd --without-dhclient"
fi
econf ${ECONF}
}
src_install() {
emake DESTDIR="${D}" install || die "emake install failed"
# Need to keep the /var/run/NetworkManager directory
keepdir /var/run/NetworkManager
# Need to keep the /etc/NetworkManager/dispatched.d for dispatcher
scripts
keepdir /etc/NetworkManager/dispatcher.d
#dodoc AUTHORS ChangeLog NEWS README TODO || die "dodoc failed"
# Add keyfile plugin support
keepdir /etc/NetworkManager/system-connections
insinto /etc/NetworkManager
#newins "${FILESDIR}/nm-system-settings.conf-ifnet"
nm-system-settings.conf \
# || die "newins failed"
}
pkg_postinst() {
elog "You will need to reload DBus if this is your first time
installing"
elog "NetworkManager, or if you're upgrading from 0.7 or older."
elog ""
}
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/gnome-extra/nm-applet/nm-applet-0.8.4.ebuild,v 1.2
2011/05/18 16:38:28 ssuominen Exp $
EAPI=2
inherit gnome2
MY_SRC_DIR="/opt/net-misc/nm-applet/network-manager-applet"
DESCRIPTION="Gnome applet for NetworkManager."
HOMEPAGE="http://projects.gnome.org/NetworkManager/";
SRC_URI=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~ppc ~x86"
IUSE="bluetooth"
# FIXME: bluetooth is automagic
RDEPEND=">=dev-libs/glib-2.16:2
>=dev-libs/dbus-glib-0.88
>=sys-apps/dbus-1.4.1
>=x11-libs/gtk+-2.18:2
>=gnome-base/gconf-2.20:2
>=x11-libs/libnotify-0.4.3
>=gnome-base/libglade-2:2.0
>=gnome-base/gnome-keyring-2.20
>=dev-lib
