+1 for reverting

What are the merits and demerits for this new date time format?

Given https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs I don't think adding the time is supported. Especially when parsing the name of the changelog-er, adding more fields to the date stamp make things harder. Please revert and discuss this on devel if needed.

The changelog section in the guidelines does not specifically indicate that full timestamps are not supported, only that a specific structure must be used that includes a variant of the EVR to indicate what version that entry is associated with. (Also, people have been using the newer timestamp format for at least two years now in Fedora, and this is the first time I'm hearing of someone complain...)

That said, since rpmdevtools is upstream, I do not specifically want to revert because someone in Fedora is uncomfortable without a decent justification.

I am, however, willing to consider adding a way to switch to the pre-RPM 4.14 format for those who are trying to target RHEL 7/SLE 12 still.

@ngompa could you please provide justification for including the time? I understand it is supported by RPM, but that is not reason. Even the date is commonly problematic, but time, really? Should I just delete the time all the time manually? What is the utility of this tool then?

The changelog timestamp is the source for SOURCE_DATE_EPOCH in rpm, which is used to clamp timestamps all over the RPM, including in build dates and such. Without a fully qualified timestamp, it gets hard to sort reproducibly-build RPMs where multiple builds have occurred with multiple changelog entry bumps in the same day without EVR bumps. Some distros do, in fact, do this, and I'm doing it myself for stuff as well.

@ngompa thx for the explanation.

However, I don't understand, why somebody would have "multiple builds in the same day without EVR bumps" and why I should care about such situation. This is not how things works in Koji.

Also, if you are serious about it, I still think this should be discussed and explained to broader audience then just push some commit (it was not you I know, but you are here defending the change, so I assume you knew about it), which does not even bother to include the information.

Package "Build Date" is entirely separate from %changelog entries. No sorting based on changelog entries is done. And they are sorted implicitly anyway. Latest at the top.

It escapes me why a tool would add time and TZ to changelog entries while packagers don't when they maintain the %changelog themselves. Either "all or nothing". Else it doesn't make any sense.

The package build date can be forced to SOURCE_DATE_EPOCH. It's not enabled by default in Fedora. It is in other distributions.

Once more:

It won't work, if most %changelog entries don't specify time and TZ because packagers only add the date.

Also, SOURCE_DATA_EPOCH is an env var, and nothing mandates that it is to be populated with the timestamp from the most recent changelog entry. Which distribution relevant to Fedora pulls the timestamp from the %changelog?

Which distribution relevant to Fedora pulls the timestamp from the %changelog?

Fedora sets SOURCE_DATA_EPOCH based on the most recent (or top most, not sure) changelog entry.

Which distribution relevant to Fedora pulls the timestamp from the %changelog?

Fedora sets SOURCE_DATA_EPOCH based on the most recent (or top most, not sure) changelog entry.

The most recent is always the top changelog entry, and yes, that's what SOURCE_DATE_EPOCH is sourced from.

Which distribution relevant to Fedora pulls the timestamp from the %changelog?

Fedora isn't the only distribution that uses rpmdevtools, you know. Fedora does not get to "win" all arguments by default. But that being said, Fedora itself does this, as does Red Hat Enterprise Linux, as of version 8, by virtue of inheriting it from Fedora.

@ngompa thx for the explanation.

However, I don't understand, why somebody would have "multiple builds in the same day without EVR bumps" and why I should care about such situation. This is not how things works in Koji.

It actually can work this way in Koji, and I know of a few instances that do it that way. Fedora's Koji isn't one of them (thank goodness for that small mercy!), but other build systems do permit this normally (OBS, COPR, YOURI, ABF, etc.).

The option --legacy-datestamp/-D has been added to rpmdev-bumpspec in version 9.1

@ngompa Could you please at least do me a favor and go to Fedora devel ML, announce that this was changed and what is the purpose?

Also, EPEL7 build system does not support time, triggering build failures

I see packagers surprised by this. Especially since EPEL 7 does not accept timestamp in changelogs (I've been told). Once again I express my opinion that:

1) this is the wrong default

2) this was not communicated loudly enough

See also https://pagure.io/releng/issue/9894

