Add/users email confirmation

Contexto

Checklist

[ ] Itens

Issues linkadas

[ ] Resolves #

Como testar?

There were the following issues with your Pull Request

Commit: 1214975f186402636677897c996db68f3e7f871e

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: edcb3e7ee8ee8b1f7fa3c57390a52d63b5a571d7

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/allangrds/meu-pequeno-grupo-api

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 1214975f186402636677897c996db68f3e7f871e

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: edcb3e7ee8ee8b1f7fa3c57390a52d63b5a571d7

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: bb9953ac86f82d44bde69877bb0be9e57f0288f5

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/allangrds/meu-pequeno-grupo-api

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 1214975f186402636677897c996db68f3e7f871e

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: edcb3e7ee8ee8b1f7fa3c57390a52d63b5a571d7

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: bb9953ac86f82d44bde69877bb0be9e57f0288f5

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 728b6414b5dedc62e992ec8adede7751f783d029

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/allangrds/meu-pequeno-grupo-api

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 1214975f186402636677897c996db68f3e7f871e

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: edcb3e7ee8ee8b1f7fa3c57390a52d63b5a571d7

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: bb9953ac86f82d44bde69877bb0be9e57f0288f5

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 728b6414b5dedc62e992ec8adede7751f783d029

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 008ea8dab42847688a5e979cfaa17b3f407d3c4f

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/allangrds/meu-pequeno-grupo-api

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 1214975f186402636677897c996db68f3e7f871e

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: edcb3e7ee8ee8b1f7fa3c57390a52d63b5a571d7

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: bb9953ac86f82d44bde69877bb0be9e57f0288f5

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 728b6414b5dedc62e992ec8adede7751f783d029

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 008ea8dab42847688a5e979cfaa17b3f407d3c4f

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: ed729119c03b2935406f9390af31a090c5d7ab7f

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/allangrds/meu-pequeno-grupo-api

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 1214975f186402636677897c996db68f3e7f871e

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: edcb3e7ee8ee8b1f7fa3c57390a52d63b5a571d7

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: bb9953ac86f82d44bde69877bb0be9e57f0288f5

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 728b6414b5dedc62e992ec8adede7751f783d029

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 008ea8dab42847688a5e979cfaa17b3f407d3c4f

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: ed729119c03b2935406f9390af31a090c5d7ab7f

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: dcda7e4a23754320473f30ab686b52e19cf3749b

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/allangrds/meu-pequeno-grupo-api

This message was auto-generated by https://gitcop.com


Lagging while using it inside PageView

When I use it in the a PageView everything slows down.🤔

@o4x provide details by publishing the source code

Oh In fact, I was wrong.
The reason for lagging is rebuilding scaffold while closing or opening drawer. Is there a way to disable it ?

@o4x I have not experienced this combination ... I should try it

The problem was my code, sorry😓


Deleting the last key doesn't save

If the last key in the database is emptied from a DEL command, the next SAVE or BGSAVE operation is not performed because there are technically no keys to be saved.. this results in the DB file remaining intact (and the deleted key gets restored).

This can be fixed by not checking if the DB tempfile is empty before writing the DB file to disk.

Fixed in ffe069d


Ignore return value of SecRandomCopyBytes explicitly

Coverage remained the same at 92.183% when pulling f4cb36dab6412ecca0a0608f4bad13a016eaf89b on ignore-return-value into 7d71a320449d5f3bc471ba655734ebb5562924e2 on master.


Fix unwanted change during merge

There were couple changes in manifest-diff file reverted during rebase for commit #132. Bring those back.

@sdake Can you help approve it?


[BUG] @Delegate compilation issue

hello.
because an example is much better than a lot of words:
here is a public repo where you can see the issue:
https://github.com/clembou590/lombokFails
two branches in this repo:
"master" branch works. (just type mvn clean install)
"fails" branch does not work (just type mvn clean install)
the 2 branches should succeed... (the only difference between the 2 branches is the use of @Delegate)
here is the error I get in the "fails" branch
Compilation failure
[ERROR]  cannot find symbol
[ERROR]   symbol:   method save(com.example.deleg.fail.Message)
[ERROR]   location: variable messageService of type com.example.deleg.fail.MessageService
for information
1.18.12 is the lombok version that is brought in by  org.springframework.boot:spring-boot-starter-parent:2.2.5.RELEASE

Hi. did anyone had some time to dig into this bug?

There seems to multiple @Delegate related bugs, @rzwitserloot or @rspilker mentioned somewhere that they plan to rewrite it. If they will do that soon it would be a waste of time to fix these bugs. If not I can try to fix some of these bugs.

@clembou590 not yet, but your efforts in making this one easy to reproduce is quite useful!
Given that the usage is so simple I assume the problem is due to the interaction between lombok and @Autowired - might not be feasible for us to fix this.

Based on the good example I created a smaller example without Spring to reproduce this issue:
import lombok.experimental.Delegate;

public class Controller {
	@Delegate
	I1 target;

	public void call(String entity) {
		this.save(entity);
	}
}

interface I1 extends I2<String, Integer> {
}
interface I2<T, ID> extends I3<T, ID> {
}
interface I3<T, ID> {
	public T save(T a);
}

It compiles

if you remove I2
if you remove the generics <T, ID>
in eclipse


Some Devices may have Wired internet connection

Some Devices may have Wired internet connection,and May have No WifiInfo connection.
For example, some android OTT and android TV.

No feedback was provided, and MAC retrieval was modified since then.
Closing this stale PR.


Create remaining pages & backend cleanup

After setting up the backend code for snippet pages, we are now setting up the code that will handle static pages, listing pages and search pages.
This PR will definitely include some new components to cover the needs of said pages, along with some cleanup and QoL improvements to existing backend code.

After some extensive work on this PR, I am merging pretty much everything necessary to render pages on the backend, a bunch of bug fixes, some cleanup and a lot of fontend work to enable the proper rendering of all the pages. This should be considered a stable point in the development lifecycle.


Added architecture ppc64le

Hi
Here is my contribution to your code, its working good on powersystems.
Thanks for the code, its working good.
What do these changes do?
Added Architecture "ppc64le"
Are there changes in behavior for the user?
No

Coverage remained the same at 92.308% when pulling ff1b733921e74a7b4c0a54f64763a5cc24c1a88c on genisysram:master into f3d4c7933ab03ad60353bacd70663614ab4482e9 on normalize:master.

