Fix unaligned double word accesses in chunkset_c on ARMv7

c.f., https://github.com/zlib-ng/zlib-ng/issues/708#issuecomment-667622465

Does not yet implement the recommendation from https://github.com/zlib-ng/zlib-ng/issues/708#issuecomment-667706892

Re: https://github.com/zlib-ng/zlib-ng/issues/708#issuecomment-667706892
Would something like that work?
diff --git a/deflate.h b/deflate.h
index 153ec25..6e3d431 100644
--- a/deflate.h
+++ b/deflate.h
@@ -97,7 +97,7 @@ typedef struct tree_desc_s {
 typedef uint16_t Pos;

 /* A Pos is an index in the character window. We use short instead of int to
- * save space in the various tables.
+ * save space in the various tables.
  */

 typedef struct internal_state {
@@ -355,14 +355,10 @@ static inline void put_uint64(deflate_state *s, uint64_t lld) {
     *(uint64_t *)(&s->pending_buf[s->pending]) = lld;
     s->pending += 8;
 #else
-    put_byte(s, (lld & 0xff));
-    put_byte(s, ((lld >> 8) & 0xff));
-    put_byte(s, ((lld >> 16) & 0xff));
-    put_byte(s, ((lld >> 24) & 0xff));
-    put_byte(s, ((lld >> 32) & 0xff));
-    put_byte(s, ((lld >> 40) & 0xff));
-    put_byte(s, ((lld >> 48) & 0xff));
-    put_byte(s, ((lld >> 56) & 0xff));
+    *(uint32_t *)(&s->pending_buf[s->pending]) = lld & 0xffffffff;
+    s->pending += 4;
+    *(uint32_t *)(&s->pending_buf[s->pending]) = (lld >> 32) & 0xffffffff;
+    s->pending += 4;
 #endif
 }

It looks right. But you would want something like this:
#if defined(UNALIGNED64_OK)
     *(uint64_t *)(&s->pending_buf[s->pending]) = lld;
     s->pending += 8;
#elif defined(UNALIGNED_OK)
    *(uint32_t *)(&s->pending_buf[s->pending]) = lld & 0xffffffff;
    s->pending += 4;
    *(uint32_t *)(&s->pending_buf[s->pending]) = (lld >> 32) & 0xffffffff;
    s->pending += 4;
#else
    put_byte(s, (lld & 0xff));
    put_byte(s, ((lld >> 8) & 0xff));
    put_byte(s, ((lld >> 16) & 0xff));
    put_byte(s, ((lld >> 24) & 0xff));
    put_byte(s, ((lld >> 32) & 0xff));
    put_byte(s, ((lld >> 40) & 0xff));
    put_byte(s, ((lld >> 48) & 0xff));
    put_byte(s, ((lld >> 56) & 0xff));
#endif

@nmoinvaz: Oh, yeah, of course. :facepalm:

@nmoinvaz: Oops ^^. I think I got everything in 6516925. It builds, and bsdtar still doesn't implode ;).

Looks good to me.


Displaying mutations

See https://github.com/jeromekelleher/sc2ts/issues/180 for a suggestion about one way of displaying mutations as bars across the edge:

The plot_subgraph function currently has these two alternatives:
Numbers:
List of mutations:


Ignore invalid cookie attributes

If a cookie contains an invalid attribute the current code throws an System.IndexOutOfRangeException.
Why are attributes other then HttpOnly and Secure not accepted?
I see this error frequently in my logging, so I propose to just ignore all attributes.

Let's get this in! Thanks :heart:


Pass correct option (--enable-external-auth) to knife-opc

Fixes #744

:shipit: We have nifty testing for files/private-chef-ctl-commands now if you feel ambitious, but probably not worth it here since this file has zero coverage and it'd be a decent bit of work to get it in a testable state.

:+1:


Parent child component for easier animation 201

See #201 .
This branch doesn't not intend to merge into master. Tell me what do you think about this approach. Then I will clean up some code and send another pr =)

@esbullington Have a look on my latest commit.
I combined Polygon and CircleAndPolygon into VoronoiCircle but I created a layer - VoronoiCircleContainer to handle state and control hoverAnimation setting. So now VoronoiCircle remains pure.
Just one issue, I changes scatter chart api
pointRadius => circleRadius because it sounds more correct for me. If you think this change is not necessary yet(which changes api), I can make a change and amend it.
I still need some time to figure out line chart. I am also considering your idea which use wider area to cover the mouser move events.

This looks great, please feel free to go ahead and merge it.  Also, feel free to merge #203 if everything looks ok to you.  I wanted to wait until you had a chance to take a look since that PR affects a lot of the charts you've been working on.


New API, Chain.call() returns the in-flight call.

Interceptors could use this to detect if the call has been canceled, or
cancel the call, or do other things.

Love it - thanks.


split windows

grapple windows only fill the space of splits. is there an option to fill up the entire vim window?

wrong plugin.. sorry! :>


Fix documentation

@alexwaibel so I guess I should start fixing from here, right? https://staticman.net/docs/index.html
I list here a few ideas, please correct me if I don't understand correctly:

relegate the "hosted version of the platform" bit to the end with maybe a disclaimer, like "in the past this was such and such, but now we officially encourage you to host your private Staticman instance via Heroku, we're not providing any support for the legacy hosted service at the moment"
add a chapter at the beginning which displays the actual integration, maybe with a simple diagram showing the connection between the components (e.g. your site <-> staticman API <-> git repo). I think starting straight with instructions on how to setup GitHub repo is confusing
explicitly restrict the setup for which we provide support form, i.e. self hosted Heroku instance + GitHub, and just mention that it's possible to use other integrations like GitLab or even running it with some container orchestration like AWS ECS, Kubernetes etc. but we don't provide support in that case

Please add/edit whatever you think makes sense or might help coming up with a decent draft, thanks

Umm, from what I understand (I only managed to setup Staticman yesterday) there are three versions of staticman

v1 - deprecated, used to use the staticman as a collaborator
v2 - Heroku based Github
v3 - Heroku based GitHub / staticman-net GitHub application which is used without Heroku

Did I get it right? Because these are not discussed in documentation, and I picked them up from here and there from various websites and issues here. Since it is this confusing, maybe provide setup based quick-start steps in documentation considering the last two approaches.
I like the second point, visualizing (through a flow / block diagram maybe) will definitely help.

Umm, from what I understand (I only managed to setup Staticman yesterday) there are three versions of staticman
* v1 - deprecated, used to use the staticman as a collaborator

* v2 - Heroku based Github

* v3 - Heroku based GitHub / staticman-net GitHub application which is used without Heroku

Did I get it right?
Because these are not discussed in documentation, and I picked them up from here and there from various websites and issues here. Since it is this confusing, maybe provide setup based quick-start steps in documentation considering the last two approaches.
(edit: oh wait, maybe v2 is actually v3.. uh.. nvm, I am confused)
I like the second point, visualizing (through a flow / block diagram maybe) will definitely help.

You're close, but a few details aren't quite right:

V1 - Original API, used webhooks, is deprecated but still supported for now since some users are presumably still using it

V2 - API which uses tokens to authenticate with GitHub. Most stable version and what many guides are written for

V3 - Newest API, intended to add authentication as a GitHub App rather than using a personal access token. Adds supports for GitLab as well.

All of these require some kind of hosting. Even V3 as a GH App requires that the application be hosted somewhere (we recommend Heroku). We definitely need better API docs and I'm hoping to leverage something like Swagger to help document this stuff. Having up to date API docs should go a long way towards clarifying all the endpoints Staticman offers.

@alexwaibel so I guess I should start fixing from here, right? https://staticman.net/docs/index.html

Yes, this is a good place to start updating.

I list here a few ideas, please correct me if I don't understand correctly:

* relegate the "hosted version of the platform" bit to the end with maybe a disclaimer, like "in the past this was such and such, but now we officially encourage you to host your private Staticman instance via Heroku, we're not providing any support for the legacy hosted service at the moment"

I think we should stop mentioning the public instance in the docs all together. This instance is not being actively maintained and we offer no guarantees that we'll fix it if it ever goes down. No new users should be using this and as such I think it's best to leave it out of the docs. Anyone using that instance should immediately migrate to a self-hosted solution. I would write the docs as if self-hosting is the only option.

* add a chapter at the beginning which displays the actual integration, maybe with a simple diagram showing the connection between the components (e.g. your site <-> staticman API <-> git repo). I think starting straight with instructions on how to setup GitHub repo is confusing

Some kind of architecture and/or sequence diagrams would definitely be helpful. This would be a good addition to the docs.

* explicitly restrict the setup for which we provide support form, i.e. self hosted Heroku instance + GitHub, and just mention that it's possible to use other integrations like GitLab or even running it with some container orchestration like AWS ECS, Kubernetes etc. but we don't provide support in that case

I agree. I'd call out in the docs that the setup instructions are for Heroku + GitHub (I've never tried GitLab but I believe it works and the setup should be very similar to GitHub) and mention that Heroku is just one of many hosting options and that users can host on whatever platform they desire. We just use Heroku in the docs because that's what we've personally been using for hosting and it's the most streamlined setup at the moment.

@alexwaibel can you please review https://github.com/eduardoboucas/staticman.net/pull/11 ?

@alexwaibel can you please review eduardoboucas/staticman.net#11 ?

@alexwaibel thank you, I see you approved the PR.
I'm still confused about the dev workflow though: why is it not merged yet? do you need a certain amount of reviewers to approve it too? etc.
Thanks

I'm still confused about the dev workflow though: why is it not merged yet? do you need a certain amount of reviewers to approve it too? etc.

Sorry, I forgot to click the merge button. It's fine for you to merge in your own PRs once they have at least one approval. I'll double check that the branch protections enforce this

Related PR: https://github.com/eduardoboucas/staticman/pull/371

I am really liking how it is turning out.
One suggestion: current deploy to heroku deploys v3 of staticman. Most of the documentation I see (tutorial,staticman.net) are based on either v1 and v2, and the references I find to v3 are in issues/commits. Maybe the "howto" should focus on v3 since it offers both GitHub/gitlab approach.

@LordAmit yeah I agree. We're improving staticman.net docs too, which by the way in my opinion should become the official user documentation resource, i.e. user docs there and dev docs here.
Given that I've found no documentation about v3 yet it means that either someone else provides or points me there, or I'd have to go through the codebase (which is not too big but it will take me some time obviously).
@alexwaibel also said he wishes to add support for Open API (ex Swagger), I don't know the effort needed for that though.

I believe this is the pull request which introduced major changes for v3 and also includes the most details
https://github.com/eduardoboucas/staticman/pull/219
I am not quite sure why I was unable to setup v3 following this (or others). Some of the details are also missing there, like what prop means and why it is used.
@alexwaibel since I am very new to this repo and don't have much experience, can you please confirm that this is the correct link to find details about v3?

@LordAmit I missed this before, but indeed that post is probably a good reference for the various APIs, though it may not be 100% accurate now given how old the post is.
If by prop you mean property in the routes, I believe that is used for the top level property block in your staticman config. In the case of the provided staticman.sample.yml the property would be comments.
I know this thread is old now, but I am hoping to tackle some doc updates here soon.

Big documentation PR for this up now on the docs repo

Big documentation PR for this up now on the docs repo

The intention of introducing the v3 API scheme is due to the lack of Git service provider in v2:
/v2/entry/user/repo/branch/property

together with the request to support GitLab in #22.  If you follow the discussion four years ago, you'll see that @zburgermeiszter proposed the current link format in his comment.  That was supported by @ntsim, who authored #219 to address this feature request.
The rate limit issues about the v2/connect route #222 and #227 that inspired the proposal of using a GitHub App in #243 and resolved in #255 is another issue.

So regarding: Webhook URL: "{STATICMAN_BASE_URL}/v1/webhook" - e.x. "https://mystaticmaninstance.herokuapp.com/v1/webhook" in step 1, I'm already lost. How do I even get this? Signing up to heroku doesn't give you this link. Am I missing something?


Split out HBONE enablement

There are now three properties:

Allow sending HBONE. This is critical, and required for interop between ingress and sidecars to waypoints/ztunnel.
Listen on HBONE. This is only needed if we want to allow HBONE from ztunnel to sidecars.
Prefer to send HBONE. This is experimental and only if we want to use HBONE between sidecars. This is not needed in any way for ambient.

These are now split out to give more operational controls. In particular, users can now configure to not use HBONE between sidecars, which is excessively risky at this point.

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-security_istio
788a4ff305d701de767c93c684b21495c03f8f48
link
true
/test integ-security

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Perhaps we should listen on HBONE ( with TLS ) in all cases - because the sidecar may be on a VM without ztunnel.
And also start listening with HA-PROXY for sandwich by default - letting the other side decide to send to the node ztunnel or sidecar HBONE ?

Perhaps we should listen on HBONE ( with TLS ) in all cases - because the sidecar may be on a VM without ztunnel. And also start listening with HA-PROXY for sandwich by default - letting the other side decide to send to the node ztunnel or sidecar HBONE ?

I generally want to do this, but I don't feel confident enough with HBONE that in 1.22 all users get HBONE. That seems like its going to cause some stability issues.
However, any ambient users should install with --profile=ambient and get this out of the box without needing to think about it

Perhaps we should listen on HBONE ( with TLS ) in all cases - because the sidecar may be on a VM without ztunnel. And also start listening with HA-PROXY for sandwich by default - letting the other side decide to send to the node ztunnel or sidecar HBONE ?

This would break NetworkPolicy - so it cannot be the default for sidecars when ambient is not used. Because the control plane is shared, and it seems that ambient will be on by default, the sidecars should have a separate control to allow custom ports for the traffic.

This would break NetworkPolicy - so it cannot be the default for sidecars when ambient is not used. Because the control plane is shared, and it seems that ambient will be on by default, the sidecars should have a separate control to allow custom ports for the traffic.

The intended default behaviors after this PR:

With ambient: All Envoy's can send and recieve HBONE. They will only send HBONE if the other side doesn't support mTLS (i.e. it is ztunnel or waypoint)
Without ambient: nothing uses HBONE at all

Given this, I don't think we are breaking NetPol really because we are not sending HBONE where its not required.
My current expectation is that ambient would not be on by default, and would required the --profile=ambient installation

I agree with (most) of the intended behavior - but not with how the state
is determined.
"Ambient" doesn't only mean you installed with --profile=ambient - or
whatever is the helm equivalent.
You may have a revision using ambient and one without ambient for example,
or a cluster using ambient and one using sidecars.
Once you install ztunnel and CNI with ztunnel - I think it is reasonable to
expect something may use ztunnel, and if we don't have the listener - the
mesh is broken.
We need one setting to clearly indicate the intent of using ambient - to be
used with helm and any other install method. Once the setting is on, it
means
something in the mesh is using HBONE, and listeners should be generated in
envoy.
What I slightly disagree ( or perhaps it's not clear ) is on Envoy having
to send/receive HBONE when talking to workloads that only support hbone
(ztunnel/waypoint).
IMO the requirement is that Envoy (sidecar or gateway) can securely
communicate with ztunnel/waypoint workloads. As a client, it is
perfectly fine to use
original dst and let ztunnel handle ambient L4 details. As a server - until
HA-PROXY and associated stuff lands we must do the full HBONE, but there
should
be no guarantee we'll have this long term ( depending on the result of perf
and other tests ).
@Kuat Yessenov @.***> - if the user enables ambient ( in any way
) - they should expect NetworkPolicy and any behavior defined by ambient to
be in effect.
With Istio multi-cluster NetworkPolicy is also broken - both by east-west
and by the cross-cluster load balancing ( since K8S NetworkPolicy is
cluster-wide by default)
On Mon, Apr 15, 2024 at 9:34 AM John Howard @.***>
wrote:

This would break NetworkPolicy - so it cannot be the default for sidecars
when ambient is not used. Because the control plane is shared, and it seems
that ambient will be on by default, the sidecars should have a separate
control to allow custom ports for the traffic.
The intended default behaviors after this PR:

With ambient: All Envoy's can send and recieve HBONE. They will only
send HBONE if the other side doesn't support mTLS (i.e. it is ztunnel or
waypoint)
Without ambient: nothing uses HBONE at all

