python38Packages.google-cloud-pubsub: 2.7.1 -> 2.8.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.google-cloud-pubsub is: "Google Cloud Pub/Sub API client library"
meta.homepage for python38Packages.google-cloud-pubsub is: "https://pypi.org/project/google-cloud-pubsub"
meta.changelog for python38Packages.google-cloud-pubsub is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

/nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0/bin/fixup_pubsub_v1_keywords.py passed the binary check.

/nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0/bin/.fixup_pubsub_v1_keywords.py-wrapped passed the binary check.

2 of 2 passed binary check by having a zero exit code.

0 of 2 passed binary check by having the new version present in output.

found 2.8.0 with grep in /nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0

found 2.8.0 in filename of file in /nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0

directory tree listing: https://gist.github.com/1b4c4401a08287e53f791d304abfc1b9

du listing: https://gist.github.com/85bccaf67278b999f9d36eebbc264b21

Rebuild report (if merged into master) (click to expand)

11 total rebuild path(s)

3 package rebuild(s)

3 x86_64-linux rebuild(s)
3 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
3 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
home-assistant
python38Packages.google-cloud-pubsub
python39Packages.google-cloud-pubsub

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.google-cloud-pubsub https://github.com/r-ryantm/nixpkgs/archive/18f15823d23d1debb67ace6de3dbcb86aa31c99a.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0
ls -la /nix/store/xxq1wmmbxi1p2ghx39dzx9kbs9l7xlk8-python3.8-google-cloud-pubsub-2.8.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @SuperSandro2000 for testing.

Result of nixpkgs-review pr 136960 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.google-cloud-pubsub
python39Packages.google-cloud-pubsub


use secrets yaml if available

if i want to create a new device, i have to put in wifi ssid + pw, but i use !secret.. in my yaml.
So i have to fill in something and have to change it after that.
it is possible to leave it blank at creating new yaml or maybe to choose out secret things.
Or it is possible to create a default config yaml, that will be used every time you create a new device?

Implemented.


Add flag to ignore missing app on msg creation

Some users use Svix in a stateless mode where they do not know if an app (consumer) exists or not when they send a message. These users just want to ignore the error when an app does not exist when a message is sent.
This change adds a new query parameter ignore_missing_app, which can be set to true to return 200 OK on create_message when the app does not exist.

Closing this as it was superseded by another solution.


Improve README.md

Current dependencies on/for this PR:

main

PR #161   👈

This comment was auto-generated by Graphite.

Thx - I did a quick re-read and didn't notice it under the "You will be asked for an API key on first login, which is stored in $XDG_CONFIG_HOME/tod.cfg." section, but then re checked and it is listed above. I would combine those sections and/or remove that line.

Thx - I did a quick re-read and didn't notice it under the "You will be asked for an API key on first login, which is stored in $XDG_CONFIG_HOME/tod.cfg." section, but then re checked and it is listed in the above section . I would combine those sections and/or remove that line.

Great idea, amended :+1:


Update the test model to use obejcts for action/connection properties.

Squashed and rebased to fixup conflicts with master.

retest this please.

retest this please.

retest this please.

Going to manual merge this in as @gashcrumb's merge in  redhat-ipaas/ipaas-ui  depends on this going in.


Keeping track of previous tab(s) when clicking on tags

Describe your suggested feature
Currently, when you click on the tags, it brings you to the extension's search page of that tag. But if you go back, it doesn't go back to the manga where you clicked the tag on, but to the homepage of the website (refreshed). Is there a way for it to NOT skip all the way back to the homepage, and just go back to the manga page you were on? This would also keep track of the position/page you were browsing in the webpage (browse/latest catalog) if you went back out of the manga page.
Other details
Reason why I'm posting this here, instead of vanilla Tachiyomi (which, along with all the other forks, have this same problem) is because this is only a feature that I find inconvenient for situations where I HAVE to click on the tag, instead of clicking on the author/artist (where it does a global search and this problem wouldn't occur). Example: On a E-Hentai/Exhentai manga/gallery page, and it's a group work (so there's no artist), so I click on the group name from the tags instead. It'd probably be more convenient for NHentai, too, because clicking on the artist tag is good for saving time (skipping going to global search and picking the source you were on), but it doesn't keep track of the previous tab (the manga page I clicked the tag from). Was using TachiEH up until a few days ago, and only stopped using it because I have a bug where the app always crashes now when I click on the tags (I'm probably wrong, but I think it has something to do with the E-Hentai extension update a few days prior). I might be Mandela effecting myself here, but I don't recall having this problem on TachiEH (it would go back to the manga page, instead of the homepage refreshed). It's inconvenient, because every time I'm browsing hentai and click on a tag, it loses track of not only the manga I was on, but the spot where I was browsing.
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to version 1.7.0.
[X] I will fill out all of the requested information in this form.

Just long click the tag


Data stored on Register BYOD

We currently allow employees to BYOD and register their devices in Azure, the question we have is what data is stored on a registered device that is not controlled by the company?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8877b198-deb1-6ae9-ea0d-3830370b0b4a
Version Independent ID: f1a4495c-7da8-0c3f-5d97-4f816a2b696c
Content: What is device management in Azure Active Directory?
Content Source: articles/active-directory/devices/overview.md
Service: active-directory
GitHub Login: @MarkusVi
Microsoft Alias: markvi

@amel00
Thanks for your feedback! We will investigate and update as appropriate.

For device registration it should only be company data that is controlled and not any other data that the user owns. You can set up individually which resources a user can access on a registered device. See https://docs.microsoft.com/en-us/azure/active-directory/devices/faq
Let me know if this is what you mean and are looking for.

I was actually wondering what kind of information, registration keys, tokens etc that were stored on the newly registered device.. I know it adds a certificate of some sort, I am just wondering what else it might be storing on the device

I've forwarded your question to someone on the product team but he is on leave at the moment. @MarkusVi do you have information about this?

@amel00 While you're registering your device on your organization's network, the following actions will happen:

Windows registers your device on your organization's network.
Optionally, based on your organization's choices, you might be asked to set up two-step verification through either Multi-Factor Authentication or security info.
Optionally, based on your organization's choices, you might be automatically enrolled in mobile device management, such as Microsoft Intune. For more info about enrolling in Microsoft Intune, see Enroll your device in Intune.
You'll go through the sign-in process, using the username and password for your personal Microsoft account.

In case the Azure AD registered device is managed using MDM, you can configure Azure AD Conditional Access Policy. With Azure AD conditional access, you can address this requirement with a single policy that grants access:

To selected cloud apps
For selected users and groups
Requiring a managed device

You can set a condition that device that is compliant only can access certain Microsoft cloud application. For a device that is marked as compliant, you can assume that:

The mobile devices your workforce uses to access company data are managed
Mobile apps your workforce uses are managed
Your company information is protected by helping to control the way your workforce accesses and shares it
The device and its apps are compliant with company security requirements

After your device is registered, it will be able to access your organization's restricted resources. You can ensure that users are accessing your resources from devices that meet your standards for security and compliance. You can also see the device registration status by running the command: dsregcmd /status from an elevated command prompt.

@MohitGargMSFT
I guess my question would be more along the lines, does a BYOD registered device store any certificates or hash any passwords or access tokens on the personal device that is not controlled via intune or some other mobility management service since these devices are personal devices that are being registered.
I know for instance if you are hybrid joined then a user cert is stored on a device that is joined to the network.
Does registering a personal device get any of this type of information stored on it when they are registered?

@amel00 there are no passwords or certificates stored on the device. Based on all existing documentation the registration token is the only thing that is passed to the device.


Upgrade Ansistrano roles

deploy (1.10.1)
rollback (1.5.0)

I'm not able to test the rollback role, do you have a project where you use it?

Haven't had to use a rollback yet, no :)

I'll create a new version of this using the fork.


Linux doesn't have RDP...

...tweaked the template to point to SSH instead.

Hi @rcarmo, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (rucarmo). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@rcarmo : Thanks for your contribution to the Azure documentation! The author, @davidmu1, has been notified to review your proposed change.

@rcarmo this is a good fix! Sorry about that. :-) Don't know WHAT  we were thinking. ;-) @davidmu1 LGTM....FWIW

@squillace nah, no worries. I know it's hard to do docs -- you stare at them for so long sometimes that things like this get by.

@rcarmo: Thank you very much for your feedback on the article.

#sign-off


Background Color of the Progress View

Can someone help me with my little problem. It's not technically a issue. I couldn't find how to change the background color of the progress circle. I want to make the black square disappear. How can I set the alpha of that to 0 ? Or is there an other way to solve this problem.
Thank you for sparing time.

@utkueray probably setting
ARSLineProgressConfiguration.backgroundViewStyle = .full
or
ARSLineProgressConfiguration.backgroundViewStyle = .simple
will do the thing?


Error 'using' TextAnalysis package

After adding TextAnalysis package in Julia with
julia> Pkg.add("Distributions")

