[JIRA] [git-client-plugin] (JENKINS-20387) git submodule update timeout value should be configurable per job
Josh Santangelo commented on JENKINS-20387 git submodule update timeout value should be configurable per job I had the extended timeout in the "advanced clone behaviours" and "advanced checkout behaviours" sections. I did not have it in "advanced submodules behaviours". When I configured it there, it seemed to work correctly. All three of these claim to honor "org.jenkinsci.plugins.gitclient.Git.timeout" in their help text. If I set that globally, will it be permanently sorted for all jobs? Thanks again for your help. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-20387) git submodule update timeout value should be configurable per job
Josh Santangelo commented on JENKINS-20387 git submodule update timeout value should be configurable per job Thanks for your reply. I am now on git plugin 2.3-beta-4. I see the same result. In the output above, note the "# timeout=NN" at the end of each command. I'm still seeing that with the new plugin. I'm guessing that comments out the timeout argument. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client-plugin] (JENKINS-20387) git submodule update timeout value should be configurable per job
Josh Santangelo commented on JENKINS-20387 git submodule update timeout value should be configurable per job I'm disappointed to report that I can still reproduce this issue. I have Jenkins 1.585, git plugin 2.2.7, and git client plugin 1.11.0. The last comment here says it's fixed in git plugin 2.3, but that was three months ago. Is 2.3 on the way? In any case, I have been using the same test project as mentioned earlier, configured with a 240 minute timeout on submodules. The output is below. You can see the timeouts in the output, but it seems like they are commented out. {{ Building in workspace C:\Jenkins\jobs\git-test\workspace Cloning the remote Git repository Cloning repository g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe init C:\Jenkins\jobs\git-test\workspace # timeout=10 Fetching upstream changes from g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe --version # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe fetch --tags --progress g...@github.com:stimulant/IMR4.git +refs/heads/:refs/remotes/origin/ # timeout=240 > C:\Program Files (x86)\Git\cmd\git.exe config remote.origin.url g...@github.com:stimulant/IMR4.git # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe config remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe config remote.origin.url g...@github.com:stimulant/IMR4.git # timeout=10 Fetching upstream changes from g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe fetch --tags --progress g...@github.com:stimulant/IMR4.git +refs/heads/:refs/remotes/origin/ # timeout=240 > C:\Program Files (x86)\Git\cmd\git.exe rev-parse "refs/remotes/origin/dev^{commit}" # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe rev-parse "refs/remotes/origin/origin/dev^{commit}" # timeout=10 Checking out Revision 696e4dea88730d445406e6a7dd5101b00be2d751 (refs/remotes/origin/dev) > C:\Program Files (x86)\Git\cmd\git.exe config core.sparsecheckout # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe checkout -f 696e4dea88730d445406e6a7dd5101b00be2d751 # timeout=240 > C:\Program Files (x86)\Git\cmd\git.exe rev-list 696e4dea88730d445406e6a7dd5101b00be2d751 # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe remote # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe submodule init # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe submodule sync # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe config --get remote.origin.url # timeout=10 > C:\Program Files (x86)\Git\cmd\git.exe submodule update --init --recursive ERROR: Timeout after 10 minutes FATAL: Command "C:\Program Files (x86)\Git\cmd\git.exe submodule update --init --recursive" returned status code -1: }} This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [github] (JENKINS-23501) Link to Github for changeset details
Josh Santangelo created JENKINS-23501 Link to Github for changeset details Issue Type: New Feature Assignee: Unassigned Components: github Created: 19/Jun/14 11:48 PM Description: The http://jenkins/job/[job]/changes page lists changes in source across various builds. Each change has a "details" link which goes to http://jenkins/job/[job]/[build]/changes. Instead, it would be nice if that link went to the actual change set on GitHub.com, which actually shows the diff and such. This would probably require additional configuration, as you'd need to know the user/origanization of the GitHub account. Project: Jenkins Labels: gui Priority: Minor Reporter: Josh Santangelo This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client] (JENKINS-20387) Timeout (10min) on git clone command
Josh Santangelo commented on JENKINS-20387 Timeout (10min) on git clone command My workaround for this issue has been to do the initial clone and submodule update from a command shell on the server. This works great and doesn't prompt for any authentication because it's using certificates. The submodule ("Cinder") is rather large and has several submodules within it. Cloning it definitely takes longer than ten minutes, so the timeout isn't entirely surprising. (It is a fork of this: https://github.com/cinder/Cinder/tree/dev) So, I don't think it's blocking on an authentication prompt, both because it works fine from the command line, and also because the parent repo and the submodule both have the same authentication, and the parent works fine. Also when either the parent or submodule are updated, Jenkins gets those updates reliably. It's just the initial clone that's a problem. If there's another way I can confirm, let me know, and thanks for your help. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client] (JENKINS-20387) Timeout (10min) on git clone command
Josh Santangelo commented on JENKINS-20387 Timeout (10min) on git clone command They are both private github repositories which require authentication, but I have many jobs with such repositories and there are no authentication prompts since the SSL certificates are configured correctly. Even if it was blocking on an auth prompt, I would expect it to time out after the 240 minutes specified in the configuration rather than the default of 10. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client] (JENKINS-20387) Timeout (10min) on git clone command
Josh Santangelo reopened JENKINS-20387 Timeout (10min) on git clone command Still seeing this with git plugin 2.2.1, git client plugin 1.9.1 and Jenkins 1.567. Change By: Josh Santangelo (10/Jun/14 10:17 PM) Resolution: Fixed Status: Closed Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client] (JENKINS-20387) Timeout (10min) on git clone command
Josh Santangelo commented on JENKINS-20387 Timeout (10min) on git clone command Still seeing this with git plugin 2.2.1, git client plugin 1.9.1 and Jenkins 1.567. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [git-client] (JENKINS-20387) Timeout (10min) on git clone command
Josh Santangelo commented on JENKINS-20387 Timeout (10min) on git clone command I'm still seeing this issue using the latest version of Jenkins and all Git plugins. Below I have added the contents of the job's config.xml and the console output of the build. I am seeing this problem in both matrix builds and "freestyle" ones too. This is Jenkins running on Windows as a service. config.xml false "hudson.plugins.git.GitSCM" plugin="git@2.2.1"> 2 g...@github.com:stimulant/IMR4.git */dev false "list"/> false 240 false true false true false false false H/5 * * * * false false console Building in workspace C:\Jenkins\jobs\git-test\workspace Cloning the remote Git repository Cloning repository g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe init C:\Jenkins\jobs\git-test\workspace Fetching upstream changes from g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe --version > C:\Program Files (x86)\Git\cmd\git.exe fetch --tags --progress g...@github.com:stimulant/IMR4.git +refs/heads/*:refs/remotes/origin/* > C:\Program Files (x86)\Git\cmd\git.exe config remote.origin.url g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* > C:\Program Files (x86)\Git\cmd\git.exe config remote.origin.url g...@github.com:stimulant/IMR4.git Fetching upstream changes from g...@github.com:stimulant/IMR4.git > C:\Program Files (x86)\Git\cmd\git.exe fetch --tags --progress g...@github.com:stimulant/IMR4.git +refs/heads/*:refs/remotes/origin/* > C:\Program Files (x86)\Git\cmd\git.exe rev-parse "origin/dev^{commit}" Checking out Revision dec485282d92247c404fe5a76c4dcfd75ace7b00 (origin/dev) > C:\Program Files (x86)\Git\cmd\git.exe config core.sparsecheckout > C:\Program Files (x86)\Git\cmd\git.exe checkout -f dec485282d92247c404fe5a76c4dcfd75ace7b00 First time build. Skipping changelog. > C:\Program Files (x86)\Git\cmd\git.exe remote > C:\Program Files (x86)\Git\cmd\git.exe submodule init > C:\Program Files (x86)\Git\cmd\git.exe submodule sync > C:\Program Files (x86)\Git\cmd\git.exe config --get remote.origin.url > C:\Program Files (x86)\Git\cmd\git.exe submodule update --init --recursive ERROR: Timeout after 10 minutes FATAL: Command "C:\Program Files (x86)\Git\cmd\git.exe submodule update --init --recursive" returned status code -1: stdout: stderr: Cloning into 'Cinder'... hudson.plugins.git.GitException: Command "C:\Program Files (x86)\Git\cmd\git.exe submodule update --init --recursive" returned status code -1: stdout: stderr: Cloning into 'Cinder'... at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1325) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:87) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$6.execute(CliGitAPIImpl.java:733) at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:77) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:909) at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:513) at hudson.model.Run.execute(Run.java:1706) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://gro
[JIRA] [git] (JENKINS-20445) Git plugin timeout is too small
Josh Santangelo commented on JENKINS-20445 Git plugin timeout is too small I have the Git plugin 2.0.3, and Git Client Plugin 1.6.3, but I don't see any new option. Am I just missing it? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-21338) All addresses are invalid?
Josh Santangelo commented on JENKINS-21338 All addresses are invalid? Sorry, "current" was all Jira would let me put in. The plugin version is 2.37. Just now I: turned off debug mode ran the job again restarted jenkins turned on debug mode ran the job again Same output. I also tried removing the email prefix setting (which was @mydomain.com), and telling it not to attach the build log, but no luck there either. More of a log... Performing post-build step Checking if email needs to be generated Email was triggered for: Always Sending email for trigger: Always Overriding default server settings, creating our own session messageContentType = text/plain; charset=UTF-8 Request made to attach build log Request made to compress build log Adding recipients from recipient list Adding developers Successfully created MimeMessage Sending email to: j...@mydomain.com Error sending to the following INVALID addresses: j...@mydomain.com SendFailedException message: Invalid Addresses Finished: SUCCESS After poking around more, I think I found it – I hadn't gone into advanced to enable SMTP authentication. Once I configured that, it worked. So I guess the only bug here is a confusing error message. Thank you for responding! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-21338) All addresses are invalid?
Josh Santangelo commented on JENKINS-21338 All addresses are invalid? I turned debug mode on, and the output was the same. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [email-ext] (JENKINS-21338) All addresses are invalid?
Josh Santangelo created JENKINS-21338 All addresses are invalid? Issue Type: Bug Affects Versions: current Assignee: Alex Earl Components: email-ext Created: 11/Jan/14 6:54 PM Description: I created a temporary job that doesn't do anything, and added an "editable email notification" with trigger set to "always" and a single email address in the recipient list. I see this in the console after a successful build: Sending email to: j...@mydomain.com Error sending to the following INVALID addresses: j...@mydomain.com SendFailedException message: Invalid Addresses No email is sent. Environment: Jenkins 1.546 running under Windows 7 as a service. Project: Jenkins Priority: Major Reporter: Josh Santangelo This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Josh Santangelo commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows You know, you're right. I was misinterpreting that number. This should work fine for my needs. The issue with explorer not following the links by default is real, though. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Josh Santangelo commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows Expanding on the above directory listing, note how the links to build numbers show the target, but the "last*" ones don't. 01/10/2014 02:25 PM . 01/10/2014 02:25 PM .. 01/09/2014 02:09 PM 152 [2014-01-09_14-08-58] 01/09/2014 03:24 PM 153 [2014-01-09_15-24-00] 01/09/2014 03:29 PM 154 [2014-01-09_15-29-22] 01/09/2014 03:44 PM 155 [2014-01-09_15-44-02] 01/09/2014 04:09 PM 156 [2014-01-09_16-09-01] 01/09/2014 05:19 PM 157 [2014-01-09_17-19-02] 01/09/2014 06:29 PM 158 [2014-01-09_18-28-59] 01/10/2014 11:09 AM 159 [2014-01-10_11-09-02] 01/10/2014 12:31 PM 160 [2014-01-10_12-31-32] 01/10/2014 12:49 PM 161 [2014-01-10_12-48-59] 01/10/2014 12:58 PM 162 [2014-01-10_12-58-51] 01/09/2014 02:12 PM 2014-01-09_14-08-58 01/09/2014 03:27 PM 2014-01-09_15-24-00 01/09/2014 03:33 PM 2014-01-09_15-29-22 01/09/2014 03:47 PM 2014-01-09_15-44-02 01/09/2014 04:12 PM 2014-01-09_16-09-01 01/09/2014 05:22 PM 2014-01-09_17-19-02 01/09/2014 06:32 PM 2014-01-09_18-28-59 01/10/2014 11:13 AM 2014-01-10_11-09-02 01/10/2014 12:35 PM 2014-01-10_12-31-32 01/10/2014 12:52 PM 2014-01-10_12-48-59 01/10/2014 01:02 PM 2014-01-10_12-58-51 01/08/2014 10:24 PM archive 01/09/2014 05:22 PM lastFailedBuild [-1] 01/10/2014 01:02 PM lastStableBuild [162] 01/10/2014 01:02 PM lastSuccessfulBuild [162] 01/05/2014 03:14 PM lastUnstableBuild [-1] 01/09/2014 05:22 PM lastUnsuccessfulBuild [-1] This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Josh Santangelo commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows @jesse @joe – My apologies, I'm pretty new to Jenkins and I don't really know how Maven fits in. I'm not specifically doing anything with Maven, but maybe it's involved in all builds? The behavior that I'm seeing is that these symlinks can't be followed in the Windows Explorer GUI without applying that fsutil command above. Further, if I look at them from a command line, I see this: 01/09/2014 05:22 PM lastFailedBuild [-1] 01/10/2014 01:02 PM lastStableBuild [162] 01/10/2014 01:02 PM lastSuccessfulBuild [162] 01/05/2014 03:14 PM lastUnstableBuild [-1] 01/09/2014 05:22 PM lastUnsuccessfulBuild [-1] A regular symlink would show the target of the link instead of a numeric code. I am trying to parse the target in a deployment script. If I should enter this bug elsewhere, let me know. Thanks for responding. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Josh Santangelo commented on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows This issue still exists – but running this command at an admin prompt fixes it. fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1 We pushed this out via group policy on our domain to fix it generally, but it is annoying on non-domain machines. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-18303) Cannot do checkout of a git repository in BitBucket in Jenkins
Josh Santangelo commented on JENKINS-18303 Cannot do checkout of a git repository in BitBucket in Jenkins I'm having this problem with a different host. The frustrating part is that sometimes it hangs and sometimes it doesn't – so everything is configured correctly, but it just randomly fails. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.