If that works, some other processing can also take advantage. For example at present CCLAs and ICLAs are filed separately from updating cclas.txt/iclas.txt
On Wed, 8 Jul 2020 at 01:04, Sam Ruby <ru...@intertwingly.net> wrote: > > 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 > >
