Projectkk2glider/launchpad packages #4274

projectkk2glider · 2017-01-22T19:44:47Z

For discussion. Some package details are still missing and the whole Debian packaging process is still a mystery to me. There is room for improvement.

Test PPA is open at https://launchpad.net/~opentx-test/+archive/ubuntu/ppa

Instructions will follow.

projectkk2glider · 2017-01-22T20:08:11Z

Instructions

Steps:

you must have launchpad.net account and be a member of the team
create and conifgure your gpg signing key
run prepared script

Prepare your GPG key

Create GPG key using name and *email that will later appear in the changelog. This will be the key
that will be used to sign the package before uploading it to launcpad.

gpg --gen-key

Upload your GPG key (public part) to Ubuntu keyserver. First get the KEY ID (8 characters) of your key:

gpg --list-keys

Then upload it (replace with your key ID):

gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>

Create Launchpad account

Go to https://launchpad.net/ and sign-in or register.
Associate your GPG key with your launchpad account. You will need your keys fingerprint (<fingerprint looks like E448 37D6 EF6E F13C 30C0 415C E7A0 818F 4864 9459>), get it with:

gpg --fingerprint

Join OpenTX team on launchpad (one of admins will add you to the team).

Releasing new version of Companion on Launchpad

Example:

my GPG key has name projectkk2glider and email <projectkk2glider@gmail.com>
Companion version is 2.2.0
Companion suffix is N360

Go into opentx directory and execute:

./launchpad/release.sh "projectkk2glider <projectkk2glider@gmail.com>" 2.2.0 N360

If everything goes OK, you will receive an email from the launchpad telling you that your file was accepted.

The release.sh script will modify some files in the repository (changelog), so make sure you check-in those changes after successful upload.

Notes:

you can not upload a package with the version that is equal or less than any already uploaded package (even if the build failed).

References:

mpaperno · 2017-01-23T00:27:15Z

Not to beat a dead horse (from Rocket discussions) but the whole effort of building/packaging the software for only one Linux distribution (and version!) doesn't make much sense to me. The simpler solution (to me) would be to package all the required Qt and C++ libraries with the application distro, just like it is done now for Mac and Windows. This eliminates any requirements for the user (lib conflicts gone) and also works across various Linux distros and versions, not just "debuntu" xx.xx. Not only have I done this successfully on several projects, but this is also how Qt distributes it's own software, so you know it works (they don't have separate packages for each Linux flavor!).

A GUI installer could also be added, eg. using Qt Installer Framework. But not required. W/out an installer the package can be distributed as a simple compressed archive, then simply un-compressed to any folder and run from there.

An example script which does all the packaging and library management (for all 3 OSs) can be found here. It is for qmake but could easily be adapted to cmake or whatever. The key part for Linux is adding rpath to the linker definitions, which tells the OS to first look in the specified folder for any libs. In this script, the required .so libs are placed in a subfolder of the application distro called qtlibs. (The rpath can be modified after linking, but it's more of a PITA.)

So that's my suggestion. For example the current nightly Linux package already didn't work on my Ubuntu 14.04-based Linux Mint due to dependency conflicts, but of course it runs fine when it can find the right libs. Which IMHO is silly because the whole point of Qt is to easily run on "any" OS.

-Max

mpaperno · 2017-01-23T00:32:32Z

PS. in the script example I posted, this line is also important to modify the Qt libs themselves. The same chrpath can probably be used on the actual application itself (so the -rpath link flag is not required), but I think it was easier to just add the linker flag in the first place.

projectkk2glider · 2017-01-23T13:52:55Z

would be to package all the required Qt and C++ libraries with the application distro

I agree, this would be a good solution.

This might also bring some other problems we don't even know exist. One thing I already know is not working correctly (at least when using non-native QT57 package) is the style of the windows. The colors scheme is not following the one used by other programs. So on my system Companion compiled with native Qt and non-native looks different (and not in a pleasant way).

I am OK with not using this PR, if nothing else I learned a lot of new things about the whole packaging/building system.

For example the current nightly Linux package already didn't work on my Ubuntu 14.04-based Linux Mint

Does this package work https://launchpad.net/~opentx-test/+archive/ubuntu/ppa/+files/opentx-companion22_2.2.0~N6-2~trusty_amd64.deb

projectkk2glider · 2017-01-23T14:19:31Z

This works, both companion22 programs work first one with QT5.2, second with 5.7. The thing to watch is that new RPATH cant be longer than original one, so enough space must be reserver while linking.

$ chrpath -l companion22 
companion22: RPATH=/usr/local/lib:
$ ldd companion22 | head -n4
	linux-vdso.so.1 =>  (0x00007ffde89e6000)
	libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f9029778000)
	libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f9028f4f000)
	libQt5Network.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Network.so.5 (0x00007f9028c0b000)
