add up / down button for sorting images before uploading and renaming as "001.jpg", "002.jpg", ... when you press the button "upload"

Hi,
I am looking for a way to add buttons to sort the images before uploading. The important thing is to be received with the image names changed with a command like "001.jpg", "002.jpg", "003.jpg", ... In this way I know the order of the album.
Any help would be highly appreciated. Thanks ~.^

Hi,
Did u got  any solution for the same?


[VS Code] [Audio] HTTPS request failed for SkypeToken: Parse Error: JS Exception

Error:
HTTPS request failed for SkypeToken: Parse Error: JS Exception
Steps to Reproduce:

start/join live share
start audio call

Version Data

extensionName
VSLS-Audio

extensionVersion
0.1.84

applicationName
VSCode

applicationVersion
1.45.0-insider

platformName
Linux

platformVersion
5.4.0-26-generic

@Raju: thanks for reporting this issue! We have a fix that will be released shortly. I'm resolving this issue as a duplicate of #3432 to consolidate the communication.


Pagination

Could elm-sortable-table provide pagination?  This could collapse long lists into multiple pages, e.g., 1 of 12, which users could navigate forward and back.  jQuery provides an example:
https://esimakin.github.io/twbs-pagination/

I have exactly this requirement.
We are working on a webshop-application, that will have multiple thousand products, so pagination is a must.

This package is deprecated. Community members will be managing forks and alternates from 0.19 and above.


What if i want to delete documents? Vector dbs

Hi with the current setup of importing documents.
I understand that if i add new documents it will load the new documents.
What if i want to delete or replace existing embedded documents.
Also what do i have to change to use qtrand database installed locally on a docker instead of chroma?

just delete the db and cache folder which is created when you run the code.

That's not a workable solution.
Say you waited many hours, indexed a couple dozen documents.
But now you want to remove one of those.
You're telling me the solution is to.. well.. re-index all of it without that one document. That's not going to scale ;)


Webcmdlets should parse the  attribute for the correct encoding if not in http header

Some websites do not populate the charset property of the content-type header so characters aren't rendered correctly.  Suggestion is to expose a -charset parameter, however the user still needs to know the expected charset.  Advanced users today can do the encoding translation in script.  utf-8 probably works in most cases, so not entirely sure how useful this will be to expect the user to know ahead of time the correct charset.
See discussion from https://github.com/PowerShell/PowerShell/issues/3126 for details on how this came about

Point for the fix is here

I believe we should discuss here a default encoding for Web cmdlets.
Currently we use RFC 2616 "ISO-8859-1"
In fact, browsers for a long time use Windows-1252.
And HTML5 default is UTF-8.
Perhaps we should also use Windows 1252.

There are all like powershell fans,do not be perfunctory.
I disagree "-CharSet", do not push this question to the users.
Think:
If the browser does not recognize 【meta charset="gb2312"】,every time you need to manually select   ...
1 Receive raw html string
2 Find out after 'charset=' strings.
3 use 【some charset】 encoding raw html，and out to console
2 and 3 are so hard that powershell can not do it?

I looked Web cmdlets and found that we use ContentType parameter to encode a request (Content-Type header can contains charset value). If we don't specify a charset in ContenType we use default charset ISO-8859-1.
For decoding a response we use a charset from ContentType of the response. If a server return no ContentType we use the same default charset ISO-8859-1.
So we should treat -CharSet as -ResponseCharSet.
After some thought, I believe that using Windows 1252 as default is obsolete and we should aim at HTML5 and UTF-8 as defaults.

@PowerShell/powershell-committee reviewed this and agree this is an issue for customers.  proposal is to parse the HTTP header first, if charset is in content-type, we use that.  otherwise if content-type is html, we parse <meta charset="X">  for the charset attribute and use that

In Windows Powershell we use Internet Explorer to parse HTML. What portable parser we can use in PowerShell Core?
And if HTML don't contain  ? What defaults we should use?

@iSazonov the proposal is that we don't rely on any browser for the html parsing (if complete parsing is needed, I still think it would make more sense in a convertfrom-html cmdlet).  I think "best effort" for this is sufficient (perhaps even just a regular expression) to cover the majority of cases and we wouldn't worry about malformed html.

@SteveL-MSFT Original Windows web cmdlet returns ParsedHtml        : mshtml.HTMLDocumentClass - we want lost the functionality?

@iSazonov .ParshedHtml relied on Internet Explorer.  I don't think we can have a dependency on any particular web browser in the webcmdlets.
To answer your other question I missed, if <meta charset> doesn't exist and charset isn't specified in the content-type HTTP header, then we do what we do today which is assume ISO-8859-1

@SteveL-MSFT

.ParshedHtml  relied on Internet Explorer

If we use any ported library for HTML parsing we will solve this Issue, get ParshedHtml ported, as well as get a base for ConvertFrom-HTML.
I wonder about ISO-8859-1. Why we do not want to accept the new standard HTML5?

@iSazonov my understanding is that HTTP1.1 still defaults to iso-8859-1, if the content-type is text/html, we should just follow the HTML 5 rules for determining content type ideally just using one of the OSS HTML parsing libraries you already found

@SteveL-MSFT It seems the doc is very old. New is http://www.w3.org/TR/html5/syntax.html#the-input-byte-stream It don't mention iso-8859-1 at all.

Currently CoreFX already use UTF8 as default.

@iSazonov that's html5, HTTP 1.1 defaults to ISO-8859-1 if charset is not specified.  See 3.4.1 in https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html

These standards are too muddled 😕 From https://tools.ietf.org/html/rfc7231:

The default charset of ISO-8859-1 for text media types has been
removed; the default is now whatever the media type definition says.
Likewise, special treatment of ISO-8859-1 has been removed from the
Accept-Charset header field.

In any case we trust CoreFX. Yes?

Ideally, we should just leave this to corefx.

This already is in CoreFX so we can.
Only is this in CoreFX version we use currently or we blocked until NetStandard 2.0?

Marking as waiting on NetStandard20.  Once we move to latest CoreClr, we can verify if this is still an issue.

@SteveL-MSFT Can you initiate internal conclusion about using HtmlAgilityPack or
AngleSharp? What one we can more trust?
Then I would try to replace IE on one of these parsers for PowerShell Core (and leave IE for FullCLR).

@PowerShell/powershell-committee believes AngleSharp is a better choice as it seems to be more actively updated and this should be a separate convertfrom-html cmdlet.  The charset attribute on the meta html tag parsing should still be in the webcmdlets and a simplified best effort than using a complete html parser.

Please help look, there seems to be a problem. could reopen?
Steps to reproduce
Invoke-RestMethod -Uri 'http://www.gov.cn' |more #html 4.01 utf8
Invoke-RestMethod -Uri 'http://news.sina.com.cn' |more # utf8
Invoke-RestMethod -Uri 'http://ip138.com' |more #gb2312
Invoke-RestMethod -uri "http://tv.sohu.com" |more #gbk
Environment data
win10 15063	+	PowerShell v6.0.0-beta.6
cenos 7.3 + PowerShell v6.0.0-beta.6

@dantraMSFT can you look into this?

Looking now. The challenge will be verifying.

The problem occured because Invoke-RestMethod was calling ContentHelper.GetEncoding.  This returns a fallback encoding which was defeating checks for meta tags in the response.  Explicit tests were added to cover the same variations as are tested for Invoke-WebRequest.

From beta7 i tested again,return:
already fixed
Invoke-RestMethod -Uri 'http://www.gov.cn' |more #html 4.01 utf8
Invoke-RestMethod -Uri 'http://news.sina.com.cn' |more # utf8
No fixed,Garbled still
Invoke-RestMethod -Uri 'http://weibo.com' | more #gb2312
Invoke-RestMethod -Uri 'http://ip138.com' | more #gb2312
Invoke-RestMethod -Uri 'http://tv.sohu.com' | more #gbk
Invoke-WebRequest -Uri 'http://tv.sohu.com' #gbk
Environment data
cenos 7.3 + PowerShell v6.0.0-beta.7

I'm not seeing the problem with 'http://weibo.com'.  Invoke-RestMethod is detecting the encoding correctly.  Can you be more specific?
For tv.sohu.com and ip138.com, I found a bug in Invoke-RestMethod. It is calling WriteVerbose with the encoding indicating the encoding name or header name but Encoding.EncodingName is throwing.  I'll need to change this and update the tests.

Oh, looks like this is .Net core 2.0 problem. Please help confirm the following:
Same as #3126,this code can return right strings of "http://weibo.com".
$gbk = [System.Text.Encoding]::GetEncoding(936)
$utf8 = [System.Text.Encoding]::GetEncoding(65001)
$iso88591 = [System.Text.Encoding]::GetEncoding(28591) #ISO 8859-1 ,Latin-1

$wrong_string = Invoke-RestMethod -Uri 'http://weibo.com'
$wrong_bytes = $utf8.GetBytes($wrong_string)

$right_bytes = [System.Text.Encoding]::Convert($utf8,$iso88591,$wrong_bytes)
$right_string = $gbk.GetString($right_bytes)
write-host $right_string

Environment data:
windows 10 build 14393 + PowerShell 5.1
=================================================
but this codes can not run in linux + powershell beta7, Problem code:
$utf8 = [System.Text.Encoding]::GetEncoding(65001) #normal
$gbk = [System.Text.Encoding]::GetEncoding(936) #System.NotSupportedException

return:
Exception calling "GetEncoding" with "1" argument(s): "No data is available for encoding 936. For information on defining a custom encoding, see
the documentation for the Encoding.RegisterProvider method."
Environment data:
cenos 7.3 + PowerShell v6.0.0-beta.7
IS THIS .NET CORE 2.0 PROBLEM? Please help us to see.

somebody tell me, .net core need:
1 import dll from nuget.   "System.Text.Encoding.CodePages"
2 use System.Text.Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)
But I do not know .net core 2.0 need to be so.

We already do this in private static void EncodingRegisterProvider()

Any further work on this I'm deferring to 6.1.0

ao

Submitted RFC for the creation of ConvertFrom-Html here: https://github.com/PowerShell/PowerShell-RFC/pull/137

We get new HttpClient with .Net 3+ so I remove the label.


BUG: special.chdtrc: returns 1.0 when both degrees of freedom and argument are negative

Describe your issue.
As expected, the CDF of the chi-squared distribution is undefined for negative degrees of freedom.
from scipy import special
special.chdtr(-1, [-1, 1])  # array([nan, nan])

