Issue with custom headers

Not sure what I'm doing wrong here, but I want to have token claim info available between each of the subdomains on my server. Below is my sanitized Caddyfile that has the relevant sections:
https://example.net {
        route /auth* {

                realip {
                       header "X-Forwarded-For"
                        from cloudflare
                        maxhops 5
                }

                encode gzip

                header {
                        header_up X-Forwarded-For {>CF-Connecting-IP}
                        Strict-Transport-Security max-age=31536000;
                        X-Content-Type-Options nosniff
                        X-Frame-Options DENY
                        Referrer-Policy no-referrer-when-downgrade
                        X-XSS-Protection 1
               }

                auth_portal {
                        path /auth
                                backends {
                                        local_backend {
                                                method local
                                                path /authdb/users.json
                                                realm local
                                                }
                                        }
                        cookie_domain example.net
                        jwt {
                                token_name access_token
                                token_secret TOKEN_SECRET
                                token_issuer TOKEN_ISSUER
                                token_lifetime 86400
                        }

                        ui {
                                links {
                                        "Subdomain" https://subdomain.example.net
					"Subdomain2" https://subdomain2.example.net
				}
			}
                }
        }

        route {
                realip {
                        header "X-Forwarded-For"
                        from cloudflare
                        maxhops 5
                }

                encode gzip

                header {
                        header_up X-Forwarded-For {>CF-Connecting-IP}
                        Strict-Transport-Security max-age=31536000;
                        X-Content-Type-Options nosniff
                        X-Frame-Options DENY
                        Referrer-Policy no-referrer-when-downgrade
                        X-XSS-Protection 1
                }
                redir https://example.net/auth 302
        }

        tls my_email {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        log {
                format formatted
                output file /authdb/access.log {
                        roll_size 50MiB
                        roll_keep 5
                        roll_keep_for 48h
                        }
                }
}

https://subdomain.example.net {
        route {
        jwt {
                primary yes
                enable claim headers
                trusted_tokens {
                        static_secret {
                                token_name access_token
                                token_secret TOKEN_SECRET
                                token_issuer TOKEN_ISSUER
                                }
                        }
                auth_url https://example.net/auth?redirect_url=https://subdomain.example.net
                allow roles user
                allow roles superadmin
                }
        }
        tls my_email {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        reverse_proxy <IP_ADDRESS>:32400

        encode gzip

        header {
                request_header -Referer
                header_upstream X-Forwarded-For {>CF-Connecting-IP}
                Strict-Transport-Security max-age=31536000;
                X-Content-Type-Options nosniff
                X-Frame-Options DENY
                Referrer-Policy no-referrer-when-downgrade
                X-XSS-Protection 1
        }
}

https://subdomain2.example.net {

        route {
                jwt
        }

        tls my_email {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        reverse_proxy <IP_ADDRESS>:9091

        encode gzip

        header {
                request_header -Referer
                header_upstream X-Forwarded-For {>CF-Connecting-IP}
                X-Token-Subject {userIdentity}
                Strict-Transport-Security max-age=31536000;
                X-Content-Type-Options nosniff
                X-Frame-Options DENY
                Referrer-Policy no-referrer-when-downgrade
                X-XSS-Protection 1
        }
}

As you can see, I first tried just adding "enable claim headers" to the primary jwt instance but that wasnt working, so I have been trying to manually add the X-Token-Subject header to subdomain2 but cant see to narrow down the syntax of the user_identity variable? Interestingly when I look at the logs for a request, the common_log format shows the correct username but im not sure what field that's referencing.

