Posts made by it_9582

For now we try to use a workaround - It would be really helpful for us if this would be implemented into the code in the future.

Hi @atripp,

thanks for the explanation.
I can understand that you are not willing/able to change this behavior. Now I will check if it is possible for us to modify the underlying wget call to allow downloading of the files from ProGet.

Best regards

Hi @atripp,
thanks for your fast answer.

Our script only downloads files from the ProGet-Server with wget on Linux and username:password (cannot be changed as simple). As we are using the API-Keys to authenticate with the server, so the wget call is the following:

wget --user api --password <api-key> <Download path>

After running this command I get a 401 from the Server. If I add the --auth-no-challenge argument like in the following snipped:

wget --user api --password <api-key> --auth-no-challenge <Download path>

than the Download runs without any issues.

The download also works without the --auth-no-challenge argument if I allow the download for Anonymous users.

I also checked if a download works if I send the Auth-Header manually with wget.

# generate base64 Encode Credentials
echo -n 'api:<key>' | base64

wget --header="Authorization: Basic <base64 Credentials>" <Download path>

This works also without any issues.

Hi there,
today I want to implement a file download over a toolkit which we use in our development process. This toolkit (which runs on linux) will download files from the server (now ProGet) over wget. The username and password will be used from wget over a .netrc file.

If I run a download of a file (I tested asset download and pypi-package download) with wget the ProGet-Server will response with 401 Unauthorized.

---response end---
401 Unauthorized
Registered socket 3 for persistent reuse.
Skipping 105 bytes of body: [You are not authorized to perform the Feeds_DownloadPackage task on this feed anonymously. Please log in.] done.
Unknown authentication scheme.

Username/Password Authentication Failed.

If I add the argument --auth-no-challenge to the wget call than the download will finish successfully but I this is more a workaround for this issue. As a side note the download of the same file over curl run without any issues and without extra arguments.

Are there any possibilities to fix this issue?

Best regards.

Would using an external database resolve that issue? So not using the embedded one?

Is it possible to switch to an external one with the instance already running with the embedded one?

Hi @atripp
thanks for your response and the description. We want to store some cache informations generated from yocto, onto our ProGet-Asset to share it between the developers. Unfortunately the generated filename can not be shorted, but it seems so that the maximum length of the filenames generated by yocto are 254.
Do you think it could be possible to modify the code/database to allow fitting this maximum?

Thanks

@Dan_Woolf Thanks for the quick reply - so this is nothing we can configure at the moment?

When uploading we do get the following error:

Failed to upload sstate:go-cross-canadian-aarch64:x86_64-nativesdk-poky-linux:1.17.13:r0:x86_64_x86_64-nativesdk:10:014a9fde37c442d487899c82c313f81e6bb015b8eaddfd10b257fda1e3e88afb_deploy_source_date_epoch.tar.zst.sigi: 22001: value too long for type character varying(200)