I am getting following error while using the package:
using TextAnalysis
ERROR: Stats not found
 in require at loading.jl:39
 in include at boot.jl:238
 in include_from_node1 at loading.jl:114
 in reload_path at loading.jl:140
 in _require at loading.jl:58
 in require at loading.jl:46
 in include at boot.jl:238
 in include_from_node1 at loading.jl:114
 in reload_path at loading.jl:140
 in _require at loading.jl:58
 in require at loading.jl:43
at /Users/user/.julia/DataFrames/src/DataFrames.jl:5
at /Users/user/.julia/TextAnalysis/src/TextAnalysis.jl:1

(On Mac OS X 10.9.1)

Yes, this looks  fixed, and can be closed.


PopUp open more and close all

Hi Vladimir,
i´d need the following behaver
Situation: their are more than one icons on the map
User Interaction:

When user clicks an icon it opens a popup. When another popUp is already open it stays open!

When the user clicks on the map where no popup or icon is all open popups are closed

When the user clicks one X one one particular popup, this popup is closed

Solution?
1 is done with changing the code from openPopup to
L.Map.include({
openPopup:function(a){return this,
this._popup=a,this.addLayer(a),this.fire("popupopen",{popup:this._popup}),this},
closePopup:function(){
return this._popup&&(this.removeLayer(this._popup),this.fire("popupclose",{popup:this._popup}),this._popup=null),this}}
)
2. only the last is closed and i don´t know how to access the others?
3.same proplem is in 2 only the last opened is closed but not the others can not be closed.
To changed to this behaver was easy with version before 14.2, we changed to the new version as we would like the zoom to work on Andriod 3.0. Have you got any idea to fix this.
thanx in advance
gertie

Where are all the popups closed from in RC3? I don't see iteration in any calls to closePopup


Make serialization.dart compatible with Dart editor

I am not a dart expert and I may be wrong, but it seems like the lines such as
import 'package:mypackage/myclass_serialization_rules.dart';

appear as errors in the Dart editor are underlined in red. However, it seems to work fine when ran.
Would there be at least a workaround not to see these errors and have serialization.dart be compatible with the Dart editor?
Alternatively, is there a bug report in Dart editor to make this happen?
Thanks.

I'm taking care of this in https://github.com/google/serialization.dart/pull/9 :)
The issue is that you need to import a file that has not yet been created. The file gets created at built-time by the transformer though. In my Pull Request I propose to add an import re-writer.

That's great to hear, thanks for your work!
By the way, do you think it would ever be possible for Dart editor to know about files that will be generated? (maybe actually create these files in a directory that is out of sight?) Does it make sense to tell Dart editor developers anything about this in case some other package wants to use such transformers?


FPS drops when looking at blocks

when i have this mod in my modpack...
https://www.curseforge.com/minecraft/modpacks/rankersmp-exploratory-revelations
on the 1.18.2 version...  i have major FPS drops when looking at blocks .
if i dont focus on any block its perfect..
without this mod included, i can do everything as per normal and no FPS drops when looking at blocks
im not sure what causes this , but i cant include it in my modpack until its resolved.
if you have any indication of what is doing it.   im all ears :)
ive been trying different mods for better waila ...  using wthit or megene , FPS drops majorly and game becomes unplayable when focusing on blocks.
using mod like Polydex does not cause this issue for me.  but doesnt have the compat i want with some other mods i have.
any info be great.. thanks :)

guess ill just recommend all devs to not use this as it can cause major issues.

To be fair, shedaniel doesn't get paid for working on these mods, and there is a lot of mods to be worked on. You also didn't provide much information as to what actually happened, and after May 4th, you made it difficult for anyone to care enough to listen.
But, I have nothing better to do, so here goes.
FPS drops are common on different computers for different reasons; my best recommendation is to get a profiler mod like spark and see what the actual source of the lag spike is. My best guess is that the number of mods you have installed is making the database of blocks difficult to search through, causing long lookup times for blocks that would otherwise be practically unnoticeable.
My best recommendation is adding other optimization mods; I don't know what you currently have installed, but I do believe there are some that optimize the block lookup implementation. Until then, I don't know what to tell you; I have not seen this issue personally, so I can't provide more information.


updated pipeline pull request git provider type docs

What changed? Added documentation for pipelines pull request git providers

How did you validate the change?

we'll need to rebase this following the removal of the enterprise section in https://github.com/weaveworks/weave-gitops/pull/3133

@enekofb you will need to move this from /versioned-docs/v0.12.0/ to just /docs/ as its not in v0.12.0 of WGE


affected/package: go1.19.4

What version of Go are you using (go version)?

$ go version 1.19.4

Does this issue reproduce with the latest release?
not sure
What operating system and processor architecture are you using (go env)?
go env Output
$ go env  ubuntu

What did you do?
i want to use spacevim to develop golang software. when i use gd function to open the definiation page. the ssh will going down for half an hour when i broswer the page for a while.
the old version have no such problem such as go 1.15.*

What did you expect to see?
What did you see instead?

doesn't sound like a go issue
Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For questions please refer to https://github.com/golang/go/wiki/Questions


setProps doesn't allow setting attributes

Version
1.0.0-beta.25
Reproduction link
https://vue-test-utils.vuejs.org/api/wrapper/#setprops-props
Steps to reproduce
Call setProps with an object with attributes not defined in the mounted component's props option.
What is expected?
Undefined attributes will be parsed as $attrs in the component, just like what will happen when providing propsData when mounting the component.
What is actually happening?
The following error pops up:
[vue-test-utils]: wrapper.setProps() called with [undefined attribute name] property which is not defined on the component

As Vue 2.4 adds support for $attrs, this inconsistency in vue-test-utils would be annoying when testing a component that uses $attrs. We had to re-mount the component which is not required in actual code, as $attrs is reactive.

I have created a pull request for this #1029

This has been added in #1029 and will be released in beta.26.
Thanks @abilicz!


Why is DynamicViewData internal?

is there any reason this class is internal? I want to write a custom base class to replace the abstract ViewComponent class. I want to return a different ViewViewComponent result, one that is localized and opinionated about the view location in a different way to the embedded convention, so the code is a copy/paste job, but this class is internal and I cant understand why.
https://github.com/aspnet/AspNetCore/blob/c565386a3ed135560bc2e9017aa54a950b4e35dd/src/Mvc/Mvc.ViewFeatures/src/DynamicViewData.cs

@oferns thanks for contacting us.
We normally don't make any type public if we can avoid it unless we determine there is useful in some common scenario, as it increases our maintenance cost and prevents us from making changes in the future.


Indexing not working correctly with dynamic name-paths

Please post to the mailing list with the details of your problem.

done - was actually still typing them here while you already closed the issue - I checked if there was a doc describing on how to post issues but apparently missed the mailing list.


Add an unwrap! macro

Rendered

We just moved from try! to ? which greatly improves readability. I'd be sad for this movement backwards.
Alternative suggestion: add compiler support for forced MIR inlining of functions + some new MIR rvalue that gets turned into the function/line/col position of the inline location during such a forced inlining. This way no user code needs to be changed and we get the same advantage.

We just moved from try! to ? which greatly improves readability. I'd be sad for this movement backwards.

Well, it doesn't effect code that uses try!/? at all. It means that foo.unwrap() would instead be written unwrap!(foo) which, to me at least, isn't any less readable.

Alternative suggestion: add compiler support for forced MIR inlining of functions + some new MIR rvalue that gets turned into the function/line/col position of the inline location during such a forced inlining. This way no user code needs to be changed and we get the same advantage.

How would that look? Would the unwrap/expect methods need to be written directly in MIR? Or would you add a macro to get the caller context? ie. something like:
#[inline(always)]
fn unwrap(self) -> T {
    match self {
        Some(t) => t,
        None => {
            let ctx = caller_context!();
            panic!("unwrap on empty Option at location: {}", ctx);
        },
    }
}

It means that foo.unwrap() would instead be written unwrap!(foo) which, to me at least, isn't any less readable.

And code that uses foo.boo().unwrap().bar().blub().unwrap().cake() will be unwrap!(unwrap!(foo.boo()).bar().blub()).cake().

How would that look?

Should be possible the way you described it. Maybe even more like the asm! macro:
let line;
let col;
mir!(line = Inline(Line); col = Inline(Col));

Another alternative (from C++) is default function arguments (if they are evaluated at point of use):
fn unwrap(self, context: Context = file_line_column!()) { .... }

foo.unwrap(); // desugared into foo.unwrap(file_line_column!())

@petrochenkov That doesn't really work. The file_line_column!() macro would have to be expanded at the point of the function declaration.

What specifically is the issue with RUST_BACKTRACE=1 other than "you have to know to use it"?

@canndrew

The file_line_column!() macro would have to be expanded at the point of the function declaration.

Then file_line_column need to be a compiler intrinsic or lang item or whatever works.

Macros in method position would be nice for this too foo.unwrap!()

@BurntSushi: The issue with RUST_BACKTRACE is that, depending on the platform, it may not provide the information you want: On OS X I'll only get the (mangled) function names and as far as I known in some windows configurations you don't even get that much.

@TimNN Is that a deficiency in the current implementation that can be fixed?

