Vulnerability roundup 89: thunderbird-68.9.0: 5 advisories [8.8]

search, files

[ ] CVE-2020-12417 CVSSv3=8.8 (nixos-20.03)
[ ] CVE-2020-12419 CVSSv3=8.8 (nixos-20.03)
[ ] CVE-2020-12420 CVSSv3=8.8 (nixos-20.03)
[ ] CVE-2020-12418 CVSSv3=6.5 (nixos-20.03)
[ ] CVE-2020-12421 CVSSv3=6.5 (nixos-20.03)

Scanned versions: nixos-20.03: dabbc5a5603. May contain false positives.
Cc @edolstra
Cc @lovesegfault
Cc @nbp

20.03 is Frozen and EOL.
As such, issue is closed.


Fix wool touches

Previously there were two onWoolPickup events It also only would register when you picked it up from an inventory, now it registers the pick up even if you picked it up from the ground. I also broadcasted the wool touch.
the wool touches should be broadcasted to only players on the team and right now I don't see where you are tracking who is on what team, so if you are let me know and ill start work on team chat

https://github.com/twizmwazin/CardinalPGM/pull/47


Added Buy Me a Coffee link

I've fixed indentation issues as well, I've only made changes in CSP, buttonContainer, and added some CSS.

Thanks for the help @shehrozsheikh


API data load testing.

Form.io data load/subission. Use the Student Application to test the amount of submission that the form.io server can handle. As a suggestion, we can have a Student Application payload sample submitted multiple times directly to the form.io server and check how the form.io server handles the requests till it stops.
Camunda submission capacity trying to establish the workers capacity to handle the requests.
Check the performance by increasing the number of PODs.
Check if there is the best way to configure workers maxJobsToActivate.

Related to Ticket #2155


Add persist state option

Hey there @davezuko,
Awesome boilerplate, many thanks!
I was going to suggest that you also include the persist state functionality that comes with redux-devtools. I find this to be one of the best addons to redux, and think that users should at least have the option to use it.
Here's what my configureStore.js looks like with it it place.
import { persistState } from 'redux-devtools';

function getDebugSessionKey() {
  // You can write custom logic here!
  // By default we try to read the key from ?debug_session=<key> in the address bar
  const matches = window.location.href.match(/[?&]debug_session=([^&]+)\b/);
  return (matches && matches.length > 0) ? matches[1] : null;
}

function withDevTools (middleware) {
  const devTools = window.devToolsExtension
    ? window.devToolsExtension()
    : require('containers/DevTools').default.instrument()
  return compose(middleware, devTools, persistState(getDebugSessionKey()))
}

Also, I just found this boilerplate, so maybe I am missing something. If so, please let me know.
Cheers,
Thomas

I'll give it a shot, thanks for the recommendation. Sorry for the slow reply.

Slowly formalizing 2.0.0 milestone, moved this to topics for consideration: https://github.com/davezuko/react-redux-starter-kit/wiki/v2.0.0-Plans. Will create a new issue when it's a confirmed feature (just trying to parse through the issues right now and filter it out to problematic issues while keeping recommendations/requests in another doc).
I realize this should be fairly trivial, just haven't had time to get to it unfortunately.


Deploy to Glitch

[x] Detect when running on glitch
[x] Build a good default config for glitch - hostname, data dir, etc
[ ] Add Remix on Glitch button to README

What else?

An obnoxious gotcha: Started building this thing with the latest node.js v22. But, Glitch only supports v16 as the latest. Hopefully things still work?

Seems like things work on Glitch and the button in README imports into a new project. I think that's enough for this issue, will file follow-ups as further gotchas arise


Grab Super and Left Control in window

For example, in the xterm window, I cannot show the menu or prompt when the cursor is focusing the window.
I cannot get the press event.

I only succeeded to grab the Super Left key.


AnimationPlayer don't memories time position in editor (red line)

Operating system or device - Godot version:
Window 7, v2.1.3.stable.official
Issue description:
Red Line from AnimationPlayer go back to 0 time after reselecting.
It looks like animation is on correct position. But you got fooled.

It doesn't matter if animation is auto play = on.
I expect red line should be on same place after reselecting animationplayer.
Link to minimal example project:
issue_save_and_animationplayer.gz
together with #8994 you can get sometimes magically changes :smirk:

Fixed in master, still relevant to 2.1.5

Thanks, closing as fixed in 3.1 then. At this stage only critical bug fixes will still be considered for the 2.1 branch.


News errors with HA 2022.4.0

Logger: homeassistant.setup
Source: setup.py:298
First occurred: 00:11:30 (1 occurrences)
Last logged: 00:11:30
Unable to prepare setup for platform xiaomi_miot_raw.fan: Platform not found (cannot import name 'ATTR_SPEED' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/init.py)).
Logger: homeassistant.components.sensor
Source: helpers/entity_registry.py:383
Integration: Capteur (documentation, issues)
First occurred: 00:11:51 (1 occurrences)
Last logged: 00:11:51
Error adding entities for domain sensor with platform xiaomi_miot
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 510, in _async_add_entity
entry = entity_registry.async_get_or_create(
File "/usr/src/homeassistant/homeassistant/helpers/entity_registry.py", line 383, in async_get_or_create
raise ValueError("entity_category must be a valid EntityCategory instance")
ValueError: entity_category must be a valid EntityCategory instance
Cette erreur provient d'une intégration personnalisée
Logger: custom_components.xiaomi_miot_raw.deps.xiaomi_cloud_new
Source: custom_components/xiaomi_miot_raw/deps/xiaomi_cloud_new.py:181
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 00:11:31 (1 occurrences)
Last logged: 00:11:31
Timeout while loading MiCloud device list

#503

ValueError: entity_category must be a valid EntityCategory instance

#504
Upgrade to master branch.

Hi,
Same issues here:

Logger: homeassistant.setup
Source: setup.py:298
First occurred: 11:46:58 (6 occurrences)
Last logged: 11:46:58
    Unable to prepare setup for platform xiaomi_miot.fan: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).     Unable to prepare setup for platform xiaomi_miot.climate: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).     Unable to prepare setup for platform xiaomi_miot.cover: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).     Unable to prepare setup for platform xiaomi_miot.humidifier: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).     Unable to prepare setup for platform xiaomi_miot.device_tracker: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).

The same over here. Integration is loaded as it shows in the integration overview nevertheless it does not load any entity it finds by configuring the integration.

Same here.. just upgraded to the master branch and have the same errors as @Krzysztonek describe above.
I'm using Home Assistant 2022.4.1.
Logger: homeassistant.setup
Source: setup.py:298
First occurred: April 8, 2022, 23:17:35 (6 occurrences)
Last logged: April 8, 2022, 23:17:35

Unable to prepare setup for platform xiaomi_miot.device_tracker: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).
Unable to prepare setup for platform xiaomi_miot.fan: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).
Unable to prepare setup for platform xiaomi_miot.cover: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).
Unable to prepare setup for platform xiaomi_miot.climate: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).
Unable to prepare setup for platform xiaomi_miot.humidifier: Platform not found (cannot import name 'SPEED_OFF' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/__init__.py)).

Fixed in v0.5.6.


⚠ Processors has degraded performance

In 07a5977, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 46 ms

Resolved: Processors performance has improved in e361f14.


GET - /eth/v1/validator/{pubkey}/feerecipient - Specify expected behaviour when the fee recipient is not registered for {pubkey}

Issue description:
When calling /eth/v1/validator/{pubkey}/feerecipient for a {pubkey} with no fee recipient registered, the response differs depending of validator client implementation:
Lighthouse:
Lighthouse response is
{
    "code": 500,
    "message": "INTERNAL_SERVER_ERROR: no fee recipient set",
    "stacktraces": []
}

