You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aurora.apache.org by Joshua Cohen <jc...@apache.org> on 2016/10/19 21:25:59 UTC

Trouble publishing Aurora 0.16.0 binaries to bintray

Hi all,

I'm trying to get a vote out for the 0.16.0 binaries, but I'm running into
some issues publishing the binaries. I'm wondering if those who have done
this in the past have any advice.

The problem seems to boil down to this: when I upload the tarball generated
by the release-candidate script, bintray does not give me the option to
explode it. Uploading it directly via curl, rather than the UI, I get an
error back telling me that it's not a valid type of file to explode, for
some reason it reads it as an octet-stream rather than a tarball (I even
tried forcing it by specifying a Content-Type header on the curl request to
no avail).

If I change the release-candidate script to generate a tar.gz instead of a
.tar, then I am able to get bintray to give me the option to explode the
archive, however it still fails because for some reason it's trying to sign
the files in the archive, but the signature is already present. I've
confirmed that the option to GPG sign files is not selected for my
repository.

At this point I'm at a loss for how to continue, as there does not seem to
be any way to upload the binaries and have bintray explode them, which is
required for the binary to actually be usable.

You can see what I've uploaded in its current tar form here:
https://dl.bintray.com/jcohen/aurora/

Any advice is appreciated!

Cheers,

Joshua

Re: Trouble publishing Aurora 0.16.0 binaries to bintray

Posted by Joshua Cohen <jc...@apache.org>.
I was just going based off of what's documented in
https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob;f=README.md;h=440aff22cba9da67f4d466e6bc147aee9ae065d2;hb=HEAD
(and previous votes on packages seem to match the description found
therein). I can just upload the contents of the tarball generated by the
release-candidate script manually in the meantime, but I was hoping someone
who had done this recently could clarify the process (or maybe I'm just
running into a bintray bug).

On Thu, Oct 20, 2016 at 7:57 AM, Jake Farrell <jf...@apache.org> wrote:

> There should be no source tar ball for the binary artifacts, just the deb's
> and rpm's which bintray requires that you upload individually. You can use
> dist.apache.org to stage the files for the vote and after it is successful
> upload them to bintray, we should also look at adding in some scripting for
> this to help automate the process
>
> -Jake
>
>
>
> On Wed, Oct 19, 2016 at 5:25 PM, Joshua Cohen <jc...@apache.org> wrote:
>
> > Hi all,
> >
> > I'm trying to get a vote out for the 0.16.0 binaries, but I'm running
> into
> > some issues publishing the binaries. I'm wondering if those who have done
> > this in the past have any advice.
> >
> > The problem seems to boil down to this: when I upload the tarball
> generated
> > by the release-candidate script, bintray does not give me the option to
> > explode it. Uploading it directly via curl, rather than the UI, I get an
> > error back telling me that it's not a valid type of file to explode, for
> > some reason it reads it as an octet-stream rather than a tarball (I even
> > tried forcing it by specifying a Content-Type header on the curl request
> to
> > no avail).
> >
> > If I change the release-candidate script to generate a tar.gz instead of
> a
> > .tar, then I am able to get bintray to give me the option to explode the
> > archive, however it still fails because for some reason it's trying to
> sign
> > the files in the archive, but the signature is already present. I've
> > confirmed that the option to GPG sign files is not selected for my
> > repository.
> >
> > At this point I'm at a loss for how to continue, as there does not seem
> to
> > be any way to upload the binaries and have bintray explode them, which is
> > required for the binary to actually be usable.
> >
> > You can see what I've uploaded in its current tar form here:
> > https://dl.bintray.com/jcohen/aurora/
> >
> > Any advice is appreciated!
> >
> > Cheers,
> >
> > Joshua
> >
>

Re: Trouble publishing Aurora 0.16.0 binaries to bintray

Posted by Jake Farrell <jf...@apache.org>.
There should be no source tar ball for the binary artifacts, just the deb's
and rpm's which bintray requires that you upload individually. You can use
dist.apache.org to stage the files for the vote and after it is successful
upload them to bintray, we should also look at adding in some scripting for
this to help automate the process

-Jake



On Wed, Oct 19, 2016 at 5:25 PM, Joshua Cohen <jc...@apache.org> wrote:

> Hi all,
>
> I'm trying to get a vote out for the 0.16.0 binaries, but I'm running into
> some issues publishing the binaries. I'm wondering if those who have done
> this in the past have any advice.
>
> The problem seems to boil down to this: when I upload the tarball generated
> by the release-candidate script, bintray does not give me the option to
> explode it. Uploading it directly via curl, rather than the UI, I get an
> error back telling me that it's not a valid type of file to explode, for
> some reason it reads it as an octet-stream rather than a tarball (I even
> tried forcing it by specifying a Content-Type header on the curl request to
> no avail).
>
> If I change the release-candidate script to generate a tar.gz instead of a
> .tar, then I am able to get bintray to give me the option to explode the
> archive, however it still fails because for some reason it's trying to sign
> the files in the archive, but the signature is already present. I've
> confirmed that the option to GPG sign files is not selected for my
> repository.
>
> At this point I'm at a loss for how to continue, as there does not seem to
> be any way to upload the binaries and have bintray explode them, which is
> required for the binary to actually be usable.
>
> You can see what I've uploaded in its current tar form here:
> https://dl.bintray.com/jcohen/aurora/
>
> Any advice is appreciated!
>
> Cheers,
>
> Joshua
>