Unable to upload Debian Package.

[rhessinger]

Hi @luke_1024,

It looks like the error happens when trying to decompress your control file in the deb package. Something that cargo-deb is doing compresses and attaches that differently than dpkg-deb does. I took a quick look through cargo-deb's docs, but couldn't find anything to specify the compression. Something to try would be using the --fast flag when running cargo deb .

Please let me know if --fast fixes it. If not, I will set aside some time next week to debug through these packages more.

Thanks,
Rich

[luke_1024]

Thanks for looking into it but unfortunately the --fast flag did not solve the issue.

[atripp]

Hi @luke_1024 ,

Unfortunately this just doesn't look like something that's going to be easy/trivial to fix. Maybe it's a bug in the compression library we're using, or maybe cargo-deb is doing something unusual with the compression format that we're not expecting, or isn't documented in the normal debian commands.

It looks like you recreate the package with dpkg-deb then it works.

We will upgrade the libraries in the next major version, and maybe it will go away - but for now it doesn't seem worthwhile fixing, To date, just a single user (you ) has reported this, and if we hear from customers, we'll consider it too.

In the meantime, the workaround of repackaging should do the trick.

[hwittenborn]

I know this is an old issue (no clue if it's still relevant), but I experienced this issue with a program I was working on a while back and I thought I'd post the fix I had here:

If I recall correctly, ProGet thinks a deb is invalid when the first file in a .deb archive isn't control.tar.gz, or something like that. The main thing I remember is that I had to ensure files got added into the .deb archive in the correct order for ProGet to recognize it, and I'm assuming cargo-deb isn't doing that part correctly.

[MaxCascone]

I too am having this problem right now, and I don't even know how to look into the package to see if @hwittenborn 's fix is possible.

The file in question is not a cargo rust artifact but pulled from a provider's website.

I know the package still installs successfully, so as a workaround, I plan to put the deb pkg in ProGet as a simple file to be downloaded to the target.

[hwittenborn]

Hey @mcascone, my previous comment was slightly incorrect - my testing showed that ProGet requires the first file in a Debian package to be debian-binary (see this commit I made in a project a while back).

It looks like you're able to verify such is the case on a Debian archive by running the following on a Linux system:

ar tf name-of-package.deb

And the first line in the output should be debian-binary.

[MaxCascone]

@hwittenborn Thanks! I had to install binutils first, and then got what looks like a valid tree in both packages I had:

root@e6c7c176bb0d:/tmp# ar tf NessusAgent.deb 
debian-binary
control.tar.xz
data.tar.xz

root@e6c7c176bb0d:/tmp# ar tf NessusAgent-10.4.2-ubuntu1404_amd64.deb 
debian-binary
control.tar.gz
data.tar.gz

The former is a repackaged version of the latter; using @luke_1024's mechanism above.

FWIW, ar tf was not a valid command on MacOS (bash 5.2) with binutils installed, but works as expected on the Ubuntu container (above).

[MaxCascone]

It appears this has been implemented and released!
https://inedo.myjetbrains.com/youtrack/issue/PG-2530

[frei_zs]

I still encounter this issue with my packages built by aptly.

If the first file in the DEBIAN folder for the package is not "control", proget refuses the upload with: Package does not have a control file.

ar tf or compression doesn't seem to be the issue.

This deb fails:
admin@aptlyrepo:/tmp/pkg-test# ar tf tomedo-samba_1.1-2_amd64.deb
debian-binary
control.tar
data.tar

This deb works fine:
admin@aptlyrepo:/tmp/pkg-test# ar tf tomedo-zsh_1.0-3_amd64.deb
debian-binary
control.tar
data.tar

The difference is that the samba-package has a DEBIAN/conffiles file, which is enumerated earlier than the control file I guess.

[atripp]

@frei_zs I'm also replied to your ticket (EDO-10276), but wanted to reply here as well. I'm going to lock this thread after, since it's a different issue.

Unfortunately "tar" files are more of a convention than a standard, and not all libraries can read files created with different libraries. We are using one of the most "forgiving" tar libraries (we use four different ones!) in this particular scenario, but maybe aptly conventions aren't forgiving enough?

FYI - here is what we're doing with the library

public byte[] ReadControlBytes()
{
    using var control = TarReader.Open(this.Control);
    while (control.MoveToNextEntry())
    {
        if (control.Entry.Key == "./control")
        {
            var bytes = new byte[control.Entry.Size];
            using var entry = control.OpenEntryStream();
            ReadBlock(entry, bytes);
            return bytes;
        }
    }

    throw new InvalidPackageException("Package does not have a control file.");
}

We will need to inspect the file and see if we can determine what's wrong, and if it's an easy fix, we'll do it.