Npgsql.PostgresException (0x80004005): 22001: value too long for type character varying(200)
   at Npgsql.Internal.NpgsqlConnector.ReadMessageLong(Boolean async, DataRowLoadingMode dataRowLoadingMode, Boolean readingNotifications, Boolean isReadingPrependedMessage)
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
   at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
   at Npgsql.NpgsqlDataReader.NextResult(Boolean async, Boolean isConsuming, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Inedo.ProGet.Data.PostgresDatabaseContext.PostgresCommand.ExecuteReaderAsync(CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\Data\PostgresDatabaseContext.cs:line 392
   at Inedo.Data.DatabaseContext.DbResult.CreateAsync(IGenericDbCommand command, DatabaseContext context, DateTimeOffset startTime, Stopwatch stopwatch)
   at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters, DatabaseCommandReturnType returnType)
   at Inedo.Data.DatabaseContext.ExecuteNonQueryAsync(String storedProcName, GenericDbParameter[] parameters)
   at Inedo.Data.DatabaseContext.ExecuteScalarAsync[TResult](String storedProcName, GenericDbParameter[] parameters, Int32 outParameterIndex)
   at Inedo.ProGet.Feeds.Assets.AssetFeed.AddExistingFileAsync(String fullPath, String contentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\Feeds\Assets\AssetFeed.cs:line 159
   at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetContentHandler.CompleteMultipartUploadAsync(AhHttpContext context, AssetFeed feed, String url, Boolean ignoreContentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetContentHandler.cs:line 318
   at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetContentHandler.UploadFileAsync(AhHttpContext context, WebApiContext apiContext, AssetFeed feed, String url, PutMode mode, Boolean ignoreContentType) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetContentHandler.cs:line 170
   at Inedo.ProGet.WebApplication.FeedEndpoints.Assets.AssetFineUploadHandler.TryProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, AssetFeed feed, String relativeUrl) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E609935\Src\src\ProGet\WebApplication\FeedEndpoints\Assets\AssetFineUploaderHandler.cs:line 29
  Exception data:
    Severity: ERROR
    SqlState: 22001
    MessageText: value too long for type character varying(200)
    Where: PL/pgSQL function "Assets_FindFromPath"(integer,text,boolean,boolean,integer,text,xml) line 18 at assignment
SQL statement "SELECT found."@AssetItem_Id",
           found."@CanonicalAssetPath_Text",
           found."@Inherited_CacheConfiguration_XML"
                                                                                                                        FROM "Assets_FindFromPath" (
            "@Feed_Id",
            "@AssetPath_Text",
            "@IncludeDeleted_Indicator",
            "@AllowCaseInsensitiveMatch_Indicator",
            "@AssetItem_Id",
            "@CanonicalAssetPath_Text",
            "@Inherited_CacheConfiguration_XML"
            ) AS found"
PL/pgSQL function "Assets_GetItemFromPath"(integer,text,boolean,boolean,text,xml,xml) line 6 at SQL statement
    File: varchar.c
    Line: 637
    Routine: varchar

::Asset Upload Error on 01/14/2026 10:02:19::

Anyone able to help on this?

Hi @stevedennis,

thanks for your reply, it would be really nice if this feature could be implemented. We would chat about this with our point of contact.

Thanks,
Florian

Hi there,

are there any possibilities to promote a package (internal feed) to next feed if the build is promoted?

The reason for this question is that my idea for a good workflow would be as followed:

• Developer commit changes in VCS
• CI-System builds and
  • upload package to feed universal-build
  • creates new build in proGet with previously uploaded package in state Build
• If the package will be tested the test-engineer could promote the build to state Test
  • now it would be nice if the packages (possible configurable) also would be promoted to another feed

Actually we should start a lookup for each package in the Package in the Build after promotion and should promote each Package manually (over Web-UI or pgutil-CLI) to another feed.

Would this be a possible workflow solution or there any other suggestions to work with package/build/promotion?

Best regards,
Florian

Hi there,

after evaluating a Conan Feed in ProGet it saw a confusing thing in the detection.
First of all I configured the License Check in System as follows:

• General -> Undetectable rule: Warn
• Compliant -> "Empty"

I created a really simple Conan Recipe which only defines some basic parameters (no files added):

class BasicConanfile(ConanFile):
    name = "test"
    version = "1.0"
    description = "A test recipe"
    license = "Apache-2.0"

After creating this and upload it to the Conan-Feed, I get the following correct information from Proget (Package Overview):

⛔ Package is Noncompliant
This package analysis resulted in a Noncompliant result because of an Unacceptable License (Apache-2.0).

Now I added Apache-2.0 to the Compliant Licenses and get the following information from Proget (Package Overview):

⚠ Warning: Use with Caution
No license detected

The Metadata for this Package shows me the following

License: 	None, Known type (Apache-2.0)

so I added the Apache-2.0 License-File to my sources of the Conan-Recipe and reuploaded it but the message from Proget is the same:
(Package Overview):

⚠ Warning: Use with Caution
No license detected

But the Metadata for this Package now shows me the following

License: 	SPDX Expression (Apache-2.0), Known type (Apache-2.0)

Could you check this?

Best regards
Florian

Hi there,

we are currently evaluating the use of Proget and found a possible limitation for our use case which referes to universal packages.

We have some kind of components which are build with third-party components (Licensed under MIT, Apache or so) or closed-source components.
The built components should be stored in a universal package, because it does not feed in a another package type (conan, rpm, deb, ...). It would be really nice if this package would show which licenses are involved in the build so that the Manager could check if all used licenses are compliant.

The third-party components could be something like the SoC-Vendor SDK which not really fit into a conan package to deploy it, it would better fit into a universal package but on this we could not set the license.

Is it possible to implement this feature or there other possible ways to build this in Proget.

Best regards,
Florian