HDDS-2225. SCM fails to start in most unsecure environments due to leftover secure config

What changes were proposed in this pull request?
Remove unnecessary spark container from ozonesecure-mr test, since it generates configs into the wrong directory (a mounted one).  These configs are then picked up by other tests and cause failures.
https://issues.apache.org/jira/browse/HDDS-2225
How was this patch tested?
Ran ozonesecure-mr and ozone-recon tests in this order.

/label ozone

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
33
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

0
shelldocs
0
Shelldocs was not available.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

-1
mvninstall
32
hadoop-hdds in trunk failed.

-1
mvninstall
33
hadoop-ozone in trunk failed.

-1
compile
20
hadoop-hdds in trunk failed.

-1
compile
15
hadoop-ozone in trunk failed.

+1
mvnsite
0
trunk passed

+1
shadedclient
872
branch has no errors when building and testing our client artifacts.

-1
javadoc
21
hadoop-hdds in trunk failed.

-1
javadoc
19
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
34
hadoop-hdds in the patch failed.

-1
mvninstall
37
hadoop-ozone in the patch failed.

-1
compile
24
hadoop-hdds in the patch failed.

-1
compile
18
hadoop-ozone in the patch failed.

-1
javac
24
hadoop-hdds in the patch failed.

-1
javac
18
hadoop-ozone in the patch failed.

+1
mvnsite
0
the patch passed

+1
shellcheck
0
There were no new shellcheck issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
788
patch has no errors when building and testing our client artifacts.

-1
javadoc
20
hadoop-hdds in the patch failed.

-1
javadoc
19
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
26
hadoop-hdds in the patch failed.

-1
unit
25
hadoop-ozone in the patch failed.

+1
asflicense
30
The patch does not generate ASF License warnings.

2234

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1568

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient shellcheck shelldocs

uname
Linux 1b8876ba4ee1 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d947ded

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/branch-javadoc-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-javadoc-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/testReport/

Max. process+thread count
305 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/1/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.4.6

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Thanks @arp7 for the review.
ozones3 test was run after ozonesecure, but was successfully started and executed, which is the goal of this fix.  The only acceptance test failures are in MR createmrenv, which is being fixed in #1537.

Thanks @adoroszlai to fix this issue.
Can you please help me to understand how is it possible. My assumption is that all the core-site.xml files are deleted after one test is executed. docker-compose down should delete all the previous state.

Can you please help me to understand how is it possible. My assumption is that all the core-site.xml files are deleted after one test is executed. docker-compose down should delete all the previous state.

Thanks @elek for the question.  After some more research it turns out that only ozonesecure-mr is flawed: its spark container mounts ../..:/opt/hadoop, and apparently it generates configs into /opt/hadoop/etc/hadoop.  These configs are not removed by docker-compose down since it's a mount.  It seems they are picked up by subsequent tests, although they generate config into /etc/hadoop.

Somewhat drastic but effective solution ;-) I am fine with removing it for now, but we need to create a proper ozone-spark later (with smoketest).

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
3348
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

0
shelldocs
1
Shelldocs was not available.

0
yamllint
1
yamllint was not available.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

-1
mvninstall
53
hadoop-hdds in trunk failed.

-1
mvninstall
52
hadoop-ozone in trunk failed.

-1
compile
25
hadoop-hdds in trunk failed.

-1
compile
18
hadoop-ozone in trunk failed.

+1
mvnsite
0
trunk passed

+1
shadedclient
996
branch has no errors when building and testing our client artifacts.

-1
javadoc
28
hadoop-hdds in trunk failed.

-1
javadoc
24
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
39
hadoop-hdds in the patch failed.

-1
mvninstall
43
hadoop-ozone in the patch failed.

-1
compile
28
hadoop-hdds in the patch failed.

-1
compile
22
hadoop-ozone in the patch failed.

-1
javac
28
hadoop-hdds in the patch failed.

-1
javac
22
hadoop-ozone in the patch failed.

+1
mvnsite
0
the patch passed

+1
shellcheck
1
There were no new shellcheck issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
851
patch has no errors when building and testing our client artifacts.

-1
javadoc
27
hadoop-hdds in the patch failed.

-1
javadoc
20
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
32
hadoop-hdds in the patch failed.

-1
unit
29
hadoop-ozone in the patch failed.

+1
asflicense
38
The patch does not generate ASF License warnings.

5864

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1568

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient shellcheck shelldocs yamllint

uname
Linux 1cf1d4db42fc 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / f1ba9bf

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/branch-javadoc-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-javadoc-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/testReport/

Max. process+thread count
415 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/2/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.4.6

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
305
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

0
shelldocs
0
Shelldocs was not available.

0
yamllint
0
yamllint was not available.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

-1
mvninstall
47
hadoop-hdds in trunk failed.

-1
mvninstall
43
hadoop-ozone in trunk failed.

-1
compile
24
hadoop-hdds in trunk failed.

-1
compile
19
hadoop-ozone in trunk failed.

+1
mvnsite
0
trunk passed

+1
shadedclient
794
branch has no errors when building and testing our client artifacts.

-1
javadoc
26
hadoop-hdds in trunk failed.

-1
javadoc
25
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
39
hadoop-hdds in the patch failed.

-1
mvninstall
41
hadoop-ozone in the patch failed.

-1
compile
29
hadoop-hdds in the patch failed.

-1
compile
24
hadoop-ozone in the patch failed.

-1
javac
29
hadoop-hdds in the patch failed.

-1
javac
25
hadoop-ozone in the patch failed.

+1
mvnsite
0
the patch passed

+1
shellcheck
0
There were no new shellcheck issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
711
patch has no errors when building and testing our client artifacts.

-1
javadoc
27
hadoop-hdds in the patch failed.

-1
javadoc
24
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
32
hadoop-hdds in the patch failed.

-1
unit
30
hadoop-ozone in the patch failed.

+1
asflicense
39
The patch does not generate ASF License warnings.

2492

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1568

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient shellcheck shelldocs yamllint

uname
Linux ba433dd9aeed 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 51eaeca

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/branch-javadoc-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-javadoc-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/testReport/

Max. process+thread count
448 (vs. ulimit of 5500)

modules
C: hadoop-ozone/dist U: hadoop-ozone/dist

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1568/3/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.4.6

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

@adoroszlai  So now we have removed the mount and gen config? I am presuming that +1s were given for the earlier solution, but with force push I am not able to see the older changes.

@anuengineer Thanks for taking a look at this.

So now we have removed the mount and gen config?

The new solution only removes the offending container (spark), which is not required by the test at all.  Volume mount and config generation for the other containers is not changed.

I am presuming that +1s were given for the earlier solution, but with force push I am not able to see the older changes.

Both earlier solution (ff3671022a267d765d7d631cb5b6e57d46ced12d) and new one (5caa23a390197d4b2d4dbb738ac850d02378edc0) are visible in the list of commits.  The second commit just reverts the first attempt.  The force push was needed only to rebase on current trunk.  I agree, it makes understanding the conversation harder.  I'll try a plain merge next time.
Earlier +1s were for the first solution, while @elek's latest comment is for the second one.

Thanks the patch @adoroszlai I am committing it to the trunk. Let's fix Spark later.

Thanks @anuengineer, @arp7 and @elek for the reviews.


Fabconnect websocket listener not working?

Here step by step:

Create event streams

Subscription

wscat connect websocket

Transfer erc20 token, but nothing response in websocket client

Hi @thapld. Can you please provide more details about what you are trying to do? Are you using Fabconnect with FireFly and creating your subscription, websocket connection, and making the token transfer through FireFly's API or are you just using Fabconnect by itself? Did you deploy a custom chaincode for your ERC-20 contract that emits the event you are listening for?

Yes, I use Fabconnect API without FireFly. And ERC-20 chaincode have a emit event when transfer.

I also try with type Transfer:

But nothing happen.
I wonder any wrong when I create event streams or subscription as topic (any string, right?)

Ok, It works:

But I only can listen one time and I have to reconnect websocket and send message again

solved on discord!


Use Gradle Shadow instead of custom shading

Reference: https://github.com/johnrengelman/shadow

I like this, however, we need to be vary as sometimes other Gradle plugins tend to interfere, from experience I know.

d5f38b824e2c6bdd1885a2374116869258e5bd8f

Woops

cleaning out my closet issues list


