Hi!
On Wed, 2025-05-07 at 12:42:25 +0100, Ian Jackson wrote:
> Package: debian-policy
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> Background: We usually use binNMUs for rebuilds. That involves a
> binNMU-specfic arch-specific d/changelog fragment which is logical
On Wed, May 07, 2025 at 08:39:58PM +0100, Simon McVittie wrote:
> On Wed, 07 May 2025 at 20:57:15 +0200, Bill Allombert wrote:
> > By changing SOURCE_DATE_EPOCH in what is purported to be a 'binary-only
> > upload'
> > we are breaking the reproducible build semantic.
>
> How so? We're changing th
On Wed, May 07, 2025 at 02:39:00PM +0100, Ian Jackson wrote:
>...
> It seems anomalous that we (i) schedule binNMUs on each architecture
> separately but (ii) they must all be aligned. This leads to suggest
> another option
>E. Always schedule rebuilds on all arches, so they all
> have i
On Wed, 07 May 2025 at 20:57:15 +0200, Bill Allombert wrote:
By changing SOURCE_DATE_EPOCH in what is purported to be a 'binary-only upload'
we are breaking the reproducible build semantic.
How so? We're changing the build environment (that's the point of doing
a binNMU) and the version number
Simon Josefsson writes:
> .TH "tld_check_4" 3 "1.11" "libidn" "libidn"
>
> So this puts the version number in the timestamp field and the project
> name (without version number) in the field where the project name and
> version number usually goes.
[...]
> Reviewing this now, I think a slightl
On Wed, May 07, 2025 at 02:39:00PM +0100, Ian Jackson wrote:
>...
>F. Abolish binNMUs and just do no-change source-only uploads.
> tag2upload might make this much easier...
>...
That would not be workable.
For the not uncommon "binNMU 1k packages" case this would not only have
the sign
On 2025-05-07, Andrea Pappacoda wrote:
> On Wed May 7, 2025 at 1:42 PM CEST, Ian Jackson wrote:
>> B. Set S_D_E to the sdate but use the bdate for file mtimes in
>> the .deb. We would need a separate solution for arch-specific
>> archives containing mtimes (and IDK how we would even detec
Russ Allbery writes:
> Simon Josefsson writes:
>
>> I think that solution is covering up the real problem. I believe there
>> is no universal "right" timestamp to put in a man page that you can
>> guess from a generator tool like pod2man. I believe the timestamp is
>> part of the documentation
On Wed, May 07, 2025 at 08:21:00PM +0200, Simon Josefsson wrote:
> I don't think the purpose described in the specification for
> SOURCE_DATE_EPOCH matches the use case here.
sigh. it does. I'm saying this as one of the authors of said specification
and a user of it for around ten years now.
(th
On 2025-05-07, Simon Josefsson wrote:
> My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
> timestamp inside a man page. This is just one of many symptoms that
> will arise from trying to use SOURCE_DATE_EPOCH in an upstream context.
>
> It seems generally better if upstream der
On Wed, May 07, 2025 at 05:58:11PM +0200, Simon Josefsson wrote:
> My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
> timestamp inside a man page. This is just one of many symptoms that
> will arise from trying to use SOURCE_DATE_EPOCH in an upstream context.
You are assuming
On Wed, May 07, 2025 at 08:08:11PM +0200, Simon Josefsson wrote:
> Russ Allbery writes:
>
> > In particular, what "timestamp inside artifacts from the source code"
> > do you believe I should use? I do not have any special access to the
> > upstream release date. Or is the argument that the upstr
Russ Allbery writes:
> Simon Josefsson writes:
>
>> In some upstream packages I put the version number in that field, which
>> at least provide some of the out-of-date protection.
>
> There are two standard footer locations for this kind of information in
> UNIX man pages, one of which is tradit
Ian Jackson writes:
> As the author of a tool, Russ has the option to change the default
> behaviour to leave the date out rather than using SOURCE_DATE_EPOCH.
> Russ of course has to assess what the likely feelings of downstreams,
> about that, are.
I personally as a consumer of man pages find
Simon Josefsson writes:
> I think that solution is covering up the real problem. I believe there
> is no universal "right" timestamp to put in a man page that you can
> guess from a generator tool like pod2man. I believe the timestamp is
> part of the documentation, and IMHO should be provided
Simon Josefsson writes ("Re: Bug#1104854: binNMUs can cause ma-same violations
in eg manpages"):
> Consider a simple package containing two man pages. One is for a tool
> that frequently change and is re-factored and updated on every release.
> The other is for a tool that
Holger Levsen writes:
> On Wed, May 07, 2025 at 05:58:11PM +0200, Simon Josefsson wrote:
>> My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
>> timestamp inside a man page.
>
> SOURCE_DATE_EPOCH was specifically designed for use cases like this: replace
> the build date with
Vagrant Cascadian writes:
> Do tools handling man pages work without a date? I seem to recall trying
> this in the past and the man command spit out all sorts of errors...
Yes, you can suppress the date by passing an empty string into the
appropriate argument to .TH. You can see this behavior wi
Russ Allbery writes:
> In particular, what "timestamp inside artifacts from the source code"
> do you believe I should use? I do not have any special access to the
> upstream release date. Or is the argument that the upstream build
> system should explicitly pass the date for all man pages to pod
On Wed, May 07, 2025 at 05:32:35PM +0100, Simon McVittie wrote:
>...
> [1] a somewhat extreme real-world example: I count 1063 distinct source
> packages in
> https://lists.debian.org/debian-release/2025/04/msg00074.html
That's not an extreme example.
For the regular "Rebuild for outdated Built-U
On 2025-05-07, Ian Jackson wrote:
> Options that I can see:
>
> A. Shared files in ma-same packages are not allowed to embed S_D_E.
> For example, no dates in libopts25-dev's manpages. Other
> situations (eg, other docs) will be handled similarly.
>
> A.0. Implement the above by patching
On Wed, May 07, 2025 at 09:45:50AM -0700, Russ Allbery wrote:
> I'm happy to try to address this problem in the generator, but this is the
> opposite of the direction in which I thought we were going
to be clear (and as just expressed in another mail to this thread), I don't
think we want to reve
On Wed, May 07, 2025 at 05:58:11PM +0200, Simon Josefsson wrote:
> My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
> timestamp inside a man page.
SOURCE_DATE_EPOCH was specifically designed for use cases like this: replace
the build date with source_date_epoch based dates. (w
Simon Josefsson writes:
> In some upstream packages I put the version number in that field, which
> at least provide some of the out-of-date protection.
There are two standard footer locations for this kind of information in
UNIX man pages, one of which is traditionally used for the version and
Simon Josefsson writes:
> My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
> timestamp inside a man page. This is just one of many symptoms that will
> arise from trying to use SOURCE_DATE_EPOCH in an upstream context.
> It seems generally better if upstream derive timestamps
Hi Ian,
On Wed May 7, 2025 at 1:42 PM CEST, Ian Jackson wrote:
B. Set S_D_E to the sdate but use the bdate for file mtimes in
the .deb. We would need a separate solution for arch-specific
archives containing mtimes (and IDK how we would even detect
them - and detecting them seems l
On Wed, 07 May 2025 at 14:39:00 +0100, Ian Jackson wrote:
F. Abolish binNMUs and just do no-change source-only uploads.
I think there is at least rough consensus that binNMUs are not great and
what we ideally want is changelog-only sourceful uploads instead (as
seen as foo_1.2-3build4 in Ub
Ian Jackson writes:
> Simon Josefsson writes ("Re: Bug#1104854: binNMUs can cause ma-same
> violations in eg manpages"):
>> In this case, is the problem triggered by this line?
>>
>> https://salsa.debian.org/debian/autogen/-/blob/8b4268fa779deaba862a7938ee0d5f
Simon Josefsson writes ("Re: Bug#1104854: binNMUs can cause ma-same violations
in eg manpages"):
> In this case, is the problem triggered by this line?
>
> https://salsa.debian.org/debian/autogen/-/blob/8b4268fa779deaba862a7938ee0d5f051860d8e7/debian/rules#L11
If we're
* Johannes Schauer Marin Rodrigues [250507 17:58]:
On Wed, 7 May 2025 14:01:19 +0200 Chris Hofstaedtler wrote:
Thanks for writing this up.
* Ian Jackson [250507 13:45]:
> A. Shared files in ma-same packages are not allowed to embed S_D_E.
>For example, no dates in libopts25-dev's manpage
Hi,
On Wed, 7 May 2025 14:01:19 +0200 Chris Hofstaedtler wrote:
> Thanks for writing this up.
>
> * Ian Jackson [250507 13:45]:
> > A. Shared files in ma-same packages are not allowed to embed S_D_E.
> >For example, no dates in libopts25-dev's manpages. Other
> >situations (eg, other d
* Holger Levsen [250507 17:16]:
On Wed, May 07, 2025 at 02:01:19PM +0200, Chris Hofstaedtler wrote:
I'll also propose another option, lets call it D:
not that it matters much (see below) but I think i had proposed this
on irc earlier :)
Yes, sorry. Option D is "Holger's Option D".
On Wed,
My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
timestamp inside a man page. This is just one of many symptoms that
will arise from trying to use SOURCE_DATE_EPOCH in an upstream context.
It seems generally better if upstream derive timestamps inside artifacts
from the source
On Wed, May 07, 2025 at 02:01:19PM +0200, Chris Hofstaedtler wrote:
> I'll also propose another option, lets call it D:
not that it matters much (see below) but I think i had proposed this
on irc earlier :)
On Wed, May 07, 2025 at 02:39:00PM +0100, Ian Jackson wrote:
> Gosh, this is all very comp
[Re-sending to the bug rather than the debian-policy@ list, sorry for
the duplicate delivered to list subscribers]
On Wed, 07 May 2025 at 13:48:19 +0100, Ian Jackson wrote:
Rebuilds are arch-specific, so the binNMU
number can vary across architectures, just as the bdate can:
https://packages.d
We need to consider the trixie freeze:
Ian Jackson writes ("binNMUs can cause ma-same violations in eg manpages"):
> Options that I can see:
I think the only ones that are acceptable right now (including of the
D E and F mentioned later in this bug), given that toolchain updates
are out of the qu
Simon McVittie writes ("Re: Bug#1104854: binNMUs can cause ma-same violations
in eg manpages"):
> On Wed, 07 May 2025 at 13:48:19 +0100, Ian Jackson wrote:
> >Rebuilds are arch-specific, so the binNMU
> >number can vary across architectures, just as the bdate can:
> &g
Chris Hofstaedtler writes ("Re: Bug#1104854: binNMUs can cause ma-same
violations in eg manpages"):
> I'll also propose another option, [...]
>
> [D.] Set S_D_E to sdate + an offset in seconds of int(binNMU-number).
I don't see how this helps. Rebuilds are arch-s
Thanks for writing this up.
* Ian Jackson [250507 13:45]:
A. Shared files in ma-same packages are not allowed to embed S_D_E.
For example, no dates in libopts25-dev's manpages. Other
situations (eg, other docs) will be handled similarly.
I think we are already in this situation, and al
Package: debian-policy
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
Hi everyone. I'm filing this against policy but it's not clear which
package(s) need to be changed. We might decide to change sbuild
and/or dpkg-source and/or dh and/or lintian; we might decide to chang
40 matches
Mail list logo
