pipenv 2023.6.26 breaking change to amplifyPush --simple when building backend with python function

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
d34baz6sf50mpj
AWS Region
us-east-1
Amplify Hosting feature
Backend builds
Frontend framework
React
Next.js version
N/A
Next.js router
N/A
Describe the bug
I'm using CodeCommit for CI/CD to an AWS Amplify application.
During the amplifyPush, this error would occur on previously working functions with no changes:
2023-06-27T09:27:41.100Z [INFO]: Installing dependencies from Pipfile.lock (2a8f7d)...
2023-06-27T09:27:41.144Z [WARNING]: usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: invalid command 'egg_info'
2023-06-27T09:27:41.265Z [WARNING]: ✖ There was an error initializing your environment.
2023-06-27T09:27:41.266Z [INFO]: 🛑 Failed to install dependencies in /.../amplify/backend/function/...: Error: Command failed with exit code 1: pipenv install
Expected behavior
2023-06-25T10:19:52.488Z [INFO]: Installing dependencies from Pipfile.lock (fbf9bb)...
2023-06-25T10:19:57.153Z [INFO]: To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
2023-06-25T10:20:01.364Z [WARNING]: - Uploading files.
Reproduction steps
Build any previously working AWS Amplify application with a Python lambda function in the backend.
Build Settings
phases:
    build:
      commands:
        - update-alternatives --install /usr/bin/python3 python3 /usr/local/bin/python3.9 15
        - /usr/local/bin/python3.9 -m pip install --upgrade pip
        - /usr/local/bin/pip3.9 install --upgrade setuptools
        - /usr/local/bin/pip3.9 install pipenv
        - amplifyPush --simple

### Log output

<details>

Put your logs below this line

</details>

### Additional information

The solution ended up being easy.  Change a single line in the setup.py of every function.

from distutils.core import setup
from setuptools import setup
setup(name='src', version='1.0')

After that, builds are successful.

Hi @breencp 👋 , thanks for reaching out to us and for sharing the detailed insights on your Amplify environment.
While reviewing your backend build logs, I came across this particular error error: invalid command 'egg_info' which seems related to a breaking change with the latest pipenv release: https://github.com/pypa/pipenv/issues/5753
Thank you for sharing the workaround which helped unblock your backend builds and this is going to be very useful for other developers in the community who run into something similar with their backend lambda functions.
We really appreciate it! 👏

Hello Team,
Faced the same error when building backend with python functions. Pinning pipenv version to previous version helped to move past the issue.
version: 1
backend:
  phases:
    build:
      commands:
        - '# Execute Amplify CLI with the helper script'
        - update-alternatives --install /usr/bin/python3 python3 /usr/local/bin/python3.9 12
        - /usr/local/bin/pip3.9 install --user pipenv==2023.6.18
        - python3 --version
        - amplifyPush --simple


AreaNFT.spit does not call onERC721Received when recipient of its Transfer events is a contract.

This can leave the recipient contract unaware of the new children, rendering them untransferable. An easy solution would be for split to somehow call _checkOnERC721Received, either directly, via_safeMint, or by some other means.
Unrelated to issue #1 as this is a problem regardless of if the recipient is the original owner or the message sender.

Thank you for sharing. First, this issue is indeed separate from #1.
Identification
You are referring to these lines of code:

https://github.com/AreaWorld/ethereum-contracts/blob/4eb55b7a7f81f63caf54b6ee177ad5b017f762e2/contracts/AreaNFT.sol#L55
https://github.com/AreaWorld/ethereum-contracts/blob/4eb55b7a7f81f63caf54b6ee177ad5b017f762e2/contracts/AreaNFT.sol#L63

where a token is effectively minted but the recipient does not receive a call to onERC721Received.
References
Is this disallowed?
The ERC-721 standard specifically disclaims any specification of minting functionality:

Creating of NFTs (“minting”) and destruction [of] NFTs (“burning”) is not included in the specification.

Therefore, AreaNFT does not violate the ERC-721 standard on this accord.
See below a note about another reference in the standard.
Is this weird/confusing/uncustomary?
But our level of sensitivity here includes even "Inconsistent usage of whitespace". So we don't need to argue that the behavior is disallowed, we merely need to show it is confusing to be a valid bug report.
Here are two (most?) notable implementations of ERC-721:

https://github.com/0xcert/ethereum-erc721/blob/master/src/contracts/tokens/nf-token.sol#L326 (official, reference implementation)
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol (popular)

Both of them include mint-without-calling-onERC721Received functionality as first-class features.
This means AreaNFT is doing something that many other people are doing and which is well-known.
The split function may produce up to 400 NFTs so of course using safeMint here is not possible (400 calls is too expensive). There there is not a desire to change this functionality.
But it may be worthwhile to document this in the function NatSpec for people reading the contract and writing contracts that interact with AreaNFT. Therefore:
This is a valid bug report. Impact rating is somewhere along the line of an-advanced-user-who-has-permission-to-do-something-might-make-a-mistake-because-they-were-expecting-something-that-is-not-reasonable-to-always-expect-but-could-be-improved-with-better-documentation. That is not the final decision on the rating, and we will classify it properly for you. But either way, valid and will result in a change of documentation.

Consolation prizes:
You already won so not sure if this can be called a consolation prize. :-)

There's two grammatical errors in the 721 spec quoted above. If you like you can be the one to PR that.
The 721 spec separately includes a related error. In the NatSpec for onERC721Received see the note about "transfer". There is actually no such thing as "transfer" and this should be "safeTransferFrom". If you like you can be the one to PR that.

That's an amazingly detailed response. Thanks for the careful consideration!

Thank you for your bug report! We worked on this at https://github.com/AreaWorld/ethereum-contracts/pull/6
Here are some notes on rating your finding.
IMPACT:
As per the notes above, this is somewhere between "affects the development process and validity of the applied code" and "notable". Let's call this "low impact".
LIKELIHOOD:
For this issue to cause the impact above, somebody would need to design a smart contract to perform Area token NFT splits, but then implement that contract so that it depends on the false assumption of having onERC721Received called.
Because we do not ourselves provide any contracts like the above, nor specifically encourage people to make them, this likelihood is somewhere below "a scenario that actually happens naturally in production deployments". Let's call this "low likelihood".
PAYOUT:
According to the bug bounty rules, this is an accepted problem with a risk rating of "notable". You win:

This limited, first edition Area T-shirt, mailed to your house, in time for you to wear at NFT.nyc
One Area NFT token from the token drop
Public acknowledgement from the Area team and personally from the contract developer on Twitter (if you allow)

Please contact us privately at<EMAIL_ADDRESS>or on our Discord to @DappPunk#9999 to arrange these.


test_source_lst_zenith fails

Putting a source at LST=RA and DEC=latitude should work if we understood coordinate systems better. Currently it is in its own test that fails.  Do we want to fix this?

duplicate with #8


#659 stack slots count uses actual field size

this fixes my problem

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

There were some build failures, but that is not related to this commit. Before I can merge this commit, I'll need you to digitally sign the CLA. You can find a link in the 2nd comment of this pull request.

signed. And works for me.


"Save Integration" button state should react to user activity

Describe the bug
Save Integration button is always enabled. It should be reactive to user activity.
To Reproduce
Settings >> Node Integrations >> (particular row) >> Edit Integration
Expected behavior
Save button enabled/disabled state should respond to user activity; starting in a disabled state upon entry (no changes so nothing to save). Once a change is made, it should be enabled. If that change is backed off, it should be disabled again.
Screenshots

Versions (please complete the following information):

OS: macOS
Browser Chrome
Automate Build Number<PHONE_NUMBER>5122

Additional context
NA

this has proven to be a bit trickier than expected.  We have [resetOrigin] built out in the formControl directive specifically for remembering values in forms, however this form is separated into multiple layers through several different components that are only activated when various selections are made in the form which is causing a little bit of havoc

The source of the problem after implementing [resetOrigin] is this:  We have a multi-layer form, and certain portions are being shown conditionally based on selections at the start of the form.  What happens is that, after implementing [resetOrigin], the changes are now being tracked and the "save integration" button disables as it is designed.  New UX confusion shows itself when...for example:

I am on the GCP tab > I change the name > save button is enabled
I am on the GCP tab > I revert the name back > save button is disabled
I switch to Azure tab > I select the opposite of my current service type > save button is enabled
I switch back to GCP tab > I make no changes > save button is still enabled

As a user from a UX perspective, I would expect the save button to be disabled again, because I have chosen to go back to the GCP form.  However, we are using one large form to track all settings, so [resetOrigin] is actually working as it is designed - it sees that there are in fact changes to the form with the altering of the Azure setting - so the save button is enabled.
All this is to say that, we know the problem, but the fix may be a bit more complex that I initially thought.

It appears we are only sending the portion of the form that is needed to save the integration.  In order to fix, i'll disable portions of the form that aren't needed - this way the formControl Directive won't track portions of the form that aren't being used but are still "existing"

Seems like fixed.


Removed unused import

This line causes a build breakage in environments that only expose some (public?) OpenSSL header files.
I'm not an expert in the area. Just noticed it and submitting a simple fix for it.

Friendly ping on this.

Oh... @bjosv so this PR is should instead be rejected then?

@zuiderkwast I believe so.
@bjornleffler Interesting, err.h is usually included in the required openssl-devel package or via Brews openssl on Mac, Windows I dont know. Which OS/distribution are you using? and which build system (Make or via CMake)?

Going to close this, as it looks like we do sometimes need the header.


[test-triage] chip_rv_dm_ndm_reset_req assert failing

Hierarchy of regression failure
Chip Level
Failure Description
Offending '(!rst_src_ni)' has 6 failures:

Test chip_sw_lc_ctrl_kmac_reset has 3 failures.
0.chip_sw_lc_ctrl_kmac_reset.4126001754
Line 493, in log /container/opentitan-public/scratch/os_regression/chip_earlgrey_asic-sim-vcs/0.chip_sw_lc_ctrl_kmac_reset/latest/run.log

      Offending '(!rst_src_ni)'
  UVM_ERROR @ 2408.539809 us: (prim_sync_reqack.sv:201) [ASSERT FAILED] SyncReqAckRstSrc
  UVM_INFO @ 2408.539809 us: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
  --- UVM Report catcher Summary ---

1.chip_sw_lc_ctrl_kmac_reset.1805505272
Line 495, in log /container/opentitan-public/scratch/os_regression/chip_earlgrey_asic-sim-vcs/1.chip_sw_lc_ctrl_kmac_reset/latest/run.log

      Offending '(!rst_src_ni)'
  UVM_ERROR @ 2843.112728 us: (prim_sync_reqack.sv:201) [ASSERT FAILED] SyncReqAckRstSrc
  UVM_INFO @ 2843.112728 us: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
  --- UVM Report catcher Summary ---

... and 1 more failures.

Test chip_rv_dm_ndm_reset_req has 3 failures.
0.chip_rv_dm_ndm_reset_req.3778920470
Line 475, in log /container/opentitan-public/scratch/os_regression/chip_earlgrey_asic-sim-vcs/0.chip_rv_dm_ndm_reset_req/latest/run.log

      Offending '(!rst_src_ni)'
  UVM_ERROR @ 3459.111856 us: (prim_sync_reqack.sv:201) [ASSERT FAILED] SyncReqAckRstSrc
  UVM_INFO @ 3459.111856 us: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
  --- UVM Report catcher Summary ---

1.chip_rv_dm_ndm_reset_req.369530232
Line 475, in log /container/opentitan-public/scratch/os_regression/chip_earlgrey_asic-sim-vcs/1.chip_rv_dm_ndm_reset_req/latest/run.log

      Offending '(!rst_src_ni)'
  UVM_ERROR @ 3586.547920 us: (prim_sync_reqack.sv:201) [ASSERT FAILED] SyncReqAckRstSrc
  UVM_INFO @ 3586.547920 us: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
  --- UVM Report catcher Summary ---

Steps to Reproduce

Commit hash d0b9668b2
dvsim invocation command to reproduce the failure, inclusive of build and run seeds:
./util/dvsim/dvsim.py hw/top_earlgrey/dv/chip_sim_cfg.hjson -i chip_rv_dm_ndm_reset_req --fixed-seed<PHONE_NUMBER> --build-seed<PHONE_NUMBER> --waves -v h

Tests with similar or related failures

[ ] chip_rv_dm_ndm_reset_req
[ ] chip_sw_lc_ctrl_kmac_reset

Github: https://github.com/lowrisc/opentitan/tree/84fdd3bf374f168367ba7ffcb07cfa4d79c54875

[x] chip_sw_pwrmgr_random_sleep_all_wake_ups.3614850612
[x] chip_sw_pwrmgr_deep_sleep_all_wake_ups.2335872897
[x] chip_sw_pwrmgr_normal_sleep_all_wake_ups.3771606132

The chip_rv_dm_ndm_reset_req test fails (with the provided seeds and also on e79e3525c284efe83f957ba62a24cd91be94370b, which is the current head of master) because the source of the following prim_sync_reqack_data is reset while the destination is not:
https://github.com/lowRISC/opentitan/blob/e79e3525c284efe83f957ba62a24cd91be94370b/hw/ip/otbn/rtl/otbn_scramble_ctrl.sv#L227-L235
According to a recently added (https://github.com/lowRISC/opentitan/pull/15100) assertion
https://github.com/lowRISC/opentitan/blob/e79e3525c284efe83f957ba62a24cd91be94370b/hw/ip/prim/rtl/prim_sync_reqack.sv#L199-L207
this is not legal, and thus the SyncReqAckRstSrc assertion fails.
The resets are driven by the reset manager (top_earlgrey.u_rstmgr_aon), which resets rstmgr_aon_resets.rst_sys_n[rstmgr_pkg::Domain0Sel] without simultaneously resetting rstmgr_aon_resets.rst_lc_io_div4_n[rstmgr_pkg::Domain0Sel]):
https://github.com/lowRISC/opentitan/blob/e79e3525c284efe83f957ba62a24cd91be94370b/hw/top_earlgrey/rtl/autogen/top_earlgrey.sv#L2310-L2312
I think the assertion is correct and the reorganization of the reset domains that is in progress (https://github.com/lowRISC/opentitan/issues/15317) should fix this. A hotfix to get these tests to pass could be to disable the assertion (set EnRstChks to 1'b0 for u_otp_key_req_sync in otbn_scramble_ctrl), but that would only mask the actual problem.
I have not tried chip_sw_lc_ctrl_kmac_reset or the other seeds, but the name of the failing assertion is the same, so I suspect the problem is the same.

Thanks @andreaskurth for the assessment. It looks like we should keep this open until https://github.com/lowRISC/opentitan/issues/15317 is merged in and then see if this issue is resolved.
@engdoreis let's keep this open during our on-call window. If by the end of Friday the issue is not merged please de-assign @andreaskurth but keep the issue open. I'm assigning @tjaychen as the planned assignee as the person with experience in this issue.

@jeoongp
@matutem
who will be looking after this change.

Adding a few more tests to this failing category (already updated in the description):
Github: https://github.com/lowrisc/opentitan/tree/84fdd3bf374f168367ba7ffcb07cfa4d79c54875

[ ] chip_sw_pwrmgr_random_sleep_all_wake_ups.3614850612
[ ] chip_sw_pwrmgr_deep_sleep_all_wake_ups.2335872897
[ ] chip_sw_pwrmgr_normal_sleep_all_wake_ups.3771606132

hmmm... let me have a look at the pwrmgr failures.
If those are actually going into deep sleep, there shouldn't be a domain crossing problem.  So this might be hitting a case that was not originally expected.  @cindychip i might separate those into a different issue if that's the case.

The chip_sw_pwrmgr_* failures should be addressed by #15541

@jeoongp i'm assigning this to you for now since it is related to the reset domain change.
Once that is ready, we can come back and have a look!

Sounds good.

All the related tests are passing:

Tests
latest
2022.10.23
2022.10.22
2022.10.21
2022.10.17/2
2022.10.17/1
2022.10.15
2022.10.14/2
2022.10.14/1
2022.10.12
Suite

141
chip_sw_pwrmgr_deep_sleep_all_wake_ups
100
100
100
100
0
0
0
100
100
100.00
chip_sw_pwrmgr_deep_sleep_all_wake_ups, chip_sw_power_sleep_load

146
chip_sw_pwrmgr_normal_sleep_all_wake_ups
100
100
100
100
0
0
0
100
100
66.67
chip_sw_pwrmgr_normal_sleep_all_wake_ups

148
chip_sw_pwrmgr_random_sleep_all_wake_ups
100
100
100
100
0
0
0
100
100
--
chip_sw_pwrmgr_random_sleep_all_wake_ups

Repening because I didn't notice that there's still two test failing with the same signature:

Tests
latest
2022.10.23
2022.10.22
2022.10.21
2022.10.17/2
2022.10.17/1
2022.10.15
2022.10.14/2
2022.10.14/1
2022.10.12
Suite

14
chip_rv_dm_ndm_reset_req
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
chip_rv_dm_ndm_reset_req

114
chip_sw_lc_ctrl_kmac_reset
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
chip_sw_lc_ctrl_kmac_reset

should we keep this open for a bit? The test does need a bit of tweaking also.

Huh I don't remember closing this... was it maybe autoclosed via #15602?
In any case, yes let's keep it open.

yeah in hindsight i think this was auto close. I'm going to quickly run the test just to see what's happening.

this should now hopefully be fixed, just waiting on regression results.

2 nightlies passed - If ok during the weekend we can close this out on Monday.


BUG/TEST: Fix stochastic oscillator test.

Don't create unnecessary extra data (requires passing fastd_period=1
to TA-Lib or else it fills the FastK with NaNs even though it must
have already computed them...

Use random_sample instead of random_integers so that we're not
dependent on integer arithmetic.

Pass array_decimal to assert_equal so that we do almost equal checking
on results.

Coverage decreased (-0.06%) to 85.71% when pulling 007e1f9cfbbd8da4be0a75def124fe6ef833442d on fix-flapping-stoch-osc-test into 5cf9921f04b048737035c9cb0cdea645210002c3 on master.

The consistent seed looks good to me. :+1:


obs-studio: fix build

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.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

The reason for the patch is in the patch name, which is better than a comment because it also shows up in build output.  It will be obvious when it can be removed because it is a backport, so it will produce a previously applied diff error when upgrading to a version that contains the patch.


Code part: No notification of exceptions in postamble with any setting

If an exception is raised in the postamble, NUMBAS silently stops running it and continues the grading without any kind of notification. The below example demonstrates this, raising an exception that results in the following code being unreachable:
https://numbas.mathcentre.ac.uk/question/share/edit/a4e16511-5d8e-446f-931c-bdf7b287f85d
I realize there may be security issues with students triggering exceptions to peek into marking code via tracebacks, but this makes debugging code parts extremely difficult.

I think this is just an oversight. Thanks for pointing it out.


feat(Icon): add ability use the loading prop without an icon

Fixes #1716.

Codecov Report

Merging #1768 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1768      +/-   ##
==========================================
+ Coverage   99.75%   99.75%   +<.01%
==========================================
  Files         142      142
  Lines        2466     2469       +3
==========================================
+ Hits         2460     2463       +3
  Misses          6        6

Impacted Files
Coverage Δ

src/elements/Input/Input.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

❤

Released in<EMAIL_ADDRESS>


Block input while window out of focus

Adds INPUT_ALLOW_OUT_OF_FOCUS macro, whether to allow input while game window is out of focus on desktop platforms
When false (default):

Prevents clicks from out of focus from registering input on all desktop platforms
Prevents gamepads registering input while window is out of focus on MacOS and Linux (this is default behaviour on Windows)

might as well do some per platform cursor normalization while we’re at it


Added Readme!

Could you mark this PR with Hacktoberfest-accepted Label so it counts towards the 4 open-source PR's? <3

Could you mark this PR with Hacktoberfest-accepted Label so it counts towards the 4 open-source PR's? <3

you need to add some info in readme like getting started and then I am able to add a hacktoberfest-accepted label.


What is this

What this?
Is a Warfare inc. map?
How and where i can download?
(This randomly appeared)

Hostile Takeover is the open-sourced version of Warfare Inc.

Hostile Takeover is the open-sourced version of Warfare Inc.

Oh


[RFP]: Create and Add KEUR in SORA for Kensetsu

Proposal Due Date
July 2024
Proposal Overview
Currently, Kensetsu has defined $KUSD as its main stablecoin due to the general dominance of the USD. With the arrival of the SORA card, all Europeans will deposit money into SORA in EUR and with the creation of KEUR we would avoid exposure to the fluctuation of the USD/EUR pair.
Additionally, creating $KEUR would allow many more vault creation combinations in Kensetsu.
Proposal Goals
Same as Proposal Overview
Scope of Work
Same as Proposal Overview
Current Roadblocks and Barriers to Success
Previous development tasks queued
Evaluation Metrics and Criteria
Same as KUSD
Submission Requirements
Created and approved in Democracy
Submission Method
Blockchain: Mainnet
Project Due Date
July 2024
Budget Amount
Same as KUSD, xD

Hey @miansegat this is actually already in the pipeline. We use Band protocol as our oracle provider, so any asset there we can use in Kensetsu.
I agree this could be a good selling point and additional usecase for SORA Card


Add example using multi2vec-clip module and python

This example makes use of Python and flask to use and explore the multi2vec-clip module available in weaviate.

Amazing work @sky-2002!


Added part of parser of the php7 branch

@to-be-the-best I really appreciate the help! Thanks for your PR.


Add comments to document expired cert handling

Add in-code comments to document whether expired certificates are included when iterating over certificates in a store.

Done in ef205776ee56a1b4d6f745afcd5ed3ae67a2cd26


Python 3.10 Lambda image throws Segmentation Violation when running locally

Any lambda image release for 3.10 past public.ecr.aws/lambda/python:3.10.2<IP_ADDRESS> cause the following error on receipt of a post request to the test endpoint when running locally
23 May 2023 23:13:20,652 [DEBUG] (rapid) invoke: -> POST /2015-03-31/functions/function/invocations map[Accept:[*/*] Accept-Encoding:[gzip, deflate] Baggage:[...] Connection:[keep-alive] Content-Length:[34] Content-Type:[application/json] Sentry-Trace:[...] User-Agent:[python-requests/2.28.2]]
23 May 2023 23:13:20,652 [INFO] (rapid) ReserveFailed: AlreadyReserved
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x68c30f]

goroutine 68 [running]:
go.amzn.com/lambda/rapidcore.(*Server).Invoke.func2()
/LambdaRuntimeLocal/lambda/rapidcore/server.go:653 +0xef
created by go.amzn.com/lambda/rapidcore.(*Server).Invoke
/LambdaRuntimeLocal/lambda/rapidcore/server.go:636 +0x23d

Same issue with public.ecr.aws/lambda/ruby:3.2-x86_64, image id: d95983042957
START RequestId: f998bff1-47d4-4206-a8f6-7696b92be10f Version: $LATEST
08 Dec 2023 10:57:13,427 [INFO] (rapid) ReserveFailed: AlreadyReserved
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x6af115]

goroutine 53 [running]:
go.amzn.com/lambda/rapidcore.(*Server).Invoke.func2()
	/LambdaRuntimeLocal/lambda/rapidcore/server.go:666 +0xf5
created by go.amzn.com/lambda/rapidcore.(*Server).Invoke
	/LambdaRuntimeLocal/lambda/rapidcore/server.go:649 +0x23d

I think this happens when there is more than one lambda executing at the same time

Anyone know of a resolution?  I'm hitting the exact same error using SAM CLI, version 1.105.0.
START RequestId: 865a1b4f-7c4e-466f-acb2-c7f06cc0cd6e Version: $LATEST
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x6af115]

goroutine 15 [running]:
go.amzn.com/lambda/rapidcore.(*Server).Invoke.func2()
	/LambdaRuntimeLocal/lambda/rapidcore/server.go:666 +0xf5
created by go.amzn.com/lambda/rapidcore.(*Server).Invoke
	/LambdaRuntimeLocal/lambda/rapidcore/server.go:649 +0x23d
No response from invoke container for HelloWorldFunction

I too only see this when invoking more than one execution at the same time.

Still happening with the Python 3.12 image.

I had the same issue with version 1.105.0 and using Python 3.12. I updated to the latest version of SAM (1.119.0) and it was resolved. It was not necessary to enable debug mode.


[Improvement]: Refactor Diagnostic Helper in Language Server

Description
The DiagnosticHelper class is used to publish diagnostics to the client side. A thread can invoke either of the following methods to publish the diagnostics.
https://github.com/ballerina-platform/ballerina-lang/blob/3a3b15ea0f2d0af250494feb2ab31b768e3dfca8/language-server/modules/langserver-core/src/main/java/org/ballerinalang/langserver/diagnostic/DiagnosticsHelper.java#L85-L144
When there is a contention among threads, the diagnostics corresponding to the thread which gets the execution at last will be visible to the user on client(vscode).
Following is a example scenario where the diagnostics published last is outdated.

In the quickfix option, we have a code action to generate the IDL client. When we execute it it generates files related to the IDL client inside the generated folder.

For each of this files a didChangeWatch is triggered from the client side and a new thread is created to compileAndPublish diagnostics. Inaddtion, at the end of the generation of files we create another thread to publish diagnostics here.
https://github.com/ballerina-platform/ballerina-lang/blob/3a3b15ea0f2d0af250494feb2ab31b768e3dfca8/language-server/modules/langserver-core/src/main/java/org/ballerinalang/langserver/command/executors/GenerateModuleForClientDeclExecutor.java#L121
So let's assume there are 4 threads in total, there is a contention among these threads. In many occasions the thread corresponding to the  GenerateModuleForClientDeclExecutor wins and publish the diagnostics(which are upto datet) first. And then the threads which are corresponding to the didChangeWatch event gets the chance and publish diagnostis (which are not up to date).
Therefore, even-though the IDL client is generated, the diagnostic no module generated for client declaration is still shown to the user`.
Therefore, we have to introduce a way to manage the contention. (eg: By using a cancellation approach)

I investigated the example scenario related to the IDL client generation and figured out the cause for the diagnostic inconsistency. When the IDL plugin generation is successful, a Scheduled Future (https://github.com/ballerina-platform/ballerina-lang/blob/8a2031c77a29185ada545b343fcabee8797c52c1/language-server/modules/langserver-core/src/main/java/org/ballerinalang/langserver/diagnostic/DiagnosticsHelper.java#L257)  is created to publish the diagnostics of the project. Further, the files created by the IDL client generation trigger the LS procedure DidChangedWatched and it also creates a scheduler to publish the diagnostics.
The latter cancels execution of the first scheduled future if it is not complete(https://github.com/ballerina-platform/ballerina-lang/blob/8a2031c77a29185ada545b343fcabee8797c52c1/language-server/modules/langserver-core/src/main/java/org/ballerinalang/langserver/diagnostic/DiagnosticsHelper.java#L253). Then it proceeds to publish the duiagnostics. However, when it attempts to obtain the compilation using projectPair.get().project().currentPackage().getCompilation() the thread does not complete the execution(hangs). Need to investigate more to figure out the cause.

Closing this as a low-priority task with the Icebox label might reopen in the future.


nix for m1 mac

Summary
As OTP24 JIT is not compatible with M1 mac,
replace nix with custom build of OTP24 without JIT.

@jechol we can actually switch this based on the enclosing environment. It would be nice to only scope the custom build to aarch64-darwin. Thoughts?


String translations for app

The chat functionality is currently completely in German. We need translations.

Done in https://github.com/digitalfabrik/integreat-app/pull/2939.


Keepalived fails silently

Issue description
I left keepalived running (while it generates quite some output), but after a couple of days it fails apparently with a successful exit status.
systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
   Loaded: loaded (/nix/store/pi8klfbs9iljsxxkpnksmsj6kksqh1p6-unit-keepalived.service/keepalived.service; linked; vendor preset: enabled)
   Active: inactive (dead) since Wed 2018-04-11 12:47:28 CEST; 5 days ago
 Main PID: 16815 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/keepalived.service

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Steps to reproduce
Add non-existing real servers (for example thousands of them to speed up the crashing). (These will generate output.)
Technical details

system: "x86_64-linux"
host os: Linux 4.9.75, NixOS, 17.09.git.2169304 (Hummingbird)
multi-user?: no
sandbox: yes
version: nix-env (Nix) 1.11.16
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

This issue is resolved with latest versions of all dependencies.


Login redirects

Look into history, possibly 6-7 page stack, to see how to redirect user to previous page after logging into the application.
Also, logged in users should not be able to access /login and logged out users should not be able to access /logout.

I've added auth checks to the /login and /logout routes in feature/add-user-roles-permissions. I also set up a possible redirect for when the user successfully logs in. Will need to test this once the auth login process is working again.


[ADDON] - Open Policy Agent

Add OPA addon with sensible defaults.
https://github.com/jasonumiker/eks-quickstart/tree/main/gatekeeper-policies

OPA Gatekeeper add-on merged - closing


Appstudio update test-component-pac-jmjj

Pipelines as Code configuration proposal

Pipelines as Code CI/test-component-pac-jmjj-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
26 seconds
init

✅ Succeeded
25 seconds
clone-repository

✅ Succeeded
49 seconds
build-container

✅ Succeeded
18 seconds
deprecated-base-image-check

✅ Succeeded
16 seconds
sanity-inspect-image

✅ Succeeded
3 minutes
clair-scan

✅ Succeeded
46 seconds
clamav-scan

✅ Succeeded
18 seconds
sbom-json-check

✅ Succeeded
7 seconds
sanity-optional-label-check

✅ Succeeded
7 seconds
sanity-label-check

✅ Succeeded
20 seconds
show-summary

Pipelines as Code CI/test-component-pac-jmjj-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
43 seconds
init

✅ Succeeded
17 seconds
clone-repository

✅ Succeeded
40 seconds
build-container

✅ Succeeded
21 seconds
sanity-inspect-image

✅ Succeeded
16 seconds
deprecated-base-image-check

✅ Succeeded
14 seconds
clair-scan

✅ Succeeded
13 seconds
sbom-json-check

✅ Succeeded
35 seconds
clamav-scan

✅ Succeeded
14 seconds
sanity-label-check

✅ Succeeded
14 seconds
sanity-optional-label-check

✅ Succeeded
5 seconds
show-summary


Enable Link-Time Optimization (LTO)

Hi!
I noticed that in the Cargo.toml file Link-Time Optimization (LTO) for the project is not enabled. I suggest switching it on since it will reduce the binary size (always a good thing to have) and will likely improve the application's performance - the same observation was mentioned in a Maturin issue. If you want to read a bit more about LTO, I can recommend starting from this Rustc documentation.
I suggest enabling LTO only for the Release builds so as not to sacrifice the developers' experience while working on the project since LTO consumes an additional amount of time to finish the compilation routine. If you think that a regular Release build should not be affected by such a change as well, then I suggest adding an additional dist or release-lto profile where in addition to regular release optimizations LTO will also be added. Such a change simplifies life for maintainers and others interested in the project persons who want to build the most performant version of the package. If we enable it on the Cargo profile level, users, who build the package manually will get the LTO-optimized version "automatically". E.g., check cargo-outdated Release profile.
Basically, it can be enabled with the following lines:
[profile.release]
lto = true

According to my quick local tests with the latest evmole version on Fedora 41 + Rustc 1.82, adding lto = true to the Release profile reduces the final wheel size from 313 Kib to 284 Kib (built with the maturin build --release command).
Thank you.

Hi!
Thanks! It's been enabled in the master branch: https://github.com/cdump/evmole/commit/932284ae54da8a3c4acd121f10d34bd1515c6317
P.S. I tried using LTO some time ago but observed no changes in the benchmark results, so I didn’t enable it then. However, the reduction in size is a sufficient reason to enable it by default now.


fix(): fixed slicegw health status for single cluster (#207)

fix(): fixed slicegw health status for single cluster

fix(): fixed broken UTs

fix(): fixed ITs

fix(): handling multiple slicegw deployments

Reference PR https://github.com/kubeslice/worker-operator/pull/207
allure report https://kubeslice.github.io/e2e-allure-reports/Kind-worker-operator-2023-04-01T16:48:11-release-guwahati-394/index.html

  [FAIL] Hub ClusterController Cluster health check [It] Should update cluster CR with compoent status as error for all
  /workspace/tests/hub/cluster_controller_test.go:327
  [FAIL] Hub ClusterController Cluster health check [It] Should update cluster CR with component status as normal when pods running``` these cases are related to cluster health events present in master.

@gourishkb cluster health check tests were passing in https://github.com/kubeslice/worker-operator/pull/204. The failures maybe be due to recent changes.
Also  @richiesebastian Is there any change in github actions file? I don't see ITs here in this PR

closing this PR for https://github.com/kubeslice/worker-operator/pull/213


auth:list prints empty table when no auth'd orgs are found

Summary
sfdx auth:list prints an empty table when no auth'd orgs are found, previously it would just print No results found.
Seems this happened after releasing plugin-auth v2, if I re-install v1 I get the previous msg.
Steps To Reproduce:
no orgs, run sfdx auth:list on latest:

if you install plugin-auth v1 (sfdx plugins:install @salesforce/plugin-auth@1.8.2):

System Information
{
  "cliVersion": "sfdx-cli/7.176.1",
  "architecture": "linux-x64",
  "nodeVersion": "node-v18.12.0",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 1.3.5 (core)",
    "@oclif/plugin-commands 2.2.1 (core)",
    "@oclif/plugin-help 5.1.17 (core)",
    "@oclif/plugin-not-found 2.3.7 (core)",
    "@oclif/plugin-plugins 2.1.6 (core)",
    "@oclif/plugin-update 3.0.6 (core)",
    "@oclif/plugin-version 1.1.3 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.12 (core)",
    "@oclif/plugin-which 2.1.1 (core)",
    "alias 2.1.7 (core)",
    "apex 1.3.0 (core)",
    "auth 1.8.2 (user)",
    "community 2.0.14 (core)",
    "config 1.4.22 (core)",
    "custom-metadata 2.0.3 (core)",
    "data 2.1.7 (core)",
    "generator 2.0.9 (core)",
    "info 2.2.4 (core)",
    "limits 2.0.10 (core)",
    "org 2.2.11 (core)",
    "packaging 1.10.1 (core)",
    "schema 2.1.12 (core)",
    "signups 1.2.11 (core)",
    "source 2.3.0 (core)",
    "telemetry 2.0.2 (core)",
    "templates 55.1.0 (core)",
    "trust 2.0.4 (core)",
    "user 2.1.16 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "salesforce-alm 54.8.3 (core)"
  ],
  "osVersion": "Linux 5.10.47-linuxkit",
  "shell": "bash",
  "rootPath": "/usr/local/sfdx"
}

The code for the error msg is still in the plugin:
https://github.com/salesforcecli/plugin-auth/blob/main/src/commands/auth/list.ts#L47
in the v2 of plugin-auth we moved to sfdx-core v3 so maybe the func used to get the auths changed. To make sure the command shows the error it might be better to check the length of the array returned by AuthInfo.listAllAuthorizations and print a table or the msg instead of relying on it to throw.
AuthInfo.listAllAuthorizations: https://github.com/forcedotcom/sfdx-core/blob/main/src/org/authInfo.ts#L269
noResultsFound msg: https://github.com/salesforcecli/plugin-auth/blob/main/messages/list.json#L3
I will left this marked as help wanted, please post here if you have any questions.


[23.x][WFLY-14711] In WildFly Preview enable use an alternate XJC variant

https://issues.redhat.com/browse/WFLY-14711
Upstream: #14228
This build on #14227 so it can get the test benefit of that change

WF Preview tests of this PR:
https://ci.wildfly.org/viewLog.html?buildId=252951&tab=buildResultsDiv&buildTypeId=WF_WildFlyPreviewLinuxJdk11
https://ci.wildfly.org/viewLog.html?buildId=252953&tab=buildResultsDiv&buildTypeId=WF_Ee9BootableJarLinuxJdk8

Note that as the PR currently stands it's not expected to have any functional impact. It just sets things up to make it easy to do a possible XJC upgrade via a simple version property change PR.


feature: Blacklist/Whitelist headers

🚨 Breaking Change Alert!
🧰 What's being changed?
Adding the ability to black/whitelist request and response headers! Now the blacklist and whitelist options have headers and body objects which take the arrays.
💭 Outstanding Questions

[ ] Should I do this in a way that is non-breaking? I was thinking options.blacklistHeaders or something like that but it seems somewhat inelegant
[ ] I don't need tests for "nested" headers, right? Is that even a thing?
[ ] Are there certain headers that we shouldn't allow users to exclude? Stuff like: https://github.com/readmeio/readme-node/blob/7d353c7a8d0dac75dcb4d744e2a18f11143a4461/lib/process-request.js#L21-L22

Should I do this in a way that is non-breaking? I was thinking options.blacklistHeaders or something like that but it seems somewhat inelegant

I'm okay with no longer supporting the old options key in that way. I'll just package this as a full version bump and add a note in the changelog.

How about we just make this super simple, keep the API the same and we use the same blacklist/whitelist keys for everything (body and headers?).

Interesting... I'm good with that! Thoughts @erunion?

Sounds good to me.


Unable to run on Ubuntu 20.04 due to python command

Hey! I noticed that when I tried to run the basic example that I was unable to. The reason seems to be that it runs the python command. Unfortunately, on my system (Ubuntu 20.04), I didn't have this command set, as I only had python3. I got around this by using update-alternatives as per this documentation.
Here is the error I got:
cargo run --features glsl-compile --release --example basic
   Compiling shaderc-sys v0.6.2
The following warnings were emitted during compilation:

warning: Checking for system installed libraries.  Use --features = build-from-source to disable this behavior
warning: System installed library not found.  Falling back to build from source

error: failed to run custom build command for `shaderc-sys v0.6.2`

Caused by:
  process didn't exit successfully: `/home/vax/code/emu/target/release/build/shaderc-sys-53b173bc91346eab/build-script-build` (exit code: 101)
--- stdout
cargo:warning=Checking for system installed libraries.  Use --features = build-from-source to disable this behavior
cargo:warning=System installed library not found.  Falling back to build from source

--- stderr
thread 'main' panicked at '

couldn't find required command: "python"

', /home/vax/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.2/build/cmd_finder.rs:50:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Thanks for posting an issue for this! It seems like this has to do with the way shaderc gets compiled. Since there's a work-around I'm going to close this.


Boolean comparison vs tuple fails in 0.17.0

Just updated to 0.17.0 (python 2.7.9 on OS X Yosemite) and I found the following:
>>> import pandas as pd
>>> pd.__version__
u'0.17.0'
>>> s = pd.Series([(1,1),(1,2)])
>>> s==(1,2)
0    False
1    False
dtype: bool

Meanwhile in 0.16.2:
>>> import pandas as pd
>>> pd.__version__
'0.16.2'
>>> s = pd.Series([(1,1),(1,2)])
>>> s==(1,2)
0    False
1     True
dtype: bool

Can you check that you're using the same version of numpy? I think this could actually be an issue with numpy 1.10 adjusting its casting rules...

Hi,
In both cases I have latest numpy (1.10.1). I don't know if it's related or not but I actually got to this issue because I have a Series where values are frozensets. In that case not only fails but there is also an exception. Maybe the traceback helps you to know if this is numpy- or just pandas-related
>>> s = pd.Series([frozenset([1]), frozenset([1,2])])
>>> s
0       (1)
1    (1, 2)
dtype: object
>>> s == frozenset([1,2])
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-40-2d7a371a1a3d> in <module>()
----> 1 s == frozenset([1,2])

/Users/sancho/.virtualenvs/test/lib/python2.7/site-packages/pandas/core/ops.pyc in wrapper(self, other, axis)
    724                 other = np.asarray(other)
    725
--> 726             res = na_op(values, other)
    727             if isscalar(res):
    728                 raise TypeError('Could not compare %s type with Series'

/Users/sancho/.virtualenvs/test/lib/python2.7/site-packages/pandas/core/ops.pyc in na_op(x, y)
    644                     result = lib.vec_compare(x, y.astype(np.object_), op)
    645                 else:
--> 646                     result = lib.vec_compare(x, y, op)
    647             else:
    648                 result = lib.scalar_compare(x, y, op)

pandas/lib.pyx in pandas.lib.vec_compare (pandas/lib.c:14283)()

ValueError: Buffer has wrong number of dimensions (expected 1, got 0)

this was a bug introduced in #10569  I think. fixed in #11339

Should I create another issue for the exception when comparing versus a frozenset or it's already included in the same fix?

fixed up.. note that using object dtype things inside a Series is very inefficient.

The behavior may be changed after #13637. Pls comment if any thoughts.


Connecting to a DB Instance Through psql

Issue on page:        https://github.com/opentelekomcloud-docs/relational-database-service/blob/main/umn/source/getting_started_with_rds_for_postgresql/step_2_connect_to_a_db_instance/connecting_to_a_postgresql_db_instance_through_a_private_network/connecting_to_a_db_instance_through_psql.rst
On the manuals there are several commands written without using code blocks which looks weird, for instance the following part:
**psql --no-readline -U <user> -h <host> -p <port> -d <datastore> -W**

A code-block directive should be used instead:
  .. code-block::

     psql --no-readline -U <user> -h <host> -p <port> -d <datastore> -W

Hi @tischrei ,
sorry for the late answer. The document provider had been addressed about the issue, I will inform you in case we will have some updates.


global: release checklist

Takes over https://github.com/inveniosoftware/invenio-pidstore/pull/100

Build will pass once https://github.com/inveniosoftware/invenio-access/pull/108 gets merged


⚠ Bofrost.at has degraded performance

In 73da496, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2236 ms

Resolved: Bofrost.at performance has improved in 60bde53.


Out of Memory Issue in Semantic Segmentation

Why is it that when working on semantic segmentation, I constantly encounter out of memory errors, even though I have two GPUs with 15GB each? Is it possible to distribute the model workload across the GPUs in parallel?

The SAM itself is not heavy. But semantic segment anything requires four large model which is very memory consuming.  At now, simply use  --semantic_segment_device as 'CPU' to run.  We are working on make this model lightweight now.

Hi, we have implement a light version.
Can be run on 8G GPU less than 10s.


Wrong cast to non scalar type, and some other problems.

I try build rock in Visual Studio 2015, but got several bugs which i don't understand.
I can fix that manually in C source, but I think it's wrong.
I tried minimize broken code, and:
Handler: interface {
    onHandle: func
}

DefaultHandler: class implements Handler {
    init: func
    onHandle: func
}

Foo : class {
    handler: Handler { get set }
    init: func {
        handler = DefaultHandler new()
    }
}

main: func {
    foo := Foo new()
    foo handler onHandle()
}

in C source I got...  example:
Handler__reference test_temp__Foo___gethandler__(test_temp__Foo* this) {
    return (Handler__reference) ((test_temp__FooClass *)((lang_types__Object *)this)->class)->__gethandler__((test_temp__Foo*)this);
}

Handler_reference is struct, and I think such cast is GCC extension not allowed in C99, and in Visual C.
Next. In some places uses structs without member, is also GCC extension imho, and Visual C++ throw
error C2016: C requires that a struct or union has at least one member.
And finally. When I tried minimize broken code, I write:
Handler: interface {
    onHandle: func
}

DefaultHandler: class implements Handler {
	init: func
    onHandle: func
}

main: func {
    handler: Handler
    handler = DefaultHandler new()
    handler onHandle()
}

and got
lang_Numbers__Int main(lang_Numbers__Int __test_temp_argc1, lang_Character__CString* __test_temp_argv2) {
...
    Handler__reference handler = NULL; // 1
    handler = test_temp__DefaultHandler_new(); // 2
    test_temp__Handler_onHandle((Handler__reference) handler); // 3
    return 0;
}

in 1 place struct Handler__reference initialized like pointer
in 2 place DefaultHandler * assigned to struct Handler_reference
in 3 place we also have cast to non scalar type.

Hi and thanks for the report.
Interfaces are a known buggy feature and MSVC compatibility has not been tested in a long time.
However, I will take a look into these tomorrow, especially the last issue you pointed out.

Hi and thanks for the respond
I can build and test rock on MSVC, and fix not cross-platform places, but first I think need fix GCC specific code.
To build rock on MSVC I change some places:

remove unistd.h,
use https://github.com/tronkko/dirent for dirent.h,
build boehmgc from https://github.com/ivmai/bdwgc,
fix structs without member,
add defined(_WIN32) for version (windows),
replace ssize_t with intptr_t for SSizeT

Then I use --driver=dummy or bootstrap C source and manually add files to MSVC project.

You can also use cmake driver to generate msvc project files.


Use friendly enum names for the D wrapper

E.g. before:
public alias cairo_antialias_t AntiAlias;
auto gray = AntiAlias.CAIRO_ANTIALIAS_GRAY;

After:
enum AntiAlias
{
    ...
    gray = cairo_antialias_t.CAIRO_ANTIALIAS_GRAY,
    ...
}
auto gray = AntiAlias.gray;

I think the above would avoid having use use casts in the D wrapper. It will break existing code (not that anyone noticed code breakage recently, probably very few if any users are around yet), but it would not break code which used the cairo.c.* modules directly since they would not be affected.
@jpf91: If you give me the go-ahead I can start working on this.

Whoever wrote that deimos header, he shouldn't have changed the enum names. The goal of deimos is to provide 1-to-1 translation headers of the C version.
Renaming enums is left for D wrappers such as this.


Left USB-C Thunderbolt port not working properly

I am observing some interesting behaviour with the thunderbolt port. When I boot up with nothing plugged in and try to connect a storage device to that port no device is connected. However, USB HID devices work (keyboard, mouse) as expected.
More interestingly, if I start with the computer off and the storage device plugged in and then boot into OSX, the device will be connected and will show up. If I unplug and plug back in the storage device it will not show up as a connected device.

This is normal thunderbolt behavior on hackintosh AFAIK. Also I think there is no known workaround for this.

Just as a hint: Your HID-Devices and similar aren't really thunderbolt, but very likely usb. The connector is usb-c and it can do multiple protocols (TB, USB 2/3/3.1, DP, etc) with different backing controllers.
The problem on hackintoshes is mostly about TB on usb-c, because the firmware and power management of apple's TB-controllers works entirely different than those for other OS'es. So even if it's the same hardware found on windows laptops, they don't "just work" because of the different firmware.
Some attempts to fix this by patching the firmware can be found here: https://github.com/osy86/ThunderboltPatcher


fix(terraform): fix terraform module versions

Description

Fix Terraform module versions
Add default_language_version to .pre-commit-config.yaml

How has this been tested?
Tested with terraform apply locally.
Checklist

[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have successfully run the E2E tests, and have included the links to the pipeline runs below
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have updated any relevant documentation to reflect my changes
[ ] I have assigned a reviewer and messaged them

Pipeline run links:

It's a fair point!
These docs were (mostly) autogenerated using terraform-docs, which works great for reusable Terraform modules that are published to the Terraform Registry.
Since I don't think we're likely to publish the terraform directory as a module to the Terraform Registry, let's remove this stuff from the README (everything from <!-- BEGIN_TF_DOCS --> below can be cut). It will make it neater and easier to maintain.
Thanks!

Done! I removed the auto-generated terraform-docs from README.

/lgtm
/merge

@Linchin I don't think we have any of this automation set up. Is this something you can help us with?

@Linchin I don't think we have any of this automation set up. Is this something you can help us with?

Yes, I merged it as I just became an admin for this repo. Let me see how to do the / lgtm and / approve thing.


CI: Upgrade artifact actions

v3 of actions/upload-artifact and
actions/download-artifact becomes obsolete.

Posted upstream: https://github.com/mcu-tools/mcuboot/pull/2125


Optional basic auth protection for site

Context
We want to be able to see & share next year's course listings before they are ready to be seen by candidates. This adds an optional password to protect the whole site. See the readme for usage.
Changes proposed in this pull request

Add a basic auth lib.
Make it configurable based on password config.

 🔒 Secure Search and Compare UI with optional authentication


[AMD] Hint the compiler to preload kernel arguments

This PR adds InReg attributes to all kernel arguments. This tells the backend compiler to try to set things up so that the firmware will set kernel args to user SGPRs instead of using s_load at the beginning of the kernel.
Note that though we set InReg to all kernel args,  the backend compiler will decide the actual number of args that can be pre-set.
Performance context: this PR can improve kernel execution time by about 5 ~ 10 us.

@zhanglx13 could you resolve the conflicts so I can merge ?


[bug] fast pcl NDT use huge memory

Bug
When "use_fast_pcl" is true,  if load a large map (like moriyama), use too huge memory.
If the map size is large, I think that it is better to notify the warning and end the program.
Specifications

Ubuntu version: 16.04
ROS Version: kinekic
Autoware branch: develop

@kitsukawa @anhnv3991 was this solved in the latest fix #1189?

I confirmed that the program outputs the warning and terminates when the memory usage reaches its limit. So I close this issue.


try running editor (from update-alternatives) before vi

I had configured nano as the default editor on my system by using update-alternatives.
cargo crev ends up using vi as the default editor since I didn't set the EDITOR env var or git's core.editor value (git ends up using nano without those being set).
crev should try using editor (/usr/bin/editor) before defaulting to vi.
Version:
cargo-crev-crev 0.8.3 installed using cargo install from crates.io
I'm on Ubuntu 18.04 x86_64

I looked into how git does things here...
https://github.com/git/git/blob/6d5b26420848ec3bc7eae46a7ffa54f20276249d/editor.c#L8
and vi seems to be a fallback default.
It seems that it is being patched in debian/ubuntu package, here http://archive.ubuntu.com/ubuntu/pool/main/g/git/git_2.7.4-0ubuntu1.6.debian.tar.xz
rules
19:  DEFAULT_PAGER=pager DEFAULT_EDITOR=editor \

Since edtior binary doesn't seem to be any sort of Unix standard... so I'm a bit meh about implementing it. Once cargo-crev is package in debian... LOL... they will just have to patch it there too. :D

would you accept pull requests as long as falling back to vi works when editor is not found?

No, because there is no guarantee that editor even have to be a text editor on other systems etc. while vi considered (informally?) a always-present, default text editor in Unix. And it is just silly, when all it takes... is to set a default global EDITOR. :D

What about if it checks for Debian-based distros where editor is known to be correct before trying editor?  can be checked relatively easily by checking for /etc/debian_version


Cleanup of terminated tasks

I've added a handler for tasks revoked through Celery. Right now it cleans up the temp subdirectory it operates on every time revoke is called.

 divik-worker does not clean up after task revoke


publisher exclusion feature from advanced profile

Thanks for the contribution, I've just merged it. I think the advanced mode features need a little more polish (e.g. roles and features should be validated and if a feature is not configured it should not be used). But that's too much for now and this is at least a start to get your desired feature working.


Fix Xcode project warning

:wave: Thanks for taking the time to submit a PR! We use XcodeGen to automatically generate our Xcode project file. Can you make the changes required there instead, and then run swift run xcodegen from the root of the repo to regenerate the project file? This may be a matter of upgrading the version of XcodeGen we use (defined in our SPM package description, here: https://github.com/pointfreeco/swift-snapshot-testing/blob/master/Package.swift#L27-L33).

Oh, sorry, I don't have expertise in XcodeGen. Could someone else do this?

Just got around to doing this. Thanks for opening the issue 😄


[tooling] Enable validation for appwrapper

We need to enable yaml validation submitted to MCAD. specifically to stanzas that represent resources ie custompodresources
CC @tardieu

@anishasthana @astefanutti  Can you please help us to mandate custompodresources stanza that can help us further simplify resource discovery logic in MCAD

One trivial, yet limited, way would be to mandate the custompodresources array to have at least one item.
As the CRDs are generated from the APIs, this can be achieved with:
// +kubebuilder:validation:MinItems:=1
CustomPodResources []CustomPodResourceTemplate

A more elaborated logic could be specified using validation rules, which leverages the CEL expression language. Note that fields from the generic items, other than the runtime object ones, are not accessible to at CEL, so the logic would be limited to the later. Note also these validation rules are available since Kubernetes 1.25.
For completeness, a validation webhook would provide the maximum expressiveness, that would come at the expense of an operational cost that would be difficult to justify here.
So we need to review first what functional logic is to be applied, and then decide on the implementation.


deploy:shared recipe ignores changes in laravel storage folder

Q
A

Issue Type
Bug

Deployer Version
6.1.0

Local Machine OS
Ubuntu 16.04.4

Remote Machine OS
Ubuntu 16.04.4

Description
deploy:shared recipe ignores changes in the Laravel storage folder coming from git.
Steps to reproduce
You manually create a new folder inside Laravel 5.5 storage/app/ that was already deployed before without this new folder and push that change. Then, deploy it using deployer 6.1.0 and you will see that the folder shared/storage/app does not contain the folder you created manually.
This is because the shared recipe in Deployer only updates the content of "storage" if it does not exist.

This can be closed since it is already solved here: https://github.com/deployphp/deployer/pull/1594


Add HN Special to Chrome

Thank you for your contribution to the awesome-hackernews repository. :thumbsup:
Before submitting this PR, please make sure the following conditions are met (please tick the relevant boxes):

[x] The pull request concerns only one project1.

[x] This project is classified as FOSS.

[x] The pull request title is "Add <xxx> to <yyy>", which means adding project <xxx> to section <yyy>.2

[x] Your addition satisfy the following formatting3:
- [Name](http://homepage/) - Short description. ([Source Code](http://url.of/source/code)) `License`

If the project does not have a homepage, use the following format3:
- [Name](http://url.of/source/code) - Short description. `License`

[x] Your addition is inserted in alphabetical order in the list.

[x] You have searched the repository for any relevant issues or PRs, including closed ones.

If you have any questions or would like to provide more information regarding your PR, please use the comments section below.

1: If you want to submit multiple projects, please open one PR per project.
2: If the project does not fit into an already existing section, i.e. a new one must be created, do not hesitate to create it. We'll discuss that in the comments below.
3: scripts/format_entry.sh can be invoked to help you.

Let's:

remove '📋 '. I suppose you copy-pasted it from somewhere.
add a space after the dot (before Source Code)

Done, thanks for reviewing!


Update API Documentation

This issue asked about the possible precipitation types and since it was not in the API documentation I went and added it in as well as placeholders for the other items in the main response block.
Feel free to make any wording changes or updates to the information I provided if you have better wording or I have included incorrect information. I mimicked the documentation style of DarkSky but if you prefer to have your own style you can change that as well. Hopefully this is a reminder to finish the API documentation 😊
When going through the documentation I noticed that windGustTime is missing on the daily section in your API response.
EDIT: I had originally had definitions for the daily temperature parameters but since there is ongoing discussions in this issue I decided to change them to In progress so there is no misinformation in the documentation.

These are great updates! Updating this part of the docs is something that had dropped off my radar (pun intended), so I really appreciate you putting these changes in. I took a look over this and it all is looking good, so I've merged this in. The docs are generated automatically, so this revision should show up shortly.

@alexander0042 You're welcome! I might add more documentation in the future but for now this is at least a good start.
I see that the text summaries are now next up on the priority list which is exciting. I find that after using AccuWeather/The Weather Channel/Environment Canada that the summaries offered by DarkSky are pretty basic though it can be added to down the line.


Ib routes Made URLS act like they should

Added url routes so that get requests to pages return index.html and not null

added a file that shouldnt be merged


Problem Details should be expanded

The problem details intent doesn't really give you much useful information that the problem intent doesn't. Once we have "permission" from the user to do more analysis on a problem, perhaps we should spend more time doing things like looking for similar incidents in the past or listing more than just the first root cause event

{
    "text": "Below are the problem details you requested.",
    "attachments": [
        {
            "fallback": "WEB_CHECK_GLOBAL_OUTAGE\nImpacted: easy travel demo booking \nApplication\nInitial Event: Web Check Global Outage\nStatus: Resolved",
            "color": "#dc172a",
            "title": "Web Check Global Outage",
            "title_link": "https://cdojfgmpzd.live.dynatrace.com/#problems;filter=watched/problemdetails;pid=-3951031557428477198",
            "fields": [
                {
                    "title": "Impacted",
                    "value": "easy travel demo booking \nApplication",
                    "short": "true"
                },
                {
                    "title": "Initial Event",
                    "value": "Web Check Global Outage",
                    "short": "true"
                },
                {
                    "title": "Status",
                    "value": "Unresolved",
                    "short": "true"
                },
                {
                    "title": "Unresolved Impacts",
                    "value": "1/5",
                    "short": true
                },
				{
					"title": "Time Frame",
					"value": "Started <!date^1484031471^{date_short_pretty} {time}|yesterday at 1:57 AM>. Currently ongoing",
					"short": false
				}
            ]
        },
        {
            "title": "User Action Duration Degradation",
            "color": "#7dc540",
            "fields": [
                {
                    "title": "Open",
                    "value": "0/4",
                    "short": true
                },
                {
                    "title": "Affected Actions/Minute",
                    "value": "25.4",
                    "short": true
                }
            ]
        },
        {
            "title": "Connection Lost",
            "color": "#dc172a",
            "fields": [
                {
                    "title": "Open",
                    "value": "1/1",
                    "short": true
                }
            ]
        }
    ]
}

Check it out here

This is fixed for visual responses in 609e6159. Still need to expand text and audible.


App getting stuck while adding contact

In 2.0 live app I was able to add contacts. I upgraded the live app to 2.0.2. Now when I'm trying to add contact the app is getting stuck.https://user-images.githubusercontent.com/68264080/142012011-23841bcc-d0a9-43ae-833d-417d5b3efec9.mp4

Verified this issue on staging app v2.0.5(282)


[SOLVERS] Epic for Curve CowSwap Fee Burning with Paloma

Closing as requires mainly back-end work.


Fault injection

Most mature distributed system projects have some sort of fault injection frameworks for testing purposes.  Some examples:

Hadoop: https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/FaultInjectFramework.html
Spark: https://github.com/databricks/spark-integration-tests/blob/9f515bf9aa8163ee7e7936f6e4a36cc771cfff04/src/test/scala/org/apache/spark/integrationtests/docker/network/NetworkFaultInjector.scala

And there are more general-purpose tools such as Jepsen and ChaosMonkey that can be used to inject network faults.
Using tools such as these will help us identify bugs that would otherwise be found in production.

Made some progress for 1.1 by adding tests for dynamic membership.  Removing the 1.1 label as we will be revisiting this issue post 1.1.

We should aim to do more of this in 1.2.
In particular I'd like to see some faults that affect running jobs and see how the system handles it.

We should also add coverage for the places that we support exponential backoff. Specifically in PutBlock and DeleteBlock

The need for this tool is getting stronger, as we are seeing more people pumping a serious amount of data into Pachyderm and bugs are being caught in production.  Most of those bugs only manifest when certain requests fail due to transient network failures, which can be simulated by such a tool.

We have a recent need for testing of this nature:
https://github.com/pachyderm/pachyderm/issues/2675
This will be a critical path for a customer's deployment.


Assetto Corsa 1.12

Opponent race finished check. (same as in R3E)

Dont we need to copy SessionData.HasExtraLap from previousGameState to currentGameState in "if (!justGoneGreen && previousGameState != null)" Block ?

Yra

Argghh, fcking mobile phone, what have I done? All I wanted to do was say "yes"

ok i'll push that change.

added it!


Add support for entrypoint in stack files

Fixes #2949
Adds / fixes support for the entrypoint keyword in stack/compose YAMLs.

For reference, https://github.com/kontena/kontena/blob/9defedc8bc82cea6eb48ee2708bd6a69e2424829/cli/lib/kontena/cli/stacks/service_generator.rb includes all the keys imported from compose yml's.
Should cross check with https://kontena.io/docs/references/stack-file-vs-compose.html

I think depends_on, logging and env_file are not supported when extending.

I think this should have an e2e test.

I don't mean a test spec that runs kontena stack validate, I mean an actual e2e spec that deploys the stack and looks at the deployed container entrypoint.
That kind of real e2e spec is needed to make sure that e.g. the CLI is sending the right form of { "entrypoint": ...}  JSON that doesn't just get ignored/rejected by the server, or possibly even cause the container create to fail on the agent (is it an array or a string in the Docker API? Both, I think...). The current specs don't cover that.

Tested to work with both the /w/w entrypoint and in network_mode: host, I think I'll write up an e2e spec for this next.


Testnet/mainnet selection should probably be in stored in URL

Otherwise reloading page changes the selection to mainnet

What would be an acceptable URL schema?
For example, instead of the current /account/<address>, should it be /account/<network>/<address> ?

I no longer think we want this after https://github.com/oasisprotocol/oasis-wallet-web/issues/792
it would just be a source of conflicting state

Indeed.


/swap_pixel and /copy_pixel

Suggestion add a /move endpoint
This will allow a user to move a pixel on maybe a shorter rate limit than /set_pixel
Things to consider are:

Max range of moving a pixel
dynamic rate limit based on distance moved

Discussion on discord points towards 2 things:

a /copy_pixel endpoint to copy a pixel from one location to another but NOT change the original location's pixel
much higher ratelimits on /swap_pixel since it can be used destructively

If this is approved I'll reopen #83 with these changes

I am closing this issue. We will be doing something different for the next event, but that will be planned in secret, as to not spoil the fun!


feat: remove test-d.ts file override rules

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Error decoding response body when trying to fetch subreddit.article_comments

Those lines of code should be enough to replicate the issue:
use anyhow::Result;
use roux::Subreddit;

#[tokio::main]
async fn main() -> Result<()> {
    let subreddit = Subreddit::new("rust");

    let comments = subreddit.article_comments("t3_zv5znb", None, None).await?;

    Ok(())
}

And I'm getting the following output:
Error: error decoding response body: invalid type: map, expected a sequence at line 1 column 0

Caused by:
    0: error decoding response body: invalid type: map, expected a sequence at line 1 column 0
    1: invalid type: map, expected a sequence at line 1 column 0

My Cargo.toml consists of the following crates:
anyhow = "1.0.68"
roux = "2.2.4"
tokio = { version = "1.23.0", features = ["full"] }

Any ideas?

It seems like you're using the article name  instead of id. Reddit IDs are in base 36 and are 6 chars long, but I think names are just the combination of <kind>_<id>, so if you remove the t3 from you example like:
let comments = subreddit.article_comments("zv5znb", None, None).await?;

It should work.

Yes, it does work. Thanks a lot!


Dark Mode for blog theme

Would it be possible, to add the dark mode button to the blog theme?
Loving the project so far, huge thanks :)

This would be something nice to work on!


Allow json_build_object to work

For issue https://github.com/kyleconroy/sqlc/issues/761. While this is kind of a hack, it gets the job done in the meantime.

It is indeed a hack! Thanks for the PR, but I'm going to go ahead and work on adding true support for variadic functions.

Did you look at the latest changes? I am no longer using the hack and just ignoring the argument length test if they include a variadic argument.
If you are looking to accomplish more than what I have laid out I am willing to work more on this.
I suppose if there is 1 variadic argument then no additional positional arguments should be able to follow, and I suppose that we can still check whether the minimum number of arguments is met, but I figure there is a superficial argument check currently.


ERROR: column "public" of relation "buckets" does not exist (SQLSTATE 42703) During supabase db reset

Describe the bug
I was previously using v1.68.6 of the cli, and had no problem running migrations that included, among other things:
-- supabase/migrations/20230420235920_buckets.sql
insert into storage.buckets (id, name, public)
  values
    ('public', 'public', 'TRUE'),
    ('private', 'private', 'FALSE');

I then upgraded to v1.75.3 and the following error began presenting itself:
Applying migration<PHONE_NUMBER>5920_buckets.sql...
ERROR: column "public" of relation "buckets" does not exist (SQLSTATE 42703)
At statement 0: insert into storage.buckets (id, name, public)
  values
    ('public', 'public', 'TRUE'),
    ('private', 'private', 'FALSE')
Try rerunning the command with --debug to troubleshoot the error.

I tried running the exact same query in an empty project, using v1.75.3, without any migrations, once supabase db reset finished (from the web UI's SQL Editor) and get no errors (Success. 0 rows returned).
To Reproduce
Steps to reproduce the behavior:

Create a new supabase project without any migrations

cd ~ && mkdir supabase-bug-test
cd supabase-bug-test
supabase init && supabase start

Create a new migration:

supabase migration new buckets

Add the following to the newly created migration:

-- supabase/migrations/..._buckets.sql
insert into storage.buckets (id, name, public)
  values
    ('public', 'public', 'TRUE'),
    ('private', 'private', 'FALSE');

Attempt to reset the database (supabase db reset)

Expected behavior
The database should not be throwing the error (indeed, it worked all the way to, at least, v1.68.6 and broke somewhere between v1.75.3)
Desktop (please complete the following information):

OS: Mac OS 13.3 (22E252)
Version of CLI:

v1.68.6 (no error)
v1.75.3 (error)

Edit: current workaround is downgrading back to 1.68.6:
brew tap-new supabase/local-tap
brew extract --version=1.68.6 supabase/tap/supabase supabase/local-tap
brew install<EMAIL_ADDRESS>supabase -v

Can you try supabase stop --no-backup before running supabase start? This flag cleans up any db volumes leftover from previous runs to ensure a clean start.
I can't seem to reproduce on a clean start.

@sweatybridge I tried your suggestion, and running supabase stop --no-backup followed by supabase start manages to reset everything fine, however I am still getting the exact same issue when I try and run supabase db reset.

Here's the output:
nrb@nrb-mbp inspire-tms-frontend % supabase stop --no-backup
Stopped supabase local development setup.
nrb@nrb-mbp inspire-tms-frontend % supabase start
Applying migration<PHONE_NUMBER>1043_diff.sql...
Applying migration<PHONE_NUMBER>4112_diff.sql...
Applying migration<PHONE_NUMBER>4424_diff.sql...
Applying migration<PHONE_NUMBER>5315_diff.sql...
Applying migration<PHONE_NUMBER>0056_diff.sql...
Applying migration<PHONE_NUMBER>1240_diff.sql...
Applying migration<PHONE_NUMBER>1424_diff.sql...
Applying migration<PHONE_NUMBER>1755_diff.sql...
Applying migration<PHONE_NUMBER>5920_buckets.sql...
Applying migration<PHONE_NUMBER>0801_diff.sql...
Applying migration<PHONE_NUMBER>0505_diff.sql...
Applying migration<PHONE_NUMBER>5108_diff.sql...
Applying migration<PHONE_NUMBER>5218_diff.sql...
Applying migration<PHONE_NUMBER>5649_diff.sql...
Applying migration<PHONE_NUMBER>0201_diff.sql...
Applying migration<PHONE_NUMBER>0327_diff.sql...
Applying migration<PHONE_NUMBER>1224_diff.sql...
Applying migration<PHONE_NUMBER>2912_diff.sql...
Applying migration<PHONE_NUMBER>4427_diff.sql...
Applying migration<PHONE_NUMBER>1059_diff.sql...
Applying migration<PHONE_NUMBER>1435_diff.sql...
Applying migration<PHONE_NUMBER>0437_diff.sql...
Applying migration<PHONE_NUMBER>0753_diff.sql...
Applying migration<PHONE_NUMBER>2602_diff.sql...
Applying migration<PHONE_NUMBER>3352_diff.sql...
Applying migration<PHONE_NUMBER>3507_diff.sql...
Applying migration<PHONE_NUMBER>0001_diff.sql...
Applying migration<PHONE_NUMBER>0338_diff.sql...
Applying migration<PHONE_NUMBER>0741_diff.sql...
Applying migration<PHONE_NUMBER>1005_diff.sql...
Applying migration<PHONE_NUMBER>1836_diff.sql...
Applying migration<PHONE_NUMBER>1013_diff.sql...
Applying migration<PHONE_NUMBER>0442_diff.sql...
Applying migration<PHONE_NUMBER>0804_diff.sql...
Applying migration<PHONE_NUMBER>1041_diff.sql...
Applying migration<PHONE_NUMBER>1606_diff.sql...
Applying migration<PHONE_NUMBER>1948_diff.sql...
Applying migration<PHONE_NUMBER>2432_diff.sql...
Applying migration<PHONE_NUMBER>2717_diff.sql...
Applying migration<PHONE_NUMBER>0326_diff.sql...
Applying migration<PHONE_NUMBER>0236_diff.sql...
Applying migration<PHONE_NUMBER>3056_diff.sql...
Applying migration<PHONE_NUMBER>3826_diff.sql...
Applying migration<PHONE_NUMBER>4231_diff.sql...
Applying migration<PHONE_NUMBER>4738_diff.sql...
Applying migration<PHONE_NUMBER>4924_diff.sql...
Applying migration<PHONE_NUMBER>0636_diff.sql...
Applying migration<PHONE_NUMBER>1835_diff.sql...
Applying migration<PHONE_NUMBER>4722_diff.sql...
Applying migration<PHONE_NUMBER>1141_diff.sql...
Applying migration<PHONE_NUMBER>2212_diff.sql...
Applying migration<PHONE_NUMBER>2550_diff.sql...
Applying migration<PHONE_NUMBER>4129_diff.sql...
Applying migration<PHONE_NUMBER>3543_diff.sql...
Applying migration<PHONE_NUMBER>5826_diff.sql...
Applying migration<PHONE_NUMBER>0024_diff.sql...
Applying migration<PHONE_NUMBER>0811_diff.sql...
Applying migration<PHONE_NUMBER>1733_diff.sql...
Applying migration<PHONE_NUMBER>2148_diff.sql...
Applying migration<PHONE_NUMBER>2503_diff.sql...
Applying migration<PHONE_NUMBER>1949_diff.sql...
Applying migration<PHONE_NUMBER>2231_diff.sql...
Applying migration<PHONE_NUMBER>3214_diff.sql...
Applying migration<PHONE_NUMBER>3517_diff.sql...
Applying migration<PHONE_NUMBER>2346_diff.sql...
Applying migration<PHONE_NUMBER>2534_diff.sql...
Applying migration<PHONE_NUMBER>2800_diff.sql...
Applying migration<PHONE_NUMBER>5833_diff.sql...
Applying migration<PHONE_NUMBER>1021_diff.sql...
Applying migration<PHONE_NUMBER>0338_diff.sql...
Applying migration<PHONE_NUMBER>0712_diff.sql...
Applying migration<PHONE_NUMBER>1512_diff.sql...
Applying migration<PHONE_NUMBER>3935_diff.sql...
Applying migration<PHONE_NUMBER>0505_diff.sql...
Applying migration<PHONE_NUMBER>2321_diff.sql...
Applying migration<PHONE_NUMBER>3118_diff.sql...
Applying migration<PHONE_NUMBER>3432_diff.sql...
Applying migration<PHONE_NUMBER>4438_diff.sql...
Applying migration<PHONE_NUMBER>2238_diff.sql...
Applying migration<PHONE_NUMBER>4037_diff.sql...
Applying migration<PHONE_NUMBER>5357_diff.sql...
Applying migration<PHONE_NUMBER>0259_diff.sql...
Applying migration<PHONE_NUMBER>3038_diff.sql...
Applying migration<PHONE_NUMBER>1823_diff.sql...
Applying migration<PHONE_NUMBER>2533_diff.sql...
Applying migration<PHONE_NUMBER>3018_diff.sql...
Applying migration<PHONE_NUMBER>3622_diff.sql...
Applying migration<PHONE_NUMBER>4105_bulk_migrating_company_id_checks.sql...
Applying migration<PHONE_NUMBER>3429_diff.sql...
Applying migration<PHONE_NUMBER>0548_diff.sql...
Applying migration<PHONE_NUMBER>0712_diff.sql...
Applying migration<PHONE_NUMBER>0137_diff.sql...
Applying migration<PHONE_NUMBER>4632_diff.sql...
Applying migration<PHONE_NUMBER>4724_diff.sql...
Applying migration<PHONE_NUMBER>2318_diff.sql...
Applying migration<PHONE_NUMBER>2948_diff.sql...
Applying migration<PHONE_NUMBER>3217_company_id_unique_with_account_id.sql...
Applying migration<PHONE_NUMBER>3656_renaming_realtime_function.sql...
Applying migration<PHONE_NUMBER>0431_diff.sql...
Applying migration<PHONE_NUMBER>0548_diff.sql...
Applying migration<PHONE_NUMBER>0847_profile_picture_bucket.sql...
Applying migration<PHONE_NUMBER>2200_profile_picture_bucket_rls_policies.sql...
Applying migration<PHONE_NUMBER>3815_diff.sql...
Applying migration<PHONE_NUMBER>4029_diff.sql...
Applying migration<PHONE_NUMBER>4307_diff.sql...
Applying migration<PHONE_NUMBER>1845_diff.sql...
Applying migration<PHONE_NUMBER>1125_adding_current_company_id_to_accounts_with_protections.sql...
Applying migration<PHONE_NUMBER>2401_refining_account_level_protections.sql...
Applying migration<PHONE_NUMBER>3015_refining_account_level_protections.sql...
Applying migration<PHONE_NUMBER>3344_refining_account_level_protections.sql...
Applying migration<PHONE_NUMBER>3146_diff.sql...
Applying migration<PHONE_NUMBER>0824_delete_own_comments.sql...
Applying migration<PHONE_NUMBER>1242_view_profiles_by_user_company.sql...
Applying migration<PHONE_NUMBER>3817_fix_full_name_for_profiles.sql...
Applying migration<PHONE_NUMBER>1842_diff.sql...
Applying migration<PHONE_NUMBER>0234_diff.sql...
Applying migration<PHONE_NUMBER>0506_diff.sql...
Applying migration<PHONE_NUMBER>1156_diff.sql...
Applying migration<PHONE_NUMBER>1250_diff.sql...
Applying migration<PHONE_NUMBER>1429_protect_company_id_for_equipment.sql...
Applying migration<PHONE_NUMBER>2353_diff.sql...
Applying migration<PHONE_NUMBER>3515_finishing_equipment_table.sql...
Applying migration<PHONE_NUMBER>5510_diff.sql...
Applying migration<PHONE_NUMBER>0701_diff.sql...
Applying migration<PHONE_NUMBER>1045_diff.sql...
Applying migration<PHONE_NUMBER>1414_diff.sql...
Applying migration<PHONE_NUMBER>2040_diff.sql...
Applying migration<PHONE_NUMBER>3514_allow_auth_users_schema_access.sql...
Applying migration<PHONE_NUMBER>0218_beginning_public_issues.sql...
Applying migration<PHONE_NUMBER>1420_issues_company_id_protections.sql...
Applying migration<PHONE_NUMBER>1552_diff.sql...
Applying migration<PHONE_NUMBER>1812_diff.sql...
Applying migration<PHONE_NUMBER>1104_building_kanban.sql...
Applying migration<PHONE_NUMBER>1801_diff.sql...
Applying migration<PHONE_NUMBER>4612_diff.sql...
Applying migration<PHONE_NUMBER>5806_diff.sql...
Applying migration<PHONE_NUMBER>3139_diff.sql...
Applying migration<PHONE_NUMBER>0252_diff.sql...
Applying migration<PHONE_NUMBER>3206_diff.sql...
Applying migration<PHONE_NUMBER>5225_diff.sql...
Applying migration<PHONE_NUMBER>5549_diff.sql...
Applying migration<PHONE_NUMBER>5617_diff.sql...
Applying migration<PHONE_NUMBER>1533_diff.sql...
Applying migration<PHONE_NUMBER>4043_diff.sql...
Applying migration<PHONE_NUMBER>1520_diff.sql...
Applying migration<PHONE_NUMBER>2248_diff.sql...
Applying migration<PHONE_NUMBER>3101_protect_issues_company_id.sql...
Applying migration<PHONE_NUMBER>3234_diff.sql...
Applying migration<PHONE_NUMBER>3701_diff.sql...
Applying migration<PHONE_NUMBER>2130_diff.sql...
Applying migration<PHONE_NUMBER>4505_diff.sql...
Applying migration<PHONE_NUMBER>4932_diff.sql...
Applying migration<PHONE_NUMBER>2614_diff.sql...
Applying migration<PHONE_NUMBER>2707_diff.sql...
Applying migration<PHONE_NUMBER>4525_diff.sql...
Applying migration<PHONE_NUMBER>0435_diff.sql...
Applying migration<PHONE_NUMBER>2206_diff.sql...
Applying migration<PHONE_NUMBER>5356_diff.sql...
Applying migration<PHONE_NUMBER>2328_diff.sql...
Applying migration<PHONE_NUMBER>0252_removing_profile_pictures_bucket.sql...
Applying migration<PHONE_NUMBER>1743_public_profile_pictures_rls_policies.sql...
Applying migration<PHONE_NUMBER>2314_cleaning_up_old_profile_pictures_bucket_policies.sql...
Applying migration<PHONE_NUMBER>3053_profile_pictures_folder.sql...
Applying migration<PHONE_NUMBER>3913_diff.sql...
Applying migration<PHONE_NUMBER>4639_diff.sql...
Applying migration<PHONE_NUMBER>4651_create_public_profiles_picture_folder.sql...
Applying migration<PHONE_NUMBER>3509_allow_users_to_create_company_private_folder.sql...
Seeding data supabase/seed.sql...
Started supabase local development setup.

         API URL: http://localhost:54321
     GraphQL URL: http://localhost:54321/graphql/v1
          DB URL: postgresql://postgres:postgres@localhost:54322/postgres
      Studio URL: http://localhost:54323
    Inbucket URL: http://localhost:54324
      JWT secret: super-secret-jwt-token-with-at-least-32-characters-long
        anon key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0
service_role key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImV4cCI6MTk4MzgxMjk5Nn0.EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU
nrb@nrb-mbp inspire-tms-frontend % supabase db reset
Resetting local database...
Restarting containers...
Applying migration<PHONE_NUMBER>1043_diff.sql...
Applying migration<PHONE_NUMBER>4112_diff.sql...
Applying migration<PHONE_NUMBER>4424_diff.sql...
Applying migration<PHONE_NUMBER>5315_diff.sql...
Applying migration<PHONE_NUMBER>0056_diff.sql...
Applying migration<PHONE_NUMBER>1240_diff.sql...
Applying migration<PHONE_NUMBER>1424_diff.sql...
Applying migration<PHONE_NUMBER>1755_diff.sql...
Applying migration<PHONE_NUMBER>5920_buckets.sql...
ERROR: column "public" of relation "buckets" does not exist (SQLSTATE 42703)
At statement 0: insert into storage.buckets (id, name, public)
  values
    ('public', 'public', 'TRUE'),
    ('private', 'private', 'FALSE')
Try rerunning the command with --debug to troubleshoot the error.

Thanks for the quick turn-around @sweatybridge !


proxies are repeating

is there a way to use every proxy once?
my code is like:
`
from proxy_requests import ProxyRequests
while True:
r = ProxyRequests("Censored")
r.post({"Censored"})
print(r)
print(r.get_status_code())
print(r.get_proxy_used())`

and output is like this:
`
<IP_ADDRESS>:40487
"CENSORED"
200
<IP_ADDRESS>:41960
"CENSORED"
400
<IP_ADDRESS>:41960
"CENSORED"
400
<IP_ADDRESS>:41960
"CENSORED"`

Ah yeah for each request there is a list of proxies used (they are scraped from the web). That list won't change until the source is changed/updated (when the website updates their proxies).
Give me a week or so and I will try to add something to fix that. It is possible to use the entire list: See #6
But maybe I will try to add something to randomize or minimize repeated proxies. I'm mostly concerned with the proxy socket's health.


highlight shell code blocks and remove '> ' for easier copying of commands

Highlight is for highlighting comments

Any comment why?


Ready for 0.2.0 release: add conda.txt dependencies and update python version

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

closes #1

@conda-forge-admin please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

@cadenmyers13 for the PR title, let's make sure we (@sbillinge and I) can recognize what this PR is about from our notifications.. probably "Ready for xxx release -  " would be good.

Checklist

[x]  Used a personal fork of the feedstock to propose changes
[x]  Bumped the build number (if the version is unchanged)
[x]  Reset the build number to 0 (if the version changed)
[ ]  Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x]  Ensured the license file is being packaged.

closes #1

@cadenmyers13 looking at the checklist - the second checklist should not have been checked-off since the version number is changed. For the 4th, let's also re-render. It's a way to ensure conda-forge cooks new CI pipe configurations based on our meta.yaml (our command).

@bobleesj Sorry, misread. Got it

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11788062649.

@cadenmyers13 meta.yaml lgtm. Welcome to the circle of life (patiently waiting for the CI to pass) - also it will take 15-20 mins to appear on  the conda-forge chanel once we merge this PR as well (Probably it's also building again behind the scenes)

Seems like we are trying to source it from test pypi
From
source:
  url: https://test.pypi.io/packages/source/d/diffpy_fourigui/diffpy_fourigui-{{ version }}.tar.gz

to
source:
  url: https://pypi.org/packages/source/d/diffpy_fourigui/diffpy_fourigui-{{ version }}.tar.gz

ad also please remove https://github.com/cadenmyers13/diffpy.fourigui-feedstock/blob/meta/recipe/conda_build_config.yaml - this conda package was also released using a rc version (instructions provided in GitLab) but here we want to do full release.

@cadenmyers13 in the meantime, we could fix this conda-forge building problem? We don't need another release since we can re-build docs via workflow dispatch.

@bobleesj got it

@bobleesj I updated the sha256 as done in this PR: https://github.com/conda-forge/kaldi-feedstock/pull/3

@sbillinge pinging for review

Please check https://github.com/conda-forge/diffpy.fourigui-feedstock/issues/1 which is an instruction in the release too

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11802634772.

Please check #1 There is an checklist to check the issues in the release checklist

Okay, I'll recut the meta.yml file

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

❌ There are too few lines.  There should be one empty line at the end of the file.

For recipe/meta.yaml:

ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

closing for a fresh PR

closing for a new, clean PR


Update link to point to new repo

@ArvindHarinder1 : Thanks for your contribution! The author, @billmath, has been notified to review your proposed change.

#sign-off


hellomako: trivial bare python app

My second snap.  I did this to learn how to use python modules inside snaps.

Nice work!


Reward across multiple days is confusing

Description
Today I received the daily reward, but a minute after the amount was reduced.
I received 1140 today and my balance reflected that, but now the amount in the wallet history dropped to 904 in both my history and balance.
Steps to Reproduce
Check the wallet and notification immediately after receiving, check if it changes after a while.
Expected behavior
The amount should stay the same and not be reduced after.
Screenshot
Notification:

Wallet history:

Additional context
Noticed for the first time, not sure if it happened before.
Is there any amount shared with territories owners? If it is, it should be shown on a separate notification.

That reward notification is summarizing your rewards across multiple days, 12/9-12/10. Click on it for a break down across multiple days

Multiple people have been confused by this though so we probably need to summarize this in a less ambiguous way.

I see, but why has the wallet's total balance changed too?
Is it based in the aggregation?

Your wallet balance shouldn't change as the result of rewards. It should only go up as the result of rewards.
You can see all the sources of spending/stacking by looking at your wallet history. If there's discrepancy after you review that, let me know.

That's what made me notice the issue.
After I received the reward the balance was around 4000 and then it stopped to around 3800 with the change in the notification.
Also I just received today's rewards and it seems to be correct.

So when you look at your wallet history there's no - zero - spending but your balance went down?
What's your nym? I can look for myself if you can double check and confirm you spent nothing to explain the difference.

Yes, I did zap two comments the same day but it was after the issue, I didn't do anything before sharing the issue.
The screenshots attached show the latest entries at the time.
Anyway, my nym on SN is nostranger.

After double checking, with the 80 sats spent later in the day, they still won't add up to the 4000 I was before the issue with the notification.

I just did a full manual accounting on your wallet. It checks out to the millisat:
Rewards: +22691497
Zaps earned: +22752900
Invoices paid/funded: +250000
Fee or zaps sent: -16375000
Donations given: -4830000
Withdrawals: -20404933
-------------------------
current balance: 4084464 msats (ie 4084 sats)

Sorry to intervene but I just wanted to mention it might be good to just stop merging the reward notifications until we found a better solution since this has confused quite some people already.

That assumes they were merged for no reason

Thanks @huumn for the trouble, so basically the balance was wrong when I received the notification and it updated to the correct value.
I haven't checked the code but maybe it was a wrong sum on the frontend side?

Personally, I think the aggregation could be more readable if it respects the interaction with the notifications.
For example, it adds the amount until it is seen, then it adds as a separate aggregate until seen again later.
Or maybe simpler, it can just show everything separately and then aggregate everything on a daily basis for easier viewing of post events.
What do you think?

I haven't checked the code but maybe it was a wrong sum on the frontend side?

According to our current limited understanding and iirc, there was and is no wrong sum on the frontend

Personally, I think the aggregation could be more readable if it respects the interaction with the notifications.

Interesting, makes sense

We send a notification for each reward day now. Thus this is resolved.