Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi all,

This morning I reviewed the C code for the backend to gracefully
account for error situations. At the moment I am using the latest
edited version to test whether it behaves so that I may git push the
latest changes.

As I am approaching the completion of this present and first project
for Devuan, I am thinking of what I can do next to help the Devuan
project develop. I have a small project that is already finished that
I wish to upload to Devuan. This is a simple frontend for dict, the
online dictionary but this is only the work of about 30 minutes of
coding. I wish to give more than that.


Edward

On 17/09/2015, Edward Bartolo  wrote:
> Hi Aitor,
>
> Yes.
>
> Edward.
>
> On 25/02/2032, aitor_czr  wrote:
>> So, the content of "/etc/netman.conf" would be:
>>
>> backend=/usr/lib/netman/bin/backend
>>
>> Isn't it?
>>
>> Aitor.
>>
>> On 17/09/15 16:28, Edward Bartolo wrote:
>>> Hi Aitor,
>>>
>>> Agreed. Shall I also remove the ability to have the backend placement
>>> set in an /etc/netman.conf file?
>>>
>>> By itself the frontend is unable to give root privileges to whatever
>>> is pointed to in that file. So, I see no problem in having an
>>> /etc/netman.conf file. But I stand to being corrected if this is not
>>> the case.
>>>
>>> Edward
>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

I think avoiding to use two links for the backend would help to keep
the project as simple as possible. Also using the version as a
directory would indicate that more than one concurrent version of
netman would be installed.

The frontend, netman, expects to find the backend named as backend. If
this is to be changed, I will need to modify the frontend. We can also
opt to use an /etc settings file to enable use use whatever location
and name for the backend.

So, an /etc conf file (/etc/netman.conf) would look like this:
backend=/usr/lib/netman/0.1.0/netman-backend

In case you instruct me to use a configuration file for the frontend,
please inform me, to set me going. I can do that in an hour.

Edward

On 16/09/2015, aitor_czr  wrote:
> Thanks Edward, i will try it.
>
> I am considering locating  netman-backend in the following path:
>
> "/usr/lib/netman/0.1.0/"
>
> doing after that the following simbolic links:
>
> # ln -s  /usr/lib/netman/0.1.0/netman-backend  /etc/alternatives/
>
> # ln -s  /etc/alternatives/netman-backend  /usr/bin/
>
>
>
> What do you think about it?
>
> Aitor.
>
> On 16/09/15 09:55, Edward Bartolo wrote:
>> Hi Aitor,
>>
>> Try this command:
>>
>> fpc  -MObjFPC -Scghi -Tlinux -vewnhi -Filib/x86_64-linux
>> -Fl/opt/gnome/lib
>> -Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux/gtk2
>> -Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux
>> -Fu/usr/lib/lazarus/1.2.4/components/lazutils/lib/x86_64-linux
>> -Fu/usr/lib/lazarus/1.2.4/packager/units/x86_64-linux -Fu.
>> -FUlib/x86_64-linux -l -dLCL -dLCLgtk2 netman.lpr
>>
>> Edward
>>
>> On 21/07/2019, aitor_czr  wrote:
>>> >Lazbuild doen't exit as a package, but it would be more appropiate
>>> >fp-compiler (freepascal) than lazarus.
>>> >
>>> >Aitor.
>>> >
>>> >On 16/09/15 05:51, Edward Bartolo wrote:
 >>Hi Aitor,
 >>
 >>Lazarus IDE may not be a hard dependency as it can be avoided by
 >>directly building netman using lazbuild.
 >>
 >>The version number should appropriately be 0.1.0 as this is the first
 >>version and still needs maturation to become proper version 1.0
 >>
 >>Edward
 >>
 >>On 15/09/2015, aitor_czr   wrote:
>> >>> >The only error hurled by lintian is:
>> >>> >
>> >>> >"Could not find a profile matching "{VENDOR}/main" for
>> >>> > vendor
>> >>> >devuan
>> >>> >at /usr/bin/lintian line 979."
>> >>> >
>> >>> >On the other hand, what about the number version of the package?
>> >>> >
>> >>> >0.1.0 ??
>> >>> >
>> >>> >1.0 ??
>> >>> >
>> >>> >Aitor.
>> >>> >
>> >>> >On 15/09/15 15:30, aitor_czr wrote:
  >>I think that the dependencies of netman are the following:
  >>
  >>Build-Depends: debhelper (>= 7.0.50), gcc, lazarus,
  >> dh-python,
  >>python-all-dev
  >>"netman-gui" deps -> netman-backend, libatk1.0-0,
  >> libgdk-pixbuf2.0-0,
  >>libglib2.0-0, libpango-1.0-0, libx11-6
  >>"netman-backend" deps -> libc-bin
  >>
  >>Aitor.
  >>
>> > >>>   Now i must to hit with the correct dependencies. All
>> > >>> the rest is
>> > >>>   done. So, now i need some time to build it into a
>> > >>> chroot jail
>> > >>>using
>> > >>>   pbuilder, etc..
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Ok, thanks.

On 17/09/15 10:21, Edward Bartolo wrote:

Hi Aitor,

I think avoiding to use two links for the backend would help to keep
the project as simple as possible. Also using the version as a
directory would indicate that more than one concurrent version of
netman would be installed.

The frontend, netman, expects to find the backend named as backend. If
this is to be changed, I will need to modify the frontend. We can also
opt to use an /etc settings file to enable use use whatever location
and name for the backend.

So, an /etc conf file (/etc/netman.conf) would look like this:
backend=/usr/lib/netman/0.1.0/netman-backend

In case you instruct me to use a configuration file for the frontend,
please inform me, to set me going. I can do that in an hour.

Edward


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[tilt!]

Hi Aitor & Edward,

i don't think an /etc config file describing a location of a
backend executable is required in the first release.
What would be the motivation for a user to mess with
intrinsics of the software architecture?

Please keep in mind that the backend is a dangerous setuid
executable; keeping it out of PATH is reasonable; indirection
layers - such as symlinks or a configurable location -
would introduce additional risk.

Kind regards,
T.

On 02/24/2032 06:42 PM, aitor_czr wrote:

Ok, thanks.

On 17/09/15 10:21, Edward Bartolo wrote:

Hi Aitor,

I think avoiding to use two links for the backend would help to
keep the project as simple as possible. Also using the version as a
directory would indicate that more than one concurrent version of
netman would be installed.

The frontend, netman, expects to find the backend named as backend.
If this is to be changed, I will need to modify the frontend. We
can also opt to use an /etc settings file to enable use use
whatever location and name for the backend.

So, an /etc conf file (/etc/netman.conf) would look like this:
backend=/usr/lib/netman/0.1.0/netman-backend

In case you instruct me to use a configuration file for the
frontend, please inform me, to set me going. I can do that in an
hour.

Edward

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

I am understanding you are giving me the go-ahead to let netman use an
/etc/netman.conf file. In this case, the location of the backend would
only be dictated by the path specified in the /etc/netman.conf file.

Changes implemented to use an /etc/netman.conf file.

Edward

On 24/02/2032, aitor_czr  wrote:
> Ok, thanks.
>
> On 17/09/15 10:21, Edward Bartolo wrote:
>> Hi Aitor,
>>
>> I think avoiding to use two links for the backend would help to keep
>> the project as simple as possible. Also using the version as a
>> directory would indicate that more than one concurrent version of
>> netman would be installed.
>>
>> The frontend, netman, expects to find the backend named as backend. If
>> this is to be changed, I will need to modify the frontend. We can also
>> opt to use an /etc settings file to enable use use whatever location
>> and name for the backend.
>>
>> So, an /etc conf file (/etc/netman.conf) would look like this:
>> backend=/usr/lib/netman/0.1.0/netman-backend
>>
>> In case you instruct me to use a configuration file for the frontend,
>> please inform me, to set me going. I can do that in an hour.
>>
>> Edward
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

Now, you should be able to place backend wherever you want and to name
it what you like but you have to use a config file under /etc.

New file name:
/etc/netman.conf

Contents of /etc/netman.conf
backend=/usr/lib/netman/bin/backend

Edward