@BurntSushi even if it is fixed, if compiling in release mode, the backtrace might not yield any info that helps you, if enough functions got inlined.

@BurntSushi I probably can be fixed and is tracked at rust-lang/rust#24346, to quote

So what is the plan with this? Is there any ETA?

Someone who feels sufficiently motivated will have to track down the appropriate libraries/APIs on Windows, OSX, BSD, etc and integrate them.

I've wanted this before too, so I'm in favor of the basic idea. Have not read the RFC though. I'd much prefer if the macro was in method position though. The 'unwrappiness' is not the most important part of the whole expression, would rather not have it in front.

I'm also very interested in distinguishing the 'expect' case from the 'sloppy coding' case. IOW, today I write 'unwrap' when I'm being sloppy, and 'expect' (often with an empty string) to mean, "I've thought about this and unwrapping is correct here". I would not want a single macro to mean both.

today I write 'unwrap' when I'm being sloppy, and 'expect' (often with an empty string) to mean, "I've thought about this and unwrapping is correct here".

Why would you use expect with an empty string? I agree that expect is less sloppy but only because it forces you to provide a string justifying why it's safe to unwrap here. If you're passing in an empty string you may as well just use unwrap.

Why would you use expect with an empty string? I agree that expect is less sloppy but only because it forces you to provide a string justifying why it's safe to unwrap here. If you're passing in an empty string you may as well just use unwrap.

expect vs unwrap signals intent. When I write expect, whether or not I give justification, I am asserting to future readers that this is not going to fail. If I write unwap then future readers have no indication that I wasn't just lazy. Granted, a message is better, but there's a clear semantic distinction between good unwrapping and bad unwrapping either way.

@petrochenkov was onto something, although this would have to be done with type parameters in Rust:
impl<T> Option<T> {
    fn unwrap<C: SourceContext = CallerSourceContext>(self) -> T {
        match self {
            Some(t) => t,
            None => {
                panic!("unwrap on empty Option at location: {}", C::default());
            }
        }
    }
}

CallerSourceContext would be a lang item that the compiler replaces with a type implementing SourceContext which has some sort of API to get the information out.
I've been told Haskell does something similar with type parameters. cc @solson

@eddyb What I told you about before (I think) was the HasCallStack typeclass (note that it has no parameter, which is impossible in Rust since all traits have Self).
Another relevant thing I found uses GHC implicit parameters to provide call site location information, like your example: https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations

What specifically is the issue with RUST_BACKTRACE=1 other than "you have to know to use it"?

One problem is when you run your application normally, and it crashes unexpectedly in a not immediately reproducible way. Now you have to rerun with RUST_BACKTRACE over and over again until you can find a way to reproduce the crash before you can get source information about where the crash happened.

Another prior art crate is the inner crate, which contains the inner! macro. It can do both unwrap! and try! functionality, and more.

What specifically is the issue with RUST_BACKTRACE=1 other than "you have to know to use it"?

One problem is when you run your application normally, and it crashes unexpectedly in a not immediately reproducible way. Now you have to rerun with RUST_BACKTRACE over and over again until you can find a way to reproduce the crash before you can get source information about where the crash happened.

Exactly. And anyway, what's the point of printing some random location inside libcore when we could instead print somewhere useful.

@petrochenkov was onto something, although this would have to be done with type parameters in Rust:

Interesting, but I'm a little uncomfortable that CallerSourceContext looks like a type there but it's really some weird thing that gets substituted with a different, unique type everywhere that it gets used.

And anyway, what's the point of printing some random location inside libcore when we could instead print somewhere useful.

This is a rather small and bearable cost IMO.

One problem is when you run your application normally, and it crashes unexpectedly in a not immediately reproducible way. Now you have to rerun with RUST_BACKTRACE over and over again until you can find a way to reproduce the crash before you can get source information about where the crash happened.

I can appreciate that this is indeed a benefit.

As a data point, we're having problems getting good crash reports in Servo because .unwrap() doesn't give us the file/line number when it fails. We get the backtrace, but it's often not much use because of inlining and other optimizations.

That can be fixed without changing the API, though. It might involve ugliness like adding a custom calling convention for unwrap-like functions (which would, of course, remain unstable forever), but I'd rather that than adding an unwrap! macro.

@notriddle is right. I read these and think the line info is very my wanted, but the macro is not a good idea.

I'm kinda surprised by some of the negativity towards this. @notriddle would rather introduce a new calling convention then use a macro, @oli-obk would rather use asm! style hackery then use a macro, @BurntSushi would rather just go without accurate line info than use a macro.
What's so bad about using a macro? Is it just because it goes in-front rather than in the method position? That seems like a very minor complaint to me.

expect vs unwrap signals intent. When I write expect, whether or not I give justification, I am asserting to future readers that this is not going to fail. If I write unwap then future readers have no indication that I wasn't just lazy. Granted, a message is better, but there's a clear semantic distinction between good unwrapping and bad unwrapping either way.

@brson would you rather there was both an unwrap! macro and an expect! macro? We could do that but AFAICT the two macros would do exactly the same thing.

@canndrew Existing code gets 0 benefits with a macro, and you have to turn every caller into a macro too if you want to get the benefits transitively.
The type-system or calling convention "hacks" actually solves those problems.

Well it's not ideal that there'd be two ways of doing things - the old way and the new way. But adding a new calling convention still seems like a heavy-handed way of solving something that we already have a solution for.

I wonder if it is possible to have an #[inline(always_at_call_site)] attribute, such that the file!(), line!() and column!() macros inside the function will refer to the span at the call site instead of the point of macro expansion. We could then apply #[inline(always_at_call_site)] to unwrap(), expect() and unwrap_err().
This would require the result of these three macros remain unevaluated until the inline-always pass though (or becomes an expression referring to the CallerSourceContext), which could be a huge hack.

@kennytm That would work, but realistically it would have to be a MIR transformation with some way (other than the file/line/column macros, unless those are made magical) to get the source information.

If we had a macro loc! which appended the file/line/column number, but otherwise acted like format! we could get a lot of the benefit of this just by writing .expect(loc!()) in place of .unwrap(). If we were allowed to elide empty arguments, this would be .expect(loc!).

If we had a macro loc! which appended the file/line/column number, but otherwise acted like format! we could get a lot of the benefit of this just by writing .expect(loc!()) in place of .unwrap(). If we were allowed to elide empty arguments, this would be .expect(loc!).

That wouldn't work with existing code, and it would be harder to use than a plain unwrap! macro.

@notriddle true, it wouldn't help with existing code. Not sure about ease of use, e.g. compared to worrying about the order of inlining vs macro expansion.

That should be transparent to the user; the only people who should have to worry about that are the libs and compiler teams.

@brson would you rather there was both an unwrap! macro and an expect! macro? We could do that but AFAICT the two macros would do exactly the same thing.

Yes.

use asm! style hackery

Adding a mir! macro sounds reasonable to me anyway $someday, so we could add a hacky internal version now, and worry about doing it correct later, as it would only be used inside the stdlib anyway.

This would require the result of these three macros remain non-constant until the inline-always pass though (or becomes an expression referring to the CallerSourceContext), which could be a huge hack.

I don't think it's hacky or unreasonably complex to add code that will be transformed by the inline-always pass. We'll have many transformations on MIR in the future, this will be a a simple one-way transformation. I think the actual inlining pass will be more complex than the expansion of the macro to the caller's function_name/file_name/line/col (which should mostly just be "is this a mir!?" -> yes -> "is this a source context mir!?" -> yes -> replace it by a statement moving the values as constants into the given target)

My 2c:
I agree with many on the thread that:

The lack of useful line info is a real problem today. Even though we can continue to make improvements to the visibility of backtraces, the reality is that it's a cumbersome and not newbie-friendly experience.

OTOH, as @eddyb points out, solving the problem by introducing a new means of unwrapping is problematic because it doesn't help with any existing code. At this point the conventions around unwrap are quite well-settled, and moving such a core operation to a macro seems unfortunate.

In general, I suspect that building consensus around macros as the stabilized solution to this problem is an uphill battle. I wonder if it's worth branching off a thread on internals to talk about other ways of solving this problem within unwrap itself, as some are already doing here?

🔔 This RFC is now entering its week-long final comment period 🔔
The libs team is leaning towards closing this along the line of @aturon's previous comment. It seems too late in the game to shift conventions as .unwrap() is so entrenched. We agree though that this is a very real problem and we'd like to tackle it, but it probably needs to be done through a different means than a new macro.

I meant to close this already but I've been very busy. Here's the internals discussion thread as per @aturon's suggestion.


Run eslint in the CI

Resolves #108

Actually I think its actually run in test already

You're right, I missed the test-* part


Add a way to find .eh_frame_hdr using __GNU_EH_FRAME_HDR.

GNU ld on at least some platforms adds a symbol __GNU_EH_FRAME_HDR for
the .eh_frame_hdr section. Add a cargo feature fde-gnu-eh-frame-hdr
to enable use of this.

GNU ld (BFD) defines it.

I don't know of any documentation for this though; I only know of it because I found it while looking at a disassembly.

Thanks a lot!


[mongodb-replicaset] found invalid field args for v1.ExecAction

Is this a request for help?:

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
Helm Version
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

Kubernetes Version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.5", GitCommit:"cce11c6a185279d037023e02ac5249e14daa22bf", GitTreeState:"clean", BuildDate:"2017-12-07T18:09:07Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.6", GitCommit:"6260bb08c46c31eea6cb538b34a9ceb3e406689c", GitTreeState:"clean", BuildDate:"2017-12-21T06:23:29Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
mongodb-replicaset version 3.0.0
What happened:
$ helm install stable/mongodb-replicaset
> Error: error validating "": error validating data: found invalid field args for v1.ExecAction

What you expected to happen:
Chart successfully installs
How to reproduce it (as minimally and precisely as possible):
$ helm install stable/mongodb-replicaset
Anything else we need to know:
Also downloaded the values.yaml file, uncommented resources section, and ran
$ helm install -f values.yaml stable/mongodb-replicaset
Still encountered the same problem.
@unguiculus

The chart installed and tests ran successfully on our CI. I also run it without any problems on my cluster. These clusters have 1.9.x and Helm 2.8.2. Maybe it's related to your Helm or Kubernetes version. I'm kind of clueless from looking at the manifest.
Do you have any idea?

/assign

I have the same problem when using helm 2.7.2, works fine with 2.8.2

Same problem when using Kubernetes 1.8.2 and Helm 2.7.2

I have the same problems uing helm 2.7.0 and Kubernetes 1.9.3. Is there any work around to fix that?

This might be due to #3331 which was necessary for Kubernetes 1.10 compatibility.
I guess there are only two options: Use an older version of the chart or upgrade Helm. I would definitely recommend the latter if possible.
cc @mattfarina

Hi @unguiculus ，I found that a property called "args" is used in livenessProbe of mongo container. You can see it in the picture below:

I checked api-reference, "args" is not supported in version 1.8, 1.9 and 1.10. After I removed "args", the chart works fine in kubernetes 1.8 and helm 2.7.2 .

I think maybe higher version helm can ignore properties not supported when generating yaml files. But you still should remove "args" appear in  livenessProbe  and readinessProbe.

I was wrong in my above comment. Anyways, the issue was fixed in #5008.


Temporarily disable PR test filtering on mac

To work around https://github.com/grpc/grpc/issues/18968 which has been happening quite often recently.

I'm holding off on this for now for the ios binary size diff failure.

Superseded by #19120


rescue clause needs to match the body type

If a begin/rescue block is used as a value, we need to make sure the type of the body matches the rescue clauses, or the class will get a VerifyError at load time.

I almost got this working, but the problem is that deferred inference doesn't take into account whether the previous infer call was an expression or not, which turns out to be important when you are dealing with begin rescue end structures.

I think this should be fixed in the newast branch.  It's probably not the
nicest error message but I believe this will say something like "Cannot
assign java.lang.String to variable of type int'.
On Sun, Oct 23, 2011 at 6:09 PM, Nick Howard <
<EMAIL_ADDRESS>
I almost got this working, but the problem is that deferred inference
doesn't take into account whether the previous infer call was an expression
or not, which turns out to be important when you are dealing with begin
rescue end structures.
--
Reply to this email directly or view it on GitHub:
https://github.com/mirah/mirah/issues/52#issuecomment-2498924

@ribrdb now it is fixed in master too. I want to clean it up further, but it's a start.


fix: gux-button accessibility with icon-only and gux-title

Closes COMUI-3044

Is there a reason why the following existing implementations can't be used instead? Let me know if I'm missing something but at first glance these two implementations seem sufficient:
using gux-button
<gux-button>
    <gux-icon icon-name="user-add" decorative></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
</gux-button>

using gux-button-slot
  <gux-button-slot>
    <button type="button" onclick="notify(event)">
    <gux-icon icon-name="user-add"></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
    </button>
  </gux-button-slot>

Is there a reason why the following existing implementations can't be used instead? Let me know if I'm missing something but at first glance these two implementations seem sufficient:
using gux-button
<gux-button>
    <gux-icon icon-name="user-add" decorative></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
</gux-button>

using gux-button-slot
  <gux-button-slot>
    <button type="button" onclick="notify(event)">
    <gux-icon icon-name="user-add"></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
    </button>
  </gux-button-slot>

@katie-bobbe-genesys I agree with you on this. This is the best option imo, and I asked about it in standups, but was told to keep the current guxTitle functionality (just with our own styled tooltip instead of the "title" attr) instead of removing it entirely.
We already use it like this in the gux-tooltip example page ¯_(ツ)_/¯

Is there a reason why the following existing implementations can't be used instead? Let me know if I'm missing something but at first glance these two implementations seem sufficient:
using gux-button
<gux-button>
    <gux-icon icon-name="user-add" decorative></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
</gux-button>

using gux-button-slot
  <gux-button-slot>
    <button type="button" onclick="notify(event)">
    <gux-icon icon-name="user-add"></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
    </button>
  </gux-button-slot>

@katie-bobbe-genesys I agree with you on this. This is the best option imo, and I asked about it in standups, but was told to keep the current guxTitle functionality (just with our own styled tooltip instead of the "title" attr) instead of removing it entirely. We already use it like this in the gux-tooltip example page ¯_(ツ)_/¯

Jordan, could you tag whoever said to keep the guxTitle functionality in standup here. I would like to hear their opinion on this too

Is there a reason why the following existing implementations can't be used instead? Let me know if I'm missing something but at first glance these two implementations seem sufficient:
using gux-button
<gux-button>
    <gux-icon icon-name="user-add" decorative></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
</gux-button>

using gux-button-slot
  <gux-button-slot>
    <button type="button" onclick="notify(event)">
    <gux-icon icon-name="user-add"></gux-icon>
    <gux-tooltip-beta>

Add User

    </gux-tooltip-beta>
    </button>
  </gux-button-slot>

@katie-bobbe-genesys I agree with you on this. This is the best option imo, and I asked about it in standups, but was told to keep the current guxTitle functionality (just with our own styled tooltip instead of the "title" attr) instead of removing it entirely. We already use it like this in the gux-tooltip example page ¯_(ツ)_/¯

Jordan, could you tag whoever said to keep the guxTitle functionality in standup here. I would like to hear their opinion on this too

@MattCheely Can we get your opinion on this? You were the one said in the EU/APAC standup to keep the guxTitle for now.
Keeping the guxTitle to not cause breaking changes makes sense to me, but should we start having our examples work like Katie's example so that is what it moves to in the future? It makes sense to me since it simplifies our code and gives the consumer more flexibility too. The guxTitle prop doesn't really make sense to have anymore imo especially since we can't use a "title" prop in a button anyways without it clashing with our styling.

Sorry for the delayed response on this. We have to continue to support the gux-title because removing it would break backwards compatibility. It's not clear to me from reviewing the ticket if there's an actual a11y issue with gux-title or if it's a false positive from Axe scans related to Shadow DOM. I'd summarize my position as:

We have to support gux-title until the next major release
gux-title needs to be properly accessible. If these changes are required for that, we should implement them.
If gux-title is currently accessible, but is flagged by axe, I'm fine with just changing the example recommendations and not altering the components.


factor erange handling into its own function

Nice. FTR, we have a few occurences of this pattern in src/ffi.rs.

ah I should prob move a number of the functions I just added for service and netgroup to ffi.rs.


Reformatted VS Code documentation

Thank you for helping make the Dapr documentation better!
Please follow this checklist before submitting:

[ ] Read the contribution guide
[ ] Commands include options for Linux, MacOS, and Windows within codetabs
[ ] New file and folder names are globally unique
[ ] Page references use shortcodes instead of markdown or URL links
[ ] Images use HTML style and have alternative text
[ ] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:
Description
Reformatted some of the information in the VS Code Dapr documentation by creating a folder instead of singular file to hold information regarding

Extension
Remote Dev Work
Manually setting up VS Code debugging for Dapr

Looks good. See some of my minor change requests.
I know some of this wording was there before and just refactored but please see it is also consistent with style and tone (for example, can remove the "lets get started" first person statement in the manual config page )

Got it! fixed everything except the extension title regarding "Overview"

Hey everyone I tried to fix all the spots you all pointed out, I believe that the pages should be in good shape now @AaronCrawfis suggestions were pretty much spot on and they fixed the informal structure that the extension page had for the first two features the rest are pretty much self explanatory in their usage. Let me know if anyone has any other points i should look into @msfussell.


US969005: Accept secret name/key as arg rather than actual secret

https://internal.almoctane.com/ui/entity-navigation?p=131002/6001&entityType=work_item&id=969005

A developer build has not yet been created for this branch. Click here to go ahead and create the build...

CI Build Link:
https://sou-jenkins2.swinfra.net/job/CAFapi/job/CAFapi~util-flyway-installer~US969005~CI


undefined symbol: _ZN10tensorflow12OpDefBuilder4AttrESs

