OK, so how do I do the merge?
I tried using the following in a fresh checkout of the staging branch:
svn merge ^/subversion/site/publish
However it showed changes I have not made, so I am loath to commit them:
$ svn -u st
M 1839421 roadmap.html
M 1839421 quick-start.html
M 1839421 faq.html
M 1839421 .
Status against revision: 1839421
Is this normal?
On 25 August 2018 at 22:18, Stefan <luke1410_at_posteo.de> wrote:
> On 25/08/2018 18:06, sebb AT ASF wrote:
>> On 25 August 2018 at 13:44, Stefan <luke1410_at_posteo.de> wrote:
>>> On 25/08/2018 14:37, Stefan wrote:
>>>> On 23/08/2018 20:01, sebb_at_apache.org wrote:
>>>>> Author: sebb
>>>>> Date: Thu Aug 23 18:01:30 2018
>>>>> New Revision: 1838746
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1838746&view=rev
>>>>> Log:
>>>>> SVN-4736 - fix gpg command
>>>>>
>>>>> Modified:
>>>>> subversion/site/staging/download.html
>>>>>
>>>>> Modified: subversion/site/staging/download.html
>>>>> URL: http://svn.apache.org/viewvc/subversion/site/staging/download.html?rev=1838746&r1=1838745&r2=1838746&view=diff
>>>>> ==============================================================================
>>>>> --- subversion/site/staging/download.html (original)
>>>>> +++ subversion/site/staging/download.html Thu Aug 23 18:01:30 2018
>>>>> @@ -253,7 +253,7 @@ Other mirrors:
>>>>> <em>or</em><br />
>>>>> <code>
>>>>> % gpg --import subversion.asc<br />
>>>>> -% gpg --verify subversion-[version].tar.gz.asc
>>>>> +% gpg --verify subversion-[version].tar.gz.asc subversion-[version].tar.gz
>>>> Testing GPG locally (2.2.8 - Windows 10 - bundled version with Gpg4Win
>>>> 3.1.2) running the command w/o specifying the filename of the gz archive
>>>> works fine:
>>>> "gpg: assuming signed data in 'subversion-1.10.2.tar.bz2' [...]"
>>>>
>>>> Is this command problematic with older GPG versions? If not, why not
>>>> keep the command as short as possible and rely on the default resolution
>>>> of the archive name?
>>> Just saw the referenced SVN issue with the link which gives the missing
>>> rational for that change. Thanks for that (should have spotted it before
>>> replying). For the record:
>> Would it be useful to link to the explanation from the download page?
> I would not think so. The target audience of that article is primarily
> the user who's downloading the package. We'd provide him with proper
> details about how to verify the download, but anything which explains
> the rational behind how the tech side of the verification works and why
> the command should be written the way it's presented in the example
> would be out of scope for that page, IMO. The rational why something was
> done the way it was should be in the log (and there it's already present
> via the Jira issue link).
>
>>
>>> "If the release file is omitted, GPG will only check the signature
>>> against the release file if the signature is a detached signature. If
>>> the .asc file is a self-contained signed file, GPG will only check that,
>>> and will not verify the release. (This should not happen if the
>>> signature file was downloaded from an ASF server, but it is safer to
>>> always specify the release filename)" [1]
>>>
>>> That said, +1 on that change. Feel free to merge it to publish.
>>>
>>> [1] https://www.apache.org/info/verification.html#CheckingSignatures
>>>>> </code></p>
>>>>>
>>>>> <p>Alternatively, you can verify the checksums on the
>>>>>
>>> Regards,
>>> Stefan
>>>
> Regards,
> Stefan
>
>
Received on 2018-08-28 12:46:07 CEST