@kirsch33 , let's do it one by one:
https://subdomain.example.net {
        route {
        jwt {
                primary yes
                enable claim headers
                trusted_tokens {
                        static_secret {
                                token_name access_token
                                token_secret TOKEN_SECRET
                                token_issuer TOKEN_ISSUER
                                }
                        }
                auth_url https://example.net/auth?redirect_url=https://subdomain.example.net
                allow roles user
                allow roles superadmin
                }

Here, you need to replace:
auth_url https://example.net/auth?redirect_url=https://subdomain.example.net

with:
auth_url https://example.net/auth

The plugin knows how to create the redirect.

@kirsch33 , also, what kind of errors do you get?

@kirsch33 , next ... the following needs to be rewritten as:
https://subdomain2.example.net {

        route {
                jwt
        }

        tls my_email {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        reverse_proxy <IP_ADDRESS>:9091

        encode gzip

        header {
                request_header -Referer
                header_upstream X-Forwarded-For {>CF-Connecting-IP}
                X-Token-Subject {userIdentity}
                Strict-Transport-Security max-age=31536000;
                X-Content-Type-Options nosniff
                X-Frame-Options DENY
                Referrer-Policy no-referrer-when-downgrade
                X-XSS-Protection 1
        }
}

to:
https://subdomain2.example.net {
        encode gzip

        tls my_email {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        header {
                request_header -Referer
                header_upstream X-Forwarded-For {>CF-Connecting-IP}
                X-Token-Subject {userIdentity}
                Strict-Transport-Security max-age=31536000;
                X-Content-Type-Options nosniff
                X-Frame-Options DENY
                Referrer-Policy no-referrer-when-downgrade
                X-XSS-Protection 1
        }

        route {
                jwt
                reverse_proxy <IP_ADDRESS>:9091
        }
}

@kirsch33 , also, try removing header config. You need to go to a very basic config. Then, scale up. My concerns are header and encoding.
        header {
                request_header -Referer
                header_upstream X-Forwarded-For {>CF-Connecting-IP}
                X-Token-Subject {userIdentity}
                Strict-Transport-Security max-age=31536000;
                X-Content-Type-Options nosniff
                X-Frame-Options DENY
                Referrer-Policy no-referrer-when-downgrade
                X-XSS-Protection 1
        }

I think the reverse proxy needs to be inside a route, but I could be wrong.

Hey Paul, I have taken all of your advice including complete removal of the encoding and header sections to no avail. Here is my updated and sanitized Caddyfile:
https://example.net {

        tls MY_EMAIL {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        route /auth* {
                realip {
                       header "X-Forwarded-For"
                        from cloudflare
                        maxhops 5
                }

                auth_portal {
                        path /auth
                                backends {
                                        local_backend {
                                                method local
                                                path /authdb/users.json
                                                realm local
                                                }
                                        }
                        cookie_domain example.net
                        jwt {
                                token_name access_token
                                token_secret TOKEN_SECRET
                                token_issuer TOKEN_ISSUER
                                token_lifetime 86400
                        }

                        ui {
                                links {
                                        "Subdomain1" https://subdomain1.example.net
                                        "Subdomain2" https://subdomain2.example.net
                                }
                        }
                }
        }

        route {
                realip {
                        header "X-Forwarded-For"
                        from cloudflare
                        maxhops 5
                }

                redir https://example.net/auth 302
        }

        log {
                format formatted
                output file /authdb/access.log {
                        roll_size 50MiB
                        roll_keep 5
                        roll_keep_for 48h
                }
        }
}

https://subdomain1.example.net {

        tls MY_EMAIL {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        route {
                jwt {
                        primary yes
                        enable claim headers
                        trusted_tokens {
                                static_secret {
                                        token_name access_token
                                        token_secret TOKEN_SECRET
                                        token_issuer TOKEN_ISSUER
                                        }
                                }
                        auth_url https://example.net/auth
                        allow roles user
                        allow roles superadmin
                }

                reverse_proxy <IP_ADDRESS>:32400
        }
}

https://subdomain2.example.net {

        tls MY_EMAIL {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        route {
                jwt

                reverse_proxy <IP_ADDRESS>:9091
        }
}

The above Caddyfile, in my case, returns a log resembling the following when accessing subdomain2.example.net:
{"level":"info","ts":1606113558.8473835,"logger":"http.log.access","msg":"handled request","request":{"remote_addr":"CLOUDFLARE_IP","proto":"HTTP/1.1","method":"POST","host":"subdomain2.example.net","uri":"/subdomain2/rpc","headers":{"Sec-Fetch-Dest":["empty"],"Referer":["https://subdomain2.example.net/subdomain2/web/"],"Cf-Ray":["CF_RAY"],"Content-Length":["439"],"X-Requested-With":["XMLHttpRequest"],"Origin":["https://subdomain2.example.net"],"Sec-Fetch-Site":["same-origin"],"Sec-Fetch-Mode":["cors"],"Accept-Language":["en-US,en;q=0.9"],"Cookie":["__cfduid=CFDUID; access_token=ACCESS_TOKEN"],"X-Forwarded-Proto":["https"],"Accept":["application/json, text/javascript, */*; q=0.01"],"Cf-Request-Id":["CF_REQUEST_ID"],"Cdn-Loop":["cloudflare"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cf-Connecting-Ip":["ACTUAL_IP"],"Connection":["Keep-Alive"],"Cf-Ipcountry":["US"],"X-Forwarded-For":["ACTUAL_IP"],"Content-Type":["json"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36"],"Accept-Encoding":["gzip"]},"tls":{"resumed":false,"version":772,"cipher_suite":4867,"proto":"","proto_mutual":true,"server_name":"subdomain2.example.net"}},"common_log":"CLOUDFLARE_IP - MY_EMAIL [23/Nov/2020:06:39:18 +0000] \"POST /subdomain2/rpc HTTP/1.1\" 200 76","duration":0.002014479,"size":76,"status":200,"resp_headers":{"Content-Type":["application/json; charset=UTF-8"],"Date":["Mon, 23 Nov 2020 06:39:18 GMT"],"Content-Length":["76"],"Content-Encoding":["gzip"],"Server":["Caddy","Subdomain2"]}}

Also, I forgot to mention, as you can see it does manage to put MY_EMAIL in the common_log format of the log but thats the only place I see it--and regardless I'm not sure if thats the "enable claim headers" doing that or just default behavior considering I dont see any of the other headers such as "X-Token-Subject"

@kirsch33 are you able to browse subdomain2.example.net? Are you able to get to reverse proxy or you are brought back to auth endpoint?
We will get to headers later... please add ‘caddy-trace’ plugin and insert it between jwt and reverse-proxy lines. In the output, you will see the headers being passed from jwt to reverse-proxy plugins.
https://github.com/greenpau/caddy-trace
Once you collect trace, please attach it here in a text file.

@greenpau yes i am able to access and use subdomain2.example.net after authenticating via the portal. I will add caddy-trace, rebuild and follow up shortly

@greenpau well, were getting somewhere. i added this line:
trace tag="GWS" response_debug=yes
which returned this log line:
{"level":"debug","time":"2020-11-24T02:18:43.622Z","msg":"debugging request","request_id":"2036a77e-c748-4445-8108-b0fb61060643","direction":"incoming","tag":"GWS","method":"POST","proto":"HTTP/2.0","host":"subdomain2.example.net","uri":"/subdomain2/rpc","remote_addr_port":"CLOUDFLARE_IP","remote_addr":"CLOUDFLARE_IP","remote_port":CLOUDFLARE_PORT,"content_length":24,"cookie_count":2,"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36","referer":"https://subdomain2.example.net/subdomain2/web/","cookies":[{"Name":"__cfduid","Value":"CFDUID","Path":"","Domain":"","Expires":"0001-01-01T00:00:00Z","RawExpires":"","MaxAge":0,"Secure":false,"HttpOnly":false,"SameSite":0,"Raw":"","Unparsed":null},{"Name":"access_token","Value":"ACCESS_TOKEN","Path":"","Domain":"","Expires":"0001-01-01T00:00:00Z","RawExpires":"","MaxAge":0,"Secure":false,"HttpOnly":false,"SameSite":0,"Raw":"","Unparsed":null}],"query_params":{},"headers":{"Accept":"application/json, text/javascript, */*; q=0.01","Accept-Encoding":"gzip","Accept-Language":"en-US,en;q=0.9","Cdn-Loop":"cloudflare","Cf-Connecting-Ip":"ACTUAL_IP","Cf-Ipcountry":"US","Cf-Ray":"CF_RAY","Cf-Request-Id":"CF_REQUEST_ID","Cf-Visitor":"{\"scheme\":\"https\"}","Content-Length":"24","Content-Type":"json","Origin":"https://subdomain2.example.net","Referer":"https://subdomain2.example.net/subdomain2/web/","Sec-Fetch-Dest":"empty","Sec-Fetch-Mode":"cors","Sec-Fetch-Site":"same-origin","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36","X-Forwarded-For":"ACTUAL_IP","X-Forwarded-Proto":"https","X-Requested-With":"XMLHttpRequest","X-Token-Subject":"akirsch","X-Token-User-Email":"MY_EMAIL","X-Token-User-Roles":"superadmin guest anonymous"},"form":{}}
which obviously includes the correct headers. no the question is, how do I access these without trace? not sure what I'm doing to cause them to be 'hidden' otherwise

@kirsch33 , now, what header key and values do you need to pass to reverse-proxy for your setup to work?

which obviously includes the correct headers. now the question is, how do I access these without trace? not sure what I'm doing to cause them to be 'hidden' otherwise

@kirsch33 , the headers you see with trace are exactly the same that are being password to the reverse proxy.
There was a similar issue here.
The PHP backend got:
REMOTE_USER = bdda81e3-f768-4094-be09-e985955882fe
HTTP_X_TOKEN_SUBJECT = andrew
HTTP_X_TOKEN_USER_EMAIL =<EMAIL_ADDRESS>HTTP_X_TOKEN_USER_ROLES = superadmin guest anonymous

@greenpau for my current project I just need to be able to reference the current user username, so "X-Token-Subject"... but heres a related question. the documentation for caddy-auth-jwt says "the plugin passes the user identity identifier back to the Caddy server" meaning I could just set "user_identity subject" which should also make this info available, but I'm not sure how to get that working either?
Both would, for me, arrive at the same solution...just trying to make sure I understand everything going on

@kirsch33 , I think I understood your problem... pls correct me if I am wrong.
❗  use user_identity Caddyfile directive.
Please read: https://github.com/greenpau/caddy-auth-jwt/blob/main/README.md#user-identity

the documentation for caddy-auth-jwt says "the plugin passes the user identity identifier back to the Caddy server" meaning I could just set "user_identity subject" which should also make this info available, but I'm not sure how to get that working either?

@kirsch33 , upon successful authentication, the building of userIdentity starts
https://github.com/greenpau/caddy-auth-jwt/blob/4fe3ff57c5d73bc1f753ec477b38cbe37f99275f/pkg/auth/authorizer.go#L201-L251
At that moment, when enable claim headers is used, the header is being set.
https://github.com/greenpau/caddy-auth-jwt/blob/4fe3ff57c5d73bc1f753ec477b38cbe37f99275f/pkg/auth/authorizer.go#L245-L247
Finally, the previously set headers make its way to UserIdentity.Metadata:
https://github.com/greenpau/caddy-auth-jwt/blob/4fe3ff57c5d73bc1f753ec477b38cbe37f99275f/plugin.go#L73-L77

the user identity identifier

Next, the identifier here is NOT Metadata, but rather ID. The ID is being generated by the plugin
https://github.com/greenpau/caddy-auth-jwt/blob/4fe3ff57c5d73bc1f753ec477b38cbe37f99275f/plugin.go#L70-L72
The ID depends on the following calculation:
https://github.com/greenpau/caddy-auth-jwt/blob/4fe3ff57c5d73bc1f753ec477b38cbe37f99275f/pkg/auth/authorizer.go#L215-L225
If you want to set the identity, then use user_identity Caddyfile directive :-)
https://github.com/greenpau/caddy-auth-jwt/blob/b55aecc559b9b62fd0036be2494574a9893c8aa0/caddyfile.go#L280-L284

@kirsch33 , it is great that you are asking these questions! 👍 This would help building a better README.md file.

@kirsch33 , you could also create a PR and improve documentation yourself!

@greenpau  i appreciate that, because i feel like youre explaining things very well I just am so new to all of this it takes me a while to understand. once I get a grasp on things id love to help anyway I can!
its still not completely clear to me. user_identity is built regardless of if enable claim headers is specified, but is that in anyway accessible from local Caddyfile? as in, if I wanted to specify my own downstream header:
header_down Custom-Username-Header {user_identity_variable_from_plugin}
im asking this because even if dont specify enable claim headers then I can see still my token email address in the common_log output...meaning its getting that info somehow?
completely separate from the question above, if i use enable claim headers why is it that i'm only able to see the token headers using the trace plugin? as in, standard info level caddy logs do not display them so I dont think my downstream services would be able to see them either.