$ chrpath -r /opt/qt57/lib/ companion22 
companion22: RPATH=/usr/local/lib:
companion22: new RPATH: /opt/qt57/lib/
$ ldd companion22 | head -n4
	linux-vdso.so.1 =>  (0x00007ffdf757f000)
	libQt5Core.so.5 => /opt/qt57/lib/libQt5Core.so.5 (0x00007f719ddb7000)
	libQt5Widgets.so.5 => /opt/qt57/lib/libQt5Widgets.so.5 (0x00007f719d769000)
	libQt5Network.so.5 => /opt/qt57/lib/libQt5Network.so.5 (0x00007f719e39a000)

schwabe · 2017-01-23T14:46:54Z

I think we should add this PR as it at least adds a nicer way to build on Debian based systems.

For the discussion of including QT or not. I think as long as this launchpad is not much extra effort, I would keep it. It also allows Ubuntu users to install opentx with a simple add-apt-repository command and also keeps their OpenTX updated. And if only 16.04 ships with recent enough qt libs, then just let it make 16.04+ only.

bsongis · 2017-01-23T19:04:01Z

I also think we should go the way of this PR. Yes perhaps it will bring more work, but if we have one maintainer per distribution I don't see any problem, users will choose themselves how they will install / update Companion, that's nice, isn't it?

I will try to bring Manjaro packages myself as it's now my Linux system

That's said, we won't cover all linux distributions. What about snap?
http://snapcraft.io/

bsongis · 2017-01-23T19:04:34Z

launchpad/common/control

+Source: opentx-companion22
+Section: utils
+Priority: optional
+Maintainer: Bertrand Songis <bsongis-nosp@m-gmail.com>


mpaperno · 2017-01-23T19:14:40Z

Does this package work https://launchpad.net/~opentx-test/+archive/ubuntu/ppa/+files/opentx-companion22_2.2.0~N6-2~trusty_amd64.deb

Yes! I'll try it on a fresh "no development tools" install a bit later.

The thing to watch is that new RPATH cant be longer than original one, so enough space must be reserver while linking.

Ah good to know, not sure I ever realized that.

I also think we should go the way of this PR. Yes perhaps it will bring more work, but if we have one maintainer per distribution I don't see any problem, users will choose themselves how they will install / update Companion, that's nice, isn't it?

Sure, don't get me wrong, if there is the bandwidth to handle specific distributions, and/or the audience doesn't need other distros, then that is great. I was under the impression no one exactly wanted to deal with it. :)

bsongis · 2017-01-25T07:11:56Z

.gitignore

@@ -11,3 +11,4 @@ radio/src/bootloader/bootloader_ramBoot*
 radio/src/lua/lua_fields_*.txt
 radio/src/lua/lua_exports_*.txt
 build*/
+/debian/


not sure what is best, should we put / at the beginning of all lines here?

That was added by SmartGit, not sure either what is the proper way.

http://stackoverflow.com/questions/24139478/when-to-use-leading-slash-in-gitignore