On 17/09/2015, Edward Bartolo  wrote:
> Hi Aitor,
>
> I am understanding you are giving me the go-ahead to let netman use an
> /etc/netman.conf file. In this case, the location of the backend would
> only be dictated by the path specified in the /etc/netman.conf file.
>
> Changes implemented to use an /etc/netman.conf file.
>
> Edward
>
> On 24/02/2032, aitor_czr  wrote:
>> Ok, thanks.
>>
>> On 17/09/15 10:21, Edward Bartolo wrote:
>>> Hi Aitor,
>>>
>>> I think avoiding to use two links for the backend would help to keep
>>> the project as simple as possible. Also using the version as a
>>> directory would indicate that more than one concurrent version of
>>> netman would be installed.
>>>
>>> The frontend, netman, expects to find the backend named as backend. If
>>> this is to be changed, I will need to modify the frontend. We can also
>>> opt to use an /etc settings file to enable use use whatever location
>>> and name for the backend.
>>>
>>> So, an /etc conf file (/etc/netman.conf) would look like this:
>>> backend=/usr/lib/netman/0.1.0/netman-backend
>>>
>>> In case you instruct me to use a configuration file for the frontend,
>>> please inform me, to set me going. I can do that in an hour.
>>>
>>> Edward
>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor and Tilt,

I think, Tilt has a point, if you agree, I can remove the use of an
/etc config file.

Edward

On 17/09/2015, Edward Bartolo  wrote:
> Hi Aitor,
>
> Now, you should be able to place backend wherever you want and to name
> it what you like but you have to use a config file under /etc.
>
> New file name:
> /etc/netman.conf
>
> Contents of /etc/netman.conf
> backend=/usr/lib/netman/bin/backend
>
> Edward
>
> On 17/09/2015, Edward Bartolo  wrote:
>> Hi Aitor,
>>
>> I am understanding you are giving me the go-ahead to let netman use an
>> /etc/netman.conf file. In this case, the location of the backend would
>> only be dictated by the path specified in the /etc/netman.conf file.
>>
>> Changes implemented to use an /etc/netman.conf file.
>>
>> Edward
>>
>> On 24/02/2032, aitor_czr  wrote:
>>> Ok, thanks.
>>>
>>> On 17/09/15 10:21, Edward Bartolo wrote:
 Hi Aitor,

 I think avoiding to use two links for the backend would help to keep
 the project as simple as possible. Also using the version as a
 directory would indicate that more than one concurrent version of
 netman would be installed.

 The frontend, netman, expects to find the backend named as backend. If
 this is to be changed, I will need to modify the frontend. We can also
 opt to use an /etc settings file to enable use use whatever location
 and name for the backend.

 So, an /etc conf file (/etc/netman.conf) would look like this:
 backend=/usr/lib/netman/0.1.0/netman-backend

 In case you instruct me to use a configuration file for the frontend,
 please inform me, to set me going. I can do that in an hour.

 Edward
>>>
>>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

This is the case, for example, of Qt. Qtchooser chooses between Qt4 or 
Qt5 depending on the installed package: qt4-default, or qt5-default.


But i think this is not our case... So, i will use the directory 
suggested by Tilt, if you agree.


Aitor.

On 17/09/15 10:21, Edward Bartolo wrote:

Also using the version as a
directory would indicate that more than one concurrent version of
netman would be installed.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor and Tilt,

As it is, the frontend can use an /etc config file for the location
and name of the backend but the GUI does NOT provide any means to
alter the config file.

Do you, Tilt, still think that I have to remove the use of a config
file even though users have to edit it by hand? The only purpose of
the config file is to specify the full path to the backend executable.

Edward

On 17/09/2015, Edward Bartolo  wrote:
> Hi Aitor and Tilt,
>
> I think, Tilt has a point, if you agree, I can remove the use of an
> /etc config file.
>
> Edward
>
> On 17/09/2015, Edward Bartolo  wrote:
>> Hi Aitor,
>>
>> Now, you should be able to place backend wherever you want and to name
>> it what you like but you have to use a config file under /etc.
>>
>> New file name:
>> /etc/netman.conf
>>
>> Contents of /etc/netman.conf
>> backend=/usr/lib/netman/bin/backend
>>
>> Edward
>>
>> On 17/09/2015, Edward Bartolo  wrote:
>>> Hi Aitor,
>>>
>>> I am understanding you are giving me the go-ahead to let netman use an
>>> /etc/netman.conf file. In this case, the location of the backend would
>>> only be dictated by the path specified in the /etc/netman.conf file.
>>>
>>> Changes implemented to use an /etc/netman.conf file.
>>>
>>> Edward
>>>
>>> On 24/02/2032, aitor_czr  wrote:
 Ok, thanks.

 On 17/09/15 10:21, Edward Bartolo wrote:
> Hi Aitor,
>
> I think avoiding to use two links for the backend would help to keep
> the project as simple as possible. Also using the version as a
> directory would indicate that more than one concurrent version of
> netman would be installed.
>
> The frontend, netman, expects to find the backend named as backend. If
> this is to be changed, I will need to modify the frontend. We can also
> opt to use an /etc settings file to enable use use whatever location
> and name for the backend.
>
> So, an /etc conf file (/etc/netman.conf) would look like this:
> backend=/usr/lib/netman/0.1.0/netman-backend
>
> In case you instruct me to use a configuration file for the frontend,
> please inform me, to set me going. I can do that in an hour.
>
> Edward


>>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

Agreed. Shall I also remove the ability to have the backend placement
set in an /etc/netman.conf file?

By itself the frontend is unable to give root privileges to whatever
is pointed to in that file. So, I see no problem in having an
/etc/netman.conf file. But I stand to being corrected if this is not
the case.

Edward

On 24/02/2032, aitor_czr  wrote:
> This is the case, for example, of Qt. Qtchooser chooses between Qt4 or
> Qt5 depending on the installed package: qt4-default, or qt5-default.
>
> But i think this is not our case... So, i will use the directory
> suggested by Tilt, if you agree.
>
> Aitor.
>
> On 17/09/15 10:21, Edward Bartolo wrote:
>> Also using the version as a
>> directory would indicate that more than one concurrent version of
>> netman would be installed.
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

So, the content of "/etc/netman.conf" would be:

backend=/usr/lib/netman/bin/backend

Isn't it?

Aitor.

On 17/09/15 16:28, Edward Bartolo wrote:

Hi Aitor,

Agreed. Shall I also remove the ability to have the backend placement
set in an /etc/netman.conf file?

By itself the frontend is unable to give root privileges to whatever
is pointed to in that file. So, I see no problem in having an
/etc/netman.conf file. But I stand to being corrected if this is not
the case.

Edward


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

Yes.

Edward.

On 25/02/2032, aitor_czr  wrote:
> So, the content of "/etc/netman.conf" would be:
>
> backend=/usr/lib/netman/bin/backend
>
> Isn't it?
>
> Aitor.
>
> On 17/09/15 16:28, Edward Bartolo wrote:
>> Hi Aitor,
>>
>> Agreed. Shall I also remove the ability to have the backend placement
>> set in an /etc/netman.conf file?
>>
>> By itself the frontend is unable to give root privileges to whatever
>> is pointed to in that file. So, I see no problem in having an
>> /etc/netman.conf file. But I stand to being corrected if this is not
>> the case.
>>
>> Edward
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Lazbuild doen't exit as a package, but it would be more appropiate 
fp-compiler (freepascal) than lazarus.


Aitor.

On 16/09/15 05:51, Edward Bartolo wrote:

Hi Aitor,

Lazarus IDE may not be a hard dependency as it can be avoided by
directly building netman using lazbuild.

The version number should appropriately be 0.1.0 as this is the first
version and still needs maturation to become proper version 1.0

Edward

On 15/09/2015, aitor_czr  wrote:

>The only error hurled by lintian is:
>
>"Could not find a profile matching "{VENDOR}/main" for vendor devuan
>at /usr/bin/lintian line 979."
>
>On the other hand, what about the number version of the package?
>
>0.1.0 ??
>
>1.0 ??
>
>Aitor.
>
>On 15/09/15 15:30, aitor_czr wrote:

>>I think that the dependencies of netman are the following:
>>
>>Build-Depends: debhelper (>= 7.0.50), gcc, lazarus, dh-python,
>>python-all-dev
>>"netman-gui" deps -> netman-backend, libatk1.0-0, libgdk-pixbuf2.0-0,
>>libglib2.0-0, libpango-1.0-0, libx11-6
>>"netman-backend" deps -> libc-bin
>>
>>Aitor.
>>

