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

[Simon Urbanek]

Ivan,

thanks, you have clarified the main question I wanted to have answered, so in that case the semantic meaning actually *does* match in R and Debian so I'm perfectly happy to accommodate the old date format as fallback since that will be useful in that context then.

On related topic on the other side: what we could really do is have --build-timestamp try to parse the value and always store the ISO UTC form to make sure that field is always valid (and warn/error if it is not valid), but of course that only works for the future.

Thanks
Simon


> On 27/03/2026, at 21:37, Ivan Krylov <ikrylov using disroot.org> wrote:
> 
> On Thu, 26 Mar 2026 20:46:46 -0500
> Dirk Eddelbuettel <edd using debian.org> wrote:
> 
>> Are we really only talking about parsing an RFC 822 date into an ISO
>> date or is there more going here? If it is this, why can the date
>> (coming in with a regularized format) not be converted as needed?
> 
> R needs the "Built" date to differ between binary builds of the same
> version of the source package for approximately the same purpose as why
> the +b1 suffix is added to version numbers in Debian when rebuilding
> without changing the source. R uses the date as a proxy for
> binary-level dependencies (e.g. cached S4 classes [1] or ABI issues
> with LinkingTo [2]) that "disappear" upon re-installation from source.
> 
> Interestingly, Debian rules for binNMUs [3] seem to fulfil this already:
> 
>> The only file in the source package which is modified by the binNMU
>> is debian/changelog, which gets a new entry for the new version.
> 
> In other words, when a binNMU happens, the Built: date is updated,
> which is what R cares about.
> 
> So, e.g., r-cran-libcoin (1.0-9-1+b1) in bookworm has
> 
> Built: R 4.2.1; x86_64-pc-linux-gnu; 'Sun, 18 Sep 2022 22:43:49 +0000'; unix
> 
> with the binNMU timestamp from changelog.Debian.amd64 and not the
> source package timestamp from changelog.Debian. Actually, I see this
> for all r-cran-* packages with binNMUs that I have installed:
> 
> dpkg -l | \
> awk '
>  ($1=="ii" && $2 ~ /^r-cran-/ && $3 ~ /\+b/){
>   sub("r-cran-","",$2); print $2
>  }
> ' | while read pkg; do
>  srcDate=$(dpkg-parsechangelog \
>   -l /usr/share/doc/r-cran-"$pkg"/changelog.Debian.gz -S Date)
>  binDate=$(dpkg-parsechangelog \
>   -l /usr/share/doc/r-cran-"$pkg"/changelog.Debian.amd64.gz -S Date)
>  pkgDesc=$(dpkg -L r-cran-"$pkg" | grep '/DESCRIPTION$')
>  grep -q "^Built:.*$srcDate" $pkgDesc && echo "$pkg has source date"
>  grep -q "^Built:.*$binDate" $pkgDesc && echo "$pkg has binary date"
> done
> 
> So, while Simon's fix in r89726 avoided the immediate breakage, the
> dates patched in by the Debian build system should be safe to use as
> well. r-cran.mk would just need to use something like:
> 
> builttime := $(shell dpkg-parsechangelog -l$(CURDIR)/debian/changelog -S Timestamp)
> builttimeR := $(shell date -u -d @$(builttime) +"%Y-%m-%d %H:%M:%S UTC")
> builttimeStamp := "--built-timestamp=\"$(builttimeR)\""
> 
> instead of the RFC 5322 format.
> 
> -- 
> Best regards,
> Ivan
> 
> [1]
> https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html
> Also discussed in
> https://stat.ethz.ch/pipermail/r-devel/2023-August/082769.html
> https://stat.ethz.ch/pipermail/r-devel/2025-January/083779.html
> 
> [2]
> https://stat.ethz.ch/pipermail/r-package-devel/2025q1/011376.html
> 
> [3]
> https://wiki.debian.org/binNMU
>