@greenpau to expand on part 1 above...if I set user_identity subject inside jwt { for subdomain2, i can actually see the username (or subject) in the common_log section of a standard Caddy info level log line...which is why it seems like it seems like it should be accessible somehow from local Caddyfile (this is without enable claim headers)
interestingly to get the behavior above you have to set user_identity subject inside subdomain2 jwt { ...if you place it in the primary jwt instance you get the token email instead for a subdomain2 log line.

interestingly to get the behavior above you have to set user_identity subject inside subdomain2 jwt { ...if you place it in the primary jwt instance you get the token email instead for a subdomain2 log line.

@kirsch33 , this looks like a bug ... non-primary instance issue

its still not completely clear to me. user_identity is built regardless of if enable claim headers is specified, but is that in anyway accessible from local Caddyfile? as in, if I wanted to specify my own downstream header:
header_down Custom-Username-Header {user_identity_variable_from_plugin}

@kirsch33 , idk the answer to this. This is a good question to ask in https://caddy.community

@kirsch33 , to sum it up. The primary jwt instance config does not propagate to non-primary jwt instance with respect to enable claim headers Caddyfile directive.
As a workaround, please specify it in the non-primary jwt instance:
https://subdomain2.example.net {

        tls MY_EMAIL {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        }

        route {
                jwt {
                    enable claim headers
                }

                reverse_proxy <IP_ADDRESS>:9091
        }
}

Do you see the headers being passed after that change?

@greenpau i can confirm that after making that change i still only see the headers if I use the trace plugin. without trace (aka just normal caddy logs) do not show the headers.

@greenpau actually just figured out that if I set log levels to debug i can see the headers--even without trace
this can be closed at this point. thanks for hanging in there with me Paul.

@kirsch33 , any time! Will keep it open until i have a chance looking into nonprimary instance issue.


pgadmin4: 8.8 -> 8.9

This also fixes a startup error for a fresh instance
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[x] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I've proposed a pr yesterday already #323989

Thank you for your update. Since our changes are identical, I'm fine closing either PR

Snap, why didn't I see that?
I don't care, I just did this to see if it fixed my startup error (it did).


Added SLDS Slider

This adds the SLDS Slider component to the component library.
Fixes #1314
@interactivellama

Pull Request Review checklist (do not remove)

[x] Review the appropriate Storybook stories. Open http://localhost:9001/.
[ ] Review tests are passing in the browser. Open http://localhost:8001/.
[x] Review markup conforms to SLDS by looking at snapshot strings.
[ ] Add year-first date and commit SHA to last-slds-markup-review in package.json and push.
[x] Request a review of the deployed Heroku app by the Salesforce UX Accessibility Team.
[ ] Add year-first review date, and commit SHA, last-accessibility-review, to package.json and push.
[x] While the contributor's branch is checked out, run npm run local-update within locally cloned site repo to confirm the site will function correctly at the next release.

@interactivellama should be good. Let me know if I missed anything.


Create backupCertsDir before running recert

Fixes this error:
failed to run recert tool container: Error: statfs /var/tmp/backupCertsDir: no such file or directory\n: exit status 125"

/cc @leo8a
/cc @donpenney

Closing, since https://github.com/openshift-kni/lifecycle-agent/pull/101 also fixes this


release-21.1: cli/zip: assorted improvements

PR: https://github.com/cockroachdb/cockroach/pull/64705
From release notes:

The format of the informational messages printed by cockroach debug zip now make it clearer which step is ongoing, when concurrent execution is enabled. [#64705][#64705] {% comment %}doc{% endcomment %}

Closing, as this doesn't need additional documentation.


Obsoletion request: GO:0036212  contractile ring maintenance

Please provide as much information as you can:

[ ] 1. GO term ID and Label GO:0032189  maintenance of actomyosin contractile ring localization
Any process in which an actomyosin contractile ring is maintained in a location and prevented from moving elsewhere.

Reason for deprecation

[x] The reason for obsoletion is that this represents a phenotype.
(Once the ring is positioned it does not move in a normal situation)
0 annotations

[ ] 2.  * GO term ID and Label GO:0032187   actomyosin contractile ring localization

Reason for deprecation

[x]  The term is redundant with other terms  in a different branch
The process in which a contractile ring is positioned or maintained in a specific location, in the context of cytokinesis that takes place as part of a cell cycle.
Consider "cytokinesis division site positioning"
FlyBase2
CGD 1

[ ] 3. * GO term ID and Label GO:0031566   actomyosin contractile ring maintenance

Reason for deprecation

[x]  The term is redundant with other terms  in a different branch
The  contractile ring doesn't assembly and then not dissassembly, the assembly is "dynamic" , so  GO:0031566   actomyosin contractile ring maintenance can be annotated  (replaced by)  GO:0000915   actomyosin contractile ring assembly

[ ] PomBase 16

[ ] 4. * GO term ID and Label GO:0036212   contractile ring maintenance

Reason for deprecation

[x]  The term is redundant with other terms in a different branch
Consider  GO:0000915   actomyosin contractile ring assembly
Cacao 1

Are there mappings and cross references to this term? (InterPro, Keywords; check QuickGO cross-references section)

Is this term in a subset? (check the AmiGO page for that term)

Any other information

Checklist for ontology editor
Check term usage and metadata in Protégé

[ ] check term usage in the ontology
[x] check internal mappings: RHEA, EC, MetaCyc
[x] check subset usage
[x] check taxon constraints

Check annotations

[x] create Annotation Review spreadsheet

https://docs.google.com/spreadsheets/d/1nKlwFfm8vXAPz5sJyPtGb16YXE70JupOpAMr1Mx2ytc/edit#gid=0

Instructions: https://wiki.geneontology.org/Annotation_Review_Request

[x] https://github.com/geneontology/go-annotation/issues/4646

[x] find external mappings (via IEAS), include in obsoletion notice

[x] tag curators in Annotation Review ticket. Responsible annotator for each group: https://github.com/geneontology/go-site/blob/master/metadata/group-contacts.csv

Notification

[x] create obsoletion announcement
[x] announce to GO friends<EMAIL_ADDRESS>[ ] paste the text in the ontology ticket

presumably these are inherited?
GO:0031566 | actomyosin contractile ring maintenance | Only in Taxon | 2759 | Eukaryota |
GO:0032187 | actomyosin contractile ring localization | Only in Taxon | 2759 | Eukaryota

Hi @pgaudet  I'm stuck on this one.
I removed the 2 taxon constraints and checked in the file and did a pull request on the file.
I went to run the other thing that is needed, but I don't understand the instructions.
https://wiki.geneontology.org/Adding_Taxon_Restrictions
Can you advise? thanks

Taxon constrains have disappeared for me
Will go ahead and obsolete
GO:0036212 contractile ring maintenance
GO:0032187 actomyosin contractile ring localization
GO:0032189 maintenance of actomyosin contractile ring localization
GO:0031566 actomyosin contractile ring maintenance |

I forgot
GO:1904789 regulation of mitotic actomyosin contractile ring maintenance
but it is only used by PomBase for 2 annotations so I will obsolete it here.

Also did the name /def tweaks approved in
https://github.com/geneontology/go-ontology/issues?q=is%3Aissue+is%3Aopen+mitotic+actomyosin+contractile+ring+maintenance


have mulitiply themes and override views not work

'view' => [
'theme' => [
//'basePath' => '@app/views/themes/basic',
//'baseUrl' => '@web/themes/basic',
'pathMap' => [
'@dektrium/user/views' =><EMAIL_ADDRESS>'@app/views'=>'@app/views/themes/basic',
			],
		],
	],

'user' => [
'class' => 'dektrium\user\Module',
'enableUnconfirmedLogin' => true,
'confirmWithin' => 21600,
'cost' => 12,
'modelMap' => [
'User' => 'backend\models\AdminUser',
'Profile'=>'backend\models\AdminProfile',
'Token'=>'backend\models\AdminToken',
],
'controllerMap' => [
'security' => 'backend\controllers\user\SecurityController'
],
'admins' => ['admin'],
'mailer'=>[
<EMAIL_ADDRESS>]
],
wether you change any value of '@dektrium/user/views'=>'xxx',the view file will not be override and not give some errors  or exceptions show

will show only

'@dektrium/user/views' =><EMAIL_ADDRESS>you don't need to add a.php here. It should just point the directory with overriden views.


#1732 Making UserManager Implement IUserManager, initia…

…l code changes.  I can't get the tests to run on my machine, so I'm trying to see what happens in the pull request...

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: jholovacs sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


𝐌𝐚𝐭𝐜𝐡 𝐌𝐚𝐤𝐢𝐧𝐠

🎮 Game Request
Feature
I created a new game, called  "𝐌𝐚𝐭𝐜𝐡 𝐌𝐚𝐤𝐢𝐧𝐠", in this game, there is a Hit Value, which ranges from 0 to 9, and every time the value of the hit gets changed.
Now the task is to match the hit value to all the options, here options are also changing every time. And there is a time constraint for 60 Seconds.
If you can match it, you will get 10 Points, if not then the game gets ended.
Point down the features
Game points
For Correct Matching -  +10 Points.
For Incorrect Matching - Game Over.
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @Kiran-pro2001 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hey @Kiran-pro2001! 🙂
It seems like you are not following proper guidelines !! 👀
Read documentation properly !!🙏
If you have any queries reach out to us on Discord🕹 .

Hey @Kiran-pro2001 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇

/assign


[Suggestion][SFX] Suggestions for TTS

Hi!
I have some suggestions/requests for the SFX cog:

Have the bot say the name of the person that typed in the tts channel like the Hawking the bot does.
An option to turn off the "you are not in a vc" message.
When someone posts a link/image, the bot says "[Name] posted a link/image"

Thanks for the cog, its very helpful!

This definitely will not be default behavior, however it makes sense to add it as an option for the server admins/mods.
I don't think this is the best idea to be included because for TTS you really need to be in the VC to be able to use it well since you need to know the context of the conversation, and I think SFX will just be abused a lot.
Good idea. I think what I will do is piggyback of the settings from your first suggestion on whether or not to say the user's name, though.

Above will be implemented in v7.1.0.


Cannot create an account with email

Describe the bug
When attempting to create an account with an email address, the email is not sent, and an error appears in the console.
To Reproduce
Steps to reproduce the behavior:

Go to the account creation page;
Select 'Baptized brother';
Select 'Continue with Email';
Write some Email;
See the error.

Expected behavior
Should send a confirmation email without errors.
Screenshots

Desktop (please complete the following information):

Fedora Workstation 41

Additional context
....

The error occurs when trying to continue with Google as well

Hello @fschein, sorry for the inconvenience this caused. The restart of the server to support the changes takes longer than expected. I’ll let you know when it’s online. Thank you.

No problem. Thanks for the quick response!

It is back online now @fschein. Thanks for your patience.


Icon buttons all have the same id

What is affected?
Component
Description

Reproduction
When using  filled or standard, google flags a warning that they all have the same id. Can this just be removed? They don't need to have an id at all.
Workaround
Tried to add my own id's to override, but unable to. No work around available.
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
"@material/web": "^1.0.1",
Browser/OS/Node environment
Browser: Chrome 119
Node: v18.16.1
Stack: Nuxt 3.8.0

I believe this is working as intended. IDs are scoped to the nearest document or shadow root, so the IDs are unique within the component's shadow dom.
Are you using any tooling to remove the shadow dom?

Closing since this is working as intended


Inquiry about Google Summer of Code Application

I am a Novice Open Source Programmer, I wanted to Inquire about the Possibilities of Application for Google Summer of Code with this Repo.

Dear @iamhardikat11, thank you for your interest in the project! :) The project development is paused for the moment, so most likely we won't be part of GSoC this year.

Ok.


add Segment for track user behavior

Coverage decreased (-0.8%) to 38.532% when pulling ba60143ee9308d6a54cb312c4a60d660f8675a18 on alvita:segment into 7ce6783eb9517ab2ac4d0de4b44b2432e4d03849 on ringcentral:dynamics-1.1.1.

Coverage decreased (-0.8%) to 38.532% when pulling 7bad2fefff77b099cae36c2ec83eb29ad19f703e on alvita:segment into 7ce6783eb9517ab2ac4d0de4b44b2432e4d03849 on ringcentral:dynamics-1.1.1.


Slack Channel Reorganization

Steps

Assignees - assign to community members responsible for work, leave blank if unknown
Add labels -  specify the state of item (ex. 'to do') and work group that is working on the issue (purple labels)
Project - assign to 'Baseline Outreach team' project
Milestone - add to '2022 Outreach Items' milestone
Complete the fields below

Item

Baseline Slack needs to be updated to remove duplicate channels and follow an optimized structure.
Description

Baseline Slack currently has ~50 slack channels, which contains a majority of unused or duplicate channels. The slack channel should be welcoming, intuitive, and easy to navigate for community members.
Definition of 'Done'

[x] Old channels archived
[x] New channels created/updated

Steps

[x] Outline proposal for channels to retain
[x] Update community of change
[x] Archive channels that are no longer needed
[x] Finalize remaining channels with group
[ ] Rename / create new channels for the final list
[ ] Update community of completion

Updates
Issue comments will be used for logging updates and labels will be used for current tstatus and work group responsible for current stage.
Grants
Outreach work items that are related to an approved grant project require updates by the 1st of each month by adding a comment on this issue with a detailed update on progress, roadblocks, and any comments.

2/28/22:

Sonal will complete tasks above

Notes for Outreach call added here, need to make final decision on channel numbering

3/28/22:
Actions

Sonal will correct naming conventions of channel
Sonal will check on automation for slack channel,
Sonal will check on bots for spam messages (typically from bridged channels)
Sonal will request Discord & Telegram admin access from Hudson to look into^

Notes

JW: proposal to remove bridge or properly tend to it
Bot for responding to token related/spam

Item has been complete, slack has been reorganized


Could you surport AIMP ?

love your OpenLyrics so much . Hope your plugin can surport for AIMP .
Could you build new project for it ? love you so much .

No. This project is strictly confined to being a plugin for fb2k.
If you want similar functionality in another player, the code is there for you to use as a starting point.


Issue 756

Please describe the purpose of this pull request.

Introduce a new description attribute to the AgentConfig
New describe CLI command: memgpt describe --agent=NAME --description="Short description here"
During run command, the agent selector has changed:

AI Persona is always displayed
Human name is always displayed
If description is set, it is also displayed

When run is cancelled during agent selection (using CTRL-C), the command exits instead of creating a new agent

The description is only used in the agent selector of the run command.
How to test
Start a new chat using memgpt run using existing agents.
Have you tested this PR?
Tested with existing agents & creating new ones via CLI.
Additional context

Heads-up: The first version of the PR created some bugs after changing the agents "name" attribute.
I've updated this PR to introduce a dedicated "description" attribute that has no other function than displaying info in the agent selector screen.

Hey @stracker-phil - thanks for the awesome PR!
Just a heads up, the timing of this PR is a little unfortunately since there's a large refactor in the process of being merged in that changes the way agents are stored (by default they will now be stored in a database, instead of in JSON files). So this PR will likely have to be rewritten in some capacity to use the new AgentState data type - probably makes the most sense to include the description field as metadata. Once that set of PRs is fully merged in (#785, #779 remaining), we'd be happy to guide you on how to refactor your change for the new code.
Again, really cool addition, we appreciate the PR and hope to merge a version of it in soon!
CC'ing @sarahwooders

@stracker-phil - it would be great to have this feature, however unfortunately due to some major refactors with the agent configuration (all moved to being saved in a DB), we can't merge this PR anymore. I'll close this for now but let us know if you'd be interested in contributing a similar PR for the refactored state saving.


Rescope class names

Jira: https://issues.redhat.com/browse/RHCLOUD-16591

Add "hub" prefix to classes
Use PF/Platform class naming convention

@himdel Please review/test. (I was not able to get an env working with adequate data for screenshots)

Apart from that one missing truncated, and the merge commits, LGTM :+1: :)

PR replaced by: https://github.com/ansible/ansible-hub-ui/pull/1382


[rom_ctrl/dv] Improve FSM coverage by injecting more faults

This addresses #18645

Ran multiple seeds with the new test and confirmed that it now hits all FSM states:
Test Results

Stage
Name
Tests
Max Job Runtime
Simulated Time
Passing
Total
Pass Rate

V2S
corrupt_sig_fatal_chk
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_checker_ctr_consistency
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_checker_ctrl_flow_consistency
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_checker_fsm_local_esc
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_compare_ctrl_flow_consistency
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_compare_ctr_consistency
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_bus_local_esc
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_mux_mubi
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_mux_consistency
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S
sec_cm_ctrl_redun
rom_ctrl_corrupt_sig_fatal_chk
5.059m
83.535ms
16
16
100.00 %

V2S

TOTAL

16
16
100.00 %

TOTAL

16
16
100.00 %

Coverage Results
Coverage Dashboard

SCORE
LINE
COND
TOGGLE
FSM
BRANCH
ASSERT
GROUP

82.09 %
93.25 %
77.58 %
94.44 %
100.00 %
91.50 %
93.98 %
23.90 %

I also added an assertion to prove the linear control flow for the rom_ctrl FSM (similar to the one in lc_ctrl) and proved it with Jasper:

name
pass_rate
stimuli_cov
coi_cov
prove_cov

lc_ctrl_sec_cm_fsm
100.00 %
N/A
N/A
N/A

rom_ctrl_sec_cm_fsm
100.00 %
N/A
N/A
N/A

CHANGE AUTHORIZED: hw/ip/rom_ctrl/rtl/rom_ctrl_fsm.sv


Run from Cron

Can the command line mode be saved in sh file and ran from cron job?

Tested ,cron able to generate pdf file and send on mail


Ignore IntelliJ Gradle build outputs

This ignores IntelliJ's default output directories when building a gradle-importing project when you don't delegate actions to Gradle.
To avoid any conflicts with command-line gradle, IntelliJ writes to out folders instead of build folders. I don't have full context or a strong opinion. Lots of details at https://youtrack.jetbrains.com/issue/IDEA-175172

Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.

[x] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It turns out that all of our idea plugin config is not effective when we do not delegate, because the hints are relative to Gradle's output directories, not IntelliJ's. The comments on the linked ticket indicate how to set things up for IntelliJ in a Java-specific way so perhaps we can try for the same in all areas. I am not sure.
CC @akedin @bsidhom

Looking at https://github.com/gradle/gradle/issues/2315 it seems we should recommend using gradle idea. However, I want the project files to be generated outside the source tree, to support git clean so that is a prerequisite.
Closing this as I don't think we should just ignore these, until we have them configured properly within the gradle scripts.

OK I am going to add hints so these output dirs actually work.

We should exclude this out/ thing also from assembly.xml and probably from build.gradle too. For ref this was the commit I reviewed from the PR mentioned yesterday.
https://gist.github.com/iemejia/c894d1da4ee9b6bea8eb5bdbadfb43d3

Please update/respond for @iemejia's comment

Indeed. Not abandoned, just back burner.

Added the additional ignores. Added a couple hints that get IntelliJ to use its own default directories when not delegating to gradle. Remaining problems with non-delegated build include - not running protoc - not running avro generation from avsc.

But this one should be g2g

The changes I asked for are ok, up to @lukecwik for the final LGTM.


Add github page

Add a github page with more information about altair, and links to all the other dependent products.

Done.


secret not found when using the cluster issuer

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:
When switching from Issuer to ClusterIssuer

Re-queuing item "" due to error processing: error getting clouddns service account: secret "" not found

What you expected to happen:
A certificate to be issued
How to reproduce it (as minimally and precisely as possible):
following the docs
and then migrate the to using ClusterIssuers
Anything else we need to know?:
the secret existed in both the certificates namespace and in the default namespace
Environment:

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-05-12T04:12:12Z", GoVersion:"go1.9.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.6-gke.1", GitCommit:"cb151369f60073317da686a6ce7de36abe2bda8d", GitTreeState:"clean", BuildDate:"2018-04-07T22:06:59Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud provider or hardware configuration**:
Install tools:
Others:

config
---
# Source: cert-manager/templates/00-namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: "cert-manager"

---
# Source: cert-manager/templates/certificate-crd.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: certificates.certmanager.k8s.io
  labels:
    app: cert-manager
    chart: cert-manager-v0.3.2
    release: cert-manager
    heritage: Tiller
spec:
  group: certmanager.k8s.io
  version: v1alpha1
  scope: Namespaced
  names:
    kind: Certificate
    plural: certificates
    shortNames:
      - cert
      - certs

---
# Source: cert-manager/templates/clusterissuer-crd.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: clusterissuers.certmanager.k8s.io
  labels:
    app: cert-manager
    chart: cert-manager-v0.3.2
    release: cert-manager
    heritage: Tiller
spec:
  group: certmanager.k8s.io
  version: v1alpha1
  names:
    kind: ClusterIssuer
    plural: clusterissuers
  scope: Cluster
---
# Source: cert-manager/templates/issuer-crd.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: issuers.certmanager.k8s.io
  labels:
    app: cert-manager
    chart: cert-manager-v0.3.2
    release: cert-manager
    heritage: Tiller
spec:
  group: certmanager.k8s.io
  version: v1alpha1
  names:
    kind: Issuer
    plural: issuers
  scope: Namespaced
---
# Source: cert-manager/templates/deployment.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: cert-manager
  namespace: "cert-manager"
  labels:
    app: cert-manager
    chart: cert-manager-v0.3.2
    release: cert-manager
    heritage: Tiller
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cert-manager
      release: cert-manager
  template:
    metadata:
      labels:
        app: cert-manager
        release: cert-manager
      annotations:
    spec:
      serviceAccountName: default
      containers:
        - name: cert-manager
          image: "quay.io/jetstack/cert-manager-controller:v0.3.0"
          imagePullPolicy: IfNotPresent
          args:
          - --cluster-resource-namespace=$(POD_NAMESPACE)
          - --leader-election-namespace=$(POD_NAMESPACE)
          env:
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          resources:
            requests:
              cpu: 10m
              memory: 32Mi
---
# this secret is present in both default and "somenamespacehere"
apiVersion: v1
kind: Secret
metadata:
  name: clouddns-service-account
type: Opaque
data:
  service-account.json: *****
---
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email<EMAIL_ADDRESS>
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging

    # ACME DNS-01 provider configurations
    dns01:

      # Here we define a list of DNS-01 providers that can solve DNS challenges
      providers:

        - name: prod-dns
          clouddns:
            # A secretKeyRef to a google cloud json service account
            serviceAccountSecretRef:
              name: clouddns-service-account
              key: service-account.json
            # The project in which to update the DNS zone
            project: *****
---
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: ****
  namespace: somenamespacehere
spec:
  secretName: tls
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer
  commonName: '*.example.com'
  dnsNames:
  - www.example.com
  acme:
    config:
    - dns01:
        provider: prod-dns
      domains:
      - '*.example.com'
      - www.example.com

@darkyat thanks for the suggestion, unfortunately that had no effect. I also created the secret in that namespace too.
the secret now exists in default, "somenamespacehere", kube-system
However creating the secret in the namespace 'cert-manager' appears to have fixed the issue!
Can the scope of this bug be to please update the documentation regarding this?

Creating the secret in the namespace 'cert-manager' has no affect
E0614 13:09:02.877284       1 sync.go:168] [cert-manager/testtls] Error getting certificate 'testtls': secret "testtls" not found

