To all those trying to install netman,

Please note that now the directories for installation have changed to
comply with the usual placement of executables. /usr/bin is required
to contain only executables, creating a directory in it may disrupt
the behaviour of unrelated programs.

The new place for netman, the frontend is:
/usr/bin

And the place for backend is, the workhorse is:
/usr/lib/netman/bin

It is very important for the backend executable to have an SUID
belonging to root. This what ls -l /usr/lib/netman/bin displays:
-rwsr-xr-x 1 root root 38112 Sep 13 14:02 backend

To allow netman to automatically connect on startup use --auto-conn
parameter for the frontend.

Create this directory to hold the essid files:
/etc/network/wifi

Modify /etc/network/interfaces to contain:
iface wlan0 inet dhcp

To avoid the OS from trying to automatically connect on boot do NOT
use the phrase:
auto wlan0

In your window manager of desktop make sure netman is automatically
started on startup. This step is not necessary: netman can be started
on request and can be terminated without affecting the status of the
active connection.

Hopefully, this set everyone interested in using this project going.

Edward



On 14/09/2015, Edward Bartolo <edbarx@???> wrote:
> Hi Aitor,
>
> Hopefully, now the BUG has been removed. On my computer disconnecting
> now is respected even in auto-connect mode. Now, you can continue
> packaging netman.
>
> Edward
>
> On 14/09/2015, KatolaZ <katolaz@???> wrote:
>> On Mon, Sep 14, 2015 at 10:28:09AM -0400, Steve Litt wrote:
>>
>> [cut]
>>
>>>
>>> KatolaZ,
>>>
>>> Back in the day I used to do #include "/path/absolute" all the time.
>>> I'm pretty sure #include #include "../path/relative" would work too.
>>>
>>> I prefer to annunciate the include in the source file so I don't have
>>> to document the -I.
>>>
>>
>> Hi Steve,
>>
>> the problem is that, as you know, when you #include a file with "" the
>> compiler searches first for the current directory and then for the
>> standard include path (to which it adds any paths specified through
>> -I). Using anything like "../path/relative" is just confusing, because
>> you should then avoid to move any of your include files to a different
>> path. It is usually found more convenient to specify a directory to be
>> added to the include path, and there is indeed no good reason to
>> specify a folder at a level deeper than strictly needed, just to allow
>> "../path/relative" to point to something useful...
>>
>> I mean, if all the include files of a project live into subfolders of
>> "SOMETHING/projectdir/include/" there is no reason to add
>> "SOMETHING/projectdir/src" to the includepath and then use
>> "../include/whatever.h" to include your file. This just adds unneeded
>> hurdles to changes/portability. And if you decide to move your
>> includes somewhere else, you just need to add the right path to the
>> include-path (not one of its subdirectories, which is really
>> confusing)
>>
>> My2Cents
>>
>> KatolaZ
>>
>> --
>> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
>> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
>> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
>> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>