chip_io.v gl is missing some ports

chip_io.v gl is missing ports such as const_zero and const_one.

I didn't create the gate level verilog for chip_io.  It was created from the DEF file, maybe by Kareem or Marwan?  They have a script somewhere, or maybe they did it manually, to process the DEF file through yosys and generate a gate-level verilog netlist.  But yosys doesn't read DEF so I'm not sure what tools they're using (other than that the gate level netlist has a header from yosys in it, so it definitely got passed through yosys as the final step).


MINOR: Update docs, remove JBOD from missing features

As of 3.8, JBOD in KRaft mode (KIP-858) is no longer an early access feature.

We would need to backport this to both the 3.8. and 3.9 branches too.
The newly generated docs for 3.8.1 and 3.9.0 still mention the JBOD limitation. I'll hold on doing backports for now as releases are in progress for both branches.


reuse_address on windows == reuse_port on linux

I think this is a better solution than having runtime errors on windows and having to write code like this for multi-platform support
    # example of what needs to be written before this commit is merged
    @socket = UDPSocket.new @address.family
    @socket.reuse_address = true
    {% unless flag?(:win32) %}
      @socket.reuse_port = true
    {% end %}

noting that windows SO_REUSEADDR == linux SO_REUSEPORT
and on windows, reuse of the address component of a binding is always allowed
I've also changed the socket defaults to use SO_EXCLUSIVEADDRUSE
as per the docs:

Unhandled exception in spawn: setsockopt 4: An invalid argument was supplied. (Socket::Error)
  from src\crystal\system\win32\socket.cr:322 in 'system_setsockopt'
  from src\socket.cr:403 in 'setsockopt'
  from src\socket.cr:413 in 'setsockopt_bool'
  from src\socket.cr:411 in 'setsockopt_bool'
  from src\socket.cr:275 in 'reuse_address='
  from src\socket\tcp_server.cr:40 in 'initialize:reuse_port'
  from src\socket\tcp_server.cr:36 in 'new:reuse_port'
  from src\http\server.cr:213 in 'bind_tcp'
  from spec\std\http\web_socket_spec.cr:377 in '->'
  from src\fiber.cr:146 in 'run'
  from src\fiber.cr:98 in '->'

@HertzDevil in regards to the error
  from src\socket.cr:411 in 'setsockopt_bool'
  from src\socket.cr:275 in 'reuse_address='

it looks like my macro finished isn't working as reuse_address should be a no-op

Yeah macro finished didn't work as an override the way you had implemented it. It would define these methods after everything else, but still in the module scope. So it could not override the defs in the including scope.

needed macro included; macro finished switched to @HertzDevil's wasm approach


Implicit flow custom user store

I have successfully implemented an authorization server using ResourceOwner flow having custom user store.
But this time I have to implement an authorization server using Implicit flow and I have to have custom user store. I have searched a lot, but I have not found which Interface I have to implement for validating users in Implicit flow?

You do this in the login page that you build.

Any update on the issue? closing for now - feel free to re-open if it needs further discussion.


Specify a limited test suite

Define load_tests() in tests/init.py

coverage: 1.947% (+1.9%) from 0.0%
when pulling 885a8d5a37a869c5f27d27c8a95e28c9f75129a2 on bact:add-test-suites
into 515fe7ced70a17e1b4260e62db3cf9136a5c1a87 on PyThaiNLP:dev.

Test is now able to run on 3.9 to 3.13, install PyICU on Windows and install PyTorch on every platform.
Some tests that require external imports are not in tests/testx_.py (instead of test_.py), to make it able to run some tests without those imports (and facing import conflicts)

Will merge for now, the test_sent_tokenize and  test_normalize that failed have to be fix in another PR


Instability when launching multiple nodes simultaneously in rmw_zenoh 1.0.0.

When launching 50 nodes simultaneously with the default configuration of rmw_zenoh 1.0.0, the following logs are output. Although errors occur, communication itself seems to be working, suggesting that issues during high-load situations, such as scouting, may be resolved through retries or similar mechanisms.
WARN net-0 ThreadId(02) zenoh::net::runtime::orchestrator: Unable to connect to any locator of scouted peer abcca54e9b9f39dcc959a291b70ad4a3: [tcp/<IP_ADDRESS>:37439]

ERROR rx-3 ThreadId(10) zenoh_transport::unicast::universal::tx: Unable to push non droppable network message to abcca54e9b9f39dcc959a291b70ad4a3. Closing transport!

ERROR rx-3 ThreadId(10) zenoh::net::routing::dispatcher::pubsub: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown subscriber 36
ERROR rx-3 ThreadId(10) zenoh::net::routing::dispatcher::queries: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown queryable 37

