The GitHub API has a low rate-limit per IP for unauthenticated users, which we regularly hit on the scruffy.

The upstream ontologist should support having credentials passed in, or reading them from the users home directory.

For simplicity we should support the GITHUB_TOKEN environment variable, in addition to potentially reading the users' home directory.

• Use GITHUB_TOKEN for API operations
• Inject into Breezy git operations

Hi since there isn't a discussion tab I had to open an issue, I found this issue on the bug tracking system https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029750 I would like to work on it but I could not setup my development environment as I'm using a Windows machine with WSL enabled could you guide me to setup the development environment and mentor me into resolving this bug as I'm fairly new to Debian. Here is the list of things that I've done till now

• subscribed to the relevant mailing lists
• understood the bug-tracking system
• asked #debian-mentors on IRC how to set up the dev environment and they told me to use sbuild for building the package and docker for testing. but I don't know how to reproduce the error on WSL(Ubuntu).

so as of now, I need help setting up my dev environment and reproducing the error.
thanks and apologies if this isn't the right way to ask for help

The current API in rust is basically a 1:1 copy of what existed in Python. Instead, we should probably have a more rustic API.

Should UpstreamDatum be an enum (like it is now), or a trait for example?

See https://release-monitoring.org/

See edenhill/kcat#372

upstream-ontologist currently verifies that URLs are valid, but it should update URLs when it receives 30X responses.

upstream-ontologist currently has its own gemfile parsing logic. It would be great to use a standard solution like https://github.com/gemfileparser/gemfileparser instead

(that currently doesn't support parsing non-dependency metadata, but that should be fixable)

In https://salsa.debian.org/debian/decopy/-/merge_requests/3, lintian-brush suggests a Bug Database URL that is broken.

I can reproduce this with guess-upstream-metadata:

Name: decopy
Repository: https://salsa.debian.org/debian/decopy.git
Homepage: https://salsa.debian.org/debian/decopy
X-Version: 0.2.4.7
X-Summary: Automatic debian/copyright Generator
X-Description: |2-

      Decopy automates writing and updating the debian/copyright file.

      It reads all files in the source tree, analyzes the licenses and copyright
      messages included and generates the corresponding debian/copyright file.
      When the file already exists, decopy parses it to generate a more complete
      output.

X-License: ISC
X-Author:
- !Person
  name: Maximiliano Curia
  email: [email protected]
  url:
Repository-Browse: https://salsa.debian.org/debian/decopy
Bug-Database: https://salsa.debian.org/debian/decopy/issues
Bug-Submit: https://salsa.debian.org/debian/decopy/issues/new

However, while the project exists, it does not have issues enabled.

Some projects have multiple maintainers, and e.g. DOAP files will list all of them.

It would be good to change the X-Maintainer field into List[Person] rather than just a single string.

it would be good to fall back to AI models using the transformers library, perhaps with low certainty. We could use these on the README file and homepage contents.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038326 for the Debian ITP

https://huggingface.co/tiiuae/falcon-40b for a model that could potentially be shipped somewhere in Debian?

Some approximation of a long description can probably be done by parsing README.md and:

• Skipping over the initial header for the project
• taking the paragraphs until the next header
• filtering out anything clearly irrelevant ("See INSTALL for ... ")

If there are too many paragraphs, perhaps just take the first paragraph. Otherwise, take all paragraphs.

@isomer