This bug was fixed in the package network-manager -
0.9.6.0~git201207161259.00297f4-0ubuntu1
---------------
network-manager (0.9.6.0~git201207161259.00297f4-0ubuntu1) quantal; urgency=low
* upstream snapshot 2012-07-16 12:59:59 (GMT)
+ 00297f49fbbe05c51c02da43cda254c35e053589
[ Edward Donovan ]
* debian/source_network-manager.py: port package hook to python3.
(LP: #1013171)
[ Mathieu Trudel-Lapierre ]
* debian/patches/lp292054_tune_supplicant_timeout_60s.patch: disable the
patch. It adds unnecessary delays to things like detecting that hidden
networks are not in range, and since Jaunty drivers have changed a lot.
If we're still seeing timing issues with the supplicant, then perhaps the
drivers should be fixed instead, or we'll re-enable the patch. (LP: #446623)
* debian/network-manager.dnsmasq, debian/rules:
install a config file to /etc/dnsmasq.d to avoid system-wide instances of
dnsmasq to bind to 0.0.0.0 and the loopback interface, so that the NM-
spawned instance can claim an IP on lo and provide local resolution.
(LP: #959037)
* debian/patches/add-veth-support.diff: add support for the veth* virtual
ethernet devices. Thanks to Stéphane Graber for the patch.
* debian/patches/nm-ip6-rs.patch: dropped, applied upstream.
* debian/libnm-util2.symbols: add symbols:
+ nm_utils_file_is_pkcs12@Base
* debian/control: move policykit-1 from Recommends to Depends: without it
calls to the backend (e.g. when starting nm-tool), will fail. Thanks to
Stéphane Graber for the testing and solution.
* debian/rules: fix clean to properly remove m4/intltool.m4.
* debian/tests/control, debian/tests/nm: add an autopkgtest control file and
initial test to verify that NM works once installed.
* debian/control: add XS-Testsuite: autopkgtest.
-- Mathieu Trudel-Lapierre <[email protected]> Mon, 16 Jul 2012 17:17:51
-0400
** Changed in: network-manager (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
Status in “djbdns” package in Ubuntu:
New
Status in “dnsmasq” package in Ubuntu:
Confirmed
Status in “network-manager” package in Ubuntu:
Fix Released
Status in “pdns-recursor” package in Ubuntu:
Invalid
Status in “pdnsd” package in Ubuntu:
Invalid
Status in “djbdns” source package in Precise:
New
Status in “dnsmasq” source package in Precise:
Confirmed
Status in “network-manager” source package in Precise:
Triaged
Status in “pdns-recursor” source package in Precise:
Invalid
Status in “pdnsd” source package in Precise:
Invalid
Bug description:
As described in
https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-
resolving, network manager now starts a dnsmasq instance for local DNS
resolving.
That breaks the default bind9 and dnsmasq installations, for people that
actually want to install a DNS server.
Having to manually comment out "#dns=dnsmasq" in
/etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays
that way, it should be moved to the bind9 and dnsmasq postinst scripts.
Please make network-manager smarter so that it checks if bind9 or
dnsmasq are installed, so that it doesn't start the local resolver in
that case.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
