Update contrib/debian to latest Ubuntu PPA upload.

[TheBlueMatt]

This:

• Partially reverts 9f68ed6 (which fixed spelling in a changelog,
  though generally changelogs should be append-only).
• Disables UPnP support (PPA has not had it for a while, and I
  still don't trust miniupnpc, plus it seems uneccessary - its
  been a while since we needed to care about Bitcoin-Qt home users
  getting their inbound ports auto-mapped).
• Enables ZMQ.
• Forces GUI to Qt4 to fix various issues people have been seeing
  on Ubuntu and elsewhere with Qt5.
• Reverts 70899d7 (Bitcoin does not enable "instant payments",
  not is transaction management "carried out collectively by the
  network", for whatever "transaction management" means, finally
  Bitcoin Core is not the only way to use the Bitcoin currency,
  as seemingly implied in the description).

[laanwj]

Forces GUI to Qt4 to fix various issues people have been seeing
on Ubuntu and elsewhere with Qt5.

Which issues have you seen with Qt5 apart from the Unity tray icon problem?

Reverts 70899d7 (Bitcoin does not enable "instant payments",
not is transaction management "carried out collectively by the
network", for whatever "transaction management" means, finally
Bitcoin Core is not the only way to use the Bitcoin currency,
as seemingly implied in the description).

Probably want to change the README.md too, then, as that's where that description came from.

[TheBlueMatt]

Hm, I was under the impression there were tray icon issues outside of Ubuntu, but that may be out-of-date (or a static-linking issue?)

[parazyd]

@TheBlueMatt There are no Qt5 issues besides Ubuntu. I've tested the build on Devuan's KDE5 (Plasma), which is in turn the exact same environment provided in Debian. So Ubuntu is your only problem. If you want to block all other distros from using current software because of one distro's bug, that's your choice, but it is not a sane one. Build it with Qt5 and then fix it in Ubuntu.

[TheBlueMatt]

@parazyd up until today the only user of contrib/debian I was aware of was the PPA, and there are very few issues (aside from some cosmetic ones) with building with Qt4 instead of 5 (though that may be different on KDE5, apparently). I'm happy to keep on maintaining a fork of contrib/debain instead if you want to maintain contrib/debian, but at that point we might as well just delete the folder if everyone is gonna use their own.

[luke-jr]

I don't see how optional UPnP support is a bad thing. Even when built with it, it's still disabled by default.

Other than that, utACK.

[parazyd]

ACK. Agreed with @luke-jr

[TheBlueMatt]

@luke I believe its enabled by default in Qt, no?

[luke-jr]

@TheBlueMatt Not since the last exploit IIRC.

This fails for precise:

The following packages have unmet dependencies:
 sbuild-build-depends-bitcoin-dummy : Depends: libzmq3-dev but it is not installable

[TheBlueMatt]

Ah, ok, I suppose we could re-add UPnP to the builds. Not sure it matters much, but ok. We can no longer build on precise period due to https://svn.boost.org/trac/boost/ticket/6198.

…

On May 3, 2017 4:11:46 PM EDT, Luke Dashjr ***@***.***> wrote: @TheBlueMatt Not since the last exploit IIRC. This fails for precise: ``` The following packages have unmet dependencies: sbuild-build-depends-bitcoin-dummy : Depends: libzmq3-dev but it is not installable ```

[luke-jr]

Ah. I guess precise doesn't matter anymore anyway (supposedly support for it ended last month).

[jaromil]

You need a neew maintainer for Debian builds, not a new PR rushed by the old neglecting maintainer when a new contribution comes in, IMHO. This turf-war attitude calls for burn out. At Dyne we are actively testing the builds proposed and can well deal with guidelines and complexities of gnu/linux packaging, so @bluematt once again (like at the time of autoconf) you are missing an occasion for having more contributors to core. Friendly yours

[TheBlueMatt]

@jaromil are y'all using contrib/debian for anything? If it gets use I'm happy to start maintaining it again (or @parazyd can). The PPA never falls behind, just this dir which I've neglected updating (but I assume not many people used it given it was missing the libevent dep for a long time).

Unrelatedly, would be nice if we have a way to switch to Qt5 when building on non-ubuntu, @parazyd any idea how to do that?

[parazyd]

@TheBlueMatt Well, the debian/rules file is a Makefile. We could use environment flags to differ between Ubuntu and Debian I guess.

The contrib/debian is being used by at least three distributions at this moment: Ubuntu, Devuan, and heads.

[luke-jr]

But the qt4/5 dep is in debian/control - can that have conditionals?

[parazyd]

@luke-jr I'll try to find out. If possible, then it is the best solution, since the configure script will then prefer what's found. And as long as it's built in some sort of CI, the environment is clean.

EDIT:
Indeed we have a thing like the following:
https://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/

[TheBlueMatt]

@luke-jr the deps of the built package are auto-guessed from library deps, I believe, so it may be sufficient to just change which libraries configure links against, even if buildeps requires both qt4 and qt5 (though I havent tested this).

[theuni]

Minimum boost for 0.14 is 1.47.

[TheBlueMatt]

Fixed.

[jaromil]

@TheBlueMatt there are the distro efforts @parazyd mentions and we are planning for more hardened gnu/linux based VM environments (so to say containers) and what not, some fancy distro tricks for isolated environments. Within the sphere of Debian&co the backporting libdb4.8 to Jessie was a long due liberation step finally taken and you know well the berkeleydb mess we are talking about. So yea, there is attention on the contrib/debian and this and the other PR are here because we think we are ready to contribute. Said that I see nothing really problematic in this process and I'm glad you find the time to look into it. Knowing fairly well the autoconf pains your prolongued work deserves much respect.

[TheBlueMatt]

@parazyd I pushed a version that should use Qt5 automagically on Debian-based distros, but dont have a machine handy to test on, care to give it a whirl?

[luke-jr]

QT=$(shell dpkg-vendor --derives-from Ubuntu && echo qt4 || echo qt5)

or better yet (to enable Qt5 on Ubuntu 17.10+ which is GNOME instead of Unity):

QT=$(shell { [ $(lsb_release -s -i) = Ubuntu ] && { [ $(lsb_release -s -r | cut -d. -f1) -lt 17 ] || [ $(lsb_release -s -r) = 17.04 ]; } } && echo qt4 || echo qt5)

[TheBlueMatt]

Maybe lets wait until 10.17 before we lock in using qt5 in 17.10 in case they slip to the next release or so?

[luke-jr]

k

[parazyd]

@TheBlueMatt Your if clause doesn't pass $QT correctly, on my Devuan build it stays empty. @luke-jr 's lsb_release oneliner works.

[TheBlueMatt]

Wait, the dpkg-vendor version doesn't work, or the if doesnt hold the variable outside of the scope?

[parazyd]

$(QT) is empty on the ./configure call

[luke-jr]

That's odd, I would expect both to work... :/

[parazyd]

OK, it seems if you don't indent the QT= assigns, it works.

[luke-jr]

Don't forget to drop --without-miniupnpc?

(and restore libminiupnpc8-dev | libminiupnpc-dev (>> 1.6), in build deps)

[parazyd]

Introducing typos?

[parazyd]

Is there a reason for introducing these typos?

[luke-jr]

Yes, read the OP...

Partially reverts 9f68ed6 (which fixed spelling in a changelog,
though generally changelogs should be append-only).

[parazyd]

I fail to understand the reasoning.

[TheBlueMatt]

Fixed Qt version auto-detection and re-enabled UPnP.

[luke-jr]

utACK

[parazyd]

Looks good