Dear maintainer,

Thanks for shipping a systemd service file with wpa.

By applying dh-systemd.patch, systemd users will enjoy a fully working
wpa on their machines: it will get enabled and started properly
(even if installed on sysvinit and later switching to systemd).

You can see the differences this patch causes in the attached
dh-systemd.debdiff. Use:

    colordiff --difftype=debdiff < dh-systemd.debdiff

(colordiff's highlighting is not entirely correct, but very helpful.)

Please apply this patch before uploading a new version. Thank you!

For more details on dh-systemd packaging, see
http://wiki.debian.org/Systemd/Packaging
In case of any questions, feel free to drop by in #debian-systemd or
send an email to pkg-systemd-maintainers@lists.alioth.debian.org

tags 715267 + wontfix
thanks

Following up on the discussion we had between Stefan, Michael S. and me,
I'm marking the bug as wontfix.
For completeness sake I'm copying the relevant parts

and

Hi

[ I'm cross-posting this reply for #806889 to the bugreport in #766746
  and #715267, if you're interested in networkd integration, feel free
  to skip to the second ff. paragraph. ]

I am currently seeing problems with a wpa_supplicant/ hostapd combination
using 4addr setups (potential regression compared to v2.3, link staying
connected, not transmitting any data on the hostapd side, but not
reconnecting - forcing a reconnect by restarting hostapd tends to help).
As of yet, I haven't been able to confirm if this is an issue with
src:wpa v2.5 or induced by unrelated changes (e.g. kernel version),
given that this is difficult to reproduce reliably (it might take
several days to happen, but can also happen within minutes, making
reliable bisecting hard).


Another open question, not preventing the upgrade to v2.5, but one that
needs to either be deferred/ backed out or decided is #715267/ #766746,
shipping a systemd unit for networkd integration. While this is
technically simple (and no, the upstream provided systemd unit as it
stands is not suitable[1]) and strictly opt-in, shipping this in an
upload implies committing to this way of starting wpasupplicant more or
less for "all eternity" as fixed ABI...

+ it works, I'm testing it for close to a year now - with mixed results
+ there seem to be advantages when it comes to suspend/ resume
+ it's strictly opt-in and needs explicit enabling from the admin

- systemd-networkd upstream hasn't committed to a policy regarding
  wireless devices, its handling might change in the future
- systemd-networkd doesn't provide any tools like ifup/ ifdown so
  far, making dynamic configuration changes (e.g. switch from wired-
  to wireless networks) difficult.
- hotpluggable wireless cards (USB) are problematic in the sense
  that systemd will wait (until timeout, 90s by default) if the
  a configured device is unplugged.
- basically unsuitable for notebook scenarios, where one might
  occasionally want to switch to wired ethernet (so far routing
  metrics seem to be the only, quite hacky workaround).

While it's easy to defer this decision once more, I was hoping to
come to an conclusion regarding #766746 for the next (as in this)
upload.

Given that it's opt-in, explicitly documenting this as volatile
and potentially unsupported (in the future) might be a way out,
but I'd still hate to eventually break previously working network
configurations in the future.

Regards
	Stefan Lippers-Hollmann

[1]	breaks with legacy/ staging (non-cfg80211 wlan cards)
	and DBus activation, I have fixes for both in the
	packaging VCs.