#1392 PR merged: Simplify Makefile

Labels: enhancement, cleanup, fixed / solved / done

schlomo opened issue at 2017-06-22 22:01:

  • use git infos (rev count, hash, branch) in development version
  • put resulting dist files in dist/
  • not patch the working copy (removed rewrite/restore)
  • use debuild to build debian package

Contributes to #1362

This is work in progress and for sure needs more attention for the OBS parts, @gdha can you have a look and tell me what you think? Next would be to enable building packages from a zip clone without git.

schlomo commented at 2017-06-23 07:19:

@gdha I fixed the remaining issues I had and now this is ready for you to look.

What exactly do you need for OBS? I had to remove building a Debian source package for now (couldn't figure out how to tell it which tar.gz to use) but I can try to put it pack in if you need that for OBS.

schlomo commented at 2017-06-23 08:25:

Another thought about OBS: I would love to somewhat detach the OBS builds from our other builds, ideally we should be able to feed a dist tar.gz into OBS.

Another thought about the debian changes file: We can use gbp dch to auto-create the changes file from the git log. OTOH if this changes file is only used for dev builds then we can also do away with it completely.

In general I wonder which "official" build for a distro actually depends on what we do in the ReaR source tree.

gdha commented at 2017-06-23 13:44:

@schlomo works well, but I do not like the wording .dirty - I would rather see .unstable - any objections to change that? For the rest I'm fine for the check-in into our master tree.

gdha commented at 2017-06-23 13:54:

@schlomo I like the following output of the command:

git log --format="* %cd %aN%n- (%h) %s%d%n" --date=local | sed -r 's/[0-9]+:[0-9]+:[0-9]+ //'

What do you think?

schlomo commented at 2017-06-23 14:04:

I personally like the word dirty because it makes it very clear that this is not good for anything serious. Unstable could be also read as unstable release, similar to Debian unstable. So how about one of these: .changed, .modified, .unclear, .notcommitted, ...? Any of these are fine with me.

About the log, do you mean for filling the change log automatically? Then maybe like this:

$ git log --format="* %cd %aN%n- (%h) %s%d%n" --no-merges --date=short  | head
* 2017-06-22 Gratien D'haese
- (cd00e46d) Makefile: remove . before * as suggested by @schlomo Concerns issue #1389 (HEAD -> master, origin/master, origin/HEAD)

* 2017-06-22 Gratien D'haese
- (b958cde4) The 'make rpm' now relies on 'make srpm' which creates the src.rpm package first. This src.rpm package can then be easily copied to another computer to rebuild a rpm package from it without needed the sources itself (or git checkout). Concerns issue #1389 - verification still required on OBS to see the nightly builds are performed as usual

* 2017-06-21 Vladimir Gozora
- (5150dd2a) Minor correction of conditional missed by previous commit.

I did not manage to get it to properly show multi-line comments that have bullets. --no-merges saves about 2000 lines of probably useless information and --date=short saves us the sed :-)

gdha commented at 2017-06-23 15:40:

@schlomo Ok I'm fine with the word .changed - does not have a negative sound like dirty (just a personal preference that is).

Indeed a kind of automatic changelog could be created for perhaps OFFICIAL=1 (official releases only)? I was just a thought as I came across a nice example of this feature.

schlomo commented at 2017-06-25 10:16:

OK, let's go for .changed. Will you merge this PR? Also, what is the change in the man page in your last commit?

gdha commented at 2017-06-26 07:18:

@schlomo change in man page was probably a rebuild only as I did not modify the source file (rear.8.adoc)

schlomo commented at 2017-06-26 08:11:

I see. Can you update the Makefile to not touch the source work dir at all? Now that we have build/<name>-<version> we should IMHO do all the patching and building in there.

[Export of Github issue for rear/rear.]