[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Invalid check in debian/patches





On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote:
Quoting Simon McVittie (2025-02-01 14:21:38)
On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote:
Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378

I believe the intended DEP-3 syntax for this is:

Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378

so using that instead of Bug-Upstream might help?

My understanding is that the Bug-<vendor> convention is intended
for other downstreams, which might be Debian, a Debian derivative like
Ubuntu, or sometimes an unrelated downstream like Fedora that has provided
useful/relevant information in their record of the equivalent bug.

Agreed that *ideally* an URI for the forwarded bug is provided. But does
the omission *invalidate* the data points of "yes, it has been forwarded
somewhere not mentioned, and has also been forwarded to some downstream
confusingly labelled "Upstream"?
With regards to other possible values (No, NotNeeded), I find it a bit hacky to use this field to provide an upstream bug URL.
I would completely remove this practice and keep this field human readable and understandable to be a simple tri-state field (Yes, No, Not-Needed).

I suggest to go ahead and file a bug against the service, suggesting to

Sure I'll do that.
clarify (e.g. using a hover string) what causes an invalidation, and
also to choose a different keyword (e.g. "ambiguous" or "weak") when
strictly speaking it is not invalid per the spec but just somehow not
ideal.
  • Bug-<Vendor> or Bug (optional)
    It contains one URL pointing to the related bug (possibly fixed by the patch). The Bug field is reserved for the bug URL in the upstream bug tracker. Those fields can be used multiple times if several bugs are concerned.
    The vendor name is explicitely encoded in the field name so that vendors can share patches among them without having to update the meta-information in most cases. The upstream bug URL is special cased because it's the central point of cooperation and it must be easily distinguishable among all the bug URLs.
My understanding is that this applies to two kind of bug trackers:
  1. Upstream using Bug
  2. Downstream using Bug-<vendor>

In my case I used Bug-Upstream because I found it on an other patch, but this point is not very clear in the spec and I would suggest we rewrite it to make is more explicit.
-- 
Cheers,
Abou Al Montacir

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: