Hi @gdivis,
I've tried encoding the purl URL, and it works on both Windows and Linux, without having to interchange the distro and component order. However, it's a little strange that NuGet package purls work whether they are encoded or not.
Anyway, I'm going to encode the URL in the code.
Thank you very much.
Hi again @atripp,
I'm afraid it doesn't work by changing the order either. I tried with a simpler package version, not a prerelease one, and it fails in the same way:
ERROR - Error '400 Client Error: Bad Request for url: https://serverip/api/packages/unstable-lin/delete?purl=pkg:deb/scatinat@7.2.2.0-1?arch=amd64&distro=jammy&component=scati'
As I mentioned, I'm just catching the purl from a previous API request. Would you have any other suggestions to try?
Thanks.
Hi @atripp,
using pgutil works OK:
pgutil packages delete --feed=unstable-lin --package=scatimysqlcluster --version=7.3.0.0-0.202406122314.6df3a85167 --component=scati --distro=jammy --arch=amd64
Deleting scatimysqlcluster 7.3.0.0-0.202406122314.6df3a85167 arch=amd64&component=scati&distro=jammy from unstable-lin feed...
Package deleted.
Although I'm not sure if it's the same, as pgutil doesn't really use a purl. In any case, we'd rather use the HTTP API to keep everything contained within the script code.
Thanks.
Hi,
I'm trying to remove packages from a Debian feed using the HTTP Request described in the API documentation: https://docs.inedo.com/docs/proget/reference-api/proget-api-packages/proget-api-packages-delete#http-request-specification
But it always returns an error 400 - Missing required qualifier component: distro, despite my using the purl returned by the server, as it's described here: https://docs.inedo.com/docs/proget/reference-api/proget-api-packages#using-a-purl-to-identify-a-package
I'm making this POST request https://serverip/api/packages/unstable-lin/delete?purl=pkg:deb/scatimysqlcluster@7.3.0.0-0.202406122314.6df3a85167?arch=amd64&component=scati&distro=jammy from a python script.
It doesn't seem to be a code error because the same script with a Windows purl works perfectly https://serverip/api/packages/unstable-win/delete?purl=pkg:nuget/scativision@7.3.5-2024-06-11
Thanks a lot.
Hi @stevedennis,
Seeing the PG-2716 solution included in the last release 24.0.8, we upgraded.
In 2024.8 version the creation of new Debian feed works perfect, but the feedGroup property doesn't seem to do it.
Could you double check if feedGroup is the right name, and if it's included on current version?
Great.
We’re looking forward to the next release and will let you know as soon as we test it.
Thank you.
Hi,
We are trying to create a feed following the Create feed documentation, but we run into two problems:
We are using the last ProGet version running under Windows Server.
Thank you.
Hi @gdivis,
pgutil packages delete --source=scati --feed=stable --package="pacomalarmprocessor" --version=7.2.1.0-1 --qualifier="arch=amd64&component=scati&distro=bionic"
It works perfect with that command.
Thank you. Keep up the good work.
Thanks @stevedennis,
this is the information returned:
[
{
"purl": "pkg:deb/pacomalarmprocessor@7.2.1.0-1?arch=amd64&component=scati&distro=bionic",
"name": "pacomalarmprocessor",
"version": "7.2.1.0-1",
"qualifier": "arch=amd64&component=scati&distro=bionic",
"totalDownloads": 0,
"downloads": 0,
"published": "2024-05-14T07:40:58.73Z",
"publishedBy": "Admin (API)",
"size": 7088772,
"md5": "f9b5cac473e1539824486ec76c8515b7",
"sha1": "43e2493ee4fd6f6284c225bda574da8f884597ea",
"sha256": "aa51e0cff448c3df2fcc509fb7f223fa600ed129c81a15b5f1c15e2f34dd0f1f",
"sha512": "38d6cdfb91a052edddf1452c763f8cc83845f896a9fa7e5c6539071ad0f17be5188d7c39ff41b5690eb89e08527eac5dfc23d2355dfb4050986570b086ef2b61",
"versions": [
"7.2.1.0-1",
"7.2.1.0-1"
]
}
]
Odd or not, it claims that I have twice the same version 7.2.1.0-1. I presume that's because I have one bionic and one jammy version.
This is the list of files in the Web UI:
Files
Name Size Published
bionic/scati/pacomalarmprocessor_7.2.1.0-1_amd64.deb 6.922 KB 14/05/2024 9:40:58
jammy/scati/pacomalarmprocessor_7.2.1.0-1_amd64.deb 7.913 KB 14/05/2024 9:37:31
According to the returned qualifier I tried other options, but it still fails:
pgutil packages delete --source=scati --feed=stable --package="scati/pacomalarmprocessor" --version=7.2.1 --qualifier="arch=amd64&component=scati&distro=bionic"
pgutil packages delete --source=scati --feed=stable --package="pacomalarmprocessor" --version=7.2.1 --qualifier="arch=amd64&component=scati&distro=bionic"
pgutil packages delete --source=scati --feed=stable --package="scati/pacomalarmprocessor" --version=7.2.1 --qualifier="arch=amd64&distro=bionic"
Hi @atripp,
sorry I don't really get what you mean.
In the ProGet UI everything looks ok, I guess. I don't really know what to look at.
Regarding to the Common Package API and purl, could you give me some information about how to request that information? I only have been able to find this webpage https://docs.inedo.com/docs/proget-api-common-package that returns a 404 error.
Thanks.
I'm trying to remove Debian packages using the API on a ProGet 2024.3 installation, following this documentation. I tried both, pgutil and HTTP request, and none of them worked for me.
I suspect it's a software or documentation issue because the same process works for Chocolatey (Nuget) packages.
I tried pgutil:
pgutil packages delete --source=scati --feed=stable --package=scati/pacomalarmprocessor --version=7.2.1.0-1 --qualifier="arch=amd64"
and HTTP request:
$uri = 'https://neptuno.sisifo.this:8080/api/packages/stable/delete?group=scati&name=pacomalarmprocessor&version=7.2.1.0-1&qualifier=arch%3Damd64'
$response = Invoke-WebRequest -Uri $uri -Method Post -Headers @{"X-ApiKey" = $apiKey}
By contrast Nuget works with:
pgutil packages delete --source=scati --feed=beta --package=scatimetadata --version=7.2.0
In ProGet Event Log webpage I see a line Package Deleted beta systemapi 13/05/2024 16:25:27 after execute pgutil with a Nuget package. But nothing is written with Debian packages (expected as nothing is deleted in fact).
However, in API Key Access Logs webpage there is a
request line with response code 200 (Success) https://neptuno.sisifo.this:8080/api/packages/stable/delete?group=scati&name=pacomalarmprocessor&version=7.2.1.0-1&qualifier=arch=amd64 200
And that's maybe another problem because pgutil command always return Package deleted even if you use a non-existing package intentionally.
Thank you.
Fix verified on 2024.2 version.
Thank you.
Fix verified on 2024.2 version.
Thank you.
Hi, I'm getting warnings about invalid date using Debian feeds when update from clients.
The specific error is the following:
W: Invalid 'Date' entry in Release file /var/lib/apt/lists/neptuno.sisifo.this:8080_debian_test_dists_bionic_InRelease
The issue is that the release file generated by ProGet writes the Date in local format, not following the Debian guidelines:
The date has the following format 7 (compatible and with the same semantics of RFC 2822 and RFC 5322):
day-of-week, dd month yyyy hh:mm:ss +zzzz
where:
Executing a grep among the InRelease files I notice that the Date in ProGet release files is in Spanish format instead of English:
operador@scatipc:~$ grep Date /var/lib/apt/lists/*_InRelease
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_InRelease:Date: Thu, 26 Apr 2018 23:37:48 UTC
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic-updates_InRelease:Date: Fri, 19 Apr 2024 1:22:01 UTC
/var/lib/apt/lists/linux.teamviewer.com_deb_dists_stable_InRelease:Date: Tue, 23 Apr 2024 07:26:48 UTC
/var/lib/apt/lists/neptuno.sisifo.this:8080_debian_test2_dists_bionic_InRelease:Date: vie., 19 abr. 2024 06:09:01 UTC
/var/lib/apt/lists/neptuno.sisifo.this:8080_debian_test3_dists_bionic_InRelease:Date: jue., 25 abr. 2024 06:31:46 UTC
/var/lib/apt/lists/neptuno.sisifo.this:8080_debian_test4_dists_bionic_InRelease:Date: jue., 25 abr. 2024 06:31:46 UTC
/var/lib/apt/lists/neptuno.sisifo.this:8080_debian_test_dists_bionic_InRelease:Date: jue., 25 abr. 2024 06:31:45 UTC
/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_bionic-security_InRelease:Date: Mon, 13 Nov 2023 0:36:15 UTC
I presume the problem is originated because my ProGet server runs in a Windows Server in Spanish language, otherwise many users would have reported it. But the Release generation should ignore any language format, using always the English standard to avoid those warnings in client computers.
Thank you.
@philippe-camelio_3885 thanks for the piece of advice about how to import the certificate on Jammy, but I already used that way, and it also fails.
After several tests I found out the root of the problem, and strange as it may seem, it is caused for the Description field in the Properties of Manage Feed. The feed description supports markdown format, but if it contains a break line with a blank line, after some minutes (or hours?) it will start to fail in the client when execute an update.
One example of a description that reproduce the bug could be:
**Fabricación**
Instaladores Ubuntu liberados a producción
The second blank line is the one that causes the issue. Fortunately, edit the description removing the blank line solves it 
Is there any documentation about how ProGet generate the certificates for Debian repositories? or, where I could find them in a Windows installation? To have something to start working with.
I tried searching for any file with .asc extension, but there is nothing found in my Windows installation, so I guess certificates like stable.asc are generated/stored somehow on the website for download ¿?
I'm totally willing to help as far as I can. Thank you.
Hi. I'm having troubles using debian repositories on Ubuntu.
I've followed the instructions to use the debian repository and the key was imported correctly, but when I run apt update command the following error appears:
W: GPG error: https://myserver:8080/debian/stable jammy InRelease: The following signatures were invalid: BADSIG D263579579B65410 stable@proget
E: The repository "https://myserver:8080/debian/stable jammy InRelease" is not signed.
I tried on Bionic and Jammy versions with several client computers. I tried importing the key with apt and using a keyring directory. I tried with different feeds. But the same error always appears.
How could I solve it? Is it any way to recreate the ".asc" keys? Maybe there is some kind of error with them.
Thank you.
Setting aside the apt-key deprecation point. I'm using now 2023.32 and the Integrate with apt documentation is perfect now.
If I'm not wrong the web documentation it's still incorrect, though.
Add the signing key
To add the signing key to apt, run the following command:
wget -qO - http://{proget-server}/debian/keys/{feed-name}.asc | sudo apt-key add -
Should be:
wget -qO - http://{proget-server}/debian/{feed-name}/keys/{feed-name}.asc | sudo apt-key add -
Just to give you a heads up. I'm already on version 2023.32 and it works like a charm.
Thank you.
Nice!
I'll be waiting for the next release.
Thank you very much.
Hi,
I found several mistakes in the debian feeds client configuration documentation, both inedo docs webpage and proget app web (strangely they aren't the same).
https://docs.inedo.com/docs/proget-feeds-debian
wget -qO - http://{proget-server}/debian-feeds/keys/{feed-name}.asc
In a new Debian feed that URL address return the error (404) Not Found.
In the section Adding the repository there is a misspelling (debina vs debian)
echo "deb http://{proget-server}/debina/{feed-name} {distro-name} {component-name}"
On the other side the information the Integrate with apt information on proget web app is also erroneous:
echo "deb http://myserver:8624/debian/stable/bionic libs scati third" | sudo tee "/etc/apt/sources.list.d/proget-stable.list"
The distro-name should be separated by a space from the URL echo "deb http://myserver:8624/debian/stable bionic libs scati third"
Above all, bear in mind that apt-key was considered deprecated as of Debian 11 and Ubuntu 22.04
The Packages count number in the Feeds page doesn't show the actual number of packages in every feed. The count seems to work OK when you add a new package (+1), yet not go down when you remove it. I add and remove the packages using the web interface.
In my case, it is happening in all feed types I'm using (Debian new and Chocolatey).
Here, for example, I uploaded a package to beta and then removed it, but it still says that there is 1 package:
When I click on the beta Name link it shows "There are no local Packages in this feed."
When I click on the 1 number under Packages row it shows "There are no packages that match the specified criteria."
I've already used the Storage & Retention re-index function, without any change.
There are no error messages on Diagnostic Center
I'm using version 2023.28 (upgraded today to .29) with a ProGet Free license at the moment.