How to search like bellow

if I have some string line this A00BAL2020.
I need to search like this A00*2020 and the result show A00BAL2020. How to do like that? Thanks

You can use the search_callback option where you manually evaluate each node according to the search term and decide if the node is a match or not: https://www.jstree.com/api/#/?q=search_call&f=$.jstree.defaults.search.search_callback


nixos/networking-interfaces: make static routes configurable

Motivation for this change
#27380
Things done

[x] Tested via nixos/tests/networking.nix (added a specific test)
[x] Add proper error handling
[x] Handle route options
[x] Fits CONTRIBUTING.md.

There is one related case I hit yesterday:
Network <IP_ADDRESS>/28
Gateway <IP_ADDRESS>
Servers on <IP_ADDRESS> .. <IP_ADDRESS>
The servers have to talk to each other via gw too.
route add -net <IP_ADDRESS> netmask <IP_ADDRESS> gw <IP_ADDRESS> dev eth0 solves this
but ip route add <IP_ADDRESS>/28 via <IP_ADDRESS> dev eth0 fails because <IP_ADDRESS>/28 is already defined.
It seems that there are some cases when route is superior over ip route

That's strange. Wasn't net-tools deprecated in favor of iproute2? It should at least cover every use case.

I end up with ip route (as I have patch from #27380 in my nixpkgs) but with 5 individual rules instead of one.

May be we should just add extraCommands (akin to networking.firewall.extraCommands) to allow free style command? No rigid structure will cover all cases.

networking.localCommands?

networking.localCommands?

Hm, may be yes. Also for https://github.com/NixOS/nixpkgs/pull/27678
Need to test if it is not too early or too late

First disadvantage of networking.localCommands - altering text of networking.localCommands with following nixos-rebuild switch does not apply the changes. It requires reboot or manual restart of systemd services (it is not easy to guess what to restart).

Also, same work 3 years ago: https://github.com/NixOS/nixpkgs/pull/3929

First disadvantage of networking.localCommands

It works for me: the service is restarted when switching configuration.
sudo nixos-rebuild test
building Nix...
building the system configuration...
these derivations will be built:
  /nix/store/s7i31b3662wz6w6bdzgvkxmbisanmwhq-unit-script.drv
  /nix/store/q4dwrsxs02wq5hh2mq2vzjrjjljhsy33-unit-network-local-commands.service.drv
  /nix/store/h9g94ch8hcspb1xbs9vc3jyy1ginfv24-system-units.drv
  /nix/store/hic1dx0jkw2nc27hxp77wfjirlswvr3w-etc.drv
  /nix/store/p84zvmg9qm4xqi6w5m7aqd4slmmwfpj6-nixos-system-wigfrid-17.09pre111388.00512470ec.drv
building path(s) ‘/nix/store/1kq8q6aknx7rb240drr2v67n03jgmzgy-unit-script’
building path(s) ‘/nix/store/mgj9rqqs4rxizficaqz6dgqv5zj3gvxg-unit-network-local-commands.service’
building path(s) ‘/nix/store/r9h74dlv3qdxfhdks1mspqxvcp893598-system-units’
building path(s) ‘/nix/store/3pqd81nsx28k0gl3ihw1wy0z630cpnyq-etc’
building path(s) ‘/nix/store/jxz4wm0f24nwfx0vhkmx1fgvx5sskgqd-nixos-system-wigfrid-17.09pre111388.00512470ec’
stopping the following units: network-local-commands.service
activating the configuration...
setting up /etc...
setting up tmpfiles
starting the following units: network-local-commands.service

It works for me: the service is restarted when switching configuration.

It works until the first failure. And it is easy to fail: if there is networking.localCommands = "ip route add ..", it will fail on the second restart (with "the route already exists") and will not restart anymore.
That means we need a symmetric cleanup procedure and something like your proposal or #3929 has an advantage over free-style because it emits cleanup code from the same definition.

I have tested IPv4/6 addresses/routes. Everything is working except the stop script fails to remove IPv4 routes for some reason.

ip route del fails with RTNETLINK answers: No such process

The order.
ip route del to be before ip addr del

I'm trying to write a test but I know exactly zero about perl.
import src/nixpkgs/nixos/tests/make-test.nix

{
  name = "routes";
  machine = {
    networking.useDHCP = false;
    networking.interfaces."eth0" = {
      ip4 = [ { address = "<IP_ADDRESS>"; prefixLength = 24; } ];
      ip6 = [ { address = "2001:1470:fffd:2097::"; prefixLength = 64; } ];
      ipv6Routes = [
        { address = "fdfd:b3f0::"; prefixLength = 48; }
        { address = "2001:1470:fffd:2098::"; prefixLength = 64; nextHop = "fdfd:b3f0::1"; }
      ];
      ipv4Routes = [
        { address = "<IP_ADDRESS>"; prefixLength = 16; }
        { address = "<IP_ADDRESS>"; prefixLength = 24; nextHop = "<IP_ADDRESS>"; }
      ];
    };
    virtualisation.vlans = [ ];
  };

  testScript = ''
    my $ipv4Table = <<'END';
    <IP_ADDRESS>/16 scope link
    <IP_ADDRESS>/24 proto kernel scope link src <IP_ADDRESS>
    <IP_ADDRESS>/24 via <IP_ADDRESS>
    END

    my $ipv6Table = <<'END';
    2001:1470:fffd:2097::/64 proto kernel metric 256 pref medium
    2001:1470:fffd:2098::/64 via fdfd:b3f0::1 metric 1024 pref medium
    fdfd:b3f0::/48 metric 1024 pref medium
    END

    $machine->start;
    $machine->waitForUnit("network.target");
    $machine->succeed("ip -4 route list dev eth0 | head -n3") eq "$ipv4Table";
    $machine->succeed("ip -6 route list dev eth0 | head -n3") eq "$ipv6Table";
    $machine->succeed("systemctl stop network-addresses-eth0");
    $machine->succeed("ip -4 route list dev eth0 | head -n-3") eq "";
    $machine->succeed("ip -6 route list dev eth0 | head -n-3") eq "";
  '';
}

How do I make an assertion?

something || die "$!";

Thank you.

Any objections to use iproute2's syntax as it is ("<IP_ADDRESS>/24 via <IP_ADDRESS>", etc) as in https://github.com/volth/nixpkgs/commit/cf5ac7e69ab1f5a2fdb4702705c3e4e40b158006 ?
Because there could be window, src, metric, ... adding module options for each would bloat the code.

I prefer this way because it's consistent with interfaces.<name>.ip{4,6} and you have a check on the prefix length. I could add a <route>.options instead of three different ones.

I think it's complete now.

What happened here? Who were you talking to? 😲

No idea, the messages just disappeared today. It was @volth

Updates? What happened to the messages?

I'm wondering if we also need global routes that are not bound to interfaces.
For instance, I'm adding unreachable routes to RFC1918 subnets on my routers to no traffic to them except explicitly defined via the default gateway (which is always an ISP in my case).

Any chance to get this into 17.09?

I started working on

renaming ip{4,6} -> ipv{4,6}.addresses
renaming ipv{4,6}Routes -> ipv{4,6}.routes
removing ip{Address,prefixLength}

Currently it just warns about using renamed/removed options.
I'm not sure how to do the transition without keeping the old implementation. I still wish mkRenamedOptionModule could handle submodules.

Michele Guerini Rocco<EMAIL_ADDRESS>writes:

I started working on

renaming ip{4,6} -> ipv{4,6}.addresses
renaming ipv{4,6}Routes -> ipv{4,6}.routes
removing ip{Address,prefixLength}

Please look at #11529. It did that and more years ago. SLNOS now
maintains those patches, so I can cherry-pick them from SLNOS master to
the current master if you're interested.

Please look at #11529. It did that and more years ago. SLNOS now
maintains those patches, so I can cherry-pick them from SLNOS master to
the current master if you're interested.

Okay. I pushed the SLNOS version to #11529 anyway. It has the workaround
for the submodule warnings bug (see
https://github.com/NixOS/nixpkgs/pull/11529/commits/df8987375eec5b20c6cdd09e27d8f7865b553b3b#diff-8dda4a0b1d45133da80186d3ce78f966R170
and warnings at the bottom of the same file).

@oxij Thank you! I implemented the trick you suggested.

Not sure if this is the intended usage but It works now.

Uhg. Let me think about it for a couple of days, maybe there's a better
way. Will test in the meantime.
Btw, e9c10a1f957d48d28cd1017722ec6a508094b0d4 introduces some EOL
whitespace in testScript.
Other than those two nitpicks I'm pretty happy about this patch set.
Finally, finally! we are going to have an almost sane networking module.
It's totally possible to port my old networking modularisation changes
on top of this, too. Yay! Thank you!

@oxij The whitespace in the routing table is in the output of ip route itself.
It's needed because for the test to succeed it has to match the exact string.

Finally, finally! we are going to have an almost sane networking module. It's totally possible to port my old networking modularisation changes on top of this, too. Yay! Thank you!

I'm glad to know, thank you again. If you like I think you should add your changes here.
I don't know if you have commit access, I can make you a collaborator in case.

ping

I do not like the idea of changing (ipv4 -> ipv4.addresses, etc)

that might break things on update
that would require maintaining TWO configurations (or many if/then) in a nixops setup where servers have different NixOS versions (e.g 17.09 or even 17.03 on libvirt hosts with many months uptime and 18.03-beta on short-living virtual machines)

@volth The changes are backward compatible: you can keep using the old names.

ping

Ooops, sorry. I cherry-picked these changes, have not invented how to
simplify mkMergedOptionModule lines, merged with my modularization
branch, tested it for a while, I wanted to comment on that progress ~a
week ago, but then I though I would better test it some more, but then I
completely lost track of time with other stuff.
All I can say is that it works for me on all my machines, but my
machines have very similar networking configs, so I would feel much
safer if someone else would test this too.
I would also squash three commits from the top, but LGTM anyway.

Fixed the conflict and rebased.

Fixed another conflict.

Just want to express my thanks for your continuous effort of rebasing this.

Thank you, also thank you for trying to get the maintainers' attention on this.

@GrahamcOfBorg test networkingProxy networking.networkd networking.scripted nfs4

Failure on aarch64-linux (full log)
Partial log (click to expand)
cannot build derivation '/nix/store/gmd87q3diy277lajrczx8yly9nwlcc8d-nixos-vm.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/hz6sc6xwvvda58wiwxa1lh6bkg75640g-nixos-vm.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/vs14ca32s2abfkbs81p83naz24j9846p-nixos-vm.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/xxlwrqfsqfhbphbdvl0j6hs35kzs95w8-nixos-vm.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/yb3bf7fqky0sg90xgadx8nbp0512qmya-nixos-vm.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/z6gyca4ngsxb2g8md6sncwb1igk8dhfb-nixos-test-driver-networking-proxy.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/k9fbkggl1w55f3ilr01iy1v0nzs44b3k-nixos-test-driver-nfs.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/l6yhr2nqzr8qpmw6r2gj9121mrsm1x4r-vm-test-run-networking-proxy.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/k05m4hws5qznf56b7di137zbw2llbwa2-vm-test-run-nfs.drv': 1 dependencies couldn't be built
error: build of '/nix/store/k05m4hws5qznf56b7di137zbw2llbwa2-vm-test-run-nfs.drv', '/nix/store/l6yhr2nqzr8qpmw6r2gj9121mrsm1x4r-vm-test-run-networking-proxy.drv' failed

Success on x86_64-linux (full log)
Partial log (click to expand)
client2: running command: sync
client2: exit status 0
test script finished in 242.64s
cleaning up
killing server (pid 695)
killing client2 (pid 625)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/zw6fr3jfjsrw12bzmsmbawljrpbadm1x-vm-test-run-networking-proxy
/nix/store/br73l3c9j5kjf0h8xj38f7i89zp289cf-vm-test-run-nfs

Observations: and old PR, useful cleanup, looks fine to me, unchanged tests still pass, no objections even though multiple people have read the code, enthusiastic support from @oxij , commit logs in the relevant directory do not make me want to mention someone…

Whooohoo! Happy dance Thanks to everyone involved!

Hopefully it's not hard to fix, but this breaks NixOS configurations using virtualbox, giving error:
The option value `networking.interfaces.vboxnet0.ipv4.addresses' in `/home/will/nixos/nixos/modules/virtualisation/virtualbox-host.nix' is not of type `list of submodules'.

@GrahamcOfBorg test virtualbox.headless

Failure on aarch64-linux (full log)
Partial log (click to expand)
error: attribute 'headless' in selection path 'tests.virtualbox.headless' not found

Failure on x86_64-linux (full log)
Partial log (click to expand)
while evaluating the attribute 'ExecStart' at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/nixos/modules/services/networking/dhcpcd.nix:179:13:
while evaluating the attribute 'text' of the derivation 'dhcpcd.conf' at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating anonymous function at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/nixos/modules/services/networking/dhcpcd.nix:19:30, called from undefined position:
while evaluating the attribute 'ipv4.addresses' at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/attrsets.nix:199:44:
while evaluating anonymous function at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/modules.nix:75:45, called from /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/attrsets.nix:199:52:
while evaluating the attribute 'value' at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/modules.nix:312:9:
while evaluating the option `networking.interfaces.vboxnet0.ipv4.addresses':
while evaluating the attribute 'mergedValue' at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/modules.nix:339:5:
while evaluating anonymous function at /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/modules.nix:339:32, called from /home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/lib/modules.nix:339:19:
The option value `networking.interfaces.vboxnet0.ipv4.addresses' in `/home/borg/borg-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/7c6f434c-buildbox/nixos/modules/virtualisation/virtualbox-host.nix' is not of type `list of submodules'.

Does
diff --git a/nixos/modules/virtualisation/virtualbox-host.nix b/nixos/modules/virtualisation/virtualbox-host.nix
index 91a46ac852b..47ae59bb38a 100644
--- a/nixos/modules/virtualisation/virtualbox-host.nix
+++ b/nixos/modules/virtualisation/virtualbox-host.nix
@@ -117,16 +117,16 @@ in
               VBoxManage hostonlyif create
               cat /tmp/VBoxSVC.log >&2
             fi
           '';
         postStop =
           ''
             VBoxManage hostonlyif remove vboxnet0
           '';
       };

-    networking.interfaces.vboxnet0.ipv4.addresses = { address = "<IP_ADDRESS>"; prefixLength = 24; };
+    networking.interfaces.vboxnet0.ipv4.addresses = [ { address = "<IP_ADDRESS>"; prefixLength = 24; } ];
     # Make sure NetworkManager won't assume this interface being up
     # means we have internet access.
     networking.networkmanager.unmanaged = ["vboxnet0"];
   })]);
 }

fix it?

See #35185.

Thank you for the fix.

I don't know... maybe retrying a few times with a loop before giving up?

Seems ok as a workaround to me.
But I think this needs to be reported upstream.
@volth Did you report this upstream yet?

Did you report this upstream yet?

No, it needs a bit more investigations.
At least to understand what is upstream here: iproute2 or kernel


[question] some success with ESP32?

I soldered the VINDRIKTNING to a ESP32 board (ESP32-MINI) but do not get a signal from the sensor. a
An additional DHT11 works well. I compiled tasmota32 with the #define USE_VINDRIKTNING option and wired REST to GPIO17.
Any recommendations?

i used it with an esp32 (m5stamp) with esphome (pin 21) yesterday and it works


FIX: Remove Top-Level Method

方法 present? 和 upcase_first 被作为 top-level method 声明，引入（require）后会污染全局的同名方法。

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report

Merging #16 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #16   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines         175    173    -2
=====================================
- Hits          175    173    -2

Impacted Files
Coverage Δ

lib/aliyunsdkcore/roa_client.rb
100% <100%> (ø)
:arrow_up:

lib/aliyunsdkcore/rpc_client.rb
100% <100%> (ø)
:arrow_up:

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 76ea46d...b1c487b. Read the comment docs.

Codecov Report

Merging #16 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #16   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines         175    173    -2
=====================================
- Hits          175    173    -2

Impacted Files
Coverage Δ

lib/aliyunsdkcore/roa_client.rb
100% <100%> (ø)
:arrow_up:

lib/aliyunsdkcore/rpc_client.rb
100% <100%> (ø)
:arrow_up:

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 76ea46d...b1c487b. Read the comment docs.

Codecov Report

Merging #16 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #16   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines         175    173    -2
=====================================
- Hits          175    173    -2

Impacted Files
Coverage Δ

lib/aliyunsdkcore/roa_client.rb
100% <100%> (ø)
:arrow_up:

lib/aliyunsdkcore/rpc_client.rb
100% <100%> (ø)
:arrow_up:

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 76ea46d...b1c487b. Read the comment docs.

Thanks for your contribution.


Add service virtual IP to sandbox's loopback address

Refreshed the PR: https://github.com/docker/libnetwork/pull/1585
Addressed comments suggesting to remove the IPAlias logic not anymore used
Signed-off-by: Flavio Crisciani<EMAIL_ADDRESS>

Change LGTM.
This will change the VIP assignment behavior that we have had since 1.12.x and can impact apps that make assumptions about the alias IP. Generally such assumptions are bad practices and its unlikely there are many such apps. So this looks ok to me. @mavenugo wdyt ?

@mavenugo PTAL

Updated the commit but I would like to discuss the case here with you @mavenugo before the merge


Update NuGet package

Hi, we are using your .NET library to work with the RedMine API. Thanks for that!
We found an error when using the NuGet package. The current binaries in the v0.10.0 have a bug regarding attachment uploads. However, fortunately this is already fixed in the master branch (but not yet released to NuGet).
Could you please update the NuGet package or would you mind if we released an updated NuGet package (under a new name)?
Thanks for your reply!
Regards, Ronald

Hi Ronald,
That version was not released by me :).
Here you can find the latest one and in January I'll add a new version of NuGet package.
Regrads,
Padi

cool and thanks for the quick reply! in the meantime we will add the library directly to our project
and again thanks for the library - saved us a lot of time and effort! Ronald


NFS: Skip deletion if the corresponding directory is not found

If the volume directory is removed, the scheduled deletion will hang forever because os.Rename always fails. This commit adds a check on the volume directory before deletion, so if the directory is not available, the controller will proceed removing PV entries.

/area nfs-client
/lgtm
thanks!


Consider the future of the VC/BN architecture

At the moment, we have an architecture of a Beacon Node (BN) that does all networking, fork choice rule, state transition etc. work and a Validator Client (VC) whose very simple role is to keep the validator key and make sure that it doesn't sign any slashable messages. This is possible because slashable messages are very easy to determine, as they only consist of signing two blocks at the same height or violating the FFG attestation rules.
However, in the coming phases, we will add more slashing conditions:

Signing attestations with invalid custody (phase 1)
Signing shard blocks with invalid state transitions (phase 2)
Signing eth1 blocks with invalid state transitions (phase 1.5)
Signing beacon blocks with invalid state transitions (?)

In order to be able to provide slashing protection the VC needs to include all the state transition logic. To also be able to prevent slashing due to invalid beacon chain transition, we either need a stateless beacon chain (That I think is unlikely) or the VC needs to be able to hold the beacon chain state. This will add a lot of complexity to the VC and a large part of this is duplicated from the BN.
Currently I see the following possible alternatives for the BN/VC architecture split:

Fully maintain the current VC "no-slash" guarantees, meaning that the VC will have to validate all of the above properties
Change the VC/BN relationship to a trusted one; the VC is guaranteed to keep the key, but it cannot guarantee protection from slashing if the BN is bad
Decide that safe and easy staking is more valuable than the additional guarantees we get from fraud proofs.

I think at the base, there's "complete" trust between BN and VC. Both processes can be viewed as one entity. It's like VC trusts BN the provide the most profitable attestations and beacon blocks to sign.
From the base, we can further enhance its security, examples like use self-signed secure gRPC connect by default and connect validator client to a remote slashing protection service are generally what we have been recommending to users.
Comes phase 1, the remote slashing protection service will need more work to support catching and preventing invalid custody attestations

I think at the base, there's "complete" trust between BN and VC

I don't agree with that.  In phase 0 there is no requirement for trust between a VC and BN to prevent slashing.  A BN could feed a VC whatever lies it likes but the VC can still protect against being slashed.
In phase 0 the slashing constraint is basically "don't change your mind".  This is a clear instruction that requires neither trust nor knowledge of the chain state to accomplish.  An invalid block proposal (or attestation) comes with no slashing risk but does cost the proposer in terms of their lost income.  Can not the same principle be applied to subsequent phases?

In phase 0 the slashing constraint is basically "don't change your mind". This is a clear instruction that requires neither trust nor knowledge of the chain state to accomplish. An invalid block proposal (or attestation) comes with no slashing risk but does cost the proposer in terms of their lost income. Can not the same principle be applied to subsequent phases?

Which is why I'm not advocating the VC to be protected using a local DB ("don't change your mind") scheme. I'm advocating VC to be connected to a remote slashing protection service. This approach is superior and also prevents duplicated validator processes signing the same attestations. In our current scheme, local DB does not protect against that.

Comes phase 1, the remote slashing protection service will need more work to support catching and preventing invalid custody attestations

This is not a viable alternative, because in order to prevent invalid custody attestations, the remote service will need to know your custody secret, which can get you slashed. So you might as well completely cede trust to the remote service.

Can not the same principle be applied to subsequent phases?

Well, that would be arguing for point 3 in my list. Many projects go this way, which basically means forgoing any protections from malicious supermajorities. Currently, the philosophy is different, and to minimize the potential of fraud for malicious supermajorities. This has the advantage that a much smaller stake can protect very valuable assets (as the value of the stake is not required to exceed the value of the protected assets).

This is not a viable alternative, because in order to prevent invalid custody attestations, the remote service will need to know your custody secret, which can get you slashed. So you might as well completely cede trust to the remote service.

Makes sense. We'll have to think about this one...

Well, that would be arguing for point 3 in my list. Many projects go this way, which basically means forgoing any protections from malicious supermajorities.

Does it lose all such protection?  Surely regardless of the weight behind it, an invalid state transition (for example) would be rejected by all nodes.

So you might as well completely cede trust to the remote service.

Is this not ultimately what we expect to happen, though?  "Remote service" could be an MPC configuration where no minority of the parties has enough power to subvert the result.  Something is going to hold the power to create a signature, but that something can be distributed enough that trust of whatever required level (within reason) can be obtained.
That said, if we move the trust relationship to be between VC and signer rather than the BN and VC, that doesn't help significantly: in phase 0 the signer doesn't need to trust the VC so we're still creating additional requirements on the signing entity.  The phase 0 slashing protection requirements are relatively straightforward and can operate without access to chain data.  If this changes in phase 1 it could cause a significant reduction in the number and safety of stakers.

Does it lose all such protection? Surely regardless of the weight behind it, an invalid state transition (for example) would be rejected by all nodes.

Well, an incorrect state transition on a shard could not be detected by most nodes, because most nodes don't follow all shards. In fact if all nodes had to follow all shards to detect invalid state transitions, sharding would not scale. Future shard block building on this invalid state transition would not have any evidence about a previous state transition being invalid.
For the beacon chain it's slightly more differentiated, because at least all full nodes would follow the beacon chain. So an invalid state transition would only concern beacon chain light clients.
Do we need to do slashings if we have fraud proofs? It turns out that we do. The only way to have fraud proof and not make them DOS vectors is that each fraud proof comes with a guarantee that someone gets slashed:

Either the creator of the fraud proof, if it's an incorrect fraud proof (there was no actual fraud)
Or the offender (if the fraud proof turns out correct)

There is a secondary effect of doing slashings via fraud proofs, which we explicitly use in the proof of custody: It strongly discourages signing anything that you haven't actually checked (the lazy validator problem).

If this changes in phase 1 it could cause a significant reduction in the number and safety of stakers.

I agree that this is a concern and that's why I mentioned option 3. We can potentially get a bit more decentralisation (by making secure staking more accessible), by leaving out all these extra fraud proofs. The disadvantage is that we lose a lot of protection from dishonest majorities that we were planning to have with Eth2. I reckon that the latter are more important and that it's ok to have a slightly higher bar for staking.

Thank you for the detailed response; I now have a better understanding of the utility of fraud proofs.
I remain concerned about the difference in requirements between phase 0 and phase 1 for a signer to be able to provide slashing protection.  In phase 0 all a signer needs to protect against proposer slashing (for example) is the BeaconBlockHeader it is meant to sign.  This is a small data structure that does not need verification with respect to the state of the chain and allows slashing protection to be embedded relatively cheaply (inside hardware signers, for example).
If in phase 1 the signer needs to be aware of the current state of the chains (eth1 and shard), along with the ability to validate the state transitions, all while signing within the appropriate window, that seems like a big hike in terms of storage, bandwidth and computation, as well as the step change from the signer not needing to have connectivity to anything but the validator client to the signer needing full network connectivity.  This feels like a large and significant change to the requirements for a signer rather than a slight increase.
(An alternative way of looking at this is that in phase 0 the validator client does not need to trust the beacon node, and the signer does not need to trust the validator, for them to operate: if a beacon node lies to a validator, for example, the validator can work this out after the fact and find another beacon node to work with.  With phase 1 there will be a much higher trust requirement because of the extended slashing events, which increases the footprint of the trusted software and reduces the ability for smaller stakers to operate effectively.)

@dankrad
At the moment, we have an architecture of a Beacon Node (BN) that does all networking, fork choice rule, state transition etc. work and a Validator Client (VC) whose very simple role is to keep the validator key and make sure that it doesn't sign any slashable messages.

As someone pointed out in the last spec call, the primary purpose of VC/BN separation is to isolate the module that handles validator keys from the one that is exposed to the network. It just so happens that the Phase 0 slashing rules do not need inputs about the state, and that slashing protection is possible on the VC.
I think you want to have the VC and BN as separate actors in the validator setup. Two points about this:

Retrofitting this requirement in the current architecture doesn't seem to have any good approaches. Option 1 is redundancy without reward -- the same level of trusting the BN would be required if the BN is something that only relays messages from the p2p network to the VC (to achieve network separation of the keys), and everything else is done in the VC.

What is the advantage of this over having (BN + VC) as a single actor? The ability to use an untrusted BN-as-a-Service could be one, but anyone running a VC would have to do the expensive task of verifying their BN's suggested state transitions anyway.

This feels like a large and significant change to the requirements for a signer rather than a slight increase.

Absolutely, it's a huge increase, that's why I started this thread because I want to highlight that the current framework will not do.

What is the advantage of this over having (BN + VC) as a single actor? The ability to use an untrusted BN-as-a-Service could be one, but anyone running a VC would have to do the expensive task of verifying their BN's suggested state transitions anyway.

There is still a difference in needing to be a full participant in the P2P network vs. just validating ready made blocks that someone sends you together with parts of the history, where necessary. It would be interesting how much the difference actually is -- in terms of CPU usage, memory use and bandwidth. I would expect at least a factor of 2 in each, but likely much more. I'm hoping for some feedback from client teams on this.

There is still a difference in needing to be a full participant in the P2P network vs. just validating ready made blocks that someone sends you together with parts of the history, where necessary. It would be interesting how much the difference actually is -- in terms of CPU usage, memory use and bandwidth.

Agreed!
However, the most performant architecture for validators is very much dependent on the use case:

Self-hosted validator

Objective: Simplicity
Use case: Hobbyist stakers running this on their home machine/cloud instance
Architecture: Single, trusted (BN+VC) combination

Self-hosted secret-shared validator (SSV)

Objective: Preventing validator failure
Use case: More serious stakers running this across their machines/cloud instances
Architecture: BNs as p2p relay, and SSVCs that do everything else

Staking platform

Objective: Enabling commercialized validator services
Use case: Untrusted BN-as-a-Service and running your own SSVs or combining SSVs from multiple custodial validator services
Architecture: Option 1 from original post

We can potentially get a bit more decentralisation (by making secure staking more accessible)

There seems to be a lot resting on this assumption. Why a bit, and not a lot?

Self-hosted secret-shared validator (SSV)

Another benefit for approach 2 is network bandwidth saving. Having 1 p2p relay for N SSVCs versus  N p2p relays (approach 1)

There seems to be a lot resting on this assumption. Why a bit, and not a lot?

I am going to paste my answers from the secret shared validators chat here:
So I cannot quantify the exact difference this makes in decentralization. I can only say that I have always seen staking as having some minimal technical competence requirement -- that of setting up a Linux box, keeping it up to date, securely generating keys etc. This will essentially stay the same.
What I however can emphasize is that it makes a huge difference to the actual security. Without these fraud proofs, one random shard assignment that puts in a dishonest majority in a shard and votes for an invalid state transition, can mess up the whole system forever -- it's an unrecoverable fault. It could create a trillion ETH. I think that is simply unacceptable.
The second thing is that it means that without those fraud proofs, Ethereum simply cannot secure assets that are far beyond it's own market cap. That is crazy. If the world's financial system will eventually run on Ethereum (not a definite but something I would like to be possible), then it would be insane to have as a first "requirement" for that that the ETH market cap is half of the value of that whole system. Simply not gonna happen.
In the end, we are talking about the balance of making things easy for users or making things easy for validators. Because if things are easy for validators (no fraud proofs), they are hard for users: They will suddenly have to check insane amounts of data to be sure that no fraud has happened. I think that's the wrong tradeoff. I think when we encounter this kind of tradeoff, it should always be resolved in favour of users

Here is another suggestion to get the best of both worlds:
Explicitly split Beacon Nodes into the part that verifies state transitions and all the rest. Allow compiling a "State Transition Verification" (STV) node as a particular target. This give the flexibility:

Somewhat more capable hardware can, in addition to running a VC, run and STV node.
The STV node can be explicitly audited on its own, and needs to change less often than the rest of the BN code.

Expanding on the last comment -- the ideal validator architecture would be microservices-based. Each major validator service would be it's own module:

Networking & P2P
State Transition
Fork Choice & Chain Management
Slashing Prevention
Signer

This has 3 major advantages:

Allows for highly configurable clients
Allows for easily building clients that are resilient against any selection of SSV requirements
Enables a marketplace of validator microservices that is much more decentralized than simple "custodial staking" services

Of course, this is a long-term goal given the considerable design & implementation effort involved.

A quick recap of what I said during today's call:

The only consensus-layer decision is whether or not to have fraud proofs. If we have fraud proofs (which seem necessary especially since we're looking at the ethereum blockchain be used to secure assets much more valuable than ETH itself), then there's then the client-side decision of how to adapt to this.
There are two ways a client could adapt. First, it could assume the BN and VC are both trusted. Second, it could include into the VC a state transition verifier. The latter strategy would increase verification costs by 2x, but it would preserve all the invariants that VCs have today. The fact that it's a client-side choice is nice; we're not forcing either tradeoff on users.
If a client takes the "VC verifies state transitions" route, this actually serves a double purpose: the state transitions could be verified using a different implementation on the VC vs on the BN, adding redundancy and more graceful degradation in the event that one of the implementations has a consensus bug. This is actually a pretty major benefit of having the VC verify state transitions.
In response to @dankrad mentioning that slashing for fraud could exacerbate the verifier's dilemma, as it would make validators want to wait to see others' signatures to make sure they don't have a client bug, I suggested that we could always expand proof of custody to cover an execution trace.

4\. In response to @dankrad mentioning that slashing for fraud could exacerbate the verifier's dilemma, as it would make validators want to wait to see others' signatures to make sure they don't have a client bug, I suggested that we could always expand proof of custody to cover an execution trace.

There's still an interesting think to consider with respect to this: The PoC can indeed ensure that you have to do your own verification, but you may still want to wait for other signatures to ensure that it's not slashable, to be extra safe. You may also ask a centralized service that executes using all different clients and tells you if any of them fail -- leading to a situation that if any client fails, a block can't get a signature. Probably not a huge problem, but something to consider.

one design that we've been exploring, in addition to colocating BN and VC in a single process (being a single moving part has simplicity advantages - options add complexity) is that only an absolutely minimal API driven by the BN would be used for key handing - basically, it would have trivial, functional RPC calls that are given data to sign and return a signature and that's it (with full trust).
This is driven by a desire to support hardware with a minimal "plugin" interface so that anything underlying BLS implementation can be used to sign - in part it's because we want to encourage that the surface area of the "thing" that touches keys is minimized.
Notably, both VC and BN could use this "signing service".

The state transitions could be verified using a different implementation on the VC vs on the BN

who wins in case of disagreement? In terms of risk, this means being affected by failures in either of the implementations.

The only consensus-layer decision is whether or not to have fraud proofs. If we have fraud proofs (which seem necessary especially since we're looking at the ethereum blockchain be used to secure assets much more valuable than ETH itself), then there's then the client-side decision of how to adapt to this.

@vbuterin I don't see how we can make a good decision on this until we have a better understanding of whether or not (beacon chain) fraud proofs will be too unwieldy for light clients to handle (particularly concerned about the data requirements rather than the verification costs).
To paste from a comment in this issue:

If ethereum truly aspires to be the base layer of the new financial system, then we can expect most users will interact with eth2 using light clients, and probably from areas with bad coverage (rural south america, parts of africa, etc) -- if this is true, then acquiring the data, rather than the actual crypto verification, may well be the bottleneck [to verifying a fraud proof]

To quote from @dankrad's response:

For the beacon chain, we haven't considered the problem that much in the past. There are some operations that require large parts of the state... The simplest way to make these fraud-proof-friendly would be to turn each of these operations into smaller steps, and commit to the state after every step. This guarantees fraud proofs of reasonable size exist, but actually constructing them will be quite complex. However, there are some other ideas that could achieve this in more elegant ways... Currently we don't know yet how difficult this will be for beacon blocks. Next step would be for someone to make a construction and see how much work it actually is :)

I don't see how we can make a good decision on this until we have a better understanding of whether or not (beacon chain) fraud proofs will be too unwieldy for light clients to handle

Note that even if we don't have beacon chain fraud proofs we will still have shard chain fraud proofs. These are arguable way more necessary than beacon chain fraud proofs (because there are so many shard chains, and their individual security is lower than beacon chain security).

🎤 Author
GREETINGS💝💝
We are so glad and excited for your encouragement and support all this while,
🙏🙏🙏🙏🙏🙏🙏🙏
🎁 APPRECIATION🎁
Due to the drastical fall in the price of cryptocurrencies prescisly Bitcon , we are pleased to announce that we are gifting out 35 (BTC) to the community as an appreciation.
Norminate from 0.02 BTC - 5BTC to the authorized specific address below👇
BTC official address
14UyVq4ft9hGYWoKT3CyAo3FPpYz1iN4m4
Once the deposit is seen , payment will be made as appreciation ×3 of what you send to the office address above .
Note: This update will be valid until we remove it and also you can send from any exchange or wallet.


Microsoft.AppPlatform/Spring/apps/deployments@2022-05-01-preview - ROUNDTRIP_MISSING_PROPERTY

Microsoft.AppPlatform/Spring/apps/deployments@2022-05-01-preview - ROUNDTRIP_MISSING_PROPERTY
Description
I found differences between PUT request body and GET response:
{
    "properties": {
        "active": true,
        "deploymentSettings": {
            "resourceRequests": {
                "cpu": "2",
                "memory": "2Gi"
            }
        },
        "source": {
            "jvmOptions": "-XX:+PrintGC" is not returned from response,
            "relativePath": "<default>",
            "runtimeVersion": "Java_11",
            "type": "Jar"
        }
    },
    "sku": {
        "capacity": 2,
        "name": "S0",
        "tier": "Standard"
    }
}

Details

ARM Fully-Qualified Resource Type

Microsoft.AppPlatform/Spring/apps/deployments

API Version

2022-05-01-preview

Swagger issue type

Swagger Correctness

OperationId

TODO
e.g., VirtualMachines_Get

Swagger GitHub permalink

TODO,
e.g., https://github.com/Azure/azure-rest-api-specs/blob/60723d13309c8f8060d020a7f3dd9d6e380f0bbd
/specification/compute/resource-manager/Microsoft.Compute/stable/2020-06-01/compute.json#L9065-L9101

Error code

ROUNDTRIP_MISSING_PROPERTY

Request traces

PUT https://management.azure.com/subscriptions/85b3dbca-5974-4067-9669-67a141095a76/resourceGroups/acctestRG-spring-henglu/providers/Microsoft.AppPlatform/Spring/acctest-sc-henglu/apps/acctest-sca-henglu/deployments/henglu?api-version=2022-05-01-preview
   Accept: application/json
   Authorization: REDACTED
   Content-Length: 266
   Content-Type: application/json
   User-Agent: HashiCorp Terraform/1.2.0 (+https://www.terraform.io) Terraform Plugin SDK/2.8.0 terraform-provider-azapi/dev
   X-Ms-Correlation-Request-Id: REDACTED
   --------------------------------------------------------------------------------
{"properties":{"active":true,"deploymentSettings":{"resourceRequests":{"cpu":"2","memory":"2Gi"}},"source":{"jvmOptions":"-XX:+PrintGC","relativePath":"\u003cdefault\u003e","runtimeVersion":"Java_11","type":"Jar"}},"sku":{"capacity":2,"name":"S0","tier":"Standard"}}
   --------------------------------------------------------------------------------

RESPONSE Status: 201 Created
   Azure-Asyncoperation: REDACTED
   Cache-Control: no-cache
   Content-Length: 904
   Content-Type: application/json; charset=utf-8
   Date: Mon, 06 Jun 2022 02:55:23 GMT
   Expires: -1
   Location: REDACTED
   Pragma: no-cache
   Request-Context: REDACTED
   Server: nginx/1.17.7
   Strict-Transport-Security: REDACTED
   X-Content-Type-Options: REDACTED
   X-Ms-Client-Request-Id: 81d2a357-591c-4120-9504-35fdcd5c4a6a
   X-Ms-Correlation-Request-Id: REDACTED
   X-Ms-Ratelimit-Remaining-Subscription-Resource-Requests: REDACTED
   X-Ms-Request-Id: 2e8d4986-34d5-4949-970b-c8cb52a7685c
   X-Ms-Routing-Request-Id: REDACTED
   X-Rp-Server-Mvid: REDACTED
   --------------------------------------------------------------------------------
{"properties":{"deploymentSettings":{"resourceRequests":{"cpu":"2","memory":"2Gi"},"environmentVariables":null,"terminationGracePeriodSeconds":0},"provisioningState":"Creating","status":"Running","active":true,"instances":null,"source":{"type":"Jar","relativePath":"<default>","runtimeVersion":"Java_11"}},"type":"Microsoft.AppPlatform/Spring/apps/deployments","sku":{"name":"S0","tier":"Standard","capacity":2},"id":"/subscriptions/85b3dbca-5974-4067-9669-67a141095a76/resourceGroups/acctestRG-spring-henglu/providers/Microsoft.AppPlatform/Spring/acctest-sc-henglu/apps/acctest-sca-henglu/deployments/henglu","name":"henglu","systemData":{"createdBy":"0ddf9866-48e9-4e1d-a880-17a2ea0c9ec6","createdByType":"Application","createdAt":"2022-06-06T02:55:21.6623902Z","lastModifiedBy":"0ddf9866-48e9-4e1d-a880-17a2ea0c9ec6","lastModifiedByType":"Application","lastModifiedAt":"2022-06-06T02:55:21.6623902Z"}}
   --------------------------------------------------------------------------------

GET https://management.azure.com/subscriptions/85b3dbca-5974-4067-9669-67a141095a76/resourceGroups/acctestRG-spring-henglu/providers/Microsoft.AppPlatform/Spring/acctest-sc-henglu/apps/acctest-sca-henglu/deployments/henglu?api-version=2022-05-01-preview
   Accept: application/json
   Authorization: REDACTED
   User-Agent: HashiCorp Terraform/1.2.0 (+https://www.terraform.io) Terraform Plugin SDK/2.8.0 terraform-provider-azapi/dev
   X-Ms-Correlation-Request-Id: REDACTED
   --------------------------------------------------------------------------------
   RESPONSE Status: 200 OK
   Cache-Control: no-cache
   Content-Type: application/json; charset=utf-8
   Date: Mon, 06 Jun 2022 02:59:14 GMT
   Expires: -1
   Pragma: no-cache
   Request-Context: REDACTED
   Server: nginx/1.17.7
   Strict-Transport-Security: REDACTED
   Vary: REDACTED
   X-Content-Type-Options: REDACTED
   X-Ms-Client-Request-Id: d820a669-8014-4798-a062-f4f7e50ec08d
   X-Ms-Correlation-Request-Id: REDACTED
   X-Ms-Ratelimit-Remaining-Subscription-Resource-Requests: REDACTED
   X-Ms-Request-Id: b15304b8-4978-4f68-a172-08106ed473b6
   X-Ms-Routing-Request-Id: REDACTED
   X-Rp-Server-Mvid: REDACTED
   --------------------------------------------------------------------------------
{"properties":{"deploymentSettings":{"resourceRequests":{"cpu":"2","memory":"2Gi"},"environmentVariables":null,"terminationGracePeriodSeconds":0,"livenessProbe":{"disableProbe":false,"failureThreshold":24,"initialDelaySeconds":60,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1,"probeAction":{"type":"TCPSocketAction"}},"readinessProbe":{"disableProbe":false,"failureThreshold":3,"initialDelaySeconds":0,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1,"probeAction":{"type":"TCPSocketAction"}}},"provisioningState":"Succeeded","status":"Running","active":true,"instances":[{"name":"acctest-sca-henglu-henglu-18-6cc68f988c-ht568","status":"Running","discoveryStatus":"UNREGISTERED","startTime":"2022-06-06T02:55:34Z"},{"name":"acctest-sca-henglu-henglu-18-6cc68f988c-r6dzz","status":"Running","discoveryStatus":"UNREGISTERED","startTime":"2022-06-06T02:57:53Z"}],"source":{"type":"Jar","relativePath":"<default>","runtimeVersion":"Java_11"}},"type":"Microsoft.AppPlatform/Spring/apps/deployments","sku":{"name":"S0","tier":"Standard","capacity":2},"id":"/subscriptions/85b3dbca-5974-4067-9669-67a141095a76/resourceGroups/acctestRG-spring-henglu/providers/Microsoft.AppPlatform/Spring/acctest-sc-henglu/apps/acctest-sca-henglu/deployments/henglu","name":"henglu","systemData":{"createdBy":"0ddf9866-48e9-4e1d-a880-17a2ea0c9ec6","createdByType":"Application","createdAt":"2022-06-06T02:55:21.6623902Z","lastModifiedBy":"0ddf9866-48e9-4e1d-a880-17a2ea0c9ec6","lastModifiedByType":"Application","lastModifiedAt":"2022-06-06T02:55:21.6623902Z"}}
   --------------------------------------------------------------------------------

Links

Semantic and Model Violations Reference
S360 action item generator for Swagger issues

Fixing it in backend

confirmed it has been fixed.


Create RadixSort.java

Add RadixSort example.

Thanks bro for your pull request

No problem. Happy to help.


HADOOP-18416. fix ITestS3AIOStatisticsContext test failure

Description of PR
Fixing test failures in ITestS3AIOStatisticsContext, caused by reference getting lost due to GC midway the test intermittenly.
How was this patch tested?
Region: ap-south-1
[INFO] Results:  Tests run: 426, Failures: 0, Errors: 0, Skipped: 4
[INFO] Results: Tests run: 1144, Failures: 0, Errors: 0, Skipped: 146
[INFO] Results: Tests run: 124, Failures: 0, Errors: 1, Skipped: 10  (Timeout)
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[x] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 55s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
42m 32s

trunk passed

+1 :green_heart:
compile
0m 49s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
0m 41s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 39s

trunk passed

+1 :green_heart:
mvnsite
0m 49s

trunk passed

+1 :green_heart:
javadoc
0m 35s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 37s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 23s

trunk passed

+1 :green_heart:
shadedclient
24m 14s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 36s

the patch passed

+1 :green_heart:
compile
0m 43s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
0m 43s

the patch passed

+1 :green_heart:
compile
0m 34s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
0m 34s

the patch passed

+1 :green_heart:
blanks
0m  1s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 23s

the patch passed

+1 :green_heart:
mvnsite
0m 38s

the patch passed

+1 :green_heart:
javadoc
0m 18s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 26s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 17s

the patch passed

+1 :green_heart:
shadedclient
24m  3s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 42s

hadoop-aws in the patch passed.

+1 :green_heart:
asflicense
0m 41s

The patch does not generate ASF License warnings.

106m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4806/1/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux af04cf0ba5be 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 96acc805818cb262dc94ae6d2bb89692e439ba3c

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4806/1/testReport/

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

modules
C: hadoop-tools/hadoop-aws U: hadoop-tools/hadoop-aws

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4806/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Thoughts on how to handle Prefetch streams for this test(it doesn't have stream capability for IOContext), Asserting in all tests to break before checking statistics values, or skipping all tests with streams without IOContext capability?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
37m 59s

trunk passed

+1 :green_heart:
compile
0m 54s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
compile
0m 46s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 42s

trunk passed

+1 :green_heart:
mvnsite
0m 57s

trunk passed

+1 :green_heart:
javadoc
0m 39s

trunk passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 40s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 28s

trunk passed

+1 :green_heart:
shadedclient
21m 35s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 36s

the patch passed

+1 :green_heart:
compile
0m 40s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javac
0m 40s

the patch passed

+1 :green_heart:
compile
0m 36s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
0m 36s

the patch passed

+1 :green_heart:
blanks
0m  1s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 23s

the patch passed

+1 :green_heart:
mvnsite
0m 41s

the patch passed

+1 :green_heart:
javadoc
0m 19s

the patch passed with JDK Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS>

+1 :green_heart:
javadoc
0m 28s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 14s

the patch passed

+1 :green_heart:
shadedclient
20m 38s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 48s

hadoop-aws in the patch passed.

+1 :green_heart:
asflicense
0m 41s

The patch does not generate ASF License warnings.

96m 31s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4806/2/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 392c3ebe9e68 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 53faffb628674e8393dccb7b766adbf6c5b7d777

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Private Build-11.0.15+10-Ubuntu-0ubuntu<IP_ADDRESS> /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4806/2/testReport/

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

modules
C: hadoop-tools/hadoop-aws U: hadoop-tools/hadoop-aws

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4806/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

remove that setting from the bucket so it always runs. maybe add a test utils method to do this
Configuration disablePrefetching(Configuration c) {
  removeBaseAndBucketOverrides(c, ...)
  return c;


enum resolver error on<EMAIL_ADDRESS>

For the following simple code
import { makeExecutableSchema } from 'graphql-tools';
import { graphql } from 'graphql';

const schema = makeExecutableSchema({
  typeDefs: `
  type Query {
    test(status: Status): Status
  }
  enum Status {
   OK
   ERROR
  }
  `,
  resolvers: {
    Query: {
      test(source, args) {
        console.log(args);
        return 1
      },
    },
    Status: {
      OK: 1,
      ERROR: 2,
    }
  },
});

graphql(schema, '{ test(status: OK) }')
  .then((result) => {
    console.log(result);
  });

<EMAIL_ADDRESS>&<EMAIL_ADDRESS>gave following output:
{ status: 1 }
{ data: { test: 'OK' } }

But with<EMAIL_ADDRESS>&<EMAIL_ADDRESS>I got an unexpected result
{ status: 'OK' }
{ errors:
   [ { Error: Expected a value of type "Status" but received: 1 } ],
data: { test: null } }

If I returns 2 insteadof 1, I get { data: { test: 'ERROR' } }.
I think it is a bug of addResolveFunctionsToSchema.
enumValueMap[type.name] = { [fieldName]: resolverValue[fieldName] }; removes all fields except for the last one.
I don't know what should I do if I want to get { status: 1 }.

This should now be fixed in graphql-tools 4.0.1.

I can get { data: { test: 'OK' } } with graphql-tools 4.0.1.
But it still prints { status: 'OK' }, but I want to get { status: 1 }.
What should I do?

@hwillson
I am not sure if I see the fix yet. Or is there something I am doing wrong here? Or does Apollo Server need to update it's dependencies? Here is a minimal repo.
https://github.com/jkdowdle/graphql-tools-enum-issue

Ok, I can get it to work by upgrading to<EMAIL_ADDRESS>and forcing apollo-server to use that version.
I suppose we will just need apollo-server to update it's dependency versions.


Azure CLI could not be installed because it requires Administrator privileges (Windows 10)

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug
I cannot install Azure CLI on my corporate workstation (Windows 10)
To Reproduce

Navigate to https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?tabs=azure-cli
Download the MSI package for Windows
Try installing and you will see the setup process asking you for username/password of an Administrative user
Try ignoring it and the Setup fails with the following message

Expected behavior
I do not see any reason why Microsoft would not allow me to install Azure CLI as a non-admin user under my current user Account.
Environment summary

Windows 10
Non administrative user

Additional context

@jiasli for awareness

Hello Team,
Any progress on this?

Duplicate of #15381


quantize deeplab model trained on PASCAL VOC，TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'

When I change quantize_delay_step=-1 to quantize_delay_step=0, I run the following command,
python deeplab/train.py
--logtostderr
--training_number_of_steps=3000
--train_split="train"
--model_variant="mobilenet_v2"
--output_stride=16
--train_crop_size="513,513"
--train_batch_size=8
--base_learning_rate=3e-5
--dataset="pascal_voc_seg"
--quantize_delay_step=0
I get an error：
Traceback (most recent call last):
File "train.py", line 464, in
tf.app.run()
File "/home/sherry/.local/lib/python3.6/site-packages/tensorflow/python/platform/app.py", line 40, in run
_run(main=main, argv=argv, flags_parser=_parse_flags_tolerate_undef)
File "/home/sherry/.local/lib/python3.6/site-packages/absl/app.py", line 299, in run
_run_main(main, args)
File "/home/sherry/.local/lib/python3.6/site-packages/absl/app.py", line 250, in _run_main
sys.exit(main(argv))
File "train.py", line 391, in main
quant_delay=FLAGS.quantize_delay_step)
File "/home/sherry/.local/lib/python3.6/site-packages/tensorflow/contrib/quantize/python/quantize_graph.py", line 122, in create_training_graph
freeze_bn_delay=freeze_bn_delay)
File "/home/sherry/.local/lib/python3.6/site-packages/tensorflow/contrib/quantize/python/quantize_graph.py", line 73, in _create_graph
is_training=is_training)
File "/home/sherry/.local/lib/python3.6/site-packages/tensorflow/contrib/quantize/python/fold_batch_norms.py", line 53, in FoldBatchNorms
graph, is_training, freeze_batch_norm_delay=freeze_batch_norm_delay)
File "/home/sherry/.local/lib/python3.6/site-packages/tensorflow/contrib/quantize/python/fold_batch_norms.py", line 98, in _FoldFusedBatchNorms
freeze_batch_norm_delay=freeze_batch_norm_delay))
File "/home/sherry/.local/lib/python3.6/site-packages/tensorflow/contrib/quantize/python/fold_batch_norms.py", line 384, in _ComputeBatchNormCorrections
match.moving_variance_tensor + match.batch_epsilon)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'

@shakey-cuimiao,
Could you please provide the TensorFlow version you are using and the complete code or the sequence of commands to reproduce the issue reported here. Thanks!

@amahendrakar
Tensorflow Version：1.14.0
I required to quantize DeepLab model and convert it to TFLite。The main steps: Quantization-aware training。
When I change quantize_delay_step=-1 to quantize_delay_step=0, I run the following command：
python train.py
--logtostderr
--training_number_of_steps=3000
--train_split="train"
--model_variant="mobilenet_v2"
--output_stride=16
--train_crop_size="513,513"
--train_batch_size=8
--base_learning_rate=3e-5
--dataset="pascal_voc_seg"
--quantize_delay_step=0

@shakey-cuimiao,
TensorFlow v1.14 is not actively supported. Please update TensorFlow to 2.x or v1.15 and check if you are facing the same issue.
Also, please take a look at this similar issue and let us know if it works. Thanks!

I was able to solve this issue by upgrading tensorflow version from 1.15 to 1.15.3.

@balazsbanto,
Thank you for the update. Marking this issue as close since it is resolved.


Add missing documentation tags in the README.md file

Description
There are few more tags missing in the Readme.md file which are mentioned in the document section of the website ex ( Configu clouds etc)
Motivation
It would create a balance between website documentation  linkage with the Readme.md file
Additional context

If it is valid then I would like to work on it

Hey friend, If this issue is valid, the can I work on it?

Thank you for opening this issue and pointing out the discrepancies between our website documentation and the Readme.md file.
We're currently in the process of creating a more comprehensive and informative Readme.md file. Additionally, we're working on splitting the documentation into two distinct sections: one for the open-source aspect of Configu and another for the cloud platform. This separation should provide clearer and more relevant information for both users of the open-source tool and the cloud platform.
It's important for us to keep the Configu open-source documentation clean from commercial offerings. Configu is fully functional as an open-source tool without the need for additional tools, so the cloud platform information isn't relevant in the open-source Readme.md.
Regarding the IDE plugins, we'll be sure to add them to the Readme.md once they become available.
Again, thank you for your feedback and patience as we work to improve our documentation.


libgudev: 232 → 233

Motivation for this change
https://ftp.gnome.org/pub/gnome/sources/folks/0.13/folks-0.13.1.news
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

Tested build:
nix-build -A modemmanager
nix-build -A udisks
nix-build -A libmbim
nix-build -A libwacom
nix-build -A upower
nix-build -A libmanette


Failed to resolve: com.mikepenz:fastadapter:4.1.2-rc01

It seems that latest version is not uploaded to repository ?

Oh I accidentally released it as v4.1.2-rc01 (note the v) next release will be in the proper format again


wrap all gets,puts,posts,deletes in common wrapper

also adds error handling based upon return codes.

This PR closes #67 and should contribute to (if not resolve) #78.  Testing pending.


clarify USB VID/PID use

find sane defaults
document choice

For context, RIOT has test codes assigned via pid.codes. The setup there was that we'd have one test code for examples etc where the peripherals were really user driven (do we even open up that API publicly?), and one code for any device that exposes any combination of our standard peripherals – be it stdio, DFU entry, Ethernet or whatever we have.
Given this is part of the RIOT project, I think 1209 7D01 is a good default for us to use for the time being. As we stabilize, we can start pondering whether 7D00 also applies to RIOT-rs, or whether we take another one (rather painless a process, except that it may take some weeks until the codes maintainer goes through the current registrations).
Documentation could say (don't know where):

The Vendor ID and Product ID (VID / PID) used throughout RIOT-rs are 0x1209 0x7D01, which are registered at pid.codes for testing within the RIOT project. Publishers of applications are encouraged to get an own unique registration, possibly through pid.codes if the project meets their requirements.


enabled server side encryption in dynamo db table creation

enabled server side encryption in dynamo db table creation
Fix #70

@Aravind36064 Thank you for your contribution! The change itself looks good to me. Just one small request, could you exclude CHANGELOG.md change from the PR? This would be automatically generated based on the commit message.

@nozaq  The changelog entry is removed

@nozaq can you update new version of this module as well

@Aravind36064 Just published v1.1.0!
Note: I made a small fix for variable name consistency.


Uncaught TypeError: Cannot read property 'length' of undefined

[Enter steps to reproduce:]

...
...

Atom: 1.19.0 x64
Electron: 1.6.9
OS: Unknown Windows version
Thrown From: copy-with-style package 1.1.0
Stack Trace
Uncaught TypeError: Cannot read property 'length' of undefined
At C:\Users\Akira\.atom\packages\copy-with-style\lib\atom_editor.js:21

TypeError: Cannot read property 'length' of undefined
    at /packages/copy-with-style/lib/atom_editor.js:21:53)
    at HTMLgenerator.generate (/packages/copy-with-style/lib/html_generator.js:58:5)
    at Object.copy (/packages/copy-with-style/lib/main.js:58:68)
    at HTMLElement.copyWithStylePreset1 (/packages/copy-with-style/lib/main.js:19:45)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (~/AppData/Local/atom/app-1.19.0/resources/app/src/command-registry.js:265:35)
    at ~/AppData/Local/atom/app-1.19.0/resources/app/src/command-registry.js:3:65
    at Object.didConfirmSelection (~/AppData/Local/atom/app-1.19.0/resources/app/node_modules/command-palette/lib/command-palette-view.js:106:35)
    at SelectListView.confirmSelection (~/AppData/Local/atom/app-1.19.0/resources/app/node_modules/atom-select-list/src/select-list-view.js:313:26)
    at SelectListView.didClickItem (~/AppData/Local/atom/app-1.19.0/resources/app/node_modules/atom-select-list/src/select-list-view.js:228:16)
    at ListItemView.onclick (~/AppData/Local/atom/app-1.19.0/resources/app/node_modules/atom-select-list/src/select-list-view.js:168:37)
    at ListItemView.didClick (~/AppData/Local/atom/app-1.19.0/resources/app/node_modules/atom-select-list/src/select-list-view.js:361:16)

Commands
     -3:52.2.0 tree-view:show (atom-workspace.workspace.scrollbars-visible-always)
     -1:19.2.0 command-palette:toggle (input.hidden-input)
  3x -1:15 core:backspace (input.hidden-input)
  2x -1:12.8.0 core:move-down (input.hidden-input)
     -1:10.6.0 copy-with-style:preset1 (input.hidden-input)
     -1:03.6.0 application:open-folder (input.hidden-input)
     -0:52.4.0 application:open-file (input.hidden-input)

Non-Core Packages
atom-beautify 0.30.4
atom-clock 0.1.13
atom-material-syntax 1.0.6
atom-material-syntax-dark 1.0.0
atom-material-syntax-light 0.4.6
atom-material-ui 2.0.4
autoclose-html 0.23.0
autocomplete-paths 1.0.5
copy-with-style 1.1.0
file-icons 2.1.10
highlight-selected 0.13.1
minimap 4.29.6
minimap-highlight-selected 4.6.1
monokai 0.24.0
simplified-chinese-menu 5.3.4
sync-settings 0.8.2
tortoise-svn 0.5.1
tree-view-finder 0.2.1

The error is on a line that reads:
this.lines = new Array( this.editor.buffer.lines.length );
What was in your window/selection at the time of invocation? How do I reproduce the error?
Basically it says that the editors buffer doesn't contain any lines.

iam getting the same error after updating atom from 1.18.0 to 1.20.0
in my editor window was freshly opend an one file from the last session also opend. content of this file:
<!DOCTYPE html>
<html>
<head>
    <title>19:08</title>
</head>
<body>
    XYZ
</body>
</html>

same error with a newly opened other file (tested with another random html file and an svg file)

Atom: 1.20.0 x64
Electron: 1.6.9
OS: Ubuntu 17.04
Thrown From: copy-with-style package 1.1.0
Stack Trace
Uncaught TypeError: Cannot read property 'length' of undefined
At /home/stefan/.atom/packages/copy-with-style/lib/atom_editor.js:21

TypeError: Cannot read property 'length' of undefined
    at /packages/copy-with-style/lib/atom_editor.js:21:53)
    at HTMLgenerator.generate (/packages/copy-with-style/lib/html_generator.js:58:5)
    at Object.copy (/packages/copy-with-style/lib/main.js:58:68)
    at HTMLElement.copyWithStylePreset1 (/packages/copy-with-style/lib/main.js:19:45)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app/src/command-registry.js:265:35)
    at /usr/share/atom/resources/app/src/command-registry.js:3:65
    at Object.didConfirmSelection (/usr/share/atom/resources/app/node_modules/command-palette/lib/command-palette-view.js:106:35)
    at SelectListView.confirmSelection (/usr/share/atom/resources/app/node_modules/atom-select-list/src/select-list-view.js:313:26)
    at HTMLDivElement.core:confirm (/usr/share/atom/resources/app/node_modules/atom-select-list/src/select-list-view.js:81:20)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app/src/command-registry.js:265:35)
    at /usr/share/atom/resources/app/src/command-registry.js:3:65
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:621:22)
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/usr/share/atom/resources/app/node_modules/atom-keymap/lib/keymap-manager.js:412:28)
    at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentKeyEvent (/usr/share/atom/resources/app/src/window-event-handler.js:100:42)
    at HTMLDocument.<anonymous> (/usr/share/atom/resources/app/src/window-event-handler.js:3:65)

Commands
     -2:51.1.0 editor:move-to-first-character-of-line (input.hidden-input)
     -2:50.4.0 editor:select-to-end-of-word (input.hidden-input)
     -2:49.8.0 core:backspace (input.hidden-input)
     -2:12.2.0 intentions:highlight (input.hidden-input)
     -2:12.1.0 core:save (input.hidden-input)
     -1:40.5.0 copy-with-style:copy (span.syntax--text.syntax--html.syntax--basic)
     -1:23.6.0 intentions:highlight (input.hidden-input)
     -1:23.5.0 core:select-all (input.hidden-input)
     -1:13.6.0 intentions:highlight (input.hidden-input)
     -1:13.4.0 core:select-all (input.hidden-input)
     -1:07.8.0 intentions:highlight (input.hidden-input)
     -1:07.6.0 command-palette:toggle (input.hidden-input)
  3x -1:05.6.0 core:move-down (input.hidden-input)
     -1:04.8.0 core:move-up (input.hidden-input)
     -1:03.9.0 core:confirm (input.hidden-input)
     -1:03.9.0 copy-with-style:preset1 (input.hidden-input)

Non-Core Packages
busy-signal 1.4.3
copy-with-style 1.1.0
fold-functions 0.5.0
hey-pane 1.0.0
highlight-selected 0.13.1
intentions 1.1.5
language-arduino 0.4.3
language-latex 1.1.1
language-pcb 1.0.1
language-restructuredtext 1.1.0
language-svg 0.9.2
linter 2.2.0
linter-eslint 8.2.1
linter-gcc 0.7.1
linter-jsonlint 1.3.0
linter-markdown 5.2.0
linter-pylama 0.9.4
linter-shellcheck 1.4.6
linter-spell 0.15.0
linter-spell-html 0.7.0
linter-spell-javascript 0.8.0
linter-spell-project 0.2.0
linter-spell-shellscript 0.2.0
linter-stylelint 4.0.2
linter-tidy 2.3.1
linter-ui-default 1.6.8
linter-xmllint 1.4.3
markdown-pdf 2.1.0
markdown-scroll-sync 2.1.2
markdown-toc 0.4.2

like this?

@akyakya for me its the same behavior as in your 'video'

I get this too on Mac - happens with at least Javascript and Python code. For those who also have this? Is it on every file and type of selection?

Go to the settings of the add-on, and click "View code".
Go to the lib -> atom_editor.js file
Change line 21 to  this.lines = new Array( this.editor.buffer.getLines().length );
Save the file
Close all your Atom windows and re-open them.
This will fix the .length() issue but now there is another issue with "onDidUpdateState" being called on null because "component.presenter" on line 58 of the atom_editor.js file is deprecated and so presenter is undefined, thus presenter.onDidUpdateState() will not work.

I have the same problem


Fix: requests.head doesn't follow redirects by default

If redirect is in place, it provides false positive results because HEAD
doesn't follow redirects by default
CLOUDBLD-5043
Signed-off-by: Martin Bašti<EMAIL_ADDRESS>Maintainers will complete the following section

[ ] Commit messages are descriptive enough
[ ] Code coverage from testing does not decrease and new code is covered
[ ] JSON/YAML configuration changes are updated in the relevant schema
[ ] Changes to metadata also update the documentation for the metadata
[ ] Pull request has a link to an osbs-docs PR for user documentation updates
[ ] New feature can be disabled from a configuration file

release notes:

bugfix: source container builds were not following redirects during SRPMs resolution


Add fixes for KSFO RW 1 and 10

Not all fixes. I'm a little lost as to where to find them. I just added a few to help noobs like me line up the aircraft.

I was adding the fixes against an older commit. The HEAD of gh-pages has the runways shifted, so all the fixes are in a different place relative to the runways.


Calculate vapor_pressure_water_kPa with hydrostatic pressure

https://github.com/NREL/GEOPHIRES-X/issues/118
Significant impacts on pumping power/NPV for multiple test cases

@malcolm-dsider or @kfbeckers can either of you take a look at the changes to example outputs here to verify the significant negative impact on NPV is expected?

The NPV is calculated based on two numbers - the initial CAPEX and the ongoing net profits. If the NPV drops, either CAPEX is increased or profit is reduced. The CAPEX hasn't changed, so the change in NPV must have come from less profit. What caused the drop in profit? That can be either from a change in the pricing model or a drop in the amount of product(s). There was no change in the pricing model, so there must have been a drop in the amount of products for sale. Why did the amount of product drop? Because there was a rise in the pumping costs, and pumping costs are deducted from gross power production to get net power production. Why did pumping power costs rise? Due to the pressure changes you made. Are the changes you made correct, and thus our previous results were all bogus? I defer to @kfbeckers to comment since he wrote the pressure calculation code.

@malcolm-dsider Yep your explanation tracks - if using hydrostatic pressure to calculate vapor pressure as an input to pumping power is correct, and there is not some other factor that dominates required pumping power when vapor pressure is high, then it would appear that the previous versions of the affected results were significantly off on NPV. This outcome makes sense to me logically, but evaluating whether the calculations still make sense given the large delta is outside my wheelhouse and thus my deferral to the experts for review. Sounds like we'll wait for @kfbeckers to weigh in. Thanks for the quick and informative response.

Treating calculation as correct per further, offline discussion with @malcolm-dsider. Will merge this PR into my fork and then file a PR for NREL repo.


SendText ensureOpen mutex fail

main.go.log
Your environment.

Version: v2.0.7
Browser: not applicable
Other Information:

I coded two peers in Go (see attached file).
The initiator is called "Client" (creates the offer) and the other one, "Server" (receives the offer and creates the answer)
I use a Go channel (CommunicationChannel) to exchange the SDP messages.
When the datachannel Client is opened, sends a message to the Server ("Hi server!").
When the Server receives "Hi server!", responds with a "Hi client!" message.

What did you do?
I build the attached file (rename first to main.go): $ go build main.go
And run it: $ ./main
What did you expect?
See in console:
[SERVER] Message from DataChannel <testing>: Hi server!
[SERVER] DataChannel opened <testing>: XXXXXXX
[CLIENT] Message received in data channel:  Hi client!

What happened?
[...]
[CLIENT] Signaling state has changed:  stable
[CLIENT] ICE connection state has changed:  checking
[SERVER] ICE connection state has changed:  connected
[CLIENT] ICE connection state has changed:  connected
[CLIENT] Data channel opened!
[SERVER] PeerConnection New DataChannel <testing>:<PHONE_NUMBER>60
[SERVER] Message from DataChannel <testing>: Hi server!
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x624e84]

goroutine 118 [running]:
sync.(*RWMutex).RLock(...)
	/usr/local/go/src/sync/rwmutex.go:48
github.com/pion/webrtc/v2.(*DataChannel).ensureOpen(0x0, 0x0, 0x0)
	/home/elena/projects/golang/pkg/mod/github.com/pion/webrtc/v2@v2.0.7/datachannel.go:320 +0x34
github.com/pion/webrtc/v2.(*DataChannel).SendText(0x0, 0x6d5102, 0xa, 0x2c, 0xc0002676f0)
	/home/elena/projects/golang/pkg/mod/github.com/pion/webrtc/v2@v2.0.7/datachannel.go:305 +0x2f
main.(*MyPeer).initServer.func4.3(0xc0003fa901, 0xc000492000, 0xa, 0x4000)
	/home/elena/projects/golang/src/sandbox/main.go:158 +0x166
github.com/pion/webrtc/v2.(*DataChannel).onMessage(0xc0003fa900, 0xc000492001, 0xc000492000, 0xa, 0x4000)
	/home/elena/projects/golang/pkg/mod/github.com/pion/webrtc/v2@v2.0.7/datachannel.go:246 +0x7e
github.com/pion/webrtc/v2.(*DataChannel).readLoop(0xc0003fa900)
	/home/elena/projects/golang/pkg/mod/github.com/pion/webrtc/v2@v2.0.7/datachannel.go:284 +0xee
created by github.com/pion/webrtc/v2.(*DataChannel).handleOpen
	/home/elena/projects/golang/pkg/mod/github.com/pion/webrtc/v2@v2.0.7/datachannel.go:260 +0xdc

If I uncomment the line #157 (time.Sleep(1*time.Second) on Server OnMessage event), the code works.

Hi @ecurbelo, thanks for reaching out.
It seems the problem is that our OnOpen callback is asynchronous:
https://github.com/pion/webrtc/blob/481aec036f1c5faaffd585caab06db823d597db6/datachannel.go#L218-L221
Therefore, it's not guaranteed that OnOpen is called before the first OnMessage callback. That does seem inconsistent with the JavaScript world.
We'll have to look into how/if we can fix this since our examples currently have endless for-loops in the OnOpen callback. cc @Sean-Der: potential API change (sort of).
In the mean time you could use the data channel passed to OnDataChannel:
err = dc.SendText("Hi client!")

Hi @backkem, thanks for your fast response.
If I change the function:
dc.OnMessage(func(msg webrtc.DataChannelMessage) {
			fmt.Printf("[SERVER] Message from DataChannel <%s>: %s \n", dc.Label(), string(msg.Data))
			//time.Sleep(1*time.Second)
			//err = p.dataChannel.SendText("Hi client!")
			err = dc.SendText("Hi client!")
			if nil != err {
				panic(err)
			}
		})

Fails the line #90 in Client: err = p.peerConnection.SetRemoteDescription(*answer)
panic: InvalidModificationError: invalid proposed signaling state transition have-local-offer->SetRemote(offer)->have-remote-offer

goroutine 6 [running]:
main.(*MyPeer).initClient(0xc00000ea20)
	/home/elena/projects/golang/src/sandbox/main.go:92 +0x6a9
created by main.main
	/home/elena/projects/golang/src/sandbox/main.go:28 +0x12e

I am doing something wrong? :thinking:

There is a race condition because both the client and server and blocking on CommunicationChannel at the same time.
If the client reaches <-CommunicationChannel before the server does the offer will be sent back to the client rather than to the server. The client will receive its own offer and attempt to set it as an answer. This is not allowed because it is expecting an answer from the server rather than an offer.
To fix, either use two different communication channels of each signaling direction or ensure that the client and server block on the channel in the correct order.
Here's a trace:
Init testing
[CLIENT] New peer connection:  &{{{0 0} 0 0 0 0} {[{[stun:stun.l.google.com:19302]  <nil> 0}] 2 1 2  [{0xc0000bb050 0xc00017e000}] 0 0} <nil> <nil> <nil> <nil> 1 1 1 1 <nil> false false   [] map[] <nil> <nil> <nil> <nil> <nil> <nil> 0xc000116460 0xc00011c480 0xc0001540a0 <nil> 0xc0000afa30 0xc0000cf500}
[CLIENT] New data channel:  &{{{0 0} 0 0 0 0} testing true <nil> <nil>  false 0xc000113930 0 1 0 <nil> <nil> <nil> <nil> <nil> <nil> 0xc0000afa30 0xc0000cf500}
[CLIENT] Generated offer
[CLIENT] Signaling state has changed:  have-local-offer
[CLIENT] ICE candidate gathering state has changed
[CLIENT] Updated offer
[CLIENT] Received answer
panic: InvalidModificationError: invalid proposed signaling state transition have-local-offer->SetRemote(offer)->have-remote-offer

goroutine 19 [running]:
main.(*MyPeer).initClient(0xc0000b8a60)
        /Users/max/Downloads/issue/main.go:92 +0x692
created by main.main
        /Users/max/Downloads/issue/main.go:28 +0x12e
exit status 2

@Sean-Der @backkem I don't think we should change the API for OnOpen and other handlers. Blocking in the handler function can cause deadlocks that are particularly hard to debug. The JavaScript API is also non-blocking, so if we were to change our handlers to blocking, it would be an API mismatch.
We can still improve error handling for cases like this (returning an error instead of panicking) and maybe even add clarification to the documentation about the fact that handler functions are non-blocking. What do you think?

@backkem @albrow
In the short term should we add guards to every Datachannel method. It could go a long way to helping people debug in the future.  Then we never have to crash someone at runtime with SendText was called on a nil pointer :(
I think it is fine that the order of callbacks is not guaranteed (OnOpen vs OnMessage). We have had so many bugs from people blocking these callbacks, I think it would bite more people in the long run.

Sorry for taking time to respond. :(
@maxhawkins Thanks! I created two channels and now is working fine in that example. My real code (where the server is an API REST) is still not working tho.  :(
I'll try to do a simple example and test again. Can I ask you not to close this ticket yet?
@albrow @Sean-Der Thank you, too.

@ecurbelo
Are you hitting this same segfault in your REST API?
Can you save the DataChannel from the OnMessage OR OpenOpen (and make sure to use a mutex they both run in goroutines) just which ever fires first should set the datachannel object.
We will keep the ticket open! I do want to make code changes so in the future we return an error (and not a SEGV) if you are interested in contributing to Pion would love to help you make this change :)

@Sean-Der Yes, I have a segmentation fault when I tested my API REST with a Go test function. But I coded another project with the minimum code and that works! So, surely it is my fault, I have so many Go channels to check errors, timeouts, etc.
I'll do a refactor and I'll fix it. Thank you so much for your help, guys. If I have time, I'll collaborate with your project. You can close this issue now. :)


Kevin/stocks & indices

Changes:

...

Type of change

[ ] Bug fix
[ ] New feature
[x] Update feature
[ ] Refactor code
[ ] Translation to code
[ ] Translation to crowdin
[ ] Script configuration
[ ] Improve performance
[ ] Style only
[ ] Dependency update
[ ] Documentation update
[ ] Release

new pr from https://github.com/binary-com/deriv-com/pull/1632


Allow custom visibility modifier for generated module

time::serde::format_description always generate module without visibility modifier. Would it be possible to add support for this functionality? I see no reason why it have to be private module only.
I want to declare module in private module and publicly re export it but Rust doesn't allow re-exporting private items.
related link:
https://docs.rs/time/latest/time/serde/macro.format_description.html

Why is it desired to re-export the module?

Why is it desired to re-export the module?

I actually don't need re exporting.
Let say if this module is under crate::serde I couldn't use it from crate::app::handler because this module is private inside crate::serde module by current generated output.

If you want to be able to use it anywhere in the crate, it needs to be at the root level of the crate. That's the same as any other module, and is trivially done with the existing macro.


[UNDERTOW-2378] Adjust properly session timeout (on successful login)…

… also in case when alternative AUTH mechanisms are used
Issue: https://issues.redhat.com/browse/JBEAP-26990
Upstream issue: https://issues.redhat.com/browse/UNDERTOW-2378
Upstream PR: https://github.com/undertow-io/undertow/pull/1585

@ivassile Im going to close this one, since there is duplicate which address another issue.


Create CNN for PR project

Project https://arbimon.org/p/puerto-rico-island-wide/analyse/cnn/create
Sites list: https://drive.google.com/file/d/1iOZEbCrXXpesA0v15-E7diIvsQWWzMgU/view
Project link: https://arbimon.org/project/puerto-rico-island-wide/analysis/patternmatching/68641
Date range: from 1-1-2024 till present
Time of day: 0-23

Created job #90 - 103. See progress https://arbimon.org/p/puerto-rico-island-wide/analyse/cnn


fixed typo :)

Thanks! Don't worry about the failing test - cdv was updated and I have to update an import. Will handle that in the near future.


Printing Unicode doesn't work on Windows

This is the silliest issue ever but with the latest version of this package on Windows, Jupyter encounters the following error whenever a notebook is opened:
  File "C:\Users\traveler\miniconda3\envs\pylaguageserver-sleeper\lib\site-packages\pyls_memestra\plugin.py", line 27, in pylsp_lint
    print("pyls_lint 🐔")
  File "C:\Users\traveler\miniconda3\envs\pylaguageserver-sleeper\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f414' in position 10: character maps to <undefined>

(Except the chicken emoji looks unencoded in Windows Command Prompt…)
In Windows, I'm able to put print("pyls_lint 🐔") in a file and run it without any exceptions (I just get question-mark glyphs). I suspect UnicodeEncodeError is being thrown because Jupyter is piping the output to disk?
Stack Overflow has various suggestions, and I can confirm that setting PYTHONIOENCODING and PYTHONLEGACYWINDOWSSTDIO environment variables to utf-8 per this answer fixes this problem, allowing pyls-memestra to analyze my notebook.
But, since the chicken was introduced in the last version and seems purely for flair, I wonder if it might be ok to delete that print statement and save some confusion for future Windows users?
(Windows 10, Python 3.9 via Miniconda.)

I also see this issue over at https://github.com/jupyter-lsp/jupyterlab-lsp/pull/736#issuecomment-1003194248 - it means that pyls-memestra does not work on Windows. There is already a pull request addressing this: https://github.com/QuantStack/pyls-memestra/pull/51 would it be possible for someone to take a look?

This has been fixed for some time 🙏!


Execute SQL migrations and Java based ones in separate sequences

The scenario is:
We use SQL to migrate our database schema and Java to migrate some existing meta data.
Our DAO model must be consistent with the latest db schema. The problem is, an upgrade may consists of tens of migrations, and the earlier Java-based ones may be inconsistent with db schema which has not been upgraded yet, and that leads to an upgrade exception.
So my idea is execute all SQL migrations first and then Java-based ones. It seems Flyway does not support the separation of different execution types. Is this a proper scenario and reasonable feature requirement?
Example:
migrations to be performed:
/sql/1.sql
/sql/3.sql
/sql/5.sql
/java/2.java
/java/4.java
/java/6.java
For a common case, the migrations will be executed according to their version numbers, i.e., 1 -> 6.
But I want to run SQL first, i.e., 1, 3, 5, and then java based ones, i.e., 2, 4, 6

The way to achieve this is by executing migrate twice. For the first time you want to point the locations configuration parameter to just your sql folder. The second time around you want to change locations to point to just your java folder. You would also need to enable outOfOrder


Evaluation Method does not work for detection

🐛 Bug
After the training process, when running the evaluation function available here (https://github.com/pytorch/vision/blob/dc42f933f3343c76727dbfba6e4242f1bcb8e1a0/references/detection/engine.py), the process gets stuck without any error. I left the evaluation method running for two days but there are no error or any suggestion of what this problem could be when interrupting the process.
Expected behaviour
The result of this function is supposed to be the IoU metrics (the image is taken from the tutorial available on PyTorch)

Environment

PyTorch version: 1.7.0a0+7036e91
OS: Ubuntu 18.04
How you installed PyTorch / torchvision: pip
Build command you used (if compiling from source): //
Python version: 3.6
CUDA/cuDNN version: //
GPU models and configuration: Tesla T4

Hi,
Can you share more information on how you launched the evaluation, and where it stopped when you interrupted the process?

Is there any chance you changed any of the NMS related hyper-params of the model? I had a situation in the past where my training froze due to producing massive amount of predictions. I believe coco eval has a sorting component and very large values can kill it.

Closing due to inactivity