Invalid check in debian/patches

[Abou Al Montacir]

Hi All,

According
to https://udd.debian.org/patches.cgi?src=lazarus&version=3.8%2Bdfsg1-4 my
package have a patch with invalid metadata. There seem to be that the tool
considers the following as an error:
Forwarded: Yes
Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378

This is despite that https://dep-team.pages.debian.net/deps/dep3/, which is

* Forwarded (optional)Any value other than "no" or "not-needed" means that the
patch has been forwarded upstream. Ideally the value is an URL proving that
it has been forwarded and where one can find more information about its
inclusion status.If the field is missing, its implicit value is "yes" if the
"Bug" field is present, otherwise it's "no". The field is really required
only if the patch is vendor specific, in that case its value should be "not-
needed" to indicate that the patch must not be forwarded upstream (whereas
"no" simply means that it has not yet been done).

So the natural value "yes" is considered as an error, just because the (not so)
ideal value is not used.

Without arguing too much why using "Forwarded" followed by "Bug-upstream" is
much better than the ideal proposed value, I consider that the check tool
implementation is wrong. However I would like to hear from others what do they
think before asking to relax the check.

[Jonas Smedegaard]

Hi Abou,

Quoting Abou Al Montacir (2025-02-01 13:13:32)

Post by Abou Al Montacir
According
to https://udd.debian.org/patches.cgi?src=lazarus&version=3.8%2Bdfsg1-4 my
package have a patch with invalid metadata. There seem to be that the tool
Forwarded: Yes
Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378
This is despite that https://dep-team.pages.debian.net/deps/dep3/, which is

* Forwarded (optional)Any value other than "no" or "not-needed" means that the
patch has been forwarded upstream. Ideally the value is an URL proving that
it has been forwarded and where one can find more information about its
inclusion status.If the field is missing, its implicit value is "yes" if the
"Bug" field is present, otherwise it's "no". The field is really required
only if the patch is vendor specific, in that case its value should be "not-
needed" to indicate that the patch must not be forwarded upstream (whereas
"no" simply means that it has not yet been done).

So the natural value "yes" is considered as an error, just because the (not so)
ideal value is not used.
Without arguing too much why using "Forwarded" followed by "Bug-upstream" is
much better than the ideal proposed value, I consider that the check tool
implementation is wrong. However I would like to hear from others what do they
think before asking to relax the check.

I agree with your interpretation, that "Forwarded: Yes" is legal, and
therefore a parser that flags that as illegal is a broken parser.

That said, I find it superfluous to ever state "Forwarded: Yes", because
it is never sensible to state that without also stating to *where* it is
forwarded, and stating that implies "Forwarded: Yes" - as you also quote
above.

- Jonas

[Simon McVittie]

Post by Abou Al Montacir
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.

smcv

[Jonas Smedegaard]

Quoting Simon McVittie (2025-02-01 14:21:38)

Post by Simon McVittie

Post by Abou Al Montacir
Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378

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"?

I suggest to go ahead and file a bug against the service, suggesting to
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.

- Jonas

[Abou Al Montacir]

Post by Jonas Smedegaard
Quoting Simon McVittie (2025-02-01 14:21:38)

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

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

Post by Jonas Smedegaard
I suggest to go ahead and file a bug against the service, suggesting to

Sure I'll do that.

Post by Jonas Smedegaard
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.

[Jeremy Bícha]

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

The vast majority disagree with you on the Forwarded field (4000ish to
almost 600) but Forwarded: yes is used a lot.

https://codesearch.debian.net/search?q=path%3Adebian%2Fpatches+Forwarded%3A+yes
https://codesearch.debian.net/search?q=path%3Adebian%2Fpatches+Forwarded%3A+http

A Forwarded link is human-readable and machine-readable. Also, Github
and Gitlab separate issues from merge requests so it's possible to
have two different upstream links. Personally, I would probably just
use the merge request link instead of the issue link in this case
though.

Thank you,
Jeremy Bícha

[Jonas Smedegaard]

Quoting Abou Al Montacir (2025-02-01 16:13:44)

Post by Abou Al Montacir

Post by Jonas Smedegaard
Quoting Simon McVittie (2025-02-01 14:21:38)

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

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

If you are proposing a change to the definition of DEP-3, then do you
really think that the benefit of such change outweight the burden of
updating current machinery and declarations? Because I fail to see it.

If not a proposal for change, then what is your point of mentioning it?

Post by Abou Al Montacir

Post by Jonas Smedegaard
I suggest to go ahead and file a bug against the service, suggesting to

Sure I'll do that.

Post by Jonas Smedegaard
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.

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.

I agree that it might make sense to refine the non-formal parts of DEP-3
to avoid misunderstanding.

