ALVR fails to start

Description
After trying multiple versions of ALVR, multiple clean installs of SteamVR, and some trouble shooting spent in the Discord help channel, I've decided to make an issue.
Launching ALVR simply sits on the "Waiting for server to load..." window, and SteamVR launches asking me to plug in my VR headset. "Reset drivers" button does not work.
Launching the executable in terminal does not give me any valuable information. SteamVR logs have printed out this:
Sun Jan 29 2023 21:53:19.583688 - Unable to load driver alvr_server from /home/azure/Desktop/alvr_server_linux/lib64/alvr/bin/linux64/driver_alvr_server.so (libx264.so.163: cannot open shared object file: No such file or directory)
And on app image and built from source:
Mon Jan 30 2023 08:24:32.463160 - Not loading driver alvr_server because it was blocked by a previous safe mode event
Unblocking the addon in settings does not work and continues to be blocked on start up.
I don't know if there's something wrong with my hardware or Linux install, it's a recently fresh install and runs other things perfectly fine so far, only ALVR is tripping up.
General Troubleshooting

[x] I carefully followed the instructions in the README and successfully completed the setup wizard
[x] I read the ALVR Wikis here and here

Environment
Hardware
https://linux-hardware.org/?probe=8f3278e68a
Installation
ALVR Version: v19 release, and multiple different versions of v20 nightly.
SteamVR Version: Beta 1.25.3 and Stable 1.24.7.
Install Type:

[ ] Packaged (exe, deb, rpm, etc)
[x] Portable (zip)
[x] Source

^ I've tried both. (Is app image considered packaged? If so, throw that in there.)
OS Name and Version: Ubuntu 22.10

Same problem. May be you need install libx264.so.163
I tried install libray but still safe mode and no any logs.

Can you confirm that 19.1 and the newer nightly AppImages also show this issue? (We stopped distributing portable tar.gz builds due to the number of similar compatibility issues)

I am no longer using linux for the time being, thank you for getting back
to me but I've just used windows for VR at this point.

I see. Well, when you decide to give VR on Linux a chance, consider reaching out as we have a nice community to help fellow Linux VR users out. Going to close this for the meantime.

I have this issue on Pop OS 22.04 (Ubuntu based) with a;vr 19.1. Im attempting the latest nightly now, then ill test older ones.

The solution in my case, was to extract the .appimage with --appimage-extract in the terminal. Then go into the newly created folders and use spuashfs-root/usr/bin/alvr_launcher to run ALVR
`
./ALVR-x86_64.AppImage --appimage-extract
cd squashfs-root/usr/bin
./alvr_launcher
`
This is the only way ive ever been able to get alvr .appimages to work on Pop(Ubuntu) 20.04 as well as 22.04.

do you have fuse2 installed?

Yes i have libfuse2 v2.9.9 on my system
-------- Original Message --------
On Mar 11, 2023, 11:38 AM, Vixea wrote:

do you have fuse2 installed?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>


Exam: Divide the Testing Process into Steps

Is your feature request related to a problem?
Currently it is a best practice is to replace working test cases with a single dummy test (that never fails) by issuing a commit during the exam programming exercise creation process to prevent accidental execution of test cases due to misconfiguration. After testing, it is subsequently necessary to revert this commit. This procedure causes unnecessary workload and may lead to problems if handled carelessly.
Describe the solution you'd like
One option would be to split the testing process into four steps:

Compile the test code on the test repository. In case the test code does not compile, deactivate all further steps and notify the instructors.
Compile the student code on the student repository. In case the student code does not compile, deactivate all further steps and display an error message to the student.
Copy the student code from the the student repository into the assignment/src folder of the test code on the test repository. This step is deactivated until the end of the exam.
Execute the test code and display the respective result to the student. This step is deactivated until the end of the exam.

Describe alternatives you've considered
Another option would be to automate the dummy test commit and commit revert, so that the instructors do not have to do it manually.
Additional context
One advantage of compiling the test code separately without the student code is that it enforces the use of reflections to access the student code (a general best practice).

For teaching FPV (the programming language is set to OCaml in Artemis), we solve this by checking whether the deadline has passed, and if so, statically disabling all but a dummy test. This is done by dynamically generating source code, so it happens before student code ever gets the chance to do anything, and should be fairly safe. With this approach, the deadline needs to be set only once in the test repository. Effectively, we perform the four steps you've described embedded into our test framework. Note that for OCaml exercises, the entry point is just a shell script, which makes this possible. Helpful, perhaps, would be to somehow pass the exercise deadline (and maybe even some additional parameters about the exercise?) into the environment of the test runner.
As a side note: one of the current strengths of Artemis, currently, is that the test system is very generic: anything that can be run from a docker container and output JUnit XML files can be used as a test runner (just choose "Empty" as the programming language and configure the CI as desired). By enforcing any kind of system onto what happens inside the runner, you remove some of that flexibility. For example: OCaml (and other more "static" languages, probably) can't easily be compiled without the implementation present and reflection is out of the question. So maybe this would make more sense to add to the (Java?) programming language template.


fix: feature to use uuids as entity ids

Added feature to use uuids for post.id, tag.id and author.id

@zhkazarosian please rename PR to feat


985 | Sum of Even Numbers After Queries | Python

Title - Sum of Even Numbers After Queries
Type of Issue -

[x] Adding New Code

Programming Language

[x] Python

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

Please assign to me

@juhikushwah Will you be assigning this issue?


fix: remove old exclusions for openfermion.

Codecov Report
Base: 94.04% // Head: 94.04% // No change to project coverage :thumbsup:

Coverage data is based on head (131a271) compared to base (f06543d).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #68   +/-   ##
=======================================
  Coverage   94.04%   94.04%
=======================================
  Files          46       46
  Lines        3042     3042
=======================================
  Hits         2861     2861
  Misses        181      181

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[in_app_purchase] Provide Documentation on "How to verify subscriptions status"

Is it possible to have some docs or guide about how to verify subscriptions status? Thanks in advance  (in_app_purchase)

Related issue

@dannycortesv did you find a solution to this?

Year and half later and still no documentation , neither any example

@mvanbeusekom Is this resolved in the updated docs?


Bandcamp rejecting clients with 403

Jul 18 10:00:21 nixos mopidy[668276]:   translate_uri error "403 Client Error: Forbidden for url: https://bandcamp.com/api/mobile/24/tralbum_details?band_id=3537931136&tralbum_type=t&tralbum_id=530455317"
Jul 18 10:00:21 nixos mopidy[668276]: WARNING  2024-07-18 10:00:21,193 [668276:Core-7 (_actor_loop)] mopidy.core.tracklist
Jul 18 10:00:21 nixos mopidy[668276]:   Track is not playable: bandcamp:track:3537931136-1106135643-530455317
Jul 18 10:00:21 nixos mopidy[668276]: ERROR    2024-07-18 10:00:21,235 [668276:BandcampBackend-5 (_actor_loop)] mopidy_bandcamp

Anybody seeing similar stuff? I can still connect and play bandcamp content through the website, so it doesn't seem to be some ip-based block.

The token stored in configuration may have expired. Have you checked after generating a new token?

That's the strange thing though, I don't think I've ever configured and set a token to access bandcamp. Used to "just-work", and that seems to have changed recently.

Is there a bandcamp section in Mopidy's configuration? Does this bandcamp section has a identity key ?
[bandcamp]
identity = 7%09xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%3D%09%7B%22ex%22%3Ax%2C%22id%22%3Axxxxxxxxxx%7D

It does not!

So, I've created myself a "fan" account, and captured the identity field from the cookie, and I still get:
Jul 24 22:03:17 kktdr mopidy[924152]: INFO     2024-07-24 22:03:17,774 [924152:MpdSession-17 (_actor_loop)] mopidy_mpd.session
Jul 24 22:03:17 kktdr mopidy[924152]:   New MPD connection from [::ffff:<IP_ADDRESS>]:32820
Jul 24 22:03:17 kktdr mopidy[924152]: ERROR    2024-07-24 22:03:17,902 [924152:BandcampBackend-5 (_actor_loop)] mopidy_bandcamp
Jul 24 22:03:17 kktdr mopidy[924152]:   Bandcamp failed to scrape "https://nodey.bandcamp.com/album/vinasounds-vol1"
Jul 24 22:03:17 kktdr mopidy[924152]: Traceback (most recent call last):
Jul 24 22:03:17 kktdr mopidy[924152]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy_bandcamp/library.py", line 312, in lookup
Jul 24 22:03:17 kktdr mopidy[924152]:     resp = self.backend.bandcamp.scrape(url)
Jul 24 22:03:17 kktdr mopidy[924152]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 24 22:03:17 kktdr mopidy[924152]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy_bandcamp/bandcamp.py", line 77, in scrape
Jul 24 22:03:17 kktdr mopidy[924152]:     resp.raise_for_status()
Jul 24 22:03:17 kktdr mopidy[924152]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/requests/models.py", line 1024, in raise_for_status
Jul 24 22:03:17 kktdr mopidy[924152]:     raise HTTPError(http_error_msg, response=self)
Jul 24 22:03:17 kktdr mopidy[924152]: requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://nodey.bandcamp.com/album/vinasounds-vol1

Thing is, search is also broken for some reason:
Jul 24 22:10:36 kktdr mopidy[930417]: ERROR    2024-07-24 22:10:36,183 [930417:Core-10 (_actor_loop)] mopidy.core.library
Jul 24 22:10:36 kktdr mopidy[930417]:   FileBackend backend returned bad data: Expected a SearchResult instance, not []
Jul 24 22:10:36 kktdr mopidy[930417]: ERROR    2024-07-24 22:10:36,185 [930417:Core-10 (_actor_loop)] mopidy.core.library
Jul 24 22:10:36 kktdr mopidy[930417]:   StreamBackend backend returned bad data: Expected a SearchResult instance, not []
Jul 24 22:10:36 kktdr mopidy[930417]: ERROR    2024-07-24 22:10:36,313 [930417:BandcampBackend-5 (_actor_loop)] mopidy_bandcamp
Jul 24 22:10:36 kktdr mopidy[930417]:   Bandcamp failed to search.
Jul 24 22:10:36 kktdr mopidy[930417]: Traceback (most recent call last):
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy_bandcamp/library.py", line 411, in search
Jul 24 22:10:36 kktdr mopidy[930417]:     resp = self.backend.bandcamp.search(q)
Jul 24 22:10:36 kktdr mopidy[930417]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy_bandcamp/bandcamp.py", line 183, in search
Jul 24 22:10:36 kktdr mopidy[930417]:     js = self._get(f"{self.BASE_URL}/fuzzysearch/1/app_autocomplete?q={query}")
Jul 24 22:10:36 kktdr mopidy[930417]:          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy_bandcamp/bandcamp.py", line 57, in _get
Jul 24 22:10:36 kktdr mopidy[930417]:     resp.raise_for_status()
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/requests/models.py", line 1024, in raise_for_status
Jul 24 22:10:36 kktdr mopidy[930417]:     raise HTTPError(http_error_msg, response=self)
Jul 24 22:10:36 kktdr mopidy[930417]: requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://bandcamp.com/api/fuzzysearch/1/app_autocomplete?q=nodey
Jul 24 22:10:36 kktdr mopidy[930417]: ERROR    2024-07-24 22:10:36,314 [930417:Core-10 (_actor_loop)] mopidy.core.library
Jul 24 22:10:36 kktdr mopidy[930417]:   BandcampBackend backend caused an exception.
Jul 24 22:10:36 kktdr mopidy[930417]: Traceback (most recent call last):
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy/core/library.py", line 17, in _backend_error_handling
Jul 24 22:10:36 kktdr mopidy[930417]:     yield
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy/core/library.py", line 330, in search
Jul 24 22:10:36 kktdr mopidy[930417]:     result = future.get()
Jul 24 22:10:36 kktdr mopidy[930417]:              ^^^^^^^^^^^^
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/pykka/_threading.py", line 68, in get
Jul 24 22:10:36 kktdr mopidy[930417]:     raise exc_value
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/pykka/_actor.py", line 238, in _actor_loop_running
Jul 24 22:10:36 kktdr mopidy[930417]:     response = self._handle_receive(envelope.message)
Jul 24 22:10:36 kktdr mopidy[930417]:                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/pykka/_actor.py", line 349, in _handle_receive
Jul 24 22:10:36 kktdr mopidy[930417]:     return callee(*message.args, **message.kwargs)
Jul 24 22:10:36 kktdr mopidy[930417]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 24 22:10:36 kktdr mopidy[930417]:   File "/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/lib/python3.12/site-packages/mopidy_bandcamp/library.py", line 414, in search
Jul 24 22:10:36 kktdr mopidy[930417]:     if "results" in resp:
Jul 24 22:10:36 kktdr mopidy[930417]:                     ^^^^
Jul 24 22:10:36 kktdr mopidy[930417]: UnboundLocalError: cannot access local variable 'resp' where it is not associated with a value

When I curl 'https://bandcamp.com/api/fuzzysearch/1/app_autocomplete?q=nodey' it works.

I'm at a loss why mopidy gets rejected while curl doesn't.

Both requests aren't equivalent. Mopidy-Bandcamp adds headers (a User-Agent header and a Cookie header with value read from the configuration identity=...). You can add those informations to Curl command if you want to reproduce the problem out of Mopidy-Bandcamp.

I see, I tried:
curl -s -H 'Cookie: identity=7%09mdpI1%2FZkCCVv%2FWr3upQRUIUtCSfreKLp8muUidVb0cQ%3D%09%7B%22id%22%3A3654361541%2C%22ex%22%3A0%7D' -H 'User-Agent: Mopidy-Bandcamp/v1.1.5' https://bandcamp.com/api/fuzzysearch/1/app_autocomplete\?q\=nodey

And this return proper JSON results and 200 OK.

How did you checked Mopidy's config? By running sudo mopidyctl config (or mopidy config if not running as a systemd unit)?

I did systemctl cat mopidy to inspect what it was started with, which gave me:
# /etc/systemd/system/mopidy.service
[Unit]
After=network-online.target sound.target
Description=mopidy music player daemon
Wants=network-online.target network-online.target

[Service]
...
ExecStart=/nix/store/xdx2cz72p48yvrh7qr7pqi2abv0z49p9-mopidy-with-extensions-3.4.2/bin/mopidy --config /nix/store/2gpffwrzsc8q3q1z29w76h8gyz107nn2-mopidy.conf
User=mopidy

[Install]
WantedBy=multi-user.target

and then I simply inspected the file at /nix/store/2gpffwrzsc8q3q1z29w76h8gyz107nn2-mopidy.conf