(Note: https://github.com/sigp/lighthouse/issues/3507 is open about error code)
Teku:
Teku does not allow to start a validator client without setting a fee recipient.
At start, Teku validator client logs are:
2023-01-30 12:53:28.336 FATAL - Invalid configuration. --validators-proposer-default-fee-recipient or --validators-proposer-config must be specified when Bellatrix milestone is active

then Teku validator client quits.
==> A user cannot query /eth/v1/validator/{pubkey}/feerecipient on a Teku validator client if no (at least default) fee recipient is registered for {pubkey}.
Prysm:
Currently, Prysm validator client uses a custom gRPC API to communicate with the beacon node.
This gRPC API has special GetFeeRecipientByPubKey method which is the GET equivalent of Beacon API prepareBeaconProposer: The request body contains a validator pubkey. The beacon node responds the corresponding fee recipient. If no specific fee recipient for this pubkey is known by the beacon node, then the beacon node answers the default fee recipient specified in beacon node configuration. If no default fee recipient is specified in beacon node configuration, then the beacon node answers the burn address 0x0000....
Proposals:
Proposal 1:
Define in Key Manager API specification that any call to /eth/v1/validator/{pubkey}/feerecipient validator client API with {pubkey} with no registered fee recipient should return HTTP 404.
Proposal 2:
Define in Beacon API specification a new GET fee_recipient method. This method could take in query parameters a list of validators pubkey/index and could return corresponding fee recipient addresses.
In this case, the call to /eth/v1/validator/{pubkey}/feerecipient validator client API will be able to answer the default fee recipient specified in beacon node configuration if no specific fee recipient is registered for {pubkey} in the validator client.
However, if {pubkey} has a registerd fee recipient in the validator client configuration, the validator client will have 2 possibilities:

Returning directly fee recipient from validator client configuration corresponding to {pubkey}
Querying the newly defined Beacon API GET fee_recipient method and returning the result.

1. and 2. may differ.

So basically we're saying that we should allow validators to start in an invalid state?
Teku took the approach that if configuration is invalid, that we should not allow the user to run, because they can fix it and get into a valid configuration, if they know the problem.
My preference would be that people aren't allowed to start up with a configuration that won't work, so from a teku perspective I think that will remain for now at least.
 As a general rule i do dislike 404, as it's indistinguishable from a route that is not implemented in a way...
500 is probably on the harsh side depending on how you look at it, but I can definitely see the argument for using it in preference to 404.
If you decide that its a valid state for a validator to be, and decide to startup, then you accept this complexity. I think that the result is an error whichever way you cut it, and it's probably not hugely important the code, though I'd probably steer towards a 400 or 500 in preference to a 404. Regardless of which way, I think we definitely want a body, which is ever so slightly not the normal with a 404, as generally its handled by the router, and you don't get an option (admittedly you would in this circumstance).

I do think this goes against the original intention of having these apis throw as few errors as possible. that's why at prysm ours just goes with whatever the default was even if it's not set because after you import the key it's going to use it anyways.


cleanupOnSuccess for hypershift

Description

Destroys HostedCluster resources as well as Management cluster after completion
Installs grafana agent on both cluster to remote write metrics

Fixes #140 #141

Codecov Report

Merging #134 (6416fa8) into master (e745b4a) will decrease coverage by 0.50%.
The diff coverage is 73.91%.

@@            Coverage Diff             @@
##           master     #134      +/-   ##
==========================================
- Coverage   93.94%   93.44%   -0.51%
==========================================
  Files          24       24
  Lines         974      991      +17
==========================================
+ Hits          915      926      +11
- Misses         59       65       +6

Flag
Coverage Δ

gha
93.44% <73.91%> (-0.51%)
:arrow_down:

python-3.9
93.44% <73.91%> (-0.51%)
:arrow_down:

unit
93.44% <73.91%> (-0.51%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

dags/openshift_nightlies/dag.py
94.71% <68.42%> (-2.46%)
:arrow_down:

...nshift_nightlies/tasks/utils/platform_connector.py
100.00% <100.00%> (ø)

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 e745b4a...6416fa8. Read the comment docs.

@Harshith-umesh @morenod please take a look when you have a sec. thanks!


Finalize Alpine Linux / linux-musl-x64 support

Thanks to @janvorli's fix in #7522 we can now build the objwriter package on Alpine Linux (in the Docker image from https://github.com/dotnet/corert/issues/7510#issuecomment-501516667 - mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.6-WithNode-cfdd435-20190521001804), by invoking:
./build.sh objwriter Release

However, even while the ObjectWriter package itself builds, CoreRT does not pick it up. CoreRT expects to find a published ObjectWriter package, musl edition, in the nuget feed. The error message when invoking the above is therefore (after having successfully built the native components of CoreRT + objwriter):
 Restoring packages for /corertalpine/src/ILCompiler/ObjectWriter/ObjectWriter.depproj...
  Installing Microsoft.DotNet.ObjectWriter 1.0.0-alpha-27619-05.
/corertalpine/src/ILCompiler/ObjectWriter/ObjectWriter.depproj : error NU1101: Unable to find package runtime.linux-musl-x64.Microsoft.DotNet.ObjectWriter. No packages exist with this id in source(s): dotnetfeed dotnet-core, dotnetfeed dotnet-coreclr, myget.org dotnet-buildtools, myget.org dotnet-core, myget.org dotnet-corefxlab, myget.org system-commandline, nuget.org
  Generating MSBuild file /corertalpine/bin/obj/Linux.x64.Release/ObjectWriter/ObjectWriter.depproj.nuget.g.props.
  Generating MSBuild file /corertalpine/bin/obj/Linux.x64.Release/ObjectWriter/ObjectWriter.depproj.nuget.g.targets.

Proper fix: Publish linux-musl-x64 packages
I suspect the best longtime fix would be for CoreRT to publish linux-musl-x64 packages by adding a linux-musl-x64 flavor to the eng/platform-matrix.yml, if I'm understanding the infrastructure correctly.
If this is the way going forward, would it then be as simple as just adding it there, or do things need to be changed in other places too?
Since CoreCLR builds musl flavors and we can now build those manually for CoreRT with janvorli's fix, I suspect this should be a pretty simple change, right?
Workaround for now: Patch CoreRT to pick up the built objwriter package
For now I'm fine with having to build CoreRT myself on Alpine Linux, even if we need to do some manual patches to the tree to allow CoreRT to pick up the built objwriter package.
But, how should I patch it so that it does that? I'm assuming the ObjectWriter.depproj is part of the solution (or the problem).

I'm assuming the ObjectWriter.depproj

Right, part of the fix should be to disable building of the .depproj project when we are building proper objectwriter. Something like this in https://github.com/dotnet/corert/blob/master/src/dirs.proj#L17 should do the trick:
<Project Include="ILCompiler\ObjectWriter\ObjectWriter.depproj" Condition="'$(ObjWriterBuild)' != 'true'" />

A similar condition may need to be in a one or two more other places to get you a working build out of the box.

Once build.sh objwriter works on Alpine, we can add it to the official build and the official build will publish the ObjectWriter package to save everybody from building LLVM every time.

Thank you Jan!

Once build.sh objwriter works on Alpine
It already does, after #7522 (if what you mean is building the objectwriter native package). If you meant everything building, then gotcha. We seem to be almost there.

With your change, I get to ILC compiling the BasicThreading test, then it fails to find the objwriter library:
 /usr/bin/clang
  Generating native code
EXEC : error : Unable to load shared library 'objwriter' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libobjwriter: No such file or directory [/corertalpine/tests/src/Simple/BasicThreading/BasicThreading.csproj]

So I'm assuming on the condition $(ObjWriterBuild) == 'true' we need to copy the objwriter.so file some time during the build.

Yes, something like this in ILCompiler.csproj should do it:
  <PropertyGroup Condition="$(ObjWriterBuild) == 'true'">
    <ObjWriterLibrary Condition="'$(OSGroup)' == 'Windows_NT'">objwriter.dll</ObjWriterLibrary>
    <ObjWriterLibrary Condition="'$(OSGroup)' == 'Linux'">libobjwriter.so</ObjWriterLibrary>
    <ObjWriterLibrary Condition="'$(OSGroup)' == 'OSX'">libobjwriter.dylib</ObjWriterLibrary>
  </PropertyGroup>

  <ItemGroup Condition="$(ObjWriterBuild) == 'true' and '$(OSGroup)' == 'Windows_NT'">
    <Content Include="$(ObjDir)Native\$(OSPlatformConfig)\ObjWriter\llvmCap\LLVM-prefix\src\LLVM-build\bin\$(ConfigurationGroup)\$(ObjWriterLibrary)">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </File>
  </ItemGroup>
  <ItemGroup Condition="$(ObjWriterBuild) == 'true' and '$(OSGroup)' != 'Windows_NT'">
    <Content Include="$(ObjDir)Native\$(OSPlatformConfig)\ObjWriter\llvmCap\LLVM-prefix\src\LLVM-build\lib\$(ObjWriterLibrary)">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </File>
  </ItemGroup>

Thanks again @jkotas.
Followed your suggestions on this branch:
https://github.com/dotnet/corert/compare/master...christianscheuer:objwriterbuild
It appears it builds just fine in ./build.sh objwriter Release mode but all tests fail for some reason that I haven't located yet. Trying with a debug build now and investigating some more.

On a different note. CoreRT seems to think it's building Linux.x64.Release with the above parameters running on Alpine. If this will be made into an official build, would that be wrong? Ie. should this (the build output directories) properly read Linux-musl.x64.Release or doesn't it matter?

It does not matter.

It is the same on coreclr. The target folder path looks like a rid, but it is just OS.Arch.Config.

master...christianscheuer:objwriterbuild

I have submitted PR with this branch https://github.com/dotnet/corert/pull/7536 so that it does not get lost.
@christianscheuer Any interesting findings about the test failures?

It appears the tests all fail silently with a 255 exit code without running any user code.
./Hello /corertalpine/tests/src/Simple/Hello/bin/Debug/x64/native # echo $? 255
For some reason I cannot run lldb at all in this image (seems unrelated).
The dependencies of Hello are (readelf -d Hello):
Dynamic section at offset 0xecd758 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.musl-x86_64.so.1]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN]
 0x000000000000000c (INIT)               0x24ac8
 0x000000000000000d (FINI)               0xcf44fd
 0x0000000000000019 (INIT_ARRAY)         0x10cc918
 0x000000000000001b (INIT_ARRAYSZ)       72 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x10cc960
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x258
 0x0000000000000005 (STRTAB)             0x1730
 0x0000000000000006 (SYMTAB)             0x290
 0x000000000000000a (STRSZ)              2398 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x10cd978
 0x0000000000000002 (PLTRELSZ)           4680 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x23880
 0x0000000000000007 (RELA)               0x2268
 0x0000000000000008 (RELASZ)             136728 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x0000000000000018 (BIND_NOW)
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
 0x000000006ffffffe (VERNEED)            0x2248
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x208e
 0x000000006ffffff9 (RELACOUNT)          5486
 0x0000000000000000 (NULL)               0x0

Interestingly, there doesn't appear to be a libc.musl-x86_64.so.1 in this image (at least not in /usr/lib or /usr/local/lib):
/usr/lib # ls -d libc*
libc.a	     libcc1.so.0.0.0  libcilkrts.so.5.0.0  libcom_err.a   libcrypto.so	       libcurl.a
libc.so      libcilkrts.a     libcilkrts.spec	   libcom_err.so  libcrypto.so.1.0.0   libcurl.so
libcc1.so    libcilkrts.so    libclang.so	   libcrypt.a	  libcrypto.so.41      libcurl.so.4
libcc1.so.0  libcilkrts.so.5  libclang.so.4.0	   libcrypto.a	  libcrypto.so.41.0.1  libcurl.so.4.5.0

Could this be the root cause?

@christianscheuer the libc.musl-x86_64.so.1 is in /lib/libc.musl-x86_64.so.1, it is part of the musl package (standard C library on Alpine) and it should be installed, otherwise basically nothing would work.
LLDB is known to not to work on Alpine, but GDB should work. Can you please try to debug it with that?

@janvorli thanks for clarifying that for me :)
Installed gdb in the image with apk add gdb and ran Hello by:
gdb Hello and then run:
Starting program: /corertalpine/tests/src/Simple/Hello/bin/Debug/x64/native/Hello
warning: Error disabling address space randomization: Operation not permitted
During startup program exited with code 255.

Could this be PIE related?

No, this is due to docker having address space randomization disabled. It is possible to enable that when you run the container or easier - just enter set disable-randomization off GDB command right before you use the run command.

Gotcha. Thanks, I found out I could also add some runtime args to the docker run that gives basically the same result. Sorry for not googling before answering :)
Now I get this when running in gdb:
Starting program: /corertalpine/tests/src/Simple/Hello/bin/Debug/x64/native/Hello
[Inferior 1 (process 20) exited with code 0377]

Setting a breakpoint on exit and _exit reveals this stacktrace:
#0  0x00007ffff7d88518 in exit () from /lib/ld-musl-x86_64.so.1
#1  0x00007ffff7d8f96b in __libc_start_main () from /lib/ld-musl-x86_64.so.1
#2  0x0000000000000000 in ?? ()

I have tried to run one of the tests (tests/src/Simple/Generics/bin/Release/x64/native/Generics) in my Alpine VM and step through the code. The part that makes it fail is that PalInit() is compiled to this:
   0x0000555555c3bc70 <+0>:     push   %rax
   0x0000555555c3bc71 <+1>:     movb   $0x1,0x35c3b0(%rip)        # 0x555555f98028 <_ZL19g_dwPALCapabilities>
   0x0000555555c3bc78 <+8>:     mov    $0x54,%edi
   0x0000555555c3bc7d <+13>:    callq  0x555555579bd0 <sysconf@plt>
   0x0000555555c3bc82 <+18>:    mov    %eax,0x35c3a4(%rip)        # 0x555555f9802c <_ZL14g_cLogicalCpus>
=> 0x0000555555c3bc88 <+24>:    xor    %eax,%eax
   0x0000555555c3bc8a <+26>:    pop    %rcx
   0x0000555555c3bc8b <+27>:    retq

So as you can see, the function always returns "false" (the return value in eax is zeroed). Looking at the source code, that seems to indicate that the compiler figured that QueryCacheSize would always return false. And it is actually true, as none of the _SC_LEVEL* symbols are defined on Alpine.
We should do what coreclr does - consider the ability to figure out the cache size optional.
With patched GetLogicalProcessorCacheSizeFromOS to return 512*1024 unconditionally got the following test results:
JIT - TOTAL: 11 PASSED: 9
CPP - TOTAL: 6 PASSED: 6
WASM - TOTAL: 0 PASSED: 0
R2R - TOTAL: 1 PASSED: 0

@jkotas with your change #7547, ./build.sh objwriter debug now works with 10/11 JIT tests in image mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.6-WithNode-cfdd435-20190521001804:
JIT - TOTAL: 11 PASSED: 10
CPP - TOTAL: 6 PASSED: 6
WASM - TOTAL: 0 PASSED: 0
R2R - TOTAL: 1 PASSED: 0

The failing test is a segmentation fault in the Generics test
  /usr/bin/clang
  Generating native code
Running test /corert/tests/src/Simple/Generics Generics
/corert/tests/src/Simple/Generics/Generics.sh: line 2: 15454 Segmentation fault      $1/$2
fail

However, running the binary manually appears valid:
/corert/tests/src/Simple/Generics/bin/Debug/x64/native # ./Generics
Base.GMethod1<System.Int32>(1,2)
Base.IMethod1<System.Int32>(3,4)
Base.IMethod1<System.Int32>(5,6)
Base.IMethod1<System.Int32>(7,8)
====================
Derived.GMethod1<System.Int32>(1,2)
Derived.IFoo<string>.IMethod1<System.Int32>(3,4)
Derived.IFoo<string>.IMethod1<System.Int32>(5,6)
Base.IMethod1<System.Int32>(7,8)
====================
Derived.GMethod1<System.Int32>(1,2)
Derived.IFoo<string>.IMethod1<System.Int32>(3,4)
Derived.IFoo<string>.IMethod1<System.Int32>(5,6)
SuperDerived.IFoo<int>.IMethod1<System.Int32>(7,8)
====================
GenBase<System.Byte>.GMethod1<System.Int32>(1,2)
GenBase<System.Byte>.IMethod1<System.Int32>(3,4)
GenBase<System.Byte>.IMethod1<System.Int32>(5,6)
GenBase<System.Byte>.IMethod1<System.Int32>(7,8)
====================
GenDerived<System.Byte>.GMethod1<System.Int32>(1,2)
GenDerived<System.Byte>.IFoo<string>.IMethod1<System.Int32>(3,4)
GenDerived<System.Byte>.IFoo<string>.IMethod1<System.Int32>(5,6)
GenBase<System.Byte>.IMethod1<System.Int32>(7,8)
====================
GenDerived<System.String>.GMethod1<System.Int32>(1,2)
GenDerived<System.String>.IFoo<string>.IMethod1<System.Int32>(3,4)
GenDerived<System.String>.IFoo<string>.IMethod1<System.Int32>(5,6)
GenBase<System.String>.IMethod1<System.Int32>(7,8)
====================
GenDerived<System.Byte>.GMethod1<System.Int32>(1,2)
GenDerived<System.Byte>.IFoo<string>.IMethod1<System.Int32>(3,4)
GenDerived<System.Byte>.IFoo<string>.IMethod1<System.Int32>(5,6)
GenSuperDerived<System.Byte>.IFoo<int>.IMethod1<System.Int32>(7,8)
====================
MyStruct1.IFoo<string>.IMethod1<System.Int32>(1,2)
MyStruct1.IFoo<string>.IMethod1<System.Int32>(3,4)
MyStruct1.IFoo<int>.IMethod1<System.Int32>(5,6)
====================
MyStruct2.IFoo<string>.IMethod1<System.Int32>(1,2)
MyStruct2.IFoo<string>.IMethod1<System.Int32>(3,4)
MyStruct2.IMethod1<System.Int32>(5,6)
====================
MyStruct3.IMethod1<System.Int32>(1,2)
MyStruct3.IMethod1<System.Int32>(3,4)
MyStruct3.IFoo<int>.IMethod1<System.Int32>(5,6)
====================
AnotherBaseClass.IFaceGVMethod1
BarImplementor:123
YahooDerived:456
Covariant<String>.ICovariantGVM<Exception>
Foo<ClassType> cctor
Foo<StructType> cctor
Bar cctor
Testing static fields on type Foo<ClassType> ...
Testing static fields on type Foo<StructType> ...
Testing static fields on type Bar ...
Testing instance fields on type Foo<ClassType> ...
Testing instance fields on type Foo<StructType> ...
Testing instance fields on type Bar ...
Foo<Object> cctor
Foo<ClassType2> cctor
Testing dynamic invoke stubs...
/corert/tests/src/Simple/Generics/bin/Debug/x64/native # echo $?
100
/corert/tests/src/Simple/Generics/bin/Debug/x64/native #

Any thoughts?

However, running the binary manually appears valid:

The CppCodegen test run will overwrite the Jit test run. I got burned by that in the past - make sure you're rerunning the output of the RyuJit compilation.

Thanks @MichalStrehovsky, that helps :)
That gets me to the SIGSEGV here (gdb backtrace):
#0  0x00007ffff7dc995d in ?? () from /lib/ld-musl-x86_64.so.1
#1  0x0000000000000000 in ?? ()

Setting a breakpoint at main or PalInit or InitializeRuntime doesn't help so the error appears to somehow happen before we get there (if that's possible). Tried setting a breakpoint on the entry point (0x125000) I got from doing readelf -h Generics but that also doesn't catch anything before the SIGSEGV.
Also tried layout asm and start to step directly to first assembly instruction, but the SIGSEGV still happens before that. Maybe somehow the section tables get messed up?

@christianscheuer are you running in docker container? And if yes, have you run it with --privileged option? That's necessary for debugging

@janvorli yes this was in Docker container and no I wasn't using the --privileged option. Trying it again now - thank you.

@janvorli I tried with --privileged, getting same result when debugging.
Note launching in gdb works fine, and it resolves the breakpoints fine to the source code addresses.
These are my complete steps:
docker run --privileged --cap-add=SYS_PTRACE --security-opt seccomp=unconfined --rm -it mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.6-WithNode-cfdd435-20190521001804 /bin/sh -c "exec /bin/sh"

Then in the container, I just clone corert and run ./build.sh objwriter debug.
This is what passes 10 out of 11 JIT tests, the only one consistently failing is the Generics one.
To debug in gdb, I then did apk add gdb and then gdb Generics while in the bin output dir.
The binary's entrypoint resolves to function _start. Setting a breakpoint there doesn't work, it still gives a segfault no matter how I start it up (layout asm, start or just run).
Note that this segfault appears to be the same as just running the binary without debugging, which could indicate it's not docker privilege related, but an actual error in the binary (also since the other binaries run just fine).
But maybe I'm doing it wrong :)

FWIW something like this Dockerfile should give the same result:
FROM mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.6-WithNode-cfdd435-20190521001804 AS ciimage

WORKDIR /root
RUN git clone --depth 1 https://github.com/dotnet/corert -b master
WORKDIR /root/corert
RUN ./build.sh objwriter debug

ENTRYPOINT ["/bin/sh"]

The difference in my case is that I am using Alpine VM for debugging. Btw, I had to run setfattr -n user.pax.flags -v "emr" tests/src/Simple/Generics/bin/Release/x64/native/Generics to enable gdb to work, but I think that running on other Linux in docker should not need that.

I might have accidentally debugged the Cpp codegened version though.

@janvorli do you want a copy of the binary produced by the Docker image to see if you have better luck debugging it? Might help rule out debugging issues and find out why it segfaults. Is your build on the Alpine VM with current tip also failing the Generics test?
I was trying to get this all set up in Docker since it makes it reproducable and once it works it will allow us to build multi step Docker images immediately (which is our target) - but also since @jkotas mentioned the CI machines only had some images available, so the one I'm testing on I suppose is going to just work once the CI will do the building and publishing.


URL bar too big on Firefox 68.3.0esr

Sanity checks (must complete)

[✓] I have read and followed the installation instructions in the README
[✓] I have not modified the userChrome.css file
[✓] I have tested the latest release or commit on master

Describe the bug
Url bar is too big
To Reproduce
Steps to reproduce the behavior:

Install the theme on Firefox 68.3.0esr

Screenshots

System info

OS: Debian 10 kernel 5.3.0-2-amd64
Firefox version: 68.3.0esr

Additional context
It would be nice to add a branch for ESR version of Firefox.

Am I right in thinking ESR won't really change until Q3 2020?
It's going to be a difficult, messy process to branch from a 68 commit and cherry pick newer bug fixes and features while maintaining 68 compatibility.
In case I don't get around to this, you can try commit caa72cf8aacf3a00cd85073c2bf3bf06c67ef979. This contains the last bug fix I applied for 68, which implies it is compatible with 68. Won't have many of the newer bug fixes though. A lot changed between 68 and 72 so probably at least half the commits are just fixing regressions, sprinkled with some improvements.
Moving forward I'll probably have a branch for each major Firefox version and just update the default branch to point to the latest stable version branch. That way, you'll be able to locate the correct branch based on your ESR version.

I've marked as wontfix. If you try caa72cf you might find it resolves the problem but the DOM has changed dramatically between 68 and 72+ so if you want support for ESR moving forward, you'll have to wait until Q3 2020. Probably not what you're wanting to hear but a few more months and it should be compatible again, and I'm creating incremental branches so this shouldn't be a problem in the future.


How to load a pytorch model with model analyzer

Hi, I am trying to use model analyzer to analyze an ensemble model that contains two python models and 1 ONNX model. The python models using pytorch to perform some preprocessing and postprocessing functions.
However, when I use the following command, I get a "ModuleNotFoundError: no module named 'torch'" error.
model-analyzer profile \ --model-repository=/model_repository \ --profile-models=ensemble_model --triton-launch-mode=docker \ --triton-http-endpoint=localhost:8000 --triton-grpc-endpoint=localhost:8003 --triton-metrics-url=localhost:8002 \ --output-model-repository-path=/model_analyzer_outputs/ \ --override-output-model-repository \ --run-config-search-mode quick \ --triton-output-path triton_log.txt \ --triton-docker-image devel
How do i make sure that the docker container spun up by model analyzer has pytorch installed?

Hi @tgerdesnv thanks for the tip!
To clarify, the command that gives the 'ModuleNotFoundError' error does not include the --triton-docker-image devel flag. I had incorrectly placed that in.
To provide some context, devel is a container that is built to serve my models in tritonserver. It has all the dependencies that I need for my models to work. However, when I run the command with '--triton-docker-image devel', I can the error message docker.errors.ImageNotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=latest&fromImage=devel: Not Found ("pull access denied for devel, repository does not exist or may require 'docker login': denied: requested access to the resource is denied").
Maybe my experience with docker is still not so good, but here are some questions I have:

When i pass the input for the flag --triton-doker-image, do I provide the Image ID, the Image Repository Name or the Image Tag?
When i run docker images inside the tritonserver container, loaded by the command docker run -it  --gpus all \ -v /var/run/docker.sock:/var/run/docker.sock --net=host [nvcr.io/nvidia/tritonserver:23.02-py3-sdk](http://nvcr.io/nvidia/tritonserver:23.02-py3-sdk) (including mounting all the volumes i need), I get a bash: docker: command not found' error. How do I then pass an existing docker image into the --triton-docker-image` flag?

Thanks for your time and help, greatly appreciate it.

Support for custom local docker images was not added unit the 23.03 release. Can you try running on that (or a newer version) and let me know if you are still seeing an issue. Thanks.

Hi @nv-braf I have changed to use the 23.03 release. When I start up the local docker image instance, I get an error in my triton log file, tritonserver: unrecognized option '--metrics-interval-ms=1000', that I'm not sure how it got there. Note that my local docker instance is 21.08.
`=============================
== Triton Inference Server ==
NVIDIA Release 21.08 (build 26170506)
Copyright (c) 2018-2021, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.
Various files include modifications (c) NVIDIA CORPORATION.  All rights reserved.
This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license
tritonserver: unrecognized option '--metrics-interval-ms=1000'
Usage: tritonserver [options]
--help
Print usage
--log-verbose
Set verbose logging level. Zero (0) disables verbose logging
and values >= 1 enable verbose logging.
--log-info
Enable/disable info-level logging.
--log-warning
Enable/disable warning-level logging.
--log-error
Enable/disable error-level logging.
--id
Identifier for this server.
--model-store
Equivalent to --model-repository.
--model-repository
Path to model repository directory. It may be specified
multiple times to add multiple model repositories. Note that if a model
is not unique across all model repositories at any time, the model
will not be available.
--exit-on-error
Exit the inference server if an error occurs during
initialization.
--strict-model-config
If true model configuration files must be provided and all
required configuration settings must be specified. If false the model
configuration may be absent or only partially specified and the
server will attempt to derive the missing required configuration.
--strict-readiness
If true /v2/health/ready endpoint indicates ready if the
server is responsive and all models are available. If false
/v2/health/ready endpoint indicates ready if server is responsive even if
some/all models are unavailable.
--allow-http
Allow the server to listen for HTTP requests.
--http-port
The port for the server to listen on for HTTP requests.
--http-thread-count
Number of threads handling HTTP requests.
--allow-grpc
Allow the server to listen for GRPC requests.
--grpc-port
The port for the server to listen on for GRPC requests.
--grpc-infer-allocation-pool-size
The maximum number of inference request/response objects
that remain allocated for reuse. As long as the number of in-flight
requests doesn't exceed this value there will be no
allocation/deallocation of request/response objects.
--grpc-use-ssl
Use SSL authentication for GRPC requests. Default is false.
--grpc-use-ssl-mutual
Use mututal SSL authentication for GRPC requests. Default is
false.
--grpc-server-cert
File holding PEM-encoded server certificate. Ignored unless
--grpc-use-ssl is true.
--grpc-server-key
File holding PEM-encoded server key. Ignored unless
--grpc-use-ssl is true.
--grpc-root-cert
File holding PEM-encoded root certificate. Ignore unless
--grpc-use-ssl is false.
--grpc-infer-response-compression-level
The compression level to be used while returning the infer
response to the peer. Allowed values are none, low, medium and high.
By default, compression level is selected as none.
--grpc-keepalive-time
The period (in milliseconds) after which a keepalive ping is
sent on the transport. Default is 7200000 (2 hours).
--grpc-keepalive-timeout
The period (in milliseconds) the sender of the keepalive
ping waits for an acknowledgement. If it does not receive an
acknowledgment within this time, it will close the connection. Default is
20000 (20 seconds).
--grpc-keepalive-permit-without-calls
Allows keepalive pings to be sent even if there are no calls
in flight (0 : false; 1 : true). Default is 0 (false).
--grpc-http2-max-pings-without-data
The maximum number of pings that can be sent when there is
no data/header frame to be sent. gRPC Core will not continue sending
pings if we run over the limit. Setting it to 0 allows sending pings
without such a restriction. Default is 2.
--grpc-http2-min-recv-ping-interval-without-data
If there are no data/header frames being sent on the
transport, this channel argument on the server side controls the minimum
time (in milliseconds) that gRPC Core would expect between receiving
successive pings. If the time between successive pings is less than
this time, then the ping will be considered a bad ping from the peer.
Such a ping counts as a ‘ping strike’. Default is 300000 (5
minutes).
--grpc-http2-max-ping-strikes
Maximum number of bad pings that the server will tolerate
before sending an HTTP2 GOAWAY frame and closing the transport.
Setting it to 0 allows the server to accept any number of bad pings.
Default is 2.
--allow-sagemaker
Allow the server to listen for Sagemaker requests. Default
is false.
--sagemaker-port
The port for the server to listen on for Sagemaker requests.
Default is 8080.
--sagemaker-safe-port-range <->
Set the allowed port range for endpoints other than the
SageMaker endpoints.
--sagemaker-thread-count
Number of threads handling Sagemaker requests. Default is 8.
--allow-metrics
Allow the server to provide prometheus metrics.
--allow-gpu-metrics
Allow the server to provide GPU metrics. Ignored unless
--allow-metrics is true.
--metrics-port
The port reporting prometheus metrics.
--trace-file
Set the file where trace output will be saved.
--trace-level
Set the trace level. OFF to disable tracing, MIN for minimal
tracing, MAX for maximal tracing. Default is OFF.
--trace-rate
Set the trace sampling rate. Default is 1000.
--model-control-mode
Specify the mode for model management. Options are "none",
"poll" and "explicit". The default is "none". For "none", the server
will load all models in the model repository(s) at startup and will
not make any changes to the load models after that. For "poll", the
server will poll the model repository(s) to detect changes and will
load/unload models based on those changes. The poll rate is
controlled by 'repository-poll-secs'. For "explicit", model load and unload
is initiated by using the model control APIs, and only models
specified with --load-model will be loaded at startup.
--repository-poll-secs
Interval in seconds between each poll of the model
repository to check for changes. Valid only when --model-control-mode=poll is
specified.
--load-model
Name of the model to be loaded on server startup. It may be
specified multiple times to add multiple models. Note that this
option will only take affect if --model-control-mode=explicit is true.
--pinned-memory-pool-byte-size
The total byte size that can be allocated as pinned system
memory. If GPU support is enabled, the server will allocate pinned
system memory to accelerate data transfer between host and devices
until it exceeds the specified byte size. If 'numa-node' is configured
via --host-policy, the pinned system memory of the pool size will be
allocated on each numa node. This option will not affect the
allocation conducted by the backend frameworks. Default is 256 MB.
--cuda-memory-pool-byte-size <:>
The total byte size that can be allocated as CUDA memory for
the GPU device. If GPU support is enabled, the server will allocate
CUDA memory to minimize data transfer between host and devices
until it exceeds the specified byte size. This option will not affect
the allocation conducted by the backend frameworks. The argument
should be 2 integers separated by colons in the format :. This option can be used multiple times, but only
once per GPU device. Subsequent uses will overwrite previous uses for
the same GPU device. Default is 64 MB.
`

@tgerdesnv thanks for the advice! I tried that and was able to run a full analysis on my ensemble model. I got some very nice results and report, but there is now one small error/glitch that I see, where the model analyzer reported that No GPU metric corresponding to tag 'gpu_used_memory' found in the model's measurement. Possibly comparing measurements across devices.   and No GPU metric corresponding to tag 'gpu_used_memory' found in the model's measurement. Possibly comparing measurements across devices.
From the message, I guess this is because I ran the analysis over a multi-GPU instance, and if I set the --gpus flag to a specific GPU UUID, I will be able to get these metrics. I will try it out and update if I face the same error.
Otherwise, how can I enable GPU metrics reporting even on a multi-GPU instance?

@nv-braf hello, I tried by setting --gpus to the UUID of the GPU I want to use, and model analysis began with the correct GPU that I specified. However, at the end of the analysis, I got the same error messages. Are there any other workarounds I can try?

Are measurements being taken? Are the charts/data being outputted correctly at the end of profile? If so, then it's probably safe to ignore this warning message.

Have you specified CPU_ONLY anywhere in the original configuration? Do the resulting output model configurations have KIND_CPU or KIND_GPU under instance_group?
My concern if you are getting no GPU metrics is that nothing is actually running on the GPU.

Hi @tgerdesnv you make a good point. I realised that although I had put KIND_GPU for all my models, in my pre and post-processing models, I did not explicitly pass the models to GPU using a .to(torch.device("cuda").
However, my main inference model (a CNN) has always been set to run in GPU. Which I am puzzled over as to why no GPU metrics were recorded for that.

Hi @tgerdesnv @nv-braf my apologies, I missed out on the other question.
Yes I am getting measurements on the latency and throughput, those are fine. I was just wondering how to make the GPU metrics appear.
@tgerdesnv I understand what you mean. However, if in an ensemble model, for example, where I have a pipeline of pre processing model -> CNN -> post processing model and only the CNN is on GPU, should I expect GPU metrics to be recorded from the CNN side even though the pre and post processing models are on CPU?

As long as you have not set the cpu_only flag I would expect the composing config to gather GPU metrics and they should be shown in the summary report. Can you confirm that you are not seeing any GPU metrics (like GPU utilization or GPU memory usage) in the summary report table?

Hi @nv-braf yes I confirm that I did not use the cpu_only flag and I did not encounter any GPU metrics.

root@cfbe7ff7cf1e:/app/ma#    model-analyzer profile
--model-repository /app/ma/examples/quick-start
--profile-models add_sub
--output-model-repository-path /app/ma/output11
--export-path profile_results --triton-launch-mode=local
[Model Analyzer] Starting a local Triton Server
[Model Analyzer] Loaded checkpoint from file /app/ma/checkpoints/0.ckpt
[Model Analyzer] GPU devices match checkpoint - skipping server metric acquisition
[Model Analyzer] Starting a local Triton Server
[Model Analyzer] Model add_sub load failed: [StatusCode.INTERNAL] failed to load 'add_sub', failed to poll from model repository
i am doing this add_sub example cpu instance mode, what is wrong in this


Set the default .env location to the absolute path of the working directory

Using the PWD env var we should be able to set the env in the root directory.  I think this is a better default than where the executable file is.  What do you guys think?
Good work on the package by the way.  :smile:

I don't have a strong opinion on this. What do other dotenv packages do? (I should probably know that...)
@chills42 Thoughts?

If I'm reading it correctly bkeepers implementation defaults to a relative path.
https://github.com/bkeepers/dotenv/blob/master/lib/dotenv.rb

Also, the env! macro refers to the value of the environment value at compile time, not at runtime, which may or may not be what you want (but almost surely isn't what the implementation @chills42 linked does).
In any case, it would be nice if it didn't crash the application when PWD isn't defined; perhaps use option_env instead?

As far as what dotenv for Ruby goes, every project I have ever used has had .env file in the root.
From the readme: "Add your application configuration to your .env file in the root of your project"
That is a good call with option_env.  I will work on making it not break when missing the PWD.
If instead of the making the pwd the default would it be better to just add an arg that would allow you to load from root: dotenv("root") or something along those lines?

Oh, okay. It seems to me that making the root folder the default is the right thing to do.
I'm still unsure about the usage of env!/option_env! (that is, getting the compile-time value of the environment variable, as opposed to using std::env::var to get the run-time value). Furthermore, it seems like Rust provides you with a function that outputs the current working directory (std::env::current_dir), which is probably the right way to do this.

@slapresta,  I pushed up a change that uses current_dir().

I like this, it's a breaking change, but it is aligning us with other implementations, so it would still be a good move.

Lovely, @mfpiccolo! Thanks for the pull request :)


chore: Add tests for ariakit utils/focus

More tests for utils.

Thanks for the suggestion. I think you are right. I need to dig into the test-utils more. I was worried how much of this was mocking other functions. I think I went down this path far enough that I didn't want to turn back but I yesterday while I was finishing some of these up I really started to consider going back and trying to undo all the weird mocking. I am going to make this a draft for now and try to do another pass.

@diegohaz I think this should be in a much better spot.


[Feature]: Add CSP

Expected behavior
I'd like to set up a CSP but couldn't do it as I wanted.

tauri.conf.json

    "security": {
      "dangerousDisableAssetCspModification": ["style-src"],
      "csp": "default-src 'self';script-src 'self' 'strict-dynamic' 'unsafe-inline';worker-src 'self' 'strict-dynamic' 'blob:https://tauri.localhost/*';style-src 'self' 'unsafe-inline'; img-src 'self' https: asset: data:"
    }

Set CSP and restrict content.
other
No response

Gave up because it was not possible to set up a CSP that would maintain the existing permit status.


Calling an originally POST API using MeshContext results in an error: TypeError: cannot read property 'args' of undefined

Error
I was defining my own resolver and using the MeshContext to call multiple Queries and Mutations for an OpenAPI endpoint.
I ran into an error when I tried to call my resolver using a POST request through Postman (I can't send the request in the GraphiQL playground because the POST request involves sending a document); the console showed an uncaught exception: TypeError: cannot read property 'args' of undefined.
I reduced the resolver that causes the error to the following:
export const resolvers = {
    Mutation: {
        async uploadDocument(_parent: Mutation, args: MutationArgs, context: MeshContext){
            let obj = ...; // constructing the obj to fit in args requirement for the POST request
            const response = await context.sourceName.api.thePostRequestUsingPOST(obj); // The error occurs in this line
        }
    }
}

Possible source
When debugging, I found that the error was thrown by a generated script in the runtime, where it was trying to get the args for a field from the generated schema types. The field is undefined.

Here, the typeMap is retrieving schema types for queries, mutations, and subscriptions respectively, and type is retrieving typeMap[kind]. The value of kind is query. Since thePostRequestUsingPOST is a mutation and not a query, it cannot be located, resulting in an undefined variable.
Tracing down the stack, it turns out that the kind variable is passed in by this function:
export function buildOperationNodeForField({ schema, kind, field, models, ignore, depthLimit, circularReferenceDepth, argNames, selectedFields = true, }) {
    resetOperationVariables();
    resetFieldMap();
    const operationNode = buildOperationAndCollectVariables({
        schema,
        fieldName: field,
        kind,
        models: models || [],
        ignore: ignore || [],
        depthLimit: depthLimit || Infinity,
        circularReferenceDepth: circularReferenceDepth || 1,
        argNames,
        selectedFields,
    });
    // attach variables
    operationNode.variableDefinitions = [...operationVariables];
    resetOperationVariables();
    resetFieldMap();
    return operationNode;
}

The value of kind for this function is from createProxyInfo:
function createProxyInfo({ schema, parentType, field, depthLimit = 2, root, args, selectedFields, selectionSet, info, }) {
    const actualReturnType = 'ofType' in info.returnType ? info.returnType.ofType : info.returnType;
    const returnType = 'ofType' in field.type ? field.type.ofType : field.type;
    if (!selectedFields &&
        !selectionSet &&
        'name' in actualReturnType &&
        'name' in returnType &&
        actualReturnType.name === returnType.name) {
        return {
            ...info,
            returnType,
        };
    }
    selectionSet = selectionSet && (typeof selectionSet === 'string' ? parse(selectionSet) : parse(print(selectionSet)));
    const operation = (selectionSet === null || selectionSet === void 0 ? void 0 : selectionSet.definitions[0]) ||
        buildOperationNodeForField({
            schema,
            kind: 'query',
            field: field.name,
            depthLimit,
            argNames: Object.keys(args),
            selectedFields,
        });
    return {
        fieldName: field.name,
        fieldNodes: operation.selectionSet.selections.filter(s => s.kind === Kind.FIELD),
        returnType: field.type,
        parentType,
        schema,
        fragments: {},
        rootValue: root,
        operation,
        variableValues: args,
        path: {
            key: field.name,
        },
    };
}

Here, when defining operation, the value of kind is hardcoded to query
Is there a way to overwrite this portion in the code, or a workaround to pickup the POST APIs too?
Minimal steps to replicate error
Here are the minimal number of steps to reproduce the error:

Find an OpenAPI endpoint with a POST API
Let graphql-mesh generate a mesh file for that API based on its OpenAPI definition
Call the POST API by using MeshContext: context.sourceName.api.thePostRequestUsingPOST()
Run the server and send a request.

Fixed in the latest version!


Please auto-open "My Positions" in single market view

Viewing open orders here requires an extra click, when it really seems like they should just be displayed.

https://app.clubhouse.io/augur/story/14665/github-please-auto-open-my-positions-in-single-market-view

a change for this has been merged and will be in the next release.


SQL Express max cores

SQL Cores number seems strange.
The system only has 4 cores and the SQL express limit is 4 logical cores (on the first socket). Don't know where the 16 comes from, but that could be optimized.
To Reproduce
Steps to reproduce the behavior:
1.Run vHC on default VBR11 installation with SQL Express, 4 cores on the VM
2. See HTML Report
Expected behavior
Show 4 - basically out of the 4 logical cores for SQL Express (as we know the edition) or at least because there are no 16 cores available on the VM.
Screenshots

vHC: v<IP_ADDRESS>2

Issue is fixed. Bug was in logic trying to account for multi-threading. This will be included in the next release.


distributed 1.21.8 requires msgpack, which is not installed.

I keep getting this error trying to simply install tf.  Why is none of this simple???

also getting an error trying to install cert. this is supposed to be easy!

+1

For tensorflow and python installation issues, I will kindly direct you to StackOverflow.

your tutorials should assume a scratch install. You want this to be accessible to more people, right? So providing detailed instructions that don't skip over things would help in this vain. thanks

Because of the way anaconda is installed, the error "distribution 1.21.8 requires msgpack, which is not installed" may occur; the answer is to install msgpack as administrator. https://kodlogs.net/196/distributed-1-21-8-requires-msgpack-which-is-not-installed-fixed


datalake-ete-test-added

Describe your changes :

I worked on the adding e2e test for datalake

Type of change :

[x] Bug fix
[x] Improvement
[x] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Frontend Preview (Screenshots) :
For frontend related change, please link screenshots of your changes preview! Optional for backend related changes.

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] All new and existing tests passed.

Reviewers

@codingwithabhi can you add datalake in the workflow file
ref: https://github.com/open-metadata/OpenMetadata/blob/main/ingestion/tests/cli_e2e/README.md


Add missing type for animationConfig

This is a bit pedantic, but it satisfies an error in a strict type checking compile that I unfortunately can't easily work around.

Hey thanks for helping out. I'going to merge this shortly.
Would you be interested in maintaining this component? I don't really use it anymore.


Update cats-effect to 3.2.9 in series/0.3

Updates org.typelevel:cats-effect from 2.5.4 to 3.2.9.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Applied Migrations

github:typelevel/cats-effect/v3_0_0?sha=v3.0.0

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "cats-effect" } ]

labels: library-update, early-semver-major, semver-spec-major, scalafix-migrations

Nope. This needs to be pinned.


Made navbar sticky, fixed the misalignment of logo in the footer and …

…fixed logo visibility below follow us

🛠 Fixes Issue 158
Closes #158

👨💻 Changes proposed

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

This branch is 1 commit ahead, 13 commits behind Rayman-Sodhi:main.

What am I supposed to do now @gurjeetsinghvirdee

What am I supposed to do now @gurjeetsinghvirdee

Fetch upstream

What am I supposed to do now @gurjeetsinghvirdee

Fetch upstream

Done. @gurjeetsinghvirdee


recentColors prop array doesn't work

Describe the bug
Passing a recentColors prop as an array of colors doesn't set the initial recent color palette.
I'm guessing in Verte.vue#L197:
\\ this:
      return initStore();
\\ needs to be:
      return initStore(Vue, {recentColors: this.recentColors});

edit: Added Vue as first parameter to initStore().

I guessed wrong!  I didn't see that initStore() is also called in beforeCreate().
this.recentColors doesn't exist in beforeCreate().  In that case, as well as the above I've fixed it by doing this in store.js:
  function initStore (_Vue, opts) {
    if (store) {
	  if (opts && typeof opts.recentColors=='object') store.recentColors = opts.recentColors;
      return store;
    }

I see that the recentColors and onRecentColorChange are intended to be defined with a Vue.use(...).  However, I can't do that because my color picker component is dynamically imported.

The PR #20 implemented the recent colors behavior, as you have said you cannot initialize a different color list during rendering or later on in your app.
Ideally, I think we could introduce a recent color prop which will serve as the source of the colors which will stop the event in the config from firing, it will act as the component is now isolated with its own recent colors, and will emit its own event.

In my opinion PR #20 is a regression.
Before PR #20 , commit https://github.com/baianat/verte/commit/3cd669007ef67d54fa52a43a077a892453cf17bd first introduced the recentColors prop in response to issue #15.  That implementation allowed the component to take the recentColors prop as an array any time an instance of the component is rendered.  The developer can choose whether to make that a shared or unique recentColors list between instances.
Then PR #20 broke that behaviour, leaving the only way to initialise the recent colors list as Vue.use(), which is impossible in some situations where the component is dynamically imported.
The previous behaviour is inline with the published API which says that 'recentColors' can be an array and makes no mention of Vue.use(), and the new behavior is incompatible with the published API.
The two code changes I've shown above allow both uses, either Vue.use(), or passing a recentColors props as an array (as per the published API).  In both cases the recent colors list is still shared among components.  If you wanted to isolate the recent colors within each instance then that's what the https://github.com/baianat/verte/commit/3cd669007ef67d54fa52a43a077a892453cf17bd did by not using a shared store.  I think the separated list implementation is better because then the developer can choose to use a common recentColors list, or use unique lists for separate components.

My bad, The API was falling behind the actual behavior, I have introduced a new PR #27. Feedback is appreciated!


Suggestion: Add default notes

I think it might be a good improvement for the end user to have default notes instead of showing "no info available" when a note isn't provided (presumably when it's obvious what to do).
Perhaps something like "Visit the linked page and delete your account" if the difficulty is easy and "Visit the linked page for further information" otherwise. If an email is specified then there could be a default note indicating to either use the email link provided or manually write to ${address}. This would also allow to cut down on translation for entries where a note is unnecessary.

I like the suggestion! Shouldn't be difficult to implement, want to give it a try? :)

I have a fair amount on at the moment, but will happily look at implementing this when I find some spare time (if nobody beats me to it) 😃

The hardest part of this might be translation. I'd do it myself, but I'm only comfortable in a few languages using Google Translate for long phrases like this.

We can always leave these untranslated and create an issue to ask for the community to complete the translation later :)

Nice, glad someone was able to look at this :)
As a follow up suggestion: Reviewing existing easy entry notes to trim the fat from the translation workload for cases where the default message is good enough (probably the majority). I'll leave it up to you maintainers whether to open an issue task for that.

As a follow up suggestion: Reviewing existing easy entry notes to trim the fat from the translation workload for cases where the default message is good enough (probably the majority). I'll leave it up to you maintainers whether to open an issue task for that.

I gave this a thought and I'm alright with leaving as is, specially because we don't get a lot of translation movement around here.


Rspec  to execute different spec files in desired order

Hi ,
I have recently started using ruby and rspec. I am facing some issue in executing different spec files in desired order. rather executing tests in specified order,  tests execution is in alphabetical order . But I would like to execute tests in the order provided user.
Initially i tried using rake,but going through several post came to know the best way to this through rpsec and there are several options to do that and rspec won't  consider order that has given in CLI .
Could someone help me to sort out  this in best way and pls elaborate on implementing it?

am facing some issue in executing different spec files in desired order. rather executing tests in specified order, tests execution is in alphabetical order .

RSpec does not execute tests in alphabetical order.  It loads spec files in alphabetical order and then runs tests in defined order or random order depending on your configuration.
In general, we recommend you use random ordering as that helps surface ordering dependencies, which can help you fix them when they first surface.
If you want move control over the ordering, you can use config.register_ordering:
http://rspec.info/documentation/3.2/rspec-core/RSpec/Core/Configuration.html#register_ordering-instance_method
If you want more info about how to use that option, see this recent discussion on the mailing list:
https://groups.google.com/forum/#!topic/rspec/mCCXj8RROYc

Closing as there's nothing actionable for us to do here.  But I'm happy to continue the conversation if you have followup questions, @chandanaGollapudi.

thanks your quick response( to request no 1900).I have gone through link that you suggested.i have few clarifications on below provided code.
Could you please provide your answers on below points.
1.In which file i need to add below provided code( is it spec_helper.rb or new spec file)?
1.1 if it is spec_helper,now different scrum team using same spec_helper file. will it affect others execution,if so how to handle it?
1.2 can archive same by creating new spec file and add below code to that.will it execute all other spec files in desired order by running new spec?
2.what is the significance of numerics in below code? as per my understanding groups execution order will be based on tags and the order will be feature,request and model.
lets say i have 3 test under each spec file . can the below code support in executing test in written order ? if not, could tell me how to that?
Could you point me to the link that gives detailed info about rspec for beginners?
RSpec.configure do |config|
config.register_ordering(:global) do |items|
items.sort_by do |group|
case group.metadata[:type]
when :feature then 50
when :request then 40
when :model then 10
else 20
end
end
end
end
thanks in advance,
Chandana

1.In which file i need to add below provided code( is it spec_helper.rb or new spec file)?

If you want it to always apply to every spec run, add it to a file that it always loaded.  spec_helper.rb is a pretty conventional place to put code you want always loaded for every spec run (or in a file required from spec_helper.rb).

1.1 if it is spec_helper,now different scrum team using same spec_helper file. will it affect others execution,if so how to handle it?

It seems like a bad idea to force a different ordering than other devs or teams use on the project (it could hide ordering dependencies that one team sees but not the other).
If you want to just apply the ordering for when you run rspec, you can add the ordering code to some file (e.g. spec/support/change_global_ordering.rb) and then add a git-ignored .rspec-local file to the project with --require support/change_global_ordering as the contents.  .rspec and .rspec-local can contain CLI flags you always want to apply (the former being intended to be project-wide for all devs, while the latter being for personal preferences).  --require will load the specified file so you can use it to load your ordering logic.

1.2 can archive same by creating new spec file and add below code to that.will it execute all other spec files in desired order by running new spec?

I don't understand this question.

2.what is the significance of numerics in below code? as per my understanding groups execution order will be based on tags and the order will be feature,request and model.

The absolute numeric values don't actually matter -- it's just how they sort relative to each other.  sort_by sorts low to high, so that code orders model specs first, feature specs last, request specs 2nd-to-last, and everything else in between model and request specs.

lets say i have 3 test under each spec file . can the below code support in executing test in written order ? if not, could tell me how to that?

You can write the ordering logic to order the specs however you like.  We chose a block-based API because it supports any arbitrary logic a user could want.  Just put ruby code in there that sorts the list however you want it to sort it.  I don't have the time to write the code for you (sorry).
Honestly, changing the ordering is a more "advanced" feature of RSpec and not something I generally recommend unless you have needs that are outside the norm and you know what you're doing.  I generally recommend running specs in random order  (--order random) which helps surface ordering dependencies so you can quickly solve them when they arise.  Using the ordering API to force an ordering to work around some issue is going to cause other problems for you in the long term.

Could you point me to the link that gives detailed info about rspec for beginners?

https://skillsmatter.com/skillscasts/5438-welcome-back-to-rspec
https://pragprog.com/book/nrtest2/rails-4-test-prescriptions
http://www.pluralsight.com/courses/rspec-the-right-way
https://www.codeschool.com/courses/testing-with-rspec

Your answers are very clear and helpful . It makes my work easy.thank you so much for your help.


rustls-ffi: 0.10.0 -> 0.13.0

Description of changes
Switched to the recently introduced cargo-c build in order to get pkg-config/.so config.
rustls-ffi 0.10.0 has been kept as is in order to keep the ability of building Apache with the support for it. Hopefully support for recent version of rustls-ffi will land soon, see https://bz.apache.org/bugzilla/show_bug.cgi?id=67860
Changelog:
https://github.com/rustls/rustls-ffi/blob/v0.13.0/CHANGELOG.md

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

curl with the Rustls support currently does not build:
curl> checking for rustls options with pkg-config... found
curl> configure: pkg-config: SSL_LIBS: "-lrustls"
curl> configure: pkg-config: SSL_LDFLAGS: "-L/nix/store/d6gw39pnrbyap9dhpkbm6z9n82jkll4h-rustls-ffi-0.13.0/lib"
curl> configure: pkg-config: SSL_CPPFLAGS: "-I/nix/store/d6gw39pnrbyap9dhpkbm6z9n82jkll4h-rustls-ffi-0.13.0/include"
curl> configure: detected rustls
curl> configure: Added /nix/store/d6gw39pnrbyap9dhpkbm6z9n82jkll4h-rustls-ffi-0.13.0/lib to CURL_LIBRARY_PATH
curl> configure: error: TLS not detected, you will not be able to use HTTPS, FTPS, NTLM and more.
curl> Use --with-openssl, --with-gnutls, --with-wolfssl, --with-mbedtls, --with-schannel, --with-secure-transport, --with-amissl, --with-bearssl or --with-rustls to address this.

From my understanding this is supposed to have been fixed (https://github.com/curl/curl/issues/13200) so it will require some troubleshoting.

cc @cpu to follow up with https://github.com/NixOS/nixpkgs/pull/299580#issuecomment-2035340195

cc @cpu to follow up with #299580 (comment)

Thanks! I will take a deeper look ASAP.

From my understanding this is supposed to have been fixed (https://github.com/curl/curl/issues/13200) so it will require some troubleshooting.

Hmm that is interesting. I will see if I can reproduce.

I was able to checkout the curl-8_7_1 upstream, apply the same patches as proposed here, and build successfully. I manually pointed the PKG_CONFIG_PATH to the nix store path from building rustls-ffi from this branch when running configure --with-rustls. That gives me at least a little bit of confidence that the upstream detection code is working (I think the Gentoo folks confirmed it too). I'm still not sure what's breaking in the passthrough test curl build. My understanding is the pkg-config hook in curl would be doing that PKG_CONFIG_PATH work for us.
I don't think it's load-bearing, but reading "Writing packages providing pkg-config modules " in the manual I noticed there's a meta.pkgConfigModules = [ "rustls" ]; element for describing exported pkg config libs that should probably be included in the rustls-ffi derivation now.

I don't think it's load-bearing, but reading "Writing packages providing pkg-config modules " in the manual I noticed there's a meta.pkgConfigModules = [ "rustls" ]; element for describing exported pkg config libs that should probably be included in the rustls-ffi derivation now.

Thanks, I forgot about that. Adjusted in the latest change.
Everything has been fixed, curl builds with rustls and it looks OK :+1:

Everything has been fixed, curl builds with rustls and it looks OK 👍

Nice work!
I'm reading the diff and wondering what the key fix was, conditionally adding autoreconfHook to the nativeInputs when the patches are in play?

Yes, the autoreconfHook runs autoreconf which will regenerate the configure file provided by the curl release tarball.

Hopefully support for recent version of rustls-ffi will land soon, see https://bz.apache.org/bugzilla/show_bug.cgi?id=67860

FWIW this has landed in-tree but is pending release: https://svn.apache.org/viewvc?view=revision&revision=1917270
I've used this branch to smoke test the change in Nix-land and it worked well :tada: The main wrinkle is that it's tricky to build HTTPD from a src clone and not a released tarball. I had to hack up the apache derivation a bit to clone apr sources (using srcOnly apr was throwing some weird errors) into srclib and then run the buildconf script for generating the autotools gunk. Something like this diff (Note; sorry about the reformatting noise, made this quickly & with the wrong vim config loaded).

Thanks for the upstream fix. I applied the patch on top of sources we are using for Apache and it looks good :+1:

I checked out this branch, built this derivation and diffed the content to the Arch Linux package for 0.13.0 (since the curl-rustls package over there sucessfully uses dynamic linking with librustls.so). The overall package structure is very similar (Arch has extra license files but lacks the static .a library and also has it's debug symbols detached into a different package):
--- is Arch Linux, +++ is NixOS
@@ -1,14 +1,9 @@
 drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./
 drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./include/
 -rw-rw-rw-   0        0        0    87309 1970-01-01 00:00:00.000000 ./include/rustls.h
 drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./lib/
+-rw-rw-rw-   0        0        0 14631106 1970-01-01 00:00:00.000000 ./lib/librustls.a
 lrwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./lib/librustls.so -> librustls.so.0.13.0
--rwxrwxrwx   0        0        0  1878432 1970-01-01 00:00:00.000000 ./lib/librustls.so.0.13.0
+-rwxrwxrwx   0        0        0  2389432 1970-01-01 00:00:00.000000 ./lib/librustls.so.0.13.0
 drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./lib/pkgconfig/
--rw-rw-rw-   0        0        0      275 1970-01-01 00:00:00.000000 ./lib/pkgconfig/rustls.pc
-drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./share/
-drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./share/licenses/
-drwxrwxrwx   0        0        0        0 1970-01-01 00:00:00.000000 ./share/licenses/librustls/
--rw-rw-rw-   0        0        0    10847 1970-01-01 00:00:00.000000 ./share/licenses/librustls/LICENSE-APACHE
--rw-rw-rw-   0        0        0      781 1970-01-01 00:00:00.000000 ./share/licenses/librustls/LICENSE-ISC
--rw-rw-rw-   0        0        0     1089 1970-01-01 00:00:00.000000 ./share/licenses/librustls/LICENSE-MIT
+-rw-rw-rw-   0        0        0      337 1970-01-01 00:00:00.000000 ./lib/pkgconfig/rustls.pc

The rustls.h header files are identical, the pkg-config file also seems fine:
@@ -1,10 +1,10 @@
-prefix=/usr
+prefix=/nix/store/7nlybprdl56qj9i3amalmrrlx59fhc0r-rustls-ffi-0.13.0
 exec_prefix=${prefix}
-libdir=${prefix}/lib
+libdir=${exec_prefix}/lib
 includedir=${prefix}/include

 Name: rustls
 Description: Rustls bindings for non-Rust languages
 Version: 0.13.0
 Libs: -L${libdir} -lrustls
 Cflags: -I${includedir}

For the binary it's normal to have large differences, in this case most of them are offset changes due to an additional symbol:

This is most likely because the Arch Linux package was built with a different rustc Version:
├── readelf --wide --decompress --string-dump=.comment {}
│ @@ -1,5 +1,5 @@
│
│  String dump of section '.comment':
│ -  [     0]  GCC: (GNU) 14.1.1 20240507
│ -  [    1b]  rustc version 1.78.0 (9b00956e5 2024-04-29) (Arch Linux rust 1:1.78.0-1)
│ +  [     0]  GCC: (GNU) 13.2.0
│ +  [    12]  rustc version 1.77.1 (7cf61ebde 2024-03-27) (built from a source tarball)

I also found a difference in the Library runpath, but I assume this is related to how NixOS works:

Overall I think dynamic linking should work fine, I couldn't figure out how to build curl-rustls (like which nix-shell command to run) but I'd be happy to give that a try too (I noticed there's curlWithGnuTls but no curlWithRustls).

I've resolved the merge conflict like so:
  patches = lib.optionals (lib.versionOlder finalAttrs.version "8.7.2") [
    # https://github.com/curl/curl/pull/13219
    # https://github.com/newsboat/newsboat/issues/2728
    ./8.7.1-compression-fix.patch
  ] ++ lib.optionals (rustlsSupport && lib.versionOlder finalAttrs.version "8.7.2") [
    # https://github.com/curl/curl/issues/13200 and https://github.com/curl/curl/issues/13248
    ./rustls-build-fix.patch
  ];

The rebased commit can also be found at e727f6099ebd3c01f36aa5e77f861364c6ad199c.

Thanks for taking the time to compare!

I also found a difference in the Library runpath, but I assume this is related to how NixOS works:

Yup this one is not unexpected in the nixpkgs/NixOS context.

Overall I think dynamic linking should work fine, I couldn't figure out how to build curl-rustls (like which nix-shell command to run) but I'd be happy to give that a try too (I noticed there's curlWithGnuTls but no curlWithRustls).

At the root of your nixpkgs clone you can run nix-build -A rustls-ffi.tests.curl to build it. I did not add curlWithRustls just yet as the backend is still marked experimental upstream and it might require some work between upgrades (as seen here :) ).

Thanks, I built the binary but it doesn't seem to pick up ca-certificates:
$ /nix/store/4xwgm6qsbpa8bs0jnagapb6q8h1awy26-curl-8.7.1-bin/bin/curl -v https://github.com/
* Host github.com:443 was resolved.
* IPv6: (none)
* IPv4: <IP_ADDRESS>
*   Trying <IP_ADDRESS>:443...
* Connected to github.com (<IP_ADDRESS>) port 443
* ALPN: curl offers h2,http/1.1
* rustls_connection wants us to write_tls.
* Curl_socket_check: reading would block
* Curl_socket_check: reading would block
* rustls_connection wants us to read_tls.
* rustls_connection_process_new_packets: invalid peer certificate: BadSignature
* Closing connection
curl: (60) rustls_connection_process_new_packets: invalid peer certificate: BadSignature
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

This could either indicate https://github.com/curl/curl/issues/13248 isn't fully fixed yet, or I'm using the test binary in a way that it's not supposed to be used.
Arch Linux currently ships curl-rustls 8.7.1 by reverting https://github.com/curl/curl/commit/647e86a3efe1eea7a2a456c009cfe1eb55fe48eb.
This command is working fine, so it seems rustls-ffi itself is working correctly:
$ /nix/store/4xwgm6qsbpa8bs0jnagapb6q8h1awy26-curl-8.7.1-bin/bin/curl --cacert /etc/ssl/certs/ca-certificates.crt -sSfv https://github.com/ > /dev/null
* Host github.com:443 was resolved.
* IPv6: (none)
* IPv4: <IP_ADDRESS>
*   Trying <IP_ADDRESS>:443...
* Connected to github.com (<IP_ADDRESS>) port 443
* ALPN: curl offers h2,http/1.1
* rustls_connection wants us to write_tls.
* Curl_socket_check: reading would block
* rustls_connection wants us to read_tls.
* rustls_connection wants us to write_tls.
* rustls_connection wants us to read_tls.
* Done handshaking
* ALPN: server accepted h2
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://github.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: github.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: github.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 200
< server: GitHub.com
< date: Tue, 14 May 2024 09:57:22 GMT
< content-type: text/html; charset=utf-8
< vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, Accept-Language, Accept-Encoding, Accept, X-Requested-With
< content-language: en-US
< etag: W/"6e886ad4ab0d5247c4e88b7b241e312f"
< cache-control: max-age=0, private, must-revalidate
< strict-transport-security: max-age=31536000; includeSubdomains; preload
< x-frame-options: deny
< x-content-type-options: nosniff
< x-xss-protection: 0
< referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
[...]

Rebased now that we have curl 8.8.0 in master.
The cert issue is not new AFAIK, it probably requires some adjustment to handle NIX_SSL_CERT_FILE. It works as expected if a bundle of CA is explicitly provided.

I'm also in favor of merging this


Text polishing for enrollment/registration

Pull Request Test Coverage Report for Build 633

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.977%

Totals

Change from base Build 631:
0.0%

Covered Lines:
3662

Relevant Lines:
3662

💛  - Coveralls


Document coordinate frame axes conventions

Local space, view space, NDC space, wgpu space:

positive z is viewing direction
positive x is right
positive y is up

What is up in world space, depends on the application. This is why the camera and some routines in pylinalg have a configurable up vector.

I think this would be a good candidate for a gallery example. It's a bit verbose to describe, but becomes clear immediately with a picture (or two). We have the pygfx.AxisHelper (which I just documented) that would come in quite handy for this purpose.


Update to drive Portal UX

Plan update to stacks that allows us to specify the language, version, and "mode" (embedded or isolated) for .NET
Talk with Elliot/Allison about whether we can update the UX to look more like Web Apps:

Functions:

Web Apps:

This would remove the need for a third dropdown in the Function create flow and move everything to one selection. For example, we'd have ".NET Core 3.1 embedded", ".NET Core 3.1 isolated", and ".NET 5 isolated"

Closing as done.


fix(scroll-area): horizontal scroll bar not visible

PRs #1515 and #1296 interfere with each other and cause the horizontal scroll bar to not be visible. This removes the conditional flex-1, however you could also remove flex-col to achieve the same result.
before:
https://github.com/shadcn-ui/ui/assets/9381099/6514de2e-e353-4d0b-bd24-aff79e0d5161
after:
https://github.com/shadcn-ui/ui/assets/9381099/3205baad-569b-4096-8dcd-9beb794de536

@gregermendle This looks good. Could you run a quick pnpm format:write to fix the failing code check please? Thank you.


⚙ Add smart tracking config

:star2: What does this PR do?

📦 Add base config fixture
🔧 Add config command
🔍 Add config lookup
👩🎨 Add config init command
📐 Refactor utilities
🩹 Fix description help not showing up

:bug: Recommendations for testing

See recording for quick demo.

Another recording shows how configuration is inherited by all child directories but not the ancestors of a tracked dir.

Adds toggl config command to manage auto tracking configuration [^1].
The focus of this PR is to implement a neat way to manage your auto-tracking configuration toml, and not the configuration itself.
We also add a few fixtures to test the config logic at some point.
The default configuration[^2] is bundled into the binary.

New commands introduced
# Create a new configuration using the default bundled config
$ toggl config init

# Pretty print currently active configuration
$ toggl config

# Edit the configuration in the system's default editor
$ toggl config --edit # or toggl config -e

# Delete the active configuration for current directory
$ toggl config --delete # or toggl config -d

# Log the path of the active configuration file
$ toggl config --path # or toggl config -p

:memo: Links to relevant issues/docs
See #45 which defines the configuration storage and retrieval mechanism.
Minor changes have been incorporated that differ from the original spec.
Instead of using md5(path) we use base64(path)

because md5 usage is highly discouraged by the ecosystem.
we don't need the file path to be hashed just encoded.
another benefit is, that the encoded is reversible, so if we plan to add something like toggl config list to log all tracked paths; it would be trivial.
Config files are stored in directories specified by the directories::ProjectDirs::from("studio.watercooler", "labs", "toggl-cli")[^3] method.

I've updated the spec to reflect these changes.
Current locations are

linux
windows
macOS

$XDG_CONFIG_HOME/toggl-cli or $HOME/.config/toggl-cli
{FOLDERID_RoamingAppData}/labs/toggl-cli/config
$HOME/Library/Application Support/studio.watercooler.labs.toggl-cli

:speech_balloon: Summarise how you feel about this PR with a gif/image

[^1]: Auto tracking RFC at #45
[^2]: default.toml
[^3]: For platform agnostic config directory calculation https://docs.rs/directories/5.0.0/directories/struct.ProjectDirs.html#method.config_dir

Just chiming in that it's functioning beautifully for me 💅


fix(BFormGroup): change labelSrOnly to labelVisuallyHidden as per BS5

Describe the PR
Rename prop labeSrOnly to labelVisuallyHiddes as per the BS5 change
Also fix the types for labelAlign* - the can only be strings not number or boolean
Small replication
See tests
PR checklist

What kind of change does this PR introduce? (check at least one)

[x] Bugfix :bug: - fix(...)
[ ] Feature - feat(...)
[ ] ARIA accessibility - fix(...)
[ ] Documentation update - docs(...)
[ ] Other (please describe)

The PR fulfills these requirements:

[x] Pull request title and all commits follow the Conventional Commits convention or has an override in this pull request body This is very important, as the CHANGELOG is generated from these messages, and determines the next version type. Pull requests that do not follow conventional commits or do not have an override will be denied

this

this

Sorry, git confusion. I've created a new PR with the changes that I intended.


FIX: typo in README.md

From 'File Manage' to 'File Manager'

I made a mistake... I'll reopen another one


[TASK] Make use of S3 fixtures in the dApp

Overview
Instead of using ipfs to fetch the fixtures we are opting to make use of S3 buckets to fetch fixtures to make it much quicker.
Task Checklist

[ ] Replace IPFS fetching to make use of S3 buckets in the dApp

Closed in #535


No visual indicator for priority

It seems like setting a priority in a task doesn't have any visual indicator of the priority in the task list in the Home tab.
More broadly - is there a roadmap for what are the next features to be implemented, or just a general list of features to be implemented before a 1.0 release?

We do, this is the app roadmap: https://my.vikunja.cloud/share/BTZXIiomjxyQEdtsLmPkAKeRGkUCWUttgYbEyNIc/auth?view=kanban

Yep it works! Thanks!


Add ITP method?

I think the ITP method for root-finding would be a nice addition since it's unlikely to make it into scipy.
Reference
https://en.wikipedia.org/wiki/ITP_Method

Is there a scipy bug report or pull request where this idea had been rejected?

Is there a scipy bug report or pull request where this idea had been rejected?

No there isn't. It is my guess based on scipy policies about new code. This method is not widely used and seems new so it would take a long time before it gets accepted into scipy. I (and many others) have proposed new algorithms in the past with no success, where maintainers expressed that they only prefer adding methods with many citations and those that have been around for a while.

I understand, same situation here. (That's why I created scipyx.) You should at least try and suggest it for scipy though. You can also just PR here, of course.


attestationResult suddenly return error

my app was just working fine, but from yesterday , attestationResult return error as
"typeerror: clientdata challenge was not properly encoded base64url"
first i fill my session with challenge
ctx.session.challenge = Buffer.from(registrationOptions.challenge)
and then in registering fingerprint i get it from session
const challenge = new Uint8Array(ctx.session.challenge.data).buffer
whats wrong with it?

We did not do any changes, if that's what you mean. If you provide a full and running example including payloads, maybe someone can spot the issue you're encountering.

yes
that was issue on my backend side


Include a slightly modified version of CSRF-Protector-PHP

This version of CSRF-Protector-PHP  is just modified to allow the config file (now called csrfp-config.php) to reside in the same folder as bb-config.php.
Normally I wouldn't want to include a lib like this since it can't auto update, but the original lib hasn't updated since oct 2020.
This should close https://github.com/boxbilling/boxbilling/issues/881 and conveniently this lib is supposed to automatically work with any forum on we add on the website, so we shouldn't have to ensure it's added when needed with each contribution.
I don't know how to test this and ensure everything works as it should.
Also, maybe we should consider an HTTPS only option for BoxBilling? SSL is very easy to get these days and IMO is needed if you have anything more than a static webpage

Failed checks are code warnings from CSRF-Protector-PHP and not my work, do we fix it?

@BenNottelling Fix it at the source and let the maintainer merge it in then reapply.

@BenNottelling Thanks for the draft of your pull request.

I won't be removing the TODO's. Those should be turned into a warning in CodeFactor and not a fail

@timothygwebb Can you confirm the fail CodeQL gives is correct? I don't want to mess with a replace function like this as I don't know if it's deliberate or not

I will look into it and get back to you.
Thanks
Timothy Webb Sr.
On Sat, Aug 7, 2021, 12:45 PM Benjamin Aerni @.***>
wrote:

@timothygwebb https://github.com/timothygwebb Can you confirm the fail
CodeQL gives is correct? I don't want to mess with a replace function like
this as I don't know if it's deliberate or not
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/boxbilling/boxbilling/pull/926#issuecomment-894677438,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD24K7IHEAIYBZ5FECL25A3T3VPLXANCNFSM5BW5DARA
.

Does anyone have anything for me to change before I merge?

Does this work on PHP 8?

Also, it'd be very nice if we don't go with a modified version. It means extra work for us to keep our fork even with the origin. I'm afraid this will turn out to have the same end with our forks of 7 year old packages that we never had time to maintain.

Does this work on PHP 8?

When I changed my instance to PHP 8, I get this when trying to login, with or without the protection module being loaded inside of bb-load.php.
Call to undefined function RedBeanPHP\new\ArrayIterator()
I find this strange, as I thought I've had a BB instance working on PHP 8 before. I'll have to do a clean install and try again

It means extra work for us to keep our fork even with the origin

Origin hasn't show any sign of life since October 16th, 2020. If they do update, the only modifications are this
https://github.com/boxbilling/boxbilling/pull/926/files?file-filters[]=.md&file-filters[]=.php#diff-20508a4d5810d789413daad8bdf0ec2b1213c3e75a0117ba1a5a6a1d22c70b22R140
And, I also updated the JS file based on coed analysis and this comment:
https://github.com/mebjas/CSRF-Protector-PHP/commit/df629c87e4b7b5408d32f1692ea8c93fb5ac8e4e#commitcomment-52126505
Also, on the subject of PHP8 giving that error, I can confirm it happens even on a fresh instance from the master branch

Well, it may not be a necessity but I still think it would be a better practice to leave the updating part to composer. If it's not possible now, I'm okay with that. But still would be glad to get rid of external packages from our base code, and get every dependancy handled by Composer.
I still approve these changes, and thanks for your work :)

Well, I'm okay with the changes. But not sure if anyone else would raise another concern.  RedBeanPHP
:: Install https://www.redbeanphp.com/index.php?p=/install
On Mon, Aug 9, 2021 at 11:28 AM Benjamin Aerni @.***>
wrote:

Does this work on PHP 8?
When I changed my instance to PHP 8, I get this when trying to login, with
or without the protection module being loaded inside of bb-load.php.
Call to undefined function RedBeanPHP\new\ArrayIterator()
I find this strange, as I thought I've had a BB instance working on PHP 8
before. I'll have to do a clean install and try again
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/boxbilling/boxbilling/pull/926#issuecomment-895319890,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD24K7LHMXNPORUFJ6REJITT37XZDANCNFSM5BW5DARA
.


This allows for users to set the environment as a string

This allows for users to set the environment as a string , often code uses string environment names and not symbols , this would wourk just as well with either without much effort

Are you sure this is a issue? Because it seems Sinatra is already forcing to_sym on settings.environment by default if you use ENV['RACK_ENV']. The documentation also suggest you use a symbol if you set it otherwise.
All in all, unfortunately I think this should not be dealt within sinatra-assetpack.

Hey ,
So the convention of setting a symbol is recommended but at best it's a convention. The code you point out works in case an app does not explicitly set it.
In cases where applications configure from an alternate data source and use environment in configuration this could very well be a string ( we render yml dynamically from an API call to a config server or from ETCD in a dockerized auto reconf deploy use case)
Also one may use :deployment, :release etc too we choose to use :production for assetpack's sake. The addition of a .to_sym is a neat solution , if it's a symbol it will be unchanged if string "production" it'll still just work, one stands to not loose anything by having this in place. There is no "overhead" per-say , and it retains all compat it already has.It'll be good to have this upstream.
My two cents.

I will merge since I see no bad side effect of doing it, but I would prefer to replace this whole configuration of output style with a setting like settings.assets.combine [true|false] rather than depend solely on the current sinatra env, which would allow to manage it like we want in any environment (staging, etc) & then you could do in your own app settings.assets.combine (settings.env.to_sym == 'production').
This was is something already discussed in #162 & #180.


There are no commands defined in the "code" namespace.

Sorted out.

how did you sorted out guys?

@linkgeneral Please read the docs.
https://github.com/nunomaduro/larastan/blob/master/README.md#-getting-started-in-3-steps
We moved away from artisan command.

@szepeviktor no one ever updated the carbon screenshot to remove the analyze command