Should it be bugs to fix a bug in bugtracker?

[samcarter]

Related to https://fosstodon.org/@[email protected]/112874734124443803

It seems that for packages submitted via l3build, the bugtracker information is missing on ctan.

I'm wondering if the line

https://github.com/latex3/l3build/blob/main/l3build-upload.lua#L269

ctan_field("bugtracker",   uploadconfig.bugtracker,    255, "URL(s) of bug tracker",               false, true  )

should read

ctan_field("bugs",   uploadconfig.bugtracker,    255, "URL(s) of bug tracker",               false, true  )

to match the field name given at https://ctan.org/help/submit ?

(feel free to edit the punny title, I could not resist)

[muzimuzhi]

The field name bugtracker was once used by the deprecated v1.0 of the API (https://ctan.org/help/submit/1.0). The newest version is 1.1.

I'll try if I can provide a PR.

[samcarter]

@muzimuzhi Thanks for the API archaeology! This explains why l3build uses bugtracker.

[davidcarlisle]

@muzimuzhi thanks, that appears to be the only difference between the listed fields.

[muzimuzhi]

I found there are inconsistencies in fields and their docs among each 2-pair of

• l3build implementation l3build-upload.lua,
• latest CTAN API doc, section "Parameters for Validation" https://ctan.org/help/submit#validation.parameters, and
• latest CTAN API doc, section "Requesting the Known Fields" https://ctan.org/help/submit#fields

For example,

• l3build uses fields development and support which are not listed on CTAN;
• CTAN accepts field mailinglist which is not used by l3build;
• Length limitation and if-mandatory state of some fields are different;

I've reported these findings to CTAN and after CTAN updates its API doc to be more consistent, I'll provide another PR to sync our use of CTAN API to its latest doc.

[muzimuzhi]

CTAN has confirmed that bugs field name was indeed a typo. Now https://ctan.org/help/submit#validation.parameters lists bugtracker again.

Quoting part of an email response from CTAN member Gerd Neugebauer:

Please keep in mind that the upload via the API or the Web site is only part of the process. The data is not stored in the catalogue automatically. Normally a upload manager comes along and transfers the submission into the catalogue. This could also be the origin of the error.

To investigate further I would like to have a the real upload (name of the package and date of upload). Then I could try to investigate further what happened: The upload is logged in the database. A mail is sent to the upload managers containing the collected fields. A mail is sent when the publication is completed.

@Cs137 I've provided the upload for doibanner 0.3 2024-07-28 as an example (CTAN Announcement), and suggested using chaos.social or this issue for direct contacting with you.

[josephwright]

So we close?

[muzimuzhi]

Not yet. Gerd checked the doibanner 0.3 2024-07-28 upload and found

The information has not made it into the log entry for the upload.
This means that the field has not been sent or the controller has a bug. I will continue to think about it tomorrow.

So there's still some mysteries.

I feel most packages already have their Bug tracker field set on CTAN before their adoption of l3build, and even after the adoption their updates may not be done by l3build upload. Therefore the doibanner case, a new package uploaded to CTAN by l3build automatically, is relatively rare.

Using l3build repository as an example, after running l3build ctan && l3build upload --debug, the HTTP response from https://httpbin.org/post does contain

{
  ...
  "form": {
    "author": "The LaTeX Team",
    "bugtracker": "https://github.com/latex3/l3build/issues",
    ...
  }
}

We may need another real auto update to collect more info.