Yet:
special.chdtrc(-1, [-1, 1])  # array([1., nan])

Reproducing Code Example
from scipy import special
special.chdtrc(-1, -1)  # produces 1.0 instead of NaN

Error message
NA

SciPy/NumPy/Python version and system information
1.15.0.dev0+935.e984c95 1.26.4 sys.version_info(major=3, minor=12, micro=3, releaselevel='final', serial=0)
Build Dependencies:
  blas:
    detection method: pkgconfig
    found: true
    include directory: C:/Users/matth/miniforge3/envs/scipy-dev/Library/include/openblas
    lib directory: C:/Users/matth/miniforge3/envs/scipy-dev/Library/lib
    name: openblas
    openblas configuration: USE_64BITINT= NO_CBLAS= NO_LAPACK= NO_LAPACKE= DYNAMIC_ARCH=ON
      DYNAMIC_OLDER=OFF NO_AFFINITY=1 USE_OPENMP= HASWELL MAX_THREADS=128
    pc file directory: C:\Users\matth\miniforge3\envs\scipy-dev\Library\lib\pkgconfig
    version: 0.3.27
  lapack:
    detection method: pkgconfig
    found: true
    include directory: C:/Users/matth/miniforge3/envs/scipy-dev/Library/include/openblas
    lib directory: C:/Users/matth/miniforge3/envs/scipy-dev/Library/lib
    name: openblas
    openblas configuration: USE_64BITINT= NO_CBLAS= NO_LAPACK= NO_LAPACKE= DYNAMIC_ARCH=ON
      DYNAMIC_OLDER=OFF NO_AFFINITY=1 USE_OPENMP= HASWELL MAX_THREADS=128
    pc file directory: C:\Users\matth\miniforge3\envs\scipy-dev\Library\lib\pkgconfig
    version: 0.3.27
  pybind11:
    detection method: pkgconfig
    include directory: C:/Users/matth/miniforge3/envs/scipy-dev/Library/include
    name: pybind11
    version: 2.12.0
Compilers:
  c:
    commands: cc
    linker: ld.bfd
    name: gcc
    version: 10.3.0
  c++:
    commands: c++
    linker: ld.bfd
    name: gcc
    version: 10.3.0
  cython:
    commands: cython
    linker: cython
    name: cython
    version: 3.0.10
  fortran:
    commands: gfortran
    linker: ld.bfd
    name: gcc
    version: 10.3.0
  pythran:
    include directory: ..\..\miniforge3\envs\scipy-dev\Lib\site-packages\pythran
    version: 0.15.0
Machine Information:
  build:
    cpu: x86_64
    endian: little
    family: x86_64
    system: windows
  cross-compiled: false
  host:
    cpu: x86_64
    endian: little
    family: x86_64
    system: windows
Python Information:
  path: C:\Users\matth\miniforge3\envs\scipy-dev\python.exe
  version: '3.12'

I looked at the implementation, and this appears to be intentional:
https://github.com/scipy/scipy/blob/5383624e90f02a3f1924ee8439a41be919bd8eb5/scipy/special/special/cephes/chdtr.h#L164-L178
To find why this change was made, I went looking through git blame, ignoring commits which only move code around. It appears to have been added in commit 867539341e.
Here's the diff from that commit, edited for length:
commit 867539341eb68e0a0ead13fc6c2170541fd5b41a
Author: Travis Oliphant<EMAIL_ADDRESS>Date:   Tue Feb 12 09:39:43 2002 +0000

    Added help for strings which searches scipy tree for object.  Changed stats names in special subdirectory.  Cosmetic changes to cephes *.c files (removed some funny control characters).

[...]