I made same mistake when I began using DEP-3. :-)

- Jonas

[Abou Al Montacir]

Hi Jonas,

Post by Jonas Smedegaard
Quoting Abou Al Montacir (2025-02-01 16:13:44)

Post by Abou Al Montacir

Post by Jonas Smedegaard
Quoting Simon McVittie (2025-02-01 14:21:38)

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

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

If you are proposing a change to the definition of DEP-3, then do you
really think that the benefit of such change outweight the burden of
updating current machinery and declarations?  Because I fail to see it.

I would love to, but as Jeremy spotted out, I'm minority (600 vs 4000) so no.

Post by Jonas Smedegaard
If not a proposal for change, then what is your point of mentioning it?

That tools do not enforce practice by stating that other practices are errors
(which may explain the above mentioned majority)

Tools are here to enforce rules, not to enforce a particular way to comply to
them.
I hope this is clear enough.

Post by Jonas Smedegaard

Post by Abou Al Montacir

Post by Jonas Smedegaard
I suggest to go ahead and file a bug against the service, suggesting to

Sure I'll do that.

Post by Jonas Smedegaard
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.

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.

I agree that it might make sense to refine the non-formal parts of DEP-3
to avoid misunderstanding.
I made same mistake when I began using DEP-3. :-)

If you made a mistake, and I made it, and many made the same, then the spec is
not clear enough.

But also, in this particular case, it's not the issue of the spec but of a
particular tool trying to enforce the rule.

I'll file a bug to fix it.

[Abou Al Montacir]

Hi,

Post by Abou Al Montacir
But also, in this particular case, it's not the issue of the spec but of a
particular tool trying to enforce the rule.
I'll file a bug to fix it.

I finally found many reports already dealing with this issue in the bug tracker.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043043
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034102

Above two bugs are reporting very similar problems.

The following bug was closed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028503
But I find it no clear consensus there that it could be closed with the current
situation.

So I'm reporting this here again to ask what can be done to fix this issue that
seems to wait for more than one year?

[Guillem Jover]

Hi!

Post by Abou Al Montacir

Post by Abou Al Montacir
But also, in this particular case, it's not the issue of the spec but of a
particular tool trying to enforce the rule.
I'll file a bug to fix it.

I finally found many reports already dealing with this issue in the bug tracker.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043043
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034102
Above two bugs are reporting very similar problems.
The following bug was closed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028503
But I find it no clear consensus there that it could be closed with the current
situation.

There is also <https://bugs.debian.org/1031381>, and I started a
discussion on this list with the stuff I think was collected as being
unclear and worth improving or clarifying at [M], but AFAIR the driver
of the DEP stated not having time to handle that work.

[M] https://lists.debian.org/debian-devel/2023/08/msg00067.html

Post by Abou Al Montacir
So I'm reporting this here again to ask what can be done to fix this issue that
seems to wait for more than one year?

So I assume, given the above, someone might need to step up to drive
this further (?), but I'm not sure now how this would be handled in
the DEP process, or if it's possible within that framework, etc.
In any case IMO the DEP needs to be improved and/or clarified, as
stated in the above mentioned thread.

Thanks,
Guillem

[Richard Lewis]

Post by Guillem Jover
Hi!

Post by Abou Al Montacir

Post by Abou Al Montacir
But also, in this particular case, it's not the issue of the spec but of a
particular tool trying to enforce the rule.
I'll file a bug to fix it.

I finally found many reports already dealing with this issue in the bug tracker.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043043
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034102
Above two bugs are reporting very similar problems.
The following bug was closed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028503
But I find it no clear consensus there that it could be closed with the current
situation.

There is also <https://bugs.debian.org/1031381>, and I started a
discussion on this list with the stuff I think was collected as being
unclear and worth improving or clarifying at [M], but AFAIR the driver
of the DEP stated not having time to handle that work.
[M] https://lists.debian.org/debian-devel/2023/08/msg00067.html

Post by Abou Al Montacir
So I'm reporting this here again to ask what can be done to fix this issue that
seems to wait for more than one year?

So I assume, given the above, someone might need to step up to drive
this further (?), but I'm not sure now how this would be handled in
the DEP process, or if it's possible within that framework, etc.
In any case IMO the DEP needs to be improved and/or clarified, as
stated in the above mentioned thread.

I think there are 2 separate issues
- improving the DEP
- improving udd to reflect the current DEP

if the first is too difficult because no-one is willing to drive a
process, that seems more of a reason to focus on the second, which
"just" needs some technical changes to make udd match the current DEP.

If you are thinking that there might need to be further changes when the
DEP changes, i would instead suggest there is still value in making
improvements as people will be more willing to get involved in the
process side if they see a tool under more development