@ivanovUA that is an unrelated issue, I also receive this when I delete the tls secret for the certificate. cert-manager creates a new one so this can be ignored.
This bug relates specifically to 'I0613 10:16:44.039666 1 sync.go:241] Error preparing issuer for...'

I believe Let's Encrypt does not allow<EMAIL_ADDRESS>as a valid email address.
I got a similar error:
Error initializing issuer: 400 urn:acme:error:invalidEmail: Error creating new registration :: invalid contact domain. Contact emails @example.com are forbidden

@perspectivus1 you do realise i replaced the actual domain name email address with example.com rather than their real counterparts?

@mgazza I mean next:
I0619 14:53:15.674011       1 sync.go:241] Error preparing issuer for certificate ssl-test/testapp: acme: authorization for identifier domain.net is invalid
E0619 14:53:15.679462       1 sync.go:168] [ssl-test/testapp] Error getting certificate 'testapp': secret "testapp" not found
E0619 14:53:15.679526       1 controller.go:186] certificates controller: Re-queuing item "ssl-test/testapp" due to error processing: acme: authorization for identifier domain.net  is invalid

I had the same issue. Moving the secret to kube-system namespace solved it for me (was default).

@iceydee in your setup you used ClusterIssuer?

Having the same issue - the ClusterIssuer and secret are all in the same namespace (kube-system), still getting the Error getting certificate 'ifconfig-tls': secret "ifconfig-tls" not found error. I'm wondering if something about cross namespace stuff is borking.