@churchyard I tend to agree. Adding the new format as an opt-in is fine, but switching the default was probably too early. I'm running rpmdev-bumpspec with -D flag always now ...

It also doesn't help that I used syntax highlighting to show me whether a changelog datestamp was valid, and now it always "fails" because it doesn't recognise the new format yet :)

I had no idea this was being used as a default. It's indeed not a good idea as the rpm feature is flawed and it's not clear if it's at all fixable in it's current form [1]. So I'd recommend going back to the old format, but at the very least only ever use an UTC offset as the timezone, that is the part of the rpm feature that has the best chance of surviving.

[1] https://github.com/rpm-software-management/rpm/pull/739

+1 to reverting the change by default. For 99% of use cases, the time is just noise.

+1 to reverting.

+1 to reverting. I don't think datetime and timezone are useful at all.

The only thing it's useful for is for better setting SOURCE_DATE_EPOCH. But almost no packages in fedora use this ...

Is it possible to simply check the previous changelog entry to see if it includes the time and then just do what it does? That way packages which don't use the time in changelog entries don't suddenly acquire it, and packages which are using it don't lose it.

The only thing it's useful for is for better setting SOURCE_DATE_EPOCH. But almost no packages in fedora use this ...

Plenty of packages are automatically using it. A lot of build scripts do different behavior based on the presence and value set in that shell variable. In most cases, you don't do anything yourself to have the builds take advantage of it.

+1 for reverting

meanwhile I'm happy with my new alias :smile:
alias rpmdev-bumpspec='rpmdev-bumpspec -D'

This has appeared in my copy of rpmdev-bumpspec now. I think we should revert it, or turn it into an option for people who want timestamps.

will someone revert this change? looks like nobody wants this feature for now.

I think there are better chances reverting this downstream in Fedora, since it does not look upstream would be willing to change the defaults.

Downstream maintainers are pretty much the same people ;)

Plenty of packages are automatically using it. A lot of build scripts do different behavior based on the presence and value set in that shell variable. In most cases, you don't do anything yourself to have the builds take advantage of it.

@ngompa does this mean we really have to set the date format of the SOURCE_DATE_EPOCH to the changelog date? Can we manage both the format of SOURCE_DATE_EPOCH and the changelog described date format separately?

Downstream maintainers are pretty much the same people ;)

Even when they are the same people, can we apply the patch on Fedora (downstream)?

@ngompa does this mean we really have to set the date format of the SOURCE_DATE_EPOCH to the changelog date? Can we manage both the format of SOURCE_DATE_EPOCH and the changelog described date format separately?

No. SOURCE_DATE_EPOCH is computed automatically based on the time of the most recent changelog entry, whether it has time information or not. And as far as I can tell, it's formatted in seconds since Unix epoch, so there's no datetime formatting involved at all.

Downstream maintainers are pretty much the same people ;)

Even when they are the same people, can we apply the patch on Fedora (downstream)?

Based on the feedback, and as one of the upstream/downstream maintainers, I would revert "downstream" back to the "old" behaviour as the default, with the new one being opt-in for people who actually want it.

Normally we do a downstream patch when the issue is a temporary workaround while dependencies are updated or a downstream-specific issue. But in this particular seems that the change was just misguided, and doesn't make much sense for any distro. Why not just revert it usptream, or at least wait for definite answer from upstream? (Especially that the same people are involved in both places. If they support revert downstream, they will most likely have the same opinion for upstream.)

Here's the issue: if I revert this, no one will adapt and things will never get fixed.

My experience with other changes around RPM ecosystem tooling makes me very biased towards not reverting. I caved a little and added an option to use the old format, but I don't want it to be the default because I want everything to be fixed to expect the full timestamp format.

The more complete timestamp makes it saner for reproducible builds stuff, and build-compare stuff I work with on COPR/OBS-based builds.

I need an extremely strong justification for a downstream revert in Fedora. But I will not revert it upstream.

I think that's the misunderstanding: people don't just have an issue with this because tools that consume the changelog are confused. Most commenters think the timezone is pointless and unnecessary:

It escapes me why a tool would add time and TZ to changelog entries while packagers don't when they maintain the %changelog themselves.