ERROR rx-5 ThreadId(12) zenoh::net::routing::dispatcher::pubsub: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown subscriber @/a58b796ef2f5719ab57e80fb2c728d75/peer/config/**!
ERROR rx-5 ThreadId(12) zenoh::net::routing::dispatcher::queries: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown queryable @/a58b796ef2f5719ab57e80fb2c728d75/peer/**!

ERROR rx-1 ThreadId(08) zenoh::net::routing::dispatcher::queries: Face{27, 524dd4311cd7123f970f723a5392f031} Declare queryable 40 for unknown scope 40!

[ERROR][rmw_zenoh_cpp]: topic name /clock not found in topic_map. Report this.

Reducing the number of nodes to 31 significantly reduces errors, leaving only the following two types:
ERROR ThreadId(13) zenoh_transport::unicast::universal::tx: Unable to push non droppable network message to 5512dc59d089a06f075aef2519934705. Closing transport!

ERROR rx-0 ThreadId(07) zenoh::net::routing::dispatcher::queries: Face{2, cf85ad2d74c31f9f8380d04b0f718782} Undeclare unknown queryable @/5011374e2ef9e02648f354442d5bffb/peer/**!

I have not yet investigated the parameters, but I will add comments as I find more information.
Additionally, while the following warnings are not problematic, I would like to suppress them if possible. I am also curious as to why ROS 2 reliability is not supported.
[WARN][rmw_zenoh_cpp]: `reliability` no longer supported on subscriber. Ignoring...

here is our operating environment:

OS: Ubuntu 24.04
ROS2 jazzy
rmw_zenoh 1.0.0

Do you encounter the same issues when running with the rolling branch of rmw_zenoh?

In the rolling, the following error appears instead of the above error.
WARN net-0 ThreadId(02) zenoh::net::runtime::orchestrator: Unable to connect to any locator of scouted peer 19e837d73b78681c57969db53c2a58a1: [tcp/<IP_ADDRESS>:37373]
ERROR rx-0 ThreadId(07) zenoh::net::routing::dispatcher::resource: Resource 1 remapped. Remapping unsupported!
ERROR rx-1 ThreadId(08) zenoh::net::routing::dispatcher::pubsub: Undeclare subscription with unknown scope!
ERROR rx-1 ThreadId(08) zenoh::net::routing::dispatcher::queries: Declare queryable for unknown scope 29!
[ERROR][rmw_zenoh_cpp]: topic name /clock not found in topic_map. Report this.

Could you clarify if these errors/warnings are from the rmw_zenohd router or from the nodes you are launching?
It sounds like communication itself is working so i'm curious why you classify this as "instability"? Is there some functionality that is not working as per expectations?
It would be great if you can provide a link to a repository that can help us reproduce this behavior.

These are all outputs from the RMW of our node.
I believe there were also some ERROR messages from the zenohd router, but I haven't included them here.
If these behaviors are expected, then it’s fine,
but it’s hard to believe that frequent ERROR-level logs are normal, which is why I described it as "instability."
If the system can recover from these errors, perhaps the log level should be WARN rather than ERROR.
Providing code to reproduce this issue is not possible,
but I believe a similar setup would be an environment where a robot is spawned in a Gazebo environment.

When launching 50 nodes simultaneously with the default configuration of rmw_zenoh 1.0.0, the following logs are output. Although errors occur, communication itself seems to be working, suggesting that issues during high-load situations, such as scouting, may be resolved through retries or similar mechanisms.
WARN net-0 ThreadId(02) zenoh::net::runtime::orchestrator: Unable to connect to any locator of scouted peer abcca54e9b9f39dcc959a291b70ad4a3: [tcp/<IP_ADDRESS>:37439]

ERROR rx-3 ThreadId(10) zenoh_transport::unicast::universal::tx: Unable to push non droppable network message to abcca54e9b9f39dcc959a291b70ad4a3. Closing transport!

ERROR rx-3 ThreadId(10) zenoh::net::routing::dispatcher::pubsub: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown subscriber 36
ERROR rx-3 ThreadId(10) zenoh::net::routing::dispatcher::queries: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown queryable 37

ERROR rx-5 ThreadId(12) zenoh::net::routing::dispatcher::pubsub: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown subscriber @/a58b796ef2f5719ab57e80fb2c728d75/peer/config/**!
ERROR rx-5 ThreadId(12) zenoh::net::routing::dispatcher::queries: Face{2, ba18fecf1dc6032086ef7598ee0610d3} Undeclare unknown queryable @/a58b796ef2f5719ab57e80fb2c728d75/peer/**!

ERROR rx-1 ThreadId(08) zenoh::net::routing::dispatcher::queries: Face{27, 524dd4311cd7123f970f723a5392f031} Declare queryable 40 for unknown scope 40!

[ERROR][rmw_zenoh_cpp]: topic name /clock not found in topic_map. Report this.

Reducing the number of nodes to 31 significantly reduces errors, leaving only the following two types:
ERROR ThreadId(13) zenoh_transport::unicast::universal::tx: Unable to push non droppable network message to 5512dc59d089a06f075aef2519934705. Closing transport!

ERROR rx-0 ThreadId(07) zenoh::net::routing::dispatcher::queries: Face{2, cf85ad2d74c31f9f8380d04b0f718782} Undeclare unknown queryable @/5011374e2ef9e02648f354442d5bffb/peer/**!

I have not yet investigated the parameters, but I will add comments as I find more information.
Additionally, while the following warnings are not problematic, I would like to suppress them if possible. I am also curious as to why ROS 2 reliability is not supported.
[WARN][rmw_zenoh_cpp]: `reliability` no longer supported on subscriber. Ignoring...

here is our operating environment:
* OS: Ubuntu 24.04

* ROS2 jazzy

* rmw_zenoh [1.0.0](https://github.com/ZettaScaleLabs/rmw_zenoh/tree/dev/1.0.0)

Hi @Tacha-S, the warning will be removed since it's not really useful to the users. Thanks for your feedback.
And I just tested rmw_zenoh_cpp 1.0 with 50 more demo listeners and talkers, but I didn't see any errors as you posted. Can you share how you produce the errors?

It has been confirmed that the issue can be reproduced with the following launch.
ros2 launch turtlebot4_gz_bringup turtlebot4_spawn.launch.py namespace:=robot2 nav2:=true localization:=true rviz:=true

Hi @Tacha-S, It would be great if you could provide any minimum reproducible example to reduce the complexity. On my side, the turtlebot4_gz_bringup can't even work with CycloneDDS, so it's a little difficult to see what is expected.


useSupabaseUser()  is not updated until I leave the browser window or switch browser tabs

I'll apologize in advance if this is a beginner's question, but I've tried searching for an answer, and I can't seem to find any addressing the issue I have.
I use this module and I can successfully login using email and password, but for some reason, the user session is not updated within useSupabaseUser() until I leave the browser window or switch tabs and come back. Even if I refresh the page the useSupabaseUser() is not up to date. I have tried watchers, plugins, etc., but to no avail.
But as soon as I leave the browser window for a second, everything is updated and working as expected.
I would be really grateful if anyone could point me in the right direction!

I am having this same issue. Why was this closed?

I can add that I've tried both npm run dev and Netlify Dev locally and neither works.
It doesn't work when deploying to Netlify, I get a 404 on a supabase call.
I've tried Chrome, Safari and Firefox.

signInWithOAuth method is not returning any session data. If you want to work around with using signInWithOAuth and Nuxt 3, here my solution.
myComposable.js
const supabaseClient = useSupabaseClient();
const oAuthHandler = async (provider) => {
       try {
         const { data, error } = await supabaseClient.auth.signInWithOAuth({
           provider: provider,
         });
         if (error) throw Error(error);
       } catch (err) {
         alert(err?.message || "unknown error on sign in");
       }
     };

supabaseClient .auth.onAuthStateChange((_, _session) => {
      if(_session?.access_token) {
        const accessToken = useCookie('sb-access-token')
        const refreshToken = useCookie('sb-refresh-token')
        accessToken.value = _session?.access_token ?? null
        refreshToken.value = _session?.refresh_token ?? null
      }
    })

@bayramorhan hi! It might not be the same issue. I get session data from the client and cookies are set. It's just the useSupabaseUser() that is not updated accordingly.
Great workaround otherwise!

hi @anderslutzhoft . I also experienced your exact problem. After oAuth is complete and redirected, nothing changes, there is no session data. But as soon as I switch between tabs, the data was there. So, populating session data with useCookie() fixed my problem. Im just curious about what is different on your code and why this workaround is not solving your problem. maybe you can share some code.

Hi, i;ve been struggling with this issue for a while and this is what i cameup with using getSession and refreshSession  using supabase client as in the  docs. Dont know if this is the right way but works for now
 export default defineNuxtRouteMiddleware(async(to, _from) => {   const supabase =  useSupabaseClient()   let {data}= await supabase.auth.getSession() if(!data.session){   const { data, error } = await supabase.auth.refreshSession()   let {user} = data    if(!user){     return navigateTo('/login')   } }else{   if(!data.session.user){     return navigateTo('/login')   } }   })
I havent really tested out if the refreshSession is actually required, and i think not, but i just put it there as a failsafe

Hi, i;ve been struggling with this issue for a while now. The session cookies are only set after i switch the tab etc.. and this is what i cameup with using getSession and refreshSession  using supabase client as in the docs. Dont know if this is the right way but works for now(NB: only in non SRR mode)
 export default defineNuxtRouteMiddleware(async(to, _from) => {
  const supabase =  useSupabaseClient()
  let {data}= await supabase.auth.getSession()
if(!data.session){
  const { data, error } = await supabase.auth.refreshSession()
  let {user} = data
  if(!user){
    return navigateTo('/login')
  }
}else{
  if(!data.session.user){
    return navigateTo('/login')
  }
}
  })

I havent really tested out if the refreshSession is actually required, and i think not, but i just put it there as a failsafe

Im using with ssr mode and setting cookies manually is mandatory thing until they fix this

supabaseClient.auth.onAuthStateChange((_, _session) => {
if(_session?.access_token) {
const accessToken = useCookie('sb-access-token')
const refreshToken = useCookie('sb-refresh-token')
accessToken.value = _session?.access_token ?? null
refreshToken.value = _session?.refresh_token ?? null
}
})

Hi @bayramorhan it seems like the onAuthStateChange() is not firing until I switch tabs, so unfortunately, it doesn't fix my issue :(
Are you running SSR?

I found a fix that worked for me.
I noticed that there was 4 cookies set after I switched tabs:
'my-access-token'
'my-refresh-token'
'sb-access-token'
'sb-refresh-token'
the values of access and refresh tokens where respectively the same.
I got it to work by setting all 4 of them as per @bayramorhan s example AND setting the useSupabaseUser().value to the returned _session.user.
const myAccessToken = useCookie('my-access-token') const myRefreshToken = useCookie('my-refresh-token') const sbAccessToken = useCookie('sb-access-token') const sbRefreshToken = useCookie('sb-refresh-token')         myAccessToken.value = _session?.access_token ?? null         myRefreshToken.value = _session?.refresh_token ?? null         sbAccessToken.value = _session?.access_token ?? null         sbRefreshToken.value = _session?.refresh_token ?? null         console.log("session.access_token", _session.access_token)         useSupabaseUser().value = _session.user
all of this done in the login_handler method.

Any news on that topic?

Any news on that topic?

I have managed to fix it with the solution above BUT and its a big but, it seems sometimes this solution is also not working.

I got it working on localhost, but after deploying it to vercel it's back to tab-switching for it to work...

damn, guess they forgot about this repo

@larbish not sure if you are aware of the issues we are facing, it seems something got broken somewhere

so this might sound weird, but have you guys tried using useSupabaseAuthClient instead of useSupabaseClient cus that seems to resolve it for me at least, not sure if it'll break later or something, but for now that worked for me

The way I got it working again was to manually update the gotrue-js package to the latest version.

so this might sound weird, but have you guys tried using useSupabaseAuthClient instead of useSupabaseClient cus that seems to resolve it for me at least, not sure if it'll break later or something, but for now that worked for me

Using useSupabaseAuthClient resolved signOut issue but its not resolved session problem.

I realized that this module is not even at a major release. It's 0.5.0. So I reverted back to using the native SupabaseJS, and it works as it should.
Until they release a major update, I felt like it wouldn't be fair to assume full stability or production readiness.

Can you share on how you did it? Thought about switching to native aswell.

Can you share on how you did it? Thought about switching to native aswell.

Firstly I configured the whole app to CSR instead of SSR just to be sure. And then I just followed the instructions in the documentation and examples.

so this might sound weird, but have you guys tried using useSupabaseAuthClient instead of useSupabaseClient cus that seems to resolve it for me at least, not sure if it'll break later or something, but for now that worked for me

Dude, this made it for me. Changed it and login with password worked flawlessly. Unfortunately documentation is lacking.

I have a reproducible case of this - using useSupabaseAuthClient helps partially but not completely.
See if my repo exhibits the problem you're all seeing? When I login (using signInWithPassword) the user is not in the composite useSupabaseUser but the auth session does actually contain the user.
https://github.com/rscorer/auth-demo

It seems to me that the issue stems from the gotrue package. Once it's updated to the latest version, everything is working as intended.

It seems to me that the issue stems from the gotrue package. Once it's updated to the latest version, everything is working as intended.

I am using the latest gotrue-js package - v2.11.0 - there is nothing later that I can see, and it is still exhibiting the bug.

I have this issue as well. And this issue has been open for a month with no admin attention. @larbish can you please take a look?

I'm using the useSupabaseAuthClient composable and still observing the same behavior, nothing updates until the window loses focus

I'm sorry guys but since I'm working hard on the beta opening of the Nuxt Studio and because I'm only using the supabase module for side projects that are all working well on production, I don't have much time to check issues in particular if reproduction is missing. The demo is working as expected and deployed on Netlify. Please check it and if you can easily reproduce your wrong behaviour, create and share a repository to reproduce, I'll find a moment to help 🙏

Hey @larbish, thanks for taking the time to address this ❤
I believe this could be a reproduction of the issue:

Login page that redirects you to another route once logged in (Supabase Auth via email/password)
Auth middleware which is blocking access to the /authenticated route for users that are not logged in.

Current behavior:

When logging in, your tokens are defined in your browser cookies
Once you get redirected to the /authenticated route, the middleware checks your access
The useSupabaseUser() composable is not defined right after the login, which leads to an abort of the navigation

https://stackblitz.com/edit/nuxt-starter-tefz9j?file=pages/login.vue

⚠ Warning: This doesn't work right out of the box for a few reasons

Stackblitz seems to mess with cookies or whatever. While the session is retrieved correctly via the Supabase API, the useSupabaseUser() composable returns a ref to null at all times, even after refreshing the page or switching tabs, this should work locally though, since the Supabase API gets queried correctly.
You need to define the SUPABASE_URL and SUPABASE_API_KEY environment variables in the .env file to your Supabase project credentials

Hey @MAXOUXAX, thanks for the reproduction. The user returned by the useSupabaseUser composable is a reactive utility that only exists in the module scope but not in supabase itself. The module keeps it synchronised with the session. If you were using only supabase, you should do await authClient.auth.getUser() each time you would like to fetch the user (by doing so the reactivity is lost). I'm explaining that because since the user is not set by supabase itself, we'll receive the signInWithPassword response before the user is set in the chore of the module. To fix this behaviour you just need to watch the user in your login page/component. For your reproduction, something like this will work:
const supabase = useSupabaseAuthClient();
const user = useSupabaseUser()

watch(user, () => {
  if (user.value) {
    navigateTo('/authenticated')
  }
})

async function handleLoginForm() {
  const { error } = await supabase.auth.signInWithPassword({
    email: email.value,
    password: password.value,
  });

  if (error) {
    alert(error.message);
  }
}

I will update the documentation to explain it.
NB: Concerning the SIGNED_IN event getting fired on tab focus, I need to dive deeper to check what's going on. I've create an issue to keep track of it #163


Update azure-rbac.md

command correction

@JnHs

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hi @ParisaMousavi - thank you for taking the time to help us improve the docs! We have actually been working on updating this topic and have just published many changes. The section that you edited was updated and I believe we have addressed your issue, so I'm going to go ahead and close this pull request instead of merging it into the updated document. If it appears further changes are needed, please let me know or feel free to open a new PR with your suggested improvements. Again, thanks for your contribution and for taking the time to improve our content.
#please-close


Removal of error in Fourier example

PR Checklist
Link to relevant issue(s)
https://github.com/JuliaAnimators/Javis.jl/issues/467
Closes #
How did you address these issues with this PR? What methods did you use?
Updated the file with correct ones.

Codecov Report

Merging #468 (b54a05c) into main (3465eff) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #468      +/-   ##
==========================================
- Coverage   96.47%   96.46%   -0.02%
==========================================
  Files          35       35
  Lines        1617     1612       -5
==========================================
- Hits         1560     1555       -5
  Misses         57       57

Impacted Files
Coverage Δ

src/Javis.jl
96.80% <0.00%> (-0.08%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3465eff...b54a05c. Read the comment docs.


Updated events.yaml to add Birmingham open hack

Hi there!
We're back again with Birmingham Open Hack this year. Much more clarity on who's running it. It's basically run by BCU Tech Guild aka the new computer science community for BCU. Same goal as before, get as many students, professionals, and enthusiasts who love tech under one roof to solve a few challenges and win some prizes.
BCU Tech guild twitter: https://twitter.com/bcutechguild?lang=en

@jmsv can i close the PR?

waiting on @bahorn for the merge since they run this 🙂

Merged!


Update README.md

Microservice architecture has become increasingly popular in recent years due to its ability to improve scalability, resilience, and maintainability of software applications. Microservice architecture break down the task into smaller, independent services that can be managed separately, which help in separation of concerns and make code more readable.

Description

Motivation and Context

How Has This Been Tested?

Types of changes

[ ] Content Update (change which fixes an issue or updates an already existing submission)
[ ] New Article (change which adds functionality)
[ ] Documentation change

Checklist:

[ ] My code follows the code style of this project.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have made checks to ensure URLs and other resources are valid

Hey! You forget to add the link :P


Bug: MQ Wall Cow where Ruto spawns can be milked for the MQ Jabu Cow's item further in the dungeon

Title is self-explanatory. Apparently you can milk the wall cow in the room Ruto spawns in to get the MQ Jabu cow's item further in the dungeon (past the Big Octo). Should probably be prevented somehow (maybe just make it give milk? Or just restrict it somehow). Reported here: https://discord.com/channels/1004394204992118935/1004394205478662156/1174741399183302727

Fixed


Updates to Publish-Module require the source folder to be the same as the module name

Expected Behavior
When performing the Invoke-Build -Task Publish, assuming all requirements are met, the module should be published to PSGallery.
Actual Behavior
When performing the Invoke-Build -Task Publish all tasks complete, except the publish itself, returning an error:
No valid module was found at the specified location

Steps to Reproduce the Problem

Create an otherwise valid PowerShell Module that passes all tests and compiles
Perform Invoke-Build -Task Publish
The error is returned

One of the current requirements for Publish-Module is that the Folder/Directory specified in the -Path parameter have the same name as the module itself.  In the Module Build script the folder name is build.
Specifications

Version: Plaster 1.0.x
Platform: PowerShell Core
Subsystem: Invoke-Build

Solution
Adjust the Build script to create a sub-folder under build using the module name, derived in the same way as in other parts of the script.
I will submit a PR for the same.

Thanks for the contribution! Apologies it has taken me so long to get back to this and get it merged.
Closed via #4


track_io feature is not documented

No documentation of track_io in optimize!:
help?> DescentMethods.optimize!
  optimize!(M::DescentWrapper, fdf, x0)

  Find an optimizer for fdf, starting with the initial approximation x0. fdf(x, g) must return a tuple (f(x), ∇f(x)) and, if g is mutable,
  overwrite it with the gradient.

  ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  optimize!(M::CoreMethod, fdf, x0; gtol = 1e-6, maxiter = 100, maxcalls = nothing, reset = true, constrain_step = nothing)

  Find an optimizer for fdf, starting with the initial approximation x0. fdf(x, g) must return a tuple (f(x), ∇f(x)) and, if g is mutable,
  overwrite it with the gradient. A function constrain_step(x0, d) may be passed to limit the step sizes.

Need to decide on the API for path tracking. Current implementation (an open IO stream as parameter) doesn't feel quite right (who closes the stream in case of exception during optimization?)


Allow atomic Flutter releases

Today, Flutter releases are triggered by a push to the release branch. From there, LUCI git pollers will pick up the new commits, and trigger packaging builds (one per host platform per architecture). At the end of each build, they are zipped, uploaded to cloud storage, and a manifest JSON file for the website is updated.
Problems with current process

If one of the packaging builds fail but others succeed (as happened here, we are in a strange state that is difficult to recover from.
There is latency between when the different platform archives are available on the website.
There is latency between when a release is pushed to the branch and when it is available on the website.
The release archive is not tested before it is publicly available (although the code has already been tested on the candidate branch).
Build triggering has to be timed approximately 1 hour before the intended release.

We should have a system where packaging archives are built but not publicly available, and then, upon all green builds, the release can be pushed to release branch which triggers a quick simple CI job that merely updates the website manifest.
Blockers to atomic releases
The Flutter tool assumes a release channel is a git branch (e.g. the source of truth for the stable channel is the upstream stable branch). It reports the current branch as the name of the local branch it has checked out, and it subscribes to upgrades by checking if the upstream remote branch has newer commits. To allow a release package to be created before it is publicly available to existing customers, either:

an SDK package would have to be created with a git repo whose release branch is ahead of the upstream repository yet still tracking it; or
the Flutter tool would have to be refactored to not rely on git branches for identifying the current release and for subscribing to upgrades.

Solution 1 would be messing with git history in a way that would be difficult to reason about and difficult to test, and Solution 2 would be a significant amount of work and need to be scoped with a design doc (especially how to subscribe to upgrades).

As I think about it more, I think we'll have to push to the branch first, otherwise the archive checkout will be on the candidate branch. So this would fix 2, and mitigate 1 and 4, but we'd still inherently be stuck on 3 and thus 5.

Triage: what priority is this?

Triage: what priority is this?

added a p4

We could also create 3 new branches: dev-staging, beta-staging, and stable-staging, and have the packaging builders watch these branches. The packaging jobs would still upload to cloud storage at the end, but they would not update the website JSON files.

in the release process, where we currently push the candidate branch to beta, we  instead push it to beta-staging, triggering packaging builds.
Once all three (mac, windows, linux) packaging builds are done and uploaded to cloud storage, we could test and verify them.
We could then push from beta-staging to beta, which triggers a new job, entitled publish which verifies the three packages exist, and then updates the website. All three platforms can be triggered by a single job.

Step 3 will be quick, and can happen at a later time than the first two steps.

\cc @sealesj related to packaging and docs

Triaged: This work is still in flight.


fatal error

I am seeing this error, but I don't see a fix.
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 64 bytes) in phar://daux.io/daux.phar/libs/Tree/Directory.php on line 51
Line 51 is a } and I don't see where else this change would make sense.

Hello, the case of the memory is not necessarily related to a specific line of code.
How big is your documentation ?

Several hundred pages!

From: Stéphane Goetz<EMAIL_ADDRESS>Sent: Wednesday, March 29, 2017 8:16:26 AM
To: justinwalsh/daux.io
Cc: Slack-Moehrle; Author
Subject: Re: [justinwalsh/daux.io] fatal error (#443)
Hello, the case of the memory is not necessarily related to a specific line of code.
How big is your documentation ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/justinwalsh/daux.io/issues/443#issuecomment-290071666, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHJQrlWxj-U6FKj3aT_ZzE-gj8RRfmM9ks5rqkuagaJpZM4Mr7AH.

Okay, that's probably why, because when creating the documentation it takes all pages in memory and writes them down after.
Is your documentation public by any chance so I can make some tests and improve Daux's behaviour on big projects ?
If not, I will try to replicate your case with dummy pages and hope to get some improvements.
In the meantime, can you try to update to the latest daux version and/or to change your memory parameters ? (memory_limit in php.ini)

Hello @slackmoehrle, sorry for the long wait, I didn't have too much time on side projects these past months.
I made some improvements in how Daux handles big documentation and their memory usage.
I created a documentation with over 2'700 pages and reduced its memory usage to a minimum. It certainly changes from on documentation to another, but I hope this fix helps you.
You can test it by downloading the latest dev-masterversion in packagist. I hope to be able to make a release of this soon.

By the way, if you still have problems, you might want to disable the search feature, to generate it, all files have to be kept in memory at the same time, this is one of the main causes of memory usage in the daux generator.

@onigoetz Thanks, I will update my install and test things out.


[Window] Command group menus do not close after a second window has been closed

Bug Description
Normally, when a command group menu is open and the window is moved, the command group menu will close. However, if a second window is opened and then closed, the command group menu will no longer close when the window is moved and will rather stay in place, as shown below.
For context, I am showing the second window through var isAboutWindowOpen by remember { mutableStateOf(false) }.
Steps to Reproduce

Open a second window and close it
Open a command group menu
Move the window

Actual Result:
The command group menu stays in place when the window is moved.
Expected Result:
The command group menu should close when the window is moved.
Screenshots

Platform Info
Aurora Version: 1.1.0
Operating System: Windows 11

This issue still seems to be present on native, decorated windows:

I think I know why this is happening - in non-undecorated mode the window is using OS-provided title bar. So when you move the window by grabbing that title bar, right now Aurora doesn't get notified in its window-level AWT listener, and the popups like menus, combos etc don't get dismissed.

Ugh, this is not going to be easy to fix.
Over here this is how Swing's popup menu registers itself to get notified on window ungrabbing. Note that it's using internal, undocumented and inaccessible event mask. Then over here it gets notified that the window has been ungrabbed so that it can hide itself. Again, internal and inaccessible event class. And there's also these APIs to grab / ungrab windows to have the whole process rolling.
None of which can be used, especially now that the JDK is heavily restricting access to such internal APIs.


[WIP] Enable instances and ckptmgr transferring state via local disk

During our test, we found that if a state is too large (>~64MB), the original checkpointing mechanism fails. The actual state will be packed in the protobuf message and transmitted through the network. Once it's large enough, the receiver will have problems parsing the IncomingPacket, which causes the connection to be closed. And it fails the whole checkpointing process.
This PR solves this problem by introducing the state spilling feature. With the feature turned on, the actual state will be spilled to local disk and only the state location information is transmitted through the network. This ensures the checkpointing works for even very large states.
Tested with internal topologies.

Closing this PR due to confusing commits and code not cleaned up.
A new PR will be posted for this feature with better commit information and clean code.


wlinhibit: init

Description of changes
wlinhibit is an extremely simple program to prevent your wayland compositor from going idle.
if it runs idle inhibit is active, if not not. its that simple.
https://github.com/0x5a4/wlinhibit
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

1 package built:

wlinhibit

Please rebase away the merge and squash commits into logical units. In your case, probably just one commit.
The we're good to go I think.


adding event on triggering rule decoding payload in container

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind documentation

/kind tests

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area commands

/area pkg

/area events

What this PR does / why we need it:
this is an syscall event which will trigger Decoding payload in container rule
Which issue(s) this PR fixes:

Fixes #115
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: h4l0gen
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

this rule triggered with use of base64 -d no need to give any encoded payload.
as expected this rule triggered in above terminal when i used base64 -d command inside container. Please provide your feedback @FedeDP

LGTM label has been added.  Git tree hash: ee59191998f4eed3167dd5a8f86695a26310d905


FontAwesome issue

Hi.
Cool plugin!
Find issue when font-awesome style is not loaded on site then icons is missing.
In file Resources/font-awesome/style.css
Looks like font-family must be PhpDebugbarFontAwesome instead FontAwesome
With this fix icons is visible.

Actually the problem is generated because Phalcon's Debugbar do a prepend with phpdebugbar- before every css class in your View.
Said that, your generated HTML is:

And what the FA's CSS expects is:

You can test in your browser by changing the class by Inspect element...


fix(date-picker) Specify type for flatpickrOptions

Closes carbon-design-system/carbon-components-angular#2665
Add the type for the flatpickrOptions input in the Date picker component

I have read the DCO document and I hereby sign the DCO.

recheck


License?

There’s no license in the repo, what license are the trained RemoteCLIP weights under? For comparison, the RSICD CLIP model is under an Apache 2 license.
RSICD CLIP license: https://github.com/arampacha/CLIP-rsicd/blob/master/LICENSE

License is created, thanks : )

Thanks :)
On Mon, Mar 4, 2024 at 10:57 PM Delong Chen (陈德龙) @.***>
wrote:

License is created, thanks : )
—
Reply to this email directly, view it on GitHub
https://github.com/ChenDelong1999/RemoteCLIP/issues/23#issuecomment-1978078793,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABEHUL4J5OBRRWDCJ654XDYWVUERAVCNFSM6AAAAABEGOB27SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZYGA3TQNZZGM
.
You are receiving this because you authored the thread.Message ID:
@.***>


KAFKA-7110 Add windowed changelog serde

*Currently the TimeWindowedSerde does not deserialize the windowed keys from a changelog topic properly. There are a few assumptions made in the TimeWindowedDeserializer that prevents the changelog windowed keys from being correctly deserialized. This PR will introduce a new WindowSerde to allow proper deserialization of changelog windowed keys. See https://issues.apache.org/jira/browse/KAFKA-7110 for more details.

@guozhangwang How about you and I review this one?

Go for it @vvcephei

@guozhangwang How about you and I review this one?

Sounds good. I left some comments on the JIRA first, and @shawnsnguyen also replied.

Note that this PR is correlated to https://github.com/apache/kafka/pull/5044, in a way that we want to provide the windowed serde with the window size into it so that the window end timestamp can be correctly reasoned. Copying @shawnsnguyen 's comment:

we could just set the window size in the serde when the windowConsumed() method is called in the timeWindowedKTable api.
Something like:
public synchronized <K, V> KTable<Windowed<K>, V> timeWindowedKTable(final String topic, final Consumed<K, V> consumed, final Materialized<K, V, WindowStore<Bytes, byte[]>> materialized, final TimeWindows timeWindow) {
Consumed<Windowed<K>, V> windowedConsumed = consumed.windowedChangelogConsumed(timeWindow.size());
ConsumedInternal<Windowed<K>, V> consumedInternal = new ConsumedInternal<>(windowedConsumed);
...
}

My idea is that, alternatively, we do not modify the Consumed API, but still allow users to pass in the serdes in Consumed, instead, only requires users to pass in the inner serde inside consumed parameter, and the library can wrap it with the windowedserde, and set the window size:
public synchronized <K, V> KTable<Windowed<K>, V> timeWindowedKTable(final String topic, final Consumed<K, V> consumed, final Materialized<K, V, WindowStore<Bytes, byte[]>> materialized, final TimeWindows timeWindow) {

        // wrap the user provided serde with the window serde, with the window size,
        // note that needs a new constructor
        TimeWindowedSerde windowedSerde = new TimeWindowedSerde(consumed.keySerde, timeWindow.size());

        // then create the table
        final ConsumedInternal<K, V> consumedInternal =
                new ConsumedInternal<>(Consumed.with(windowedSerde, consumed.valueSerde()));

        return internalStreamsBuilder.windowTable(topic, consumedInternal, materializedInternal);
    }

And on TimeWindowedSerde, add this constructor:
        public TimeWindowedSerde(final Serde<T> inner, final long windowSize) {
            super(new TimeWindowedSerializer<>(inner.serializer()), new TimeWindowedDeserializer<>(inner.deserializer(), windowSize));
        }

Would that work? @vvcephei @abbccdda

Also I've left another comment on the ticket itself regarding 1) issue, and I think we should fix the inconsistency between:
https://github.com/apache/kafka/blob/b1aa1912f08765d9914e3d036deee6b71ea009dd/streams/src/main/java/org/apache/kafka/streams/state/internals/ChangeLoggingWindowBytesStore.java#L82
(for serialize) and
https://github.com/apache/kafka/blob/b1aa1912f08765d9914e3d036deee6b71ea009dd/streams/src/main/java/org/apache/kafka/streams/state/internals/WindowKeySchema.java#L123-L132
(for deserialize)
Note that we only want to encode the sequence number if retainDuplicate is true, which is only used for stream-stream join today, which we should fix in the long run. For now I think we should let the window deserializer to be aware if it is deserializing a repartition topic with windowed key (in which case the toBinary was used to ser), or deserializing a changelog topic with windowed key (in which case the toStoreBinary was used to ser). It is a bit hacky admittedly, but maybe a quick workaround for now.

@shawnsnguyen Also consider adding tests. They would be nice. :+1:

I think we need a KIP for this?

@mjsax yes. We were having some internal discussions here about which API proposal looks more promising, and I'm counting on @shawnsnguyen to send out a KIP for this when he comes back online.

I'm thinking we can just pass in
a string constant specifying the input topic type (e.g. "changelog") in the constructor of the time windowed deserializer and perform the correct deserialization method in WindowKeySchema based on the type.

Yeah that sounds good to me as a short-term fix.

I will have to delay the KIP and fix to ~3 weeks since there are a couple high priority items I'm working on atm.

@shawnsnguyen No worries. Thanks for the status update!!

@mjsax I should be able to update this PR by end of this week.

It's been a while, could you rebase when you got time?

We still don't have a KIP for this, do we?

Added a KIP here - https://cwiki.apache.org/confluence/display/KAFKA/KIP-393%3A+Time+windowed+serde+to+properly+deserialize+changelog+input+topic.

Thanks for the KIP. I am wondering why it does contain KIP-300 related proposal? Do you intend to merge both KIPs into one? If, your KIP should focus on the changes the the Serde, but no include KTable#timeWindowedKTable.
Also, I am wondering if we want to expose the changelog details this way? Maybe @guozhangwang can comment on this. Also, I am wondering if it might be cleaner to change the format to encode window-start and window-end timestamp? Upgrading would be tricky to be fair... Thoughts?

@shawnsnguyen Also in order to merge this PR, we need to vote and accept the corresponding KIP. I think we can just separate 300 with 393 such that 393 only covers the newly added public APIs for this PR, i.e. TimeWindowedSerde, while 300 will only discuss on StreamsBuilder API changes which may need more time to discuss. cc @abbccdda @mjsax @vvcephei
Given this proposal, could you update the 393 wiki page and then move on with a VOTE thread directly? My comments on the wiki it self:

Public Interfaces is actually deprecated by Proposed Changes. Let's just use Proposed Changes section for the newly added APIs in TimeWindowedDeserializer and TimeWindowedSerde.

Remove the part on StreamsBuilder as we will discuss about it separately on KIP-300.

Also for this PR could you add corresponding docs on developer guide and upgrade guide as well?

I do have some more comments, that I did not post here because I thought we should discuss on the KIP -- do you think it make sense to start a VOTE directly (we can still discuss on this thread)?
I am little confused about the exposure of the isChangelog setting, just as a heads up. Seems we leak implemenation details?

Thanks @guozhangwang and @mjsax for the detailed review! No objection to making the constructor package private since it is a quick fix for now, and adding a new constructor for the serde.
While this approach of having a constructor with 'isChangelog' does expose some unnecessary implementation details, at least if we make the constructor private and have a helper method forChangelog for now, it does not leak too much imo and can easily be fixed/changed later.
I updated the kip in the meantime to remove reference to KIP300, and will start a vote thread.

@shawnsnguyen Thanks for the updates!

@guozhangwang @mjsax I updated the PR and it seems the vote thread is approved by 3 members. Could you guys help review this again for merging?

@shawnsnguyen Yes I think the PR can be merged. Could you close the voting thread, update the wiki page with the status field as well?


Logging changes

Changed the default log level depending on the DEBUG flag. In Debug builds, defaults to BNCLogLevelDebug. In Release builds, defaults to BNCLogLevelNone.
Added BNCLog.h to Branch.h to expose BNCLogSetDisplayLevel().
Added support for branch_log_level in the Info.plist.

Result of Integration 1
Duration: 8 minutes and 8 seconds
Result: Perfect build! All 184 tests passed. :+1:
Test Coverage: 60%

I can't merge this because it will break the threading model.  But I like the idea of loading the logging from the Info.plist and I'll add that to the current version of the logging.


feat: Gitlab provider

Add support for GitLab as a provider

@ssliman moved to this PR

Thanks! looking forward to test this out. Will it be merged this week?

Thanks! looking forward to test this out. Will it be merged this week?

merged.
will be great to get your feedback :)


Remove img-retina mixin

Closes #25754.

This is a breaking change as it removes functionality, regardless of it's usefulness today :). We'd need to deprecate and not remove outright.

I'm closing this.
Discussion about mixins documentation here: #25977
Once we have an overview of all the mixins, we can figure out which mixins need to be deprecated in the future.


2185 doc updates for multitenancy

Modify extended operation docs to show that they need to be run against a partition.

This adds more docs for #2185


App Center Login issue "Update user profile failed, status code 500, status msg: Internal Server Error"

Hi ,
I am trying to Setup an Account in App center
Getting the following error , When I am Using my company Microsoft account :
Another Issue is When I click on forget password , I am not getting reset link to my above ID.
"Update user profile failed, status code 500, status msg: Internal Server Error"
URL It take me to is :
https://appcenter.ms/sign-in?original_url=/invitations/org/3291163f8ac5f7df77188f3f3211e9f90eb5668b55e6c9a7e99badf23d2c4205?&&&&

Hi @yoganandhini23,
This repository is for documentation issues. For issues like this, please contact App Center support, or Microsoft support in general since the sign-in flow is not owned by App Center. Normally you contact support through the website, but you cannot log in, so that won't work. If any of your colleagues already have an account, you could ask one of them to open a support case. Otherwise, please use the general App Center repository: https://github.com/microsoft/appcenter/issues
Always be careful sharing personal information in public spaces. I deleted your email address from the original question.


Credentials API

We will offer extension API around keytar such that extensions can use the host OS secret store. Current proposal is:
	/**
	 * Namespace for handling credentials.
	 */
	export namespace credentials {

		/**
		 * Read a previously stored secret from the credential store.
		 *
		 * @param service The service of the credential.
		 * @param account The account of the credential.
		 * @return A promise for the secret of the credential.
		 */
		export function readSecret(service: string, account: string): Thenable<string | undefined>;

		/**
		 * Write a secret to the credential store.
		 *
		 * @param service The service of the credential.
		 * @param account The account of the credential.
		 * @param secret The secret of the credential to write to the credential store.
		 * @return A promise indicating completion of the operation.
		 */
		export function writeSecret(service: string, account: string, secret: string): Thenable<void>;

		/**
		 * Delete a previously stored secret from the credential store.
		 *
		 * @param service The service of the credential.
		 * @param account The account of the credential.
		 * @return A promise resolving to true if there was a secret for that service and account.
		 */
		export function deleteSecret(service: string, account: string): Thenable<boolean>;
	}

To me this already looks proper, I wonder if we should create a new namespace or not. Until now we have been adding them very conservatively, my first instinct would be to have these functions in env which also host ofter platform'ish things. Another idea would be ExtensionContext tho it scopes things to this extension and I believe the secrets-store is shared for all, right?

Yes, it is shared by all extensions. That is given by our decision to use the OS key chain for implementation. No strong opinion on the namespace. I think it should have its own, like env.credentials.*.

I think it should have its own,

Why do you think so?

Concern raised during the standup is that now all extensions can read/write secrets on behalf of VS Code. We should consider making this API more explicit such that the editor can prompt (at least once) per extension. Something like a getSecretsStore-function that returns an object to read/write. During that function call we can ask the user if that particular extension is allowed to access secrets, e.g
interface SecretsStorage {
  read(): Thenable,
  write(...): Thenable,
  delete(...):Thenable
}

function getSecretsStorage(): Thenable<SecretsStorage> // <- will prompt the user per extension

With such a flow we would be on the save side, similar to browsers that must first get permissions from the OS to use your geo-locations, and then ask per website that wants to use your geo-locations

On the namespace: Since its already 3 functions it is nicer to put them in context of a name 'credentials'. env.readSecret() wouldn't speak as much for it self as env.credentials.readSecret() and env.readCredentialsSecret() is repetitive when used on all 3 functions.
On the confirmation per extension: I'm not convinced the confirmation per extension will add much. From what I have seen on Windows and Linux you unlock the OS key chain once per desktop session, after that all your applications can access it. Only on Mac are you asked per application and credential if that application may access it. An extension can bundle keytar itself and use the unlocked key chains on Windows and Linux and on Mac the prompt would say 'Code Helper' wants to access some credential which isn't much help either.
Unlike with browser's location and other restricted APIs where a webpage cannot bypass the user's decision, extensions have full access.
/cc @chrisdias

'credentials'. env.readSecret() wouldn't speak as much for it self as env.credentials.readSecret() and env.readCredentialsSecret() is repetitive when used on all 3 functions.

What throws me off here that mixed usage of credentials and secret. What is it we are dealing with? Will there be more things in the credentials namespace which isn't a secret?

An extension can bundle keytar itself and use the unlocked key chains on Windows and Linux and on Mac the prompt would say 'Code Helper' wants to access some credential which isn't much help either.

Sure, we are not going for security but for clarity. Accessing credentials is a very touchy topic and while I might trust a certain extension I might not trust another extension. I think it's somehow more polite/fair to our users to tell them what extension is now going off with their secrets.

In my view the secret is just one part of the credential and it is the secret we want to store, not the service or the account name, these are used to access the secret. The credential is account name and secret.
If we ask the user for each secret and extension, wouldn't that lead the user to think that there is some security involved in that question, not just politeness?
Either way, I'd prefer an API with just a single level of promises. Even if we add the user confirmation, we could still go just with promises on the functions without need for a promise on the namespace.

Let me advance a devil's-advocate argument for not doing this. First, an example, and then I'll get to the argument.
Currently, when I start VS Code in a fresh login session (in Linux) and load a folder connected to a Git repository, I see a popup asking for the passphrase to unlock my SSH private key. That's because VS Code's Git extension has tried to do a git fetch, which in turn has seen that my Git repo has an origin remote with an SSH URL (git@github.com:rmunn/my-cool-project). It tries to connect to that SSH URL, which causes OpenSSH to read my .ssh folder and find my private SSH key. That key is protected with a passphrase, so OpenSSH asks the ssh-agent process (which was automatically started when I logged in) to give it access to that particular private key. The ssh-agent process then says, "I don't yet have an unlocked version of that private key in memory, let me prompt the user" and causes a secure prompt to pop up to ask me for my passphrase. Once I type in my passphrase, that password is not stored in memory; instead, the ssh-agent process simply stores the unlocked private key (for a configurable length of time), using the Linux kernel's mlock syscall to ensure that that region of memory is never written to a swapfile (if it was ever written to disk, an attacker who stole my laptop could theoretically get my unlocked private key out of the swapfile, and do Evil Things with it).
That's a lot of complexity, but it Just Works™. And the argument is this: if VS Code adds an interface to keytar (or any other credential-management service), are extensions going to start relying on it? Will the Git extension end up not being able to use the system's SSH agent for unlocking passphrase-protected private keys, because its developers didn't think about the existence of other systems besides keytar? In the case of the Git extension specifically, the answer is almost certainly no, because Git access over SSH is a long-established method and plenty of people rely on it, and there would be no good reason for removing that feature (which works perfectly well) from the code. But in the case of some future extension that does something sensitive (say, managing your OAuth2 client IDs and secrets for you), what if the developers see the existence of the keytar API and take the path of least resistance, when a better solution exists that they didn't see?
This may or may not be a particularly likely scenario, but I think it's one that should be considered. Will adding this API cause people to ignore alternative options?

We need a first class support of credentials store in VS Code API to store credentials for web service connection. It will allow extension developers not to bundle packages like keytar and not to implement their own credential stores.
In my vision use case described by @rmunn is not representative since it too specific for git. It's up to extension developer to use this API or not. In Git extension it may not be valuable due to existence of Git credentials store, but for VSTS/GitHub and other web service integrations it makes sence.

Agreed, the inclusion of keytar will not change what the Git extension or others relying on ssh keys should do.
On asking the user for confirmation before passing credentials to an extension: Offline discussions suggest that this is seen as "security theater" because it suggests added security when in fact we can't add any additional security beyond what the OS provides:

Windows unlocks the entire credential store for all processes when the user logs in.
Linux (libsecret on Ubuntu) asks the user for permission to unlock the entire credential store for all processes once per desktop session.
Mac asks the user for confirmation for each credential and process.

What we would need to add on top of that is sandboxing of extensions, they have access to the full node.js API at the moment.

On asking the user for confirmation before passing credentials to an extension

Again, this isn't about confirmation or making this more secure but to inform people. We have a number of dupes on this issue which is simply about showing a message. We also have UI to show which extension added what status bar item. So, my guess is that folks maybe wanna know what extension is using its credentials.

Are you suggesting to have a purely informational message without a button to "deny" access? Like: Extension x.y.z is accessing your credentials for service a.b.c. - OK.
As much as I would like that transparency (and also a way to deny access), it will incorrectly suggest that the user will always know when an extension accesses credentials, but we cannot guarantee that as long as extensions are not sandboxed.
Status bar items are different because there is not much gain in an extension working around the reporting there. Credentials are more sensitive and any kind of suggested control should to be backed by actual security measures, IMHO.

