im experiencing the same issue where atom doesnt quit with the shortcut or from the menu. im very new to programming,,,wondering if anyone can help.

Prerequisites

[ ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
[Description of the issue]
Steps to Reproduce

[First Step]
[Second Step]
[and so on...]

Expected behavior: [What you expect to happen]
Actual behavior: [What actually happens]
Reproduces how often: [What percentage of the time does it reproduce?]
Versions
You can get this information from copy and pasting the output of atom --version and apm --version from the command line. Also, please include the OS and what version of the OS you're running.
Additional Information
Any additional information, configuration or data that might be necessary to reproduce the issue.

Thanks for the report!
Based on the issue title, this sounds looks like a duplicate of https://github.com/atom/atom/issues/18228 so you can subscribe there for updates if you'd like.
If you need to close Atom, you should be able to quit it from Activity Monitor for now (if you have trouble, feel free to reach out on our message board).
Lastly, for future issues, please fill out the issue template, the information in the template is super helpful for us when triaging issues.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


r = sr.Recognizer()
with sr.Microphone() as source:
print("dinlemedeyem")
audio = r.listen(source)
metin = str(r.recognize_google(audio,language = "tr"))
print("dediyiniz soz:"+metin)

Describe the bug

How to reproduce or log data

Expected behavior

Additional context

Operating system: [e.g. Ubuntu 16.04]

You


add central npm "binary" to vendor dependencies

Current dependencies on/for this PR:

main

PR #3724   👈

This comment was auto-generated by Graphite.

super outdated


how to do with the input data for myObj tracking

can i make it track obj from my video clip ?
if that's all right , how to do that in a little bit of detail.
i'll be deeply grateful. :)

I need to do it as well... plz anyone help us.. Thanks

You should pass your folder path to the demo.py as a parameter. For example, I put my images into the "my_test" folder under the "data" directory. So I can run the demo.py like this:
python ../../tools/demo.py --base_path='../../data/my_test/images' --resume SiamMask_DAVIS.pth --config config_davis.json


ListDirectoryEntriesParameters doesn't accept "max" or "all" for per page parameter.

https://developers.ringcentral.com/api-reference/Internal-Contacts/listDirectoryEntries
Says that perPage accepts "all" or "max" as values for pages.

It is a known issue. Since the field is an integer, C# doesn't all string values.

I have created an internal ticket to change the data type of the API spec.

Issue resolved. perPage is a string now.


Add the tag button provided by "branch-buttons" to the compare page

Example URL: https://github.com/sindresorhus/refined-github/compare/<IP_ADDRESS>4...master
Often when comparing branches I want to make the base the latest tag. Using the dropdown - you cannot select tags, you need to type them. I find myself often opening the home page of the repo in a new tab and looking at the button provided by the "branch-buttons" for the latest tag.
It'd be awesome if the button would also set the "base" dropdown to the tag, but maybe that's a little too opinionated?
This is very similar to #1197 - I'm not sure if it's sufficiently different to have a separate issue 😅

Tags already kind of work this way:

Open the tags page
Click the “XX commits on master since this tag”

Alternatively, once #1197 is in:

Visit the latest tag
Then click compare
Then select the branch (the tag will be filled in)

Using the dropdown - you cannot select tags, you need to type them

Send them a feature request. This kinda annoys me too, but I rarely need it

Comparing a random branch is a little too opinionated to need a specific button.
If you need to do this, it's best to go the other way

Visit the latest tag (even from the repo root)
Then click compare
Then select the branch (the tag will be filled in)


I should be able to generate API Manifest from Kiota

Today, when running Kiota CLI to generate plugins, I can do the following:
kiota plugin add --pn sunoWithExtensions --openapi .\suno-openapi-with-extensions.yml --type apimanifest

However, the output generated is not an API Manifest.
When choosing --type apimanifest, the output file should be an API Manifest.

To clarify here according to the spec, what is expected is that since --output is optional and not specified in the above command, we should generate in the ./output folder a sunoWithExtensions-apimanfest.json
The apimanifest.json is currently already generated in the ./kiota folder.

According to the spec, in addition to the already generated apimanifest.json in the ./kiota folder, when choosing --type apimanifest, Kiota should generate a specific apimanifest to the given --open-api named {plugin-name}-apimanifest.json.
The apimanifest.json in the ./kiota folder will be a concatenated version of all clients and plugins and one may need a specific apimanifest for the plugin they are creating.
A scenario for that is, Semantic Kernel has a under development skill that accepts an API Manifest as input for creating a plugin. So one may want to create a specific API Manifest using Kiota to use in SK.


More documentation

This is a work in progress. This PR adds the gfx::doc::terminology module which only contains rustdoc documentation. The idea is to have a centralized place with information about what various gfx concepts map to in other APIs. I am not quite certain what the best way to present this information is. For example we could also have sections "OpenGL to gfx", "D3D11 to gfx", etc which would only link to the documentation of each term in gfx concisely (like: " - GL thing: [gfx thing](link to thing in the doc)".
What I am trying to address here is that for someone who does not know the internals of gfx, using this crate currently is a small exercise in reverse-engineering, especially when you know what you want to do (but not how it is called in gfx).
The other thing that I want to move towards, is for each module (or at least each crate) to have a large doc block with sections Overview and Examples that give some info about the general design and what the most important concepts are with link to teh relevant pieces. Rustoc is not good at making the important things stand out, so it has to be done somewhat manually in the crate/module doc.
Ultimately, gfx should strive to get to a documentation at the level of glium's which I took a lot of inspiration from when documenting lyon. I received some positive feedback from the work on lyon and I think that gfx could really use some doc that is structured similarly.
I don't think should land as is with all of the TODO's. Don't hesitate to review this while the work is in progress to help me fill the holes and rewrite/rearrange as needed.

It might be better to make the terminology page just a list of links to various areas of the documentation and move the extra explanation closer to their types in the doc.

I see that Factory has  *_raw methods for untyped buffer creation and *_u8 for textures. Do they mean different things?

@nical

Agreed. How would you name the high level api as opposed to the ll one?

Maybe "current core" as opposed to "low level core"? I don't see a good name :(

I see that Factory has *_raw methods for untyped buffer creation and *_u8 for textures. Do they mean different things?

_u8 has been added on top, it's not soundly matching the existing APIs. It still operates on typed handles, just expects byte slices of data.
@msiglreith

We need to find a new name for our Device struct then!

If you are referring to CoreLL Device, then it looks rather auxiliary, so the name doesn't matter much. Could be ActiveAdapter or something.

A few things changed with the first ll integration (sorry for the extra work!). Would you mind addressing the points I mentioned?

No problem, on it.


Inform the user that he has been logged out

Depends on https://github.com/datagovsg/beeline-server/issues/201

https://github.com/datagovsg/beeline-server-archive/issues/201
https://github.com/datagovsg/beeline-server-archive/pull/374

Is this still alive?

The PR was reverted in https://github.com/datagovsg/beeline-server-archive/pull/375 so we are not ready to do this yet


Is there anyway of running this as a subdomain on apache?

Checklist

[ ] I have read the FAQ
[ ] I have checked if this issue already exists (both open and closed issues)
[ ] I am using the most recent version of pogom from the master branch
[ ] If this is an installation issue, I am posting my OS, OS version, python version, pip version
[ ] I'm posting the complete log
[ ] I'm using a descriptive title for this issue

My Issue
Is there anyway of running this as a subdomain on apache?  Mywebsite.com/pogom for instance?
Thanks
Craig

Yes. I just Let my Fritz Box forward to my no-ip Adress. Pogom runs on my raspberry and is used by half my town in our local whatsapp group.

port 5000 is blocked on the server I'm using. Trying to pip it through 80 essentially, but there is a wordpress site already there.

@Craggles17 You should be able to run pogom on <IP_ADDRESS>:SOME_PORT and use ProxyPass in the VirtualHost configuration to run pogom on a subdomain.
@ctr26 you can specify a port by using the -P flag.


License missing

Assume it's something like MIT?
Not defined in the project or files.

MIT ! added


Higher level classes with jax (WIP)

Working on Integrator with jax, diffrax and equinox.

Pytree coefficient work reasonably well using equinox modules. It can be used with jit and grad without issue. But if does not pickle well. I used the changes from qutip/qutip#1816 to have coefficient not force complex output and allow sub project like this to define new coefficient types. (See ericgig/qutip/autodiff for a cleaned #1816).
Qobj and QobjEvo will be hard to make into Pytree, so I tried to make a simplified version JaxQobjEvo. It's immutable and with operations and support for callable(t, args) -> Qobj format removed, making it jax friendly is easy. All method are compiled and can be derived.
DiffraxIntegrator is in progress. I can derive the step function and pushing the derivation capacities to the Solver layer seems doable.

grad is working with solver:
import qutip_jax
import qutip as qt
from qutip.solver.sesolve import sesolve, SeSolver
import jax
@jax.jit
def fp(t, w):
    return jax.numpy.exp(1j * t * w)

@jax.jit
def fm(t, w):
    return jax.numpy.exp(-1j * t * w)

H = (
    qt.num(2)
    + qt.destroy(2) * qt.coefficient(fp, args={"w": 3.1415})
    + qt.create(2) * qt.coefficient(fm, args={"w": 3.1415})
).to("jax")

ket = qt.basis(2, 1)

solver = SeSolver(H, options={"method": "diffrax"})

def f(w, solver):
    result = solver.run(ket, [0, 1], e_ops=qt.num(2).to("jax"), args={"w":w})
    return result.expect[0][-1].real

jax.grad(f)(0.5, solver)

100.0%. Run time:   1.64s. Est. time left: 00:00:00:00
Total run time:   1.65s
CPU times: user 7.08 s, sys: 37.2 ms, total: 7.11 s
Wall time: 7.03 s

DeviceArray(-0.06224748, dtype=float64, weak_type=True)

The first call is slow, but following calls are fast:
def f(w, solver):
    result = solver.run(ket, [0, 1], e_ops=qt.num(2).to("jax"), args={"w":w})
    return result.expect[0][-1].real

%time jax.grad(f)(0.2, solver)

100.0%. Run time:   0.01s. Est. time left: 00:00:00:00
Total run time:   0.01s
CPU times: user 31.2 ms, sys: 4.15 ms, total: 35.4 ms
Wall time: 34.4 ms

DeviceArray(-0.09687763, dtype=float64, weak_type=True)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

127 of 280 (45.36%)  changed or added relevant lines in 7 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-18.3%) to 77.004%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/qutip_jax/jaxarray.py
15
24
62.5%

src/qutip_jax/qutip_trees.py
25
55
45.45%

src/qutip_jax/ode.py
38
83
45.78%

src/qutip_jax/qobjevo.py
44
113
38.94%

Files with Coverage Reduction
New Missed Lines
%

src/qutip_jax/jaxarray.py
1
82.86%

Totals

Change from base Build<PHONE_NUMBER>:
-18.3%

Covered Lines:
586

Relevant Lines:
761

💛  - Coveralls

Hi Eric, I'm trying out the code above. SeSolver is now named SESolver I guess, which is ok.
But for the expectation value in qutip.core there is a conversion to NumPy array
File .../qutip/solver/result.py:330, in <listcomp>(.0)
    328 @property
    329 def expect(self):
--> 330     return [np.array(e_op) for e_op in self.e_data.values()]

This was introduced in https://github.com/qutip/qutip/pull/2077

@BoxiLi expect as a list instead of array was one issues that often came back when migrating from v4 to v5.
e_data return the list and do not force the casting to numpy. It should work with jax for auto differentiation here.


Add publish_rate option for the diff_drive_controller

This PR add a publish_rate option for the diff_drive_controller in order to limit the publication on the /odom and /tf topics.
This solve request #274 and is intended for Foxy, Galactic and Rolling distributions.

It seems that IMUSensorBroadcasterTest.SensorName_Publish_Success test is failing but I do not know why, may I ask you what is the link between this test and my change?

@BenjaminHug8 actually scratch that, I'll touch it up quickly ;)

Thank you for your review @destogl and @bmagyar.
I have push another commit according to the comments of @destogl but used rclcpp::Duration instead of rclcpp::Time.
Tell me if it should be strictly a rclcpp::Time variable and / or if I can do anything else for this PR :)

@mergyfy backport galactic

@mergifyio backport foxy


feat: As a user, I want to be able to call any method on the PortalRegistry via the SDK

What does this PR do?
Related ticket
Fixes #204
Type of change

[ ] Chore
[ ] Bug fix
[x] New feature
[ ] Documentation update

Check list

[ ] Unit tests for any smart contract change
[x] Contracts and functions are documented

Codecov Report

Merging #313 (45d7f16) into dev (c877819) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #313   +/-   ##
=======================================
  Coverage   93.43%   93.43%
=======================================
  Files          12       12
  Lines         198      198
  Branches       46       46
=======================================
  Hits          185      185
  Misses          8        8
  Partials        5        5

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


DWARF: Disable GC around dl_iterate_phdr in freebsd

Fixes #10084. Prevents deadlock as shown in https://github.com/crystal-lang/crystal/issues/10084#issuecomment-761142066
I don't know if it's a good idea to disable it in every platform or in every bsd platform.

What about https://github.com/crystal-lang/crystal/issues/10084#issuecomment-761214840?

What about https://github.com/crystal-lang/crystal/issues/10084#issuecomment-761214840?

I think that would require iterating the structure twice, to count the required memory. Disabling the GC seems a less error prone approach to me.

I think that would require iterating the structure twice, to count the required memory. Disabling the GC seems a less error prone approach to me.

@straight-shoota mmm, no. There is no llvm issue here. We are preventing a deadlock in freebsd.

@straight-shoota mmm, no. There is no llvm issue here. We are preventing a deadlock in freebsd.

Okay, if that's all. Sry, I couldn't look into it more closely, just rememberd your initial unch it might be cause by LLVM.

Okay, if that's all. Sry, I couldn't look into it more closely, just rememberd your initial unch it might be cause by LLVM.


For root org console settings there is an unnecessary guest invitation API call getting invoked.

This API call is required only in sub org console settings.

Fixed with https://github.com/wso2/identity-apps/pull/5414


Multiple table series labels not working

The scrapeMultiple method does not correctly capture multiple series.

Closed; sadly my ticket submission hadn't gone through so the autoclose from commit didn't work.


Importing record associations that are related :through another model

I'm trying to import a Service that has_one :user, through: :pro, where :pro is a "role model" that holds information about that particular role a user may fulfill. I have the user's email to uniquely identify it, but I can't get the association to save.
I have:
A standard user model with an email field, which can have various role models attached:
class User < ActiveRecord::Base
  has_one :pro
  has_one :other_role_model
  has_one :some_other_role_model
  ...etc...
end

Various role models that exist for any user that fulfills that role, and holds data corresponding to that role:
class Pro < ActiveRecord::Base
  belongs_to :user
end

class OtherRoleModel < ActiveRecord::Base
  belongs_to :user
end

...etc...

And finally my Service model, which is only tied to users with a Pro role:
class Service < ActiveRecord::Base
  belongs_to :pro
  has_one :user, through: :pro
end

Now I want to import a service which belongs to a particular user via their pro role. The only unique identifier I have for that user/pro is their email, so I want to provide a csv with the format you listed above:
date,description,price,user
2016-02-12T03:21:55Z,Project<EMAIL_ADDRESS>
This will go through fine, but each service's Pro never actually gets set, which means their User is null too.
Looking through the code, it seems like import_single_association_data will try to  set service.user = user, given the service it's created and the user that it (successfully) finds. But that never sets the :through association, so service.pro is nil and of course after saving service.user becomes nil because it's accessed through service.pro.
I have a feeling I'm tripping over how ActiveRecord associations work here.
I tried setting the user's email field as a delegate in Pro:
class Pro < ActiveRecord::Base
  belongs_to :user
  delegate :email, to: :user
end

and then changing my import data to
date,description,price,pro
2016-02-12T03:21:55Z,Project<EMAIL_ADDRESS>
But unfortunately I'm unable to select email as the mapping field for pro, even with the above delegation, probably because mapping fields are pulled directly from AR attributes.
I imagine I'm going to just work around this in the before_import_save hook. After changing the import column name to "user_email", I can write:
class Service < ActiveRecord::Base
  belongs_to :pro
  has_one :user, through: :pro

  def before_import_save(record)
    if (email = record[:user_email]) and (user = User.find_by_email(email))
      self.pro = user.pro
    end
  end
end

and it should work. But I'm wondering if there's a cleaner approach that I'm missing.

Confirmed, my final suggested approach worked. Still curious if there's a more general approach.

You got it: for more complex cases you have to use the import hook.
On Feb 12, 2016 12:30 AM, "zrisher"<EMAIL_ADDRESS>wrote:

Confirmed, my final suggested approach worked. Still curious if there's a
more general approach.
—
Reply to this email directly or view it on GitHub
https://github.com/stephskardal/rails_admin_import/issues/51#issuecomment-183185396
.

Rgr that, will include in docs PR per #50


rubocops/cask: Enforce the use of on_{system} blocks

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Sort of related to #14898.
As discussed in https://github.com/Homebrew/brew/pull/14976#issuecomment-1474544569 and further comments, this is needed because in order to enforce the order of on_{arch,system} blocks we need to have everything consistently within one of those blocks.
We previously allowed overrides where the top-level version stanza would be the default, unless on an OS that had an on_system block with a version specified. But this breaks down when we try to order the on_system blocks because if a url at the top-level has a version interpolated in it, then the version stanza needs to be above the url stanza. But it could be that version is OS-specific.
Let's stop allowing overrides and require that everything be in an on_system block. This will make it easier to enforce the order of on_system blocks in a future PR (#14976).

There's a TODO here for to what extent we want "everything" to be in an on_system block - I think it should only be url, version, sha256? Not name, appcast, etc since they're generic. Opinions?

Review period will end on 2023-03-21 at 00:00:00 UTC.

Does this work for cases with no on_{system} blocks at all?

Now it does.

And in cases where the only difference is e.g. the url, we also don't want to force it for e.g. version, right?

I can't get my head around this right now. Hopeful for a 💡🧠 soon!

I can't get my head around this right now. Hopeful for a 💡🧠 soon!

We need to first collect all stanzas which are present in on_* blocks, then check if those are also present at the top level.
So for
cask "foo" do
  version "1.2.3"
  sha256 "aaa"
  url "https://brew.sh/foo-2.3.4.dmg"

  on_big_sur :or_older do
    sha256 "bbb"
    url "https://brew.sh/legacy/foo-2.3.4.dmg"
  end
end

we collect the set [:sha256, :url] from the on_* blocks, so we need to flag the top-level sha256 and url stanzas.

OK, running against actual Casks, this reports 4184 files inspected, 89 offenses detected.

I’ll do a PR this week to fix up the Cask failures manually and see how bad/confusing it is.
It might be a bit tedious to go through and correct all of those. Maybe it would be better for users if we could somehow specify what the on_* block syntax they should use is, particularly the macOS version? But that’s almost an autocorrect then and that seems complicated.

In this case the top-level version should be in an on_arm block though, so this cop wouldn't catch it.
How would we handle
cask "foo" do
  version "1.2.3"

  on_intel do
    on_monterey :or_older do
      version "1.0.0"
    end
  end
end

though? Duplicate version in on_arm and in on_intel { on_ventura :or_newer }?

I guess my example is more likely this
cask "foo" do
  on_monterey :or_older do
    version "1.0.0"

    depends_on arch: :intel
  end
  on_ventura :or_newer do
    version "1.2.3"
  end
end

I'd say let's forget about the edge case for now, since when mixing on_arch and on_system we would also have to take depends_on arch: into account.

Yeah, I mean that's an edge case that is definitely worse-looking when we don't allow the overrides.

I am so confused by these edge cases and what we're tracking or not. 😆

There's either a 🐛 or an oversight or this behaviour for arch is actually intentional?

Heh, it is a 🐛, the "stanza names" array looks like [:version, :sha256, :url, :no_dots, :version, :version, :sha256, :url, :arch] for that cask. But arch is a variable. Some more work to do here!

Review period ended.

OK, with the bug fixes I've made, this detects in "" in Cask right now. I think this might be ready, pending a PR in Cask that I'll do at some point this week to show the example fixes. And we still haven't decided if we should attempt some kind of autocorrect? I have to say flipping between the Wikipedia page for macOS versions to get the codenames to put them in the right :or_newer, :or_older order is quite tedious. But we should only have to do this mass correction once?

There's another bug here with some real casks, the handling of "skip stanzas not already in on_* blocks is bugged. For Cask sip, as a random example:
  on_mojave :or_newer do
    version "2.7.1"
    sha256 "074c7a1b5e4ebfabdc43b6583a96da9dfaf02f1a93a468b616dc14833ea1705d"

    livecheck do
      url "https://sipapp.io/updates/"
      regex(%r{href=.*?/sip[._-]v?(\d+(?:\.\d+)*)\.dmg}i)
    end
  end

  url "https://sipapp.fra1.digitaloceanspaces.com/updates/v#{version.major}/sip-#{version}.dmg",
      verified: "sipapp.fra1.digitaloceanspaces.com/updates/"

Since url is in on_mojave the top-level url stanza detected as in the block even though it's a livecheck URL not a "standard" URL for the download.

Since url is in on_mojave the top-level url stanza is detected as in the block even though it's a livecheck URL not a "standard" URL for the download.

Judging from this and https://github.com/Homebrew/brew/pull/15013/files#r1142791224, the toplevel_stanzas method seems to be bugged and returns more than just top-level stanzas. I haven't looked into whether that's actually the case yet though.

https://github.com/Homebrew/brew/blob/ffa7ee01126c3ae59c80e684550702ccaa5aeba9/Library/Homebrew/rubocops/cask/ast/stanza.rb#L56
toplevel_stanza? seems to check two levels up for a cask block, no idea why.

Okay, so I found one problem with toplevel_stanzas so far. For the following
cask do
  url
end

the AST looks like cask > url, so cask is the parent node of url.
For
cask do
  url
  homepage
end

the AST is actually cask > block > url, so cask is the grandparent node of url.

I don't understand how this can be?

If there is only one stanza, there is no need to group it.
In the AST it's similar to how an if statement works:
stmt1 if cond

doesn't need a block, while
if cond
  stmt1
  stmt2
end

does.

Rebased on master after #15028.

There's something funky now with the variable interpolation detection, but this is very close to being done now hopefully!

OK, I think we're there (_n_th time lucky - it's got to be more than 3 by now)... 🙏🏻 The main Cask repo reports 4183 files inspected, 35 offenses detected which is significantly less than there were in previous days when I found out the brokenness, so I think the main 🐛 are squashed.

OK, there's a PR to fix the Homebrew/homebrew-cask problems at https://github.com/Homebrew/homebrew-cask/pull/143646. Thanks to that exercise I caught a bunch more edge cases! This is now, I think, ready for real review!

As seen in https://github.com/Homebrew/homebrew-cask-versions/pull/16257, the cop needs to differentiate between stanzas which can be overridden (e.g. url) and those which cannot (e.g. app, binary).

@reitermarkus Thanks, I'm learning lots about Casks! Is there a list somewhere of parts that are overridable and those that are not?

I don't think we have a list, I think it's implemented for each stanza individually.


Use a custom Jasmine reporter to actually show spec names

Our CI builds have been really flaky again recently, and it's difficult to see why because a renderer crash prevents anything but a bunch of dots from showing up in test output. I'm replacing our Jasmine reporter with one that displays the full name of each spec before it begins so that we can diagnose these issues more rapidly.
Remaining work

[x] Do the same for the main process Mocha tests
[x] Make the new reporters opt-in

Oh, right. We already are doing this for the Mocha tests:
   . AtomApplication waits until all the windows have saved their state before quitting: 28716ms

Merging despite failures because... the failures are what this is supposed to help us narrow down 🙈


Getting "Loading..."

Used the "I hate NPM" method, and I see my information at the top, but the posts do not load (just get the "Loading..." message). What could it be?

Weird, can you share the top lines of the html file?

Found the issue. Cisco Umbrella is blocking the  relays. I will have to wait for the 24 hours penalty for them to become available. Sorry for the noise, and thanks!

Follow up on this. For Oracolo to work, the notes need to be kind:30023. If there aren't any of that kind, it will not work.

Yes, I confirm. Oracolo is a blog and so currently it only uses the long format. The short format could be integrate but it has a lot of pitfalls in this context, for example it doesn't have a title, end often short notes are not so meaningful, so they should be filtered (by lenght? tags? idk).
I already have a working version, where I use the date as title:

But I don't like it very much.
I need to think more about this uses case.

Do you have that version publicly available somewhere? I would love to play with it! :-)

https://github.com/dtonon/oracolo/tree/short-notes


[7.1.0] Please ignore. This is for testing.

Forked from #473

Cherry-picked in https://github.com/bazelbuild/bazel/pull/21534


Resolve JS files referenced by TypeScript declaration files if possible

Context
First of all, thanks for developing this tool!
I am looking into using this tool at work and am running into a false positive scenario where JavaScript files which are referenced by TypeScript declaration files (.d.ts) are showing up as unused.
A summary of the issue looks like this:
// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "src"
  }
}

// This is index.ts
// This imports from './utils/fn.js' which has a corresponding './utils/fn.d.ts'
// but Knip is reporting './utils/fn.js' as unused
import { g } from 'utils/fn';

I have included in the PR here test & fixtures to describe the issue above.
I believe this has something to do with this part of the code in resolveModuleNames:
https://github.com/webpro/knip/blob/0b02923352940b3129ea8bb411b46e5804b2ce0a/packages/knip/src/typescript/resolveModuleNames.ts#L62-L71
Approach
Create a new function jsMatchingDeclarationFileExists where given a TypeScript declaration file (.d.ts), it checks if there exists a file by replacing the extension to .js and returns the module.
Note: The same behaviour is done for .d.mts to .mjs and .d.cts to .cjs but I am not sure if this is necessary.
This function is used to augment the existing behaviour in resolveModuleNames as follows:
https://github.com/webpro/knip/blob/b521b156c7c805c62e17643172634b52e6081def/packages/knip/src/typescript/resolveModuleNames.ts#L86-L101

Thanks @junyi! Feel free to open a pull request. Looks like you know where to look for 👍 Would be awesome!
One note: please delete any files that are not relevant to the issue.

When can we expect this merged and released into knip? I'm having the same issue and for the time being I've mitigated this by adding the javascript file to the configuration ignore list.

Hi @webpro, thanks for the advice! I have updated the PR to include a fix for the module resolution and removed unnecessary files from the tests.

Thanks for the fix! Interestingly, knip reports this issue in its own repo:
Unused files (1)
packages/eslint-config/index.d.ts

I'll dig some deeper when I have time.

OK I think I've figured out why it didn't pass in the Knip repo itself, and I've also added the other DTS extensions during TS init.
@junyi Could you please format the changes (npm run format from root or workspace)?

The changes "broke" tests, they're fixed. If you could wrap it up when/however you like (so you're the contributor of it all) I'm happy to merge!

:rocket: This pull request is included in v5.0.4. See Release 5.0.4 for release notes.

This doesn't seem to cover the case where the JavaScript file's extension is .jsx.

That's right. It also doesn't cover entry files in certain cases. Feel free to open a PR!

This doesn't seem to cover the case where the JavaScript file's extension is .jsx.

This should be OK in the latest canary (v5.1.3-canary.0)


Fixed casting result in float.xml

The float-string parsing result in the documentation was inaccurate. 1e-3 is written as 0.001 when decimal.

Thank you!


Version 1.1.0 - Dist folder not published to NPM

It seems the dist folder specified in package.json is not published to NPM in version 1.1.0 see https://www.npmjs.com/package/next-merge-props/v/1.1.0?activeTab=code

Thank you @gurkerl83! Bad changeset config when migrating away from tsdx. Resolved in #22. Let me know if you notice anything else!

It is working, thx!


Polkadot-address wrong

I tried to generate polkadot address with Swift language, but the generated address is different from the address which is generated by ImToken, I'm not sure where I missed. The code snippet is below:
let wallet = HDWallet.init(mnemonic: mnemonic, passphrase: "")
let polkadotAddress = wallet.getAddressForCoin(coin: CoinType.polkadot)

Thanks!

This is a known issue, it uses different derivation scheme, we might enable private key importing for Trust app later

Thanks for your help. So currently I can't generate the same polkadot address as ImToken by using trustWalletCore, correct?


chroot: failed to run command ‘bash’: Exec format error

root@volumio:~/spotify-connect-web-chroot# ./spotify-connect-web.sh --username a --password b
chroot: failed to run command `bash': No such file or directory

What OS/device are you using?

https://volumio.org on a Raspberry Pi.

Do you know if the OS is softfloat or hardfloat? and RPi 1 or RPi 2? Also, which libspotify_embedded are you using?

It's probably the Rocki one because he uses the pre-built chroot script.

I have the same error. My hardware is RPI2 with Archlinux.
To make it work I have to run the script line by line. Entering the chroot environment. and manually run the python.
In my chroot there is no bash.

Okay, I changed the script to use the full path (/bin/bash). Should work now.
You need to change the script accordingly or just redownload it:
curl -O http://spotify-connect-web.s3-website.eu-central-1.amazonaws.com/spotify-connect-web.sh

Thanks!!!! Now its Ok 😉

Nope, still getting the same error. On an Ubuntu/Xeon system this time.

@klokop spotify-connect-web uses a spotify library from ARM-based receivers and thus works only on systems running the armel/armhf architecture, e.g. Raspberry Pi. (We should probably document that fact better.)
You could try librespot on your x86 machine instead.

I figured as much. Will try on Pi. thx.

I'm gonna close this for now, feel free to re-open if you're still having problems

Nope, is fine to close. It's all working now. Thanks!

I just ran into the same issue when trying to install this on a debian x64 system.
So can this be resolved by just exchanging a binary within the chroot at some place or does it need more changes than that?

@1337sup3rh4x0r This software depends on a spotify library binary which can only be found on ARM-based receiver devices. Thus it is not possible to run this on a x86/x64 system.
You should probably try out librespot instead.

Thank you for clarifying. So does the binary within spotify-connect-web need to be replaced with librespot or does librespot offer Spotify connect features and replaces spotify-connect-web as a whole?

It replaces it as a whole. There already is a sample program which acts as a spotify connect receiver.


Cannot access services of pods located in a different node after applying NetworkPolicies

I have a K3S cluster with two control-plane nodes which is using Calico as the cluster CNI.
I am installing K3S in my nodes using the K3S installation script. I am disabling Flannel and the default Network Policy that comes by default in K3S, and setting the <IP_ADDRESS>/16 CIDR range (my network uses a 10.x.x.x CIDR range, so no overlapping should exist), following the Calico docs on K3S:
# K3S installation flags
K3S_EXEC="--disable=traefik \
  --secrets-encryption \
  --cluster-init \
  --flannel-backend=none \
  --disable-network-policy \
  --cluster-cidr=<IP_ADDRESS>/16 \
  --selinux"
# Install K3S
INSTALL_K3S_SKIP_DOWNLOAD=true \
	INSTALL_K3S_EXEC="$K3S_EXEC" \
	INSTALL_K3S_SYMLINK=force \
	K3S_TOKEN="<master-token>" \
	install.sh

After installing K3S, I'm deploying Calico into the cluster, following the Calico documentation. I am also enabling Wireguard in the Calico deployment to encrypt the pod traffic:
# Install Calico CRDs
kubectl create -f tigera-operator.yaml"
# Install Calico on the cluster
kubectl create -f custom-resources.yaml"
# Enable Wireguard in Calico deployment
calicoctl patch Felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true}}'

These are the contents of the custom-resources.yaml file:
# This section includes base Calico installation configuration.
# For more information, see: https://docs.projectcalico.org/v3.19/reference/installation/api#operator.tigera.io/v1.Installation
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  # Configures Calico networking.
  calicoNetwork:
    containerIPForwarding: Enabled
    # Note: The ipPools section cannot be modified post-install.
    ipPools:
    - blockSize: 26
      cidr: <IP_ADDRESS>/16
      encapsulation: VXLANCrossSubnet
      natOutgoing: Enabled
      nodeSelector: all()

After installing Calico, I install several components into my cluster: Grafana, Prometheus, Longhorn, Istio, etc. Each component is installed in an specific namespace.
Before installing the components, I create several Calico Network Policies to restrict the access to those components. I first enable the default deny policy, and then I add several allow policies to only allow certain traffic.
This is the default deny policy applied into the cluster, following the default deny policy documentation (I can post the rest of the NetworkPolicies if that can help debugging the issue):
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-all-policy
spec:
  order: 1
  namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "tigera-operator"}
  types:
    - Ingress
    - Egress
  egress:
    # allow all namespaces to communicate to DNS pods
    - action: Allow
      protocol: UDP
      destination:
        selector: 'k8s-app == "kube-dns"'
        ports:
          - 53

After installing all these components into the first control-plane node, all is working as expected. All the accesses allowed/denied by Network Policies are working fine, and the components can be deployed correctly in the cluster.
The problem I have is when adding a second control-plane node to the existing cluster. For doing that, I execute the K3S install script in the new node:
# K3S installation flags
K3S_EXEC="--disable=traefik \
  --secrets-encryption \
  --cluster-init \
  --flannel-backend=none \
  --disable-network-policy \
  --cluster-cidr=<IP_ADDRESS>/16 \
  --selinux \
  --server=https://<master-node-1-ip>:6443"
# Install K3S
INSTALL_K3S_SKIP_DOWNLOAD=true \
	INSTALL_K3S_EXEC="$K3S_EXEC" \
	INSTALL_K3S_SYMLINK=force \
	K3S_TOKEN="<master-token>" \
	install.sh

The second node is successfully added into the cluster, and some new DaemonSet pods start to create in the new node, as expected.
Some of the new Daemonset pods fail to reach some of the Kubernetes services of pods that are running in the first control-plane node.
For example, the Grafana ClusterIP service can be accessed from the first control-plane node (where the Grafana pod is located), but it cannot be accessed from the second control-plane.
<control-plane-node-1> $ kubectl get svc -A
NAMESPACE                NAME                                       TYPE           CLUSTER-IP      EXTERNAL-IP               PORT(S)                                      AGE
<grafana-ns>             grafana                                    ClusterIP      <IP_ADDRESS>     <none>                    80/TCP                                       5h37m

<control-plane-node-1> $ curl -vvv http://<IP_ADDRESS>
* About to connect() to <IP_ADDRESS> port 80 (#0)
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: <IP_ADDRESS>
> Accept: */*
>
< HTTP/1.1 302 Found
[...]
<
Found.

* Connection #0 to host <IP_ADDRESS> left intact

<control-plane-node-2> $ curl -vvv http://<IP_ADDRESS>
* About to connect() to <IP_ADDRESS> port 80 (#0)
*   Trying <IP_ADDRESS>...

I have tried to debug which component can be failing on this scenario:

I tried with an installation without Wireguard enabled, but the same error happens
I then tried to not install any Network Policy in the cluster (and Wireguard enabled), and after that, the second node could actually reach the services deployed in the first node.

So I'm starting to think that maybe it has to do with the set of Network Policies that I'm creating in the cluster.
This is the NetworkPolicy for the namespace where Grafana is deployed. In this NetworkPolicy, I am only allowing (in theory) the Grafana namespace to communicate with the Prometheus namespace (so I can visualize metrics), and the Istio namespace (to expose Grafana outside of the cluster):
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: grafana-allow-access-policy
  namespace: <grafana-namespace>
spec:
  selector: all()
  order: 9
  types:
  - Egress
  - Ingress
  egress:
  - action: Allow
    source:
      namespaceSelector: (projectcalico.org/name == '<grafana-namespace>' || projectcalico.org/name == '<istio-namespace>' || projectcalico.org/name == '<prometheus-namespace>')
  ingress:
  - action: Allow
    source:
      namespaceSelector: (projectcalico.org/name == '<grafana-namespace>' || projectcalico.org/name == '<istio-namespace>' || projectcalico.org/name == '<prometheus-namespace>')

Is there something obvious that I'm missing here about Network Policies?
Is there any extra configuration that I need to add intothe Calico installation (or to the Network Policy objects) to enable the traffic between the different nodes of the cluster?
Do I need to include or fix any of the fields in the NetworkPolicy spec?
I have been stuck with this problems for a couple of days, and I still don't know how to solve it....
I am not seeing any significant error on the Calico pods also. I can post the content of iptables if that is needed for further debugging...
FYI:

NetworkManager has been configured to not interfere with the iptables in both nodes, and firewalld has been disabled in both nodes, following the Calico requirements
Both nodes are Virtual Machines created on a VMware vSphere infrastructure.
I'm trying to change the previous CNI that I was using in my K3S cluster (Flannel + Wireguard), and use Calico + Wireguard instead (so I can create NetworkPolicies in my cluster). The Grafana access scenario described before was working successfully when using Flannel + Wireguard, but it is not working when using Calico + Wireguard.

Expected Behavior
The second node should be able to access the services of pods deployed in the first node
Current Behavior
The second node does not reach services of pods deployed in the first node
Your Environment

Calico version:
** CALICO_VERSION = v3.19.1
** TIGERA_OPERATOR_VERSION = v1.17.4
Orchestrator version (e.g. kubernetes, mesos, rkt): K3S v1.20.4+k3s1
Operating System and version: CentOS Linux release 7.9.2009 (Core)
Link to your project (optional):

Thanks for the detailed report! This helps a lot to diagnose what is going on.

 $ curl -vvv http://<IP_ADDRESS>

Just wanted to confirm - it looks like the curl command you are trying is being run from the second node, rather than a pod on the other node. Are you sure that your policy allows traffic from the node's IP?
From what it sounds like, your policy will not allow traffic from the nodes themselves, rather only allow from pods in the selected namespaces. This might just be a matter of your policy not matching your expectation!
The reason it works from node-1 is because Calico allows a local node to access pods running on that node, since Kubernetes needs that behavior in order to properly implement pod liveness checking.

@aalcaraz97 ^

Thanks for the answer @caseydavenport!
I think it is definitely a NetworkPolicy issue that is only allowing traffic from within the specified namespace, and blocking the traffic from the other nodes.
I found the following Calico documentation on External IP and Networks rules.
I wanted to do something similar, but instead of allowing all ingress traffic and denying explicitly the CIDRs of the IPs, I want to do the opposite: only allow ingress traffic from certain CIDRs.
For simplicity in the testing, I removed the NetworkPolicies associated to the components (Grafana, Istio, etc.) from the cluster.
Without any NetworkPolicy applied, I tested the curl command to the Grafana ClusterIP Service from both nodes of the cluster, and both nodes are able to reach it (which is expected).
Then, I applied the "deny all" policy described above, and the Grafana Service was not available from the second node (which is also expected).
I wanted to test the GlobalNetworkSet approach, so I created the following resources in the cluster: a GlobalNetworkSet including the two IPs of the nodes (let's name the IP of the nodes <IP_ADDRESS> for node1, and <IP_ADDRESS> for node2), and a GlobalNetworkPolicy allowing the traffic from the CIDRs in the GlobalNetworkSet:

global-network-set.yaml:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkSet
metadata:
  name: network-set-node-allow
  labels:
    IP-allow-list: true
spec:
  nets:
  - <IP_ADDRESS>/32
  - <IP_ADDRESS>/32

global-network-policy-allow-nodes.yaml:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: global-node-allow
spec:
  selector: all()
  order: 2
  types:
  - Ingress
  ingress:
  - action: Allow
    source:
      selector: IP-allow-list == 'true' && !has(projectcalico.org/namespace)

I tested the curl command to the Grafana ClusterIP Service after applying the GlobalNetworkSet and the GlobalNetworkPolicy:

From the node where Grafana pod is deployed, the service is still reachable.
But from the second node in the cluster, the service is still unreachable:

<control-plane-node-2> $ curl -vvv http://<IP_ADDRESS>
* About to connect() to <IP_ADDRESS> port 80 (#0)
*   Trying <IP_ADDRESS>...

I also have tried to add the following:
 ingress:
  - action: Allow
    source:
      selector: IP-allow-list == 'true' && !has(projectcalico.org/namespace)

into the spec of my "deny all" policy, but the service is still unreachable from the second node.
I wanted to perform these rules to allow certain IPs in a GlobalNetworkPolicy, in order to avoid having to manually add a rule for each new node (that is, a new CIDR) to all the already created NetworkPolicies in the cluster.
I have seen some documentation on how to protect Kubernetes hosts, which includes defining HostEndpoints and applying a GlobalNetworkPolicy to them to allow/deny traffic. I haven't tried that yet, but first I wanted to make sure that I am going to the right way for solving my issue, or if it is much more simpler than I think it is.

let's name the IP of the nodes <IP_ADDRESS> for node1, and <IP_ADDRESS> for node2), and a GlobalNetworkPolicy allowing the traffic from the CIDRs in the GlobalNetworkSet:

Are you sure those are the IP addresses being used for communication from Node2 -> Pods on node 1?
If you have IPIP / VXLAN encap enabled in Calico, there is likely another IP address you need to add to your NetworkSet - namely, the tunnel address on the tunl0 (ipip) or vxlan.calico (vxlan) devices.

The doc on protecting kubernetes hosts https://docs.projectcalico.org/security/kubernetes-nodes also talks about turning on a feature which will automatically create Host Endpoints for them, which can be thought of as a way of automating updates of the IPs of the nodes (particularly handy if you're adding/deleting nodes later).

Thanks for the answer @caseydavenport!
I think it is definitely a NetworkPolicy issue that is only allowing traffic from within the specified namespace, and blocking the traffic from the other nodes.
I found the following Calico documentation on External IP and Networks rules.
I wanted to do something similar, but instead of allowing all ingress traffic and denying explicitly the CIDRs of the IPs, I want to do the opposite: only allow ingress traffic from certain CIDRs.
For simplicity in the testing, I removed the NetworkPolicies associated to the components (Grafana, Istio, etc.) from the cluster.
Without any NetworkPolicy applied, I tested the curl command to the Grafana ClusterIP Service from both nodes of the cluster, and both nodes are able to reach it (which is expected).
Then, I applied the "deny all" policy described above, and the Grafana Service was not available from the second node (which is also expected).
I wanted to test the GlobalNetworkSet approach, so I created the following resources in the cluster: a GlobalNetworkSet including the two IPs of the nodes (let's name the IP of the nodes <IP_ADDRESS> for node1, and <IP_ADDRESS> for node2), and a GlobalNetworkPolicy allowing the traffic from the CIDRs in the GlobalNetworkSet:

global-network-set.yaml:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkSet
metadata:
  name: network-set-node-allow
  labels:
    IP-allow-list: true
spec:
  nets:
  - <IP_ADDRESS>/32
  - <IP_ADDRESS>/32

global-network-policy-allow-nodes.yaml:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: global-node-allow
spec:
  selector: all()
  order: 2
  types:
  - Ingress
  ingress:
  - action: Allow
    source:
      selector: IP-allow-list == 'true' && !has(projectcalico.org/namespace)

I tested the curl command to the Grafana ClusterIP Service after applying the GlobalNetworkSet and the GlobalNetworkPolicy:

From the node where Grafana pod is deployed, the service is still reachable.
But from the second node in the cluster, the service is still unreachable:

<control-plane-node-2> $ curl -vvv http://<IP_ADDRESS>
* About to connect() to <IP_ADDRESS> port 80 (#0)
*   Trying <IP_ADDRESS>...

I also have tried to add the following:
 ingress:
  - action: Allow
    source:
      selector: IP-allow-list == 'true' && !has(projectcalico.org/namespace)

into the spec of my "deny all" policy, but the service is still unreachable from the second node.
I wanted to perform these rules to allow certain IPs in a GlobalNetworkPolicy, in order to avoid having to manually add a rule for each new node (that is, a new CIDR) to all the already created NetworkPolicies in the cluster.
I have seen some documentation on how to protect Kubernetes hosts, which includes defining HostEndpoints and applying a GlobalNetworkPolicy to them to allow/deny traffic. I haven't tried that yet, but first I wanted to make sure that I am going to the right way for solving my issue, or if it is much more simpler than I think it is.

hello aalcaraz97
we are facing similar issue where namespace based policy is working fine as long as the pods are in same nodes
did you find any solution to make calico policies to work across nodes ?

I'm facing a similar situation. The following policy doesn't let pods in the same namespace talk to each other, if they are on different nodes :
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-web-policy
  namespace: ybontap-tynsoe-org
spec:
  podSelector: {}
  ingress:
    - from:
      - podSelector: {}
  egress:
    - to:
      - podSelector: {}
    - to:
      - namespaceSelector: {}
        podSelector:
          matchLabels:
            k8s-app: kube-dns
      ports:
      - port: 53
        protocol: UDP

On the destination host with tcpdump, I see packets being SNAT'd to the VXLAN's interface IP, not sure that's expected or part of the issue.
@laptimus do you remember what were those SNAT rules and where they came from ?

I have the same problem....i'm using RKE... @laptimus  and @ybizeul could you tell me in detail what shoud i do?
my ippool config:
ipPools:
- blockSize: 26
cidr: <IP_ADDRESS>/16
encapsulation: IPIP
natOutgoing: "Enabled"
nodeSelector: all()


Client error: 403 - Docker install failed?

GuzzleHttp \ Exception \ ClientException (403)
Client error: 403
The install says something about keys. I run the following:
$ docker exec -it cachet_cachet_1 php artisan key:generate
$ docker exec -it cachet_cachet_1 php artisan config:cache
and it gives the error at the top. This is after completely blowing it away and trying again from scratch due to various database related errors that I could never solve.
How do I fix this?

The way this is running/built:
cd /usr/src
git clone https://github.com/cachethq/Cachet.git
cd Cachet
docker-compose build
docker-compose up
$ docker exec -it cachet_cachet_1 php artisan migrate --force
$ docker exec -it cachet_cachet_1 php artisan key:generate
$ docker exec -it cachet_cachet_1 php artisan config:cache
What am I missing?

It looks like this is because of the API hit limit.
It would be nice if someone would put an error message in that says, "Due to our design choices, the software cannot install correctly more than one or two times in X number of hours. ERROR" It would save us some searching..

This will be fixed by using git if cannot download dist in coming 1.2 version.

1.2 now has separated Docker support. Please see https://docs.cachethq.io/docs/get-started-with-docker


Export information associated with per-image detections to geospatial projections

Often, pre-image object detectors predict information such as the class of the object and an associated confidence. This data, as well as the image that the detection was produced from when these detections were projected into geospatial coordinates. This PR merges this data back in to the geospatial projections.

@rowanoaktree this should address your issue

One very minor comment about a typo, otherwise looks good to me!


Blender file NLA track import glitches, no blend shapes

Tested versions

Tested in Godot v4.3.stable with Blender 4.2.1

System information
Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA RTX A2000 (NVIDIA; <IP_ADDRESS>86) - Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (8 Threads)
Issue description
Created a mesh, rigged with rigify, created animation, creaded blend shapes/shape keys, added blend file to godot project.

Animation imported and shows up and plays but the mesh is deforming not like in blender
Blend shapes are not accessible.

Did the same but exported to glb file with NLA tracks, added to godot project:

Still same problem with animation where mesh deforming not like it is in blender.
Blend shapes are accessible.

Godot:

https://streamable.com/iao59w
Blender:

https://streamable.com/5rcb9i
Steps to reproduce
Create mesh in blender, rigify, create animation, create blend shapes, import blend file to godot project.
Minimal reproduction project (MRP)
murger-43.zip

Hey, I looked at your issue and found that the same deformation errors appear when I import your gltf file into Blender and https://gltf-viewer.donmccurdy.com/. I believe the problem is to do with your export.
GLTF viewer:

Reimporting GLTF into Blender:

OK but what about the blendshapes not being able to be edited when using blend file import in godot?

I am having trouble reproducing your bug on my system. All the blend shapes appear without any problem after I open up the project. I will try on Windows tomorrow.
My system:  Pop!_OS 22.04 LTS - Godot 4.3 stable -  Vulkan (Forward+) - dedicated NVIDIA GeForce GT 1030 (nvidia; 555.58.02) - Intel® Core™ i7-3770 CPU @ 3.40GHz ( 8 Threads ) - Blender 4.2(Flatpak)

the blendshapes not appearing for the blenderfile. They appear only if you import gltf/glb file.. atleast for me..

I can confirm this bug on my other machine .  Pop!_OS 22.04 LTS - Godot 4.3 stable standalone and Godot Steam - Vulkan (Forward+) - dedicated AMD Radeon RX 6400 - Intel® Core™ i7-10700 CPU @ 2.90GHz (168 Threads )

I can confirm this bug on my other machine . Pop!_OS 22.04 LTS - Godot 4.3 stable standalone and Godot Steam - Vulkan (Forward+) - dedicated AMD Radeon RX 6400 - Intel® Core™ i7-10700 CPU @ 2.90GHz (16 Threads )

so sometimes it works and sometimes it doesnt (the blend shapes)


Allow label for requestor in a proof to be configurable

Currently just displays VCAuthN Agent name in the wallet when you scan a proof. The OOB invitation sets that as the label, or can be provided with a my_label field in the body.

https://github.com/bcgov/vc-authn-oidc/pull/627


Replace minikube with standalone deployment for Ceph Tests

Explain the changes
This PR replaces minikube with standalone deployment (inside a container). The expectations are:

Have more reliable runs.
Runs should take lesser time.

This is done by creating a standalone_deploy.sh script which can be used locally as well to spin up a fully functioning NooBaa.
Testing Instructions:

Run make test-cephs3 or CONTAINER_PLATFORM=linux/arm64 make test-cephs3 if on mac.

[ ] Doc added/updated
[ ] Tests added

@utkarsh-pro
I think we should do that for all the jobs.

@liranmauda, I think we are using minikube only in sanity tests now, right? Or am I missing something?

@utkarsh-pro
I think we should do that for all the jobs.

@liranmauda, I think we are using minikube only in sanity tests now, right? Or am I missing something?

I think that you are correct. It will be grat to change that also


Update inscriptions.json

btc domain inscriptions ending on .btc
@MillHaus33 are we listing these, if so, does it require a collection with inscriptions.json?

Contributor

Are you suggesting that we integrate an auto-update feature into your project? We are prepared to develop the necessary logic to address this issue and would greatly appreciate your support. This feature would significantly enhance our users' experience.
BTW, this pull should be closed since #1806 is merged

Closed it now since #1806


Allow e: unknown in catch arguments

In addition, allow an explicit any; anything else throws an error.
Also adjust and reorganize existing tests.
Fixes #36775.

FYI, here's the eslint rule that reminds you to type catch (e: unknown)
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-implicit-any-catch.md

And now I wonder, is it possible yet to opt into this behavior by default?

...we might consider a new --strict mode flag in the future so that users can opt in to this behavior.
~ Announcing TS 4.0

HOME
SEND
ASSETS
TOOLS
SETTINGS
MENU
HELP
Back arrowBack
Export
Your MyCrypto settings file is ready.
{"version":"v2.0.0","mtime":1712221809928,"accounts":{"f535254d-4740-5b81-a333-b2440d785991":{"uuid":"f535254d-4740-5b81-a333-b2440d785991","label":"Mi acount","address":"0xD132973EaEbBd6d7ca7b88e9170f2CCA058de430","networkId":"Ethereum","assets":[{"uuid":"74cf0f2b-414c-53b7-bd2a-04f78b05aaad","balance":"146525882781026478"},{"uuid":"1c77b322-a88c-57cc-b956-78c2bc17c360","balance":"640320365083042853819"},{"uuid":"281fa3af-8e6d-5f33-900c-33a480035475","balance":"4751273381063224128"},{"uuid":"2db84be6-32ae-50e3-81b8-59694bef84a1","balance":"3280290031428302461368"},{"uuid":"42362ed0-333d-5123-ae7d-29b79178769d","balance":"101602612229651807859"},{"uuid":"52f6407e-e3de-50f6-a26a-23702e0efc16","balance":"159423036594807358915"},{"uuid":"c737fec0-a9e9-5841-b4c8-64d48731eb1c","balance":"127170171039073754662"},{"uuid":"c9a85d0b-5f75-5fd7-9cd2-b94ba5caceef","balance":"90307779741239614343"},{"uuid":"d3230312-cacb-52e6-a849-8bbf6e8142dd","balance":"440489883392100126"},{"uuid":"06df45d9-dce1-557e-8b95-6092996677bc","balance":"486045569970211448730"},{"uuid":"1d71b13d-12d6-50d2-922b-022966bc433a","balance":"48960569860878978468"},{"uuid":"29f74af9-6c7d-5021-9d52-30985310ab49","balance":"39642886781129425647"},{"uuid":"2b74ef58-19d0-5263-8e2a-1d0232f1edf0","balance":"275801717508500016387"},{"uuid":"4930405c-4f62-5664-bb65-f8b300cbf220","balance":"24817865728422887622028"},{"uuid":"5611d328-30e9-5319-8c59-7abc6c462b2b","balance":"10333514999118006492"},{"uuid":"7ffc9561-464f-5e22-ad6a-9bcc9ac8537e","balance":"13171935464507741655800"},{"uuid":"9978ace7-7a98-5960-887d-b35d65a33c5f","balance":"4241541636908701822740"},{"uuid":"efda8e83-d2da-5d38-b813-f0cf2ccce895","balance":"492120868104362764968"},{"uuid":"fc9851b9-3bd7-5293-83c6-ccaa57ce1087","balance":"14352370034093926075024"},{"uuid":"356a192b-7913-504c-9457-4d18c28d46e6","balance":"0"}],"wallet":"VIEW_ONLY","transactions":[],"mtime":0,"favorite":false,"isPrivate":true}},"addressBook":{"f535254d-4740-5b81-a333-b2440d785991":{"address":"0xd132973eaebbd6d7ca7b88e9170f2cca058de430","label":"Mi acount","network":"Ethereum","notes":"CRISTIAN","uuid":"f535254d-4740-5b81-a333-b2440d785991"},"f625fa21-20ed-5154-a785-d88fbb85f58a":{"address":"0x8000f432747ccdc71b9df9f8eb96effeeac6218e","label":"My Account #1","network":"Ethereum","notes":"CRISTIAN123","uuid":"f625fa21-20ed-5154-a785-d88fbb85f58a"},"78d42968-6071-5a72-8dd0-9ca4c6c55e83":{"address":"0xa42830ee059c77caf8c8200b44aa9813cb0720c5","label":"My Account #3","network":"Ethereum","notes":"","uuid":"78d42968-6071-5a72-8dd0-9ca4c6c55e83"},"a1acf1f2-0380-5bd6-90c3-2b4a0974a6fe":{"address":"0x4bbeEB066eD09B7AEd07bF39EEe0460DFa261520","label":"MyCrypto Team Tip Jar","network":"Ethereum","notes":"This is MyCrypto's Donate address. Feel free to delete it!","uuid":"a1acf1f2-0380-5bd6-90c3-2b4a0974a6fe"}},"assets":{"74cf0f2b-414c-53b7-bd2a-04f78b05aaad":{"uuid":"74cf0f2b-414c-53b7-bd2a-04f78b05aaad","name":"YFI","decimal":18,"ticker":"YFI","networkId":"Ethereum","contractAddress":"0x0bc529c00C6401aEF6D220BE8C6Ea1667F6Ad93e","type":"erc20","isCustom":true},"df0cc14b-ce6a-544f-83ea-e78f21b31cae":{"uuid":"df0cc14b-ce6a-544f-83ea-e78f21b31cae","name":"BASED","decimal":18,"ticker":"BASED","networkId":"Ethereum","contractAddress":"0x68A118Ef45063051Eac49c7e647CE5Ace48a68a5","type":"erc20","isCustom":true},"5e0b14d9-c63b-5550-beaf-1e09ce3f2c0d":{"uuid":"5e0b14d9-c63b-5550-beaf-1e09ce3f2c0d","name":"WOM","decimal":18,"ticker":"WOM","networkId":"Ethereum","contractAddress":"0xBd356a39BFf2cAda8E9248532DD879147221Cf76","type":"erc20","isCustom":true}},"rates":{"356a192b-7913-504c-9457-4d18c28d46e6":{"usd":3337.01,"usd_24h_change":-0.354416464758243,"eur":3072.19,"eur_24h_change":-1.2086891723302806,"gbp":2635.22,"gbp_24h_change":-1.0295570273488062,"rub":308412,"rub_24h_change":-0.44651008491400296,"inr":278480,"inr_24h_change":-0.33834080203797295,"cny":24144,"cny_24h_change":-0.36130215539868715,"try":106406,"try_24h_change":-0.720477593461242,"cad":4506.55,"cad_24h_change":-0.9113932947109918,"dkk":22916,"dkk_24h_change":-1.199637828086303},"e1f698bf-cb85-5405-b563-14774af14bf1":{"usd":1,"usd_24h_change":0.03868958479387407,"eur":0.92086,"eur_24h_change":-0.7804500138555635,"gbp":0.789951,"gbp_24h_change":-0.617316672769773,"rub":92.43,"rub_24h_change":-0.053767348595792075,"inr":83.46,"inr_24h_change":0.0782627748825547,"cny":7.24,"cny_24h_change":0.031776729811694965,"try":31.89,"try_24h_change":-0.35041809187719103,"cad":1.35,"cad_24h_change":-0.521645405016721,"dkk":6.87,"dkk_24h_change":-0.7772911774432445},"2ed3ebcd-2d4f-52f7-b12b-54360ed49b55":{"usd":1.001,"usd_24h_change":-0.01549539996404062,"eur":0.921387,"eur_24h_change":-0.8019233041429825,"gbp":0.790403,"gbp_24h_change":-0.6521543249296331,"rub":92.48,"rub_24h_change":-0.10790225495336381,"inr":83.5,"inr_24h_change":0.016766451212162796,"cny":7.24,"cny_24h_change":-0.022404510664983796,"try":31.91,"try_24h_change":-0.3866519507122852,"cad":1.35,"cad_24h_change":-0.5668875734954398,"dkk":6.87,"dkk_24h_change":-0.8001768562627335},"c737fec0-a9e9-5841-b4c8-64d48731eb1c":{"usd":11.13,"usd_24h_change":-0.9871928848533926,"eur":10.25,"eur_24h_change":-1.819513733464342,"gbp":8.79,"gbp_24h_change":-1.6358794475426492,"rub":1028.59,"rub_24h_change":-1.0787016856001421,"inr":928.78,"inr_24h_change":-0.9696339343771643,"cny":80.52,"cny_24h_change":-0.9940348494949837,"try":354.87,"try_24h_change":-1.3517028599323702,"cad":15.03,"cad_24h_change":-1.5512772378253297,"dkk":76.44,"dkk_24h_change":-1.8128798942690287},"7f4d2f19-9a76-5930-b63b-ac9b0afe6201":{"usd":2.81,"eur":2.41,"gbp":2.16,"rub":221.49,"inr":209.52,"cny":18.82,"try":23.63},"7e6f798a-2e6a-5b4c-b7e4-ef6a12cc4d5a":{"usd":3332.53,"usd_24h_change":-0.34565208743732717,"eur":3068.6,"eur_24h_change":-1.1616446088463204,"gbp":2632.37,"gbp_24h_change":-0.9991380146859016,"rub":307997,"rub_24h_change":-0.43775380773351896,"inr":278099,"inr_24h_change":-0.30623093478629765,"cny":24112,"cny_24h_change":-0.3525383837122208,"try":106264,"try_24h_change":-0.7332648395373653,"cad":4500.57,"cad_24h_change":-0.9038343092749366,"dkk":22888,"dkk_24h_change":-1.1584979084632587},"4a21c8bc-3df3-5d61-b9c4-c6c2f2296914":{"usd":0.00451162,"eur":0.00371171,"gbp":0.00335571,"rub":0.330944,"inr":0.331785,"cny":0.02952404,"try":0.03538924},"a9cc6884-14bd-53b6-abcd-f9b56b60463d":{"usd":0.02086022,"eur":0.0171617,"gbp":0.01551568,"rub":1.53,"inr":1.53,"cny":0.136509,"try":0.163628},"34eeb9ed-4225-515b-9cb1-d93fd16d78c2":{"usd":0.00267466,"eur":0.002201,"gbp":0.00199008,"rub":0.196185,"inr":0.197283,"cny":0.01749037,"try":0.02095891},"112d920e-96e8-57cd-b141-6dd63fa90d31":{"usd":0.181848,"eur":0.149606,"gbp":0.135257,"rub":13.34,"inr":13.37,"cny":1.19,"try":1.43},"0765f5fa-f31e-5aa9-9122-c20b90d686f3":{"usd":16.5,"usd_24h_change":-3.608086600344098,"eur":15.19,"eur_24h_change":-4.366256986224696,"gbp":13.03,"gbp_24h_change":-4.221869428052172,"rub":1524.96,"rub_24h_change":-3.697173140296445,"inr":1376.93,"inr_24h_change":-3.576983965219492,"cny":119.38,"cny_24h_change":-3.6147474564739253,"try":526.14,"try_24h_change":-3.9659069470123667,"cad":22.28,"cad_24h_change":-4.139666437168822,"dkk":113.33,"dkk_24h_change":-4.364573290801055},"3ebda70e-d4a9-5a20-81a1-32f1109d3121":{"usd":0.956455,"usd_24h_change":-3.4908106783723616,"eur":0.880707,"eur_24h_change":-4.281049924158154,"gbp":0.755506,"gbp_24h_change":-4.123672147971237,"rub":88.4,"rub_24h_change":-3.5800056061110768,"inr":79.82,"inr_24h_change":-3.4526336839495784,"cny":6.92,"cny_24h_change":-3.497479638481242,"try":30.5,"try_24h_change":-3.8661901099724103,"cad":1.29,"cad_24h_change":-4.031376291932514,"dkk":6.57,"dkk_24h_change":-4.2780025357666025},"59a6f871-34bb-5914-86cc-b5f1307bb3b9":{"usd":0.520503,"usd_24h_change":-2.6663805434536796,"eur":0.479281,"eur_24h_change":-3.4319579162832783,"gbp":0.411147,"gbp_24h_change":-3.2861597559838542,"rub":48.11,"rub_24h_change":-2.756337419218494,"inr":43.44,"inr_24h_change":-2.634974049438373,"cny":3.77,"cny_24h_change":-2.6731064731809204,"try":16.6,"try_24h_change":-3.0276966355206016,"cad":0.702939,"cad_24h_change":-3.203153678496095,"dkk":3.57,"dkk_24h_change":-3.4302577719054463},"e34bb9ff-47be-503b-956b-30d4b3f3507b":{"usd":0.220291,"eur":0.181254,"gbp":0.163848,"rub":16.16,"inr":16.2,"cny":1.44,"try":1.73},"13c0661d-68f1-5b8f-8ff8-410bb67c5f06":{"usd":0.00061639,"eur":0.00050711,"gbp":0.00045847,"rub":0.04521464,"inr":0.04532941,"cny":0.00403366,"try":0.00483498},"f0935aad-cb4c-5f72-bc59-79879d718c87":{"usd":0.00005947,"usd_24h_change":-1.2455074994986821,"eur":0.00005476,"eur_24h_change":-2.022260746175231,"gbp":0.00004698,"gbp_24h_change":-1.8743342290244152,"rub":0.00549645,"rub_24h_change":-1.3367775628404273,"inr":0.0049629,"inr_24h_change":-1.2136425344945685,"cny":0.00043029,"cny_24h_change":-1.252331614131532,"try":0.00189637,"try_24h_change":-1.6120980722479514,"cad":0.00008032,"cad_24h_change":-1.7901164314893487,"dkk":0.00040846,"dkk_24h_change":-2.0205357831443833},"2f16477d-6bd6-5fac-8b9e-3f0772b6489d":{"usd":0.76692,"eur":0.630945,"gbp":0.57043,"rub":56.26,"inr":56.4,"cny":5.02,"try":6.02},"12470ffd-9ed1-5899-80b8-b1d30b1d1194":{"usd":0.110922,"eur":0.091266,"gbp":0.082501,"rub":8.14,"inr":8.16,"cny":0.725837,"try":0.869969},"c469f604-d610-5252-8f8b-580ca1837e58":{"usd":3.08,"eur":2.53,"gbp":2.29,"rub":225.65,"inr":226.21,"cny":20.13,"try":24.13},"6c1e671f-9af5-546d-9c1a-52067bdf0e53":{"usd":6,"eur":4.94,"gbp":4.47,"rub":440.45,"inr":441.57,"cny":39.29,"try":47.1},"a7dad681-9933-56fd-a593-7b4746b7304b":{"usd":12.11,"eur":9.97,"gbp":9.01,"rub":888.53,"inr":890.77,"cny":79.26,"try":95},"d3230312-cacb-52e6-a849-8bbf6e8142dd":{"usd":3818.84,"usd_24h_change":1.672746883570081,"eur":3516.37,"eur_24h_change":0.8180660656802443,"gbp":3016.39,"gbp_24h_change":1.0066336138154375,"rub":352943,"rub_24h_change":1.5787797352079407,"inr":318695,"inr_24h_change":1.6907775482825165,"cny":27630,"cny_24h_change":1.665721112263526,"try":121769,"try_24h_change":1.298444492672286,"cad":5156.68,"cad_24h_change":1.0935086283210165,"dkk":26229,"dkk_24h_change":0.8248781203327673},"52f6407e-e3de-50f6-a26a-23702e0efc16":{"usd":1.57,"usd_24h_change":-4.724173382604547,"eur":1.45,"eur_24h_change":-5.525080448799327,"gbp":1.24,"gbp_24h_change":-5.3483769606723905,"rub":145.39,"rub_24h_change":-4.812228422027608,"inr":131.28,"inr_24h_change":-4.707277148976783,"cny":11.38,"cny_24h_change":-4.730757115112571,"try":50.16,"try_24h_change":-5.074925878143315,"cad":2.12,"cad_24h_change":-5.266967840990495,"dkk":10.8,"dkk_24h_change":-5.5186969865847395},"a24f0eba-c56c-5095-8b45-d4bd5b7063d7":{"usd":5.2,"eur":4.28,"gbp":3.87,"rub":381.36,"inr":382.32,"cny":34.02,"try":40.78},"c9a85d0b-5f75-5fd7-9cd2-b94ba5caceef":{"usd":71.12,"usd_24h_change":-1.1023506330044084,"eur":65.48,"eur_24h_change":-1.950211217486557,"gbp":56.16,"gbp_24h_change":-1.7724236283509838,"rub":6573.14,"rub_24h_change":-1.1937530036060082,"inr":5935.22,"inr_24h_change":-1.0863956333080116,"cny":514.58,"cny_24h_change":-1.1091846400366219,"try":2267.83,"try_24h_change":-1.4656641273807358,"cad":96.05,"cad_24h_change":-1.6551468260712707,"dkk":488.41,"dkk_24h_change":-1.9412278121254285},"42362ed0-333d-5123-ae7d-29b79178769d":{"usd":1.89,"usd_24h_change":3.8667377077240452,"eur":1.74,"eur_24h_change":2.993613777697434,"gbp":1.49,"gbp_24h_change":3.1862504149741295,"rub":174.82,"rub_24h_change":3.77074284724049,"inr":157.86,"inr_24h_change":3.8851574551960013,"cny":13.69,"cny_24h_change":3.859560327670444,"try":60.32,"try_24h_change":3.4843582653422045,"cad":2.55,"cad_24h_change":3.275000100820059,"dkk":12.99,"dkk_24h_change":3.000572829316838},"281fa3af-8e6d-5f33-900c-33a480035475":{"usd":115.84,"usd_24h_change":-2.3233214218973752,"eur":106.67,"eur_24h_change":-3.144410515039351,"gbp":91.5,"gbp_24h_change":-2.963254282381083,"rub":10706.15,"rub_24h_change":-2.4135953569369164,"inr":9667.28,"inr_24h_change":-2.3059994207157968,"cny":838.13,"cny_24h_change":-2.3300710576324564,"try":3693.75,"try_24h_change":-2.682912516339089,"cad":156.42,"cad_24h_change":-2.87979373736354,"dkk":795.63,"dkk_24h_change":-3.137866196201227},"1c77b322-a88c-57cc-b956-78c2bc17c360":{"usd":4e-17,"usd_24h_change":-20.064643719125122,"eur":3.7e-17,"eur_24h_change":-20.718088298151148,"gbp":3.2e-17,"gbp_24h_change":-20.581104861670273,"rub":3.695e-15,"rub_24h_change":-20.138520915456034,"inr":3.337e-15,"inr_24h_change":-20.050330971310572,"cny":2.89e-16,"cny_24h_change":-20.07016739729595,"try":1.275e-15,"try_24h_change":-20.357370115226562,"cad":5.4e-17,"cad_24h_change":-20.49979443671669,"dkk":2.75e-16,"dkk_24h_change":-20.714932453452153},"34d158c5-eed0-51ad-8252-5336a391958a":{"usd":0.00035947,"usd_24h_change":0.009586525505633154,"eur":0.00033109,"eur_24h_change":-0.7377903442976939,"gbp":0.00028394,"gbp_24h_change":-0.6291239876026993,"rub":0.03325311,"rub_24h_change":0.00958652550564617,"inr":0.02999921,"inr_24h_change":0.0513154849564754,"cny":0.00260081,"cny_24h_change":0.0026756815978279443,"try":0.0114624,"try_24h_change":-0.36941355875728843,"cad":0.00048552,"cad_24h_change":-0.536386791446727,"dkk":0.00246956,"dkk_24h_change":-0.7376895898255746},"53306efd-fb16-5e9a-b6d0-fc0e9713da40":{"usd":18.84,"usd_24h_change":-21.260180267423898,"eur":17.35,"eur_24h_change":-21.879508148833555,"gbp":14.88,"gbp_24h_change":-21.761562048365608,"rub":1741.04,"rub_24h_change":-21.332952534816975,"inr":1572.03,"inr_24h_change":-21.234773407070797,"cny":136.3,"cny_24h_change":-21.26562133184981,"try":600.69,"try_24h_change":-21.552473558423184,"cad":25.44,"cad_24h_change":-21.69441275694313,"dkk":129.38,"dkk_24h_change":-21.878132785802922},"685f1c7f-2d31-56c2-ae80-9cd433aeb0e1":{"usd":1,"usd_24h_change":-0.11428593325173103,"eur":0.921264,"eur_24h_change":-0.8999368007052824,"gbp":0.790297,"gbp_24h_change":-0.7503158019953596,"rub":92.47,"rub_24h_change":-0.20660148486840277,"inr":83.49,"inr_24h_change":-0.0820559586697705,"cny":7.24,"cny_24h_change":-0.12118821734756738,"try":31.9,"try_24h_change":-0.48507575963875865,"cad":1.35,"cad_24h_change":-0.6651332990942704,"dkk":6.87,"dkk_24h_change":-0.898192078417584},"e6b79bdf-4c78-5719-aa76-e9944ac8a849":{"usd":0.00002652,"eur":0.00002182,"gbp":0.00001973,"rub":0.00194543,"inr":0.00195033,"cny":0.00017355,"try":0.00020801},"3dcbc269-fa47-5707-b180-4cb0ba6e5cdf":{"usd":1.18,"usd_24h_change":-3.6113535943337003,"eur":1.085,"eur_24h_change":-4.369498283680187,"gbp":0.931042,"gbp_24h_change":-4.2251156192096495,"rub":108.94,"rub_24h_change":-3.700437114891831,"inr":98.36,"inr_24h_change":-3.580252013365217,"cny":8.53,"cny_24h_change":-3.618014224708381,"try":37.58,"try_24h_change":-3.9691618134605253,"cad":1.59,"cad_24h_change":-4.142915414417493,"dkk":8.1,"dkk_24h_change":-4.367814645321837},"d3e4675a-4ca4-5e05-a4d7-445edcd76965":{"usd":0.00112129,"eur":0.00092259,"gbp":0.00083399,"rub":0.082251,"inr":0.082458,"cny":0.00733736,"try":0.00879436},"c90311b2-90b2-5bf4-8d93-e06bd7cfb666":{"usd":1,"usd_24h_change":-0.019004125627889903,"eur":0.921071,"eur_24h_change":-0.8054044319327227,"gbp":0.790132,"gbp_24h_change":-0.6556407085163872,"rub":92.45,"rub_24h_change":-0.11140773781168982,"inr":83.47,"inr_24h_change":0.013256593393037546,"cny":7.24,"cny_24h_change":-0.02591299386951233,"try":31.9,"try_24h_change":-0.3901476514927103,"cad":1.35,"cad_24h_change":-0.5703769493222469,"dkk":6.87,"dkk_24h_change":-0.8036580453400259},"543a4909-8501-575f-b3a5-f3f7117dcc8b":{"usd":0.00003117,"eur":0.00002565,"gbp":0.00002342,"rub":0.00227833,"inr":0.00229343,"cny":0.00020385,"try":0.00024631},"8c5ef44a-ffef-5478-929d-488b0135192f":{"usd":0.052982,"eur":0.04358829,"gbp":0.03940208,"rub":3.89,"inr":3.9,"cny":0.346465,"try":0.415077},"daaceb9e-7d95-54fb-a924-d4d013adfb4c":{"usd":0,"eur":0,"gbp":0,"rub":0,"inr":0,"cny":0,"try":0},"b4ebfad5-090f-534e-aa26-e77035adc0fc":{"usd":0.04165293,"eur":0.03427182,"gbp":0.03098057,"rub":3.06,"inr":3.06,"cny":0.272564,"try":0.326688},"b79cdc9b-9a97-5413-9a0b-bee09c086c78":{"usd":0.00230872,"eur":0.00207448,"gbp":0.00179052,"rub":0.147582,"inr":0.163863,"cny":0.01632915,"try":0.01329806},"c697f7c1-5f8a-5de8-ae44-22687bba713a":{"usd":0.00721442,"eur":0.00659903,"gbp":0.0058711,"rub":0.466919,"inr":0.508346,"cny":0.05138,"try":0.04088155},"7c39f1de-8bc8-5d03-bee5-6451741664bd":{"usd":0.060986,"eur":0.050189,"gbp":0.04537778,"rub":4.48,"inr":4.49,"cny":0.399123,"try":0.478381},"7dc10f7d-a63a-516f-a6a1-da2320f1a845":{"usd":0.00002331,"eur":0.00001919,"gbp":0.00001735,"rub":0.00170706,"inr":0.00171935,"cny":0.00015243,"try":0.00018263},"a3131ec3-7689-50b3-b135-0d36a676c90b":{"usd":0.00086528,"eur":0.00071194,"gbp":0.00064357,"rub":0.063471,"inr":0.063631,"cny":0.0056621,"try":0.00678644},"d48a25ca-8d2b-596f-a852-79407565b6e4":{"usd":0.00990355,"usd_24h_change":-38.61846054581231,"eur":0.00911923,"eur_24h_change":-39.10125691132246,"gbp":0.00782284,"gbp_24h_change":-39.00931215904941,"rub":0.9153,"rub_24h_change":-38.67519008643517,"inr":0.826451,"inr_24h_change":-38.59865465590201,"cny":0.071654,"cny_24h_change":-38.622702121572225,"try":0.315794,"try_24h_change":-38.84631745778653,"cad":0.01337473,"cad_24h_change":-38.956966003130276,"dkk":0.068019,"dkk_24h_change":-39.10018474859198},"f774001a-d201-5445-b63a-6221f63c237b":{"usd":0.00518912,"eur":0.00433969,"gbp":0.00390096,"rub":0.394464,"inr":0.383684,"cny":0.03412887,"try":0.04052187},"778541d2-65e6-5c57-b083-aa3129eb91c8":{"usd":1.75,"eur":1.44,"gbp":1.3,"rub":128.63,"inr":128.95,"cny":11.47,"try":13.75},"4ca1289d-7126-5a11-8be3-2fc7f6c45820":{"usd":0.00209528,"eur":0.00172398,"gbp":0.0015585,"rub":0.153695,"inr":0.154087,"cny":0.01371316,"try":0.01643593},"cfd7b234-57bd-5306-89e8-3d477c4cbb83":{"usd":0.00622422,"eur":0.00512125,"gbp":0.00462944,"rub":0.45657,"inr":0.457719,"cny":0.0407294,"try":0.04881715},"e02a1b4e-ab8b-5894-a49e-a36b74bd99ab":{"usd":12.17,"eur":10.01,"gbp":9.05,"rub":892.37,"inr":894.62,"cny":79.61,"try":95.41},"5e895083-fac7-5033-ae8a-a0f317f230ff":{"usd":2.17,"usd_24h_change":-2.8139511127286085,"eur":2,"eur_24h_change":-3.57836776956549,"gbp":1.72,"gbp_24h_change":-3.432790658453751,"rub":200.67,"rub_24h_change":-2.903771602037846,"inr":181.19,"inr_24h_change":-2.7825922350890897,"cny":15.71,"cny_24h_change":-2.8206668450617167,"try":69.24,"try_24h_change":-3.1747194020764704,"cad":2.93,"cad_24h_change":-3.3499104290971395,"dkk":14.91,"dkk_24h_change":-3.5766702028301496},"d339805d-b72c-5546-a10e-2a74f425d9d2":{"usd":0.00004157,"eur":0.00003799,"gbp":0.00003383,"rub":0.00268778,"inr":0.00293689,"cny":0.00029608,"try":0.00023572},"b3aed520-c84f-566c-9431-5263a2d40460":{"usd":0.03589272,"eur":0.02953235,"gbp":0.02669625,"rub":2.63,"inr":2.64,"cny":0.234871,"try":0.28151},"93686561-3c9d-5bc8-81bf-0334150be221":{"usd":0.00987544,"eur":0.00913139,"gbp":0.00763171,"rub":0.639568,"inr":0.709521,"cny":0.069435,"try":0.060704},"5d06038d-8c66-5921-958e-4be4421944c5":{"usd":0.0009832,"eur":0.00080897,"gbp":0.00073132,"rub":0.072121,"inr":0.072305,"cny":0.00643486,"try":0.00771252},"00ff8c75-22ce-5e15-b06a-770154d7e333":{"usd":1,"eur":0.823818,"gbp":0.744646,"rub":73.45,"inr":73.64,"cny":6.55,"try":7.85},"c0ae47d5-f020-5ea8-9886-522d3af70845":{"usd":12.49,"eur":10.28,"gbp":9.29,"rub":916.09,"inr":918.39,"cny":81.72,"try":97.95},"4930405c-4f62-5664-bb65-f8b300cbf220":{"usd":0.00714457,"usd_24h_change":-8.574641214911285,"eur":0.00657869,"eur_24h_change":-9.343180502157944,"gbp":0.00564329,"gbp_24h_change":-9.173618291320684,"rub":0.660312,"rub_24h_change":-8.659137606681368,"inr":0.596238,"inr_24h_change":-8.558427823997885,"cny":0.051692,"cny_24h_change":-8.580958873105045,"try":0.227815,"try_24h_change":-8.911218433791262,"cad":0.0096475,"cad_24h_change":-9.095499231748773,"dkk":0.04907129,"dkk_24h_change":-9.337055020553837},"7ffc9561-464f-5e22-ad6a-9bcc9ac8537e":{"usd":0.701174,"usd_24h_change":null,


19.1.1 Alias API fails to retain data or create new alias

When using the alias_util api for Add / List, I am able to add an address to an existing alias list which is visible in the web interface. The additional entry will be added and will be visible via the API if "list"ing the alias, but after 10 - 20 seconds it will drop every entry in the list except the new one I just added. The
Existing Alias:
name: myalias
Hosts: <IP_ADDRESS>
POST details:
addurl = 'https://fw/api/firewall/alias_util/add/myalias'
addalias = requests.post(addurl,
                verify=False,
                auth=(api_key, api_secret),
                json={'address': '<IP_ADDRESS>'})

i.e: listing the alias:
{u'current': 1, u'rowCount': 9999, u'total': 2, u'rows': [{u'ip': u'<IP_ADDRESS>'}, {u'ip': u'<IP_ADDRESS>'}]
}
after 10 seconds or so:
{u'current': 1, u'rowCount': 9999, u'total': 1, u'rows': [{u'ip': u'<IP_ADDRESS>'}]}
Additionally, when adding a NEW alias via the API, the alias is not visible in the web interface, nor selectable for any rules.
Please let me know if you require any further info or if I'm doing something wrong :)

Can you replicate the exact same behaviour using the gui? if so, please provide steps and alias type used. All endpoints are also available through the user interface.

I'm sorry, I'm not quite sure I understand you. I can use the gui to add/remove/modify an alias, then click apply and it works as expected. This is only occurring when using the /api/firewall/alias_util/add/ endpoint. Is there another API endpoint I should be trying or another component in the gui you're referring to?

The alias_util endpoint is available in the diagnostic section (https://your-host/ui/firewall/alias_util/), could you replicate your issue there?

Yes, that has the same symptom. The new address added via the "Quick add address" box, adds the address into the list and then the existing entry vanishes after 10 - 20 seconds

Which type of alias are you using?

I'm just working with the default Host(s) one

looks like a bug, it's replacing the content instead of adding it...

Thank you for your help with this. We've been looking forward to this feature :)

Is it also intentional that the API created Alias would not be assignable to rules via the gui?

https://github.com/opnsense/core/commit/50c25eaf6b1ddbac78a4618ce38d70393141f534 fixes the replacement on my end.
Install locally using:
opnsense-patch 50c25ea

if the alias is visible in the interface, you should be able to assign it.


Enable ads & chromecast extensions

Can't get it compiling, to be investigated what's up

Created by accident PR to upstream instead of our forked repository, please ignore


[ERROR] The resource could not be found.

I am running the module on a docker install so I did a new install on another PI with out docker.
After running MagicMirror on the non-docker PI I get the auth screen and am able to login. After that the terminal shows that the resource cannot be found.
Token.json is located in the correct folder and has been updated.
-rw-r--r-- 1 mirroradmin mirroradmin 1216 Nov 12 14:28 CachePlugin.js
-rw-r--r-- 1 mirroradmin mirroradmin 5060 Nov 12 14:28 AuthProvider.js
-rw-r--r-- 1 mirroradmin mirroradmin 1590 Nov 12 14:28 authConfig.js
-rw-r--r-- 1 mirroradmin mirroradmin 5462 Nov 12 14:31 token.json

[2024-11-12 14:31:43.733] [DEBUG] [ONEDRIVE:CORE] onAuthReady token responed
[2024-11-12 14:31:44.137] [LOG]   [ONEDRIVE:CORE] onAuthReady done
[2024-11-12 14:31:44.139] [LOG]   [ONEDRIVE:CORE] Getting Album info chunks.
[2024-11-12 14:31:45.452] [ERROR] Trace: [ONEDRIVE:CORE] request fail with URL https://graph.microsoft.com/v1.0/me/drive/items/e69b16d18dabbef5!0:/SkyDriveCache/Albums:/children
    at OneDrivePhotos.logTrace (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:74:13)
    at OneDrivePhotos.request (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:112:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async getAlbum (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:139:24)
    at async OneDrivePhotos.getAlbums (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:120:18)
    at async Class.getAlbums (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:225:15)
    at async Class.getAlbumList (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:270:18)
    at async Class.scanJob (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:251:5)
[2024-11-12 14:31:45.454] [ERROR] Trace: [ONEDRIVE:CORE] data null
    at OneDrivePhotos.logTrace (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:74:13)
    at OneDrivePhotos.request (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:113:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async getAlbum (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:139:24)
    at async OneDrivePhotos.getAlbums (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/OneDrivePhotos.js:120:18)
    at async Class.getAlbums (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:225:15)
    at async Class.getAlbumList (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:270:18)
    at async Class.scanJob (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:251:5)
[2024-11-12 14:31:45.456] [ERROR] [ONEDRIVE:CORE] The resource could not be found.
stack:
Error: The resource could not be found.
    at new GraphError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphError.js:34:28)
    at GraphErrorHandler.constructErrorFromResponse (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:63:22)
    at Function.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:91:48)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.next (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:169:75
    at new Promise (<anonymous>)
    at Object.__awaiter (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:165:16)
    at GraphErrorHandler.getError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:87:24)
    at GraphRequest.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphRequest.js:315:84)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.throw (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at rejected (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:167:69)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2024-11-12 14:31:45.456] [LOG]   [ONEDRIVE:CORE] Error: The resource could not be found.
[2024-11-12 14:31:45.457] [ERROR] The resource could not be found.
stack:
Error: The resource could not be found.
    at new GraphError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphError.js:34:28)
    at GraphErrorHandler.constructErrorFromResponse (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:63:22)
    at Function.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:91:48)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.next (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:169:75
    at new Promise (<anonymous>)
    at Object.__awaiter (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:165:16)
    at GraphErrorHandler.getError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:87:24)
    at GraphRequest.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphRequest.js:315:84)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.throw (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at rejected (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:167:69)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2024-11-12 14:31:45.461] [INFO]  Finish Album scanning. Properly scanned : 0
[2024-11-12 14:31:45.462] [INFO]  Albums:
[2024-11-12 14:31:45.464] [INFO]  getAlbumList done
[2024-11-12 14:31:45.465] [WARN]  There is no album to get photos.
[2024-11-12 14:31:45.469] [INFO]  Next scan will be at 2024-11-12T20:26:26.442Z
[2024-11-12 14:32:45.475] [INFO]  Used last pic in list
[2024-11-12 14:32:45.478] [ERROR] couldn't send  0  pics
[2024-11-12 14:33:45.468] [INFO]  Used last pic in list
[2024-11-12 14:33:45.469] [ERROR] couldn't send  0  pics

@createitforme Please switch to dev branch and try if it works.

New errors this time.
[2024-11-12 21:40:37.228] [LOG]   [ONEDRIVE:CORE] onAuthReady token responed
[2024-11-12 21:40:37.837] [LOG]   [ONEDRIVE:CORE] onAuthReady done
[2024-11-12 21:40:37.837] [LOG]   [ONEDRIVE:CORE] Getting Album info chunks.
[2024-11-12 21:40:39.483] [ERROR] [ONEDRIVE:CORE] [getAlbumThumbnail]request fail get URL: https://graph.microsoft.com/v1.0/drives/b!RHKBF5I1ZUSKsN7CtigeaXeMQ1t_5VZAuGAZNZFIovagg9MbeMhgSJT0-7mMv_mS/items/E69B16D18DABBEF5!s8de3edecbe7b459a89a0c1bd6bf1e0c2/thumbnails?$select=mediumSquare
[2024-11-12 21:40:39.484] [ERROR] [ONEDRIVE:CORE] [getAlbumThumbnail]data:  null
[2024-11-12 21:40:39.485] [ERROR] [ONEDRIVE:CORE] Invalid request
stack:
Error: Invalid request
    at new GraphError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphError.js:34:28)
    at GraphErrorHandler.constructErrorFromResponse (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:63:22)
    at Function.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:91:48)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.next (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:169:75
    at new Promise (<anonymous>)
    at Object.__awaiter (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:165:16)
    at GraphErrorHandler.getError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:87:24)
    at GraphRequest.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphRequest.js:315:84)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.throw (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at rejected (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:167:69)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2024-11-12 21:40:39.486] [ERROR] [ONEDRIVE:CORE] Error in getAlbum() Error: Invalid request
[2024-11-12 21:40:39.486] [ERROR] [ONEDRIVE:CORE] Error: Invalid request
[2024-11-12 21:40:39.487] [ERROR] Invalid request
stack:
Error: Invalid request
    at new GraphError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphError.js:34:28)
    at GraphErrorHandler.constructErrorFromResponse (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:63:22)
    at Function.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:91:48)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.next (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:169:75
    at new Promise (<anonymous>)
    at Object.__awaiter (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:165:16)
    at GraphErrorHandler.getError (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphErrorHandler.js:87:24)
    at GraphRequest.<anonymous> (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/@microsoft/microsoft-graph-client/lib/src/GraphRequest.js:315:84)
    at step (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:195:27)
    at Object.throw (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:176:57)
    at rejected (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_modules/tslib/tslib.js:167:69)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

@createitforme  Please do some testings in Microsoft offical Graph Explorer

Go to https://developer.microsoft.com/en-us/graph/graph-explorer
Sign in at the top right concer

Run query with the following url
https://graph.microsoft.com/v1.0/me/drive/bundles?filter=bundle/album+ne+null
You can see the response data in the bottom panel. Please DON'T paste the whole resposne in here because of sensitive data.{
<EMAIL_ADDRESS>"https://graph.microsoft.com/v1.0/$metadata#users('###########')/drive/bundles",
<EMAIL_ADDRESS>4,
<EMAIL_ADDRESS>"Use $select to choose only the properties your app needs, as this can lead to performance improvements. For example: GET me/drive/bundles?$select=audio,bundle",
    "value": [
    ...
    ]
}

Please can find with the keyword E69B16D18DABBEF5!s8de3edecbe7b459a89a0c1bd6bf1e0c2. Please remove webUrl and paste in here{
    "createdDateTime": "2024-01-10T14:44:18.583Z",
    "cTag": "adasdasdsad#",
    "eTag": "asdasdasdx",
    "id": "E69B16D18DABBEF5!s8de3edecbe7b459a89a0c1bd6bf1e0c2",
    "createdBy": ...
    "lastModifiedBy": ...
    "parentReference": {
        "driveId": "b!RHKBF5I1ZUSKsN7CtigeaXeMQ1t_5VZAuGAZNZFIovagg9MbeMhgSJT0-7mMv_mS",
        "driveType": "personal",
        "id": "asdasdsadas"
    },
    "fileSystemInfo": ...
    "bundle":  ...
}

My output does not look like yours. It also only worked after consenting to file permissions. I am using a personal account with my own domain might be the difference. Not a M365 account.
{
<EMAIL_ADDRESS>"\"{8DE3EDEC-BE7B-459A-89A0-C1BD6BF1E0C2},3\"",
            "createdDateTime": "2024-11-12T19:09:30Z",
            "eTag": "asdasdasdx",
            "id": "E69B16D18DABBEF5!s8de3edecbe7b459a89a0c1bd6bf1e0c2",
            "lastModifiedDateTime": "2024-11-12T19:09:32Z",
            "name": "MagicMirror",
            "size": 343025,
            "webUrl": "...",
            "cTag": "asdasdasdx",
            "commentSettings": {
                "commentingDisabled": {
                    "isDisabled": false
                }
            },

I see. I am using M365 Family plan so I am not sure if it is working in SharePoint. Will you get the success result with this url in graph explorer?
https://graph.microsoft.com/v1.0/me/drives/b!RHKBF5I1ZUSKsN7CtigeaXeMQ1t_5VZAuGAZNZFIovagg9MbeMhgSJT0-7mMv_mS/items/E69B16D18DABBEF5!s8de3edecbe7b459a89a0c1bd6bf1e0c2/children
These are the key fields in the response.
{
<EMAIL_ADDRESS>2,
    "value": [
        {
<EMAIL_ADDRESS>"######",
            "id": "########",
            "lastModifiedDateTime": "2024-01-10T17:21:58.54Z",
            "name": "20200117_090301068_iOS.heic",
            "size": 1520961,
            "fileSystemInfo": {
                "createdDateTime": "2020-01-17T09:03:01.068Z",
                "lastModifiedDateTime": "2023-07-21T13:46:19.66Z"
            },
            "image": {
                "height": 3024,
                "width": 4032
            },
            "photo": {
                "cameraMake": "Apple",
                "cameraModel": "iPhone XR",
                "exposureDenominator": 50,
                "exposureNumerator": 1,
                "focalLength": 4.25,
                "fNumber": 1.8,
                "iso": 100,
                "orientation": 1,
                "takenDateTime": "2020-01-17T17:03:01Z"
            }
        }
    ]
}

How do you create the 'MagicMirror" album? Is it from this screen? Are you the owner of the album or shared from someone?

Could you please double check the value of parentReference.driveId and parentReference.driveType in previous payload? This driveId should be the same from https://graph.microsoft.com/v1.0/me/drive

Sorry for the delay in responding. I have tried this every way I can think of. I tried it with my work account, but business accounts do not support photos for some reason. I've signed up for a M365 family account to match yours and I still get the same results.
I'm not sure what you have done differently in your account versus mine. Mine is vanilla with only one album created on the web just as the picture above.

I created a new microsoft account with free plan and fixed the code. Would you pull the latest dev branch and try again?

It works! Thank you!
Once I added more than one picture it throws cache errors in the logs, but it still rotates the images.
[2024-12-01 22:47:24.404] [WARN]  Cache Config does not exist: /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/cache/config.json
[2024-12-01 22:47:24.404] [ERROR] unable to write Cache Config
[2024-12-01 22:47:24.405] [ERROR] Cannot set properties of null (setting 'CACHE_HASH')
stack:
TypeError: Cannot set properties of null (setting 'CACHE_HASH')
    at Class.saveCacheConfig (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:453:19)
    at Class.getAlbums (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:251:7)
    at Class.getAlbumList (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:293:18)
    at Class.scanJob (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:274:5)

[2024-12-01 22:47:24.407] [WARN]  Cache Config does not exist: /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/cache/config.json
[2024-12-01 22:47:24.411] [ERROR] unable to write Cache Config
[2024-12-01 22:47:24.411] [ERROR] Cannot set properties of null (setting 'CACHE_ALBUMNS_PATH')
stack:
TypeError: Cannot set properties of null (setting 'CACHE_ALBUMNS_PATH')
    at Class.saveCacheConfig (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:453:19)

[2024-12-01 22:47:25.426] [WARN]  Cache Config does not exist: /home/mirroradmin/MagicMirror/modules/MMM-OneDrive/cache/config.json
[2024-12-01 22:47:25.426] [ERROR] unable to write Cache Config
[2024-12-01 22:47:25.426] [ERROR] Cannot set properties of null (setting 'CACHE_PHOTOLIST_PATH')
stack:
TypeError: Cannot set properties of null (setting 'CACHE_PHOTOLIST_PATH')
    at Class.saveCacheConfig (/home/mirroradmin/MagicMirror/modules/MMM-OneDrive/node_helper.js:453:19)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

I updated the dev branch and it should be fine now.

dev branch has zero errors and seems to be working perfectly. Thank you!

The fixing has merged so you can switch back to main branch