propose-update does not generate proper changelog from release tag

As discussed in issue #298, the idea was that the changelog gets generated from the upstream release tag (or the github description, etc). I think that even worked right when I tested that, but it seems to have regressed. For cockpit-ostree 179 it now just generates:

--- a/cockpit-ostree.spec
+++ b/cockpit-ostree.spec
@@ -1,12 +1,17 @@
 Name: cockpit-ostree
-Version: 178
+Version: 179
 Release: 1%{?dist}
 BuildArch: noarch
 Summary: Cockpit user interface for rpm-ostree
 License: LGPLv2+
 Requires: cockpit-bridge >= 125
 Requires: cockpit-system >= 125
-Requires: /usr/libexec/rpm-ostreed
+# On RHEL Atomic 7, the package name is different (curiously not on CentOS Atomic)
+%if 0%{?rhel} == 7
+Requires: rpm-ostree-client
+%else
+Requires: rpm-ostree
+%endif
 
 # Download from https://github.com/cockpit-project/cockpit-ostree/releases
 Source: cockpit-ostree-%{version}.tar.gz
@@ -27,6 +32,9 @@ find %{buildroot}%{_datadir}/cockpit/ -name '*.map' | xargs rm --verbose
 %{_datadir}/cockpit/*
 
 %changelog
+* Wed Jul 24 2019 Martin Pitt <[e-mail]> - 179-1
+- new upstream release: 179
+
 * Fri Jul 12 2019 Martin Pitt <[e-mail]> - 178-1
 - new upstream release: 178

(that’s just the .spec change, ignoring changes to sources and .gitignore).

This is a bit sad, the changelog should include some useful information, bug refs, etc. I did 178 with an earlier packit master as well, same problem (but that was after #298 landed).

❱❱❱ git -C ~/tmp/packit/ rev-parse HEAD
efb466df8567c2050b09f6854b515250ac1dfa7a

[lachmanfrantisek]

I am not sure about the priority, but it looks still relevant to me.

[martinpitt]

Maybe I was just imagining that it worked before then? Ideally we want to copy the upstream git tag description, i. e. what can be seen on the GitHub /releases page. In this case:

 %changelog
* Wed Jul 24 2019 Martin Pitt <[e-mail]> - 179-1
- spec: Depend on package instead of file path (rhbz#1731687)
- Add packit configuration

If packit can’t or doesn’t want to (for clean architecture reasons) look at the tag, would it be possible to feed that in through an option?

Edit: @TomasTomecek highlighted the request a bit