Re: [PATCH 1/1] start after systemd-networkd
25.11.2015 18:11, Thomas Haller пишет: > On Wed, 2015-11-25 at 15:36 +0100, Christian Hesse wrote: >> Thomas Haller on Wed, 2015/11/25 15:11: >>> On Wed, 2015-11-25 at 11:53 +0100, Christian Hess wrote: 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. > > > (does networkd rename device? I'd think that is be done by udev). > That's correct. Interfaces are renamed by udev, not by systemd-networkd. They share configuration files (foo.link) but NamePolicy part is interpreted by udev only. signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MC 7304 ipv4v6
Thomas Schäfer writes: > Am 25.11.2015 um 11:12 schrieb Bjørn Mork: >> Bjørn Mork writes: >> >>> But I believe I implemented it the last time this was discussed. I'll >>> see if I can dig up the old code for a demo. Not going to rush this >>> anyway. I'd like everyone to be happy with the result. And it's going >>> to be immutable once it's in. >> >> git is a wonderful tool. Nothing is ever lost :) >> >> I found my example code in an old v3.2 based branch, and turned it into >> a demo on the bus to job. Note that this requires a minor change to >> usbnet.c as well, to prevent it from doing eth_type_trans() on the rx >> skbs we pass on to it. Therefore two, eh.. three, patches. >> > > > You are so fast. :-) > > > Some questions to your detailed solution and the invitation to test. > > > I need a very recent kernel (I have seen 4.4 in patch 003)? It will probably apply to older versions as well. There hasn't been that many changes to the qmi_wwan driver. Yes, I currently use v4.4-rcX. But that is primarily because I have found running a recent release candidate to be the best way to eliminate bugs affecting me, not because it's necessary for this testing. I don't know if I'm just lucky, but there tend to be one or two bugs like that in each release cycle. The one making cdc_mbim crash with EM7305, or any other Sierra MBIM device except for the MC74xx, is one current and nasty example. I believe it's good to avoid releasing with bugs like that... So I risk my file systems running release candidates. > I need to follow your instructions (why do you use sometimes ifconfig > instead of ip ?) Arbitray choice made by fingers with no brain involvement. Sort of like DMA :) > - with ModemManager/Networkmanager disabled - exclusively using qmi-cli > > so far I can follow. > > Your example has IPv4. Do I need additionally qmicli-commands for > testing IPv4v6? Probably. I don't know how to do that. Is there an IP family setting for qmicli? Another alternative is modifying the 802.3 default in ModemManager. That would be this part of src/mm-port-qmi.c: if (ctx->set_data_format) flags |= (QMI_DEVICE_OPEN_FLAGS_NET_802_3 | QMI_DEVICE_OPEN_FLAGS_NET_NO_QOS_HEADER); Changing it to something like if (ctx->set_data_format) flags |= (QMI_DEVICE_OPEN_FLAGS_NET_RAW_IP | QMI_DEVICE_OPEN_FLAGS_NET_NO_QOS_HEADER); should do for a simple test. I don't think you can use NM to configure the netdev, though. So you'll have to do that manually after connecting. > Because the test contains kernel-compilation, where I am totally out > of practice, I cannot promise a date for test results. No hurry. The solution is pretty much guaranteed to solve your problem if Reinhard's guess is correct. And that is likely. The real question is not whether it will work around the firmware bug, but whether and how we should implement the raw-ip support. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MC 7304 ipv4v6
Dan Williams writes: > On Wed, 2015-11-25 at 08:51 +0100, Bjørn Mork wrote: > >> The only "real" objection I once had was that I don't think there are >> any DHCP clients on Linux that will work with such an interface. But >> that is a lousy excuse. Using DHCP here is another bad idea, trying >> to > > The downside is that we know some QMI devices don't support the static > IP configuration returned by GetCurrentSettings. They only allow DHCP, > or at least DHCP seems to kick the device into actually talking. > However, maybe that's just a problem in 802.3 mode and raw-ip always > works on those devices with GetCurrentSettings static info? Not sure, > but something to make sure we test... That is likely an issue with the 802.3 firmware implementation. It probably needs DHCP to know what mac address the client wants to use. Based on the number of bugs we've seen in this area, my guess is that there are multiple solutions of this problem - some from Qualcomm and some from vendors. And probably twice as many quirks and workarounds for when it doesn't work... But even if it is much simpler, I would be surprised if raw IP works for all QMI devices/firmwares. I certainly don't think we can blindly assume so. If we open this box, then we may have to deal with both kinds of links for the forseeable future. Maybe a "safe" split would be based on the presence of WDA? If WDA, then try raw-ip, else continue to use 802.3. Then you at least have the ability to check if the "set data format" succeeded. Most older devices will probably default to 802.3 and be tested with that, with some exceptions as usual. I believe you had a Pantech UML290 which used raw IP in Windows? Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MC 7304 ipv4v6
On Wed, 2015-11-25 at 08:51 +0100, Bjørn Mork wrote: > Dan Williams writes: > > > Well, if we're going to add rawip support, why bother emulating a > > netdev at all? > > (assuming you mean etherdev - we'll need the netdev in any case :) > > Good question. Asked before, but I have fewer and fewer arguments. I > know Marcel H has wanted a raw device from the beginning. > > > I guess because it's convenient and we don't have to > > destroy the existing wwan0 and create some other tun-type device > > instead. But still, seems odd that we'd set raw-ip mode and then > > emulate ethernet when all that's really going back and forth is IP. > > Yes, it is odd and it does create a few problems which the driver > tries > to hide. It would be more honest to just let userspace decide what > to > do, e.g, wrt bridging. > > So when the firmware finally gave up messing with the L2 headers, why > should the driver continue to do that? Make it raw IP all the way. > Yes, > I'm starting to lean to that side as well. > > The only "real" objection I once had was that I don't think there are > any DHCP clients on Linux that will work with such an interface. But > that is a lousy excuse. Using DHCP here is another bad idea, trying > to The downside is that we know some QMI devices don't support the static IP configuration returned by GetCurrentSettings. They only allow DHCP, or at least DHCP seems to kick the device into actually talking. However, maybe that's just a problem in 802.3 mode and raw-ip always works on those devices with GetCurrentSettings static info? Not sure, but something to make sure we test... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MC 7304 ipv4v6
Am 25.11.2015 um 11:12 schrieb Bjørn Mork: Bjørn Mork writes: But I believe I implemented it the last time this was discussed. I'll see if I can dig up the old code for a demo. Not going to rush this anyway. I'd like everyone to be happy with the result. And it's going to be immutable once it's in. git is a wonderful tool. Nothing is ever lost :) I found my example code in an old v3.2 based branch, and turned it into a demo on the bus to job. Note that this requires a minor change to usbnet.c as well, to prevent it from doing eth_type_trans() on the rx skbs we pass on to it. Therefore two, eh.. three, patches. You are so fast. :-) Some questions to your detailed solution and the invitation to test. I need a very recent kernel (I have seen 4.4 in patch 003)? I need to follow your instructions (why do you use sometimes ifconfig instead of ip ?) - with ModemManager/Networkmanager disabled - exclusively using qmi-cli so far I can follow. Your example has IPv4. Do I need additionally qmicli-commands for testing IPv4v6? Because the test contains kernel-compilation, where I am totally out of practice, I cannot promise a date for test results. Regards, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] start after systemd-networkd
On Wed, 2015-11-25 at 15:36 +0100, Christian Hesse wrote:
> Thomas Haller on Wed, 2015/11/25 15:11:
> > On Wed, 2015-11-25 at 11:53 +0100, Christian Hess wrote:
> > > 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.
(does networkd rename device? I'd think that is be done by udev).
> > > 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.
> >
> > The "After" will delay starting NetworkManager only "after networkd
> > declared to be started".
>
> That's not true. From man 5 systemd.unit:
>
> [...] while After= ensures that the configured unit is started after
> the
> listed unit finished starting up [...]
I didn't say anything different.
systemd-networkd.service has:
[Service]
Type=notify
and networkd does:
...
r = manager_rtnl_enumerate_links(m);
r = manager_rtnl_enumerate_addresses(m);
r = manager_rtnl_enumerate_routes(m);
log_info("Enumeration completed");
sd_notify(false,
"READY=1\n"
"STATUS=Processing requests...");
thus, networkd signals that it is READY=1 before configuring the
devices (or not?). How does ordering NM "After=networkd" help then?
I think it's anyway a bad idea to have networkd and NM fight over the
same devices.
You can use networkd to create the device for which NM
then does IP configuration. That will probably work, but doesn't
require "After" either (does it?).
Maybe you can elaborate on your use-case and show how "After" solves it?
Thomas
signature.asc
Description: This is a digitally signed message part
___
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: [PATCH 1/1] start after systemd-networkd
Thomas Haller on Wed, 2015/11/25 15:11:
> On Wed, 2015-11-25 at 11:53 +0100, Christian Hess wrote:
> > 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.
>
> The "After" will delay starting NetworkManager only "after networkd
> declared to be started".
That's not true. From man 5 systemd.unit:
[...] while After= ensures that the configured unit is started after the
listed unit finished starting up [...]
> That is not the same as "after networkd completed configuring the
> network interfaces" -- which is what "networkd-wait-online.service"
> might be.
This service can be activated in addition, but achieves something different:
It finished successful after a network connection is established, which is
different from starting the systemd-networkd service.
> Because of that, I don't think this patch is correct.
I think it is. ;)
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
pgph09fmkFpVd.pgp
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
On Wed, 2015-11-25 at 11:53 +0100, Christian Hess wrote: > 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. The "After" will delay starting NetworkManager only "after networkd declared to be started". That is not the same as "after networkd completed configuring the network interfaces" -- which is what "networkd-wait-online.service" might be. Because of that, I don't think this patch is correct. Thomas signature.asc Description: This is a digitally signed message part ___ 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
[PATCH 1/1] start after systemd-networkd
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 [Service] Type=dbus -- 2.6.2 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MC 7304 ipv4v6
Bjørn Mork writes: > But I believe I implemented it the last time this was discussed. I'll > see if I can dig up the old code for a demo. Not going to rush this > anyway. I'd like everyone to be happy with the result. And it's going > to be immutable once it's in. git is a wonderful tool. Nothing is ever lost :) I found my example code in an old v3.2 based branch, and turned it into a demo on the bus to job. Note that this requires a minor change to usbnet.c as well, to prevent it from doing eth_type_trans() on the rx skbs we pass on to it. Therefore two, eh.. three, patches. Warning: Trying the qmi_wwan raw-ip feature without the usbnet patch is a sure path to an oops. Works for me(tm). Only tested on an E392 for now: nemi:/tmp# ifconfig wwan1 wwan1 Link encap:Ethernet HWaddr 92:b9:2a:c0:4f:96 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip N nemi:/tmp# echo 1 >/sys/class/net/wwan1/qmi/raw_ip nemi:/tmp# ifconfig wwan1 wwan1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) nemi:/tmp# cat /sys/class/net/wwan1/qmi/raw_ip Y bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1 --device-open-net='net-raw-ip|net-no-qos-header' --wds-start-network=apn=telenor --wds-follow-network [/dev/cdc-wdm1] Network started Packet data handle: '34967784' Ctrl+C will stop the network [/dev/cdc-wdm1] Connection status: 'connected' bjorn@nemi:~$ qmicli -d /dev/cdc-wdm1 --client-cid=1 --client-no-release-cid --wds-get-current-settings [/dev/cdc-wdm1] Current settings retrieved: IP Family: IPv4 IPv4 address: 46.157.38.113 IPv4 subnet mask: 255.255.255.252 IPv4 gateway address: 46.157.38.114 IPv4 primary DNS: 193.213.112.4 IPv4 secondary DNS: 130.67.15.198 MTU: 1500 Domains: none [/dev/cdc-wdm1] Client ID not released: Service: 'wds' CID: '1' nemi:/tmp# ifconfig wwan1 46.157.38.113 nemi:/tmp# ifconfig wwan1 wwan1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:46.157.38.113 P-t-P:46.157.38.113 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) nemi:/tmp# ip route add 148.122.171.130 dev wwan1 nemi:/tmp# ping -c3 148.122.171.130 PING 148.122.171.130 (148.122.171.130) 56(84) bytes of data. 64 bytes from 148.122.171.130: icmp_seq=1 ttl=58 time=156 ms 64 bytes from 148.122.171.130: icmp_seq=2 ttl=58 time=24.5 ms 64 bytes from 148.122.171.130: icmp_seq=3 ttl=58 time=27.5 ms --- 148.122.171.130 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 24.568/69.492/156.345/61.426 ms nemi:/tmp# tshark -nxxi wwan1 tshark: Lua: Error during loading: [string "/usr/share/wireshark/init.lua"]:46: dofile has been disabled due to running Wireshark as superuser. See http://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user. Running as user "root" and group "root". This could be dangerous. Capturing on 'wwan1' 45 00 00 54 75 99 40 00 40 01 30 05 2e 9d 26 71 E..Tu.@.@.0...&q 0010 94 7a ab 82 08 00 4d e4 6e c0 00 01 6e 77 55 56 .zM.n...nwUV 0020 00 00 00 00 ad b9 0b 00 00 00 00 00 10 11 12 13 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567 45 04 00 54 01 98 00 00 3a 01 ea 02 94 7a ab 82 E..T:z.. 0010 2e 9d 26 71 00 00 55 e4 6e c0 00 01 6e 77 55 56 ..&q..U.n...nwUV 0020 00 00 00 00 ad b9 0b 00 00 00 00 00 10 11 12 13 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050 34 35 36 37 4567 45 00 00 54 76 2f 40 00 40 01 2f 6f 2e 9d 26 71 E..Tv/@.@./o..&q 0010 94 7a ab 82 08 00 73 dc 6e c0 00 02 6f 77 55 56 .zs.n...owUV 0020 00 00 00 00 86 c0 0b 00 00 00 00 00 10 11 12 13 0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 !"# 0040 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30
Re: ANN: NetworkManager 1.0.8 released
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". Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.8 released
On Wed, 2015-11-25 at 02:46 +0100, Michael Biebl wrote: > 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. Hi Michael, This seems correct and as intended to me. Since 1.0 there are two libraries: (A) libnm-glib: existed from pre-1.0 time and is considered legacy. It is actually is split in several parts: NetworkManager.pc (headers in /usr/include/NetworkManager) libnm-util.pc (headers in /usr/include/NetworkManager) libnm-glib.pc (headers in /usr/include/libnm-glib) libnm-glib-vpn.pc (headers in /usr/include/libnm-glib) (B) libnm: a new version to replace the above. Note that it merges the parts togther to one: libnm.pc (headers in /usr/include/libnm). These libraries are independent, especially libnm must not use any headers from libnm-glib. E.g. the file nm-version-macros.h is present twice: (α) /usr/include/NetworkManager/nm-version-macros.h (β) /usr/include/libnm/nm-version-macros.h (don't you get nm-version-macros.h installed in both places? That would be a bug). In Fedora we package the two libraries are separate packages: (a) NetworkManager-glib, NetworkManager-glib-devel NetworkManager-devel (b) NetworkManager-libnm NetworkManager-libnm-devel one day, we hope to entirely drop the legacy libraries (a). > Shouldn't libnm.pc have > Requires: NetworkManager >= 1.0.8 Yeah maybe, I dunno. Lubomir? Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
