[Rd] recent changes to r-devel with package date checking?

[Dirk Eddelbuettel]

Hi Simon,

On 27 March 2026 at 13:58, Simon Urbanek wrote:
| I was afraid of that, thanks for confirming. In that case this won't work, i.e., it cannot be just the source changelog, that is the wrong semantic information - you would have to update it in that case. The whole point of the Built timestamp is exactly to make sure it changes when the binaries change so it can be distinguished from any previously built binary, that is the definition of that field - they cannot be the same if the contents differ. Based on what you said we will simply ignore those if they are not correctly formatted as "legacy", since it is impossible for this to work anyway the way you are overriding it. To produce a valid entry you'll have to make sure they are set to the build timestamp (or in your world the maintainer build timestamp if I read that correctly, i.e., the timestamp when the new b... version was created) in the ISO form (or leave it untouched).

I will admit that I no real idea what you are talking about, and what the
current actual or perceived change is.

Debian has signed its (package internal) changelog entries with the exact
same RFC 822 (then current) form since the 1990s. This has not changed.  See
below for samples from r-base maintained by Doug (initially) and myself. The
file is also at https://sources.debian.org/src/r-base/4.5.3-1/debian/changelog

As nothing changed on our end, if your processing now breaks it's not us. I
am sure you can sort it out, but I am afraid I may not be able to help as you
are not making yourself very clear (or maybe I just had a busy day...)

Cheers, Dirk


edd using paul:~/deb/r-base(master)$ awk '/^ -- / {print $6, $7, $8, $9, $10}' debian/changelog | wc -l
542
edd using paul:~/deb/r-base(master)$ awk '/^ -- / {print $6, $7, $8, $9, $10}' debian/changelog | head -5
11 Mar 2026 07:09:46 -0500
11 Mar 2026 06:42:01 -0500
31 Oct 2025 06:47:11 -0500
31 Oct 2025 06:00:34 -0500
16 Jun 2025 07:07:46 -0500
edd using paul:~/deb/r-base(master)$ awk '/^ -- / {print $6, $7, $8, $9, $10}' debian/changelog | tail -5
14 Jan 1998 08:31:53 -0600
12 Jan 1998 09:30:04 -0600
4 Jan 1998 14:54:04 -0600
23 Dec 1997 12:02:09 -0600
23 Dec 1997 10:01:21 -0600
edd using paul:~/deb/r-base(master)$

| Cheers,
| Simon
| 
| 
| 
| > Everything sorts by _version_.
| > 
| > | So the question is: if a package needs to be re-built (=new binary needs to
| > | be created) due to either another package's ABI change (classic example was
| > 
| > It is guaranteed to get a new _version number_. There is an entire
| > (elaborate) system of suffixes, usually '+b1' (for first binary rebuild)
| > for unchanged sources. Changes source, of course, get a new versison.
| > 
| > | Matrix, but there are other S4 cases), does that trigger in Debian a new
| > | source release with updated changelog even if the actual sources for the
| > | package don't change?
| > 
| > Again, a valid question, but one 100% unrelated to 'builttimeStamp'. I am
| > happy to go over how r-cran-matrix was or was not rebuilt. In that example, I
| > think we may have forced new source minors (repeatedly) but it has been a
| > while. And given the above, as these would be _maintainer_ rebuilds not
| > archive rebuilds a new version number, or just a Debian minor, makes sense.
| > 
| > Let me know if I misunderstood something but it seems to me that you were
| > inferring issues simply not present here. Hope the explanation makes sense.
| > 
| > Cheers, Dirk
| > 
| > -- 
| > dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
| > 
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org