I hear your pain :-)
FWIW, I did import your key using the (possibly incomplete?) directions
reported by the script.
That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.
I did what it told me to below when it failed the 1st time I ran it.
buildTools/download_edgent_asf.sh —validate 1.2.0 1
...
If the following bundle gpg signature checks fail, you may need to
import the project's list of signing keys to your keyring
$ gpg downloaded-edgent-1.2.0rc1/KEYS # show the included keys
$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
…
> On Dec 6, 2017, at 11:24 AM, Christofer Dutz <christofer.d...@c-ware.de>
> wrote:
>
> Hi Dale,
>
> I'm still on the task of manually deleting Things. Will continue tomorrow.
> Have to manually delete at least 4 Files for every artifact one at a time :-(
>
> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No
> expert on that. My key should be valid judging from the number of Apaches
> that signed it. Eventually there is no path of trust and you need to import
> it manually.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
> ________________________________
> From: Dale LaBossiere <dml.apa...@gmail.com>
> Sent: Wednesday, December 6, 2017 5:08:27 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>
> Thx re the nexus content.
>
> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I
> don’t
> get when downloading/validating 1.1.0.
> Might your KEY changes have an issue or you didn’t “published” your key or
> such?
> Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
> to it doesn’t complain for me?
>
> Do you get the WARNING below when you
> buildTools/download_edgent_asf.sh —validate 1.2.0 1
>
> Do you get the WARNING if for 1.1.0?
> Using the *master* branch for the script:
> buildTools/download_edgent_asf.sh —validate 1.1.0
>
> When I run
> buildTools/download_edgent_asf.sh —validate 1.2.0 1
> ...
> Verifying the source bundle signatures...
> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh
> 1.2.0-incubating/rc1
>
> Checking
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5
> OK
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA
> OK
> gpg: assuming signed data in
> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
> gpg: Signature made Fri Dec 1 03:32:10 2017 EST using RSA key ID 5C60D6B9
> gpg: Good signature from "Christofer Dutz (Apache Comitter)
> <cd...@apache.org>" [unknown]
> gpg: aka "[jpeg image of size 272202]" [unknown]
> 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: F156 813F F315 007E 36BA 6C13 0891 27C1 5C60 D6B9
>
> — Dale
>
>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz <christofer.d...@c-ware.de>
>> wrote:
>>
>> Hi Dale,
>>
>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>>
>> Regarding stuff in Nexus, we should remove before hitting the “release”
>> button:
>> - Intermediate poms are important as they are defined as “parent” of other
>> artifacts. Maven downloads them in order to know the entire modules pom, if
>> we omit the intermediate poms, all is broken. This is especially true for
>> the edgent-parent pom.
>> - Yes, we should remove:
>> o Distributions
>> o Test-Jars
>> o Source-Release archives
>> (I’ll see if I can manually remove them otherwise, I would drop the staging
>> repo … re-do the staging of the maven artifacts and then manually delete
>> them before closing the repo)
>> - First thing we should then do in develop for 1.3.0 is to fine tune the
>> maven-deploy-plugin to only deploy stuff we want it to.
>>
>> Chris
>>
>>
>>
>> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
>>
>>
>> Re the KEYS, please update the file in the incubator-edgent source repo.
>>
>> FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing
>> the release”
>> process is supposed to *move* the exact staged/voted artifacts to the
>> release area.
>> I see the our buildTools/publish_release.sh script doesn’t bother to
>> delete the
>> residual staged <ver> dir.
>>
>> In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS
>> in the
>> “release” area (from the “dev” area) so that will be taken care of
>> automatically if the script is used.
>> It looks like it should work without any changes.
>>
>> Agreed, no need to cancel the RC1 vote at this moment since as you note,
>> the RC1 source content hasn’t changed. And generally, updating the
>> poms,etc
>> for “what’s released” is OK to not include in the 1.2.0 source release.
>> But...
>>
>> I think some things MUST get removed from Nexus for 1.2.0. Do you agree?
>> - edgent-distribution (for j8,j7,android)
>> - edgent-parent/*source-release* - or edgent-parent in its entirety?
>> (for j8,j7,android)
>> - …/*-1.2.0-tests.* (for j8,j7,android)
>> - edgent-test* (for j8,j7)
>> - what about “pom-only” intermediate dirs - will those show up in MC?
>> Are they useful?
>> - edgent-analytics
>> - edgent-android
>> - edgent-api
>> ...
>>
>>
>>> On Dec 6, 2017, at 4:00 AM, Christofer Dutz <christofer.d...@c-ware.de>
>>> wrote:
>>>
>>> Hi Dale,
>>>
>>> So, I updated the scripts, deployed the RC in the correct area (I wonder
>>> why the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test
>>> myself to the right solution by running the scripts and fine tuning my
>>> deployment and the scripts. But now I think we have a working solution. As
>>> nothing had to be changed with the source-bundle itself, I don’t think we
>>> need to cancel the RC and create a new one. What do you others think?
>>>
>>> Chris
>>>
>>>
>>> Am 06.12.17, 09:10 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
>>>
>>> HI Dale,
>>>
>>> as I mentioned in the other DISCUSS thread I already noticed this
>>> shortcoming.
>>> I think the following path should be ok for us to follow:
>>>
>>> 1. I manually add my pgp key to the list in KEYS in SVN
>>> 2. I manually add the files created by the assembly plugin to SVN
>>> 3. We continue the voting
>>> 4. In develop I try to automate the deployment of RCs for the next version
>>> 5. We decide what to deploy and what not to and add exclusions to the poms
>>> for next time
>>>
>>> You think that’s a valid approach?
>>>
>>> Chris
>>>
>>>
>>>
>>> Am 06.12.17, 00:09 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
>>>
>>> Chris, thanks for moving the release/RC along!
>>>
>>> I’ve kicked off this DISCUSS thread because I'm unable to tell if the
>>> staged RC is good to go or not and I didn’t want to pollute the RC1
>>> Vote thread.
>>>
>>> Since this is a new process for the project and the nexus / maven
>>> release flow
>>> is new to me I’m confused and have to ask some questions before I can
>>> assess
>>> if the RC contents are ok.
>>>
>>> I, and others, definitely can’t follow the directions in the VOTE's [6]
>>> even reading between the lines and omitting the RM and “binary” parts
>>> of it :-)
>>>
>>> Here’s where I’m stumbling:
>>>
>>> - I’m of the belief that the traditional normally mandated ASF
>>> *source* release staging and
>>> release areas must continued to be used for the release’s aggregate
>>> source bundle(s)
>>> https://dist.apache.org/repos/dist/dev/incubator/edgent
>>> <https://dist.apache.org/repos/dist/dev/incubator/edgent>
>>> https://dist.apache.org/repos/dist/release/incubator/edgent
>>> <https://dist.apache.org/repos/dist/release/incubator/edgent>
>>>
>>> There isn’t anything staged in the “dev” area for 1.2.0.
>>> If you look at the “release” area you’ll see what the expected
>>> contents/layout are
>>> (of course omitting the “binaries” dir for 1.2.0).
>>>
>>> FWIW, there seems to be inconsistency among what additional files
>>> TLPs have - e.g., beam,nifi,camel only have the bundle, kafka
>>> includes RELEASE_NOTES,
>>> flex (which original edgent process derived from) has LICENSE,
>>> README, ….
>>> I guess we can follow the lean-and-mean ones if we want to :-)
>>>
>>> That said, that layout, and form of bundle name, is what the [6]
>>> referenced
>>> download-edgent-asf.sh tool expects so it simply won’t work.
>>> I’m happy to fix the script, if appropriate, once I understand
>>> things.
>>>
>>> Note: I see aggregate source release bundles *are* present in the
>>> nexus dir:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>>
>>> <https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/>
>>> That said, the form of their names
>>> (edgent-parent-1.2.0-source-releaase…) isn’t what's expected / required.
>>> Also note, those names are different from what -Papache-release
>>> generates in the target dir
>>> (apache-edgent-<ver>—incubating-source-release…)
>>>
>>> - I’m unclear on what I see staged in nexus will ultimately be
>>> released in nexus and mirrored to maven central,
>>> hence unclear whether the nexus contents are “correct”.
>>>
>>> Is everything present in the nexus’s RC staging repo going to get
>>> mirrored to Maven Central
>>> and if so, is that what’s desired?
>>> - there are the aforementioned aggregate edgent-parent source
>>> bundles (with names different from what's mandated - e.g. “incubating” in
>>> them)
>>> - there are individual component source jars - I can imagine those
>>> could be useful for associating src with a component
>>> - there are individual component test jars - those seem undesired
>>> - there’s the edgent-test* components - those seem undesired
>>> - there are edgent-distribution components that have
>>> aggregate/transitive “bin” bundles that we’re NOT releasing
>>>
>>> Thanks in advance for the clarifications.
>>> — Dale
>>>
>>>> On Dec 5, 2017, at 3:40 AM, Christofer Dutz <christofer.d...@c-ware.de>
>>>> wrote:
>>>>
>>>> Apache Edgent (Incubating) 1.2.0 has been staged under [4] and it’s time
>>>> to vote
>>>> on accepting it for release. All Maven artifacts are available under [3].
>>>> If approved we will seek final release approval from the IPMC.
>>>> Voting will be open for 72hr.
>>>>
>>>> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>>>> are required to pass.
>>>>
>>>> Per [5] "Before voting +1 [P]PMC members are required to download
>>>> the signed source code package, compile it as provided, and test
>>>> the resulting executable on their own platform, along with also
>>>> verifying that the package meets the requirements of the ASF policy
>>>> on releases."
>>>>
>>>> You can achieve the above by following [6].
>>>>
>>>> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
>>>> items in [6])
>>>> [ ] -1 reject (explanation required)
>>>>
>>>>
>>>> Apache Edgent release process documentation: [1] and [2]. However, this
>>>> is a first test of a Maven based
>>>> Release described in the projects Maven site:
>>>> src/site/asciidoc/releasing.adoc if this form of release proves
>>>> to be valid we will update [1] and [2] to the latest changes.
>>>>
>>>> [1]
>>>> https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>>> [2]
>>>> https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>>> [3]
>>>> https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>>> [4]
>>>> https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