As much as I would like that transparency (and also a way to deny access), it will incorrectly suggest that the user will always know when an extension accesses credentials, but we cannot guarantee that as long as extensions are not sandboxed

On the mac we could actually do that. Only the main process is able to get the nice prompt and before that happens we could show a modal dialog asking specifically for that extension. An "always"-choice should then be remembered in the keychain itself. Yes, on other platforms we cannot do that but that shouldn't stop us from being as good as possible per platform.
Again, the same sample: There is many ways to spoof on my geolocation, e.g. an app can make a http call to a server that derives my location from my IP. However, for most folks that is too much work and they want to use a utility API. On the mac that exists and when being used it shows its users. To me no sense of false security, just UI.

How do we make sure that an extension cannot trick the extension host or the main process into handing out credentials on behalf of some other extension? If we cannot secure that in a sandbox-way, the UI will suggest a false sense of security.
This doesn't compare well with the location service case because the OS might have access to a GPS unit and the precise location deserves better protection than the one guessed from the IP address. It is also not clear to me if the location service asks the user for confirmation for each application, maybe it's more a power-consumption than a security thing.

Pls see https://github.com/kieferrm/vscode-keytar-sample which demos what happens when using plain keytar.

I personally think the location services are a great analogy. It's definitely not a power-consumption thing, but a privacy thing. The power-consumption thing is right next to it:

I don't think we'll get to a point in which we'll provide any type of reasonable security. The best we can do is provide awareness to the user. This has always been our motto: clicking that Install button is the contract upon which we start attributing fault of any possible risk on the user's conscious choice.

Any idea when this feature will be available?

The discussion on if and how to surface this in the UI is still ongoing.

Hi, do you have any new details about discussion of Credentials API?

@dtretyakov No, this has stalled.


request with no output defaults to HEAD method

We were already doing a PUT request if there is input to the request,
this extends that to do GET if there is output but
HEAD if there is no input or output. The implementation is a bit
sutbler than that: we use libcurl's CURLOPT_NOBODY and
CURLOPT_UPLOAD options, which incidentally switches the default method
that it uses for HTTP/S requests and has corresponding appropriate effects
on uploads/downloads by other protocols.
This also changes the default for input and output to nothing instead
of using devnull as a sentinel, which had the unfortunate side-effect
that if explicitly pass devnull as an input or output argument, intending
to make the same request but provide an empty input or ignore any output,
it would change the behavior of the request. This was already present if
you tried to do a PUT with an empty request body: using devnull turned
it into a GET but using "/dev/null" or some other empty file didn't.
With nothing as a sentinel value, you can safely pass devnull as an
input or and output and have it work the same as any other value but empty.

Codecov Report

Merging #55 into master will decrease coverage by 2.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #55      +/-   ##
==========================================
- Coverage   90.25%   88.21%   -2.04%
==========================================
  Files           5        5
  Lines         359      365       +6
==========================================
- Hits          324      322       -2
- Misses         35       43       +8

Impacted Files
Coverage Δ

src/Curl/Curl.jl
100.00% <ø> (ø)

src/Curl/Easy.jl
91.91% <100.00%> (+0.05%)
:arrow_up:

src/Downloads.jl
81.70% <100.00%> (+0.12%)
:arrow_up:

src/Curl/utils.jl
75.75% <0.00%> (-21.22%)
:arrow_down:

src/Curl/Multi.jl
91.81% <0.00%> (-0.08%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 106ce0d...52a1434. Read the comment docs.


Report extended results in commandProcessFinished

Collect user/system time and max RSS values for subprocesses and report
them via a new CommamdExtendedResults struct in the
commandProcessFinished callback.
rdar://problem/37889042

@swift-ci please smoke test

This is just re-landing PR #237 now that downstream projects are ready for it.


How to set date time format in gantt

Currently while in on mouse over and drag events, the task time is displayed in 24hour time, how can I change this to 12 hour civilian time?
Thanks!

The tooltip has a 'date-format' property. Docu: https://www.angular-gantt.com/plugins/tooltips/

Works great, thanks!


fix(tanstack-start): Merge router context instead of updating

Description
This PR fixes bug where the initialisation of Clerk overwrites the context, by merging the original/existing context with the clerkInitialState.

Checklist

[x] npm test runs as expected.
[x] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[x] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

!snapshot

@octoper is there a reason this was reverted? it's causing the loaders to run twice as mentioned here: https://github.com/clerk/javascript/pull/4414


Sass 2076

Description

updated all the captions for employment details, benefits and expenses question pages
updated integration tests to use the caption check helper

Add a link to the relevant story in Jira
SASS-2076
Checklist PR Reviewer
Before Reviewing

[ ]  Have you pulled the branch down?
[ ]  Have you assigned yourself to the PR?
[ ]  Have you moved the task to “in review” on JIRA?
[ ]  Have you checked to ensure all dependencies are up to date?
[ ]  Have you checked to ensure its been rebased against the current version of main?

Whilst Reviewing

[ ]  Have you run the tests?
[ ]  Have you run the journey tests?
[ ]  Have you looked at the JIRA story to make sure all Acceptance Criteria has been met?

After Reviewing

[ ]  Have you checked for merge conflicts or any changes in the current main that may affect the current pull request? i.e. does it need another rebase?
[ ]  Have you checked to make sure there are no builds in the pipeline before you merge?
[ ]  Have you moved the task to “in pipeline” on Jira?

Checklist PR Raiser
Before creating PR

[ ]  Have you run the tests?
[ ]  Have you run the journey tests? (where applicable)
[ ]  Have you addressed warnings where appropriate?
[ ]  Have you rebased against the current version of main?
[ ]  Have you checked code coverage isn’t lower than previously?

After PRs been raised

[ ]  Have you checked the PR Builder passes?

test this please

test this

test this please

I think the following version can be updated:  uk.gov.hmrc: play-frontend-hmrc from 2.0.0-play-28 to 3.0.0-play-28


Can't add animator layers

Hello, nice job, but i have a problem on an avatar.
CuteDancer creates action animator but refuse to use it !
Any solution ? Thank you !

Hello
Are you using it in project managed by CreatorCompanion? If yes, try the new version 3.2.
If it won't help, please post more details about the issue. Screenshots with descriptions would be fine.

Closed due to lack of details.


Rename User -> Member in everywhere in subscription UI

Please change server side to return 'Member' instead of 'User'


[Bug]: Scan QR doesn't work on Lightning Connection Manual Setup page

Describe the bug
When on the Manual Setup page, the Scan QR option doesn't populate the form.
It doesn't matter whether the form has already been populated or not.
The 'Paste Node URI' button is working.
It is still possible to scan a LN node QR from the home screen though.
Reproduce

Go to Advanced -> Lightning Connection -> Manual Setup
Click on 'Scan QR'
Scan a valid LN node QR, e.g. https://1ml.com/node/0296b2db342fcf87ea94d981757fdf4d3e545bd5cef4919f58b5d38dfdd73bf5c9
Observe form is not populated

Screenshots / Recording
https://github.com/user-attachments/assets/30c55bb2-012d-4742-94da-cb366df9dbb9
Operating system
Android 14
Bitkit version
0d67faa2509b1ec083d475abc80e90802f8d7d28
Log output
No response

Verified in 1.0.6. (138)


Selected theme in options not saved

Between restarts, the users selected theme is not saved.

On it! Expect this to be fixed within the next day or so, sorry for the late response!


Add .fossa.yml to central-cp-multi-upfs branch for FOSSA CI

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

+1