Re: [DNG] Automatic connections: expected behaviour from netman
On Sun, Sep 13, 2015 at 05:20:25PM +0200, Edward Bartolo wrote: > Hi all, > > By automatic connections I understood netman using the available > essids for which it knows the password to connect. This means, it does > not attempt to connect if no essid file is found under > /etc/network/wifi. > A simple question: how will netman choose between two or more available ESSIDs? Will it just go for the one providing a stronger signal? And what if the signal-strength-based ranking keeps changing? Will netman go on and off to chase the ESSID witht the strongest signal? Would it be possible to "force" the usage of a given ESSID in such cases? HND 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
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] About the issues on the devuan repositories
Am 12.09.2015 um 06:54 schrieb Franco Lanza: > Thanks for your patience, in few hours the devuan repositories will be > up&running. Jep, repo is working again. Thanks for fixing the issue! Regards Thomas ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Automatic connections: expected behaviour from netman
Hi, Once it connects, netman will not try to change connection unless it fails. The backend first reads the available signal strengths, then it reads what essids are installed, and finally, it tries to connect by first trying the strongest wifi source if that is available in the essid files. This is done in descending strength order. Unstable signal strengths will not affect netman's behaviour a connection remains valid until it disconnects. In such a case, the user can intervene manually to connect by clicking a button. This to avoid having netman become a nuisance trying to automatically connect with unstable connections. As with all KISS software, the user is always at the helm: which means, users can override what netman chooses to connect with. The procedure is as simple as: a) disconnect from unwanted wifi source b) connect to wanted wifi source Edward On 14/09/2015, KatolaZ wrote: > On Sun, Sep 13, 2015 at 05:20:25PM +0200, Edward Bartolo wrote: >> Hi all, >> >> By automatic connections I understood netman using the available >> essids for which it knows the password to connect. This means, it does >> not attempt to connect if no essid file is found under >> /etc/network/wifi. >> > > A simple question: how will netman choose between two or more > available ESSIDs? Will it just go for the one providing a stronger > signal? And what if the signal-strength-based ranking keeps changing? > Will netman go on and off to chase the ESSID witht the strongest > signal? > > Would it be possible to "force" the usage of a given ESSID in > such cases? > > HND > > 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] Xorg dependency on libsystemd
On 2015-09-13 23:44, k...@aspodata.se wrote: Shraptor: When I check on Arch linux the only dependency they explicitly states is xorg-server-xnest is dependent on libsystemd. I do not have this package installed. When I try to run my os Xorg complains about missing libsystemd There is some package builds in AUR and if I check them I see --enable-systemd-logind under ./configure command So I guess that its this where th dependency comes from. So if I recompile without it maybe I can run without libsystemd installed? Anyone have any experience regarding this? Is it hard to compile and get Xorg to work? Any comments would be most welcome I got xorg to work on a funtoo box and that without any udev nor libudev. I.e. there is no dependancy. Regards, /Karl Hammar Was there libsystemd on your funtoo setup? The dependency I found was on systemd-login. The udev dependency probably is just arch buildscripts. If I include libsystemd my system starts fine with vdev Did you recompile Xorg. which parts? I saw some mention you may have to recompile xf86-input-evdev also if you recompile xorg-server How did you do it? best regards Scooby --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ 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
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
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
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 -- [ 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
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 >>> >>> > > ___ Dng mailing list Dng@lists.dyne.org https://mai
Re: [DNG] [DN Offlist G] netman GIT project
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 final steps would be to create a launcher for netman, the frontend. To enable automatic att
Re: [DNG] [DN Offlist G] netman GIT project
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
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] About the issues on the devuan repositories
Le 12/09/2015 06:54, Franco Lanza a écrit : Hi all, after the last days issues with devuan repositories, ... Thanks for your patience, in few hours the devuan repositories will be up&running. Thanks very much Franco. I could install devuan-jessie alpha2 amd64 yesterday evening on an old Toshiba laptop. It worked pretty well, except two glitches where a step failed first and then succeeded when retried. I have seen systemd around, but it doesn't hold the reins, which is as expected. I found very nice to see a menu in which you can choose your Desktop Environment. I chose Xfce and it works with no surprise. Good job. Waiting to see the Beta, with, maybe, vdev and s6-rc... Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [DN Offlist G] netman GIT project
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
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
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
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
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
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
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
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 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [DN Offlist G] netman GIT project
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
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
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 be created >>> i.e. /etc/network/wifi must be an existin
Re: [DNG] [DN Offlist G] netman GIT project
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] Xorg dependency on libsystemd
shraptor: > On 2015-09-13 23:44, k...@aspodata.se wrote: ... > > I got xorg to work on a funtoo box and that without any udev nor > > libudev. I.e. there is no dependancy. ... > Was there libsystemd on your funtoo setup? No, none. > The dependency I found was on systemd-login. > The udev dependency probably is just arch buildscripts. Yes, seems to be in many distribution buildscripts. Seems maintainers by reflex think udev is installed, that they want it themselfs, or that it provides some convenience that shouldn't be left out. > If I include libsystemd my system starts fine > with vdev > > Did you recompile Xorg. which parts? Since it's funtoo (which is based on gentoo): everything. > I saw some mention you may have to > recompile xf86-input-evdev also > if you recompile xorg-server > > How did you do it? By modifying the funtoo build script, removing mentions of udev: $ cd /usr/portage $ diff ./x11-drivers/xf86-input-evdev/xf86-input-evdev-2.9.2.ebuild* 10c10 < RDEPEND=">=x11-base/xorg-server-1.12 --- > RDEPEND=">=x11-base/xorg-server-1.12[udev] $ diff x11-base/xorg-server/old/xorg-server-1.16.4-r1.ebuild x11-base/xorg-server/xorg-server-1.16.4-r1.ebuild 12c12 < IUSE="dmx kdrive xnest +xorg xvfb glamor ipv6 minimal nptl selinux +suid systemd tslib +udev unwind wayland" --- > IUSE="dmx kdrive xnest +xorg xvfb glamor ipv6 minimal nptl selinux +suid > systemd tslib unwind wayland" 60d59 < udev? ( >=virtual/udev-150 ) 170d168 < $(use_enable udev config-udev) $ and then # emerge --regen I don't remeber if I had to do anything with mesa. In mesa there is: $ git remote -v origin git://anongit.freedesktop.org/git/mesa/mesa (fetch) origin git://anongit.freedesktop.org/git/mesa/mesa (push) $ ./configure --help | grep sysfs --enable-sysfs enable /sys PCI identification [default=disabled] $ which you can use instead of libudev. /// If you run current xorg server, you have to make your own xorg.conf (I think). I added flag below to make it work: Section "ServerFlags" ... Option "AutoAddDevices" "off" EndSection Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
Isaac: ... > I've redone that function without udev but using my own library libsysdev, > which I mentioned earlier this summer. > Repositories that you'd need to build that: > > -https://github.com/idunham/libsysdev > -https://github.com/idunham/xf86-input-evdev (branch sysdev) $ git remote -v origin https://github.com/idunham/xf86-input-evdev.git (fetch) origin https://github.com/idunham/xf86-input-evdev.git (push) $ git pull Already up-to-date. $ git branch * master $ How do I get the sysdev branch ? > But that does require something that has no Debian packaging yet. ... You did some debian packaging earlier and I intended to test this, but real world issues got in the way. I'm willing to work on this, perhaps to make a *dev-agnostic version of the X11 packages. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [DN Offlist G] netman GIT project
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] xf86-input-evdev
On 9/14/15, k...@aspodata.se wrote: ... > How do I get the sysdev branch ? git checkout remotes/origin/sysdev sysdev ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [DN Offlist G] netman GIT project
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
[DNG] where to find include files.
On Mon, Sep 14, 2015 at 10:54:53AM +0200, aitor_czr wrote: > Hi Katolaz, > > I tried it but it doesn't work: > > aitor@gnuinos:~/netman/backend_src/src$ gcc -g -I../include Try with the actual path to the include. With a -I option it isn't clear what home directory the -I is relative to. I remember a long discussion online about the "home" directory from which include paths started indicating that they should be relative to the source file doing the include, not to the home directory where the compiler was invoked. I don't know what the final decision was. But is you do provide an absolute path in the -I and it works, you'll know for sure that there was a problem with the "../". -- hendrik > 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [DN Offlist G] netman GIT project
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] upgrade wheezy to ceres -- warnings, errors, and oddities
If there's a better place to report this, let me know. On a fully updated Wheezy system, I installed debuan-baseconf-0.6.4+devuan3_all.deb. That sets up the Devuan repositories and then puts some instructions on the screen. When you select OK, those instructions disappear. It would be nice if they remained on the screen. Anyway, I removed the Debian sources and then ran 'apt-get update'. I got normal output plus several lines like 'ignoring provides line with depcompareop for package php-psr-http-message-implementation'. 'apt-get update' did not correct this, as the on-screen messages suggested it might. I then ran 'apt-get upgrade' and after some upgrades it stopped with errors about 'bsdmainutils is not configured yet'. 'apt-get install bsdmainutils' got me past that, but that's something that probably should be addressed. Another 'apt-get update' still produces the 'ignoring provides line' warnings. 'apt-get upgrade' tells me that systemd and systemd-sysv are going to be installed. Additionally, for some reason samba is going to be installed (nothing against samba, but I don't need it on this system). Various qemu packages are also going to be installed for some reason. If somebody wants to try fixing these issues, I can re-test. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to ceres -- warnings, errors, and oddities
On Mon, Sep 14, 2015 at 02:26:10PM -0400, Rob Owens wrote: [cut] > > Another 'apt-get update' still produces the 'ignoring provides line' warnings. > > 'apt-get upgrade' tells me that systemd and systemd-sysv are going to be > installed. Additionally, for some reason samba is going to be installed > (nothing against samba, but I don't need it on this system). Various qemu > packages are also going to be installed for some reason. > > If somebody wants to try fixing these issues, I can re-test. > Hi Rob, I don't know if it is related, and maybe my comment is just silly, but in order to upgrade from Wheezy I believe you should give an "apt-get dist-upgrade" and not a simple "apt-get upgrade". Sorry if the comment is too stupid or irrelevant, but this little detail might make a difference. Also, I don't know if direct upgrading from Wheezy to Ceres (which is equivalent to an upgrade from an "old-stable" to an "unstable", in Debian words) is actually supported, but Devuan developers will certainly be able to clarify this point better. 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
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
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
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
[DNG] upgrade wheezy to devuan jessie instead of ceres
On Mon, Sep 14, 2015 at 07:35:34PM +0100, KatolaZ wrote: > On Mon, Sep 14, 2015 at 02:26:10PM -0400, Rob Owens wrote: > > [cut] > > > > > Another 'apt-get update' still produces the 'ignoring provides line' > > warnings. > > > > 'apt-get upgrade' tells me that systemd and systemd-sysv are going to be > > installed. Additionally, for some reason samba is going to be installed > > (nothing against samba, but I don't need it on this system). Various qemu > > packages are also going to be installed for some reason. > > > > If somebody wants to try fixing these issues, I can re-test. > > > > Hi Rob, > > I don't know if it is related, and maybe my comment is just silly, but > in order to upgrade from Wheezy I believe you should give an "apt-get > dist-upgrade" and not a simple "apt-get upgrade". > > Sorry if the comment is too stupid or irrelevant, but this little > detail might make a difference. Also, I don't know if direct upgrading > from Wheezy to Ceres (which is equivalent to an upgrade from an > "old-stable" to an "unstable", in Debian words) is actually supported, > but Devuan developers will certainly be able to clarify this point > better. I'm wondering whether things are ready to upgrade my server to devuan jessie. I'll take the usual precautions to be able to back out if it doesn't work, (i.e. doing the upgrade on a copy of the working system) but ... would it be worth the effort at present, or would I just be wasting my time? And wasting everyone else's time, reporting on problems you all know about already? -- hendrik > > 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] xf86-input-evdev
Hleb: > On 9/14/15, k...@aspodata.se wrote: > ... > > How do I get the sysdev branch ? > > git checkout remotes/origin/sysdev sysdev $ git checkout remotes/origin/sysdev sysdev error: pathspec 'sysdev' did not match any file(s) known to git. Didn't work. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ 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 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] upgrade wheezy to ceres -- warnings, errors, and oddities
I correct a mistake near the end of my original email. 'apt-get dist-upgrade' is what causes systemd, samba, and qemu to get installed. And just to be clear, I did 'apt-get upgrade' first, then 'apt-get dist-upgrade' later in the process. This is how I am accustomed to doing Debian upgrades. - Original Message - > From: "rowens" > If there's a better place to report this, let me know. > > On a fully updated Wheezy system, I installed > debuan-baseconf-0.6.4+devuan3_all.deb. That sets up the Devuan repositories > and then puts some instructions on the screen. When you select OK, those > instructions disappear. It would be nice if they remained on the screen. > > Anyway, I removed the Debian sources and then ran 'apt-get update'. I got > normal output plus several lines like 'ignoring provides line with > depcompareop > for package php-psr-http-message-implementation'. 'apt-get update' did not > correct this, as the on-screen messages suggested it might. > > I then ran 'apt-get upgrade' and after some upgrades it stopped with errors > about 'bsdmainutils is not configured yet'. 'apt-get install bsdmainutils' > got > me past that, but that's something that probably should be addressed. > > Another 'apt-get update' still produces the 'ignoring provides line' warnings. > edit: 'apt-get dist-upgrade' tells me that systemd and systemd-sysv are going to be > installed. Additionally, for some reason samba is going to be installed > (nothing against samba, but I don't need it on this system). Various qemu > packages are also going to be installed for some reason. > > If somebody wants to try fixing these issues, I can re-test. > > -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
- Original Message - > On Mon, Sep 14, 2015 at 07:35:34PM +0100, KatolaZ wrote: >> On Mon, Sep 14, 2015 at 02:26:10PM -0400, Rob Owens wrote: >> > Another 'apt-get update' still produces the 'ignoring provides line' >> > warnings. >> > >> > 'apt-get upgrade' tells me that systemd and systemd-sysv are going to be >> > installed. Additionally, for some reason samba is going to be installed >> > (nothing against samba, but I don't need it on this system). Various qemu >> > packages are also going to be installed for some reason. >> > >> > If somebody wants to try fixing these issues, I can re-test. >> > >> >> Hi Rob, >> >> I don't know if it is related, and maybe my comment is just silly, but >> in order to upgrade from Wheezy I believe you should give an "apt-get >> dist-upgrade" and not a simple "apt-get upgrade". >> That should have read 'apt-get dist-upgrade'. I have corrected my original email. >> Sorry if the comment is too stupid or irrelevant, but this little >> detail might make a difference. Also, I don't know if direct upgrading >> from Wheezy to Ceres (which is equivalent to an upgrade from an >> "old-stable" to an "unstable", in Debian words) is actually supported, >> but Devuan developers will certainly be able to clarify this point >> better. I only chose ceres because that was the default when I installed devuan-baseconf. Which would be a more sensible upgrade path from Wheezy? Should I have chosen ascii? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
On 9/14/15, k...@aspodata.se wrote: > $ git checkout remotes/origin/sysdev sysdev > error: pathspec 'sysdev' did not match any file(s) known to git. > > Didn't work. Swap sysdev and remotes/origin/sysdev or try just git checkout sysdev Hint: man git-checkout :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
Le 14/09/2015 21:48, Rob Owens a écrit : I only chose ceres because that was the default when I installed devuan-baseconf. Which would be a more sensible upgrade path from Wheezy? Should I have chosen ascii? Up to now, Debian has never supported skipping one or two versions in dist-upgrade. The version just after Wheezy is Jessie; therefore you should probably dist-upgrade to Devuan Jessie. The planets come after that. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
- Original Message - > From: "Didier Kryn" > Le 14/09/2015 21:48, Rob Owens a écrit : >> I only chose ceres because that was the default when I installed >> devuan-baseconf. Which would be a more sensible upgrade path from Wheezy? >> Should I have chosen ascii? > Up to now, Debian has never supported skipping one or two versions > in dist-upgrade. The version just after Wheezy is Jessie; therefore you > should probably dist-upgrade to Devuan Jessie. The planets come after that. Thanks for the input, everyone. My upgrade was better this time. 1) 'wget http://packages.devuan.org/devuan/pool/main/d/devuan-baseconf/devuan-baseconf_0.6.4+devuan3_all.deb' 2) 'dpkg -i devuan-baseconf_0.6.4+devuan3_all.deb' 3) enter 'jessie' in place of the default value of 'ceres' 4) remove debian sources from /etc/apt/sources.list 5) 'apt-get update' 6) 'apt-get upgrade' 7) 'apt-get update' -- just to be sure 8) 'apt-get dist-upgrade' No warnings or errors. Samba and various qemu packages get installed, even though they were not installed on my Wheezy system. Package db5.1-util has been kept back. Upgrading it wanted to remove python 2.6, so instead I removed db5.1-util and the system boots fine without it. I haven't done much testing beyond that. 'aptitude search ~i | grep systemd' shows libsystemd-login0 and libsystemd0 installed. 'apt-cache policy' for both packages shows version 215-17+deb8u2 installed from http://packages.devuan.org/merged jessie/main libsystemd-login0 is listed as deprecated in the output of 'aptitude search...' and in fact, it was installed prior to my upgrade. After a reboot libsystemd-login0 is not installed -- I may have done a 'apt-get autoremove' in the meantime. I am going to have to re-test. But overall, the upgrade was successful. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
On Mon, 9/14/15, Didier Kryn wrote: Subject: Re: [DNG] upgrade wheezy to devuan jessie instead of ceres To: dng@lists.dyne.org Date: Monday, September 14, 2015, 2:58 PM Le 14/09/2015 21:48, Rob Owens a écrit : > I only chose ceres because that was the default when I installed > devuan-baseconf. Which would be a more sensible upgrade path from Wheezy? > Should I have chosen ascii? Up to now, Debian has never supported skipping one or two versions in dist-upgrade. The version just after Wheezy is Jessie; therefore you should probably dist-upgrade to Devuan Jessie. The planets come after that. Didier Didier . . . Jessie IS the name of a minor planet! https://git.devuan.org/devuan/devuan-project/wikis/releases/jessie golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade wheezy to devuan jessie instead of ceres
On Mon, Sep 14, 2015 at 03:10:30PM -0400, Hendrik Boom wrote: [cut] > > I'm wondering whether things are ready to upgrade my server to devuan > jessie. I'll take the usual precautions to be able to back out if it > doesn't work, (i.e. doing the upgrade on a copy of the working > system) but ... would it be worth the effort at present, or would I just > be wasting my time? > > And wasting everyone else's time, reporting on problems you all know > about already? > Hi Hendrik, I have been using Devuan on my production laptop in the last few months, without any problem. Indeed, nothing major has changed between my old Debian Jessie with systemd pinned to -1 and the current Devuan Jessie. Just a few packages were upgraded, smoothly. I admit my installation is not what most people would call a "standard desktop" though (basically, Window Maker + emacs + standard ncurses clients + iceape and little more), and I am not using any network daemon, except for ssh and cups, but everything works pretty well. libsystemd0 is still there, due to the (practically useless) rdepend of cups-daemon, which I cannot unistall, but apparently that nuisance shall be removed in the forthcoming Devuan beta. Come on Hendrik, it's time to jump in the hole ;) 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] upgrade wheezy to ceres -- warnings, errors, and, oddities
In my opinion, the best way to update the system is (as KatolaZ says) "apt-get dist-upgrade". Aitor. El 14/09/15 a las 21:33, Rob Owens escribió: Hi Rob, I don't know if it is related, and maybe my comment is just silly, but in order to upgrade from Wheezy I believe you should give an "apt-get dist-upgrade" and not a simple "apt-get upgrade". Sorry if the comment is too stupid or irrelevant, but this little detail might make a difference. Also, I don't know if direct upgrading from Wheezy to Ceres (which is equivalent to an upgrade from an "old-stable" to an "unstable", in Debian words) is actually supported, but Devuan developers will certainly be able to clarify this point better. 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
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] upgrade wheezy to devuan jessie instead of ceres
On Mon, Sep 14, 2015 at 10:36:45PM +0100, KatolaZ wrote: > On Mon, Sep 14, 2015 at 03:10:30PM -0400, Hendrik Boom wrote: > > [cut] > > > > > I'm wondering whether things are ready to upgrade my server to devuan > > jessie. I'll take the usual precautions to be able to back out if it > > doesn't work, (i.e. doing the upgrade on a copy of the working > > system) but ... would it be worth the effort at present, or would I just > > be wasting my time? > > > > And wasting everyone else's time, reporting on problems you all know > > about already? > > > > Hi Hendrik, > > I have been using Devuan on my production laptop in the last few > months, without any problem. Indeed, nothing major has changed between > my old Debian Jessie with systemd pinned to -1 and the current Devuan > Jessie. Just a few packages were upgraded, smoothly. > > I admit my installation is not what most people would call a "standard > desktop" though (basically, Window Maker + emacs + standard ncurses > clients + iceape and little more), and I am not using any network > daemon, except for ssh and cups, but everything works pretty well. > > libsystemd0 is still there, due to the (practically useless) rdepend > of cups-daemon, which I cannot unistall, but apparently that nuisance > shall be removed in the forthcoming Devuan beta. > > Come on Hendrik, it's time to jump in the hole ;) I'm already using the alpha 2 versin of Devuan Jessie on my laptop, done by a straightforward and mostly uneventful install. The server is another matter. I'm going to be upgrading it from straight from Debian wheezy to Devuan Jessie. Upgrades are often eventful. Im guessing that it's time to try the upgrade, and report back here. I'll get onto it when I have the time, and report back here, unless I hear advice to the contrary. I've been waiting for this day for a log time. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
Hleb: > On 9/14/15, k...@aspodata.se wrote: > > $ git checkout remotes/origin/sysdev sysdev > > error: pathspec 'sysdev' did not match any file(s) known to git. > > > > Didn't work. > > Swap sysdev and remotes/origin/sysdev or try just git checkout sysdev ?? co sysdev worked, I'm clueless Thanks! Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Supporting wlanN, where N = {1, 2, 3, ...}
Hi all, Although at the moment I am occupied with other commitments, I would to discuss how support for uncommon systems with more than one wifi adaptor and/or with more than one wired network adaptor. The main drawback supporting such systems is that the GUI has to account for them and this makes it more complicated for the end user who almost seldom will be faced by the situation of having to deal with more than one wifi card and/or more than one wired connector on the same system. I am assuming these type of unfortunate users should already be comfortable tweaking there system, so I am suggesting that the backend would be made behave differently in extraordinary situations like these. Instead of defaulting on wlan0 and eth0, power users would opt to use wlan1 or eth1. For this, a simple text configuration file mapping wlanX to wlan1 and ethX to eth1 should provide a simple and yet neat solution without editing too much of the already working code. This is my first concept of how support for uncommon systems can be added without too much disruption of the already working code. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Supporting wlanN, where N = {1, 2, 3, ...}
Hi all, Obviously, the major disadvantage of using my proposed 'solution', is users must decide which physical network interfaces to use and stick with their decision afterwards. Edward On 15/09/2015, Edward Bartolo wrote: > Hi all, > > Although at the moment I am occupied with other commitments, I would > to discuss how support for uncommon systems with more than one wifi > adaptor and/or with more than one wired network adaptor. > > The main drawback supporting such systems is that the GUI has to > account for them and this makes it more complicated for the end user > who almost seldom will be faced by the situation of having to deal > with more than one wifi card and/or more than one wired connector on > the same system. > > I am assuming these type of unfortunate users should already be > comfortable tweaking there system, so I am suggesting that the backend > would be made behave differently in extraordinary situations like > these. Instead of defaulting on wlan0 and eth0, power users would opt > to use wlan1 or eth1. For this, a simple text configuration file > mapping wlanX to wlan1 and ethX to eth1 should provide a simple and > yet neat solution without editing too much of the already working > code. > > This is my first concept of how support for uncommon systems can be > added without too much disruption of the already working code. > > Edward > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