diff --git a/Lib/special/cephes/chdtr.c b/Lib/special/cephes/chdtr.c
index 271217a08..71c61280e 100644
--- a/Lib/special/cephes/chdtr.c
+++ b/Lib/special/cephes/chdtr.c
@@ -157,7 +157,8 @@ double chdtrc(df,x)
 double df, x;
 {

-if( (x < 0.0) || (df < 1.0) )
+if (x < 0.0) return 1.0;   /* modified by T. Oliphant */
+if (df < 1.0)
        {
        mtherr( "chdtrc", DOMAIN );
        return(0.0);

[...]

In conclusion, I still don't know why this change was made, but I figured I'd save anyone else the effort of finding this.

Thanks for tracking that down, but it still doesn't look correct to unconditionally return 1:
chdtrc(np.nan, -1)  # 1.0

From the C comments in the source code, it seems that the original cephes code returns 0 and sets an error code if x < 0. But if the function is treated as a survival function, a return value of 1 would be more appropriate for negative x. I guess that’s what the previous change was meant to achieve.
The fix is easy — set an error and return nan if df is non-positive. (Btw, the function returns 0 if df is zero; I’m not sure if that’s intended.)
Separately, the doc appears not completely consistent in specifying what the function returns. On the one hand it says the function is a survival function; on the other hand it says the function is an integral (that is not well defined for negative x.)

I'd like to submit a PR for this issue. But I see two possible solutions and I'd like to hear your opinion on which one is preferred: @mdhaber @nickodell @steppi
Solution 1: Fix the immediate issue with chdtrc by disallowing (v <= 0 or x < 0). Review the related functions chdtr, chdtri, chdtriv for consistency. (At least, right now chdtr(1, -1) returns nan, thus violating the desirable identity chdtr(v, x) + chdtri(v, x) == 1.) Update the docs to clarify the domain and special values.
Solution 2: Deprecate the four functions chdtr, chdtrc, chdtri, chdtriv in favor of the respective gamma functions gammainc, gammaincc, gammaincinv, gammainccinv because the ch* ones provide little/no value over the gamma* ones.
I'm inclined to go for Solution 2 because it saves maintenance burden -- efforts spent to make ch* better could better be spent to make gamma* better. The drawback is potential backward compatibility break (for user code), which I don't have the visibility to assess.

Solution 1 maintains backward compatibility, while Solution 2 reduces maintenance burden in the long run. What do you think?

I would argue in favor of Solution 1.

Many other projects use these functions. I searched chdtrc, and ignoring stuff that wraps cephes or SciPy, or provides a SciPy equivalent API, I count 3 repos which are using this in non-trivial ways on the first page. Assuming 3/20 of the 1.4k results are real users, that would correspond to about 200 users of this function. Removing this function would create churn in those projects.
It may be a trivial wrapper around igamc, but that also reduces the maintenance associated with it.

I can take a closer look at the actual issue when I have time, but just want to voice that I'm against deprecating and removingchdtr and friends. I don't think keeping them around will pose any significant maintenance burden once we've corrected the edge case behavior.

Thanks for the comments @nickodell, @steppi!
So, I proceed to check the edge cases of chdtr/chdtrc (chi-square distribution functions) and compare them to gdtr/gdtrc (gamma distribution functions) and gammainc/gammaincc.
For v == 0, the CDFs return 1.0 if x > 0 but nan if x == 0. I'm not sure how v == 0 is expected to be defined (this MathOverflow question suggests v == 0 corresponds to a point mass at 0), but at least the current behavior makes the CDFs not right-continuous at zero, which seems not very nice.

So it seems to me that, leaving the behavior of v == 0 aside, the easiest fix is to align chdtrc with the rest in terms of handling x < 0, i.e. to return nan instead of 1.0. Do you agree?

Do you agree?

I thought that the point of the _tr/_trc functions was that they would behave like CDFs/CCDFs and return a number for real x and valid shape parameter. But I guess that's not the case, so yes, I suppose chdtrc should be aligned with the rest w.r.t. x < 0.

I've been working on rewriting cdflib in C++, with the solver written in a regular structured style instead of the reverse communication style the original authors used to get around the limitations of F77. I guess I'll just make all of the edge case behavior consistent as I go.


CSBC Staging DCA is down

Describe the bug
Unable to access the CSBC staging DCA
To Reproduce
Steps to reproduce the behavior:

Go to CSBC Staging DCA
Get an error stating Error : invalid_redirect_uri. Redirect URI https://sagebio.shinyapps.io/csbc_data_curator_staging is not registered for DCA (project-agnostic)

Expected behavior
Should be able to log into CSBC DCA without the above error
Priority (select one)

[ ] Minor ⬇
[ ] Major 📢
[X] Critical 🆘

Screenshots

Desktop (if applicable, please complete the following information):

Chrome Version 101.0.4951.64 (Official Build) (x86_64)

I am receiving the same error.

@ychae @aclayton555 it's fixed now. The problem came from merging updates from the CSBC devel branch back into the main repo. This workflow pushed the default DCA to the CSBC staging URL.


Dropdowns activation method

I personally think it's not cool when dropdowns are falling out automatically (on mouse hover). I think it's more default to have it happening on click. Probably could make it optional in user settings?

I'll make it optional.
I prefer hovering method, I've addes special library for this.


[Request] EncryptCookies $except property should be method instead

If you have a legacy system with legacy authorization cookies, you will want to add those to the $except array of the EncryptCookies middleware so you can retrieve them without going through the decryption process.
However, some legacy apps (like Invision Power Board) let you define the cookie prefix, which could vary from one environment to the next, as such you need a way to dynamically define those cookie strings.
protected $except = [
    getenv('COOKIE_PREFIX').'session_id',
    getenv('COOKIE_PREFIX').'pass_hash'
];

is not allowed, as you can't have function calls in class properties.
As such, it would be better to have the array returned via a method rather than defined as a property so that you can dynamically build the cookie names to exclude.
For the time being, the parent's handle() method will have to be overridden, which is not quite as elegant.

Sounds like a good idea to me :+1:

Please don't create issues regarding small proposals. PRs are better. :)

Graham, I am not going to put in work that might be summarily rejected. I don't have the time to play pull request roulette.
I'll do a PR if I get confirmation that the proposal is a good idea.

:+1: both for the proposal and for waiting for a confirmation ;)

Sorry for being so late but...
Just so that if other people click on this issue through google, as I did, and don't find any code that might solve their problem, here is a simple work around:
<?php

namespace App\Http\Middleware;

use Illuminate\Cookie\Middleware\EncryptCookies as Middleware;
use Illuminate\Contracts\Encryption\Encrypter;

class EncryptCookies extends Middleware
{
    /**
     * The names of the cookies that should not be encrypted.
     *
     * @var array
     */
    protected $except = [];

    public function __construct(Encrypter $encrypter)
    {
        parent::__construct($encrypter);

        $this->except = [
          getenv('COOKIE_PREFIX').'session_id',
          getenv('COOKIE_PREFIX').'pass_hash',
        ];
    }
}

Hope it helps!

If everyone stumbles on this issue from google search - Here's another solution:
I had a similar issue, but in my case, I had to disable encryption for cookies that match a specific pattern. I found that you can customize the isDisabled-method, which checks if a cookie should be encrypted or not. Here's what I came up with:
<?php

namespace App\Http\Middleware;

use Illuminate\Cookie\Middleware\EncryptCookies as Middleware;

class EncryptCookies extends Middleware
{
    /**
     * The names of the cookies that should not be encrypted.
     *
     * @var array
     */
    protected $except = [
        'subscribed-to-newsletter',
        'gdpr-notified',
    ];

    /**
     * Determine whether encryption has been disabled for the given cookie.
     *
     * @param  string $name
     * @return bool
     */
    public function isDisabled($name)
    {
        if (preg_match('/ebook-\d+-page/', $name)) {
            return true;
        }
        return in_array($name, $this->except);
    }
}


Provide a way for layouts to determine if current page is an error page

In Sapper we did https://github.com/sveltejs/sapper/pull/1498
Suggestion from Rich for SvelteKit:

Given that it only applies to the root layout I think I'd prefer that we pass the error (and possibly status) as a prop. It doesn't belong on the page store

Created a new straightforward label for issues like this that should be pretty easy to implement since they don't touch a bunch of different places. In this case I think we just need to add a prop here... https://github.com/sveltejs/kit/blob/64d02910d0000a4ca28af7de1a1cae8f487cc5d7/packages/kit/src/core/create_app/index.js#L191 ...and add a test.
The one downside of this approach is that we'll get created with unknown prop warnings in dev if the root layout doesn't expose an error prop, but that's not the worst thing in the world

Could we partially relieve that by having the starter template define the prop in the root layout, even if it doesn't use it? That might not be worth it though, and would add bytes to the prod version just to avoid a dev time warning. I'm torn.

I think Svelte should probably skip the warning in cases where the prop is undefined anyway.
Relatedly, we have a similar problem with it often warning that a default slot was provided to a leaf component

We decided that the best way to do this would be
import { status, error } from '$app/stores';

closed via #3096


'Undefined is not a function error' in IE11

This is most likely caused by an issue in Babel 7.5.0.
See: https://github.com/babel/babel/issues/10166

This question is available on Nuxt community (#c9456)

This has now been fixed in 7.5.1:
https://github.com/babel/babel/releases/tag/v7.5.1

Well, that was fast :relaxed:


[feat] Add encryption to TableView

Fixes #

Master Issue: #
Motivation
Now that the C++ / C client supports
Modifications

Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation

[ ] doc-required
(Your PR needs to update docs and you will update later)

[ ] doc-not-needed
(Please explain why)

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

Sorry, wanted to create a PR in my fork first 😬


Istio-Pilot / Istiod HPA shows 0% cpu utilization

Bug description
On installing istio, an HPA is created named as 'istiod' and target deployment as 'istio-pilot' which shows 0% cpu utilization at all times. In 1.6.0, there is no specific deployment called istio-pilot. Even if I edit the HPA and put istiod as scaleTargetRef Deployment, then too it shows 0%.
[X] Configuration Infrastructure
[ ] Docs
[X] Installation
[ ] Networking
[X] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
HPA should be configured based on proper deployment and show correct cpu utilization.
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.6.0
How was Istio installed?
istioctl
Environment where bug was observed (cloud vendor, OS, etc)
AWS EKS

Where does that HPA come from?
~/istio/istio-1.6.0/bin/istioctl manifest generate shows:

# Cni component is disabled.

# EgressGateways istio-egressgateway component is disabled.

# Resources for IngressGateways component

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  labels:
    app: istio-ingressgateway
    istio: ingressgateway
    release: istio
  name: istio-ingressgateway
  namespace: istio-system
spec:
  maxReplicas: 5
  metrics:
  - resource:
      name: cpu
      targetAverageUtilization: 80
    type: Resource
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: istio-ingressgateway

---

# IstiodRemote component is disabled.

# Resources for Pilot component

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: istiod
  namespace: istio-system
  labels:
    app: istiod
    release: istio
    istio.io/rev: default
spec:
  maxReplicas: 5
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: istiod
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 80

No istio-pilot is found

I have the same issue. 1.6.2.  I have a custom profile slightly modified from a dump of the default profile.  I didn't modify anything istiod or pilot related.
But check out this clean example even without any mods:
istiod hpa has correct label:
istioctl manifest generate --set profile=default |kubectl apply -f -

istio hpa has wrong label:
istioctl profile dump default > profile.yaml
istioctl manifest generate -f profile.yaml |kubectl apply -f -

zero modifications of the profile.yaml file

@richardwxn ^

taking a look


[URGENT] CW account potentially hacked

@jhoffner ,
I suspect that someone managed to log in to my CW account without my permission within the last 24 hours.
When I logged in to my CW account for the first time today just now, I suddenly received a notification that I have gained 4 kyu rank progress in Java.  Previously, I was already quite close to 4 kyu in Java myself, but I think I still had about 20% rank progress to go and today I was already 5% into 4 kyu in Java which is rather suspicious.  I seriously doubt that this sudden increase in rank progress is due to previous Java Kata I have solved and/or previous Java translations I have written that were recently approved because Java is not my main language and therefore I have not written a single Java translation before and I am highly unlikely to have completed a Java Kata that is still in Beta.
Please do investigate this issue thoroughly and ban the IP address of whoever may have done it.  Furthermore, if my account has happened to use any Java cheats during the last 24 hours, please simply reset my Java progress for those Kata - I swear that I have not cheated on any Java Kata myself.
Yours sincerely,
DonaldKellett (donaldsebleung on Codewars)
A concerned power user

Sorry for the false alarm, I literally just realized where all that extra rank progress in Java came from - I did indeed complete a beta Kata in Java a few weeks ago which has just been recently approved and is currently ranked 3 kyu.


Can't get it to work in NuxtJS

This is probably just a configuration error, but seeing that #15 isn't related I thought I might open a new one. I have added slate-vue to my Nuxt project and enabled the plugin in nuxt.config.js.
// plugins/vue-slate.js
import Vue from 'vue'
import { SlatePlugin } from 'slate-vue'

Vue.use(SlatePlugin)

// nuxt.config.js
{
  build: {
    transpile: ['slate-vue']
  },
  plugins: ['~/plugins/vue-slate.js'],
}

I still experience the Unexpected token 'export' error. That's why I added the package to the transpile key in the first place. As soon as I remove the plugin file reference from the plugins array, the website loads fine.
Edit: I've uploaded the project: https://github.com/SirWindfield/zt-write. It's basically just the default template (yarn create nuxt-app zt-write) with slate-vue added and configured.

Looks like the plug-in only works when disabling ssr, not sure why though.

Looks like the plug-in only works when disabling ssr, not sure why though.

Sorry to re-open this but for some reason it doesn't work again today. I used the exact same project that I had yesterday with ssr disabled but that fails today. Cleaned cache and everything. Maybe someone else has/had similar issues...

Sorry to re-open this but for some reason it doesn't work again today. I used the exact same project that I had yesterday with ssr disabled but that fails today. Cleaned cache and everything. Maybe someone else has/had similar issues...

I don't have enough time to test. You can set mode: 'SPA' as a temporary solution. I will test it this weekend.

I don't have enough time to test. You can set mode: 'SPA' as a temporary solution. I will test it this weekend.

Thank you for taking the time to try it out!

Thank you for taking the time to try it out!

I have done some tests and found the problems. The module for tsx support<EMAIL_ADDRESS>only has ES6 dist version.
Just add it to transpile option like :
build: {     transpile: ['slate-vue', 'vue-tsx-support']   }

I have done some tests and found the problems. The module for tsx support<EMAIL_ADDRESS>only has ES6 dist version.
Just add it to transpile option like :
build: {     transpile: ['slate-vue', 'vue-tsx-support']   }

Oh, the trick is to add both of them, dang. I only added slate-vue. Thanks!!!

JFYI, you can get this to work with SSR (and e.g. the static target) when wrapping the <Slate> component in <client-only> in order to bypass prerendering for this specific part of the code. https://nuxtjs.org/docs/features/nuxt-components/#the-client-only-component


Custom elevation for BottomBar

Can you add this method? This will be very useful.

By elevation, do you mean a larger shadow or controlling the z-index?

Yes. Controlling z-index may be very useful.
On Fri, Mar 25, 2016, 13:47 Iiro Krankka<EMAIL_ADDRESS>wrote:

By elevation, do you mean a larger shadow or controlling the z-index?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/roughike/BottomBar/issues/83#issuecomment-201237316

@TemMax According to MD specs Bottom navigation component should have 8dp elevation to be between navigation drawer and snackbar. :)

@NikolaDespotoski is right.
Controlling z-index / elevation would possibly break some behavior with snackbars.
I'm closing this one.


Add multidex flag and automatic multi dex support

This PR adds multi dex support to the flutter_tool. Resolves https://github.com/flutter/flutter/issues/21009
When the multi dex gradle build error is detected, Flutter will prompt the developer whether they wish to enable multi dex support. If yes, android/app/multidex-flutter-keepfile.txt and android/app/src/main/java/io/flutter/app/FlutterMultiDexSupportUtils.java will be added and the build will be retried.
Once enabled, the existence of the files will be used to determine if the multi dex gradle groovy configs and dependencies should added to the app. In practice, this means that apps will build without issue after selecting enable.
Developers who don't want this may pass the --no-multi-dex flag to disable this automated support for flutter run and flutter build commands.
The FlutterMultiDexSupportUtils is called via reflection by the android embedding: https://github.com/flutter/engine/pull/28974
tags: multidex 64k

Would prefer if the approach is reviewed first, will add tests shortly.

other than the two comments, approach LGTM

In testing with lower API devices, turns out multidex is incompatible with reflection. Moving forwards with an alternative solution.

New approach:

codegen FlutterMultiDexApplication.java, thus avoiding adding overhead to non-multidex apps by not including it as an engine dependency. This also makes it easier for developers to integrate it with any custom android implementations.
Use manifest variable injection to automatically inject either android.app.Application or io.flutter.app.FlutterMultiDexApplication depending on if multidex is enabled or not. The template should now include a variable for <application android:name="{$applicationName}> property in AndroidManifest.xml
For older apps that do not have the variable injection in their manifest, we ask them to manually add the line.
Newly generated apps should already have the variable injection and can automatically enable multidex.


[FancyZones] Create layout from current windows

Feature to "snapshot" your current windows into a new layout

(copied from my duplicate feature request)
The custom layout creator should provide a way to add a new zone that matches an open window.
After windows have been organized into a desirable arrangement, it would be great to easily create a custom layout using the windows' positions.
Currently, it is possible to create a custom layout with approximate zone sizes & positions by dragging & resizing zones. It would be a cleaner experience if the editor provided a way to create a new zone that matches an open window.
I can imagine this being implemented as something simple like selecting a window from a list, or something more robust like picking a window with the mouse

From https://github.com/microsoft/PowerToys/issues/295

Why go through the hassle of manually creating and editing a Fancy Zones template, when I'm already using a window arrangement I like, and I simply need a way to save and quickly restore it?
The created template should also preserve the apps associated with each pane. (Or is it the other way around? Apps should remember their zone association for the new template.)
A hot-key or Fancy Zones UI button should trigger the action, then invoke the editor on the new template for the user to adjust as desired, then manually save.

Here is something that helped my specific problem, and may help in general: https://tjinit.com/?p=7
Whenever my monitor turned off, the PC video interface went to its "default" resolution, which relocated/resized the windows, which were then misplaced when the monitor next powered on.  Fortunately, these defaults are all in the Registry, so setting them to match my physical monitor size eliminated my specific issue.

Another reason this would be useful is fingerprinting protection in browsers. Firefox and Tor both rely on having a 1000x1000 resolution to make user-fingeprint less unique. When I switch monitors or drag something unintentionally it gets all messed up. I then have to go a readjust everything pixel-by-pixel. It'd be nice to have FancyZones save the layout taking into account FF/Tor (or any other window) position.

Tracked in https://github.com/microsoft/PowerToys/issues/6611

Here is something that helped my specific problem, and may help in general: https://tjinit.com/?p=7
Whenever my monitor turned off, the PC video interface went to its "default" resolution, which relocated/resized the windows, which were then misplaced when the monitor next powered on. Fortunately, these defaults are all in the Registry, so setting them to match my physical monitor size eliminated my specific issue.

thx a lot, but for me the simulated device is missing in registry. any advice?

Was this ever implemented?  If not, why was it closed?  It would be a very logical and extremely useful feature.

@unimatter
this feature is tracked in #6611

Perhaps I misunderstand, but #6611 looks like just a compilation of issues, not the issues themselves which are separately tracked.  Since the individual issue (#159) is closed, it appears as if it was resolved.

@unimatter
when we resolve an issue we label it Resolution-fix-committed

The custom layout creator should provide a way to add a new zone that matches an open window.
Agreed, and also reposition/resize an existing zone to match up to a current window.

This is becoming even more needed: I've started doing training videos using OBS, employing the OBS window stream feature to switch between multiple active 1280x720 windows on my 4K desktop.  But each OBS session requires me to tediously orient the windows to their precise prior size and locations for consistent behavior between OBS sessions.
Getting these windows sized and placed using a single FancyZones keystroke would be epic.


Shoot cannot be deleted if the InfrastructureConfig is mis-configured

What happened:
Shoot cannot be deleted if the InfrastructureConfig is mis-configured, the error is:
Last Error
task "Waiting until shoot infrastructure has been reconciled" failed: failed to create infrastructure: retry failed with context deadline exceeded, last error: extension encountered error during reconciliation: Error reconciling infrastructure: no kind "InfrastructureConfig" is registered for version "aws.provider.extensions.gardener.cloud/v1alpha1" in scheme "github.com/gardener/gardener-extension-provider-gcp/pkg/apis/gcp/helper/scheme.go:45"

What you expected to happen:
The shoot is deleted successfully.
How to reproduce it (as minimally and precisely as possible):
Create a shoot with mis-configured InfrastructureConfig and delete the shoot.
....
  provider:
    type: gcp
    infrastructureConfig:
      kind: InfrastructureConfig
      apiVersion: aws.provider.extensions.gardener.cloud/v1alpha1
      networks:
        worker: ''
        workers: <IP_ADDRESS>/16

Anything else we need to know?:
We use a go client to create shoots (the error would not have happened if we use the gardener UI), and a code bug causes the GCP shoots are created with the aws InfrastructureConfig
Environment:

Gardener version: v1.0.4
Kubernetes version (use kubectl version): v1.16.7
Cloud provider or hardware configuration: GCP

Hello @aylei, thanks for filing the issue - can you try with v1.4.0 of the GCP extension? The problem should have been fixed with https://github.com/gardener/gardener-extension-provider-gcp/pull/44.

@rfranzke Thanks! I cannot for now because I am still using gardener v1.0.4, which is not compatible with GCP extension v1.4.0. I will schedule an update and try out then.

@aylei I'm closing this issue for now as I expect that it's fixed, kindly reopen if you still have problems. :)