Added certificate into same namespace where deployed cert-manager and added CAA dns records to the root domain, and now it works

Am having the same problem. Using a ClusterIssuer, as long as I place it and the Certificate resource in the same namespace as the helm-chart for cert-manager it works. If I attempt to place it in default the error "[default/redacted] Error getting certificate 'redacted': secret "redacted" not found".

closing as i no longer have this issue

I found that the secret had to be in the same namespace as the cert-manager Service in order for it to work.
Can we reopen this issue as a docs request for explaining this important detail?

moving it to default namespace worked for me

I found that the secret had to be in the same namespace as the cert-manager Service in order for it to work.
Can we reopen this issue as a docs request for explaining this important detail?

+1. This bit me as well. The instructions tell to deploy cert-manager into "cert-manager" namespace: https://docs.cert-manager.io/en/latest/getting-started/install.html
but the clouddns instruction does not mention that the namespace must be the same for the secret: https://docs.cert-manager.io/en/latest/tasks/acme/configuring-dns01/google.html

:+1: on adding the cert-manager namespace to the documentation for secrets

I used GitLab to install cert-manager and adding the Cloud DNS secret to the gitlab-managed-apps namespace worked. The namespace for the ingress-nginx-ingress-controller service and certmanager-cert-manager-... pod.

I used GitLab to install cert-manager and adding the Cloud DNS secret to the gitlab-managed-apps namespace worked. The namespace for the ingress-nginx-ingress-controller service and certmanager-cert-manager-... pod.

i also installed cert-manager with gitlab but i dont seem to get it working...
what namespace are you using on the cert-manager?

I am using Vault CA in my AKS Cluster, on creating a ClusterIssuer I am getting a similar error.
`Events:
Type     Reason         Age                    From          Message

Warning  ErrInitIssuer  3m58s (x266 over 21h)  cert-manager  Error initializing issuer: error reading Vault token from AppRole: error reading Vault AppRole from secret: cert-manager-vault-approle/ingress: secret "cert-manager-vault-approle" not found`

I'm using ClusterIssuer with digitalocean and DNS01 challenge.
The API Key secret is only found when created in cert-manager namespace.
I could not find any mentioning of this fact in the current documentation.
I've installed cert-manager using Helm:
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.5.3 \
  --set installCRDs=true

I'm using ClusterIssuer with digitalocean and DNS01 challenge.
The API Key secret is only found when created in cert-manager namespace.
I could not find any mentioning of this fact in the current documentation.
I've installed cert-manager using Helm:
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.5.3 \
  --set installCRDs=true

Thanks for the insight!
I had to also copy the secret into the default namespace using

kubectl get secret somesecret -n default -o yaml | sed s/"namespace: default"/"namespace: cert-manager"/ | kubectl apply -n cert-manager -f -

Same for me there, moving secret to kube-system namespace solved the issue maybe we should get this documented ?

@MartianGreed (et al) thanks for raising the issue and apologies for not replying sooner.
Any Secret associated with a ClusterIssuer must reside in the --cluster-resource-namespace,
which is the namespace cert-manager by default,
but may be overridden by whoever installed your cert-manager.
See  Cluster Resource Namespace and please help us improve that documentation if you have time.

Very old versions of cert-manager used to use kube-system as the cluster-resource namespace and your cert-manager administrator may have continued that practice:

https://cert-manager.io/docs/installation/upgrading/upgrading-0.2-0.3/#supporting-resources-for-clusterissuers-moving-into-the-cert-manager-namespace

Same problem here. The Digital Ocean documentation didn't say anything about having to put the secret into a specific namespace for the ClusterIssuer.

I'm using v1.16.0, the Cert Manager pod, the (Sealed)Secret and the ClusterIssuer are all installed into the same namespace, which is cert-manager, yet I cannot use the ClusterIssuer from another namespace. I'm installing from the Helm chart, it sets --cluster-resource-namespace=$(POD_NAMESPACE) and POD_NAMESPACE=cert-manager which is obtained from the metadata.namespace as setup by the Helm chart. What am I doing wrong, please?

I have the same issue as @christian-schlichtherle using 1.16, but switching back to the 1.15.3 release solved the problem of cert-manager not finding the secret, although it is in the namespace specified by --cluster-resource-namespace.

@Magi3r @christian-schlichtherle It's a more general bug affecting the DNS01 solvers in v1.16.0.

https://github.com/cert-manager/cert-manager/issues/7331


