I finally managed to run steps 1,2 (3 partly, 4 partly) While testing on one of my machines it creates Zombie processes with 100% load, clearly signalling a kernel bug. I seem to trip over docker induced kernel / aufs problems, like https://github.com/docker/docker/issues/18180
Anyway: +1 to the release. Olaf > Am 07.02.2016 um 16:56 schrieb Evans Ye <[email protected]>: > > I think it's OK to just update the KEYS file. > > > Here's my evaluation result of 1.1.0 RC1: > > 1. sha1, md5, signature verified > 2. build bigtop/slaves 1.1.0 images > 3. use above 1.1.0 slave images to build 1.1.0 packages > 4. run Docker Provisioner to deploy 1.1.0 packages > 5. run Vagrant Provisioner to deploy 1.1.0 packages > 6. run hadoop and pig smoke tests > 7. run hadoop itest > > Surely I didn't cover all the features, but the core feature I touched all > works well. > Hence here's my +1 to the RC1. > > > 2016-02-07 15:23 GMT+08:00 Konstantin Boudnik <[email protected]>: > >> Argh... the keys again. CB588E12 is one of my subs, but it is DSA key and >> we >> had a lot of troubles with the RPMs (because RPM only works with "secure" >> RSA >> keys). Eventually, for package signing I've used FA08B173, which is a part >> of >> the KEYS file. >> >> Technically, speaking there's no rule dictating to sign release artifacts >> and >> binary package with the same key. So, if having two keys is ok, then I will >> need to add CB588E12 to the KEYS as well. Or alternatively, I (or someone >> else) would need to do RC2 with correct signature. >> >> Cos >> >> On Sun, Feb 07, 2016 at 03:15PM, Evans Ye wrote: >>> Hi Olaf, did you get the key from keyserver? >>> >>> $ gpg --verify bigtop-1.1.0-project.tar.gz.asc >> bigtop-1.1.0-project.tar.gz >>> gpg: Signature made Sun Jan 31 12:09:46 2016 CST using DSA key ID >> CB588E12 >>> gpg: Can't check signature: public key not found >>> >>> $ gpg --keyserver pgpkeys.mit.edu --recv-key CB588E12 # Took a while to >>> finish >>> >>> $ gpg --verify bigtop-1.1.0-project.tar.gz.asc >> bigtop-1.1.0-project.tar.gz >>> gpg: Signature made Sun Jan 31 12:09:46 2016 CST using DSA key ID >> CB588E12 >>> gpg: Good signature from "Konstantin I Boudnik (Cos) <[email protected]>" >>> gpg: aka "Konstantin I Boudnik (Cos) <[email protected]>" >>> gpg: WARNING: This key is not certified with a trusted signature! >>> gpg: There is no indication that the signature belongs to the >>> owner. >>> Primary key fingerprint: 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 >> E622 >>> Subkey fingerprint: 88C5 8332 D1A9 6A83 F9B3 2776 7A7C 8596 CB58 >> 8E12 >>> >>> >>> 2016-02-05 17:01 GMT+08:00 Olaf Flebbe <[email protected]>: >>> >>>> hi, >>>> >>>> the signature file is made with a key CB588E12 , not contained in KEYS. >>>> Or missed I something important? >>>> >>>> Olaf >>>> >>>>> Am 31.01.2016 um 05:35 schrieb Konstantin Boudnik <[email protected]>: >>>>> >>>>> This is the vote for release 1.1.0 of Apache Bigtop. >>>>> >>>>> It fixes the following issues: >>>>> >>>> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12329714 >>>>> >>>>> The vote will be going for at least 72 hours and will be closed on >>>> Wednesday, >>>>> February 3rd, 2016 at noon PDT. Please download, test and vote with >>>>> >>>>> [ ] +1, accept rc1 as the official 1.1.0 release of Apache Bigtop >>>>> [ ] +0, I don't care either way, >>>>> [ ] -1, do not accept rc1 as the official 1.1.0 release of Apache >>>> Bigtop, because... >>>>> >>>>> Source and binary files: >>>>> https://dist.apache.org/repos/dist/dev/bigtop/1.1.0-rc1 >>>>> >>>>> Maven staging repo: >>>>> >> https://repository.apache.org/content/repositories/orgapachebigtop-1006 >>>>> >>>>> The git tag to be voted upon is release-1.1.0 >>>>> >>>>> Bigtop's KEYS file containing PGP keys we use to sign the release: >>>>> https://dist.apache.org/repos/dist/release/bigtop/KEYS >>>>> >>>>> Thanks! >>>>> Cos >>>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