Coverage remained the same at 92.308% when pulling ff1b733921e74a7b4c0a54f64763a5cc24c1a88c on genisysram:master into f3d4c7933ab03ad60353bacd70663614ab4482e9 on normalize:master.


fix build with recent GCC

Fix "multiple definition" errors when building with a recent GCC.

this should be corrected with latest version. thank you.


Add support for the INIT_HALT environment variable

Please note that this change is untested; I'm looking for some feedback before I invest the effort in actually testing it.
The shutdown command provided by sysvinit sets the INIT_HALT environment
variable before switching to runlevel 0.
shutdown -hH -> INIT_HALT=HALT
shutdown -hP -> INIT_HALT=POWEROFF
Add a new "halt" init script to interpret this variable and invoke "halt"
or "poweroff" as appropriate.
This restores the ability to actually halt the system instead of always
turning off the power.
Reference:
http://git.savannah.nongnu.org/cgit/sysvinit.git/tree/doc/Changelog?h=2.95#n30
http://git.savannah.nongnu.org/cgit/sysvinit.git/tree/src/shutdown.c?h=2.95#n457
http://git.savannah.nongnu.org/cgit/sysvinit.git/tree/src/shutdown.c?h=2.95#n554
Signed-off-by: Mike Gilbert<EMAIL_ADDRESS>

I like it, and if it works I think we should use it.
Adding this to the shutdown runlevel by default assumes that everyone using OpenRC on Linux uses sysvinit, and this isn't necessarily the case.
I think A better place to put something like this would be in the support/sysvinit directory along with updating the README stored there.

The more I think about this, it is a bug, but I'm not sure about whether the approach here works either. The final halt is run by /etc/inittab after OpenRC shuts down its services.

There's no way to inspect an environment variable in inittab, so we would need to invoke a external script. Given that it already invokes openrc shutdown, I figured adding it to the end of the shutdown runlevel would suffice.

The more I think about this, it is a bug, but I'm not sure about whether the approach here works either.

I'm pretty sure this approach would work. There's no requirement that the final halt has to be invoked directly from inittab.

Closing this in favor of #319.


Add support for new types like dict[str, int]

No need to fail if upcoming type is the as new_arg_types current type

Thanks, I'm closing this one in favor of https://github.com/art049/odmantic/pull/240 since it handles all the test update.


CAMEL-19060: use LongAdder in DefaultInflightRepository to reduce contention

This seems to help (mostly?) consumers when there is heavy contention. For instance, with Disruptor on a 6 consumer / 3 producer thread configuration:
GEOMETRIC MEAN (RATE):
Test: 1041550.6594790532 | Baseline:<PHONE_NUMBER>67714
Delta:<PHONE_NUMBER>113392
The geometric mean rate was greater for the test than for the baseline

Where "Test" is this patch and "Baseline" is 4.0.0-M3.

I think this may break stuff, I can now see jbang have incorrect inflight exchanges
out in 5 seconds. Inflights per route: [route2 = 26]
2023-05-07 13:53:14.719  INFO 39678 --- [ - ShutdownTask] impl.engine.DefaultShutdownStrategy : Waiting as there are still 26 inflight and pending exchanges to complete, timeout in 4 seconds. Inflights per route: [route2 = 26]
2023-05-07 13:53:15.721  INFO 39678 --- [ - ShutdownTask] impl.engine.DefaultShutdownStrategy : Waiting as there are still 26 inflight and pending exchanges to complete, timeout in 3 seconds. Inflights per route: [route2 = 26]
2023-05-07 13:53:16.727  INFO 39678 --- [ - ShutdownTask] impl.engine.DefaultShutdownStrategy : Waiting as there are still 26 inflight and pending exchanges to complete, timeout in 2 seconds. Inflights per route: [route2 = 26]
2023-05-07 13:53:17.731  INFO 39678 --- [ - ShutdownTask] impl.engine.DefaultShutdownStrategy : Waiting as there are still 26 inflight and pending exchanges to complete, timeout in 1 seconds. Inflights per route: [route2 = 26]

Yes this works fine on 3.20.x branch

Yes this works fine on 3.20.x branch

How about with M3?


Crashing when loading a stash tab

It suddenly started. I deleted Procurement then downloaded it again, same issue. Version 1.24.1 both times.
DebugInfo.log

Can you attach the bin files which are in your application directory - you might need to zip them up and put them on drop box. They will be in a folder that has your alias name on it.

Here you go!
issue-916.zip

Glad my fishing rod can finally be used for something :joy:

I've released the fix as part of Procurement 1.24.2!


Error putting blob image:Azure - Unity3D2017/Unity3D2018

Error putting blob image:AuthenticationFailedServer failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:85f41450-901e-002a-33a4-14553a000000
Time:2018-07-05T21:09:46.9683350ZThe MAC signature found in the HTTP request 'JTS6K4SeTm3KC/IVPOa6b5ejmfA590xr+qR+yehQdTA=' is not the same as any computed signature. Server used following string to sign: 'PUT
2
image/png
x-ms-blob-content-disposition:attachment; filename="18-07-05-21-09-44-30.png"
x-ms-blob-type:BlockBlob
x-ms-date:Thu, 05 Jul 2018 21:09:46 GMT
x-ms-version:2017-04-17
/unityazureblobst/blobunity/18-07-05-21-09-44-30.png'.
UnityEngine.Debug:LogError(Object)
Log:Text(Text, String, String, Level) (at Assets/Utilities/Log.cs:30)
ImageDemo:PutImageCompleted(RestResponse) (at Assets/Demos/Image/ImageDemo.cs:85)
RESTClient.RestRequest:GetText(Action1, Boolean) (at Assets/Dependencies/RESTClient/http/RestRequest.cs:282) RESTClient.RestRequest:Result(Action1) (at Assets/Dependencies/RESTClient/http/RestRequest.cs:269)
Azure.StorageServices.c__IteratorA:MoveNext() (at Assets/Dependencies/StorageServices/BlobService.cs:132)
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

I've the very same issue. Although samples from StorageServiceDemo project work, but whenever I'm incorporating it to my project I'm getting the MAC signature error as you.

what is the MAC OS X and Unity3D Version?