@ngompa could you please provide justification for including the time? I understand it is supported by RPM, but that is not reason. Even the date is commonly problematic, but time, really?

It's indeed not a good idea as the rpm feature is flawed and it's not clear if it's at all fixable in it's current form

For 99% of use cases, the time is just noise.

I don't think datetime and timezone are useful at all.

Detailed timestamp information is only useful to set SOURCE_DATE_EPOCH. And nothing says that SOURCE_DATE_EPOCH must be set precisely to the time when the package is built. It is good to roughly keep it in sync with the actual time, but it certainly doesn't have to reflect the precise time the spec file was last updated. And even if you wanted to do that, it doesn't work for this purpose: it is rather usual to make changes to the .spec file without touching the changelog. For example to fix the build or upload missing sources or do other tweaks that don't require a changelog entry. So the precise timestamp in the %changelog is both too much and not enough.

Indeed, the new changelog format is mostly just a PITA for both humans and computers.
It's not as if a SOURCE_DATE_EPOCH needs it in any way, the changelog timestamp is just a timestamp which the old format sets to UTC noon, and nobody cares if a spec change was made at 9 AM UTC-8 or at noon. If the point is to differentiate between the entries made on a same day, it should be easy to increment seconds/minutes per changelog entry on a given day.

I want everything to be fixed to expect the full timestamp format.

@ngompa , just to make this clear: the full timestamp format is frowned upon at upstream rpm, because it's fundamentally broken as it is [1]. I really don't want you or anybody else to be pushing that format anywhere at all in its current form. Like said earlier, if you "must" use it for something, limit it to UTC offsets only, as that style should be preservable. Better yet, stop pushing for it at all until https://bugzilla.redhat.com/show_bug.cgi?id=1715412 is resolved one way or the other. We can differentiate timestamps without this madness.

[1] See the despair in https://github.com/rpm-software-management/rpm/pull/739

If the new format is used on my packages for the f34 mass-rebuild I will be orphan all my epel7 branches.

Here's a PR to get rpm to produce unique, reproducable timestamps using the good ol' changelog format: https://github.com/rpm-software-management/rpm/pull/1511

@pmatilai Fine. I'll change it in Fedora. I'm still not changing it in upstream, because I have a very sneaky suspicion that if I do, you'll not bother to fix the full timestamp format (which I actually do need).

Also, as for the rest of you, especially @mschwendt and @leigh123linux, you've demonstrated your worst in this ticket. I hope you don't think this is acceptable conduct to communicate with upstreams, because if you do, you do a disservice to the community at large.

When you do, please make sure to include https://pagure.io/rpmdevtools/pull-request/70

Thanks.

@churchyard It'll be included, I'm making a new release and will stack a Fedora-specific patch on top.

Nice, thanks @ngompa!

@ngompa - what exactly do you need the full stamp for - that isn't resolved by my rpm PR?

When the timestamp is computer generated (such as git commits) it'd be plain stupid not to include a full timestamp, and if VCS commits or other automation is used for creating changelog entries, its quite fine - as long as an UTC offset is used as the timestamp. People manually putting whatever they think they're timezone abbreviation might be is a recipe for disaster.

So again - I don't see the full timestamp support being removed from rpm, but it likely has to stop pretending to support human-friendly timezone names.

I have three major reasons for full timestamps:

1. I do conversions from Debian to RPM and back for changelogs. Without full timestamps with proper timezone support, this is lossy and that's unacceptable.

2. I'm working with infrastructure that has systems working in multiple timezones for package build and promotion.

3. I don't work in UTC, and I do multiple changes in a day, and I want the precision and the ability to map it back to the datestamp of a commit or whatever for reproducible builds.

Right. Which is all fine - as long as you use an UTC-offset for the timezone. Like Debian changelog, and git, and practically everything else does. That's supportable and I've no problem with it. But that's not what the current rpmdev-newspec does, so this is all causing more and more damage that will need to be some day be resolved. Have rpmdev-foo adopt a +- UTC offset for the timezone part and I have no issues with it.

I should also mention that I'm converting from SUSE style changes files, which use timezone names, just to add a wrinkle to that.