Bug report

What happened?

=== c++
``` c++
std::cout << "hello c++!" << std::endl;
```

=== c
``` c
printf("hello, c!");
```

=== latex
$$ \alpha \to \beta $$

The code block inside the tab for C++ does not display the correct syntax highlighting.
Sample Markdown
No response
Errors
No response
Obsidian Version
No response
Plugin Version
No response
OS
Windows

Hey the plugin renders the content in reading mode. And Obsidian uses different parsers for Live Preview and Reading mode (not sure why).
I think it Live Preview uses CodeMirror's syntax highlighting and Reading uses PrismJS.
So, the parser in Reading mode (PrismJS) doesn't support "c++" for the language. It supports "cpp" though.

I got this error output in reading mode, and my Obsidian Version is 1.7.7, running on Windows 10.

Dataview?
If possible, can you send:

Full markdown
Tab panels settings
Dataview settings (Not sure if needed but it would be helpful to see if there is any Dataview interactions)

Thx, I disabled the Dataview plugin, and the issue disappeared.

Full markdown
index.md

Tab panels settings

Dataview settings
The Dataview settings are default

Not sure if you still want to use Dataview with the plugin. If you don't need Dataview, ignore everything that's said here.
However, if you still want to use Dataview together, continue reading.
Reproducing the issue.
I created a new vault and tried it but I couldn't reproduce it.
This was the closest I got. I needed to change some things though.

Changes:

Enable inline js in Dataview settings
Put backticks to trigger Dataview inline. (Arrows in picture)

But this only happens when it's on the same line...
Maybe try to remove the ~~~tabs syntax and see if it's a problem with this plugin or does it happen even outside of the plugin. Since this plugin just takes whatever markdown you have and render it out like it's in reading mode.

Thank you, this is not important anymore.
By the way, I wrote an MkDocs plugin that can convert the syntax of your plugin into a syntax supported by MkDocs.

Ah, I see. Well, it’s great that the issue is resolved for now!
Oh, nice! Currently, I don’t have any notes I want to make public, so I haven’t tried tools like MkDocs yet. That said, I might use your plugin when I do! Or, if I have some free time, I could look into finding a good way to add that functionality natively into the plugin.
Initially, I wanted to fully support MkDocs syntax (I think the main difference is just the quotes?), but I couldn’t find a simple way for the average user to quickly understand and modify the syntax.
Some of the approaches I considered were:

Using regex: This felt too complicated and error-prone, especially for users unfamiliar with regex.
Adding an option: While this could work, I don’t think many users would use it. It might even confuse them. Maybe if there were more syntaxes beyond MkDocs that needed support, it would make sense, but I doubt there are enough to justify it.

Anyway, I’m nice that you found a workaround!

Thank you for the detailed explanation and for taking the time to address the issue!
Your guidance was really clear and helpful.
I appreciate how actively you're supporting the community with this plugin.
Keep up the amazing work!


How to both seed and leech

Hey! I'm trying to figure out the best way to have several machines both leech and seed. As of right now, I've got:
Server A (seeder):
datadir: /Users/nathanpierce/Library/Application Support/Veertu
database: seeder.db
datadirincludestorrentid: false
rpcport: 7246
dhtenabled: false
portbegin: 50000
portend: 50001

Server B (leecher):
datadir: /Users/administrator/Library/Application Support/Veertu
database: leecher.db
datadirincludestorrentid: false
rpcport: 7247
dhtenabled: false

Is it as simple as adding portbegin and portend to the leecher configs on each server and then running add-peer --addr... for not only the seeder IP:50000 but also for each leecher I want to also be a seeder?
Let me know if this isn't clear and I'll elaborate. I'd like a single seeder that has the source file and then a bunch of leechers to connect to not only the original seeder but all of the other leechers.

I don't recommend doing that manually. Add a tracker address while creating the torrent file. You can use a public tracker such as http://opentrackr.org or run yourself one.
If you use a tracker, you will not need to keep track of IP addresses and port numbers.

I don't recommend doing that manually. Add a tracker address while creating the torrent file. You can use a public tracker such as http://opentrackr.org or run yourself one.
If you use a tracker, you will not need to keep track of IP addresses and port numbers.

Can rain act as a tracker by chance?

Can rain act as a tracker by chance?

No, but you can use on of these:

https://github.com/chihaya/chihaya
http://erdgeist.org/arts/software/opentracker/

No, but you can use on of these:

https://github.com/chihaya/chihaya
http://erdgeist.org/arts/software/opentracker/


(paint.net) Update dependencies

Description

Motivation and Context
Fixes #1299
How Has this Been Tested?
Tested on local test environment
Screenshot (if appropriate, usually isn't needed):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the chocolatey test environment.
[x] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review

Agreed, this wasn’t intended to directly address comments in Twitter, but rather to correct an issue that was noticed during testing of package.


Add reliquary support as staking option & calculate apr

resolves #154

You also need to hook up the APR service.

hooked up the apr service, will run some local tests anyways before we merge but kinda blocked until we can deploy the new version of reliquary


bfgminer cannot mine using cpu

i tried to follow the tutorial in the website but i didn't understand it please show me another way send the information to this email<EMAIL_ADDRESS>

can you send me the BFGminer that has CPU enabled to my email<EMAIL_ADDRESS>


Thank you Monyx

You got our money and now you are going to trade with it, but we will get casino after 3 months, that is completely "normal". Bought for 45 cent now 17 excellent! That is how you appreciate your early investors!
Guys do something.

buy-back plan tomorrow at MARKET PRICE

no btc withdrawal for 3 days lol ,,, im losing hope to get my .2 btc ----

Where did you read that they are going to buy at market price?

WOW!

Read Twitter People

Doesnt matter if we sell or buy lol.

They are going to fix that soon, read other thread on Github

Thanks IamTheM8

no worries m8, we all are here to help, and carry on

market price is 16c lol

ALL PLAN ARE USLESS WITHOUT BTC WITHDRAWAL
SCAMMMM


Invalid output with strings that are only a newline.

A string that is "\n" will be encoded as |\n but it should be |+\n at least or rather simply "\n"
This code:
Mix.install([{:ymlr, "~> 4.2"}, {:yamerl, "~> 0.10.0"}])
data = %{top: "\n", nested: %{key: "\n"}, correct: "aaa\nbbb"}
yaml = data |> Ymlr.document!()
IO.puts(yaml)
data = :yamerl_constr.string(yaml, str_node_as_binary: true)
IO.inspect(data, label: ~S/loadeddata/)

Produces this:
---
top: |

nested:
  key: |

correct: |-
  aaa
  bbb

loadeddata: [[{"top", ""}, {"nested", [{"key", ""}]}, {"correct", "aaa\nbbb"}]]

Hey @lud-wj
What makes you think this is wrong behaviour?

Thank you :)


