Ruby2JS 5.1, esbuild, and a Peek at the Future
FYI: https://www.ruby2js.com/updates/future-of-ruby2js/ In particular, note the link at the bottom for GitHub discussions. - Sam Ruby
Re: ldap "meta" ou
On Mon, Jun 13, 2022 at 1:06 PM Chris Lambertus wrote: > > > On Jun 12, 2022, at 4:54 PM, sebb wrote: > > > > If the problem is just that recreating ou=meta is messy, then there > > are other solutions. > > > > For example, it should not be too difficult to compare the lists and > > only update those which have changed. > > Probably can also speed this up by comparing last updated dates. > > > > It might also make sense to enhance Whimsy to update the ou=meta list > > at the same time as the owners. > > As Sam points out this would require that the karma needed must agree > > with the karma for owners. > > Yes, this whimsy enhancement is ultimately what my proposal is -- update > whimsy to maintain the pmc groups with instead of having a separate > drop/parse/create system as we do now. I am not sure what you mean by "karma > needed must agree" though. Are you referring to LDAP ACLs? if so, the policy > would already allow this if the ou is under ou=groups. I preface the following by stating that what I am about to say may be a result of my ignorance of LDAP configuration capabilities, but I believe the crux of the issue can be found on the following line: https://github.com/apache/infrastructure-p6/blob/d0e1160c2a5d0a7f6b9197893f126f80013f/modules/ldapserver/templates/slapd.conf.erb#L321 What that line says is that (in addition to root, secretary, pmc chairs, and the secretarial team) members of [P]PMCs can edit their own group. So, for example, PMC members (owners) can add/remove committers (members). Now for a thought experiment. If 'owner' is problematic for some tools, then what would an LDAP configuration look like with NO owners? What we would need is the ability to specify "members of groups in this subtree are authorized to write to CORRESPONDING groups in ANOTHER subtree". We have the ability to say that "members of THIS SPECIFIC group can write to THAT SPECIFIC group". And the ability to say "members of THIS SPECIFIC group can update that entire SUBTREE". But as far as I know (and this may very well be my ignorance), there is no way to grant corresponding members of one subtree update access to another subtree. > > This would minimise process changes as well as minimising LDAP updates. > > This is the goal. > > > In case there are Infra scripts that update owners it would make sense > > to keep a regular check on the consistency of the lists. > > Yes, I have been looking to see if there are any infra scripts which would > need to be updated, but I currently believe the only active tooling is within > whimsy. > > -Chris - Sam Ruby > > Sebb > > On Mon, 13 Jun 2022 at 00:32, Sam Ruby wrote: > >> > >> From a whimsy requirements perspective, the key requirement is that > >> PMC members can update LDAP the PMC (i.e., both the PMC and committers > >> lists). > >> > >> On Sun, Jun 12, 2022 at 6:56 PM sebb wrote: > >>> > >>> On Sun, 12 Jun 2022 at 21:26, Chris Lambertus wrote: > >>>> > >>>> > >>>> Hi folks, > >>>> > >>>> I have been working on some updates to the LDAP service, and I would > >>>> like to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the > >>>> process which manages it.) > >>>> > >>>> Some history -- this ou was created to address a problem which arose > >>>> after project groups were converted to member/owner (INFRA-16188). The > >>>> Atlassian Crowd service that feeds authentication and authorization for > >>>> Jira and Confluence does not understand the "owner" concept. > >>>> > >>>> Infra had previously created local roles in cwiki and jira, and > >>>> generally pushed maintenance of memberships of said roles to the project > >>>> owners defined within cwiki and jira. Over time this grew cumbersome, > >>>> and we elected to switch to LDAP-based groups, but we only had access > >>>> via Crowd to the attr=member version of the groups, so we could not > >>>> assign PMC-based roles. > >>>> > >>>> Because of this, I created a stop-gap process which drops and reloads > >>>> ou=meta nightly, populating > >>>> ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of > >>>> the PMC members. This process is awkward, and causes problems with the > >>>> LDAP audit logging system. > >>>> > >>>> I would like to gather feedback on re-creating and
Re: ldap "meta" ou
>From a whimsy requirements perspective, the key requirement is that PMC members can update LDAP the PMC (i.e., both the PMC and committers lists). On Sun, Jun 12, 2022 at 6:56 PM sebb wrote: > > On Sun, 12 Jun 2022 at 21:26, Chris Lambertus wrote: > > > > > > Hi folks, > > > > I have been working on some updates to the LDAP service, and I would like > > to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the process > > which manages it.) > > > > Some history -- this ou was created to address a problem which arose after > > project groups were converted to member/owner (INFRA-16188). The Atlassian > > Crowd service that feeds authentication and authorization for Jira and > > Confluence does not understand the "owner" concept. > > > > Infra had previously created local roles in cwiki and jira, and generally > > pushed maintenance of memberships of said roles to the project owners > > defined within cwiki and jira. Over time this grew cumbersome, and we > > elected to switch to LDAP-based groups, but we only had access via Crowd to > > the attr=member version of the groups, so we could not assign PMC-based > > roles. > > > > Because of this, I created a stop-gap process which drops and reloads > > ou=meta nightly, populating > > ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of the > > PMC members. This process is awkward, and causes problems with the LDAP > > audit logging system. > > > > I would like to gather feedback on re-creating and maintaining the ou=pmc > > tree in parallel with the owner/member paradigm that is now in place, > > specifically to support Crowd-based applications (which now also include > > JFrog/artifactory,) or other 3rd party tooling which may not understand > > member/owner. > > > > At this time, I believe the only ASF tooling which creates or modifies the > > owner attribute of project groups is Whimsy, so any code adjustments would > > likely have to happen here. > > AFAIK Whimsy is not the only place where accounts are created and PMC > memberships updated; there are likely some Infra scripts that do so. > > It's not clear to me whether the existing owner attributes will be kept or > not. > Indeed I'm not clear what the proposal is. > > > What are your thoughts? > > > > Thanks, > > Chris > > ASF Infra > > > >
Re: Whimsy (Status) https://whimsy.apache.org/status/ is up!
The issue appears to have been chrome. See attached. - Sam Ruby On Fri, May 13, 2022 at 3:13 PM NodePing Alert wrote: > > Host Whimsy (Status) : https://whimsy.apache.org/status/ is back up after 247 > minutes of downtime as of Fri May 13 2022 19:13:48 GMT+. > Public results : > https://nodeping.com/reports/checks/e7hdvmc4-5e85-41vr-8xho-t8rjxow9dipl > >
500 Internal Server Error
https://whimsy.apache.org/roster/committer/rubys What's weird is that I don't see anything show up in the the server logs. - Sam Ruby
Re: node.js does not (yet) support Ubuntu 22.04
On Tue, Apr 26, 2022 at 12:06 PM sebb wrote: > > Just discovered that node.js does not yet support Ubuntu 22.04, so no > point looking at that version for now: > > https://github.com/nodesource/distributions/ n and nvm can be used to install other versions. Example: FROM ubuntu:22.04 ENV DEBIAN_FRONTEND="noninteractive". RUN apt-get update RUN apt-get install -y nodejs npm curl RUN npm install -g n RUN which node && node -v RUN n 18 RUN which node && node -v CMD ["/bin/bash"] - Sam Ruby
Re: Warnings re: already initialized constants
On Tue, Apr 26, 2022 at 10:27 AM sebb wrote: > > On Tue, 26 Apr 2022 at 14:53, Sam Ruby wrote: > > > > On Tue, Apr 26, 2022 at 9:29 AM sebb wrote: > > > > > > There are a lot of older versions of Gems around - maybe time to do a > > > cleanup? > > > > It would take a bit of refactoring, but there is code in the Rakefile > > that might be useful. On my ubuntu machine, I need to prefix gem > > install commands with `sudo` and having `rake udpate` iterate through > > the gemfiles and prompting me many times grew old fast so I added a > > check to see if Bundler.bundle_path.writable? and if not I would build > > a single gemfile that collected up all the dependencies. Having a > > 'rake gem:clean' or equivalent task that would do this followed > > immediately by an update might be useful. The update is required as > > there are rare cases where different apps use different gems (until > > recently, active_support required an old version of tzinfo, for > > example). > > I don't think that is the case at present. True, but it won't always be the case. > I just did a cleanup on the Docker build, and a subsequent update did > not install anything. > > Is a separate task needed? > Why not just always do a cleanup just before an update? Routinely uninstalling a gem that is still needed (like was the case with the tzinfo gem) will likely cause user visible failures. > The update might then introduce new versions, but next time around > they should be cleaned up. > > > Of course, all this will be cleaned up when infra supports Ubuntu > > 22.04 and we move to whimsy-vm7. > > That will result in an initial cleanup, but versions will continue to > build up over time, so cleanup will still be needed. > > > - Sam Ruby - Sam Ruby
Re: Warnings re: already initialized constants
On Tue, Apr 26, 2022 at 9:29 AM sebb wrote: > > There are a lot of older versions of Gems around - maybe time to do a cleanup? It would take a bit of refactoring, but there is code in the Rakefile that might be useful. On my ubuntu machine, I need to prefix gem install commands with `sudo` and having `rake udpate` iterate through the gemfiles and prompting me many times grew old fast so I added a check to see if Bundler.bundle_path.writable? and if not I would build a single gemfile that collected up all the dependencies. Having a 'rake gem:clean' or equivalent task that would do this followed immediately by an update might be useful. The update is required as there are rare cases where different apps use different gems (until recently, active_support required an old version of tzinfo, for example). Of course, all this will be cleaned up when infra supports Ubuntu 22.04 and we move to whimsy-vm7. - Sam Ruby
Re: Warnings re: already initialized constants
On Tue, Apr 26, 2022 at 8:24 AM sebb wrote: > > For example: "warning: already initialized constant Net::ProtocRetryError" > > The following Ruby code generates the warning on Whimsy (and in my > Docker build): > > require 'net/http' > require 'net/smtp' > > The same happens if the require order is reversed. > > I wondered why the public json scripts only report the error sometimes. > Turns out that the script only requires 'net/smtp' (via require > 'mail') if there has been a change that needs to be mailed to the > list. > > Whilst the warning is harmless (I think), it can obscure other errors, > so I would like to fix it. > > It looks like removing the net-smtp Gem solves the issue. > When tested in Docker, this does not appear to affect the ability to > send emails, so I propose to make the change in Whimsy -- unless I > hear otherwise? If you remove the net-smtp gem from the Gemfile, the require will fail with ruby 3.1.2p20. Perhaps add "unless RUBY_VERSION =~ /^2/" to that line in the Gemfile? > Sebb - Sam Ruby
[jira] [Resolved] (WHIMSY-385) agenda unit tests don't work on node.js 15+
[ https://issues.apache.org/jira/browse/WHIMSY-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Ruby resolved WHIMSY-385. - Assignee: Sam Ruby Resolution: Fixed https://github.com/apache/whimsy/commit/3e4c18ba96b91e954ca4cf3a794ef1e64601b8df > agenda unit tests don't work on node.js 15+ > --- > > Key: WHIMSY-385 > URL: https://issues.apache.org/jira/browse/WHIMSY-385 > Project: Whimsy > Issue Type: Bug >Reporter: Sebb > Assignee: Sam Ruby >Priority: Major > > As the subject says: node.js has to be pegged at 14, or the agenda tests will > fail or hang. > AIUI there are API changes in 15 and 16. > However it may no be worth fixing this if the replacement agenda tool becomes > available soon -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: [whimsy] branch master updated: Only accessible from Secretary workbench now
Internal server error: https://whimsy.apache.org/roster/committer/sebb - Sam Ruby On Tue, Apr 5, 2022 at 4:39 PM wrote: > > This is an automated email from the ASF dual-hosted git repository. > > sebb pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/whimsy.git > > > The following commit(s) were added to refs/heads/master by this push: > new c0cd7a87 Only accessible from Secretary workbench now > c0cd7a87 is described below > > commit c0cd7a87a07679eb740860f2054ae91ba0a72298 > Author: Sebb > AuthorDate: Tue Apr 5 21:39:43 2022 +0100 > > Only accessible from Secretary workbench now > --- > repository.yml | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/repository.yml b/repository.yml > index 58412da0..0cbad2d8 100644 > --- a/repository.yml > +++ b/repository.yml > @@ -157,11 +157,6 @@ > url: asf/incubator/public/trunk/content/podlings > depth: files > > - member_apps: > -url: private/documents/member_apps > -depth: delete > -list: true > - >minutes: > url: asf/infrastructure/site/trunk/content/foundation/records/minutes > >
Re: Move from Travis to GitHub Actions
On Tue, Mar 29, 2022 at 12:57 PM sebb wrote: > > AFAICT the navigate test does not use the Vue server, so I assume the > problem must be somewhere in Capybara/Puma/Selenium. > > So it would be useful to enable some tracing for those. Agreed. Meanwhile, some random thoughts: 1) The hex address stack traceback shown in the current log is useless. 2) The error message that we do have implies some sort of server failure. 3) The test in question is a client test. No specific server functionality is being called for here beyond what is exercised in other tests. 4) The indication is that the error is occurring on a HTTP get request. Net: none of this makes sense. The test also passes for me on my laptop - other than hanging at the end as I have a newer version of node installed. On *THAT* topic, I don't presume that the underlying issue is an API change, but rather node not knowing when to quit. Essentially JS is an event driven language where you write code that waits for events. Programs exit only when node is sure that no possible future events can ever take place. Something in node's heuristics must have changed. This all works out much better - at least it is easier to reason about, if the client and server are written in the same language. But that doesn't seem meant to be - at least not here at the ASF. I guess my recommendation is to not enable that one test, and leave that problem to the infra team. - Sam Ruby > On Tue, 29 Mar 2022 at 16:05, sebb wrote: > > > > It looks as though chromedriver is working under GHA, as a test does > > work against apache.org. > > > > However as soon as the test script tries to check the content of an > > agenda page, it fails: > > > > https://github.com/apache/whimsy/runs/5739402171?check_suite_focus=true > > > > Any ideas? > > > > Sebb > > > > On Fri, 25 Mar 2022 at 23:46, sebb wrote: > > > > > > On Fri, 25 Mar 2022 at 23:35, sebb wrote: > > > > > > > > On Fri, 25 Mar 2022 at 23:13, Sam Ruby wrote: > > > > > > > > > > On Fri, Mar 25, 2022 at 7:02 PM sebb wrote: > > > > > > > > > > > > I have set up a couple of GH Actions to replace the Travis jobs. > > > > > > > > > > Excellent! > > > > > > > > > > > These seem to be working OK finally after a lot of false starts. > > > > > > > > > > > > Note that the screen navigation tests have to be skipped, as they > > > > > > were > > > > > > on Travis. > > > > > > This is because chromedriver crashes, which appears to be because GH > > > > > > runs headless. > > > > > > I've not been able to find out how to fix this, but at least the > > > > > > same > > > > > > set of tests now run under GH, so I have renamed the Travis file to > > > > > > switch it off. > > > > > > > > > > Have you tried > > > > > https://github.com/marketplace/actions/setup-chromedriver ? > > > > > > > > I have now. > > > > The software is already installed, so I just used the run commands, > > > > and that has solved the issue for Ubuntu, but the driver still crashes > > > > on macOS. > > > > It would probably be OK to skip the test on macOS if that cannot be > > > > solved. > > > > It's anyway an improvement on the previous setup. > > > > > > Unfortunately although the driver no longer crashes on Ubuntu, the > > > navigation test does not work. > > > > > > > Thanks! > > > > > > > > > > Sebb > > > > > > > > > > - Sam Ruby
Re: Move from Travis to GitHub Actions
On Fri, Mar 25, 2022 at 7:02 PM sebb wrote: > > I have set up a couple of GH Actions to replace the Travis jobs. Excellent! > These seem to be working OK finally after a lot of false starts. > > Note that the screen navigation tests have to be skipped, as they were > on Travis. > This is because chromedriver crashes, which appears to be because GH > runs headless. > I've not been able to find out how to fix this, but at least the same > set of tests now run under GH, so I have renamed the Travis file to > switch it off. Have you tried https://github.com/marketplace/actions/setup-chromedriver ? > Sebb - Sam Ruby
Re: [whimsy] branch master updated: No wonder Travis avoids chromedriver issues
I have to say that I've been watching this progress with a combination of admiration and amusement. :-) It is also pleasing to see that whether something you tried works or didn't work, you find out quickly, not hours later, like what sometimes happens with Travis. - Sam Ruby On Fri, Mar 25, 2022 at 8:17 AM wrote: > > This is an automated email from the ASF dual-hosted git repository. > > sebb pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/whimsy.git > > > The following commit(s) were added to refs/heads/master by this push: > new bbb3867 No wonder Travis avoids chromedriver issues > bbb3867 is described below > > commit bbb38673fcfb0c7bd8ca27f000d3b6c39423d68f > Author: Sebb > AuthorDate: Fri Mar 25 12:17:02 2022 + > > No wonder Travis avoids chromedriver issues > > [skip ci] > --- > www/board/agenda/spec/navigate_spec.rb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/www/board/agenda/spec/navigate_spec.rb > b/www/board/agenda/spec/navigate_spec.rb > index 783429b..9de520d 100644 > --- a/www/board/agenda/spec/navigate_spec.rb > +++ b/www/board/agenda/spec/navigate_spec.rb > @@ -7,6 +7,8 @@ require_relative 'spec_helper' > feature 'navigation', js: true do >it "should navigate to the Cocoon report and back" do > skip "headless browser test not run on Travis" if ENV['TRAVIS'] > +# Looks like chromedriver cannot cope for some reason > +skip "headless browser test not run under GitHub Actions" if > ENV['GITHUB_ACTIONS'] > > visit '/2015-02-18/Clerezza' > expect(page).to have_selector '.navbar-fixed-top.reviewed .navbar-brand',
Re: [jira] [Commented] (WHIMSY-383) root@ needs access to ICLAs
Short answer: SVN is master here. All that whimsy is doing is providing URL links to the ICLA in SVN. If Whimsy shows the link to a person who is not authorized, that person can click on the link, but svn will reject access. Example links for you to try: https://svn.apache.org/repos/private/documents/iclas/sam-ruby.pdf https://svn.apache.org/repos/private/documents/iclas/shane-curcuru.pdf - Sam Ruby On Tue, Mar 8, 2022 at 7:32 AM Shane Curcuru wrote: > > Sebb (Jira) wrote on 3/8/22 7:10 AM: > ... > > Sebb commented on WHIMSY-383: > > - > > > > Infra will need to update the SVN auth (pit-auth) as well. > > Whimsy cannot grant access that it does not have. > ... > > Is there any way this change - either in whimsy or by infra - could > result in other security issues? Sam's if statement seems OK, and > Secretary can already see ICLAs, but I'm wondering why/how infra would > need to change the svn auth as well. > > Question: how, is a user authorized in each step of this case? > > - User navigates to /roster/curcuru (or various other pages) > - httpd auths the user via LDAP (pretty simple & secure) > - roster app loads, and might use our model to also auth specific roles > (or _self_) of the user gotten from httpd to choose code paths to go down > - roster app tries to display my data, which means it goes into various > parts of the model(s) to possibly auth me again (in ruby) for specific > data from the model (like here; secretary + root bypass some things) > - roster app gets here, decides I'm OK, and then ALSO goes and reads my > icla file or membership file from svn > -- When it reads from svn, what user is it acting as? > - Anything else? > > I worry about two things: > - Code bugs in Whimsy, where our code grants the wrong people access > - Subtle bugs in Whimsy that could allow our applications access to > sensitive files because our tools have whimsysvn or whatever access to > SVN or other sources > > -- > - Shane >Apache Whimsy PMC >The Apache Software Foundation > > -- > - Shane >Member >The Apache Software Foundation
[jira] [Commented] (WHIMSY-383) root@ needs access to ICLAs
[ https://issues.apache.org/jira/browse/WHIMSY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502811#comment-17502811 ] Sam Ruby commented on WHIMSY-383: - I have no way to test it, but the following should do the trick: https://github.com/apache/whimsy/commit/6ac5277a7288df9cfb0dc73669f786bb2847bed3 > root@ needs access to ICLAs > --- > > Key: WHIMSY-383 > URL: https://issues.apache.org/jira/browse/WHIMSY-383 > Project: Whimsy > Issue Type: Improvement > Components: General >Reporter: Chris Lambertus >Priority: Minor > > People in the infrastructure-root LDAP group need to be able to view ICLAs > and Member forms for occasional identity verification and operational > requirements. We can already access these in svn, of course, but having them > available to us in Whimsy would be very convenient. -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Broken: apache/whimsy#3682 (master - a875f5a)
On Fri, Jan 14, 2022 at 10:43 AM sebb wrote: > On Fri, 14 Jan 2022 at 15:12, Sam Ruby wrote: > > > > On Fri, Jan 14, 2022 at 9:52 AM sebb wrote: > > > > > > On Fri, 14 Jan 2022 at 14:04, Sam Ruby wrote: > > > > > > > > On Fri, Jan 14, 2022 at 8:30 AM sebb wrote: > > > > > > > > > > I'm wondering whether we should pin major version numbers of Gems. > > > > > > > > > > Combined with a regular job to look for outdated Gems, > > > > > I think that would have given us advance warning. > > > > > > > > I gather that the gem in question that was updated was psych. We > > > > don't directly reference it in our Gemfile. > > > > > > It also affected yaml, but we don't seem to reference that either > > > > Yaml is part of the Ruby core runtime library. It does not provide a > > safe_load method. But all classes in Ruby are "open". > > > > Looking at Gemfile.lock for the board agenda tool, rdoc -- of all > > things -- pulls in psych. It specifies ">= 4.0.0". > > > > Here is the history for psych: https://rubygems.org/gems/psych > > > > > > There are two major strategies for dealing with dependencies: > > > > > > > > * The one we currently deploy aggressively pulls fixes, which has the > > > > benefit of being automatic, and ensures we are up to date > > > > (particularly with security fixes). > > > > > > But does it need to pull in changes to major versions? > > > Could we not pin the major versions but allow minor updates? > > > > It looks to me like this was released as a minor version. > > > > > > * The other is to check in Gemfile.lock files and only run in > > > > production what has been tested locally. This would request > > > > frequently updating Gemfile.lock files for each whimsy application > > > > locally and checking in the results. > > > > > > Is there any way to get advance notification of which gems have > updates? > > > And which have security implications? > > > That would be closer to the way that other ecosystems such as Java > work. > > > > > > Or at least if we had notification when there has been a change to a > > > major version of a Gem that would alert us to possible > > > incompatibilities. > > > > In summary, we are using an API that is not part of the documented > > interface for YAML, and might be considered "private" to psych. > > YAML says it is an alias for Psych, for which safe_load is documented: > > > https://ruby-doc.org/stdlib-2.5.9/libdoc/psych/rdoc/Psych.html#method-c-safe_load > > The above version is what we used originally > > It looks like it changed in > > https://ruby-doc.org/stdlib-2.6.1/libdoc/psych/rdoc/Psych.html#method-c-safe_load > Forgive me in advance for diving into semantics :-) >From the definition of Semantic Versioning (https://semver.org/), the difference between 2.5.9 and 2.6.1 is a minor version, and differences in minor versions are supposed to be backwards compatible. Obviously this failed here. I've been burned by this enough that I don't place absolute trust in these distinctions. Ruby and Node.js are examples where recent major versions didn't create major backwards compatibility issues. I've seen patch versions of gems take down whimsy applications. I'll repeat that it feels weird for us to start pinning versions of gems that aren't currently in our Gemfiles. I'll close with what an ideal situation would look like: * we check in Gemfile.lock files, and have our deployment do 'bundle install' instead of 'bundle update'. * we have a comprehensive test suite. * we have github actions that will update Gemfile.lock files upon successful execution of our tests. The end result is that we would automatically be kept up to date whenever a new version of any gem becomes available, as long as that change doesn't break something. And when there is breakage, we will be notified so that the problem can be addressed. - Sam Ruby > > It changed in a minor version in a way that broke our code. > > > > I don't know of any notification mechanism that would help with that > > combination. > > > > - Sam Ruby > > > > > > > > > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby > wrote: > > > > > > > > > > > > I was debugging the same thing, and came to the same > conclusion. By > > > > > > the way this affects the roster tool as well as the board agenda. > > > > > > > > > > > > - Sam Ruby > > > > > > > > > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb wrote: > > > > > > > > > > > > > > Looks like the API for YAML.safe_load has changed. It now > requires named > > > > > > > parameters. > > > > > > > > > > ... >
Re: Broken: apache/whimsy#3682 (master - a875f5a)
On Fri, Jan 14, 2022 at 9:52 AM sebb wrote: > > On Fri, 14 Jan 2022 at 14:04, Sam Ruby wrote: > > > > On Fri, Jan 14, 2022 at 8:30 AM sebb wrote: > > > > > > I'm wondering whether we should pin major version numbers of Gems. > > > > > > Combined with a regular job to look for outdated Gems, > > > I think that would have given us advance warning. > > > > I gather that the gem in question that was updated was psych. We > > don't directly reference it in our Gemfile. > > It also affected yaml, but we don't seem to reference that either Yaml is part of the Ruby core runtime library. It does not provide a safe_load method. But all classes in Ruby are "open". Looking at Gemfile.lock for the board agenda tool, rdoc -- of all things -- pulls in psych. It specifies ">= 4.0.0". Here is the history for psych: https://rubygems.org/gems/psych > > There are two major strategies for dealing with dependencies: > > > > * The one we currently deploy aggressively pulls fixes, which has the > > benefit of being automatic, and ensures we are up to date > > (particularly with security fixes). > > But does it need to pull in changes to major versions? > Could we not pin the major versions but allow minor updates? It looks to me like this was released as a minor version. > > * The other is to check in Gemfile.lock files and only run in > > production what has been tested locally. This would request > > frequently updating Gemfile.lock files for each whimsy application > > locally and checking in the results. > > Is there any way to get advance notification of which gems have updates? > And which have security implications? > That would be closer to the way that other ecosystems such as Java work. > > Or at least if we had notification when there has been a change to a > major version of a Gem that would alert us to possible > incompatibilities. In summary, we are using an API that is not part of the documented interface for YAML, and might be considered "private" to psych. It changed in a minor version in a way that broke our code. I don't know of any notification mechanism that would help with that combination. - Sam Ruby > > > > > On Fri, 14 Jan 2022 at 00:52, Sam Ruby wrote: > > > > > > > > I was debugging the same thing, and came to the same conclusion. By > > > > the way this affects the roster tool as well as the board agenda. > > > > > > > > - Sam Ruby > > > > > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb wrote: > > > > > > > > > > Looks like the API for YAML.safe_load has changed. It now requires > > > > > named > > > > > parameters. > > > > > > ...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
On Fri, Jan 14, 2022 at 8:30 AM sebb wrote: > > I'm wondering whether we should pin major version numbers of Gems. > > Combined with a regular job to look for outdated Gems, > I think that would have given us advance warning. I gather that the gem in question that was updated was psych. We don't directly reference it in our Gemfile. There are two major strategies for dealing with dependencies: * The one we currently deploy aggressively pulls fixes, which has the benefit of being automatic, and ensures we are up to date (particularly with security fixes). * The other is to check in Gemfile.lock files and only run in production what has been tested locally. This would request frequently updating Gemfile.lock files for each whimsy application locally and checking in the results. - Sam Ruby > On Fri, 14 Jan 2022 at 00:52, Sam Ruby wrote: > > > > I was debugging the same thing, and came to the same conclusion. By > > the way this affects the roster tool as well as the board agenda. > > > > - Sam Ruby > > > > On Thu, Jan 13, 2022 at 7:44 PM sebb wrote: > > > > > > Looks like the API for YAML.safe_load has changed. It now requires named > > > parameters. > > ...
Re: Broken: apache/whimsy#3682 (master - a875f5a)
I was debugging the same thing, and came to the same conclusion. By the way this affects the roster tool as well as the board agenda. - Sam Ruby On Thu, Jan 13, 2022 at 7:44 PM sebb wrote: > > Looks like the API for YAML.safe_load has changed. It now requires named > parameters. > > I think *YAML*.safe_load(data, [Symbol]) now needs to be > *YAML*.safe_load(data, > permitted_classes: [Symbol]) > > I have updated the code; hope it works ... > > On Fri, 14 Jan 2022 at 00:12, Travis CI wrote: > > > apache > > > > / > > > > whimsy > > > > <https://app.travis-ci.com/github/apache/whimsy?utm_medium=notification_source=email> > > > > [image: branch icon]master <https://github.com/apache/whimsy/tree/master> > > [image: build has failed] > > Build #3682 was broken > > <https://app.travis-ci.com/github/apache/whimsy/builds/244793181?utm_medium=notification_source=email> > > [image: arrow to build time] > > [image: clock icon]9 mins and 57 secs > > > > [image: Sebb avatar]Sebb > > a875f5a CHANGESET → > > <https://github.com/apache/whimsy/compare/ee186940be85...a875f5a8004f> > > > > Make it more obvious user must be moderator > > > > Want to know about upcoming build environment updates? > > > > Would you like to stay up-to-date with the upcoming Travis CI build > > environment updates? We set up a mailing list for you! > > SIGN UP HERE <http://eepurl.com/9OCsP> > > > > [image: book icon] > > > > Documentation <https://docs.travis-ci.com/> about Travis CI > > Have any questions? We're here to help. > > Unsubscribe > > <https://app.travis-ci.com/account/preferences/unsubscribe?repository=16807422_medium=notification_source=email> > > from build emails from the apache/whimsy repository. > > To unsubscribe from *all* build emails, please update your settings > > <https://app.travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email>. > > > > [image: black and white travis ci logo] <https://travis-ci.com> > > > > Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy > > Jacops | Contact: cont...@travis-ci.com | Amtsgericht Charlottenburg, > > Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: > > DE282002648 > >
Re: Remove vagrant code from default branch
On Fri, Dec 10, 2021 at 8:01 AM sebb wrote: > > The vagrant code has not been touched since 2016 (2014 if you discount > some generic changes). > > Seems little reason to keep it in the main branch. > > I propose to create a vagrant branch with the current code, and drop > it from the default branch. > > Any objections? No objections to removing it from the main branch. I don't see a reason to create a vagrant branch as if there ever is interest the code remains in the history, but if you are inclined to create it - again, no objections. > Sebb - Sam Ruby
[jira] [Resolved] (WHIMSY-373) Whimsy board agenda page error, won't display
[
https://issues.apache.org/jira/browse/WHIMSY-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Ruby resolved WHIMSY-373.
-
Resolution: Fixed
Regression in ruby2js:
https://github.com/ruby2js/ruby2js/commit/4d5f0b966b710b5408067c4d3096d30fbf10d443
> Whimsy board agenda page error, won't display
> -
>
> Key: WHIMSY-373
> URL: https://issues.apache.org/jira/browse/WHIMSY-373
> Project: Whimsy
> Issue Type: Bug
> Components: BoardAgenda
>Reporter: Sidney Markowitz
>Assignee: Sam Ruby
>Priority: Major
>
> When I am signed in to whimsy (I'm a PMC chair) going to URL
> [https://whimsy.apache.org/board/agenda/2021-12-15/]
> or going to
> [https://whimsy.apache.org/board/agenda/]
> which redirects to it, or reloading the page, flashes the following error
> trace and then displays a blank page. Tried it in both Chrome and Firefox.
> Running MacOS Monterey.
> {code:java}
> [stdin]:19
> Vue.config.errorHandler = (err, vm, info) => setTimeout(() => {throw err}, 0);
> ^
> TypeError: Cannot read property '0' of undefined
> at [stdin]:661:31
> at [stdin]:669:13
> at Proxy.render ([stdin]:692:7)
> at VueComponent.Vue._render ([stdin]:1:427633)
> at renderComponentInner ([stdin]:1:242829)
> at renderComponent ([stdin]:1:242112)
> at RenderContext.renderNode ([stdin]:1:240182)
> at RenderContext.next ([stdin]:1:157727)
> at cachedWrite ([stdin]:1:155403)
> at renderElement ([stdin]:1:244692)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (WHIMSY-373) Whimsy board agenda page error, won't display
[
https://issues.apache.org/jira/browse/WHIMSY-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Ruby reassigned WHIMSY-373:
---
Assignee: Sam Ruby
> Whimsy board agenda page error, won't display
> -
>
> Key: WHIMSY-373
> URL: https://issues.apache.org/jira/browse/WHIMSY-373
> Project: Whimsy
> Issue Type: Bug
> Components: BoardAgenda
>Reporter: Sidney Markowitz
>Assignee: Sam Ruby
>Priority: Major
>
> When I am signed in to whimsy (I'm a PMC chair) going to URL
> [https://whimsy.apache.org/board/agenda/2021-12-15/]
> or going to
> [https://whimsy.apache.org/board/agenda/]
> which redirects to it, or reloading the page, flashes the following error
> trace and then displays a blank page. Tried it in both Chrome and Firefox.
> Running MacOS Monterey.
> {code:java}
> [stdin]:19
> Vue.config.errorHandler = (err, vm, info) => setTimeout(() => {throw err}, 0);
> ^
> TypeError: Cannot read property '0' of undefined
> at [stdin]:661:31
> at [stdin]:669:13
> at Proxy.render ([stdin]:692:7)
> at VueComponent.Vue._render ([stdin]:1:427633)
> at renderComponentInner ([stdin]:1:242829)
> at renderComponent ([stdin]:1:242112)
> at RenderContext.renderNode ([stdin]:1:240182)
> at RenderContext.next ([stdin]:1:157727)
> at cachedWrite ([stdin]:1:155403)
> at renderElement ([stdin]:1:244692)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
Re: Is SafeTempFile really still needed?
On 11/3/2021 1:19 PM, sebb wrote: The comments state that the class was created to deal with a problem in Ruby 2.3.0 related to the use of the $SAFE variable. Whimsy no longer uses 2.3.0, and Ruby no longer uses the $SAFE variable, so can the class be dropped? Yes. Sebb - Sam Ruby
Re: [whimsy] branch master updated: resync config/whimsy.conf
I ran https://github.com/apache/whimsy/blob/master/tools/mkconf.rb,
which in turn executes:
ssh whimsy.apache.org cat /etc/apache2/sites-enabled/*-whimsy-vm-443.conf
patches welcome, either to infra-p6, or to the mkconf script :-)
- Sam Ruby
On Wed, Oct 13, 2021 at 6:47 AM sebb wrote:
>
> On Tue, 12 Oct 2021 at 23:51, wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rubys pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/whimsy.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new d3cd998 resync config/whimsy.conf
> > d3cd998 is described below
> >
> > commit d3cd998e133b164da6638fa3ab78aab6acf465e5
> > Author: Sam Ruby
> > AuthorDate: Tue Oct 12 18:51:03 2021 -0400
> >
> > resync config/whimsy.conf
> > ---
> > config/whimsy.conf | 95
> > +++---
> > tools/mkconf.rb| 2 +-
> > 2 files changed, 27 insertions(+), 70 deletions(-)
> >
> > diff --git a/config/whimsy.conf b/config/whimsy.conf
> > index a601cec..329473b 100644
> > --- a/config/whimsy.conf
> > +++ b/config/whimsy.conf
> > @@ -2,7 +2,7 @@
> > # Vhost template in module puppetlabs-apache
> > # Managed by Puppet
> > #
> > -
> > +#
> >
> >ServerName whimsy.local
> >
> > @@ -23,19 +23,15 @@
> >CustomLog "/var/log/apache2/whimsy_access.log" combined
> >
> >## Server aliases
> > - ## ServerAlias whimsy-test.apache.org
> > - ## ServerAlias whimsy4.apache.org
> > - ## ServerAlias whimsy-vm4.apache.org
> > + ## ServerAlias whimsy6.apache.org
> > + ## ServerAlias whimsy.apache.org
> >
> >## Custom fragment
> >
> > -SetEnv PATH /usr/local/bin:${PATH}
> > +## Needed? SetEnv PATH /usr/local/rvm/wrappers/ruby-2.7:${PATH}
> >
> > PassengerFriendlyErrorPages on
> >
> > -PassengerUser www-data
> > -PassengerGroup www-data
> > -
> > AddCharset UTF-8 .json
> >
> > ExpiresActive On
> > @@ -52,6 +48,10 @@ ExpiresActive On
> >
> >
> >
> > +
> > + Require all granted
> > +
> > +
> >
> >Header add Access-Control-Allow-Origin "*"
> >Options +Indexes
> > @@ -80,6 +80,7 @@ RedirectMatch permanent ^/officers/public_names
> > /secretary/public-names
> >
> > # redirect obsolete mailing list request form to replacement application
> > RedirectMatch permanent ^/officers/mlreq
> > https://selfserve.apache.org/mail.html
> > +
> > ProxyPass "/board/agenda/websocket/" "ws://localhost:34234/"
> >
> > # We now have local custom error pages
> > @@ -141,10 +142,9 @@ Alias /project/icla/
> > /srv/whimsy/www/project/icla/public
> >AuthType Basic
> >AuthName "ASF Committers"
> >AuthBasicProvider ldap
> > - AuthLDAPUrl "ldaps://ldap-us-ro.apache.org:636
> > ldap-eu-ro.apache.org:636/ou=people,dc=apache,dc=org?uid"
> > + AuthLDAPUrl "ldaps://
> > ldap-us-ro.apache.org:636/ou=people,dc=apache,dc=org?uid"
> >
>
> Why drop the eu host?
> Not all developers are US-located, even though the live server may be.
>
>
> >AuthLDAPGroupAttribute member
> >AuthLDAPGroupAttributeIsDN on
> > - AuthLDAPMaxSubGroupDepth 0
> >Require ldap-group cn=committers,ou=role,ou=groups,dc=apache,dc=org
> >
> >
> > @@ -152,10 +152,9 @@ Alias /project/icla/
> > /srv/whimsy/www/project/icla/public
> >AuthType Basic
> >AuthName "ASF Committers"
> >AuthBasicProvider ldap
> > - AuthLDAPUrl "ldaps://ldap-us-ro.apache.org:636
> > ldap-eu-ro.apache.org:636/ou=people,dc=apache,dc=org?uid"
> > + AuthLDAPUrl "ldaps://
> > ldap-us-ro.apache.org:636/ou=people,dc=apache,dc=org?uid"
> >AuthLDAPGroupAttribute member
> >AuthLDAPGroupAttributeIsDN on
> > - AuthLDAPMaxSubGroupDepth 0
> >
>
> Why drop this?
> It should speed up LDAP checks.
>
>
> >Require ldap-group cn=committers,ou=role,ou=groups,dc=apache,dc=org
> >
> >
> > @@ -163,10 +162,9 @@ Alias /project/icla/
> > /srv/whimsy/www/project/icla/public
> >AuthType Basic
> >AuthName "ASF Committers"
> >AuthBasicProvider ldap
> > - AuthLDAPUrl "ldaps://ldap-us-ro.apache.org:636
> > ldap-eu-ro.apache.org:
Re: svn commit: r1893287 - /infrastructure/site/trunk/content/foundation/board/calendar.mdtext
While there is long term benefits to working through the
authentication process for git (likely through gitbox not github), it
is possible for svn to serve content as text/html by setting
svn:mime-type.
So a short term fix would be to commit calendar.html to svn, change
the board agenda tool to update the html rather than the markdown, and
then update the site to (a) link to the calendar "overview" page in
svn rather than the current location, and (b) do either a
redirect/rewrite of the current location of the calendar overview page
to the new location in svn.
- Sam Ruby
On Tue, Sep 14, 2021 at 9:46 AM sebb wrote:
>
> On Tue, 14 Sept 2021 at 12:18, sebb wrote:
> >
> > The minutes are still stored in SVN.
> > It is only the calendar overview that is now in Git.
> >
> > So it is just a question of ensuring that the contents of
> >
> > https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/board/calendar.mdtext
> > are merged into
> > https://github.com/apache/www-site/blob/main/content/foundation/board/calendar.md
> >
> > Unfortunately the formats are not identical, so a simple copy won't do.
>
> I updated the Git version.
>
> Given that this is a monthly update at most, and the only change is to
> add a paragraph to the Git version, I'm not sure it's worth the effort
> implementing this in Whimsy.
> It's pretty easy to do it in GitHub by copying the data from the updated
> source.
>
> i.e. browse to
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/board/calendar.mdtext
>
> find the first "Board meeting minutes" header
>
> Select and copy the new paragraph.
>
> Paste into
> https://github.com/apache/www-site/edit/main/content/foundation/board/calendar.md
> after the first "Board meeting minutes" header (line 43 currently)
>
> Check and commit.
>
> Done.
>
> > On Tue, 14 Sept 2021 at 05:25, Greg Stein wrote:
> > >
> > > I don't know what the Whimsy community wants to do with their tool, but
> > > at some point in the future (plan is TBD), Infra will maintain a Board
> > > Agenda Tool. But we (infra) currently don't have plans to build that
> > > tool. And the existing tool cannot be maintained by Infra; some kind of
> > > rebuild/rewrite is necessary first. This is a known conundrum, with no
> > > solution found so far.
> > >
> > > In the meanwhile, I recommend the Secretary process be updated to include
> > > the copy of the minutes into www-site.
> > >
> > > Regards,
> > > Greg Stein
> > > Infrastructure Administrator, ASF
> > >
> > >
> > > On Mon, Sep 13, 2021 at 11:13 PM Matt Sicker wrote:
> > >>
> > >> Is anyone going to update the board agenda tool? Or do we need to pay
> > >> someone to maintain this?
> > >>
> > >> Matt Sicker
> > >>
> > >> > On Sep 12, 2021, at 15:14, Dave Fisher wrote:
> > >> >
> > >> > This change should be manually copied to www-site until whimsy can
> > >> > write to git.
> > >> >
> > >> > Sent from my iPhone
> > >> >
> > >> >> On Sep 12, 2021, at 1:05 PM, mattsic...@apache.org wrote:
> > >> >>
> > >> >> Author: mattsicker
> > >> >> Date: Sun Sep 12 20:05:17 2021
> > >> >> New Revision: 1893287
> > >> >>
> > >> >> URL: http://svn.apache.org/viewvc?rev=1893287=rev
> > >> >> Log:
> > >> >> Publish 16 June 2021 minutes
> > >> >>
> > >> >> Modified:
> > >> >> infrastructure/site/trunk/content/foundation/board/calendar.mdtext
> > >> >>
> > >> >> Modified:
> > >> >> infrastructure/site/trunk/content/foundation/board/calendar.mdtext
> > >> >> URL:
> > >> >> http://svn.apache.org/viewvc/infrastructure/site/trunk/content/foundation/board/calendar.mdtext?rev=1893287=1893286=1893287=diff
> > >> >> ==
> > >> >> ---
> > >> >> infrastructure/site/trunk/content/foundation/board/calendar.mdtext
> > >> >> (original)
> > >> >> +++
> > >> >> infrastructure/site/trunk/content/foundation/board/calendar.mdtext
> > >> >> Sun Sep 12 20:05:17 2021
> > >> >> @@ -59,6 +59,12 @@ as is an alternate [categorized view of
> > >> >>
> > >> >> # 2021 Board meeting minutes # {#2021}
> > >> >>
> > >> >> +- [16 June
> > >> >> 2021](../records/minutes/2021/board_minutes_2021_06_16.txt)
> > >> >> +* Terminate Sqoop
> > >> >> +* Terminate MetaModel
> > >> >> +* Change Mynewt Chair
> > >> >> +* Change Tez Chair
> > >> >> +
> > >> >> - [19 May 2021](../records/minutes/2021/board_minutes_2021_05_19.txt)
> > >> >>* Change Parquet Chair
> > >> >>* Change Geode Chair
> > >> >>
> > >> >>
> > >> >
Re: Ruby2JS 4.0.0+ creates syntax error for board/agenda/.. events.js.rb
Fixed, thanks!
I'll start a thread on board@ about dropping support for IE.
- Sam Ruby
On Sat, Aug 14, 2021 at 9:03 AM sebb wrote:
>
> Having unpinned Ruby2JS, I found that board/agenda no longer worked.
>
> This turned out to be due to Ruby2JS generating a syntax error for
> events,js.rb.
> This seems to have emerged in v4.0.0.
>
> The symptom is a line of the form:
>
> Events.broadcast(function(, ) {
>
> which is a syntax error.
>
> This is caused by the source line:
>
> Events.broadcast json.reporter.merge(type: :reporter)
>
> This error only seems to occur when eslevel: 5 is set.
>
> The Gemfile for board/agenda has been reverted to Ruby2JS v3.6.1 and
> the app now works.
>
> Sebb
Re: Rakefile restarts Passenger apps before updating Gems?
On Sat, Aug 7, 2021 at 7:34 PM sebb wrote: > > The 'rake update' command restarts Passenger apps that have changed > since the last update. > > It then goes on the update the Gems. ... and my touch restart.txt again. > That seems a bit odd: would it not be better to update the Gems first, > so any restarted apps pick up the new Gems? Gem install may take a while. Most of the time, no new gems are required. Put another way, with the current dual approach, changes that you push will be deployed quicker, and in the somewhat rare case that the deploy fails due to missing a dependency, things will straighten themselves out in minutes. > The task comment says: > '# update gems and restart applications as needed' > i.e. the reverse order And later you will find the following: # if new gems were istalled and this directory contains a passenger # application, restart it (and, yes, there is a typo in that comment) > Sebb - Sam Ruby
Re: Drop Gem packaging code for whimsy
On Sat, Aug 7, 2021 at 6:12 PM sebb wrote: > > On Sat, 7 Aug 2021 at 19:53, sebb wrote: > > > > On Sat, 7 Aug 2021 at 18:58, Sam Ruby wrote: > > > > > > On Sat, Aug 7, 2021 at 1:10 PM sebb wrote: > > > > > > > > On Sat, 7 Aug 2021 at 17:42, Sam Ruby wrote: > > > > > > > > > > On Sat, Aug 7, 2021 at 11:46 AM sebb wrote: > > > > > > > > > > > > On Sat, 7 Aug 2021 at 16:28, Sam Ruby > > > > > > wrote: > > > > > > > > > > > > > > The 'gem' lines with path values in Gemfiles are effectively a > > > > > > > way to > > > > > > > add another part of the source tree to the ruby lib path. > > > > > > > > > > > > But is the Gem packaging code still needed for Whimsy? > > > > > > > > > > Indeed, there is no need to package the gem. There may be a few rare > > > > > cases where it was useful for bootstrapping (setupmymac, docker), but > > > > > those can be addressed by other (and frankly better) ways. > > > > > > > > > > > I've created a branch to work on this. > > > > > > It mostly works, but it looks like some code which was previously > > > > > > pulled in by the Whimsy gem needs to be explicitly referenced. > > > > > > > > > > That's what the 'gem' lines with path values in Gemfiles do. Those > > > > > lines either need to be restored, or another way to achieve this needs > > > > > to be created. > > > > > > > > The lines I removed from the Gemfiles referred to the 'whimsy-asf' gem. > > > > Does that not need to exist? > > > > > > It does not need to exist as a published or installed gem. Take a > > > look at the Gemfile.lock file that is produced by bundle > > > install/update. > > > > > > > AFAICT the branch I created does work; it is only Travis that has > > > > problems. > > > > > > I'm not so sure about that. Anything that references bundler will > > > cause bundle to rewrite your ruby library path. You probably can get > > > CGis to avoid referencing bundler, but I doubt that you can get > > > passenger applications to do so. > > > > I already tried several Passenger apps, and they originally failed. > > But when I added the following to config.ru they worked: > > $LOAD_PATH.unshift '/srv/whimsy/lib' > > I also had to add a dependency on ruby-ldap to Gemfile. > > > > > > > And Travis probably does so too, by > > > default. > > > > > > It is probably best to continue with having all dependencies in the > > > Gemfile, including path references to the lib directory. > > > > However that seems that only works if asf.gemspec and asf.version are > > present. > > I was hoping to drop those two to avoid maintaining them. > > I have now got Travis to work. > It needed LOAD_PATH adjustments in a couple of places. > > I tried all the Passenger apps in a Docker build and they started OK. > I suppose it's possible that there may be one or two missing Gemfile > dependencies that were previously provided by transitive dependencies > of the Whimsy pseudo Gem, as was the case for ruby-ldap. Any such errors will likely be found quickly and produce reasonable diagnostics indicating what dependency needs to be added. +0 on merging whenever you feel ready. - Sam Ruby
Re: Is .ruby-version still needed?
On Sat, Aug 7, 2021 at 6:52 PM sebb wrote: > > On Sat, 7 Aug 2021 at 16:00, Matt Sicker wrote: > > > > I probably added those at one point when I had a bunch of ruby versions > > installed. I don’t think it’s needed anymore. > > OK I can delete the file, but what changes are needed to MACOS.md? Recommendation: delete the file, add .ruby-version to .git-ignore, and leave MACOS.md alone. Those that need it in the future, can create it, but there is no need to commit such files at this time. - Sam Ruby > > Matt Sicker > > > > > On Aug 7, 2021, at 08:22, sebb wrote: > > > > > > The file .ruby-version is mentioned in MACOS.md in relation to rbenv. > > > > > > However the contents are 2.4.1, having previously been 2.5.5. > > > Both seem seriously out of date, so it looks like the file is not needed. > > > > > > Sebb
Re: Drop Gem packaging code for whimsy
The 'gem' lines with path values in Gemfiles are effectively a way to add another part of the source tree to the ruby lib path. - Sam Ruby On Sat, Aug 7, 2021 at 8:43 AM sebb wrote: > > AFAICT it is not necessary for the whimsy library code to be packaged as a > Gem. > > However there is still some code relating to the packaging. > This may or may not still work. > > I think it would be best to drop the code to reduce the burden on > future maintainers. > > Sebb
Re: Testing secretary workbench
Perhaps at some point we should have a zoom call and you can share your screen and we can explore it together. Ping me on slack if this interests you. Meanwhile, did setupmymac complete successfully? Can you try the following command from the /srv/whimsy/www/secretary/workbench directory? $ bundle update If that doesn't work, you won't have the gems installed you need to run the workbench. --- Some background on the "auto update issue". Bundle update will update you to nokogiri 1.12.2 (which was recently updated to include nokogumbo) and no separate nokogumbo. Unfortunately, wunderbar version 1.4.5 still looks for nokogumbo and will fail if it isn't present. Solutions are to either pin nokogiri to 1.11 (NOT RECOMMENDED) or to update wunderbar to 1.5.0 (RECOMMENDED). This is the danger of doing bundle update to get the latest of most things, but selectively pinning other things. Eventually, you will get out of sync. There are two sane approaches to this problem: (1) have the server run bundle update, try to stay up to date, report and regressions promptly and see to it that the regressions are added to the test suite, or (2) have the server run bundle install, check in Gemfile.lock and don't allow any updates (including security updates!) until a whimsy developer runs bundle update on their machine and checks in the updated Gemfile.lock file. I prefer the first option as getting a bug report that "version n released yesterday introduced a regression" is much easier to debug than "some version released in the past n months introduced a regression". But honestly, either approach is preferable to the broken approach that whimsy had been using since late last year. - Sam Ruby On Wed, Aug 4, 2021 at 11:14 PM Craig Russell wrote: > > Still looking for some help here. The error reported from the completion of > setupmymac points to ruby2js strange error. Is this perhaps related to the > auto-update issue being discussed else-thread? > > Is there some reason that ruby2js must be === 3.6.0? > Raw Bundler exception > > Exception message: > > Could not find gem 'ruby2js (= 3.6.0)' in rubygems repository > https://rubygems.org/ or installed locally. > The source contains the following versions of 'ruby2js': 3.2.0, 4.1.4 > (Bundler::GemNotFound) > Any help will be rewarded in kind(ness). > Craig > > > On Aug 3, 2021, at 7:57 PM, Craig Russell wrote: > > > > I think Apple has indicated their intent to discontinue ruby as a > > system-provided tool. > > > > macOS Catalina 10.15 Release Notes > > Scripting Language Runtimes > > Deprecations > > Scripting language runtimes such as Python, Ruby, and Perl are included in > > macOS for compatibility with legacy software. Future versions of macOS > > won’t include scripting language runtimes by default, and might require you > > to install additional packages. If your software depends on scripting > > languages, it’s recommended that you bundle the runtime within the app. > > (49764202) > > > > > > > >> On Aug 3, 2021, at 3:25 PM, Sam Ruby >> <mailto:ru...@intertwingly.net>> wrote: > >> > >> On Tue, Aug 3, 2021 at 3:32 PM Craig Russell >> <mailto:apache@gmail.com>> wrote: > >>> > >>> [MacBook-Pro-10:~] clr% head -1 `which bundle` > >>> #!/usr/local/opt/ruby/bin/ruby > >>> [MacBook-Pro-10:~] clr% head -1 `which gem` > >>> #!/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby > >> > >> Unless you have a reason to want two versions of Ruby, I would > >> recommend that you stick with the system installed version. You > >> should be able to remove the non-system installed Ruby using: > >> > >> $ brew uninstall ruby > >> > >> Whether or not you want to do that (and whether or not removing it > >> works) Try to install/overwrite bundler: > >> > >> $ sudo gem install bundler > >> > >> If this works (i.e., the two commands at the top of this email > >> starting with "head -1" now return the same results), try rerunning > >> setupmymac. > > > > I'll try that. I guess if Apple ever does get rid of ruby I can easily > > reinstall it. > > > > Craig > >> > >> - Sam Ruby > > > > Craig L Russell > > c...@apache.org <mailto:c...@apache.org> > Craig L Russell > c...@apache.org >
-1 (was: Error starting web application secretary workbench)
New subject line for visibility; cc PMC chair On Wed, Aug 4, 2021 at 8:14 PM Sam Ruby wrote: > > What you have implemented is unwise, and I therefore am now giving my > -1 to that approach and am requesting that it be reverted. - Sam Ruby
Re: Error starting web application secretary workbench
On Wed, Aug 4, 2021 at 9:06 PM sebb wrote: > > On Thu, 5 Aug 2021 at 01:15, Sam Ruby wrote: > > > > On Wed, Aug 4, 2021 at 7:38 PM sebb wrote: > > > > > > On Thu, 5 Aug 2021 at 00:14, Sam Ruby wrote: > > > > > > > > It looks like sebb disabled security updates on wunderbar, which seems > > > > unwise. > > > > > > Updates were *not* disabled, but updates are no longer automatically > > > installed. > > > > > > This was done because one of the previous updates to Wunderbar broke > > > things. > > > > > > https://lists.apache.org/thread.html/r2d1a2e39bd92390e68efebc5bd53b4594271492468728c1ca45ab895%40%3Cdev.whimsical.apache.org%3E > > > > Once whimsy updated to Ruby 2.7, Ruby safety checks were no longer > > something that could be trusted, and wunderbar was updated to require > > an opt in to retain the old (insecure) behavior. > > > > The version of wunderbar had been pinned before that change, whimsy > > would have had a security issue. If there is a choice between > > availability (up time) and security, we need to prioritize security. > > > > What you have implemented is unwise, and I therefore am now giving my > > -1 to that approach and am requesting that it be reverted. > > Is it always wise to update to the most recent version of a Gem? > i.e. does a new release never have a new security issue? Should we turn off "apt-get update"? Meanwhile the secretary workbench is down, and I'm asking you to honor my -1. > Note that ruby2js is currently pinned - should that be unpinned also? It seems rather odd that you have picked exactly those two gems to pin. And yet any fix I personally make directly to whimsy gets deployed instantly. All other gems (and, for that matter, apt-get packages, and any direct software changes get updated and deployed automatically. Wunderbar has been feature complete (and therefore stable) for quite some time. Ruby2JS is quiet at the moment, but there has been significant development this past year. It is true that Ruby2JS had a regression which was detected on December 29, and promptly fixed on December 29. Since you decided to pin Ruby2JS and not update it for over seven months - what is your plan to upgrade to the latest version? - Sam Ruby
Re: Error starting web application secretary workbench
On Wed, Aug 4, 2021 at 7:38 PM sebb wrote: > > On Thu, 5 Aug 2021 at 00:14, Sam Ruby wrote: > > > > It looks like sebb disabled security updates on wunderbar, which seems > > unwise. > > Updates were *not* disabled, but updates are no longer automatically > installed. > > This was done because one of the previous updates to Wunderbar broke things. > > https://lists.apache.org/thread.html/r2d1a2e39bd92390e68efebc5bd53b4594271492468728c1ca45ab895%40%3Cdev.whimsical.apache.org%3E Once whimsy updated to Ruby 2.7, Ruby safety checks were no longer something that could be trusted, and wunderbar was updated to require an opt in to retain the old (insecure) behavior. The version of wunderbar had been pinned before that change, whimsy would have had a security issue. If there is a choice between availability (up time) and security, we need to prioritize security. What you have implemented is unwise, and I therefore am now giving my -1 to that approach and am requesting that it be reverted. - Sam Ruby > > https://github.com/apache/whimsy/blob/f95c56af00e57ee51582b9a74961983b6dc85e6a/www/secretary/workbench/Gemfile#L19 > > > > - Sam Ruby > > > > On Wed, Aug 4, 2021 at 5:24 PM Sam Ruby wrote: > > > > > > I pushed wunderbar 1.5.0 which should fix the problem. This will be > > > picked up the next time puppet runs. > > > > > > - Sam Ruby > > > > > > On Wed, Aug 4, 2021 at 2:00 PM Craig Russell wrote: > > > > > > > > Anyone else seeing this on > > > > https://whimsy.apache.org/secretary/workbench/ ? > > > > > > > > Error starting web application > > > > > > > > The Phusion Passenger application server tried to start the web > > > > application. But the application itself (and not Passenger) encountered > > > > an internal error. > > > > > > > > Error details: > > > > > > > > cannot load such file -- nokogumbo (LoadError) > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > > > `require' > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > > > `' > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in > > > > `require' > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in > > > > `' > > > > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `require' > > > > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in ` > > > (required)>' > > > > config.ru:1:in `require' > > > > config.ru:1:in `block in ' > > > > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > > > > `instance_eval' > > > > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > > > > `initialize' > > > > config.ru:1:in `new' > > > > config.ru:1:in `' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > > > > `eval' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > > > > `preload_app' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:189:in > > > > `block in ' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb:378:in > > > > `run_block_and_record_step_progress' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:188:in > > > > `' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:30:in > > > > `' > > > > > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:29:in > > > > `' > > > > The stdout/stderr output of the subprocess so far is: > > > > > > > > Error: The application encountered the following error: cannot load > > > > such file -- nokogumbo (LoadError) > > > > > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > > > `require' > > > > > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > > > `' > > > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in
Re: Error starting web application secretary workbench
It looks like sebb disabled security updates on wunderbar, which seems unwise. https://github.com/apache/whimsy/blob/f95c56af00e57ee51582b9a74961983b6dc85e6a/www/secretary/workbench/Gemfile#L19 - Sam Ruby On Wed, Aug 4, 2021 at 5:24 PM Sam Ruby wrote: > > I pushed wunderbar 1.5.0 which should fix the problem. This will be > picked up the next time puppet runs. > > - Sam Ruby > > On Wed, Aug 4, 2021 at 2:00 PM Craig Russell wrote: > > > > Anyone else seeing this on https://whimsy.apache.org/secretary/workbench/ ? > > > > Error starting web application > > > > The Phusion Passenger application server tried to start the web > > application. But the application itself (and not Passenger) encountered an > > internal error. > > > > Error details: > > > > cannot load such file -- nokogumbo (LoadError) > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > `require' > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > `' > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in > > `require' > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in ` > (required)>' > > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `require' > > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `' > > config.ru:1:in `require' > > config.ru:1:in `block in ' > > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > > `instance_eval' > > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > > `initialize' > > config.ru:1:in `new' > > config.ru:1:in `' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > > `eval' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > > `preload_app' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:189:in > > `block in ' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb:378:in > > `run_block_and_record_step_progress' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:188:in > > `' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:30:in > > `' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:29:in > > `' > > The stdout/stderr output of the subprocess so far is: > > > > Error: The application encountered the following error: cannot load such > > file -- nokogumbo (LoadError) > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > `require' > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > > `' > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in > > `require' > > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in > > `' > > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `require' > > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `' > > config.ru:1:in `require' > > config.ru:1:in `block in ' > > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > > `instance_eval' > > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > > `initialize' > > config.ru:1:in `new' > > config.ru:1:in `' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > > `eval' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > > `preload_app' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:189:in > > `block in ' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb:378:in > > `run_block_and_record_step_progress' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:188:in > > `' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:30:in > > `' > > > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:29:in > > `' > > This website is powered by Phusion Passenger®, the smart application server > > built by Phusion®. > > Craig L Russell > > c...@apache.org > >
Re: Error starting web application secretary workbench
I pushed wunderbar 1.5.0 which should fix the problem. This will be picked up the next time puppet runs. - Sam Ruby On Wed, Aug 4, 2021 at 2:00 PM Craig Russell wrote: > > Anyone else seeing this on https://whimsy.apache.org/secretary/workbench/ ? > > Error starting web application > > The Phusion Passenger application server tried to start the web application. > But the application itself (and not Passenger) encountered an internal error. > > Error details: > > cannot load such file -- nokogumbo (LoadError) > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > `require' > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in ` (required)>' > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in `require' > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in ` (required)>' > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `require' > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `' > config.ru:1:in `require' > config.ru:1:in `block in ' > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > `instance_eval' > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in `initialize' > config.ru:1:in `new' > config.ru:1:in `' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > `eval' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > `preload_app' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:189:in > `block in ' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb:378:in > `run_block_and_record_step_progress' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:188:in > `' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:30:in > `' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:29:in > `' > The stdout/stderr output of the subprocess so far is: > > Error: The application encountered the following error: cannot load such file > -- nokogumbo (LoadError) > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > `require' > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/render.rb:9:in > `' > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in > `require' > /var/lib/gems/2.7.0/gems/wunderbar-1.4.5/lib/wunderbar/vue.rb:1:in ` (required)>' > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `require' > /x1/srv/whimsy/www/secretary/workbench/server.rb:7:in `' > config.ru:1:in `require' > config.ru:1:in `block in ' > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > `instance_eval' > /var/lib/gems/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:125:in > `initialize' > config.ru:1:in `new' > config.ru:1:in `' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > `eval' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:101:in > `preload_app' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:189:in > `block in ' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/loader_shared_helpers.rb:378:in > `run_block_and_record_step_progress' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:188:in > `' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:30:in > `' > > /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/helper-scripts/rack-preloader.rb:29:in > `' > This website is powered by Phusion Passenger®, the smart application server > built by Phusion®. > Craig L Russell > c...@apache.org >
Re: Testing secretary workbench
On Tue, Aug 3, 2021 at 3:32 PM Craig Russell wrote: > > [MacBook-Pro-10:~] clr% head -1 `which bundle` > #!/usr/local/opt/ruby/bin/ruby > [MacBook-Pro-10:~] clr% head -1 `which gem` > #!/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby Unless you have a reason to want two versions of Ruby, I would recommend that you stick with the system installed version. You should be able to remove the non-system installed Ruby using: $ brew uninstall ruby Whether or not you want to do that (and whether or not removing it works) Try to install/overwrite bundler: $ sudo gem install bundler If this works (i.e., the two commands at the top of this email starting with "head -1" now return the same results), try rerunning setupmymac. - Sam Ruby
Re: Testing secretary workbench
On Mon, Aug 2, 2021 at 2:10 PM Roy T. Fielding wrote: > > On Aug 1, 2021, at 4:47 PM, Sam Ruby wrote: > > My experience is that reinstalling xcode-select is sometimes > > necessary, but solves the problem. Unfortunately, this hasn't worked > > for you. > > I had to do that recently as well in order to get brew upgrade to work for > some installs. > I think one of the recent macOS or Xcode patches messed up all of the > command-line > tools, or removed some dependency binaries from the systems, and the way to > fix it > was to re-run > >xcode-select --install > > on my old 2013 mbp running 10.15.7. > > Another potential issue is the version of ruby installed. The system ruby for > Catalina > is 2.6.3p62, whereas brew installs 3.0.2. Since Craig indicated that he was running 2.6.3p62, I was assuming that he is using system Ruby, but your comment sparked something for me: perhaps he has an inconsistent version of either bundle or gem. Craig, please try the following commands, and verify the results: % head -1 `which bundle` #!/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby % head -1 `which gem` #!/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby - Sam Ruby
Re: Testing secretary workbench
On Sun, Aug 1, 2021 at 5:18 PM sebb wrote: > > On Sun, 1 Aug 2021 at 21:34, Craig Russell wrote: > > > > So I had a very old checkout of whimsy in my /srv repository. I cloned a > > new copy and it started the server and opened a web page to whimsy.local. I > > went to secretary/workbench and now just have one small issue. I don't > > recall how I got wunderbar but maybe it's now installed in the wrong place? > > [2] > > > > And bundle update fails. [1] > > > > I really really do not want to upgrade my machine... > > In which case, Docker may be your friend. +1 Ruby is provided by MacOSX. ruby.h is provided by XCode's command line interface (xcode-select) json is one of the most common gems If your system can't install the json gem, it is unlikely that you will be able to run many Ruby applications, and certainly can't run whimsy. My experience is that reinstalling xcode-select is sometimes necessary, but solves the problem. Unfortunately, this hasn't worked for you. Alternatives include containers and VMs, and at the present time there only are up to date instructions for getting set up with Docker. - Sam Ruby P.S. I don't see these problems with node, which is NOT provided with Mac OSX. But a rewrite of the workbench application to another language is a non-trivial effort.
Re: Testing secretary workbench
On Fri, Jul 30, 2021 at 11:05 PM Craig Russell wrote: > > The setupmymac does run to completion with a bunch of errors but it starts > the server and opens a browser to whimsy.local. From there, I select > secretary workbench and it gives me six emails from 7/14/2020 to 7/17/2020. Try the following commands: cd /srv/whimsy/www/secretary/workbench rake fetch > I select one of the messages and it gives me the message processing page and > when I select category (icla) it gives me the icla screen. I know that this > is using very old code because the category has (0) incomplete form but none > of the checkboxes that indicate what is incomplete. > > So where it this code getting the icla.js.rb? /srv/whimsy/www/secretary/workbench//views/forms/icla.js.rb - Sam Ruby > > > > On Jul 30, 2021, at 6:06 PM, Sam Ruby wrote: > > > > While I am currently running 11.4, setupmymac was developed using > > prior versions of MacOSX. > > > > What does "xcode-select -p" return? > > > [MacBook-Pro-10:~/apache/foundation/officers] clr% xcode-select -p > /Library/Developer/CommandLineTools > > Craig > > > > If it returns something OTHER than "/Library/Developer/CommandLineTools", > > try: > > > > $ sudo xcode-select --switch /Library/Developer/CommandLineTools > > > > As to your question, if you do choose to upgrade, you will likely need > > to reinstall xcode-select again, and at that point things should work. > > Meanwhile, you are running a supported version of Ruby and bundler > > isn't all that backlevel and shouldn't be a problem. > > > > - Sam Ruby > > > > On Fri, Jul 30, 2021 at 8:57 PM Craig Russell wrote: > >> > >> I installed the command line tools but still the bundler is 2.1.4. > >> > >> So the problem is that whimsy doesn't work with Catalina 10.15.7 which I > >> admit is not the latest MacOSX? > >> > >> Before I upgrade my system, will this likely change anything? > >> > >> Thanks, > >> Craig > >> > >>> On Jul 30, 2021, at 5:48 PM, Craig Russell wrote: > >>> > >>> > >>> > >>>> On Jul 30, 2021, at 5:16 PM, Sam Ruby >>>> <mailto:ru...@intertwingly.net>> wrote: > >>>> > >>>> You don't need to do both setupmymac AND docker, so feel free to pick > >>>> which option works best for you. In the off chance you do wish to > >>>> continue to explore setupmymac, see my response interspersed below. > >>>> > >>>> On Fri, Jul 30, 2021 at 4:45 PM Craig Russell >>>> <mailto:apache@gmail.com>> wrote: > >>>>> > >>>>> [MacBook-Pro-10:~/apache/git/whimsy] clr% ruby -v > >>>>> ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19] > >>>>> [MacBook-Pro-10:~/apache/git/whimsy] clr% bundle -v > >>>>> Bundler version 2.1.4 > >>>> > >>>> That's a slightly old version of bundler. This is an indication that > >>>> you have an old version of the command line tools installed. > >>>> > >>>> [snip] > >>>> > >>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/include/ruby-2.6.0/ruby/ruby.h:24:10: > >>>>> fatal error: 'ruby/config.h' file not found > >>>>> #include "ruby/config.h" > >>>>>^~~ > >>>> > >>>> If you google this, you will see the recommendation to reinstall the > >>>> command line tools: > >>>> > >>>> $ sudo rm -rf /Library/Developer/CommandLineTools > >>>> $ xcode-select --install > >>>> > >>>> The progress indicator that you will see will likely fluctuate widely > >>>> from hours to minutes, but realistically this will take 15 minutes or > >>>> so. > >>>> > >>>> Once this completes, run setupmymac again. > >>> > >>> $ rake update > >>> Fetching gem metadata from https://rubygems.org/ > >>> <https://rubygems.org/>... > >>> Resolving dependencies... > >>> Using builder 3.2.4 > >>> Using bundler 2.1.4 > >>> Using concurrent-ruby 1.1.9 > >>> Fetching json 2.5.1 > >>> Installing json 2.5.1 with native extensions > >>> Gem::Ext::BuildError: ERROR: Failed to build g
Re: Testing secretary workbench
While I am currently running 11.4, setupmymac was developed using prior versions of MacOSX. What does "xcode-select -p" return? If it returns something OTHER than "/Library/Developer/CommandLineTools", try: $ sudo xcode-select --switch /Library/Developer/CommandLineTools As to your question, if you do choose to upgrade, you will likely need to reinstall xcode-select again, and at that point things should work. Meanwhile, you are running a supported version of Ruby and bundler isn't all that backlevel and shouldn't be a problem. - Sam Ruby On Fri, Jul 30, 2021 at 8:57 PM Craig Russell wrote: > > I installed the command line tools but still the bundler is 2.1.4. > > So the problem is that whimsy doesn't work with Catalina 10.15.7 which I > admit is not the latest MacOSX? > > Before I upgrade my system, will this likely change anything? > > Thanks, > Craig > > > On Jul 30, 2021, at 5:48 PM, Craig Russell wrote: > > > > > > > >> On Jul 30, 2021, at 5:16 PM, Sam Ruby >> <mailto:ru...@intertwingly.net>> wrote: > >> > >> You don't need to do both setupmymac AND docker, so feel free to pick > >> which option works best for you. In the off chance you do wish to > >> continue to explore setupmymac, see my response interspersed below. > >> > >> On Fri, Jul 30, 2021 at 4:45 PM Craig Russell >> <mailto:apache@gmail.com>> wrote: > >>> > >>> [MacBook-Pro-10:~/apache/git/whimsy] clr% ruby -v > >>> ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19] > >>> [MacBook-Pro-10:~/apache/git/whimsy] clr% bundle -v > >>> Bundler version 2.1.4 > >> > >> That's a slightly old version of bundler. This is an indication that > >> you have an old version of the command line tools installed. > >> > >> [snip] > >> > >>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/include/ruby-2.6.0/ruby/ruby.h:24:10: > >>> fatal error: 'ruby/config.h' file not found > >>> #include "ruby/config.h" > >>> ^~~ > >> > >> If you google this, you will see the recommendation to reinstall the > >> command line tools: > >> > >> $ sudo rm -rf /Library/Developer/CommandLineTools > >> $ xcode-select --install > >> > >> The progress indicator that you will see will likely fluctuate widely > >> from hours to minutes, but realistically this will take 15 minutes or > >> so. > >> > >> Once this completes, run setupmymac again. > > > > $ rake update > > Fetching gem metadata from https://rubygems.org/ > > <https://rubygems.org/>... > > Resolving dependencies... > > Using builder 3.2.4 > > Using bundler 2.1.4 > > Using concurrent-ruby 1.1.9 > > Fetching json 2.5.1 > > Installing json 2.5.1 with native extensions > > Gem::Ext::BuildError: ERROR: Failed to build gem native extension. > > > > current directory: > > /Users/clr/apache/git/whimsy/tools/vendor/bundle/ruby/2.6.0/gems/json-2.5.1/ext/json/ext/generator > > /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby -I > > /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0 > > -r ./siteconf20210730-35595-1461wtm.rb extconf.rb > > creating Makefile > > > > current directory: > > /Users/clr/apache/git/whimsy/tools/vendor/bundle/ruby/2.6.0/gems/json-2.5.1/ext/json/ext/generator > > make "DESTDIR=" clean > > > > current directory: > > /Users/clr/apache/git/whimsy/tools/vendor/bundle/ruby/2.6.0/gems/json-2.5.1/ext/json/ext/generator > > make "DESTDIR=" > > compiling generator.c > > In file included from generator.c:1: > > In file included from ./../fbuffer/fbuffer.h:5: > > In file included from > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/include/ruby-2.6.0/ruby.h:33: > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/include/ruby-2.6.0/ruby/ruby.h:24:10: > > fatal error: 'ruby/config.h' file not found > > #include "ruby/config.h" > > ^~~ > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/include/ruby-2.6.0/ruby/ruby.h:24:10: > > note: did not find header 'config.h' in framework 'ruby' (loaded from > > '/Library/Developer/CommandLineTools/SDKs/
Re: Testing secretary workbench
You don't need to do both setupmymac AND docker, so feel free to pick which option works best for you. In the off chance you do wish to continue to explore setupmymac, see my response interspersed below. On Fri, Jul 30, 2021 at 4:45 PM Craig Russell wrote: > > [MacBook-Pro-10:~/apache/git/whimsy] clr% ruby -v > ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19] > [MacBook-Pro-10:~/apache/git/whimsy] clr% bundle -v > Bundler version 2.1.4 That's a slightly old version of bundler. This is an indication that you have an old version of the command line tools installed. [snip] > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/include/ruby-2.6.0/ruby/ruby.h:24:10: > fatal error: 'ruby/config.h' file not found > #include "ruby/config.h" > ^~~ If you google this, you will see the recommendation to reinstall the command line tools: $ sudo rm -rf /Library/Developer/CommandLineTools $ xcode-select --install The progress indicator that you will see will likely fluctuate widely from hours to minutes, but realistically this will take 15 minutes or so. Once this completes, run setupmymac again. - Sam Ruby
Re: Testing secretary workbench
Can you try the following commands? ruby -v bundle -v bundle update - Sam Ruby P.S. The easiest way to get started is by either using setupmymac or a docker container. On Fri, Jul 30, 2021 at 1:03 PM Craig Russell wrote: > > I'm trying to set up the test environment for secretary workbench. > > [MacBook-Pro-10:~] clr% cd apache/git/whimsy/www/secretary/workbench/ > [MacBook-Pro-10:www/secretary/workbench] clr% rake fetch > rake aborted! > Command failed with status (127): [bundle update...] > /Users/clr/apache/git/whimsy/www/secretary/workbench/Rakefile:11:in `block in > ' > /Library/Ruby/Gems/2.6.0/gems/rake-13.0.1/exe/rake:27:in `' > Tasks: TOP => fetch => bundle => Gemfile.lock > (See full trace by running task with --trace) > [MacBook-Pro-10:www/secretary/workbench] clr% which rake > /usr/bin/rake > > Any ideas? > > Thanks, > Craig > > Craig L Russell > c...@apache.org >
Re: [whimsy] branch family-first updated: Fix obvious errors
On Sun, Jul 25, 2021 at 7:40 PM Craig Russell wrote: > > > On Jul 25, 2021, at 2:06 PM, sebb wrote: > > > > AFAICT the code cannot have been tested -- previously it did not even > > compile, and there was a missing method. > > You are completely correct. I made the decision not to invest the few hours > needed to set up the workbench (the notes in www/secretary/workbench/README > led me to believe that there was an hour of downloading stuff just to get > started). That definitely used to be the case, but Sebb trimmed this down considerably a while ago. In particular, one used to have a complete copy of all ICLAs, but that is no more. I don't know about how long it will take to download just what the workbench needs, but downloading everything every tool might need is less than 200MB these days. I just tried it here after erasing my /srv/svn directory, and was able to completely download everything in 71 seconds using the command "rake svn:update". This was across wifi with Spectrum, where my plan provides me 200Mb/second download speeds. - Sam Ruby
Re: [whimsy] branch master updated: LDAP-namecheck print header each 30 rows
Try (mismatches += 1). "++" is not an operator in Ruby, and is interpreted as +(+(mismatches)). - Sam Ruby On Mon, Jul 12, 2021 at 7:32 PM wrote: > > This is an automated email from the ASF dual-hosted git repository. > > clr pushed a commit to branch master > in repository https://gitbox.apache.org/repos/asf/whimsy.git > > > The following commit(s) were added to refs/heads/master by this push: > new cbf6fad LDAP-namecheck print header each 30 rows > cbf6fad is described below > > commit cbf6fadae3e85eefc09abe96593e1f6b3b8ff243 > Author: Craig L Russell > AuthorDate: Mon Jul 12 16:32:10 2021 -0700 > > LDAP-namecheck print header each 30 rows > --- > www/members/ldap-namecheck.cgi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/www/members/ldap-namecheck.cgi b/www/members/ldap-namecheck.cgi > index d6247ad..5b60a8e 100755 > --- a/www/members/ldap-namecheck.cgi > +++ b/www/members/ldap-namecheck.cgi > @@ -97,7 +97,7 @@ _html do > next >end > > - if ++mismatches % 30 == 0 # repeat header every 30 lines > + if 0 == ((++mismatches) % 30) # repeat header every 30 lines > _tr do >_td 'uid' >_td "iclas.txt public name"
[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly
[ https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376904#comment-17376904 ] Sam Ruby commented on WHIMSY-113: - > ssh whimsy apmail karma I've tried to avoid that, for firewall reasons. If the whimsy server ever got compromised, that would be bad. If hermes got compromised, that would be worse. > Have Secretary create new accounts directly > --- > > Key: WHIMSY-113 > URL: https://issues.apache.org/jira/browse/WHIMSY-113 > Project: Whimsy > Issue Type: New Feature > Components: SecMail >Reporter: Sam Ruby >Assignee: Sam Ruby >Priority: Major > > See also: https://issues.apache.org/jira/browse/INFRA-14456 > Currently most new account requests are made by the secretary, with the > remainder by PMC chairs and ASF members. These requests are made by whimsy > forms and result in a file created in svn that is processed, generally daily, > by infrastructure staff. > The new process envisioned is that the secretary will create new accounts > directly; and that new account requests will be sent via email to secretary@ > and processed by the secretary workbench. Generally, processing of such > requests should be at most a few mouse clicks, though an opportunity will be > provided to tweak such things a public names and to verify that a proper vote > link was provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly
[ https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376898#comment-17376898 ] Sam Ruby commented on WHIMSY-113: - > hermes creates the qmail forwarding files automatically, A while back, I created .qmail-__update_forward__, which will run /home/apmail/bin/generate-dotqmail-availid.py. The thought was that some whimsy tool (most likely the secretary workbench) could email _update_forward__,@apache.org which would create the qmail forwarding files semi-immediately rather than wait until the next time the cron job ran. > Have Secretary create new accounts directly > --- > > Key: WHIMSY-113 > URL: https://issues.apache.org/jira/browse/WHIMSY-113 > Project: Whimsy > Issue Type: New Feature > Components: SecMail >Reporter: Sam Ruby >Assignee: Sam Ruby >Priority: Major > > See also: https://issues.apache.org/jira/browse/INFRA-14456 > Currently most new account requests are made by the secretary, with the > remainder by PMC chairs and ASF members. These requests are made by whimsy > forms and result in a file created in svn that is processed, generally daily, > by infrastructure staff. > The new process envisioned is that the secretary will create new accounts > directly; and that new account requests will be sent via email to secretary@ > and processed by the secretary workbench. Generally, processing of such > requests should be at most a few mouse clicks, though an opportunity will be > provided to tweak such things a public names and to verify that a proper vote > link was provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Board agenda bug
On Mon, May 17, 2021 at 9:03 PM Craig Russell wrote: > > Hi, > > I changed my "comment name" for a jUDDI comment and after commit, 16 of the > approvals in the agenda are approved by "Craig, Russell". > > ! My suggestion would be to use your favorite text editor to change your "comment name" in the 16 approvals and one comment to a name that does not contain a space. But if you feel strongly that spaces should be allowed in such names, then the one line to change is here: https://github.com/apache/whimsy/blob/fde4fcaa1e83de80b4975f0832618c49f6489e0c/lib/whimsy/asf/agenda.rb#L65 > Craig L Russell > c...@apache.org - Sam Ruby
[jira] [Commented] (WHIMSY-362) Error while trying to publish draft minutes
[
https://issues.apache.org/jira/browse/WHIMSY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343622#comment-17343622
]
Sam Ruby commented on WHIMSY-362:
-
If the discussion item is added via the agenda tool, the dialog window already
prevents you from posting the item if the text is empty. Of course, this
doesn't stop people from adding discussion items via their favorite text
editor. Therefore, I've pushed a change to provide a warning if this ever
happens again:
[https://github.com/apache/whimsy/commit/ea0dbc46f47527c4032109507006837300a4]
Warnings cause the title bar to turn red, and display when you visit the item.
> Error while trying to publish draft minutes
> ---
>
> Key: WHIMSY-362
> URL: https://issues.apache.org/jira/browse/WHIMSY-362
> Project: Whimsy
> Issue Type: Task
> Components: BoardAgenda
>Reporter: Matt Sicker
>Priority: Blocker
>
> When I click the "Draft Minutes" button, the following stack trace pops up in
> an error dialog:
> {noformat}
> Exception
> #
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:26:in `mreplace'
> /x1/srv/whimsy/www/board/agenda/models/minutes.rb:116:in `block in draft'
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:32:in `block in mreplace'
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:28:in `each'
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:28:in `mreplace'
> /x1/srv/whimsy/www/board/agenda/models/minutes.rb:111:in `draft'
> /x1/srv/whimsy/www/board/agenda/routes.rb:512:in `block (3 levels) in (required)>'
> /x1/srv/whimsy/www/board/agenda/routes.rb:510:in `chdir'
> /x1/srv/whimsy/www/board/agenda/routes.rb:510:in `block (2 levels) in (required)>'
> /x1/srv/whimsy/www/board/agenda/routes.rb:509:in `block in '
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:222:in `call'
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:199:in `call'
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:253:in `call'
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:78:in `call'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:107:in
> `process_request'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:149:in
> `accept_and_process_next_request'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in
> `main_loop'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in
> `block (3 levels) in start_threads'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/utils.rb:113:in
> `block in create_thread_and_abort_on_exception'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WHIMSY-362) Error while trying to publish draft minutes
[
https://issues.apache.org/jira/browse/WHIMSY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343552#comment-17343552
]
Sam Ruby commented on WHIMSY-362:
-
Looks like the tool is attempting to copy the body of the following discussion
item from the agenda to the minutes, and not finding any text to copy:
[https://whimsy.apache.org/board/agenda/2021-04-21/Discussion-of-a-name-change]
At this point, the secretary should be able to go to that page, click on edit
item and add some text, and once that is done, proceed with publishing the
minutes.
> Error while trying to publish draft minutes
> ---
>
> Key: WHIMSY-362
> URL: https://issues.apache.org/jira/browse/WHIMSY-362
> Project: Whimsy
> Issue Type: Task
> Components: BoardAgenda
>Reporter: Matt Sicker
>Priority: Blocker
>
> When I click the "Draft Minutes" button, the following stack trace pops up in
> an error dialog:
> {noformat}
> Exception
> #
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:26:in `mreplace'
> /x1/srv/whimsy/www/board/agenda/models/minutes.rb:116:in `block in draft'
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:32:in `block in mreplace'
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:28:in `each'
> /x1/srv/whimsy/www/board/agenda/helpers/string.rb:28:in `mreplace'
> /x1/srv/whimsy/www/board/agenda/models/minutes.rb:111:in `draft'
> /x1/srv/whimsy/www/board/agenda/routes.rb:512:in `block (3 levels) in (required)>'
> /x1/srv/whimsy/www/board/agenda/routes.rb:510:in `chdir'
> /x1/srv/whimsy/www/board/agenda/routes.rb:510:in `block (2 levels) in (required)>'
> /x1/srv/whimsy/www/board/agenda/routes.rb:509:in `block in '
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:222:in `call'
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:199:in `call'
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:253:in `call'
> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:78:in `call'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:107:in
> `process_request'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:149:in
> `accept_and_process_next_request'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in
> `main_loop'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in
> `block (3 levels) in start_threads'
>
> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/utils.rb:113:in
> `block in create_thread_and_abort_on_exception'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: committers: r102110 - /committers/board/committee-info.txt
On Wed, Apr 21, 2021 at 7:25 PM sebb wrote: > > Which tools don't work? > > What errors were reported? The board agenda tool was unable to parse the proposed new chair name out of the River resolution. This was fixed by commit 102122. - Sam Ruby > On Wed, 21 Apr 2021 at 18:54, wrote: > > > > Author: fielding > > Date: Wed Apr 21 17:54:36 2021 > > New Revision: 102110 > > > > Log: > > temporarily restore peterfirmstone for the tools to work > > > > Modified: > > committers/board/committee-info.txt > > > > Modified: committers/board/committee-info.txt > > == > > --- committers/board/committee-info.txt [utf-8] (original) > > +++ committers/board/committee-info.txt [utf-8] Wed Apr 21 17:54:36 2021 > > @@ -226,7 +226,7 @@ Committees (PMCs): > > Ranger Selvamohan Neethiraj > > Ratis Tsz-wo Sze > > REEFSergiy Matusevych > > -River ASF Board > > +River Peter Firmstone > > RocketMQXiaorui Wang > > Roller Dave Johnson > > Royale Piotr Zarzycki > > @@ -4970,6 +4970,7 @@ NOTE: > > Jonathan Costers > > [2011-01-19] > > Jukka Zitting > > [2011-01-19] > > Patricia Shanahan > > [2011-01-19] > > +Peter Firmstone > > [2011-01-19] > > Robert Resendes > > [2011-01-19] > > > > > > > >
Re: Headline for board agenda web pages
On Mon, Apr 5, 2021 at 8:33 PM Craig Russell wrote: > > Hi Sam, > > > On Mar 15, 2021, at 2:15 PM, Sam Ruby wrote: > > > > On Mon, Mar 15, 2021 at 1:07 PM Craig Russell > <mailto:apache@gmail.com>> wrote: > >> > >> Hi, > >> > >> The title for the board agenda changes depending on which page is > >> currently being viewed. The "agenda home page" is currently "2021-03-17". > >> > >> The challenge for me (world's tiniest violin plays in back) is that my > >> browser orders the page list in the "Windows" dropdown. > >> > >> So if I'm in the middle of reviewing the President's report, the browser > >> thinks I'm viewing "President". Which means that if I want to return to > >> the agenda, I have to find the page last viewed. There is no longer a > >> "2021-03-17" page in the dropdown. > > > > If memory serves, that was done because you used to keep multiple open > > tabs, and having each tab say the current date wasn't helpful when you > > wanted to identify which one had a given report open. > > I've looked at the current behavior and it solves both problems. With Safari, > the titles show up as e.g. "2021-04-21 Board Chair", "2021-04-21 Treasurer", > "2021-04-21 Fundraising". Once I have many tabs open, the titles suddenly > change to remove the "2021-04-21" part of the title. > > And in the drop-down, the tab that is open shows the full title even though > the tab shows the abbreviated title. > > > > > >> I'd much prefer the title to not change from "2021-03-17". Or at least > >> have the title change to "2021-03-17/President". > > > > It sounds like we need a way for an individual to set a preference. > > But in Chrome, the tab title does not change regardless of how many tabs are > open. And with many tabs, the only part of the title that is visible is the > "2021-04-21" part. > > Firefox behaves like Chrome. > > I'm at a loss to explain why Safari seems to be smarter than the other > browsers ;-) , but the different behavior would argue in favor of a > preference. But I won't push for it because my browser of choice and the > current agenda tool behave exactly as I like. Cool. Armed with the knowledge that [1] is all it took to make that change possible, could I talk you into trying to make the corresponding change to the JavaScript version of the tool[2]? If you bring up the tool, pressing "D" will bring you to a developer page where you can find plenty of documentation and ways to explore live data. I recommend first going from there to the Documentation/Guides, and running through the brief React/Redux demo. Once you are done with that, return to the Developer Tools page, click on store, expand "Client" and observe the value of the meetingDate. This should give you enough background to enable you to add that bit of state to the props passed to the Header component, and to use that prop when updating the textContent of the title. Best of all, edit/compile/debug is reduced to edit/save/observe results as the browser window will automatically be updated automatically[3] as you save your changes. A test for this change can be added to src/client/layout/__tests__/header.js. You can run tests with the command "yarn test", and tests will also automatically be re-run as you save your changes. [1] https://github.com/apache/whimsy/commit/c277085198807f9a2aafae53daa6d8294af6e8b1 [2] https://github.com/rubys/whimsy-board-agenda-nodejs/ [3] https://github.com/rubys/whimsy-board-agenda-nodejs/blob/master/docs/overview/performance.md#reconciliation > Craig - Sam Ruby > >> If someone can point me to the place where this is done, I'm happy to try > >> to "fix" it. > > > > The code is here: > > https://github.com/apache/whimsy/blob/eebbc16bcc2c3d7ee4f39359d8be01d6357dbe04/www/board/agenda/views/layout/main.js.rb#L72 > > > > <https://github.com/apache/whimsy/blob/eebbc16bcc2c3d7ee4f39359d8be01d6357dbe04/www/board/agenda/views/layout/main.js.rb#L72> > > > >> Any other ideas? > > > > We probably need to tackle the idea of user preferences first. > > Initials are stored in a per-user yaml file today. That's probably > > the place to store the preference. What needs to be worked out is the > > UI. > > > >> Craig > >> > >> Craig L Russell > >> c...@apache.org <mailto:c...@apache.org> > > > > - Sam Ruby > > Craig L Russell > c...@apache.org >
Re: Headline for board agenda web pages
On Mon, Mar 15, 2021 at 1:07 PM Craig Russell wrote: > > Hi, > > The title for the board agenda changes depending on which page is currently > being viewed. The "agenda home page" is currently "2021-03-17". > > The challenge for me (world's tiniest violin plays in back) is that my > browser orders the page list in the "Windows" dropdown. > > So if I'm in the middle of reviewing the President's report, the browser > thinks I'm viewing "President". Which means that if I want to return to the > agenda, I have to find the page last viewed. There is no longer a > "2021-03-17" page in the dropdown. If memory serves, that was done because you used to keep multiple open tabs, and having each tab say the current date wasn't helpful when you wanted to identify which one had a given report open. > I'd much prefer the title to not change from "2021-03-17". Or at least have > the title change to "2021-03-17/President". It sounds like we need a way for an individual to set a preference. > If someone can point me to the place where this is done, I'm happy to try to > "fix" it. The code is here: https://github.com/apache/whimsy/blob/eebbc16bcc2c3d7ee4f39359d8be01d6357dbe04/www/board/agenda/views/layout/main.js.rb#L72 > Any other ideas? We probably need to tackle the idea of user preferences first. Initials are stored in a per-user yaml file today. That's probably the place to store the preference. What needs to be worked out is the UI. > Craig > > Craig L Russell > c...@apache.org - Sam Ruby
[jira] [Commented] (WHIMSY-348) Alter what proxies are listed, that are assigned to "you"
[ https://issues.apache.org/jira/browse/WHIMSY-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287538#comment-17287538 ] Sam Ruby commented on WHIMSY-348: - > I believe there is something upstream that Whimsy consumes, that produces > Meetings/*/member_proxy.txt. So this might not even be a bug against Whimsy > itself, in the long run. Correct. Process is documented here: [https://svn.apache.org/repos/private/foundation/Meetings/runbook.txt] The specific script that creates that file: [https://svn.apache.org/repos/private/foundation/Meetings/create-meeting.rb] The templates that script uses can be found here: [https://svn.apache.org/repos/private/foundation/Meetings/meeting-template] Fix member_proxy.txt.erb in that directory, and that will be the source used for the NEXT meeting. > Alter what proxies are listed, that are assigned to "you" > - > > Key: WHIMSY-348 > URL: https://issues.apache.org/jira/browse/WHIMSY-348 > Project: Whimsy > Issue Type: Wish > Environment: proxy.cgi >Reporter: Greg Stein >Priority: Minor > > The proxy form says that it remains in force for (3) years. > The template states "act on my behalf" for $Meeting. > Which is correct? If the former, then I think the "who you proxy for" should > list *all* proxy forms that fall within that 3 year period. ie. Whimsy would > look back at prior years, and include additional lines for the cut/paste > attendance call. > If the latter is correct, then we should eliminate the (3) years language, > IMO. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [jira] [Commented] (WHIMSY-348) Alter what proxies are listed, that are assigned to "you"
On Fri, Feb 19, 2021 at 11:58 PM Greg Stein (Jira) wrote: > > I believe there is something upstream that Whimsy consumes, that produces > Meetings/*/member_proxy.txt. So this might not even be a bug against Whimsy > itself, in the long run. Correct. Process is documented here: https://svn.apache.org/repos/private/foundation/Meetings/runbook.txt The specific script that creates that file: https://svn.apache.org/repos/private/foundation/Meetings/create-meeting.rb The templates that script uses can be found here: https://svn.apache.org/repos/private/foundation/Meetings/meeting-template Fix member_proxy.txt.erb in that directory, and that will be the source used for the NEXT meeting. - Sam Ruby
ruby2js and ruby2.7
First, a link to the line of code in question: https://github.com/apache/whimsy/blob/9b1bd40e277969936f7b8138efb70b0ef28416f6/www/roster/views/committers.html.rb#L28 Questions: is this still necessary, or is is moot given the direction to make ICLAs private? If necessary, can it be done via an @variable rather than backtics? --- Background. Prior to Ruby 2.7, with $SAFE and taint support, one could detect whether a given string contained unverified user input. Starting with Ruby 2.7, this became impossible. Ruby2JS has the ability to evaluate an arbitrary string in the host context, which could be very unsafe (consider "system rm -rf /"). I made a change to only allow this if a binding is specified as an option (not recommended, but possible). https://github.com/ruby2js/ruby2js/commit/704f1a5c20485414f1831938b0a4364a83fa1538 I did this only after scanning all of the whimsy .js.rb files. What I missed is that this was used in an html file with an embedded script. If this is still necessary, I would recommend it be done by evaluating a host instance variable (@ivar) rather than evaluating an arbitrary method call. --- Footnote: if you view source on https://whimsy.apache.org/roster/committee/whimsy and scroll to the bottom, you can see instance variables expanded (you will see, for example, auth with your id). If, however, you view source on https://whimsy.apache.org/roster/committer/, you will see icla path evaluated, but will not see that notinavail expanded (instead you will see this._notinavail, i.e., evaluation of an instance variable inside of a JavaScript class). I'm not sure yet what is going on here. - Sam Ruby
Re: Bug in secretary workbench -- additional ICLA when the first ICLA was signed with gpg
Perhaps whimsysvn should be given read access after all? At least temporarily until another approach can be implemented? https://lists.apache.org/thread.html/r5bfcd501e21a70ec7c6bebbf91995ef06c2a7e347afa9dbaed040b97%40%3Cprivacy.apache.org%3E - Sam Ruby On Mon, Dec 28, 2020 at 12:00 PM sebb wrote: > > Here is the error from the update job: > https://whimsy.apache.org/status/#svn-iclas > > On Mon, 28 Dec 2020 at 14:49, Craig Russell wrote: > > > > > > > > > On Dec 28, 2020, at 5:05 AM, sebb wrote: > > > > > > I think that is because the job that updates the cached list of icla > > > file names no longer has access to the SVN directory to be able to > > > list the file names. > > > > The error occurs after reading the existing ICLA names and details (from > > iclas.txt apparently) and creating the request to do the work. But when I > > asked to do the work of filing the new ICLA the error occurs. > > > > Craig > > > > > It might be possible to do away with the cache, and fetch the names on > > > demand. > > > > > > On Mon, 28 Dec 2020 at 04:41, Craig Russell wrote: > > >> > > >> This second ICLA for Kent Yao is still pending in the workbench. > > >> > > >> The second ICLA cannot be filed due to: > > >> > > >> # > > >> /x1/srv/whimsy/www/secretary/workbench/views/actions/icla2.json.rb:36:in > > >> `_evaluate' > > >> /x1/srv/whimsy/www/secretary/workbench/server.rb:121:in `block in > >> (required)>' > > >> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:222:in `call' > > >> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/rack/out_of_band_gc.rb:48:in > > >> `call' > > >> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:147:in `call' > > >> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:78:in `call' > > >> /x1/srv/whimsy/lib/whimsy/asf/rack.rb:253:in `call' > > >> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:107:in > > >> `process_request' > > >> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:157:in > > >> `accept_and_process_next_request' > > >> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in > > >> `main_loop' > > >> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in > > >> `block (3 levels) in start_threads' > > >> /var/lib/gems/2.7.0/gems/passenger-6.0.5/src/ruby_supportlib/phusion_passenger/utils.rb:113:in > > >> `block in create_thread_and_abort_on_exception' > > >> > > >> Craig L Russell > > >> Assistant Secretary, Apache Software Foundation > > >> c...@apache.org http://db.apache.org/jdo > > >> > > > > Craig L Russell > > c...@apache.org > >
agenda new is broken
Symptom: App 3560669 output: 2020-12-19 01:25:01 - NoMethodError - undefined method `utc_to_local_returns_utc_offset_times' for ActiveSupport:Module: App 3560669 output: /var/lib/gems/2.7.0/gems/activesupport-6.1.0/lib/active_support/values/time_zone.rb:514:in `block in utc_to_local' First the boring technical stuff. ActiveSupport is a part of the Rails project. It is huge, but it allows you to only pull in what you need. A new gem was pushed on the 8th of December: https://rubygems.org/gems/activesupport/versions/6.1.0 My current theory is that "pull in only what you need" is broken with this gem in that not everything needed is pulled in. One quick fix may be to pull in more than we theoretically need in order to get what we actually do, in fact, need. Now, for the longer range implications. There is a distinct possibility that I will not run again for the board once my term is up, and may go emeritus shortly thereafter. I've been saying this for a long while, but future boards will either need to develop a plan to support this tool, either that or migrate to something else because at some point the tool will break. - Sam Ruby
Re: [whimsy] 02/02: Try to fix Travis OSX failure
Most likely the issue is that svnmucc isn't (by default) installed on OS/X.
- Sam Ruby
On Mon, Nov 23, 2020 at 7:20 PM wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/whimsy.git
>
> commit ff518b1c73e493c833da478e0b3c3ce5229e58b7
> Author: Sebb
> AuthorDate: Tue Nov 24 00:20:16 2020 +
>
> Try to fix Travis OSX failure
> ---
> lib/whimsy/asf/svn.rb | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/lib/whimsy/asf/svn.rb b/lib/whimsy/asf/svn.rb
> index 4fd7ed0..82f521c 100644
> --- a/lib/whimsy/asf/svn.rb
> +++ b/lib/whimsy/asf/svn.rb
> @@ -697,6 +697,7 @@ module ASF
>temp = options[:tmpdir]
>tmpdir = temp ? temp : Dir.mktmpdir
>
> + rc = -1 # in case
>begin
> cmdfile = Tempfile.new('svnmucc_input', tmpdir)
> # add the commands
> @@ -739,18 +740,19 @@ module ASF
>_.system 'echo', [syscmd.flatten, sysopts.to_s]
> end
> if options[:dryrun]
> - _.system syscmd.insert(0, 'echo')
> + rc = _.system syscmd.insert(0, 'echo')
> else
>if _.instance_of?(Wunderbar::JsonBuilder) or
> _.instance_of?(Wunderbar::TextBuilder)
> -_.system syscmd, sysopts, sysopts # needs two hashes
> +rc = _.system syscmd, sysopts, sysopts # needs two hashes
>else
> -_.system syscmd, sysopts
> +rc = _.system syscmd, sysopts
>end
> end
>ensure
> File.delete cmdfile.path # always drop the command file
> FileUtils.rm_rf tmpdir unless temp
>end
> + rc
> end
>
> # DRAFT
>
Re: [whimsy] branch master updated: add back in super, explicitly passing in no block
On Mon, Nov 23, 2020 at 6:55 AM sebb wrote:
>
> Thanks for fixing that, I was about to try the same elimination
> exercise using my branch.
>
> The tests did not fail for me locally on macOS, which makes debugging harder.
They also did not fail for me locally on macOS, Ubuntu (either pure or
WSL2). Or on whimsy-vm6. Very weird, given that they failed
consistently on Travis. That got me curious, and I used your branch
as a starting point.
The problem also wasn't obvious via inspection (hence why I also did
it via an elimination exercise), but once found made sense: Hash.new
will take a block parameter.
- Sam Ruby
> On Mon, 23 Nov 2020 at 03:43, wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rubys pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/whimsy.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 55cc6ca add back in super, explicitly passing in no block
> > 55cc6ca is described below
> >
> > commit 55cc6cae9f60a907a301eefbe20134970e35f7a1
> > Author: Sam Ruby
> > AuthorDate: Sun Nov 22 22:43:22 2020 -0500
> >
> > add back in super, explicitly passing in no block
> > ---
> > lib/whimsy/asf/ldap.rb | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/whimsy/asf/ldap.rb b/lib/whimsy/asf/ldap.rb
> > index f25e41c..cac792a 100644
> > --- a/lib/whimsy/asf/ldap.rb
> > +++ b/lib/whimsy/asf/ldap.rb
> > @@ -530,6 +530,7 @@ module ASF
> >class LazyHash < Hash
> > # capture an initializer to be called only if necessary.
> > def initialize()
> > + super() {}
> >@initializer = initializer
> > end
> >
> >
Re: Hold on ugrading to Big Sur
False alarm. I didn't realize that a change had been made to whimsy.conf that broke mac users, and I first picked up this change when I tried upgrading to Big Sur. Details here: https://github.com/apache/whimsy/commit/b2fa8ec31a700d5772b40f6bd5ab007d8d3d97e3 - Sam Ruby On Sun, Nov 15, 2020 at 4:07 PM Sam Ruby wrote: > > I upgraded a macbook from macOS Catalina to Big Sur. > > This resulted in a number of messages that various gems needed to be > reinstalled --pristine. However, attempting to do so failed due to > permission errors, and attempting to reinstall the gems resulted in > errors due to headers not being found. > > Not wanting to deal with this mess, I wiped the hard drive and > reinstalled Big Sur. After doing so, setupmymac ran clean, and loaded > the whimsy.local landing page. > > The problem occurred when I navigated to the board agenda tool. It seems > that passenger applications run as 'nobody' rather than either the > configured passenger user or the owner of the config.ru file. To be > fair, Phusion Passenger indicates that Big Sur is not yet a supported > configuration. > > I've opened an issue: > > https://github.com/phusion/passenger/issues/2320 > > - Sam Ruby >
Hold on ugrading to Big Sur
I upgraded a macbook from macOS Catalina to Big Sur. This resulted in a number of messages that various gems needed to be reinstalled --pristine. However, attempting to do so failed due to permission errors, and attempting to reinstall the gems resulted in errors due to headers not being found. Not wanting to deal with this mess, I wiped the hard drive and reinstalled Big Sur. After doing so, setupmymac ran clean, and loaded the whimsy.local landing page. The problem occurred when I navigated to the board agenda tool. It seems that passenger applications run as 'nobody' rather than either the configured passenger user or the owner of the config.ru file. To be fair, Phusion Passenger indicates that Big Sur is not yet a supported configuration. I've opened an issue: https://github.com/phusion/passenger/issues/2320 - Sam Ruby
Re: Adding more website checks to Whismy?
On Fri, Nov 13, 2020 at 9:17 AM Christian Grobmeier wrote: > > Hello Whimsy developers, > > today I found this: > https://whimsy.apache.org/site/ > > Is it possible for me to add a few more checks? In example, I would like to > check if a site does contain Google Analytics, TagManager or Google Fonts. > There might be more to check. GA is a privacy related problem, so I thought > how I could check how many of our sites are using known, critical things like > GA. > > My question is, if you would be willing to accept code to perform those > checks and where would I add it? The following code performs the scan: https://github.com/apache/whimsy/blob/master/tools/site-scan.rb The results of the scan are placed here: https://whimsy.apache.org/public/site-scan.json The page you are referencing is produced by this script: https://github.com/apache/whimsy/blob/master/www/site.cgi That script delegates the production of the page to be displayed to https://github.com/apache/whimsy/blob/master/lib/whimsy/sitewebsite.rb > Kind regards, > Christian - Sam Ruby
Re: Broken link
On Tue, Oct 27, 2020 at 1:27 PM Andrew Wetmore wrote: > > Hi: > > On this page [1] there is a link that purports to go to "Infra reference > pages". Since that section no longer exists on the Infra wiki, the link is > broken. If you wanted to provide a general link to the services Infra > provides, this URL [2] might serve. > > Andrew > > [1] https://whimsy.apache.org/committers/tools > > [2] https://infra.apache.org/services.html Fixed, thanks! https://github.com/apache/whimsy/commit/e32b543fd5807325c6bea635b4b88d036ca2ae1c - Sam Ruby
Re: agenda websocket seems to be down
On Tue, Oct 6, 2020 at 4:53 PM Sam Ruby wrote: > > When the client > connected to the websocket process directly it made a lot of sense for > that process to implement SSL. Now that that is no longer the case, > it no longer is necessary. In fact, it no longer is necessary for the > websocket to be running as root, as that is only done to enable it to > access the certificates. Dropping the internal SSL connection enables browsers (including Firefox) to connect to the websocket again. - Sam Ruby
Re: [whimsy] branch master updated: wsc: support remote authentication
On Sat, Oct 24, 2020 at 7:00 PM sebb wrote:
>
> On Sat, 24 Oct 2020 at 19:40, wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rubys pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/whimsy.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new aa1bde1 wsc: support remote authentication
> > aa1bde1 is described below
> >
> > commit aa1bde1728cf4cbb490172fd2803a274f5fce9ff
> > Author: Sam Ruby
> > AuthorDate: Sat Oct 24 14:37:58 2020 -0400
> >
> > wsc: support remote authentication
> >
> > * Change to websocket-client-simple as it is actively maintained
>
> Huh?
>
> The change below replaces websocket-client-simple with
> websocket-eventmachine-client
Yup. commit message bad.
- Sam Ruby
> > * Enable the specification of the path to the websocket/session
> > * If not running locally, fetch session using HTTP basic auth
> > ---
> > www/board/agenda/Gemfile | 2 +-
> > www/board/agenda/daemon/wsc.rb | 98
> > --
> > www/board/agenda/main.rb | 2 -
> > 3 files changed, 66 insertions(+), 36 deletions(-)
> >
> > diff --git a/www/board/agenda/Gemfile b/www/board/agenda/Gemfile
> > index 83cfa0a..f39f3f8 100644
> > --- a/www/board/agenda/Gemfile
> > +++ b/www/board/agenda/Gemfile
> > @@ -25,7 +25,7 @@ gem 'erubis'
> > gem 'mustache'
> >
> > gem 'websocket-eventmachine-server'
> > -gem 'websocket-client-simple'
> > +gem 'websocket-eventmachine-client'
> > gem 'concurrent-ruby'
> >
> > gem 'rubyXL'
> > diff --git a/www/board/agenda/daemon/wsc.rb b/www/board/agenda/daemon/wsc.rb
> > index 5cda25a..c7f09b7 100644
> > --- a/www/board/agenda/daemon/wsc.rb
> > +++ b/www/board/agenda/daemon/wsc.rb
> > @@ -1,29 +1,27 @@
> > #!/usr/bin/env ruby
> >
> > +# Web socket client:
> > +# - securely connects and authenticates with the web socket
> > +# - outputs the messages received
> > +
> > $LOAD_PATH.unshift '/srv/whimsy/lib'
> >
> > -require 'websocket-client-simple'
> > +require 'websocket-eventmachine-client'
> > require 'optparse'
> > require 'ostruct'
> > require 'etc'
> > +require 'net/http'
> > +require 'json'
> >
> > require_relative './session'
> >
> > -# monkey patch for
> > https://github.com/shokai/websocket-client-simple/issues/24
> > -class WebSocket::Client::Simple::Client
> > - def sleep(*args)
> > -close
> > - end
> > -end
> > -
> >
> > # Parse argument list #
> >
> >
> > options = OpenStruct.new
> > -options.host = 'localhost'
> > -options.port = 34234
> > -options.protocol = 'ws'
> > +options.host = 'whimsy.local'
> > +options.path = '/board/agenda/websocket/'
> > options.user = Etc.getlogin
> > options.restart = false
> >
> > @@ -34,10 +32,14 @@ opt_parser = OptionParser.new do |opts|
> > options.host = host
> >end
> >
> > - opts.on "-p", "--port PORT", 'Port to connect to' do |port|
> > + opts.on "--port PORT", 'Port to connect to' do |port|
> > options.port = port
> >end
> >
> > + opts.on "--path PORT", 'Path to connect to' do |path|
> > +options.path = path
> > + end
> > +
> >opts.on "--secure", 'Use secure web sockets (wss)' do
> > options.protocol = 'wss'
> >end
> > @@ -53,38 +55,68 @@ end
> >
> > opt_parser.parse!(ARGV)
> >
> > +options.port ||= (options.host.include?('whimsy') ? 80 : 34234)
> > +options.protocol ||= (options.host.include?('local') ? 'ws' : 'wss')
> > +
> >
> > # Connect to WebSocket #
> >
> >
> > -url ="#{options.protocol}://#{options.host}:#{options.port}"
> > -ws = WebSocket::Client::Simple.connect url
> > +EM.run do
> > + url =
> > "#{options.protocol}://#{options.host}:#{options.port}#{options.path}"
> > + puts "coonnecting to #{url}..."
agenda websocket proxy not working on whimsy-vm6
I made some improvements to the websocket client test tool, and ran
some tests on whimsy-vm6. Based on the results below, it appears that:
1) The websocket service process is operating correctly on whimsy-vm6
2) The Apache httpd ssl proxy is hanging on whimsy-vm6
3) Both the service process and Apache httpd proxy are working on whimsy-vm4.
Full results below.
I believe that this is related to the problems people are seeing with
the board agenda tool, particularly on Firefox. It is not so much
that the functions people are trying to do require the websocket to
operate correctly, but perhaps the websocket is hanging in such a way
as to cause JavaScript or other network requests to hang.
- Sam Ruby
---
rubys@whimsy-vm6:~$ ruby /srv/whimsy/www/board/agenda/daemon/wsc.rb
--host localhost --path '/' --secure --noverify
coonnecting to wss://localhost:34234/...
{"id":"rubys","secret":"8ba123f1ec4fd66649bff7bb209d9a0a","mtime":"2020-10-24
19:20:07 +","type":"login"}
{"type":"arrive","user":"rubys","present":null,"timestamp":1603567257918.307}
{"type":"pending","private":"rubys","value":{"agenda":"board_agenda_2020_11_18.txt","initials":"rubys","approved":[],"unapproved":[],"flagged":[],"unflagged":[],"comments":{},"seen":{},"userid":"rubys","role":"director","username":"Sam
Ruby","firstname":"sam"}}
{"type":"pending","private":"rubys","value":{"agenda":"board_agenda_2020_11_18.txt","initials":"rubys","approved":["3A"],"unapproved":[],"flagged":[],"unflagged":[],"comments":{},"seen":{},"userid":"rubys","role":"director","username":"Sam
Ruby","firstname":"sam"}}
{"type":"pending","private":"rubys","value":{"agenda":"board_agenda_2020_11_18.txt","initials":"rubys","approved":[],"unapproved":[],"flagged":[],"unflagged":[],"comments":{},"seen":{},"userid":"rubys","role":"director","username":"Sam
Ruby","firstname":"sam"}}
^Cclosing: 1002
Traceback (most recent call last):
2: from /srv/whimsy/www/board/agenda/daemon/wsc.rb:71:in `'
1: from
/var/lib/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in
`run'
/var/lib/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in
`run_machine': Interrupt
rubys@whimsy-vm6:~$ ruby /srv/whimsy/www/board/agenda/daemon/wsc.rb
--host whimsy.apache.org
coonnecting to wss://whimsy.apache.org:443/board/agenda/websocket/...
^Cclosing: 1002
Traceback (most recent call last):
2: from /srv/whimsy/www/board/agenda/daemon/wsc.rb:71:in `'
1: from
/var/lib/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in
`run'
/var/lib/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in
`run_machine': Interrupt
rubys@whimsy-vm6:~$ ruby /srv/whimsy/www/board/agenda/daemon/wsc.rb
--host whimsy-vm4.apache.org
coonnecting to wss://whimsy-vm4.apache.org:443/board/agenda/websocket/...
password for rubys:
{"id":"rubys","secret":"1dfc3608ea11dbcc33047176ed7d8e4b","mtime":"2020-10-24
19:25:43 +","type":"login"}
{"type":"arrive","user":"rubys","present":null,"timestamp":1603567543075.5056}
---
Re: Board resolution for Shane
+1 - Sam Ruby On Thu, Oct 22, 2020 at 7:56 PM Craig Russell wrote: > > Here's the draft resolution for lazy consensus: > > WHEREAS, the Board of Directors heretofore appointed Sam Ruby (rubys) to the > office of Vice President, Apache Whimsy, and > > WHEREAS, the Board of Directors is in receipt of the resignation of Sam Ruby > from the office of Vice President, Apache Whimsy, and > > WHEREAS, the Project Management Committee of the Apache Whimsy project has > chosen by consensus to recommend Shane Curcuru (curcuru) as the successor to > the post; > > NOW, THEREFORE, BE IT RESOLVED, that Sam Ruby is relieved and discharged from > the duties and responsibilities of the office of Vice President, Apache > Whimsy, and > > BE IT FURTHER RESOLVED, that Shane Curcuru be and hereby is appointed to the > office of Vice President, Apache Whimsy, to serve in accordance with and > subject to the direction of the Board of Directors and the Bylaws of the > Foundation until death, resignation, retirement, removal or disqualification, > or until a successor is appointed. > > Craig L Russell > c...@apache.org >
Re: Why does Whimsy override apache::mod::ssl::ssl_protocol: ?
On Thu, Oct 22, 2020 at 9:21 AM sebb wrote: > > whimsy-vm*.yaml have: > apache::mod::ssl::ssl_protocol: ['all', '-SSLv2', '-SSLv3'] > > AFAICT this overrides the default, which is > > apache::mod::ssl::ssl_protocol: ['all', '-SSLv2', '-SSLv3', '-TLSv1', > '-TLSv1.1'] > > Is there a reason for the override? This change was made by the infrastructure team: https://github.com/apache/infrastructure-puppet/commit/b9b1a54e603eb9cd0a12a2ac782041bc06cf09d7 > S - Sam Ruby
Re: [whimsy] branch master updated: fix regression by avoiding broken versions of ruby2js
On Wed, Oct 7, 2020 at 6:56 PM sebb wrote:
>
> On Wed, 7 Oct 2020 at 18:57, wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rubys pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/whimsy.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 1800878 fix regression by avoiding broken versions of ruby2js
>
> Note that there are several other Gemfiles which reference 3.3.1 still.
> Also one which has no minimum version.
>
> Should those be fixed?
In some sense, it doesn't matter. Any commit will cause all of the
whimsy applications to be updated to the latest version of the ruby2js
gem.
- Sam Ruby
> > 1800878 is described below
> >
> > commit 1800878b2b1345c5ae02d2bd2c55289a05786cfe
> > Author: Sam Ruby
> > AuthorDate: Wed Oct 7 13:57:03 2020 -0400
> >
> > fix regression by avoiding broken versions of ruby2js
> > ---
> > www/board/agenda/Gemfile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/www/board/agenda/Gemfile b/www/board/agenda/Gemfile
> > index 08b47fb..83cfa0a 100644
> > --- a/www/board/agenda/Gemfile
> > +++ b/www/board/agenda/Gemfile
> > @@ -14,7 +14,7 @@ end
> > gem 'rake'
> > wunderbar_version =
> > File.read(File.expand_path("#{root}/wunderbar.version", __FILE__)).chomp
> > gem 'wunderbar', wunderbar_version
> > -gem 'ruby2js', '>=3.3.1'
> > +gem 'ruby2js', '>=3.3.6'
> > gem 'sinatra', '~> 2.0'
> > gem 'nokogumbo'
> > gem 'execjs'
> >
Re: agenda websocket seems to be down
On Tue, Oct 6, 2020 at 1:10 PM Roy T. Fielding wrote: > > > On Oct 6, 2020, at 4:31 AM, sebb wrote: > > > > Apart from a lack of console messages, how can one check if the socket > > is working properly? > > Maybe try something that fills in a form, like sending reminders. > You can cancel it after the form is filled, but the filling > seems to be done via websocket. I don't know if we are logging > the requests received via a websocket. > > I was able to send out the reminders on Monday, so your fix > worked for me. Random, disjointed thoughts, in no particular order. 1) The only use of websockets by the board agenda application is for asynchronous, one-way messages from the server to the client, generally to provide updates to data that the client already has a stale version of. It would surprise me if being unable to obtain a websocket connection would affect forms in any way other than in the staleness of the content. (Note: I'm saying "it would surprise me", not that it can't happen. I'm often surprised). 2) The problems to date could all have been detected by simply attempting to open a websocket connection, nothing more is needed. If the socket can't be opened, it clearly is a problem. Down the road, it may be worth exploring additional tests, but this single test could be a good place to start. 3) Prior to websockets, I tried both eventsource and websockets hosted by the Apache webserver itself. Both lead to lock ups and even to crashing the VM due to out-of-memory errors. When I moved the websocket to a separate process and port, things worked better. Eventually the infra team firewalled that port, and I had the Apache webserver forward the requests to the process. When the client connected to the websocket process directly it made a lot of sense for that process to implement SSL. Now that that is no longer the case, it no longer is necessary. In fact, it no longer is necessary for the websocket to be running as root, as that is only done to enable it to access the certificates. > Roy - Sam Ruby > > On Mon, 5 Oct 2020 at 17:08, sebb wrote: > >> > >> As you suspected, the failure was: > >> Cert does not match for name 'localhost' > >> > >> This fixes it, but may not be the best solution: > >> SSLProxyCheckPeerName off > >
Re: agenda websocket seems to be down
This is unrelated to the problem I was seeing (the websocket server was failing). The message in the error log: [Sat Oct 03 13:52:54.956298 2020] [proxy:error] [pid 1042:tid 140478557177600] [client 71.204.185.91:59703] AH00898: Error during SSL Handshake with remote server returned by /board/agenda/websocket/ The relevant portion of the Apache configuration: SSLProxyEngine On ProxyPass "/board/agenda/websocket/" "wss://localhost:34234/" So it looks like the Apache web server is trying to create a SSL connection to a localhost websocket, and isn't happy about something, most likely the certificate as it isn't possible to create a certificate for localhost. But whimsy-vm4 is set up the same way, and works. Not sure what the difference is, perhaps the newer libraries are actually checking the certificate now, or perhaps the base puppet configuration is different. The following seems to have some suggestions worth exploring: https://serverfault.com/questions/538086/proxyerror-ah00898-error-during-ssl-handshake-with-remote-server - Sam Ruby P.S. It does seem odd that the whimsy_error.log is empty and the errors are going to whimsy_error.log.1. On Fri, Oct 2, 2020 at 2:43 PM Roy T. Fielding wrote: > > I was going to send out reminders under "missing" but the agenda > won't fill the email form after clicking on "send initial reminders". > > My web console shows 500 errors every few minutes > > GET wss://whimsy.apache.org/board/agenda/websocket/[HTTP/1.1 500 Internal > Server Error 763ms] > > GET > wss://whimsy.apache.org/board/agenda/websocket/ > Status > 500 > Internal Server Error > VersionHTTP/1.1 > Transferred253 B (0 B size) > Accept-Ranges > bytes > Connection > close > Content-Length > 5220 > Content-Type > text/html > Date > Fri, 02 Oct 2020 18:37:16 GMT > > I would guess this is the issue that Sam talked about earlier, > but I thought it was fixed already. > > Er, looks like the error logs just rotated. Is some work being done? > > Roy >
Re: [whimsy] branch master updated: Try to fix Travis failures
It might also be a good idea to revisit the ruby version(s) tested
with Travis...
- Sam Ruby
On Thu, Oct 1, 2020 at 7:46 PM sebb wrote:
>
> Ah, I have:
>
> $ node -v
> v14.8.0
>
> which probably explains why I was not seeing any errors.
>
> On Fri, 2 Oct 2020 at 00:36, Sam Ruby wrote:
> >
> > The following line fails with node 7 but works with node 8+:
> >
> > let private_lines = /^([
> > \t]*private(?:\n|.)*?\/private)(\s*)$/migs;
> >
> > I've fixed .travis.yml.
> >
> > - Sam Ruby
> >
> > On Thu, Oct 1, 2020 at 7:16 PM wrote:
> > >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > sebb pushed a commit to branch master
> > > in repository https://gitbox.apache.org/repos/asf/whimsy.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > > new 315cdc2 Try to fix Travis failures
> > > 315cdc2 is described below
> > >
> > > commit 315cdc29eea87a6016b440108a308037667d17ae
> > > Author: Sebb
> > > AuthorDate: Fri Oct 2 00:16:27 2020 +0100
> > >
> > > Try to fix Travis failures
> > >
> > > Revert to 3.2.0 as was used until Sep 30
> > > ---
> > > www/board/agenda/Gemfile| 2 +-
> > > www/roster/Gemfile | 2 +-
> > > www/secretary/Gemfile | 2 +-
> > > www/secretary/workbench/Gemfile | 2 +-
> > > 4 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/www/board/agenda/Gemfile b/www/board/agenda/Gemfile
> > > index 2e79924..f838780 100644
> > > --- a/www/board/agenda/Gemfile
> > > +++ b/www/board/agenda/Gemfile
> > > @@ -14,7 +14,7 @@ end
> > > gem 'rake'
> > > wunderbar_version =
> > > File.read(File.expand_path("#{root}/wunderbar.version", __FILE__)).chomp
> > > gem 'wunderbar', wunderbar_version
> > > -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> > > +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> > > gem 'sinatra', '~> 2.0'
> > > gem 'nokogumbo'
> > > gem 'execjs'
> > > diff --git a/www/roster/Gemfile b/www/roster/Gemfile
> > > index e959e1c..b95b313 100644
> > > --- a/www/roster/Gemfile
> > > +++ b/www/roster/Gemfile
> > > @@ -15,7 +15,7 @@ end
> > > gem 'rake'
> > > wunderbar_version =
> > > File.read(File.expand_path("#{root}/wunderbar.version", __FILE__)).chomp
> > > gem 'wunderbar', wunderbar_version
> > > -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> > > +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> > > gem 'sinatra', '~> 2.0'
> > > gem 'nokogumbo'
> > > gem 'mail'
> > > diff --git a/www/secretary/Gemfile b/www/secretary/Gemfile
> > > index 5b0423e..02a77e0 100644
> > > --- a/www/secretary/Gemfile
> > > +++ b/www/secretary/Gemfile
> > > @@ -8,7 +8,7 @@ if File.exist? version_file
> > >gem 'whimsy-asf', asf_version, path: File.expand_path(root, __FILE__)
> > > end
> > >
> > > -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> > > +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> > > wunderbar_version =
> > > File.read(File.expand_path("#{root}/wunderbar.version", __FILE__)).chomp
> > > gem 'wunderbar', wunderbar_version
> > > gem 'mail'
> > > diff --git a/www/secretary/workbench/Gemfile
> > > b/www/secretary/workbench/Gemfile
> > > index 4c68f8a..5e01e30 100644
> > > --- a/www/secretary/workbench/Gemfile
> > > +++ b/www/secretary/workbench/Gemfile
> > > @@ -18,7 +18,7 @@ gem 'sinatra', '~> 2.0'
> > > gem 'sanitize'
> > > wunderbar_version =
> > > File.read(File.expand_path("#{root}/wunderbar.version", __FILE__)).chomp
> > > gem 'wunderbar', wunderbar_version
> > > -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> > > +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> > > gem 'execjs'
> > > gem 'listen'
> > > gem 'escape'
> > >
Re: [whimsy] branch master updated: Try to fix Travis failures
The following line fails with node 7 but works with node 8+:
let private_lines = /^([
\t]*private(?:\n|.)*?\/private)(\s*)$/migs;
I've fixed .travis.yml.
- Sam Ruby
On Thu, Oct 1, 2020 at 7:16 PM wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/whimsy.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 315cdc2 Try to fix Travis failures
> 315cdc2 is described below
>
> commit 315cdc29eea87a6016b440108a308037667d17ae
> Author: Sebb
> AuthorDate: Fri Oct 2 00:16:27 2020 +0100
>
> Try to fix Travis failures
>
> Revert to 3.2.0 as was used until Sep 30
> ---
> www/board/agenda/Gemfile| 2 +-
> www/roster/Gemfile | 2 +-
> www/secretary/Gemfile | 2 +-
> www/secretary/workbench/Gemfile | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/www/board/agenda/Gemfile b/www/board/agenda/Gemfile
> index 2e79924..f838780 100644
> --- a/www/board/agenda/Gemfile
> +++ b/www/board/agenda/Gemfile
> @@ -14,7 +14,7 @@ end
> gem 'rake'
> wunderbar_version = File.read(File.expand_path("#{root}/wunderbar.version",
> __FILE__)).chomp
> gem 'wunderbar', wunderbar_version
> -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> gem 'sinatra', '~> 2.0'
> gem 'nokogumbo'
> gem 'execjs'
> diff --git a/www/roster/Gemfile b/www/roster/Gemfile
> index e959e1c..b95b313 100644
> --- a/www/roster/Gemfile
> +++ b/www/roster/Gemfile
> @@ -15,7 +15,7 @@ end
> gem 'rake'
> wunderbar_version = File.read(File.expand_path("#{root}/wunderbar.version",
> __FILE__)).chomp
> gem 'wunderbar', wunderbar_version
> -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> gem 'sinatra', '~> 2.0'
> gem 'nokogumbo'
> gem 'mail'
> diff --git a/www/secretary/Gemfile b/www/secretary/Gemfile
> index 5b0423e..02a77e0 100644
> --- a/www/secretary/Gemfile
> +++ b/www/secretary/Gemfile
> @@ -8,7 +8,7 @@ if File.exist? version_file
>gem 'whimsy-asf', asf_version, path: File.expand_path(root, __FILE__)
> end
>
> -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> wunderbar_version = File.read(File.expand_path("#{root}/wunderbar.version",
> __FILE__)).chomp
> gem 'wunderbar', wunderbar_version
> gem 'mail'
> diff --git a/www/secretary/workbench/Gemfile b/www/secretary/workbench/Gemfile
> index 4c68f8a..5e01e30 100644
> --- a/www/secretary/workbench/Gemfile
> +++ b/www/secretary/workbench/Gemfile
> @@ -18,7 +18,7 @@ gem 'sinatra', '~> 2.0'
> gem 'sanitize'
> wunderbar_version = File.read(File.expand_path("#{root}/wunderbar.version",
> __FILE__)).chomp
> gem 'wunderbar', wunderbar_version
> -gem 'ruby2js', '>= 3.3.1' # Travis fails with 3.3.0
> +gem 'ruby2js', '3.2.0' # Travis fails with 3.3.[01]
> gem 'execjs'
> gem 'listen'
> gem 'escape'
>
Re: Making it official: resigning as chair of the Whimsy PMC.
It is now October and this has failed to produce any discussion. If this does not make substantive progress by the next board meeting, I will raise this as a board issue at that time. - Sam Ruby On Wed, Aug 19, 2020 at 2:06 PM Sam Ruby wrote: > > Now that the meeting is over, I'm resigning as chair of this PMC, > effective immediately. > > We can have a discussion either here or on private@ for naming a replacement. > > Any volunteers? > > - Sam Ruby > > On Thu, Aug 6, 2020 at 5:04 PM Sam Ruby wrote: > > > > I've submitted this quarter's board report, and after it is accepted > > at the next board meeting, I intend to step down as chair. I've done > > this role for over 5 years. > > > > The requirements for chair are minimal: quarterly reports that > > indicate that there is plenty of oversight is pretty much it. > > > > - Sam Ruby
Re: [whimsy] branch master updated: Can't have _json in same script as _html
Why was this removed?
Wunderbar will select which of the two blocks to execute based on the
"ACCEPT" header.
- Sam Ruby
On Sat, Sep 26, 2020 at 6:40 PM wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/whimsy.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 5aae43a Can't have _json in same script as _html
> 5aae43a is described below
>
> commit 5aae43a40e866099885a8a6072135a98a96ed379
> Author: Sebb
> AuthorDate: Sat Sep 26 23:39:56 2020 +0100
>
> Can't have _json in same script as _html
>
> _json block does not execute
> ---
> www/members/nominations.cgi | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/www/members/nominations.cgi b/www/members/nominations.cgi
> index 2ed4788..c6945f6 100755
> --- a/www/members/nominations.cgi
> +++ b/www/members/nominations.cgi
> @@ -142,12 +142,3 @@ _html do
> end
>end
> end
> -
> -# produce JSON output of reports
> -_json do
> - _ reports do |mail|
> -_subject mail.subject
> -_link MBOX + URI.escape('<' + mail.message_id + '>')
> -_missing missing.any? {|title| mail.subject.downcase =~ /\b#{title}\b/}
> - end
> -end
>
Re: URI.escape - is it needed for wunderbar code?
On Sat, Sep 26, 2020 at 1:36 PM Sam Ruby wrote:
>
> On Sat, Sep 26, 2020 at 12:22 PM sebb wrote:
> >
> > On Sat, 26 Sep 2020 at 16:37, Sam Ruby wrote:
> > >
> > > On Sat, Sep 26, 2020 at 10:55 AM sebb wrote:
> > > >
> > > > The URI.escape method is deprecated, and should be replaced.
> > > >
> > > > However, I'm not sure it's actually needed for Wunderbar code.
> > > >
> > > > For example, posted-reports.json.rb has
> > > >
> > > > _link THREAD + URI.escape('<' + mail.message_id + '>')
> > > >
> > > > However surely Wunderbar _json handles any necessary escaping?
> > > >
> > > > And posted-reports.cgi has:
> > > > href = THREAD + URI.escape('<' + mail.message_id + '>')
> > > > ...
> > > > _a mail.subject, href: href
> > > >
> > > > Again, I would expect Wunderbar to do the necessary.
> > >
> > > Wunderbar would need a way to know if the href was already escaped.
> >
> > I've just checked, and it does do some escaping:
> >
> > $ ruby -rwunderbar -e'_html {x=""; y="&"; _h3 x ; _a y, href: x }'
> >
> > gives the following body:
> >
> > a@b.c
> >
> >
> > This suggests that Wunderbar expects unescaped input?
>
> Currently, wunderbar does indeed do HTML escaping (consistently, for
> all text and attribute content), but it doesn't do URL escaping.
>
> What would you expect the following to return?
>
> % ruby -r wunderbar -e '_html {x="http://example.com?q=foo%20bar;; _a
> x, href: x}'
It is also worth understanding why URI.escape was deprecated. The
rules for escaping a URI depend on the part of the URI involved. The
correct way to form a URI is to escape each part separately and then
combine the parts.
- Sam Ruby
Re: URI.escape - is it needed for wunderbar code?
On Sat, Sep 26, 2020 at 12:22 PM sebb wrote:
>
> On Sat, 26 Sep 2020 at 16:37, Sam Ruby wrote:
> >
> > On Sat, Sep 26, 2020 at 10:55 AM sebb wrote:
> > >
> > > The URI.escape method is deprecated, and should be replaced.
> > >
> > > However, I'm not sure it's actually needed for Wunderbar code.
> > >
> > > For example, posted-reports.json.rb has
> > >
> > > _link THREAD + URI.escape('<' + mail.message_id + '>')
> > >
> > > However surely Wunderbar _json handles any necessary escaping?
> > >
> > > And posted-reports.cgi has:
> > > href = THREAD + URI.escape('<' + mail.message_id + '>')
> > > ...
> > > _a mail.subject, href: href
> > >
> > > Again, I would expect Wunderbar to do the necessary.
> >
> > Wunderbar would need a way to know if the href was already escaped.
>
> I've just checked, and it does do some escaping:
>
> $ ruby -rwunderbar -e'_html {x=""; y="&"; _h3 x ; _a y, href: x }'
>
> gives the following body:
>
> a@b.c
>
>
> This suggests that Wunderbar expects unescaped input?
Currently, wunderbar does indeed do HTML escaping (consistently, for
all text and attribute content), but it doesn't do URL escaping.
What would you expect the following to return?
% ruby -r wunderbar -e '_html {x="http://example.com?q=foo%20bar;; _a
x, href: x}'
- Sam Ruby
Re: URI.escape - is it needed for wunderbar code?
On Sat, Sep 26, 2020 at 10:55 AM sebb wrote:
>
> The URI.escape method is deprecated, and should be replaced.
>
> However, I'm not sure it's actually needed for Wunderbar code.
>
> For example, posted-reports.json.rb has
>
> _link THREAD + URI.escape('<' + mail.message_id + '>')
>
> However surely Wunderbar _json handles any necessary escaping?
>
> And posted-reports.cgi has:
> href = THREAD + URI.escape('<' + mail.message_id + '>')
> ...
> _a mail.subject, href: href
>
> Again, I would expect Wunderbar to do the necessary.
Wunderbar would need a way to know if the href was already escaped.
- Sam Ruby
Re: board agenda websocket not working
On Thu, Sep 24, 2020 at 2:15 PM Matt Sicker wrote: > > Is this ordering problem a limitation of Puppet or the underlying > package manager? I haven't tried it myself, but Nix/NixOS seem to be > designed around making reproducible VMs/containers. IIRC, the VMs we > have are Ubuntu-based, so perhaps > https://wiki.debian.org/ReproducibleBuilds is more relevant. Puppet has no a priori knowledge that the eventmachine gem has an optional dependency on libssl, but if one expresses that requirement in the puppet scripts, puppet will order the installation correctly. - Sam Ruby P.S. I've said it before, but none of this complexity exists in the Node implementation. In fact, there is no need for a separate process and a system service in order to have a web socket connection. > On Thu, 24 Sep 2020 at 12:41, Sam Ruby wrote: > > > > On Thu, Sep 24, 2020 at 11:54 AM sebb wrote: > > > > > > On Thu, 24 Sep 2020 at 16:36, Sam Ruby wrote: > > > > > > > > On Thu, Sep 24, 2020 at 11:12 AM sebb wrote: > > > > > > > > > > On Thu, 24 Sep 2020 at 16:06, Sam Ruby wrote: > > > > > > > > > > > > On Thu, Sep 24, 2020 at 10:58 AM sebb wrote: > > > > > > > > > > > > > > I tried running the following as root: > > > > > > > > > > > > > > /usr/local/bin/ruby /srv/whimsy/www/board/agenda/daemon/wss.rb -p > > > > > > > 34243 > > > > > > > > > > > > > > This falls over when contacted by: > > > > > > > > > > > > > > curl localhost:34243 > > > > > > > > > > > > > > However, curiously it does not fall over when run as myself or > > > > > > > www-data > > > > > > > > > > > > > > One obvious difference is that only root has access to > > > > > > > /etc/letsencrypt/live/*/ > > > > > > > which is used to set options.privkey and options.chain. > > > > > > > > > > > > Perhaps consistent with the theory that the gem is not compiled with > > > > > > access to the encryption libraries. > > > > > > > > > > The letsencrypt certificates won't be available on initial Puppet load > > > > > - maybe that affects the compilation options? > > > > > > > > > > Worth trying to reinstall now that the certs are up and running. > > > > > > > > While anything is possible, I doubt the existence of the certs matters > > > > at install time. At install time, even if the certs were installed, > > > > it wouldn't know which ones you were intending to use. The paths to > > > > the certs are only provided at runtime. > > > > > > > > Again, my theory is that the puppet installation requests that both > > > > libssl-dev and eventmachine need to be installed, but does not specify > > > > in which order these packages need to be installed. And in this case, > > > > the order is important. If eventmachine is installed first, it will > > > > be installed without encryption support. If libssl-dev is installed > > > > first, eventmachine will be installed with encryption support. > > > > > > Could be. > > > > > > libssl-dev is not mentioned in the whimsy5 puppet packages, but AFAICT > > > it is installed. > > > Maybe it comes pre-loaded in Ubuntu 18.04 which would explain how it > > > worked there. > > > > Yup, that would do it. > > > > > I think we should try re-installing eventmachine. > > > If that works, note the work-round until such time as the cause can be > > > identified and fixed. > > > That would require quite a lot of experimenting with Puppet and Docker... > > > > I'm thinking something like this: > > > > https://github.com/apache/infrastructure-p6/pull/475 > > > > > BTW, I'm not sure what you mean by the agenda console. > > > > Sorry, I was unclear. I mean browser console while viewing the agenda. > > > > > > - Sam Ruby > > > > - Sam Ruby > > > > > > > > If you run without enabling options.privkey / options.chain, things > > > > > > will work. If you enable those options, things will fail. > > > > > > > > > > > > - Sam Ruby > > > > > > > > > > > > > On Thu, 24 Sep 2020 at 15:30, sebb wrote: > >
Re: board agenda websocket not working
On Thu, Sep 24, 2020 at 11:54 AM sebb wrote: > > On Thu, 24 Sep 2020 at 16:36, Sam Ruby wrote: > > > > On Thu, Sep 24, 2020 at 11:12 AM sebb wrote: > > > > > > On Thu, 24 Sep 2020 at 16:06, Sam Ruby wrote: > > > > > > > > On Thu, Sep 24, 2020 at 10:58 AM sebb wrote: > > > > > > > > > > I tried running the following as root: > > > > > > > > > > /usr/local/bin/ruby /srv/whimsy/www/board/agenda/daemon/wss.rb -p > > > > > 34243 > > > > > > > > > > This falls over when contacted by: > > > > > > > > > > curl localhost:34243 > > > > > > > > > > However, curiously it does not fall over when run as myself or > > > > > www-data > > > > > > > > > > One obvious difference is that only root has access to > > > > > /etc/letsencrypt/live/*/ > > > > > which is used to set options.privkey and options.chain. > > > > > > > > Perhaps consistent with the theory that the gem is not compiled with > > > > access to the encryption libraries. > > > > > > The letsencrypt certificates won't be available on initial Puppet load > > > - maybe that affects the compilation options? > > > > > > Worth trying to reinstall now that the certs are up and running. > > > > While anything is possible, I doubt the existence of the certs matters > > at install time. At install time, even if the certs were installed, > > it wouldn't know which ones you were intending to use. The paths to > > the certs are only provided at runtime. > > > > Again, my theory is that the puppet installation requests that both > > libssl-dev and eventmachine need to be installed, but does not specify > > in which order these packages need to be installed. And in this case, > > the order is important. If eventmachine is installed first, it will > > be installed without encryption support. If libssl-dev is installed > > first, eventmachine will be installed with encryption support. > > Could be. > > libssl-dev is not mentioned in the whimsy5 puppet packages, but AFAICT > it is installed. > Maybe it comes pre-loaded in Ubuntu 18.04 which would explain how it > worked there. Yup, that would do it. > I think we should try re-installing eventmachine. > If that works, note the work-round until such time as the cause can be > identified and fixed. > That would require quite a lot of experimenting with Puppet and Docker... I'm thinking something like this: https://github.com/apache/infrastructure-p6/pull/475 > BTW, I'm not sure what you mean by the agenda console. Sorry, I was unclear. I mean browser console while viewing the agenda. > > - Sam Ruby - Sam Ruby > > > > If you run without enabling options.privkey / options.chain, things > > > > will work. If you enable those options, things will fail. > > > > > > > > - Sam Ruby > > > > > > > > > On Thu, 24 Sep 2020 at 15:30, sebb wrote: > > > > > > > > > > > > The login message said to reboot, so I have done this. > > > > > > > > > > > > However it does not appear to have helped. > > > > > > > > > > > > On Thu, 24 Sep 2020 at 14:28, sebb wrote: > > > > > > > > > > > > > > On Thu, 24 Sep 2020 at 14:14, Sam Ruby > > > > > > > wrote: > > > > > > > > > > > > > > > > If you go into the board agenda tool and open the console, you > > > > > > > > will > > > > > > > > see messages that it can't connect to the websocket. Things > > > > > > > > appear > > > > > > > > to mostly be set up correctly: > > > > > > > > > > > > > > > > $ grep websocket > > > > > > > > /etc/apache2/sites-available/10-whimsy-vm-443.conf > > > > > > > > ProxyPass "/board/agenda/websocket/" "wss://localhost:34234/" > > > > > > > > > > > > > > > > $ sudo lsof -i :34234 > > > > > > > > COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME > > > > > > > > ruby3430562 root 16u IPv4 160482206 0t0 TCP > > > > > > > > *:34234 (LISTEN) > > > > > > > > > > > &
Re: board agenda websocket not working
On Thu, Sep 24, 2020 at 11:12 AM sebb wrote: > > On Thu, 24 Sep 2020 at 16:06, Sam Ruby wrote: > > > > On Thu, Sep 24, 2020 at 10:58 AM sebb wrote: > > > > > > I tried running the following as root: > > > > > > /usr/local/bin/ruby /srv/whimsy/www/board/agenda/daemon/wss.rb -p 34243 > > > > > > This falls over when contacted by: > > > > > > curl localhost:34243 > > > > > > However, curiously it does not fall over when run as myself or www-data > > > > > > One obvious difference is that only root has access to > > > /etc/letsencrypt/live/*/ > > > which is used to set options.privkey and options.chain. > > > > Perhaps consistent with the theory that the gem is not compiled with > > access to the encryption libraries. > > The letsencrypt certificates won't be available on initial Puppet load > - maybe that affects the compilation options? > > Worth trying to reinstall now that the certs are up and running. While anything is possible, I doubt the existence of the certs matters at install time. At install time, even if the certs were installed, it wouldn't know which ones you were intending to use. The paths to the certs are only provided at runtime. Again, my theory is that the puppet installation requests that both libssl-dev and eventmachine need to be installed, but does not specify in which order these packages need to be installed. And in this case, the order is important. If eventmachine is installed first, it will be installed without encryption support. If libssl-dev is installed first, eventmachine will be installed with encryption support. - Sam Ruby > > If you run without enabling options.privkey / options.chain, things > > will work. If you enable those options, things will fail. > > > > - Sam Ruby > > > > > On Thu, 24 Sep 2020 at 15:30, sebb wrote: > > > > > > > > The login message said to reboot, so I have done this. > > > > > > > > However it does not appear to have helped. > > > > > > > > On Thu, 24 Sep 2020 at 14:28, sebb wrote: > > > > > > > > > > On Thu, 24 Sep 2020 at 14:14, Sam Ruby wrote: > > > > > > > > > > > > If you go into the board agenda tool and open the console, you will > > > > > > see messages that it can't connect to the websocket. Things appear > > > > > > to mostly be set up correctly: > > > > > > > > > > > > $ grep websocket /etc/apache2/sites-available/10-whimsy-vm-443.conf > > > > > > ProxyPass "/board/agenda/websocket/" "wss://localhost:34234/" > > > > > > > > > > > > $ sudo lsof -i :34234 > > > > > > COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME > > > > > > ruby3430562 root 16u IPv4 160482206 0t0 TCP *:34234 > > > > > > (LISTEN) > > > > > > > > > > > > $ sudo systemctl status board-agenda-websocket.service > > > > > > ● board-agenda-websocket.service - Whimsy Board Agenda WebSocket > > > > > > service > > > > > > Loaded: loaded > > > > > > (/etc/systemd/system/board-agenda-websocket.service; static; vendor > > > > > > preset: enabled) > > > > > > Active: active (running) since Thu 2020-09-24 12:56:18 UTC; 9s > > > > > > ago > > > > > >Main PID: 3430562 (ruby) > > > > > > Tasks: 8 (limit: 9541) > > > > > > Memory: 35.5M > > > > > > CGroup: /system.slice/board-agenda-websocket.service > > > > > > └─3430562 /usr/local/bin/ruby > > > > > > /srv/whimsy/www/board/agenda/daemon/wss.rb > > > > > > > > > > > > Sep 24 12:56:18 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda > > > > > > WebSocket service. > > > > > > > > > > > > Note, however, how long the websocket has been running (9s). This > > > > > > indicates that it is dying and was restarted. Looking at the syslog > > > > > > confirms this: > > > > > > > > > > > > Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: terminate called after > > > > > > throwing an instance of 'std::runtime_error' > > > > > > Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: what(): Encryption not > > > > > > available on this event
Re: board agenda websocket not working
On Thu, Sep 24, 2020 at 10:58 AM sebb wrote: > > I tried running the following as root: > > /usr/local/bin/ruby /srv/whimsy/www/board/agenda/daemon/wss.rb -p 34243 > > This falls over when contacted by: > > curl localhost:34243 > > However, curiously it does not fall over when run as myself or www-data > > One obvious difference is that only root has access to > /etc/letsencrypt/live/*/ > which is used to set options.privkey and options.chain. Perhaps consistent with the theory that the gem is not compiled with access to the encryption libraries. If you run without enabling options.privkey / options.chain, things will work. If you enable those options, things will fail. - Sam Ruby > On Thu, 24 Sep 2020 at 15:30, sebb wrote: > > > > The login message said to reboot, so I have done this. > > > > However it does not appear to have helped. > > > > On Thu, 24 Sep 2020 at 14:28, sebb wrote: > > > > > > On Thu, 24 Sep 2020 at 14:14, Sam Ruby wrote: > > > > > > > > If you go into the board agenda tool and open the console, you will > > > > see messages that it can't connect to the websocket. Things appear > > > > to mostly be set up correctly: > > > > > > > > $ grep websocket /etc/apache2/sites-available/10-whimsy-vm-443.conf > > > > ProxyPass "/board/agenda/websocket/" "wss://localhost:34234/" > > > > > > > > $ sudo lsof -i :34234 > > > > COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME > > > > ruby3430562 root 16u IPv4 160482206 0t0 TCP *:34234 > > > > (LISTEN) > > > > > > > > $ sudo systemctl status board-agenda-websocket.service > > > > ● board-agenda-websocket.service - Whimsy Board Agenda WebSocket service > > > > Loaded: loaded > > > > (/etc/systemd/system/board-agenda-websocket.service; static; vendor > > > > preset: enabled) > > > > Active: active (running) since Thu 2020-09-24 12:56:18 UTC; 9s ago > > > >Main PID: 3430562 (ruby) > > > > Tasks: 8 (limit: 9541) > > > > Memory: 35.5M > > > > CGroup: /system.slice/board-agenda-websocket.service > > > > └─3430562 /usr/local/bin/ruby > > > > /srv/whimsy/www/board/agenda/daemon/wss.rb > > > > > > > > Sep 24 12:56:18 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda > > > > WebSocket service. > > > > > > > > Note, however, how long the websocket has been running (9s). This > > > > indicates that it is dying and was restarted. Looking at the syslog > > > > confirms this: > > > > > > > > Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: terminate called after > > > > throwing an instance of 'std::runtime_error' > > > > Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: what(): Encryption not > > > > available on this event-machine > > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: > > > > Main process exited, code=dumped, status=6/ABRT > > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: > > > > Failed with result 'core-dump'. > > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: > > > > Scheduled restart job, restart counter is at 17895. > > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: Stopped Whimsy Board Agenda > > > > WebSocket service. > > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda > > > > WebSocket service. > > > > > > > > Random googling turned up: > > > > > > > > https://github.com/huginn/huginn/issues/386 > > > > > > > > Perhaps it is a puppet sequence error, and the eventmachine gem needs > > > > to be installed AFTER libssl-dev? > > > > > > Looks like the code is working on vm5, which has a very similar Puppet > > > setup. > > > The main differences are some software versions. > > > > > > > - Sam Ruby
Re: board agenda websocket not working
My read of the link I provided is that when the eventmachine gem is installed it configures itself based on what headers it can find on the system. If libssl-dev is present, it will configure encryption. If the puppet configuration doesn't specify an order, packages may be installed in any order. By now, you know as well as I do that the first time you run puppet on a new machine, there likely is going to be an error which is discovered after some packages install. Fix that error, and more install. Repeat until everything is installed. What that inevitably means is that the order in which packages are installed on different machines can be different, even if the end result is that all of the packages eventually are installed. This is just a theory at this point, but worth exploring. The fix may be as simple as uninstalling eventmachine manually and letting puppet install it again. I'm stopping short of doing this myself as an explicit goal of mine is to get to the point where others can resolve problems like these. - Sam Ruby On Thu, Sep 24, 2020 at 10:30 AM sebb wrote: > > The login message said to reboot, so I have done this. > > However it does not appear to have helped. > > On Thu, 24 Sep 2020 at 14:28, sebb wrote: > > > > On Thu, 24 Sep 2020 at 14:14, Sam Ruby wrote: > > > > > > If you go into the board agenda tool and open the console, you will > > > see messages that it can't connect to the websocket. Things appear > > > to mostly be set up correctly: > > > > > > $ grep websocket /etc/apache2/sites-available/10-whimsy-vm-443.conf > > > ProxyPass "/board/agenda/websocket/" "wss://localhost:34234/" > > > > > > $ sudo lsof -i :34234 > > > COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME > > > ruby3430562 root 16u IPv4 160482206 0t0 TCP *:34234 (LISTEN) > > > > > > $ sudo systemctl status board-agenda-websocket.service > > > ● board-agenda-websocket.service - Whimsy Board Agenda WebSocket service > > > Loaded: loaded > > > (/etc/systemd/system/board-agenda-websocket.service; static; vendor > > > preset: enabled) > > > Active: active (running) since Thu 2020-09-24 12:56:18 UTC; 9s ago > > >Main PID: 3430562 (ruby) > > > Tasks: 8 (limit: 9541) > > > Memory: 35.5M > > > CGroup: /system.slice/board-agenda-websocket.service > > > └─3430562 /usr/local/bin/ruby > > > /srv/whimsy/www/board/agenda/daemon/wss.rb > > > > > > Sep 24 12:56:18 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda > > > WebSocket service. > > > > > > Note, however, how long the websocket has been running (9s). This > > > indicates that it is dying and was restarted. Looking at the syslog > > > confirms this: > > > > > > Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: terminate called after > > > throwing an instance of 'std::runtime_error' > > > Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: what(): Encryption not > > > available on this event-machine > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: > > > Main process exited, code=dumped, status=6/ABRT > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: > > > Failed with result 'core-dump'. > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: > > > Scheduled restart job, restart counter is at 17895. > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: Stopped Whimsy Board Agenda > > > WebSocket service. > > > Sep 24 13:09:07 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda > > > WebSocket service. > > > > > > Random googling turned up: > > > > > > https://github.com/huginn/huginn/issues/386 > > > > > > Perhaps it is a puppet sequence error, and the eventmachine gem needs > > > to be installed AFTER libssl-dev? > > > > Looks like the code is working on vm5, which has a very similar Puppet > > setup. > > The main differences are some software versions. > > > > > - Sam Ruby
board agenda websocket not working
If you go into the board agenda tool and open the console, you will see messages that it can't connect to the websocket. Things appear to mostly be set up correctly: $ grep websocket /etc/apache2/sites-available/10-whimsy-vm-443.conf ProxyPass "/board/agenda/websocket/" "wss://localhost:34234/" $ sudo lsof -i :34234 COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME ruby3430562 root 16u IPv4 160482206 0t0 TCP *:34234 (LISTEN) $ sudo systemctl status board-agenda-websocket.service ● board-agenda-websocket.service - Whimsy Board Agenda WebSocket service Loaded: loaded (/etc/systemd/system/board-agenda-websocket.service; static; vendor preset: enabled) Active: active (running) since Thu 2020-09-24 12:56:18 UTC; 9s ago Main PID: 3430562 (ruby) Tasks: 8 (limit: 9541) Memory: 35.5M CGroup: /system.slice/board-agenda-websocket.service └─3430562 /usr/local/bin/ruby /srv/whimsy/www/board/agenda/daemon/wss.rb Sep 24 12:56:18 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda WebSocket service. Note, however, how long the websocket has been running (9s). This indicates that it is dying and was restarted. Looking at the syslog confirms this: Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: terminate called after throwing an instance of 'std::runtime_error' Sep 24 13:09:07 whimsy-vm6 ruby[3435205]: what(): Encryption not available on this event-machine Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: Main process exited, code=dumped, status=6/ABRT Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: Failed with result 'core-dump'. Sep 24 13:09:07 whimsy-vm6 systemd[1]: board-agenda-websocket.service: Scheduled restart job, restart counter is at 17895. Sep 24 13:09:07 whimsy-vm6 systemd[1]: Stopped Whimsy Board Agenda WebSocket service. Sep 24 13:09:07 whimsy-vm6 systemd[1]: Started Whimsy Board Agenda WebSocket service. Random googling turned up: https://github.com/huginn/huginn/issues/386 Perhaps it is a puppet sequence error, and the eventmachine gem needs to be installed AFTER libssl-dev? - Sam Ruby
Re: LDAP cn=podlings,ou=groups,dc=apache,dc=org - is it needed?
On Tue, Sep 22, 2020 at 6:46 AM sebb wrote: > > Is the following used/needed? Short answer: no. Longer answer: https://lists.apache.org/thread.html/346f1eca5d746dfbd80f76b778b0bddbb682fd028ada72b546875442%40%3Cdev.whimsical.apache.org%3E > dn: cn=podlings,ou=groups,dc=apache,dc=org > structuralObjectClass: groupOfNames > createTimestamp: 20161221015843Z > > It has not been maintained: > modifyTimestamp: 20170802021104Z > > Sebb - Sam Ruby
[jira] [Issue Comment Deleted] (WHIMSY-341) Use of RACK_ENV for Whimsy customisation
[ https://issues.apache.org/jira/browse/WHIMSY-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Ruby updated WHIMSY-341: Comment: was deleted (was: While the origin of RACK_ENV is unquestionably derived from rack usage, its usage has gone well beyond rack. As an example, the de facto way to determine if one is running in a test environment is to check if RACK_ENV is "test" . See, for example, [https://docs.travis-ci.com/user/environment-variables/]) > Use of RACK_ENV for Whimsy customisation > > > Key: WHIMSY-341 > URL: https://issues.apache.org/jira/browse/WHIMSY-341 > Project: Whimsy > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The RACK_ENV variable is being used for purposes for which it was not > intended. > For example, logging level and use of local test data overrides. > It should not be used for anything other than a Rack application. > It would be much less fragile to use a WHIMSY_ prefix for variables that > relate to the Whimsy application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WHIMSY-341) Use of RACK_ENV for Whimsy customisation
[ https://issues.apache.org/jira/browse/WHIMSY-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198998#comment-17198998 ] Sam Ruby commented on WHIMSY-341: - While the origin of RACK_ENV is unquestionably derived from rack usage, its usage has gone well beyond rack. As an example, the de facto way to determine if one is running in a test environment is to check if RACK_ENV is "test" . See, for example, [https://docs.travis-ci.com/user/environment-variables/] > Use of RACK_ENV for Whimsy customisation > > > Key: WHIMSY-341 > URL: https://issues.apache.org/jira/browse/WHIMSY-341 > Project: Whimsy > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The RACK_ENV variable is being used for purposes for which it was not > intended. > For example, logging level and use of local test data overrides. > It should not be used for anything other than a Rack application. > It would be much less fragile to use a WHIMSY_ prefix for variables that > relate to the Whimsy application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Making it official: resigning as chair of the Whimsy PMC.
Now that the meeting is over, I'm resigning as chair of this PMC, effective immediately. We can have a discussion either here or on private@ for naming a replacement. Any volunteers? - Sam Ruby On Thu, Aug 6, 2020 at 5:04 PM Sam Ruby wrote: > > I've submitted this quarter's board report, and after it is accepted > at the next board meeting, I intend to step down as chair. I've done > this role for over 5 years. > > The requirements for chair are minimal: quarterly reports that > indicate that there is plenty of oversight is pretty much it. > > - Sam Ruby
Intending to step down as chair
I've submitted this quarter's board report, and after it is accepted at the next board meeting, I intend to step down as chair. I've done this role for over 5 years. The requirements for chair are minimal: quarterly reports that indicate that there is plenty of oversight is pretty much it. - Sam Ruby
[jira] [Commented] (WHIMSY-338) new-account-reqs.txt is getting bad data
[ https://issues.apache.org/jira/browse/WHIMSY-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167521#comment-17167521 ] Sam Ruby commented on WHIMSY-338: - Possible fix: [https://github.com/apache/whimsy/commit/ab3d53cd9c77fdf7fe6860e8d6873b244e7d7901] It looks like the callback block is passed two parameters: the first is the name of the temporary directory and the second is the current contents of the file in question. > new-account-reqs.txt is getting bad data > > > Key: WHIMSY-338 > URL: https://issues.apache.org/jira/browse/WHIMSY-338 > Project: Whimsy > Issue Type: Task > Components: General >Reporter: Chris Thistlethwaite >Priority: Major > > Over the last week or so I've noticed that a few accounts have been entered > into new-account-reqs.txt with "/tmp/someNumberorGUID" before the actual > account info. Here's an example (data removed to protect the users identity): > /tmp/d20200728-32299-12l9t20ApacheID;FirstName > LastName;em...@email.com;project;project;07-28-2020;yes;yes;no > > Not sure where that came from, but I've been working with Matt and just > clearing out the garbage data and running the account through our scripts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Renaming of ICLA PDF files - why?
On Tue, Jul 21, 2020 at 5:46 PM sebb wrote: > > On Tue, 21 Jul 2020 at 21:31, Sam Ruby wrote: > > > > The case that needs to be handled is if I were to send in an updated > > ICLA by the name of 'sam-ruby.pdf'. At that point, there would be a > > sam-ruby.pdf in the documents/iclas directory, and one in the email, > > and both would need to be placed into a directory. > > Indeed, but that's a separate issue. > The code does check if there is a matching ICLA and will put out a > warning if so. > [The user must then either change the target name or use ICLA2 if the > duplicate is intentional.] > > What I am referring to is the following: > > Assume there is an email with attachments named: > abcd.pdf > abcd.pdf.asc > > The code I am referring to will attempt to create the following files: > iclas/subdir/icla.pdf > iclas/subdir/icla.pdf.asc My recollection is that the original intent was that the next icla pdf/asc pair should be named icla2.pdf and icla2.pdf.asc. And the reason for this naming convention was to both prevent the naming conflict and to make it easier to determine the order in which the documents were received as this would make it easier to find the most recent document. > That does not work currently. The code could be fixed to do what I stated above. Or it could be replaced with a different approach. > Even if it did, it would not fix the name clash issue. > Also the code does not rename other file types such as .txt. Possibly a second bug. > So why the rename? To prevent name clashes, and make it easier to identify the most recent document or document pair. > > - Sam Ruby - Sam Ruby > > On Tue, Jul 21, 2020 at 3:39 PM sebb wrote: > > > > > > The icla code attempts [1] to rename PDF files to icla.pdf and > > > icla.pdf.asc if there is a signature. > > > > > > However the code has been broken for a while, because the fileext is > > > nil unless the signature is empty [2]. Thus the condition becomes: > > > > > > if @signature.to_s.empty? or (not @signature.empty? && fileext != '.pdf') > > > > > > i.e. the condition is always true. > > > > > > AFAICT this has been the case since May 2017 [3] > > > > > > It's easy enough to fix (ensure fileext is always created). > > > > > > However I wonder if the rename is needed, and if so, why not rename > > > other files that have detached signatures? Removing the rename would > > > simplify the code, and make it easier to use the shared asvn_update > > > task code. > > > > > > Note that most applications seem to use icla.pdf anyway. > > > > > > Sebb > > > > > > [1] > > > https://github.com/apache/whimsy/blob/d714487b3da3f2efe7aed7021fa204eb22ba9cd5/www/secretary/workbench/views/actions/icla.json.rb#L68 > > > > > > [2] > > > https://github.com/apache/whimsy/blob/d714487b3da3f2efe7aed7021fa204eb22ba9cd5/www/secretary/workbench/views/actions/icla.json.rb#L16 > > > > > > [3] > > > https://github.com/apache/whimsy/commit/786413d74a2515f91916225d929705b7b5c08811
Re: Renaming of ICLA PDF files - why?
The case that needs to be handled is if I were to send in an updated ICLA by the name of 'sam-ruby.pdf'. At that point, there would be a sam-ruby.pdf in the documents/iclas directory, and one in the email, and both would need to be placed into a directory. - Sam Ruby On Tue, Jul 21, 2020 at 3:39 PM sebb wrote: > > The icla code attempts [1] to rename PDF files to icla.pdf and > icla.pdf.asc if there is a signature. > > However the code has been broken for a while, because the fileext is > nil unless the signature is empty [2]. Thus the condition becomes: > > if @signature.to_s.empty? or (not @signature.empty? && fileext != '.pdf') > > i.e. the condition is always true. > > AFAICT this has been the case since May 2017 [3] > > It's easy enough to fix (ensure fileext is always created). > > However I wonder if the rename is needed, and if so, why not rename > other files that have detached signatures? Removing the rename would > simplify the code, and make it easier to use the shared asvn_update > task code. > > Note that most applications seem to use icla.pdf anyway. > > Sebb > > [1] > https://github.com/apache/whimsy/blob/d714487b3da3f2efe7aed7021fa204eb22ba9cd5/www/secretary/workbench/views/actions/icla.json.rb#L68 > > [2] > https://github.com/apache/whimsy/blob/d714487b3da3f2efe7aed7021fa204eb22ba9cd5/www/secretary/workbench/views/actions/icla.json.rb#L16 > > [3] > https://github.com/apache/whimsy/commit/786413d74a2515f91916225d929705b7b5c08811
Re: [OT] Catalina users: recommended OPIE password generator for macOS
https://github.com/apache/infrastructure-otp may also be worth trying.
- Sam Ruby
On Mon, Jul 20, 2020 at 7:38 AM Sam Ruby wrote:
>
> The following works on Ubuntu and Mac (including Catalina). Put it in
> a file named otp-md5 in your path and make it executable:
>
> #!/usr/bin/env ruby
> require 'otp' # gem install ruby-otp
> require 'open3'
>
> def OTP.md5(sequence, seed, password=nil)
> if password == nil
> begin
> print "password: "
> system 'stty -echo -icanon'
> password = $stdin.gets
> password.chomp! if password
> ensure
> system 'stty echo icanon'
> print "\r"
> end
> end
>
> if password.size < 10
> joined = seed + password
> password = joined[-10..-1]
> seed = joined[0...-10]
> end
>
> OTP.new(sequence.to_i, seed, password, 'md5')
> end
>
> if __FILE__ == $0
> password = OTP.md5(*ARGV[0..1])
>
> if RUBY_PLATFORM.include? 'darwin'
> Open3.capture2e('pbcopy', stdin_data: password)
> else not `which xclip`.empty?
> Open3.capture2e('xclip', '-select', 'clipboard', stdin_data: password)
> end
>
> puts password
> end
>
> On Mon, Jul 20, 2020 at 6:33 AM sebb wrote:
> >
> > My current generator apparently does not work on Catalina.
> >
> > Can you recommend a good generator?
> >
> > S.
Re: [OT] Catalina users: recommended OPIE password generator for macOS
The following works on Ubuntu and Mac (including Catalina). Put it in
a file named otp-md5 in your path and make it executable:
#!/usr/bin/env ruby
require 'otp' # gem install ruby-otp
require 'open3'
def OTP.md5(sequence, seed, password=nil)
if password == nil
begin
print "password: "
system 'stty -echo -icanon'
password = $stdin.gets
password.chomp! if password
ensure
system 'stty echo icanon'
print "\r"
end
end
if password.size < 10
joined = seed + password
password = joined[-10..-1]
seed = joined[0...-10]
end
OTP.new(sequence.to_i, seed, password, 'md5')
end
if __FILE__ == $0
password = OTP.md5(*ARGV[0..1])
if RUBY_PLATFORM.include? 'darwin'
Open3.capture2e('pbcopy', stdin_data: password)
else not `which xclip`.empty?
Open3.capture2e('xclip', '-select', 'clipboard', stdin_data: password)
end
puts password
end
On Mon, Jul 20, 2020 at 6:33 AM sebb wrote:
>
> My current generator apparently does not work on Catalina.
>
> Can you recommend a good generator?
>
> S.
Re: Upgrade to Catalina issues
On Fri, Jul 17, 2020 at 8:32 PM Craig Russell wrote: > > tl;dr secretary workbench now works on whimsy.local > > I have verified that _a also accepts target: "_self" for normal operation and > "_blank" to open the link in a separate window which is what we (actually, I) > want to do for :emeritusReady status. And maybe for :emeritusPending status. > Discuss else thread. > > But if I process a document, what happens? Does it actually change the real > remote repositories? I'm still unclear on how the repositories work in both > whimsyvm6 in production and my whimsy.local. Is there a HOWITWORKS.md > explaining it? tl;dr: yes, it changes real remote repositories. Each of the machines you mentioned may have local, checked out, working copies of various repositories. When you call a whimsy library method like svn_ or svnmucc_, that routine may chose to create a temporary directory, do yet another checkout of one or more repositories (typically with --depth empty), make changes in that temporary directory, and then commit those changes. Or, in the case of svnmucc, the temporary directory itself may not be necessary - if you call svnmucc to move a file from one URL to another, that will be done directly - all on the server. No, there isn't a HOWITWORKS.md that says "if you call svnmucc mv src dest", where the URLs are of the form https://svn.apache.org/repos/private/xxx, then result will be to change real remote repositories. Nor is there one that says that if you call "svn commit", to a local checkout of an ASF repository, then changes made in your local checkout workspace will be sent to a real, remote repository. The node.js implementation has code to intercept these calls and either redirect these calls to local repositories (in the case of development) or with mocked implementations in memory (in the case of test). This logic is not present in the Ruby implementation. This way development, test, and production environments are intended to work in the node.js implementation is covered here: https://github.com/rubys/whimsy-board-agenda-nodejs/blob/master/docs/overview/environments.md > Thanks, > Craig - Sam Ruby
Re: Upgrade to Catalina issues
On Fri, Jul 17, 2020 at 6:05 PM Craig Russell wrote: > > On Jul 16, 2020, at 5:51 PM, Sam Ruby wrote: > > > > On Thu, Jul 16, 2020 at 8:22 PM Dave Fisher wrote: > >> > >> Latest versions of Catalina have locked up permissions. > > > > Yea, you will find that your /srv directory has been relocated. > > Figure out where they put it[1], and see if there is anything in there > > you need. Otherwise, delete it. > > > > Then brew uninstall ruby and close the window. > > > > Open a new command window, and verify that you are running ruby from > > /usr/bin, and that it is version 2.6. Here's what I see: > > > > rubys@sams-air ~ % which ruby > > /usr/bin/ruby > > rubys@sams-air ~ % ruby -v > > ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19] > > > > If you don't see similar values do not proceed to the next step. > > > > Finally, execute > > > > whimsy/config/setupmymac --all > > > > Be sure to specify --all, otherwise there are a number of things that > > will be left pointing to the now uninstalled Ruby. In order to > > address the locked up permissions issue that Dave alluded to, this > > will require a reboot. Once that is done, rerun > > whimsy/config/setupmymac --all again. > > My ruby: > ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19] > > I did setupmymac three times and rebooted twice. Now whimsy.local:80 works > for the "home" page. > > The last time I did setupmymac I got a few hundred errors [1] Feel free to ignore those warnings. > Roster works, > board agenda works, > secretary workbench has no documents to process and (check for new mail) > gives me: > Exception: # officers-secretary> > > I'm still not clear on which svn repository and mailboxes are used by the > local tool here. setupmymac didn't create the necessary directories. Fetching the directories will either require you setting up ssh for the _www user OR for you to change ownership of these directories temporarily to you, fetching the contents, and then changing ownership back. For now, do the latter. Pull the latest whimsy code to get my changes, then: cd /srv/whimsy ./config/setupmymac --user cd www/secretary/workbench rake sync cd - ./config/setupmymac > Thanks, > Craig - Sam Ruby > [1] ... > $ tools/collate_minutes.rb > _INFO 2020-07-17 14:47:54 -0700 Starting tools/collate_minutes.rb > _INFO 2020-07-17 14:47:54 -0700 Processing minutes matching > board_minutes_20*.txt > _INFO 2020-07-17 14:47:54 -0700 Most recent update: 2020-07-17 20:58:24 UTC > _INFO 2020-07-17 14:47:54 -0700 Index file update: 2020-06-17 09:44:30 -0700 > Diff: -2607234.670521082 > _INFO 2020-07-17 14:47:54 -0700 Updating files > _INFO 2020-07-17 14:47:54 -0700 Fetching remote copy of committee-info.json > 2020_07_15 > element h2: validity error : ID 2017-12-20 already defined > element a: validity error : ID minutes_2017_12_20 already defined > _INFO 2020-07-17 14:47:58 -0700 Writing AGE.html > element h2: validity error : ID 2010-10-20 already defined > element a: validity error : ID minutes_2010_10_20 already defined > _INFO 2020-07-17 14:47:58 -0700 Writing APISIX.html > element h2: validity error : ID 2012-07-25 already defined > element a: validity error : ID minutes_2012_07_25 already defined > element h2: validity error : ID 2012-04-18 already defined > element a: validity error : ID minutes_2012_04_18 already defined > element h2: validity error : ID 2012-01-24 already defined > > > > > - Sam Ruby > > > > [1] > > https://support.apple.com/guide/mac-help/a-relocated-items-folder-upgrading-macos-mac-mchl8ae423a3/mac > > > > > > > >> Sent from my iPhone > >> > >>> On Jul 16, 2020, at 4:41 PM, Craig Russell wrote: > >>> > >>> I upgraded to Catalina and tried setupmymac [1] > >>> > >>> Anything that is obvious? > >>> > >>> Thanks, > >>> Craig > >>> > >>> [1] Bundler::PermissionError (Bundler::PermissionError) > >>> /usr/local/Cellar/ruby/2.7.1_2/lib/ruby/2.7.0/bundler/shared_helpers.rb:105:in > >>> `rescue in filesystem_access' > >>> /usr/local/Cellar/ruby/2.7.1_2/lib/ruby/2.7.0/bundler/shared_helpers.rb:102:in > >>> `filesystem_access' > >>> /usr/local/Cellar/ruby/2.7.1_2/lib/ruby/2.7.0/bundler/definition.rb:353:in > >>> `lock' > >>> /usr/local/Cellar/ruby/2.7.1_2/lib/ruby/2.7.0/bundler/runtime.rb:114:in > >>> `lock' > >>> /usr/local/Cellar/ruby/2.7.1_2/lib/ruby/2.7.0/bundler/
[jira] [Commented] (WHIMSY-336) cclas.json.rb does not perform an atomic commit
[ https://issues.apache.org/jira/browse/WHIMSY-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160088#comment-17160088 ] Sam Ruby commented on WHIMSY-336: - This likely also applies to ICLAs, Software Grants, and Membership Applications. > cclas.json.rb does not perform an atomic commit > --- > > Key: WHIMSY-336 > URL: https://issues.apache.org/jira/browse/WHIMSY-336 > Project: Whimsy > Issue Type: Bug >Reporter: Sebb >Priority: Major > > Further to WHIMSY-335, a failure of an svn update caused the repo to be left > in an inconsistent state. > Whilst the commit failure this time was due to a bug, other conditions could > have caused the failure. > So the code ideally ought to make the changes as a single commit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WHIMSY-335) SecurityError: Insecure operation - directory? in ccla.json.rb
[ https://issues.apache.org/jira/browse/WHIMSY-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160048#comment-17160048 ] Sam Ruby commented on WHIMSY-335: - Partial stack traceback: App 11247 output: _ERROR # App 11247 output: _WARN /x1/srv/whimsy/lib/whimsy/asf/svn.rb:593:in `directory?' App 11247 output: _WARN /x1/srv/whimsy/lib/whimsy/asf/svn.rb:593:in `update' App 11247 output: _WARN /x1/srv/whimsy/www/secretary/workbench/views/actions/ccla.json.rb:94:in `block (2 levels) in _evaluate' > SecurityError: Insecure operation - directory? in ccla.json.rb > -- > > Key: WHIMSY-335 > URL: https://issues.apache.org/jira/browse/WHIMSY-335 > Project: Whimsy > Issue Type: Bug > Components: SecMail >Reporter: Matt Sicker >Assignee: Craig L Russell >Priority: Blocker > > CCLAs fails after committing the document and then trying to commit the > metadata (this is the failing step). This also has left two docs in an > inconsistent state at the moment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