>>>   Now i must to hit with the correct dependencies. All the rest is
>>>   done. So, now i need some time to build it into a chroot jail using
>>>   pbuilder, etc..


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Thanks Edward, i will try it.

I am considering locating  netman-backend in the following path:

"/usr/lib/netman/0.1.0/"

doing after that the following simbolic links:

# ln -s  /usr/lib/netman/0.1.0/netman-backend  /etc/alternatives/

# ln -s  /etc/alternatives/netman-backend  /usr/bin/



What do you think about it?

Aitor.

On 16/09/15 09:55, Edward Bartolo wrote:

Hi Aitor,

Try this command:

fpc  -MObjFPC -Scghi -Tlinux -vewnhi -Filib/x86_64-linux
-Fl/opt/gnome/lib
-Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux/gtk2
-Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux
-Fu/usr/lib/lazarus/1.2.4/components/lazutils/lib/x86_64-linux
-Fu/usr/lib/lazarus/1.2.4/packager/units/x86_64-linux -Fu.
-FUlib/x86_64-linux -l -dLCL -dLCLgtk2 netman.lpr

Edward

On 21/07/2019, aitor_czr  wrote:

>Lazbuild doen't exit as a package, but it would be more appropiate
>fp-compiler (freepascal) than lazarus.
>
>Aitor.
>
>On 16/09/15 05:51, Edward Bartolo wrote:

>>Hi Aitor,
>>
>>Lazarus IDE may not be a hard dependency as it can be avoided by
>>directly building netman using lazbuild.
>>
>>The version number should appropriately be 0.1.0 as this is the first
>>version and still needs maturation to become proper version 1.0
>>
>>Edward
>>
>>On 15/09/2015, aitor_czr   wrote:

>>> >The only error hurled by lintian is:
>>> >
>>> >"Could not find a profile matching "{VENDOR}/main" for vendor
>>> >devuan
>>> >at /usr/bin/lintian line 979."
>>> >
>>> >On the other hand, what about the number version of the package?
>>> >
>>> >0.1.0 ??
>>> >
>>> >1.0 ??
>>> >
>>> >Aitor.
>>> >
>>> >On 15/09/15 15:30, aitor_czr wrote:

 >>I think that the dependencies of netman are the following:
 >>
 >>Build-Depends: debhelper (>= 7.0.50), gcc, lazarus, dh-python,
 >>python-all-dev
 >>"netman-gui" deps -> netman-backend, libatk1.0-0, libgdk-pixbuf2.0-0,
 >>libglib2.0-0, libpango-1.0-0, libx11-6
 >>"netman-backend" deps -> libc-bin
 >>
 >>Aitor.
 >>

> >>>   Now i must to hit with the correct dependencies. All the rest is
> >>>   done. So, now i need some time to build it into a chroot jail
> >>>using
> >>>   pbuilder, etc..


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

Lazarus IDE may not be a hard dependency as it can be avoided by
directly building netman using lazbuild.

The version number should appropriately be 0.1.0 as this is the first
version and still needs maturation to become proper version 1.0

Edward

On 15/09/2015, aitor_czr  wrote:
> The only error hurled by lintian is:
>
>"Could not find a profile matching "{VENDOR}/main" for vendor devuan
> at /usr/bin/lintian line 979."
>
> On the other hand, what about the number version of the package?
>
> 0.1.0 ??
>
> 1.0 ??
>
> Aitor.
>
> On 15/09/15 15:30, aitor_czr wrote:
>> I think that the dependencies of netman are the following:
>>
>> Build-Depends: debhelper (>= 7.0.50), gcc, lazarus, dh-python,
>> python-all-dev
>> "netman-gui" deps -> netman-backend, libatk1.0-0, libgdk-pixbuf2.0-0,
>> libglib2.0-0, libpango-1.0-0, libx11-6
>> "netman-backend" deps -> libc-bin
>>
>> Aitor.
>>
>>>   Now i must to hit with the correct dependencies. All the rest is
>>>   done. So, now i need some time to build it into a chroot jail using
>>>   pbuilder, etc..
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

The only error hurled by lintian is:

  "Could not find a profile matching "{VENDOR}/main" for vendor devuan 
at /usr/bin/lintian line 979."


On the other hand, what about the number version of the package?

0.1.0 ??

1.0 ??

Aitor.

On 15/09/15 15:30, aitor_czr wrote:

I think that the dependencies of netman are the following:

Build-Depends: debhelper (>= 7.0.50), gcc, lazarus, dh-python, 
python-all-dev
"netman-gui" deps -> netman-backend, libatk1.0-0, libgdk-pixbuf2.0-0, 
libglib2.0-0, libpango-1.0-0, libx11-6

"netman-backend" deps -> libc-bin

Aitor.


  Now i must to hit with the correct dependencies. All the rest is
  done. So, now i need some time to build it into a chroot jail using
  pbuilder, etc..


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

I think that the dependencies of netman are the following:

Build-Depends: debhelper (>= 7.0.50), gcc, lazarus, dh-python, 
python-all-dev
"netman-gui" deps -> netman-backend, libatk1.0-0, libgdk-pixbuf2.0-0, 
libglib2.0-0, libpango-1.0-0, libx11-6

"netman-backend" deps -> libc-bin

Aitor.


  Now i must to hit with the correct dependencies. All the rest is
  done. So, now i need some time to build it into a chroot jail using
  pbuilder, etc...


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[fsmithred]

I added 'iface wlan0 inet dhcp' while there was a static ip configuration
in place.

With the dhcp line before the static configuration or with the dhcp line
in a separate file under interfaces.d, boot hangs for a short time while
it's trying dhcp, then boot completes, and it's connected with the static
ip number. I assume it hangs while trying to connect without the wpa
passphrase.

With the dhcp line at the end of /etc/network/interfaces, there's no delay
at boot, and it connects using the static ip number.

In all cases, if I run netman, it shows that I'm connected, it can
disconnect, and if I reconnect, I get an ip address in the dhcp range.

I didn't test it with wireless encryption turned off.

-fsr


On 09/14/2015 06:59 AM, fsmithred wrote:
> Having 'iface wlan0 inet dhcp' in /etc/network/interfaces causes no
> problem if there is no wireless interface, but it might cause a problem if
> someone already has wlan0 configured. I guess I should test that, too.
> (Need to reboot for that.)
> 
> If netman is going to inject that line into the interfaces file, it might
> be good to check if the interface is already configured, and give the user
> a warning and choice.
> 
> FYI, it also works if you put the line into a file under
> /etc/network/interfaces.d/. The default interfaces file in jessie sources
> that directory.
> 
> -fsr
> 
> 
> On 09/14/2015 03:24 AM, Edward Bartolo wrote:
>> Hi,
>>
>> I tested my installation, Devuan 64 bit, for unwanted behaviour when
>> /etc/network/interfaces contains lines as follows but which point to
>> inexistent physical devices:
>>
>> iface wlan1 inet dhcp
>>
>> The OS didn't complain and I was able to use netman as usual without
>> the least of issues. Needless to state, I kept the original "iface
>> wlan0 inet dhcp".
>>
>> This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
>> # ifup wlan1
>> Internet Systems Consortium DHCP Client 4.3.1
>> Copyright 2004-2014 Internet Systems Consortium.
>> All rights reserved.
>> For info, please visit https://www.isc.org/software/dhcp/
>>
>> Cannot find device "wlan1"
>> Bind socket to interface: No such device
>>
>> If you think you have received this message due to a bug rather
>> than a configuration issue please read the section on submitting
>> bugs on either our web page at www.isc.org or in the README file
>> before submitting a bug.  These pages explain the proper
>> process and the information we find helpful for debugging..
>>
>> exiting.
>> Failed to bring up wlan1.
>>
>>
>> And this is with "iface wlan1 inet dhcp" removed from 
>> /etc/network/interfaces:
>> root@edbarx-pc:/dev# ifup wlan1
>> Ignoring unknown interface wlan1=wlan1.
>>
>> Both instances fail to connect but with different error messages.
>>
>>
>> Edward.
>>
>>
>> On 14/09/2015, Edward Bartolo  wrote:
>>> Hi all,
>>>
>>> The additional ability to recognize wlan1, wlan2, wlan3, etc, in
>>> something I will do as soon as I can.
>>>
>>> Regarding the use of "iface wlan0 inet dhcp" in
>>> /etc/network/interfaces, I have no other option unless someone really
>>> versed in network configuration provides an alternative that works and
>>> that doesn't disrupt the already working code.
>>>
>>> I have already a germinating idea of how to implement support for
>>> wlanN. This is by naming the essid files as wlanX_essid. This way only
>>> the essid saving function and the frontend essid listing functions
>>> would need to be changed. The connecting functions of the backend
>>> would simply parse the filename to extract the device name, and it
>>> would be done.
>>>
>>> However, at this time of the year, I am very busy doing other work
>>> besides programming for Devuan. At the moment, I am busy planting my
>>> vegetables which cannot wait as that depends on the season, and a
>>> couple of weeks makes a whole difference.
>>>
>>> Edward
>>>
>>> On 13/09/2015, aitor_czr  wrote:
 Ok, I like XFCE4 of course.

 Aitor.

 El 13/09/15 a las 20:13, Edward Bartolo escribió:

 Hi aitor, I forgot to write that the final step is to let netman be
 automatically run as soon as a user boots into XFCE4 or desktop or
 window manager. Edward On 13/09/2015, Edward Bartolo 
 wrote:
>>> Hi aitor,
>>>
>>> I think, the time has come to start thinking about producing a .deb
>>> package for netman. However, we will have to use a post installation
>>> script to add the line:
>>>
>>> "iface wlan0 inet dhcp"
>>>
>>> to /etc/network/interfaces. The script has also to create a new
>>> directory under /usr/bin with the name netman ie  /usr/bin/netman will
>>> hold both the frontend and the backend.
>>>
>>> The SUID for backend must be changed to that belonging to root. I do
>>> this as follows:
>>> chown root:root backend
>>> chmod u+s backend
>>>
>>> A new directory under /etc/network with the name wifi must 

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Ok, thank you.

On 14/09/15 13:10, Edward Bartolo wrote:

Hi Aitor,

I discovered that disconnecting immediately calls auto-connect
restoring the connection. I will 'git push' the necessary changes to
netman after making sure this behaviour is rectified. However, this
afternoon I am too busy to continue working on the computer. I will
make myself available as soon as I can.

Thanks for helping in the project.

Edward


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

I discovered that disconnecting immediately calls auto-connect
restoring the connection. I will 'git push' the necessary changes to
netman after making sure this behaviour is rectified. However, this
afternoon I am too busy to continue working on the computer. I will
make myself available as soon as I can.

Thanks for helping in the project.

Edward

On 14/09/2015, Edward Bartolo  wrote:
> Hi Aitor,
>
> Don't forget that we also need to create a subdirectory, 'wifi', in
> /etc/network. The full path to the new directory will be:
> /etc/network/wifi
>
> Together with the above, /etc/network/interfaces should have this line
> added if not already included.
>
> iface wlan0 inet dhcp
>
> Without it ifdown fails, unless someone more versed in networking
> gives an equally simple alternative.
>
>
> Thanks,
>
> Edward.
>
> On 14/09/2015, aitor_czr  wrote:
>> Ok :-)
>>
>> On 14/09/15 12:23, Edward Bartolo wrote:
>>> Hi Aitor,
>>>
>>> I pushed the necessary changes in netman. The changes are only in
>>> backend.pas to account for the new placement of backend.
>>>
>>> Please, note that the two executables will be placed according to
>>> Tilt's suggestion so that we comply with where executables should be
>>> placed.
>>>
>>> Thanks.
>>>
>>> Edward.
>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[fsmithred]

Having 'iface wlan0 inet dhcp' in /etc/network/interfaces causes no
problem if there is no wireless interface, but it might cause a problem if
someone already has wlan0 configured. I guess I should test that, too.
(Need to reboot for that.)

If netman is going to inject that line into the interfaces file, it might
be good to check if the interface is already configured, and give the user
a warning and choice.

FYI, it also works if you put the line into a file under
/etc/network/interfaces.d/. The default interfaces file in jessie sources
that directory.

-fsr


On 09/14/2015 03:24 AM, Edward Bartolo wrote:
> Hi,
> 
> I tested my installation, Devuan 64 bit, for unwanted behaviour when
> /etc/network/interfaces contains lines as follows but which point to
> inexistent physical devices:
> 
> iface wlan1 inet dhcp
> 
> The OS didn't complain and I was able to use netman as usual without
> the least of issues. Needless to state, I kept the original "iface
> wlan0 inet dhcp".
> 
> This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
> # ifup wlan1
> Internet Systems Consortium DHCP Client 4.3.1
> Copyright 2004-2014 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
> 
> Cannot find device "wlan1"
> Bind socket to interface: No such device
> 
> If you think you have received this message due to a bug rather
> than a configuration issue please read the section on submitting
> bugs on either our web page at www.isc.org or in the README file
> before submitting a bug.  These pages explain the proper
> process and the information we find helpful for debugging..
> 
> exiting.
> Failed to bring up wlan1.
> 
> 
> And this is with "iface wlan1 inet dhcp" removed from /etc/network/interfaces:
> root@edbarx-pc:/dev# ifup wlan1
> Ignoring unknown interface wlan1=wlan1.
> 
> Both instances fail to connect but with different error messages.
> 
> 
> Edward.
> 
> 
> On 14/09/2015, Edward Bartolo  wrote:
>> Hi all,
>>
>> The additional ability to recognize wlan1, wlan2, wlan3, etc, in
>> something I will do as soon as I can.
>>
>> Regarding the use of "iface wlan0 inet dhcp" in
>> /etc/network/interfaces, I have no other option unless someone really
>> versed in network configuration provides an alternative that works and
>> that doesn't disrupt the already working code.
>>
>> I have already a germinating idea of how to implement support for
>> wlanN. This is by naming the essid files as wlanX_essid. This way only
>> the essid saving function and the frontend essid listing functions
>> would need to be changed. The connecting functions of the backend
>> would simply parse the filename to extract the device name, and it
>> would be done.
>>
>> However, at this time of the year, I am very busy doing other work
>> besides programming for Devuan. At the moment, I am busy planting my
>> vegetables which cannot wait as that depends on the season, and a
>> couple of weeks makes a whole difference.
>>
>> Edward
>>
>> On 13/09/2015, aitor_czr  wrote:
>>> Ok, I like XFCE4 of course.
>>>
>>> Aitor.
>>>
>>> El 13/09/15 a las 20:13, Edward Bartolo escribió:
>>>
>>> Hi aitor, I forgot to write that the final step is to let netman be
>>> automatically run as soon as a user boots into XFCE4 or desktop or
>>> window manager. Edward On 13/09/2015, Edward Bartolo 
>>> wrote:
>> Hi aitor,
>>
>> I think, the time has come to start thinking about producing a .deb
>> package for netman. However, we will have to use a post installation
>> script to add the line:
>>
>> "iface wlan0 inet dhcp"
>>
>> to /etc/network/interfaces. The script has also to create a new
>> directory under /usr/bin with the name netman ie  /usr/bin/netman will
>> hold both the frontend and the backend.
>>
>> The SUID for backend must be changed to that belonging to root. I do
>> this as follows:
>> chown root:root backend
>> chmod u+s backend
>>
>> A new directory under /etc/network with the name wifi must be created
>> i.e. /etc/network/wifi must be an existing directory.
>>
>> Then, the final steps would be to create a launcher for netman, the
>> frontend. To enable automatic attempts at connecting basing on
>> installed essid files under /etc/network/wifi, the parameter
>> --auto-conn must be passed to netman upon invocation. --auto-conn need
>> not be used and netman would not attempt to connect without user
>> intervention. This feature is for those who want to control what
>> happens on their machine.
>>
>> Edward
>>
>>
>>>
>>>
>>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

___
Dng mailing list
Dng@lists.dyne.org

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

Don't forget that we also need to create a subdirectory, 'wifi', in
/etc/network. The full path to the new directory will be:
/etc/network/wifi

Together with the above, /etc/network/interfaces should have this line
added if not already included.

iface wlan0 inet dhcp

Without it ifdown fails, unless someone more versed in networking
gives an equally simple alternative.


Thanks,

Edward.

On 14/09/2015, aitor_czr  wrote:
> Ok :-)
>
> On 14/09/15 12:23, Edward Bartolo wrote:
>> Hi Aitor,
>>
>> I pushed the necessary changes in netman. The changes are only in
>> backend.pas to account for the new placement of backend.
>>
>> Please, note that the two executables will be placed according to
>> Tilt's suggestion so that we comply with where executables should be
>> placed.
>>
>> Thanks.
>>
>> Edward.
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Phred Xmidt]