Hello
Please after setup all the requirements , I want now to do a setup for training by running this command ./setup_training.sh <ontonotes/path/ontonotes-release-5.0> $data_dir
but i am getting this error
"  _np_quint8 = np.dtype([("quint8", np.uint8, 1)])
/opt/conda/envs/coref/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:543: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint16 = np.dtype([("qint16", np.int16, 1)])
/opt/conda/envs/coref/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:544: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_quint16 = np.dtype([("quint16", np.uint16, 1)])
/opt/conda/envs/coref/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:545: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint32 = np.dtype([("qint32", np.int32, 1)])
/opt/conda/envs/coref/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:550: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
np_resource = np.dtype([("resource", np.ubyte, 1)])
Traceback (most recent call last):
File "minimize.py", line 14, in
import util
File "/home/jupyter/coref/util.py", line 16, in
import independent
File "/home/jupyter/coref/independent.py", line 14, in
import coref_ops
File "/home/jupyter/coref/coref_ops.py", line 8, in
coref_op_library = tf.load_op_library("./coref_kernels.so")
File "/opt/conda/envs/coref/lib/python3.7/site-packages/tensorflow/python/framework/load_library.py", line 61, in load_op_library
lib_handle = py_tf.TF_LoadLibrary(library_filename)
tensorflow.python.framework.errors_impl.NotFoundError: ./coref_kernels.so: undefined symbol: _ZN10tensorflow12OpDefBuilder4AttrESs"
Please is there a way to fix this issue?

Looks like solution is here: #29


✨ API | Second onelink.to link for new users

Hi team
We currently use one onelink.to link for both Google Form email templates. We should create a second one and implement it so that both emails have unique links, and as such we can get analytics for new users vs existing users.
Tasks

[x] Create second link
[x] Implement on both email templates

Acceptance Criteria

[x] Meets Definition of Done - https://github.com/SSWConsulting/SSW.Rewards.Mobile/blob/main/_docs/Definition-of-Done.md

Thanks!

Done - the email templates now user separate links for new and existing users.


Error level too high for "matched none of the white list"

Do you want to request a feature or report a bug?
Bug
What did you do?
Error level for an IP not matching the trusted IP's for forwardedHeaders is too high. (It's ERROR, should be INFO or DEBUG)
When used as a reverse proxy, most clients hitting Traefik aren't going to be a trusted IP, so we don't want them to be able to set headers like X-Forwarded-For. This means the trusted IP range is going to be very small. However, because the error level is currently set to ERROR, every request will generate a line in the Traefik logfile. This should be an INFO or DEBUG error message, as it's not an ERROR. It's working as intended, just filling up the logs with unnecessary messages.
I believe just https://github.com/containous/traefik/blob/3b3ca894834912a24b08ba85775a2b3197003055/whitelist/ip.go#L90 needs to be modified to be an INFO or DEBUG line
What did you expect to see?
No log lines for each request, unless the log level is INFO or DEBUG
time="2018-05-29T23:00:40Z" level=debug msg="\"<IP_ADDRESS>:48656\" matched none of the white list"
time="2018-05-29T23:01:25Z" level=debug msg="\"<IP_ADDRESS>:63690\" matched none of the white list"

What did you see instead?
"Error" lines
time="2018-05-29T23:00:40Z" level=error msg="\"<IP_ADDRESS>:48656\" matched none of the white list"
time="2018-05-29T23:01:25Z" level=error msg="\"<IP_ADDRESS>:63690\" matched none of the white list"

Output of traefik version: (What version of Traefik are you using?)
$ sudo docker run traefik version
Version:      v1.6.1
Codename:     tetedemoine
Go version:   go1.10.2
Built:        2018-05-14_07:16:56PM
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
debug = false

logLevel = "ERROR"

defaultEntryPoints = ["https","http"]
[traefikLog]
  filePath = "/traefik.log"

