On Tue, 7 Jul 2020 at 23:14, Sam Ruby <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
> >
