Merge lp://qastaging/~morphis/network-manager/add-snappy-support into lp://qastaging/~phablet-team/network-manager/snappy

1) I will have to say, I'm not a fan of merging the debian and snappy packaging into a single branch. There's simply too many debian-specific files included which are useless when it comes to building a snap. Add in the fact that the debian packaging branch for NM includes many stale patches ( ie. patches that aren't used or are commented out in the d/p/series ), and it seems like a mess to me.

Also, if we base the snap on the NM branch like this, we probably should revise the version to actually reflect this, at the moment it doesn't include the '-4ubuntu15.1.8' part in the version, yet it does include the code from that version.

I really prefer the bluez approach, where although the bzr namespace is the same as the debian package, the snap branch *only* includes snappy bits.

2) Why bother with --configure-snappy, the branch is solely for snappy? If we eventually try to upstream the patch(es), we'll probably need to change this is done ( ie. doubtful upstream would accept such a switch, we'd probably instead want to fix generically ), so let's either make the branch snappy only, or re-work the snappy patch into something we *think* upstream might accept ( note, let's do this after we switch to 1.2 ).

3) Why did you remove modemmanager and leave ofono in place? We know that modemmanager works, and we also know that ofono won't work till we re-write the settings plugin.

4) What's the reasoning behind the fix-code-to-build-with-werror.patch? It seems like this is changing a lot of code. Also this may not work with NM1.2, as they've gotten rid of some deprecated code ( eg. dbus-glib ), but not all ( eg. GSimpleAsyncResult ). Does the snap fail to build without this?

Note, I've also cleaned up a lot of ofono unused code in my 1.2 branch.

5) Where did the icon.svg come from? It's *huge* compared to the bluez icon.png ( which is a generic Ubuntu icon ).

6) What's the plan to fix "XXX: hardcode architecture" in wrapper binaries?

7) It looks like you're manually installing the binary wrapper scripts. Have you tested this? I couldn't get bluez to work this way, and ended up modifying yet another core snapcraft library to add the copies in when generating the wrapper scripts.

8) I don't see nmcli?

9) d/p/0002-Force-online-state-with-unmanaged-devices.patch: not re-patched for snappy.

10) 0003-Don-t-setup-Sleep-Monitor-if-not-booted-with-systemd.patch: not applicable for snappy.

11) d/p/0004-Use-symlinks-for-nmtui.patch: have you tested nmtui on snappy?

12) There are bunch of other patches that aren't really applicable to snappy ( eg. whoopsie support, upstart patches, ... ).

Also note that the bluez snap uses the ~bluetooth team, perhaps we should use ~network-manager here instead of ~phablet-team?

Thanks a lot for the first review round!

For 1: I must say I don't really like us separating stuff into multiple different approaches per product. We already have separate packaging branches for desktop and touch and adding a third one for snappy doesn't really scale. That there are debian patches which might not apply to snappy, stale patches etc. but those things are all sth we have to solve over time. We have to find one common approach for all projects we're doing and apply that to all projects the same way.

Also respect that we're already shipping snappy packages for 15.04 with the exact same approach we're doing here but just having the debian package unpacked in another git repo. So this is only a continuation of what we've done before but in a more packed way. I would really like to bring all the different work we're doing as close as possible together rather than investing a huge amount of time for development, testing, reviewing for all different projects. There will be always project specific development/testing/.. but we should aim for convergence. I know there are problems in practice but those are the bits we need to solve.

I am fine with adding the debian packaging version number.

For 2: Adding --enable-snappy was done with the aim to align our packaging as described for 1). The debian package would simply build with --disable-snappy.

For 3: I removed ModemManager as

 * It needs to be in its own snap. The NetworkManager snap/part
   then just interacts with. What we did for 15.04 was a
   quick hack and is nothing we should just continue to do
   without discussing what we really want.
 * Its a per device decision if a telephony snap should be
   installed or not.
 * There are different components we can use to bring
   telephony into the game and we still haven't decided
   which horse we will ride for snappy (ofono, ModemManager)
 * This MP isn't aiming for feature completeness. Its just
   bringing the basic work from 15.04 to series 16 and
   leaving stuff out we don't know if we want it or not.

Also I left ofono in place as I simply copied the configflags from the debian packaging which have ofono enabled by default. That is again sth which needs to be reworked in follow up stories after we have decided where our way goes to.

For 4: I added that patch simply because all the wonderful patches we did on top of upstream doesn't build with -Werror (deprecated glib functions, ignoring const, unused variables) which is the default on xenial. I am sure you fixed some or most of them already with your 1.2 work and lets not bother with this patch too much. Its just there to get stuff building for the time being but the right way is to rework all those patches.

For 5: That icon is what we had in 15.04 for the network-manager snap. Its a more colorful networking one coming from the default icon set on desktop??

For 6: None yet. But the best would be if we get rid of them by telling the build not to install things into arch specific directories as that doesn't make much sense with snappy. Its currently a bit of a mess how those things are handled within the snap configuration but that is up for later.

For 7: Works as it s...

Approved; discussion on most of the above points will happen separately.