Re: Is gtk4 support in libnma still EXPERIMENTAL?
Am 13.03.22 um 22:18 schrieb Thomas Haller: On Sun, 2022-03-13 at 16:01 +0100, Michael Biebl wrote: Am 13.03.22 um 12:46 schrieb Thomas Haller: On Sat, 2022-03-12 at 21:55 +0100, Michael Biebl wrote: ./usr/lib/x86_64-linux-gnu/girepository-1.0/NMA4-1.0.typelib ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0.0.0 ./usr/lib/x86_64-linux-gnu/pkgconfig/libnma-gtk4.pc ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0 ./usr/share/vala/vapi/libnma-gtk4.vapi ./usr/share/vala/vapi/libnma-gtk4.deps ./usr/share/gir-1.0/NMA4-1.0.gir yes. I think it's fine. is there a problem? You cannot load gtk3 and gtk4 in the same application, and consequently, you cannot load libnma.so (gtk3) and libnma-gtk4 together. libnma is a GUI library based on GTK. It seems not unreasonable that the GTK version is part of the library name -- in particular, as there might come GTK5 in the future. These are really two different libraries (with very similar API and the same underlying sources). I see the necessity and maybe this is just bike shedding on my side but I'd personally prefer the gtk part being dropped, so the soname becomes libnma-4.so.0 And correspondingly libnma-4.pc (libnma4.pc would be fine as well). Or do we have some prior art where the gtkX string is encoded in the library soname? I also find it a bit inconsistent that the gobject instrospection files do not have GTK string embedded. Hi, I tend to agree. but it might be too late for that... even if it was announced as experimental :) Lubomir, wdyt? Could we have some definitive answer if the naming is going to stay? I have a request in Debian to enable gtk4 support in libnma but before doing that, I'd like to have an answer here first. OpenPGP_signature Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PSK+SAE when creating an Access Point
Am 23.03.22 um 08:57 schrieb Alfonso Sanchez-Beato via networkmanager-list: On Tue, Mar 22, 2022 at 10:56 PM Thomas Haller wrote: sounds related to https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638#note_1306214 ? Looks related, but in my case I was creating the AP with NM instead of connecting to an external AP. It is interesting to see that the problem starts to happen with wpa_supplicant 2.10, the same version as the one I am using. See my findings in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907#70 https://w1.fi/cgit/hostap/commit/?id=7a9c36722511ce4df88b76cceceb241d6c6a151e older wpasupplicant versions did not allow to set the SAE flag via D-Bus (which NetworkManager uses to talk to wpasupplicant). OpenPGP_signature Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is gtk4 support in libnma still EXPERIMENTAL?
Am 13.03.22 um 12:46 schrieb Thomas Haller: On Sat, 2022-03-12 at 21:55 +0100, Michael Biebl wrote: ./usr/lib/x86_64-linux-gnu/girepository-1.0/NMA4-1.0.typelib ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0.0.0 ./usr/lib/x86_64-linux-gnu/pkgconfig/libnma-gtk4.pc ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0 ./usr/share/vala/vapi/libnma-gtk4.vapi ./usr/share/vala/vapi/libnma-gtk4.deps ./usr/share/gir-1.0/NMA4-1.0.gir yes. I think it's fine. is there a problem? You cannot load gtk3 and gtk4 in the same application, and consequently, you cannot load libnma.so (gtk3) and libnma-gtk4 together. libnma is a GUI library based on GTK. It seems not unreasonable that the GTK version is part of the library name -- in particular, as there might come GTK5 in the future. These are really two different libraries (with very similar API and the same underlying sources). I see the necessity and maybe this is just bike shedding on my side but I'd personally prefer the gtk part being dropped, so the soname becomes libnma-4.so.0 And correspondingly libnma-4.pc (libnma4.pc would be fine as well). Or do we have some prior art where the gtkX string is encoded in the library soname? I also find it a bit inconsistent that the gobject instrospection files do not have GTK string embedded. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is gtk4 support in libnma still EXPERIMENTAL?
Am 12.03.22 um 21:47 schrieb Michael Biebl: Hi there, there has been a flurry of updates for nm vpn plugins adding support for GTK4. All of them require a libnma built with GTK4 support which is still marked experimental. I haven't seen any real follow up commits in libnma dealing with GTK4 issues, so I wonder if the EXPERIMENTAL status is still true or if it's safe to enable support for it (say in the Debian package). Related to that, are you really considering embedding gtk4 into the soname and pc file name? ./usr/lib/x86_64-linux-gnu/girepository-1.0/NMA4-1.0.typelib ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0.0.0 ./usr/lib/x86_64-linux-gnu/pkgconfig/libnma-gtk4.pc ./usr/lib/x86_64-linux-gnu/libnma-gtk4.so.0 ./usr/share/vala/vapi/libnma-gtk4.vapi ./usr/share/vala/vapi/libnma-gtk4.deps ./usr/share/gir-1.0/NMA4-1.0.gir OpenPGP_signature Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Is gtk4 support in libnma still EXPERIMENTAL?
Hi there, there has been a flurry of updates for nm vpn plugins adding support for GTK4. All of them require a libnma built with GTK4 support which is still marked experimental. I haven't seen any real follow up commits in libnma dealing with GTK4 issues, so I wonder if the EXPERIMENTAL status is still true or if it's safe to enable support for it (say in the Debian package). Regards, Michael OpenPGP_signature Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Inconsistent behaviour for non-admin users when creating new connections
Hi Thomas Am 23.04.2020 um 08:37 schrieb Thomas Haller: > On Wed, 2020-04-22 at 17:55 +0200, Michael Biebl wrote: >> I think the current situation is unfortunate. Ideally, NM Clients >> would >> behave more consistently and provide a better ootb experience for >> unprivileged users. I find especially a) very unfriendly for users. >> In a >> multi-user setup it's unlikely they have an admin password and I >> think >> NM clients should just create user-owned connections in that case. > > I agree. I see you dropped patch [1] now? Possibly this should be > upstream. Yes, see https://salsa.debian.org/utopia-team/network-manager-applet/-/commit/6363ab1469a3d68f41d7370c909a13132aa6bbd4 The patch was added originally to address https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696256 and is 7 years old. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Inconsistent behaviour for non-admin users when creating new connections
Hi everyone, for a bit of backstory: in Debian we traditionally ship a strict PolicyKit configuration for NetworkManager, which doesn't allow non-admin users to edit system wide connections (we build NM with --disable-modify-system, i.e. we use auth_admin_keep instead of yes) The reason for that is, that we want to be able to ship a default policy which is reasonably secure on a wide variety of setups and we didn't want to give unprivileged users the ability to read/write/modify connections that were not created by themselves. At the same time, unprivileged users should be able to connect to new WiFi networks without too much fuss (i.e. without having to enter an admin password). This was the main motivation for the Debian patch [1] to nm-applet back in the days. Nowadays, we have a lot more NetworkManager clients: Cinnamon, GNOME, KDE (plasma-nm) etc all have native NM support. I did a series of tests with an unprivileged users named "test" under Debian trying to connect to a new WiFi network. Here are the results a) GNOME Shell admin prompt, credentials system wide, permissions= b) gnome-control-center no admin prompt, credentials system wide, permissions=user:test:; c) Cinnamon no admin prompt, credentials user wide, permissions=user:test:; d) cinnamon-control-center no admin prompt, credentials system wide, permissions=user:test:; e) nm-applet 1.16.0 no admin prompt, credentials system wide, permissions=user:test:; f) nm-connection-editor 1.16.0 admin prompt, credentials system wide, permissions= g) nm-applet 1.8.24 (with Debian patch [1]) no admin prompt, credentials user wide, permissions=user:test:; h) nm-connection-editor 1.8.24 (with Debian patch [1]) no admin prompt, credentials system wide, permissions=user:test:; I think the current situation is unfortunate. Ideally, NM Clients would behave more consistently and provide a better ootb experience for unprivileged users. I find especially a) very unfriendly for users. In a multi-user setup it's unlikely they have an admin password and I think NM clients should just create user-owned connections in that case. Whether to store credentials system wide or make them agent owned is another topic. I guess for WiFi connections it makes sense to store them system wide, for VPN connections I would (always) default to make them agent owned. For that reason, I would like your feedback as NetworkManager upstream. Maybe we can come up with a set of recommendations how clients should behave for unprivileged users in a variety of use cases (WiFi, VPN, etc). Once we have that set of rules/recommendations, it would be easier for me to contact the various upstream projects like GNOME, Cinnamon, KDE. I would also be interested how other distros handle this situation and what there default policy is. I know that Fedora uses --enable-modify-system, which is probably ok if your target audience is a single-user desktop system. This email is already pretty long, so I'll stop here. Looking forward to read your thoughts, Michael [1] https://salsa.debian.org/utopia-team/network-manager-applet/-/blob/debian/master/debian/patches/Allow-creation-of-connections-without-admin-privileges.patch signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Collect agreement/disagreement to Relicense NetworkManager under LGPL-2.1+
Am 09.01.20 um 13:26 schrieb Thomas Haller via networkmanager-list: > Hi all, > > > Currently, we have some LGPL vs. GPL license issue in libnm. > This will be addressed by [1]. > > However, I'd like not only to fix that particular issue, but instead > collect agreement/disagreement of copyright holders of NetworkManager > code, to perform this and future such relicensing. > > I would ask everybody relevant to provide explicitl agreement or > disagreement. This is all explained and tracked in our git repository > [2]. > > I would very much appreciate if you could look at [2] and provide > feedback. > > [1] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/390 > > [2] > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/master/RELICENSE.md I'm fine with the changes above. Michael signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
Bringing Vincent into the loop here. Vincent, can you gather the information Beniamino is asking for? Am 08.08.19 um 09:51 schrieb Beniamino Galvani: > On Wed, Aug 07, 2019 at 05:00:01PM +0200, Michael Biebl wrote: >> Full downstream bug report at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930 > > Hi, > > comparing a successful run to a failed one, the only difference > visible from logs is that sometimes the server replies with a NAK > instead of an ACK. > > Aug 07 14:06:14 [1565179574.0438] libsystemd: DHCP CLIENT > (0x1bf948fc): OFFER > Aug 07 14:06:14 [1565179574.0439] libsystemd: DHCP CLIENT > (0x1bf948fc): received message was not an ACK, ignoring > Aug 07 14:06:14 [1565179574.0439] libsystemd: DHCP CLIENT > (0x1bf948fc): REQUEST (requesting) > Aug 07 14:06:14 [1565179574.0441] libsystemd: DHCP CLIENT > (0x1bf948fc): received message was not an ACK, ignoring > Aug 07 14:06:14 [1565179574.0448] libsystemd: DHCP CLIENT > (0x1bf948fc): NAK: requested address not available > > Aug 07 14:04:28 [1565179468.2149] libsystemd: DHCP CLIENT > (0x299b0344): OFFER > Aug 07 14:04:28 [1565179468.2150] libsystemd: DHCP CLIENT > (0x299b0344): received message was not an ACK, ignoring > Aug 07 14:04:28 [1565179468.2151] libsystemd: DHCP CLIENT > (0x299b0344): REQUEST (requesting) > Aug 07 14:04:28 [1565179468.2164] libsystemd: DHCP CLIENT > (0x299b0344): ACK > Aug 07 14:04:28 [1565179468.2417] libsystemd: DHCP CLIENT > (0x299b0344): lease expires in 23h 59min 57s > Aug 07 14:04:28 [1565179468.2418] libsystemd: DHCP CLIENT > (0x299b0344): T2 expires in 20h 59min 58s > Aug 07 14:04:28 [1565179468.2418] libsystemd: DHCP CLIENT > (0x299b0344): T1 expires in 11h 59min 59s > > Would it be possible to capture a dump of DHCP packets for a success > and for a failure? And also with dhclient (but perhaps this is not > necessary). Do you know which DHCP server it is? > > Beniamino > > >> Weitergeleitete Nachricht >> Betreff: Re: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: >> Bug#933930: network-manager: Ethernet connection no longer works >> Datum: Wed, 7 Aug 2019 15:58:04 +0200 >> Von: Vincent Lefevre >> An: Michael Biebl >> Kopie (CC): 933...@bugs.debian.org >> >> On 2019-08-07 12:57:37 +0200, Michael Biebl wrote: >>> mbiebl_, Unclear what is not working. Could you ask for >>> level=TRACE logs? See >>> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 >>> , preferably without ratelimiting from journal (see also the comment) >> >> I've attached an archive with 3 log files of tests with the >> internal dhcp client: >> >> * nm-1.19.90-failing (with network-manager 1.19.90-2). >> I had to wait for more that one minute to get an IP address, and this >> was not even the correct one (I normally have a fixed IP address). >> Sometimes, this is worse, e.g. after each of the following reboots >> REBOOT in 1s >> REBOOT in 2s >> REBOOT in 4s >> REBOOT in 8s >> REBOOT in 16s >> REBOOT in 32s >> REBOOT in 1min 4s >> I got "NAK: requested address not available". I did not wait longer. >> >> * nm-1.19.90-working (with network-manager 1.19.90-2). >> I got the correct IP address (140.77.13.17) after 5 seconds. >> This is OK. >> >> * nm-1.20.0-failing (with network-manager 1.20.0-1). >> After each of the following reboots >> REBOOT in 1s >> REBOOT in 2s >> REBOOT in 4s >> REBOOT in 8s >> REBOOT in 16s >> REBOOT in 32s >> REBOOT in 1min 4s >> I got "NAK: requested address not available". I did not wait longer. >> I tried several times and could not make it work. >> Still no issues with dhcp=dhclient. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Fwd: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works
Full downstream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933930 Weitergeleitete Nachricht Betreff: Re: [Pkg-utopia-maintainers] Bug#933930: Bug#933930: Bug#933930: network-manager: Ethernet connection no longer works Datum: Wed, 7 Aug 2019 15:58:04 +0200 Von: Vincent Lefevre An: Michael Biebl Kopie (CC): 933...@bugs.debian.org On 2019-08-07 12:57:37 +0200, Michael Biebl wrote: > mbiebl_, Unclear what is not working. Could you ask for > level=TRACE logs? See > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 > , preferably without ratelimiting from journal (see also the comment) I've attached an archive with 3 log files of tests with the internal dhcp client: * nm-1.19.90-failing (with network-manager 1.19.90-2). I had to wait for more that one minute to get an IP address, and this was not even the correct one (I normally have a fixed IP address). Sometimes, this is worse, e.g. after each of the following reboots REBOOT in 1s REBOOT in 2s REBOOT in 4s REBOOT in 8s REBOOT in 16s REBOOT in 32s REBOOT in 1min 4s I got "NAK: requested address not available". I did not wait longer. * nm-1.19.90-working (with network-manager 1.19.90-2). I got the correct IP address (140.77.13.17) after 5 seconds. This is OK. * nm-1.20.0-failing (with network-manager 1.20.0-1). After each of the following reboots REBOOT in 1s REBOOT in 2s REBOOT in 4s REBOOT in 8s REBOOT in 16s REBOOT in 32s REBOOT in 1min 4s I got "NAK: requested address not available". I did not wait longer. I tried several times and could not make it work. Still no issues with dhcp=dhclient. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) nm-dhcp.tar.xz Description: Binary data signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager: doesn't show nor autoconnect to hidden wifi
Am 17.07.19 um 10:48 schrieb Jiri Novak: > Managed to debug it with someone else at #nm irc. > > the issue was that the wifi.hidden=yes works only on commandline, in > config file it needs hidden=true. > seems this version strictly needs this configured, the version shipped > with debian 9 did autoconnect even without hidden=true, now it needs to > be added with "nmcli connection modify uuid wifi.hidden=yes" or adding > line in the profile file under > > [wifi] > hidden=true Looping in the networkmanager mailing list. Not sure if this new behaviour of having to explicitly set hidden=true is deliberate or considered a bug (given that it breaks existing connection profiles) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v3] Do not use /etc/resolv.conf symbolic links on SELinux
Am 29.09.2016 um 18:01 schrieb Guido Trentalancia: > On Thu, 29/09/2016 at 17.52 +0200, Michael Biebl wrote: >> Am 29.09.2016 um 17:33 schrieb Guido Trentalancia: >>> >>> On Thu, 29/09/2016 at 17.29 +0200, Michael Biebl wrote: >>>> >>>> Am 29.09.2016 um 17:11 schrieb Guido Trentalancia: >>>>> >>>>> >>>>> Run-time checks are wrong because they leave the filesystem in >>>>> a >>>>> state that is not usable when SELinux goes back into enforcing >>>>> mode. >>>>> >>>>> Compile-time checks have no side effects and in any case are >>>>> better >>>>> than the bug! >>>> >>>> Debian enables selinux support during compile time but we do not >>>> enable >>>> selinux by default. >>>> >>>> So the side-effect of this patch would be that suddenly NM would >>>> use >>>> files instead of symlinks on Debian. >>> >>> This is not a side-effect in my opinion, but an added benefit >>> because >>> there is no good reason for using a symbolic link. >> >> So you want to get rid of the symbolic link altogether and selinux is >> only a diversion? > > I am in favor of getting rid completely of the symbolic link creation, > but this is outside of the scope of a simple patch created as a quick > fix of an existing bug. > > I'll leave more extensive changes to the author... They are not > strictly required for running NetworkManager. How do resolvconf/openresolv or resolved/networkd handle this? They use a file in /run as well and /etc/resolv.conf being a symlink to that file. I know basically zero about selinux but I would assume there is a way to get the selinux labelling right otherwise they would be broken as well. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v3] Do not use /etc/resolv.conf symbolic links on SELinux
Am 29.09.2016 um 17:33 schrieb Guido Trentalancia: > On Thu, 29/09/2016 at 17.29 +0200, Michael Biebl wrote: >> Am 29.09.2016 um 17:11 schrieb Guido Trentalancia: >>> >>> Run-time checks are wrong because they leave the filesystem in a >>> state that is not usable when SELinux goes back into enforcing >>> mode. >>> >>> Compile-time checks have no side effects and in any case are better >>> than the bug! >> >> Debian enables selinux support during compile time but we do not >> enable >> selinux by default. >> >> So the side-effect of this patch would be that suddenly NM would use >> files instead of symlinks on Debian. > > This is not a side-effect in my opinion, but an added benefit because > there is no good reason for using a symbolic link. So you want to get rid of the symbolic link altogether and selinux is only a diversion? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v3] Do not use /etc/resolv.conf symbolic links on SELinux
Am 29.09.2016 um 17:11 schrieb Guido Trentalancia: > Run-time checks are wrong because they leave the filesystem in a state that > is not usable when SELinux goes back into enforcing mode. > > Compile-time checks have no side effects and in any case are better than the > bug! Debian enables selinux support during compile time but we do not enable selinux by default. So the side-effect of this patch would be that suddenly NM would use files instead of symlinks on Debian. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] plugins: ifupdown: support source-directory stanza
Am 06.09.2016 um 20:37 schrieb Tony Espy: > On 09/06/2016 02:05 PM, Michael Biebl wrote: >> Am 06.09.2016 um 15:41 schrieb Tony Espy: >>> From: Scott Sweeny >>> >>> Enable the ifupdown settings plugin to read interface >>> definitions from the source directory: >> >> Hm, I must be missing something. Doesn't the plugin already support the >> source stanza. >> See https://bugzilla.gnome.org/show_bug.cgi?id=707276 > > This patch adds support for the 'source-directory' stanza, not 'source'. Oh, right. Thanks for the clarification. Didn't read carefully enough. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] plugins: ifupdown: support source-directory stanza
Am 06.09.2016 um 15:41 schrieb Tony Espy: > From: Scott Sweeny > > Enable the ifupdown settings plugin to read interface > definitions from the source directory: Hm, I must be missing something. Doesn't the plugin already support the source stanza. See https://bugzilla.gnome.org/show_bug.cgi?id=707276 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.2.4 released
Am 08.08.2016 um 10:18 schrieb Beniamino Galvani: > On Sun, Aug 07, 2016 at 11:14:45PM +0200, Michael Biebl wrote: >> Since the upgrade to 1.2.4, I noticed that my network connection >> (wireless) is gone after a suspend/resume and NM does not auto-connect >> on resume. >> >> Is anyone else seeing this behaviour? If so, I would file a bug report >> for this. > > Hi, > > there are other reports for this issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=1362165 > > and it seems these two patches from master branch should fix the problem: > > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=899d7e5cb1eb3bddaf92de3644c49c9f634b675e > > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eed8fd2e43d244caa856d9993e750ff19ba62fd7 > > Can you please give them a try? That seems to do the trick. Thanks! Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.2.4 released
Am 03.08.2016 um 18:40 schrieb Francesco Giudici: > Hi, > I'm pleased to announce the second update to the NetworkManager 1.2.x > stable series. Since the upgrade to 1.2.4, I noticed that my network connection (wireless) is gone after a suspend/resume and NM does not auto-connect on resume. Is anyone else seeing this behaviour? If so, I would file a bug report for this. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.2.4 released
Hi Am 03.08.2016 um 18:40 schrieb Francesco Giudici: > The 1.2.4 release include some new features and bug fixes. > > The rc-manager option has been extended with the "symlink" and > "unmanaged" values. Moreover, it is now possible to set its default by > passing the option "--with-config-dns-rc-manager-default" during > configuration at compile time. Given bug reports like [1], I'm tempted to switch the default in Debian from symlink to file. What are the benefits of symlink over file which would make it worth keeping? Regards, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826366 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.1.91 (1.2-beta2) released
Am 21.03.2016 um 07:32 schrieb Robby Workman: > 2. Some manual pages were not installed, e.g. NetworkManager.conf(5), >although nm-system-settings.conf(5), which directs users to the >former, is installed. Looking at the Makefile.am, it appears that >maybe these are autogenerated during tarball creating and shipped >there as pregenerated files, but if so, that didn't happen with >the 1.1.91 tarball. Maybe they need to be added to EXTRA_DIST? Atm only $(docbook_autogenerated_man_pages) is added to EXTRA_DIST, looks like $(docbook_generated_man_pages) is missing. Shipping $(configure_generated_man_pages) in the tarball is probably not necessary, they are created by ./configure after all. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dbus-policy-without-send-destination
Hi everyone, when building NetworkManager on Debian, I get the following warning from lintian, our Debian package checker: > W: network-manager: dbus-policy-without-send-destination > etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf context="default"> send_interface="org.freedesktop.NetworkManager.SecretAgent"/> > N: > N:The package contains D-Bus policy configuration that uses one of the > N:send_* conditions, but does not specify a send_destination, and is not > N:specific to root. > N: > N:Rules of the form > N: > N: > N: > N:allow messages with the given interface to be sent to service, not > N:just the one installing the rule, which is rarely what was intended. > N: > N:Similarly, on the system bus, rules of the form > N: > N: > N: > N:are redundant with the system bus's default-deny policy, and have > N:unintended effects on other services. > N: > N:This check ignores rules of the form > N: > N: > N: > N: > N: > N:which are commonly used for the "agent" pattern seen in services like > N:BlueZ and NetworkManager: a root-privileged daemon calls out to one or > N:more per-user user interface agent processes with no specific name, so > N:send_destination is not easily applicable. However, such rules should > N:still be made as specific as possible to avoid undesired side-effects. > N: > N:Refer to https://bugs.freedesktop.org/show_bug.cgi?id=18961 and > N:http://lists.freedesktop.org/archives/dbus/2008-February/009401.html for > N:details. > N: > N:Severity: normal, Certainty: certain > N: > N:Check: dbus, Type: binary > N: > W: network-manager: dbus-policy-without-send-destination > etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf context="default"> send_member="SetLogging"/> > W: network-manager: dbus-policy-without-send-destination > etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf context="default"> send_member="Sleep"/> > W: network-manager: dbus-policy-without-send-destination > etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf context="default"> send_interface="org.freedesktop.NetworkManager.Settings" > send_member="LoadConnections"/> > W: network-manager: dbus-policy-without-send-destination > etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf context="default"> send_interface="org.freedesktop.NetworkManager.Settings" > send_member="ReloadConnections"/> Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Revert "Install a desktop file for nm-vpnc-auth-dialog"
Am 22.01.2016 um 00:36 schrieb Michael Biebl: > The desktop file was added a long time ago, when we didn't have native > gnome-shell dialogs yet. This is no longer the case and the vpnc plugin > uses supports-external-ui-mode=true nowadays. So drop the desktop file > again. Dan rightfully pointed out, that we need to update po/ accordingly. See the attached follow up commit. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From 0eefae6fa8ab635fe8bb49b436c7e6d3293bcaa1 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Fri, 22 Jan 2016 00:51:22 +0100 Subject: [PATCH] po: update for the removal of nm-vpnc-auth-dialog.desktop.in.in This is a follow up for d58947f6173fc2ebec5ac8734e2daa27b0e2e3fc. --- po/POTFILES.in | 1 - po/POTFILES.skip | 3 --- po/bs.po | 8 po/ca.po | 10 -- po/cs.po | 8 po/da.po | 8 po/de.po | 8 po/el.po | 8 po/en_GB.po | 8 po/eo.po | 8 po/es.po | 8 po/eu.po | 8 po/fa.po | 8 po/fi.po | 8 po/fr.po | 8 po/gl.po | 8 po/hu.po | 8 po/id.po | 8 po/it.po | 8 po/ja.po | 8 po/lt.po | 8 po/lv.po | 8 po/nb.po | 8 po/pa.po | 9 - po/pl.po | 8 po/pt.po | 9 - po/pt_BR.po | 8 po/ru.po | 8 po/sl.po | 8 po/sr.po | 8 po/s...@latin.po | 8 po/sv.po | 8 po/tr.po | 8 33 files changed, 256 deletions(-) diff --git a/po/POTFILES.in b/po/POTFILES.in index c88e300..e74381c 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -1,7 +1,6 @@ # List of source files containing translatable strings. # Please keep this file sorted alphabetically. auth-dialog/main.c -auth-dialog/nm-vpnc-auth-dialog.desktop.in.in properties/nm-vpnc.c [type: gettext/glade]properties/nm-vpnc-dialog.ui src/nm-vpnc-service.c diff --git a/po/POTFILES.skip b/po/POTFILES.skip index 7c11971..e69de29 100644 --- a/po/POTFILES.skip +++ b/po/POTFILES.skip @@ -1,3 +0,0 @@ -auth-dialog/nm-vpnc-auth-dialog.desktop.in -# https://bugs.launchpad.net/intltool/+bug/1117944 -sub/auth-dialog/nm-vpnc-auth-dialog.desktop.in diff --git a/po/bs.po b/po/bs.po index 9f3eecc..f3335b6 100644 --- a/po/bs.po +++ b/po/bs.po @@ -46,14 +46,6 @@ msgid "You need to authenticate to access the Virtual Private Network '%s'." msgstr "" "Trebate provjeriti autentiÄnost za pristup virtuelnoj privatnoj mreži '%s'." -#: ../auth-dialog/nm-vpnc-auth-dialog.desktop.in.in.h:1 -msgid "Network" -msgstr "Mreža" - -#: ../auth-dialog/nm-vpnc-auth-dialog.desktop.in.in.h:2 -msgid "Request VPN authentication" -msgstr "Zatraži VPN autentifikaciju" - #: ../nm-vpnc.desktop.in.h:1 msgid "VPN Connection Manager (vpnc)" msgstr "VPN Upravitelj konekcija(vpnc)" diff --git a/po/ca.po b/po/ca.po index afc7552..8fb1c58 100644 --- a/po/ca.po +++ b/po/ca.po @@ -52,16 +52,6 @@ msgstr "Contrasenya de _grup:" msgid "You need to authenticate to access the Virtual Private Network '%s'." msgstr "Us heu d'autenticar per poder accedir a la xarxa privada virtual «%s»." -#: ../auth-dialog/nm-vpnc-auth-dialog.desktop.in.in.h:1 -msgid "Network" -msgstr "" - -#: ../auth-dialog/nm-vpnc-auth-dialog.desktop.in.in.h:2 -#, fuzzy -#| msgid "Use _domain for authentication" -msgid "Request VPN authentication" -msgstr "Utilitzeu el _domini per l'autenticació" - #: ../properties/nm-vpnc.c:51 msgid "Cisco Compatible VPN (vpnc)" msgstr "VPN compatible amb Cisco (vpnc)" diff --git a/po/cs.po b/po/cs.po index 4ad0623..112e40d 100644 --- a/po/cs.po +++ b/po/cs.po @@ -48,14 +48,6 @@ msgstr "Heslo _skupiny:" msgid "You need to authenticate to access the Virtual Private Network '%s'." msgstr "Pro pÅÃstup do VPN â%sâ se musà provést ovÄÅenÃ." -#: ../auth-dialog/nm-vpnc-auth-dialog.desktop.in.in.h:1 -msgid "Network" -msgstr "SÃÅ¥" - -#: ../auth-dialog/nm-vpnc-auth-dialog.desktop.in.in.h:2 -msgid "Request VPN authentication" -msgstr "Požadovat ovÄÅenà VPN" - #: ../nm-vpnc.desktop.in.h:1 msgid "VPN Connection Manager (vpnc)" msgstr "Správce spojenà VPN (vpnc)" diff --git a/po/da.po b/po/da.po index 405bedc..15ba8b6 100644 --- a/po/da.po +++ b/po/da.po @@ -47,14 +47,6 @@ msgstr "VPN-godkendelse" msgid &qu
[PATCH] Revert "Install a desktop file for nm-vpnc-auth-dialog"
The desktop file was added a long time ago, when we didn't have native gnome-shell dialogs yet. This is no longer the case and the vpnc plugin uses supports-external-ui-mode=true nowadays. So drop the desktop file again. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From d58947f6173fc2ebec5ac8734e2daa27b0e2e3fc Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Fri, 22 Jan 2016 00:28:28 +0100 Subject: [PATCH] Revert "Install a desktop file for nm-vpnc-auth-dialog" This reverts commit ae326938797b93dbc07df07296f9b00c5b042f69. The plugin uses supports-external-ui-mode=true nowadays. This means gnome-shell no longer needs to start nm-vpnc-auth-dialog but uses builtin dialogs to prompt for authentication. --- acinclude.m4 | 40 --- auth-dialog/Makefile.am | 15 +- auth-dialog/nm-vpnc-auth-dialog.desktop.in.in | 7 - configure.ac | 3 -- 4 files changed, 1 insertion(+), 64 deletions(-) delete mode 100644 acinclude.m4 delete mode 100644 auth-dialog/nm-vpnc-auth-dialog.desktop.in.in diff --git a/acinclude.m4 b/acinclude.m4 deleted file mode 100644 index 0c71173..000 --- a/acinclude.m4 +++ /dev/null @@ -1,40 +0,0 @@ -dnl AS_AC_EXPAND(VAR, CONFIGURE_VAR) -dnl -dnl example -dnl AS_AC_EXPAND(SYSCONFDIR, $sysconfdir) -dnl will set SYSCONFDIR to /usr/local/etc if prefix=/usr/local - -AC_DEFUN([AS_AC_EXPAND], -[ - EXP_VAR=[$1] - FROM_VAR=[$2] - - dnl first expand prefix and exec_prefix if necessary - prefix_save=$prefix - exec_prefix_save=$exec_prefix - - dnl if no prefix given, then use /usr/local, the default prefix - if test "x$prefix" = "xNONE"; then -prefix=$ac_default_prefix - fi - dnl if no exec_prefix given, then use prefix - if test "x$exec_prefix" = "xNONE"; then -exec_prefix=$prefix - fi - - full_var="$FROM_VAR" - dnl loop until it doesn't change anymore - while true; do -new_full_var="`eval echo $full_var`" -if test "x$new_full_var"="x$full_var"; then break; fi -full_var=$new_full_var - done - - dnl clean up - full_var=$new_full_var - AC_SUBST([$1], "$full_var") - - dnl restore prefix and exec_prefix - prefix=$prefix_save - exec_prefix=$exec_prefix_save -]) diff --git a/auth-dialog/Makefile.am b/auth-dialog/Makefile.am index 580e1a6..9add74a 100644 --- a/auth-dialog/Makefile.am +++ b/auth-dialog/Makefile.am @@ -19,18 +19,5 @@ nm_vpnc_auth_dialog_LDADD = \ $(LIBNMA_LIBS) \ $(LIBSECRET_LIBS) -@INTLTOOL_DESKTOP_RULE@ -desktopdir = $(datadir)/applications -desktop_in_in_files = nm-vpnc-auth-dialog.desktop.in.in -desktop_in_files = nm-vpnc-auth-dialog.desktop.in -desktop_DATA = $(desktop_in_files:.desktop.in=.desktop) +CLEANFILES = *~ -EXTRA_DIST = \ - $(desktop_in_in_files) - -CLEANFILES = \ - *~ \ - $(desktop_DATA) - -DISTCLEANFILES = \ - $(desktop_in_files) diff --git a/auth-dialog/nm-vpnc-auth-dialog.desktop.in.in b/auth-dialog/nm-vpnc-auth-dialog.desktop.in.in deleted file mode 100644 index 75c2f08..000 --- a/auth-dialog/nm-vpnc-auth-dialog.desktop.in.in +++ /dev/null @@ -1,7 +0,0 @@ -[Desktop Entry] -_Name=Network -_Comment=Request VPN authentication -Exec=@LIBEXECDIR@/nm-vpnc-auth-dialog -Terminal=false -Type=Application -NoDisplay=true diff --git a/configure.ac b/configure.ac index 7b42058..847a4bd 100644 --- a/configure.ac +++ b/configure.ac @@ -117,13 +117,10 @@ if ! test x"$ac_distver" = x""; then AC_DEFINE_UNQUOTED(DIST_VERSION, "$ac_distver", [Define the distribution version string]) fi -AS_AC_EXPAND(LIBEXECDIR, $libexecdir) - AC_CONFIG_FILES([ Makefile src/Makefile auth-dialog/Makefile -auth-dialog/nm-vpnc-auth-dialog.desktop.in properties/Makefile properties/tests/Makefile properties/tests/pcf/Makefile -- 2.7.0 signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] tests: use dbus-run-session instead of dbus-launch
Am 21.01.2016 um 23:19 schrieb Michael Biebl: > The dbus-run-session utility was designed to run a process within a > D-Bus session, specifically for running regressions tests and is much > better suited then dbus-launch. As an additional benefit, this avoids > any X dependencies. > > With the attached patch, I could successfully run the test-suite. Somehow the patch got lost. Trying again. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From 8d731df917a4b3843d7c5cfa85799c842680cebd Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Thu, 21 Jan 2016 23:11:29 +0100 Subject: [PATCH] tests: use dbus-run-session instead of dbus-launch The dbus-run-session utility was designed to run a process within a D-Bus session, specifically for running regressions tests and is much better suited then dbus-launch. As an additional benefit, this avoids any X dependencies. --- libnm-glib/tests/libnm-glib-test-launch.sh | 6 +- libnm/tests/libnm-test-launch.sh | 6 +- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/libnm-glib/tests/libnm-glib-test-launch.sh b/libnm-glib/tests/libnm-glib-test-launch.sh index 980f834..1064e41 100755 --- a/libnm-glib/tests/libnm-glib-test-launch.sh +++ b/libnm-glib/tests/libnm-glib-test-launch.sh @@ -1,7 +1,3 @@ #!/bin/sh -# Spawn DBus -eval `dbus-launch --sh-syntax` -trap "kill $DBUS_SESSION_BUS_PID" EXIT - -"$@" +dbus-run-session -- "$@" diff --git a/libnm/tests/libnm-test-launch.sh b/libnm/tests/libnm-test-launch.sh index 980f834..1064e41 100755 --- a/libnm/tests/libnm-test-launch.sh +++ b/libnm/tests/libnm-test-launch.sh @@ -1,7 +1,3 @@ #!/bin/sh -# Spawn DBus -eval `dbus-launch --sh-syntax` -trap "kill $DBUS_SESSION_BUS_PID" EXIT - -"$@" +dbus-run-session -- "$@" -- 2.7.0 signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] tests: use dbus-run-session instead of dbus-launch
The dbus-run-session utility was designed to run a process within a D-Bus session, specifically for running regressions tests and is much better suited then dbus-launch. As an additional benefit, this avoids any X dependencies. With the attached patch, I could successfully run the test-suite. NOTE: There is one remainig usage of dbus-launch in tools/run-test-valgrind.sh. I didn't touch that script, as it wasn't immediately necessary to run the test suite and converting this script to dbus-run-session wasn't as straightforward as the other two. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
libnm-* configure check in nm-applet 1.2
Hi, nm-applet 1.1.90 contains the following configure check: PKG_CHECK_MODULES(LIBNM_GLIB, [gio-2.0 >= 2.32 NetworkManager >= 1.1 libnm-glib >= 1.1 libnm-util >= 1.1 libnm-glib-vpn >= 1.1 This check should be updated to check for libnm >= 1.1 instead. libnm-glib/libnm-util are still required to build libnm-gtk, which is now deprecated. Dan suggested to add a configure switch t disable building libnm-gtk. Checking for libnm-glib/libnm-util should therefor be done conditional. He also mentioned that NMA_CFLAGS in configure.ac should probably be LIBNM_GLIB_CFLAGS Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
broken VPN routes (Re: ANN: NetworkManager 1.0.10 released)
Am 04.01.2016 um 19:34 schrieb Thomas Haller: > this seems to be a bug in NM. > > The upstream BZ is https://bugzilla.gnome.org/show_bug.cgi?id=759892 > (at the moment still unfixed). Maybe this helps https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809526#10 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.10 released
Hi everyone! Am 23.12.2015 um 15:47 schrieb Lubomir Rintel: > We're not releasing the new versions of VPN plugins this time. The VPN > plugins for older versions of NetworkManager remain compatible with > NetworkManager 1.0.10. You're encouraged to run version 1.0.8 of the > plugins. I received several bug reports against 1.0.10, which deal with broken routes and VPN. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809195 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809494 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809526 Is that a bug in NetworkManager or do the VPN plugins need changes for 1.0.10? Regards, Michael signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] initscript: remove all distribution initscripts
Am 01.12.2015 um 19:22 schrieb Thomas Haller: > These initscripts weren't modified for a long time. Are they > just unused or flawless? It seems they are no longer best-practice > (e.g. NetworkManager supports reloading configuration with SIGHUP, > which only x implement). > > Nowadays some distributions moved to systemd and quite possible > nobody uses these scripts. Also, any potential downstream user > already has a (probably modified) copy of these initscripts. > > Just remove them. ok from the Debian/Ubuntu side. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] start after systemd-networkd
Am 25.11.2015 um 11:53 schrieb Christian Hess: > From: Christian Hesse > > It is possible to use systemd-networkd for some general network setup > (rename devices, ...) even for devices that are managed by > NetworkManager later. > Since systemd 228 the behaviour changed that systemd-networkd drops > foreign configuration from devices. It does not change configuration > that is done after systemd-networkd has started up, though. > To prevent race conditions we order NetworkManager service to start > after systemd-networkd service. > > Signed-off-by: Christian Hesse > --- > data/NetworkManager.service.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/data/NetworkManager.service.in b/data/NetworkManager.service.in > index 6690f5a..9194d4b 100644 > --- a/data/NetworkManager.service.in > +++ b/data/NetworkManager.service.in > @@ -2,6 +2,7 @@ > Description=Network Manager > Wants=network.target > Before=network.target @DISTRO_NETWORK_SERVICE@ > +After=systemd-networkd.service I don't see why this should be necessary. systemd-networkd is only supposed to drop foreign configuration from devices it manages [1]. Having the same device managed by networkd and NetworkManager is simply not a reasonable thing to do. Michael [1] https://github.com/systemd/systemd/commit/5e5b137acc7094c9a1b8e7634b426dd445688bf0 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.8 released
Am 25.11.2015 um 13:46 schrieb Michael Biebl: > Am 25.11.2015 um 09:49 schrieb Thomas Haller: >> Thus it's correct to have no "Requires". > > As I tried to explain, > /usr/include/libnm/nm-version.h (from libnm) does actually include a > header from a legacy library. So it would be broken without the legacy > headers being installed. > So, either #include is dropped from > /usr/include/libnm/nm-version.h, or libnm.pc get's Requires on > NetworkManager.pc. Ok, my fault. I just realized that nm-version-macros.h is actually copied twice. To /usr/include/libnm/nm-version-macros.h *and* /usr/include/NetworkManager/nm-version.h. So, nm-version.h including nm-version-macros.h is fine. Somehow I missed that there is an additional copy. Sorry for the noise. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.8 released
Hi Thomas Am 25.11.2015 um 09:49 schrieb Thomas Haller: > On Wed, 2015-11-25 at 09:45 +0100, Thomas Haller wrote: >> On Wed, 2015-11-25 at 02:46 +0100, Michael Biebl wrote: >>> Hi >> >>> Shouldn't libnm.pc have >>> Requires: NetworkManager >= 1.0.8 >> >> Yeah maybe, I dunno. Lubomir? > > Ah, got it now... > > As detailed before, NetworkManager in this case means > "NetworkManager.pc" which is part of the legacy libraries. > libnm.pc is self-contained and has no requirements on other > NetworkManager libraries. > > Thus it's correct to have no "Requires". As I tried to explain, /usr/include/libnm/nm-version.h (from libnm) does actually include a header from a legacy library. So it would be broken without the legacy headers being installed. So, either #include is dropped from /usr/include/libnm/nm-version.h, or libnm.pc get's Requires on NetworkManager.pc. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.8 released
Hi Am 23.11.2015 um 18:20 schrieb Lubomir Rintel: > I'm pleased to announce the release of NetworkManager 1.0.8, the > latest stable release in the 1.0.x series. We recommend that users > of 1.0.x series as well as users of older 0.9.10.x series upgrade to > this release which is D-Bus and C API backwards compatible. I notice that a new header was added /usr/include/NetworkManager/nm-version-macros.h This header is used in /usr/include/libnm/nm-version.h:#include The libnm.pc file doesn't add add /usr/include/NetworkManager to its include path, so this looks like it might be broken. Shouldn't libnm.pc have Requires: NetworkManager >= 1.0.8 Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Split out the bits which determine ID_NET_DRIVER or DRIVERS, into separate udev rules file
Am 31.08.2015 um 09:50 schrieb Thomas Haller:
> On Fri, 2015-08-28 at 16:52 +0200, Michael Biebl wrote:
>> Am 28.08.2015 um 16:33 schrieb Michael Biebl:
>>> +ENV{ID_NET_DRIVER}=="?*", GOTO="nm_drivers_end"
>>> +DRIVERS=="?*", GOTO="nm_unmanaged_drivers_end"
>>^
>> Sorry, this was a typo. Noticed the second I hit send :-/
>>
>> Fixed patch attached.
>
> LGTM
Thanks for the review. Pushed to master and nm-1-0
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Split out the bits which determine ID_NET_DRIVER or DRIVERS, into separate udev rules file
Am 28.08.2015 um 16:33 schrieb Michael Biebl:
> +ENV{ID_NET_DRIVER}=="?*", GOTO="nm_drivers_end"
> +DRIVERS=="?*", GOTO="nm_unmanaged_drivers_end"
^
Sorry, this was a typo. Noticed the second I hit send :-/
Fixed patch attached.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From cd6dcc56c596eb62da0364e9e503b338d1423799 Mon Sep 17 00:00:00 2001
From: Michael Biebl
Date: Fri, 28 Aug 2015 16:30:15 +0200
Subject: [PATCH] Split out the bits which determine ID_NET_DRIVER or DRIVERS
into separate udev rules file
Those are not required with systemd-udevd v210 or newer. This way
distros which have a new enough version of udev can skip installing
84-nm-drivers.rules. While at it, don't use absolute paths for sed and
ethtool.
---
data/84-nm-drivers.rules | 12
data/85-nm-unmanaged.rules | 8 +---
data/Makefile.am | 2 ++
3 files changed, 15 insertions(+), 7 deletions(-)
create mode 100644 data/84-nm-drivers.rules
diff --git a/data/84-nm-drivers.rules b/data/84-nm-drivers.rules
new file mode 100644
index 000..d246ef6
--- /dev/null
+++ b/data/84-nm-drivers.rules
@@ -0,0 +1,12 @@
+# Do not modify this file, it will get overwritten on updates.
+# To override or extend the rules place a file in /etc/udev/rules.d
+
+SUBSYSTEM!="net", GOTO="nm_drivers_end"
+ACTION!="add|change", GOTO="nm_drivers_end"
+
+# Determine ID_NET_DRIVER if there's no ID_NET_DRIVER or DRIVERS (old udev?)
+ENV{ID_NET_DRIVER}=="?*", GOTO="nm_drivers_end"
+DRIVERS=="?*", GOTO="nm_drivers_end"
+PROGRAM="/bin/sh -c 'ethtool -i $1 | sed -n s/^driver:\ //p' -- $env{INTERFACE}", RESULT=="?*", ENV{ID_NET_DRIVER}="%c"
+
+LABEL="nm_drivers_end"
diff --git a/data/85-nm-unmanaged.rules b/data/85-nm-unmanaged.rules
index 9d2ad77..887ab84 100644
--- a/data/85-nm-unmanaged.rules
+++ b/data/85-nm-unmanaged.rules
@@ -1,15 +1,9 @@
-# Do not modify this file, it will get overwriten on updates.
+# Do not modify this file, it will get overwritten on updates.
# To override or extend the rules place a file in /etc/udev/rules.d
SUBSYSTEM!="net", GOTO="nm_unmanaged_end"
ACTION!="add|change", GOTO="nm_unmanaged_end"
-# Determine ID_NET_DRIVER if there's no ID_NET_DRIVER or DRIVERS (old udev?)
-ENV{ID_NET_DRIVER}=="?*", GOTO="nm_unmanaged_driver"
-DRIVERS=="?*", GOTO="nm_unmanaged_driver"
-PROGRAM="/bin/sh -c '/usr/sbin/ethtool -i $1 | /bin/sed -n s/^driver:\ //p' -- $env{INTERFACE}", RESULT=="?*", ENV{ID_NET_DRIVER}="%c"
-LABEL="nm_unmanaged_driver"
-
# VirtualBox host networking. Out-of-tree driver that looks like an ordinary
# Ethernet. No parent device (lives in /virtual/), no support for ethtool
# to identify the driver, MAC address defaults to 08:00:27:, but can be
diff --git a/data/Makefile.am b/data/Makefile.am
index 64ff337..ce059fc 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -37,6 +37,7 @@ examples_DATA = server.conf
if WITH_UDEV_DIR
udevrulesdir = $(UDEV_DIR)/rules.d
udevrules_DATA = \
+ 84-nm-drivers.rules \
85-nm-unmanaged.rules
endif
@@ -57,6 +58,7 @@ EXTRA_DIST = \
NetworkManager-wait-online-systemd-pre200.service.in \
NetworkManager-dispatcher.service.in \
org.freedesktop.NetworkManager.service.in \
+ 84-nm-drivers.rules \
85-nm-unmanaged.rules \
server.conf.in
--
2.5.0
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Split out the bits which determine ID_NET_DRIVER or DRIVERS, into separate udev rules file
Those are not required with systemd-udevd v210 or newer. This way
distros which have a new enough version of udev can skip installing
84-nm-drivers.rules. While at it, don't use absolute paths for sed and
ethtool.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 7051669d45aaba29a61a6498a92d4d90294e5c37 Mon Sep 17 00:00:00 2001
From: Michael Biebl
Date: Fri, 28 Aug 2015 16:30:15 +0200
Subject: [PATCH] Split out the bits which determine ID_NET_DRIVER or DRIVERS
into separate udev rules file
Those are not required with systemd-udevd v210 or newer. This way
distros which have a new enough version of udev can skip installing
84-nm-drivers.rules. While at it, don't use absolute paths for sed and
ethtool.
---
data/84-nm-drivers.rules | 12
data/85-nm-unmanaged.rules | 8 +---
data/Makefile.am | 2 ++
3 files changed, 15 insertions(+), 7 deletions(-)
create mode 100644 data/84-nm-drivers.rules
diff --git a/data/84-nm-drivers.rules b/data/84-nm-drivers.rules
new file mode 100644
index 000..3467089
--- /dev/null
+++ b/data/84-nm-drivers.rules
@@ -0,0 +1,12 @@
+# Do not modify this file, it will get overwritten on updates.
+# To override or extend the rules place a file in /etc/udev/rules.d
+
+SUBSYSTEM!="net", GOTO="nm_drivers_end"
+ACTION!="add|change", GOTO="nm_drivers_end"
+
+# Determine ID_NET_DRIVER if there's no ID_NET_DRIVER or DRIVERS (old udev?)
+ENV{ID_NET_DRIVER}=="?*", GOTO="nm_drivers_end"
+DRIVERS=="?*", GOTO="nm_unmanaged_drivers_end"
+PROGRAM="/bin/sh -c 'ethtool -i $1 | sed -n s/^driver:\ //p' -- $env{INTERFACE}", RESULT=="?*", ENV{ID_NET_DRIVER}="%c"
+
+LABEL="nm_drivers_end"
diff --git a/data/85-nm-unmanaged.rules b/data/85-nm-unmanaged.rules
index 9d2ad77..887ab84 100644
--- a/data/85-nm-unmanaged.rules
+++ b/data/85-nm-unmanaged.rules
@@ -1,15 +1,9 @@
-# Do not modify this file, it will get overwriten on updates.
+# Do not modify this file, it will get overwritten on updates.
# To override or extend the rules place a file in /etc/udev/rules.d
SUBSYSTEM!="net", GOTO="nm_unmanaged_end"
ACTION!="add|change", GOTO="nm_unmanaged_end"
-# Determine ID_NET_DRIVER if there's no ID_NET_DRIVER or DRIVERS (old udev?)
-ENV{ID_NET_DRIVER}=="?*", GOTO="nm_unmanaged_driver"
-DRIVERS=="?*", GOTO="nm_unmanaged_driver"
-PROGRAM="/bin/sh -c '/usr/sbin/ethtool -i $1 | /bin/sed -n s/^driver:\ //p' -- $env{INTERFACE}", RESULT=="?*", ENV{ID_NET_DRIVER}="%c"
-LABEL="nm_unmanaged_driver"
-
# VirtualBox host networking. Out-of-tree driver that looks like an ordinary
# Ethernet. No parent device (lives in /virtual/), no support for ethtool
# to identify the driver, MAC address defaults to 08:00:27:, but can be
diff --git a/data/Makefile.am b/data/Makefile.am
index 64ff337..ce059fc 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -37,6 +37,7 @@ examples_DATA = server.conf
if WITH_UDEV_DIR
udevrulesdir = $(UDEV_DIR)/rules.d
udevrules_DATA = \
+ 84-nm-drivers.rules \
85-nm-unmanaged.rules
endif
@@ -57,6 +58,7 @@ EXTRA_DIST = \
NetworkManager-wait-online-systemd-pre200.service.in \
NetworkManager-dispatcher.service.in \
org.freedesktop.NetworkManager.service.in \
+ 84-nm-drivers.rules \
85-nm-unmanaged.rules \
server.conf.in
--
2.5.0
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
C&P error in --enable-more-logging commit
Hi, commit 63593a19d8e7d7fb5e844f0e3c8ac847e68699cb added a --enable-more-logging configure switch which seems to be a C&P of the asserts configure switch, resulting in AC_DEFINE(NM_MORE_LOGGING, [1], [Define if more asserts are enabled]) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: is anyone actually still using WiMAX
Am 12.02.2015 um 19:09 schrieb Stuart Longland: > On 11/02/15 11:27, Michael Biebl wrote: >> Debian (and Ubuntu) never enabled WiMAX support in our packages. I don't >> have plans to enable it in our Debian packages either. >> So from my PoV, feel free to drop WiMAX support. > > Probably worth pointing out, here in Australia there's been a move to > get better Internet coverage in rural areas using fixed-wireless broadband. > > There's talk of that being based on "WiMAX 2", so there could be more > demand for WiMAX support in Linux in the future. I forgot to add, that we never enabled WiMaX support in Debianc since a/ the WiMaX SDK hasn't been packaged yet for Debian b/ there simply has been no demand so far. I vaguely remember one single bug report [1]. And this one was rather: I have a wimax0 device, but NM does not know what to do with it. Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654544 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: is anyone actually still using WiMAX
Am 10.02.2015 um 15:53 schrieb Dan Winship: > While taking cheap potshots at WiMAX during devconf.cz, we started > wonder whether anyone would care (or even notice) if we dropped support > for it in NM 1.2, given that: > > - WiMAX seems to be a dying technology > > - the Intel WiMAX driver for Linux has never worked very well, and > the SDK appears to no longer be supported > > - NM's WiMAX support requires a hacked up version of the Intel > WiMAX SDK that supports libnl3, which exists only in a git > repository whose location has never been terribly well > advertised, suggesting most distros probably don't build it > anyway. > > - Fedora dropped it a few releases back and there was no uproar > > Of course this would not affect people using WiMAX via external hotspots > (assuming such people and hotspots still exist). Debian (and Ubuntu) never enabled WiMAX support in our packages. I don't have plans to enable it in our Debian packages either. So from my PoV, feel free to drop WiMAX support. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally
Am 09.02.2015 um 11:20 schrieb Lubomir Rintel: > Hi Michael, > > Thanks you for the patch. > > On Mon, 2015-02-09 at 01:31 +0100, Michael Biebl wrote: >> Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh >> configuration plugin has been enabled. It's confusing to have this man >> page around on e.g. a Debian based distro. >> >> See attached patch. >> >> There might be small issue here, i.e. if you build the release tarball >> and you don't have ifcfg-rh enabled, then the nm-settings-ifcfg-rh.5 man >> page would be missing from the release tarball as it's not added to >> EXTRA_DIST >> >> If that is a concern, please let me know and I'll rework to the patch to >> always unconditionally build and dist the man pages, but only install >> them conditionally. > > The distribution tarball contents indeed should not depend on the > configuration configuration options. Please rework it the way you > suggest. On second thought, the pre-generated man pages are removed on "make clean", so the release tarball can't be built twice in a row. So I wonder if we should bother at all to ship pre-generated man pages. After all, xsltproc is not that an uncommon dependency. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally
Am 09.02.2015 um 01:31 schrieb Michael Biebl: > Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh > configuration plugin has been enabled. It's confusing to have this man > page around on e.g. a Debian based distro. > > See attached patch. This time for real... -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From 1ab508ebd614197a5a7b81294b318f60e2a08d44 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Mon, 9 Feb 2015 01:12:16 +0100 Subject: [PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh configuration plugin has been enabled. --- man/Makefile.am | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/man/Makefile.am b/man/Makefile.am index 4577cb4..5ed5ad5 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -67,9 +67,15 @@ docbook_generated_man_pages = \ nmcli-examples.5 docbook_autogenerated_man_pages = \ - nm-settings.5 \ - nm-settings-keyfile.5 \ + nm-settings.5 + +docbook_autogenerated_man_pages = \ + nm-settings-keyfile.5 + +if CONFIG_PLUGIN_IFCFG_RH +docbook_autogenerated_man_pages += \ nm-settings-ifcfg-rh.5 +endif EXTRA_DIST += \ nm-settings.xml\ -- 2.1.4 signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally
Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh configuration plugin has been enabled. It's confusing to have this man page around on e.g. a Debian based distro. See attached patch. There might be small issue here, i.e. if you build the release tarball and you don't have ifcfg-rh enabled, then the nm-settings-ifcfg-rh.5 man page would be missing from the release tarball as it's not added to EXTRA_DIST If that is a concern, please let me know and I'll rework to the patch to always unconditionally build and dist the man pages, but only install them conditionally. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
automake warnings about "option 'subdir-objects' is disabled"
Hi, during build, I get the following warning: > automake: warning: possible forward-incompatibility. > automake: At least a source file is in a subdirectory, but the > 'subdir-objects' > automake: automake option hasn't been enabled. For now, the corresponding > output > automake: object file(s) will be placed in the top-level directory. However, > automake: this behaviour will change in future Automake versions: they will > automake: unconditionally cause object files to be placed in the same > subdirectory > automake: of the corresponding sources. > automake: You are advised to start using 'subdir-objects' option throughout > your > automake: project, to avoid future incompatibilities. > clients/cli/Makefile.am:49: warning: source file > '$(srcdir)/../common/nm-polkit-listener.c' is in a subdirectory, > clients/cli/Makefile.am:49: but option 'subdir-objects' is disabled > clients/tui/Makefile.am:35: warning: source file > '$(srcdir)/../common/nm-secret-agent-simple.c' is in a subdirectory, ... and then hundred of those warnings. Not sure if simply adding "subdir-objects" to AM_INIT_AUTOMAKE is the right fix for this. The build seems to fail with that option set. So this probably needs some more work. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
outdated version requirements in libnm-gtk.pc.in
Hi,
had a look at nm-applet 1.0.0, specifically src/libnm-gtk/libnm-gtk.pc.in.
It contains
> nmversion=0.8.998
> Requires: NetworkManager >= ${nmversion} libnm-util >= ${nmversion}
> libnm-glib >= ${nmversion} gtk+-3.0 >= 2.91.4
That nmversion looks outdated, so does the gtk version.
Would be great if those version requirements could be updated.
Btw, is there a libnm port of nm-applet planned?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
missing xml files in 1.0.0 dist tarball
hi,
I just noticed that the 1.0.0 tarball failed to build twice in a row
(./configure && make && make clean * 2)
due to man/{NetworkManager.xml,nmcli-examples.xml} missing in the dist
tarball.
The tarball only contains the generated man pages but should also
contains the xml sources.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
.pc file for new libnm with incorrect dependencies?
Hi, the libnm.pc file for the new libnm library has Requires: gio-2.0 dbus-glib-1 This looks incorrect, especially the dependency on dbus-glib-1. Is this a C&P error? Especially since the Description is the same as for libnm-util.pc. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Support building against libsystemd library
In systemd v209, the various libraries were merged into a single
libsystemd library [1].
Add support for building against this new library and fall back to the
old library names if not found.
[1]
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 32b630692a319c14fc2cdba7e6f34404bf47957b Mon Sep 17 00:00:00 2001
From: Michael Biebl
Date: Tue, 30 Sep 2014 05:38:25 +0200
Subject: [PATCH] Support building against libsystemd library
In systemd v209, the various libraries were merged into a single
libsystemd library [1].
Add support for building against this new library and fall back to the
old library names if not found.
[1] http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
---
configure.ac | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index e24ce73..af6efb5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -331,7 +331,8 @@ AS_IF([! (echo "$with_session_tracking" | grep -q -E "^(systemd|consolekit|no)$"
AM_CONDITIONAL(SESSION_TRACKING_CK, test "$with_session_tracking" = "consolekit")
AM_CONDITIONAL(SESSION_TRACKING_SYSTEMD, test "$with_session_tracking" = "systemd")
if test "$with_session_tracking" = "systemd"; then
- PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login])
+ PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd],,
+ [PKG_CHECK_MODULES(SYSTEMD_LOGIN, [libsystemd-login])])
AC_SUBST(SYSTEMD_LOGIN_CFLAGS)
AC_SUBST(SYSTEMD_LOGIN_LIBS)
fi
@@ -342,7 +343,8 @@ AC_MSG_RESULT($with_session_tracking)
AC_ARG_WITH(suspend-resume, AS_HELP_STRING([--with-suspend-resume=upower|systemd], [Build NetworkManager with specific suspend/resume support]))
if test "z$with_suspend_resume" = "z"; then
-PKG_CHECK_EXISTS([libsystemd-login >= 183], [have_systemd_inhibit=yes], [have_systemd_inhibit=no])
+PKG_CHECK_EXISTS([libsystemd >= 209], [have_systemd_inhibit=yes],
+ [PKG_CHECK_EXISTS([libsystemd-login >= 183], [have_systemd_inhibit=yes], [have_systemd_inhibit=no])])
if test "z${have_systemd_inhibit}" = "zyes"; then
# Use systemd if it's new enough
with_suspend_resume="systemd"
@@ -355,7 +357,8 @@ fi
case $with_suspend_resume in
upower) ;;
systemd)
- PKG_CHECK_MODULES(SYSTEMD_INHIBIT, [libsystemd-login >= 183])
+ PKG_CHECK_MODULES(SYSTEMD_INHIBIT, [libsystemd >= 209],,
+ [PKG_CHECK_MODULES(SYSTEMD_INHIBIT, [libsystemd-login >= 183])])
;;
*)
AC_MSG_ERROR(--with-suspend-resume must be one of [upower, systemd])
--
2.1.1
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: recent update makes me crazy...
Am 16.07.2014 10:59, schrieb Pal, Laszlo: > Hi, > > One of the recent upgrade continuously trying to destroy my brain by > changing my virtual bridge configs... > > I don't have a very complicated config, one physical ethernet, one > wireless and five virtual networks for my KVM machines. It was ok for > several months, but after one of the recent update I cannot enable > static addressing for my bridges. If I set-up the interface correctly > (I mean using static address) and I restart NetworkManager my bridge > interfaces are duplicated and NM creates another ones with DHCP > enabled... crazy... I'm not sure if this is because virt-manager or nm > this is why I post on both list [1] and [2] might be related here. In the Debian package I currently ship [3], to not make NM manage any virtual devices, since I saw a similar behaviour as yours (NM tried to run DHCP on the vbox interfaces). Hope that helps, Michael [1] https://bugzilla.gnome.org/show_bug.cgi?id=731014#c27 [2] https://bugzilla.gnome.org/show_bug.cgi?id=732998 [3] http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=blob;f=debian/patches/0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch;hb=HEAD -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmtui links [Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released]
Am 23.06.2014 11:00, schrieb Michael Biebl: >> >> Looking at nmtui, I think I'd prefer if we made /usr/bin/nmtui-* >> symbolic links to /usr/bin/nmtui. Attached is an updated patch which I ship as part of the Debian package. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From: Michael Biebl Date: Thu, 10 Jul 2014 03:33:18 +0200 Subject: Use symlinks for nmtui Make /usr/bin/nmtui-* symbolic links to /usr/bin/nmtui. --- configure.ac| 2 ++ tui/Makefile.am | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index a77d55a..3c216a2 100644 --- a/configure.ac +++ b/configure.ac @@ -46,6 +46,8 @@ AM_PROG_CC_C_O # C++ only required if --enable-qt=yes AC_PROG_CXX +AC_PROG_LN_S + dnl Initialize libtool LT_PREREQ([2.2]) LT_INIT([disable-static]) diff --git a/tui/Makefile.am b/tui/Makefile.am index 755b689..7f4e7d6 100644 --- a/tui/Makefile.am +++ b/tui/Makefile.am @@ -24,7 +24,7 @@ links = nmtui-edit nmtui-connect nmtui-hostname install-exec-hook: for link in $(links); do \ - ln -f $(DESTDIR)$(bindir)/nmtui $(DESTDIR)$(bindir)/$$link; \ + cd $(DESTDIR)$(bindir) && $(LN_S) -f nmtui $$link; \ done uninstall-hook: signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmtui links [Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released]
Am 23.06.2014 00:23, schrieb Michael Biebl: > Am 21.06.2014 04:55, schrieb Dan Williams: >> Hi! >> >> Continuing the release bullet-train, here's the next one on the way to >> 0.9.10. > > > Looking at nmtui, I think I'd prefer if we made /usr/bin/nmtui-* > symbolic links to /usr/bin/nmtui. > > This makes it much more obvious then a hard link. > > Simple patch attached the automake documentation [1] suggests to use the AC_PROG_LN_S macro in configure.ac and then $(LN_S) in Makefile.am [1] http://www.gnu.org/software/automake/manual/html_node/Extending.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nmtui links [Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released]
Am 21.06.2014 04:55, schrieb Dan Williams: > Hi! > > Continuing the release bullet-train, here's the next one on the way to > 0.9.10. Looking at nmtui, I think I'd prefer if we made /usr/bin/nmtui-* symbolic links to /usr/bin/nmtui. This makes it much more obvious then a hard link. Simple patch attached -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? diff --git a/tui/Makefile.am b/tui/Makefile.am index 755b689..0c24466 100644 --- a/tui/Makefile.am +++ b/tui/Makefile.am @@ -24,7 +24,7 @@ links = nmtui-edit nmtui-connect nmtui-hostname install-exec-hook: for link in $(links); do \ - ln -f $(DESTDIR)$(bindir)/nmtui $(DESTDIR)$(bindir)/$$link; \ + ln -sf $(DESTDIR)$(bindir)/nmtui $(DESTDIR)$(bindir)/$$link; \ done uninstall-hook: signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: virtual interfaces [Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released]
Am 17.06.2014 17:21, schrieb Michael Biebl: > Am 07.06.2014 02:20, schrieb Dan Williams: >> Hi, >> >> I'm pleased to announce the release of NetworkManager 0.9.9.95 > > * Changes made to IP addresses, IP routes, and master/slave > relationships from > external tools are now recognized and reflected in the D-Bus API > > I do have virtualbox and vmware installed on this particular laptop, > i.e. I have the following virtual interfaces: vboxnet0 and vmnet1/vmnet8. > > nmcli shows them as > > # nmcli d > DEVICETYPE STATE CONNECTION > vmnet1ethernet connected vmnet1 > vmnet8ethernet connected vmnet8 > wlan0 wifi connected wgrouter (automatisch) > vboxnet0 ethernet disconnected -- > eth0 ethernet unavailable -- > ttyACM0 gsm unavailable -- > loloopback unmanaged -- > > > # nmcli c > ... > vmnet8 ef586f60-75cf-4717-8279-ed82c28c15cc > 802-3-ethernet vmnet8 > vmnet1 105b4339-54a8-4fea-b6fe-2e2fafabff49 > 802-3-ethernet vmnet1 > Kabelgebundene Verbindung 2 2cf491fd-a74d-4b65-84ac-789196009487 > 802-3-ethernet vboxnet0 Looks like NM is creating more of those vmnet connections # nmcli c | grep vmnet vmnet8 576ec95a-e3d3-4004-a1ad-825d0722e3e6 802-3-ethernet -- vmnet1 1cdf6f65-b143-4e52-a970-8f6028c830df 802-3-ethernet -- vmnet8 2055126c-f084-4ae3-b4de-150c95870b27 802-3-ethernet -- vmnet1 f446a89c-3b3e-40db-a275-10dee6decca7 802-3-ethernet -- That's odd. Those are stored nowhere. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released
Am 17.06.2014 19:54, schrieb Dan Winship: > On 06/17/2014 10:50 AM, Michael Biebl wrote: >> Looking through the changes in configure.ac, I notice that libteam is a >> new (optional) dependency. >> Which of the new functionality depends on libteam? > > "team" devices. (The new half-kernel/half-userland replacement for the > "bond" driver.) That's where my question was aiming at: does the bonding support in NM require libteam/teamd or does it also work with kernel-style bonding? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released
Am 17.06.2014 18:31, schrieb Dan Williams: > Separate directories were used for pre-up/pre-down because these events > block state changes internally. NM will not advance a device from > ACTIVATED -> DISCONNECTED (pre-down) or IP_CHECK -> SECONDARIES (pre-up) > until all the scripts execute. > > Unfortunately, many scripts don't bother checking the action and just > run stuff, and the goal was to ensure that couldn't adversely impact the > user experience on upgrade. I checked the complete Debian archive and there is only one package installing a dispatcher script which doesn't check for the $action parameter, so is potentially affected. Easy to fix. You were talking about many scripts doing it wrong? Do you have a list of such packages/scripts? I get where you're coming from, but there will always be ways for people to shoot themselves in the foot and I'd rather prefer consistency here then convenience for lazy script writers. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released
Am 17.06.2014 16:50, schrieb Michael Biebl: > I also noticed that you implemented pre-up and pre-down in the > dispatcher and that there are now dedicated directories in > /etc/NetworkManager/dispatcher.d/pre-down.d > /etc/NetworkManager/dispatcher.d/pre-up.d > > That seems a bit inconsistent with how currently dispatcher scripts are > handled, i.e. the "phase" is passed as $2 to scripts in > /etc/NetworkManager/dispatcher.d/ > Is there any reason why you didn't just extend the existing up/vpn-up, > down/vpn-down? This also leads to this error message from the dispatcher: Jun 17 17:03:13 pluto nm-dispatcher[14151]: Cannot execute '/etc/NetworkManager/dispatcher.d/pre-down.d': not a regular file. Jun 17 17:03:13 pluto nm-dispatcher[14151]: Cannot execute '/etc/NetworkManager/dispatcher.d/pre-up.d': not a regular file. While I'm not generally opposed to the idea of using .d directories, I think what's important is consistency. Either we use .d directories for all available actions, or we use a single directory and pass the action as $2. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
virtual interfaces [Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released]
Am 07.06.2014 02:20, schrieb Dan Williams: > Hi, > > I'm pleased to announce the release of NetworkManager 0.9.9.95 * Changes made to IP addresses, IP routes, and master/slave relationships from external tools are now recognized and reflected in the D-Bus API I do have virtualbox and vmware installed on this particular laptop, i.e. I have the following virtual interfaces: vboxnet0 and vmnet1/vmnet8. nmcli shows them as # nmcli d DEVICETYPE STATE CONNECTION vmnet1ethernet connected vmnet1 vmnet8ethernet connected vmnet8 wlan0 wifi connected wgrouter (automatisch) vboxnet0 ethernet disconnected -- eth0 ethernet unavailable -- ttyACM0 gsm unavailable -- loloopback unmanaged -- # nmcli c ... vmnet8 ef586f60-75cf-4717-8279-ed82c28c15cc 802-3-ethernet vmnet8 vmnet1 105b4339-54a8-4fea-b6fe-2e2fafabff49 802-3-ethernet vmnet1 Kabelgebundene Verbindung 2 2cf491fd-a74d-4b65-84ac-789196009487 802-3-ethernet vboxnet0 If I now disable my wlan0 interface, NM tries to activate vboxnet0, and runs dhclients, which obviously fails. This behaviour is kinda odd. Should I file a bug for this issue? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released
Hi, Am 07.06.2014 02:20, schrieb Dan Williams: > I'm pleased to announce the release of NetworkManager 0.9.9.95 > (0.9.10-beta1) and the same version of nm-applet and > nm-connection-editor. This release contains many, many enhancements and > bug fixes, most notably much better cooperation with external changes > and tools, better configurability, and better IPv6 support over 0.9.9.1 > and earlier versions. 0.9.10 is packed with so much awesome that I > can't list it all here, so just check out the updated NEWS file: > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS > https://git.gnome.org/browse/network-manager-applet/plain/NEWS This reads like an impressive update, indeed (might be worth mentioning that nm-tool was dropped,fwiw) Looking through the changes in configure.ac, I notice that libteam is a new (optional) dependency. Which of the new functionality depends on libteam? I also noticed that you implemented pre-up and pre-down in the dispatcher and that there are now dedicated directories in /etc/NetworkManager/dispatcher.d/pre-down.d /etc/NetworkManager/dispatcher.d/pre-up.d That seems a bit inconsistent with how currently dispatcher scripts are handled, i.e. the "phase" is passed as $2 to scripts in /etc/NetworkManager/dispatcher.d/ Is there any reason why you didn't just extend the existing up/vpn-up, down/vpn-down? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
bashisms in configure.ac and usage of realpath
Hi, running ./autogen.sh I get sh: 1: [[: not found during autoreconf. Culprit is m4_define([nm_git_sha], [m4_esyscmd([ ( [[ -d ./.git/ && "$(realpath ./.git/)" = "$(realpath "$(git rev-parse --git-dir 2>/dev/null)" 2>/dev/null)" ]] && git rev-parse --verify -q HEAD 2>/dev/null ) || true ])]) [[ ]] is a bashism. Fixing that to use [ ] && [ ] I encounter another error: sh: 1: realpath: not found The realpath utility is not installed by default on Debian systems. It would probably be better to use readlink -f here, since that is part of coreutils and installed by default. I'm not sure what the check is supposed to achieve, but the attached patch fixes the errors for me. Please review. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From b8fc9817a392dffb4cf2d1a86ce1be998af4bc94 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Tue, 17 Jun 2014 16:09:10 +0200 Subject: [PATCH] Fix bashisms in configure.ac [[ && ]] is a bashism, so use [ ] && [ ] instead. Also use readlink -f instead of realpath, since the latter is not guaranteed to be installed. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index e5044d4..00af5b8 100644 --- a/configure.ac +++ b/configure.ac @@ -7,7 +7,7 @@ m4_define([nm_micro_version], [9]) m4_define([nm_nano_version], [95]) m4_define([nm_version], [nm_major_version.nm_minor_version.nm_micro_version.nm_nano_version]) -m4_define([nm_git_sha], [m4_esyscmd([ ( [[ -d ./.git/ && "$(realpath ./.git/)" = "$(realpath "$(git rev-parse --git-dir 2>/dev/null)" 2>/dev/null)" ]] && git rev-parse --verify -q HEAD 2>/dev/null ) || true ])]) +m4_define([nm_git_sha], [m4_esyscmd([ ( [ -d ./.git/ ] && [ "$(readlink -f ./.git/)" = "$(readlink -f "$(git rev-parse --git-dir 2>/dev/null)" 2>/dev/null)" ] && git rev-parse --verify -q HEAD 2>/dev/null ) || true ])]) AC_INIT([NetworkManager], [nm_version], [http://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager], -- 2.0.0 signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: broken paths in VPN plugins (Re: ANN: NetworkManager 0.9.8.2 released)
Am 08.06.2013 02:31, schrieb Michael Biebl: > Hi, > > Am 07.06.2013 23:43, schrieb Dan Williams: >> http://ftp.gnome.org/pub/gnome/sources/network-manager-vpn/0.9/ >> http://ftp.gnome.org/pub/gnome/sources/network-manager-openconnect/0.9/ >> http://ftp.gnome.org/pub/gnome/sources/network-manager-openvpn/0.9/ >> http://ftp.gnome.org/pub/gnome/sources/network-manager-pptp/0.9/ >> http://ftp.gnome.org/pub/gnome/sources/network-manager-openswan/0.9/ > > Looks like the VPN plugins have broken > properties paths: > > taking nm-openvpn-service.name.in as an example: > properties=@LIBDIR@/libnm-openvpn-properties > > yet, the plugin is installed into > plugindir = $(libdir)/NetworkManager Just wanted to mention, that this has been fixed in Git in the mean time. Thanks! Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
broken paths in VPN plugins (Re: ANN: NetworkManager 0.9.8.2 released)
Hi, Am 07.06.2013 23:43, schrieb Dan Williams: > http://ftp.gnome.org/pub/gnome/sources/network-manager-vpn/0.9/ > http://ftp.gnome.org/pub/gnome/sources/network-manager-openconnect/0.9/ > http://ftp.gnome.org/pub/gnome/sources/network-manager-openvpn/0.9/ > http://ftp.gnome.org/pub/gnome/sources/network-manager-pptp/0.9/ > http://ftp.gnome.org/pub/gnome/sources/network-manager-openswan/0.9/ Looks like the VPN plugins have broken properties paths: taking nm-openvpn-service.name.in as an example: properties=@LIBDIR@/libnm-openvpn-properties yet, the plugin is installed into plugindir = $(libdir)/NetworkManager The fix should be as simple as --- a/nm-openvpn-service.name.in +++ b/nm-openvpn-service.name.in @@ -5,6 +5,6 @@ program=@LIBEXECDIR@/nm-openvpn-service [GNOME] auth-dialog=@LIBEXECDIR@/nm-openvpn-auth-dialog -properties=@LIBDIR@/libnm-openvpn-properties +properties=@LIBDIR@/NetworkManager/libnm-openvpn-properties supports-external-ui-mode=true Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Fall back to user-owned connections if user lacks, permissions
Hi, we've discussed this topic in the past and I thought I put the patches out there in the hope to get them merged upstream. To solve the user vs system vs PK prompts issues, we apply the following patch in Debian. I have similar patches for gnome-shell and gnome-control which have been posted to the bgo bug tracker [1]. We've been using those patches for a bit now and they will be in our next stable release and generally users seem to be happy with this. The main point is, that we *never* want to bother the user with PK prompts for trivial actions like creating a wifi connection. The patch description reads: For simple operations like creating a wireless connection, we never want to bother the user with PolicyKit prompts. On the other hand, granting every user the org.freedesktop.NetworkManager.settings.modify.system privilege (without authorization) might not be wanted in certain setups (like a shared laptop/computer use case). To address this we check in advance if the action would trigger a PolicyKit prompt and if that is the case fall back to user-owned connections where the secret is agent-owned. The logic is: - Bluetooth, CDMA and GSM connections: always user-owned - WEP/WPA connections: system-owned if user has the permissions, user-owned otherwise. - WiMax / Wired connections: always system-owned (with 802.1x passwords in the keyring). Distributions can still choose to override the PolicyKit configuration to grant all active users those provileges (currently used in Fedora), or make that based on group memberships (like Debian does). I've set Joss as Author since he has been doing most of the work on this patch. Cheers, Michael [1] https://bugzilla.gnome.org/show_bug.cgi?id=646187 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From 448ce6c1097ee80d170d763e4bb90e74fef48e09 Mon Sep 17 00:00:00 2001 From: Josselin Mouette Date: Fri, 8 Mar 2013 08:01:42 +0100 Subject: [PATCH] Fall back to user-owned connections if user lacks permissions For simple operations like creating a wireless connection, we never want to bother the user with PolicyKit prompts. On the other hand, granting every user the org.freedesktop.NetworkManager.settings.modify.system privilege (without authorization) might not be wanted in certain setups (like a shared laptop/computer use case). To address this we check in advance if the action would trigger a PolicyKit prompt and if that is the case fall back to user-owned connections where the secret is agent-owned. The logic is: - Bluetooth, CDMA and GSM connections: always user-owned - WEP/WPA connections: system-owned if user has the permissions, user-owned otherwise. - WiMax / Wired connections: always system-owned (with 802.1x passwords in the keyring). Distributions can still choose to override the PolicyKit configuration to grant all active users those provileges (currently used in Fedora), or make that based on group memberships (like Debian does). --- src/applet-device-wifi.c| 25 + src/connection-editor/ce-page.h |1 + src/connection-editor/new-connection.c |2 ++ src/connection-editor/page-bond.c |1 + src/connection-editor/page-bond.h |1 + src/connection-editor/page-bridge.c |1 + src/connection-editor/page-bridge.h |1 + src/connection-editor/page-dsl.c|1 + src/connection-editor/page-dsl.h|1 + src/connection-editor/page-ethernet.c |1 + src/connection-editor/page-ethernet.h |1 + src/connection-editor/page-infiniband.c |1 + src/connection-editor/page-infiniband.h |1 + src/connection-editor/page-mobile.c | 11 +++ src/connection-editor/page-mobile.h |1 + src/connection-editor/page-vlan.c |1 + src/connection-editor/page-vlan.h |1 + src/connection-editor/page-vpn.c| 10 ++ src/connection-editor/page-vpn.h|1 + src/connection-editor/page-wifi.c | 14 ++ src/connection-editor/page-wifi.h |1 + src/connection-editor/page-wimax.c |1 + src/connection-editor/page-wimax.h |1 + src/gnome-bluetooth/nma-bt-device.c |5 + src/libnm-gtk/nm-wifi-dialog.c |4 src/mobile-helpers.c|3 +++ src/utils/utils.c |7 +++ src/utils/utils.h |3 +++ src/wireless-security/ws-wep-key.c |7 +++ src/wireless-security/ws-wpa-psk.c |5 + 30 files changed, 114 insertions(+) diff --git a/src/applet-device-wifi.c b/src/applet-device-wifi.c index fa3d618..d4c8773 100644 --- a/src/applet-device-wifi.c +++ b/src/applet-device-wifi.c @@ -404,6 +404,7 @@ _do_new_auto_connection (NMApplet *applet, NMSettingWirelessSecurity *s_wsec = NULL; NMSetting8021x *s_8021x = NULL; const GByteArray *ssid; + NM80211ApFlags flags; NM802
[PATCH] Fall back to user-owned connections if user lacks, permissions
Hi, we've discussed this topic in the past and I thought I put the patches out there in the hope to get them merged upstream. To solve the user vs system vs PK prompts issues, we apply the following patch in Debian. I have similar patches for gnome-shell and gnome-control which have been posted to the bgo bug tracker [1]. We've been using those patches for a bit now and they will be in our next stable release and generally users seem to be happy with this. The main point is, that we *never* want to bother the user with PK prompts for trivial actions like creating a wifi connection. The patch description read: For simple operations like creating a wireless network, we never want to bother the user with PolicyKit prompts. On the other hand, granting every user the org.freedesktop.NetworkManager.settings.modify.system privilege (without authorization) might not be wanted in certain setups (like a shared laptop/computer use case). To address this we check in advance if the action would trigger a PolicyKit prompt and if that is the case fall back to user-owned connections where the secret is agent-owned. The logic is: - Bluetooth, CDMA and GSM connections: always user-owned - WEP/WPA connections: system-owned if user has the permissions, user-owned otherwise. - WiMax / Wired connections: always system-owned (with 802.1x passwords in the keyring). Distribution can still choose to override the PolicyKit configuration to grant all active users those provileges, or make that based on group memberships (like Debian does). I've set Joss as Author since he has been doing most of the work on this patch. Cheers, Michael [1] https://bugzilla.gnome.org/show_bug.cgi?id=646187 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From 3ffc31e5e9a576b372c9f2e44403672203bcf43d Mon Sep 17 00:00:00 2001 From: Josselin Mouette Date: Wed, 30 Jan 2013 05:10:56 +0100 Subject: [PATCH] Fall back to user-owned connections if user lacks permissions For simple operations like creating a wireless network, we never want to bother the user with PolicyKit prompts. On the other hand, granting every user the org.freedesktop.NetworkManager.settings.modify.system privilege (without authorization) might not be wanted in certain setups (like a shared laptop/computer use case). To address this we check in advance if the action would trigger a PolicyKit prompt and if that is the case fall back to user-owned connections where the secret is agent-owned. The logic is: - Bluetooth, CDMA and GSM connections: always user-owned - WEP/WPA connections: system-owned if user has the permissions, user-owned otherwise. - WiMax / Wired connections: always system-owned (with 802.1x passwords in the keyring). Distribution can still choose to override the PolicyKit configuration to grant all active users those provileges, or make that based on group memberships (like Debian does). --- src/applet-device-wifi.c| 25 + src/connection-editor/ce-page.h |1 + src/connection-editor/new-connection.c |2 ++ src/connection-editor/page-bond.c |1 + src/connection-editor/page-bond.h |1 + src/connection-editor/page-bridge.c |1 + src/connection-editor/page-bridge.h |1 + src/connection-editor/page-dsl.c|1 + src/connection-editor/page-dsl.h|1 + src/connection-editor/page-ethernet.c |1 + src/connection-editor/page-ethernet.h |1 + src/connection-editor/page-infiniband.c |1 + src/connection-editor/page-infiniband.h |1 + src/connection-editor/page-mobile.c | 11 +++ src/connection-editor/page-mobile.h |1 + src/connection-editor/page-vlan.c |1 + src/connection-editor/page-vlan.h |1 + src/connection-editor/page-vpn.c| 10 ++ src/connection-editor/page-vpn.h|1 + src/connection-editor/page-wifi.c | 14 ++ src/connection-editor/page-wifi.h |1 + src/connection-editor/page-wimax.c |1 + src/connection-editor/page-wimax.h |1 + src/gnome-bluetooth/nma-bt-device.c |5 + src/libnm-gtk/nm-wifi-dialog.c |4 src/mobile-helpers.c|3 +++ src/utils/utils.c |7 +++ src/utils/utils.h |3 +++ src/wireless-security/ws-wep-key.c |7 +++ src/wireless-security/ws-wpa-psk.c |5 + 30 files changed, 114 insertions(+) diff --git a/src/applet-device-wifi.c b/src/applet-device-wifi.c index fa3d618..d4c8773 100644 --- a/src/applet-device-wifi.c +++ b/src/applet-device-wifi.c @@ -404,6 +404,7 @@ _do_new_auto_connection (NMApplet *applet, NMSettingWirelessSecurity *s_wsec = NULL; NMSetting8021x *s_8021x = NULL; const GByteArray *ssid; + NM80211ApFlags flags; NM80211ApSecurityFlags wpa_flags, rsn_flags; GtkWidget *dialog; M
Re: Possible GSOC project ideas
On 25.02.2013 09:25, todd rme wrote: >>> >>> 3. Implement auto-detection of connection status. >> >> This is already supported roughly in a way you are describing it below. > > It is? I have tried connecting under these circumstances and nothing > remotely like this happened. See man NetworkManager.conf section [connectivity] Your NM package must have been built with connectivity support enabled. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9.10 requirements: glib 2.32, gtk 3.4? (and no gtk2)
On 18.02.2013 22:53, Dan Winship wrote: > For 0.9.10 (expected sometime May-ish), we'd like to bump up the > required versions of some NM dependencies to start taking advantage of > assorted new awesomeness (eg, GDBus). > > We're currently eyeing glib 2.32, and the corresponding gtk release > would be 3.4. Anyone got a problem with those? > Fine with me (with my Debian maintainer hat on). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dropping support for libnl1 and libnl2?
On 06.12.2012 19:11, Dan Williams wrote: > > So, given that libnl 3.2.7 has been out for almost a year (2012-01-20), > and most major distros are packaging it (Ubuntu, OpenSUSE, Debian, > Fedora, Gentoo, Arch), would anyone object to libnl >= 3.2.7 as a build > requirement for the next release of NetworkManager? With my Debian maintainer hat on: go for it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Debian testing + MM 0.5.2 + Huawei
On 19.05.2012 18:35, PongráczI wrote: > /modem-manager: symbol lookup error: > /usr/lib/ModemManager/libmm-plugin-cinterion.so: undefined symbol: > mm_plugin_base_supports_task_propagate_cached > [Inferior 1 (process 6110) exited with code 0177] /usr/lib/ModemManager/libmm-plugin-cinterion.so is not part of the Debian modemmanager package. Is this a local build/modification? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet as normal user + debian + fluxbox + slim
On 16.02.2012 22:28, PongráczI wrote: > > Hi, > > I have an issue with nm-applet, I am not able to enable/setup network > (openvpn), due to that, the user has no rights to modify/enable configs. > > I have to sudo root to setup the network (mobile broadband, vpn). > > I found a lot of stuff on the internet, it seems a common issue when one use > Slim and other WM than gnome. > > I already solved the keyring read, but I am not able to step further to solve > this issue. I tried several tricks, spent hours/days to read and try to fix > it, but all of them are failed, no solution. > > Due to that, I need automatic things with normal user, my goal is to to use > and control all the network settings with this user, instead of sudo. Anyway, > root has no keyring, so, I am not able to store password, it is not possible > to start openvpn in this case. > > I keep the right to be a complete idiot, so, it is possible, I am the > problem, but I would appreciate if you could send me hints or links if you > know the "solution", where I can find solution for this. > Check with ck-list-sessions, if your session is marked as active. The slim login manager is one of the known ones which doesn't have builting ConsoleKit support, which is used by PolicyKit to determine if a user may allow to execute certain actions. Personally, if you want a lightweight login manager, I'd suggest you use lightdm. Other display managers with ConsoleKit support are gdm and kdm. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor working only as root
Am 06.11.2011 14:39, schrieb Ramon Diaz-Uriarte: > > Yes, I do have polkit-gnome-authentication-agent-1 in > /usr/lib/policykit-1-gnome/ ... > > No, I never see a PolicyKit authentication dialog. However, in case it > matters, I do have the daemon running: > > > ramon@Bufo:~$ ps -A -f | grep polkit > root 1487 1 0 12:00 ?00:00:01 /usr/lib/policykit-1/polkitd > That's your problem, I guess. You not only need polkitd daemon running, but you also need a "PolicyKit authentication agent" in your user session, which is responsible for show the authentication dialogs. Such a service is e.g. provided by gnome-shell (if you use GNOME 3), by kdebase-workspace (if you use KDE) or polkit-gnome-authentication-agent-1 (from policykit-1-gnome). The policykit-1-gnome package uses an xdg autostart file. Most likely your xmonad WM does not read that autostart files, so you need to start /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 manually. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor working only as root
Am 21.10.2011 21:14, schrieb Ramon Diaz-Uriarte: > > > On Fri, 21 Oct 2011 16:42:52 +0200,Michael Biebl wrote: >> Am 21.10.2011 13:44, schrieb Ramon Diaz-Uriarte: > >> What's the output of ck-list-sessions? > > > Session5: > active = FALSE > is-local = FALSE That's your problem. Use a login manager, like gdm or kdm, which properly registers a ConsoleKit session. Otherwise the PolicyKit rules used by NM won't work. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor working only as root
Am 21.10.2011 13:44, schrieb Ramon Diaz-Uriarte: > > Dear All, > > I just upgraded to version 0.9 of network manager and the > nm-connection-editor (running Debian). Since the upgrade: What's the output of ck-list-sessions? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] docs/Makefile.am: use `WITH_DOCS_TRUE` to fix `--with-docs=no`
Am 08.05.2011 12:32, schrieb Paul Menzel: > Date: Sun, 8 May 2011 12:26:06 +0200 > > Although passing `--with-docs=no` to `configure` the build system still tries > to include `gtk-doc.make`. > gtk-doc should always be included, even if the documentation is not built. Otherwise you could end up with a non-functional release tarball. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.997 (0.9.0-beta3)
Am 20.03.2011 11:10, schrieb Michael Biebl:
> Am 20.03.2011 02:47, schrieb Michael Biebl:
>> Am 19.03.2011 20:16, schrieb Dan Williams:
>>> VPN plugins to follow. Thanks to everyone so far for their testing,
>>> lets keep at it til we're done. Areas of interest are WiFi scanning
>>
>> A few issues I found while testing the 0.8.997 tarball (on Debian sid, GCC
>> 4.5,
>> i386)
>>
>> 1/ it fails to build with --enable-more-warnings (due to -Werror)
>>
>> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include
>> -I../../marshallers -I../../src/logging -I../../libnm-util -I../../src
>> -pthread
>> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include -DG_DISABLE_DEPRECATED
>> -DLIBEXECDIR=\"/usr/local/libexec\" -DLOCALSTATEDIR=\"/usr/local/var\"
>> -DDHCLIENT_PATH=\"/sbin/dhclient\" -DDHCPCD_PATH=\"\" -Wall -Werror
>> -std=gnu89
>> -g -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes
>> -Wdeclaration-after-statement -Wfloat-equal -Wno-unused-parameter
>> -Wno-sign-compare -fno-strict-aliasing -Wno-unused-but-set-variable -MT
>> libdhcp_manager_la-nm-dhcp-manager.lo -MD -MP -MF
>> .deps/libdhcp_manager_la-nm-dhcp-manager.Tpo -c nm-dhcp-manager.c -fPIC
>> -DPIC
>> -o .libs/libdhcp_manager_la-nm-dhcp-manager.o
>> cc1: warnings being treated as errors
>> nm-dhcp-manager.c: In function 'nm_dhcp_manager_handle_event':
>> nm-dhcp-manager.c:238:3: error: format '%zd' expects type 'signed size_t',
>> but
>> argument 6 has type 'long unsigned int'
>> nm-dhcp-manager.c:243:3: error: format '%zd' expects type 'signed size_t',
>> but
>> argument 6 has type 'long unsigned int'
>> nm-dhcp-manager.c:250:3: error: format '%zd' expects type 'signed size_t',
>> but
>> argument 6 has type 'long unsigned int'
>> At top level:
>> cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"
>> make[5]: *** [libdhcp_manager_la-nm-dhcp-manager.lo] Error 1
>> make[5]: Leaving directory `/tmp/NetworkManager-0.8.997/src/dhcp-manager'
>>
>
> "faulty" commit is d815cb9f33ce1aba7b570343caa27d95f014a074
Well, not faulty really, just stricter format checking causing the build
failure.
As temp is of unsigned long, I changed src/dhcp-manager/nm-dhcp-manager.c to
use %lu.
For printf() time_t in src/ip6-manager/nm-ip6-manager.c , I followed
http://lists.freebsd.org/pipermail/freebsd-ports/2006-January/028656.html
Patch attached
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From d86a7210147b11808f3df2d84c02446a18cc36d4 Mon Sep 17 00:00:00 2001
From: Michael Biebl
Date: Sun, 20 Mar 2011 12:05:50 +0100
Subject: [PATCH] logger: printf formatting fixes
For printf() time_t see
http://lists.freebsd.org/pipermail/freebsd-ports/2006-January/028656.html
---
src/dhcp-manager/nm-dhcp-manager.c |6 +++---
src/ip6-manager/nm-ip6-manager.c | 16
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/dhcp-manager/nm-dhcp-manager.c b/src/dhcp-manager/nm-dhcp-manager.c
index 8e2392d..23dc3d0 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -235,19 +235,19 @@ nm_dhcp_manager_handle_event (DBusGProxy *proxy,
client = get_client_for_pid (manager, (GPid) temp);
if (client == NULL) {
- nm_log_warn (LOGD_DHCP, "(pid %zd) unhandled DHCP event for interface %s", temp, iface);
+ nm_log_warn (LOGD_DHCP, "(pid %lu) unhandled DHCP event for interface %s", temp, iface);
goto out;
}
if (strcmp (iface, nm_dhcp_client_get_iface (client))) {
- nm_log_warn (LOGD_DHCP, "(pid %zd) received DHCP event from unexpected interface '%s' (expected '%s')",
+ nm_log_warn (LOGD_DHCP, "(pid %lu) received DHCP event from unexpected interface '%s' (expected '%s')",
temp, iface, nm_dhcp_client_get_iface (client));
goto out;
}
reason = get_option (options, "reason");
if (reason == NULL) {
- nm_log_warn (LOGD_DHCP, "(pid %zd) DHCP event didn't have a reason", temp);
+ nm_log_warn (LOGD_DHCP, "(pid %lu) DHCP event didn't have a reason", temp);
goto out;
}
diff --git a/src/ip6-manager/nm-ip6-manager.c b/src/ip6-manager/nm-ip6-manager.c
index c158496..53a21de 100644
--- a/src/ip6-manager/nm-ip6-manager.c
+++ b/src/ip6-manager/nm-ip6-manager.c
@@ -701,9 +701,9 @@ process_nduseropt_
Re: ANN: Release of NetworkManager 0.8.997 (0.9.0-beta3)
Am 20.03.2011 02:47, schrieb Michael Biebl: > Am 19.03.2011 20:16, schrieb Dan Williams: >> VPN plugins to follow. Thanks to everyone so far for their testing, >> lets keep at it til we're done. Areas of interest are WiFi scanning > > A few issues I found while testing the 0.8.997 tarball (on Debian sid, GCC > 4.5, > i386) > > 1/ it fails to build with --enable-more-warnings (due to -Werror) > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include > -I../../marshallers -I../../src/logging -I../../libnm-util -I../../src > -pthread > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -DG_DISABLE_DEPRECATED > -DLIBEXECDIR=\"/usr/local/libexec\" -DLOCALSTATEDIR=\"/usr/local/var\" > -DDHCLIENT_PATH=\"/sbin/dhclient\" -DDHCPCD_PATH=\"\" -Wall -Werror -std=gnu89 > -g -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes > -Wdeclaration-after-statement -Wfloat-equal -Wno-unused-parameter > -Wno-sign-compare -fno-strict-aliasing -Wno-unused-but-set-variable -MT > libdhcp_manager_la-nm-dhcp-manager.lo -MD -MP -MF > .deps/libdhcp_manager_la-nm-dhcp-manager.Tpo -c nm-dhcp-manager.c -fPIC -DPIC > -o .libs/libdhcp_manager_la-nm-dhcp-manager.o > cc1: warnings being treated as errors > nm-dhcp-manager.c: In function 'nm_dhcp_manager_handle_event': > nm-dhcp-manager.c:238:3: error: format '%zd' expects type 'signed size_t', but > argument 6 has type 'long unsigned int' > nm-dhcp-manager.c:243:3: error: format '%zd' expects type 'signed size_t', but > argument 6 has type 'long unsigned int' > nm-dhcp-manager.c:250:3: error: format '%zd' expects type 'signed size_t', but > argument 6 has type 'long unsigned int' > At top level: > cc1: error: unrecognized command line option "-Wno-unused-but-set-variable" > make[5]: *** [libdhcp_manager_la-nm-dhcp-manager.lo] Error 1 > make[5]: Leaving directory `/tmp/NetworkManager-0.8.997/src/dhcp-manager' > "faulty" commit is d815cb9f33ce1aba7b570343caa27d95f014a074 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: build system related issues
Am 20.03.2011 10:45, schrieb Michael Biebl: > Am 20.03.2011 10:39, schrieb Michael Biebl: >> 2/ We should only ship the input files for the SysV init scripts in the >> tarball, >> not the generated files. Patch attached. > > Looking at this a second time, given that all init scripts are generated via > AC_CONFIG_FILES(), there is not point really adding > > EXTRA_DIST = foo.in > DISTCLEANFILES = foo > > in initscript/*/Makefile.am. This can be dropped. Updated patch attached -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From abe72573b1ae8eee8fc1fcad5221cc7b4b40e401 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Sun, 20 Mar 2011 10:23:02 +0100 Subject: [PATCH] Only ship input files for SysV init scripts in dist tarball And let AC_CONFIG_FILES() take care of including them --- initscript/Arch/Makefile.am |3 --- initscript/Debian/Makefile.am|3 --- initscript/Gentoo/Makefile.am|3 --- initscript/Mandriva/Makefile.am |3 --- initscript/RedHat/Makefile.am|3 --- initscript/SUSE/Makefile.am |3 --- initscript/Slackware/Makefile.am |3 --- initscript/linexa/Makefile.am|3 --- initscript/paldo/Makefile.am |3 --- 9 files changed, 0 insertions(+), 27 deletions(-) diff --git a/initscript/Arch/Makefile.am b/initscript/Arch/Makefile.am index 2c1f8b5..98d4343 100644 --- a/initscript/Arch/Makefile.am +++ b/initscript/Arch/Makefile.am @@ -1,5 +1,2 @@ -EXTRA_DIST = networkmanager -DISTCLEANFILES = networkmanager - initddir = $(sysconfdir)/rc.d initd_SCRIPTS = networkmanager diff --git a/initscript/Debian/Makefile.am b/initscript/Debian/Makefile.am index 890ed77..a735645 100644 --- a/initscript/Debian/Makefile.am +++ b/initscript/Debian/Makefile.am @@ -1,5 +1,2 @@ -EXTRA_DIST = NetworkManager.in -DISTCLEANFILES = NetworkManager - initddir = $(sysconfdir)/init.d initd_SCRIPTS = NetworkManager diff --git a/initscript/Gentoo/Makefile.am b/initscript/Gentoo/Makefile.am index af023b7..a735645 100644 --- a/initscript/Gentoo/Makefile.am +++ b/initscript/Gentoo/Makefile.am @@ -1,5 +1,2 @@ -EXTRA_DIST = NetworkManager -DISTCLEANFILES = NetworkManager - initddir = $(sysconfdir)/init.d initd_SCRIPTS = NetworkManager diff --git a/initscript/Mandriva/Makefile.am b/initscript/Mandriva/Makefile.am index 0a0cc2b..bdc9908 100644 --- a/initscript/Mandriva/Makefile.am +++ b/initscript/Mandriva/Makefile.am @@ -1,6 +1,3 @@ -EXTRA_DIST = networkmanager -DISTCLEANFILES = networkmanager - initddir = $(sysconfdir)/rc.d/init.d initd_SCRIPTS = networkmanager diff --git a/initscript/RedHat/Makefile.am b/initscript/RedHat/Makefile.am index 3f7b876..fc97ec4 100644 --- a/initscript/RedHat/Makefile.am +++ b/initscript/RedHat/Makefile.am @@ -1,6 +1,3 @@ -EXTRA_DIST = NetworkManager -DISTCLEANFILES = NetworkManager - initddir = $(sysconfdir)/rc.d/init.d initd_SCRIPTS = NetworkManager diff --git a/initscript/SUSE/Makefile.am b/initscript/SUSE/Makefile.am index 75a7c2a..4938e3e 100644 --- a/initscript/SUSE/Makefile.am +++ b/initscript/SUSE/Makefile.am @@ -1,6 +1,3 @@ -EXTRA_DIST = networkmanager.in -DISTCLEANFILES = networkmanager - # Nowadays, NetworkManager support is built-in to the SUSE networking # subsystem, therefore a SUSE machine does not want these scripts. Uncomment # this if you actually want external initscripts, such as SUSE 10.0 or earlier. diff --git a/initscript/Slackware/Makefile.am b/initscript/Slackware/Makefile.am index ded3ee0..254bb7a 100644 --- a/initscript/Slackware/Makefile.am +++ b/initscript/Slackware/Makefile.am @@ -1,6 +1,3 @@ -EXTRA_DIST = rc.networkmanager -DISTCLEANFILES = rc.networkmanager - initddir = $(sysconfdir)/rc.d initd_SCRIPTS = rc.networkmanager diff --git a/initscript/linexa/Makefile.am b/initscript/linexa/Makefile.am index 0a0cc2b..bdc9908 100644 --- a/initscript/linexa/Makefile.am +++ b/initscript/linexa/Makefile.am @@ -1,6 +1,3 @@ -EXTRA_DIST = networkmanager -DISTCLEANFILES = networkmanager - initddir = $(sysconfdir)/rc.d/init.d initd_SCRIPTS = networkmanager diff --git a/initscript/paldo/Makefile.am b/initscript/paldo/Makefile.am index 3d67ff6..2c1b196 100644 --- a/initscript/paldo/Makefile.am +++ b/initscript/paldo/Makefile.am @@ -1,6 +1,3 @@ -EXTRA_DIST = NetworkManager -DISTCLEANFILES = NetworkManager - initddir = $(sysconfdir)/init.d initd_SCRIPTS = NetworkManager -- 1.7.4.1 signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: build system related issues
Am 20.03.2011 10:39, schrieb Michael Biebl: > 2/ We should only ship the input files for the SysV init scripts in the > tarball, > not the generated files. Patch attached. Looking at this a second time, given that all init scripts are generated via AC_CONFIG_FILES(), there is not point really adding EXTRA_DIST = foo.in DISTCLEANFILES = foo in initscript/*/Makefile.am. This can be dropped. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
build system related issues
Am 19.03.2011 20:16, schrieb Dan Williams: > VPN plugins to follow. Thanks to everyone so far for their testing, > lets keep at it til we're done. 1/ The network-manager tarball has a build-aux directory, which contains compile config.guess config.rpath config.sub depcomp install-sh ltmain.sh missing The same file are also available in the root directory. This is 436K of duplicated data. build-aux is used because of AC_CONFIG_AUX_DIR([build-aux]). I haven't further investigated yet, if that macro does not work as expected. 2/ We should only ship the input files for the SysV init scripts in the tarball, not the generated files. Patch attached. 3/ introspection/nm-device-cdma.xml, nm-device-gsm.xml and src/nm-gsm-device.h are in Git, but not the tarball. This seems to be because of 2140dad5e0de0033e5c9bb10bd77ecd80085e5a3 Should those files be removed from Git? 4/ What is src/ppp-manager/nm-pppd-plugin.xml good for (in Git)? It doesn't seem to be used is not part of the dist tarball 5/ Missing tests/test files in tarball src/settings/plugins/ifcfg-rh/tests/iscsiadm-test-bad-entry src/settings/plugins/ifcfg-rh/tests/iscsiadm-test-bad-record test/add-connection.py (unused?) test/nm-dhcp-opt-test.c (unused?) test/nmnetlinktest.c (unused?) test/set-hostname.py (unused?) Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From b8645ed168998fd9a249b8e692ff85d76bef5f35 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Sun, 20 Mar 2011 10:23:02 +0100 Subject: [PATCH] Only ship input files for SysV init scripts in dist tarball Not the generated files. --- initscript/Arch/Makefile.am |2 +- initscript/Gentoo/Makefile.am|2 +- initscript/Mandriva/Makefile.am |2 +- initscript/RedHat/Makefile.am|2 +- initscript/Slackware/Makefile.am |2 +- initscript/linexa/Makefile.am|2 +- initscript/paldo/Makefile.am |2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/initscript/Arch/Makefile.am b/initscript/Arch/Makefile.am index 2c1f8b5..0be1bc2 100644 --- a/initscript/Arch/Makefile.am +++ b/initscript/Arch/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = networkmanager +EXTRA_DIST = networkmanager.in DISTCLEANFILES = networkmanager initddir = $(sysconfdir)/rc.d diff --git a/initscript/Gentoo/Makefile.am b/initscript/Gentoo/Makefile.am index af023b7..890ed77 100644 --- a/initscript/Gentoo/Makefile.am +++ b/initscript/Gentoo/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = NetworkManager +EXTRA_DIST = NetworkManager.in DISTCLEANFILES = NetworkManager initddir = $(sysconfdir)/init.d diff --git a/initscript/Mandriva/Makefile.am b/initscript/Mandriva/Makefile.am index 0a0cc2b..09277de 100644 --- a/initscript/Mandriva/Makefile.am +++ b/initscript/Mandriva/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = networkmanager +EXTRA_DIST = networkmanager.in DISTCLEANFILES = networkmanager initddir = $(sysconfdir)/rc.d/init.d diff --git a/initscript/RedHat/Makefile.am b/initscript/RedHat/Makefile.am index 3f7b876..347d0fa 100644 --- a/initscript/RedHat/Makefile.am +++ b/initscript/RedHat/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = NetworkManager +EXTRA_DIST = NetworkManager.in DISTCLEANFILES = NetworkManager initddir = $(sysconfdir)/rc.d/init.d diff --git a/initscript/Slackware/Makefile.am b/initscript/Slackware/Makefile.am index ded3ee0..8fce2cf 100644 --- a/initscript/Slackware/Makefile.am +++ b/initscript/Slackware/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = rc.networkmanager +EXTRA_DIST = rc.networkmanager.in DISTCLEANFILES = rc.networkmanager initddir = $(sysconfdir)/rc.d diff --git a/initscript/linexa/Makefile.am b/initscript/linexa/Makefile.am index 0a0cc2b..09277de 100644 --- a/initscript/linexa/Makefile.am +++ b/initscript/linexa/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = networkmanager +EXTRA_DIST = networkmanager.in DISTCLEANFILES = networkmanager initddir = $(sysconfdir)/rc.d/init.d diff --git a/initscript/paldo/Makefile.am b/initscript/paldo/Makefile.am index 3d67ff6..22d2e31 100644 --- a/initscript/paldo/Makefile.am +++ b/initscript/paldo/Makefile.am @@ -1,4 +1,4 @@ -EXTRA_DIST = NetworkManager +EXTRA_DIST = NetworkManager.in DISTCLEANFILES = NetworkManager initddir = $(sysconfdir)/init.d -- 1.7.4.1 signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
0.8.997 / vpn / crashes in nm-applet
Am 19.03.2011 20:16, schrieb Dan Williams:
> VPN plugins to follow. Thanks to everyone so far for their testing,
> lets keep at it til we're done. Areas of interest are WiFi scanning
> (making sure the APs you expect have reasonable signal strength) and
> connection editing.
vpn (pptp and vpnc) do not yet work reliably. With pptp I *sometimes* get a
connection, vpnc always files.
Worst of all nm-applet crashes regularly if I try to enable a vpn connection.
backtrace attached.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
(gdb) run
Starting program: /usr/bin/nm-applet
[Thread debugging using libthread_db enabled]
ignored.
** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area
[New Thread 0xa6971b70 (LWP 25576)]
Program received signal SIGSEGV, Segmentation fault.
0xb76cbb81 in free () from /lib/i686/cmov/libc.so.6
(gdb)
bt full
#0 0xb76cbb81 in free () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#1 0xb77ec4d6 in g_free (mem=0x5) at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./glib/gmem.c:263
No locals.
#2 0xb79a8f10 in activate_info_free (info=0x81b8bc0) at nm-client.c:577
No locals.
#3 0xb79ab1c1 in recheck_pending_activations (self=) at
nm-client.c:627
info = 0x81b8bc0
active = 0x82ea1f8
priv = 0x816a0d0
iter = 0x8274210
active_connections = 0x81b8c20
i =
#4 0xb78c1758 in g_cclosure_marshal_VOID__PARAM (closure=0x817c540,
return_value=0x0, n_param_values=2, param_values=0x82f1390,
invocation_hint=0xbfffede0, marshal_data=0x0) at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gmarshal.c:533
callback = 0xb79ab2d0
cc = 0x817c540
data1 =
data2 =
__PRETTY_FUNCTION__ = "g_cclosure_marshal_VOID__PARAM"
#5 0xb78a4a22 in g_closure_invoke (closure=0x817c540, return_value=0x0,
n_param_values=2, param_values=0x82f1390,
invocation_hint=0xbfffede0) at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gclosure.c:767
marshal = 0xb78c16d0
marshal_data = 0x0
in_marshal = 136023040
__PRETTY_FUNCTION__ = "g_closure_invoke"
#6 0xb78b79b8 in signal_emit_unlocked_R (node=0x80b7210, detail=1148,
instance=0x816a0a0, emission_return=0x0,
instance_and_params=0x82f1390) at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gsignal.c:3252
tmp =
handler = 0x8173f60
accumulator = 0x0
emission = {next = 0x0, instance = 0x816a0a0, ihint = {signal_id = 1,
detail = 1148, run_type = G_SIGNAL_RUN_FIRST},
state = EMISSION_RUN, chain_type = 4}
class_closure = 0x80b6b20
handler_list = 0x8173f40
return_accu = 0x0
accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong
= 0, v_int64 = 0, v_uint64 = 0, v_float = 0,
v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long =
0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0,
v_double = 0, v_pointer = 0x0}}}
signal_id = 1
max_sequential_handler_number = 366
return_value_altered = 1
#7 0xb78c0426 in g_signal_emit_valist (instance=0x816a0a0, signal_id=1,
detail=1148, var_args=0xbfffefa0 "\204\247\207\267")
at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gsignal.c:2983
instance_and_params = 0x82f1390
signal_return_type = 4
param_values = 0x82f13a4
node = 0x80b7210
i =
n_params = 1
__PRETTY_FUNCTION__ = "g_signal_emit_valist"
#8 0xb78c05d2 in g_signal_emit (instance=0x816a0a0, signal_id=1, detail=1148)
at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gsignal.c:3040
var_args = 0xbfffef9c "h\361\020\b\204\247\207\267"
#9 0xb78a67a1 in g_object_dispatch_properties_changed (object=0x816a0a0,
n_pspecs=1, pspecs=0xb030)
at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gobject.c:925
i =
#10 0xb78a5a9f in g_object_notify_dispatcher (object=0x816a0a0, n_pspecs=1,
pspecs=0xb030)
at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gobject.c:330
No locals.
#11 0xb78a8ab1 in g_object_notify_queue_thaw (object=0x816a0a0,
property_name=0x81707e0 "active-connections")
at
/build/buildd-glib2.0_2.28.2-1-i386-B7GzlY/glib2.0-2.28.2/./gobject/gobjectnotifyqueue.c:132
context = 0xb78df460
pspecs_mem = {0x810f168, 0x8, 0x18, 0xb7cff019, 0xb779f3a0, 0xb779dff4,
0x80abbb4, 0x80d2ac8, 0xb779f3a0, 0xb779dff4,
0xb088, 0xb79a7085, 0xb79ca9c4, 0xb76cbb00, 0x2, 0x1}
pspecs =
free_me = 0x0
slist =
n_pspecs =
#12 g_object_notify_by_spec_internal (object=0x816a0a0, property_name=0x81707e0
"active-connections")
at
/build/buildd-glib2.0_
Re: ANN: Release of NetworkManager 0.8.997 (0.9.0-beta3)
Am 19.03.2011 20:16, schrieb Dan Williams: > VPN plugins to follow. Thanks to everyone so far for their testing, > lets keep at it til we're done. Areas of interest are WiFi scanning A few issues I found while testing the 0.8.997 tarball (on Debian sid, GCC 4.5, i386) 1/ it fails to build with --enable-more-warnings (due to -Werror) libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../marshallers -I../../src/logging -I../../libnm-util -I../../src -pthread -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_DISABLE_DEPRECATED -DLIBEXECDIR=\"/usr/local/libexec\" -DLOCALSTATEDIR=\"/usr/local/var\" -DDHCLIENT_PATH=\"/sbin/dhclient\" -DDHCPCD_PATH=\"\" -Wall -Werror -std=gnu89 -g -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -fno-strict-aliasing -Wno-unused-but-set-variable -MT libdhcp_manager_la-nm-dhcp-manager.lo -MD -MP -MF .deps/libdhcp_manager_la-nm-dhcp-manager.Tpo -c nm-dhcp-manager.c -fPIC -DPIC -o .libs/libdhcp_manager_la-nm-dhcp-manager.o cc1: warnings being treated as errors nm-dhcp-manager.c: In function 'nm_dhcp_manager_handle_event': nm-dhcp-manager.c:238:3: error: format '%zd' expects type 'signed size_t', but argument 6 has type 'long unsigned int' nm-dhcp-manager.c:243:3: error: format '%zd' expects type 'signed size_t', but argument 6 has type 'long unsigned int' nm-dhcp-manager.c:250:3: error: format '%zd' expects type 'signed size_t', but argument 6 has type 'long unsigned int' At top level: cc1: error: unrecognized command line option "-Wno-unused-but-set-variable" make[5]: *** [libdhcp_manager_la-nm-dhcp-manager.lo] Error 1 make[5]: Leaving directory `/tmp/NetworkManager-0.8.997/src/dhcp-manager' 2/ make check fails for the python scripts This is because on Debian we use /usr/bin/env, not /bin/env. I've sent Dan a patch for this already 3/ building the documentation (--with-docs) fails to link in libnm-glib gtk-doc: Linking scanner libtool: link: gcc -g -O2 .libs/libnm-glib-scan.o -pthread -o .libs/libnm-glib-scan ../../libnm-glib/.libs/libnm-glib.so /tmp/NetworkManager-0.8.997/libnm-util/.libs/libnm-util.so -luuid -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -ldl -ldbus-glib-1 -ldbus-1 -lpthread -lgudev-1.0 /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread /usr/bin/ld: .libs/libnm-glib-scan.o: in function main:libnm-glib-scan.c:77: error: undefined reference to 'nm_vpn_plugin_error_get_type' /usr/bin/ld: .libs/libnm-glib-scan.o: in function main:libnm-glib-scan.c:78: error: undefined reference to 'nm_vpn_plugin_get_type' /usr/bin/ld: .libs/libnm-glib-scan.o: in function main:libnm-glib-scan.c:79: error: undefined reference to 'nm_vpn_plugin_ui_interface_get_type' /usr/bin/ld: .libs/libnm-glib-scan.o: in function main:libnm-glib-scan.c:80: error: undefined reference to 'nm_vpn_plugin_ui_widget_interface_get_type' collect2: ld returned 1 exit status Linking of scanner failed: make[3]: *** [scan-build.stamp] Error 1 make[3]: Leaving directory `/tmp/NetworkManager-0.8.997/docs/libnm-glib' It's interesting to note, that if I build directly from git and use autogen.sh, I don't get this link failures. Maybe this is related du to the fact that on Debian I have gtk-doc 1.17, whereas the buildsystem of the 0.8.997 tarballs seems to use gtk-doc 1.18. Haven't further investigated yet. 4/ soname of libnm-glib was bumped (I assume because of the removal of nm_ip4_config_get_hostname() Do you plan further changes to the API for 0.9? If so, only additions or also incompatible ones with further soname bumps? If you prefer separate bug reports for these issues, let me know. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
assertion failures in nm-applet (0.8.3.998)
Hi, I've been running 0.8.3.998 on a up-to-date Debian Sid system, using nm 0.8.3.998 and nm-applet 0.8.3.998. Kernel is 2.6.38, wireless card is ipw2200 When I click on the applet in the systray, I get a lot of those errors on my terminal where I started nm-applet from: (nm-applet:22292): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (nm-applet:22292): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (nm-applet:22292): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (nm-applet:22292): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (nm-applet:22292): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (nm-applet:22292): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer (nm-applet:22292): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (nm-applet:22292): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (nm-applet:22292): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (nm-applet:22292): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed Has anyone else seen similar warnings/error messages? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)
Am 11.03.2011 18:21, schrieb Dan Williams: > On Fri, 2011-03-11 at 09:49 +0100, Michael Biebl wrote: >> Am 10.03.2011 18:00, schrieb Dan Williams: >>> other VPN plugins may/may not follow depending on whether we find and >>> fix bugs. Thanks to everyone so far for their testing, lets keep at it >>> til we're done. >> >> Been testing the 0.8.996 packages. Looking quite ok so far. >> >> Some impressions: >> >> - Import of user settings worked fine when restarting nm-applet. >> >> - libnm-glib api doc contains invalid xml: Object Hierarchy, API Index and >> Glossary are not shown in the devhelp documentation. >> >> "public" and "private" system connections: >> private: permissions=user:michael:; is set >> public: no permissions settings, global to all users. > > I just uploaded new docs which should have some of these issues fixed. The still point to e.g. http://projects.gnome.org/NetworkManager/developers/libnm-glib/08/ and In libnm-util API Reference I get an after nm-utils — Utility functions >> >> - I can edit public system connections without authorization through >> policykit!!! > > org.freedesktop.NetworkManager.settings.modify.system now defaults to > "yes", but may be locked down on a per-user basis via PolicyKit. > Perhaps we should review that decision, but the core issue is that it > would be odd to require a user to authenticate to connect to a new WiFi > AP in a default install. If that were the case, you'd authenticate when > you clicked a new AP from an applet menu so you could create the > connection, and then you'd authenticate when you had to type the WPA-PSK > since that's also modifying a system connection. > > All connections are now system-wide by default, which is checked against > the org.freedesktop.NetworkManager.settings.modify.system permission. > System-wide-by-default was something that Ubuntu requested last year and > matches the behavior of other OSes as well. > > Or maybe we discuss this a bit? Ideas? What should the defaults be? At least system connections which were previously created with 0.8 and not readable by regular users without prior authorization, will need to be locked down. Otherwise you possibly leak sensible information, which I'd consider a security bug. For newly created connections the situation is different. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)
Am 11.03.2011 14:26, schrieb Mikhail Efremov: > On Fri, 11 Mar 2011 10:28:58 +0100 Michael Biebl wrote: >> Am 11.03.2011 09:49, schrieb Michael Biebl: >>> >>> Been testing the 0.8.996 packages. Looking quite ok so far. >>> >>> Some impressions: >>> >> >> The online/offline (D-Bus) API seems to be broken. >> firefox always starts in offline mode now when using >> toolkit.networkmanager.disable false > > Values of NM states have been changed. See commits ec115ed4 and > 11a68133. So all applications which uses that API should be rebuilded. > But firefox uses its own hardcoded constants (see > toolkit/system/dbus/nsNetworkManagerListener.cpp). I don't think NM should break that specific D-Bus API and be backwards compatible. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can not compile 0.8.4-beta3 - implicit declaration of function ‘g_key_file_get_uint64’
Am 11.03.2011 10:47, schrieb Thomas Bechtold: > Hi, > > i can not compile (on debian squeeze) the 0.8.4-beta3 version of NM. > > ... > cc1: warnings being treated as errors > nm-sysconfig-settings.c: In function ‘claim_connection’: > nm-sysconfig-settings.c:541: error: implicit declaration of function > ‘g_key_file_get_uint64’ > At top level: > cc1: error: unrecognized command line option "-Wno-unused-but-set-variable" > ... I think Dan fixed that already. See the NM_0_8 branch, especially aee725fe9f9fc956bd5a75a37ef1c7f2ca168702 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)
Am 11.03.2011 09:49, schrieb Michael Biebl: > > Been testing the 0.8.996 packages. Looking quite ok so far. > > Some impressions: > The online/offline (D-Bus) API seems to be broken. firefox always starts in offline mode now when using toolkit.networkmanager.disable false -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)
Am 11.03.2011 09:49, schrieb Michael Biebl: > Am 10.03.2011 18:00, schrieb Dan Williams: >> other VPN plugins may/may not follow depending on whether we find and >> fix bugs. Thanks to everyone so far for their testing, lets keep at it >> til we're done. > > Been testing the 0.8.996 packages. Looking quite ok so far. > > Some impressions: > > - Import of user settings worked fine when restarting nm-applet. > The imported VPN connections (VPNC/PPTP) did not work correctly. I get: NetworkManager[19188]: VPN connection 'PPTP-VPN' (Connect) reply received. NetworkManager[19188]: VPN connection 'PPTP-VPN' failed to connect: 'property 'password-flags' invalid or not supported'. NetworkManager[19188]: error disconnecting PPTP-VPN: Could not process the request because no VPN connection was active. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)
Am 11.03.2011 09:49, schrieb Michael Biebl: > - I can edit public system connections without authorization through > policykit!!! I.e. system connections that were created with 0.8 and required authorization are now editable for everyone. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)
Am 10.03.2011 18:00, schrieb Dan Williams: > other VPN plugins may/may not follow depending on whether we find and > fix bugs. Thanks to everyone so far for their testing, lets keep at it > til we're done. Been testing the 0.8.996 packages. Looking quite ok so far. Some impressions: - Import of user settings worked fine when restarting nm-applet. - libnm-glib api doc contains invalid xml: Object Hierarchy, API Index and Glossary are not shown in the devhelp documentation. "public" and "private" system connections: private: permissions=user:michael:; is set public: no permissions settings, global to all users. - nm-connection-editor does not yet correctly distinguish between system settings available to all users and "private" system settings available only to the user. For all connections, the Edit button says that it needs authorization, even if this is not true, and the "available to all users" checkbox is also set for every connection, even the private ones. - I can edit public system connections without authorization through policykit!!! - nm-applet does not show the correct signal strength, see attached screenshot. Might be a NM issue though, as nm-tool lists either Strength 1 or 2 for those wireless networks, which is clearly wrong. (I'm using wpasupplicant 0.7.3 + the BSS events patch) Hope this is useful. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? <> signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: One the road to 0.9 - release of 0.8.995 (0.9.0-beta1)
Am 07.03.2011 07:11, schrieb Michael Biebl: > Will report back when I encounter > any other issues. Looks like all user defined connections have been "forgotten", they are neither shown anymore by nm-connection-editor nor nm-applet. It would be cool, if nm-applet would automatically convert/import old user settings into new system connections. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: One the road to 0.9 - release of 0.8.995 (0.9.0-beta1)
Am 05.03.2011 07:48, schrieb Dan Williams: > > Any and all testing, patches, comments, etc, greatly appreciated. Lets > get 0.9 out soon! Looks like 0.8.995 does not contain the changes of 0.8.4, which moved the timestamps to /var/lib/NetworkManager. I've been compiling on Debian unstable (using gtk2) and it runs fine so far. I already sent you two build related fixes. Will report back when I encounter any other issues. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] dnsmasq: fix sending the conf-file parameter to dnsmasq
Hi! Am 26.02.2011 03:19, schrieb Mathieu Trudel-Lapierre: > Hi, > > Please see the attached patch. It fixes an issue reported downstream on > https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/725041 > > dnsmasq, starting in version 2.56, expects parameters requiring > arguments to have the arguments "attached" to them with an =. This > makes dnsmasq fail on startup when loading a connection in internet > sharing mode. See the discussion at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615082 with dnsmasq upstream. It seems the way to fix this is to stop making up a random, bogus file name and just pass --conf-file without arguments to dnsmasq. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can not build NM 0.8.4 on debian squeeze
Am 24.02.2011 19:28, schrieb toabctl: > Hi, > > NM 0.8.4 can't be build on debian squeeze because squeeze has glib > 2.24 and NM needs 2.26 because it uses G_DEFINE_BOXED_TYPE() which was > introduced in 2.26. [..] > Is there any way to build NM 0.8.4 on debian squeeze? Either the source is changed, to compile with older glib versions or the configure check for glib2 should be bumped. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Device removal not detected
On 21.01.2011 19:22, Dan Williams wrote: > On Thu, 2011-01-20 at 10:55 +0100, Michael Biebl wrote: >> On 19.01.2011 07:42, toabctl wrote: >>> Hi, >>> >>> i use networ-manager 0.8.1 (from debian squeeze) and when i remove a usb >>> wlan stick, the device removal is not shown in the nm-applet. any ideas why? > > I think you want: > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=608783c5b773a30139158ef3b00c211dcc255ee8 > > if you don't already have it backported. Thanks, that did it. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Device removal not detected
On 19.01.2011 07:42, toabctl wrote: > Hi, > > i use networ-manager 0.8.1 (from debian squeeze) and when i remove a usb > wlan stick, the device removal is not shown in the nm-applet. any ideas why? Hm, seem like I can reproduce that. If I run rmmod 8139cp, NM doesn't recognize the hotplug device removal. When restarting NM it correctly sees the device as removed. The only hint I found in the logs is: # rmmod 8139cp Jan 20 10:53:10 pluto NetworkManager[755]:SCPlugin-Ifupdown: devices removed (path: /sys/devices/pci:00/:00:1e.0/:02:01.0/net/eth0, iface: eth0) # modprobe 8139cp Jan 20 10:54:11 pluto NetworkManager[755]: (eth0): carrier is OFF Jan 20 10:54:11 pluto NetworkManager[755]:SCPlugin-Ifupdown: devices added (path: /sys/devices/pci:00/:00:1e.0/:02:01.0/net/eth0, iface: eth0) Jan 20 10:54:11 pluto NetworkManager[755]:SCPlugin-Ifupdown: device added (path: /sys/devices/pci:00/:00:1e.0/:02:01.0/net/eth0, iface: eth0): no ifupdown configuration found. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager-0.8.2 keyfile syslog spam
On 14.01.2011 19:44, Dan Williams wrote: > First thought is an sqlite database of connection timestamps for system > connections so that we don't have to write them out, but some places > don't have/want sqlite and thus a more generic solution is a better one. Given the size and the ubiquity of sqlite, I'd say it is a safe choice. Even aptitude (a dpkg/apt frontend) uses sqlite in Debian and with a default gnome installation sqlite is guaranteed to be installed. Where do you think would sqlite be a problem? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and pm-utils sleep hook
On 11.01.2011 20:03, Dan Williams wrote: > On Sat, 2010-12-18 at 10:01 -0600, Robby Workman wrote: >> Hi Dan, >> >> Re this commit: >> >> commit 8310593ce48a85aa82d4a2adf805662f2b019ef5 >> Author: Dan Williams >> Date: Fri Oct 15 10:28:38 2010 -0500 >> >> core: ignore authorization for sleep/wake requests (but restrict to >> root) (rh #638640) >> >> Everyone uses pm-utils still for sleep/wake support, and that's >> traditionally how NM was put to sleep and woken up. But pm-utils >> uses dbus-send without --print-reply so dbus-send quits immediately >> after sending the message. That doesn't give NM enough time to >> get the senders UID and thus validate the request, so the request >> gets denied, and sometimes NM stays asleep after the machine is >> woken up. >> >> Instead, don't get the sender's UID and try to authorize it, but >> just let the request go through. Rely on D-Bus permissions to >> make sure that only root can call sleep/wake methods. >> >> Why not have NM ship the pm-utils sleep hook instead of having to >> work around what they ship? Last I checked, NM is the only app >> for which upstream pm-utils ships a sleep hook, and Victor (the >> lead dev there) was hoping to have apps ship their own so that >> he didn't have to maintain stuff that he may not be familiar with. > > I'm happy to ship the hooks in NM. I've talked about doing that for a > couple years already, it's just never happened :) Just put them into NM and I make sure the next pm-utils upstream release has those hooks removed (I have commit rights for pm-utils). If you want to make sure NM also works with oder pm-utils versions, you can do a neat trick: Run "disablehook 55NetworkManager" in your hook and install it as say 50NetworkManager. On the other hand, I can also just add the --print-reply option to upstream pm-utils. Just let me know what you prefer. FWIW, this change had an unfortunate side-effect, when root is looged in and the at_console policy is used, see [1] Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608301 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration?
Am 07.01.2011 17:13, schrieb Uwe Geuder: > > On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: > > - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1 > > - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf > (I'm willing to share the patch if anybody is interested. I haven't > done so, because it's not 100% perfect, see below) > > - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never > be changed (*) Or you can simply install resolvconf + dnsmasq without any patching. Should basically work the same way: /etc/resolv.conf contains 127.0.0.1 and remains static. NM pushes DNS updates to resolvconf, which in turn pushes those updates to dnsmasq. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/2] ifupdown: Correctly mark unmanaged devices
See attached patch for details.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From fc86ba3b0c7d403defb3014ed5f1e1f745e4c8fc Mon Sep 17 00:00:00 2001
From: Michael Biebl
Date: Mon, 6 Dec 2010 18:57:50 +0100
Subject: [PATCH 1/2] ifupdown: Correctly mark unmanaged devices
If we find a "iface ..." line, add the interface to
well_known_interfaces no matter if there is a connection for it or not.
Otherwise we fail to mark devices as unmageded in cases like
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
as NM does not know how to parse such a interface configuration.
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569215
---
system-settings/plugins/ifupdown/plugin.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/system-settings/plugins/ifupdown/plugin.c b/system-settings/plugins/ifupdown/plugin.c
index 33c058e..7daa06a 100644
--- a/system-settings/plugins/ifupdown/plugin.c
+++ b/system-settings/plugins/ifupdown/plugin.c
@@ -368,6 +368,7 @@ SCPluginIfupdown_init (NMSystemConfigInterface *config)
/* Remove any connection for this block that was previously found */
exported = g_hash_table_lookup (priv->iface_connections, block->name);
if (exported) {
+PLUGIN_PRINT("SCPlugin-Ifupdown", "deleting %s from iface_connections", block->name);
nm_settings_connection_interface_delete (NM_SETTINGS_CONNECTION_INTERFACE (exported),
ignore_cb,
NULL);
@@ -377,11 +378,14 @@ SCPluginIfupdown_init (NMSystemConfigInterface *config)
/* add the new connection */
exported = nm_ifupdown_connection_new (block);
if (exported) {
+PLUGIN_PRINT("SCPlugin-Ifupdown", "adding %s to iface_connections", block->name);
g_hash_table_insert (priv->iface_connections, block->name, exported);
-g_hash_table_insert (priv->well_known_interfaces, block->name, "known");
}
+ PLUGIN_PRINT("SCPlugin-Ifupdown", "adding iface %s to well_known_interfaces", block->name);
+ g_hash_table_insert (priv->well_known_interfaces, block->name, "known");
} else if (!strcmp ("mapping", block->type)) {
g_hash_table_insert (priv->well_known_interfaces, block->name, "known");
+ PLUGIN_PRINT("SCPlugin-Ifupdown", "adding mapping %s to well_known_interfaces", block->name);
}
block = block->next;
}
--
1.7.2.3
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/2] ifupdown: Allow to mark bridge ports as unmanaged
See attached patch
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From e793f03ae85dd14e7b4b07a5929938b5800bb3bf Mon Sep 17 00:00:00 2001
From: Michael Biebl
Date: Mon, 6 Dec 2010 19:03:09 +0100
Subject: [PATCH 2/2] ifupdown: Allow to mark bridge ports as unmanaged
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Parse bridge configurations in /etc/network/interfaces and add
interfaces defined via bridge_ports to well_known_interfaces. This
allows to mark those interfaces as unmanaged if managed=false.
The "all" keyword and regexes are not supported and simply skipped.
Example:
iface br0 inet manual
bridge_ports eth0 eth1 (â eth0/1 will be marked as unmanaged)
See also:
http://manpages.ubuntu.com/manpages/maverick/man5/bridge-utils-interfaces.5.html
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530335
---
system-settings/plugins/ifupdown/plugin.c | 43 -
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/system-settings/plugins/ifupdown/plugin.c b/system-settings/plugins/ifupdown/plugin.c
index 7daa06a..476cf95 100644
--- a/system-settings/plugins/ifupdown/plugin.c
+++ b/system-settings/plugins/ifupdown/plugin.c
@@ -362,9 +362,49 @@ SCPluginIfupdown_init (NMSystemConfigInterface *config)
while (block) {
if(!strcmp ("auto", block->type) || !strcmp ("allow-hotplug", block->type))
g_hash_table_insert (auto_ifaces, block->name, GUINT_TO_POINTER (1));
- else if (!strcmp ("iface", block->type) && strcmp ("lo", block->name)) {
+ else if (!strcmp ("iface", block->type)) {
NMIfupdownConnection *exported;
+ /* Bridge configuration */
+ if(!strncmp ("br", block->name, 2)) {
+/* Try to find bridge ports */
+const char *ports = ifparser_getkey (block, "bridge_ports");
+if (ports) {
+ PLUGIN_PRINT("SCPlugin-Ifupdown", "found bridge ports %s for %s", ports, block->name);
+ char **port_ifaces = g_strsplit_set (ports, " \t", -1);
+
+ int i;
+ int state = 0;
+ for (i = 0; i < g_strv_length (port_ifaces); i++) {
+ char *token = port_ifaces[i];
+ /* Skip crazy stuff like regex or all */
+ if (!strcmp ("all", token)) {
+ continue;
+ }
+ /* Small SM to skip everything inside regex */
+ if (!strcmp ("regex", token)) {
+ state++;
+ continue;
+ }
+ if (!strcmp ("noregex", token)) {
+ state--;
+ continue;
+ }
+ if (state == 0 && strlen (token) > 0) {
+ PLUGIN_PRINT("SCPlugin-Ifupdown", "adding bridge port %s to well_known_interfaces", token);
+ g_hash_table_insert (priv->well_known_interfaces, g_strdup (token), "known");
+ }
+ }
+ g_strfreev (port_ifaces);
+}
+goto next;
+ }
+
+ /* Skip loopback configuration */
+ if(!strcmp ("lo", block->name)) {
+goto next;
+ }
+
/* Remove any connection for this block that was previously found */
exported = g_hash_table_lookup (priv->iface_connections, block->name);
if (exported) {
@@ -387,6 +427,7 @@ SCPluginIfupdown_init (NMSystemConfigInterface *config)
g_hash_table_insert (priv->well_known_interfaces, block->name, "known");
PLUGIN_PRINT("SCPlugin-Ifupdown", "adding mapping %s to well_known_interfaces", block->name);
}
+ next:
block = block->next;
}
--
1.7.2.3
signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager 0.8.1-beta2 does not work with isc dhcp-clients 3.1.3 and 4.1.1
On 30.05.2010 11:38, Thomas Schmidt wrote: > Hi, > > i am currently testing the beta2 of network-manager 0.8.1 on my Debian > Testing system, which has the isc dhcp3-client 3.1.3 installed by > default. > > The new network-manager seems to use some commandline options for > calling the dhcp-client which are not available in version 3.1.3 because > i can see the following in the syslog: > NM 0.8.1 requires ISC dhcp-client with DHCPv6 support enabled. The isc-dhcp package from experimental has DHCPv6 support disabled, due to build failures in the past, which have been sorted out in 4.1.1. Hopefully Andrew finds the time to upload a new version with DHCPv6 support enabled (I CCed just in case). Not sure if he still plans to upload isc-dhcp 4.x to unstable so it has a chance to get into squeeze. Of course I would prefer to have a newer dhcp version in Debian (and Ubuntu fwiw), on the other hand if NM 0.8.1 could safely fall back to not use dhcpv6 if older dhclient versions are detected, it would be even better. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549060 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager 0.8.1-beta2 does not work with isc dhcp-clients 3.1.3 and 4.1.1
On 30.05.2010 20:24, Michael Biebl wrote: > > NM 0.8.1 requires ISC dhcp-client with DHCPv6 support enabled. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549060 To clarify that: If ISC dhcp is compiled with --enable-dhcpv6, it gets a few new commandline options. Comparing the output of dhclient --help, those seem to be: -4 -6 -S -N -T -P Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM starts disabled after system crash (hard power off)
Am 10.03.2010 18:33, schrieb Andrey Borzenkov: > Unfortunately, I still experience occasional lockups which require me to > press power off button. What I find annoying - NM consistently comes up > disabled after this. Simple "cnetworkmanager -o yes" is enough, but I am > curious - why? Is it intentional design decision or should it be > considered a bug? How NM decides it should be disabled in the first > place? It's a bug. When you are going into suspend state, pm-utils will send NM a signal to disable all interfaces. This state is written to /var/lib/NetworkManager/NetworkManager.state. Upon (successful) resume, pm-utils will tell NM again, to reenable all devices. If your system crashes on resume, NetworkManager.state will contain stale information. Iirc, Dan proposed to solve this, using two different kind of disabled states: user initiated (which should be preserved on reboots) and automatic/system state. The latter could probably simply be put into /var/run, which would ensure it is cleaned up on boot. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