Various bugfixes related to 1.38 changes. (#1109)

Removed some MDL uniform qualifiers.

Removed unsafe conditional optimization.

Allow thin-film layered over conductor (result is not correct and needs more work, but this setup is now valid).

Looks good, thanks @niklasharrysson!


New Feature: Please Provide Real World Example Usage

Hi, looking over this repo, there seems to be no documentation, demo or usage examples provided to see this in action.
Is it possible this repo can be updated?
Thanks

See #10


publish wysiwyg.js on npm

Hi,
I would like to use your editor on my project, but you have not published it on npm. Can you do it please ?
Thanks in advance

We don't use npm. What has to be done?

I'm sorry for my newbie question but what is npm?

hi, thanks for your time.
you juste have to do a npm publish tutorial here
if you don't have a npm user, you should create one before (it really is simple)
then you will have to have a proper package.json, you need to set your version number at 1.0.0 and not just 1
let me know if you need any help

Merged the pull requests. Could you publish this account?
If you need write access to this repository please let me know.

:+1:

hi, sorry for the delay, i was out of time. if you want, i can do it, i will need access to the repository yes, to publish git tags in order to publish on npm, if you want.

@Nyalab
I have added you as "collaborator". Hope this helps.

yes thanks, it is done! your editor is on npm, congrats!

Thanks a lot!


tests

The benchmarks should probably be separated out into bench, with actual tests (perhaps property-based?) living in test.

👍
I've added you as a collaborator on the repo, so you should have push access now.

Yikes. Thanks! I would of course prefer review before merging anything.


Change the contributor suggested (default) voting for three amendments

Change the contributor suggested (default) voting to yes for three amendments:

NonFungibleTokensV1_1 (XLS20)
ExpandedSignerList
CheckCashMakesTrustLine

Following discussions with other contributors about how default voting should work, I am submitting my suggestion, as a contributor, that validators who have opted not to cast a vote should now vote yes by default on these amendments.

Why only those 3 and not the other 5?

Why only those 3 and not the other 5?

I assume you're referring to these?
REGISTER_FEATURE(OwnerPaysFee,                  Supported::no,  DefaultVote::no);
REGISTER_FEATURE(CryptoConditionsSuite,         Supported::yes, DefaultVote::no);
REGISTER_FEATURE(NonFungibleTokensV1,           Supported::yes, DefaultVote::no);
REGISTER_FIX    (fixNFTokenDirV1,               Supported::yes, DefaultVote::no);
REGISTER_FIX    (fixNFTokenNegOffer,            Supported::yes, DefaultVote::no);

OwnerPaysFee is not supported so can't be voted on anyway.
CryptoConditionsSuite is not for production / deprecated
NonFungibleTokensV1, fixNFTTokenDirV1 and fixNFTokenNegOffer are deprecated in favour of a roll up amendment NonFungibleTokensV1_1.

To back this PR, most validators are supporting 3 of these amendments with proper consideration/governance in mind that correlates with network health & stability. There have been issues with amendments passing as most validators on the dUNL are inactive and are not participating in amendment voting, which leads to amendments not being able to pass the 80% network approval threshold. +1 from me.

most validators are supporting 3 of these amendments with proper consideration/governance in mind that correlates with network health & stability.

https://xrpscan.com/amendment/32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 only shows the votes of a fraction of validating nodes (the ones on the "dUNL"), not globally.
It is probably possible to also get a global view on amendment support (but then one needs to consider that it isn't clear which of those votes are actually unique entities, so this can only be taken as an indication, not as ground truth), which likely looks different.
According to https://xrpscan.com/validators for example there are more validators voting for 20/5 fees than 10/2. If those just follow the default votes, also most validators globally would oppose these changes here at the moment.
All 3 amendments are optional new features, they are not related to increasing stability but increasing complexity and risk. Still of course it might be nice to have new things, this is why the voting process exists after all. I'm all for setting bugfix amendments to default yes to push them through as soon as enough people have upgraded, but pure feature amendments should be voted in, not out.

most validators on the dUNL are inactive

The dUNL can be changed freely. Why are there inactive operators on there or at least ones that don't care about the XRPL enough to make a choice regarding the protocol every few months? Also the dUNL still does contain duplicate entries for Ripple to this day, its entries can hardly be called "unique"...
Also the "no" (=default or explicit) votes on these amendments are already in the minority on the dUNL, which would mean most operators there actually did actively vote for these changes. Just not enough to safely go through yet.

@MarkusTeufelberger in my analysis there are at least 10 passive (non-voting) validators on the dUNL. These are easily identified because they are the validators who do not vote for 10/2. There's only two possible reasons you would vote this way: either you want to increase the reserve after it has already been decreased, or you didn't change your fee voting to begin with. Voting the reserve higher is highly inadvisable once it has already been lowered, thus I take that to mean 10 validators are passive validators with respect to amendment and fee voting.
Amendments require 80% yes on the dUNL for two weeks to pass. If 10 of the 35 dUNL validators are passive then even if all active validators vote yes we will achieve only 71%, which is not sufficient to pass any amendment.
After discussions with other community members on the XRPLF mattermost it was concluded that passive validators effectively delegate their voting to the contributors... which along with the two ways of actively voting is also their right to do. Currently without the contributor's votes no amendments can pass. So as a contributor with these factors in mind I submit a vote of yes for these amendments.

I think the presence of passive, non-voting validators on the dUNL is a significant issue that warrants larger discussion. This discussion should occur here on GitHub, where everyone can see, as opposed to on the Mattermost, which is invite only. It's definitely not good to have passive, non-voting validators on the dUNL.

I agree the discussion should occur here on github. @ximinez made a very compelling case that passive validators are taking the legitimate action of delegating their votes to the contributors, which is effectively a third way of voting along with yes and no. I changed my mind from what was effectively your position to his after this. Maybe he can restate it briefly here :)

I'm opposed to this. We (collectively) decided on a "default no" policy for new features and I think we ought to stick with it.

Valid points. A big concern I have had regarding amendments, that has been mentioned previously by me, and others, is that a passive vote, being cast by default, is not a vote and should not be reflected as such. It fails to give an accurate view of the actual position of a validator as there is no current way of determining whether a vote to reject was a default or whether it was configured by the validator.
Given the current default status, some validators may feel there is no need to interact if their intent was to reject, for whatever reason, once again, not giving a clear indication.
The remedy, a neutral position on updating with a requirement to actually. There has been some talk of making it a requirement to vote in order to activate validation. A great idea, however network wide it may cause the network to deplete  especially with auto-updating.
Community involvement in the voting process could/should be considered. If, say >50% of (total of non UNL) validators in the wider network have voted to reject or enable an amendment then a proportion of voting rights is afforded to them in the allocation to get to the (current) 80% threshold. It could be apportioned by say - the 10% of UNL or similar which could make 38 combined UNL and they would have 3 votes.
UNL members need to be diligent, timely and contactable by list providers and vacated from lists if they are not being a good reliable validator.

What made you change your mind so quickly?

I proposed that policy as a standard, that anyone can refer to if they wish to do so: In this PR and In my mind, I don't see why we should be following it right now when the problem is, there are inactive validator operators that aren't voting-in or voting-out amendments.

I'm opposed to this. We (collectively) decided on a "default no" policy for new features and I think we ought to stick with it.

Then no amendments can pass until the dUNL changes. Since that requires fairly exact coordination between the three VL publishers who knows when that will be.

Community involvement in the voting process could/should be considered. If, say >50% of (total of non UNL) validators in the wider network have voted to reject or enable an amendment then a proportion of voting rights is afforded to them in the allocation to get to the (current) 80% threshold. It could be apportioned by say ~10% of UNL or similar which could make 38 combined UNL and they would have 3 votes.

This just means that sybil attacks can and will happen. Of course dUNL owners should take a look at the community at large ideally and react to that, but in general there should be no way for someone outside my UNL to influence my vote or the aggregated outcome. I don't even see a feasible way to implement your suggestion in practice by the way and am wary of magic numbers (why 3 votes and not 2 or 4? Why 10%?).

Then no amendments can pass until the dUNL changes.

No amendment that has a "no" default vote, not no amendment at all. Also publishing a strict subset of a current list is safe and requires no coordination as long as over time the same subset is published. Lastly it might be worth a discussion to think about how entities end up on these lists that don't demonstrate the capability of configuring amendment and/or fee votes and do something about that instead of "tricking" these passive entities to vote for/against certain amendments or fee settings.
This seems like a way to address shortcomings from dUNL providers in their policies and transparency about member selection instead of going further (e.g. requiring explicit votes when validating) or removing the "bugfix yes, feature no" policy and thus risking pushing through feature amendments that weren't really well understood or tested (or even desired). Who gets to decide if my hypotherical feature amendment of "freeze all XRP that Ripple owns" should be a default yes vote or even included in the code after all? If it were default no and the code was sensible, it might get added for a while to have this as an option, if the policy gets weakened then it is up to a handful of people with commit rights here to decide which amendments have a chance of being voted upon - not the actual validators.
In conclusion:
It is not the job of people contributing to this software to decide on which feature amendments have a chance to pass. It is already bad enough that the dUNL publishers apparently have a large amount of power in this regard (because they add(ed) a too large portion of apparently passive participants to their list). Ideally this decision should only be in the hands and votes of responsible validator operators.
If the current way of how voting is structured, communicated and configured does not support this model, this should be changed instead of keeping the current model of "just follow the defaults - that WE, the code owners set for your own good".

It is not the job of people contributing to this software to decide on which feature amendments have a chance to pass.
This is also my position, however in practical terms whomsoever is in charge of publishing the binary packages that everyone runs ultimately has 100% control over what code, including which amendments, run on the XRPL. In fact there is nothing to prevent those binaries being compiled from code other than this repository.
There's plenty of problems with the current distribution of trust and power. Let's either fix it completely (which requires accepting some further hard truths I won't enumerate here yet) or continue pretending it doesn't exist in which case default::yes so we can actually get some work done.

Invoked by @RichardAH , I'll restate / summarize my opinion about default votes:

One of the main reasons that DefaultVote was added was to allow an amendment to be supported without being voted yes by default, which allows a more gradual update path for operators.

For example, an amendment introduced in 1.7 would have been voted on as soon as a node was upgraded unless the operator took the time / action to vote against it. That could easily lead to nodes still running 1.6 to get amendment blocked if enough UNL validators upgraded without changing their vote, which would be particularly bad if they were UNL nodes that hadn't upgraded, but could also cause problems for exchanges and such. This sometimes discouraged UNL operators from upgrading.
Now, support for amendment X can be added in, say, 1.9 with a default vote of no. Nodes running 1.8 should still upgrade, but they aren't forced to rush to do it within 2 weeks for fear of getting amendment blocked. There could be additional releases after that - 1.9.1, 1.10.0, etc. Once a sufficient portion of the network has upgraded to a version that supports X, the next version of rippled (which may be much later, e.g. 1.13) can safely change the default vote for that amendment to yes, which should motivate the stragglers to update, seeing as they've presumably now had plenty of time to test.

Default votes are merely recommendations from the contributors. Operators can always choose to vote differently. If they decide to accept the default, that is also a choice (a less active choice, but still a choice). That allows validators who can keep a reliable connection, on reliable hardware, and reliably upgrading to stay functional without necessarily being "active" about voting. To the best of my knowledge, actively voting on amendments has not been considered a requirement to be on a UNL.
The contributors have only changed the default vote from no to yes once so far, because the default vote functionality is still pretty new. Still, https://github.com/XRPLF/rippled/commit/8266d9d598d19f05e1155956b30ca443c27e119e changed the default for NegativeUNL from no to yes.

Still, https://github.com/XRPLF/rippled/commit/8266d9d598d19f05e1155956b30ca443c27e119e changed the default for NegativeUNL from no to yes.

The reason given in https://github.com/XRPLF/rippled/pull/4215 was:

Well, I figured it was particularly safe since the NegativeUNL amendment is already live on the main net. So this specific change should be very safe.

I am not happy about this drive-by change of unrelated default votes, nUNL does to my knowledge have nothing to do with the rest of the contents or the topic of #4215. Then again the nUNL amendment was enabled in late 2021 (https://xrpscan.com/tx/1500FADB73E7148191216C53040990E829C7110788B26E7F3246CB3660769EBA) already and the PR is from June of 2022, so apparently "default vote: no" feature amendments could pass less than a year ago... what changed?
The documentation states it is enabled by default vote "no" by the way: https://xrpl.org/known-amendments.html#negativeunl

Having the power make an amendment pass and resolving not to use it is not the same as not having it. If the only reason for default::no is that we shouldn't have this power, then that is completely arbitrary. It might as well be default::yes "because we shouldn't have this power" (as it was previously.) I suggest we disregard any argument based on "we shouldn't have this power" because we do have this power.

I think the developer community is at an impasse. If more than 20% of dUNL validators are inattentive, inactive or passive in their voting then nothing will pass. Over time the chain will become dated technology that people do not want to work with.

Why don't we just remove the passive validators from the UNL?

Let's coordinate it then. I think if a validator operator is not actually even paying attention to the community and development, then they probably should not be a validator on the dUNL.

Let's coordinate it then. I think if a validator operator is not actually even paying attention to the community and development, then they probably should not be a validator on the dUNL.

100%. But tell them that 🤣 I can sway XRPLF I'm an advisor. Can you sway ripple? Then we just need to find someone who can get coil in.

There are only 2 publishers in the default file (XRPLF and Ripple Labs Inc.), not 3. You're on the team of one of those 2 entities... The guidelines there state the following: https://foundation.xrpl.org/unl/

Active participation in the amendment voting process

As long as the one published by the XRPLF is a subset of the one published by Ripple Labs, there is no need to delay or coordinate anything.

There are only 2 publishers in the default file (XRPLF and Ripple Labs Inc.), not 3. You're on the team of one of those 2 entities... The guidelines there state the following: https://foundation.xrpl.org/unl/

Active participation in the amendment voting process

As long as the one published by the XRPLF is a subset of the one published by Ripple Labs, there is no need to delay or coordinate anything.

There's no guarantee the dUNL validators are listening to the default VLs in the default configuration. Notably the configuration wasn't always this way, and if they have been on the dUNL for some time they might listen to some other list. It is prudent to coordinate between the three well known VL publishers.
I will just tag @alloynetworks and advise removal of any validators not voting 10/2 reserve from the XRPLF's VL right now, if it makes you happy.

I don't think coil was ever part of this file: https://github.com/XRPLF/rippled/commits/develop/cfg/validators-example.txt

https://github.com/XRPLF/rippled/commit/a4a46a491f08781855e6b6ea2ccbc2634c5ee239

If it forks it forks.  Everyone change their VLs please.

Let's coordinate it then. I think if a validator operator is not actually even paying attention to the community and development, then they probably should not be a validator on the dUNL.

100%. But tell them that 🤣 I can sway XRPLF I'm an advisor. Can you sway ripple? Then we just need to find someone who can get coil in.

Yeah I'll do my best to sway

Let's coordinate it then. I think if a validator operator is not actually even paying attention to the community and development, then they probably should not be a validator on the dUNL.

100%. But tell them that 🤣 I can sway XRPLF I'm an advisor. Can you sway ripple? Then we just need to find someone who can get coil in.

I will try

I don't think coil was ever part of this file: https://github.com/XRPLF/rippled/commits/develop/cfg/validators-example.txt

a4a46a4

This is commented out, just like http://<IP_ADDRESS>:8000...

I don't think coil was ever part of this file: https://github.com/XRPLF/rippled/commits/develop/cfg/validators-example.txt

a4a46a4

This is commented out, just like http://<IP_ADDRESS>:8000...

It's an official example for which a key is also provided. You have no way of knowing who is using this VL in their validators.txt

Well, I figured it was particularly safe since the NegativeUNL amendment is already live on the main net. So this specific change should be very safe.

I only looked at the code, not the PRs, so it's a fair point that changing the default vote didn't really do anything on mainnet.

If it forks it forks.  Everyone change their VLs please.

IMHO, a fork would be much more detrimental to the ecosystem than slow uptake on amendments.

One more thing I'd like to point out is that in PR #3877, which implemented the option to not vote for supported amendments by default, I wrote:

This will allow completed features to be released and supported for one or more release cycles before they are voted on by default. Operators will still have full control over voting for or against amendments on their own nodes.

I know that developer notes are not canonical or binding in any way, and that best practices can be changed in ways that aren't directly reflected in code, but at least at that time, my intention was that default votes would be changed from "no" to "yes" at some point in an amendment's life cycle.

IMHO, a fork would be much more detrimental to the ecosystem than slow uptake on amendments.

Of course it is, we shouldn't risk a fork from happening.
Please, let's just cooperate and change your VLs: remove passive operators that have been put for political motives, that do not care about the network's advancement. The very least that all of us could do is to remove all passive validators that:

are not voting for 10/2 fee reserve
operators have not participated in any recent off-chain discussions

from the dUNL, before this PR was issued. This is the bare minimum, scrap off the obvious bad apples from the dUNL.

Closing for lack of support

To those who participated in this discussion: please review https://github.com/XRPLF/rippled/pull/4291
Thanks! :)


[Firebase 11]:  Firebase App Check's limited use token API as required

Description
The FirebaseAppCheckInterop contains an API for getting limited-use tokens. This was introduced in 10.10 and was marked as optional for backwards compatibility purposes. The @optional attribute can now be removed for a major version breaking change.
API Proposal
In FirebaseAppCheck/Interop/FIRAppCheckInterop.h:
-  // MARK: - Optional API
-
-  @optional

 /// Retrieve a new limited-use Firebase App Check token
 - (void)getLimitedUseTokenWithCompletion:(FIRAppCheckTokenHandlerInterop)handler
    NS_SWIFT_NAME(getLimitedUseToken(completion:));

Firebase Product(s)
App Check

Hey there 👋 - @paulb777 and @ncooke3 I have a question about this that might affect the API shape of the limited use token functionality
Here's the context:
For dynamic language environments (react-native at least, Flutter also I presume) it is difficult for the user to configure App Check as a system because App Check expects to be initialized at app startup and never changed after. This configuration constraint is a window that closes during an app lifecycle phase that is prior to the dynamic language environment being up and available though and means that by the time the dynamic language environment knows what it wants to configure and could do so, it is too late to do so for the underlying SDK's constraints.
I have worked around this by implementing a custom provider and custom provider factory that stores a reference to one of the concrete underlying providers from the SDKs, and I have library consumers initialize our module, then configure/install our dynamically delegating custom provider for usage.
Now when the dynamic language environment is available, they can configure the custom provider the way they want (perhaps setting the debug factory up, with a debug token...) and install it - all the web/android/ios API disjointedness happily smoothed over and dynamically configurable - something that was very difficult to do with the app-check module unlike all the other modules.
This has been working really well, it was an innovation that finally made app check user friendly for react-native-firebase.
Why am I commenting here? Unless the getLimitedUseTokenWithCompletion method is on the AppCheckProvider interface, I can not use that type (as I do with getTokenWithCompletion...) to dynamically and in a provider-agnostic way in my custom provider, so I cannot proxy the call through and implement this API.
This is a current concern for me as I attempt to shepherd through a community PR to implement it: https://github.com/invertase/react-native-firebase/pull/7424
If it seems reasonable to add the limited use token API to the interface and you can do so then I'll propose the same thing over on firebase-android-sdk for their similar interface

@andrewheard who may also have some thoughts

I should check the source more carefully! Here I was looking at the docs, but apparently it is there, just marked optional - https://github.com/firebase/firebase-ios-sdk/blob/8fe1ddc5f16957da5b2dc8b1dee90e5bd85205ff/FirebaseAppCheck/Sources/Public/FirebaseAppCheck/FIRAppCheckProvider.h#L35-L47
appears to work well when I call it (and call it with the correct name...)
Not seeing "consumed" in there as a claim but that may be added by verify() in admin-sdk, that's just on me to test. I need to look more closely at firebase-android-sdk then
My general comments on the difficulty of configuration + smoothing over API disjointedness from native SDKs to dynamic language environments are still on point, but my custom provider shim may be able to paper over this new API as well without much issue

Closing, since it should remain optional for custom providers


Change check for daily-notes

The vault config no longer contains the  pluginEnabledStatus hash.
Use the getPluginById function instead.

Closing this - there are more issues other than the lookup, so I'll re-assess.


Fix missing @bodyRoot

Missed in some templates and it is making some spec fail in spec repo

All changed packages have been documented.

:white_check_mark: @azure-tools/typespec-azure-resource-manager

Show changes
@azure-tools/typespec-azure-resource-manager - internal ✏

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/708/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/708/


The Avast antivirus on Windows recognizes cs.exe as a virus

Feedback from one of our students:

When I try entering ".\cs setup -y --jvm 8 --apps cs,sbt", Avast warns me about some virus and places a file named cs.exe to quarantine (telling me it is infected by IDP.ALEXA.53).

I'm not sure if there's anything that can be done, maybe there's a way to get whitelisted by Avast?

If we can't get it fixed by the anti-virus, we could mention it in the doc just to not surprise the user.

maybe there's a way to get whitelisted by Avast

Not sure how we can do that…
It'd be interesting to check if that error also happens with other GraalVM native images, like the bloop launcher.

@smarter I'm facing similar issues with BitDefender Anitivirus.


Configure line height

[X] I am on the latest Hyper.app version
[X] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: macOS High Sierra 10.13.3
Hyper.app version: Hyper 2.0.0 (stable)
Link of a Gist with the contents of your .hyper.js: https://gist.github.com/hankchizljaw/d1733306ae06854a6ae9d1304bbd0844

Issue
Hey Hyper Team,
First of all, the new version looks excellent, so thank you for your ongoing hard work on this 👏
Now that we've got a canvas based rendering system, is it any simpler to increase the line height at all?
Here's two screenshots of Vim, the first using iTerm and the second user Hyper 2.0
iTerm

Hyper

As mentioned by @Spaxe in #75, xterm 3.0 exposes a lineHeight option. It doesn't look like it's being passed on, though, since defining it in the config doesn't do anything.

#2858 looks like a decent solution. Let's hope this is resolved soon, as I'd love to use Hyper as my primary terminal 🙂

@piotr-yuxuan because it's not used by a lot of people. Feel free to create a PR. Now we have #2858 so it will be in soon. We're all doing this in our spare time and for free.

Please forgive the tone of my previous message which was too cold. I know we all contribute for free in our spare time :-)