I'm not getting that with the build you uploaded a few hours ago. But I
didn't get it with yesterday's build, either. When I disconnect after
auto-connect, it stays disconnected. Could that be because I only have one
essid saved?

-fsr


On Mon, Sep 14, 2015 at 7:45 AM, aitor_czr  wrote:

> Ok, thank you.
>
> On 14/09/15 13:10, Edward Bartolo wrote:
>
> Hi Aitor,
>
> I discovered that disconnecting immediately calls auto-connect
> restoring the connection. I will 'git push' the necessary changes to
> netman after making sure this behaviour is rectified. However, this
> afternoon I am too busy to continue working on the computer. I will
> make myself available as soon as I can.
>
> Thanks for helping in the project.
>
> Edward
>
>
>
> ___
> 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

Re: [DNG] [DN Offlist G] netman GIT project

[Steve Litt]

On Mon, 14 Sep 2015 09:39:55 +0100
KatolaZ  wrote:

> On Mon, Sep 14, 2015 at 10:26:25AM +0200, aitor_czr wrote:
> > Hi Edward,
> > 
> > I thick you must change all the headers like:
> > 
> > #include "paths.h"
> > #include "automated_scanner.h"
> > #include "core_functions.h"
> > #include "caller.h"
> > 
> > etc... in the *.c files of the backend of netman by:
> > 
> > #include "../include/paths.h"
> > #include "../include/automated_scanner.h"
> > #include "../include/core_functions.h"
> > #include "../include/caller.h"
> > 
> > because they are not found by the compiler.
> > 
> 
> 
> I think you guys must rather specify an appropriate "-I" flag to gcc
> in the Makefile.  I have never ever seen "../something" in an
> #include
> 
> My2Cents
> 
> KatolaZ

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.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[KatolaZ]

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

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Wow =-O

El 14/09/15 a las 21:33, Rainer Weikusat 
 escribió:

NB: I'm (professionally) maintaining 57 Debian packages, 33 of these
being completely 'original' developments.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi,

I tested my installation, Devuan 64 bit, for unwanted behaviour when
/etc/network/interfaces contains lines as follows but which point to
inexistent physical devices:

iface wlan1 inet dhcp

The OS didn't complain and I was able to use netman as usual without
the least of issues. Needless to state, I kept the original "iface
wlan0 inet dhcp".

This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
# ifup wlan1
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Cannot find device "wlan1"
Bind socket to interface: No such device

If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging..

exiting.
Failed to bring up wlan1.


And this is with "iface wlan1 inet dhcp" removed from /etc/network/interfaces:
root@edbarx-pc:/dev# ifup wlan1
Ignoring unknown interface wlan1=wlan1.

Both instances fail to connect but with different error messages.


Edward.


On 14/09/2015, Edward Bartolo  wrote:
> Hi all,
>
> The additional ability to recognize wlan1, wlan2, wlan3, etc, in
> something I will do as soon as I can.
>
> Regarding the use of "iface wlan0 inet dhcp" in
> /etc/network/interfaces, I have no other option unless someone really
> versed in network configuration provides an alternative that works and
> that doesn't disrupt the already working code.
>
> I have already a germinating idea of how to implement support for
> wlanN. This is by naming the essid files as wlanX_essid. This way only
> the essid saving function and the frontend essid listing functions
> would need to be changed. The connecting functions of the backend
> would simply parse the filename to extract the device name, and it
> would be done.
>
> However, at this time of the year, I am very busy doing other work
> besides programming for Devuan. At the moment, I am busy planting my
> vegetables which cannot wait as that depends on the season, and a
> couple of weeks makes a whole difference.
>
> Edward
>
> On 13/09/2015, aitor_czr  wrote:
>> Ok, I like XFCE4 of course.
>>
>> Aitor.
>>
>> El 13/09/15 a las 20:13, Edward Bartolo escribió:
>>
>> Hi aitor, I forgot to write that the final step is to let netman be
>> automatically run as soon as a user boots into XFCE4 or desktop or
>> window manager. Edward On 13/09/2015, Edward Bartolo 
>> wrote:
 >Hi aitor,
 >
 >I think, the time has come to start thinking about producing a .deb
 >package for netman. However, we will have to use a post installation
 >script to add the line:
 >
 >"iface wlan0 inet dhcp"
 >
 >to /etc/network/interfaces. The script has also to create a new
 >directory under /usr/bin with the name netman ie  /usr/bin/netman will
 >hold both the frontend and the backend.
 >
 >The SUID for backend must be changed to that belonging to root. I do
 >this as follows:
 >chown root:root backend
 >chmod u+s backend
 >
 >A new directory under /etc/network with the name wifi must be created
 >i.e. /etc/network/wifi must be an existing directory.
 >
 >Then, the final steps would be to create a launcher for netman, the
 >frontend. To enable automatic attempts at connecting basing on
 >installed essid files under /etc/network/wifi, the parameter
 >--auto-conn must be passed to netman upon invocation. --auto-conn need
 >not be used and netman would not attempt to connect without user
 >intervention. This feature is for those who want to control what
 >happens on their machine.
 >
 >Edward
 >
 >
>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Rainer Weikusat]

aitor_czr  writes:
> Good job !
>
> Now i must to hit with the correct dependencies. All the rest is
> done. So, now i need some time to build it into a chroot jail using
> pbuilder, etc...

For a native package (as this), you really only need to invoke dh_make
in a suitable way and edit some of the files it generates below
debian/.

NB: I'm (professionally) maintaining 57 Debian packages, 33 of these
being completely 'original' developments.

> On 14/09/15 20:51, Edward Bartolo 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Good job !

Now i must to hit with the correct dependencies. All the rest is done. 
So, now i need some time to build it into a chroot jail using pbuilder, 
etc...


Regards,

Aitor.

On 14/09/15 20:51, Edward Bartolo 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


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

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  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  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

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

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  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

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

I will include the relative path as you instructed. Thanks.

The compiler command is this:
gcc -lm core_functions.c file_functions.c backend.c essid_encoder.c
automated_scanner.c -o backend


Edward.



On 14/09/2015, aitor_czr  wrote:
> Hi Edward,
>
> I thick you must change all the headers like:
>
> #include "paths.h"
> #include "automated_scanner.h"
> #include "core_functions.h"
> #include "caller.h"
>
> etc... in the *.c files of the backend of netman by:
>
> #include "../include/paths.h"
> #include "../include/automated_scanner.h"
> #include "../include/core_functions.h"
> #include "../include/caller.h"
>
> because they are not found by the compiler.
>
> Cheers,
>
> Aitor.
>
>
> On 14/09/15 09:24, Edward Bartolo wrote:
>> Hi,
>>
>> I tested my installation, Devuan 64 bit, for unwanted behaviour when
>> /etc/network/interfaces contains lines as follows but which point to
>> inexistent physical devices:
>>
>> iface wlan1 inet dhcp
>>
>> The OS didn't complain and I was able to use netman as usual without
>> the least of issues. Needless to state, I kept the original "iface
>> wlan0 inet dhcp".
>>
>> This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
>> # ifup wlan1
>> Internet Systems Consortium DHCP Client 4.3.1
>> Copyright 2004-2014 Internet Systems Consortium.
>> All rights reserved.
>> For info, please visit https://www.isc.org/software/dhcp/
>>
>> Cannot find device "wlan1"
>> Bind socket to interface: No such device
>>
>> If you think you have received this message due to a bug rather
>> than a configuration issue please read the section on submitting
>> bugs on either our web page at www.isc.org or in the README file
>> before submitting a bug.  These pages explain the proper
>> process and the information we find helpful for debugging..
>>
>> exiting.
>> Failed to bring up wlan1.
>>
>>
>> And this is with "iface wlan1 inet dhcp" removed from
>> /etc/network/interfaces:
>> root@edbarx-pc:/dev# ifup wlan1
>> Ignoring unknown interface wlan1=wlan1.
>>
>> Both instances fail to connect but with different error messages.
>>
>>
>> Edward.
>>
>>
>> On 14/09/2015, Edward Bartolo  wrote:
>>> Hi all,
>>>
>>> The additional ability to recognize wlan1, wlan2, wlan3, etc, in
>>> something I will do as soon as I can.
>>>
>>> Regarding the use of "iface wlan0 inet dhcp" in
>>> /etc/network/interfaces, I have no other option unless someone really
>>> versed in network configuration provides an alternative that works and
>>> that doesn't disrupt the already working code.
>>>
>>> I have already a germinating idea of how to implement support for
>>> wlanN. This is by naming the essid files as wlanX_essid. This way only
>>> the essid saving function and the frontend essid listing functions
>>> would need to be changed. The connecting functions of the backend
>>> would simply parse the filename to extract the device name, and it
>>> would be done.
>>>
>>> However, at this time of the year, I am very busy doing other work
>>> besides programming for Devuan. At the moment, I am busy planting my
>>> vegetables which cannot wait as that depends on the season, and a
>>> couple of weeks makes a whole difference.
>>>
>>> Edward
>>>
>>> On 13/09/2015, aitor_czr  wrote:
 Ok, I like XFCE4 of course.

 Aitor.

 El 13/09/15 a las 20:13, Edward Bartolo escribió:

 Hi aitor, I forgot to write that the final step is to let netman be
 automatically run as soon as a user boots into XFCE4 or desktop or
 window manager. Edward On 13/09/2015, Edward Bartolo 
 wrote:
>>> Hi aitor,
>>>
>>> I think, the time has come to start thinking about producing a .deb
>>> package for netman. However, we will have to use a post installation
>>> script to add the line:
>>>
>>> "iface wlan0 inet dhcp"
>>>
>>> to /etc/network/interfaces. The script has also to create a new
>>> directory under /usr/bin with the name netman ie  /usr/bin/netman
>>> will
>>> hold both the frontend and the backend.
>>>
>>> The SUID for backend must be changed to that belonging to root. I do
>>> this as follows:
>>> chown root:root backend
>>> chmod u+s backend
>>>
>>> A new directory under /etc/network with the name wifi must be
>>> created
>>> i.e. /etc/network/wifi must be an existing directory.
>>>
>>> Then, the final steps would be to create a launcher for netman, the
>>> frontend. To enable automatic attempts at connecting basing on
>>> installed essid files under /etc/network/wifi, the parameter
>>> --auto-conn must be passed to netman upon invocation. --auto-conn
>>> need
>>> not be used and netman would not attempt to connect without user
>>> intervention. This feature is for those who want to control what
>>> happens on their machine.
>>>
>>> Edward
>>>
>>>

>
>

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

I will rectify this issue in my libpqxx++ project.

https://gitlab.com/aitor_czr/libpqxx/tree/master

Thanks.

Aitor.

On 14/09/15 11:00, aitor_czr wrote:

On 14/09/15 10:39, KatolaZ wrote:

I think you guys must rather specify an appropriate "-I" flag to gcc
in the Makefile.  I have never ever seen "../something" in an
#include

My2Cents

KatolaZ


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Hi,

I'm adding:

lazbuild -B netman.lpr

to the debian/rules. Is it enough to build the frontend? I've never used 
Lazarus.


Thanks in advance,

Aitor.

On 14/09/15 10:52, Edward Bartolo wrote:

Hi,

My experience using gcc directly corroborates what KatolaZ said. This
command works on my computer without the need to edit the .c files as
you suggested.

The gcc command:
gcc -lm -I../include core_functions.c file_functions.c backend.c
essid_encoder.c automated_scanner.c -o backend

Edward


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Hi Edward,

I thick you must change all the headers like:

#include "paths.h"
#include "automated_scanner.h"
#include "core_functions.h"
#include "caller.h"

etc... in the *.c files of the backend of netman by:

#include "../include/paths.h"
#include "../include/automated_scanner.h"
#include "../include/core_functions.h"
#include "../include/caller.h"

because they are not found by the compiler.

Cheers,

Aitor.


On 14/09/15 09:24, Edward Bartolo wrote:

Hi,

I tested my installation, Devuan 64 bit, for unwanted behaviour when
/etc/network/interfaces contains lines as follows but which point to
inexistent physical devices:

iface wlan1 inet dhcp

The OS didn't complain and I was able to use netman as usual without
the least of issues. Needless to state, I kept the original "iface
wlan0 inet dhcp".

This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
# ifup wlan1
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Cannot find device "wlan1"
Bind socket to interface: No such device

If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging..

exiting.
Failed to bring up wlan1.


And this is with "iface wlan1 inet dhcp" removed from /etc/network/interfaces:
root@edbarx-pc:/dev# ifup wlan1
Ignoring unknown interface wlan1=wlan1.

Both instances fail to connect but with different error messages.


Edward.


On 14/09/2015, Edward Bartolo  wrote:

Hi all,

The additional ability to recognize wlan1, wlan2, wlan3, etc, in
something I will do as soon as I can.

Regarding the use of "iface wlan0 inet dhcp" in
/etc/network/interfaces, I have no other option unless someone really
versed in network configuration provides an alternative that works and
that doesn't disrupt the already working code.

I have already a germinating idea of how to implement support for
wlanN. This is by naming the essid files as wlanX_essid. This way only
the essid saving function and the frontend essid listing functions
would need to be changed. The connecting functions of the backend
would simply parse the filename to extract the device name, and it
would be done.

However, at this time of the year, I am very busy doing other work
besides programming for Devuan. At the moment, I am busy planting my
vegetables which cannot wait as that depends on the season, and a
couple of weeks makes a whole difference.

Edward

On 13/09/2015, aitor_czr  wrote:

Ok, I like XFCE4 of course.

Aitor.

El 13/09/15 a las 20:13, Edward Bartolo escribió:

Hi aitor, I forgot to write that the final step is to let netman be
automatically run as soon as a user boots into XFCE4 or desktop or
window manager. Edward On 13/09/2015, Edward Bartolo 
wrote:

Hi aitor,

I think, the time has come to start thinking about producing a .deb
package for netman. However, we will have to use a post installation
script to add the line:

"iface wlan0 inet dhcp"

to /etc/network/interfaces. The script has also to create a new
directory under /usr/bin with the name netman ie  /usr/bin/netman will
hold both the frontend and the backend.

The SUID for backend must be changed to that belonging to root. I do
this as follows:
chown root:root backend
chmod u+s backend

A new directory under /etc/network with the name wifi must be created
i.e. /etc/network/wifi must be an existing directory.

Then, the final steps would be to create a launcher for netman, the
frontend. To enable automatic attempts at connecting basing on
installed essid files under /etc/network/wifi, the parameter
--auto-conn must be passed to netman upon invocation. --auto-conn need
not be used and netman would not attempt to connect without user
intervention. This feature is for those who want to control what
happens on their machine.

Edward






___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi,

My experience using gcc directly corroborates what KatolaZ said. This
command works on my computer without the need to edit the .c files as
you suggested.

The gcc command:
gcc -lm -I../include core_functions.c file_functions.c backend.c
essid_encoder.c automated_scanner.c -o backend

Edward