[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
  address = ":443"
  [entryPoints.https.forwardedHeaders]
      trustedIPs = ["<IP_ADDRESS>/12"]
  [entryPoints.https.tls]

@ldez Thanks for the quick response


nested groups missing after update/configuration update (1.8.0+)

System Health details
System Information

version
core-2023.7.2

installation_type
Home Assistant Supervised

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.11.4

os_name
Linux

os_version
5.10.0-19-amd64

arch
x86_64

timezone
Europe/Stockholm

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
5000

Installed Version
1.32.1

Stage
running

Available Repositories
1275

Downloaded Repositories
54

Home Assistant Cloud

logged_in
false

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Debian GNU/Linux 11 (bullseye)

update_channel
stable

supervisor_version
supervisor-2023.07.1

agent_version
1.2.1

docker_version
20.10.21

disk_total
78.2 GB

disk_used
55.8 GB

healthy
true

supported
true

supervisor_api
ok

version_api
ok

installed_addons
Studio Code Server (5.8.1), MariaDB (2.6.1), InfluxDB (4.7.0), Mosquitto broker (6.2.1), phpMyAdmin (0.8.7), ESPHome (2023.6.5), Frigate NVR Proxy (1.3), Node-RED (14.3.0), Zigbee2MQTT (1.32.1-1), Network UPS Tools (0.12.0)

Husqvarna Automower

can_reach_server
ok

Dashboards

dashboards
2

resources
31

views
20

mode
storage

Recorder

oldest_recorder_run
July 14, 2023 at 06:32

current_recorder_run
July 16, 2023 at 09:49

estimated_db_size
2121.41 MiB

database_engine
mysql

database_version
10.6.12

Spotify

api_endpoint_reachable
ok

Checklist

[X] I have read the FAQ to see if there is a known solution to my problem.
[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of currently previous issues..

Describe the issue
After the update to 1.8.0 and changes to configuration related to that (removed platform and moved configuration to powercalc->sensors), no entities defined in nested groups are shown anymore
Only single entities and single groups are working
Full configuration:
new style:
https://github.com/gribber/ha/blob/main/integrations/powercalc.yaml
old disabled:
https://github.com/gribber/ha/blob/main/sensors/powercalc.yaml.disabled
Reproduction steps

create nested groups
include entities by area in each group

Debug logs
2023-07-16 09:49:59.131 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Including entities from area: parkering_och_uppfart
2023-07-16 09:49:59.133 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Found include entities: [RegistryEntry(entity_id='light.entre_1', unique_id='0x84fd27fffeb32cc0_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='e76897dda0a1f08d893f942c80960d6b', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='efeed9360ecb093e0b1b49f80ea198de', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='entre_1', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.entre_2', unique_id='0x84fd27fffeab9599_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='b490e0e16be952eeccc825df7d611142', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='b39c171d9828058bf4309f2bd7da35cc', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='entre_2', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.parking_1', unique_id='0xcc86ecfffe1bd881_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='8af4d2acf3f765f5d6dbc06a68676115', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='e5c6ed34b9b9d891e983516df040e571', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='parking_1', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.garage_front', unique_id='0x84fd27fffeb30da6_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='c693fc5507d76d887b1c3fb1f0083918', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='b3a23bccd7c28b1b39392653a5e357f5', has_entity_name=False, name='Framsida garage', options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='garage_front', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.parking_2', unique_id='0xcc86ecfffe1bd6f2_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='23bc52fc888649402e4a28932d208375', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='c26a9be5e03bb8eaeb3d70cf4a778b48', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='parking_2', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.parking_3', unique_id='0x84fd27fffeb0f857_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='66c2a7c58ba5d2097f5f69d4be20ada5', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='04788124a2c98a23e7c7e5aa46d252f6', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='parking_3', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.garage_side', unique_id='0x84fd27fffe2ce91c_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='5f332018ca05af7300efef50db568560', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='a013df8b41ced2b5eb3578bc34fae4f0', has_entity_name=False, name='Sida garage', options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='garage_side', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.driveway_1', unique_id='0x84fd27fffeb31224_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='1c4ff4a1b08cfa55ff692cf04bb2c288', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='5223f878e8e82ba0d44afd5842723577', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='driveway_1', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.parkering_och_uppfart', unique_id='3_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='e222f8525f061f68f03d582116928905', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='beeed4c60774c2d252b0a1f22a08a37a', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='parkering_och_uppfart', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.earth_cellar', unique_id='0x84fd27fffeb0f4d9_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='ce27983fa32233d67ddc48a9db8e01fa', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='4c7b00931fede882f91335b80e81f36f', has_entity_name=False, name='Lampa utanför', options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='earth_cellar', supported_features=44, translation_key=None, unit_of_measurement=None)]
2023-07-16 09:49:59.133 ERROR (MainThread) [custom_components.powercalc.sensor] Could not resolve any entities in group 'outdoor parking driveway'
2023-07-16 09:49:59.134 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Including entities from area: uterum
2023-07-16 09:49:59.135 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Found include entities: [RegistryEntry(entity_id='light.conservatory_ceiling', unique_id='0x84fd27fffe581775_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='8b95874d125bbf906ff826fadb25d0d9', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='374d2653767cbf634bb56a8225385c49', has_entity_name=False, name='Tanklampan', options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='conservatory_ceiling', supported_features=44, translation_key=None, unit_of_measurement=None), RegistryEntry(entity_id='light.rice_lamp', unique_id='0x588e81fffeb754eb_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'min_color_temp_kelvin': 2202, 'max_color_temp_kelvin': 4000, 'min_mireds': 250, 'max_mireds': 454, 'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['color_temp']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='78e51e1a6b8374940bd8b4d77e4998f0', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='7d301c9c48fe9cbf2f8338cded569ab2', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='rice_lamp', supported_features=44, translation_key=None, unit_of_measurement=None)]
2023-07-16 09:49:59.135 ERROR (MainThread) [custom_components.powercalc.sensor] Could not resolve any entities in group 'conservatory'
2023-07-16 09:49:59.137 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Including entities from area: garage
2023-07-16 09:49:59.138 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Found include entities: [RegistryEntry(entity_id='light.garage_alert', unique_id='0x680ae2fffe8f8d11_light_zigbee2mqtt', platform='mqtt', aliases=set(), area_id=None, capabilities={'effect_list': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect'], 'supported_color_modes': ['brightness']}, config_entry_id='ed73bc0dd5b037efe0f7b5208585e074', device_class=None, device_id='3189253f55a131dad88e0cd0fde99cd7', disabled_by=None, entity_category=None, hidden_by=None, icon=None, id='b8ca778678886ea0af4beca18b090cfd', has_entity_name=False, name=None, options={'conversation': {'should_expose': True}}, original_device_class=None, original_icon=None, original_name='garage_alert', supported_features=44, translation_key=None, unit_of_measurement=None)]
2023-07-16 09:49:59.138 ERROR (MainThread) [custom_components.powercalc.sensor] Could not resolve any entities in group 'garage'
2023-07-16 09:49:59.141 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=sensor.dummy entity_category=None, sensor_name=techups power strategy=fixed manufacturer= model= standby_power=0.00 unique_id=3788b38d-5330-4c7e-a0ea-8565dda2c6c9)
2023-07-16 09:49:59.141 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: techups energy
2023-07-16 09:49:59.141 DEBUG (MainThread) [custom_components.powercalc.discovery] media_player.hobbyroom_speaker: Auto discovered model (manufacturer=Google Inc., model=Google Home Mini)
2023-07-16 09:49:59.142 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=media_player.hobbyroom_speaker entity_category=None, sensor_name=hobbyroom_speaker power strategy=linear manufacturer=google model=Home Mini (HOA) standby_power=1.65 unique_id=9d2104d0-fa1d-6e19-eeaa-e08660787ed4)
2023-07-16 09:49:59.142 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: hobbyroom_speaker energy
2023-07-16 09:49:59.142 DEBUG (MainThread) [custom_components.powercalc.discovery] media_player.kitchen_display: Auto discovered model (manufacturer=Google Inc., model=Google Nest Hub)
2023-07-16 09:49:59.142 ERROR (MainThread) [custom_components.powercalc.sensors.power] media_player.kitchen_display: Skipping sensor setup Model not found in library (manufacturer: Google Inc., model: Google Nest Hub)
2023-07-16 09:49:59.143 ERROR (MainThread) [custom_components.powercalc.sensors.power] media_player.kitchen_display: Skipping sensor setup: Model not found in library (manufacturer: Google Inc., model: Google Nest Hub)
2023-07-16 09:49:59.143 DEBUG (MainThread) [custom_components.powercalc.discovery] media_player.vardagsrummet_speaker: Auto discovered model (manufacturer=Google Inc., model=Google Nest Mini)
2023-07-16 09:49:59.143 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=media_player.vardagsrummet_speaker entity_category=None, sensor_name=vardagsrummet_speaker power strategy=linear manufacturer=google model=Nest Mini (H2C) standby_power=1.65 unique_id=a7f130bf-f099-1f63-c840-ec0f84b4d285)
2023-07-16 09:49:59.143 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: vardagsrummet_speaker energy
2023-07-16 09:49:59.143 DEBUG (MainThread) [custom_components.powercalc.discovery] media_player.sovrummet_speaker: Auto discovered model (manufacturer=Lenovo, model=Lenovo CD-4N341Y)
2023-07-16 09:49:59.143 ERROR (MainThread) [custom_components.powercalc.sensors.power] media_player.sovrummet_speaker: Skipping sensor setup Model not found in library (manufacturer: Lenovo, model: Lenovo CD-4N341Y)
2023-07-16 09:49:59.143 ERROR (MainThread) [custom_components.powercalc.sensors.power] media_player.sovrummet_speaker: Skipping sensor setup: Model not found in library (manufacturer: Lenovo, model: Lenovo CD-4N341Y)
2023-07-16 09:49:59.143 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped power sensor: smart speakers power (entity_id=sensor.smart_speakers_power)
2023-07-16 09:49:59.144 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped energy sensor: smart speakers energy (entity_id=sensor.smart_speakers_energy)
2023-07-16 09:49:59.145 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=fan.livingroom_starkvind entity_category=None, sensor_name=livingroom_starkvind power strategy=fixed manufacturer= model= standby_power=0.00 unique_id=0x2c1165fffe7daa19_fan_zigbee2mqtt)
2023-07-16 09:49:59.145 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: livingroom_starkvind energy
2023-07-16 09:49:59.145 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped power sensor: environment and air quality power (entity_id=sensor.environment_and_air_quality_power)
2023-07-16 09:49:59.145 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped energy sensor: environment and air quality energy (entity_id=sensor.environment_and_air_quality_energy)
2023-07-16 09:49:59.146 DEBUG (MainThread) [custom_components.powercalc.sensors.abstract] Binding sensor.hobbyroom_speaker_power to device 3c6837d79a6db595a7d273efba0bef3a
2023-07-16 09:49:59.147 DEBUG (MainThread) [custom_components.powercalc.sensors.abstract] Binding sensor.hobbyroom_speaker_energy to device 3c6837d79a6db595a7d273efba0bef3a
2023-07-16 09:49:59.147 DEBUG (MainThread) [custom_components.powercalc.sensors.abstract] Binding sensor.vardagsrummet_speaker_power to device 171edd3abed80b550d5ec6983ee7f3c3
2023-07-16 09:49:59.147 DEBUG (MainThread) [custom_components.powercalc.sensors.abstract] Binding sensor.vardagsrummet_speaker_energy to device 171edd3abed80b550d5ec6983ee7f3c3
2023-07-16 09:49:59.148 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Load previous energy sensor states from store
2023-07-16 09:49:59.148 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.smart_speakers_energy: Restoring state: 17.8584
2023-07-16 09:49:59.158 DEBUG (MainThread) [custom_components.powercalc.sensors.abstract] Binding sensor.livingroom_starkvind_power to device 1ce5e89ca8b4bef9386eb3aff5bc1451
2023-07-16 09:49:59.159 DEBUG (MainThread) [custom_components.powercalc.sensors.abstract] Binding sensor.livingroom_starkvind_energy to device 1ce5e89ca8b4bef9386eb3aff5bc1451
2023-07-16 09:49:59.159 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.environment_and_air_quality_energy: Restoring state: 10.0417
2023-07-16 09:49:59.451 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.vardagsrummet_speaker: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:49:59.526 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.vardagsrummet_speaker: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:49:59.553 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.hobbyroom_speaker: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:49:59.564 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.hobbyroom_speaker: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:49:59.576 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.vardagsrummet_speaker: State changed to "off". Power:1.65
2023-07-16 09:49:59.650 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.hobbyroom_speaker: State changed to "off". Power:1.65
2023-07-16 09:49:59.664 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.vardagsrummet_speaker: State changed to "off". Power:1.65
2023-07-16 09:49:59.681 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.hobbyroom_speaker: State changed to "off". Power:1.65
2023-07-16 09:50:01.883 DEBUG (MainThread) [custom_components.powercalc.sensors.power] fan.livingroom_starkvind: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:50:02.075 DEBUG (MainThread) [custom_components.powercalc.sensors.power] fan.livingroom_starkvind: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:50:04.238 DEBUG (MainThread) [custom_components.powercalc.sensors.power] fan.livingroom_starkvind: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:50:08.487 DEBUG (MainThread) [custom_components.powercalc.sensors.power] sensor.dummy: State changed to "on". Power:27.00
2023-07-16 09:50:08.488 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.hobbyroom_speaker: State changed to "off". Power:1.65
2023-07-16 09:50:08.488 DEBUG (MainThread) [custom_components.powercalc.sensors.power] media_player.vardagsrummet_speaker: State changed to "off". Power:1.65
2023-07-16 09:50:08.488 DEBUG (MainThread) [custom_components.powercalc.sensors.power] fan.livingroom_starkvind: Source entity has an invalid state, setting power sensor to unavailable
2023-07-16 09:50:08.570 DEBUG (MainThread) [custom_components.powercalc.sensors.power] sensor.dummy: State changed to "on". Power:27.00
2023-07-16 09:50:08.705 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: All standby energy
2023-07-16 09:50:10.730 DEBUG (MainThread) [custom_components.powercalc.sensors.power] fan.livingroom_starkvind: State changed to "on". Power:2.00
2023-07-16 09:50:10.743 DEBUG (MainThread) [custom_components.powercalc.sensors.power] fan.livingroom_starkvind: State changed to "on". Power:2.00
2023-07-16 09:50:10.759 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.environment_and_air_quality_energy: Recalculate, current value: 10.0417
2023-07-16 09:50:10.759 DEBUG (MainThread) [custom_components.powercalc.sensors.group] delta for entity sensor.livingroom_starkvind_energy: 0.0000, prev=10.0417, cur=10.0417
2023-07-16 09:50:10.759 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.environment_and_air_quality_energy: New value: 10.0417

Diagnostics dump or YAML config
No response

Which version of powercalc are you running? 1.8.0 or 1.8.1?

Which version of powercalc are you running? 1.8.0 or 1.8.1?

1.8.1

I think the problem is not related to the change in configuration, but the change in the way auto discovery is working now.
2023-07-16 09:49:59.133 ERROR (MainThread) [custom_components.powercalc.sensor] Could not resolve any entities in group 'outdoor parking driveway'

You are expecting entities in this area right?
Previously entities were magically created even if you have enable_autodiscovery: false. In new version this is not the case anymore.
So you just have to add a few lines of yaml to register a library supported entity for powercalc registration.
For example assume you have a light light.parking_light.
Just add:
sensors:
  - entity_id: light.parking_light`

That should create the powercalc sensors for this light, and than it also should be included in the group again when you use the include option.

I think the problem is not related to the change in configuration, but the change in the way auto discovery is working now.
2023-07-16 09:49:59.133 ERROR (MainThread) [custom_components.powercalc.sensor] Could not resolve any entities in group 'outdoor parking driveway'

You are expecting entities in this area right? Previously entities were magically created even if you have enable_autodiscovery: false. In new version this is not the case anymore. So you just have to add a few lines of yaml to register a library supported entity for powercalc registration. For example assume you have a light light.parking_light.
Just add:
sensors:
  - entity_id: light.parking_light`

That should create the powercalc sensors for this light, and than it also should be included in the group again when you use the include option.

I have literary hundreds of lights, parking lights consists of about 25, that's why I include lights by area, as some tends to be added/removed all the time
So there is no way to automatically add them without define them all one by one and update the configuration by hand every time somethings changes?
Or could I just enable enable_autodiscovery? Not sure why I have that at the moment, I think it was added earlier when we debugged some other issue

hmm I see your issue. I'm sorry that you are bothered dealing with some extra configuration now.
This change had been made to make the behaviour more consistent and also the code easier to maintain.
When you enable auto discovery items should appear in the GUI, you can just click configure for these and then everything should return to work correctly hopefully.

EDIT: Enable autodiscovery did not help

You'll have to accept the discovered item. As that will make the configuration registered to HA, and powercalc knows it need to setup powercalc sensors for the entity.
When you ignore it powercalc will not setup power entities for that entity.
And also don't include it when using the include option. Previously it would still setup power sensors, that's one of the reason this change was made.

I see, I guess that's doable
Is it possible to rename a energy sensor? When I configured a light, it created duplicates (energy and energy_2, where the only one is unavailable), the power sensor was possible to rename but not the energy as in turned unavailable when I did
I want to keep the same name to have the history/statistics left
Not a big problem, just have to remove all old unavailable sensor before I configure each auto discovered light

I'm not sure why you get duplicates. As the unique id of the entities should have stayed the same, and not cause any duplicates.
How were the power sensors named? old and new one?
Could you have a look in config/.storage/core.entity_registry?

old one
      {
        "config_entry_id": null,
        "entity_id": "sensor.bedroom_left_energy",
        "id": "e0965b35fdb6900850b3494d1c518704",
        "orphaned_timestamp":<PHONE_NUMBER>.8782144,
        "platform": "powercalc",
        "unique_id": "0x2c1165fffe038a92_light_zigbee2mqtt_energy"
      },

new one:
      {
        "aliases": [],
        "area_id": null,
        "capabilities": {
          "state_class": "total_increasing"
        },
        "config_entry_id": "65aece4746e2eb662155c8156719de4e",
        "device_class": null,
        "device_id": "1d9edc4c88480e4de6cc5c34f2fdbd8b",
        "disabled_by": null,
        "entity_category": null,
        "entity_id": "sensor.bedroom_left_energy_2",
        "hidden_by": null,
        "icon": null,
        "id": "6b9435d10a4609ccc8fd1315145f98ca",
        "has_entity_name": false,
        "name": null,
        "options": {
          "conversation": {
            "should_expose": false
          },
          "sensor": {
            "display_precision": null
          }
        },
        "original_device_class": null,
        "original_icon": "mdi:lightning-bolt",
        "original_name": "bedroom_left energy",
        "platform": "powercalc",
        "supported_features": 0,
        "translation_key": null,
        "unique_id": "pc_0x2c1165fffe038a92_light_zigbee2mqtt_energy",
        "unit_of_measurement": null
      },

Ah I see.
The unique id should start with pc_, that's a change I made a long time ago.
Apparently the automatic created entities did not had this unique id structure yet.
HA tries to create entity with id sensor.bedroom_left_energy, but because it's already taken by the old one, with unique_id 0x2c1165fffe038a92_light_zigbee2mqtt_energy it renames the entity to _2.
I will have a look into the code if I can automatically modify the unique id to match the correct pattern, whenever I see an entity which has the old legacy unique_id pattern.
In the meantime you could try doing this yourself manually for an entity by modifying core.entity_registry file. And change the unique_id's of powercalc entities to pc_.

Changing the uuid before works and does not create duplicates
After changing that on one light, I expected the group energy sensors to come online as well, that did not happen, those nested groups are still unavailable
outdoor lights (group) -> outdoor ambiance (group) -> conservatory_1 (entity)
first two unavailable
root@homeassistant:~# hass-cli state get sensor.outdoor_lights_energy
ENTITY                        DESCRIPTION       STATE        CHANGED
sensor.outdoor_lights_energy  Utomhusbelysning  unavailable  2023-07-16T10:25:38.672963+00:00
root@homeassistant:~# hass-cli state get sensor.outdoor_ambience_energy
ENTITY                          DESCRIPTION              STATE        CHANGED
sensor.outdoor_ambience_energy  outdoor ambience energy  unavailable  2023-07-16T10:25:38.673905+00:00
root@homeassistant:~# hass-cli state get sensor.conservatory_1_energy
ENTITY                        DESCRIPTION              STATE  CHANGED
sensor.conservatory_1_energy  conservatory_1 energy   0.3206  2023-07-16T10:29:42.416088+00:00

Are the entities shown correctly on the powercalc integration page. Where all the GUI setup entries are shown?

Yeah, that works fine

Ok that looks fine. Do you have debug logs again? I suspect you still have the Could not resolve any entities in group error.
When you have full debug logs since startup hopefully I can figure out what the issue is.

home-assistant_powercalc_2023-07-16T11-16-46.948Z.log

hmm yes, I see the problem.
It's a kind of chicken / egg issue.
I see in your logs / and also I see that during debugging that the HA yaml setup routine is always executed first before the GUI config entries are setup. I might have an idea how to resolve. Let me give it a thought and do some testing.

No unfortunately when having a further look into it and debugging you cannot reference powercalc entities defined with the GUI in the YAML include functionality. As during evalutation of the include options the entities are just not created and not known to powercalc.
So unfortunately I don't really have an easy solution for you now.
I will give it some more thought. Might reintroduce the old logic somehow. But it's a hard one as there are so many systems, configurations and setups to consider.
You can either define the entity_id's explicitely in the YAML which you want to include in your system, or downgrade to 1.7.* for now.

Downgraded, it would be too much to maintain to keep the configuration updated for each light to be worth it
I hope you find a way to solve it, thanks in advance

I wrote some code to correctly include the GUI powercalc sensors when using the YAML include options.
#1756
Are you able to test that by installing the master branch?

Tested, don't think I can see any difference against 1.8.1, groups still not created, attaching the debug log
home-assistant_powercalc_2023-07-16T13-12-59.473Z.log

Could you verify first that you are on latest master.

You also did still have some entities setup using the GUI right?
When the answer on above both is true I might need to add some extra debug logging to the code.

It is (fell for that one before so I made sure I got the correct one this time :) )

Haha, ok good to know we are on the right version.
Let's focus on 1 entity / area in debugging this.
Which individual entity do you expect in which area group?
For this entity you have setup using discovery now, right? Could you lookup the JSON for that in config/.storage/core.config_entries?

Let's focus on conservatory_1 then
The defined area for that one is dekoration_ute which is included in the sub-group "outdoor ambience" as below:
https://github.com/gribber/ha/blob/main/integrations/powercalc.yaml#L3-L17

Added by autodiscovery:

the json for that light (energy):
      {
        "aliases": [],
        "area_id": null,
        "capabilities": {
          "state_class": "total_increasing"
        },
        "config_entry_id": "bd9ee80f8dce1e30798d6624545d8db4",
        "device_class": null,
        "device_id": "2e5f990fc475fa0f1edb75f39cfb806b",
        "disabled_by": null,
        "entity_category": null,
        "entity_id": "sensor.conservatory_1_energy",
        "hidden_by": null,
        "icon": null,
        "id": "385ecf2f868012e2d3f8e4d4fd80c6cd",
        "has_entity_name": false,
        "name": null,
        "options": {
          "conversation": {
            "should_expose": false
          }
        },
        "original_device_class": null,
        "original_icon": "mdi:lightning-bolt",
        "original_name": "conservatory_1 energy",
        "platform": "powercalc",
        "supported_features": 0,
        "translation_key": null,
        "unique_id": "pc_0x84fd27fffe2ce1d3_light_zigbee2mqtt_energy",
        "unit_of_measurement": null
      },

Thanks for the information. Looks like you shared information from .storage/core.entity_registry, needs to be .storage/core.config_entries. That contains all the data for the GUI configuration options.
But there is an easier way to get that btw, you can also click the three dots and "Download diagnostics".

Thanks for the information. Looks like you shared information from .storage/core.entity_registry, needs to be .storage/core.config_entries. That contains all the data for the GUI configuration options. But there is an easier way to get that btw, you can also click the three dots and "Download diagnostics".

You are correct, here comes the data:
      {
        "entry_id": "bd9ee80f8dce1e30798d6624545d8db4",
        "version": 2,
        "domain": "powercalc",
        "title": "conservatory_1",
        "data": {
          "entity_id": "light.conservatory_1",
          "manufacturer": "ikea",
          "model": "LED2005R5",
          "unique_id": "pc_0x84fd27fffe2ce1d3_light_zigbee2mqtt",
          "sensor_type": "virtual_power",
          "name": "conservatory_1",
          "_power_entity": "sensor.conservatory_1_power",
          "_energy_entity": "sensor.conservatory_1_energy"
        },
        "options": {},
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "integration_discovery",
        "unique_id": "pc_0x84fd27fffe2ce1d3_light_zigbee2mqtt",
        "disabled_by": null
      }

Diagnostics file:
config_entry-powercalc-bd9ee80f8dce1e30798d6624545d8db4.json.txt

That looks exactly as expected.
These are also correct. right?
"_power_entity": "sensor.conservatory_1_power",
"_energy_entity": "sensor.conservatory_1_energy"

Then I might need to add some extra debug logging.
I also changed the debug line Found include entities to only list the entity_id's and not full objects. Less data and makes it a lot easier to read.

That looks exactly as expected. These are also correct. right?
"_power_entity": "sensor.conservatory_1_power",
"_energy_entity": "sensor.conservatory_1_energy"

Yeah that's correct

Can you overwrite config/custom_components/powercalc/group_include/include.py with the following version https://github.com/bramstroker/homeassistant-powercalc/blob/debug-include/custom_components/powercalc/group_include/include.py?
Added multiple extra logs here. That would hopefully show what goes wrong.
Restart after that and check logs again.

home-assistant_powercalc_2023-07-16T15-04-12.159Z.log

I only see:
Including entities from area: parkering_och_uppfart
Including entities from area: uterum
Including entities from area: garage
These are all the first groups from the nested structure, so that's a pattern there. Need to have a further look into that if I can reproduce. Might be an regression bug in v1.8.
Could you try adding the GUI entry for a sensor for one of these groups and see if the group works correctly again? For example garage

I'm pretty sure the above happens because when no entities could be resolved for an area than it will be considers as an error and stop processing the other entities in the group.
Will have a look if we can continue processing the other entities/subgroups in that case.

Didn't we have that problem before as well? I stopped when no lights was resolved in the first group
I small bulb lighted up somewhere in my head
including the debug file, added garage_alert from auto discovery
home-assistant_powercalc_2023-07-16T15-23-01.115Z.log

Didn't we have that problem before as well? I stopped when no lights was resolved in the first group I small bulb lighted up somewhere in my head

I don't know. Anyways I was able to reproduce with a test and will have a look into fixing that. And that will also prevent any regressions in the future.

including the debug file, added garage_alert from auto discovery home-assistant_powercalc_2023-07-16T15-23-01.115Z.log

That confirmed my suspision:
2023-07-16 17:21:03.396 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Including entities from area: garage
2023-07-16 17:21:03.397 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Found possible include entities: ['light.garage_alert']
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Try to find power sensor
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Walk config entries
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Check config entry bedroom_left
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Check config entry bedroom_right
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Check config entry conservatory_1
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Check config entry garage_alert
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] light.garage_alert: Found config entry garage_alert
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped power sensor: garage power (entity_id=sensor.garage_power)
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped energy sensor: garage energy (entity_id=sensor.garage_energy)
2023-07-16 17:21:03.398 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Including entities from area: teknikrum

Now it sets up garage correctly and also continous to teknikrum.

Continue setting up group on error has been fixed with #1757
Is merged to master.

Confirmed working, now all groups showing again :)

Awesome! Thanks for providing the info and helping debugging this one.


Add a confirmation action for permanently deleting emails

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
6.800
Problem you are trying to solve
Prevent accidental deletion of emails in the "Trash", since after they're gone from there, they're gone for good.
One scenario when this can happen (as it just did to me):
You delete an email from inbox, then realize you still had to check something. You go to the trash to get the email back, and verify what you needed to. Then, when you're done with it, you may forget that it's already in the trash, and so you click the "Delete" button again; it's gone for good.
Suggested solution
Add something similar to the Outlook for Android implementation (default), where a confirmation message is shown before being able to delete an email from the "Trash" folder, and which specifies that the deletion will be permanent.
Screenshots / Drawings / Technical details
Add a new action to the already existing "Confirm actions" menu of the Interaction settings section; maybe something called "Delete (in Trash)".

I would assume that, by default, the confirmation message for these actions are generic, and so if this new action was to be implemented, having a personalized message (like done by Outlook devs) would be beneficial. Otherwise, a user who has multiple confirm actions enabled might confirm without thinking twice, which defeats the whole purpose of the confirmation feature.

@cketti I am new to this project. I hope my PR solves this issue. Would like you to review it.

Thanks, I looked into it. Right now, I think there isn't any way to find out whether a result from a search in the unified inbox belongs to the trash folder.

I don't think this should be limited to deleting messages from the trash folder. The app should ask for confirmation whenever a message is about to be deleted permanently. That includes deleting messages from the trash folder, but also applies when no trash folder is configured and deleting a message would permanently delete it right away.
I suggest using the following messages:

Do you want to permanently delete this message?
Do you want to permanently delete these messages?

A special case is deleting multiple messages from the message list. In that case some messages could be deleted permanently while others will be moved to the trash folder.
I suggest the following message for this special case:

Do you want to delete these messages, ${numberOfPermanentlyDeleted} of them permanently?

Yes, that makes a lot of sense.

Definitely the best way to implement this indeed! Well thought.
With that said, it would require a verification of the folder in which the selected messages are located. As @beradeep said, you can get a list of messages from multiple folders in the unified inbox, but it can also be the case if you initiate a search from any folder, and then change the mode to "search everywhere". @beradeep said this capability doesn't seem possible currently.

It is possible to find out what folder a message is in. The app also uses this information to decide whether to move the message to the trash folder or delete it permanently. But that's a detail that belongs to the pull request discussion, not here.


flatpak: 1.14.8 -> 1.14.10

Description of changes
Fixes CVE-2024-42472
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

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

closes https://github.com/NixOS/nixpkgs/pull/334728

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

No idea why the test times out and I lack the time to debug this. I tested this locally with a flatpak and that worked like a charm.


[Request] Add some kind of filtering system for global colliders

"Others have local colliders" feature is neat, but it almost always leads to 19 fps and lower. If it's possible, it would be neat to have the ability to turn it off person by person, or at least have a toggle to have it applied globally/only for someone on your friends list.
Thanks for the mod nevertheless!

Thank you for the request, I will try to add per user local colliders and I am also working on a more optimized version of local colliders that will hopefully improve performance even further

Take a look at the barebones implementation of GlobalDynamicBones.dll (I used it prior to your mod). I have observed no performance hit (at least no noticeable one) with it.
https://dropmefiles.com/RZ4Di

That would make the perfect sense, as the sole purpose of the mod (at least for me) is to be able to touch other avatars - and you do this by hand.
I certainly wish for this to be an option! :)
Just to clarify, that would mean that I would be able to touch every dynamic bone of any other avatar, but only with my hands, correct? Makes perfect sense as an optimization option to me then. I certainly would look into making this the default for "others have local colliders option", would I be in your place :)

New version has added this feature as "Target only hand colliders".
Thank you for your suggestion!


RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn

I tried to finetue the model by "python fish_speech/train.py --config-name text2semantic_finetune_lora"
the got the following error, Do you hava any idea? Thank you!
[2024-02-24 12:15:22,750][fish_speech.utils.utils][ERROR] - [rank: 0]
……
RuntimeError: element 0 of tensors does not require grad and does not have a grad_fn
[2024-02-24 12:15:22,776][fish_speech.utils.utils][INFO] - [rank: 0] Output dir: results/text2semantic_400m_finetune_lora
Error executing job with overrides: []

closed