CPack debian packaging #3583

robaerd · 2020-12-08T02:39:31Z

Adds creating of modular debian packages with CPack.

Basics

These points need to be fulfilled for every PR:

Short descriptions of your changes are in the release notes
(added as entry in doc/news/_preparation_next_release.md which
contains _(my name)_)
Please always add something to the release notes.
Details of what you changed are in commit messages
(first line should have module: short statement syntax)
References to issues, e.g. close #X, are in the commit messages.
The buildservers are happy. If not, fix in this order:
- add a line in doc/news/_preparation_next_release.md
- reformat the code with scripts/dev/reformat-all
- make all unit tests pass
- fix all memleaks
The PR is rebased with current master.

If you have any troubles fulfilling these criteria, please write
about the trouble as comment in the PR. We will help you.
But we cannot accept PRs that do not fulfill the basics.

Checklist

Check relevant points but please do not remove entries.
For docu fixes, spell checking, and similar none of these points below
need to be checked.

I added unit tests for my code
I fully described what my PR does in the documentation
(not in the PR description)
I fixed all affected documentation
I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
I updated all meta data (e.g. README.md of plugins and METADATA.ini)
I mentioned every code not directly written by me in THIRD-PARTY-LICENSES

Review

Reviewers will usually check the following:

Documentation is introductory, concise, good to read and describes everything what the PR does
Examples are well chosen and understandable
Code is conforming to our Coding Guidelines
APIs are conforming to our Design Guidelines
Code is consistent to our Design Decisions

Labels

If you are already Elektra developer:

Add the "work in progress" label if you do not want the PR to be reviewed yet.
Add the "ready to merge" label if the basics are fulfilled and you also
say that everything is ready to be merged.

robaerd · 2020-12-08T02:41:28Z

I ran into following problems with CPack:

CPack Deb doesn’t have multi-arch support
It is not possible to create a single package containing the debug symbols for all components. Currently CPack generates for each package a corresponding debug package(-dbgsym.ddeb).
The debian maintscripts had to be replaced with the generated control files (postinst, etc), since there is no support for maintscripts
The generated .deb packages do currently not include the *.exmaple, *.lintian-overrides, *.links or the copyright. Should these files only be included in the deb package? If yes, then it will be necessary to add a cmake flag for packaging, so that the package specific files are not installed normally.

markus2330 · 2020-12-08T06:38:12Z

Thank you so much, this looks like a massive amount of work! 🚀

Please ping me when it is ready to review.

CPack Deb doesn’t have multi-arch support

What does that mean? That an i386 package we create with cpack is uninstallable on an amd64 system? Is there already an upstream issue about that?

It is not possible to create a single package containing the debug symbols for all components. Currently CPack generates for each package a corresponding debug package(-dbgsym.ddeb).

I don't think this is a problem. We can create an extra package that depends on all other -dbgsym packages.

The generated .deb packages do currently not include the *.exmaple, *.lintian-overrides, *.links or the copyright. Should these files only be included in the deb package? If yes, then it will be necessary to add a cmake flag for packaging, so that the package specific files are not installed normally.

No cmake flag should be added. If we want to have them in the deb, we also add them in the normal installation. About the files in the debian branch:

*examples: I do not see much benefit in installing parts of the source. But I am also okay if it is done as part of the normal documentation installation.
*.lintian-overrides: As we were not lintian clean anyway, forget about this.
*.links: This link actually should be done (if kdb-static is installed). This is a bug in our installer, and it seems like someone did a workaround only in the debian package. This should be properly fixed in cmake. (We already create several links, there is already a function for that.)
copyright: we already have LICENSE.md and doc/THIRD-PARTY-LICENSES (in master) which replaces the copyright of the debian branch. Afaik there is only one leftover: license issues #2528 If you find other leftovers, please add them in the issue (or even better: fix them 💖 ).

robaerd · 2020-12-08T15:08:33Z

What does that mean? That an i386 package we create with cpack is uninstallable on an amd64 system? Is there already an upstream issue about that?