cloud web Service to train data

Is your feature request related to a problem? Please describe.
everyone has to spin up a pipenv to train their data (when its essentially the same process)
Add Json files, crunch model, spit out result - import to phone.
Describe the solution you'd like
could we spin up a cloud service where the user uploads their models and it provides the results back?
I have a dev Azure subscription I could leverage? not sure how to make a web front end for it though?
Describe alternatives you've considered
not sure if its of value, but thought i'd suggest it

Sounds like an interesting idea, but not a priority at the moment. It would also be nice to store models under some cryptic URL, so users can download the same model on multiple devices.
I have no experience with Azure, so I don't know how time intensive it is to spin something up there. Have also toyed with the idea to provide the service myself, by hosting it on a Pi or some other device. But I don't have free hardware available at the moment.
The required processing power should be fairly low, as these models are not very demanding to train.

Sounds like an interesting idea, but not a priority at the moment. It would also be nice to store models under some cryptic URL, so users can download the same model on multiple devices.
I have no experience with Azure, so I don't know how time intensive it is to spin something up there. Have also toyed with the idea to provide the service myself, by hosting it on a Pi or some other device. But I don't have free hardware available at the moment.
The required processing power should be fairly low, as these models are not very demanding to train.

After some brief research, it seems that (Flask)[https://flask.palletsprojects.com/en/1.1.x/] might be a good choice to do this.

After some brief research, it seems that (Flask)[https://flask.palletsprojects.com/en/1.1.x/] might be a good choice to do this.


FancyZones not working with certain windows

Microsoft PowerToys version
0.53.3
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
A software I use daily for work is Ableton Live. I use a second window and recently FancyZones stopped working for that window and some other "secondary" windows. It was working well just until recently.
PowerToysReport_2022-01-17-10-37-02.zip
https://user-images.githubusercontent.com/97884741/149758182-b60f6ce8-17fd-4492-8286-4e7ad4127e79.mp4
✔ Expected Behavior
When I press Shift + drag a window, the Zones should appear.
❌ Actual Behavior
With this second Ableton Live window, the Zones don't appear, and I can't automatically resize and position the window.
Other Software
I'm running Windows 10 Home and Ableton Live 11 Suite.

Same here with Visual Studio ancillary windows. FancyZones was very handy to quickly arrange the many activity windows around Visual Studio.
Same problem with regular "open" dialogs of apps. FancyZones was (at last) a way to maximize those "open" dialogs quickly.

This is a major setback. With this change, FancyZones has lost nearly all its benefit and appeal. I'm going to see if I can downgrade it.

v0.53.1 also has the problem. So, not acceptable.
Reverted to v0.51.1, works immediately.

Duplicate of #15426

Thanks for reporting this. This issue is a duplicate.
I'm linking this issue to #15426 to centralize the discussion thread for tracking.
Thanks for your help to make PowerToys a better piece of software!

I reported this as well, #15567


Can't install plugins inside cypress container

Coming from Behat I am evaluating Cypress and loving it so far, however I have a legacy of tests written in Cucumber (and I find it easier to write) so I am experimenting with official plugins that allow Cucumber syntax in Cypress.
When I try to install custom cypress plugins via NPM I am getting this error:
npm error Your cache folder contains root-owned files, due to a bug in
npm error previous versions of npm which has since been addressed.
npm error
npm error To permanently fix this problem, please run:
npm error   sudo chown -R 6001:6001 "/root/.npm"
npm error Log files were not written due to an error writing to the directory: /root/.npm/_logs
npm error You can rerun the command with `--loglevel=verbose` to see the logs in your terminal

I tried it with a simple approach first, adding my custom commands in the entrypoint:
    entrypoint: /bin/bash -c "npm install @bahmutov/cypress-esbuild-preprocessor @badeball/cypress-cucumber-preprocessor"

SSHing into the cypress container and trying to chmod the folder was not possible either, as sudo is not available.
Am I missing something or is this a problem with the official dockerimage?

You probably have to add a build: section in the docker-compose.cypress.yaml
@tyler36 is out for a few weeks but will be back :)

The build section kind of worked. I added a custom dockerfile like:
FROM cypress/included:13.15.2

# Set the working directory
WORKDIR /e2e

# Install npm package(s)
RUN npm install -g @bahmutov/cypress-esbuild-preprocessor @badeball/cypress-cucumber-preprocessor && npm cache clean --force

The container starts now, no issues there. But the plugins are still not installed, or not discoverable by Cypress.
Thanks for info and docker lessons, I'll get to the bottom of it :)

@bserem
I have found that the cypress-included image automatically find and load any cypress addon installed via NPM.
I have a couple of projects that use "@badeball/cypress-cucumber-preprocessor" too, and Cypress (via this addon) has no problems using them.
Screen shot below of cypress-cucumber-preprocessor using a Japanese-locale .feature spec file:

I understand you are running npm in the host or the web container, rather than inside cypress container? Am I right?

Use ddev npm ... to install inside the web container. This prevents npm version conflicts between the host and DDEV (web container). This should also work if you prefer YARN (ddev yarn ...).

While install cypress plugins in the cypress container could work, I find using ddev npm ... --save-dev a simplier solution. It lets the package manager do what its designed to do, manage packages.  😄

I'm going to close this for now.
See above for a suggested workaround.
Happy to discuss it further/ reopen if you feel strongly about it.


Add RTU MIREA University

Hello! Here are the informations you asked:

The university official website URL: https://mirea.ru
A URL of a page on the official website where a long-term (>1 year) IT related course is offered by the university: https://priem.mirea.ru/guide-direction?direction_id=3
A URL of a page showing that the university recognizes the domain which you are submitting as an official email domain for the enrolled students: https://lk.mirea.ru/auth.php

I hope the check will be successful

@dragontino First stage of verification passed, official domain is mirea.ru as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@dragontino Unfortunately, your request cannot be processed further because JetBrains doesn’t provide products or services to territories subject to applicable EU, UN, or US sanctions or under comprehensive export control restrictions due to legal, compliance, and other commercial risks.


Implement WebRTC 1.1 support for MS Edge

see the http://caniuse.com/#search=webrtc matrix, it is unlikely that Edge will support WebRTC 1.0 in the future, so for the time being there will be 2 versions of this API.

@wizzard0 Thanks for opening this. We'll definitely add support for Edge once they support the WebRTC Data Channel, which is what WebTorrent uses to communicate arbitrary data between peers.
From the Windows blog:

We don’t currently support any of the DataChannel functionality currently defined in the ORTC spec.

We'll probably just need to add support to simple-peer and everything will hopefully just work :)