add changelog for 1.14.0

Description
Adds changelog for 1.14.0 which is already released
Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have signed the CLA
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
[ ] I have run changie new to create a changelog entry

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 68.89%. Comparing base (243568e) to head (de4b181).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #231   +/-   ##
=======================================
  Coverage   68.89%   68.89%
=======================================
  Files          52       52
  Lines        3433     3433
=======================================
  Hits         2365     2365
  Misses       1068     1068

Flag
Coverage Δ

unit
68.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Tesla Wall charger (TWC3) support via vehicle-command API for Tesla vehicles

Is your feature request related to a problem? Please describe.
The introduction of the Tesla vehicle-command SDK has changed the APIs for Tesla vehicle management. The TWC3 charger cannot be controled via EVCC and must be managed via changing the charging parameters on the Tesla vehicle via the SDK. The new SDK requires additional Public/Private key pairs and authority from the user for EVCC to manage the vehicle.
Describe the solution you'd like
The new vehicle-command SDK is only implemented in a read-only implementation. Read-write is needed to re-indroduce the EVCC functionallity that existed with the old API. The API gateway is now region specific so additional checks are needed to use the correct gateway:  You can query the users region and appropriate fleet-api URL so you should be able to dynamically assign it
https://developer.tesla.com/docs/fleet-api?shell#region
Describe alternatives you've considered
Other projects are also tackeling this same challenge. To date there are implementations by;

https://chargehq.net/
https://github.com/pkuehnel/TeslaSolarCharger
https://www.tessie.com/

Additional context
Thank you

It will be good if this is implemented to control charging, as the charging is then controlled directly on the vehicle itself. That means any charger  (including mobile chargers) can work with a Tesla vehicle, very much like Charge HQ.

Couple of things:

Make sure that https://github.com/evcc-io/evcc/pull/10802 works for you, i.e. you can retrieve soc.
Get a Tesla developer account- follow steps at https://github.com/teslamotors/vehicle-command and note https://github.com/teslamotors/vehicle-command/issues/111
Any insight about other self-hosted solutions is welcome. Key issue here is, that controlling the vehicle needs a private key installed on the vehicle. evcc does have a private key that can be installed but we obviously not distribute that.
When 1+2 are completed we can look into implementation. Depends on https://github.com/teslamotors/vehicle-command/issues/29.

Hi @andig,
I'll follow up on these points. Fully agree not to distribute private key, that would be silly.
A thought, when users are generating their keys on https://tesla.evcc.io/ would it be possible for EVCC servers to push the private key to the vehicle and generate a unique public key for each user?
I don't believe EVCC users would be able to retrieve the private key from their Tesla's.

Hi @andig
Wenn ihr jemanden zum testen braucht, könnt ihr euch gerne melden. Mir stehen zwei evcc Instanzen mit jeweils einem TWC und einem Tesla zur Verfügung.

Problem is that in order to send vehicle commands, one must have the private key corresponding to the public key installed on the vehicle. That private key is a SECRET. One way of not distributing the secret might be running a vehicle command proxy (see https://github.com/teslamotors/vehicle-command/tree/main/cmd/tesla-http-proxy). Not sure if thats doable- needs more investigation.

This sounds promising, the app would run the proxy or is it something EVCC needs to host?

@andig confirmed #1 is now working in US and can retrieve SOC with latest nightly. @yipikaye can you try and see if it works for you too?

@infinus yes I plan to, I'm away for a few days and for some reason it seems I can't ssh into home 😔
When is it going into the stable branch, I'll see if I can get it done before then

Problem is that in order to send vehicle commands, one must have the private key corresponding to the public key installed on the vehicle. That private key is a SECRET. One way of not distributing the secret might be running a vehicle command proxy (see https://github.com/teslamotors/vehicle-command/tree/main/cmd/tesla-http-proxy).
Not sure if thats doable- needs more investigation:

Do not listen on a network interface without adding client authentication. Unauthorized clients may
be used to create excessive traffic from your IP address to Tesla's servers, which Tesla may respond
to by rate limiting or blocking your connections.

...which would bring us to client certificates.

Sounds great, can't wait to test it :)

@andig May I suggest a creation of Template based on Tessie API? https://developer.tessie.com/docs/about
They provide their users an API that I guess works the same way Tesla API used to work.
Thanks! ;)

@manuelmrmorgado
Tessie has private servers and can host the client secret which is needed and should not be shared. EVCC is open sourced and usually run at home so they have can’t protect those like Tessie can. They are looking at setting up a proxy but that it a work in progress. It is much easier for projects like Tessie, teslafi, or Optiwatt to introduce these changes than open source projects like EVCC or Teslamate. It’s trying to find a delicate balance between ease of use, privacy, and security.

This proxy seems promising!
It's great to see the improvements and the active team. This is what open source is all about!

Feel free to open a PR for Tessi integration.

Hi @andig, would this issue be why I am getting [main  ] ERROR 2024/02/01 19:28:58 creating vehicle ev3 failed: cannot create vehicle type 'template': cannot create vehicle type 'tesla-command': oauth2: "login_required" "Login required" "https://auth.tesla.com/error/reference/a15ecfb6-0272-46a6-b3d8-af10870b8af4-1706776138785" after switching to tesla-command and 124.0?

@haroldboom this Issue is about TWC. Please don't cross-post. Tesla integration is confirmed working. Feel free to share login information with<EMAIL_ADDRESS>for further diagnosis.

@manuelmrmorgado re Tessi that would mean that the old Tesla integration would continue to work by swapping the URL. Since we're using https://github.com/bogosj/tesla under the hood, swapping URI and adding API key would need to be done there. I suggest to open an issue with bogosj/tesla.

I upgraded to 0.124.0 Version now and changed the config to new api. Also added both tokens to config. Car is now recognizing from evcc. But EVCC is not able to controll, start or stop charging.

@haroldboom this Issue is about TWC. Please don't cross-post. Tesla integration is confirmed working. Feel free to share login information with<EMAIL_ADDRESS>for further diagnosis.

I´m confused. If I understand it correct, the Tesla integration with reading values is now working again with the new API, but we cannot send any commands to the car atm, which can be done via a proxy integration?
As far as for TWC3: Didn´t the car control the whole charging in the past, since the TWC3 is not controlable? Has anything changed here?

Hi @andig is the proxy in the nightly or still in draft stage?

See PR- it is nowhere yet.

Don't know if it helps, but here they are also looking at a solution with a proxy:
https://github.com/llamafilm/tesla-http-proxy-addon?tab=readme-ov-file

I also want to add, that Tesla Solar Charger is working with flawlessly with the new API. I´m using it as a temporary solution now until EVCC catches up.

Does anyone use Tessie and wants to share his credentials with<EMAIL_ADDRESS>That could be a simple drop-in replacement for controlling the vehicle. At least a workaround until we can build our own Tesla Proxy.

I gave Tessie a quick try (thanks Brin). We should be able to add Tessie, but its really its own integration using a different API structure from Tesla. See https://github.com/evcc-io/evcc/issues/12183.

@andig
First of all, thank you for your efforts! In the context of the ideas with Tessie, I am currently thinking about trying this out.
One question: In addition to controlling the Tesla, would the vehicle's other data also be retrieved directly via Tessie or would the existing evcc Tesla implementation would do this job?

Its the same thing

Short update: we're continuing to investigate running our own Tesla Proxy. Apart from testing, we still need to figure how  to handle token refreshes. This depends on resolving any lingering token refresh issues that couldn't be pin-pointed yet.

I see the PR is now closed. Does this mean the next release will have the functionality with some limitations around token refreshes or will you hold off until the token refresh is solved?

I see the PR is now closed. Does this mean the next release will have the functionality with some limitations around token refreshes or will you hold off until the token refresh is solved?

https://github.com/evcc-io/evcc/pull/12174 Still open

I've got to stop drinking 🍺

Good news: we've just merged a new tesla-proxy template which will talk via evcc's Tesla API Proxy to the Tesla Fleet API. This requires:

Sponsor token for proxy authentication
Tesla tokens for Fleet API access
evcc virtual private key installed on vehicle

If you're missing the last step just create new tokens, the virtual key is visible after token creation. Let's try it!
Nightly will be available in 30 minutes.

Good news: we've just merged a new tesla-proxy template which will talk via evcc's Tesla API Proxy to the Tesla Fleet API. This requires:

Sponsor token for proxy authentication
Tesla tokens for Fleet API access
evcc virtual private key installed on vehicle

If you're missing the last step just create new tokens, the virtual key is visible after token creation. Let's try it!
tesla-proxy and tesla-command are allowed to share tokens. evcc will manage lifecycle internally. Tokens MUST NOT be shared with other applications since token refresh will invalidate other applications token.
Nightly will be available in 30 minutes.

Perfect, thanks :)
How can i install the private key on the vehicle? I redo the last step but i didn't get a virtual key...

Seems I need to rebuild the proxy, too. Will shortly.

I'm ready to test when it is ready. Model 3/Enphase Solar/TWC3.
I do not have a Powerwall or any other ESS.

Good news: we've just merged a new tesla-proxy template which will talk via evcc's Tesla API Proxy to the Tesla Fleet API. This requires:

Sponsor token for proxy authentication
Tesla tokens for Fleet API access
evcc virtual private key installed on vehicle