@ganusajjan I got it working. Check out this issue: https://github.com/Unity3dAzure/RESTClient/issues/4
There was a bug introduced in the newest version of RESTClient.

@ganusajjan try now (update RESTClient to the newest one).


Update AUTHORS

Added @chrisjones-brack3t and myself to the AUTHORS file since the 1.9 Access Mixins are based on our work with django-braces.

Merged in 5aba3f0a453478f1b418d66b06593d04f2065a64, thanks for the inspiration!


iconv with alpine docker image

The logger throws:
 iconv(): Wrong charset, conversion from `UTF-8' to `UTF-8//IGNORE' is not allowed in /var/www/vendor/rollbar/rollbar/src/rollbar.php on line 374

When run in an alpine linux docker container.
The issue can temporarily be circumvented by using the config:
'enable_utf8_sanitization'  => false, although this is not desierable

Had the same problem with alpine with other libraries relying on iconv. Problem can be easily worked around by using transliterator_transliterate instead (http://php.net/manual/en/transliterator.transliterate.php)

This is no longer a thing right? We are not using iconv anymore anywhere.

Sorry no idea... I would like to know though.

I am adding this to the 1.0.0 release to remember to close this once we actually make that release. This was taken care of in the code updates to 1.0

Closing this as it is fixed in the newest release.


Power BI references old python interpreter

The power bi tool was using a python interpreter located on:
C:\Users\xx\Projects\ProjectA\venv\Scripts\
I decided delete this python interpreter and create a new one on:
C:\Users\xx\Projects\ProjectB\venv\Scripts\
So, I went to file > options > python scripting. And set the path to the new directory.
After doing do, my power bi is still referencing the old interpreter. Apparently the variable that holds the path to the python interpreter is not being updated.
When i open the window to write the script, power bi makes sure to print out that:
This script will run with the following Python installation: C:\Users\xx\Projects\ProjectB\venv\Scripts\
however it does not do so! When I run the script, I get the error:
DataSource.Error: ADO.NET: Python script error.
<pi>No Python at '`C:\Users\xx\Projects\ProjectA\venv\Scripts\python.exe'
</pi>
Details:
    DataSourceKind=Python
    DataSourcePath=Python
    Message=Python script error.
<pi>No Python at '`C:\Users\xx\Projects\ProjectA\venv\Scripts\python.exe'
</pi>
    ErrorCode=-2147467259

I've already tried to close and re-open again the program, but it doesn't solve the program.

Thanks for your comment, @schulzalbrecht. This issue has been assigned to the doc author for review.

Thanks for your comment, @schulzalbrecht.
This looks like a support request or product question rather than documentation feedback.
You might find a solution in the Power BI Community. If not, try our support page.


This file says "contect" but I cannot find any reference to that bein…

[This file says "contect" but I cannot find any reference to that being a legitimate string for OWA meta redirects.
I believe it's supposed to be "content" which would be the standard for meta refresh tags.

Thank you


Exactearth hvt example up5259

Not super happy with the visualisation, but a lot of effort to do something really better.
Items:

[ ] Ran test & live-tests
[ ] Implemented (new) unit tests
[ ] Removed credentials
[ ] Removed argument pointing to staging
[ ] Updated documentation

For release:

[ ] Bumped version
[ ] Added changelog
[ ] Updated announcement banner

Says Make this Notebook Trusted to load map: File -> Trust Notebook where this visualization should be, I'm guessing this is a github review render issue? Otherwise LGTM!


from core.lib.utils migrate simpleDecrypt and simpleEncrypt of data f…

…or id_ecdsa
i hope i got all failures fixed caused by my code. There is serveral tox output from other code that i do not understand right now, but for my part it looks ok.
sorry for the pr chaos. :)

Coverage increased (+1.5%) to 74.211% when pulling 505c1897e6579fad0e6ee7c89ce3488f540f0a9b on BlackDuck888:develop into 5dbbc515384701a30059e3447bc6e7ca8a88984e on Storj:develop.

Coverage increased (+1.4%) to 74.14% when pulling 2ea92f236053d2d82fa138938f27636abada96e3 on BlackDuck888:develop into 5dbbc515384701a30059e3447bc6e7ca8a88984e on Storj:develop.

looks good to me.


Bump version to v1.13.1

To do a C# patch release with #15975.
CC @srini100

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Known failures (already closed as this is the release branch):
https://github.com/grpc/grpc/issues/15621
https://github.com/grpc/grpc/issues/15405
https://github.com/grpc/grpc/issues/15916


Can't use fulltext search with traversing

Is any support planned?
Example case:
select from (traverse out() from <rid> )  where <property> LUCENE "test*"

This is already supported

Can you give me an example?  Thanks.

The query above is supported, but the LUCENE filter happens in the outer query. What's your purpose?

I want to filter the traversed elements with the fulltext query. The query above dont use any index.

@StarpTech Sorry I go it now. LUCENE filters only with a FROM clause. In your case you could execute the LUCENE against the entire set and then filter by RID. Like:
select from ( select from <your-class> where <property> LUCENE "test*" ) where <rid> IN in()

Thanks,  I will try it.

I got it but this will be very inefficient on large datasets.
select from Node where @rid IN ( select from ( traverse out() from (select from Node where Email = 'julia@local') ) ) and DisplayName LUCENE "dust*"

In my opinion this is a fundamental feature and should be improved.

I got it but this will be very inefficient on large datasets.
In my opinion this is a fundamental feature and should be improved.

I have run into the same issue a while and did the same workaround @lvca mentioned, but soon I'll be in trouble, because the database is growing and in some situations this IN operation cost ~70% off all the processing time

@ncreea yes , that's terrible and is not acceptable for a graph database. These kind of bottlenecks make a database unusable for professional production. It would be nice if orientdb is more focussed to improve the existing features instead to blowup the db with all awesome stuff. The user @mattaylor said this in good words.

Nice idea, but in my opinion it should be a third party plugin, not a part of the core.
I think that OrientDB has to be focused on its main purpose: become the most reliable, well documented, modular graph database, without wasting efforts in developing accessories before the main goal is achieved.
https://github.com/orientechnologies/orientdb/issues/2652#issuecomment-51158776

@StarpTech We did a POC a few months ago and this solution scaled quite good even with tens millions of entries. Did you execute a benchmark to see when this become a bottleneck?

@lvca @ncreea is talking about his real world scenario. It is obvious that this query isn't perfect for scalability. In general I didn't only talk about this example I am talking about the fact that there are much situations in orientdb which needs a lot improvement to be usable in production. Just to mention a few of them:

Export/Import (no way to use this tools efficiently in production)
A lot of bugs in the sql parser (one space more and the query is broken)
...

I like orientdb very much but the focus should be on the core features.

About this scaling issue by having one index for all the entries, we need proves about bottlenecks and in which cases. Can you measure index lookup with 1M or 1B items?
About the rest:

Export/Import, what's the problem?
In 2.1 the new sql parser fixed this noisy problem with spaces. 2.1-rc1 will be out tomorrow (but it's already available as 2.1-SNAPSHOT)
We're working also on this
Can you provide just one example?

Export/import:
Can you tell me one method to export my db  within an adequate time span and without locking my production environment?
SqlParser
find references (select from Node where Email = 'julia@local') works as expected.
find references  (select from Node where Email = 'julia@local') don't work (one space more after references keyword)
Projection
If I receive data with a fetchPlan with projection the nested records aren't use the projection before.


Add sbt scalastyleCheck

@gzm0 @sjrd I don't think the jenkinsbot picked up the Jenkinsfile changes, based upon my local testing I think https://github.com/scala-js/scala-js/pull/4172 will need to be merged before the Jenkinsfile commit gets merged.  Should I remove that commit from this PR to keep the Build.scala changes separate?

No, indeed. The Jenkins bot doesn't "trust" non-maintainers to edit Jenkinsfile, so during PR validation it ignores the changes and keeps using the Jenkinsfile on master. I did not find a way to configure it otherwise.

I removed the Jenkinsfile changes to simplify this and still allow running the command locally for development.

@sjrd I believe this is waiting on you.

@sjrd @gzm0 CI passing


chore(deps): update common-dev-assets digest to 0920aa4

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
9d04954 -> 0920aa4

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 3.2.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Get workflow lifetime statistics

Impact of the new feature
WM in general
Is your feature request related to a problem? Please describe.
This issue is part of  #11605
Describe the solution you'd like
Use job index database used by monit grafana or Elastic search in order to get:

Workflow lifetime (input vs non-input)

In addition to mean, min, max, get 10%, 25%, 90% distribution if possible

Workflow lifetime for original vs recovery phase.

Policy for ACDC (RequestType=Resubmission)

Describe alternatives you've considered
None
Additional context
None

I created a jupyter notebook parsing workflows created in the system from [2022,4,1] through [2023,4,1], which can be found here: https://github.com/amaltaro/WMAnalytics/blob/main/workflow_lifetime.ipynb
It provides at least the following information:

break down of workflows that entered the system and which final state they reached (some are not yet in a final state)
some stats for workflows that have been archived (normal-archived, aborted-archived, rejected-archived)
some stats for normal-archived workflows that were ACDC vs non-ACDC
some stats for normal-archived workflows for every single status from creation to archival
more stats depending on the input data requirements
plots with workflow distribution and percentile

Some of this information has been propagated to the document with the WM modeling metrics; and to the "CDR: Evaluation of the WM system for the HL-LHC scenario" google document as well.
I think this ticket can now be closed out, but I am happy to come back to this if further details are required.


Draper relies on active_model/serializers/xml which is being removed in Rails 5

If you try using Draper on Rails 5, and you have spring enabled, you'll see this less-than-helpful error message:
./bin/rails:6: warning: previous definition of APP_PATH was here
Usage: rails COMMAND [ARGS]

The most common rails commands are:
 generate    Generate new code (short-cut alias: "g")
 console     Start the Rails console (short-cut alias: "c")
 server      Start the Rails server (short-cut alias: "s")
[...]

If you disable spring:
~/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/draper-2.1.0/lib/draper.rb:5:
  in `require': cannot load such file -- active_model/serializers/xml (LoadError)

In Rails 5, active_model/serializers/xml has been extracted into its own gem. So, a quick solution is to add the activemodel-serializers-xml gem to your Gemfile:
gem 'activemodel-serializers-xml', git: 'https://github.com/rails/activemodel-serializers-xml'
gem 'draper'

There is not yet a published release of activemodel-serializers-xml, hence the need to retrieve it from master in GitHub.
I was able to run Draper on Rails 5 with this solution, although I didn't run any of Draper's tests so I don't yet know what other issues might crop up.

This issue helped me - THANKS !!!

Bit shorter solution:
gem 'activemodel-serializers-xml', github: 'rails/activemodel-serializers-xml'
gem 'draper'

#752 has been merged and 3.0.0.pre1 released, which fixes this.

We are about to publish in rubygems ambry v1, with no XML support (or dependency): https://github.com/norman/ambry/releases/tag/v1.0.0.
Thanks!

great!


Fix missing reference (tabId) in windowsSetCwd()

Hi,
Not sure if this is the best fix but this change does the job.
The body of windowsSetCwd has been copied from index.js. However the signature has changed, and tabId is no longer passed as an argument. Since the caller already sets curTabId as action.uid, I propose a fix to replace missing tabId with action.uid, although it also makes sense to remove the tabId === curTabId condition altogether, because now it will always be true.

thanks!

@bagdemir Is any posibility to merge this commit to fix this bug?

@hharnisc or @bagdemir -> Can you merge this PR? Would be greatly appreciated!

Hey everyone :wave:
So sorry for the delay here, I've been away on vacation :palm_tree: Going to merge this fix and publish a new release now.
It's become clear this project needs another maintainer, specifically one that lives on windows. Would anyone be up for that? I rely on this for Linux (OS X is same code path for now), so I can promise that will work.

Published as version 1.2.3

Thank you for the fix @asyncore :raised_hands:

@hharnisc I use Windows primarily and use hyper everyday. I can do maintenance and pull request checking to make sure it works under Windows.


Forward proxy with "proxySettings" does not work with ws+tls in stream settings

What version of V2Ray are you using (If you deploy different version on server and client, please explicitly point out)?

Server: V2Ray v2.47 (One for all) 20171109;
Client: V2Ray v2.47 (One for all) 20171109.
Debian 9 stretch x64.

What's your scenario of using V2Ray? E.g., Watching YouTube videos in Chrome via Socks/VMess proxy.

I set up a remote server with v2ray+websocket+tls, and use nginx+corresponding headers. This setting works well. The client server can connect to the remote server, and browsers can open websites via this proxy.
However, when I tried to use "proxySettings" to pass the proxy tunnel to another shadowsocks server, it fails.

What did you see? (Please describe in detail, such as timeout, fake TLS certificate etc)

With the following client configuration, I tweaked "outboundTag" to switch different proxy route.

"ss" worked, and it could connect to every site, including the REMOTE_SERVER_ADDRESS server's nginx page, so client -> ss -> freedom worked;
"tcp-via-ss" worked, so client -> ss -> vmess -> freedom tunnel worked;
"ws" worked, so my nginx + v2ray server was correctly configured, and client -> vmess+ws+tls -> freedom worked;
"ws-via-ss" failed, so client -> ss -> vmess+ws+tls -> freedom failed. The browser results: "This site can’t be reached. ipv4.google.com unexpectedly closed the connection."
I tried "curl -v -x socks5h://<IP_ADDRESS>:1080 https://ipv4.google.com" with "ws-via-ss", and the result was:

* Rebuilt URL to: https://ipv4.google.com/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* SOCKS5 communication to ipv4.google.com:443
* SOCKS5 request granted.
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 1080 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipv4.google.com:443
* stopped the pause stream!
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipv4.google.com:443

What's your expectation?

Route client -> ss -> vmess+ws+tls -> freedom should work.

Please attach your configuration file (Mask IP addresses before submit this issue).
Server configuration:

Client configuration:

{
  "log" : {
    "access": "/var/log/v2ray/access.log",
    "error":  "/var/log/v2ray/error.log",
    "loglevel" : "debug"
  },
  "inbound" : {
    "listen" : "<IP_ADDRESS>",
    "port" : 1080,
    "protocol" : "socks",
    "settings" : {
      "auth" : "noauth"
    }
  },
  "outbound": {
    "tag": "ws-via-ss",
    "protocol" : "vmess",
    "settings" : {
      "vnext" : [
        {
          "address" : "REMOTE_SERVER_ADDRESS",
          "port" : REMOTE_SERVER_PORT,
          "users" : [
            {
              "id" : "CUSTOM_UUID",
              "security": "VMESS_CIPHER",
              "alterId" : 64
            }
          ]
        }
      ]
    },
    "streamSettings": {
      "network": "ws",
      "security": "tls",
      "tlsSettings": {
        "allowInsecure": false
      },
      "wsSettings": {
        "connectionReuse": true,
        "path": "WS_PATH",
        "headers": {
          "CUSTOM_HEADER_NAME": "CUSTOM_HEADER_CONTENT"
        }
      }
    },
    "proxySettings": {
      "tag": "ss"
    }
  },
  "outboundDetour": [
    {
      "tag": "ws",
      "protocol" : "vmess",
      "settings" : {
        "vnext" : [
          {
            "address" : "REMOTE_SERVER_ADDRESS",
            "port" : REMOTE_SERVER_PORT,
            "users" : [
              {
                "id" : "CUSTOM_UUID",
                "security": "VMESS_CIPHER",
                "alterId" : 64
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "allowInsecure": false
        },
        "wsSettings": {
          "connectionReuse": true,
          "path": "WS_PATH",
          "headers": {
            "CUSTOM_HEADER_NAME": "CUSTOM_HEADER_CONTENT"
          }
        }
      }
    },
    {
      "tag": "tcp-via-ss",
      "protocol" : "vmess",
      "settings" : {
        "vnext": [
          {
            "address": "REMOTE_SERVER_2_ADDRESS",
            "port": REMOTE_SERVER_2_PORT,
            "users": [
              {
                "id": "CUSTOM_UUID",
                "alterId": 64,
                "security": "VMESS_CIPHER"
              }
            ]
          }
        ]
      },
      "proxySettings": {
        "tag": "ss"
      }
    },
    {
      "protocol": "shadowsocks",
      "tag": "ss",
      "settings": {
        "servers": [
          {
            "address": "SS_REMOTE_SERVER_ADDRESS",
            "port": SS_REMOTE_SERVER_PORT,
            "method": "SS_CIPHER",
            "password": "SS_PASSWORD",
            "ota": false
          }
        ]
      }
    }
  ],
  "routing": {
    "strategy": "rules",
    "settings": {
      "domainStrategy": "AsIs",
      "rules": [
        {
          "type": "field",
          "ip": [
            "<IP_ADDRESS>/8",
            "<IP_ADDRESS>/8",
            "<IP_ADDRESS>/10",
            "<IP_ADDRESS>/8",
            "<IP_ADDRESS>/16",
            "<IP_ADDRESS>/12",
            "<IP_ADDRESS>/24",
            "<IP_ADDRESS>/24",
            "<IP_ADDRESS>/16",
            "<IP_ADDRESS>/15",
            "<IP_ADDRESS>/24",
            "<IP_ADDRESS>/24",
            "::1/128",
            "fc00::/7",
            "fe80::/10"
          ],
          "outboundTag": "direct"
        },
        {
          "type": "field",
          "domain": [
            "regexp:.*$"
          ],
          "outboundTag": "ws-via-ss"
        }
      ]
    }
  }
}

Please attach error logs, especially the bottom lines if the file is large. Error log file is usually at /var/log/v2ray/error.log on Linux.

When switched route to "ws-via-ss", ss server did not even try to access remote nginx server. IP of ss server was not shown in remote /var/log/nginx.log. Nothing on the server side was logged.
Client error log:

The following error log only shows "ws-via-ss" route.
2017/12/15 06:01:58 [Warning]Core: V2Ray started
2017/12/15 06:01:59 [Info]Proxy|Socks: TCP Connect request to tcp:template.need.sh:443
2017/12/15 06:01:59 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:template.need.sh:443]
2017/12/15 06:01:59 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:01:59 [Info]Proxy|VMess|Outbound: tunneling request to tcp:template.need.sh:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:01:59 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:01:59 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:01:59 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:clients5.google.com:443
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:lh3.googleusercontent.com:443
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:www.gstatic.com:443
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:notifications.google.com:443
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:clients5.google.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:clients5.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:www.gstatic.com:443]
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:ssl.gstatic.com:443
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:www.gstatic.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:fonts.gstatic.com:443
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:play.google.com:443
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:notifications.google.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:notifications.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ssl.gstatic.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:lh3.googleusercontent.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:lh3.googleusercontent.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ssl.gstatic.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:apis.google.com:443
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:fonts.gstatic.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:fonts.gstatic.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:apis.google.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:apis.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:play.google.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:play.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 105 but actually 190
2017/12/15 06:02:00 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:00 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:00 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:00 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:00 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:00 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:00 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 214 but actually 144
2017/12/15 06:02:00 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 137 but actually 140
2017/12/15 06:02:00 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:00 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:00 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:01 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:01 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:01 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:01 [Info]Proxy|Socks: TCP Connect request to tcp:template.need.sh:443
2017/12/15 06:02:01 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:template.need.sh:443]
2017/12/15 06:02:01 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:01 [Info]Proxy|VMess|Outbound: tunneling request to tcp:template.need.sh:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:01 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:01 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:01 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 91 but actually 200
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:fonts.gstatic.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:fonts.gstatic.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:fonts.gstatic.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:clients5.google.com:443
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:www.gstatic.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:clients5.google.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:clients5.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:www.gstatic.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:www.gstatic.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:notifications.google.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:notifications.google.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:notifications.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:lh3.googleusercontent.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:lh3.googleusercontent.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:lh3.googleusercontent.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:play.google.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:play.google.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:play.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:02 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:02 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:02 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:02 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:02 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 108 but actually 176
2017/12/15 06:02:02 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 131 but actually 83
2017/12/15 06:02:02 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 90 but actually 50
2017/12/15 06:02:02 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 146 but actually 219
2017/12/15 06:02:02 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:02 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:02 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 224 but actually 250
2017/12/15 06:02:03 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:03 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:03 [Info]Proxy|Socks: TCP Connect request to tcp:apis.google.com:443
2017/12/15 06:02:03 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:apis.google.com:443]
2017/12/15 06:02:03 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:03 [Info]Proxy|VMess|Outbound: tunneling request to tcp:apis.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Proxy|Socks: TCP Connect request to tcp:ssl.gstatic.com:443
2017/12/15 06:02:03 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ssl.gstatic.com:443]
2017/12/15 06:02:03 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:03 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ssl.gstatic.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Proxy|Socks: TCP Connect request to tcp:live800.eic.org.cn:80
2017/12/15 06:02:03 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:live800.eic.org.cn:80]
2017/12/15 06:02:03 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:03 [Info]Proxy|VMess|Outbound: tunneling request to tcp:live800.eic.org.cn:80 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 128 but actually 241
2017/12/15 06:02:03 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 81 but actually 45
2017/12/15 06:02:03 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:03 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:03 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:04 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:05 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:05 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:05 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:05 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:05 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:05 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:05 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:05 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:05 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:05 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:05 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:05 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:05 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:05 [Info]Proxy|VMess|Encoding: failed to read response header > EOF
2017/12/15 06:02:05 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:05 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:05 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:07 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:07 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:07 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:07 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:07 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:07 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:07 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:07 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|VMess|Outbound: connection ends > Proxy|VMess|Encoding: unexpected response header. Expecting 45 but actually 216
2017/12/15 06:02:07 [Info]App|Proxyman|Inbound: connection ends > Proxy|Socks: connection ends > context canceled
2017/12/15 06:02:07 [Info]Proxy|Socks: TCP Connect request to tcp:ipv4.google.com:443
2017/12/15 06:02:07 [Info]App|Dispatcher|Default: taking detour [ws-via-ss] for [tcp:ipv4.google.com:443]
2017/12/15 06:02:07 [Debug]App|Proxyman|Outbound: proxying to ss
2017/12/15 06:02:07 [Info]Proxy|VMess|Outbound: tunneling request to tcp:ipv4.google.com:443 via tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:07 [Info]Transport|Internet|TCP: dailing TCP to tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:07 [Info]Proxy|Shadowsocks: tunneling request to tcp:VMESS_REMOTE_SERVER_ADDRESS_AND_PORT via tcp:SS_REMOTE_SERVER_ADDRESS_AND_PORT
2017/12/15 06:02:07 [Info]Proxy|VMess|Encoding: failed to read response header > EOF

Please attach access log. Access log is usually at '/var/log/v2ray/access.log' on Linux.

2017/12/15 06:01:59 tcp:<IP_ADDRESS>:61502 accepted tcp:template.need.sh:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61508 accepted tcp:lh3.googleusercontent.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61506 accepted tcp:clients5.google.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61511 accepted tcp:www.gstatic.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61509 accepted tcp:notifications.google.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61510 accepted tcp:ssl.gstatic.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61507 accepted tcp:fonts.gstatic.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61503 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61504 accepted tcp:play.google.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61505 accepted tcp:apis.google.com:443
2017/12/15 06:02:00 tcp:<IP_ADDRESS>:61512 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:01 tcp:<IP_ADDRESS>:61513 accepted tcp:template.need.sh:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61516 accepted tcp:fonts.gstatic.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61514 accepted tcp:clients5.google.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61515 accepted tcp:www.gstatic.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61517 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61518 accepted tcp:notifications.google.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61519 accepted tcp:lh3.googleusercontent.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61520 accepted tcp:play.google.com:443
2017/12/15 06:02:02 tcp:<IP_ADDRESS>:61521 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:03 tcp:<IP_ADDRESS>:61523 accepted tcp:apis.google.com:443
2017/12/15 06:02:03 tcp:<IP_ADDRESS>:61522 accepted tcp:ssl.gstatic.com:443
2017/12/15 06:02:03 tcp:<IP_ADDRESS>:61524 accepted tcp:live800.eic.org.cn:80
2017/12/15 06:02:05 tcp:<IP_ADDRESS>:61525 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:05 tcp:<IP_ADDRESS>:61526 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:07 tcp:<IP_ADDRESS>:61527 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:07 tcp:<IP_ADDRESS>:61528 accepted tcp:ipv4.google.com:443
2017/12/15 06:02:12 tcp:<IP_ADDRESS>:61529 accepted tcp:3.client-channel.google.com:443
2017/12/15 06:02:12 tcp:<IP_ADDRESS>:61530 accepted tcp:live800.eic.org.cn:80
2017/12/15 06:02:12 tcp:<IP_ADDRESS>:61531 accepted tcp:www.bitstamp.net:443
2017/12/15 06:02:13 tcp:<IP_ADDRESS>:61532 accepted tcp:3.client-channel.google.com:443 ```

Please review your issue before submitting.

8) Other configurations (such as Nginx) and logs.

The transport settings in an outbound will have no effect when the outbound is proxied to another one. Your ws-via-ss is equivalent to tcp-via-ss in the configuration. To make your ws-via-ss to work, you need to configure the same ws in ss as in ws-via-ss.
proxySettings only proxies the traffic from the outbound, not the way it gets transferred. It hijacks the connection before transporting happens.
Document will be update regarding this behavior.

So if we set up a client -> proxy1 -> proxy2 -> ... -> proxyn tunnel, only the stream setting of proxy1 is effective. If any of proxy2, proxy3, ..., proxyn requires a specific stream setting, there is no method to put it into the proxy chain in v2ray. It that correct?

No. Only the settings on the last outbound is effective. In another word, stream settings only take effect when there is an actual network connection.


Make the project REUSE compliant

See https://reuse.software/ for details.
The gist of the work is:

[ ] Convert all copyright headers in source code files to SPDX compliant versions
[ ] Add .license files for all other files
[ ] Add the compliance requirement to our contributing guidelines
[ ] Implement the REUSE Compliance Check in our GitHub Actions.

This seems useful. I'm just worried that the repository will be cluttered with .license files. Any thoughts @bast?

The only files I identified in mido that would require a .license file are:

mido.png
mido.svg
midi_time.svg

All other files are source code or allow some sort of comment where to place the SPDX statement.
I think its an acceptable tradeoff to make for licensing clarity.

Sounds good to me.

Should we use a Creative Commons license for these? I don't know if MIT makes sense for image files.

You're the copyright holder, you shall decide which license you see fit.
That being said, yes, a CC or CC-BY license would be more appropriate than the MIT.

CC-BY sounds about right. Is there one called "CC"? I couldn't find one.

I agree. We'll use CC-BY.
Aha, I didn't look for CC0. I thought there was one named "CC" but that's of course just the general term for Creative Commons so it wouldn't make sense.

It just occurred to me that the MIT isn't the best licence either for the documentation.
Should we also use the CC-BY-4.0?
ALso, what about using CC0 for configuration files which are not copyrightable since they are considered facts?

Since I was in the zone, I've gone ahead and did just that.
Don't fret letting me know if you want me to do something different.

TIL about https://reuse.software/! Thanks for the good suggestion!


Document the default behavior when --watch flag is not present

Describe the feature you’d like to be implemented
It would be nice to mention (maybe in --help, but definitely in docs) what exactly is being watched when --watch flag is not specified.
Is cabal file included in the watching by default? It seems to me that there are no reloads on cabal file changes (in which case this is a bug report). Is it all .hs files found in current directory?
List alternatives to the feature and their pros and cons
No response
Additional context
Thank you for opensourcing this great tool, I switched my project to it from ghcid and I'm excited it fixes many issues that I had with ghcid

Thanks for the ticket!
The short answer is that the default value is src. It's pretty unsophisticated. I thought I had a note explaining this somewhere but apparently I do not. Do you have somewhere you think this information should live?  I might create a new section in the user manual for it.
If a file argument is given (ghciwatch Foo.hs), the command executed is ghci Foo.hs. If neither a file argument nor --command are given, the command is cabal repl.
https://github.com/MercuryTechnologies/ghciwatch/blob/56db4fba3c8258bfac496b7885d3ab203d8f6f44/src/ghci/mod.rs#L132-L139
I also have a long-standing TODO to copy some of ghcid's logic for constructing a default command, which is listed here:
https://github.com/ndmitchell/ghcid/blob/e2852979aa644c8fed92d46ab529d2c6c1c62b59/src/Ghcid.hs#L142-L171

Do you have somewhere you think this information should live?

Good question.
Skimming the docs again I see it's actually mentioned in passing in the first example:
https://mercurytechnologies.github.io/ghciwatch/cli.html#examples
"Load cabal v2-repl and watch for changes in src:"
I would expand that to "watch for changes to *.hs files in src directory or any of its subdirectories (recursively)" (or whatever is actually true)
Originally I was looking for it under --watch flag's documentation
https://mercurytechnologies.github.io/ghciwatch/cli.html#--watch
because I'm used to optparse-applicative showing the defaults as part of the help message, e.g. it could be added as last sentence there..
--watch <PATH>
    A path to watch for changes.

    Directories are watched recursively. Can be given multiple times.

    **If not provided, the default behavior is as if `--watch src` was provided.**


Add the Win32_System_Console feature since it is used

In src/cargo/core/shell.rs windows_sys::Win32::System::Console is used but the feature is not present in Cargo.toml.
I found it while updating cargo-c.

@bors r+

:pushpin: Commit dfb4be81a84642d65b6128242dd9589182681025 has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit dfb4be81a84642d65b6128242dd9589182681025 with merge dcc47025991ca570bb930bb7e89a3d171cdfbba6...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing dcc47025991ca570bb930bb7e89a3d171cdfbba6 to master...

I'm not clear why this was needed.  The feature seems to be enabled by is-terminal. Although it is good to make sure that all used features are listed, why was this causing a problem for you?

I'm using cargo as library and apparently I do not have anything that requires that feature.


Return team stats and names PART 1

Need to return team information from the JSON.
Honestly just make another python function for this.
Functions

Create a function to return team statistics
Create a function to return team name from those statistics

Team names was done here 1c8d8a55ada74e9bfa9b0d961ed1ac4224f15fdf


Long running tests failed: Validate_rad_bicep_publish_is_publishing_the_file_to_the_given_target

Steps to reproduce
long-running tests
Observed behavior
=== FAIL: test/functional-portable/cli/noncloud Test_RecipeCommands/deploy_testdata/corerp-resources-recipe-env.bicep/Validate_`rad_bicep_publish`_is_publishing_the_file_to_the_given_target (2.28s)

...

    cli.go:341: [rad] Building ../../../testrecipes/test-bicep-recipes/corerp-redis-recipe.bicep...
    cli.go:341: [rad] Failed to publish Bicep file "../../../testrecipes/test-bicep-recipes/corerp-redis-recipe.bicep" to "localhost:5000/dev/test-bicep-recipes/redis-recipe:test-1722435384-742" Cause: Head "https://localhost:5000/v2/dev/test-bicep-recipes/redis-recipe/manifests/sha256:a632e9ac283dd7b8fd17b4f7510550b0e4675ab8cb8f72764f2144e3ad31cb9e": dial tcp [::1]:5000: connect: connection refused.

Desired behavior
test should pass
Workaround
No response
rad Version
7/31/24
Operating system
No response
Additional context
No response
Would you like to support us?

[ ] Yes, I would like to support you

AB#12921

Could you also share an example workflow run @willdavsmith? Thanks!

Fixed by https://github.com/radius-project/radius/pull/7779.


Fix brew build

Seems the brew-macos test job has broken down after 0.15.1 release. Instead of cloning the repo from git it fetches the tar ball of the release and fails on the mismatching  checksum. Why did it start fetching release tar ball? Weird.

This seems to have fixed itself after I merged a PR (despite the failing brew-macos test job, but it is not mandatory). I suppose the problem might be when main HEAD == the git tag for v0.15.1 or whatever version was most recently released? Then maybe brew handles this differently? We'll notice the next time we make a release I suppose. Even if so, I'm not sure it's worthwhile trying to fix. Homebrew is... difficult to work with. Closing issue.

Nope, it's back. So it just intermittently went through scratches head. Very weird this stuff

I really don't feel like spending time on this. I think Homebrew is quite terrible. The whole build process is a little too opinionated and essentially must run through multiple GitHub Action workflows. We need things we can run more locally to hack it up the way we want. I think this is the epitome of bad devops style.
The current process is instead to not continuously test the Homebrew Formula, rather we only use / test it once we make an actual release. In the past we had a lot of failures because all library dependencies of Acton were pulled in as Homebrew dependencies, for example, the Acton RTS uses libuv, so we pulled in libuv as a Homebrew dependency and then copied the static archive over into the Acton distribution. That meant we had lots of dependencies and as our stdlib was evolving, those dependencies would change. Now we have taken a different approach so all our dependencies are included as sources in the Acton distribution and we pull them down via git during the build.  With this change the need to test the Homebrew Formula itself has also drastically been reduced. I don't feel we have a need to revive this but can rather let things remain as-is. The Homebrew test job was also rather slow, so from that perspective it's nice to skip it.
The latest issue we've had is that of GHC mismatches but I believe I've addressed this with #1627 so it really should start working quite reliably now.
Closing this issue.


Copy over runfiles library from Bazel

This uses root_symlinks to preserve the fixed runfiles path at which the library must be available.
Users will see an error if their runfiles trees contain both @bazel_tools//tools/bash/runfiles and @rules_shell//shell/runfiles with a Bazel version in which the former is not yet an alias to the latter. This ensures that conflicting versions can't be mixed.
In fact, strict runfiles collision checking will be applied to all targets depending on @rules_shell//shell/runfiles, which may break some builds. If it turns out to be too breaking, we could add private API to ctx.runfiles that allows to disable the strict check from Starlark.

@meteorcloudy @Wyverald I'm curious to hear what you think about the strict conflict checking introduced by this PR.

I don't really understand the implication of this. Will we be removing the bash runfiles library from @bazel_tools? (I guess not completely, becuase it's hard to source the runfiles library from rules_shell.) Will we be leaving an alias behind?
Also what does "strict conflict checking" mean here?

