Closed #1301 via #1328.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1301#event-3641565661___
Rpm-maint mailing list
Rpm-mai
Well, there's not really a way to fix the behaviour of _changelog_trimtime. We
could amend it to keep a minimum number of entries even if they are older.
If we want to keep entries based on a time frame we basically need a new macro.
This of course raises the question of how these features should
Ehm, except that of course the trimtime is in the *past* so that "logic" is
completely flawed. Better not touch anything serious today, clearly :joy:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-sof
Of course, that's incompatible with the existing implementation that takes an
absolute timestamp as the cut-off point. That design is not one of our brighter
moments...
Perhaps we could do a little heuristic and determine any changelog_trimtime
value earlier than "now" as a delta, and if later,
Ooh, that's a nice and elegant solution!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1301#issuecomment-668467332___
Rpm-mai
Guess _changelog_trimtime should be counted from the newest entry to prevent
the changelog depending on the build time. This still limits the changelog to
the same length when building a new release but is stable over time and
rebuilds.
--
You are receiving this because you are subscribed to t
`rpmspec --undefine "_changelog_trimtime" -q --qf "[%{CHANGELOGTEXT}\n]"
--specfile docpkg.spec` (or define _changelog_trimtime to %{nil}) for a more
permanent workaround.
Labeling this as bug though, this is not a sane behavior for changelog trimming.
--
You are receiving this because you are
I changed the date in changelog "Sat Jun 30 2018" --> "Sun Jun 30 2019" and it
works as expected.
@pmatilai Thanks a lot for a temporary (2 years) workaround. It is definitely
better with this workaround than just disabling my unit tests. But the
behaviour is really ugly and hidden.
--
You are
This is simply due to `%_changelog_trimtime` causing the entry to be dropped as
too old, two years is the trim-off point in recent Fedoras. The behavior is
ugly even when building packages, but even worse when querying.
--
You are receiving this because you are subscribed to this thread.
Reply
`rpm -q --qf "[%{CHANGELOGTEXT}\n]" --specfile "docpkg.spec"`
returns exit code 0 and empty result
If `rpm` behaviour is correct, is there other way how to format the query or
modify the specfile to get last changelog record?
--
You are receiving this because you are subscribed to this thread.
```
/repo/docpkg$ rpm -q --qf "%{NAME} %{CHANGELOGTEXT}\n" --specfile "docpkg.spec"
docpkg (none)
/repo/docpkg$ rpm -qa | grep -w rpm
rpm-4.15.1-2.fc31.x86_64
rpm-sign-libs-4.15.1-2.fc31.x86_64
systemd-rpm-macros-243.8-1.fc31.noarch
rpm-build-4.15.1-2.fc31.x86_64
rpm-libs-4.15.1-2.fc31.x86_64
pytho
Looking at the code I understand why this may go wrong but I have not yet found
why it worked before and what changed.
`rpm --specfile` is translated to `rpmspec -q`with popt aliases. By default
rpmspec queries all generated sub packages. So I am kinda confused by you only
get one line. Can yo
Hi,
recently unit tests for `rpkg` tool started failing. I found, that `rpm`
returns a different result than before.
I have simple specfile:
```
Summary: Dummy summary
Name: docpkg
Version: 1.2
Release: 2%{dist}
License: GPL
#Source0:
#Patch0:
Group: Applications/Productivity
BuildRoot: %(mktemp
13 matches
Mail list logo
