R devel - Mar 2026 - recent changes to r-devel with package date checking?

Dirk,

> On 27 Mar 2026, at 10:35, Dirk Eddelbuettel <edd at debian.org>
wrote:
> 
> 
> Hi Simon,
> 
> On 27 March 2026 at 09:57, Simon Urbanek wrote:
> | can you clarify one thing for me? In principe, if I read the Debian specs
> | correctly[1] using the changelog date creates an entry that is
semantically
> | incorrect for this field since it is the *source* change time, so does
not
> | reflect any re-builds, but whether that matters for our purpose depends.
> 
> Let's step back for a second as I think you are reading something into
the
> 'builttime' stamp that is not there. 
> 
> Recall that *everything* in Debian works off *package versions* and their
> sorting. Always has. Likely always will be. CRAN copied that. 1.2-3 is
older
> than 1.2-4.
> 
> The timestamp never entered, and never will. The timestamp, as per my
earlier
> email in the thread, ensures that two binary builds are identical _because
we
> impose an 'available recent time'_ (of when the maintainer last
updated the
> package) simply because it shadows the package version sorting.  But again,
> the whole point of the (fixed) timestamp is to reduce (arbitrary) variation
> in the build artifact even when sources and build systems are fixed (and
> variation is caused from reflecting current time in the build, a source of
> variation).
> 
> We can look at an example. As I tend to be on Ubuntu (which does more
> rebuilds for syncs anyway) I just glanced into the rocker/r-base container
> (aka r-base). And a few packages in we have 'bzip_1.0.8-6+b1' --
the sixth
> Debian variant of upstream 1.0.8, and here in '+b1' rebuilt because
> _something_ in the toolchain required it. That is triggered and executed by
> _the archive maintainers_ as opposed to the package maintainer -- and as a
> purely binary rebuild _it has no changelog entry_ and hence no timestamp to
> reason.
> 

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).

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 at debian.org
>

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 at paul:~/deb/r-base(master)$ awk '/^ -- / {print $6, $7, $8, $9,
$10}' debian/changelog | wc -l
542
edd at 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 at 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 at 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 at debian.org
| > 
| 

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