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 <edb...@gmail.com> 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 <kato...@freaknet.org> 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@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
