You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/08/08 02:51:21 UTC

[VOTE] Release Bigtop version 1.0.0 (RC4)

This is the vote for release 1.0.0 of Apache Bigtop.

It fixes the following issues:
        https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420

This is the respin of RC3, addressing the fix for default repo uRLs and adding
proper header licenses to be able to run full RAT check on the release.
The rest of the release is the same.

The vote will be going for at least 48 hours and will be closed on
Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with

[ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
[ ] +0, I don't care either way,
[ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...

Source and binary files:
        http://people.apache.org/~cos/bigtop-1.0.0-RC4

Maven staging repo:
        https://repository.apache.org/content/repositories/orgapachebigtop-1004

The git tag to be voted upon is release-1.0.0

Bigtop's KEYS file containing PGP keys we use to sign the release:
        http://svn.apache.org/repos/asf/bigtop/dist/KEYS

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by "김영우 (Youngwoo Kim)" <wa...@gmail.com>.
+1

- Verified signature and hashes
- Built a yum repository with packages
- Ran smoke tests

Thanks,
Youngwoo

On Sat, Aug 8, 2015 at 9:51 AM, Konstantin Boudnik <co...@apache.org> wrote:

> This is the vote for release 1.0.0 of Apache Bigtop.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>
> This is the respin of RC3, addressing the fix for default repo uRLs and
> adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
>
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
>
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop,
> because...
>
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
>
> Maven staging repo:
>
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
>
> The git tag to be voted upon is release-1.0.0
>
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>
>

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
Thanks for thorough investigation Evans. The way I signed them was like this
    rpmsign --resign **/*rpm

I wonder if the instructions we have aren't sufficient. I will take a look at
it either tonight or tomorrow and once fixed will reupload the packages for
the affected platforms.

Thanks!
  Cos

On Thu, Aug 20, 2015 at 01:31AM, Evans Ye wrote:
> Hi Cos,
> 
> I've verified deb repos, and they're good as what you said, however, it
> seems that rpms are still not being signed. I don't have too much knowledge
> on this so I did my homework and conduct the following evaluation.
> Here's my evaluation steps, please advise if any thing incorrect:
> 
> First, download a rpm from S3, which should be already signed:
> 
> $ wget
> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> $ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK
> 
> As shown above, the rpm does not being signed.
> A signed rpm should be looked like this:
> 
> $ rpm --checksig puppetlabs-release-el-6.noarch.rpm
> puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> 
> And after I signed the rpm by my key, the rpm looks good now:
> 
> $ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
> $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> 
> OTOH, it looks like the pgpkey for rpm packages needs to be armored when
> exporting, for example:
> 
> $ gpg --armor --output KEYS --export 'Evans Ye'
> 
> Otherwise, an error occurs when importing a non-armored key:
> 
> $ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
> error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2 not an
> armored public key.
> 
> A good thing for that is we can fix it in the cloud.
> Sorry for not discovering this at the very beginning. :(
> 
> Evans
> 
> 
> 2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> 
> > On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> > > Well, sorry. When I do manually test on those repos, I got package is not
> > > signed message...
> > > It turns out that our puppet recipe sets pgpkey checking to false, which
> > is
> > > why I got things working without a problem.
> > > I assume the repo should just work by dropping it into /etc/yum.repos.d/.
> > > No need to import pgpkey manually, right?
> >
> > Hmm... with ubuntu repo the signatures are there because I had to run
> > apt-addkey manually to make apt recognize the signatures. Otherwise,
> > apt-get update didn't work.
> >
> > You might need to do something similar with yum - I am not really sure.
> > But I
> > am positive that I have signed the packages per the insructions on our
> > release
> > page.
> >
> >   Cos
> >
> > > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > > > I think we are in good position - I was worries about keys being not
> > found
> > > > or
> > > > something like this. If two of them are ok, then the rest should be
> > fine
> > > > too.
> > > >
> > > > Thank you very much for the confirmation and testing - really
> > appreciate
> > > > it!
> > > > I will send the announcement shortly.
> > > >
> > > > Regards,
> > > >   Cos
> > > >
> > > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > > > > We're so close to the finished line! Thank you everybody!
> > > > > I took sometime to run the deployment test before I go to bed.
> > > > > Specifically I've tested centos-6, debian-8 repo, both work like a
> > charm.
> > > > > It should be all good, if no hurry I'll do more test tomorrow. :)
> > > > >
> > > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > >
> > > > > > See? I can not even write word "dense" without making a typo...
> > That's
> > > > how
> > > > > > hot
> > > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh boy,
> > was
> > > > it
> > > > > > fun?), and updated the repo files in the release under
> > > > > >
> > https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > > > > >
> > > > > > If you have a cycle or two - please do some quick validation and I
> > will
> > > > > > send
> > > > > > the announcement to make the release final.
> > > > > >
> > > > > > Thanks everyone
> > > > > >   Cos
> > > > > >
> > > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
> > outside ;(
> > > > > > Thanks!
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> > > > cos@apache.org>
> > > > > > wrote:
> > > > > > > > > Make sense - wgetting the stuff now. centos is done, debs and
> > > > fedora
> > > > > > to go.
> > > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > > > > > >
> > > > > > > > IIRC, this had to do with double caching of packages. IOW, you
> > only
> > > > > > > > need to make this available:
> > > > > > > >
> > > > > >
> > > >
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > > > > > >
> > > > > > > > not the top level dir.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Roman.
> > > > > >
> > > > > >
> > > > > >
> > > >
> >

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
Just to wrap it up here as well. As reported on http://bit.ly/1XiYRRM - the
situation has been resolved and the guilty part is RPM's long-standing
inability to deal with subkeys.

Cos

On Mon, Aug 31, 2015 at 12:57AM, Konstantin Boudnik wrote:
> Arghhh... of course. I completely forgot about this ;( And I have updated the
> wiki release page, to avoid forgetting this in the future.
> 
> Synced the repodata folders to S3 - everything should be fine now.
> Thanks a lot for your help!
>   Cos
> 
> On Mon, Aug 31, 2015 at 03:37AM, Evans Ye wrote:
> > Hi Cos,
> > 
> > I finally found the issue by reproducing a repo in my S3 buckets.
> > The answer is that the repodata needs to be regenerated after RPMs are
> > being signed.
> > 
> > Here's my testing steps:
> > 
> > 1. download the whole built repo from jenkins release built as archive.zip
> > and unzip it
> > 2. sign RPMs:
> >   $ find -name *.rpm | xargs rpm --define="%_gpg_name Evans Ye" --addsign
> > *3. recreate the metadata*
> > *  $ rm -rf repodata; createrepo -v .*
> > 3. upload to S3 bucket:
> >   $
> > aws s3 cp bigtop-1.0.0-rpm-centos-6-output/
> > s3://evansye/bigtop/centos/6/x86_64 --recursive
> > 
> > My repo:
> > [bigtop]
> > name=Bigtop
> > enabled=1
> > gpgcheck=1
> > baseurl=https://s3-us-west-1.amazonaws.com/evansye/bigtop/centos/6/x86_64
> > gpgkey=https://s3-us-west-1.amazonaws.com/evansye/bigtop/KEYS
> > 
> > Using my repo, the armored pgpkey will be automatically imported and the
> > packages are being installed without a problem.
> > 
> > Here's the TODO summary for out official repos:
> > 1. Recreate metadata for yum repos
> > 2. Replace http://archive.apache.org/dist/bigtop/KEYS to an armored key
> > 
> > I think the bigtop official repo is critical to our user experience and I
> > hope we can get it fixed ASAP. To be mentioned that Jazz Yao-Tsung Wang hits
> > the issue too and reported back to me as well.
> > If you're kind of busy I can help, too. Just let me know. Thanks!
> > 
> > Evans
> > 
> > 2015-08-24 1:48 GMT+08:00 Evans Ye <ev...@apache.org>:
> > 
> > > Hey Cos, thanks for updating the packages.
> > > I was testing the repos these days, but it still behaving strange.
> > > I constantly got "no more mirrors to try" when yum installing rpms from S3
> > > repo:
> > >
> > > Error Downloading Packages:
> > >   bigtop-utils-1.0.0-1.el6.noarch: failure:
> > > bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm from bigtop: [Errno
> > > 256] No more mirrors to try.
> > >
> > > However, the package exist and has been signed as well:
> > >
> > > $ wget
> > > http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> > > $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> > > bigtop-utils-1.0.0-1.el6.noarch.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK
> > > (MISSING KEYS: (MD5) PGP#d0c3824f)
> > >
> > > I can't figure out why for days, so I just what to bring up the issue and
> > > see if you have any clue.
> > > Does it work on your end?
> > >
> > >
> > > 2015-08-21 11:32 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > >> Ok, my mistake - I have only signed src rpms ;( My bad - apologies for
> > >> wasting
> > >> your time. Now, with the key - I can really figure out what's going on
> > >> here.
> > >> The key seems to be fine, yet rpm --checksig isn't happy about it. I've
> > >> re-imported the key as you suggested, yet ir complains that the key is
> > >> missing
> > >> during the validation phase. I want to get to the bottom of it, but at
> > >> least
> > >> we have the packages signed now (the upload should be over in about an
> > >> hour, I
> > >> hope).
> > >>
> > >> Thanks,
> > >>   Cos
> > >>
> > >> On Thu, Aug 20, 2015 at 01:31AM, Evans Ye wrote:
> > >> > Hi Cos,
> > >> >
> > >> > I've verified deb repos, and they're good as what you said, however, it
> > >> > seems that rpms are still not being signed. I don't have too much
> > >> knowledge
> > >> > on this so I did my homework and conduct the following evaluation.
> > >> > Here's my evaluation steps, please advise if any thing incorrect:
> > >> >
> > >> > First, download a rpm from S3, which should be already signed:
> > >> >
> > >> > $ wget
> > >> >
> > >> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> > >> > $ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> > >> > bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK
> > >> >
> > >> > As shown above, the rpm does not being signed.
> > >> > A signed rpm should be looked like this:
> > >> >
> > >> > $ rpm --checksig puppetlabs-release-el-6.noarch.rpm
> > >> > puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> > >> >
> > >> > And after I signed the rpm by my key, the rpm looks good now:
> > >> >
> > >> > $ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
> > >> > $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> > >> > bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> > >> >
> > >> > OTOH, it looks like the pgpkey for rpm packages needs to be armored when
> > >> > exporting, for example:
> > >> >
> > >> > $ gpg --armor --output KEYS --export 'Evans Ye'
> > >> >
> > >> > Otherwise, an error occurs when importing a non-armored key:
> > >> >
> > >> > $ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
> > >> > error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2
> > >> not an
> > >> > armored public key.
> > >> >
> > >> > A good thing for that is we can fix it in the cloud.
> > >> > Sorry for not discovering this at the very beginning. :(
> > >> >
> > >> > Evans
> > >> >
> > >> >
> > >> > 2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >> >
> > >> > > On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> > >> > > > Well, sorry. When I do manually test on those repos, I got package
> > >> is not
> > >> > > > signed message...
> > >> > > > It turns out that our puppet recipe sets pgpkey checking to false,
> > >> which
> > >> > > is
> > >> > > > why I got things working without a problem.
> > >> > > > I assume the repo should just work by dropping it into
> > >> /etc/yum.repos.d/.
> > >> > > > No need to import pgpkey manually, right?
> > >> > >
> > >> > > Hmm... with ubuntu repo the signatures are there because I had to run
> > >> > > apt-addkey manually to make apt recognize the signatures. Otherwise,
> > >> > > apt-get update didn't work.
> > >> > >
> > >> > > You might need to do something similar with yum - I am not really
> > >> sure.
> > >> > > But I
> > >> > > am positive that I have signed the packages per the insructions on our
> > >> > > release
> > >> > > page.
> > >> > >
> > >> > >   Cos
> > >> > >
> > >> > > > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >> > > >
> > >> > > > > I think we are in good position - I was worries about keys being
> > >> not
> > >> > > found
> > >> > > > > or
> > >> > > > > something like this. If two of them are ok, then the rest should
> > >> be
> > >> > > fine
> > >> > > > > too.
> > >> > > > >
> > >> > > > > Thank you very much for the confirmation and testing - really
> > >> > > appreciate
> > >> > > > > it!
> > >> > > > > I will send the announcement shortly.
> > >> > > > >
> > >> > > > > Regards,
> > >> > > > >   Cos
> > >> > > > >
> > >> > > > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > >> > > > > > We're so close to the finished line! Thank you everybody!
> > >> > > > > > I took sometime to run the deployment test before I go to bed.
> > >> > > > > > Specifically I've tested centos-6, debian-8 repo, both work
> > >> like a
> > >> > > charm.
> > >> > > > > > It should be all good, if no hurry I'll do more test tomorrow.
> > >> :)
> > >> > > > > >
> > >> > > > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >> > > > > >
> > >> > > > > > > See? I can not even write word "dense" without making a
> > >> typo...
> > >> > > That's
> > >> > > > > how
> > >> > > > > > > hot
> > >> > > > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh
> > >> boy,
> > >> > > was
> > >> > > > > it
> > >> > > > > > > fun?), and updated the repo files in the release under
> > >> > > > > > >
> > >> > > https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > >> > > > > > >
> > >> > > > > > > If you have a cycle or two - please do some quick validation
> > >> and I
> > >> > > will
> > >> > > > > > > send
> > >> > > > > > > the announcement to make the release final.
> > >> > > > > > >
> > >> > > > > > > Thanks everyone
> > >> > > > > > >   Cos
> > >> > > > > > >
> > >> > > > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > >> > > > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
> > >> > > outside ;(
> > >> > > > > > > Thanks!
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > >> > > > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> > >> > > > > cos@apache.org>
> > >> > > > > > > wrote:
> > >> > > > > > > > > > Make sense - wgetting the stuff now. centos is done,
> > >> debs and
> > >> > > > > fedora
> > >> > > > > > > to go.
> > >> > > > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > >> > > > > > > > >
> > >> > > > > > > > > IIRC, this had to do with double caching of packages.
> > >> IOW, you
> > >> > > only
> > >> > > > > > > > > need to make this available:
> > >> > > > > > > > >
> > >> > > > > > >
> > >> > > > >
> > >> > >
> > >> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > >> > > > > > > > >
> > >> > > > > > > > > not the top level dir.
> > >> > > > > > > > >
> > >> > > > > > > > > Thanks,
> > >> > > > > > > > > Roman.
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > >
> > >> > >
> > >>
> > >
> > >

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
Arghhh... of course. I completely forgot about this ;( And I have updated the
wiki release page, to avoid forgetting this in the future.

Synced the repodata folders to S3 - everything should be fine now.
Thanks a lot for your help!
  Cos

On Mon, Aug 31, 2015 at 03:37AM, Evans Ye wrote:
> Hi Cos,
> 
> I finally found the issue by reproducing a repo in my S3 buckets.
> The answer is that the repodata needs to be regenerated after RPMs are
> being signed.
> 
> Here's my testing steps:
> 
> 1. download the whole built repo from jenkins release built as archive.zip
> and unzip it
> 2. sign RPMs:
>   $ find -name *.rpm | xargs rpm --define="%_gpg_name Evans Ye" --addsign
> *3. recreate the metadata*
> *  $ rm -rf repodata; createrepo -v .*
> 3. upload to S3 bucket:
>   $
> aws s3 cp bigtop-1.0.0-rpm-centos-6-output/
> s3://evansye/bigtop/centos/6/x86_64 --recursive
> 
> My repo:
> [bigtop]
> name=Bigtop
> enabled=1
> gpgcheck=1
> baseurl=https://s3-us-west-1.amazonaws.com/evansye/bigtop/centos/6/x86_64
> gpgkey=https://s3-us-west-1.amazonaws.com/evansye/bigtop/KEYS
> 
> Using my repo, the armored pgpkey will be automatically imported and the
> packages are being installed without a problem.
> 
> Here's the TODO summary for out official repos:
> 1. Recreate metadata for yum repos
> 2. Replace http://archive.apache.org/dist/bigtop/KEYS to an armored key
> 
> I think the bigtop official repo is critical to our user experience and I
> hope we can get it fixed ASAP. To be mentioned that Jazz Yao-Tsung Wang hits
> the issue too and reported back to me as well.
> If you're kind of busy I can help, too. Just let me know. Thanks!
> 
> Evans
> 
> 2015-08-24 1:48 GMT+08:00 Evans Ye <ev...@apache.org>:
> 
> > Hey Cos, thanks for updating the packages.
> > I was testing the repos these days, but it still behaving strange.
> > I constantly got "no more mirrors to try" when yum installing rpms from S3
> > repo:
> >
> > Error Downloading Packages:
> >   bigtop-utils-1.0.0-1.el6.noarch: failure:
> > bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm from bigtop: [Errno
> > 256] No more mirrors to try.
> >
> > However, the package exist and has been signed as well:
> >
> > $ wget
> > http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> > $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> > bigtop-utils-1.0.0-1.el6.noarch.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK
> > (MISSING KEYS: (MD5) PGP#d0c3824f)
> >
> > I can't figure out why for days, so I just what to bring up the issue and
> > see if you have any clue.
> > Does it work on your end?
> >
> >
> > 2015-08-21 11:32 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> >> Ok, my mistake - I have only signed src rpms ;( My bad - apologies for
> >> wasting
> >> your time. Now, with the key - I can really figure out what's going on
> >> here.
> >> The key seems to be fine, yet rpm --checksig isn't happy about it. I've
> >> re-imported the key as you suggested, yet ir complains that the key is
> >> missing
> >> during the validation phase. I want to get to the bottom of it, but at
> >> least
> >> we have the packages signed now (the upload should be over in about an
> >> hour, I
> >> hope).
> >>
> >> Thanks,
> >>   Cos
> >>
> >> On Thu, Aug 20, 2015 at 01:31AM, Evans Ye wrote:
> >> > Hi Cos,
> >> >
> >> > I've verified deb repos, and they're good as what you said, however, it
> >> > seems that rpms are still not being signed. I don't have too much
> >> knowledge
> >> > on this so I did my homework and conduct the following evaluation.
> >> > Here's my evaluation steps, please advise if any thing incorrect:
> >> >
> >> > First, download a rpm from S3, which should be already signed:
> >> >
> >> > $ wget
> >> >
> >> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> >> > $ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> >> > bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK
> >> >
> >> > As shown above, the rpm does not being signed.
> >> > A signed rpm should be looked like this:
> >> >
> >> > $ rpm --checksig puppetlabs-release-el-6.noarch.rpm
> >> > puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> >> >
> >> > And after I signed the rpm by my key, the rpm looks good now:
> >> >
> >> > $ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
> >> > $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> >> > bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> >> >
> >> > OTOH, it looks like the pgpkey for rpm packages needs to be armored when
> >> > exporting, for example:
> >> >
> >> > $ gpg --armor --output KEYS --export 'Evans Ye'
> >> >
> >> > Otherwise, an error occurs when importing a non-armored key:
> >> >
> >> > $ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
> >> > error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2
> >> not an
> >> > armored public key.
> >> >
> >> > A good thing for that is we can fix it in the cloud.
> >> > Sorry for not discovering this at the very beginning. :(
> >> >
> >> > Evans
> >> >
> >> >
> >> > 2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >> >
> >> > > On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> >> > > > Well, sorry. When I do manually test on those repos, I got package
> >> is not
> >> > > > signed message...
> >> > > > It turns out that our puppet recipe sets pgpkey checking to false,
> >> which
> >> > > is
> >> > > > why I got things working without a problem.
> >> > > > I assume the repo should just work by dropping it into
> >> /etc/yum.repos.d/.
> >> > > > No need to import pgpkey manually, right?
> >> > >
> >> > > Hmm... with ubuntu repo the signatures are there because I had to run
> >> > > apt-addkey manually to make apt recognize the signatures. Otherwise,
> >> > > apt-get update didn't work.
> >> > >
> >> > > You might need to do something similar with yum - I am not really
> >> sure.
> >> > > But I
> >> > > am positive that I have signed the packages per the insructions on our
> >> > > release
> >> > > page.
> >> > >
> >> > >   Cos
> >> > >
> >> > > > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >> > > >
> >> > > > > I think we are in good position - I was worries about keys being
> >> not
> >> > > found
> >> > > > > or
> >> > > > > something like this. If two of them are ok, then the rest should
> >> be
> >> > > fine
> >> > > > > too.
> >> > > > >
> >> > > > > Thank you very much for the confirmation and testing - really
> >> > > appreciate
> >> > > > > it!
> >> > > > > I will send the announcement shortly.
> >> > > > >
> >> > > > > Regards,
> >> > > > >   Cos
> >> > > > >
> >> > > > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> >> > > > > > We're so close to the finished line! Thank you everybody!
> >> > > > > > I took sometime to run the deployment test before I go to bed.
> >> > > > > > Specifically I've tested centos-6, debian-8 repo, both work
> >> like a
> >> > > charm.
> >> > > > > > It should be all good, if no hurry I'll do more test tomorrow.
> >> :)
> >> > > > > >
> >> > > > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >> > > > > >
> >> > > > > > > See? I can not even write word "dense" without making a
> >> typo...
> >> > > That's
> >> > > > > how
> >> > > > > > > hot
> >> > > > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh
> >> boy,
> >> > > was
> >> > > > > it
> >> > > > > > > fun?), and updated the repo files in the release under
> >> > > > > > >
> >> > > https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> >> > > > > > >
> >> > > > > > > If you have a cycle or two - please do some quick validation
> >> and I
> >> > > will
> >> > > > > > > send
> >> > > > > > > the announcement to make the release final.
> >> > > > > > >
> >> > > > > > > Thanks everyone
> >> > > > > > >   Cos
> >> > > > > > >
> >> > > > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> >> > > > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
> >> > > outside ;(
> >> > > > > > > Thanks!
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> >> > > > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> >> > > > > cos@apache.org>
> >> > > > > > > wrote:
> >> > > > > > > > > > Make sense - wgetting the stuff now. centos is done,
> >> debs and
> >> > > > > fedora
> >> > > > > > > to go.
> >> > > > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> >> > > > > > > > >
> >> > > > > > > > > IIRC, this had to do with double caching of packages.
> >> IOW, you
> >> > > only
> >> > > > > > > > > need to make this available:
> >> > > > > > > > >
> >> > > > > > >
> >> > > > >
> >> > >
> >> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> >> > > > > > > > >
> >> > > > > > > > > not the top level dir.
> >> > > > > > > > >
> >> > > > > > > > > Thanks,
> >> > > > > > > > > Roman.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > >
> >> > >
> >>
> >
> >

Re: convenience artifacts are signed and uploaded

Posted by Evans Ye <ev...@apache.org>.
Hi Cos,

I finally found the issue by reproducing a repo in my S3 buckets.
The answer is that the repodata needs to be regenerated after RPMs are
being signed.

Here's my testing steps:

1. download the whole built repo from jenkins release built as archive.zip
and unzip it
2. sign RPMs:
  $ find -name *.rpm | xargs rpm --define="%_gpg_name Evans Ye" --addsign
*3. recreate the metadata*
*  $ rm -rf repodata; createrepo -v .*
3. upload to S3 bucket:
  $
aws s3 cp bigtop-1.0.0-rpm-centos-6-output/
s3://evansye/bigtop/centos/6/x86_64 --recursive

My repo:
[bigtop]
name=Bigtop
enabled=1
gpgcheck=1
baseurl=https://s3-us-west-1.amazonaws.com/evansye/bigtop/centos/6/x86_64
gpgkey=https://s3-us-west-1.amazonaws.com/evansye/bigtop/KEYS

Using my repo, the armored pgpkey will be automatically imported and the
packages are being installed without a problem.

Here's the TODO summary for out official repos:
1. Recreate metadata for yum repos
2. Replace http://archive.apache.org/dist/bigtop/KEYS to an armored key

I think the bigtop official repo is critical to our user experience and I
hope we can get it fixed ASAP. To be mentioned that Jazz Yao-Tsung Wang hits
the issue too and reported back to me as well.
If you're kind of busy I can help, too. Just let me know. Thanks!

Evans

2015-08-24 1:48 GMT+08:00 Evans Ye <ev...@apache.org>:

> Hey Cos, thanks for updating the packages.
> I was testing the repos these days, but it still behaving strange.
> I constantly got "no more mirrors to try" when yum installing rpms from S3
> repo:
>
> Error Downloading Packages:
>   bigtop-utils-1.0.0-1.el6.noarch: failure:
> bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm from bigtop: [Errno
> 256] No more mirrors to try.
>
> However, the package exist and has been signed as well:
>
> $ wget
> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> bigtop-utils-1.0.0-1.el6.noarch.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK
> (MISSING KEYS: (MD5) PGP#d0c3824f)
>
> I can't figure out why for days, so I just what to bring up the issue and
> see if you have any clue.
> Does it work on your end?
>
>
> 2015-08-21 11:32 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>
>> Ok, my mistake - I have only signed src rpms ;( My bad - apologies for
>> wasting
>> your time. Now, with the key - I can really figure out what's going on
>> here.
>> The key seems to be fine, yet rpm --checksig isn't happy about it. I've
>> re-imported the key as you suggested, yet ir complains that the key is
>> missing
>> during the validation phase. I want to get to the bottom of it, but at
>> least
>> we have the packages signed now (the upload should be over in about an
>> hour, I
>> hope).
>>
>> Thanks,
>>   Cos
>>
>> On Thu, Aug 20, 2015 at 01:31AM, Evans Ye wrote:
>> > Hi Cos,
>> >
>> > I've verified deb repos, and they're good as what you said, however, it
>> > seems that rpms are still not being signed. I don't have too much
>> knowledge
>> > on this so I did my homework and conduct the following evaluation.
>> > Here's my evaluation steps, please advise if any thing incorrect:
>> >
>> > First, download a rpm from S3, which should be already signed:
>> >
>> > $ wget
>> >
>> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
>> > $ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
>> > bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK
>> >
>> > As shown above, the rpm does not being signed.
>> > A signed rpm should be looked like this:
>> >
>> > $ rpm --checksig puppetlabs-release-el-6.noarch.rpm
>> > puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
>> >
>> > And after I signed the rpm by my key, the rpm looks good now:
>> >
>> > $ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
>> > $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
>> > bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
>> >
>> > OTOH, it looks like the pgpkey for rpm packages needs to be armored when
>> > exporting, for example:
>> >
>> > $ gpg --armor --output KEYS --export 'Evans Ye'
>> >
>> > Otherwise, an error occurs when importing a non-armored key:
>> >
>> > $ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
>> > error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2
>> not an
>> > armored public key.
>> >
>> > A good thing for that is we can fix it in the cloud.
>> > Sorry for not discovering this at the very beginning. :(
>> >
>> > Evans
>> >
>> >
>> > 2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>> >
>> > > On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
>> > > > Well, sorry. When I do manually test on those repos, I got package
>> is not
>> > > > signed message...
>> > > > It turns out that our puppet recipe sets pgpkey checking to false,
>> which
>> > > is
>> > > > why I got things working without a problem.
>> > > > I assume the repo should just work by dropping it into
>> /etc/yum.repos.d/.
>> > > > No need to import pgpkey manually, right?
>> > >
>> > > Hmm... with ubuntu repo the signatures are there because I had to run
>> > > apt-addkey manually to make apt recognize the signatures. Otherwise,
>> > > apt-get update didn't work.
>> > >
>> > > You might need to do something similar with yum - I am not really
>> sure.
>> > > But I
>> > > am positive that I have signed the packages per the insructions on our
>> > > release
>> > > page.
>> > >
>> > >   Cos
>> > >
>> > > > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>> > > >
>> > > > > I think we are in good position - I was worries about keys being
>> not
>> > > found
>> > > > > or
>> > > > > something like this. If two of them are ok, then the rest should
>> be
>> > > fine
>> > > > > too.
>> > > > >
>> > > > > Thank you very much for the confirmation and testing - really
>> > > appreciate
>> > > > > it!
>> > > > > I will send the announcement shortly.
>> > > > >
>> > > > > Regards,
>> > > > >   Cos
>> > > > >
>> > > > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
>> > > > > > We're so close to the finished line! Thank you everybody!
>> > > > > > I took sometime to run the deployment test before I go to bed.
>> > > > > > Specifically I've tested centos-6, debian-8 repo, both work
>> like a
>> > > charm.
>> > > > > > It should be all good, if no hurry I'll do more test tomorrow.
>> :)
>> > > > > >
>> > > > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>> > > > > >
>> > > > > > > See? I can not even write word "dense" without making a
>> typo...
>> > > That's
>> > > > > how
>> > > > > > > hot
>> > > > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh
>> boy,
>> > > was
>> > > > > it
>> > > > > > > fun?), and updated the repo files in the release under
>> > > > > > >
>> > > https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
>> > > > > > >
>> > > > > > > If you have a cycle or two - please do some quick validation
>> and I
>> > > will
>> > > > > > > send
>> > > > > > > the announcement to make the release final.
>> > > > > > >
>> > > > > > > Thanks everyone
>> > > > > > >   Cos
>> > > > > > >
>> > > > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
>> > > > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
>> > > outside ;(
>> > > > > > > Thanks!
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
>> > > > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
>> > > > > cos@apache.org>
>> > > > > > > wrote:
>> > > > > > > > > > Make sense - wgetting the stuff now. centos is done,
>> debs and
>> > > > > fedora
>> > > > > > > to go.
>> > > > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
>> > > > > > > > >
>> > > > > > > > > IIRC, this had to do with double caching of packages.
>> IOW, you
>> > > only
>> > > > > > > > > need to make this available:
>> > > > > > > > >
>> > > > > > >
>> > > > >
>> > >
>> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
>> > > > > > > > >
>> > > > > > > > > not the top level dir.
>> > > > > > > > >
>> > > > > > > > > Thanks,
>> > > > > > > > > Roman.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > >
>> > >
>>
>
>

Re: convenience artifacts are signed and uploaded

Posted by Evans Ye <ev...@apache.org>.
Hey Cos, thanks for updating the packages.
I was testing the repos these days, but it still behaving strange.
I constantly got "no more mirrors to try" when yum installing rpms from S3
repo:

Error Downloading Packages:
  bigtop-utils-1.0.0-1.el6.noarch: failure:
bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm from bigtop: [Errno
256] No more mirrors to try.

However, the package exist and has been signed as well:

$ wget
http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
$ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
bigtop-utils-1.0.0-1.el6.noarch.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK
(MISSING KEYS: (MD5) PGP#d0c3824f)

I can't figure out why for days, so I just what to bring up the issue and
see if you have any clue.
Does it work on your end?


2015-08-21 11:32 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> Ok, my mistake - I have only signed src rpms ;( My bad - apologies for
> wasting
> your time. Now, with the key - I can really figure out what's going on
> here.
> The key seems to be fine, yet rpm --checksig isn't happy about it. I've
> re-imported the key as you suggested, yet ir complains that the key is
> missing
> during the validation phase. I want to get to the bottom of it, but at
> least
> we have the packages signed now (the upload should be over in about an
> hour, I
> hope).
>
> Thanks,
>   Cos
>
> On Thu, Aug 20, 2015 at 01:31AM, Evans Ye wrote:
> > Hi Cos,
> >
> > I've verified deb repos, and they're good as what you said, however, it
> > seems that rpms are still not being signed. I don't have too much
> knowledge
> > on this so I did my homework and conduct the following evaluation.
> > Here's my evaluation steps, please advise if any thing incorrect:
> >
> > First, download a rpm from S3, which should be already signed:
> >
> > $ wget
> >
> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> > $ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> > bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK
> >
> > As shown above, the rpm does not being signed.
> > A signed rpm should be looked like this:
> >
> > $ rpm --checksig puppetlabs-release-el-6.noarch.rpm
> > puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> >
> > And after I signed the rpm by my key, the rpm looks good now:
> >
> > $ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
> > $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> > bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> >
> > OTOH, it looks like the pgpkey for rpm packages needs to be armored when
> > exporting, for example:
> >
> > $ gpg --armor --output KEYS --export 'Evans Ye'
> >
> > Otherwise, an error occurs when importing a non-armored key:
> >
> > $ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
> > error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2
> not an
> > armored public key.
> >
> > A good thing for that is we can fix it in the cloud.
> > Sorry for not discovering this at the very beginning. :(
> >
> > Evans
> >
> >
> > 2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> > > > Well, sorry. When I do manually test on those repos, I got package
> is not
> > > > signed message...
> > > > It turns out that our puppet recipe sets pgpkey checking to false,
> which
> > > is
> > > > why I got things working without a problem.
> > > > I assume the repo should just work by dropping it into
> /etc/yum.repos.d/.
> > > > No need to import pgpkey manually, right?
> > >
> > > Hmm... with ubuntu repo the signatures are there because I had to run
> > > apt-addkey manually to make apt recognize the signatures. Otherwise,
> > > apt-get update didn't work.
> > >
> > > You might need to do something similar with yum - I am not really sure.
> > > But I
> > > am positive that I have signed the packages per the insructions on our
> > > release
> > > page.
> > >
> > >   Cos
> > >
> > > > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > I think we are in good position - I was worries about keys being
> not
> > > found
> > > > > or
> > > > > something like this. If two of them are ok, then the rest should be
> > > fine
> > > > > too.
> > > > >
> > > > > Thank you very much for the confirmation and testing - really
> > > appreciate
> > > > > it!
> > > > > I will send the announcement shortly.
> > > > >
> > > > > Regards,
> > > > >   Cos
> > > > >
> > > > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > > > > > We're so close to the finished line! Thank you everybody!
> > > > > > I took sometime to run the deployment test before I go to bed.
> > > > > > Specifically I've tested centos-6, debian-8 repo, both work like
> a
> > > charm.
> > > > > > It should be all good, if no hurry I'll do more test tomorrow. :)
> > > > > >
> > > > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > > >
> > > > > > > See? I can not even write word "dense" without making a typo...
> > > That's
> > > > > how
> > > > > > > hot
> > > > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh
> boy,
> > > was
> > > > > it
> > > > > > > fun?), and updated the repo files in the release under
> > > > > > >
> > > https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > > > > > >
> > > > > > > If you have a cycle or two - please do some quick validation
> and I
> > > will
> > > > > > > send
> > > > > > > the announcement to make the release final.
> > > > > > >
> > > > > > > Thanks everyone
> > > > > > >   Cos
> > > > > > >
> > > > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
> > > outside ;(
> > > > > > > Thanks!
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> > > > > cos@apache.org>
> > > > > > > wrote:
> > > > > > > > > > Make sense - wgetting the stuff now. centos is done,
> debs and
> > > > > fedora
> > > > > > > to go.
> > > > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > > > > > > >
> > > > > > > > > IIRC, this had to do with double caching of packages. IOW,
> you
> > > only
> > > > > > > > > need to make this available:
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > > > > > > >
> > > > > > > > > not the top level dir.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Roman.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
Ok, my mistake - I have only signed src rpms ;( My bad - apologies for wasting
your time. Now, with the key - I can really figure out what's going on here.
The key seems to be fine, yet rpm --checksig isn't happy about it. I've
re-imported the key as you suggested, yet ir complains that the key is missing
during the validation phase. I want to get to the bottom of it, but at least
we have the packages signed now (the upload should be over in about an hour, I
hope).

Thanks,
  Cos

On Thu, Aug 20, 2015 at 01:31AM, Evans Ye wrote:
> Hi Cos,
> 
> I've verified deb repos, and they're good as what you said, however, it
> seems that rpms are still not being signed. I don't have too much knowledge
> on this so I did my homework and conduct the following evaluation.
> Here's my evaluation steps, please advise if any thing incorrect:
> 
> First, download a rpm from S3, which should be already signed:
> 
> $ wget
> http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> $ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
> bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK
> 
> As shown above, the rpm does not being signed.
> A signed rpm should be looked like this:
> 
> $ rpm --checksig puppetlabs-release-el-6.noarch.rpm
> puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> 
> And after I signed the rpm by my key, the rpm looks good now:
> 
> $ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
> $ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
> bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK
> 
> OTOH, it looks like the pgpkey for rpm packages needs to be armored when
> exporting, for example:
> 
> $ gpg --armor --output KEYS --export 'Evans Ye'
> 
> Otherwise, an error occurs when importing a non-armored key:
> 
> $ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
> error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2 not an
> armored public key.
> 
> A good thing for that is we can fix it in the cloud.
> Sorry for not discovering this at the very beginning. :(
> 
> Evans
> 
> 
> 2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> 
> > On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> > > Well, sorry. When I do manually test on those repos, I got package is not
> > > signed message...
> > > It turns out that our puppet recipe sets pgpkey checking to false, which
> > is
> > > why I got things working without a problem.
> > > I assume the repo should just work by dropping it into /etc/yum.repos.d/.
> > > No need to import pgpkey manually, right?
> >
> > Hmm... with ubuntu repo the signatures are there because I had to run
> > apt-addkey manually to make apt recognize the signatures. Otherwise,
> > apt-get update didn't work.
> >
> > You might need to do something similar with yum - I am not really sure.
> > But I
> > am positive that I have signed the packages per the insructions on our
> > release
> > page.
> >
> >   Cos
> >
> > > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > > > I think we are in good position - I was worries about keys being not
> > found
> > > > or
> > > > something like this. If two of them are ok, then the rest should be
> > fine
> > > > too.
> > > >
> > > > Thank you very much for the confirmation and testing - really
> > appreciate
> > > > it!
> > > > I will send the announcement shortly.
> > > >
> > > > Regards,
> > > >   Cos
> > > >
> > > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > > > > We're so close to the finished line! Thank you everybody!
> > > > > I took sometime to run the deployment test before I go to bed.
> > > > > Specifically I've tested centos-6, debian-8 repo, both work like a
> > charm.
> > > > > It should be all good, if no hurry I'll do more test tomorrow. :)
> > > > >
> > > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > >
> > > > > > See? I can not even write word "dense" without making a typo...
> > That's
> > > > how
> > > > > > hot
> > > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh boy,
> > was
> > > > it
> > > > > > fun?), and updated the repo files in the release under
> > > > > >
> > https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > > > > >
> > > > > > If you have a cycle or two - please do some quick validation and I
> > will
> > > > > > send
> > > > > > the announcement to make the release final.
> > > > > >
> > > > > > Thanks everyone
> > > > > >   Cos
> > > > > >
> > > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
> > outside ;(
> > > > > > Thanks!
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> > > > cos@apache.org>
> > > > > > wrote:
> > > > > > > > > Make sense - wgetting the stuff now. centos is done, debs and
> > > > fedora
> > > > > > to go.
> > > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > > > > > >
> > > > > > > > IIRC, this had to do with double caching of packages. IOW, you
> > only
> > > > > > > > need to make this available:
> > > > > > > >
> > > > > >
> > > >
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > > > > > >
> > > > > > > > not the top level dir.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Roman.
> > > > > >
> > > > > >
> > > > > >
> > > >
> >

Re: convenience artifacts are signed and uploaded

Posted by Evans Ye <ev...@apache.org>.
Hi Cos,

I've verified deb repos, and they're good as what you said, however, it
seems that rpms are still not being signed. I don't have too much knowledge
on this so I did my homework and conduct the following evaluation.
Here's my evaluation steps, please advise if any thing incorrect:

First, download a rpm from S3, which should be already signed:

$ wget
http://bigtop.s3.amazonaws.com/releases/1.0.0/centos/6/x86_64/bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
$ rpm --checksig bigtop-utils/noarch/bigtop-utils-1.0.0-1.el6.noarch.rpm
bigtop-utils-1.0.0-1.el6.noarch.rpm.1: sha1 md5 OK

As shown above, the rpm does not being signed.
A signed rpm should be looked like this:

$ rpm --checksig puppetlabs-release-el-6.noarch.rpm
puppetlabs-release-el-6.noarch.rpm: rsa sha1 (md5) pgp md5 OK

And after I signed the rpm by my key, the rpm looks good now:

$ rpm --addsign bigtop-utils-1.0.0-1.el6.noarch.rpm
$ rpm --checksig bigtop-utils-1.0.0-1.el6.noarch.rpm
bigtop-utils-1.0.0-1.el6.noarch.rpm: rsa sha1 (md5) pgp md5 OK

OTOH, it looks like the pgpkey for rpm packages needs to be armored when
exporting, for example:

$ gpg --armor --output KEYS --export 'Evans Ye'

Otherwise, an error occurs when importing a non-armored key:

$ rpm --import https://dist.apache.org/repos/dist/release/bigtop/KEYS
error: https://dist.apache.org/repos/dist/release/bigtop/KEYS: key 2 not an
armored public key.

A good thing for that is we can fix it in the cloud.
Sorry for not discovering this at the very beginning. :(

Evans


2015-08-19 4:12 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> > Well, sorry. When I do manually test on those repos, I got package is not
> > signed message...
> > It turns out that our puppet recipe sets pgpkey checking to false, which
> is
> > why I got things working without a problem.
> > I assume the repo should just work by dropping it into /etc/yum.repos.d/.
> > No need to import pgpkey manually, right?
>
> Hmm... with ubuntu repo the signatures are there because I had to run
> apt-addkey manually to make apt recognize the signatures. Otherwise,
> apt-get update didn't work.
>
> You might need to do something similar with yum - I am not really sure.
> But I
> am positive that I have signed the packages per the insructions on our
> release
> page.
>
>   Cos
>
> > 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > I think we are in good position - I was worries about keys being not
> found
> > > or
> > > something like this. If two of them are ok, then the rest should be
> fine
> > > too.
> > >
> > > Thank you very much for the confirmation and testing - really
> appreciate
> > > it!
> > > I will send the announcement shortly.
> > >
> > > Regards,
> > >   Cos
> > >
> > > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > > > We're so close to the finished line! Thank you everybody!
> > > > I took sometime to run the deployment test before I go to bed.
> > > > Specifically I've tested centos-6, debian-8 repo, both work like a
> charm.
> > > > It should be all good, if no hurry I'll do more test tomorrow. :)
> > > >
> > > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > See? I can not even write word "dense" without making a typo...
> That's
> > > how
> > > > > hot
> > > > > it is. Anyway, I have uploaded all signed packages to s3 (oh boy,
> was
> > > it
> > > > > fun?), and updated the repo files in the release under
> > > > >
> https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > > > >
> > > > > If you have a cycle or two - please do some quick validation and I
> will
> > > > > send
> > > > > the announcement to make the release final.
> > > > >
> > > > > Thanks everyone
> > > > >   Cos
> > > > >
> > > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > > > > Ah, of cource ... I am so sense when it's  in the 100's F
> outside ;(
> > > > > Thanks!
> > > > > >
> > > > > >
> > > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> > > cos@apache.org>
> > > > > wrote:
> > > > > > > > Make sense - wgetting the stuff now. centos is done, debs and
> > > fedora
> > > > > to go.
> > > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > > > > >
> > > > > > > IIRC, this had to do with double caching of packages. IOW, you
> only
> > > > > > > need to make this available:
> > > > > > >
> > > > >
> > >
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > > > > >
> > > > > > > not the top level dir.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Roman.
> > > > >
> > > > >
> > > > >
> > >
>

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Aug 19, 2015 at 02:12AM, Evans Ye wrote:
> Well, sorry. When I do manually test on those repos, I got package is not
> signed message...
> It turns out that our puppet recipe sets pgpkey checking to false, which is
> why I got things working without a problem.
> I assume the repo should just work by dropping it into /etc/yum.repos.d/.
> No need to import pgpkey manually, right?

Hmm... with ubuntu repo the signatures are there because I had to run
apt-addkey manually to make apt recognize the signatures. Otherwise,
apt-get update didn't work.

You might need to do something similar with yum - I am not really sure. But I
am positive that I have signed the packages per the insructions on our release
page.

  Cos

> 2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> 
> > I think we are in good position - I was worries about keys being not found
> > or
> > something like this. If two of them are ok, then the rest should be fine
> > too.
> >
> > Thank you very much for the confirmation and testing - really appreciate
> > it!
> > I will send the announcement shortly.
> >
> > Regards,
> >   Cos
> >
> > On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > > We're so close to the finished line! Thank you everybody!
> > > I took sometime to run the deployment test before I go to bed.
> > > Specifically I've tested centos-6, debian-8 repo, both work like a charm.
> > > It should be all good, if no hurry I'll do more test tomorrow. :)
> > >
> > > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > > > See? I can not even write word "dense" without making a typo... That's
> > how
> > > > hot
> > > > it is. Anyway, I have uploaded all signed packages to s3 (oh boy, was
> > it
> > > > fun?), and updated the repo files in the release under
> > > >     https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > > >
> > > > If you have a cycle or two - please do some quick validation and I will
> > > > send
> > > > the announcement to make the release final.
> > > >
> > > > Thanks everyone
> > > >   Cos
> > > >
> > > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > > > Ah, of cource ... I am so sense when it's  in the 100's F outside ;(
> > > > Thanks!
> > > > >
> > > > >
> > > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> > cos@apache.org>
> > > > wrote:
> > > > > > > Make sense - wgetting the stuff now. centos is done, debs and
> > fedora
> > > > to go.
> > > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > > > >
> > > > > > IIRC, this had to do with double caching of packages. IOW, you only
> > > > > > need to make this available:
> > > > > >
> > > >
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > > > >
> > > > > > not the top level dir.
> > > > > >
> > > > > > Thanks,
> > > > > > Roman.
> > > >
> > > >
> > > >
> >

Re: convenience artifacts are signed and uploaded

Posted by Evans Ye <ev...@apache.org>.
Well, sorry. When I do manually test on those repos, I got package is not
signed message...
It turns out that our puppet recipe sets pgpkey checking to false, which is
why I got things working without a problem.
I assume the repo should just work by dropping it into /etc/yum.repos.d/.
No need to import pgpkey manually, right?

2015-08-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> I think we are in good position - I was worries about keys being not found
> or
> something like this. If two of them are ok, then the rest should be fine
> too.
>
> Thank you very much for the confirmation and testing - really appreciate
> it!
> I will send the announcement shortly.
>
> Regards,
>   Cos
>
> On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> > We're so close to the finished line! Thank you everybody!
> > I took sometime to run the deployment test before I go to bed.
> > Specifically I've tested centos-6, debian-8 repo, both work like a charm.
> > It should be all good, if no hurry I'll do more test tomorrow. :)
> >
> > 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > See? I can not even write word "dense" without making a typo... That's
> how
> > > hot
> > > it is. Anyway, I have uploaded all signed packages to s3 (oh boy, was
> it
> > > fun?), and updated the repo files in the release under
> > >     https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> > >
> > > If you have a cycle or two - please do some quick validation and I will
> > > send
> > > the announcement to make the release final.
> > >
> > > Thanks everyone
> > >   Cos
> > >
> > > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > > Ah, of cource ... I am so sense when it's  in the 100's F outside ;(
> > > Thanks!
> > > >
> > > >
> > > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <
> cos@apache.org>
> > > wrote:
> > > > > > Make sense - wgetting the stuff now. centos is done, debs and
> fedora
> > > to go.
> > > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > > >
> > > > > IIRC, this had to do with double caching of packages. IOW, you only
> > > > > need to make this available:
> > > > >
> > >
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > > >
> > > > > not the top level dir.
> > > > >
> > > > > Thanks,
> > > > > Roman.
> > >
> > >
> > >
>

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
I think we are in good position - I was worries about keys being not found or
something like this. If two of them are ok, then the rest should be fine too.

Thank you very much for the confirmation and testing - really appreciate it!
I will send the announcement shortly.

Regards,
  Cos

On Tue, Aug 18, 2015 at 02:05AM, Evans Ye wrote:
> We're so close to the finished line! Thank you everybody!
> I took sometime to run the deployment test before I go to bed.
> Specifically I've tested centos-6, debian-8 repo, both work like a charm.
> It should be all good, if no hurry I'll do more test tomorrow. :)
> 
> 2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> 
> > See? I can not even write word "dense" without making a typo... That's how
> > hot
> > it is. Anyway, I have uploaded all signed packages to s3 (oh boy, was it
> > fun?), and updated the repo files in the release under
> >     https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
> >
> > If you have a cycle or two - please do some quick validation and I will
> > send
> > the announcement to make the release final.
> >
> > Thanks everyone
> >   Cos
> >
> > On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > > Ah, of cource ... I am so sense when it's  in the 100's F outside ;(
> > Thanks!
> > >
> > >
> > > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > > > Make sense - wgetting the stuff now. centos is done, debs and fedora
> > to go.
> > > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > > >
> > > > IIRC, this had to do with double caching of packages. IOW, you only
> > > > need to make this available:
> > > >
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > > >
> > > > not the top level dir.
> > > >
> > > > Thanks,
> > > > Roman.
> >
> >
> >

Re: convenience artifacts are signed and uploaded

Posted by Evans Ye <ev...@apache.org>.
We're so close to the finished line! Thank you everybody!
I took sometime to run the deployment test before I go to bed.
Specifically I've tested centos-6, debian-8 repo, both work like a charm.
It should be all good, if no hurry I'll do more test tomorrow. :)

2015-08-17 14:00 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> See? I can not even write word "dense" without making a typo... That's how
> hot
> it is. Anyway, I have uploaded all signed packages to s3 (oh boy, was it
> fun?), and updated the repo files in the release under
>     https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/
>
> If you have a cycle or two - please do some quick validation and I will
> send
> the announcement to make the release final.
>
> Thanks everyone
>   Cos
>
> On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> > Ah, of cource ... I am so sense when it's  in the 100's F outside ;(
> Thanks!
> >
> >
> > On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > > > Make sense - wgetting the stuff now. centos is done, debs and fedora
> to go.
> > > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > >
> > > IIRC, this had to do with double caching of packages. IOW, you only
> > > need to make this available:
> > >
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > >
> > > not the top level dir.
> > >
> > > Thanks,
> > > Roman.
>
>
>

Re: convenience artifacts are signed and uploaded

Posted by Konstantin Boudnik <co...@apache.org>.
See? I can not even write word "dense" without making a typo... That's how hot
it is. Anyway, I have uploaded all signed packages to s3 (oh boy, was it
fun?), and updated the repo files in the release under 
    https://dist.apache.org/repos/dist/release/bigtop/bigtop-1.0.0/

If you have a cycle or two - please do some quick validation and I will send
the announcement to make the release final.

Thanks everyone
  Cos

On Mon, Aug 17, 2015 at 03:18AM, Konstantin Boudnik wrote:
> Ah, of cource ... I am so sense when it's  in the 100's F outside ;( Thanks!
> 
> 
> On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> > On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > > Make sense - wgetting the stuff now. centos is done, debs and fedora to go.
> > > Weirdly, deb repos are huge >2.5GB for whatever reason.
> > 
> > IIRC, this had to do with double caching of packages. IOW, you only
> > need to make this available:
> >     http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> > 
> > not the top level dir.
> > 
> > Thanks,
> > Roman.

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Ah, of cource ... I am so sense when it's  in the 100's F outside ;( Thanks!


On Sun, Aug 16, 2015 at 12:17PM, Roman Shaposhnik wrote:
> On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Make sense - wgetting the stuff now. centos is done, debs and fedora to go.
> > Weirdly, deb repos are huge >2.5GB for whatever reason.
> 
> IIRC, this had to do with double caching of packages. IOW, you only
> need to make this available:
>     http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/
> 
> not the top level dir.
> 
> Thanks,
> Roman.

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Aug 15, 2015 at 11:27 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Make sense - wgetting the stuff now. centos is done, debs and fedora to go.
> Weirdly, deb repos are huge >2.5GB for whatever reason.

IIRC, this had to do with double caching of packages. IOW, you only
need to make this available:
    http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/BUILD_ENVIRONMENTS=debian-8,label=docker-slave-07/lastSuccessfulBuild/artifact/output/apt/

not the top level dir.

Thanks,
Roman.

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Make sense - wgetting the stuff now. centos is done, debs and fedora to go.
Weirdly, deb repos are huge >2.5GB for whatever reason. At any rate, looks
like having a release job that also will be signing repos (was it Olaf who
suggested it at some point?) might be quite beneficial in the future.

As for suse - seems like a bug in the Tez packaging, which we should be fixing
in 1.1 Peter, any idea what's causing it (if you're around)?

Thanks,
  Cos

On Sun, Aug 16, 2015 at 01:38PM, Evans Ye wrote:
> Yes, AFAIK wget is the best way to do it.
> I always wget the archive.zip and unzip it into bigtop/output folder, then
> I can use local repo to run bigtop provisioner.
> 
> Regarding to suse, we don't have binaries for it now.
> There's a wired error when building packages on suse docker container:
> 
> *16:18:31*  Copy /ws/dl/apache-tez-0.6.0-src.tar.gz to
> /ws/build/tez/tar/apache-tez-0.6.0-src.tar.gz*16:18:31*
> :tez-srpmerror: line 34: Unclosed %if
> 
> 
> The full log:
> 
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0/BUILD_ENVIRONMENTS=opensuse-13.2,label=docker-slave-06/14/console
> 
> 
> I assume its an environment difference causing the issue happened,
> maybe suse expert can help.
> 
> At this point I thing we can just state that we don't have binary
> convenience files for suse.
> 
> 
> Evans
> 
> 
> 2015-08-16 4:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> 
> > Good point! Will do.
> >
> > We don't have a way to build Suse bits right now, right?
> >
> > Cos
> >
> > On Sat, Aug 15, 2015 at 01:30PM, nate@reactor8.com wrote:
> > > Think just wget zip of the full assets for each rpm and deb, unless
> > Evans already copied somewhere.
> > >
> > > You pulling down to apache infra to get signing?
> > >
> > > -----Original Message-----
> > > From: Konstantin Boudnik [mailto:cos@apache.org]
> > > Sent: Saturday, August 15, 2015 1:18 PM
> > > To: dev@bigtop.apache.org
> > > Subject: Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)
> > >
> > > Evans,
> > >
> > > do you know how to get the bits off these slaves other than just
> > wgetting them off? E.g. is there a location on s3 where they are or
> > something?
> > >
> > > Thanks,
> > >   Cos
> > >
> > > On Wed, Aug 12, 2015 at 10:26PM, Konstantin Boudnik wrote:
> > > > This is just great, Evans!! Last thing: I need to sign them and put to
> > > > our standard S3 location next to the previous releases.
> > > >
> > > > Will try to have it done tomorrow. So close.... ;)
> > > >   Cos
> > > >
> > > > On Thu, Aug 13, 2015 at 11:48AM, Evans Ye wrote:
> > > > > Done.
> > > > >
> > > > > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb
> > > > > /
> > > > > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm
> > > > > /
> > > > >
> > > > > Now we have up-to-date binaries for release 1.0.
> > > > > I've tested bigtop provisioners with those new builds and it's all
> > good.
> > > > >
> > > > >
> > > > > 2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > >
> > > > > > Thanks man!
> > > > > >
> > > > > > On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > > > > > > Sure. Will get back to you when repos are ready.
> > > > > > >
> > > > > > > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > > > >
> > > > > > > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's.
> > > > > > > > Here's
> > > > > > the
> > > > > > > > tally
> > > > > > > >
> > > > > > > > Evans Ye            +1
> > > > > > > > Sean Mackrory       +1
> > > > > > > > Roman Shaposhnik    +1
> > > > > > > > Youngwoo Kim        +1 (non-binding)
> > > > > > > > Olaf Flebbe         +1
> > > > > > > > jay vyas            +1
> > > > > > > > Andrew Purtell      +1
> > > > > > > > Konstantin Boudnik  +1
> > > > > > > >
> > > > > > > > Thanks everything for making this release happen and for
> > > > > > > > voting. I will roll out the artifacts. Evans, could you please
> > > > > > > > trigger the packages build
> > > > > > from
> > > > > > > > the
> > > > > > > > branch-1.0 ? Thank you very much!
> > > > > > > >
> > > > > > > > Cos
> > > > > > > >
> > > > > > > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > > > > >
> > > > > > > > > It fixes the following issues:
> > > > > > > > >
> > > > > > > >
> > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=123
> > > > > > 26837&styleName=Text&projectId=12311420
> > > > > > > > >
> > > > > > > > > This is the respin of RC3, addressing the fix for default
> > > > > > > > > repo uRLs
> > > > > > and
> > > > > > > > adding
> > > > > > > > > proper header licenses to be able to run full RAT check on
> > > > > > > > > the
> > > > > > release.
> > > > > > > > > The rest of the release is the same.
> > > > > > > > >
> > > > > > > > > The vote will be going for at least 48 hours and will be
> > > > > > > > > closed on Tuesday August 11th, 2015 at noon PDT. Please
> > > > > > > > > download, test and vote
> > > > > > > > with
> > > > > > > > >
> > > > > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache
> > > > > > > > > Bigtop [ ] +0, I don't care either way, [ ] -1, do not
> > > > > > > > > accept RC4 as the official 1.0.0 release of Apache
> > > > > > > > Bigtop, because...
> > > > > > > > >
> > > > > > > > > Source and binary files:
> > > > > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > > > > >
> > > > > > > > > Maven staging repo:
> > > > > > > > >
> > > > > > > >
> > > > > > https://repository.apache.org/content/repositories/orgapachebigtop
> > > > > > -1004
> > > > > > > > >
> > > > > > > > > The git tag to be voted upon is release-1.0.0
> > > > > > > > >
> > > > > > > > > Bigtop's KEYS file containing PGP keys we use to sign the
> > release:
> > > > > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > >
> >

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Evans Ye <ev...@apache.org>.
Yes, AFAIK wget is the best way to do it.
I always wget the archive.zip and unzip it into bigtop/output folder, then
I can use local repo to run bigtop provisioner.

Regarding to suse, we don't have binaries for it now.
There's a wired error when building packages on suse docker container:

*16:18:31*  Copy /ws/dl/apache-tez-0.6.0-src.tar.gz to
/ws/build/tez/tar/apache-tez-0.6.0-src.tar.gz*16:18:31*
:tez-srpmerror: line 34: Unclosed %if


The full log:

http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0/BUILD_ENVIRONMENTS=opensuse-13.2,label=docker-slave-06/14/console


I assume its an environment difference causing the issue happened,
maybe suse expert can help.

At this point I thing we can just state that we don't have binary
convenience files for suse.


Evans


2015-08-16 4:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> Good point! Will do.
>
> We don't have a way to build Suse bits right now, right?
>
> Cos
>
> On Sat, Aug 15, 2015 at 01:30PM, nate@reactor8.com wrote:
> > Think just wget zip of the full assets for each rpm and deb, unless
> Evans already copied somewhere.
> >
> > You pulling down to apache infra to get signing?
> >
> > -----Original Message-----
> > From: Konstantin Boudnik [mailto:cos@apache.org]
> > Sent: Saturday, August 15, 2015 1:18 PM
> > To: dev@bigtop.apache.org
> > Subject: Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)
> >
> > Evans,
> >
> > do you know how to get the bits off these slaves other than just
> wgetting them off? E.g. is there a location on s3 where they are or
> something?
> >
> > Thanks,
> >   Cos
> >
> > On Wed, Aug 12, 2015 at 10:26PM, Konstantin Boudnik wrote:
> > > This is just great, Evans!! Last thing: I need to sign them and put to
> > > our standard S3 location next to the previous releases.
> > >
> > > Will try to have it done tomorrow. So close.... ;)
> > >   Cos
> > >
> > > On Thu, Aug 13, 2015 at 11:48AM, Evans Ye wrote:
> > > > Done.
> > > >
> > > > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb
> > > > /
> > > > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm
> > > > /
> > > >
> > > > Now we have up-to-date binaries for release 1.0.
> > > > I've tested bigtop provisioners with those new builds and it's all
> good.
> > > >
> > > >
> > > > 2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > Thanks man!
> > > > >
> > > > > On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > > > > > Sure. Will get back to you when repos are ready.
> > > > > >
> > > > > > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > > >
> > > > > > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's.
> > > > > > > Here's
> > > > > the
> > > > > > > tally
> > > > > > >
> > > > > > > Evans Ye            +1
> > > > > > > Sean Mackrory       +1
> > > > > > > Roman Shaposhnik    +1
> > > > > > > Youngwoo Kim        +1 (non-binding)
> > > > > > > Olaf Flebbe         +1
> > > > > > > jay vyas            +1
> > > > > > > Andrew Purtell      +1
> > > > > > > Konstantin Boudnik  +1
> > > > > > >
> > > > > > > Thanks everything for making this release happen and for
> > > > > > > voting. I will roll out the artifacts. Evans, could you please
> > > > > > > trigger the packages build
> > > > > from
> > > > > > > the
> > > > > > > branch-1.0 ? Thank you very much!
> > > > > > >
> > > > > > > Cos
> > > > > > >
> > > > > > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > > > >
> > > > > > > > It fixes the following issues:
> > > > > > > >
> > > > > > >
> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=123
> > > > > 26837&styleName=Text&projectId=12311420
> > > > > > > >
> > > > > > > > This is the respin of RC3, addressing the fix for default
> > > > > > > > repo uRLs
> > > > > and
> > > > > > > adding
> > > > > > > > proper header licenses to be able to run full RAT check on
> > > > > > > > the
> > > > > release.
> > > > > > > > The rest of the release is the same.
> > > > > > > >
> > > > > > > > The vote will be going for at least 48 hours and will be
> > > > > > > > closed on Tuesday August 11th, 2015 at noon PDT. Please
> > > > > > > > download, test and vote
> > > > > > > with
> > > > > > > >
> > > > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache
> > > > > > > > Bigtop [ ] +0, I don't care either way, [ ] -1, do not
> > > > > > > > accept RC4 as the official 1.0.0 release of Apache
> > > > > > > Bigtop, because...
> > > > > > > >
> > > > > > > > Source and binary files:
> > > > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > > > >
> > > > > > > > Maven staging repo:
> > > > > > > >
> > > > > > >
> > > > > https://repository.apache.org/content/repositories/orgapachebigtop
> > > > > -1004
> > > > > > > >
> > > > > > > > The git tag to be voted upon is release-1.0.0
> > > > > > > >
> > > > > > > > Bigtop's KEYS file containing PGP keys we use to sign the
> release:
> > > > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> >
>

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Good point! Will do.

We don't have a way to build Suse bits right now, right?

Cos

On Sat, Aug 15, 2015 at 01:30PM, nate@reactor8.com wrote:
> Think just wget zip of the full assets for each rpm and deb, unless Evans already copied somewhere.
> 
> You pulling down to apache infra to get signing?
> 
> -----Original Message-----
> From: Konstantin Boudnik [mailto:cos@apache.org] 
> Sent: Saturday, August 15, 2015 1:18 PM
> To: dev@bigtop.apache.org
> Subject: Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)
> 
> Evans,
> 
> do you know how to get the bits off these slaves other than just wgetting them off? E.g. is there a location on s3 where they are or something?
> 
> Thanks,
>   Cos
> 
> On Wed, Aug 12, 2015 at 10:26PM, Konstantin Boudnik wrote:
> > This is just great, Evans!! Last thing: I need to sign them and put to 
> > our standard S3 location next to the previous releases.
> > 
> > Will try to have it done tomorrow. So close.... ;)
> >   Cos
> > 
> > On Thu, Aug 13, 2015 at 11:48AM, Evans Ye wrote:
> > > Done.
> > > 
> > > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb
> > > / 
> > > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm
> > > /
> > > 
> > > Now we have up-to-date binaries for release 1.0.
> > > I've tested bigtop provisioners with those new builds and it's all good.
> > > 
> > > 
> > > 2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > 
> > > > Thanks man!
> > > >
> > > > On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > > > > Sure. Will get back to you when repos are ready.
> > > > >
> > > > > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > >
> > > > > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. 
> > > > > > Here's
> > > > the
> > > > > > tally
> > > > > >
> > > > > > Evans Ye            +1
> > > > > > Sean Mackrory       +1
> > > > > > Roman Shaposhnik    +1
> > > > > > Youngwoo Kim        +1 (non-binding)
> > > > > > Olaf Flebbe         +1
> > > > > > jay vyas            +1
> > > > > > Andrew Purtell      +1
> > > > > > Konstantin Boudnik  +1
> > > > > >
> > > > > > Thanks everything for making this release happen and for 
> > > > > > voting. I will roll out the artifacts. Evans, could you please 
> > > > > > trigger the packages build
> > > > from
> > > > > > the
> > > > > > branch-1.0 ? Thank you very much!
> > > > > >
> > > > > > Cos
> > > > > >
> > > > > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > > >
> > > > > > > It fixes the following issues:
> > > > > > >
> > > > > >
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=123
> > > > 26837&styleName=Text&projectId=12311420
> > > > > > >
> > > > > > > This is the respin of RC3, addressing the fix for default 
> > > > > > > repo uRLs
> > > > and
> > > > > > adding
> > > > > > > proper header licenses to be able to run full RAT check on 
> > > > > > > the
> > > > release.
> > > > > > > The rest of the release is the same.
> > > > > > >
> > > > > > > The vote will be going for at least 48 hours and will be 
> > > > > > > closed on Tuesday August 11th, 2015 at noon PDT. Please 
> > > > > > > download, test and vote
> > > > > > with
> > > > > > >
> > > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache 
> > > > > > > Bigtop [ ] +0, I don't care either way, [ ] -1, do not 
> > > > > > > accept RC4 as the official 1.0.0 release of Apache
> > > > > > Bigtop, because...
> > > > > > >
> > > > > > > Source and binary files:
> > > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > > >
> > > > > > > Maven staging repo:
> > > > > > >
> > > > > >
> > > > https://repository.apache.org/content/repositories/orgapachebigtop
> > > > -1004
> > > > > > >
> > > > > > > The git tag to be voted upon is release-1.0.0
> > > > > > >
> > > > > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
>

RE: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by na...@reactor8.com.
Think just wget zip of the full assets for each rpm and deb, unless Evans already copied somewhere.

You pulling down to apache infra to get signing?

-----Original Message-----
From: Konstantin Boudnik [mailto:cos@apache.org] 
Sent: Saturday, August 15, 2015 1:18 PM
To: dev@bigtop.apache.org
Subject: Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Evans,

do you know how to get the bits off these slaves other than just wgetting them off? E.g. is there a location on s3 where they are or something?

Thanks,
  Cos

On Wed, Aug 12, 2015 at 10:26PM, Konstantin Boudnik wrote:
> This is just great, Evans!! Last thing: I need to sign them and put to 
> our standard S3 location next to the previous releases.
> 
> Will try to have it done tomorrow. So close.... ;)
>   Cos
> 
> On Thu, Aug 13, 2015 at 11:48AM, Evans Ye wrote:
> > Done.
> > 
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb
> > / 
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm
> > /
> > 
> > Now we have up-to-date binaries for release 1.0.
> > I've tested bigtop provisioners with those new builds and it's all good.
> > 
> > 
> > 2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > 
> > > Thanks man!
> > >
> > > On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > > > Sure. Will get back to you when repos are ready.
> > > >
> > > > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. 
> > > > > Here's
> > > the
> > > > > tally
> > > > >
> > > > > Evans Ye            +1
> > > > > Sean Mackrory       +1
> > > > > Roman Shaposhnik    +1
> > > > > Youngwoo Kim        +1 (non-binding)
> > > > > Olaf Flebbe         +1
> > > > > jay vyas            +1
> > > > > Andrew Purtell      +1
> > > > > Konstantin Boudnik  +1
> > > > >
> > > > > Thanks everything for making this release happen and for 
> > > > > voting. I will roll out the artifacts. Evans, could you please 
> > > > > trigger the packages build
> > > from
> > > > > the
> > > > > branch-1.0 ? Thank you very much!
> > > > >
> > > > > Cos
> > > > >
> > > > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > >
> > > > > > It fixes the following issues:
> > > > > >
> > > > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=123
> > > 26837&styleName=Text&projectId=12311420
> > > > > >
> > > > > > This is the respin of RC3, addressing the fix for default 
> > > > > > repo uRLs
> > > and
> > > > > adding
> > > > > > proper header licenses to be able to run full RAT check on 
> > > > > > the
> > > release.
> > > > > > The rest of the release is the same.
> > > > > >
> > > > > > The vote will be going for at least 48 hours and will be 
> > > > > > closed on Tuesday August 11th, 2015 at noon PDT. Please 
> > > > > > download, test and vote
> > > > > with
> > > > > >
> > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache 
> > > > > > Bigtop [ ] +0, I don't care either way, [ ] -1, do not 
> > > > > > accept RC4 as the official 1.0.0 release of Apache
> > > > > Bigtop, because...
> > > > > >
> > > > > > Source and binary files:
> > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > >
> > > > > > Maven staging repo:
> > > > > >
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachebigtop
> > > -1004
> > > > > >
> > > > > > The git tag to be voted upon is release-1.0.0
> > > > > >
> > > > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > >
> > > > >
> > > > >
> > > > >
> > >

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Evans,

do you know how to get the bits off these slaves other than just wgetting them
off? E.g. is there a location on s3 where they are or something?

Thanks,
  Cos

On Wed, Aug 12, 2015 at 10:26PM, Konstantin Boudnik wrote:
> This is just great, Evans!! Last thing: I need to sign them and put to our
> standard S3 location next to the previous releases.
> 
> Will try to have it done tomorrow. So close.... ;)
>   Cos
> 
> On Thu, Aug 13, 2015 at 11:48AM, Evans Ye wrote:
> > Done.
> > 
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/
> > http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm/
> > 
> > Now we have up-to-date binaries for release 1.0.
> > I've tested bigtop provisioners with those new builds and it's all good.
> > 
> > 
> > 2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > 
> > > Thanks man!
> > >
> > > On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > > > Sure. Will get back to you when repos are ready.
> > > >
> > > > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. Here's
> > > the
> > > > > tally
> > > > >
> > > > > Evans Ye            +1
> > > > > Sean Mackrory       +1
> > > > > Roman Shaposhnik    +1
> > > > > Youngwoo Kim        +1 (non-binding)
> > > > > Olaf Flebbe         +1
> > > > > jay vyas            +1
> > > > > Andrew Purtell      +1
> > > > > Konstantin Boudnik  +1
> > > > >
> > > > > Thanks everything for making this release happen and for voting. I will
> > > > > roll
> > > > > out the artifacts. Evans, could you please trigger the packages build
> > > from
> > > > > the
> > > > > branch-1.0 ? Thank you very much!
> > > > >
> > > > > Cos
> > > > >
> > > > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > >
> > > > > > It fixes the following issues:
> > > > > >
> > > > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > > > >
> > > > > > This is the respin of RC3, addressing the fix for default repo uRLs
> > > and
> > > > > adding
> > > > > > proper header licenses to be able to run full RAT check on the
> > > release.
> > > > > > The rest of the release is the same.
> > > > > >
> > > > > > The vote will be going for at least 48 hours and will be closed on
> > > > > > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> > > > > with
> > > > > >
> > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > > > > [ ] +0, I don't care either way,
> > > > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> > > > > Bigtop, because...
> > > > > >
> > > > > > Source and binary files:
> > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > >
> > > > > > Maven staging repo:
> > > > > >
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > > > >
> > > > > > The git tag to be voted upon is release-1.0.0
> > > > > >
> > > > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > >
> > > > >
> > > > >
> > > > >
> > >

Re: Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
This is just great, Evans!! Last thing: I need to sign them and put to our
standard S3 location next to the previous releases.

Will try to have it done tomorrow. So close.... ;)
  Cos

On Thu, Aug 13, 2015 at 11:48AM, Evans Ye wrote:
> Done.
> 
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/
> http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm/
> 
> Now we have up-to-date binaries for release 1.0.
> I've tested bigtop provisioners with those new builds and it's all good.
> 
> 
> 2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> 
> > Thanks man!
> >
> > On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > > Sure. Will get back to you when repos are ready.
> > >
> > > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. Here's
> > the
> > > > tally
> > > >
> > > > Evans Ye            +1
> > > > Sean Mackrory       +1
> > > > Roman Shaposhnik    +1
> > > > Youngwoo Kim        +1 (non-binding)
> > > > Olaf Flebbe         +1
> > > > jay vyas            +1
> > > > Andrew Purtell      +1
> > > > Konstantin Boudnik  +1
> > > >
> > > > Thanks everything for making this release happen and for voting. I will
> > > > roll
> > > > out the artifacts. Evans, could you please trigger the packages build
> > from
> > > > the
> > > > branch-1.0 ? Thank you very much!
> > > >
> > > > Cos
> > > >
> > > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > >
> > > > > It fixes the following issues:
> > > > >
> > > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > > >
> > > > > This is the respin of RC3, addressing the fix for default repo uRLs
> > and
> > > > adding
> > > > > proper header licenses to be able to run full RAT check on the
> > release.
> > > > > The rest of the release is the same.
> > > > >
> > > > > The vote will be going for at least 48 hours and will be closed on
> > > > > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> > > > with
> > > > >
> > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > > > [ ] +0, I don't care either way,
> > > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> > > > Bigtop, because...
> > > > >
> > > > > Source and binary files:
> > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > >
> > > > > Maven staging repo:
> > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > > >
> > > > > The git tag to be voted upon is release-1.0.0
> > > > >
> > > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > >
> > > >
> > > >
> > > >
> >

Fwd: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Evans Ye <ev...@apache.org>.
Done.

http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-deb/
http://bigtop01.cloudera.org:8080/view/Releases/job/Bigtop-1.0.0-rpm/

Now we have up-to-date binaries for release 1.0.
I've tested bigtop provisioners with those new builds and it's all good.


2015-08-13 3:05 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> Thanks man!
>
> On Thu, Aug 13, 2015 at 01:39AM, Evans Ye wrote:
> > Sure. Will get back to you when repos are ready.
> >
> > 2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. Here's
> the
> > > tally
> > >
> > > Evans Ye            +1
> > > Sean Mackrory       +1
> > > Roman Shaposhnik    +1
> > > Youngwoo Kim        +1 (non-binding)
> > > Olaf Flebbe         +1
> > > jay vyas            +1
> > > Andrew Purtell      +1
> > > Konstantin Boudnik  +1
> > >
> > > Thanks everything for making this release happen and for voting. I will
> > > roll
> > > out the artifacts. Evans, could you please trigger the packages build
> from
> > > the
> > > branch-1.0 ? Thank you very much!
> > >
> > > Cos
> > >
> > > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > >
> > > > It fixes the following issues:
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > >
> > > > This is the respin of RC3, addressing the fix for default repo uRLs
> and
> > > adding
> > > > proper header licenses to be able to run full RAT check on the
> release.
> > > > The rest of the release is the same.
> > > >
> > > > The vote will be going for at least 48 hours and will be closed on
> > > > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> > > with
> > > >
> > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > > [ ] +0, I don't care either way,
> > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> > > Bigtop, because...
> > > >
> > > > Source and binary files:
> > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > >
> > > > Maven staging repo:
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > >
> > > > The git tag to be voted upon is release-1.0.0
> > > >
> > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > >
> > >
> > >
> > >
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Evans Ye <ev...@apache.org>.
Sure. Will get back to you when repos are ready.

2015-08-12 4:08 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. Here's the
> tally
>
> Evans Ye            +1
> Sean Mackrory       +1
> Roman Shaposhnik    +1
> Youngwoo Kim        +1 (non-binding)
> Olaf Flebbe         +1
> jay vyas            +1
> Andrew Purtell      +1
> Konstantin Boudnik  +1
>
> Thanks everything for making this release happen and for voting. I will
> roll
> out the artifacts. Evans, could you please trigger the packages build from
> the
> branch-1.0 ? Thank you very much!
>
> Cos
>
> On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> > This is the vote for release 1.0.0 of Apache Bigtop.
> >
> > It fixes the following issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> >
> > This is the respin of RC3, addressing the fix for default repo uRLs and
> adding
> > proper header licenses to be able to run full RAT check on the release.
> > The rest of the release is the same.
> >
> > The vote will be going for at least 48 hours and will be closed on
> > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> with
> >
> > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > [ ] +0, I don't care either way,
> > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> Bigtop, because...
> >
> > Source and binary files:
> >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> >
> > Maven staging repo:
> >
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> >
> > The git tag to be voted upon is release-1.0.0
> >
> > Bigtop's KEYS file containing PGP keys we use to sign the release:
> >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> >
>
>
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. Here's the tally

Evans Ye            +1
Sean Mackrory       +1
Roman Shaposhnik    +1
Youngwoo Kim        +1 (non-binding)
Olaf Flebbe         +1  
jay vyas            +1
Andrew Purtell      +1
Konstantin Boudnik  +1

Thanks everything for making this release happen and for voting. I will roll
out the artifacts. Evans, could you please trigger the packages build from the
branch-1.0 ? Thank you very much!

Cos

On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> This is the vote for release 1.0.0 of Apache Bigtop.
> 
> It fixes the following issues:
>         https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> 
> This is the respin of RC3, addressing the fix for default repo uRLs and adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
> 
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> 
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
> 
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> 
> Maven staging repo:
>         https://repository.apache.org/content/repositories/orgapachebigtop-1004
> 
> The git tag to be voted upon is release-1.0.0
> 
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>

[RESULT]: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
The vote has passed with 8 +1 (7 binding); and 0 -1's or 0's. Here's the tally

Evans Ye            +1
Sean Mackrory       +1
Roman Shaposhnik    +1
Youngwoo Kim        +1 (non-binding)
Olaf Flebbe         +1  
jay vyas            +1
Andrew Purtell      +1
Konstantin Boudnik  +1

Thanks everything for making this release happen and for voting. I will roll
out the artifacts. Evans, could you please trigger the packages build from the
branch-1.0 ? Thank you very much!

Cos

On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> This is the vote for release 1.0.0 of Apache Bigtop.
> 
> It fixes the following issues:
>         https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> 
> This is the respin of RC3, addressing the fix for default repo uRLs and adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
> 
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> 
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
> 
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> 
> Maven staging repo:
>         https://repository.apache.org/content/repositories/orgapachebigtop-1004
> 
> The git tag to be voted upon is release-1.0.0
> 
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>

Keys ? Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,


What are we using the KEYS file for ? What is the status of 	BIGTOP-1762 ?

I would like to advance bigtop and have the CI create a signed repository of bigtop (that's one of the reasons behind BIGTOP-1917)
There seems to be some signing process for yum repos: Who has "owns" this key? can we reuse it for Debian Repos as well?

Olaf



> Am 10.08.2015 um 01:59 schrieb Konstantin Boudnik <co...@apache.org>:
> 
> A small update:
>    The URL to the KEYS at the botton has the old version of the KEYS file
> 
> Please use
>    https://dist.apache.org/repos/dist/release/bigtop/KEYS
> instead, while I am working with INFRA on updating the dist one.
> 
> Thank you
>  Cos
> 
> On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
>> This is the vote for release 1.0.0 of Apache Bigtop.
>> 
>> It fixes the following issues:
>>        https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>> 
>> This is the respin of RC3, addressing the fix for default repo uRLs and adding
>> proper header licenses to be able to run full RAT check on the release.
>> The rest of the release is the same.
>> 
>> The vote will be going for at least 48 hours and will be closed on
>> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
>> 
>> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
>> [ ] +0, I don't care either way,
>> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
>> 
>> Source and binary files:
>>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
>> 
>> Maven staging repo:
>>        https://repository.apache.org/content/repositories/orgapachebigtop-1004
>> 
>> The git tag to be voted upon is release-1.0.0
>> 
>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>> 
> 
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Sean Mackrory <ma...@gmail.com>.
+1 (binding)

On Tue, Aug 11, 2015 at 1:43 AM, Olaf Flebbe <of...@oflebbe.de> wrote:

> This is more or less a dup to BIGTOP-1916. But I am unsure if I should
> update this *now* since the URL to 1.0.0 release is not valid .
>
> Olaf
>
>
> > Am 10.08.2015 um 01:59 schrieb Konstantin Boudnik <co...@apache.org>:
> >
> > A small update:
> >    The URL to the KEYS at the botton has the old version of the KEYS file
> >
> > Please use
> >    https://dist.apache.org/repos/dist/release/bigtop/KEYS
> > instead, while I am working with INFRA on updating the dist one.
> >
> > Thank you
> >  Cos
> >
> > On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> >> This is the vote for release 1.0.0 of Apache Bigtop.
> >>
> >> It fixes the following issues:
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> >>
> >> This is the respin of RC3, addressing the fix for default repo uRLs and
> adding
> >> proper header licenses to be able to run full RAT check on the release.
> >> The rest of the release is the same.
> >>
> >> The vote will be going for at least 48 hours and will be closed on
> >> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> with
> >>
> >> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> >> [ ] +0, I don't care either way,
> >> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> Bigtop, because...
> >>
> >> Source and binary files:
> >>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
> >>
> >> Maven staging repo:
> >>
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> >>
> >> The git tag to be voted upon is release-1.0.0
> >>
> >> Bigtop's KEYS file containing PGP keys we use to sign the release:
> >>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> >>
> >
> >
>
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
This is more or less a dup to BIGTOP-1916. But I am unsure if I should update this *now* since the URL to 1.0.0 release is not valid .

Olaf


> Am 10.08.2015 um 01:59 schrieb Konstantin Boudnik <co...@apache.org>:
> 
> A small update:
>    The URL to the KEYS at the botton has the old version of the KEYS file
> 
> Please use
>    https://dist.apache.org/repos/dist/release/bigtop/KEYS
> instead, while I am working with INFRA on updating the dist one.
> 
> Thank you
>  Cos
> 
> On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
>> This is the vote for release 1.0.0 of Apache Bigtop.
>> 
>> It fixes the following issues:
>>        https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>> 
>> This is the respin of RC3, addressing the fix for default repo uRLs and adding
>> proper header licenses to be able to run full RAT check on the release.
>> The rest of the release is the same.
>> 
>> The vote will be going for at least 48 hours and will be closed on
>> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
>> 
>> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
>> [ ] +0, I don't care either way,
>> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
>> 
>> Source and binary files:
>>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
>> 
>> Maven staging repo:
>>        https://repository.apache.org/content/repositories/orgapachebigtop-1004
>> 
>> The git tag to be voted upon is release-1.0.0
>> 
>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>> 
> 
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
A small update:
    The URL to the KEYS at the botton has the old version of the KEYS file

Please use 
    https://dist.apache.org/repos/dist/release/bigtop/KEYS
instead, while I am working with INFRA on updating the dist one.

Thank you 
  Cos

On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> This is the vote for release 1.0.0 of Apache Bigtop.
> 
> It fixes the following issues:
>         https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> 
> This is the respin of RC3, addressing the fix for default repo uRLs and adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
> 
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> 
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
> 
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> 
> Maven staging repo:
>         https://repository.apache.org/content/repositories/orgapachebigtop-1004
> 
> The git tag to be voted upon is release-1.0.0
> 
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> This is the vote for release 1.0.0 of Apache Bigtop.
>
> It fixes the following issues:
>         https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>
> This is the respin of RC3, addressing the fix for default repo uRLs and adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
>
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
>
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...

+1 (binding)

- checked hashes
- compared tag to the tarballs and Maven deployed tarball
- checked versions
- built packages

Thanks,
Roman.

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Just ran
    % gradlew crunch-deb

on my Ubuntu 12.04 system and it went to the completion without a smallest
issue. So, I am with Evans here - could it be an environment issue,
potentially?

Cos

On Sun, Aug 09, 2015 at 10:25AM, Olaf Flebbe wrote:
> Sigh,... I had only this night the chance to recompile everything and I am hitting this problem within crunch
> 
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on project crunch-parent: Execution default-cli of goal org.apache.maven.plugins:maven-site-plugin:3.1:site failed: A required class was missing while executing org.apache.maven.plugins:maven-site-plugin:3.1:site: org/sonatype/aether/graph/DependencyFilter
> 
> Well known:
> https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound
> 
> (Fix is to increase maven-site-plugin from 3.1 to 3.3)
> 
> There may be another problem in crunch with our debian/* files and the rat plugin ..
> 
> Unfortunatly there is no maintainer listed for crunch ...
> 
> I do not know or use crunch, I am undecided wether this is a blocker or not.
> 
> Perhaps we can remove crunch from bigtop.mk for 1.0 and fixing this is master.
> 
> Right now: +0
> 
> Olaf
> 
> 
> > Am 08.08.2015 um 02:51 schrieb Konstantin Boudnik <co...@apache.org>:
> > 
> > This is the vote for release 1.0.0 of Apache Bigtop.
> > 
> > It fixes the following issues:
> >        https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > 
> > This is the respin of RC3, addressing the fix for default repo uRLs and adding
> > proper header licenses to be able to run full RAT check on the release.
> > The rest of the release is the same.
> > 
> > The vote will be going for at least 48 hours and will be closed on
> > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> > 
> > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > [ ] +0, I don't care either way,
> > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
> > 
> > Source and binary files:
> >        http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > 
> > Maven staging repo:
> >        https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > 
> > The git tag to be voted upon is release-1.0.0
> > 
> > Bigtop's KEYS file containing PGP keys we use to sign the release:
> >        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > 
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
Evans,

Thanks for pointing out that I mixed up the git-master toolchain with branch-1.0.0 compile. Retrying ...

Olaf



> Am 09.08.2015 um 11:24 schrieb Evans Ye <ev...@apache.org>:
> 
> Hi Olaf, did you tried on our dcoker slave images?
> Since the trunk daily builds for crunch is OK:
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Docker-Bigtop-trunk-Crunch/
> 
> As far as I know the crunch build in master is equivalent to the 1.0
> branch. And our docker slaves are directly built by applying bigtop
> toolchain, hence they got maven 3.0.5 installed.
> I don't have any clue yet, but maybe it's a network issue?
> 
> 
> 2015-08-09 16:25 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> 
>> Sigh,... I had only this night the chance to recompile everything and I am
>> hitting this problem within crunch
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on
>> project crunch-parent: Execution default-cli of goal
>> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: A required
>> class was missing while executing
>> org.apache.maven.plugins:maven-site-plugin:3.1:site:
>> org/sonatype/aether/graph/DependencyFilter
>> 
>> Well known:
>> https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound
>> 
>> (Fix is to increase maven-site-plugin from 3.1 to 3.3)
>> 
>> There may be another problem in crunch with our debian/* files and the rat
>> plugin ..
>> 
>> Unfortunatly there is no maintainer listed for crunch ...
>> 
>> I do not know or use crunch, I am undecided wether this is a blocker or
>> not.
>> 
>> Perhaps we can remove crunch from bigtop.mk for 1.0 and fixing this is
>> master.
>> 
>> Right now: +0
>> 
>> Olaf
>> 
>> 
>>> Am 08.08.2015 um 02:51 schrieb Konstantin Boudnik <co...@apache.org>:
>>> 
>>> This is the vote for release 1.0.0 of Apache Bigtop.
>>> 
>>> It fixes the following issues:
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>>> 
>>> This is the respin of RC3, addressing the fix for default repo uRLs and
>> adding
>>> proper header licenses to be able to run full RAT check on the release.
>>> The rest of the release is the same.
>>> 
>>> The vote will be going for at least 48 hours and will be closed on
>>> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
>> with
>>> 
>>> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
>>> [ ] +0, I don't care either way,
>>> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
>> Bigtop, because...
>>> 
>>> Source and binary files:
>>>       http://people.apache.org/~cos/bigtop-1.0.0-RC4
>>> 
>>> Maven staging repo:
>>> 
>> https://repository.apache.org/content/repositories/orgapachebigtop-1004
>>> 
>>> The git tag to be voted upon is release-1.0.0
>>> 
>>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>>       http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>>> 
>> 
>>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Evans Ye <ev...@apache.org>.
Hi Olaf, did you tried on our dcoker slave images?
Since the trunk daily builds for crunch is OK:
http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Docker-Bigtop-trunk-Crunch/

As far as I know the crunch build in master is equivalent to the 1.0
branch. And our docker slaves are directly built by applying bigtop
toolchain, hence they got maven 3.0.5 installed.
I don't have any clue yet, but maybe it's a network issue?


2015-08-09 16:25 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:

> Sigh,... I had only this night the chance to recompile everything and I am
> hitting this problem within crunch
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on
> project crunch-parent: Execution default-cli of goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site failed: A required
> class was missing while executing
> org.apache.maven.plugins:maven-site-plugin:3.1:site:
> org/sonatype/aether/graph/DependencyFilter
>
> Well known:
> https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound
>
> (Fix is to increase maven-site-plugin from 3.1 to 3.3)
>
> There may be another problem in crunch with our debian/* files and the rat
> plugin ..
>
> Unfortunatly there is no maintainer listed for crunch ...
>
> I do not know or use crunch, I am undecided wether this is a blocker or
> not.
>
> Perhaps we can remove crunch from bigtop.mk for 1.0 and fixing this is
> master.
>
> Right now: +0
>
> Olaf
>
>
> > Am 08.08.2015 um 02:51 schrieb Konstantin Boudnik <co...@apache.org>:
> >
> > This is the vote for release 1.0.0 of Apache Bigtop.
> >
> > It fixes the following issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> >
> > This is the respin of RC3, addressing the fix for default repo uRLs and
> adding
> > proper header licenses to be able to run full RAT check on the release.
> > The rest of the release is the same.
> >
> > The vote will be going for at least 48 hours and will be closed on
> > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> with
> >
> > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > [ ] +0, I don't care either way,
> > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> Bigtop, because...
> >
> > Source and binary files:
> >        http://people.apache.org/~cos/bigtop-1.0.0-RC4
> >
> > Maven staging repo:
> >
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> >
> > The git tag to be voted upon is release-1.0.0
> >
> > Bigtop's KEYS file containing PGP keys we use to sign the release:
> >        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> >
>
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
Sigh,... I had only this night the chance to recompile everything and I am hitting this problem within crunch

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on project crunch-parent: Execution default-cli of goal org.apache.maven.plugins:maven-site-plugin:3.1:site failed: A required class was missing while executing org.apache.maven.plugins:maven-site-plugin:3.1:site: org/sonatype/aether/graph/DependencyFilter

Well known:
https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound

(Fix is to increase maven-site-plugin from 3.1 to 3.3)

There may be another problem in crunch with our debian/* files and the rat plugin ..

Unfortunatly there is no maintainer listed for crunch ...

I do not know or use crunch, I am undecided wether this is a blocker or not.

Perhaps we can remove crunch from bigtop.mk for 1.0 and fixing this is master.

Right now: +0

Olaf


> Am 08.08.2015 um 02:51 schrieb Konstantin Boudnik <co...@apache.org>:
> 
> This is the vote for release 1.0.0 of Apache Bigtop.
> 
> It fixes the following issues:
>        https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> 
> This is the respin of RC3, addressing the fix for default repo uRLs and adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
> 
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> 
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
> 
> Source and binary files:
>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
> 
> Maven staging repo:
>        https://repository.apache.org/content/repositories/orgapachebigtop-1004
> 
> The git tag to be voted upon is release-1.0.0
> 
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
Yep, mvn installed by the gradlew toolchain is 3.0.5 in branch-1.0 which does not show this bug.

I accidantely used gradlew toolchain from master branch which shows the crunch problem in branch 1.0, but this is not an supported situation.

Olaf

> Am 10.08.2015 um 23:52 schrieb Andrew Purtell <ap...@apache.org>:
> 
> Ok, then never mind that, I reported what 'mvn' from the command line
> shows.
> 
> I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as far
> as crunch and it failed:
> 
> :crunch-deb FAILED
> 
> FAILURE: Build failed with an exception.
> 
> * Where:
> Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
> 
> * What went wrong:
> Execution failed for task ':crunch-deb'.
>> Process 'command 'debuild'' finished with non-zero exit value 29
> 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
> 
> BUILD FAILED
> 
> 
> 
> On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
>> Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
>> 
>> I believe the issue that Olaf hit the other day has been introduced in
>> 3.1-alpha or something like that.
>> 
>> Cos
>> 
>> On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
>>> I hit the crunch build problem too.
>>> 
>>> -0
>>> 
>>> Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
>>> 
>>> [WARNING] Error injecting:
>>> org.apache.maven.reporting.exec.DefaultMavenReportExecutor
>>> java.lang.NoClassDefFoundError:
>> org/sonatype/aether/graph/DependencyFilter
>>> at java.lang.Class.getDeclaredConstructors0(Native Method)
>>> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
>>> at java.lang.Class.getDeclaredConstructors(Class.java:1906)
>>> at
>>> 
>> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
>>> at
>>> 
>> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
>>> at
>>> 
>> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
>>> at
>>> 
>> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
>>> at
>>> 
>> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
>>> at
>>> 
>> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
>>> at
>>> 
>> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
>>> at
>>> 
>> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
>>> at
>>> 
>> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
>>> at
>>> 
>> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
>>> at
>>> 
>> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
>>> at
>>> 
>> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
>>> at
>>> 
>> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
>>> at
>>> 
>> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
>>> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
>>> at
>>> 
>> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
>>> at
>> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
>>> at
>>> 
>> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
>>> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
>>> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
>>> at
>> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
>>> at
>>> 
>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
>>> at
>>> 
>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
>>> at
>>> 
>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
>>> at
>>> 
>> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
>>> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
>>> at
>>> 
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>> at
>>> 
>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
>>> at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
>>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>> at
>>> 
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>>> at
>>> 
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>>> at
>>> 
>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.sonatype.aether.graph.DependencyFilter
>>> at
>>> 
>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>>> at
>>> 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
>>> at
>>> 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
>>> at
>>> 
>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
>>> ... 60 more
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>> 
>>>> This is the vote for release 1.0.0 of Apache Bigtop.
>>>> 
>>>> It fixes the following issues:
>>>> 
>>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>>>> 
>>>> This is the respin of RC3, addressing the fix for default repo uRLs and
>>>> adding
>>>> proper header licenses to be able to run full RAT check on the release.
>>>> The rest of the release is the same.
>>>> 
>>>> The vote will be going for at least 48 hours and will be closed on
>>>> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
>> with
>>>> 
>>>> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
>>>> [ ] +0, I don't care either way,
>>>> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
>> Bigtop,
>>>> because...
>>>> 
>>>> Source and binary files:
>>>>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
>>>> 
>>>> Maven staging repo:
>>>> 
>>>> 
>> https://repository.apache.org/content/repositories/orgapachebigtop-1004
>>>> 
>>>> The git tag to be voted upon is release-1.0.0
>>>> 
>>>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>>>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Best regards,
>>> 
>>>   - Andy
>>> 
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>> 
> 
> 
> 
> --
> Best regards,
> 
>   - Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Andrew Purtell <ap...@apache.org>.
https://issues.apache.org/jira/browse/BIGTOP-1962

On Mon, Aug 10, 2015 at 3:27 PM, Konstantin Boudnik <co...@apache.org> wrote:

> On Mon, Aug 10, 2015 at 03:14PM, Andrew Purtell wrote:
> > Ok, then I am +1
> >
> > Do we have a release note about that somewhere? Should be pretty common
> for
> > would-be users to be running a version of Maven more recent than 3.0.
> >
> > The docker image is a solution for some, but not everyone wants a fat
> > container toolchain on a build host.
>
> Definitely +1 on documenting this in ReleaseNotes on the Wiki or better yet
> on bigtop.apache.org
>
> Clearly, we can not support all possible combinations of the tools in the
> build. Hence, the certain content of the toolchain, but the requirement
> should
> be clear and easy to find.
>
> > Other things I already checked:
> >
> > - Sums and signatures
> > - Installed some packages and spot checked the installation
> >
> >
> > On Mon, Aug 10, 2015 at 3:07 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >
> > > But gradle will use whatever mvn is installed on the system or
> specified
> > > via
> > > MAVEN_HOME env. var. toolchain from 1.0 is setting up 3.0.5, I
> believe, and
> > > that's where I don't see the issue w/ Crunch while building on 12.04
> > > Ubuntu.
> > >
> > > Do you see the same issue while running on our official docker image?
> > > Thanks!
> > >   Cos
> > >
> > > On Mon, Aug 10, 2015 at 02:52PM, Andrew Purtell wrote:
> > > > Ok, then never mind that, I reported what 'mvn' from the command line
> > > > shows.
> > > >
> > > > I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got
> as
> > > far
> > > > as crunch and it failed:
> > > >
> > > > :crunch-deb FAILED
> > > >
> > > > FAILURE: Build failed with an exception.
> > > >
> > > > * Where:
> > > > Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
> > > >
> > > > * What went wrong:
> > > > Execution failed for task ':crunch-deb'.
> > > > > Process 'command 'debuild'' finished with non-zero exit value 29
> > > >
> > > > * Try:
> > > > Run with --stacktrace option to get the stack trace. Run with --info
> or
> > > > --debug option to get more log output.
> > > >
> > > > BUILD FAILED
> > > >
> > > >
> > > >
> > > > On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > > >
> > > > > Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
> > > > >
> > > > > I believe the issue that Olaf hit the other day has been
> introduced in
> > > > > 3.1-alpha or something like that.
> > > > >
> > > > > Cos
> > > > >
> > > > > On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> > > > > > I hit the crunch build problem too.
> > > > > >
> > > > > > -0
> > > > > >
> > > > > > Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven
> 3.2.2
> > > > > >
> > > > > > [WARNING] Error injecting:
> > > > > > org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> > > > > > java.lang.NoClassDefFoundError:
> > > > > org/sonatype/aether/graph/DependencyFilter
> > > > > > at java.lang.Class.getDeclaredConstructors0(Native Method)
> > > > > > at
> java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> > > > > > at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> > > > > > at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> > > > > > at
> > > > >
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> > > > > > at
> > > > > >
> > > > >
> > >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> > > > > > at
> > > com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> > > > > > at
> > > org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> > > > > > at
> > > > >
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> > > > > > at
> org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> > > > > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> > > > > > at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> > > > > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> > > > > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> > > > > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > >
> > > > >
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > > > > > at
> > > > > >
> > > > >
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > > at java.lang.reflect.Method.invoke(Method.java:606)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > > > > > at
> > > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > > > > > Caused by: java.lang.ClassNotFoundException:
> > > > > > org.sonatype.aether.graph.DependencyFilter
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> > > > > > at
> > > > > >
> > > > >
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> > > > > > ... 60 more
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <
> cos@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > > >
> > > > > > > It fixes the following issues:
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > > > > >
> > > > > > > This is the respin of RC3, addressing the fix for default repo
> > > uRLs and
> > > > > > > adding
> > > > > > > proper header licenses to be able to run full RAT check on the
> > > release.
> > > > > > > The rest of the release is the same.
> > > > > > >
> > > > > > > The vote will be going for at least 48 hours and will be
> closed on
> > > > > > > Tuesday August 11th, 2015 at noon PDT. Please download, test
> and
> > > vote
> > > > > with
> > > > > > >
> > > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache
> Bigtop
> > > > > > > [ ] +0, I don't care either way,
> > > > > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of
> Apache
> > > > > Bigtop,
> > > > > > > because...
> > > > > > >
> > > > > > > Source and binary files:
> > > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > > >
> > > > > > > Maven staging repo:
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > > > > >
> > > > > > > The git tag to be voted upon is release-1.0.0
> > > > > > >
> > > > > > > Bigtop's KEYS file containing PGP keys we use to sign the
> release:
> > > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >
> > > > > >    - Andy
> > > > > >
> > > > > > Problems worthy of attack prove their worth by hitting back. -
> Piet
> > > Hein
> > > > > > (via Tom White)
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >    - Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > > (via Tom White)
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 03:14PM, Andrew Purtell wrote:
> Ok, then I am +1
> 
> Do we have a release note about that somewhere? Should be pretty common for
> would-be users to be running a version of Maven more recent than 3.0.
> 
> The docker image is a solution for some, but not everyone wants a fat
> container toolchain on a build host.

Definitely +1 on documenting this in ReleaseNotes on the Wiki or better yet
on bigtop.apache.org

Clearly, we can not support all possible combinations of the tools in the
build. Hence, the certain content of the toolchain, but the requirement should
be clear and easy to find.

> Other things I already checked:
> 
> - Sums and signatures
> - Installed some packages and spot checked the installation
> 
> 
> On Mon, Aug 10, 2015 at 3:07 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > But gradle will use whatever mvn is installed on the system or specified
> > via
> > MAVEN_HOME env. var. toolchain from 1.0 is setting up 3.0.5, I believe, and
> > that's where I don't see the issue w/ Crunch while building on 12.04
> > Ubuntu.
> >
> > Do you see the same issue while running on our official docker image?
> > Thanks!
> >   Cos
> >
> > On Mon, Aug 10, 2015 at 02:52PM, Andrew Purtell wrote:
> > > Ok, then never mind that, I reported what 'mvn' from the command line
> > > shows.
> > >
> > > I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as
> > far
> > > as crunch and it failed:
> > >
> > > :crunch-deb FAILED
> > >
> > > FAILURE: Build failed with an exception.
> > >
> > > * Where:
> > > Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
> > >
> > > * What went wrong:
> > > Execution failed for task ':crunch-deb'.
> > > > Process 'command 'debuild'' finished with non-zero exit value 29
> > >
> > > * Try:
> > > Run with --stacktrace option to get the stack trace. Run with --info or
> > > --debug option to get more log output.
> > >
> > > BUILD FAILED
> > >
> > >
> > >
> > > On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > >
> > > > Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
> > > >
> > > > I believe the issue that Olaf hit the other day has been introduced in
> > > > 3.1-alpha or something like that.
> > > >
> > > > Cos
> > > >
> > > > On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> > > > > I hit the crunch build problem too.
> > > > >
> > > > > -0
> > > > >
> > > > > Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
> > > > >
> > > > > [WARNING] Error injecting:
> > > > > org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> > > > > java.lang.NoClassDefFoundError:
> > > > org/sonatype/aether/graph/DependencyFilter
> > > > > at java.lang.Class.getDeclaredConstructors0(Native Method)
> > > > > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> > > > > at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> > > > > at
> > > > >
> > > >
> > com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> > > > > at
> > > > >
> > > >
> > org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> > > > > at
> > > > >
> > > >
> > org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> > > > > at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> > > > > at
> > > > com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> > > > > at
> > > > >
> > > >
> > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> > > > > at
> > com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> > > > > at
> > org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> > > > > at
> > > > org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> > > > > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > > > > at
> > > > >
> > > >
> > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> > > > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> > > > > at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> > > > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> > > > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> > > > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > >
> > > >
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > > > > at
> > > > >
> > > >
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > at java.lang.reflect.Method.invoke(Method.java:606)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > > > > at
> > > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > > > > Caused by: java.lang.ClassNotFoundException:
> > > > > org.sonatype.aether.graph.DependencyFilter
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> > > > > at
> > > > >
> > > >
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> > > > > ... 60 more
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > > > wrote:
> > > > >
> > > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > > >
> > > > > > It fixes the following issues:
> > > > > >
> > > > > >
> > > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > > > >
> > > > > > This is the respin of RC3, addressing the fix for default repo
> > uRLs and
> > > > > > adding
> > > > > > proper header licenses to be able to run full RAT check on the
> > release.
> > > > > > The rest of the release is the same.
> > > > > >
> > > > > > The vote will be going for at least 48 hours and will be closed on
> > > > > > Tuesday August 11th, 2015 at noon PDT. Please download, test and
> > vote
> > > > with
> > > > > >
> > > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > > > > [ ] +0, I don't care either way,
> > > > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> > > > Bigtop,
> > > > > > because...
> > > > > >
> > > > > > Source and binary files:
> > > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > > >
> > > > > > Maven staging repo:
> > > > > >
> > > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > > > >
> > > > > > The git tag to be voted upon is release-1.0.0
> > > > > >
> > > > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >    - Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > > (via Tom White)
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > > (via Tom White)
> >
> 
> 
> 
> -- 
> Best regards,
> 
>    - Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Andrew Purtell <ap...@apache.org>.
Ok, then I am +1

Do we have a release note about that somewhere? Should be pretty common for
would-be users to be running a version of Maven more recent than 3.0.

The docker image is a solution for some, but not everyone wants a fat
container toolchain on a build host.

Other things I already checked:

- Sums and signatures
- Installed some packages and spot checked the installation


On Mon, Aug 10, 2015 at 3:07 PM, Konstantin Boudnik <co...@apache.org> wrote:

> But gradle will use whatever mvn is installed on the system or specified
> via
> MAVEN_HOME env. var. toolchain from 1.0 is setting up 3.0.5, I believe, and
> that's where I don't see the issue w/ Crunch while building on 12.04
> Ubuntu.
>
> Do you see the same issue while running on our official docker image?
> Thanks!
>   Cos
>
> On Mon, Aug 10, 2015 at 02:52PM, Andrew Purtell wrote:
> > Ok, then never mind that, I reported what 'mvn' from the command line
> > shows.
> >
> > I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as
> far
> > as crunch and it failed:
> >
> > :crunch-deb FAILED
> >
> > FAILURE: Build failed with an exception.
> >
> > * Where:
> > Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
> >
> > * What went wrong:
> > Execution failed for task ':crunch-deb'.
> > > Process 'command 'debuild'' finished with non-zero exit value 29
> >
> > * Try:
> > Run with --stacktrace option to get the stack trace. Run with --info or
> > --debug option to get more log output.
> >
> > BUILD FAILED
> >
> >
> >
> > On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >
> > > Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
> > >
> > > I believe the issue that Olaf hit the other day has been introduced in
> > > 3.1-alpha or something like that.
> > >
> > > Cos
> > >
> > > On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> > > > I hit the crunch build problem too.
> > > >
> > > > -0
> > > >
> > > > Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
> > > >
> > > > [WARNING] Error injecting:
> > > > org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> > > > java.lang.NoClassDefFoundError:
> > > org/sonatype/aether/graph/DependencyFilter
> > > > at java.lang.Class.getDeclaredConstructors0(Native Method)
> > > > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> > > > at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> > > > at
> > > >
> > >
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> > > > at
> > > >
> > >
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> > > > at
> > > >
> > >
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> > > > at
> > > >
> > >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> > > > at
> > > >
> > >
> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> > > > at
> > > >
> > >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> > > > at
> > > >
> > >
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> > > > at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> > > > at
> > > >
> > >
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> > > > at
> > > com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> > > > at
> > > >
> > >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> > > > at
> com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> > > > at
> org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> > > > at
> > > org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> > > > at
> > > >
> > >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> > > > at
> > > >
> > >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> > > > at
> > > >
> > >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> > > > at
> > > >
> > >
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> > > > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> > > > at
> > > >
> > >
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > > > at
> > > >
> > >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> > > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> > > > at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> > > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> > > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> > > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > > > at
> > > >
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > at java.lang.reflect.Method.invoke(Method.java:606)
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > > > at
> > >
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > > > Caused by: java.lang.ClassNotFoundException:
> > > > org.sonatype.aether.graph.DependencyFilter
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> > > > at
> > > >
> > >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> > > > ... 60 more
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > > >
> > > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > > >
> > > > > It fixes the following issues:
> > > > >
> > > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > > >
> > > > > This is the respin of RC3, addressing the fix for default repo
> uRLs and
> > > > > adding
> > > > > proper header licenses to be able to run full RAT check on the
> release.
> > > > > The rest of the release is the same.
> > > > >
> > > > > The vote will be going for at least 48 hours and will be closed on
> > > > > Tuesday August 11th, 2015 at noon PDT. Please download, test and
> vote
> > > with
> > > > >
> > > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > > > [ ] +0, I don't care either way,
> > > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> > > Bigtop,
> > > > > because...
> > > > >
> > > > > Source and binary files:
> > > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > > >
> > > > > Maven staging repo:
> > > > >
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > > >
> > > > > The git tag to be voted upon is release-1.0.0
> > > > >
> > > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >    - Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > > (via Tom White)
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Yup, thanks for confiming this!

On Tue, Aug 11, 2015 at 12:10AM, Olaf Flebbe wrote:
> no:
> 
> $ docker run bigtop/slaves:debian-8  bash -c '. /etc/profile.d/bigtop.sh; mvn --version'
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+0000)
> Maven home: /usr/local/maven
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "3.16.0-4-amd64", arch: "amd64", family: "unix"
> 
> 
> > Am 11.08.2015 um 00:07 schrieb Konstantin Boudnik <co...@apache.org>:
> > 
> > But gradle will use whatever mvn is installed on the system or specified via
> > MAVEN_HOME env. var. toolchain from 1.0 is setting up 3.0.5, I believe, and
> > that's where I don't see the issue w/ Crunch while building on 12.04 Ubuntu.
> > 
> > Do you see the same issue while running on our official docker image? Thanks!
> >  Cos
> > 
> > On Mon, Aug 10, 2015 at 02:52PM, Andrew Purtell wrote:
> >> Ok, then never mind that, I reported what 'mvn' from the command line
> >> shows.
> >> 
> >> I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as far
> >> as crunch and it failed:
> >> 
> >> :crunch-deb FAILED
> >> 
> >> FAILURE: Build failed with an exception.
> >> 
> >> * Where:
> >> Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
> >> 
> >> * What went wrong:
> >> Execution failed for task ':crunch-deb'.
> >>> Process 'command 'debuild'' finished with non-zero exit value 29
> >> 
> >> * Try:
> >> Run with --stacktrace option to get the stack trace. Run with --info or
> >> --debug option to get more log output.
> >> 
> >> BUILD FAILED
> >> 
> >> 
> >> 
> >> On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >> 
> >>> Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
> >>> 
> >>> I believe the issue that Olaf hit the other day has been introduced in
> >>> 3.1-alpha or something like that.
> >>> 
> >>> Cos
> >>> 
> >>> On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> >>>> I hit the crunch build problem too.
> >>>> 
> >>>> -0
> >>>> 
> >>>> Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
> >>>> 
> >>>> [WARNING] Error injecting:
> >>>> org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> >>>> java.lang.NoClassDefFoundError:
> >>> org/sonatype/aether/graph/DependencyFilter
> >>>> at java.lang.Class.getDeclaredConstructors0(Native Method)
> >>>> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> >>>> at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> >>>> at
> >>>> 
> >>> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> >>>> at
> >>>> 
> >>> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> >>>> at
> >>>> 
> >>> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> >>>> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> >>>> at
> >>> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> >>>> at
> >>>> 
> >>> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> >>>> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> >>>> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> >>>> at
> >>> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> >>>> at
> >>>> 
> >>> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> >>>> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> >>>> at
> >>>> 
> >>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> >>>> at
> >>>> 
> >>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> >>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> >>>> at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> >>>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> >>>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> >>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>> at
> >>>> 
> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>>> at
> >>>> 
> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>> at java.lang.reflect.Method.invoke(Method.java:606)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> >>>> at
> >>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> >>>> Caused by: java.lang.ClassNotFoundException:
> >>>> org.sonatype.aether.graph.DependencyFilter
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> >>>> at
> >>>> 
> >>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> >>>> ... 60 more
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> >>> wrote:
> >>>> 
> >>>>> This is the vote for release 1.0.0 of Apache Bigtop.
> >>>>> 
> >>>>> It fixes the following issues:
> >>>>> 
> >>>>> 
> >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> >>>>> 
> >>>>> This is the respin of RC3, addressing the fix for default repo uRLs and
> >>>>> adding
> >>>>> proper header licenses to be able to run full RAT check on the release.
> >>>>> The rest of the release is the same.
> >>>>> 
> >>>>> The vote will be going for at least 48 hours and will be closed on
> >>>>> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> >>> with
> >>>>> 
> >>>>> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> >>>>> [ ] +0, I don't care either way,
> >>>>> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> >>> Bigtop,
> >>>>> because...
> >>>>> 
> >>>>> Source and binary files:
> >>>>>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
> >>>>> 
> >>>>> Maven staging repo:
> >>>>> 
> >>>>> 
> >>> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> >>>>> 
> >>>>> The git tag to be voted upon is release-1.0.0
> >>>>> 
> >>>>> Bigtop's KEYS file containing PGP keys we use to sign the release:
> >>>>>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> >>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> --
> >>>> Best regards,
> >>>> 
> >>>>   - Andy
> >>>> 
> >>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >>>> (via Tom White)
> >>> 
> >> 
> >> 
> >> 
> >> --
> >> Best regards,
> >> 
> >>   - Andy
> >> 
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
no:

$ docker run bigtop/slaves:debian-8  bash -c '. /etc/profile.d/bigtop.sh; mvn --version'
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51:28+0000)
Maven home: /usr/local/maven
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "3.16.0-4-amd64", arch: "amd64", family: "unix"


> Am 11.08.2015 um 00:07 schrieb Konstantin Boudnik <co...@apache.org>:
> 
> But gradle will use whatever mvn is installed on the system or specified via
> MAVEN_HOME env. var. toolchain from 1.0 is setting up 3.0.5, I believe, and
> that's where I don't see the issue w/ Crunch while building on 12.04 Ubuntu.
> 
> Do you see the same issue while running on our official docker image? Thanks!
>  Cos
> 
> On Mon, Aug 10, 2015 at 02:52PM, Andrew Purtell wrote:
>> Ok, then never mind that, I reported what 'mvn' from the command line
>> shows.
>> 
>> I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as far
>> as crunch and it failed:
>> 
>> :crunch-deb FAILED
>> 
>> FAILURE: Build failed with an exception.
>> 
>> * Where:
>> Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
>> 
>> * What went wrong:
>> Execution failed for task ':crunch-deb'.
>>> Process 'command 'debuild'' finished with non-zero exit value 29
>> 
>> * Try:
>> Run with --stacktrace option to get the stack trace. Run with --info or
>> --debug option to get more log output.
>> 
>> BUILD FAILED
>> 
>> 
>> 
>> On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
>> 
>>> Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
>>> 
>>> I believe the issue that Olaf hit the other day has been introduced in
>>> 3.1-alpha or something like that.
>>> 
>>> Cos
>>> 
>>> On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
>>>> I hit the crunch build problem too.
>>>> 
>>>> -0
>>>> 
>>>> Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
>>>> 
>>>> [WARNING] Error injecting:
>>>> org.apache.maven.reporting.exec.DefaultMavenReportExecutor
>>>> java.lang.NoClassDefFoundError:
>>> org/sonatype/aether/graph/DependencyFilter
>>>> at java.lang.Class.getDeclaredConstructors0(Native Method)
>>>> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
>>>> at java.lang.Class.getDeclaredConstructors(Class.java:1906)
>>>> at
>>>> 
>>> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
>>>> at
>>>> 
>>> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
>>>> at
>>>> 
>>> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
>>>> at
>>>> 
>>> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
>>>> at
>>>> 
>>> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
>>>> at
>>>> 
>>> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
>>>> at
>>>> 
>>> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
>>>> at
>>>> 
>>> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
>>>> at
>>>> 
>>> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
>>>> at
>>>> 
>>> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
>>>> at
>>>> 
>>> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
>>>> at
>>>> 
>>> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
>>>> at
>>>> 
>>> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
>>>> at
>>>> 
>>> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
>>>> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
>>>> at
>>>> 
>>> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
>>>> at
>>> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
>>>> at
>>>> 
>>> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
>>>> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
>>>> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
>>>> at
>>> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
>>>> at
>>>> 
>>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
>>>> at
>>>> 
>>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
>>>> at
>>>> 
>>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
>>>> at
>>>> 
>>> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
>>>> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
>>>> at
>>>> 
>>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>>> at
>>>> 
>>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
>>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
>>>> at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
>>>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>>>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
>>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> 
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>> at
>>>> 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>>>> at
>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> org.sonatype.aether.graph.DependencyFilter
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
>>>> at
>>>> 
>>> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
>>>> ... 60 more
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>> 
>>>>> This is the vote for release 1.0.0 of Apache Bigtop.
>>>>> 
>>>>> It fixes the following issues:
>>>>> 
>>>>> 
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>>>>> 
>>>>> This is the respin of RC3, addressing the fix for default repo uRLs and
>>>>> adding
>>>>> proper header licenses to be able to run full RAT check on the release.
>>>>> The rest of the release is the same.
>>>>> 
>>>>> The vote will be going for at least 48 hours and will be closed on
>>>>> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
>>> with
>>>>> 
>>>>> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
>>>>> [ ] +0, I don't care either way,
>>>>> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
>>> Bigtop,
>>>>> because...
>>>>> 
>>>>> Source and binary files:
>>>>>        http://people.apache.org/~cos/bigtop-1.0.0-RC4
>>>>> 
>>>>> Maven staging repo:
>>>>> 
>>>>> 
>>> https://repository.apache.org/content/repositories/orgapachebigtop-1004
>>>>> 
>>>>> The git tag to be voted upon is release-1.0.0
>>>>> 
>>>>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>>>>        http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> 
>>>>   - Andy
>>>> 
>>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>>> (via Tom White)
>>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> 
>>   - Andy
>> 
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
But gradle will use whatever mvn is installed on the system or specified via
MAVEN_HOME env. var. toolchain from 1.0 is setting up 3.0.5, I believe, and
that's where I don't see the issue w/ Crunch while building on 12.04 Ubuntu.

Do you see the same issue while running on our official docker image? Thanks!
  Cos

On Mon, Aug 10, 2015 at 02:52PM, Andrew Purtell wrote:
> Ok, then never mind that, I reported what 'mvn' from the command line
> shows.
> 
> I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as far
> as crunch and it failed:
> 
> :crunch-deb FAILED
> 
> FAILURE: Build failed with an exception.
> 
> * Where:
> Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284
> 
> * What went wrong:
> Execution failed for task ':crunch-deb'.
> > Process 'command 'debuild'' finished with non-zero exit value 29
> 
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
> 
> BUILD FAILED
> 
> 
> 
> On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
> >
> > I believe the issue that Olaf hit the other day has been introduced in
> > 3.1-alpha or something like that.
> >
> > Cos
> >
> > On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> > > I hit the crunch build problem too.
> > >
> > > -0
> > >
> > > Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
> > >
> > > [WARNING] Error injecting:
> > > org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> > > java.lang.NoClassDefFoundError:
> > org/sonatype/aether/graph/DependencyFilter
> > > at java.lang.Class.getDeclaredConstructors0(Native Method)
> > > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> > > at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> > > at
> > >
> > com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> > > at
> > >
> > com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> > > at
> > >
> > org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> > > at
> > >
> > com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> > > at
> > >
> > com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> > > at
> > >
> > com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> > > at
> > >
> > com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> > > at
> > >
> > org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> > > at
> > >
> > com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> > > at
> > >
> > com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> > > at
> > >
> > com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> > > at
> > >
> > com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> > > at
> > >
> > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> > > at
> > >
> > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> > > at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> > > at
> > >
> > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> > > at
> > com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> > > at
> > >
> > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> > > at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> > > at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> > > at
> > org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> > > at
> > >
> > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> > > at
> > >
> > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> > > at
> > >
> > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> > > at
> > >
> > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> > > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> > > at
> > >
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > > at
> > >
> > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> > > at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at
> > >
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > > at
> > >
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:606)
> > > at
> > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > > at
> > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > > at
> > >
> > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > > Caused by: java.lang.ClassNotFoundException:
> > > org.sonatype.aether.graph.DependencyFilter
> > > at
> > >
> > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> > > at
> > >
> > org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> > > at
> > >
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> > > at
> > >
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> > > ... 60 more
> > >
> > >
> > >
> > >
> > > On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > >
> > > > This is the vote for release 1.0.0 of Apache Bigtop.
> > > >
> > > > It fixes the following issues:
> > > >
> > > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > >
> > > > This is the respin of RC3, addressing the fix for default repo uRLs and
> > > > adding
> > > > proper header licenses to be able to run full RAT check on the release.
> > > > The rest of the release is the same.
> > > >
> > > > The vote will be going for at least 48 hours and will be closed on
> > > > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> > with
> > > >
> > > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > > [ ] +0, I don't care either way,
> > > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> > Bigtop,
> > > > because...
> > > >
> > > > Source and binary files:
> > > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > > >
> > > > Maven staging repo:
> > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > > >
> > > > The git tag to be voted upon is release-1.0.0
> > > >
> > > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > > (via Tom White)
> >
> 
> 
> 
> -- 
> Best regards,
> 
>    - Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Andrew Purtell <ap...@apache.org>.
Ok, then never mind that, I reported what 'mvn' from the command line
shows.

I downloaded the 1.0.0 RC artifacts and executed 'gradle deb'. I got as far
as crunch and it failed:

:crunch-deb FAILED

FAILURE: Build failed with an exception.

* Where:
Script '/home/apurtell/tmp/bigtop-1.0.0/packages.gradle' line: 284

* What went wrong:
Execution failed for task ':crunch-deb'.
> Process 'command 'debuild'' finished with non-zero exit value 29

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED



On Mon, Aug 10, 2015 at 2:50 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5
>
> I believe the issue that Olaf hit the other day has been introduced in
> 3.1-alpha or something like that.
>
> Cos
>
> On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> > I hit the crunch build problem too.
> >
> > -0
> >
> > Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
> >
> > [WARNING] Error injecting:
> > org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> > java.lang.NoClassDefFoundError:
> org/sonatype/aether/graph/DependencyFilter
> > at java.lang.Class.getDeclaredConstructors0(Native Method)
> > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> > at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> > at
> >
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> > at
> >
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> > at
> >
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> > at
> >
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> > at
> >
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> > at
> >
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> > at
> >
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> > at
> >
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> > at
> >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> > at
> >
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> > at
> >
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> > at
> >
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> > at
> >
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> > at
> >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> > at
> >
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> > at
> >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> > at
> >
> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> > at
> >
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> > at
> >
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> > at
> >
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> > at
> >
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> > at
> >
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> > at
> >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> > at
> >
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> > at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> > at
> >
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> > at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> > at
> >
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> > at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> > at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> > at
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> > at
> >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> > at
> >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> > at
> >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> > at
> >
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> > at
> >
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> > at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> > at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > at
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > at
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > at
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > at
> >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > at
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> > at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > Caused by: java.lang.ClassNotFoundException:
> > org.sonatype.aether.graph.DependencyFilter
> > at
> >
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> > at
> >
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> > at
> >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> > at
> >
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> > ... 60 more
> >
> >
> >
> >
> > On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >
> > > This is the vote for release 1.0.0 of Apache Bigtop.
> > >
> > > It fixes the following issues:
> > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > >
> > > This is the respin of RC3, addressing the fix for default repo uRLs and
> > > adding
> > > proper header licenses to be able to run full RAT check on the release.
> > > The rest of the release is the same.
> > >
> > > The vote will be going for at least 48 hours and will be closed on
> > > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote
> with
> > >
> > > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > > [ ] +0, I don't care either way,
> > > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache
> Bigtop,
> > > because...
> > >
> > > Source and binary files:
> > >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> > >
> > > Maven staging repo:
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
> > >
> > > The git tag to be voted upon is release-1.0.0
> > >
> > > Bigtop's KEYS file containing PGP keys we use to sign the release:
> > >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > >
> > >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
Why it is Maven 3.2.2 ? 1.0 is based on 3.0.5 

I believe the issue that Olaf hit the other day has been introduced in
3.1-alpha or something like that.

Cos

On Mon, Aug 10, 2015 at 02:46PM, Andrew Purtell wrote:
> I hit the crunch build problem too.
> 
> -0
> 
> Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2
> 
> [WARNING] Error injecting:
> org.apache.maven.reporting.exec.DefaultMavenReportExecutor
> java.lang.NoClassDefFoundError: org/sonatype/aether/graph/DependencyFilter
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
> at java.lang.Class.getDeclaredConstructors(Class.java:1906)
> at
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> at
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
> at
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
> at
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
> at
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
> at
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> at
> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassNotFoundException:
> org.sonatype.aether.graph.DependencyFilter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> ... 60 more
> 
> 
> 
> 
> On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > This is the vote for release 1.0.0 of Apache Bigtop.
> >
> > It fixes the following issues:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> >
> > This is the respin of RC3, addressing the fix for default repo uRLs and
> > adding
> > proper header licenses to be able to run full RAT check on the release.
> > The rest of the release is the same.
> >
> > The vote will be going for at least 48 hours and will be closed on
> > Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> >
> > [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> > [ ] +0, I don't care either way,
> > [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop,
> > because...
> >
> > Source and binary files:
> >         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> >
> > Maven staging repo:
> >
> > https://repository.apache.org/content/repositories/orgapachebigtop-1004
> >
> > The git tag to be voted upon is release-1.0.0
> >
> > Bigtop's KEYS file containing PGP keys we use to sign the release:
> >         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> >
> >
> 
> 
> -- 
> Best regards,
> 
>    - Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Andrew Purtell <ap...@apache.org>.
I hit the crunch build problem too.

-0

Linux Mind 17.1 Rebecca (Ubuntu 14.04 based), Java 7u79, Maven 3.2.2

[WARNING] Error injecting:
org.apache.maven.reporting.exec.DefaultMavenReportExecutor
java.lang.NoClassDefFoundError: org/sonatype/aether/graph/DependencyFilter
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585)
at java.lang.Class.getDeclaredConstructors(Class.java:1906)
at
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
at
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
at
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:653)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:863)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
at
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
at
org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:240)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:234)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:241)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:121)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apacheDefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ClassNotFoundException:
org.sonatype.aether.graph.DependencyFilter
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
... 60 more




On Fri, Aug 7, 2015 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:

> This is the vote for release 1.0.0 of Apache Bigtop.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>
> This is the respin of RC3, addressing the fix for default repo uRLs and
> adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
>
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
>
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop,
> because...
>
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
>
> Maven staging repo:
>
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
>
> The git tag to be voted upon is release-1.0.0
>
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by jay vyas <ja...@gmail.com>.
+1 vagrant and bigpetstore parts, , looks good !

On Mon, Aug 10, 2015 at 5:39 AM, Olaf Flebbe <of...@oflebbe.de> wrote:

> +1: Verified debian rebuild,  git Tag
>
>


-- 
jay vyas

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Olaf Flebbe <of...@oflebbe.de>.
+1: Verified debian rebuild,  git Tag

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Evans Ye <ev...@apache.org>.
+1.
All the provisioner feature works well out of the box.
For the rest of the part, I think the it's mature enough to release.
Thanks for the respin and your hard work pushing 1.0 release.


2015-08-08 8:51 GMT+08:00 Konstantin Boudnik <co...@apache.org>:

> This is the vote for release 1.0.0 of Apache Bigtop.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
>
> This is the respin of RC3, addressing the fix for default repo uRLs and
> adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
>
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
>
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop,
> because...
>
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
>
> Maven staging repo:
>
> https://repository.apache.org/content/repositories/orgapachebigtop-1004
>
> The git tag to be voted upon is release-1.0.0
>
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>
>

Re: [VOTE] Release Bigtop version 1.0.0 (RC4)

Posted by Konstantin Boudnik <co...@apache.org>.
+1 [binding] 

checksums, signatures, rat-check are correct. Have built a few packages and
all seems to be in order.

Cos

On Sat, Aug 08, 2015 at 03:51AM, Konstantin Boudnik wrote:
> This is the vote for release 1.0.0 of Apache Bigtop.
> 
> It fixes the following issues:
>         https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> 
> This is the respin of RC3, addressing the fix for default repo uRLs and adding
> proper header licenses to be able to run full RAT check on the release.
> The rest of the release is the same.
> 
> The vote will be going for at least 48 hours and will be closed on
> Tuesday August 11th, 2015 at noon PDT. Please download, test and vote with
> 
> [ ] +1, accept RC4 as the official 1.0.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC4 as the official 1.0.0 release of Apache Bigtop, because...
> 
> Source and binary files:
>         http://people.apache.org/~cos/bigtop-1.0.0-RC4
> 
> Maven staging repo:
>         https://repository.apache.org/content/repositories/orgapachebigtop-1004
> 
> The git tag to be voted upon is release-1.0.0
> 
> Bigtop's KEYS file containing PGP keys we use to sign the release:
>         http://svn.apache.org/repos/asf/bigtop/dist/KEYS
>