Debian repository

Dear GitLab community members,

we are looking into new feature of the GitLab we are quite excited about, the Debian package repository. But I did not manage to make it work, related API endpoints generally does not work as expected. Has anyone managed to set it up?

I know that there is mention that it “isn’t ready for production use due to limited functionality” in the documentation, but we wanted to start preparations and maybe having some of our packages available for our internal use.

I have enabled the feature with Feature.enable(:debian_packages) and started to test it using my personal access token. But all these endpoints either say unauthorized or that the project does not exists:

curl --request PUT --upload-file <REDACTED>.deb --header "PRIVATE-TOKEN: <REDACTED>" https://<REDACTED>/api/v4/projects/1/packages/debian/<REDACTED>.deb
{"message":"401 Unauthorized"}

curl --request POST --header "PRIVATE-TOKEN: <REDACTED>" "https://<REDACTED>/api/v4/projects/75/debian_distributions?codename=unstable"
{"message":"404 Project Not Found"}

But e.g. this does work as expected (same instance, same token, same project ID):

curl --header "PRIVATE-TOKEN: <REDACTED>" "https://<REDACTED>/api/v4/projects/<REDACTED>"

I tried two combinations of Access token permissions:

  • check all
  • api

I tried it on our production instance (GitLab version 14.2) and also I deployed the latest 14.3 on my computer in Docker container using gitlab/gitlab-ce.

Does someone know whether I miss something?

1 Like

I have the exact same issue on a 14.4-ee environnement. I get a 404 project not found for any project even after enabling the debian repository.

Also had some problems with this

curl --header "PRIVATE-TOKEN: <token>" ""
{“message”:“404 Project Not Found”}

But encoding the token like this got me a correct reply

curl "https://PRIVATE-TOKEN:<token>"

So now all we have to do is to figure out how to upload the debs…

The Gitlab documentation for users is somehow inconsistent with the API documentation for projects and groups: There is #340306 open to improve this and other things:

  • Previously several documents started that “Bearer Token Authentication” should be used, but only “Basic Authentication” worked. This seems to be the cause because Debians APT tools only allow the later and thus the low-level API must allow that.
  • I looked at dput-ng last week and it basically does several HTTP PUT requests to upload each file, which you can also do via curl for example:
curl --verbose --request PUT \
  --user "${USERNAME}:${PASSWORD}" \
  --upload-file hello_1.1.0_amd64.deb \

You can even upload multiple files with one curl invocation by separating them with a comma and putting curly braces around everything: … --upload-file '{hello_1.1.0_amd64.deb,hello-dbgsym_1.1.0_amd64.deb,hello_1.1.0_amd64.buildinfo,hello_1.1.0_amd64.changes}'.
Be careful as you cannot use shell globbing here (hello_*) as curl has its own handling for –upload-file. But a simple shell helper function like this easily solves it:

glupload () {
  local IFS=,
  curl --verbose --request PUT \
  --user "${USERNAME}:${PASSWORD}" \
  --upload-file '{'"${*}"'}' \

Strangely enough our on-premise Gitlab installation stopped working: Even though I get a HTTP 201 back for all my uploads no packages are listed for my Package Registry. It worked back several months ago, but now no longer. I darkly remember that back then I forgot to create the Debian distribution by doing a POST to ${CI_API_V4-URL}projects/${CI_PROJECT_ID}/debian_distribution?codename=unstable first. But from the current documentation it’s unclear to me where that codename=unstable is evaluated: As being a Debian developer myself I know that only uploading the .changes triggers the import mechanism and therefor you have to upload that file last. It contains the Distribution: unstable information which Debians infrastructure then uses to route that upload to the specified distribution. But I do not know how Gitlab handles this.


1 Like