Given this, I don't think we are breaking NetPol really because we are not
sending HBONE where its not required.
My current expectation is that ambient would not be on by default, and
would required the --profile=ambient installation
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50360#issuecomment-2057296444, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2RBS4O5R7GRZAKZHLTY5P6RVAVCNFSM6AAAAABGBB6UV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXGI4TMNBUGQ
.
You are receiving this because your review was requested.Message ID:
@.***>

With ambient: All Envoy's can send and recieve HBONE. They will only send HBONE if the other side doesn't support mTLS (i.e. it is ztunnel or waypoint)

I'm worried about the receiving side. Sending is fine, but if sidecars can suddenly accept traffic on a different port (even when it's not the default), that's a problem. We cannot break NetworkPolicy for sidecars because solutions are built on top of both that expect them to work together.
Ambient fundamentally breaks any other implementation of NetworkPolicy besides Ambient, so people are aware of the risks. Sidecars should not take that risk.

Ambient fundamentally breaks any other implementation of NetworkPolicy besides Ambient, so people are aware of the risks. Sidecars should not take that risk.

What alternative do we have? If we don't do this, you cannot run a sidecar in a cluster that uses ambient.
And users are opting into these risks by adopting ambient -- I am NOT proposing we make this default for all users

What alternative do we have? If we don't do this, you cannot run a sidecar in a cluster that uses ambient. And users are opting into these risks by adopting ambient -- I am NOT proposing we make this default for all users

It needs to be opt-in for sidecars - with a comment that it may violate the network policy. Yes, it'll break the ambient connectivity, but that's the price of the backwards compatibility.

It needs to be opt-in for sidecars

You mean on top of opting into ambient explicitly, we would add a flag like --enable-sidecars-with-ambient?

It needs to be opt-in for sidecars

You mean on top of opting into ambient explicitly, we would add a flag like --enable-sidecars-with-ambient?

Either opt-in as a whole mesh via ambient flag (with an understanding that existing sidecar meshes will not integrate).
Or opt-in per namespace, with an understanding that network policy in those namespaces breaks.
Or opt-in per individual sidecar, for some bridging between the sidecar network and the ambient network.
I agree that it doesn't make sense to migrate existing sidecars to HBONE at this point - doesn't bring much benefit with respect to ambient, and causes trouble during updates.

Either opt-in as a whole mesh via ambient flag (with an understanding that existing sidecar meshes will not integrate).

This is what the PR implements, is there a concern here?

Either opt-in as a whole mesh via ambient flag (with an understanding that existing sidecar meshes will not integrate).

This is what the PR implements, is there a concern here?

No, it's fine I'd suggest expanding the variables PILOT_ENABLE_SIDECAR_LISTEN_HBONE, so it's less ambiguous.

Either opt-in as a whole mesh via ambient flag (with an understanding that existing sidecar meshes will not integrate).

This is what the PR implements, is there a concern here?

No, it's fine I'd suggest expanding the variables PILOT_ENABLE_SIDECAR_LISTEN_HBONE, so it's less ambiguous.

:+1: , renamed it

Kuat:

NetworkPolicy is already broken with Istio multicluster.
We can call the flag "DONT_BREAK_MY_MESH" or something like that: once
the user has opted in ambient (by installing ztunnel and cni with ambient
enabled),
there is no way for the mesh to keep working if a client using ztunnel
calls a server using sidecar.

I don't think we can ship with a setting that leaves the communication
broken.
We can document clearly that once you install Ambient ( ztunnel ) or if you
use multi-cluster NetworkPolicy is broken, so users know what to
expect. But we can't have workloads failing to communicate.
On Mon, Apr 15, 2024 at 10:06 AM Kuat @.***> wrote:

It needs to be opt-in for sidecars
You mean on top of opting into ambient explicitly, we would add a flag
like --enable-sidecars-with-ambient?
Either opt-in as a whole mesh via ambient flag (with an understanding that
existing sidecar meshes will not integrate).
Or opt-in per namespace, with an understanding that network policy in
those namespaces breaks.
Or opt-in per individual sidecar, for some bridging between the sidecar
network and the ambient network.
I agree that it doesn't make sense to migrate existing sidecars to HBONE
at this point - doesn't bring much benefit with respect to ambient, and
causes trouble during updates.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50360#issuecomment-2057413082, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2UYTNWUIYNLFLIWZZ3Y5QCJDAVCNFSM6AAAAABGBB6UV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXGQYTGMBYGI
.
You are receiving this because your review was requested.Message ID:
@.***>

In other words: from a user perspective they either are in an ambient
cluster - where the expectations are based on ambient ( no NetworkPolicy,
etc),
or in a non-ambient cluster.
We should not listen HBONE in a non-ambient cluster - there is no need for
it.
And we can't have an ambient cluster with sidecars not listening on HBONE.
Since this impacts security and reliability - it must be very clear for the
users, and not based on implementation details.
I don't mind if we keep some internal env variables ( not sure for what
purpose - since we'll unlikely test all combinations and
probably few will understand what setting individual envs will do ).
My concern with the 'profile' is that it's specific to istioctl and has a
bunch of non-very-stable settings. If they are only tested together - we
should
have a single on/off flag that user can set with helm or when running
istiod manually.
On Mon, Apr 15, 2024 at 12:10 PM Costin Manolache @.***> wrote:

Kuat:

NetworkPolicy is already broken with Istio multicluster.
We can call the flag "DONT_BREAK_MY_MESH" or something like that: once
the user has opted in ambient (by installing ztunnel and cni with ambient
enabled),
there is no way for the mesh to keep working if a client using ztunnel
calls a server using sidecar.

I don't think we can ship with a setting that leaves the communication
broken.
We can document clearly that once you install Ambient ( ztunnel ) or if
you use multi-cluster NetworkPolicy is broken, so users know what to
expect. But we can't have workloads failing to communicate.
On Mon, Apr 15, 2024 at 10:06 AM Kuat @.***> wrote:

It needs to be opt-in for sidecars
You mean on top of opting into ambient explicitly, we would add a flag
like --enable-sidecars-with-ambient?
Either opt-in as a whole mesh via ambient flag (with an understanding
that existing sidecar meshes will not integrate).
Or opt-in per namespace, with an understanding that network policy in
those namespaces breaks.
Or opt-in per individual sidecar, for some bridging between the sidecar
network and the ambient network.
I agree that it doesn't make sense to migrate existing sidecars to HBONE
at this point - doesn't bring much benefit with respect to ambient, and
causes trouble during updates.
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50360#issuecomment-2057413082, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2UYTNWUIYNLFLIWZZ3Y5QCJDAVCNFSM6AAAAABGBB6UV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXGQYTGMBYGI
.
You are receiving this because your review was requested.Message ID:
@.***>

My concern with the 'profile' is that it's specific to istioctl and has a
bunch of non-very-stable settings. If they are only tested together - we
should
have a single on/off flag that user can set with helm or when running
istiod manually.

Its not an istioctl specific thing, it applies to helm as well. Helm and istioctl are the only supported install methods (others, like Argo, build on top of helm), so all install methods can use profiles.
Effectively the env vars are internal flags.
The alternative would be to just have one single "enable ambient" flag, which I suppose I don't mind but it limits flexibility a lot

On Mon, Apr 15, 2024 at 12:18 PM John Howard @.***>
wrote:

My concern with the 'profile' is that it's specific to istioctl and has a
bunch of non-very-stable settings. If they are only tested together - we
should
have a single on/off flag that user can set with helm or when running
istiod manually.
Its not an istioctl specific thing, it applies to helm as well. Helm and
istioctl are the only supported install methods (others, like Argo, build
on top of helm), so all install methods can use profiles.
Effectively the env vars are internal flags.
The alternative would be to just have one single "enable ambient" flag,
which I suppose I don't mind but it limits flexibility a lot

I don't mind having flexibility - as long as it's tested and documented.
As a user - or as a developer - I don't understand the semantics of various
combinations of the flags, and I don't think we have tests for such
combinations - just for 'ambient profile'.
You are saying 'internal flags' - and that's what every env variable was at
the start - yet we see very well (DNS and many others) that users don't
really consider
them 'internal'.
How about: one 'master' setting, with the meaning "I want to use ambient" -
with 'internal' options to fine tune how that operates ( and clear docs on
when they would be used).
If 'I want to use ambient' is off - all other settings should be off.
If it is 'on' - they should be in the tested state and the mesh should not
be broken.
Developers/users may still disable individual features - for testing or
'flexibility' - but with some clear documentation that it's not tested,
supported ( unless it is ) and it will break
stuff.

Message ID: @.***>

How about: one 'master' setting, with the meaning "I want to use ambient" -
with 'internal' options to fine tune how that operates ( and clear docs on
when they would be used).

That is exactly what this PR, IMO, implements. So I 100% agree -- if there is a better way to implement that can you give more specific suggestions? Its hard for me to make changes to implement it this way since I feel like I already did?

My suggestion would be for ambient_profile to have a single setting
ENABLE_AMBIENT=true
In code, you can keep the other 4 settings - but the code should be 'if
enable_ambient && XXX'.
Default value for enable_ambient would be false - all others would be true.
If a user wants 'ambient' and for some reason disable ambient controllers
or disable waypoints or HBONE listener - they can still do it, with
some TBD result.
On Mon, Apr 15, 2024 at 1:10 PM John Howard @.***>
wrote:

How about: one 'master' setting, with the meaning "I want to use ambient" -
with 'internal' options to fine tune how that operates ( and clear docs on
when they would be used).
That is exactly what this PR, IMO, implements. So I 100% agree -- if there
is a better way to implement that can you give more specific suggestions?
Its hard for me to make changes to implement it this way since I feel like
I already did?
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/50360#issuecomment-2057718285, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2WBB3KRQTW3PEPQJKTY5QX2ZAVCNFSM6AAAAABGBB6UV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXG4YTQMRYGU
.
You are receiving this because your review was requested.Message ID:
@.***>

My suggestion would be for ambient_profile to have a single setting ENABLE_AMBIENT=true In code, you can keep the other 4 settings - but the code should be 'if enable_ambient && XXX'. Default value for enable_ambient would be false - all others would be true. If a user wants 'ambient' and for some reason disable ambient controllers or disable waypoints or HBONE listener - they can still do it, with some TBD result.
…
On Mon, Apr 15, 2024 at 1:10 PM John Howard @.> wrote: How about: one 'master' setting, with the meaning "I want to use ambient" - with 'internal' options to fine tune how that operates ( and clear docs on when they would be used). That is exactly what this PR, IMO, implements. So I 100% agree -- if there is a better way to implement that can you give more specific suggestions? Its hard for me to make changes to implement it this way since I feel like I already did? — Reply to this email directly, view it on GitHub <#50360 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUR2WBB3KRQTW3PEPQJKTY5QX2ZAVCNFSM6AAAAABGBB6UV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXG4YTQMRYGU . You are receiving this because your review was requested.Message ID: @.>

I've implemented this, PTAL.

PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-basic-arm64

unit-tests-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests-arm64

integ-operator-controller_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-operator-controller

integ-ipv6_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ipv6

integ-helm_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-helm

gencheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test gencheck

integ-cni_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-cni

integ-ambient_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ambient

integ-distroless_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-distroless

integ-ds_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ds

integ-pilot_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot

integ-pilot-istiodremote-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote-mc

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-basic-arm64

unit-tests-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests-arm64

integ-operator-controller_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-operator-controller

integ-ipv6_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ipv6

integ-helm_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-helm

gencheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test gencheck

integ-cni_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-cni

integ-ambient_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ambient

integ-distroless_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-distroless

integ-ds_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ds

integ-pilot_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot

integ-pilot-istiodremote-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote-mc

release-notes_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-notes

integ-telemetry-discovery_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-discovery

integ-security_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security

integ-telemetry_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry

release-test_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-test

lint_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test lint

integ-pilot-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-multicluster

macbuildcheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test macbuildcheck

integ-pilot-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote

integ-security-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-multicluster

integ-security-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-istiodremote

integ-telemetry-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-mc

integ-telemetry-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-istiodremote

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-basic-arm64

unit-tests-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests-arm64

integ-operator-controller_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-operator-controller

integ-ipv6_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ipv6

integ-helm_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-helm

gencheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test gencheck

integ-cni_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-cni

integ-ambient_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ambient

integ-distroless_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-distroless

integ-ds_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ds

integ-pilot_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot

integ-pilot-istiodremote-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote-mc

release-notes_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-notes

integ-telemetry-discovery_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-discovery

integ-security_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security

integ-telemetry_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry

release-test_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-test

lint_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test lint

integ-pilot-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-multicluster

macbuildcheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test macbuildcheck

integ-pilot-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote

integ-security-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-multicluster

integ-security-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-istiodremote

integ-telemetry-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-mc

integ-telemetry-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-istiodremote

unit-tests_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-basic-arm64

unit-tests-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests-arm64

integ-operator-controller_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-operator-controller

integ-ipv6_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ipv6

integ-helm_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-helm

gencheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test gencheck

integ-cni_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-cni

integ-ambient_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ambient

integ-distroless_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-distroless

integ-ds_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ds

integ-pilot_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot

integ-pilot-istiodremote-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote-mc

release-notes_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-notes

integ-telemetry-discovery_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-discovery

integ-security_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security

integ-telemetry_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry

release-test_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-test

integ-pilot-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-multicluster

macbuildcheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test macbuildcheck

integ-pilot-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote

integ-security-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-multicluster

integ-security-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-istiodremote

integ-telemetry-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-mc

integ-telemetry-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-istiodremote

unit-tests_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests

lint_istio
2436f222167dd0052c9ac057555c63d0bc0b0a05
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-basic-arm64

integ-operator-controller_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-operator-controller

integ-ipv6_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ipv6

integ-helm_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-helm

gencheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test gencheck

integ-cni_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-cni

integ-ambient_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ambient

integ-distroless_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-distroless

integ-ds_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-ds

integ-pilot_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot

integ-pilot-istiodremote-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote-mc

release-notes_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-notes

integ-telemetry-discovery_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-discovery

integ-security_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security

integ-telemetry_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry

release-test_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test release-test

integ-pilot-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-multicluster

macbuildcheck_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test macbuildcheck

integ-pilot-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-pilot-istiodremote

integ-security-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-multicluster

integ-security-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-istiodremote

integ-telemetry-mc_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-mc

integ-telemetry-istiodremote_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-telemetry-istiodremote

unit-tests_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test unit-tests

lint_istio
2436f222167dd0052c9ac057555c63d0bc0b0a05
link
true
/test lint

unit-tests-arm64_istio
2436f222167dd0052c9ac057555c63d0bc0b0a05
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-security-multicluster_istio
a425b6a695b2f963d41f0311b62a29e9a01c4731
link
true
/test integ-security-multicluster

lint_istio
2436f222167dd0052c9ac057555c63d0bc0b0a05
link
true
/test lint

unit-tests-arm64_istio
2436f222167dd0052c9ac057555c63d0bc0b0a05
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
2436f222167dd0052c9ac057555c63d0bc0b0a05
link
true
/test integ-telemetry-discovery

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Perhaps in a separate PR we can also remove the CA setting - also I though we agreed on kube-system (or something else but 'one place' ) - so maybe we shouldn't leave both istio-system and kube-system, it's a big security setting.

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry-discovery_istio
7b3fec681982496db06c72feea679fffcf5957ba
link
true
/test integ-telemetry-discovery

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


spacemesh didn' t start after migration 1.7.1

Environment

Smapp version: 0.xx.x | develop
Node version: v1.7.1
OS: Windows 10

Describe the bug
i have this message
THE SPACEMESH NODE SOFTWARE HAS UNEXPECTEDLY QUIT. CLICK ON 'RESTART NODE' TO START IT
Steps to reproduce
i restart spacemesh but i have already this message :
THE SPACEMESH NODE SOFTWARE HAS UNEXPECTEDLY QUIT. CLICK ON 'RESTART NODE' TO START IT
Expected behavior
spacemesh start
Actual behavior
spacemesh didn' t start
Attach screenshots or GIF’s of what’s going on if it makes the issue more illustrative.
Logs
2024-09-27T13:49:30.120+0200	INFO	node	app cleanup completed
Error: open sqlite db: vacuum into C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate: step 0: sqlite.Stmt.Step: SQLITE_FULL: database or disk is full (VACUUM INTO ?1)
Error: open sqlite db: vacuum into C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate: step 0: sqlite.Stmt.Step: SQLITE_FULL: database or disk is full (VACUUM INTO ?1)
2024-09-28T00:13:07.821+0200	INFO	node	App version: v1.7.1. Git: 2983c71 - 2983c7135bbfb143c7eb7c73162771de16aeb0b8 . Go Version: go1.22.4. OS: windows-amd64 . Genesis 9eebff023abb17ccb775c602daade8ed708f0a50
2024-09-28T00:13:07.821+0200	INFO	node	Welcome to Spacemesh. Spacemesh full node is starting...
2024-09-28T00:13:07.827+0200	INFO	node	Loaded existing identity	{"filename": "local.key", "public_key": "7b5b7", "name": ""}
2024-09-28T00:13:08.009+0200	INFO	node	starting spacemesh	{"data-dir": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b", "post-dir": "D:\", "hostname": "DESKTOP-HU5T7KO", "name": ""}
2024-09-28T00:13:08.009+0200	INFO	node.clock	converting genesis time to local time	{"genesis": "2023-07-14T08:00:00.000Z", "local": "2023-07-14T10:00:00.000+0200"}
2024-09-28T00:13:08.009+0200	INFO	node	initializing p2p services
2024-09-28T00:13:08.009+0200	INFO	node.clock	starting global clock	{"now": "2024-09-28T00:13:08.009+0200", "genesis": "2023-07-14T10:00:00.000+0200", "layer_duration": "5m0s", "tick_interval": "1s"}
2024-09-28T00:13:08.359+0200	INFO	node.stateDb	running migrations	{"uri": "file:C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql", "current version": 19, "target version": 23}
2024-09-28T00:13:08.359+0200	INFO	node.stateDb	making a temporary copy of the database	{"path": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql", "target": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate"}
2024-09-28T00:32:07.382+0200	INFO	node	App version: v1.7.1. Git: 2983c71 - 2983c7135bbfb143c7eb7c73162771de16aeb0b8 . Go Version: go1.22.4. OS: windows-amd64 . Genesis 9eebff023abb17ccb775c602daade8ed708f0a50
2024-09-28T00:32:07.382+0200	INFO	node	Welcome to Spacemesh. Spacemesh full node is starting...
2024-09-28T00:32:07.414+0200	INFO	node	Loaded existing identity	{"filename": "local.key", "public_key": "7b5b7", "name": ""}
2024-09-28T00:32:07.469+0200	INFO	node	starting spacemesh	{"data-dir": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b", "post-dir": "D:\", "hostname": "DESKTOP-HU5T7KO", "name": ""}
2024-09-28T00:32:07.469+0200	INFO	node.clock	converting genesis time to local time	{"genesis": "2023-07-14T08:00:00.000Z", "local": "2023-07-14T10:00:00.000+0200"}
2024-09-28T00:32:07.469+0200	INFO	node	initializing p2p services
2024-09-28T00:32:07.474+0200	INFO	node.clock	starting global clock	{"now": "2024-09-28T00:32:07.474+0200", "genesis": "2023-07-14T10:00:00.000+0200", "layer_duration": "5m0s", "tick_interval": "1s"}
2024-09-28T00:32:07.565+0200	WARN	node.stateDb	incomplete migration detected, deleting the temporary DB	{"path": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate"}
2024-09-28T00:32:09.772+0200	INFO	node.stateDb	running migrations	{"uri": "file:C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql", "current version": 19, "target version": 23}
2024-09-28T00:32:09.775+0200	INFO	node.stateDb	making a temporary copy of the database	{"path": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql", "target": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate"}
2024-09-28T01:43:04.536+0200	ERROR	node	failed to start App	{"errmsg": "open sqlite db: vacuum into C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate: step 0: sqlite.Stmt.Step: SQLITE_FULL: database or disk is full (VACUUM INTO ?1)", "name": ""}
2024-09-28T01:43:04.757+0200	INFO	node	app cleanup starting...
2024-09-28T01:43:05.190+0200	INFO	node	app cleanup completed
Error: open sqlite db: vacuum into C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate: step 0: sqlite.Stmt.Step: SQLITE_FULL: database or disk is full (VACUUM INTO ?1)
Error: open sqlite db: vacuum into C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate: step 0: sqlite.Stmt.Step: SQLITE_FULL: database or disk is full (VACUUM INTO ?1)
2024-09-28T09:40:52.501+0200	INFO	node	App version: v1.7.1. Git: 2983c71 - 2983c7135bbfb143c7eb7c73162771de16aeb0b8 . Go Version: go1.22.4. OS: windows-amd64 . Genesis 9eebff023abb17ccb775c602daade8ed708f0a50
2024-09-28T09:40:52.501+0200	INFO	node	Welcome to Spacemesh. Spacemesh full node is starting...
2024-09-28T09:40:52.501+0200	INFO	node	Loaded existing identity	{"filename": "local.key", "public_key": "7b5b7", "name": ""}
2024-09-28T09:40:52.585+0200	INFO	node	starting spacemesh	{"data-dir": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b", "post-dir": "D:\", "hostname": "DESKTOP-HU5T7KO", "name": ""}
2024-09-28T09:40:52.585+0200	INFO	node.clock	converting genesis time to local time	{"genesis": "2023-07-14T08:00:00.000Z", "local": "2023-07-14T10:00:00.000+0200"}
2024-09-28T09:40:52.585+0200	INFO	node	initializing p2p services
2024-09-28T09:40:52.585+0200	INFO	node.clock	starting global clock	{"now": "2024-09-28T09:40:52.585+0200", "genesis": "2023-07-14T10:00:00.000+0200", "layer_duration": "5m0s", "tick_interval": "1s"}
2024-09-28T09:40:52.963+0200	INFO	node.stateDb	running migrations	{"uri": "file:C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql", "current version": 19, "target version": 23}
2024-09-28T09:40:52.963+0200	INFO	node.stateDb	making a temporary copy of the database	{"path": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql", "target": "C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate"}
How to fix
If you have an idea of how the bug can be fixed, provide a short description.

Hey @ludolinde,
The actual problem is mentioned in the logs you have attached:

Error: open sqlite db: vacuum into C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\state.sql_migrate: step 0: sqlite.Stmt.Step: SQLITE_FULL: database or disk is full (VACUUM INTO ?1)

It tells that you don't have enough disk space to migrate the database.
You can check that you don't have a lot of stale backups there C:\Users\DARD\AppData\Roaming\Spacemesh\node-data\7c8cef2b\. Delete if you have some to free disk space
If you cannot get enough free disk space, then the only option is to remove current db and run quicksync (to download already migrated db).


🎉 3.0.5

ℹ About this release

Version: 3.0.5
Type: patch
Last Release: 3.0.4 (10/14/2022, 4:55:48 AM) [?]
Commits to merge: 46 [?]

📦 Dependencies

Update puppeteer from ^18.2.1 to ^19.3.0

📦 Development Dependencies

Update @sebbo2002/semantic-release-docker from ^2.0.1 to ^2.1.0-develop.1
Update @semantic-release/changelog from ^6.0.1 to ^6.0.2
Update @types/mocha from ^10.0.0 to ^10.0.1
Update @types/node from ^18.7.14 to ^18.11.11
Update eslint from ^8.23.1 to ^8.29.0
Update eslint-plugin-jsonc from ^2.4.0 to ^2.5.0
Update mocha from ^10.0.0 to ^10.1.0
Update rollup from ^2.79.1 to ^3.6.0

:tada: This PR is included in version 3.0.5 :tada:
The release is available on:

v3.0.5
GitHub release
Docker container (sebbo2002/fileee-backup-downloader:3.0.5)
v3.0.5

Your semantic-release bot :package::rocket:


Describe the feature
test
Benefits

Improve usability...
Increase efficiency...
Enhance user experience...

Context
test
Confirmations

[X] I have followed the Code of Conduct
[X] I have checked that there isn't already a similar feature request to avoid creating a duplicate.

done


Stubbing Intl makes vi.useFakeTimer crashing

Describe the bug
When stubbing the global Intl and replacing it by a partial copy of it, as follow:
import { test, vi } from "vitest";

const UntouchedIntl = Intl;
test("My test (not working #2)", () => {
  vi.stubGlobal("Intl", { ...UntouchedIntl });
  vi.useFakeTimers();
});

We make vi.useFakeTimer resulting into the error:
TypeError: Cannot read properties of undefined (reading 'prototype')

Reproduction
I put multiple reproductions in the repository: https://github.com/dubzzz/bug-vitest-intl. By iterating over my initial test case that was aiming into stubbing Intl.NumberFormat to make sure it always relies on the US local, I reached several sub-cases with some working and others not working.
Something pretty interesting is that the stub is only causing troubles if done before the call to vi.useFakeTimer.
This one crashes:
import { test, vi } from "vitest";

const UntouchedIntl = Intl;
test("My test (not working #2)", () => {
  vi.stubGlobal("Intl", { ...UntouchedIntl });
  vi.useFakeTimers();
});

This one does not crash:
import { test, vi } from "vitest";

const UntouchedIntl = Intl;
test("My test (working #1)", () => {
  vi.useFakeTimers();
  vi.stubGlobal("Intl", { ...UntouchedIntl });
});

This one does not crash:
import { test, vi } from "vitest";

const UntouchedIntl = Intl;
test("My test (working #2)", () => {
  vi.stubGlobal("Intl", UntouchedIntl);
  vi.useFakeTimers();
});

Please note that my initial attempt (I'm gonna add it into the repo too) was only trying to spy on Intl.NumberFormat but it actually made the produced formatters fail when called on format in some cases. But so far I've not been able to restrict this case to something smaller that I can share.
System Info
System:
    OS: Linux 6.5 Ubuntu 20.04.6 LTS (Focal Fossa)
    CPU: (2) x64 Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz
    Memory: 5.49 GB / 7.74 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 20.17.0 - ~/nvm/current/bin/node
    Yarn: 1.22.22 - /usr/bin/yarn
    npm: 10.8.2 - ~/nvm/current/bin/npm
    pnpm: 9.11.0 - ~/nvm/current/bin/pnpm
  npmPackages:
    vitest: ^2.1.8 => 2.1.8

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

The crash seems to happen here:
	        ClockIntl.DateTimeFormat.prototype = Object.create(
	            NativeIntl.DateTimeFormat.prototype // undefined
	        );

What do you think about the idea of making sure that we use the untouched global and not one that may have been touched before we access it? We could rewrite SafeIntl that way const SafeIntl = typeof Intl !== 'undefined' ? Intl : undefined and then only rely on this instance.

In case other people face the same issue in the future, I have two working workarounds.

Option 1
We just make the stub a little bit more complex but we only rely on the primitives offered by Vitest.
import { test, vi } from "vitest";

const UntouchedIntl = Intl;
const UntouchedIntlDescriptors = Object.getOwnPropertyDescriptors(Intl);

test("My test (working #4)", () => {
  const defaultLocale = "en-US";
  const NewIntl = {};
  Object.defineProperties(NewIntl, {
    ...UntouchedIntlDescriptors,
    NumberFormat: {
      ...UntouchedIntlDescriptors.NumberFormat,
      value: class extends UntouchedIntl.NumberFormat {
        constructor(...args) {
          if (args.length < 1) {
            super(defaultLocale);
          } else {
            const [locales, ...otherParams] = args;
            if (
              typeof locales === "string" ||
              (Array.isArray(locales) && locales.length !== 0)
            ) {
              super(...args);
            } else {
              super(defaultLocale, ...otherParams);
            }
          }
        }
      },
    },
  });
  vi.stubGlobal("Intl", NewIntl);
  vi.useFakeTimers();
});

Option 2
We bypass Vitest and pollute the prototype in a global way.
// in vitest.setup.js

const defaultLocale = "en-US";
Intl.NumberFormat = class extends Intl.NumberFormat {
  constructor(...args) {
    if (args.length < 1) {
      super(defaultLocale);
    } else {
      const [locales, ...otherParams] = args;
      if (
        typeof locales === "string" ||
        (Array.isArray(locales) && locales.length !== 0)
      ) {
        super(...args);
      } else {
        super(defaultLocale, ...otherParams);
      }
    }
  }
};

What do you think about the idea of making sure that we use the untouched global and not one that may have been touched before we access it? We could rewrite SafeIntl that way const SafeIntl = typeof Intl !== 'undefined' ? Intl : undefined and then only rely on this instance.
If acceptable I can work on providing such fix, if you are ok with the idea.

I think if anything, this should be done on sinon side. I don't think this is an issue with Vitest, the stubGlobal just does this internally:
globalThis[key] = value


Fix a small bug in the calculation of result statistics.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

7 of 7 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 64.513%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
2167

Relevant Lines:
3359

💛  - Coveralls


Question about the scale of style loss and content loss

Hi, gordicaleksa! This is a really impressive work. I have a question about the scale of style loss and content loss. I have implemented my own feedforward network, but the value of style loss and content loss are beyond 1e8 or 1e9, why the losses in your network are only 1~15?

Hi! Thanks! Sorry for the slow reply I didn't get the notification.
Basically I experimented with it. I see over and over again people just copying other people's coefficients but I didn't like it as it seemed arbitrary. I think it has to do also with the fact that I avoided obscure divisions and normalization that some other implementations use, trying to make it as simple as possible. Only apply MSE with mean reduction and that's it.
This is especially true for my implementation of the original NST code (by Gatys et al.). Hope that answers your question!

Thank you very much for your reply, I think my problem is because the input range of the vgg model I use is between 0-255


Unable to autoload constant Engine in LinkBuilder#build_engine_name

Hi guys,
The line 58 from link_builder.rb gives the following error (Unable to autoload constant Engine) when used with another gem containing an engine.rb file.
 "#{ scopes.first.to_s.camelize }::Engine".safe_constantize

To reproduce this issue:

clone duboff/peeps
run the server
visit /api/contacts

This issue was first opened on this repo, but I think it should actually be fixed here as this could happen with any rails engine having a  file named engine.rb.
In this case, the autoloader expect lib/knock/engine.rb to define an Engine constant, even though by convention it is namespaced as Knock::Engine.
Somehow I feel like this is actually a weird behaviour from the autoloader, but maybe it would still be good to add a rescue here anyway or something like this.
If you think there is actually something wrong in my code, don't hesitate to reopen the issue on my side and letting me know what you think.
Cheers!

why is this issue closed? what was the resolution?

@christophermlne This issue is still open. It was issue in the nsarno/knock project that is closed.

my bad.

Has this been fixed? Is there a workaround of any kind?

I'm not aware of anything yet. I'll try and see if I can submit a PR here in the coming weeks.

A workaround for the time being is to create an initializer containing:
module JSONAPI
  class LinkBuilder
    private

    def build_engine_name
      scopes = module_scopes_from_class(primary_resource_klass)

      unless scopes.empty?
        begin
          "#{ scopes.first.to_s.camelize }::Engine".safe_constantize
        rescue LoadError => e
        end
      end
    end
  end
end

I ran into the same issue with:
rails <IP_ADDRESS>
jsonapi-resources 0.8.1
knock 2.0

The fix by @alessandro1997 above worked.

This is an autoloader issue. The Rails guide covers it here. There may be another way to check if the controller is from an Engine or not without relying on LoadError to be thrown (going to look into this) but as the code stands, just wrapping this in a begin/rescue to catch it should be fine. If the controller is part of an engine, the proper engine paths and urls are formatted, and if not, the expected LoadError from the Rails autoloader is caught and non engine paths and urls are formatted.
Should I look for an alternative way to handle the Engine check? Or is the fix by @alessandro1997 okay to be put into a PR?

It would be nice if someone maintaining this project would attempt to address this issue.  I don't like the idea of a monkey patch long term.  1 1/2 years is a long time for this not to be at least acknowledged by the maintainers.

@hoverlover I'll see what I can do, but it's a relatively low priority for me since I don't use engines and I'm not sure how to demonstrate the issue off the top of my head. Any help such as a failing test in a PR would be appreciated.

This issue is with knock and not jsonapi-resources so it should be closed here.  It can be reproduced without jsonapi-resources.

Just confirmed what @tindron said the issue is on the knock side. 👍


Add unique user-agent to HTTP(S) probes

Describe the feature you'd like and the problem it will solve
Description of what you want to happen and what problem will it solve for you.
Hello Manu,
It would be helpful for those debugging to have an option unique value in a User-Agent request header on HTTP(S) probes that could be logged to the output in event of probe timeout or failure to assist in debugging on the server side. We've been seeing occasional unusual timeouts to some of our services while using the probes and could use these headers (if logged) to better investigate the issue in the future.

Will something like the following work:
https://github.com/cloudprober/cloudprober/pull/317/files
You'd like it to be logged at the server side, right?

Hey @zmailloux, can you confirm if something like above will be help close this issue?


⚠ Bofrost.fr has degraded performance

In 1b60840, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1046 ms

Resolved: Bofrost.fr performance has improved in 1db66fa after 6 minutes.


VScode source controller showing laradock modified but no file modified when git status is run

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.82.3 (user setup)
OS Version: Windows_NT x64 10.0.22621
Commit: fdb98833154679dbaa7af67a5a29fe19e55c2b73
Date: 2023-10-02T10:51:22.294Z
Electron: 25.8.1
ElectronBuildId: 24153832
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621

Type: Bug

Source control shows as laradock folder modified

Git status shows  "On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean"

Tried git stash it shows "No local changes to save"

The entries in the "Source Control" view are being rendered based on the output of git status.  Could you try both of these commands in the terminal and see if they return the "laradock" folder? Thanks!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


The browser UI  http://{host_ip}:5173 not responding to the queries

My current running setup:

UI is not responding to the submitted queries:

Please let me know if you need any additional information.

Hi Skuma31,  should be similar issue  #https://github.com/opea-project/GenAIExamples/issues/281, please check if the server connect is ok

Duplicated issues.
Mega service does not work. It's expected UI gets no response, no data.

It is working now. Thank you.


ShaderCompile support is disabled

There must be an error in vsgFramework.
When running CMake, support for ShaderCompile in vsg is disabled because glslang is not found.
cmake -G "NMake Makefiles JOM"  -DCMAKE_INSTALL_PREFIX="D:/project/vk/debug/msvc2022" -DCMAKE_INCLUDE_PATH="D:/project/vk/debug/msvc2022/include" -DCMAKE_LIBRARY_PATH="D:/project/vk/debug/msvc2022/lib" -DCMAKE_PREFIX_PATH="D:/project/vk/debug/msvc2022" -DCMAKE_BUILD_TYPE=Debug ..
-- The C compiler identification is MSVC 19.38.33133.0
-- The CXX compiler identification is MSVC 19.38.33133.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: D:/VS2022-Professional-Installation/VC/Tools/MSVC/14.38.33130/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: D:/VS2022-Professional-Installation/VC/Tools/MSVC/14.38.33130/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Found Threads: TRUE
-- Found Vulkan: D:/VulkanSDK/<IP_ADDRESS>/Lib/vulkan-1.lib (found version "1.3.231") found components: glslc glslangValidator
-- Populating glslang
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: D:/project/vk/git/vsgFramework/build-debug/components/glslang-subbuild
[ 11%] ←[34m←[1mCreating directories for 'glslang-populate'←[0m
[ 22%] ←[34m←[1mPerforming download step (git clone) for 'glslang-populate'←[0m
Cloning into 'glslang-src'...
remote: Enumerating objects: 56996, done.
remote: Counting objects: 100% (227/227), done.
remote: Compressing objects: 100% (136/136), done.
remote: Total 56996 (delta 117), reused 164 (delta 90), pack-reused 56769
Receiving objects: 100% (56996/56996), 74.65 MiB | 5.58 MiB/s, done.
Resolving deltas: 100% (47877/47877), done.
Your branch is up to date with 'origin/main'.
Already on 'main'
[ 33%] ←[34m←[1mPerforming update step for 'glslang-populate'←[0m
[ 44%] ←[34m←[1mNo patch step for 'glslang-populate'←[0m
[ 55%] ←[34m←[1mNo configure step for 'glslang-populate'←[0m
[ 66%] ←[34m←[1mNo build step for 'glslang-populate'←[0m
[ 77%] ←[34m←[1mNo install step for 'glslang-populate'←[0m
[ 88%] ←[34m←[1mNo test step for 'glslang-populate'←[0m
[100%] ←[34m←[1mCompleted 'glslang-populate'←[0m
[100%] Built target glslang-populate
-- Trying to find local SPIR-V tools
-- optimizer enabled
-- Found Python3: D:/python-3.12.3/python.exe (found version "3.12.3") found components: Interpreter
-- Populating vsg
-- Configuring done (0.1s)
-- Generating done (0.0s)
-- Build files have been written to: D:/project/vk/git/vsgFramework/build-debug/components/vsg-subbuild
[ 11%] ←[34m←[1mCreating directories for 'vsg-populate'←[0m
[ 22%] ←[34m←[1mPerforming download step (git clone) for 'vsg-populate'←[0m
Cloning into 'vsg-src'...
remote: Enumerating objects: 48625, done.
remote: Counting objects: 100% (2695/2695), done.
remote: Compressing objects: 100% (627/627), done.
remote: Total 48625 (delta 1707), reused 2420 (delta 1627), pack-reused 45930
Receiving objects: 100% (48625/48625), 30.17 MiB | 4.80 MiB/s, done.
Resolving deltas: 100% (33899/33899), done.
Already on 'master'
Your branch is up to date with 'origin/master'.
[ 33%] ←[34m←[1mPerforming update step for 'vsg-populate'←[0m
[ 44%] ←[34m←[1mNo patch step for 'vsg-populate'←[0m
[ 55%] ←[34m←[1mNo configure step for 'vsg-populate'←[0m
[ 66%] ←[34m←[1mNo build step for 'vsg-populate'←[0m
[ 77%] ←[34m←[1mNo install step for 'vsg-populate'←[0m
[ 88%] ←[34m←[1mNo test step for 'vsg-populate'←[0m
[100%] ←[34m←[1mCompleted 'vsg-populate'←[0m
[100%] Built target vsg-populate
-- Reading 'vsg_...' macros from D:/project/vk/git/vsgFramework/build-debug/components/vsg-src/cmake/vsgMacros.cmake - look there for documentation
-- Found Vulkan: D:/VulkanSDK/<IP_ADDRESS>/Lib/vulkan-1.lib (found suitable version "1.3.231", minimum required is "<IP_ADDRESS>") found components: glslc glslangValidator
-- Could NOT find glslang (missing: glslang_DIR)
CMake Warning at build-debug/components/vsg-src/CMakeLists.txt:52 (message):
  glslang not found.  ShaderCompile support disabled.

-- The following OPTIONAL packages have been found:

 * SPIRV-Tools
 * SPIRV-Tools-opt

-- The following REQUIRED packages have been found:

 * Python3
 * Vulkan (required version >= <IP_ADDRESS>)
 * Threads

-- The following OPTIONAL packages have not been found:

 * glslang (required version >= 14)

-- Populating assimp
-- Configuring done (0.1s)
-- Generating done (0.0s)

Looks like glslang repo is being cloned for the purposes of being built.  Could you check the contents of repositories that have been cloned within the vsgFramework is see what has been cloned locally.
When I have an opportunity I'll see if I can reproduce the issue - I don't have access my Windows machine this week as my office is being undergoing major refitting!

The content of the build directory "components" looks like this:

Hello @640kb did you find a workaround for this error, I'm running into it as well.

We haven't come up with fix for vsgFramework building it's own gslang yet, I think we'll need to replace the use of FetchContent as it's not working sufficiently well for building glslang then the VSG.
If you build and install glslang independently or install if from vcpkg or other packaging system then build vsgFramework or the VSG projects independently then vsgFramework should be build fine.


Failing with ngtemplates while minifying html contents

Can this issue be closed?

@mbenford :+1:

Closing due to inactivity.


Allow for spaces before the closing tag of a heredoc

This allows you to write heredocs that look better, especially when you
don't care about spaces in the begging of the lines, for example:
def some_method
  here = <<-HTML

Text

  HTML
end

It also makes heredocs in Crystal behave the same way as in Ruby,
leading to less surprises to people coming from that community.

Sweet! Thanks!


Bug found

I found the following bug, which puts invalid "}" at the end:
class Program
{
	public enum Gender
	{
		Unspecified = 0,
		Male = 1,
		Female = 2
	}

	static void Main(string[] args)
	{
		var result = "";
		var template = "{gender:choose(Male|Female):{last_name:choose(null):Hi,|Dear Mr {last_name},}|{last_name:choose(null):Hi,|Dear Ms {last_name},}}";

		var model1 = new
		{
			first_name = "Jane",
			last_name = "Doe",
			gender = Gender.Male
		};
		result = Smart.Format(template, model1);
		Console.WriteLine(result);

		var model2 = new
		{
			first_name = "Jane",
			last_name = "Doe",
			gender = Gender.Female
		};
		result = Smart.Format(template, model2);
		Console.WriteLine(result);

		Console.ReadLine();
	}
}

What's happening here is that }} is treated as the default escape sequence for a literal "}". And the parser is being forgiving, since it then thinks you're missing a closing brace.
The easiest workaround is to insert a space between them, like } }.
An alternative approach is to configure an alternative escape sequence, by calling
Smart.Default.Parser.UseAlternativeEscapeChar('\');


App crash when using configuration name different from Debug or Release

Describe the bug
Not sure this is a bug or just me doing something wrong, could not find documentation regarding this, but I get the following app crash when using a Configuration name different from Debug or Release:

Faulting application name: App1.exe, version: <IP_ADDRESS>, time stamp: 0x5bb69bfe
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.17763.404, time stamp: 0x5c3c199a
Exception code: 0xc000027b
Fault offset: 0x008dc0f1
Faulting process id: 0x28bc
Faulting application start time: 0x01d4ff7fbe41260f
Faulting application path: C:\xxxxx\WinUIConfig\App1\bin\x86\Debug1\AppX\App1.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: d999fdc1-4bb6-46d0-9e39-8aaf0168a949
Faulting package full name: 797cbdfa-8cfb-4c0f-9e19-79943324e67e_<IP_ADDRESS>_x86__wgcfbsqfkre0m
Faulting package-relative application ID: App

Steps to reproduce the bug
Open attached project WinUIConfig.zip and try to run the app using configuration Debug1
and platform x86. Debug1 is the same Debug default configuration with a different name. The app should crash almost immediately.
Here is debug output from when the app crashes:

Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: EETypeLoadException at memory location 0x06C7D19C.
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'.
'App1.exe' (Win32): Unloaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'.
'App1.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Runtime.WindowsRuntime.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown: 'System.TypeLoadException' in App1.exe
Exception thrown at 0x75E8C6F2 (KernelBase.dll) in App1.exe: WinRT originate error - 0x80131522 : 'System.TypeLoadException: Could not find Windows Runtime type 'Microsoft.UI.Xaml.Controls.XamlControlsResources'.
at App1.App1_XamlTypeInfo.XamlTypeInfoProvider.InitTypeTables()
at App1.App1_XamlTypeInfo.XamlTypeInfoProvider.LookupTypeIndexByName(String typeName)
at App1.App1_XamlTypeInfo.XamlTypeInfoProvider.GetXamlTypeByName(String typeName)
at App1.App1_XamlTypeInfo.XamlMetaDataProvider.GetXamlType(String fullName)
at App1.App.GetXamlType(String fullName)'.
'App1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\userenv.dll'. Cannot find or open the PDB file.
'App1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\profext.dll'. Cannot find or open the PDB file.
'App1.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\profext.dll'
'App1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\profext.dll'. Cannot find or open the PDB file.
Exception thrown at 0x75E8C6F2 (KernelBase.dll) in App1.exe: WinRT originate error - 0x802B000A : 'Cannot deserialize XBF metadata type list as 'XamlControlsResources' was not found in namespace 'Microsoft.UI.Xaml.Controls'. [Line: 0 Position: 0]'.
Windows.UI.Xaml.dll!046F1727: (caller: 0438AD7D) Exception(1) tid(3470) 80004005 Unspecified error
Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: wil::ResultException at memory location 0x06C7DEB0.
Exception thrown at 0x75E8C6F2 in App1.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Windows.UI.Xaml.dll!046F243C: (caller: 0451975E) ReturnHr(1) tid(3470) 80004005 Unspecified error
Msg:[Windows.UI.Xaml.dll!046F1727: (caller: 0438AD7D) Exception(1) tid(3470) 80004005 Unspecified error
]
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'.
'App1.exe' (Win32): Unloaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'
'App1.exe' (Win32): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'.
'App1.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\src\WinUIConfig\App1\bin\x86\Debug1\AppX\System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

App runs fine if using configuration Debug.
Expected behavior
App does not crash.
Version Info
NuGet package version: Microsoft.UI.Xaml 2.1.190405004.2

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

October 2018 Update (17763)
Yes

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Anniversary Update (14393)

Device form factor
Saw the problem?

Desktop
Yes

Mobile

Xbox

Surface Hub

IoT

Additional Context
Not sure it matters, but I noticed the generated file XamlTypeInfo.g.cs is much larger when using Debug1 (38KB) than when using Debug (6KB) .

@rbrid can you investigate this? Sounds like the app's AppxManifest.xml doesn't have a PackageDependency for Microsoft.UI.Xaml.2.1 based on the error message, but I don't know why the different configurations would be a problem.

@jevansaks Your hypothesis is correct.  I was having the exact same problem as reported, so I switched from my custom configuration back to Release, and the problem disappeared.  I then edited the Package.appxmanifest file, adding the package dependency for Microsoft.UI.Xaml.2.1 to the Dependencies section. I switched to my custom configuration and rebuilt.  My app ran without encountering the reported problem.

What area is causing this problem given that it was a missing depency in the appxmanifest? Is this a VS issue or a Nuget issue? If this isn't an issue with the WinUI nuget package itsself (which seems to be the case based on the workaround/fix), should this be marked external or closed? @ranjeshj @StephenLPeters Your thoughts?


Issue 261: Use Hierarchy diagram

https://github.com/r-yeh/grocery-spending-tracker/issues/261

Could you maybe use the name "Receipt Extraction Module" rather than "Receipt Extraction and Review"? It's what I ended up using since I don't think the "and" looks good in terms of a module name. It might give the wrong impression that there are multiple responsibilities on the module when the review part is just one of the steps of the extraction process.


Encoding failing on Arduino

I posted an issue last month #261 about an issue serializing and deserializing message with oneof. I discovered that it was a bug and had been fixed in a new one that allowed me to get everything working locally. I've moved the code over to an arduino now that I'm developing the client on and am running into a situation where the oneof is not serializing on there but is on the my local machine. I've tested this with both version 2 and 3 of the protobuf spec and 0.3.8 and master. Wondering if anyone had any ideas on how I could debug this.
This is the relevant C code.


[Snyk] Upgrade @types/node from 20.7.0 to 20.7.2

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @types/node from 20.7.0 to 20.7.2.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 2 versions ahead of your current version.
The recommended version was released 21 days ago, on 2023-09-29.

Release notes

Package name: @types/node

20.7.2 - 2023-09-29

20.7.1 - 2023-09-27

20.7.0 - 2023-09-25

    from @types/node GitHub release notes

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


cannot install from github actions

When configuring with git@github.com:Yelp/detect-secrets (as described in the README),
[INFO] Initializing environment for git@github.com:Yelp/detect-secrets.
An unexpected error has occurred: CalledProcessError: command: ('/usr/bin/git', 'fetch', 'origin', '--tags')
return code: 128
expected return code: 0
stdout: (none)
stderr:
<EMAIL_ADDRESS>Permission denied (publickey).
    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.

Check the log at /home/runner/.cache/pre-commit/pre-commit.log
Error: Process completed with exit code 3.

The workaround is using instead git://github.com/Yelp/detect-secrets

I modified the README to use https://github.com/Yelp/detect-secrets. This should also work.
Thanks for letting us know.


Include utility and vector to fix breaking build

Small issue I came across when building this library. If building umappp with code that does not already include utility and vector, the build will fail.

Thanks. Bit surprised it didn't show up previously, but the issue is clear enough.


Request: Example for MQTT + SSL

Thank you for all these helpful samples!
We have hundreds of ME310G1 in use (NB-IoT) which send data to FTP servers, and we plan to use >1000 per year. So far so good.
Now, customers really want to steer from FTP to MQTT. And all want to use MQTT with certificates for AWS or Azure.
Do you have a (MAIN_UART) sample for the use of MQTT with SSL certifcates? Some customers want to use AWS Cloud with (x.509) certificates.
I'm thinking of a combination of
https://github.com/telit/IoT-AppZone-SampleApps/tree/master/ME310G1-ME910G1-ML865G1/AppZoneSampleApps-MAIN_UART/MQTT
and
https://github.com/telit/IoT-AppZone-SampleApps/tree/master/ME310G1-ME910G1-ML865G1/AppZoneSampleApps-MAIN_UART/TLS_SSL_CLIENT
To use AWS loT Core one needs:

A public "CA File" (eg.  MyDevice1234
Optionally some Proxy stuff

And all above certificates/information have to be changeable or updatable in some way (Firmware change, programmed directly or with a transmission if possible)

Hello and thanks for your feedback!
The application you linked https://github.com/telit/IoT-AppZone-SampleApps/tree/master/ME310G1-ME910G1-ML865G1/AppZoneSampleApps-MAIN_UART/MQTT already supports SSL (you will need a firmware version 30.00.xx9 to use it properly). To use it, yoyìu will have to set https://github.com/telit/IoT-AppZone-SampleApps/blob/master/ME310G1-ME910G1-ML865G1/AppZoneSampleApps-MAIN_UART/MQTT/src/mqtt_demo.c according to your needs.
In detail, change the values of
/* SSL */
#define CACERTFILE        ""   /* Root CA file path in module filesystem (if needed) */
#define CLIENTCERTFILE    ""   /* Client certificate file path in module filesystem (if needed) */
#define CLIENTKEYFILE     ""   /* Client private key file path in module filesystem (if needed) */

#define USER_SSL_AUTH      M2MB_SSL_NO_AUTH

in order to define them to your certificate paths in the module filesystem
for example, on ME910, you could do:
/* SSL */
#define CACERTFILE        "/mod/rootCA.cer"   /* Root CA file path in module filesystem (if needed) */
#define CLIENTCERTFILE    "/mod/cert.cer"   /* Client certificate file path in module filesystem (if needed) */
#define CLIENTKEYFILE     "/mod/cert.key"   /* Client private key file path in module filesystem (if needed) */

#define USER_SSL_AUTH      M2MB_SSL_SERVER_CLIENT_AUTH

you will then have to store the certificates in the device with the AT#M2MWRITE command, for example
AT#M2MWRITE="/mod/rootCA.cer",<size_in_bytes>
you will then need to send the file content in RAW mode with a terminal after the module sends the prompt.
about your last question, you could have a file with configuration info locally stored, and use a routine in IoT core to push a new file and a restart, then the app will parse the file at the very beginning and use the new configuration. Does it sound sensible to you?
Regards

Hello and thanks for your feedback!
The application you linked https://github.com/telit/IoT-AppZone-SampleApps/tree/master/ME310G1-ME910G1-ML865G1/AppZoneSampleApps-MAIN_UART/MQTT already supports SSL (you will need a firmware version 30.00.xx9 to use it properly). To use it, yoyìu will have to set https://github.com/telit/IoT-AppZone-SampleApps/blob/master/ME310G1-ME910G1-ML865G1/AppZoneSampleApps-MAIN_UART/MQTT/src/mqtt_demo.c according to your needs.
In detail, change the values of
/* SSL */
#define CACERTFILE        ""   /* Root CA file path in module filesystem (if needed) */
#define CLIENTCERTFILE    ""   /* Client certificate file path in module filesystem (if needed) */
#define CLIENTKEYFILE     ""   /* Client private key file path in module filesystem (if needed) */

#define USER_SSL_AUTH      M2MB_SSL_NO_AUTH

in order to define them to your certificate paths in the module filesystem
for example, on ME910, you could do:
/* SSL */
#define CACERTFILE        "/mod/rootCA.cer"   /* Root CA file path in module filesystem (if needed) */
#define CLIENTCERTFILE    "/mod/cert.cer"   /* Client certificate file path in module filesystem (if needed) */
#define CLIENTKEYFILE     "/mod/cert.key"   /* Client private key file path in module filesystem (if needed) */

#define USER_SSL_AUTH      M2MB_SSL_SERVER_CLIENT_AUTH

you will then have to store the certificates in the device with the AT#M2MWRITE command, for example
AT#M2MWRITE="/mod/rootCA.cer",<size_in_bytes>
you will then need to send the file content in RAW mode with a terminal after the module sends the prompt.
about your last question, you could have a file with configuration info locally stored, and use a routine in IoT core to push a new file and a restart, then the app will parse the file at the very beginning and use the new configuration. Does it sound sensible to you?
Regards

Thank you @fabiopi-tlt !
I think you gave us good information to start with a proof-of-concept.
AT#M2MWRITE was new to us.


ffs: list payment channels

[ ] channel id
[ ] status
[ ] outgoing/incoming
[ ] value
[ ] amount redeemed

please read https://github.com/textileio/powergate/pull/437


Unbound - fatal error: failed to setup modules - 24.1.2_3

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
Hi guys,
This is a bit of an oddity I'm seeing with Unbound on 1/4 machines that are now on 24.1.2_3
When I saw the service down I went to the logs and found this:
===================
Error	unbound	Unable to open pipe. This is likely because Unbound isn't running.
Notice	unbound	Backgrounding unbound logging backend.
Critical	unbound	[74981:0] fatal error: failed to setup modules
Error	unbound	[74981:0] error: module init for module python failed
Error	unbound	[74981:0] error: pythonmod: python error: NoneType: None
Error	unbound	[74981:0] error: pythonmod: can't parse Python script dnsbl_module.py
Notice	unbound	daemonize unbound dhcpd watcher.
Notice	unbound	[74981:0] notice: init module 0: python
===================
Restarted just in case - no change.
Reinstalled unbound - and made some progress. Service still shows down in GUI but appears operational in the console yet not resolving.
The logs:
============================
Informational	unbound	[76281:0] info: start of service (unbound 1.19.1).
Notice	unbound	[76281:0] notice: init module 1: iterator
Notice	unbound	[76281:0] notice: init module 0: validator
Informational	unbound	[60338:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Informational	unbound	[60338:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Informational	unbound	[60338:0] info: service stopped (unbound 1.19.1).
Informational	unbound	[60338:0] info: start of service (unbound 1.19.1).
Notice	unbound	[60338:0] notice: init module 1: iterator
Notice	unbound	[60338:0] notice: init module 0: validator
=====================================
And SSH output
==================================
root@OPNsense:~ # pkg install -f unbound
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating mimugmail repository catalogue...
mimugmail repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be REINSTALLED:
unbound-1.19.1 [OPNsense]
Number of packages to be reinstalled: 1
1 MiB to be downloaded.
Proceed with this action? [y/N]: y
[1/1] Fetching unbound-1.19.1.pkg: 100%    1 MiB 334.8kB/s    00:04
Checking integrity... done (0 conflicting)
[1/1] Reinstalling unbound-1.19.1...
===> Creating groups.
Using existing group 'unbound'.
===> Creating users
Using existing user 'unbound'.
[1/1] Extracting unbound-1.19.1: 100%
You may need to manually remove /usr/local/etc/unbound/unbound.conf if it is no longer needed.
root@OPNsense:~ # service unbound onestart
Obtaining a trust anchor...
Starting unbound.
root@OPNsense:~ # drill isc.org @<IP_ADDRESS>
Error: error sending query: Could not send or receive, because of network error
root@OPNsense:~ # service unbound onestatus
unbound is running as pid 51697.
====================================================
So on one and the service appears to be running but not resolving in cli and not running in GUI
Unsure why this happens on 1/4 FWs, all are configured similarly, Unbound:53 for the OS with a port forward for AGH on all vlans. No recent changes to the configuration.
Software version used and hardware type if relevant, e.g.:
OPNsense 24.1.2_3 (amd64).

Ran into this today:
# /usr/local/sbin/unbound -dc /var/unbound/unbound.conf
Traceback (most recent call last):
  File "dnsbl_module.py", line 46, in <module>
    import dns.name
  File "/usr/local/lib/python3.9/site-packages/dns/name.py", line 27, in <module>
    import dns._features
  File "/usr/local/lib/python3.9/site-packages/dns/_features.py", line 3, in <module>
    import importlib.metadata
  File "/usr/local/lib/python3.9/importlib/metadata.py", line 9, in <module>
    import zipfile
  File "/usr/local/lib/python3.9/zipfile.py", line 6, in <module>
    import binascii
ImportError: Shared object "libz.so.6" not found, required by "binascii.cpython-39.so"

probably from the last snapshots/atest pubished... please make sure to mention that...

Sorry about that, I mentioned 24.1.2_3 as I thought it only existed in snapshots at the time.
So I applied the patch, php looks happy now and reports the service as running but in fact it's not. You can see below I'm running -dc before and after the patch and the libz.so.6 missing dependency is still outstanding. I can fix it with a soft link but I don't really know why it showed up on this machine only and what's the proper fix
=======================================
root@OPNsense:~ # /usr/local/sbin/unbound -dc /var/unbound/unbound.conf
Traceback (most recent call last):
File "dnsbl_module.py", line 46, in
import dns.name
File "/usr/local/lib/python3.9/site-packages/dns/name.py", line 27, in
import dns._features
File "/usr/local/lib/python3.9/site-packages/dns/_features.py", line 3, in
import importlib.metadata
File "/usr/local/lib/python3.9/importlib/metadata.py", line 9, in
import zipfile
File "/usr/local/lib/python3.9/zipfile.py", line 6, in
import binascii
ImportError: Shared object "libz.so.6" not found, required by "binascii.cpython-39.so"
root@OPNsense:~ #
root@OPNsense:~ #
root@OPNsense:~ # opnsense-patch fd00972
Fetched fd00972 via https://github.com/opnsense/core
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
|From fd00972988b96a9a4ff2582bfe72ba3b7fbcc6ee Mon Sep 17 00:00:00 2001
|From: Franco Fichtner<EMAIL_ADDRESS>|Date: Sat, 24 Feb 2024 18:34:48 +0100
|Subject: [PATCH] unbound: fix missing /lib; closes #7274
|
|---
| src/etc/inc/plugins.inc.d/unbound.inc | 1 +
| 1 file changed, 1 insertion(+)
|
|diff --git a/src/etc/inc/plugins.inc.d/unbound.inc b/src/etc/inc/plugins.inc.d/unbound.inc
|index f74ba58e78b..5c9f52d3bed 100644
|--- a/src/etc/inc/plugins.inc.d/unbound.inc

+++ b/src/etc/inc/plugins.inc.d/unbound.inc

Patching file etc/inc/plugins.inc.d/unbound.inc using Plan A...

Hunk #1 succeeded at 142.

done

All patches have been applied successfully.  Have a nice day.

root@OPNsense:~ # /usr/local/sbin/unbound -dc /var/unbound/unbound.conf

Traceback (most recent call last):

File "dnsbl_module.py", line 46, in

import dns.name

File "/usr/local/lib/python3.9/site-packages/dns/name.py", line 27, in
import dns._features
File "/usr/local/lib/python3.9/site-packages/dns/_features.py", line 3, in
import importlib.metadata
File "/usr/local/lib/python3.9/importlib/metadata.py", line 9, in
import zipfile
File "/usr/local/lib/python3.9/zipfile.py", line 6, in
import binascii
ImportError: Shared object "libz.so.6" not found, required by "binascii.cpython-39.so"
root@OPNsense:~ # service unbound onestatus
unbound is not running.
root@OPNsense:~ #
root@OPNsense:~ # ls -l /usr/lib/libarchive.
libarchive.a     libarchive.so.7  libarchive.so@
root@OPNsense:~ # ln -s /usr/lib/libarchive.so /usr/lib/libz.so.6
root@OPNsense:~ # /usr/local/sbin/unbound -dc /var/unbound/unbound.conf
[1708797988] unbound[6217:0] error: bind: address already in use
[1708797988] unbound[6217:0] fatal error: could not open ports
root@OPNsense:~ # service unbound onestart
Obtaining a trust anchor...
Starting unbound.
root@OPNsense:~ # service unbound onestatus
unbound is running as pid 48773.
root@OPNsense:~ #
=======================================

It needs an apply, not a (re)start.


Installing some packages will fail in Mancy

I am trying to install marky-markdown package, but the installation failed with the following error:
var marky = require("marky-markdown")
Application Error
Message
Cannot read property 'id' of null
Stack Trace
TypeError: Cannot read property 'id' of null
    at EventEmitter.<anonymous> (/Applications/Mancy.app/Contents/Resources/app/main/index.js:208:33)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at EventEmitter.<anonymous> (/Applications/Mancy.app/Contents/Resources/electron.asar/browser/api/web-contents.js:156:13)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)

System Details
| …
------------ | -------------
Platform | darwin
Arch | x64
Electron Version | 1.2.6
Mancy Version | 3.1.0

I was just having this issue with node-fetch today.
My error existed because I was trying to load from my npm prefix path (~/.npm). In that path Mancy was try to load the node-fetch folder where it had directories of the installed versions, but it did not have the module itself. Once I loaded the correct module path (~/.npm/lib/node_modules) which had the actual node-fetch module, it loaded without a hitch, and did not see another error about the missing prop id.