Exactly. Packages would need to be multiarch-aware wich is not supported by CPack. The upstream issue: https://gitlab.kitware.com/cmake/cmake/-/issues/21445
AFAIK we do not cross-compile our debian packages for i386 currently, so I don't think this is actually a problem?

copyright: we already have LICENSE.md and doc/THIRD-PARTY-LICENSES (in master) which replaces the copyright of the debian branch

A machine-readable copyright file is required for for each debian package, so I don't think that LICENSE.md and THIRD-PARTY-LICENSES replaces it. We could probably generate the copyright file from the LICENSE.md and THIRD-PARTY-LICENSES files.

markus2330 · 2020-12-08T17:01:30Z

AFAIK we do not cross-compile our debian packages for i386 currently, so I don't think this is actually a problem?

Yes, I agree. It is not really a problem. And it is an upstream issue anyway, so I wouldn't do anything about it.

A machine-readable copyright file is required for for each debian package, so I don't think that LICENSE.md and THIRD-PARTY-LICENSES replaces it. We could probably generate the copyright file from the LICENSE.md and THIRD-PARTY-LICENSES files.

Did you already check for the other distributions (you want to write packages for) what they need?

Maybe we can (manually) rewrite doc/THIRD-PARTY-LICENSES to the licencecheck format. Then we could use licensecheck2dep5 for generation of the dep5 license file. (See https://wiki.debian.org/CopyrightReviewTools for the various tools that Debian has.)

We can also maintain doc/THIRD-PARTY-LICENSES directly in dep5 format, depending on which format other distributions need and which conversion tools they provide. It is up to you what works best and what is the easiest for you.

mpranj · 2020-12-09T09:59:42Z

Nice work, thank you for creating the PR! Great to see so much progress. 🚀

It's already looking really great. I think the best way forward will be to test the installed packages in the CI (as we already discussed).

robaerd · 2020-12-09T11:39:06Z

Did you already check for the other distributions (you want to write packages for) what they need?

RPM packages for example require only a mentioning of the used licenses and a short comment explaining the licensing breakdown. I have yet to check how CPack RPM handles the Licenses: field.

Maybe we can (manually) rewrite doc/THIRD-PARTY-LICENSES to the licencecheck format.

Yes good idea, I will do this.

Unfortunately there appears to be no simple way to have a common format, so we would need to maintain multiple licenses/copyright files for each package format.

markus2330 · 2020-12-11T11:45:35Z

scripts/packaging/copyright

@@ -0,0 +1,556 @@
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


Thank you, great improvements!

But we really cannot maintain several copyright files, we hardly can manage one. Simply modify doc/THIRD-PARTY-LICENSES or remove doc/THIRD-PARTY-LICENSES (after updating this file) but please do not duplicate copyright information. It is too much of a burden for anyone adding something with copyright. The copyright file of the debian branch was often forgotten to be updated.

Maintaining the doc/THIRD-PARTY-LICENSES in licencecheck format, like suggested previously, wouldn't really work. licensecheck analyzes each file in the project and returns the copyright information of the file. The problem is that wildcards for files are not supported, so we would need to mention each file explicitly.

It would be probably best if we maintain the doc/THIRD-PARTY-LICENSES in dep5 format.

Yes, doc/THIRD-PARTY-LICENSES in dep5 format is perfectly fine.

robaerd · 2020-12-11T18:55:21Z

@markus2330 can you please review this PR?

markus2330

Amazing job! 🥇 I cannot wait to get this finally merged!

markus2330 · 2020-12-12T08:02:07Z

doc/THIRD-PARTY-LICENSES

+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: Elektra
+Upstream-Contact: Markus Raab <[email protected]>
+Source: http://www.libelektra.org/ftp/elektra/releases/


Suggested change

Source: http://www.libelektra.org/ftp/elektra/releases/

Source: https://www.libelektra.org/ftp/elektra/releases/

markus2330 · 2020-12-12T08:02:49Z

doc/THIRD-PARTY-LICENSES

+Source: http://www.libelektra.org/ftp/elektra/releases/
+
+Files: *
+Copyright: 2003-2004, 2006-2008, 2010, 2013-2014 Markus Raab <[email protected]>


Is it possible to simply refer to doc/AUTHORS.md here? (Btw. doc/AUTHORS can be removed, I do not think it is used anymore).

And please feel free to add yourself also to doc/AUTHORS.md.

I couldn't find an example where a specific file was referenced, but we could simply write "libelektra contributors". Neovim for example is doing it this way.

Yes, good idea. I would say we can even write
Elektra contributors (https://www.libelektra.org/developers/authors)

It is free text, so the weirdest things are there. Also links are quite common there. (I used grep "Copyright:.*/" /usr/share/doc/*/copyright to find out.)

markus2330 · 2020-12-12T08:03:54Z

scripts/cmake/ElektraPackaging.cmake

@@ -8,6 +8,7 @@ set (CPACK_PACKAGE_VERSION "${PROJECT_VERSION}")
 set (CPACK_DEBIAN_PACKAGE_VERSION "${PROJECT_VERSION}")
 set (CPACK_DEBIAN_PACKAGE_RELEASE "1")
 set (CPACK_DEBIAN_FILE_NAME DEB-DEFAULT)
+set (CPACK_DEBIAN_PACKAGE_MAINTAINER "Pino Toscano <[email protected]>")


You are now the Debian package maintainer 🥇

markus2330 · 2020-12-12T08:06:10Z

scripts/packaging/debian-control/elektra-bin/postinst

What is this script doing? Why is a very outdated version number here?

The bash completion is not working well (or even not at all?), if there are packaging problems with it, it is probably better to simply remove it completely.

This is the generated output of the elektra-bin.maintscript.

The purpose of it was to remove a conffile which was necessary for versions prior to 0.8.11-1.
Since 0.8.11-1 was already 5 years ago, I think these maintscripts can be removed.

markus2330 · 2020-12-12T08:13:05Z

doc/CMakeLists.txt

+		DESTINATION ${TARGET_DOCUMENTATION_TEXT_FOLDER}
+		COMPONENT libelektra4)
+	install (
+		FILES METADATA.ini


Ahh, good that this finally gets installed! Does the script scripts/kdb/mount-info work? (It should as you use TARGET_DOCUMENTATION_TEXT_FOLDER)

There is an issue with it. Although these files are inside the debian package (at /usr/share/doc/elektra/) they somehow doesn't get installed.

Seems like dpkg somehow removes these files. Running dpkg with debug=7200 returns following output:

D000010: tarobject ti->name='./usr/share/doc/elektra/NEWS.md' mode=100644 owner=0:0 type=48(-) ti->linkname='' namenode='/usr/share/doc/elektra/NEWS.md' flags=2 instead='<none>' D000010: filter comparing '/usr/share/doc/elektra/NEWS.md' and '/usr/share/man/*' D000010: filter comparing '/usr/share/doc/elektra/NEWS.md' and '/usr/share/locale/*/LC_MESSAGES/*.mo' D000010: filter comparing '/usr/share/doc/elektra/NEWS.md' and '/usr/share/doc/*' D000010: filter removing ./usr/share/doc/elektra/NEWS.md D000010: filter comparing '/usr/share/doc/elektra/NEWS.md' and '/usr/share/doc/*/copyright' D000010: filter comparing '/usr/share/doc/elektra/NEWS.md' and '/usr/share/doc/*/changelog.Debian.*'

This also happens on the previous Elektra packages not built with CPack.

markus2330 · 2020-12-12T08:13:27Z

doc/news/_preparation_next_release.md

@@ -162,7 +162,7 @@ you up to date with the multi-language support provided by Elektra.
 ### CMake

 - Use Lua 5.4 when available. _(Mihael Pranjić)_
- <<TODO>>
+- We now use CPack to build modular Debian and Ubuntu packages. _(Robert Sowula)_


You can make a highlight out of this!

markus2330 · 2020-12-12T08:17:03Z

scripts/cmake/ElektraPackaging.cmake

+		set (CPACK_COMPONENT_LIBELEKTRA4_DESCRIPTION "This package contains the main elektra library, and most of the core plugins")
+		set (CPACK_DEBIAN_LIBELEKTRA4_PACKAGE_SECTION "libs")
+		set (CPACK_DEBIAN_LIBELEKTRA4_PACKAGE_BREAKS
+		     "elektra-bin (<< 0.8.14-5~), libelektra-core4 (<< 0.8.19-1), libelektra-full4 (<< 0.8.19-1)")


I doubt that these versions make sense (0.8.19) or are relevant anymore (0.8.14). I think everywhere with 0.8.19 actually the current version should be used. References to older versions we can simply ignore, without extensive testing an upgrade would not work from these versions anyway.

markus2330 · 2020-12-12T16:29:42Z

I now tried creating the debs with cpack. I get quite many warnings:

-- CPACK_DEBIAN_PACKAGE_DEPENDS not set, the package will have no dependencies.

and also:

CMake Warning (dev) at /usr/share/cmake-3.13/Modules/Internal/CPack/CPackDeb.cmake:541 (message):
  Shared library
  './home/markus/Projekte/Elektra/installation/lib/elektra/libelektra-base64.so'
  is missing soname or soversion.  Library will not be added to DEBIAN/shlibs
  control file.
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/Internal/CPack/CPackDeb.cmake:676 (cpack_deb_prepare_package_vars)
This warning is for project developers.  Use -Wno-dev to suppress it.

The debs are now directly in the build folder. Is it possible to put all of this in a subfolder?

There are also many install_manifest_* files. They look quite useless, the main purpose of packages is that it is not needed to externally remember what was installed.

The descriptions are very short, there should be some explanation of what Elektra is.

At one place we have Maintainer: https://www.libelektra.org/

What happens with the files that do not belong to any package? Where do they end up? (It would be nice if I also could install them as a deb, e.g. also the website, which I sometimes install locally).

Overall amazing work, looking forward to see this as the new way of packaging. It is much easier and faster than the old way. 💖

robaerd · 2020-12-12T17:31:05Z

-- CPACK_DEBIAN_PACKAGE_DEPENDS not set, the package will have no dependencies.

This one is fine. It only indicates that a package has no explicitly set dependencies other than the automatically discovered dependencies.

'./home/markus/Projekte/Elektra/installation/lib/elektra/libelektra-base64.so' is missing soname or soversion. Library will not be added to DEBIAN/shlibs control file.'

This is also fine. We only use symbol versioning in src/libs and for a few tools. This warning only indicates that symbolic versioning is not used and shlibs are not generated for this package. The generated shlibs are also identical to the previous debian packages generated with gpb.

The debs are now directly in the build folder. Is it possible to put all of this in a subfolder?

I will look into this.

There are also many install_manifest_* files.

They actually are useless and can be safely removed.

The descriptions are very short, there should be some explanation of what Elektra is.

The package description of each package (e.g. CPACK_COMPONENT_LIBELEKTRA4_DESCRIPTION) is appended to CPACK_PACKAGE_DESCRIPTION_SUMMARY. The descriptions should be therefore identical to the previous packages.

At one place we have Maintainer: https://www.libelektra.org/

Thanks, I will fix this.

What happens with the files that do not belong to any package? Where do they end up? (It would be nice if I also could install them as a deb, e.g. also the website, which I sometimes install locally).

Files that do not belong to a component will not be packaged. The easiest solution would be to simply add a default component where each file will be installed that is not part of a package.

robaerd · 2020-12-13T02:26:44Z

The debs are now directly in the build folder. Is it possible to put all of this in a subfolder?

The debs are now in the subfolder "packages".

The easiest solution would be to simply add a default component where each file will be installed that is not part of a package.

I added the package "elektra-misc" which contains all files that are not part of any other package.

I overlooked that the changelog file was missing. CPack DEB has unfortunatly no feature to automatically update the debian/changelog. I have now added the changelog file from the debian branch.
The changelog can still be updated with the dch command, so this shouldn't introduce any overhead.

All files that are not part of a released package are packaged into the elektra-misc package

markus2330 · 2020-12-14T07:43:54Z

This one is fine.

Maybe you find some way to not show these warnings. There are so many that we would not see relevant warnings anymore.

They actually are useless and can be safely removed.

Maybe directly after building?

The debs are now in the subfolder "packages".

Thank you, great! 🎆

I added the package "elektra-misc" which contains all files that are not part of any other package.

Perfect! Is it possible to generate a warning if someone installs something and has no COMPONENT chosen? Or we simply set CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to elektra-misc?

The changelog can still be updated with the dch command, so this shouldn't introduce any overhead.

Yes, and dch can be called during the continuous releases.

Amazing work! For me it looks like that we can already generate the Debian packages with cpack in the next release!
@mpranj what do you think?

markus2330 · 2020-12-14T08:13:24Z

install_manifest_elektra-misc.txt contains some indications of left-overs for other packages:

/usr/local/lib/elektra/libelektra-jni.so this should be in some java package
/usr/local/lib/pkgconfig/elektra-merge.pc this should be where the other pc files are, or where merge files are
/usr/local/share/java/libelektra4j-0.9.3.jar also java package
/usr/local/share/java/libelektra4j-0.9.3.pom.xml also java package
/usr/local/share/man/man1/kdb-elektrify-getenv.1 where elektrify-getenv binary is
/usr/local/share/man/man1/kdb-qt-gui.1 to the qt-gui
/usr/local/lib/elektra/libelektra-yamlcpp.so this could be interesting to have, as it is our best yaml plugin
/usr/local/lib/elektra/tool_exec/gen-gpg-testkey @petermax2 is this to be installed at all? If it is needed, it should be in the test package.

Probably fine to have them in misc is:

/usr/local/share/doc/elektra-misc/copyright
/usr/local/share/doc/elektra-misc/changelog.Debian.gz
/usr/local/lib/elektra/libelektra-gitresolver.so (probably just build because I had libgit installed, is an experimental plugin)

petermax2 · 2020-12-14T08:22:37Z

/usr/local/lib/elektra/tool_exec/gen-gpg-testkey @petermax2 is this to be installed at all? If it is needed, it should be in the test package.

gen-gpg-testkey is required by the crypto/fcrypt unit tests. If the crypto/fcrypt unit tests are installed, the tool is required as well.

mpranj · 2020-12-14T08:24:37Z

For me it looks like that we can already generate the Debian packages with cpack in the next release!

Definitely. I also look forward to other packages 🚀

robaerd · 2020-12-14T18:34:44Z

Maybe you find some way to not show these warnings.

Unfortunately I couldn't find a way to supress only these warnings. For our use in Jenkins we could filter out the warnings for the shlbis generation with e.g. awk.

Maybe directly after building?

The install_manifest_*.txt are a by-product of CPack packaging and are not generated normally. They are probably used for the debian package generation. Just to be sure, you are thinking of deleting these files with a custom command with CMake after the packages are built, or do you simply want to delete it with a script in the CI so the build dir is cleaner?

Is it possible to generate a warning if someone installs something and has no COMPONENT chosen.

This actually is possible, but we would loose the option to exclude packages from being generated (which IMHO is not a big problem).

Currently we are setting CPACK_COMPONENTS_ALL manually. If we don't set CPACK_COMPONENTS_ALL, then this variable is set automatically after the include (CPack) command. CMAKE_INSTALL_DEFAULT_COMPONENT_NAME defaults to Unspecified, so we would only need to compare if a package is present that equals to Unspecified and generate a warning/error.

/usr/local/lib/elektra/libelektra-jni.so this should be in some java package
/usr/local/share/java/libelektra4j-0.9.3.jar also java package
/usr/local/share/java/libelektra4j-0.9.3.pom.xml also java package

We didn't package the jni plugin nor the jna bindings previously, so I though they shouldn't be packaged (see scripts/packaging/package.sh for currently included bindings/packages). But I can of course create packages for the missing plugins/bindings.

Since you also mentioned yamlcpp, what plugins and bindings should actually be packaged now?

markus2330 · 2020-12-15T08:06:45Z

Unfortunately I couldn't find a way to supress only these warnings. For our use in Jenkins we could filter out the warnings for the shlbis generation with e.g. awk.

Let it be for now, maybe we find later a solution. Not urgent or critical.

Just to be sure, you are thinking of deleting these files with a custom command with CMake after the packages are built, or do you simply want to delete it with a script in the CI so the build dir is cleaner?

Again, not urgent or critical. If cmake makes them by itself, it is best if we do not touch them.

CMAKE_INSTALL_DEFAULT_COMPONENT_NAME defaults to Unspecified, so we would only need to compare if a package is present that equals to Unspecified and generate a warning/error.

Yes, sounds great! In this error message we can write that they need to choose in which package it should be. This sounds much better than simply throwing everything into the misc package.

We didn't package the jni plugin nor the jna bindings previously, so I though they shouldn't be packaged (see scripts/packaging/package.sh for currently included bindings/packages). But I can of course create packages for the missing plugins/bindings.

It would be nice, but if we get maven packages anyway it is not highest priority. I see that other Java Debian packages have a symlink from /usr/share/maven-repo/<>/*.jar and the .pom is actually in /usr/share/maven-repo/<>/ and not in /usr/share/java (what we do now). If we do this correctly, java and maven would probably find Elektra without all the things mentioned in src/bindings/jna/README.md. That pom gets installed to a wrong location we should probably fix. I did not investigate what other distributions do, though.

Since you also mentioned yamlcpp, what plugins and bindings should actually be packaged now?

Also here, not urgent as the plugin has "unfinished concept discouraged" status. I think it should be in its own package, as it has a dependency no other part of Elektra has. @sanssecours what is missing that you would recommend the plugin more?

robaerd · 2020-12-15T20:03:02Z

Regarding throwing errors if no component is provided during install. This is in our case apparantly not possible. Somehow a "ghost" package with the CMAKE_INSTALL_DEFAULT_COMPONENT_NAME name is generated. It has an empty install_manifest and no content. I checked everything multiple times but couldn't figure out what was causing it, so I had to remove the component checking and set CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to elektra-misc.

It would be nice, but if we get maven packages anyway it is not highest priority.

I added the java packages and will change them to /usr/share/maven-repo/<>/*.jar like you proposed as soon as I start working on maven packaging. I also added a package for yamlcpp.

mpranj

Great work! 🏅

Are any further changes planned within this PR or is it ready to merge?

robaerd · 2020-12-17T08:49:29Z

This PR is ready to merge.

I will create a second PR for the RPM packaging as soon as I am done with it.

mpranj · 2020-12-17T10:01:31Z

Thank you, I look forward to the next PR! 😃

markus2330 · 2020-12-17T14:34:17Z

CMakeLists.txt

+set (
+	CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
+	"elektra-misc"
+	CACHE STRING "Default component name" FORCE)


Does this really need to be in the cache? If yes, put it to scripts/cmake/ElektraCache.cmake and use mark_as_advanced as it is not something a normal user wants to change.

Apparently a previous configuration issue led me to cache this variable. This is definetly not needed and a mistake from my side. I will fix this in the upcoming PR, since this one is already merged, if this is fine for you.

Yes, of course it can be fixed with the next PR. But it would be good if it will be fixed before the release as cmake cache variables are user-facing (to maintainers) and should be documented and so on. So better to never introduce this cache variable to any release. Anyway: would be great to have RPM+DEB for next release. Is it your plan to do so?

I was currently working on extending the release automation (ABI tests, external test suites etc) but I can of course also create RPM packages for this release. With our current CPack setup this probably shouldn't be that much work.

sanssecours · 2020-12-30T14:28:38Z

@sanssecours what is missing that you would recommend the plugin more?

The primary reasons is probably that I am still the maintainer of the plugin 😊. I do not think that I will add features that are still missing, such as proper support for

types,
non-leave values, and
binary data.

robaerd added the work in progress label Dec 8, 2020

markus2330 reviewed Dec 11, 2020

View reviewed changes

robaerd removed the work in progress label Dec 11, 2020

markus2330 mentioned this pull request Dec 12, 2020

simplify infos/status #3590

Closed

20 tasks

markus2330 reviewed Dec 12, 2020

View reviewed changes

robaerd added 15 commits December 13, 2020 03:30

cpack: generate modular debian packages

e949962

cpack: add debian package descriptions

1e88436

cpack: add missing debian package properties

74186bf

package: add hardening flags, fix install location

ff1ad5f

cpack: fix libraries in wrong packages

b09f918

cpack: add debian control files

c3159cc

cpack: remove rpath

ac17b16

cmake: remove debug messages

c9fcabb

style: reformat with cmake-format 0.6.3

e210171

package: move script to packaging folder

66cd977

doc: add release notes

9b56875

cmake: add symlink kdb.1 to kdb-static.1

9293bc7

packaging: add copyright file for debian

d7817d4

cpack: install debian copyright file on debian based distros

5d0d079

cpack: add elektra-dbg package

22cf55f

robaerd added 10 commits December 13, 2020 03:30

cmake: fix error on optional macro parameter

7223844

style: reformat

7f02c6b

packaging: apply suggestions from review

ab6d936

doc: change copyright field to reference authors file

6681054

packaging: add debian changelog

97da809

packaging: change folder structure

546d7a0

news: add cpack as highlight to release notes

882feb3

doc: add myself to authors.md

9446af2

packaging: add default component elektra-misc

b72b85a

All files that are not part of a released package are packaged into the elektra-misc package

style: reformat

959ac98

robaerd force-pushed the cpack-debian-packaging branch from d9f349d to 959ac98 Compare December 13, 2020 02:31

news: fix release notes format

71bc1ce

robaerd force-pushed the cpack-debian-packaging branch from 76e017f to 71bc1ce Compare December 13, 2020 03:41

packaging: apply suggestions from review

e9f83c4

mpranj approved these changes Dec 17, 2020

View reviewed changes

mpranj merged commit e478be3 into ElektraInitiative:master Dec 17, 2020

markus2330 reviewed Dec 17, 2020

View reviewed changes

robaerd mentioned this pull request Dec 19, 2020

Continuous Releases #3519

Closed

15 tasks

This was referenced Feb 1, 2021

0.9.4 release #3553

Closed

delete debian branch #3643

Closed

		@@ -0,0 +1,556 @@
		Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

	Source: http://www.libelektra.org/ftp/elektra/releases/
	Source: https://www.libelektra.org/ftp/elektra/releases/

CPack debian packaging #3583

CPack debian packaging #3583

Conversation

robaerd commented Dec 8, 2020 • edited Loading

Basics

Checklist

Review

Labels

robaerd commented Dec 8, 2020

markus2330 commented Dec 8, 2020

robaerd commented Dec 8, 2020

markus2330 commented Dec 8, 2020

mpranj commented Dec 9, 2020

robaerd commented Dec 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

robaerd commented Dec 11, 2020

markus2330 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

robaerd Dec 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markus2330 commented Dec 12, 2020

robaerd commented Dec 12, 2020

robaerd commented Dec 13, 2020

markus2330 commented Dec 14, 2020

markus2330 commented Dec 14, 2020 • edited Loading

petermax2 commented Dec 14, 2020

mpranj commented Dec 14, 2020

robaerd commented Dec 14, 2020

markus2330 commented Dec 15, 2020

robaerd commented Dec 15, 2020

mpranj left a comment • edited Loading

Choose a reason for hiding this comment

robaerd commented Dec 17, 2020

mpranj commented Dec 17, 2020

markus2330 Dec 17, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sanssecours commented Dec 30, 2020

robaerd commented Dec 8, 2020 •

edited

Loading

robaerd Dec 12, 2020 •

edited

Loading

markus2330 commented Dec 14, 2020 •

edited

Loading

mpranj left a comment •

edited

Loading

markus2330 Dec 17, 2020 •

edited

Loading