If you're missing the last step just create new tokens, the virtual key is visible after token creation. Let's try it!
tesla-proxy and tesla-command are allowed to share tokens. evcc will manage lifecycle internally. Tokens MUST NOT be shared with other applications since token refresh will invalidate other applications token.
Nightly will be available in 30 minutes.

Hey Andy, so after I get the new nightly do I recreate the token via Tesla.evcc.io and I should get a prompt about a private key? I tried this and nothing after the tokens appear

I tried with evcc/evcc:nightly.
My config:
vehicles:
  - name: tesla
    type: template
    template: tesla-proxy
    accessToken: [token]
    refreshToken: [token]
    capacity: 60

I seem to get 500 Server when trying to control the vehicle. I didn't get the part about virtual key, and didn't see anything after creating the tokens.

[lp-1  ] INFO 2024/02/15 22:45:19 car connected
[lp-1  ] DEBUG 2024/02/15 22:45:19 pv timer elapse
[lp-1  ] DEBUG 2024/02/15 22:45:19 pv timer inactive
[lp-1  ] INFO 2024/02/15 22:45:19 start charging ->
[lp-1  ] DEBUG 2024/02/15 22:45:19 wake-up timer: stop
[lp-1  ] DEBUG 2024/02/15 22:45:20 vehicle status: C
[lp-1  ] DEBUG 2024/02/15 22:45:20 vehicle soc: 41%
[lp-1  ] DEBUG 2024/02/15 22:45:20 vehicle soc limit: 50%
[lp-1  ] DEBUG 2024/02/15 22:45:20 vehicle range: 168km
[lp-1  ] WARN 2024/02/15 22:45:20 charger out of sync: expected disabled, got enabled
[lp-1  ] DEBUG 2024/02/15 22:45:20 forced charging at vehicle soc 41% (< 50% min soc)
[lp-1  ] ERROR 2024/02/15 22:45:20 max charge current 16A: 500 Internal Server Error

Seems I need to rebuild the proxy, too. Will shortly.

Done- should offer the virtual key now.

I seem to get 500 Server when trying to control the vehicle

Virtual key installed?! Likely not. Trace log for Tesla would help.

It's working!
Thanks andig and everyone.
I want to charge on solar, but also I am stuck pre-PTO so it's extra important for me.

I probably should have asked this a while ago, are there nightly deb files so I don't have to keep doing it manually?

Seems I need to rebuild the proxy, too. Will shortly.

Done- should offer the virtual key now.

I seem to get 500 Server when trying to control the vehicle

Virtual key installed?! Likely not. Trace log for Tesla would help.

Can confirm tesla.evcc.io virtual key is working and EVCC is working with my TWC3. Will test today and post back if something goes wrong

Does this mean the charging rate is controlled at the Tesla vehicle, instead of the EVSE ? Does this mean that this approach is EVSE agnostic ?

I get a 500 server error but I have generated new tokens... Do i need to revoke the existing and start again?

I get a 500 server error but I have generated new tokens... Do i need to revoke the existing and start again?

I did not need to revoke existing.
Did you continue below and add the virtual key and use the QR to add it in the Tesla app?

No i missed that last step as I cannot read German :) I updated the above comment.
It is working well!

No i missed that last step as I cannot read German :) I updated the above comment. It is working well!

I had to have my browser translate the page to English so I could read that part.

Is anyone else getting server errors from the proxy?
 ERROR 2024/02/16 10:22:11 charger disable: Post "https://tesla.evcc.io/api/1/vehicles/LRWYHCEK5PC906710/command/charge_stop": read tcp [2406:2d40:406f:d900:9e8c:167c:3ba4:ba50]:60448->[2a09:8280:1::69:9409]:443: read: connection reset by peer

Is anyone else getting server errors from the proxy?  ERROR 2024/02/16 10:22:11 charger disable: Post "https://tesla.evcc.io/api/1/vehicles/LRWYHCEK5PC906710/command/charge_stop": read tcp [2406:2d40:406f:d900:9e8c:167c:3ba4:ba50]:60448->[2a09:8280:1::69:9409]:443: read: connection reset by peer

I am not seeing that or any other errors.

Hmm something has gone wrong. It was working for a short while, now:
ERROR 2024/02/16 10:38:42 charger enable: 500 Internal Server Error

It appears the car went to sleep and with the proxy it doesn't wake. I restarted the EVCC service and got the following
Feb 16 10:43:28 raspberrypi evcc[11093]: [main  ] ERROR 2024/02/16 10:43:28 vehicle status: asleep Feb 16 10:43:28 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:28 max charge current 5A: vehicle not capable of current control Feb 16 10:43:30 raspberrypi evcc[11093]: [lp-1  ] INFO 2024/02/16 10:43:30 vehicle updated: unknown -> Pikachu

Yes, if I wake the car via the moble app then the charging control starts working properly again with no intervention on EVCC from me.

So we have a minor wake the vehicle issue :)

