Re: Windows Build
Den ons 17 feb. 2021 kl 17:31 skrev Nathan Hartman : > > On Wed, Feb 17, 2021 at 11:12 AM Alan Fry wrote: > > For all that helped w/ the Linux build, thank you, I have a set of > > repeatable build instructions for Subversion on linux. If there is > > value, I'd be happy to post those. I verified those instructions > > last night, building from ground up a VM that builds and > > successfully runs 'make check'. > > Yes, please do! It will likely help others. Also perhaps others will > chime in and offer suggestions on easier ways to do some things. > > > I'd like to do the same with Windows. Several have sent me links > > for instructions, however I'd like to ask if there is a recent, > > relatively agreed upon set of instructions, before I start. > > Otherwise, I'll just pick one and give it a try. > > The thread "Building SVN (dependencies) on Windows" to our dev@ list > on 20 Apr 2020 has a collection of useful information. That can be > found at any of these links: > > https://svn.haxx.se/dev/archive-2020-04/0090.shtml > > https://mail-archives.apache.org/mod_mbox/subversion-dev/202004.mbox/%3cCAB84uBW0RTUkNj30zXFLOtT3=xbhxdarvlnuotnmbg-xqq6...@mail.gmail.com%3e > > https://lists.apache.org/thread.html/r59a30aabaab7bf69effa909b331eaa177418325280ea25859e8fa294%40%3Cdev.subversion.apache.org%3E In addition to this excellent thread it might be interesting to take a look at TortoiseSVN's build process [1]. As far as I understand it, all dependencies are build from source. Dependencies sit in [2], some (such as OpenSSL) are simply copied into the repository (I'm guessing from release tarballs, sometimes with local patches on top) and some (such as Subversion and APR) are svn:externals. TSVN uses NAnt [3] with a homegrown build script. I'm out of time to dig around at building on Win myself but I'm happy to test out any instructions. Kind regards, Daniel Sahlberg [1] https://svn.osdn.net/svnroot/tortoisesvn/trunk/build.txt [2] https://svn.osdn.net/svnroot/tortoisesvn/trunk/ext [3] http://nant.sourceforge.net/
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
Den ons 17 feb. 2021 kl 21:29 skrev Øyvind A. Holm : > If you're ok with a text-based interface, there's Mutt for MS Windows: > > https://cygwin.com/packages/summary/mutt.html > > Mutt doesn't do any funky stuff with your emails, WYWIWYS (What You > Write Is What You Send). You'll need to install Cygwin, though. Thanks, I'll give it a try. Since it is text based, I'll go with WSL. /Daniel
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
Den ons 17 feb. 2021 kl 21:22 skrev Daniel Shahaf : > Yes, +1 to commit. Thanks! Committed r1886641. /The other Daniel
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
On 2021-02-17 21:10:29, Daniel Sahlberg wrote: > Den ons 17 feb. 2021 19:47 Daniel Shahaf > skrev: > > Your email client added a hard link break, breaking the patch. > > Stupid Gmail. Anyone have a suggestion for a reasonable email client > on Windows? If you're ok with a text-based interface, there's Mutt for MS Windows: https://cygwin.com/packages/summary/mutt.html Mutt doesn't do any funky stuff with your emails, WYWIWYS (What You Write Is What You Send). You'll need to install Cygwin, though. - Øyvind geo:60.38,5.33;u=500 OpenPGP fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 5224e9f2-715d-11eb-8625-5582e081d110
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
Daniel Sahlberg wrote on Wed, 17 Feb 2021 20:10 +00:00: > Den ons 17 feb. 2021 19:47Daniel Shahaf skrev: > > Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:30:36 +0100: > > > Den tis 16 feb. 2021 kl 21:31 skrev Daniel Shahaf > > > : > > > > > > > > The newline between the «]» and the «[» would get copied to the output > > > > if the condition is true. Is that intentional? > > > > > > No, didn't pay attention to how ezt added newlines. Better like this? > > > No extra newlines except that the comments are on separate lines to > > > make them easy to remove. > > > > +1. More below. > > Just to be sure I get this right: Should I count this as ok to do an > "approved by" commit (Hacking, Partial commit access)? Yes, +1 to commit. > > Preëexisting issue: The whitespace (newline and spaces) between the «>» > > and the words "change log" should be removed, otherwise some browsers > > render an underlined space. > > I'll fix this as well, this would qualify as an obvious fix, right? Sure. Cheers, Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den ons 17 feb. 2021 19:42Daniel Shahaf skrev: > Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100: > > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf < > d...@daniel.shahaf.name>: > > > Is it worthwhile to automate this step? doap.rdf changes rarely enough > > > that we needn't bother with "edit part of a file" logic; we can just > > > regenerate the entire file and «svnmucc put» it into place, with a > > > comment indicating it's a generated file. > > > > The doap.rdf contain references to two separate releases (at least > > right now) and when running release.py you are working on one release > > at a time. So we can't just have a template and add the current > > release number, we also need to know the other release (which could > > have been a year ago or the same day). > > Well, yes, and «release.py clean-dist» already has logic to determine > the other release's version number. > > > To automate "edit part of file", we would need to search for the same > > major.minor and replace with current relase, but when there is a new > > minor (1.15..) we would have to edit manually anyway. > > I don't think so. > > We could generate subversion-%(version)s.rdf-excerpt files, drop them in > dist/, and then use clean_dist()-like logic to cat the right subset of > them, adding a fixed header and trailer. This way, we wouldn't need to > splice lines out of and into the file, and we wouldn't need to special-case > the first release of a minor line or the EOLing of a minor line in the > logic. > > > It's a balance between the amount of work done by RM, the downside of > > having different processes for new minor and new patch release and the > > work to code to automate. I'm leaning towards having it as it is, but > > I would listen to Stefan's opinion (since he did the most recent RM). > > By and large, agreed, but see above for the details. > All this sounds good. However I'm not fluent in Python and even though learning is on my to-do, it is not high enough right now so I'll leave it to someone else. Kind regards Daniel Sahlberg >
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
Den ons 17 feb. 2021 19:47Daniel Shahaf skrev: > Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:30:36 +0100: > > Den tis 16 feb. 2021 kl 21:31 skrev Daniel Shahaf < > d...@daniel.shahaf.name>: > > > > > > The newline between the «]» and the «[» would get copied to the output > > > if the condition is true. Is that intentional? > > > > No, didn't pay attention to how ezt added newlines. Better like this? > > No extra newlines except that the comments are on separate lines to > > make them easy to remove. > > +1. More below. > Just to be sure I get this right: Should I count this as ok to do an "approved by" commit (Hacking, Partial commit access)? > +++ templates/rc-news.ezt (working copy) > > @@ -7,9 +7,13 @@ > > - announcement for more information about this release, and the > > + announcement for more information about this release, and > > the[if-any announcement_url][else] > > Your email client added a hard link break, breaking the patch. > Stupid Gmail. Anyone have a suggestion for a reasonable email client on Windows? > +|... and this end comment--->[end] > > release notes > and > > https://svn.apache.org/repos/asf/subversion/tags/[version]/CHANGES;> > > change log for information about what will eventually be > > Preëexisting issue: The whitespace (newline and spaces) between the «>» > and the words "change log" should be removed, otherwise some browsers > render an underlined space. > I'll fix this as well, this would qualify as an obvious fix, right? Kind regards Daniel Sahlberg
Fwd: [Mark Thomas: Re: Path and name of KEYS file]
Forwarding with permission. Quoted matter not covered by permission has been omitted or paraphrased. - Forwarded message from Mark Thomas - > Date: Wed, 17 Feb 2021 17:39:23 + > From: Mark Thomas > To: operations@ > Subject: Re: Path and name of KEYS file > Reply-To: operati...@apache.org > Message-ID: <811b6803-3439-333e-d5eb-5c128dfd1...@apache.org> > > [A quoted person] wrote: > > [Who owns questions about the policy for pathnames of keyring files > > in dist/?] > > Since this stems from the release policy, I'd guess the Legal Affairs > committee. > > > [Each PMC should have a single keyring file, named "KEYS" and placed > > at the root of its dist/ tree.] > > I think that should be a strong recommendation (SHOULD) rather than a > hard requirement (MUST). > > The hard requirements are that the KEYS file is: > - linked from the download page > - contains the key(s) that signed the release(s) on the download page > - available to the mirror network > > If the project has a reason to locate the file elsewhere they should be > free to do so. > > Mark > - End forwarded message -
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:30:36 +0100: > Den tis 16 feb. 2021 kl 21:31 skrev Daniel Shahaf : > > > > The newline between the «]» and the «[» would get copied to the output > > if the condition is true. Is that intentional? > > No, didn't pay attention to how ezt added newlines. Better like this? > No extra newlines except that the comments are on separate lines to > make them easy to remove. +1. More below. > +++ templates/rc-news.ezt (working copy) > @@ -7,9 +7,13 @@ > - announcement for more information about this release, and the > + announcement for more information about this release, and > the[if-any announcement_url][else] Your email client added a hard link break, breaking the patch. > +|... and this end comment--->[end] > release notes and > href="https://svn.apache.org/repos/asf/subversion/tags/[version]/CHANGES;> > change log for information about what will eventually be Preëexisting issue: The whitespace (newline and spaces) between the «>» and the words "change log" should be removed, otherwise some browsers render an underlined space. Cheers, Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100: > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf : > > Is it worthwhile to automate this step? doap.rdf changes rarely enough > > that we needn't bother with "edit part of a file" logic; we can just > > regenerate the entire file and «svnmucc put» it into place, with a > > comment indicating it's a generated file. > > The doap.rdf contain references to two separate releases (at least > right now) and when running release.py you are working on one release > at a time. So we can't just have a template and add the current > release number, we also need to know the other release (which could > have been a year ago or the same day). Well, yes, and «release.py clean-dist» already has logic to determine the other release's version number. > To automate "edit part of file", we would need to search for the same > major.minor and replace with current relase, but when there is a new > minor (1.15..) we would have to edit manually anyway. I don't think so. We could generate subversion-%(version)s.rdf-excerpt files, drop them in dist/, and then use clean_dist()-like logic to cat the right subset of them, adding a fixed header and trailer. This way, we wouldn't need to splice lines out of and into the file, and we wouldn't need to special-case the first release of a minor line or the EOLing of a minor line in the logic. > It's a balance between the amount of work done by RM, the downside of > having different processes for new minor and new patch release and the > work to code to automate. I'm leaning towards having it as it is, but > I would listen to Stefan's opinion (since he did the most recent RM). By and large, agreed, but see above for the details. Cheers, Daniel
Re: Problems with the subversion download page
Nathan Hartman wrote on Tue, Feb 16, 2021 at 22:00:24 -0500:
> On Tue, Feb 16, 2021 at 7:31 PM Nathan Hartman
> wrote:
>
> > On Tue, Feb 16, 2021 at 5:55 PM Mark Phippard wrote:
> > >
> > > On Tue, Feb 16, 2021 at 5:04 PM Craig Russell
> > wrote:
> > >
> > >>
> > >> I'm looking at your download page
> > >> https://subversion.apache.org/download.cgi#recommended-release
> > >> and I'm unable to see any mirrors.
> > >>
> > >> The "Other mirrors" dropdown contains only two entries:
> > >> https://downloads.apache.org/
> > >> https://downloads.apache.org/ (backup)
> > >>
> > >> Any ideas how to troubleshoot this?
> > >
> > >
> > > I see 11 counting the two Apache hosts and two ftp hosts. I am not sure
> > how it works though and I assume you already tried Refreshing the page etc.
> >
> >
> > I'm seeing the same thing as Craig.
> >
> > This issue doesn't stem from our repository; it has to do with
> > whatever is executing the CGI in (download.html redirected to)
> > download.cgi on Infra's end.
> >
> > I'll ask Infra to look into it...
>
>
>
> Infra says the mirror system isn't IPv6 aware.
>
> It looks like there isn't anything we (Subversion) can do on our end.
And just to be clear: The issue isn't specific to Subversion. All
${pmc}.apache.org download pages rely on a single centralized implementation
(maintained by Infra) to determine mirrors.
I suppose there may be an optional query argument one can pass to select
a specific country, but that's a question to Infra, not to us.
Cheers,
Daniel
Re: Source Code Build Errors?
Alan Fry wrote on Tue, Feb 16, 2021 at 20:16:34 -0500: > On Tue, Feb 16, 2021 at 7:32 PM Alan Fry wrote: > > FAIL: commit_tests.py 48: set revision props during remote property edit > > FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe) > > FAIL: prop_tests.py 16: property operations on a URL > > FAIL: update_tests.py 38: update --accept automatic conflict resolution > > I was missing a link that patched up 'python' to python3. Right, I see the problem. Those four tests are exactly those that invoke use_editor(), and that function sets $SVN_MERGE and $SVN_EDITOR to a «#!/usr/bin/env python» script. That's a bug, actually. The test suite shouldn't use whichever 'python' binary happens to lie in $PATH, but the one specified by sys.executable. > Seems I have a successful build: Congrats ☺
Re: Source Code Build Errors?
Alan Fry wrote on Tue, Feb 16, 2021 at 19:32:24 -0500: > On Mon, Feb 15, 2021 at 1:38 PM Daniel Shahaf > wrote: > > > Alan Fry wrote on Mon, Feb 08, 2021 at 18:34:01 -0500: > > > It seems that, in my case in subversion/tests/libsvn_fs/locks-test.c > > (line > > > 1134), the test expects an error, however it succeeds. Again, I'm not a > > > linux person, so I spent an hour trying to figure out what executable is > > > actually generating test.log... > > > > tests.log is generated by build/run_tests.py, which runs individual test > > programs and is run by «make check». To cut a long story short, I think > > you're looking for one of these: > > > > 1. make locks-test && (cd subversion/tests/libsvn_fs && ./locks-test) > > (I could be wrong about the default cwd) > > > > 2. «make check TESTS=subversion/tests/libsvn_fs/locks-test.c» > > > > All this should be documented somewhere in the README files (in the tree > > root > > and in subversion/tests/ and subversion/tests/cmdline/). > > > > > Any suggestions on next steps? If I have not posted enough information, > > > I'd be happy to be more concise. > > > > You haven't addressed my suggestions from my previous reply. To be > > explicit, > > what's the output of «id» when run just before «make check»? > > > I do appreciate your help. I didn't think otherwise. > I documented the steps to setup a Linux VM (Virtualbox/Ubuntu 20.04). This > time, however, I followed a different set of steps to build Subversion on > linux, and I no longer get the error in locks-test.c. As I have mentioned, > I have almost zero experience in Linux, so I'm sure the original error was > 'environmental', something to do with APR probably. > > I did keep the original VM, so if you feel there is value in continuing > down that line, I'd be happy to... my challenge was not being sure what > "what's the output of «id» when run just before «make check»"... again > having zero experience with linux I wasn't sure what you were asking for. I was asking you to, just before you run the test suite, run the command «id» (two letters, just like «ls») without arguments and report its output. That's because that command reports the real and effective uid/gid, and in particular indicates whether the tests are run with superuser privileges, which the comment I referred to earlier documents as a known failure case. > At least one test FAILED, checking /home/svn/src/subversion-1.14.1/tests.log > FAIL: commit_tests.py 48: set revision props during remote property edit > FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe) > FAIL: prop_tests.py 16: property operations on a URL > FAIL: update_tests.py 38: update --accept automatic conflict resolution I see downthread these pass for you now, but for future reference, to answer any question about these, we'd need to see the full test output from tests.log. At the end of a full test run the relevant parts of tests.log are copied to fails.log. (Updating fails.log as the test run progresses has never been implemented.) Cheers, Daniel > Summary of test results: > 2517 tests PASSED > 161 tests SKIPPED > 80 tests XFAILED (17 WORK-IN-PROGRESS) > 4 tests FAILED > Python version: 3.8.5. > SUMMARY: Some tests failed
Re: Windows Build
On Wed, Feb 17, 2021 at 11:12 AM Alan Fry wrote: > For all that helped w/ the Linux build, thank you, I have a set of > repeatable build instructions for Subversion on linux. If there is > value, I'd be happy to post those. I verified those instructions > last night, building from ground up a VM that builds and > successfully runs 'make check'. Yes, please do! It will likely help others. Also perhaps others will chime in and offer suggestions on easier ways to do some things. > I'd like to do the same with Windows. Several have sent me links > for instructions, however I'd like to ask if there is a recent, > relatively agreed upon set of instructions, before I start. > Otherwise, I'll just pick one and give it a try. The thread "Building SVN (dependencies) on Windows" to our dev@ list on 20 Apr 2020 has a collection of useful information. That can be found at any of these links: https://svn.haxx.se/dev/archive-2020-04/0090.shtml https://mail-archives.apache.org/mod_mbox/subversion-dev/202004.mbox/%3cCAB84uBW0RTUkNj30zXFLOtT3=xbhxdarvlnuotnmbg-xqq6...@mail.gmail.com%3e https://lists.apache.org/thread.html/r59a30aabaab7bf69effa909b331eaa177418325280ea25859e8fa294%40%3Cdev.subversion.apache.org%3E Feel free to ask as many questions as you need to. Nathan P.S., At any time, if you'd like to help improve the documentation that we have on the website or in files that ship with Subversion, feel free to send patches!
Windows Build
For all that helped w/ the Linux build, thank you, I have a set of repeatable build instructions for Subversion on linux. If there is value, I'd be happy to post those. I verified those instructions last night, building from ground up a VM that builds and successfully runs 'make check'. I'd like to do the same with Windows. Several have sent me links for instructions, however I'd like to ask if there is a recent, relatively agreed upon set of instructions, before I start. Otherwise, I'll just pick one and give it a try.
Re: svn commit: r1886460 - /subversion/trunk/subversion/tests/cmdline/mod_authz_svn_tests.py
On Tue, Feb 16, 2021 at 08:18:04PM +, Daniel Shahaf wrote: > Stefan Sperling wrote on Tue, Feb 16, 2021 at 12:12:35 +0100: > > On Mon, Feb 15, 2021 at 07:47:48PM +, Daniel Shahaf wrote: > > > s...@apache.org wrote on Fri, Feb 12, 2021 at 10:40:16 -: > > > > Author: stsp > > > > Date: Fri Feb 12 10:40:16 2021 > > > > New Revision: 1886460 > > > > > > > > URL: http://svn.apache.org/viewvc?rev=1886460=rev > > > > Log: > > > > Add a test for the NULL deref issue also known as CVE-2020-17525. > > > > > > > > * subversion/tests/cmdline/mod_authz_svn_tests.py > > > > (nonexistent_repos_relative_access_file): New test. > > > > > > Propose this for backport? > > > > Yes, done now in r1886583. > > Thanks. How about 1.10 too? It received the fix so it should receive its > tests. Indeed, I forgot about 1.10. Thanks for the reminder. Done now.
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf : > Is it worthwhile to automate this step? doap.rdf changes rarely enough > that we needn't bother with "edit part of a file" logic; we can just > regenerate the entire file and «svnmucc put» it into place, with a > comment indicating it's a generated file. The doap.rdf contain references to two separate releases (at least right now) and when running release.py you are working on one release at a time. So we can't just have a template and add the current release number, we also need to know the other release (which could have been a year ago or the same day). To automate "edit part of file", we would need to search for the same major.minor and replace with current relase, but when there is a new minor (1.15..) we would have to edit manually anyway. It's a balance between the amount of work done by RM, the downside of having different processes for new minor and new patch release and the work to code to automate. I'm leaning towards having it as it is, but I would listen to Stefan's opinion (since he did the most recent RM). Kind regards, Daniel
Re: svn commit: r1886494 - /subversion/site/staging/docs/community-guide/releasing.part.html
Den tis 16 feb. 2021 kl 21:31 skrev Daniel Shahaf : > > The newline between the «]» and the «[» would get copied to the output > if the condition is true. Is that intentional? No, didn't pay attention to how ezt added newlines. Better like this? No extra newlines except that the comments are on separate lines to make them easy to remove. [[[ Index: templates/rc-news.ezt === --- templates/rc-news.ezt (revision 1886582) +++ templates/rc-news.ezt (working copy) @@ -7,9 +7,13 @@ We are pleased to announce the release of Apache Subversion [version]. This release is not intended for production use, but is provided as a milestone to encourage wider testing and feedback from intrepid users and maintainers. - Please see the + Please see the[if-any announcement_url][else] +[end] release notes and https://svn.apache.org/repos/asf/subversion/tags/[version]/CHANGES;> change log for information about what will eventually be Index: templates/stable-news.ezt === --- templates/stable-news.ezt (revision 1886582) +++ templates/stable-news.ezt (working copy) @@ -9,9 +9,13 @@ users of Subversion to upgrade as soon as reasonable. [else] This is the most complete release of the [major-minor].x line to date, and we encourage all users to upgrade as soon as reasonable. -[end] Please see the +[end] Please see the[if-any announcement_url][else] +[end] release notes for more information about this release. ]]] Kind regards, Daniel Sahlberg