I don't really understand the implication of this. Will we be removing the bash runfiles library from @bazel_tools? (I guess not completely, becuase it's hard to source the runfiles library from rules_shell.) Will we be leaving an alias behind?

We only need to leave an alias behind for backwards compatibility.
Sourcing the runfiles library from rules_shell is possible with the exact same init code due to the trick with root symlinks (confirmed by the BCR test module).

Also what does "strict conflict checking" mean here?

Conflicts between runfiles (i.e. different runfiles mapping to the same rlocationpath) are usually silently ignored by Bazel, but as soon as symlinks or root symlinks are added via Starlark, they result in an error.

Thanks for the explanation!

Conflicts between runfiles (i.e. different runfiles mapping to the same rlocationpath) are usually silently ignored by Bazel, but as soon as symlinks or root symlinks are added via Starlark, they result in an error.

Is this behavior by design? Also, to confirm, regarding this part in your PR desciption:

Users will see an error if their runfiles trees contain both @bazel_tools//tools/bash/runfiles and @rules_shell//shell/runfiles with a Bazel version in which the former is not yet an alias to the latter. This ensures that conflicting versions can't be mixed.

there's nothing special about these two targets, right? Any conflict in any runfiles will cause an error, whereas before they would only do so if some other transitive dep specified [root] symlinks in their runfiles.
This PR LGTM given my very limited understanding, but I also kind of want @lberki to give a go-ahead.