```Feb 16 10:43:30 raspberrypi evcc[11093]: [lp-1  ] INFO 2024/02/16 10:43:30 vehicle updated: unknown -> Pikachu
Feb 16 10:43:42 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:42 vehicle odometer: asleep
Feb 16 10:43:42 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:42 vehicle soc: asleep
Feb 16 10:43:45 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:45 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:00 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:00 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:15 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:15 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:30 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:30 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:44 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:44 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:59 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:59 max charge current 5A: 500 Internal Server Error
Feb 16 10:45:15 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:45:15 max charge current 5A: 500 Internal Server Error
Feb 16 10:45:42 raspberrypi evcc[11093]: [lp-1  ] INFO 2024/02/16 10:45:42 start charging ->
Feb 16 10:46:27 raspberrypi evcc[11093]: [lp-1  ] INFO 2024/02/16 10:46:27 stop charging <-

Yes, if I wake the car via the moble app then the charging control starts working properly again with no intervention on EVCC from me.
So we have a minor wake the vehicle issue :)
Feb 16 10:43:42 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:42 vehicle odometer: asleep
Feb 16 10:43:42 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:42 vehicle soc: asleep
Feb 16 10:43:45 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:43:45 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:00 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:00 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:15 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:15 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:30 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:30 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:44 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:44 max charge current 5A: 500 Internal Server Error
Feb 16 10:44:59 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:44:59 max charge current 5A: 500 Internal Server Error
Feb 16 10:45:15 raspberrypi evcc[11093]: [lp-1  ] ERROR 2024/02/16 10:45:15 max charge current 5A: 500 Internal Server Error
Feb 16 10:45:42 raspberrypi evcc[11093]: [lp-1  ] INFO 2024/02/16 10:45:42 start charging ->
Feb 16 10:46:27 raspberrypi evcc[11093]: [lp-1  ] INFO 2024/02/16 10:46:27 stop charging <-

Hi all, I also have the same issue, EVCC cant wake the vehicle to charge. If I wake manually with the app it will start. Also getting the
evcc[632]: [lp-1  ] ERROR 2024/02/16 00:20:02 max charge current 5A: 500 Internal Server Error when trying to wake

No errors for me so far, but I will test this.
As soon as I run out of sunlight today, I will set my car to higher than the current SOC. I'll leave it alone until tomorrow and see if it wakes up to charge when there is enough solar. I generally get enough sun by 10AM (PST).

No errors for me so far, but I will test this.
As soon as I run out of sunlight today, I will set my car to higher than the current SOC. I'll leave it alone until tomorrow and see if it wakes up to charge when there is enough solar. I generally get enough sun by 10AM (PST).

I just let the car go to sleep and switched EVCC to fast or minpv and that forces the error for me

Seems I need to rebuild the proxy, too. Will shortly.

Done- should offer the virtual key now.

I seem to get 500 Server when trying to control the vehicle

Virtual key installed?! Likely not. Trace log for Tesla would help.

I can also confirm that vehicle control works after installing the virtual key. Thanks for the great work!

I just let the car go to sleep and switched EVCC to fast or minpv and that forces the error for me

Yes I can replicate the same too.

I just let the car go to sleep and switched EVCC to fast or minpv and that forces the error for me

Yes I can replicate the same too.

OK I can replicate it as well. That is not something I will do normally so I am going to continue my planned test, but I expect I will see that same error.

I think the vehicle is also going to sleep while charging and EVCC cant change the current, see below
Feb 16 04:05:07 testrig evcc[630]: [lp-1  ] ERROR 2024/02/16 04:05:07 max charge current 27A: Post "https://tesla.evcc.io/api/1/vehicles/LRWYHCFS3NC428511/command/set_charging_amps": net/http: request canceled (Client.Timeout exceeded while awaiting headers) Feb 16 04:05:12 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:12 ---- Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 charge power: 391W Feb 16 04:05:12 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:12 pv power: 8030W Feb 16 04:05:12 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:12 grid power: -4388W Feb 16 04:05:12 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:12 site power: -4388W Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 charge voltages: [244 1.5 0]V Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 detected connected phases: 1p Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 charge currents: [1.6 0 0.2]A Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 detected active phases: 1p Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 charger status: C Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 soc estimated: 72.38% (vehicle: 72.00%) Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 vehicle soc: 72% Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 vehicle soc limit: 100% Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 vehicle range: 301km Feb 16 04:05:12 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:12 pv charge current: 22.7A = 3.6A + 19.1A (-4388W @ 1p) Feb 16 04:05:22 testrig evcc[630]: [lp-1  ] ERROR 2024/02/16 04:05:22 max charge current 22A: Post "https://tesla.evcc.io/api/1/vehicles/LRWYHCFS3NC428511/command/set_charging_amps": net/http: request canceled (Client.Timeout exceeded while awaiting headers) Feb 16 04:05:27 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:27 ---- Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 charge power: 756W Feb 16 04:05:27 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:27 pv power: 8143W Feb 16 04:05:27 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:27 grid power: -5033W Feb 16 04:05:27 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:27 site power: -5033W Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 charge voltages: [244 1.5 0]V Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 detected connected phases: 1p Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 charge currents: [3.1 0 0.2]A Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 detected active phases: 1p Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 charger status: C Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 soc estimated: 72.39% (vehicle: 72.00%) Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 vehicle soc: 72% Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 vehicle soc limit: 100% Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 vehicle range: 301km Feb 16 04:05:27 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:27 pv charge current: 27A = 5.1A + 21.9A (-5033W @ 1p) Feb 16 04:05:37 testrig evcc[630]: [lp-1  ] ERROR 2024/02/16 04:05:37 max charge current 26A: Post "https://tesla.evcc.io/api/1/vehicles/LRWYHCFS3NC428511/command/set_charging_amps": net/http: request canceled (Client.Timeout exceeded while awaiting headers) Feb 16 04:05:42 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:42 ---- Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 charge power: 1193W Feb 16 04:05:42 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:42 pv power: 8156W Feb 16 04:05:42 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:42 grid power: -4579W Feb 16 04:05:42 testrig evcc[630]: [site  ] DEBUG 2024/02/16 04:05:42 site power: -4579W Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 charge voltages: [244 1.5 0]V Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 detected connected phases: 1p Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 charge currents: [4.9 0 0.2]A Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 detected active phases: 1p Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 charger status: C Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 soc estimated: 72.39% (vehicle: 72.00%) Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 vehicle soc: 72% Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 vehicle soc limit: 100% Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 vehicle range: 301km Feb 16 04:05:42 testrig evcc[630]: [lp-1  ] DEBUG 2024/02/16 04:05:42 pv charge current: 26.8A = 6.9A + 19.9A (-4579W @ 1p) Feb 16 04:05:52 testrig evcc[630]: [lp-1  ] ERROR 2024/02/16 04:05:52 max charge current 26A: Post "https://tesla.evcc.io/api/1/vehicles/LRWYHCFS3NC428511/command/set_charging_amps": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

I am apparently also on the new API because it stopped working recently and I have been following this issue.
I have now done everything exactly according to the instructions but my vehicle is only specified as a guest vehicle.
Can anyone help me?

Did you install the nightly build, setup the car again with the new template and new tokens?

Did you install the nightly build, setup the car again with the new template and new tokens?

I have done the following:
-evcc update, but only the one that is available for everyone
-new token for Tesla with all approvals
-added sponsoring (is also recognised)
Could it be because I only did a normal update to 124.2 and the unstable nightly is not integrated?

Of course - as always with new implementations

Could it be because I only did a normal update to 124.2 and the unstable nightly is not integrated?

The changes are only in the nightly for now. You have to switch the release channel to get the new integration.

I assumed, since it is already on the homepage, that it works without nightly.
I'll be patient until it's official.
Thank you

Its not working properly anyway (vehicle wakeup).
This is why nightly builds exist, so us gunie pigs can find issues :)

Sorry - but I also have a stupid question:
is the template Tesla-proxy again a pure combination between TWC3 and Tesla, or should the control (when recognizing the Tesla vehicle) also be done with other wallboxes via the Fleet API?

Seems I need to rebuild the proxy, too. Will shortly.

Great, after the change everything works perfectly. The virtual key is created via the evcc page and you can add it in the Tesla app. The control via evcc also works so far :)
Many thanks for your work!

everything works perfectly.

Until your car goes to sleep ;)

@yipikaye please open new issue with trace log. I guess api responses are different than before and hence we may not be detecting this. Handling on evcc side hasn't changed afaia.

let the car go to sleep and switched EVCC to fast or minpv and that forces the error for me

New issue here: https://github.com/evcc-io/evcc/issues/12294

I just let the car go to sleep and switched EVCC to fast or minpv and that forces the error for me

Yes I can replicate the same too.

OK I can replicate it as well. That is not something I will do normally so I am going to continue my planned test, but I expect I will see that same error.

Yes, as expected, I did see the error when I had enough excess solar to start charging. After waking the car up with app, charging started.

One question: does this mean that now evcc has a self hosted proxy server through which all commands to tesla api will be passed through and that evcc team has access to it and to pub/priv keys ? Basically with these 3 there's no stopping someone from evcc crew or proxy malicious user (say someone would hack this proxy server) to send commands like clear_pin_to_drive_admin or door_lock ?
https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-commands#clear-pin-to-drive-admin
https://developer.tesla.com/docs/fleet-api/authentication/overview


miniupnpc: 2.2.7 -> 2.2.8 , support static build

Description of changes
New release
https://github.com/miniupnp/miniupnp/releases/tag/miniupnpc_2_2_8
and support building with pkgsStatic.
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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (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.

This is an API break: https://github.com/miniupnp/miniupnp/issues/758
Which is likely to affect most downstreams. Reverting until addressed in some way.

Should we introduce a miniupnpc_2_2_7 package and call affected packages with that?

I genuinely don't know, it's touching a pretty core part of the API, so someone needs to investigate the real impact and see if the affected packages can be patched. If not, maybe we should just hold off on updating this.

I would be interested in triaging and patching stuff here, including sending stuff upstream. Going by https://github.com/transmission/transmission/pull/6907/files#diff-5631965d253feb0720bcea80f285ac7e3fb20818fe46fc846706b3dba8e9b32c, it’s just a matter of adding NULL, 0 to the argument list. A shame that upstream doesn’t seem to priority API stability even for a trivial case like this, though.

Have fun, I guess. I honestly don't care which way we go as long as we don't break everything.

I’ve started on this.

Done: https://github.com/NixOS/nixpkgs/pull/326402


Build dataset detail popup

Each dataset will have additional details and metadata that cannot fit into a widget or map view. Wherever we display a dataset we want to be able to show these additional details.
Generally, each popup will have:

Title
Subtitle (if relevant)
Description
Citation
Link to source or download
Topics or tags

@sergioestella please post your designs when ready
@apfister let us know if you have any questions or concerns

Here it goes.


helm: Add check for prometheus service monitoring CRDs

Description
Add  test to check if monitoring.coreos.com/v1 CRD is
available before installation
Fixes: #13513
Signed-off-by: Tam Mach<EMAIL_ADDRESS>Testing
I have tested template generation with additional flag --api-versions monitoring.coreos.com/v1, please find below details:
Note: I didn't actually update makefile as it might break integration tests. Currently, prerequisite of service monitor is to have prometheus CRDs installed in advance.

Generate template
diff --git a/install/kubernetes/Makefile b/install/kubernetes/Makefile
index 6bc07691b..c85c5486b 100644
--- a/install/kubernetes/Makefile
+++ b/install/kubernetes/Makefile
@@ -17,12 +17,18 @@ CILIUM_CHART_REGEX := '\([vV]ersion:\) '$(VERSION_REGEX)
 CILIUM_TAG_REGEX := '\(tag:\) \(v'$(VERSION_REGEX)'\|latest\)'
 CILIUM_PULLPOLICY_REGEX := '\([pP]ullPolicy:\) .*'
 EXPERIMENTAL_OPTIONS := \
+  	 --api-versions monitoring.coreos.com/v1 \
     --set hubble.enabled=true \
     --set hubble.listenAddress=":4244" \
     --set hubble.tls.enabled=false \
     --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,http}" \
+    --set hubble.metrics.serviceMonitor.enabled=true \
     --set hubble.relay.enabled=true \
-    --set hubble.ui.enabled=true
+    --set hubble.ui.enabled=true \
+    --set prometheus.serviceMonitor.enabled=true \
+    --set operator.prometheus.serviceMonitor.enabled=true \
+    --set prometheus.enabled=true
+

 all: update-versions $(QUICK_INSTALL) $(EXPERIMENTAL_INSTALL)

diff --git a/install/kubernetes/experimental-install.yaml b/install/kubernetes/experimental-install.yaml
index eb9ee6ab7..d36d605d7 100644
--- a/install/kubernetes/experimental-install.yaml
+++ b/install/kubernetes/experimental-install.yaml
@@ -50,6 +50,16 @@ data:

   # If you want to run cilium in debug mode change this value to true
   debug: "false"
+  # If you want metrics enabled in all of your Cilium agents, set the port for
+  # which the Cilium agents will have their metrics exposed.
+  # This option deprecates the "prometheus-serve-addr" in the
+  # "cilium-metrics-config" ConfigMap
+  # NOTE that this will open the port on ALL nodes where Cilium pods are
+  # scheduled.
+  prometheus-serve-addr: ":9090"
+  # Port to expose Envoy metrics (e.g. "9095"). Envoy metrics listener will be disabled if this
+  # field is not set.
+  proxy-prometheus-port: "9095"

   # Enable IPv4 addressing. If enabled, all endpoints are allocated an IPv4
   # address.
@@ -566,6 +576,29 @@ subjects:
 # Source: cilium/templates/cilium-agent-service.yaml
 kind: Service
 apiVersion: v1
+metadata:
+  name: cilium-agent
+  namespace: kube-system
+  labels:
+    k8s-app: cilium
+spec:
+  clusterIP: None
+  type: ClusterIP
+  ports:
+  - name: metrics
+    port: 9090
+    protocol: TCP
+    targetPort: prometheus
+  - name: envoy-metrics
+    port: 9095
+    protocol: TCP
+    targetPort: envoy-metrics
+  selector:
+    k8s-app: cilium
+---
+# Source: cilium/templates/cilium-agent-service.yaml
+kind: Service
+apiVersion: v1
 metadata:
   name: hubble-metrics
   namespace: kube-system
@@ -743,6 +776,14 @@ spec:
               - /cni-uninstall.sh
         name: cilium-agent
         ports:
+        - containerPort: 9090
+          hostPort: 9090
+          name: prometheus
+          protocol: TCP
+        - containerPort: 9095
+          hostPort: 9095
+          name: envoy-metrics
+          protocol: TCP
         - containerPort: 9091
           hostPort: 9091
           name: hubble-metrics
@@ -1098,3 +1139,46 @@ spec:
         - name: hubble-ui-envoy-yaml
           configMap:
             name: hubble-ui-envoy
+---
+# Source: cilium/templates/cilium-agent-servicemonitor.yaml
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+  name: cilium-agent
+  namespace: kube-system
+spec:
+  selector:
+    matchLabels:
+      k8s-app: cilium
+  namespaceSelector:
+    matchNames:
+    - kube-system
+  endpoints:
+  - port: metrics
+    interval: 10s
+    honorLabels: true
+    path: /metrics
+---
+# Source: cilium/templates/cilium-agent-servicemonitor.yaml
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+  name: hubble
+  namespace: kube-system
+spec:
+  selector:
+    matchLabels:
+      k8s-app: cilium
+  namespaceSelector:
+    matchNames:
+    - kube-system
+  endpoints:
+  - port: hubble-metrics
+    interval: 10s
+    honorLabels: true
+    path: /metrics
+    relabelings:
+    - replacement: ${1}
+      sourceLabels:
+      - __meta_kubernetes_pod_node_name
+      targetLabel: node

Release Note
helm: Add check for prometheus service monitoring CRDs

@aanm few points hightlighted before in helm refractor PR https://github.com/cilium/cilium/pull/13259#issuecomment-707041569.

This change is good but I don't think this is enough.
@seanmwinn what was the rational behind removing the service monitor CRD from the Cilium charts? As far as I remember users had issues when deploying Cilium on a cluster with this CRD. More info #11261

I see that the Prometheus ServiceMonitor CRD was removed already. It makes sense that Cilium shouldn't be owning someone else's CRDs, but it does make initial provisioning of clusters difficult – I think basically it requires a second provisioning pass to enable servicemonitors for Cilium. I don't know the best way to address this. Almost makes me think a separate chart just for servicemonitors would be ok, so that cluster provisioning would go cilium -> prometheus -> cilium-monitoring.

I see that the Prometheus ServiceMonitor CRD was removed already. It makes sense that Cilium shouldn't be owning someone else's CRDs, but it does make initial provisioning of clusters difficult – I think basically it requires a second provisioning pass to enable servicemonitors for Cilium. I don't know the best way to address this. Almost makes me think a separate chart just for servicemonitors would be ok, so that cluster provisioning would go cilium -> prometheus -> cilium-monitoring.

It's a very fair point :thinking:, having a sequence of installation will help, but really not a good user experience I can say. Let me do some research on this, while waiting for others to bouncing ideas here.

@sayboras, me and @diversario spent quite some time trying to figure out a good solution for this problem so we end up adding the CRD into the Cilium chart since from the helm documentation the CRDs are only installed if they don't exist and they are never removed. It's really tricky to solve this problem in a different way but let us know about your findings!

I see that the Prometheus ServiceMonitor CRD was removed already. It makes sense that Cilium shouldn't be owning someone else's CRDs, but it does make initial provisioning of clusters difficult – I think basically it requires a second provisioning pass to enable servicemonitors for Cilium. I don't know the best way to address this. Almost makes me think a separate chart just for servicemonitors would be ok, so that cluster provisioning would go cilium -> prometheus -> cilium-monitoring.

It's a very fair point 🤔, having a sequence of installation will help, but really not a good user experience I can say. Let me do some research on this, while waiting for others to bouncing ideas here.

I'm probably way overthinking this but... what if Cilium Operator was in charge of creating the ServiceMonitor. As in:

I deploy Cilium with serviceMonitor.enabled=true
Cilium Operator configuration records that user asked to create a SM
Operator checks if it is possible (if CRD is available), and if yes – creates it; if not – logs a warning, waits some time, rechecks. Repeat forever until SM is created.

The nice part of deploying the SM as part of the Helm chart is that it's very easy to modify it and it doesn't depend on the Cilium image being used (it was very easy for me to modify it in my local fork of the Helm chart). But as far as user experience goes, this might be an edge case and making it possible to just install Cilium in one pass is more important.

I'm probably way overthinking this but... what if Cilium Operator was in charge of creating the ServiceMonitor ...

Feel like the Service Monitor CRDs still needs to be created by users manually if I am not wrong.
As we don't need to have cilium ready before installing ServiceMonitoring CRDs, can we perform simple check in validate.yaml ?

If monitoring.coreos.com/v1 is required but not available, fail helm install with some info/steps (e.g. kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml).
If monitoring.coreos.com/v1 is not required (e.g. monitor related flags enabled = false), just carry on as usual.

Basically, I want to achieve below points, feel free to let me know if my assumption is wrong.

Remove Service Monitoring in cilium helm chart. The main reason is about functional ownership.
Keep user experience fairly with minimun changes.

I'm probably way overthinking this but... what if Cilium Operator was in charge of creating the ServiceMonitor ...

Feel like the Service Monitor CRDs still needs to be created by users manually if I am not wrong.

Yes, and it is expected; SM CRD is installed as part of Prometheus Operator, so in the course of users setting up their monitoring stack.

As we don't need to have cilium ready before installing ServiceMonitoring CRDs, can we perform simple check in validate.yaml ?

If monitoring.coreos.com/v1 is required but not available, fail helm install with some info/steps (e.g. SM CRDs not available, please install it by your preferred method or run kubectl apply -f<EMAIL_ADDRESS>(raw)).
If monitoring.coreos.com/v1 is not required (e.g. monitor related flags enabled = false), just carry on as usual.

Basically, I want to achieve below points, feel free to let me know if my assumption is wrong.

Remove Service Monitoring in cilium helm chart. The main reason is about functional ownership.
Keep user experience fairly with minimal changes.

For the scope of this PR that makes sense. The functionality I described in the previous comment is definitely way outside of the scope of this PR.
It will be a breaking change as far as Helm chart goes, though, because if anyone expects the chart to get installed with the monitoring enabled will see it fail. Not the end of the world, but an annoyance at least.

One point on this would be, how do we expect the overall flow for install to work?
Option A:

Install monitoring
Install Cilium

Option B:

Install Cilium without monitoring
Install monitoring
Modify Cilium to enable monitoring

And how do we tell users to set up Cilium with monitoring in the documentation?
In some ways it seems nice to figure out during install whether the prerequisites are satisfied and let the user know since it makes the requirements more visible at install time. Sometimes though these kinds of checks can cause more trouble down the road because it forces a certain ordering of operations.
Is it possible for us to provide a runtime warning or something instead to signal when the user has installed Cilium but hasn't set up the monitoring CRDs? Then ideally whenever the user installs the CRD, Cilium would automatically just start working with it (but I could understand if a first cut also requires restarting Cilium).

@joestringer the problem was, as far as I remember, the monitoring framework depends on Cilium to start.

@aanm and what's the behaviour from Cilium side right now if the monitor CRD is not available but Cilium is configured with monitoring?

@aanm @sayboras and what's the behaviour from Cilium side right now if the monitor CRD is not available but Cilium is configured with monitoring?

In 1.8 Cilium deploys the missing CRD, removed by the helm refactoring, in 1.9 / master Cilium won't install it because it does not exist.

@aanm what's the consequences if the CRD is missing? Cilium presumably runs fine and does its core functions (ie, handle networking & policy), I assume that monitoring just doesn't work. If someone upgrades, the CRD is already in place so I guess existing users are fine? Then it's only new users which need to take additonal action, so we can document how to do it right for new installs.
Then beyond that I'd guess there's the corner cases if someone gets into this state and doesn't know how to debug it, how do we make it obvious to users that the CRD is missing and they need to take action? This PR presents one approach - force it during install - but there could be other approaches, like just documenting it as a troubleshooting step, or trying to perform runtime detection of the missing CRD when Cilium is configured with monitoring enabled, then logging a warning in that case.

Thanks guys for your inputs and comments, as now we are kind of agree on the direction, I will close the loop and wrap it up for this PR :100:

@aanm what's the consequences if the CRD is missing? Cilium presumably runs fine and does its core functions (ie, handle networking & policy), I assume that monitoring just doesn't work. If someone upgrades, the CRD is already in place so I guess existing users are fine? Then it's only new users which need to take additonal action, so we can document how to do it right for new installs.

That's all true, and doable. The downside of this is that it breaks automated cluster provisioning flows if there's a requirement to go back to the provisioning config, update it, and run it again as a second pass. And new cluster provisioning can be a very common thing when it's done for CI, one-off testing or anything like that. So ideally, it'd be great to have a single-pass provisioning.


Sub-menus (groups) for profiles

I have a lot of profiles in the list that exceed the screen high so that I always have to scroll up/down the profiles list. It would be a better usability if it would be possible to group the profiles, e.g.:

Powershell
Ubuntu

Ubuntu 16.04
Ubuntu 18.04

cmd

Administrator
Normal User
...

Thanks.

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #1571 for more discussion.
/dup #1571


Incompatibilities in the packaged index.d.ts

Following #1, once the types do get picked up, there are a few difficulties with them:

import { interceptFormData } from 'cypress-intercept-formdata' is not allowed in TypeScript land because the index.d.ts doesn't declare it. Is that intentional?
The import { Interception } from 'cypress/types/net-stubbing', as an import statement, turns TypeScript's understanding of the file into a module, so it doesn't augment the global scope for the Cypress namespace.

In other words: cy.wait('@api') will no longer have .interceptFormData available
Other libraries such as cypress-wait-until use any instead of the Interception and don't have this issue. Another way that would still allow imports and exports would be to declare global { ... } around the namespace declaration.

Thanks for the quick responses on these issues & PRs! 💖


Subscription isn't triggered, although I see the packet data

Hi
I'm trying to use Socket.Io.Client.Core for the underlying communications of a generic pub/sub service with persistence for messages. The basic usage is:

client connects
client subscribes via /subscribe with some info (topic, offset, channel)
client publishes (in the real world, this is another client, of course) to the topic for the channel
client should receive a /consume notification with the message

Now in the test code below, I can see the comms working out - I can see the received packet for /consume, but the handler set up with client.On("/consume") is never called. I've set up a demonstration repo at https://github.com/fluffynuts/socket-io-core-subscribe-issue . There's a README in there to explain how to reproduce the issue with the provided code.
For the moment, I'm going to have to manually parse Packet instances which come into the OnPacket event, but it would be really nice if I could use this library as intended.

Thanks for reporting, I will check your repository and let you know what's wrong.

There were number of issues here:

You are not json serializing emitted data on your server (this should be supported by this library)
Same issue happens when you respond to callback with { success: true } so you do not receive any callbacks (ACKs)

For debugging it's a good idea to subscribe to OnError event and/or pass in real logger. I will have to consider specific JSON library dependency to handle message data in a different way. Most likely System.Text.Json.


Feature/support ts schema

This PR adds support for importing the schema from typescript files.

One reason this is important, as stated by @maticzav in slack:

This is especially important for deployments using now because .graphql file cannot be imported - the deployment ignores it when preparing the bundle.

@jasonkuhrt @maticzav
Can you please describe the use case in more detail? I haven't a problem with it. Thank you.

@steida I'll let @maticzav expand on the now one as I'm not a zeit user myself.
However users should be able to import from TypeScript files anyways. There are quite a few examples by and of Apollo servers using the const typeDefs = gql`...`  so having this start to work is good a good step. I realize that a complex project doing modular const typeDefs = gql`...`  will not work yet. I think we could achieve that with a scan across the user's project. But more complicated. Lets see if users start to ask for it. Other priorities for now.

Hey @steida 👋,
So, the reason why this is important is that firstly, Apollo users to my understanding had to import and parse their schema during the runtime, and secondly, deployed applications couldn't work with Now 2.0. The reason behind this is that Now uses ncc to compile lambdas out of source code, therefore, they wouldn't bundle schema because it was a runtime dependency.
I hope this gives you a good enough idea 🙂

@maticzav Thank you. Btw, deployed API works for me here in https://github.com/este/este