lets give this a shot: https://github.com/apache/infrastructure-p6/pull/394
- Sam Ruby On Tue, Jul 7, 2020 at 7:25 PM Craig Russell <apache....@gmail.com> wrote: > > I would say that the easiest solution is for the svn repositories to be > "fixed" to allow the code that we have to work. > > Sebb, can you find out from infra if there is a technical solution to this? > If it is just "change some permissions" that allows svnmucc to work then > let's do that. > > Or is there some other side effect (like the code has to first checkout a > non-existent repository and fiddle with some svnurl magic that bypasses our > repository.yml architecture)? > > Please let's see if this is viable. > > Thanks, > Craig > > > On Jul 7, 2020, at 3:31 PM, sebb <seb...@gmail.com> wrote: > > > > On Tue, 7 Jul 2020 at 23:14, Sam Ruby <ru...@intertwingly.net > > <mailto:ru...@intertwingly.net>> wrote: > >> > >> On Tue, Jul 7, 2020 at 12:59 PM Craig Russell <apache....@gmail.com> wrote: > >>> > >>> Hi Sebb, > >>> > >>> Good job figuring out what the problem was (is). > >>> > >>> From my perspective, having emeritus under documents is somewhat > >>> arbitrary. There is no reason for the emeritus documents to have to live > >>> there, considering that they are all foundation. You could also make a > >>> case for moving member_apps under foundation since the member apps are > >>> probably the most personal-sensitive documents we hold. > >>> > >>> My recommended solution: > >>> > >>> mv documents/emeritus* foundation > >> > >> I've lost track of what error this fixes. > > > > svnmucc cannot update both ^foundation and ^documents in the same batch. > > > > This appears to be because the top-level private directory is locked down. > > > >> Question: would it be possible to go the other way? > >> > >> It sounds like there is a directory for temporary documents, and that > >> is currently in foundation, and that causes a problem. > > > > Not a temporary directory, it is members.txt that is under ^foundation > > > >> Can that directory instead be in documents? > > > > Not the whole directory, but potentially members.txt could move. > > That might however be more disruptive. > > > > The alternatives are: > > - solve the svnmucc permission issue with the help of Infra > > - use a non-atomic sequence of SVN commands to update members.txt and > > the emeritus files. > > The commands to do the updates are not difficult, however successful > > recovery from errors is tricky, which is why I suggested svnmucc. > > But if using svnmucc does not make it easier, then we don't have to use it. > > > >> It just seems weird to me for the rule to be that all documents are in > >> documents except for those that aren't. > > > > What is a document? > > There are lots of files under ^foundation that could be classified as > > documents... > > > >>> A bit of code tweaking to change repository.yml and we're done. > >>> > >>> If no objections within 72, we can proceed with this plan. > >>> > >>> Craig > >> > >> - Sam Ruby > >> > >>>> On Jul 7, 2020, at 8:31 AM, sebb <seb...@gmail.com> wrote: > >>>> > >>>> On Tue, 7 Jul 2020 at 14:39, Craig Russell <apache....@gmail.com> wrote: > >>>>> > >>>>> Any new news on the failure in (emeritus) function? > >>>> > >>>> Whilst the changes are both to the same repository, they have different > >>>> roots: > >>>> > >>>> ^foundation > >>>> and > >>>> ^documents > >>>> > >>>> Thus the common root is ^ > >>>> > >>>> It looks like it may be necessary to have write access to the > >>>> top-level directory to allow the commit to succeed as a batch. > >>>> I doubt that would be granted, so it may be necessary to find a > >>>> different approach -- or move the documents? > >>>> > >>>> At present not even read-access is allowed at top-level. > >>>> If read access were sufficient, that might be allowed by Infra. > >>>> > >>>>> I don't want to step on any toes if anyone is still working on the > >>>>> error. > >>>>> > >>>>> Craig > >>>>> > >>>>>> On Jul 6, 2020, at 2:17 PM, Craig Russell <apache....@gmail.com> wrote: > >>>>>> > >>>>>> Hi Sebb, > >>>>>> > >>>>>> Thanks for that. Now there is a different problem with (Emeritus). See > >>>>>> else thread. > >>>>>> > >>>>>> Craig > >>>>>> > >>>>>>> On Jul 6, 2020, at 1:17 PM, sebb <seb...@gmail.com> wrote: > >>>>>>> > >>>>>>> On Mon, 6 Jul 2020 at 18:44, Craig Russell <apache....@gmail.com> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> I merged the roster-emeritus branch and tried out some of the new > >>>>>>>> features. > >>>>>>>> > >>>>>>>> 1. Request emeritus fails on line 70 of memstat.json.rb [1] > >>>>>>>> template, err = > >>>>>>>> ASF::SVN.svn('cat', EMERITUS_TEMPLATE_URL, {env:env}) > >>>>>>> > >>>>>>> AFAICT it must be env that is untainted, but not sure if so or where > >>>>>>> to fix this yet. > >>>>>>> > >>>>>>>> > >>>>>>>> 2. Move to emeritus status for a member with an outstanding request > >>>>>>>> fails on line 21 of memstat.json.rb [2] > >>>>>>>> ASF::SVN.multiUpdate_ members_txt, message, env, _ do |text| > >>>>>>> > >>>>>>> Should be fixed; whimsy4 is on an old Ruby which does not have > >>>>>>> URI::File > >>>>>>> > >>>>>>>> Any ideas? > >>>>>>>> > >>>>>>>> Craig > >>>>>>>> > >>>>>>>> [1] { > >>>>>>>> "exception": "#<SecurityError: Insecure operation - spawn>", > >>>>>>>> "backtrace": [ > >>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:199:in > >>>>>>>> `spawn'", > >>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:199:in > >>>>>>>> `popen_run'", > >>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:95:in > >>>>>>>> `popen3'", > >>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:258:in > >>>>>>>> `capture3'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/svn.rb:387:in `svn'", > >>>>>>>> "/x1/srv/whimsy/www/roster/views/actions/memstat.json.rb:70:in > >>>>>>>> `_evaluate'", > >>>>>>>> "/x1/srv/whimsy/www/roster/main.rb:204:in `block in <top > >>>>>>>> (required)>'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:223:in `call'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:48:in `call'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:200:in `call'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:254:in `call'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in > >>>>>>>> `process_request'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:157:in > >>>>>>>> `accept_and_process_next_request'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in > >>>>>>>> `main_loop'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in > >>>>>>>> `block (3 levels) in start_threads'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/utils.rb:113:in > >>>>>>>> `block in create_thread_and_abort_on_exception'" > >>>>>>>> ] > >>>>>>>> > >>>>>>>> [2] { > >>>>>>>> "exception": "#<NameError: uninitialized constant URI::File\nDid you > >>>>>>>> mean? File>", > >>>>>>>> "backtrace": [ > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/svn.rb:752:in `multiUpdate_'", > >>>>>>>> "/x1/srv/whimsy/www/roster/views/actions/memstat.json.rb:21:in > >>>>>>>> `_evaluate'", > >>>>>>>> "/x1/srv/whimsy/www/roster/main.rb:204:in `block in <top > >>>>>>>> (required)>'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:223:in `call'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:48:in `call'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:200:in `call'", > >>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:254:in `call'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in > >>>>>>>> `process_request'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:157:in > >>>>>>>> `accept_and_process_next_request'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in > >>>>>>>> `main_loop'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in > >>>>>>>> `block (3 levels) in start_threads'", > >>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/utils.rb:113:in > >>>>>>>> `block in create_thread_and_abort_on_exception'" > >>>>>>>> ] > >>>>>>>> } > >>>>>>>> } > >>>>>>>> Craig L Russell > >>>>>>>> c...@apache.org > >>>>>>>> > >>>>>> > >>>>>> Craig L Russell > >>>>>> c...@apache.org > >>>>>> > >>>>> > >>>>> Craig L Russell > >>>>> c...@apache.org > >>>>> > >>> > >>> Craig L Russell > >>> c...@apache.org > > Craig L Russell > c...@apache.org >