Yes, the strict check in the case of (root) symlinks has been an explicit choice: https://github.com/bazelbuild/bazel/blob/3ef2abcb3fa81618a93b6c21629f40867dc46528/src/main/java/com/google/devtools/build/lib/analysis/starlark/StarlarkRuleContext.java#L1083

there's nothing special about these two targets, right? Any conflict in any runfiles will cause an error, whereas before they would only do so if some other transitive dep specified [root] symlinks in their runfiles.

That's correct. Although I just found the private skip_conflict_checking parameter of ctx.runfiles and I will use that for backwards compatibility.

I haven't read the pull request, but if that's the question, moving the runfiles library out of the Bazel repository is a fantastic idea. Do I need to engage further?

I haven't read the pull request, but if that's the question, moving the runfiles library out of the Bazel repository is a fantastic idea. Do I need to engage further?

The question was more about whether the new strict conflict checking is kosher, but @fmeum made the change to opt out of it so this PR is fully safe now.

Yes, the strict check in the case of (root) symlinks has been an explicit choice: https://github.com/bazelbuild/bazel/blob/3ef2abcb3fa81618a93b6c21629f40867dc46528/src/main/java/com/google/devtools/build/lib/analysis/starlark/StarlarkRuleContext.java#L1083

I was curious and did a bit more digging, and apparently this has been there since at least 2018 (which is basically time immemorial): https://github.com/bazelbuild/bazel/blame/e24270826804ced8adb819e2078f472c8571b5df/src/main/java/com/google/devtools/build/lib/analysis/skylark/SkylarkRuleContext.java#L1007