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 belie
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
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
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
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
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
Is there any reasonable situation where modification (during build) of
ANY existing files under debian/ is a good idea?
I know modifying existing non-debian/ files is common to patch
source-level problems, but is modifying existing debian/ files wide
spread? Could anyone do a archive-wide non-roo
Maytham Alsudany writes:
> Hi Simon,
>
> On Mon, 2025-02-03 at 13:32 +0100, Simon Josefsson wrote:
> [...]
>> Maybe adding an example for embedded static C object code like this
>> would help clarify the intention.
>
> Would adding the following after the first para
Sean Whitton writes:
> +The value is of the form ``tag=TAGOBJID fp=FINGERPRINT`` where ``TAGOBJID``
> is
> +the Git object ID of the Git tag object, and ``FINGERPRINT`` is the
> +fingerprint (in hexadecimal, without spaces) of the PGP key used to sign the
> +Git tag.
What restrictions on the fo
Maytham Alsudany writes:
> +``Static-Built-Using``
> +~~
> +
> +This ``Static-Built-Using`` field must list source packages with an
> +"exactly equal" ("=") version relation, which had their contents (like
> +source code or data) incorporated into the binary package during the
Jeremy Bícha writes:
> Therefore, I used the format 0~20200916-1 for fonts-noto-color-emoji
Re-reading
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
I wonder if we couldn't make an argument that "upstream_version" is
empty, which actually better reflect that there
"Diederik de Haas" writes:
> On Sun Dec 1, 2024 at 1:09 PM CET, Simon Josefsson wrote:
>> "Diederik de Haas" writes:
>>
>> >> In case you make more than one snapshot per day, you can append a
>> >> snapshot number after the date, e.
"Diederik de Haas" writes:
>> In case you make more than one snapshot per day, you can append a
>> snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
>> This should rarely be necessary.
>
> If a rule is proposed to Policy, then it needs to account for such a
> situation and should
Otto Kekäläinen writes:
>> The commit hash. 007c9af.
>
> OK, thanks.
>
> I disagree here - to me the git commit hash is the single most
> important identifier for the software version if there are no actual
> releases.
FWIW, I used to believe the same but this changed my mind -- gnulib is a
roll
Maytham Alsudany writes:
> In early 2022, Guillem added support for a new Static-Built-Using field to
> dpkg, encouraging packagers to use it over Built-Using to specify
> statically-linked dependencies [2]. The commit message states the following:
>
> This field mimics the previous Built-Using
Would it make sense to change this to use an inclusive list of permitted
characters instead? How about checking the field names that is in use
today, and construct a regexp of permitted symbols out of that?
Starting point: [A-Za-z][A-Za-z0-9-_]*
/Simon
signature.asc
Description: PGP signature
Package: developers-reference
Hi! The bug title suggestion for package removal requests on this page:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removing-packages
is rendered (at least in firefox on debian) as:
The bug title should be in the form RM:package
Note th
Russ Allbery writes:
>>
>>Libraries should be built with threading support and to be
>>thread-safe if the library supports this.
>>
>
> Yes, that's what I'm proposing -- at a guess, you may have misread the
> diff?
>
>>> diff --git a/policy.sgml b/policy.sgml
>>> index
Russ Allbery writes:
> Russ Allbery writes:
>> Kurt Roeckx writes:
>
>>> So it looks to me that _REENTRANT is only used to make some functions
>>> like getlogin_r available.
>
>> I believe that's correct, and the discussion at the last DebConf reached
>> the same conclusion. I think this bit i
Roger Leigh writes:
> I think it is a problem extending to all virtual packages, and I would
> like to see a more general solution which is applicable to all. It
> might be worth revisiting past discussion, for example this thread:
>
> http://lists.debian.org/debian-devel/2006/08/msg01281.html
>
Fabian Greffrath <[EMAIL PROTECTED]> writes:
> Package: debian-policy
> Version: 3.8.0.1
> Severity: minor
>
> Hi,
>
> Policy currently reads:
>
>> 8.2 Shared library support files
> [...]
>> Run-time support programs that use the shared library but are not
>> required for the library to function
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Fri, Apr 11, 2008 at 08:23:19AM +0200, Simon Josefsson wrote:
>>
>> Thanks. But does LinuxThreads need -D_REENTRANT today? The links to
>> the gnulib list I gave suggested that it isn't necessary, but without
>&
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Thu, Apr 10, 2008 at 09:28:03AM +0200, Simon Josefsson wrote:
>> Kurt Roeckx <[EMAIL PROTECTED]> writes:
>>
>> > On Tue, Apr 08, 2008 at 08:22:10PM -0400, Joey Hess wrote:
>> >> Package: debian-poli
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Tue, Apr 08, 2008 at 08:22:10PM -0400, Joey Hess wrote:
>> Package: debian-policy
>> Version: 3.7.3.0
>> Severity: normal
>>
>> You must specify the gcc option `-D_REENTRANT' when building a library
>> (either static or shared) to make the li
Russ Allbery <[EMAIL PROTECTED]> writes:
> Giacomo A Catenazzi <[EMAIL PROTECTED]> writes:
>
>> I think we should add also the license version in the first paragraph,
>> as is stated in the second part, not to confuse users.
>
>> + license, the GNU GPL (v. 2), the GNU LGPL (v. 2 and v. 2.1),
25 matches
Mail list logo