Summary: leading slash means specifically the mentioned resource (eg. only the /debian/ folder found at the root of the repo). No leading slash can include stuff matching the pattern in any subfolder (eg. any *debian/ folder found in the root or any of the subfolders of the repo).

bsongis · 2017-01-25T07:12:58Z

CMakeLists.txt

@@ -38,6 +38,7 @@ set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR})
 set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${PROJECT_SOURCE_DIR}/cmake)

 # options shared by all targets
+option(NO_GIT "Don't use git revision timestamp" OFF)


why the negative, I would prefer:
option(GIT_TIMESTAMP "Use git revision timestamp" ON)

bsongis · 2017-01-25T07:17:08Z

radio/src/CMakeLists.txt

@@ -381,6 +381,12 @@ set(SRC ${SRC} ${FIRMWARE_SRC})

 ##### firmware target #####

+option(NO_FIRMWARE_TARGET "Don't configure firmware target (usefull for compiling Companion only)" OFF)
+if(NO_FIRMWARE_TARGET)
+  message(STATUS "firmware target disabled")


Firmware with uppercase

And perhaps a positive option FIRMWARE_TARGET instead of NO_FIRMWARE_TARGET

projectkk2glider · 2017-01-26T19:29:57Z

I will prepare a new PR for this.

Added files and scripts to enable Launchpad.net package building

c78ab55

projectkk2glider changed the base branch from master to next January 22, 2017 19:45

bsongis reviewed Jan 23, 2017

View reviewed changes

bsongis approved these changes Jan 25, 2017

View reviewed changes

projectkk2glider closed this Jan 26, 2017

projectkk2glider deleted the projectkk2glider/launchpad_packages branch February 17, 2017 19:18

projectkk2glider mentioned this pull request Mar 5, 2017

Missing instructions #4561

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Projectkk2glider/launchpad packages #4274

Projectkk2glider/launchpad packages #4274

projectkk2glider commented Jan 22, 2017 •

edited

projectkk2glider commented Jan 22, 2017 •

edited

mpaperno commented Jan 23, 2017

mpaperno commented Jan 23, 2017

projectkk2glider commented Jan 23, 2017

projectkk2glider commented Jan 23, 2017

schwabe commented Jan 23, 2017

bsongis commented Jan 23, 2017

bsongis Jan 23, 2017

mpaperno commented Jan 23, 2017

bsongis Jan 25, 2017

projectkk2glider Jan 25, 2017

mpaperno Jan 25, 2017

bsongis Jan 25, 2017

bsongis Jan 25, 2017

bsongis Jan 25, 2017

projectkk2glider commented Jan 26, 2017

Projectkk2glider/launchpad packages #4274

Projectkk2glider/launchpad packages #4274

Conversation

projectkk2glider commented Jan 22, 2017 • edited

projectkk2glider commented Jan 22, 2017 • edited

Instructions

Prepare your GPG key

Create Launchpad account

Releasing new version of Companion on Launchpad

mpaperno commented Jan 23, 2017

mpaperno commented Jan 23, 2017

projectkk2glider commented Jan 23, 2017

projectkk2glider commented Jan 23, 2017

schwabe commented Jan 23, 2017

bsongis commented Jan 23, 2017

bsongis Jan 23, 2017

Choose a reason for hiding this comment

mpaperno commented Jan 23, 2017

bsongis Jan 25, 2017

Choose a reason for hiding this comment

projectkk2glider Jan 25, 2017

Choose a reason for hiding this comment

mpaperno Jan 25, 2017

Choose a reason for hiding this comment

bsongis Jan 25, 2017

Choose a reason for hiding this comment

bsongis Jan 25, 2017

Choose a reason for hiding this comment

bsongis Jan 25, 2017

Choose a reason for hiding this comment

projectkk2glider commented Jan 26, 2017

projectkk2glider commented Jan 22, 2017 •

edited

projectkk2glider commented Jan 22, 2017 •

edited