1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Invalid check in debian/patches

    From Abou Al Montacir@21:1/5 to All on Sat Feb 1 13:30:01 2025
    --=-nnd980EenA9g7Lm2/TuY
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    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 given as a hint by the tool, states clearly that:
    * 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.
    --
    Cheers, Abou Al Montacir

    --=-nnd980EenA9g7Lm2/TuY
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html><head></head><body><div>Hi All,</div><div><br></div><div>According to&nbsp;<a href="https://udd.debian.org/patches.cgi?src=lazarus&amp;version=3.8%2Bdfsg1-4">https://udd.debian.org/patches.cgi?src=lazarus&amp;version=3.8%2Bdfsg1-4</a>&nbsp;my
    package have a patch with invalid metadata. There seem to be that the tool considers the following as an error:</div><div><b><font color="#993300">Forwarded: Yes</font></b></div><pre>Bug-Upstream: <a href="https://gitlab.com/freepascal.org/lazarus/
    lazarus/-/issues/41378">https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378</a></pre><div><br></div><div>This is despite that&nbsp;<a href="https://dep-team.pages.debian.net/deps/dep3/">https://dep-team.pages.debian.net/deps/dep3/</a>, which
    is given as a hint by the tool, states clearly that:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-lef
  • From Jonas Smedegaard@21:1/5 to All on Sat Feb 1 13:50:01 2025
    Hi Abou,

    Quoting Abou Al Montacir (2025-02-01 13:13:32)
    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 given as a hint by the tool, states clearly that:
    * 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

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============a28249697741817147=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnnhdPCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmcTtVnBSWwVQWlHl1BUqKNYvoLTpVgrw3HkICt+AxBn 1BYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAC4kg//VniLM+1Ohaa27Ul+SEg5Fohm AwWShkfhX7BNEDuMA/lWWVcZoRDU0tp7ckYqaUFuAL4vAFfrMGJPmfAtHLaCSD1P FWDSj8ZabZ6wOB04UZA3aRzG4obo5fDiJBuBJZo/LEG/XUBNrsJ/GOHa7js6Dpnz +fe0g5KWvE9qxsFIgqp2DvpHw8f/0aoFZKFZ7g3IoClROap4kAldKyjCY9NBzRpS X/c9LqYF3v0JVaKW9OFr3TK0Tq3m9Yj+P1lCHm7naNEbDnNlmtU67wMlym03iLUD 9Oeu92N8JiFRxRFJYoU6jCbC8yFnJQ7KOy23e15IM/k+0br2l3jKO8ei2oGV8Kkw y+tQFxf/gGmjBKe5sL7gIYcZ2pCK8SHVPrqBxoTN
  • From Jonas Smedegaard@21:1/5 to All on Sat Feb 1 14:40:01 2025
    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"?

    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

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private --==============„90003892627615802=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

    -----BEGIN PGP SIGNATURE-----

    wsG7BAABCgBvBYJnniOFCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmeiHEXEsfHQxWA70Q/G9KRecqcCjgMhrNQ+mCfkMnZ3 fxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAARsg//RlwhZrRb/VtpMMO0yi19DoKk hPexZKsQdeC9/mmBaWnFFzORNlOaa7d45uTNqQ4XG//2nOUbDod96PeBJZAD//Er zs+pk6C7z6AE7tY64zVBvmqWJU2iwxAMHtdR9niK3+ejSaQeJuWABB8K9ZloYbui 6Pge8PYbBnDDy4r6EYTDMLwQ2P/W29fgj0i1+sYv2Ms/P+JXox4OUSkaTXOC/FeJ WE6n4uQv1wWWpk7IyR4GuE5USbh9eH4rXOESBCYNwPyoHsHelKK8MMF4JDMMBvh3 va5rLaY770G4T/egcL5VAGmCq4o5WmqUg7liSxFQv7/Uu5Iv9d4C7wwrgZ8f96PG b/j3R7TMoSsLpatkTzSHLGWRd2ZB1FN49jZh7xXE
  • From Simon McVittie@21:1/5 to Abou Al Montacir on Sat Feb 1 14:30:02 2025
    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.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jeremy_B=C3=ADcha?=@21:1/5 to abou.almontacir@sfr.fr on Sat Feb 1 16:40:01 2025
    On Sat, Feb 1, 2025 at 10:14 AM Abou Al Montacir <abou.almontacir@sfr.fr> wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Abou Al Montacir@21:1/5 to Jonas Smedegaard on Sat Feb 1 16:20:01 2025
    --=-5VNscyZbRQOMqubzFs2l
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable



    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

    --=-5VNscyZbRQOMqubzFs2l
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html><head></head><body><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div></blockquote><div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 14.666667px;"
    On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Quoting Simon McVittie (2025-02-01 14:21:38)<br></div><blockquote type="cite" style="
    margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Sat, 01 Feb 2025 at 13:13:32 +0100, Abou Al Montacir wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Bug-
    Upstream:&nbsp;<a href="https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378" title="Click to open
  • From Jonas Smedegaard@21:1/5 to All on Sat Feb 1 17:10:01 2025
    Quoting Abou Al Montacir (2025-02-01 16:13:44)


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

    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?


    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.

    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

    --
    * Jonas Smedegaard - idealist & Internet-arkitekt
    * Tlf.: +45 40843136 Website: http://dr.jones.dk/
    * Sponsorship: https://ko-fi.com/drjones

    [x] quote me freely [ ] ask before reusing [ ] keep private

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Abou Al Montacir@21:1/5 to Jonas Smedegaard on Sat Feb 1 17:40:01 2025
    --=-wdlWLkUuZoRkjHoYEHk3
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    Hi Jonas,

    On Sat, 2025-02-01 at 17:05 +0100, Jonas Smedegaard wrote:
    Quoting Abou Al Montacir (2025-02-01 16:13:44)


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

    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.

    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.

    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.

    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.
    --
    Cheers,
    Abou Al Montacir

    --=-wdlWLkUuZoRkjHoYEHk3
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html><head></head><body><div>Hi Jonas,</div><div><br></div><div>On Sat, 2025-02-01 at 17:05 +0100, Jonas Smedegaard wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Quoting Abou Al
    Montacir (2025-02-01 16:13:44)<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><
    <br></div></blockquote><div>On Sat, 2025-02-01 at 14:37 +0100, Jonas Smedegaard wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Quoting Simon McVittie (2025-02-01 14:21:38)<br></
    <blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Sat, 0
  • From Abou Al Montacir@21:1/5 to Abou Al Montacir on Sat Feb 1 22:40:01 2025
    --=-0HmewDrf4whOoSmyDDCC
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    Hi,

    On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:
    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?
    --
    Cheers,
    Abou Al Montacir


    --=-0HmewDrf4whOoSmyDDCC
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html><head></head><body><div>Hi,</div><div><br></div><div>On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>But also, in this particular
    case, it's not the issue of the spec but of a particular tool trying to enforce the rule.</div><div><br></div><div>I'll file a bug to fix it.</div></blockquote><div style="unicode-bidi: plaintext; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-
    family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing:
    0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none
  • From Guillem Jover@21:1/5 to Abou Al Montacir on Sun Feb 2 01:50:01 2025
    Hi!

    On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote:
    On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Lewis@21:1/5 to Guillem Jover on Wed Feb 5 15:10:02 2025
    Guillem Jover <guillem@debian.org> writes:

    Hi!

    On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote:
    On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)