On 14/09/2015, Edward Bartolo  wrote:
> Hi Aitor,
>
> I will include the relative path as you instructed. Thanks.
>
> The compiler command is this:
> gcc -lm core_functions.c file_functions.c backend.c essid_encoder.c
> automated_scanner.c -o backend
>
>
> Edward.
>
>
>
> On 14/09/2015, aitor_czr  wrote:
>> Hi Edward,
>>
>> I thick you must change all the headers like:
>>
>> #include "paths.h"
>> #include "automated_scanner.h"
>> #include "core_functions.h"
>> #include "caller.h"
>>
>> etc... in the *.c files of the backend of netman by:
>>
>> #include "../include/paths.h"
>> #include "../include/automated_scanner.h"
>> #include "../include/core_functions.h"
>> #include "../include/caller.h"
>>
>> because they are not found by the compiler.
>>
>> Cheers,
>>
>> Aitor.
>>
>>
>> On 14/09/15 09:24, Edward Bartolo wrote:
>>> Hi,
>>>
>>> I tested my installation, Devuan 64 bit, for unwanted behaviour when
>>> /etc/network/interfaces contains lines as follows but which point to
>>> inexistent physical devices:
>>>
>>> iface wlan1 inet dhcp
>>>
>>> The OS didn't complain and I was able to use netman as usual without
>>> the least of issues. Needless to state, I kept the original "iface
>>> wlan0 inet dhcp".
>>>
>>> This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
>>> # ifup wlan1
>>> Internet Systems Consortium DHCP Client 4.3.1
>>> Copyright 2004-2014 Internet Systems Consortium.
>>> All rights reserved.
>>> For info, please visit https://www.isc.org/software/dhcp/
>>>
>>> Cannot find device "wlan1"
>>> Bind socket to interface: No such device
>>>
>>> If you think you have received this message due to a bug rather
>>> than a configuration issue please read the section on submitting
>>> bugs on either our web page at www.isc.org or in the README file
>>> before submitting a bug.  These pages explain the proper
>>> process and the information we find helpful for debugging..
>>>
>>> exiting.
>>> Failed to bring up wlan1.
>>>
>>>
>>> And this is with "iface wlan1 inet dhcp" removed from
>>> /etc/network/interfaces:
>>> root@edbarx-pc:/dev# ifup wlan1
>>> Ignoring unknown interface wlan1=wlan1.
>>>
>>> Both instances fail to connect but with different error messages.
>>>
>>>
>>> Edward.
>>>
>>>
>>> On 14/09/2015, Edward Bartolo  wrote:
 Hi all,

 The additional ability to recognize wlan1, wlan2, wlan3, etc, in
 something I will do as soon as I can.

 Regarding the use of "iface wlan0 inet dhcp" in
 /etc/network/interfaces, I have no other option unless someone really
 versed in network configuration provides an alternative that works and
 that doesn't disrupt the already working code.

 I have already a germinating idea of how to implement support for
 wlanN. This is by naming the essid files as wlanX_essid. This way only
 the essid saving function and the frontend essid listing functions
 would need to be changed. The connecting functions of the backend
 would simply parse the filename to extract the device name, and it
 would be done.

 However, at this time of the year, I am very busy doing other work
 besides programming for Devuan. At the moment, I am busy planting my
 vegetables which cannot wait as that depends on the season, and a
 couple of weeks makes a whole difference.

 Edward

 On 13/09/2015, aitor_czr  wrote:
> Ok, I like XFCE4 of course.
>
> Aitor.
>
> El 13/09/15 a las 20:13, Edward Bartolo escribió:
>
> Hi aitor, I forgot to write that the final step is to let netman be
> automatically run as soon as a user boots into XFCE4 or desktop or
> window manager. Edward On 13/09/2015, Edward Bartolo
> 
> wrote:
 Hi aitor,

 I think, the time has come to start thinking about producing a .deb
 package for netman. However, we will have to use a post
 installation
 script to add the line:

 "iface wlan0 inet dhcp"

 to /etc/network/interfaces. The script has also to create a new
 directory under /usr/bin with the name netman ie  /usr/bin/netman
 will
 hold both the frontend and the backend.

 The SUID for backend must be changed to that belonging to root. I
 do
 this as follows:
 chown root:root backend
 chmod u+s backend

 A new directory under /etc/network with the name wifi must be
 created
 i.e. /etc/network/wifi must be an existing directory.

 Then, the 

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Hi Katolaz,

I tried it but it doesn't work:

aitor@gnuinos:~/netman/backend_src/src$ gcc -g -I../include 
core_functions.c file_functions.c backend.c essid_encoder.c -o backend
core_functions.c:29:36: fatal error: include/core_functions.h: No existe 
el fichero o el directorio

 #include "include/core_functions.h"
^
compilation terminated.
file_functions.c:26:27: fatal error: include/paths.h: No existe el 
fichero o el directorio

 #include "include/paths.h"
   ^
compilation terminated.
backend.c:28:36: fatal error: include/core_functions.h: No existe el 
fichero o el directorio

 #include "include/core_functions.h"
^
compilation terminated.
essid_encoder.c:50:35: fatal error: include/essid_encoder.h: No existe 
el fichero o el directorio

 #include "include/essid_encoder.h"
   ^
compilation terminated.

Aitor.

On 14/09/15 10:39, KatolaZ wrote:

I think you guys must rather specify an appropriate "-I" flag to gcc
in the Makefile.  I have never ever seen "../something" in an
#include

My2Cents

KatolaZ


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Sorry, sorry !!

I didn't undo some changes. How foolish failure :-(

Now it works.

Aitor.

On 14/09/15 10:54, aitor_czr wrote:

Hi Katolaz,

I tried it but it doesn't work:

aitor@gnuinos:~/netman/backend_src/src$ gcc -g -I../include 
core_functions.c file_functions.c backend.c essid_encoder.c -o backend
core_functions.c:29:36: fatal error: include/core_functions.h: No 
existe el fichero o el directorio

 #include "include/core_functions.h"
^
compilation terminated.
file_functions.c:26:27: fatal error: include/paths.h: No existe el 
fichero o el directorio

 #include "include/paths.h"
   ^
compilation terminated.
backend.c:28:36: fatal error: include/core_functions.h: No existe el 
fichero o el directorio

 #include "include/core_functions.h"
^
compilation terminated.
essid_encoder.c:50:35: fatal error: include/essid_encoder.h: No existe 
el fichero o el directorio

 #include "include/essid_encoder.h"
   ^
compilation terminated.

Aitor.

On 14/09/15 10:39, KatolaZ wrote:

I think you guys must rather specify an appropriate "-I" flag to gcc
in the Makefile.  I have never ever seen "../something" in an
#include

My2Cents

KatolaZ


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

I tried "lazbuild -B netman.lpr" in the netman directory and it
worked. There were some complaints but the executable was produced.

By the way, thanks for teaching me something new about Lazarus.


Edward.

On 14/09/2015, aitor_czr  wrote:
> Hi,
>
> I'm adding:
>
> lazbuild -B netman.lpr
>
> to the debian/rules. Is it enough to build the frontend? I've never used
> Lazarus.
>
> Thanks in advance,
>
> Aitor.
>
> On 14/09/15 10:52, Edward Bartolo wrote:
>> Hi,
>>
>> My experience using gcc directly corroborates what KatolaZ said. This
>> command works on my computer without the need to edit the .c files as
>> you suggested.
>>
>> The gcc command:
>> gcc -lm -I../include core_functions.c file_functions.c backend.c
>> essid_encoder.c automated_scanner.c -o backend
>>
>> Edward
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

The content of the resulting /lib/netman.compiled with Lazarus is:



  
  



It will track us for the needed parameters :-)

Aitor.

On 14/09/15 11:57, Edward Bartolo wrote:

Hi Aitor,

I tried "lazbuild -B netman.lpr" in the netman directory and it
worked. There were some complaints but the executable was produced.

By the way, thanks for teaching me something new about Lazarus.


Edward.

On 14/09/2015, aitor_czr  wrote:

>Hi,
>
>I'm adding:
>
>lazbuild -B netman.lpr
>
>to the debian/rules. Is it enough to build the frontend? I've never used
>Lazarus.
>
>Thanks in advance,
>
>Aitor.
>
>On 14/09/15 10:52, Edward Bartolo wrote:

>>Hi,
>>
>>My experience using gcc directly corroborates what KatolaZ said. This
>>command works on my computer without the need to edit the .c files as
>>you suggested.
>>
>>The gcc command:
>>gcc -lm -I../include core_functions.c file_functions.c backend.c
>>essid_encoder.c automated_scanner.c -o backend
>>
>>Edward

>
>


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

I've got the same resulting "/lib/i386-linux/netman.compiled" building 
*in the command line*. So, appearently, is enough with:


$ lazbuild -B netman.lpr

Aitor.

On 14/09/15 12:02, aitor_czr wrote:
The content of the resulting "/lib/i386-linux/netman.compiled" *with 
Lazarus* is:




  
  



It will track us for the needed parameters :-)

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi Aitor,

I pushed the necessary changes in netman. The changes are only in
backend.pas to account for the new placement of backend.

Please, note that the two executables will be placed according to
Tilt's suggestion so that we comply with where executables should be
placed.

Thanks.

Edward.

On 14/09/2015, Edward Bartolo  wrote:
> Hi Aitor,
>
> Tilt wrote:
>
> <
> "/usr/bin/netman" for the frontend and
> "/usr/lib/netman/bin/backend" for the backend.
>>>
>
> This means, I will have to modify the frontend to run the backend from
> the above directory. I will try the recommendation and push my changes
> when I am ready. Tilt argued placing both the backend and frontend in
> /usr/bin/netman may have side-effects on other executables. So, we
> have to avoid it.
>
> Thanks.
>
>
> On 14/09/2015, Edward Bartolo  wrote:
>> Hi Aitor,
>>
>> I tried "lazbuild -B netman.lpr" in the netman directory and it
>> worked. There were some complaints but the executable was produced.
>>
>> By the way, thanks for teaching me something new about Lazarus.
>>
>>
>> Edward.
>>
>> On 14/09/2015, aitor_czr  wrote:
>>> Hi,
>>>
>>> I'm adding:
>>>
>>> lazbuild -B netman.lpr
>>>
>>> to the debian/rules. Is it enough to build the frontend? I've never used
>>> Lazarus.
>>>
>>> Thanks in advance,
>>>
>>> Aitor.
>>>
>>> On 14/09/15 10:52, Edward Bartolo wrote:
 Hi,

 My experience using gcc directly corroborates what KatolaZ said. This
 command works on my computer without the need to edit the .c files as
 you suggested.

 The gcc command:
 gcc -lm -I../include core_functions.c file_functions.c backend.c
 essid_encoder.c automated_scanner.c -o backend

 Edward
>>>
>>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[tilt!]

Hi,

On 09/13/2015 08:10 PM, Edward Bartolo wrote:
> I think, the time has come to start thinking about producing a .deb
> package for netman. However, we will have to use a post installation
> script to add the line:
>
> "iface wlan0 inet dhcp"
>
> to /etc/network/interfaces.

Is that really neccessary? How about people who install the package
but have no wlan0 or have a hot-pluggable WiFi interface or ...
Won't they get errors from that then?

> The script has also to create a new
> directory under /usr/bin with the name netman ie  /usr/bin/netman will
> hold both the frontend and the backend.

Please allow me to instead recommend exectuable files named

"/usr/bin/netman" for the frontend and
"/usr/lib/netman/bin/backend" for the backend.

Reasons:

* Subdirectories of /usr/bin are undesireable, because they will
confuse programs that rely on PATH to only contain directories
that only contain executables.

* It is good practise to name the main application executable
the same as the package. Therefore, if the package is called
"netman", the main application should also be called "netman".
This will leave unprepared users with an improved experience.

The backend executable is not really intended for manual invokation.
It therefore should not reside in PATH. I understand it to be an
"internal binary" which FHS 2.3 section 4 mandates should reside in
/usr/lib/ (see [FHS]).

> The SUID for backend must be changed to that belonging to root. I do
> this as follows:
> chown root:root backend
> chmod u+s backend

No problem, can do that in "debian/netman.postinst".

> A new directory under /etc/network with the name wifi must be created
> i.e. /etc/network/wifi must be an existing directory.

No problem, can do that in "debian/netman.postinst".

> Then, the final steps would be to create a launcher for netman, the
> frontend.

Add file "netman.desktop" to system-wide autostart-folder:

* Write a file "netman.desktop" as described in [DESKTOP].
* Let the postinst script copy it to "/etc/xdg/autostart".

Add "Debian Menu Entry":

* Create a file debian/netman.menu as described in [DMENU].
* Let debhelper do the rest.

As a result, XDG compliant desktop environments will autostart
the GUI and all Debian-menu-aware window managers will have an
entry for the GUI in the "Debian" menu.

> To enable automatic attempts at connecting basing on installed essid
> files under /etc/network/wifi, the parameter --auto-conn must be
> passed to netman upon invocation. --auto-conn need not be used and
> netman would not attempt to connect without user intervention. This
> feature is for those who want to control what happens on their
> machine.

The decision if the package should provide the launchers described
above is indeed difficult.

In my opinion, the optimum would be if, in the running GUI,
a possibility to change the autoconnecting behavior on a permanent
basis existed, so that, when "netman" is started the next time,
auto-connecting would be turned off or on according to the last
decision the user made. The default setting would be much less
important then.

Kind regards,
T.

Links:

[FHS]: Filesystem Hierarchy Standard, Version 2.3.
Section 4. Subsection "/usr/lib : Libraries for programming
and packages". Subsubsection "Purpose".
URL: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22

[DESKTOP] freedesktop.org. Desktop Entry Specification.
Appendix A: Example Desktop Entry File.
URL: http://standards.freedesktop.org/desktop-entry-spec/latest/apa.html

[DMENU]: Debian Menu System. Chapter 3 - The menu file
URL: https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Vintage :-)

El 13/09/15 a las 20:10, Edward Bartolo escribió:

Edward Bartolo  wrote:


  Oooops, I have a new pair of spectacles that is playing tricks on me,
  especially, since it is the first near-sight spectacles. Before, I
  didn't use any.


  You just turned 40, didn't you?

  As I remember, 40's is a good decade.

  SteveT

  Steve Litt


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[aitor_czr]

Ok, I like XFCE4 of course.

Aitor.

El 13/09/15 a las 20:13, Edward Bartolo escribió:

Hi aitor, I forgot to write that the final step is to let netman be 
automatically run as soon as a user boots into XFCE4 or desktop or 
window manager. Edward On 13/09/2015, Edward Bartolo  
wrote:

>Hi aitor,
>
>I think, the time has come to start thinking about producing a .deb
>package for netman. However, we will have to use a post installation
>script to add the line:
>
>"iface wlan0 inet dhcp"
>
>to /etc/network/interfaces. The script has also to create a new
>directory under /usr/bin with the name netman ie  /usr/bin/netman will
>hold both the frontend and the backend.
>
>The SUID for backend must be changed to that belonging to root. I do
>this as follows:
>chown root:root backend
>chmod u+s backend
>
>A new directory under /etc/network with the name wifi must be created
>i.e. /etc/network/wifi must be an existing directory.
>
>Then, the final steps would be to create a launcher for netman, the
>frontend. To enable automatic attempts at connecting basing on
>installed essid files under /etc/network/wifi, the parameter
>--auto-conn must be passed to netman upon invocation. --auto-conn need
>not be used and netman would not attempt to connect without user
>intervention. This feature is for those who want to control what
>happens on their machine.
>
>Edward
>
>


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [DN Offlist G] netman GIT project

[Edward Bartolo]

Hi all,

The additional ability to recognize wlan1, wlan2, wlan3, etc, in
something I will do as soon as I can.

Regarding the use of "iface wlan0 inet dhcp" in
/etc/network/interfaces, I have no other option unless someone really
versed in network configuration provides an alternative that works and
that doesn't disrupt the already working code.

I have already a germinating idea of how to implement support for
wlanN. This is by naming the essid files as wlanX_essid. This way only
the essid saving function and the frontend essid listing functions
would need to be changed. The connecting functions of the backend
would simply parse the filename to extract the device name, and it
would be done.

However, at this time of the year, I am very busy doing other work
besides programming for Devuan. At the moment, I am busy planting my
vegetables which cannot wait as that depends on the season, and a
couple of weeks makes a whole difference.

Edward

On 13/09/2015, aitor_czr  wrote:
> Ok, I like XFCE4 of course.
>
> Aitor.
>
> El 13/09/15 a las 20:13, Edward Bartolo escribió:
>
> Hi aitor, I forgot to write that the final step is to let netman be
> automatically run as soon as a user boots into XFCE4 or desktop or
> window manager. Edward On 13/09/2015, Edward Bartolo 
> wrote:
>>> >Hi aitor,
>>> >
>>> >I think, the time has come to start thinking about producing a .deb
>>> >package for netman. However, we will have to use a post installation
>>> >script to add the line:
>>> >
>>> >"iface wlan0 inet dhcp"
>>> >
>>> >to /etc/network/interfaces. The script has also to create a new
>>> >directory under /usr/bin with the name netman ie  /usr/bin/netman will
>>> >hold both the frontend and the backend.
>>> >
>>> >The SUID for backend must be changed to that belonging to root. I do
>>> >this as follows:
>>> >chown root:root backend
>>> >chmod u+s backend
>>> >
>>> >A new directory under /etc/network with the name wifi must be created
>>> >i.e. /etc/network/wifi must be an existing directory.
>>> >
>>> >Then, the final steps would be to create a launcher for netman, the
>>> >frontend. To enable automatic attempts at connecting basing on
>>> >installed essid files under /etc/network/wifi, the parameter
>>> >--auto-conn must be passed to netman upon invocation. --auto-conn need
>>> >not be used and netman would not attempt to connect without user
>>> >intervention. This feature is for those who want to control what
>>> >happens on their machine.
>>> >
>>> >Edward
>>> >
>>> >
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng