text:
Bug: Argument --app causes ValueError

Description
A condition is missing for the case that app_path does not contain a colon.
Using Litestar app from env: 'invalid'
Traceback (most recent call last):
  File "/home/henry/miniconda3/envs/facefusion/bin/litestar", line 8, in <module>
    sys.exit(run_cli())
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/litestar/__main__.py", line 6, in run_cli
    litestar_group()
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/rich_click/rich_command.py", line 367, in __call__
    return super().__call__(*args, **kwargs)
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/rich_click/rich_command.py", line 151, in main
    with self.make_context(prog_name, args, **extra) as ctx:
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/litestar/cli/_utils.py", line 224, in make_context
    self._prepare(ctx)
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/litestar/cli/_utils.py", line 206, in _prepare
    env = ctx.obj = LitestarEnv.from_env(ctx.params.get("app_path"), ctx.params.get("app_dir"))
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/litestar/cli/_utils.py", line 112, in from_env
    loaded_app = _load_app_from_path(app_path)
  File "/home/henry/miniconda3/envs/facefusion/lib/python3.10/site-packages/litestar/cli/_utils.py", line 276, in _load_app_from_path
    module_path, app_name = app_path.split(":")
ValueError: not enough values to unpack (expected 2, got 1)

Either add a condition to _load_app_from_path or introduce a safe_split utility/helper.
URL to code causing the issue
No response
MCVE
litestar --app invalid

### Steps to reproduce

_No response_

### Screenshots

```bash
"![SCREENSHOT_DESCRIPTION](SCREENSHOT_LINK.png)"

Logs
No response
Litestar Version
2.13.0final0
Platform

[X] Linux
[ ] Mac
[ ] Windows
[ ] Other (Please specify in the description above)

[!NOTE]
While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.
Check out all issues funded or available for funding on our Polar.sh dashboard

If you would like to see an issue prioritized, make a pledge towards it!
We receive the pledge once the issue is completed & verified
This, along with engagement in the community, helps us know which features are a priority to our users.

This isn't really a bug. You're passing in an invalid value and are presented with a ValueError, which I think is appropriate. I'm assuming you're looking for a better error message here?

Yeah, something like "Invalid argument passed" instead of an exception.

authors: henryruhs provinzkraut


text:
(ui-frontend-implementation): Adding version label to the side-panel

UI-FRONTEND-IMPLEMENTATION
What happens:

Adding a Version Label to sidepanel of each chart/subchart

What you expected to happen:

The version label  will look like some thing like this :-
https://lh5.googleusercontent.com/yWVCEXflkDLpGqeqmkdXpK0Nssii_uvpAsvH0s3GQgSkKWgBlyI1VJ7qCEnDoNHXTAAcrTls--TQF85t38_koww8qRQsPI-dw_doTotQElp8WxNjTgrT3eJHmC8M7qxfWu49ow45gw

Anything else we need to know?:

Issue related to Repository : https://github.com/litmuschaos/charthub.litmuschaos.io

From where are you planning to read the version? Package.json?

@mkkhedawat we have to pick the version from the charts directory, parsing the yaml of the charts. The maintainer label has been implemented in a similar fashion.

Also @mkkhedawat don't forget to add this issue number in your PR, and add a link to your PR here as well.

@mkkhedawat are you working on this? Or can i take it up?

It seems that the Server API already have the version parameter. It's just the matter of modifying the component to show it up on UI

Hi @kmjayadeep, I will assign this task to you.

source: gharchive/issue

authors: aditya109 kmjayadeep mkkhedawat

repo: litmuschaos/litmus

license_type: permissive

license_source: github-api


text:
🛑 USTC Mirrors (Unicom) is down

In ec07dbb, USTC Mirrors (Unicom) (https://unicom.mirrors.ustc.edu.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: USTC Mirrors (Unicom) is back up in 0c28d05.

repo: littlekud/sites-status

license: MIT


text:
🛑 USTC Mirrors (Cmcc) is down

In 35b2ef9, USTC Mirrors (Cmcc) (https://cmcc.mirrors.ustc.edu.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: USTC Mirrors (Cmcc) is back up in 0aeb724 after 8 minutes.


text:
hal: what is the difference of flush and map in driver?

Hi,
The code is beautiful. 👍
I find in display driver, flush and map function are almost same code, just flush have a lv_flush_ready() called at end. So what is the different and when should use map/flush?
Thanks.

Hi,
Thank you! :)
Basically they do the same job. The only difference is disp_map() is used with LV_VDB_SIZE = 0 to  put  images to the display directly. lv_disp_flush() is used with LV_VDB_SIZE != 0 when buffered drawing is enabled to put the buffer's content to the display.
So both of them put a pixel map to the display. You can ask then why is there two functions to do the same task? The answer is because they have very different purpose and because lv_flush_ready()  is required in one case and not in the other. And I wasn't able to give an intuitive name which describes the two functionality at once. :P
If you have a good function name idea for the combined disp_map and disp_flush I'm yery open for it!

I see :) Thank you!
Another question I find yesterday
When I run it on my embed linux(580MHz MIPS), I find it is not that smooth as your youtube video when switch between "Write" and "List" and "Chart" label in the demo. First I thought it might be my device is render slow, I reduce its pixel width 16bits but still no luck..
After I run in my PC linux find same issue, it is 3.5GHz CPU, so I think it should not be the CPU speed problem. What the problem it is possible? I think the video device should be much slower than my device.

this is lvgl efficiency too [SLOW]. I try lvgl on  linux base on /dev/fb,the effect as you.
fix. don't  use AA （anti aliasing）. edit lv-conf.h .
ps. youtube video demo is do not use AA.
I also try ucgui on linux base on fb 90fps.
but lvgl only 20fps.
cpu 450MHz,ddr2 90MB
I dont try lvgl on stm32 with AA.
flush/map is  different is that flush cpu draw point,map use dma.
if use fb (on use space compile lvgl.so ) MAP mode unuse.it become more SLOW,about 10fps.
if lvgl run on linux driver that you can use map,use DMA draw point.
###################
和你一样我在linux环境基于/dev/fb[效果也很差]。
解决方法，不要用AA
顺带说一句。youtube的演示里就是没使用AA，也没有使用贴图。
我没有在stm32上具体移植过lvgl，不知道AA效果。
fluah和map模式的差别是，一个使用cpu绘图，一个使用dma。
用户空间使用 /dev/fb编译成lvgl.so，没必要使用map模式，效率低下，10fps
如果在驱动层可采样map模式，效果可能会好一些
来自 MEIZU MX
-------- 原始邮件 --------
发件人：Qin Wei notifications@github.com
时间：周日 2月25日 08:59
收件人：littlevgl/lvgl lvgl@noreply.github.com
抄送：Subscribed subscribed@noreply.github.com
主题：Re: [littlevgl/lvgl] hal: what is the difference of flush and map in driver? (#126)

I see :) Thank you!
Another question I find yesterday
When I run it on my embed linux(580MHz MIPS), I find it is not that smooth as your youtube video when switch between "Write" and "List" and "Chart" label in the demo. First I thought it might be my device is render slow, I reduce its pixel width 16bits but still no luck..
After I run in my PC linux find same issue, it is 3.5GHz CPU, so I think it should not be the CPU speed problem. What the problem it is possible? I think the video device should be much slower than my device.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/littlevgl/lvgl/issues/126#issuecomment-368273473

It is, after disable AA it is much faster. But it is not beautiful anymore :)

HI,
Please try the dev-5.1 branch and read this issue: #125 . I made a lot of update on anti-aliasing. Now it needs only very small extra rendering time. I'm very curious about your test results!
The LV_VDB_SIZE = 0 configuration is:

slower
lower quality (flickeering)
not supports some features(e.g. opacity)

So you should use the  buffered (LV_VDB_SIZE != 0) configuration. The unbuffered is useful only in some special cases.
Increasing the size of VDB also makes rendering faster. Play with it!

As the speed related thought were discussed about v5.1 in #125 I close this issue.
If you have other speed related questions pleas open a new issue for it!

authors: MenglongWu Vonger kisvegabor

repo: littlevgl/lvgl

license: mit

license_source: bigquery


text:
Issues with lv_led alignment and centering

I'm trying to do a simple front panel with a series of LEDs, each with a label above and below the LED (the top one identifying it, and the bottom one being an explanatory state), and while the LED appears to line up with the top label, I can't get the bottom label to line up with the LED.
Here's an example:
lv_obj_t * sensor2_label = lv_label_create(sensor_container, NULL);
lv_obj_align(sensor2_label, sensor1_label, LV_ALIGN_OUT_RIGHT_MID, 15, 00);
lv_label_set_text(sensor2_label, "Sensor 2");
lv_label_set_align(sensor2_label, LV_LABEL_ALIGN_LEFT);
lv_label_set_style(sensor2_label, &style_speedbox_label);

lv_obj_t * sensor2_led = lv_led_create(sensor_container, NULL);
lv_obj_set_size(sensor2_led, led_size, led_size);
lv_obj_align(sensor2_led, sensor2_label, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
lv_obj_set_style(sensor2_led, &style_led);
lv_led_on(sensor2_led);

lv_obj_t * sensor2_status = lv_label_create(sensor_container, NULL);
lv_label_set_align(sensor2_status, LV_LABEL_ALIGN_CENTER);
lv_obj_align(sensor2_status, sensor2_led, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
lv_label_set_text(sensor2_status, "OK");
lv_label_set_style(sensor2_status, &style_speedbox_label);

sensor2_led is centered below sensor2_label, but sensor2_status aligns well left of center.

@kaszeta Can you send a complete code snippet that can be reproduced independently on the PC simulator? The styles and sensor1_label are missing.

Let me see if I can make a minimal version of it.
In the meantime,
static lv_style_t style_speedbox_label;
lv_style_copy(&style_speedbox_label, &lv_style_pretty);
style_speedbox_label.text.font = &lv_font_dejavu_20;

static lv_style_t style_led;
lv_style_copy(&style_led, &lv_style_pretty_color);
style_led.body.radius = 12;
style_led.body.main_color = LV_COLOR_MAKE(0xff, 0x3f, 0x3f);
style_led.body.grad_color = LV_COLOR_MAKE(0xa0, 0x50, 0x50);
style_led.body.border.color = LV_COLOR_MAKE(0xfa, 0x0f, 0x00);
style_led.body.border.width = 2;

lv_obj_t * sensor1_label = lv_label_create(sensor_container, NULL);
lv_obj_align(sensor1_label, sensor_label, LV_ALIGN_OUT_BOTTOM_LEFT, 0, 10);
lv_label_set_text(sensor1_label, "Sensor 1");
lv_label_set_align(sensor1_label, LV_LABEL_ALIGN_CENTER);
lv_label_set_style(sensor1_label, &style_speedbox_label);

Okay, here's a minimal case that I've run in the pc simulator:
/*Create a style for the LEDs*/
        int led_size = 24;
	static lv_style_t style_led;
	lv_style_copy(&style_led, &lv_style_pretty_color);
	style_led.body.radius = 12;
	style_led.body.main_color = LV_COLOR_MAKE(0xff, 0x3f, 0x3f);
	style_led.body.grad_color = LV_COLOR_MAKE(0xa0, 0x50, 0x50);
	style_led.body.border.color = LV_COLOR_MAKE(0xfa, 0x0f, 0x00);
	style_led.body.border.width = 2;

	lv_obj_t * sensor1_label = lv_label_create(lv_scr_act(), NULL);
	lv_obj_align(sensor1_label, NULL, LV_ALIGN_IN_TOP_LEFT, 0, 10);
	lv_label_set_text(sensor1_label, "Sensor 1");
        lv_label_set_align(sensor1_label, LV_LABEL_ALIGN_CENTER);
        lv_label_set_style(sensor1_label, &style_speedbox_label);

	lv_obj_t * sensor1_led = lv_led_create(lv_scr_act(), NULL);
	lv_obj_set_size(sensor1_led, led_size, led_size);
        lv_obj_align(sensor1_led, sensor1_label, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
	lv_obj_set_style(sensor1_led, &style_led);
	lv_led_on(sensor1_led);

	lv_obj_t * sensor1_status = lv_label_create(lv_scr_act(), NULL);
	lv_obj_align(sensor1_status, sensor1_led, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
	lv_label_set_text(sensor1_status, "OK");
        lv_label_set_align(sensor1_status, LV_LABEL_ALIGN_CENTER);
        lv_label_set_style(sensor1_status, &style_speedbox_label);

        lv_obj_t * sensor2_label = lv_label_create(lv_scr_act(), NULL);
	lv_obj_align(sensor2_label, sensor1_label, LV_ALIGN_OUT_RIGHT_MID, 15, 00);
	lv_label_set_text(sensor2_label, "Sensor 2");
        lv_label_set_align(sensor2_label, LV_LABEL_ALIGN_LEFT);
        lv_label_set_style(sensor2_label, &style_speedbox_label);

	lv_obj_t * sensor2_led = lv_led_create(lv_scr_act(), NULL);
	lv_obj_set_size(sensor2_led, led_size, led_size);
        lv_obj_align(sensor2_led, sensor2_label, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
	lv_obj_set_style(sensor2_led, &style_led);
	lv_led_on(sensor2_led);

	lv_obj_t * sensor2_status = lv_label_create(lv_scr_act(), NULL);
	lv_label_set_align(sensor2_status, LV_LABEL_ALIGN_CENTER);
        lv_obj_align(sensor2_status, sensor2_led, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
	lv_label_set_text(sensor2_status, "OK");
        lv_label_set_style(sensor2_status, &style_speedbox_label);

	lv_obj_t * sensor3_label = lv_label_create(lv_scr_act(), NULL);
	lv_obj_align(sensor3_label, sensor2_label, LV_ALIGN_OUT_RIGHT_MID, 15, 00);
	lv_label_set_text(sensor3_label, "Sensor 3");
        lv_label_set_align(sensor3_label, LV_LABEL_ALIGN_LEFT);
        lv_label_set_style(sensor3_label, &style_speedbox_label);

	lv_obj_t * sensor3_led = lv_led_create(lv_scr_act(), NULL);
	lv_obj_set_size(sensor3_led, led_size, led_size);
        lv_obj_align(sensor3_led, sensor3_label, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
	lv_obj_set_style(sensor3_led, &style_led);
	lv_led_on(sensor3_led);

	lv_obj_t * sensor3_status = lv_label_create(lv_scr_act(), NULL);
	lv_obj_align(sensor3_status, sensor3_led, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);
	lv_label_set_text(sensor3_status, "OK");
        lv_label_set_align(sensor3_status, LV_LABEL_ALIGN_CENTER);
        lv_label_set_style(sensor3_status, &style_speedbox_label);

Goal is to have have essentially a 3x3 array, top row is labels (static, unchanging), middle row is LEDs, bottom row is dynamic labels.  Ideally, all centered.
Here's how it renders:"

Just change the order:
lv_label_set_text(sensor1_status, "OK");
lv_obj_align(sensor1_status, sensor1_led, LV_ALIGN_OUT_BOTTOM_MID, 0, 10);

If you align first then the default text ("Text") will be aligned. As "Ok" is shorter and you don't realing the label, the position will be wrong.

In the past few days LittlevGL's Forum has launched to discuss questions there. See this Announcment.
If the issue still persists please open a topic for it on the Forum.

authors: embeddedt kaszeta kisvegabor


text:
Performance slows

Hi, I also tested library with 10k+ test data when I scroll it really slow down scrolling and make lagging, because of the public override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? here, we check every item in every section for intersection. We can use binary search for intersection.

I think the problem can be solved by not calculating all items in all sections in prepare() method. Instead, we can calculate in func layoutAttributesForElements(in rect: [CGRect]) https://developer.apple.com/documentation/uikit/uicollectionviewlayout/1617769-layoutattributesforelements method. I remember, one guy said that if calculation process takes time, you should do this in this function


text:
requiry about the weight of DD

When I run backdoor on DD, I cannot return the weights of the models.
And when I use the saved dataset to evaluate it again, I cannot get the same results as the training log.

I will close this issue. Feel free to open it again.

repo: liuyugeng/baadd


text:
🛑 friends.wowsgame.cn is down

In b61a2bf, friends.wowsgame.cn (https://friends.wowsgame.cn/en/about) was down:

HTTP code: 0
Response time: 0 ms

Resolved: friends.wowsgame.cn is back up in 7f565d9.


text:
Implement new App page

Just a few nitpicks, looking great! :)

Done! =D

source: gharchive/pull-request

authors: jonatanklosko paulo-valim

repo: livebook-dev/livebook


text:
Execute the Windows installer as normal user

Currently the Windows installer requires admin privileges, which are typically not available in an enterprise environment. This PR produces a Windows installer that runs without admin privileges.
Three of the four reasons why the installer requires admin rights have been addressed:

HKCR registry keys were replaced by HKCU registry keys
The name of the Erlang node of the Livebook app includes the host IP (since name resolution apparently requires admin rights)
The vc_redist.x64.exe installer was removed and the Livebook.exe app no longer targets .NET Framewok 4. Now it targets .NET 8 and is completely self-contained.

OTP (or rather erl.exe) requires vcruntime140.dll. This DLL can be added after extracting the OTP distribution.

 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.

OTP (or rather erl.exe) requires vcruntime140.dll. This DLL can be added after extracting the OTP distribution.

Can you elaborate on this? If we still need .dll but we are not shipping its installer and thus not installing it ourselves, how does this work in practice?

I just learned that the windows-latest image of GH actions includes VS 2022 with the component Microsoft.VisualStudio.Component.VC.Redist.14.Latest. And I found a script that copies the DLL from it.
Python, VS Code and many Rust CLI apps ship this DLL.

Sorry I still don’t understand how it works. If we are not shipping the .dll how does Livebook work without it? Are you saying users would have gotten it after installing, say, VSCode? But then it wouldn’t work without it, right?

Are you saying we should ship .dll ourselves (as opposed to shipping the vc_redist.exe which installs it into location which requires admin)? If so, yes, that’d be great and help on that front would be very appreciated.

Yes, that's what I mean. I will ask the Erlang people why don't they do it themselves. This issue leaves students and people in companies out of the BEAM world. If for some reason they don't want to do it, I will implement it for Livebook :)

Right, thanks.
So about the other changes. Switching to HKCU sounds good to me.
About dropping Windows.Forms and .NET 4.6 with self-contained=false in favor of .NET 8.0 with self-contained=true and using third party plugins, what is the installer size difference? Could you list upsides/downsides of what you are proposing? In isolation from other issues (vc redist and HKCU) because I believe, and correct me if I’m wrong, it is completely orthogonal?

The PR looks good to me assuming OTP will ship with required .dll files. If you could start the conversation and/or PR and if accepted it would be released in OTP 27.1, I think we can wait. Otherwise, eg it is deamed to big of a change and so scheduled for OTP 28, we’d appreciate doing the change in Livebook.

If you start issue/PR in OTP please cc me and/or mention it here so we can keep track!

I opened an issue in the OTP repo. Subscribe and we'll see what they say :)

Hi @wojtekmach, I just updated the installer so that uninstalling works. I also reverted the removal of vc_redist.exe.
The Livebook installer would work for anybody who already has vcruntime140.dll. Hopefully that is a large percentage of users. And hopefully OTP will one day ship the DLL. Then Livebook will not need vc_redist.exe at all.

Could you rebase with latest main? I’d expect your changes around node naming and similar are no longer necessary.

Done

I tested it with a user with no admin rights and Livebook does not work. The notebook cannot connect to Elixir. Something is missing in the new env.bat. I will have to investigate, unless you have an idea.

@wojtekmach I got it working :) Since I am behind a VPN, following the Installation FAQ I created  ".livebookdesktop.bat" in my User Profile folder with the contents:
set LIVEBOOK_DISTRIBUTION=name
set LIVEBOOK_NODE=livebook@127.0.0.1

My suggestion would be that the installer creates this file. Unless it can negatively affect some users.

I believe those are the default in latest Livebook, so we should be good to go!

I built the installer and tested it on a Windows machine with no admin rights. Livebook is now enterprise-ready!

When we release it, we need to tell people that if they previously installed Livebook, they need to go to "Settings / Apps / Installed Apps" and manually uninstall it first. I'm a little bit worried people might run into weird issues where previously the installer was running as an admin and now as a user. I tested it though, installing nightly, uninstalling it, installing this branch, and everything works well.
@josevalim @jonatanklosko should we merge this or wait until after v0.15 is out? I'm keen on users ideally trying this out with nightlies and reporting any issues.

@wojtekmach could we perhaps use another directory, to avoid the admin conflict issue? In any case, feel free to merge this any time.

You know what, I think this is probably fine and if people run into issues we'd tell them to uninstall and try again anyway.

@wojtekmach

@josevalim @jonatanklosko @hugobarauna should we merge this or wait until after v0.15 is out? I'm keen on users ideally trying this out with nightlies and reporting any issues sooner than later.

No comments on this one. Defer to José and Jonatan.
That said, I see it's already merged. So, great! :)

@wojtekmach Thanks for all the time invested in reviewing and testing this PR. As I have mentioned before, the definitive solution for vcredist is including that one DLL in the distribution. Since it is actually needed by Erlang, they should do it. I already opened an issue in their repo and argued that requiring admin rights for installing Erlang leaves people at enterprises and universities out of the BEAM ecosystem.
I won't be at Code Beam Europe, but maybe you or @josevalim can talk to them about this :)

authors: CLAassistant hugobarauna josevalim mardukbp wojtekmach


text:
Please add a client notification to the agent termination event

Currently there is no way from the cli client code to know when the agent received SIGTERM or SIGINT and is in the graceful shutdown state. It would be useful to have a possibility for it to emit an event or provide a possibility to assign a callback, so one could execute a custom code when that happens.
Related to https://github.com/livekit/livekit-helm/issues/116

+1 that would be nice!
FWIW you can do "cleanup" on the "job/worker" level using :
            # https://docs.livekit.io/agents/build/session/#post-processing-and-cleanup
            # Just add some logging when shutdown is initiated
            async def my_shutdown_hook() -> None:
                self._log_on_livekit_event_sync("shutdown callback")

            self.ctx.add_shutdown_callback(my_shutdown_hook)

If you feel real hacky, you can overwrite their SIGTERM catch in the JobEntry func,
but that can be dangerous you had been warned.

authors: mykola-mokhnach-parloa peter-assort

repo: livekit/agents


text:
Azure multilingual STT does not work as expected

I want to use Azure STT with passing a list of languages that the input audio could be from. I want Azure to identify the language from the provided list for the provided input audio.
stt = azure.STT(
           languages=["en-GB","hi-IN","fr-FR","de-DE","ar-AE","zh-CN","it-IT"]
         )

VoicePipelineAgent(
            vad=ctx.proc.userdata["vad"],
            stt=stt,
            llm=llm,
            tts=tts,
            chat_ctx=initial_ctx
        )

In above case the interim and final results are NOT received.
However, if I don't pass the languages param then Azure STT works but it always detects language as "en-US" irrespective of what language I speak in.
Please let me know what should be done to get Azure multilingual STT to work correctly.
Any help is appreciated.
Thanks.

This is not a bug, I read the spec info at azure official site


text:
♻ Refactor Functions

Refactored Code to use => than the function keyword.
Hope This Helps😃

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 27b2a740-104c-11ea-a65a-5f455ab5a299

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 3d227a10-104c-11ea-a65a-5f455ab5a299

@NBTX Done ✨ ✨

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 936f1bc0-104d-11ea-a65a-5f455ab5a299

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 4cf755c0-104f-11ea-a65a-5f455ab5a299

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 173ea130-1050-11ea-a65a-5f455ab5a299

@jamesgeorge007 Done I guess 😂

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: ad997720-1052-11ea-a65a-5f455ab5a299

I guess that most of the Functions refactored on .vue files and I guess thats why all of em are failing(tests). I think this should be closed as of now and I'll create a new PR with just the .js files refactored.
How does that sound?

What do you say @liyasthomas @NBTX @jamesgeorge007
Close it, if you feel like this should be closed

@athul no need. I'm quite busy with office stuffs rn, will be able to make this workable with some tweaks.

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: dded9af0-1061-11ea-a65a-5f455ab5a299

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: bd6677b0-1062-11ea-a65a-5f455ab5a299

Hey @athul,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: 4d553d80-10ad-11ea-a65a-5f455ab5a299

Hey @athul,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 93979010-10b5-11ea-a65a-5f455ab5a299

@jamesgeorge007 please take a look at this PR. Contribute to this pull if there's any refactoring left.

Hey @athul,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: d2be8d70-110a-11ea-b8ff-d5ab8a371226

Hey @athul,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: 26d25620-110c-11ea-b8ff-d5ab8a371226

authors: TravisBuddy athul liyasthomas

repo: liyasthomas/postwoman


text:
How to use the main() function in zoom_flow.py to check the zoomflow operator?

hi,I have changed the file path to my own dataset,but the figure shows out are all black, do I have to change something else to make this main() function work? The dataset is linemod ape.
    img_idx[idx] = 1
    v_image_rendered[idx] = cv2.imread(
        cur_dir + "/../../data/LINEMOD_6D/LM6d_converted/LM6d_refine/data/rendered/ape/{:06}_1-color.png".format(img_idx[idx]),
        cv2.IMREAD_COLOR,
    ).transpose([2, 0, 1])

    v_image_real[idx] = cv2.imread(
        cur_dir + "/../../data/LINEMOD_6D/LM6d_converted/LM6d_refine/data/observed/01/{:06}-color.png".format(img_idx[idx]),
        cv2.IMREAD_COLOR,
    ).transpose([2, 0, 1])

    v_depth_real[idx, 0] = (
        cv2.imread(
            cur_dir + "/../../data/LINEMOD_6D/LM6d_converted/LM6d_refine/data/gt_observed/ape/{:06}-depth.png".format(img_idx[idx]),
            cv2.IMREAD_UNCHANGED,
        )
        / 10000.0
    )

    v_depth_rendered[idx, 0] = (
        cv2.imread(
            cur_dir + "/../../data/LINEMOD_6D/LM6d_converted/LM6d_refine/data/rendered/ape/{:06}_1-depth.png".format(img_idx[idx]),
            cv2.IMREAD_UNCHANGED,
        )
        / 10000.0
    )

    pose_real_path = cur_dir + "/../../data/LINEMOD_6D/LM6d_converted/LM6d_refine/data/gt_observed/ape/{:06}-pose.txt".format(img_idx[idx])

    pose_est_path = cur_dir + "/../../data/LINEMOD_6D/LM6d_converted/LM6d_refine/data/rendered/ape/{:06}_0-pose.txt".format(img_idx[idx])

the figure shows like this:

many thanks!

I want to check this operator because I want to change the input size from 640*480 to other size, but when I finished preparing the data and train, there are always some bugs in this operator, so i wonder if there are something else beside the flownet input size that I should change to make this whole train work?

Well, the code under main is using data for YCB-Video. To make it work for LINEMOD, you need to change YCB-Video K to the LINEMOD K and the depth factor from 10000 to 1000.


text:
数据库连不上

数据库密码不对，连不上去了

用自己的

authors: gszhiyong lizeze


text:
exclusion not working correctly with hidden dirs?

It might be a configuration problem, or a problem with hidden dirs...
In my CI, the gems are installed in a .gems directory at the root of the project. I can't seem to be able to exclude that directory...
For example, I get the following:
6% /builds/golf/site/.gems/ruby/2.2.0/gems/activesupport-4.2.6/lib/active_support/core_ext/thread.rb

I tried adding .gems and builds/golf/site/.gems to the exclusions, without success...
Any idea would be welcomed!

Because I never thought about this edge case it's quite possible that exclusion doesn't work with hidden dirs  :grimacing:
I will set up a new test and I will let you know…

Workaround:
:exclude:
- '.gems'

So it works? ¯_(ツ)_/¯

It does, but I think this deserves a note in the docs

authors: TiteiKo lkdjiin

repo: lkdjiin/coco


text:
How to change the size of the feature vector (currently 16)

I am trying to modify the size of the feature vector.
By default, it is 16. I am trying to use a feature vector of 3 for example.
I modified the file "gaussian-grouping/scene/gaussian_model.py", by changing line 52:
self.num_objects = 3
But, when running the code I get this error:
RuntimeError: Given groups=1, weight of size [150, 3, 1, 1], expected input[1, 16, 479, 639] to have 3 channels, but got 16 channels instead
What other part of the code should I modify in order to use a feature vector of 3?

Hi, thanks for watching our work!
For changing dim of the feature vector, you can refer to this issue.

repo: lkeab/gaussian-grouping


text:
Which timecode is supported?

File ignored (/Users/kadia/Downloads/MusicGenerator-master/data/midi/ragtimemusic/MIDI_sample.mid): SMTPE timecode not supported (480 given)

having the same issue. have you been able to resolve it?

No not yet. @xmdx If you do, please update here.

authors: neelkadia xmdx


text:
Server crashes on client reload

Steps to reproduce:

Start the server using npm start
Login and navigate to /dashboard/activities page (From Browser).
Stop the server. Start the server again. (Restart)
Refresh the /dashboard/activities page. The server crashes:

Expected behavior:

User should be redirected to the login page
Server should not crash

It's working fine on other pages.
On comparing:
https://github.com/llaske/sugarizer-server/blob/a292c95a7e91c140a7ad05e5844c8c86eb41c9d8/dashboard/controller/users.js#L54-L74
and
https://github.com/llaske/sugarizer-server/blob/a292c95a7e91c140a7ad05e5844c8c86eb41c9d8/dashboard/controller/activities/index.js#L34-L52
I would recommend removing return res.redirect('/dashboard/activities'); statement present in the else statement.
I removed return res.redirect('/dashboard/activities'); and the code seems to work correctly. The server does not crashes and it redirects to the login page.

@ashish0910 Thanks for pointing it out but I was already working on this issue and I have an open pull request.
Check contributing guidilines here

Sorry @NikhilM98 I referred your issue just as an example . It is not conflicting your pull request and has change in different files . The issue which my pull request fix is quite similar to this issue but for different set of files . Your issue and pr was specifically for activity page and mine works on journal page . If you still feel objected then I can close my PR .

@ashish0919 since your implementation was similar to mine, It couldn't handle getEntries functionality properly. It was good for rendering index. The server is crashing due to an authentication error. But the app should also be able to handle other error cases.

Edit: My current implementation does not hold true for Journal case. It won't be able to handle cases like Error Code 15 or Error Code 16. I'll make another commit handling those cases in Journal view.

@NikhilM98 since now you are now working on journal page also then I shall close my PR .

Merged #52

repo: llaske/sugarizer-server


text:
🐛 Ensure service discovery redirect maintains the proper port

In cases where the caldav server's endpoint is not on the default port (80 or 443), requests fail service discovery because the 302 response Location header excludes the original request's port. This fixes that mismatch in those scenarios.

Thanks for the contribution! I'll look into it soon.

@llldar I see this was merged into master. When might this fix be published to npm? Thanks for looking at this so quickly. 👍 💯

I will make a new release today or tomorrow.

repo: llldar/tsDAV


text:
Add basic example notebook of using UMAP for document embedding

This is a pretty basic example of embedding the 20 newsgroups dataset. Feel free to change it however you want :)

Really cool contribution. Detailed description of taken steps and good use of the newer plotting features of UMAP.

authors: gclen sleighsoft

repo: lmcinnes/umap


text:
preprocess problem

concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.

if not model.params.unconditional:
AttributeError: 'AttrDict' object has no attribute 'unconditional'

Maybe add this : if not hasattr(model.params, 'unconditional'):
model.params.unconditional = False

repo: lmnt-com/diffwave


text:
Update akka-http-backend to 3.8.11

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

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.client3", artifactId = "akka-http-backend" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.softwaremill.sttp.client3", artifactId = "akka-http-backend" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #465.

repo: ln-vortex/ln-vortex


text:
1.4.3 always fails blob support test

In localforage 1.4.3 (testing in Chrome) it always fails _checkBlobSupportWithoutCaching because it passes a database instead of a transaction, which leads to this call:
txn.objectStore(DETECT_BLOB_SUPPORT_STORE).put(blob, 'key');
which throws TypeError: txn.objectStore is not a function because txn is really an IDBDatabase. It is clearly passing a database up the callstack from _checkBlobSupport(idb), initiated by a setItem call with a blob type (_checkBlobSupport(dbInfo.db)).
Execution jumps down in to a promise catch which returns false, and it ends up saving an encoded blob rather than a normal blob directly.
localforage 1.4.0 does not appear to be affected so this seems to be a recent regression.
Demo: https://www.scirra.com/labs/bugs/localforage-blob/
That basically just does localForage.setItem("foo", new Blob(["bar"])). Open dev tools and set pause on all exceptions.

Thank you for the report and really sorry it took me so long to address this.
I'm a bit swamped until mid-December with Mozilla add-ons stuff so I won't be able to check this out until then myself. Thanks for the detailed report; should make it easier to patch. 👍

Any news on this?

I'm sorry, we've been really busy with a new add-ons frontend project and it's still eating up a lot of my time for side projects. I don't yet know when I'll be able to look at this; if someone else could patch it I could probably more quickly review it than write the code myself, but I will try to check it as soon as I can if no one else can look! Sorry!

Just opened PR #643, can I get an extra confirmation that it works?

@AshleyScirra any feedback on this? @tofumatt does it look ok to you at least?

I'd test it, but I can't see a convenient way to effectively download a release with a PR merged. I don't use GitHub much. Do I have to manually copy-paste the PR in to master?

Going to the PR and finding the dist file and pressing view and then raw you will give you the source of the file.

@AshleyScirra any feedback on this?

I tested localforage.nopromises.js from PR #643, and it looks like blobs are stored correctly again.

Great!

authors: AshleyScirra thgreasi tofumatt

repo: localForage/localForage


text:
GEOMESA-2630,GEOMESA-2631 Fix JSON output for Spark dataframes

New conversion class in spark-sql module
Deprecated spark-jts conversion class
Separated out classes in GeoMesaSparkSQL file

Signed-off-by: Emilio Lahr-Vivaz elahrvivaz@ccri.com

stacks on top of #2272

repo: locationtech/geomesa


text:
apple: fix share sheet state on iOS

fixes #1533

superseded by #1617

authors: Parth SmailBarkouch

repo: lockbook/lockbook

license: Unlicense


text:
[WIP] Allow required UUID type in scaffold.

Allow scaffolding to create a required UUID.

I just realized the existing UUID field was mandatory by default (unless I'm mistaken) so adding optionality here will require going back and making all existing usages of it into the uuid! version.

@BWStearns your current fix looks OK, what do you mean?

Ah I misread the TYPEMAP bit in the gen model here. Yeah I guess it should be fine.

authors: BWStearns jondot

repo: loco-rs/loco


text:
Charts Update Is Delayed

Discussed in https://github.com/orgs/locustio/discussions/2769

Originally posted by r01k June 24, 2024
On Locust 2.29.0 (Python 3.12.4) the charts update with an increasing lag behind the user activity. After about 20 minutes in the test the charts have already fallen behind by about 10 minutes. Is anyone else seeing this?

@andrewbaldwin44 Can you have a look - perhaps this is a windows-specific thing?
@r01k can you add some details, maybe your locustfile? And command line.

Can confirm reproducibility on both Windows 10 22H2 machines tested, with a clean venv where only Locust has been installed. Didn't test on Linux. The graphing delay becomes apparent in a couple of minutes.
>locust -V
locust 2.29.1 from E:\Downloads\venv\Lib\site-packages\locust (Python 3.12.4, OpenSSL 3.0.13)

>pip freeze
blinker==1.8.2
Brotli==1.1.0
certifi==2024.6.2
cffi==1.16.0
charset-normalizer==3.3.2
click==8.1.7
colorama==0.4.6
ConfigArgParse==1.7
Flask==3.0.3
Flask-Cors==4.0.1
Flask-Login==0.6.3
gevent==24.2.1
geventhttpclient==2.3.1
greenlet==3.0.3
idna==3.7
itsdangerous==2.2.0
Jinja2==3.1.4
locust==2.29.1
MarkupSafe==2.1.5
msgpack==1.0.8
psutil==6.0.0
pycparser==2.22
pywin32==306
pyzmq==26.0.3
requests==2.32.3
setuptools==70.1.1
urllib3==2.2.2
Werkzeug==3.0.3
zope.event==5.0
zope.interface==6.4.post2

>locust -f test.py

from locust import HttpUser, task

class TestUser(HttpUser):
    host = 'localhost'
    @task
    def ping(self):
        self.client.get("http://localhost:8000/ping")

@cyberw Is it possible that the charts have been scaled? 2.29 charts can be scaled, I had this problem before and found out that the latest version of echats can be scaled.

@cyberw, apparently the charts are upscaled by default. Just looked and that was my case too. Scaling them back to 1 with the scroll wheel in fact allowed the current live stats to be shown.

@andrewbaldwin44 , maybe there is some way to show the user that they have scaled the graph?

Thanks for reporting this issue @r01k, good catch @GeraldWhitehead! I will check this out and have it so the chart shows the live test by defaut. Then I will see if there is also a way to show if the chart is scaled or not :+1:

repo: locustio/locust


text:
req/s in output for shapes is incorrect

Prerequisites

[X] I am using the latest version of Locust
[X] I am reporting a bug, not asking a question

Description
I am running the following shape code (expected_run_time is 300 and buffer_to_spin_down_init is 5) exact code from https://github.com/locustio/locust/blob/master/examples/custom_shape/stages.py:
 stages = [
        {"duration": expected_run_time/2, "users": number_of_users, "spawn_rate": spawn_rate, "user_classes": [InitializeUser]},
        {"duration": expected_run_time/2 + buffer_to_spin_down_init, "users": 0, "spawn_rate": number_of_users, "user_classes": [InitializeUser]},
        {"duration": expected_run_time + buffer_to_spin_down_init, "users": number_of_users, "spawn_rate": spawn_rate, "user_classes": [EvaluateUser]}
        ]

So the expected run time is 300 seconds with InitializeUser running for about 150s and EvaluateUser is about 145s.
This is the output I get at the end of the run:
Type     Name                                                                          # reqs      # fails |    Avg     Min     Max    Med |   req/s  failures/s
--------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------
POST     Evaluate-Journey                                                               33006     0(0.00%) |     12       3     754     12 |  106.21        0.00
POST     Initialize-Journey                                                             31738     0(0.00%) |     13       4     925     13 |  102.13        0.00
--------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------
         Aggregated                                                                     64744     0(0.00%) |     13       3     925     13 |  208.33        0.00

As you can see from the above, the # reqs for the Evaluate-Journey is 33006 and the run time is 145 seconds so the req/s should be   227.62 and similar behaviour can be seen with the Initialize-Journey.
The Charts also show a similar average:

Command line
-f /mnt/locust/main.py,/mnt/locust/default_custom_shape.py
Locustfile contents
I am using a shape very similar to the one found in https://github.com/locustio/locust/blob/master/examples/custom_shape/stages.py

Python version
3.10.5
Locust version
2.29.1
Operating system
Windows

I'm not sure I follow completely, but RPS is calculated for the whole duration of the test, so this is kind of expected?
In fact, shapes have no control/impact on how stats are calculated, it is the same as running regular ramp up.
Probably the best way to handle this is by running two separate tests.

Yes, exactly. Unfortunately there's no way to ask Locust to calculate the RPS only for the part where a certain user type was spawned, and it would be very hard to implement in a sensible way (the stats module doesnt even know which User they came from, and even if it did, it has no real knowledge of when users were spawned/despawned).

authors: cyberw yabouelenein


text:
🛑 PotusTV is down

In 3f06f96, PotusTV (https://tv.potus.ar) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PotusTV is back up in 67dd7f6 after 4 hours, 59 minutes.


text:
Add 'metadata' option to include @metadata field in output

Just like the rubydebug codec, being able to include the @metadata field in the output of the json_lines codec can be useful, for example for debugging or test tools that prefer machine-readable output. Fixes #23.
I'm not sure exactly when the .to_json_with_metadata method was added and whether we need to bump any gem dependencies so please have a look at that.
Added a minor version bump in the hopes that you'll be able to make a new release soon.

I'm kind of uncertain about this change. The intent of event metadata was for having things that only live within a single Logstash instance and would never be shipped externally. Shipping metadata externally breaks this expectation.
Can you help me understand your use case? Beyond that, my questions about this would start with this one: Why do you need to ship @metadata-- why not name the field something else?

For clarification on the rubydebug codec: rubydebug can include metadata because the intent of that codec is to output an event for debugging purposes, so in debugging an event, it can be useful to have the metadata.

The use case is any non-human debugging or testing tool that doesn't find the rubydebug output very compelling to parse. Specifically, I want to be able to use Logstash Filter Verifier to verify that @metadata fields get the correct values. Those fields are frequently used to e.g. set options in outputs so it's relevant to be able to verify their contents.

@magnusbaeck @jordansissel FWIW I really like this idea.
I don't see how making it a non-default option would be problematic.

If everyone's happy with this change I can rebase my branch and make it ready for merging.

@magnusbaeck I'd like to get an LGTM for @jordansissel before proceeding.

I agree with the usefulness in debugging, and the use case here makes sense if there's no other way to debug a filter configuration.
On the other hand, I am trying to remove to_json_with_metadataand its hash friendto_hash_with_metadata` from Logstash 5.0 and onward, so this feature, as it stands, won't work in 5.0. If anything, it'll be deprecated in 5.0 and removed later because the API ("to json with metadata") feels wrong to me.
Given I want to remove the APIs mentioned, I try to think about what could be next for your verifier -- This verifier could be an output plugin, or a custom pipeline implementation, instead of an external tool, which would give you access to the Event object and its metadata. I'm mostly brainstorming here ... Thoughts?

So.. Ehhh. I'm on the fence. I really want to_json_with_metadata to disappear, but I like your use case and want to support it.
If we can make to_json_with_metadata (or to_hash_with_metadata) deprecated on 5.0, and figure out how to keep supporting this use case without those methods, does that sound like an OK plan to you, @magnusbaeck? If so, I am +1 on this PR.

FWIW, I am a +1 for this particular use case because at some point, I'd love to use Logstash Filter Verifier in our test suite :)

@suyograo I think we can achieve verification without outputting @metadata, but I want to keep @magnusbaeck's work alive until we come up with that solution <3

Okay, so it sounds like it'd be worthwhile for me to rebase the branch then. How about merging #25 first so that I can include that change in this PR's changelog update?

Alright, so to_json_with_metadata is already gone in the master branch of elastic/logstash.git so this patch won't work after a rebase. Should that method be reinstated then (but marked as deprecated)? And will you do that so that we can move forward?

@magnusbaeck sorry for the delays.
We have Event#to_hash_with_metadata that you could call and take that object and serialize it to json.

I really would like to see this PR to make progress to be able to finally have access to the @metadata in Logstash Filter Verifier (see https://github.com/magnusbaeck/logstash-filter-verifier/issues/5).

authors: andrewvc breml jordansissel magnusbaeck suyograo


text:
手机网站支付--签名异常

调用  getRedirectUrl  返回的链接总是显示签名异常，重新配置支付宝+验证 确定没问题，找支付宝客服，最后没辙了， 查看源码，找到原因 ，发现 支付宝官方只 urlencode($sign)
protected function getSignContent($params) {
		ksort($params);

		$stringToBeSigned = "";
		$i = 0;
		foreach ($params as $k => $v) {
			if (false === $this->checkEmpty($v) && "@" != substr($v, 0, 1)) {

				// 转换成目标字符集
				$v = $this->characet($v, $this->postCharset);

				if ($i == 0) {
					$stringToBeSigned .= "$k" . "=" . "$v";
				} else {
					$stringToBeSigned .= "&" . "$k" . "=" . "$v";
				}
				$i++;
			}
		}

		unset ($k, $v);
		return $stringToBeSigned;
	}
......
//签名
		$totalParams["sign"] = $this->generateSign($totalParams, $this->signType);
		if ("GET" == $httpmethod) {

			//拼接GET请求串
			$requestUrl = $this->gatewayUrl."?".$preSignStr."&sign=".urlencode($totalParams["sign"]);
			return $requestUrl;
		} else {
			//拼接表单字符串
			return $this->buildRequestForm($totalParams);
		}

而这里把所有参数都 urlencode 了
/**
     * Gets the redirect target url.
     */
    public function getRedirectUrl()
    {
        return sprintf('%s?%s', $this->request->getEndpoint(), http_build_query($this->data));
    }

没看完，没问题

repo: lokielse/omnipay-alipay


text:
agregar incidencias

desarrollar un gestor de riesgos, donde pueda agregar las vulnerabilidades y clasificarlas. Además de poder asignar recursos disponibles de mi inventario

Story deleted from ScrumDo


text:
Substantially refactored Python scripts to make them more in line with common convention; made variable and function names more descriptive.

I highly recommend you test my changes out!  They substantially affect how the code is structured.

For me, I think it is unnecessary to use functions for just one thing but for others yeah it is good

Many design paradigms promote having functions that do one thing and one thing only, such as 'functional programming'.  It makes it easier to group small tasks into larger ones.  That's called abstraction.

Many design paradigms promote having functions that do one thing and one thing only, such as 'functional programming'. It makes it easier to group small tasks into larger ones. That's called abstraction.

I said For me. Also I already know that.

It looks good for cosmetic but creating functions uses more memory.

Yeah I was thinking the same thing immediately after approving it.

authors: Windows81 localfossa lolmanurfunny


text:
Product ID: where can I find this?

I'm using search_products to look up a list of stocks. I tried to use the ISIN as the search key, but it seems that's not a unique number (the lookup yields the same stock on multiple stock exchanges). So if I want a specific exchange, I need to search via the product ID instead. I don't see this ID listed on the product page. Is it part of the URL?
example:
https://trader.degiro.nl/trader/#/products/14625503/overview -> product ID=14625503?
this seems to check out for the examples I've tried, but I'd like to make sure.

I tried searching for a product ID:
test = degiro.search_products(1133191)
print(Product(test[0]).id)

but that returns an error:
test = degiro.search_products(1133191)
  File "/Users/***/Library/Python/3.8/lib/python/site-packages/degiroapi/__init__.py", line 105, in search_products
    return self.__request(DeGiro.__PRODUCT_SEARCH_URL, None, product_search_payload,
KeyError: 'products'

Is there a way to search for a product by ID?

As a workaround, I'm doing a search by ISIN. Then I check all of the results to find the product ID I want:
products = degiro.search_products('Autodesk',10)
            for prod in products:
                if prod['id'] == uid:

I wonder what you are trying to do?
I would say the "Search Products" function is mainly to find the product ID.
If you are looking for the product ID of a stock with a specific exchange, the exchange ID can be used.
For example, in my case, I want to buy German stock from Tradegate.
I know that Tradegate has the stock exchange number 196.
So if I want to buy a German stock, I do the following:
products = degiro.search_products('DE000BASF111',5)
for product in products:
if product['exchangeId'] == '196':
uid = product['id']

repo: lolokraus/DegiroAPI


text:
Support Apple campaign ad sizes

The new sizes are to support the Apple campaign headed our way.  The [1,1] sizes will allow the AdOps team to not show the MPU unit and bottom unit in Destinations and Homepage.

:+1:

repo: lonelyplanet/rizzo


text:
Create docker environment

It would be great to have docker environment in this project

Sorry I can't accept this PR, it's not good run development environment in docker, and it's better use nginx when production.


text:
有关不能启用https的问题。

你好，感谢你的软件；经过大量高并发测试，发现你的lunnel比frp要稳定，打算部署在生产上。
但是发现https开启不了。
在阿里云上部署，如下是server端配置。在不开启client端时就可以在浏览器里面访问http://aaa:86,只是报通道错误而已，但不能访问https://aaa:85，观察端口已经处于监听状态。防火墙已关闭，端口已打开。
先谢了！
server_domain: aaa
ip: xxx
port: 87
http_port: 86
https_port: 85
manage_port: 8081
aes:
secret_key: yyyy
tls:
cert: e:\ecnu-cert\aaa.cer
key: e:\ecnu-cert\aaa.key
debug: true
log_file: ./client.log

在公网端，我用nginx代理转发到server端解决了这个问题。
nginx要设置    proxy_set_header Host $host;
谢了！

repo: longXboy/lunnel


text:
[BUG] Attempts to mount unreachable NFS backup target can hang

Describe the bug (🐛 if you encounter this issue)
This behavior was found while testing the fix for https://github.com/longhorn/longhorn/issues/6481.  If a backup target cannot be mounted (for instance, the path doesn't exist), repeated attempts to mount will eventually hang.
To Reproduce
Steps to reproduce are the same as #6481 (which see):

Create a volume.  Write data to it.
Set the backup target to a non-existent path
Make a snapshot and backup from it.  In the base bug, we actually made 100 backups, to hasten the process.  Here's a simple bash script to do that (replace the volume name and snapshot name with your own):

#! /bin/bash
# set -eux

for i in $(seq 1 100); do

# YAML is a heredoc with substitutions.
# kubectl apply --dry-run='client' -f - << EOF
kubectl apply -f - << EOF
apiVersion: longhorn.io/v1beta2
kind: Backup
metadata:
  labels:
    backup-volume: testvol1
  name: "backup$i"
  namespace: longhorn-system
spec:
  labels:
    longhorn.io/volume-access-mode: rwo
  snapshotName: 9db0e55b-4a75-4dbf-8fab-77ada4400e4c
EOF

done

Expected behavior
Backups will fail and be marked as "error", rather than hanging at 0%.
Note that in master and releases after 1.5.1, it may not reproduce due to the fix for endlessly retrying failed backups.
Support bundle for troubleshooting
Environment

Longhorn version: 1.5.1
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):  Rancher
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:  v1.25.12+rke2r1

Number of management node in the cluster: 1
Number of worker node in the cluster:  3

Node config

OS type and version:  Ubuntu 22.04
Kernel version:  5.15.0-67-generic 74-Ubuntu
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe/HDD):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): Digital Ocean
Number of Longhorn volumes in the cluster: 1

Additional context
From https://github.com/longhorn/longhorn/issues/6481#issuecomment-1682926359
With the fix, leaving 91 failing backups running overnight, the top pods look like:
$ kl top pod
NAME                                                CPU(cores)   MEMORY(bytes)
instance-manager-524d96f7e531a3cf659b52ba31e6cfa4   225m         295Mi
instance-manager-7694d1d58572b971e5b0176cc5855c17   111m         57Mi
instance-manager-a81265cabd52ad39fb2c212b1611c313   177m         67Mi

That's troubling.  The process list inside that pod is
# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   2516   716 ?        Ss   Aug15   0:07 /tini -- instance-manager --debug daemon --listen 0.0.0.0:8500
root           8  2.0  0.8 1543184 33212 ?       Sl   Aug15  53:40 longhorn-instance-manager --debug daemon --listen 0.0.0.0:8500
root          10  0.0  0.0   3008   872 ?        S    Aug15   0:17 tgtd -f
root          11  0.0  0.0   2532   712 ?        S    Aug15   0:00 tee /var/log/tgtd.log
root      102321  0.0  0.1   8984  4216 pts/0    Ss+  Aug16   0:00 bash
root      394458  1.2  0.6 1544964 25992 ?       Sl   03:29  10:11 /host/var/lib/longhorn/engine-binaries/jmunson4suse-longhorn-engine-6481-pprof/longhorn replica /host/var/lib/longhorn/replicas/testvol1
root      394464  5.5  1.1 2520672 45764 ?       Sl   03:29  45:48 /host/var/lib/longhorn/engine-binaries/jmunson4suse-longhorn-engine-6481-pprof/longhorn sync-agent --listen 0.0.0.0:10002 --replica 0.0.

root     1107132  0.0  0.0   8104  1176 ?        S    12:31   0:00 mount -t nfs4 -o nfsvers=4.2,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-
root     1107133  0.0  0.1  29956  5088 ?        D    12:31   0:00 /sbin/mount.nfs4 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_defa
root     1107134  0.0  0.0   8104  1260 ?        S    12:31   0:00 mount -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-
root     1107136  0.0  0.1  29956  5088 ?        D    12:31   0:00 /sbin/mount.nfs4 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_defa
... (89 more instances of mount ...)

That is, the RSS size of the sync-agent process is reasonable, although the VSZ is large.  That's because there are 91 goroutines hanging around waiting for the NFS mounts to be successful, in a blocking syscall.  Apparently each backup is attempting to mount the bogus NFS path, and is hung.
Thanks to @ejweber, this ps output shows
instance-manager-524d96f7e531a3cf659b52ba31e6cfa4:/ # ps -eo ppid,pid,user,stat,pcpu,comm,wchan:32
   PPID     PID USER     STAT %CPU COMMAND         WCHAN
      0       1 root     Ss    0.0 tini            do_sigtimedwait
      1       8 root     Sl    2.3 longhorn-instan ep_poll
      8      10 root     S     0.0 tgtd            ep_poll
      8      11 root     S     0.0 tee             pipe_read
      0  102321 root     Ss+   0.0 bash            do_select
      8  394458 root     Sl    1.1 longhorn        futex_wait_queue_me
 394458  394464 root     Sl    6.3 longhorn        do_wait
 394464 1107132 root     S     0.0 mount           do_wait
1107132 1107133 root     D     0.0 mount.nfs4      nfs_wait_client_init_complete
...

Some bugs turned up by searching for "nfs4_try_get_tree hang" suggest that it might be limited to NFSv4.

For the context, we (@ejweber , @james-munson , me) did:
I attempted to enable logging for nfs client on the problematic IM pod (instance-manager-524d96f7e531a3cf659b52ba31e6cfa4)  and normal IM pod (instance-manager-7694d1d58572b971e5b0176cc5855c17) by rpcdebug -m nfs -s all.
Then I manually run the mount command mount -t nfs4 -o nfsvers=4.2,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-2-svc.default:/opt/backupstore /mnt on both of them.
On the problematic IM pod, dmesg shows:
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'source'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'nfsvers'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'actimeo'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'soft'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'timeo'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'retry'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'addr'
[Thu Aug 17 23:29:53 2023] NFS:   parsing nfs mount option 'clientaddr'
[Thu Aug 17 23:29:53 2023] NFS: MNTPATH: '/opt/backupstore'
[Thu Aug 17 23:29:53 2023] --> nfs4_try_get_tree()
Looks like it is stuck at this function https://codebrowser.dev/linux/linux/fs/nfs/nfs4super.c.html#nfs4_try_get_tree
Then it try to find a a matching existing client. Looks like it found one matching client but wait forever for the client to finish initializing. https://codebrowser.dev/linux/linux/fs/nfs/client.c.html#298
On the normal IM pod, it continues after that log nfs4_try_get_tree :

[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'source'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'nfsvers'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'actimeo'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'soft'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'timeo'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'retry'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'addr'
[Thu Aug 17 23:43:28 2023] NFS:   parsing nfs mount option 'clientaddr'
[Thu Aug 17 23:43:28 2023] NFS: MNTPATH: '/opt/backupstore'
[Thu Aug 17 23:43:28 2023] --> nfs4_try_get_tree()
[Thu Aug 17 23:43:28 2023] NFS: get client cookie (0x0000000080012a1d/0x00000000b6f63220)
[Thu Aug 17 23:43:28 2023] nfs_create_rpc_client: cannot create RPC client. Error = -22
[Thu Aug 17 23:43:28 2023] NFS: create per-net callback data; net=f00003a2
[Thu Aug 17 23:43:28 2023] NFS: nfs4_discover_server_trunking: testing 'longhorn-test-nfs-2-svc.default'
[Thu Aug 17 23:43:28 2023] --> nfs4_proc_create_session clp=0000000080012a1d session=00000000861b2ced
[Thu Aug 17 23:43:28 2023] nfs4_init_channel_attrs: Fore Channel : max_rqst_sz=1049620 max_resp_sz=1049480 max_ops=8 max_reqs=64
[Thu Aug 17 23:43:28 2023] nfs4_init_channel_attrs: Back Channel : max_rqst_sz=4096 max_resp_sz=4096 max_resp_sz_cached=0 max_ops=2 max_reqs=16

I don't know how to make sense all of this info but I feel that an error when initializing the client the first time lead to all subsequent mounts stuck?

Interesting. It does show that something is happening. Every 40 seconds we try to do something, fail, and requeue for 40 seconds later.

Similar complaint on the same version of nfs-common as we are.
https://groups.google.com/g/linux.debian.kernel/c/YbOrXek31Sg

Nice find, though.  I wonder whether highest_used of -1 is just an initialization for "no slot ever used."  Seems like that in the logging for this defect:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2012020

Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213430] NFS: nfs_lookup_revalidate_done(/Components) is valid
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213432] --> nfs41_call_sync_prepare data->seq_server 000000008a198bb4
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213433] --> nfs4_alloc_slot used_slots=0000 highest_used=4294967295 max_slots=64
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213433] <-- nfs4_alloc_slot used_slots=0001 highest_used=0 slotid=0
Followed a little later by

Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213853] --> nfs4_alloc_slot used_slots=0001 highest_used=0 max_slots=64
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213854] <-- nfs4_alloc_slot used_slots=0003 highest_used=1 slotid=1
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213855] nfs4_free_slot: slotid 1 highest_used_slotid 0
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213855] nfs41_sequence_process: Error 0 free the slot
Mar 17 10:20:41 ip-10-1-2-84 kernel: [ 3897.213856] nfs4_free_slot: slotid 0 highest_used_slotid 4294967295
But the "deathlock" is happening in a recent kernel, according to the bug that one points to:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009325

Looks like the reported bug is related to NFS v4 and kernel 5.15.0-67-generic. Can we change one of the 2 parameters to see if it fix the problem?
1. Modify longhorn engine to speak nfs v3
1. Down grade kernel version of the instance-manager pod by building a new instance manager image

Btw, this script from @james-munson might be helpful for @longhorn/qa when trying to reproduce by creating a lot of backup CRs:
#! /bin/bash
# set -eux

for i in $(seq 11 100); do

# YAML is a heredoc with substitutions.
# kubectl apply --dry-run='client' -f - << EOF
kubectl apply -f - << EOF
apiVersion: longhorn.io/v1beta2
kind: Backup
metadata:
  labels:
    backup-volume: testvol1
  name: "backup$i"
  namespace: longhorn-system
spec:
  labels:
    longhorn.io/volume-access-mode: rwo
  snapshotName: 9db0e55b-4a75-4dbf-8fab-77ada4400e4c
EOF

done

Experimental change will have to be with kernel version (change the OS on the worker.)  It looks like NFSv4 is a given, as noted in the docs:  https://longhorn.io/docs/1.5.1/snapshots-and-backups/backup-and-restore/set-backup-target/#set-up-nfs-backupstore
For using NFS server as backupstore, NFS server must support NFSv4.

Modify longhorn engine to speak nfs v3

The mount options are currently hardcoded. We can support users customize the backupstore mount options like volume mount options.
WDYT? @PhanLe1010

The mount options are currently hardcoded. We can support users customize the backupstore mount options like volume mount options.
WDYT? @PhanLe1010

Agree that we should allow the user customize the backupstore mount options.
That being said, we are still interested in why NFS is stuck after running for 1 hour in this ticket. Perhaps we can identify problematic env issues that could be turned into a KB

Anyway, running the experiment on an Ubuntu 20.04 worker node, using 1.5.1, the repeated attempts to mount happen but they do not lock up.
The instance-manager logs show it trying nfsvers=4.2, 4.1, and 4.0 in succession, as hoped:
[instance-manager-186913705e0cef4ef968c932b79a94c8] [longhorn-instance-manager] time="2023-09-05T22:23:01Z" level=info msg="Backing up snapshot 91f62726-1302-4f15-8161-29e669c8b835 to backup backup3" backendStoreDriver=v1 engineName=vol1-e-76957d11 serviceURL="10.42.96.13:10021"
[instance-manager-186913705e0cef4ef968c932b79a94c8] [longhorn-instance-manager] time="2023-09-05T22:23:01Z" level=info msg="Backing up 91f62726-1302-4f15-8161-29e669c8b835 on tcp://10.42.245.19:10010, to nfs://longhorn-test-nfs-svc.default:/opt/backupstore-nonexist"
[instance-manager-186913705e0cef4ef968c932b79a94c8] [vol1-r-2c57bc65] time="2023-09-05T22:23:01Z" level=info msg="Initializing backup backup3 for volume vol1 snapshot 91f62726-1302-4f15-8161-29e669c8b835" pkg=backup
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Removing BackupList entry at index 1: &{backup3 0xc000001170}"
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Start creating backup backup3" pkg=backup
[instance-manager-186913705e0cef4ef968c932b79a94c8] [vol1-r-2c57bc65] time="2023-09-05T22:23:01Z" level=warning msg="Trying reading mount point /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist to make sure it is healthy" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Attempting mount for nfs path longhorn-test-nfs-svc.default:/opt/backupstore-nonexist with nfsvers 4.2" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Mounting NFS share nfs://longhorn-test-nfs-svc.default:/opt/backupstore-nonexist on mount point /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist with options [nfsvers=4.2 actimeo=1 soft timeo=300 retry=2]" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] [vol1-r-2c57bc65] E0905 22:23:01.323392      57 mount_linux.go:232] Mount failed: exit status 32
[instance-manager-186913705e0cef4ef968c932b79a94c8] Mounting command: mount
[instance-manager-186913705e0cef4ef968c932b79a94c8] Mounting arguments: -t nfs4 -o nfsvers=4.2,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist
[instance-manager-186913705e0cef4ef968c932b79a94c8] Output: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory
[instance-manager-186913705e0cef4ef968c932b79a94c8]
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Attempting mount for nfs path longhorn-test-nfs-svc.default:/opt/backupstore-nonexist with nfsvers 4.1" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Mounting NFS share nfs://longhorn-test-nfs-svc.default:/opt/backupstore-nonexist on mount point /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist with options [nfsvers=4.1 actimeo=1 soft timeo=300 retry=2]" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] [vol1-r-2c57bc65] E0905 22:23:01.383059      57 mount_linux.go:232] Mount failed: exit status 32
[instance-manager-186913705e0cef4ef968c932b79a94c8] Mounting command: mount
[instance-manager-186913705e0cef4ef968c932b79a94c8] Mounting arguments: -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist
[instance-manager-186913705e0cef4ef968c932b79a94c8] Output: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory
[instance-manager-186913705e0cef4ef968c932b79a94c8]
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Attempting mount for nfs path longhorn-test-nfs-svc.default:/opt/backupstore-nonexist with nfsvers 4.0" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=info msg="Mounting NFS share nfs://longhorn-test-nfs-svc.default:/opt/backupstore-nonexist on mount point /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist with options [nfsvers=4.0 actimeo=1 soft timeo=300 retry=2]" pkg=nfs
[instance-manager-186913705e0cef4ef968c932b79a94c8] [vol1-r-2c57bc65] E0905 22:23:01.439479      57 mount_linux.go:232] Mount failed: exit status 32
[instance-manager-186913705e0cef4ef968c932b79a94c8] Mounting command: mount
[instance-manager-186913705e0cef4ef968c932b79a94c8] Mounting arguments: -t nfs4 -o nfsvers=4.0,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist
[instance-manager-186913705e0cef4ef968c932b79a94c8] Output: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory
[instance-manager-186913705e0cef4ef968c932b79a94c8]
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=error msg="Failed to create delta block backup" destURL="nfs://longhorn-test-nfs-svc.default:/opt/backupstore-nonexist" error="cannot mount nfs longhorn-test-nfs-svc.default:/opt/backupstore-nonexist: vers=4.0: mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t nfs4 -o nfsvers=4.0,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist\nOutput: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory\n: vers=4.1: mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist\nOutput: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory\n: vers=4.2: mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t nfs4 -o nfsvers=4.2,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist\nOutput: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory\n: cannot mount using NFSv4" snapshot="&{91f62726-1302-4f15-8161-29e669c8b835 2023-09-05T22:23:01Z}" volume="&{vol1 5368709120 map[VolumeRecurringJobInfo:{} longhorn.io/volume-access-mode:rwo] 2023-09-05T22:23:01Z   0   lz4 }"
[instance-manager-186913705e0cef4ef968c932b79a94c8] time="2023-09-05T22:23:01Z" level=error msg="Failed to create backup backup3" error="cannot mount nfs longhorn-test-nfs-svc.default:/opt/backupstore-nonexist: vers=4.0: mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t nfs4 -o nfsvers=4.0,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist\nOutput: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory\n: vers=4.1: mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist\nOutput: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory\n: vers=4.2: mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t nfs4 -o nfsvers=4.2,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist\nOutput: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory\n: cannot mount using NFSv4"

As a remaining item on this ticket, we should test that in the master branch, the retry is not forever, and that the mount hang, therefore, does not take place, even if run on Ubuntu with the problematic kernel.
At that point, perhaps we can write a short KB article mentioning the issue, which can be avoided by avoiding this combination of circumstances:

Longhorn version 1.5.1 or less
Ubuntu 22.04 or another OS with Linux kernel 5.4.0.  ~(Can we be more specific, even?)
NFS as the backup target, but with an unmountable target URL.

Related issue for this is https://github.com/longhorn/longhorn/issues/6608

Modify longhorn engine to speak nfs v3

The mount options are currently hardcoded. We can support users customize the backupstore mount options like volume mount options. WDYT? @PhanLe1010

Related issue for this is https://github.com/longhorn/longhorn/issues/6608

Repro with master-head (1.6.0 code) on Ubuntu 22.04 gives a set of backups that tried to mount and failed, but did not retry forever, leaving the backup CRDs in "Error" state.  Here's one:
Name:         backup10
Namespace:    longhorn-system
Labels:       backup-volume=testvol1
Annotations:  <none>
API Version:  longhorn.io/v1beta2
Kind:         Backup
Metadata:
  Creation Timestamp:  2023-09-06T23:44:25Z
  Finalizers:
    longhorn.io
  Generation:        1
  Resource Version:  17374777
  UID:               a52e1a80-61b0-414f-bc28-107a681cbf16
Spec:
  Labels:
    longhorn.io/volume-access-mode:  rwo
  Snapshot Name:                     dd440f10-1208-41ab-ac6d-c601b77f8e00
Status:
  Backup Created At:
  Compression Method:
  Error:               proxyServer=10.42.192.241:8501 destination=10.42.192.224:10011: failed to backup snapshot dd440f10-1208-41ab-ac6d-c601b77f8e00 to backup10: rpc error: code = Unknown desc = failed to create backup to nfs://longhorn-test-nfs-svc.default:/opt/backupstore-nonexist for volume testvol1: rpc error: code = Unknown desc = cannot mount nfs longhorn-test-nfs-svc.default:/opt/backupstore-nonexist: vers=4.0: mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs4 -o nfsvers=4.0,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist
Output: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory
: vers=4.1: mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist
Output: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory
: vers=4.2: mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs4 -o nfsvers=4.2,actimeo=1,soft,timeo=300,retry=2 longhorn-test-nfs-svc.default:/opt/backupstore-nonexist /var/lib/longhorn-backupstore-mounts/longhorn-test-nfs-svc_default/opt/backupstore-nonexist
Output: mount.nfs4: mounting longhorn-test-nfs-svc.default:/opt/backupstore-nonexist failed, reason given by server: No such file or directory
: cannot mount using NFSv4
  Labels:                     <nil>
  Last Synced At:             2023-09-06T23:44:26Z
  Messages:                   <nil>
  Owner ID:                   jbm-test-01-pool2-68473cb5-jdkwv
  Progress:                   0
  Replica Address:
  Size:
  Snapshot Created At:        2023-08-11T23:13:39Z
  Snapshot Name:
  State:                      Error
  URL:
  Volume Backing Image Name:
  Volume Created:
  Volume Name:
  Volume Size:                21474836480
Events:                       <none>

After the failure, the instance-manager and longhorn-manager logs are quiet.

authors: PhanLe1010 derekbit james-munson

repo: longhorn/longhorn


text:
[IMPROVEMENT] Gracefully shut down spdk_tgt

Is your improvement request related to a feature? Please describe (👍 if you like this request)
To avoid data corruption or data recovery in SPDK blobstore, instance-manager pod should gracefully shut down spdk_tgt.
Describe the solution you'd like

Describe alternatives you've considered

Additional context

Verified pass on longhorn master(longhorn-instance-manager 96446a) with test steps
Can reproduce in v1.5.3, the same steps on master-head did not seen Performing recovery on blobstore related logs in instance-manager pod.

authors: chriscchien derekbit


text:
[BUG] longhorn-driver-deployer fail due to MountPropagation but environment_check.sh does not show any error

Describe the bug
longhorn-driver-deployer refuse to deploy log show:
W0311 08:41:51.506261       1 client_config.go:618] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
time="2024-03-11T08:42:41Z" level=warning msg="Got an error when checking MountPropagation with node status, node oci-autour.private.berangere.oraclevcn.com is not support mount propagation" func=app.deployDriver file="driver.go:177"
time="2024-03-11T08:42:41Z" level=fatal msg="Error deploying driver: CSI cannot be deployed because MountPropagation is not set: node oci-autour.private.berangere.oraclevcn.com is not support mount propagation" func=app.DeployDriverCmd.func1 file="driver.go:141"

but curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.6.0/scripts/environment_check.sh | bash:
[INFO]  Required dependencies 'kubectl jq mktemp sort printf' are installed.
[INFO]  All nodes have unique hostnames.
[INFO]  Waiting for longhorn-environment-check pods to become ready (0/0)...
[INFO]  All longhorn-environment-check pods are ready (7/7).
[INFO]  MountPropagation is enabled
[INFO]  Checking kernel release...
[INFO]  Checking iscsid...
[INFO]  Checking multipathd...
[INFO]  Checking packages...
[INFO]  Checking nfs client...
[INFO]  Cleaning up longhorn-environment-check pods...
[INFO]  Cleanup completed.

To Reproduce
On a 1.29.1 kubernetes cluster with longhorn 1.5.2, update to k8s 1.29.2 next update to longhorn 1.6.0
Expected behavior

Support bundle for troubleshooting

Uploading supportbundle_5398826c-9de3-4845-88cb-691097e941ce_2024-03-11T09-00-31Z.zip…
Environment

Longhorn version: 1.6.0
Impacted volume (PV):
Installation method : helm chart
Kubernetes distro : bare metal

Number of control plane nodes in the cluster: 2
Number of worker nodes in the cluster: 5

Node config

OS type and version: Linux Ubuntu 22.0.4 LTS
Kernel version: 6.5.0
CPU per node: 6
Memory per node: 24 GB
Disk type : SSD
Network bandwidth between the nodes (Gbps): 1GBps

Underlying Infrastructure : Baremetal
Number of Longhorn volumes in the cluster: 10

Additional context

supportbundle_5398826c-9de3-4845-88cb-691097e941ce_2024-03-11T09-00-31Z.zip

Hello @eltorio.
The environment check script runs its own set of containers and verifies that they successfully run with mount propagation enabled.
The check that is failing works in two steps:

The node controller running with longhorn-manager on each node determines whether the longhorn-manager pod on that node is running with mount propagation. If it is, a MountPropagation condition is added to the corresponding node.longhorn.io CR.
The driver deployer checks that all node.longhorn.io objects have the condition.

The support bundle your provided only includes logs from the longhorn.io namespace, but no YAML files. Because of this, I cannot verify if the node.longhorn.io CR's have the expected status. Please consider attaching the missing files or sending them to longhorn-support-bundle@suse.com.
A couple of your longhorn-manager pods appear to be having extreme difficulty communicating with your Kubernetes API server. It is possible that these pods are unable to correctly sync the expected condition to the corresponding node.longhorn.io CR.

longhorn-manager-gp56w is repeatedly failing to sync autour.
longhorn-manager-42thj is repeatedly failing to sync both autour and bartevelle.

Perhaps the in-cluster KUBECONFIG these two pods rely on to communicate with the API server is broken? If so, deleting them may allow them to be correctly recreated and get things moving.

Dear @ejweber ,
Thank you for your help, this cluster is a lab, so I deleted it and recreates from scratch. it stills have problem…
But on the new cluster (with same nodes) the support bundle fail with a 502 error.
alll my other services are working.
For investigating my cluster is a poor man HA cluster :), let me explain
there is two control planes (azure-gypaete and mikado),
6 workers (all names are oci-[alpin bird names in french]).  (circaete,autour,bartavelle, tetraslyre, choucas, chocard)
on all nodes there is an haproxy listening on 127.43.43.43:6443 and distributing to 192.168.2.8:6443 (mikado) or 10.254.0.4 (azure-gypaete)

Do your other workloads require the ability to communicate with the Kubernetes API server? It seems that this is problematic in the pods mentioned above, with every log being something like:
2024-03-11T08:21:52.716681200Z time="2024-03-11T08:21:52Z" level=error msg="Failed to sync Longhorn node" func=controller.handleReconcileErrorLogging file="utils.go:72" LonghornNode=longhorn-system/oci-autour.private.berangere.oraclevcn.com controller=longhorn-node error="failed to sync node for longhorn-system/oci-autour.private.berangere.oraclevcn.com: Put \"https://172.24.0.1:443/apis/longhorn.io/v1beta2/namespaces/longhorn-system/nodes/oci-autour.private.berangere.oraclevcn.com/status\": http2: client connection lost" node=oci-bartavelle.private.voza.oraclevcn.com

I am not sure why, but it seems either the HA configuration itself, the Kubernetes v1.29.2, or some combination is a likely culprit.
From the Longhorn side, we probably can't help much to fix the issue until the communication problems are resolved. In case it is some incompatibility between the version of the Kubernetes Go client we use and the v1.29.2 API server, I can try to get a small v1.29.2 cluster up and do a spot check, as only versions up to v1.28 were tested for Longhorn v1.6.0 (https://longhorn.io/docs/1.6.0/best-practices/#kubernetes-version).

In case it is some incompatibility between the version of the Kubernetes Go client we use and the v1.29.2 API server, I can try to get a small v1.29.2 cluster up and do a spot check, as only versions up to v1.28 were tested for Longhorn v1.6.0 (https://longhorn.io/docs/1.6.0/best-practices/#kubernetes-version).

I did run a single node v1.29.2 k3s cluster and was able to install and run Longhorn on it without issue. For now, this issue still looks related to the specific cluster networking.

Rather to directly installing 1.6.0,
I revert to longhorn 1.5.4 everything is working, I'll try to upgrade for reproducing it.
Only the "oci-*" nodes have sync problems. All this nodes are VM at Oracle OCI. They use a "special" Oracle kernel. Perhaps the MountPropagation fail is comming from this kernel ?

investigations continue:
I deleted many times the Cluster and tested with different CNI and longhorn versions

CNI
Longhorn
Test

Cilium 1.14.1
Longhorn 1.5.4
:heavy_check_mark:

Cilium 1.14.8
Longhorn 1.6.0
:heavy_check_mark:

Cilium 1.15.1
Longhorn 1.5.4
:heavy_check_mark:

Cilium 1.15.1
Longhorn 1.6.0
:x:

Interesting. I'll give that failing combo of Cilium and Longhorn a shot.
Did you upgrade Cilium to v1.15.1 alongside the upgrade to Kubernetes v1.29.2?

@ejweber
Dear Eric,
No I didn't tried to upgrade (yet) to Cilium 1.15.1. I'll try soon.

authors: ejweber eltorio


text:
Upgrading from v0.5.0 to v0.6.2 all volumes disappeared

I have longhorn installed under apps in rancher. Before upgrading I made sure to detach all volumes. Then I upgraded the chart from 0.5.0 to 0.6.2. After the upgrade I noticed that the longhorn-system namespace no longer had any pods corresponding to volumes and the longhorn UI shows no volumes as well. I checked /var/lib/rancher/longhorn on the nodes and some replicas are still there.
I tried a rollback to 0.5.0 but that didn't fix it. I tried reupgrading to 0.6.2 but had issues with the driver deployer. I followed #755 to fix this. In the ended, I completeley removed longhorn and reinstalled in order to restore from backups.
I guess I already fixed my issue by restoring from backups but just thought I'd report it anyway.

Version: v0.5.0
Version: v0.6.2

What's your Rancher version when you upgrade your Longhorn?
Did you experience the upgrade/rollback failure like #755 before the volume disappeared?

I am suspecting you may trigger the bug #783: the Longhorn uninstaller is launched and all Longhorn volumes will be deleted.

I was on Rancher v2.2.4
The first time there was no issue with the upgrade itself. #775 happened after the volumes disappeared and I attempted to rollback.

The volumes definitely disappeared during the upgrade. That somehow the uninstaller got triggered would explain it. I wish I could provide more debug information but I needed the cluster back and running so I reset everything and restored from backups.

authors: NchemIcaLS shuo-wu


text:
[BUG] RWX pod stuck in hanging forever after a node shutdown/reboot

Describe the bug
This ticket is related to https://github.com/longhorn/longhorn/issues/8999 . In that ticket, @c3y1huang attempted to fix the RWX service cleanup logic.
However, looks like the latest master-head still delete the rwx service. It will do it whenever there is no share-manager pod https://github.com/longhorn/longhorn-manager/blob/b615732bc75d5513a7f3289a667af1f06a55af1d/controller/setting_controller.go#L342-L355
This is problematic because during node reboot there is a moment there is no share-manager pod -> Longhorn manager delete the service -> Then it create a new service one -> share-manager pod is recreated -> existing clients still use old service ip -> client is hang forever -> kubelet might also hang and no new RWX pod can be created on the same node
@ejweber @james-munson and I discussed and have some ideas on top of our heads:

Don't cleanup RWX service if the setting SettingNameStorageNetworkForRWXVolumeEnabled has not changed
The cleanup logic here		    // Perform cleanup of the share manager Service
		    // This is to allow the creation of the correct Service
		    // and Endpoint when switching between cluster network
		    // and storage network.
		    if err := sc.cleanupShareManagerServiceAndEndpoints(); err != nil {
			    return err
		    }

should only be executed conditionally if		    if err := sc.updateCNI(sc.ds.AreAllRWXVolumesDetached); err != nil {
			    return err
		    }

actually did anything.
Or it may be better to change the RWX detachment check? We want to verify that there are no remaining NFS clients. If there are no more Kubernetes VolumeAttachments, then this is the case. Simply checking if the underlying Longhorn volume is detached doesn't necessarily help.

Environment

Longhorn version: master-head

To further clarify, the issue affects RWX volumes that DON'T use a storage network. Clients for these volumes still reference the ClusterIP of the service, which changes when the service is deleted.
The fix to https://github.com/longhorn/longhorn/issues/8999 assumes it is safe to delete the service when there are no more share manager pods, but this is not a good indicator that there are no NFS clients. In @PhanLe1010's example, killing a node leads Longhorn to delete a share manager pod and detach its underlying volume. However, from a Kubernetes perspective, the RWX volumes is still attached to many nodes/workloads and NFS clients are still running. As a result, this is NOT a safe time to delete the service.

Verification passed on master-head (longhorn-manager 2697ea5) and v1.7.x-head (longhorn-manager 3bc35a5). RWX workload pods can recover after a node reboot.

authors: PhanLe1010 ejweber yangchiu


text:
Main Function of this project

Hi, which file is the main function of go-loom? Not all open source?
Thanks.

Who can reply me?

You can ask questions like these in our Telegram group https://t.me/LoomSDK

Sorry, I can't access the Telegram as I am in China. could you please tell me which file the main function of go-loom here?

authors: enlight grandbaiyi

repo: loomnetwork/go-loom


text:
New feature: Resolve DNS names

Under the Scan agent settings in phpipam, there are scans that can be enabled.

This provider supports Host Check and Discover new host with these attributes:
include_in_ping        = true
host_discovery_enabled = true

My feature request would be to support the option of enabling resolving of DNS names.

@pavel-z1 what do you think? Will this be possible to implement?

Hi @sjurtf
I checked phpIPAM documentation https://phpipam.net/#subnets
Seems phpIPAM don't have resolveDNS parameter for subnet API controller or this parameter not documented.
If you provide example of phpIPAM API usage which activate resolve DNS names option I guess we could add it.

Hi,
you are right - it is missing from the documentation.
We are running phpipam 1.5.3 and the resolveDNS is present in the API and it is working as expected when I tested it now.
Working notes:
When I call /api//subnets/ the response includes a field named resolveDNS set to "1" which matched my expectations and the GUI setting.
I tried to modify it with PATCH, and I was able to confirm that it changed the Resolve DNS names setting in the GUI.
curl --request PATCH \
  --url https://<redacted>/api/<appid>/subnets/<subnetid> \
  --header 'Content-Type: application/json' \
  --header 'token: X' \
  --data '{"resolveDNS": "1"}'

Hi @sjurtf
Feature was added in this PR https://github.com/lord-kyron/terraform-provider-phpipam/pull/65
Added subnet parameter - resolve_dns

authors: lord-kyron pavel-z1 sjurtf

repo: lord-kyron/terraform-provider-phpipam


text:
Autoplay doesn't work

Autoplay doesn't work on IOS release build (reproduce on IPhone 12 Pro Max, but not on IPhone X with the same IOS version 15.5). Autoplay works on the iOS simulator, but if I move app to background and open again animation does not autoplay. It's very stranger issue, may be related to device performance, looks like in some case auto play trigger little bit earlier than it needed, it's just my prediction.
@emilioicai Repo with reproducible demo app -> https://github.com/tarasvakulka/lottie-example-app
There are two ways to reproduce:

Just move app to background and open from background again - animation does not autoplay. For comparing, on "lottie-react-native": "4.1.3" this bug doesn't appear.
Build release .ipa and open it on IPhone 12 Pro Max IOS 15.5, immediately after app launch you can see that autoplay doesn't work, because animation doesn't play (I also tested on IPhone X and this way doesn't work for it, only first one with move to background and reopen).

"react": "17.0.2",
"react-native": "0.67.4",
"react-navigation": "3.11.1",
"lottie-react-native": "5.1.3"
"lottie-ios": "3.2.3"

Might be related to https://github.com/lottie-react-native/lottie-react-native/issues/832

authors: Jorundur tarasvakulka

repo: lottie-react-native/lottie-react-native


text:
Volume

Salut Louis,
Est-ce que le volume est retourné correctement pour la Freebox Pop (si c'est ce que tu as ?) ?
androidRemote.on('volume', function (volume){
      console.debug("Volume : " + volume.level + '/' + volume.maximum + " | Muted : " + volume.muted);
  });

Car quand je teste sur ma TV Android, j'obtiens "0/0" pour le volume actuel et maximum, et muted à false tout le temps. Mais comme le volume est géré par ma Freebox Révolution connecté au Home Cinema… c'est peut-être pour ça !

Je viens de faire d'autres tests, et en effet quand la Revolution prend le dessus, ça modifie le volume. Je vais voir pour faire tester ça à des possesseurs de Freebox Pop !


text:
Find fails silently when loadDatabase can't access data file

Steps to reproduce:

Create a test.db
sudo chown root:root test.db
node load.js (see below)

var db = new (require('nedb'))('test.db');
db.loadDatabase(function(err) {
        console.log('load error', err);
});
db.find({}).exec(function(err, res) {
        console.log('find error', err);
        console.log(res);
});

Now while "load error" is shown (though actually it's a write error), the "find error" is never shown because the callback is never called. Of course, the database is in invalid state due to the loading error, still I think the callback in exec should be executed. The error could be something like 'database in wrong state'.

Actually that's not the case, as the find didn't fail, it was simply never executed because the loadDatabase failed. It has been queued in the executor though and will be executed upon a successful loadDatabase.
I've updated the readme to reflect this non trivial behavior.

authors: louischatriot ziacik

repo: louischatriot/nedb