same here, NixOS, too. curl with identity cookie works and returns JSON, mopidy gets 403. Tested with https://bandcamp.com/api/fan/2/collection_summary
It worked some weeks ago.
Is Bandcamp blocking something recently? I wonder how to reproduce outside mopidy.

Maybe a missing "Accept" header? I'll test.

no, accept-header does not matter. it even succeeds using openssl s_client. It still fails with python3.11 inside mopidy. Did not test with python outside mopidy yet.

maybe rather a bug in mopidy httpclient? But I'm still at 3.4.2

I went back to ~6 months back nixpkgs (for mopidy, mopidyPackages and all extensions), before the switch to mopidy 3.4.2, and it still gives the same error. I'm pretty sure it used to work correctly then.

I'm not able to reproduce it outside mopidy. curl, openssl s_client and even python httpclient get a result of 200 with exact the same request parameters, which are
GET /api/fan/2/collection_summary HTTP/1.1
Host: bandcamp.com
User-Agent: Mopidy-Bandcamp/1.1.5 Mopidy/3.4.2 CPython/3.11.9
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
Cookie: identity=7%09xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%7D

I even checked it by redirecting the request to an own server.
I'm not fluent enough in python for debugging what exactly is happening. I wonder if this is a nixos issue, a python issue or a bandcamp issue.

@woffs I am not convinced it's a Mopidy-Bandcamp issue since visiting my own Bandcamp collection through Iris or Argos works quite well here.
matthias@argos:~ $ python -m pip freeze | grep -i mopidy
Mopidy==3.4.2
Mopidy-Bandcamp==1.1.5
Mopidy-InternetArchive==3.0.1
Mopidy-Iris @ file:///home/matthias/T%C3%A9l%C3%A9chargements/Mopidy-Iris-3.69.3.tar.gz
Mopidy-Listenbrainz==0.2.1
Mopidy-Local==3.2.1
Mopidy-Podcast==3.0.1
Mopidy-SomaFM==2.0.2
matthias@argos:~ $ python --version
Python 3.11.2
matthias@argos:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

even python httpclient get a result of 200

I was wrong, I re-tested with "python requests" using Debian and using NixOS, and the same query gets 403 with NixOS and 200 with Debian. The test query is simply
request("GET","https://bandcamp.com/api/fan/2/collection_summary")
and the good result should be 200 and response text {"error":true,"error_message":"must be logged in"}
The bad result is 403 and
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    <title>403 Forbidden</title>

Error 403 Forbidden

Forbidden

Error 54113

Details: cache-fra-etou8220062-FRA<PHONE_NUMBER><PHONE_NUMBER>

Varnish cache server

NixOS 23.05 works, NixOS 23.11 does not. Bandcamp definitely did change something, but I'll bisect what change in python packaging relates to that.

git-bisect states that update of python-urllib3 from 1.26.16 to 2.0.4 https://github.com/NixOS/nixpkgs/commit/6beb683e972947a36ab08bad407b9861388524fc was the bad commit. So now we know how to workaround on NixOS, we have to bisect urllib3 to find out what changed

Hello! urllib3 developer here. Bandcamp.com weirdly requires the TLS cipher suites that are used in urllib3 1.26.x, even if it does not use them. Here's the workaround to continue using urllib3 2.x: https://github.com/urllib3/urllib3/issues/3439#issuecomment-2306400349

based on what @pquentin says I have a workaround with https://gist.github.com/woffs/083f57f6cd0f4bfe49a6e97e1eb2ed60
I am not experienced with python though, so maybe someone wants to beautify this, but at least it works well.


Allow to decrease and increase take, add tests

This PR is similar to a closed now PR#313.
Added:

Extrinsic decrease_take in subtensor pallet
Extrinsic increase_take in subtensor pallet
Extrinsic sudo_set_tx_rate_limit_delegate_take in admin-utils pallet
Separate rate limit logic for increasing delegate take (decreasing is not rate limited)
Unit tests for decreasing and increasing take in misc. corner cases

This PR closes https://github.com/opentensor/subtensor/issues/314

Tests passed locally, this is good to go.

Testing on the local net is done with a combination of btcli (for setting up the network and delegates) and Polkadot AppsUI (for changing takes and admin bounds for takes - min and max). All tests passed.
Start a nerwork:
./scripts/localnet.sh

btcli:
### Create subnet, register, become delegate:
btcli root register --subtensor.network <IP_ADDRESS>:9946
btcli s create --subtensor.network <IP_ADDRESS>:9946
btcli s list --subtensor.network <IP_ADDRESS>:9946
btcli s register --subtensor.network <IP_ADDRESS>:9946
# nominate
btcli r nominate --subtensor.network <IP_ADDRESS>:9946
# show delegates and their takes
btcli r list_delegates --subtensor.network <IP_ADDRESS>:9946

Polkadot Apps UI:
1. Increase take -> InvalidTake error
2. Decrease take to 17% -> ok
3. Sudo set minimum take to 10000 (15.3%) -> ok
4. Decrease take to 9999 -> InvalidTake
5. Decrease take to 10000 -> ok
6. Increase take to 10001 -> ok
7. Increase take to 20000 -> InvalidTake
8. Sudo set maximum take to 20000 -> ok
9. Increase take to 20000 -> TxRateLimitExceeded (as expected)


Implement KeyVault

Created dumpling keyvault
Received certificate from //ssladmin
[internal] All secrets are in the keyvault
Current issue I am working through : failing to retrieve token with our current certificate.
Tested end to end
copying updates over from work scripts
Added Triage DB string to key vault
Upgraded/Consolidated many nuget packages
Added BCL Build Tools to a few projects (build tools demanded it)
Leveraging CloudConfigurationManager for keyvault's client id and client secret.
Changing cloud configuration back to just deploying app services - This is because we're moving away from this big of a cloud role, and instead we'll just be a single web server and using Helix as our backend.
Fixes for certificate - Namely we will pull the certificate out of Personal\Current User instead (as this is where Azure places the certificates that we upload).
DumplingLib requires that certificate information be passed in now, rather than trying to take a dependency on CloudManagementSettings.
Configured certificates for worker role
was testing some APIs and they found some config names that were not initialized properly.
Added some PowerShell scripts to help manipulate secrets in KeyVault.

👍


feat(MOPLAT-535): Add offline sync support

This PR resolves MOPLAT-535
Description
WIP
Example on how to add a syncable query end-to-end:

artistTabsQuery

PR Checklist

[ ] I tested my changes on iOS and Android.
[ ] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Need help with something? Have a look at our docs, or get in touch with us.

one more thing, if i remove all the cache, and then open the app, login, and not run the sync, then I get no data displayed in the artist list 🤔

Fails

:no_entry_sign:

Please use useSystemQueryLoader instead of useLazyLoadQuery. This guards against queries being executed when offline. See:

src/app/relay/useSystemQueryLoader.ts

  Generated by :no_entry_sign: dangerJS against 174739f6a07b990fe8b515e104c1c778eb4f16e4

Merging per slack convo with @pvinis! 🟢 🟢 🟢


⚠ GitLab Server has degraded performance

In aa2f8be, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 6242 ms

Resolved: GitLab Server performance has improved in 8e938a4.


Add animations for open / close

Should be configurable - on / off
Animation itself should be configurable - preferably by overriding CSS animation

#goodnessSquad


Fix error response for aca in 2024-03-01

Choose a PR Template
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.

same with https://github.com/Azure/azure-rest-api-specs/pull/28244

/azp run


Can't make indentation work as expected (nvim v0.3.0-dev)

Hello, I've been trying without success to get indentation working with haskell-vim.
First, I tried using vim-plug. Next, I tried Pathogen and switched out my init.vim for a minimal one containing the following:
set sw=2 ts=2 sts=2 expandtab
syntax on
filetype plugin indent on
execute pathogen#infect()

With this selection of code from a Haskell file:
testIndent :: [String]
testIndent = [ "hello"
  ,"wat"
  ,"goodbye" ]

testWhere f = g f
  where g :: Int -> Int
   g x = 2*x

data Foo
  = Foo
  { foo :: Int
  , bar :: Char
  , baz :: Int
} deriving (Eq, Ord)

I got the same result with both methods when indenting with =:
testIndent :: [String]
testIndent = [ "hello"
  ,"wat"
    ,"goodbye" ]

testWhere f = g f
  where g :: Int -> Int
   g x = 2*x

data Foo
  = Foo
    { foo :: Int
  , bar :: Char
  , baz :: Int
    } deriving (Eq, Ord)

This doesn't seem like correct behaviour. I double-checked set indentexpr and it returns GetHaskellIndent(). Is there a configuration step I'm missing?

I've reinstalled the latest version and tested this again and those examples seem to work fine now.


Document re_replace

@vpetrovykh, can you please check if we can close this one now.

Looks like this was covered by #39, closing now.


Using RenderDoc with current spirv-builder design is hard

Currently, since we rely on an environment variable to actually transmit the compiled spirv, we also rely on cargo to be the environment actually running the executable.  When debugging, renderdoc is very useful but we'd need to actually manually copy-paste the compiled spirv into an env variable within renderdoc's run environment in order for it to work properly.
I think spitting out an intermediate file rather than using environment variables would be preferable here.

Could you explain the problem RenderDoc is having? I used it yesterday on the project and other then having to manually patch out the VariablePointer capability (in the compiler, my RenderDoc version didn't support it) I could debug our shaders as SPIR-V just fine, but maybe I'm missing something?

My impression is that the SpirvBuilder does emit a file, specifically into target/spirv-unknown-unknown/release/[shader_name].spv

Could you explain the problem RenderDoc is having? I used it yesterday on the project and other then having to manually patch out the VariablePointer capability or the Vulkan memory model (in the compiler, my RenderDoc version didn't support it) I could debug our shaders as SPIR-V just fine, but maybe I'm missing something?

hm, I didn't actually try it because of my mental model of how env!() works but now that I think about it, that's a compile time macro and so it actually is baking the shader into the binary, so it should work perfectly fine. So, nvm, gonna close this :D


[5.10][Release Notes] Swift 5.10 closes all known holes in compile-time strict concurrency checking.

Explanation: Swift 5.10 closes all known holes in the static data-race safety programming model. This change adds this milestone in a release note in CHANGELOG.md and improves the other 5.10 concurrency release notes.
Scope: None.
Risk: None.
Testing: N/A
Main branch PR: https://github.com/apple/swift/pull/70934

@swift-ci please test


fix slow unstable nix

resolves #648

I'll leave as draft for now as there could be something I'm overlooking, and at the least I'd like the environment calls to only be called when using unstable nix.

@kamadorueda


Implementation of OTel SpanBuilder API

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#911
#910
#930  👈
#925
#909
#919
#918
#917
#908
#907
#906
#903 : 1 other dependent PR (#867 )
#902
#897
#896
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on  Graphite


Add a function to truncate NWB ElectricalSeries.

Just for local files.

Can you change the input "seconds" to [start_second, end_second]? This way, the function can break down a long recording to smaller chunks. For trimming, we just set the "start_second" to the desired starting point and "end_second" to the end of the recording. We can use ":" to indicate the end of the recording since user doesn't need to know the recording length.

@surygeng Breaking up an NWB file into smaller files sounds like a different function, and I think probably a different PR from this one?


Nautobot container get OOMKilled

Good morning everyone,
I recently began working on a proof of concept (PoC) for Nautobot and was tasked with installing it on our Kubernetes cluster. Unfortunately, we encountered an issue with the Nautobot container being OOMKilled by Kubernetes when starting the chart. Specifically, the containers for the Nautobot application ("default") were consistently terminated due to memory limits.
To address this, we deployed additional Kubernetes nodes with more memory, but the issue persisted. Eventually, we removed the resource limit of 8704M, and the application finally started. However, it exceeded the previously set memory limit:
kubectl top pod
NAME                                               CPU(cores)   MEMORY(bytes)
nautobot-***-celery-beat-c57dddd89-8pfh6      1m           178Mi
nautobot-***-celery-default-bb8697c45-62kgj   2m           1290Mi
nautobot-***-celery-default-bb8697c45-7259m   2m           1319Mi
nautobot-***-default-66f6b4675f-zl42k         378m         8520Mi
nautobot-***-postgresql-0                     13m          63Mi
nautobot-***-redis-master-0                   21m          8Mi

We were quite surprised by this outcome. To be fair, Nautobot has now become the most memory-intensive application on our cluster. Additionally, the pods do not seem to release this memory after startup. Is this expected behavior? We were under the impression that Nautobot was a relatively lightweight application, and these results have left us puzzled.

The default Nautobot application requests:
300m CPU (Per Pod) * 2 Pods
1.2G RAM (Per Pod) * 2 Pods

from official website
When digging a bit deeper, we determined that the processes responsible for the high memory usage were uWSGI and its forks. Is there any way to control this? Tweaking the processes and threads parameters didn't change anything.
Any insights or suggestions would be greatly appreciated.
Best regards.

Hi,
Thank you for your response @jdrew82 . I reviewed the linked documentation and, as suggested, attempted to reduce the concurrency setting for Celery instances. I applied the following configuration in the Helm chart:
celery:
  # -- Enables the default Celery Worker for Nautobot
  enabled: true

  # -- [[ref](https://docs.nautobot.com/projects/core/en/stable/administration/celery-queues/#concurrency-setting)]Concurrency Setting (0: use the default which is the number of CPUs available on your system)<sup>[2](#notes)</sup>
  concurrency: 16

I also tested with concurrency values of 8 and 2. However, these adjustments had no impact on the memory usage of the nautobot-supersecretname-default pod.
Here's a little more detail that might help with troubleshooting.
When deploying Nautobot using the default Helm chart (with the replicaCount reduced to 1 and no other changes to resource requests, limits, or configuration), most of the pods start successfully, except for the Nautobot application pod (nautobot-supersecretname-default). The pod consistently encounters OOMKilled errors. Below are the logs and resource details:
kubectl get pods
NAME                                               READY   STATUS      RESTARTS      AGE
nautobot-supersecretname-celery-beat-c57dddd89-8pfh6      1/1     Running     0             23h
nautobot-supersecretname-celery-default-bb8697c45-62kgj   1/1     Running     0             23h
nautobot-supersecretname-celery-default-bb8697c45-7259m   1/1     Running     0             23h
nautobot-supersecretname-default-67b55dd56c-rjtnk         0/1     OOMKilled   4 (51s ago)   2m40s
nautobot-supersecretname-postgresql-0                     1/1     Running     0             23h
nautobot-supersecretname-redis-master-0                   1/1     Running     0             23h

kubectl logs nautobot-supersecretname-default-67b55dd56c-rjtnk -p
Defaulted container "nautobot" out of: nautobot, nautobot-init (init)
[uWSGI] getting INI configuration from /opt/nautobot/uwsgi.ini
[uwsgi-static] added mapping for /static => /opt/nautobot/static
*** Starting uWSGI 2.0.23 (64bit) on [Tue Aug 27 13:22:21 2024] ***
compiled with version: 12.2.0 on 08 July 2024 22:01:50
os: Linux-5.15.0-106.131.4.el9uek.x86_64 #2 SMP Fri Sep 22 18:04:33 PDT 2023
nodename: nautobot-supersecretname-default-67b55dd56c-rjtnk
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory: /opt/nautobot
detected binary path: /usr/local/bin/python3.11
!!! no internal routing support, rebuild with pcre support !!!
your memory page size is 4096 bytes
detected max file descriptor number:<PHONE_NUMBER>
building mime-types dictionary from file /etc/mime.types...1545 entry found
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on <IP_ADDRESS>:8080 fd 11
uWSGI http bound on <IP_ADDRESS>:8443 fd 12
uwsgi socket 0 bound to TCP address <IP_ADDRESS>:44813 (port auto-assigned) fd 10
Python version: 3.11.9 (main, Jul  3 2024, 00:12:48) [GCC 12.2.0]
--- Python VM already initialized ---
Python main interpreter initialized at 0x7f761be78658
python threads support enabled
your server socket listen backlog is limited to 128 connections
your mercy for graceful operations on workers is 60 seconds
mapped 333504 bytes (325 KB) for 6 cores
*** Operational MODE: preforking+threaded ***
13:22:21.825 INFO    nautobot :
  Nautobot initialized!
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x7f761be78658 pid: 1 (default app)
spawned uWSGI master process (pid: 1)
spawned uWSGI worker 1 (pid: 9, cores: 2)
spawned uWSGI worker 2 (pid: 10, cores: 2)
13:22:21.858 INFO    nautobot.core.wsgi :
  Closing existing DB and cache connections on worker 1 after uWSGI forked ...
spawned uWSGI worker 3 (pid: 12, cores: 2)
13:22:21.860 INFO    nautobot.core.wsgi :
  Closing existing DB and cache connections on worker 2 after uWSGI forked ...
13:22:21.861 INFO    nautobot.core.wsgi :
  Closing existing DB and cache connections on worker 3 after uWSGI forked ...
spawned uWSGI http 1 (pid: 14)

kubectl describe pod nautobot-supersecretname-default-67b55dd56c-rjtnk
Name:             nautobot-supersecretname-default-67b55dd56c-rjtnk
Namespace:        nautobot-v2-1-3
Priority:         0
Service Account:  nautobot-supersecretname
Node:             si-kubenode05/<IP_ADDRESS>
Start Time:       Tue, 27 Aug 2024 15:18:13 +0200
Labels:           app.kubernetes.io/component=nautobot-default
                  app.kubernetes.io/instance=nautobot-supersecretname
                  app.kubernetes.io/managed-by=Helm
                  app.kubernetes.io/name=nautobot
                  app.kubernetes.io/version=2.2.7
                  helm.sh/chart=nautobot-2.1.3
                  pod-template-hash=67b55dd56c
Annotations:      <none>
Status:           Running
SeccompProfile:   RuntimeDefault
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/nautobot-supersecretname-default-67b55dd56c
Init Containers:
  nautobot-init:
    Container ID:  containerd://3d0968b366e9b627cd1bb1f26e4b05cb1ab462a3e0286948ab5a0106c8a8a7d4
    Image:         ghcr.io/nautobot/nautobot:2.2.7-py3.11
    Image ID:      ghcr.io/nautobot/nautobot@sha256:6b936558dd5e7368b2556eae4725f053346cfa802835f5076da14281d29c5f03
    Port:          <none>
    Host Port:     <none>
    Args:
      echo
      Nautobot Initialization Done
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Tue, 27 Aug 2024 15:18:14 +0200
      Finished:     Tue, 27 Aug 2024 15:18:45 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  8704M
    Requests:
      cpu:     300m
      memory:  1Gi
    Environment Variables from:
      nautobot-supersecretname-env  ConfigMap  Optional: false
      nautobot-supersecretname-env  Secret     Optional: false
    Environment:
      NAUTOBOT_DB_PASSWORD:     <set to the key 'password' in secret 'nautobot-supersecretname-postgresql'>      Optional: false
      NAUTOBOT_REDIS_PASSWORD:  <set to the key 'redis-password' in secret 'nautobot-supersecretname-redis'>     Optional: false
      NAUTOBOT_SECRET_KEY:      <set to the key 'NAUTOBOT_SECRET_KEY' in secret 'nautobot-supersecretname-env'>  Optional: false
    Mounts:
      /opt/nautobot/git from git-repos (rw)
      /opt/nautobot/static from nautobot-static (rw)
      /opt/nautobot/uwsgi.ini from nautobot-config (rw,path="uwsgi.ini")
Containers:
  nautobot:
    Container ID:  containerd://f6f18a989142bc54aeafed5f865fb9ccd58a83cd718d8eeb1787d12b8a428b48
    Image:         ghcr.io/nautobot/nautobot:2.2.7-py3.11
    Image ID:      ghcr.io/nautobot/nautobot@sha256:6b936558dd5e7368b2556eae4725f053346cfa802835f5076da14281d29c5f03
    Ports:         8443/TCP, 8080/TCP
    Host Ports:    0/TCP, 0/TCP
    Command:
      nautobot-server
      start
      --ini
      /opt/nautobot/uwsgi.ini
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Tue, 27 Aug 2024 15:25:04 +0200
      Finished:     Tue, 27 Aug 2024 15:25:13 +0200
    Ready:          False
    Restart Count:  6
    Limits:
      cpu:     1
      memory:  8704M
    Requests:
      cpu:      300m
      memory:   1Gi
    Liveness:   exec [bash -c nautobot-server health_check] delay=15s timeout=10s period=15s #success=1 #failure=3
    Readiness:  http-get http://:http/health/ delay=15s timeout=5s period=10s #success=1 #failure=3
    Environment Variables from:
      nautobot-supersecretname-env  ConfigMap  Optional: false
      nautobot-supersecretname-env  Secret     Optional: false
    Environment:
      NAUTOBOT_K8S_COMPONENT:   nautobot-default
      NAUTOBOT_DB_PASSWORD:     <set to the key 'password' in secret 'nautobot-supersecretname-postgresql'>      Optional: false
      NAUTOBOT_REDIS_PASSWORD:  <set to the key 'redis-password' in secret 'nautobot-supersecretname-redis'>     Optional: false
      NAUTOBOT_SECRET_KEY:      <set to the key 'NAUTOBOT_SECRET_KEY' in secret 'nautobot-supersecretname-env'>  Optional: false
    Mounts:
      /opt/nautobot/git from git-repos (rw)
      /opt/nautobot/media from nautobot-media (rw)
      /opt/nautobot/static from nautobot-static (rw)
      /opt/nautobot/uwsgi.ini from nautobot-config (rw,path="uwsgi.ini")
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       False
  ContainersReady             False
  PodScheduled                True
Volumes:
  nautobot-static:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  nautobot-media:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  git-repos:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  nautobot-config:
    Type:        ConfigMap (a volume populated by a ConfigMap)
    Name:        nautobot-supersecretname-config
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason   Age                     From     Message
  ----     ------   ----                    ----     -------
  Normal   Pulling  7m26s                   kubelet  Pulling image "ghcr.io/nautobot/nautobot:2.2.7-py3.11"
  Normal   Pulled   7m25s                   kubelet  Successfully pulled image "ghcr.io/nautobot/nautobot:2.2.7-py3.11" in 481ms (481ms including waiting)
  Normal   Created  7m25s                   kubelet  Created container nautobot-init
  Normal   Started  7m25s                   kubelet  Started container nautobot-init
  Normal   Pulled   6m54s                   kubelet  Successfully pulled image "ghcr.io/nautobot/nautobot:2.2.7-py3.11" in 488ms (488ms including waiting)
  Normal   Pulled   6m44s                   kubelet  Successfully pulled image "ghcr.io/nautobot/nautobot:2.2.7-py3.11" in 480ms (480ms including waiting)
  Normal   Pulled   6m26s                   kubelet  Successfully pulled image "ghcr.io/nautobot/nautobot:2.2.7-py3.11" in 456ms (456ms including waiting)
  Normal   Pulling  5m46s (x4 over 6m54s)   kubelet  Pulling image "ghcr.io/nautobot/nautobot:2.2.7-py3.11"
  Normal   Created  5m46s (x4 over 6m53s)   kubelet  Created container nautobot
  Normal   Pulled   5m46s                   kubelet  Successfully pulled image "ghcr.io/nautobot/nautobot:2.2.7-py3.11" in 496ms (496ms including waiting)
  Normal   Started  5m45s (x4 over 6m53s)   kubelet  Started container nautobot
  Warning  BackOff  2m18s (x20 over 6m36s)  kubelet  Back-off restarting failed container nautobot in pod nautobot-supersecretname-default-67b55dd56c-rjtnk_nautobot-v2-1-3(58a5f0a1-0d46-4c0c-8279-03e75e05d49e)

With the default Helm configuration, the nautobot-default pod crashes with a memory limit of 8704M (~8308 MiB). Removing the memory limit allows the pod to start, but it then consumes significantly more memory (exceeding 8308 MiB). Here are the current result :
kubectl get pods
NAME                                               READY   STATUS    RESTARTS   AGE
nautobot-supersecretname-celery-beat-c57dddd89-8pfh6      1/1     Running   0          24h
nautobot-supersecretname-celery-default-bb8697c45-62kgj   1/1     Running   0          24h
nautobot-supersecretname-celery-default-bb8697c45-7259m   1/1     Running   0          24h
nautobot-supersecretname-default-66f6b4675f-rtthp         1/1     Running   0          61s
nautobot-supersecretname-postgresql-0                     1/1     Running   0          24h
nautobot-supersecretname-redis-master-0                   1/1     Running   0          24h

kubectl top pod
NAME                                               CPU(cores)   MEMORY(bytes)
nautobot-supersecretname-celery-beat-c57dddd89-pmvg8      1m           178Mi
nautobot-supersecretname-celery-default-d9c866796-flx92   2m           349Mi
nautobot-supersecretname-celery-default-d9c866796-hhhfv   2m           349Mi
nautobot-supersecretname-default-66f6b4675f-rtthp         560m         8802Mi
nautobot-supersecretname-postgresql-0                     18m          60Mi
nautobot-supersecretname-redis-master-0                   17m          8Mi

kubectl logs nautobot-supersecretname-default-66f6b4675f-rtthp
Defaulted container "nautobot" out of: nautobot, nautobot-init (init)
[uWSGI] getting INI configuration from /opt/nautobot/uwsgi.ini
[uwsgi-static] added mapping for /static => /opt/nautobot/static
*** Starting uWSGI 2.0.23 (64bit) on [Tue Aug 27 14:12:23 2024] ***
compiled with version: 12.2.0 on 08 July 2024 22:01:50
os: Linux-5.15.0-106.131.4.el9uek.x86_64 #2 SMP Fri Sep 22 18:04:33 PDT 2023
nodename: nautobot-supersecretname-default-66f6b4675f-rtthp
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory: /opt/nautobot
detected binary path: /usr/local/bin/python3.11
!!! no internal routing support, rebuild with pcre support !!!
your memory page size is 4096 bytes
detected max file descriptor number:<PHONE_NUMBER>
building mime-types dictionary from file /etc/mime.types...1545 entry found
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on <IP_ADDRESS>:8080 fd 11
uWSGI http bound on <IP_ADDRESS>:8443 fd 12
uwsgi socket 0 bound to TCP address <IP_ADDRESS>:41027 (port auto-assigned) fd 10
Python version: 3.11.9 (main, Jul  3 2024, 00:12:48) [GCC 12.2.0]
--- Python VM already initialized ---
Python main interpreter initialized at 0x7fea32876658
python threads support enabled
your server socket listen backlog is limited to 128 connections
your mercy for graceful operations on workers is 60 seconds
mapped 333504 bytes (325 KB) for 6 cores
*** Operational MODE: preforking+threaded ***
14:12:23.688 INFO    nautobot :
  Nautobot initialized!
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x7fea32876658 pid: 1 (default app)
spawned uWSGI master process (pid: 1)
spawned uWSGI worker 1 (pid: 9, cores: 2)
14:12:23.722 INFO    nautobot.core.wsgi :
  Closing existing DB and cache connections on worker 1 after uWSGI forked ...
spawned uWSGI worker 2 (pid: 10, cores: 2)
14:12:23.724 INFO    nautobot.core.wsgi :
  Closing existing DB and cache connections on worker 2 after uWSGI forked ...
spawned uWSGI worker 3 (pid: 12, cores: 2)
14:12:23.726 INFO    nautobot.core.wsgi :
  Closing existing DB and cache connections on worker 3 after uWSGI forked ...
spawned uWSGI http 1 (pid: 14)

This memory usage is consistant and is never released :

We went on the node and determined that the involved process in the very high memory usage are the nautobot-server process.

We are concerned about the high memory usage of the Nautobot pod and would like to know if this is expected behavior. If so, could you please clarify why it differs so significantly from the low resource requirements mentioned in the documentation?
Thanks again for the help,
Best regards.

@AxFrancois Thank you for the information. That helps clear things up a bit. First, I want to start with stating that the limits and requests that you see in the Helm chart are just examples and are NOT recommended values. As every situation is unique and your usage patterns will vary from others, it's going to be up to you to determine what are reasonable values for those. As for why so much memory is used, I'd have to assume it's due to the fact that you have your concurrency set to 16. That'd be the nautobot-server process that you're seeing as the command to start Celery is a nautobot-server command. Each worker process will reserve a bit of memory when they first start.
In addition, in our standard deployments on a VM with all services residing on a single VM we suggest resources of 4 vCPU and 16GB of memory. That is for a basic installation with very little data in it. As you start to add in more data and use the application more your resources will need to be adjusted. Also, bear in mind that depending upon which Apps you have installed the resource usage can be high too. For example, Golden Config and SSoT can both use a lot of memory.

Hi,
Thanks again for your response. I finally figured out what the issue was!
I kept searching for the cause of the high memory usage with uWSGI and found these two issues:

https://github.com/TomBursch/kitchenowl/issues/199
https://github.com/unbit/uwsgi/issues/2299

In fact, right at the start of the logs, the pod reported: "detected max file descriptor number:<PHONE_NUMBER>." The issues recommended setting this value to 1048576. Following the suggestions, I updated the Nautobot container command to the following:
  command:
    - "nautobot-server"
    - "start"
    - "--ini"
    - "/opt/nautobot/uwsgi.ini"
    - "--max-fd"
    - "1048576"

After upgrading the chart, the memory usage of the nautobot-supersecretname-default pod dropped significantly right away!
NAME                                                CPU(cores)   MEMORY(bytes)
nautobot-supersecretname-celery-beat-6cbd7f6d67-rd94b      1m           179Mi
nautobot-supersecretname-celery-default-74fcddfd55-67btq   2m           1299Mi
nautobot-supersecretname-celery-default-74fcddfd55-k6cpb   2m           1305Mi
nautobot-supersecretname-default-7cc779466f-79jbh          387m         635Mi
nautobot-supersecretname-default-7cc779466f-stqtk          407m         432Mi
nautobot-supersecretname-postgresql-0                      14m          59Mi
nautobot-supersecretname-redis-master-0                    15m          8Mi

nautobot-supersecretname-default uses less than 700Mi instead of the previous 8/9 Gi !
Thanks again for the help,
Best regards.


Tutorial does not work due to outdated npm depenencies

Describe the Bug
The tutorial breaks in the npm run start step:
$ npm start

><EMAIL_ADDRESS>start
> webpack-dev-server

(node:20541) [DEP0111] DeprecationWarning: Access to process.binding('http_parser') is deprecated.
(Use `node --trace-deprecation ...` to show where the warning was created)
ℹ ｢wds｣: Project is running at http://localhost:8080/
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: Content not from webpack is served from /home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www
node:internal/crypto/hash:71
  this[kHandle] = new _Hash(algorithm, xofLen);
                  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:71:19)
    at Object.createHash (node:crypto:133:10)
    at module.exports (/home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/webpack/lib/NormalModule.js:471:10)
    at /home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/webpack/lib/NormalModule.js:503:5
    at /home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/webpack/lib/NormalModule.js:358:12
    at /home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at Array.<anonymous> (/home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
    at Storage.finished (/home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
    at /home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
    at /home/fabian/git/RustExperiments/GuiExperiments/wasm-tutorial/www/node_modules/graceful-fs/graceful-fs.js:78:16
    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v18.15.0

Steps to Reproduce
Follow the tutorial steps up to the serving locally, when the dev server is started for the first time.
If applicable, add a link to a test case (as a zip file or link to a repository we can clone).
Expected Behavior
The step should succeed.
Actual Behavior
See error above.
Additional Context
The reason is most likely that the dependencies in the package.json are of the web app template are extremely outdated. Trying to update them with npx npm-check -u suggest major version jumps for all dependencies:

But trying to update them fails with an internal dependency conflict that I have yet to understand...

I think there's a way to make it work, you can export this as an environment variable NODE_OPTIONS=--openssl-legacy-provider and then run npm run start or npm start it seemed to have worked for me.

@Unic-X how did you manage to find the solution?. It worked for me as well.

@MariusDrulea, I also looked up somewhere i don't remember correctly, but i think this _Hash functions is the problem, and after looking for a bit i found out using --legacy version for openssl might fix it

This bug is in create-wasm-app rather than this tutorial.
See related issue on that repo: https://github.com/rustwasm/create-wasm-app/issues/214


Add react native support

Codecov Report

Merging #15 into master will decrease coverage by 10.02%.
The diff coverage is 8%.

@@             Coverage Diff             @@
##           master      #15       +/-   ##
===========================================
- Coverage   40.29%   30.27%   -10.03%
===========================================
  Files           6        7        +1
  Lines         201      294       +93
  Branches       27       46       +19
===========================================
+ Hits           81       89        +8
- Misses        120      205       +85

Impacted Files
Coverage Δ

src/types.ts
100% <ø> (ø)
:arrow_up:

src/actions.ts
14.47% <12.5%> (-0.92%)
:arrow_down:

src/services/auth.ts
41.81% <33.33%> (-41.52%)
:arrow_down:

src/AsyncLocalStorage.ts
7.5% <5.12%> (ø)

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 a3e754c...1c67ec2. Read the comment docs.


Get back to 100% test coverage

Summary:
Changes local types of fileUUID and namespace to str, to check edge case where namespace or fileUUID resolved to "". (Cases where metadata_identifier is either ":", "VALIDNS:" or ":VALIDUUID"
Also extended testing of missing namespace
Returns test-coverage to 100%
Suggested reviewer(s):
Reviewer checklist:

[ ] The headers of all files contain a reference to the repository license
[ ] 100% test coverage of new code - meaning:

[ ] The overall test coverage increased or remained the same as before
[ ] Every function is accompanied with a test suite
[ ] Tests are both positive (testing that the function work as intended with valid data) and negative (testing that the function behaves as expected with invalid data, e.g., that correct exceptions are thrown)
[ ] Functions with optional arguments have separate tests for all options

[ ] Examples are supported by doctests
[ ] All tests are passing
[ ] All names (e.g., files, classes, functions, variables) are explicit
[ ] Documentation (as docstrings) is complete and understandable

The checklist is based on the S-ENDA conventions and definition of done (see General Conventions). The above points are not necessarily relevant to all contributions. In that case, please add a short explanation to help the reviewer.

this is of course !!VERY HIGH PRIORITY!!

https://app.codecov.io/gh/metno/discovery-metadata-catalog-ingestor 99.76% coverage


Named route not defined when using ->name() method

Laravel Version: 5.8.*
PHP Version: 7.2.*
Database Driver & Version:

Description:
When naming a route with ->name() method, this causes an error Route [home] not defined. when calling route('home');
Steps To Reproduce:
When named a route by name method like this:
Route::get('/', 'Controller@handle')->name('home');
and call route('home'); after that, make error: Route [home] not defined.;
because when naming a route with name() method, this method dont update $nameList of Illuminate\Routing\RouteCollection so when calling that route with rout() function, cant find it.

I use this method all the time and never experienced this.
Have you cleared all the cache using route:clear?

I use this method all the time and never experienced this.
Have you cleared all the cache using route:clear?

I found problem. i forget call parent::boot() when i extended base route serveice provider that causes removing route lookups after booting.

Please close the issue.


install: add missing directory chown

Re-factor the copy function chown into a function that can be re-used.
Fix bug where the group overwrote the user.
Add chown compatibility to follow GNU coreutils.
Reduce two chown calls to a single syscall only when needed.
Fixes #4361

Not sure how to test this though.  Can the CI/CD server change owners?  I assume this will break most test setups.
Manually tested for now.

Not sure how to test this though. Can the CI/CD server change owners? I assume this will break most test setups.

Passing thought: it's probably possible to chown/chrgp by running fakeroot cargo ... for the tests.  This probably requires re-organizing tests that must run in fakeroot to another test suite or something to that we don't require users running unit-tests to have fakeroot installed.

Thanks!


Add support for creating a new bucket

It would be nice to support the creation of a new bucket.

I have opened a working PR but currently i'm unsure about the api. Current implementation adds a Bucket.createBucket method.
const bucket = new S3Bucket({
  accessKeyID: Deno.env.get("AWS_ACCESS_KEY_ID")!,
  secretKey: Deno.env.get("AWS_SECRET_ACCESS_KEY")!,
  bucket: "test",
  region: "us-east-1",
  endpointURL: Deno.env.get("S3_ENDPOINT_URL"),
});

const { location } = await bucket2.createBucket({
  acl: "public-read-write",
});

Another idea would be to move the createBucket method to the S3Client class and instead of returning the CreateBucketResponse we could return the Bucket instance.
const s3 = new S3Client({
  accessKeyID: Deno.env.get("AWS_ACCESS_KEY_ID")!,
  secretKey: Deno.env.get("AWS_SECRET_ACCESS_KEY")!,
  region: "us-east-1",
  endpointURL: Deno.env.get("S3_ENDPOINT_URL"),
});

const bucket = await s3.createBucket("test", {
  acl: "public-read-write",
});

What do you think @lucacasonato?

I have moved the createBucket method to the S3 class now. I think it's a better place and this way we can create multiple buckets with the same s3 config.


Iterator value

The iterator.value test contains a single value.  Are there plans to change this to an array where the first item in array is the index and second item in the array is the value?  test/es6/generators-functionality.js

Sorry I didn't quite understand the question. Can you please clarify which test are you specifically asking about?

Closing due to lack of activity. Feel free to reopen if you think we should take some action.


[UX] - Account RA - Change all Asset pairs within same cat on click !

Also from bytmaster on issue #358

All FormattedPrice components should default to showing the price in the preferred orientation
Toggling the orientation of a formatted price toggles the preference
Toggling the market view toggles the preference.

Now, the question becomes can we reasonably allow a  user to set their preferred order per trading pair. Do we just make that passive so we remember their preference across all screens once they have selected it on one screen? Seems like the easiest way.

https://github.com/cryptonomex/graphene-ui/issues/415#issuecomment-159932192
+1


light gbm hangs when loading a model file in subprocess

Description
train two models in the main process and save them into two model files.
then use Multiprocessing.pool to load these two model files in subprocess, the subprocess will hang.
part of the stack trace by using pyrasite-shell is as below
File "simple_lgbm.py", line 77, in predict
x = lgb.Booster(model_file=file_name)
File ".../lightgbm/basic.py", line 2087, in init
_safe_call(_LIB.LGBM_BoosterCreateFromModelfile(
gdb shows more detail, the CreateBoosting function calls something like __kmp_api_GOMP_parallel_40_alias() and it hung at __kmp_suspend_64()
in light gbm FAQ, it mentioned that due to openmp bug, it could hang with multithreading and fork on linux. and suggest to use nthreads=1 to close multithreading. but setting nthreads=1 has no effect for lgb.Booster when loading model file.
is there a workaround or fix for this?
Reproducible example
the code is based on simple_example.py from light gbm repo.
# coding: utf-8
from pathlib import Path
from multiprocessing import get_context

import pandas as pd
from sklearn.metrics import mean_squared_error

import lightgbm as lgb

print('Loading data...')
# load or create your dataset
regression_example_dir = Path(__file__).absolute().parents[1] / 'regression'
df_train = pd.read_csv(str(regression_example_dir / 'regression.train'), header=None, sep='\t')
df_test = pd.read_csv(str(regression_example_dir / 'regression.test'), header=None, sep='\t')

y_train = df_train[0]
y_test = df_test[0]
X_train = df_train.drop(0, axis=1)
X_test = df_test.drop(0, axis=1)

# create dataset for lightgbm
lgb_train = lgb.Dataset(X_train, y_train)
lgb_eval = lgb.Dataset(X_test, y_test, reference=lgb_train)

# specify your configurations as a dict
params = dict(
    task='train',
    objective='regression',
    num_leaves=50,
    max_depth=6,
    n_jobs=10,
    min_data_in_leaf=100,
    feature_fraction=0.8,
    num_iterations=20,
    learning_rate=0.1,
    deterministic=True,
    metric=['rmse'],
    force_col_wise=True,
    verbose=-1
    )

print('Starting training...')
def train(file_name: str):
    # train
    gbm = lgb.train(params,
                lgb_train,
                num_boost_round=20,
                valid_sets=lgb_eval,
                callbacks=[lgb.early_stopping(stopping_rounds=5)])

    print('Saving model...')
    # save model to file
    gbm.save_model(file_name)

train('model1.txt')
train('model2.txt')

print('Starting predicting...')

def predict(file_name: str):
    # it hangs here
    x = lgb.Booster(model_file=file_name)
    y_pred = x.predict(X_test, num_iteration=x.best_iteration)
    rmse_test = mean_squared_error(y_test, y_pred) ** 0.5
    print(f'The RMSE of prediction is: {rmse_test}')

with get_context("fork").Pool(processes=2) as pool:
    for r in pool.imap_unordered(predict, ['model1.txt', 'model2.txt']):
        print(f'got result {r}')

Environment info
LightGBM version or commit hash:  4.0.0
Command(s) you used to install LightGBM
pip install lightgbm

Additional Comments

@assassin5615 Thanks for using LightGBM. Did you try setting the environment variable OMP_NUM_THREADS to 1?

in my environment,  OMP_NUM_THREADS is always 1 as I ran into other issues that requires set OMP_NUM_THREADS 1, so yes.

I also tried to print the value of OMP_NUM_THREADS in the script, it's 1 before calling train and prediction.


Performance issue when item placed at borders (X 0 position)

@donnysim Hey Donny! Are you still around? :-)


[DO NOT MERGE] PP-4822 Add text explaining $reference in email custom paragraph

Add some text to the page where the custom paragraph for email notification is configured, explaining that “$reference” will be replaced by the actual payment reference.

The build may fail because I had to reboot CI. Re-run it if it goes red.

@alexbishop1 I think we can close this PR?

closing due to lack of activity


Use runtime arguments in Divan benchmarks

The new args option greatly reduces compile times and is not limited to arrays/slices.

Thanks! And thanks for making Divan!


correct QueryDepositWithdrawResponse error id json mapping

@wocorpse thanks for your feedback, your pull request is approved and merged


typescript(vx-tooltip): re-write package in TypeScript

:rocket: Enhancements
This PR builds off of #488 which added TypeScript build support, and converts the @vx-tooltip package to TypeScript.
tooltip component depends on vx/bounds, so CI might be failing because of this. Closes #505.
Testing

[x] CI
[x] Generates .d.ts files

@williaster @hshoff @schillerk @milesj @kristw

@Rudeg FYI I updated the base branch to master, and fixed a conflict.


Fix wrong sa name in crb when psp is enabled

Fix what could certainly be called a typo in PR#3102 as serviceAccount is netchecker-agent and not netchecker-agent-hostnet

ci check this

/lgtm
/approve


Playing back private vimeo videos

[ ] Issue does not already exist

Expected behaviour
Authorization via app credits or playing back anyway if allowed
Actual behaviour
404 on requesting video via oembed
Environment

Browser: Chrome
Version:  Version 58.0.3029.110 (64-bit)
Operating System: OSX
Version: Latest

Players affected:

[ ] HTML5 Video
[ ] Vimeo

Steps to reproduce

provide private full link to the allowed for embedding vimeo video

Relevant links

Any chance this is being looked into or if there is a temporary workaround?

Hi, We are also interested in this

To my knowledge private vimeo videos are just /videoId/secretId
I also noticed on their Share -> iframe it puts the url as https://player.vimeo.com/video/videoId?h=secretId

It’s not documented, but it seems like this works when data-plyr-embed-id="[complete vimeo URL including id and hash]", but does not work with just data-plyr-embed-id="[id]/][hash]" —


add body-parser middleware for express

Adds the body-parser middleware to make POST requests to react-server.

 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.

woo!  thanks @mattiasewers 🚢 👍