text:
Feat(web-react): Introduction of Header and HeaderDialog #DS-425

Introduction of Header & HeaderDialog component for React DS-425
What was done:

components and subcomponents:

Header (HeaderModern)
HeaderButton
HeaderDesktopActions
HeaderDialog
HeaderDialogActions
HeaderDialogButton
HeaderDialogCloseButton
HeaderDialogLink
HeaderDialogNav
HeaderDialogNavItem
HeaderDialogText
HeaderLink
HeaderMobileActions
HeaderNav
HeaderNavItem

Stories for development
Tests for each component & subcomponent
Documentation

TODO:

Move to the current Header folder and move the current contents of the folder to the deprecated directory
Click handlers and events
Finish documentation
Tests

I am still not sure how to deal with the name and the deprecation. I am not happy with Modern as it is time-changing. What is modern now, won't be modern in the future. Another version of the Header would be called what? :) I am not bringing any new suggestions, but we could probably discuss this on Slack or in person tomorrow. Also, this is related to the deprecation of the previous Header. I am keen to learn @literat suggestions as the easiest solution would be to remove the old variant and keep only the "modern" one, but that would be a BC. One thing is that probably no one actually uses the old header in react, but we should keep up with our principles.

@crishpeen This was my whole idea and we consulted this with @tomassychra together. This is the same problem we have with Modal and ModalComposed. As @tomassychra suggested also use HeaderComposed, I refused this name because the Header implementation is similar to the old one but only uses the Dialog component. And HeaderDialog is already a sub-component 🤷♂. So I came up with the Modern suffix. In v1 this will be renamed the same way as in Modal. But we are open to any better idea.
Also as you wrote earlier, we are trying to keep with our principles of deprecating things.

I am suggesting rewording the docs fix commit to Docs(...): Fix nesting level of Header table of contents.

I am suggesting rewording the docs fix commit to Docs(...): Fix nesting level of Header table of contents.

But i was not only nesting

I am still not sure how to deal with the name and the deprecation. I am not happy with Modern as it is time-changing. What is modern now, won't be modern in the future. Another version of the Header would be called what? :) I am not bringing any new suggestions, but we could probably discuss this on Slack or in person tomorrow. Also, this is related to the deprecation of the previous Header. I am keen to learn @literat suggestions as the easiest solution would be to remove the old variant and keep only the "modern" one, but that would be a BC. One thing is that probably no one actually uses the old header in react, but we should keep up with our principles.

@crishpeen This was my whole idea and we consulted this with @tomassychra together. This is the same problem we have with Modal and ModalComposed. As @tomassychra suggested also use HeaderComposed, I refused this name because the Header implementation is similar to the old one but only uses the Dialog component. And HeaderDialog is already a sub-component 🤷♂. So I came up with the Modern suffix. In v1 this will be renamed the same way as in Modal. But we are open to any better idea.
Also as you wrote earlier, we are trying to keep with our principles of deprecating things.

OK. So @tomassychra  please properly describe this in the Readme. Why the suffix, what is deprecated and what to expect in the next version. Thanks!

I am suggesting rewording the docs fix commit to Docs(...): Fix nesting level of Header table of contents.

But it was not only nesting

Well, that is the problem. From that commit message, I did not understand what was changed. A few hours ago I saw there were only updated readmes. Now there is a little bit messy. There are tsx files and other changes that do not belong to this commit type. Please, check carefully what happened.

authors: crishpeen literat tomassychra

repo: lmc-eu/spirit-design-system


text:
Develop 0 9 3

Input outputs in housekeeping work both ways...
I will also try to make a widget for the HK

Codecov Report

Merging #330 into master will decrease coverage by 1.89%.
The diff coverage is 27.17%.

@@            Coverage Diff            @@
##           master     #330     +/-   ##
=========================================
- Coverage   35.53%   33.64%   -1.9%
=========================================
  Files          97       98      +1
  Lines       11261    11391    +130
=========================================
- Hits         4002     3832    -170
- Misses       7259     7559    +300

Impacted Files
Coverage Δ

pyrpl/widgets/module_widgets/spec_an_widget.py
16.87% <ø> (ø)
:arrow_up:

pyrpl/acquisition_module.py
35.86% <ø> (-5.44%)
:arrow_down:

pyrpl/test/test_hardware_modules/test_na_iir.py
9.3% <ø> (ø)
:arrow_up:

pyrpl/hardware_modules/iir/__init__.py
100% <ø> (ø)
:arrow_up:

pyrpl/software_modules/lockbox/stage.py
48.68% <ø> (ø)
:arrow_up:

pyrpl/widgets/module_widgets/na_widget.py
14.79% <ø> (ø)
:arrow_up:

pyrpl/widgets/module_widgets/__init__.py
100% <ø> (ø)
:arrow_up:

pyrpl/widgets/module_widgets/lockbox_widget.py
15.74% <ø> (+0.12%)
:arrow_up:

pyrpl/hardware_modules/pid.py
48.95% <ø> (ø)
:arrow_up:

pyrpl/widgets/module_widgets/base_module_widget.py
25.4% <ø> (ø)
:arrow_up:

... and 38 more

Continue to review full report at Codecov.

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

Sorry for the persistent bugs with pyrpl_async. It's a real pain in the #.*@ to debug this in all python versions. I believe that your bugfix for python3.6 was still causing some troubles. It looks like it should be OK now in 87cd3f152b84cf3a7be26b1e93a34aa91cf6681e. At least, now in python3.6:

launching with the gui a run_continuous or run_single on scope and NA works.
Pressing calibrate in the input of a lockbox works (there is a call to single() behind a slot)
typing scope.single() and scope.single_async() in the notebook works as well.
Since the code change should be invisible for all other python versions, we should be fine now...

This is way too old, I'll close this and we'll open another one.

source: gharchive/pull-request

authors: SamuelDeleglise codecov-io lneuhaus

repo: lneuhaus/pyrpl

license: mit

license_type: permissive

license_source: bigquery


text:
How do I limit the size of my data directory？After the cluster is started, the example-data directory generated by the node startup directory occupies 140MB. How can I limit the initial size of this directory

Note: for reported bugs, please fill in the following details. bug reports without detailed steps on how to reproduce will be automatically closed.

How do I limit the size of my data directory？After the cluster is started, the example-data directory generated by the node startup directory occupies 140MB. How can I limit the initial size of this directory
Dragonboat version
Expected behavior
Actual behavior
Steps to reproduce the behavior

It is used by pre-allocated files generated by pebble.
See LogDBConfig in config.

source: gharchive/issue

repo: lni/dragonboat

license_source: github-api


text:
auth: ensure that userId and user name are unique among team members

I added validations to check if the userId and user name are unique when a new member is admitted. The validation fails if another team member already uses the same userId or (case-insensitive) userName. I hope it helps with #72. I confess that I haven't thought about the tricky part of concurrency though.

Thanks, Michael! I do want to think through the concurrency issue so we can handle conflicts in a principled way, but this is an improvement over the status quo so I'll go ahead and merge it.

authors: HerbCaudill michaelkamphausen

repo: local-first-web/auth

license: MIT


text:
When  support the web version

Is your feature request related to a problem? Please describe.
Thank you for your extraordinary work~ First time I know there is such a software!
I would like to ask if there is any plan to support the web version? When will it be available?
Thanks again for your work!
Describe the solution you'd like
Thank you for your extraordinary work~ First time I know there is such a software!
I would like to ask if there is any plan to support the web version? When will it be available?
Thanks again for your work!
Describe alternatives you've considered
No response
Additional context
No response

There will most likely never be a web version unless someone generous builds a web app. For now, I would recommend using https://snapdrop.net/.

authors: Magnusretrotech orzuzro

repo: localsend/localsend


text:
Feature request

Is your feature request related to a problem? Please describe.
安装后默认情况下采用HTTPS加密模式，会导致速度严重降低
Describe the solution you'd like
默认取消加密，第一次安装后可以通过弹窗提醒用户是否开启加密模式
Describe alternatives you've considered
No response
Additional context
No response

Not a good idea to leave data transfer unencrypted.

READ THIS BEFORE POSTING AN ISSUE #528
Please use English

I have read all the issues, this is to be done by ios users can access's
the file, the file is encrypted so..
Issue closed #2415 resolved.. please assign the developer engineer to
resolve the issue.. so leaving here for some issues rest will be done by
tomorrow
On Sun, 29 Dec 2024 at 3:23 PM, Gabriele Cabrini @.***>
wrote:

READ THIS BEFORE POSTING AN ISSUE #528
https://github.com/localsend/localsend/issues/528
Please use English
—
Reply to this email directly, view it on GitHub
https://github.com/localsend/localsend/issues/2157#issuecomment-2564670626,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BLHMSJPWB5OG2TBPHAANFQL2H7BAPAVCNFSM6AAAAABUCQLL6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGY3TANRSGY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

#2415 Issue resolved by my end. There was bug in file.The light was
blinking in software tester department. Please update as soon as possible.
So i kind update to team.
On Sun, 29 Dec 2024 at 3:28 PM, Saurabh Tripathi <
@.***> wrote:

I have read all the issues, this is to be done by ios users can access's
the file, the file is encrypted so..
Issue closed #2415 unresolved.. please assign the developer engineer to
resolve the issue.. so leaving here for some issues rest will be done by
tomorrow.
On Sun, 29 Dec 2024 at 3:23 PM, Gabriele Cabrini @.***>
wrote:

READ THIS BEFORE POSTING AN ISSUE #528
https://github.com/localsend/localsend/issues/528
Please use English
—
Reply to this email directly, view it on GitHub
https://github.com/localsend/localsend/issues/2157#issuecomment-2564670626,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BLHMSJPWB5OG2TBPHAANFQL2H7BAPAVCNFSM6AAAAABUCQLL6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGY3TANRSGY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

authors: SomeRandomCpu Yjl-Flashlightning gabrielecabrini saurabh12453


text:
Feature request: Quite a strange behavior with the selected file after transferring it in Single recipient mode

Is your feature request related to a problem? Please describe.
I also noticed that when sending to a Single recipient, the file remains selected after the transfer. I saw that this was intended, but it only works on the phone. When transferring through the app on Windows, the file is deselected after the transfer.
This is a somewhat strange default behavior that I couldn't understand. Why leave the file selected after transferring it to the phone? If it's to transfer it again to another device, then that's what the Multiple recipients mode is designed for. The most common use case is probably still transferring a file to a single recipient. Therefore, it would be much more convenient to deselect the file after the transfer, because if you need to transfer another file that you forgot about, you'll have to manually deselect the previous file to avoid transferring it again. I personally ran into this situation today.
Describe the solution you'd like

Describe alternatives you've considered
No response
Additional context
No response

What kind of files did you sent? This may be related to #293

In my case, it's media files, namely images.

What LocalSend version do you use on Windows?

What LocalSend version do you use on Windows?

The latest version of the program is 1.8.0 (27) and it is the same on both the phone and the computer.
But the issue with selection occurs not when send from computer to phone, but the other way around, from phone to computer.
If send from the computer to the phone, the selection disappears after the transfer, but if from the phone to the computer, it does not.

What LocalSend version do you use on Windows?

Tomorrow I'll try to send file it from another Android device with a different OS and version. Maybe it's not affecting all of them.

What LocalSend version do you use on Windows?

Tomorrow I'll try to send file it from another Android device with a different OS and Android version. Maybe it's not affecting all of them.

What LocalSend version do you use on Windows?

I confirm that this is a local problem, specifically some kind of glitch, as everything works fine when send from another device.
It can be resolved by simply reinstalling the application on the device and clearing its data and cache.
And the selection not disappears because for some reason the device connection page itself was not displayed (see screenshot), and the transfer was made directly from the Send tab.
Therefore, you can close this issue.

Thanks!


text:
Added Korean translation

Added Korean(ko-KR) language to the website.

Thank you

repo: localsend/website


text:
When I start lt, it prints out a URL but then exits immediately after

Doesn't print any message about why. I'm running Docker within a traefik network for my proxied endpoint, so I'm using the --local-* flags in order to accomplish that. This was working no more than a week ago.
I tried running a basic proxy with the command lt --port 8001 and that worked as expected. So this seems to be something to do with the --local-* flags. But this was working well for me previously. I haven't changed the args either.
This is the command that isn't working now:
lt \
  --local-host domain.local \
  --local-https true \
  --local-cert ~/docker/traefik/certs/domain-cert.pem \
  --local-key ~/docker/traefik/certs/domain-key.pem \
  --local-ca ~/.local/share/mkcert/rootCA.pem \
  --port 443 \
  --print-requests

lt --version is 2.0.2. System is Void Linux. Not sure what else I need to include.

Seems the issue is with the localhttps/ca/key arguments.
This fixed the issue for me.
https://github.com/localtunnel/localtunnel/issues/472#issuecomment-1447562993

Seems the issue is with the localhttps/ca/key arguments.
This fixed the issue for me.
https://github.com/localtunnel/localtunnel/issues/472#issuecomment-1447562993

Seems the issue is with the localhttps/ca/key/cert arguments.
This fixed the issue for me.
#472 (comment)

thanks. I'll check that out.

i'm not sure why i had to do it, but by adding --allow-invalid-cert true to the args, my problem went away. will close the issue.

Just FYI for anyone that comes looking, add environment variable DEBUG=localtunnel:client to debug errors.

authors: ItsMeKoder ShaneBurkhart mattbarnicle

repo: localtunnel/localtunnel


text:
Add tile.interpretAs UDF

Create UDF to implement geotrellis.raster.Tile > interpretAs

possible naming rf_interpret_cell_type_as

authors: jtnachbar vpipkt

repo: locationtech/rasterframes


text:
WORLD and LOCAL_WORLD_ALIGNED reference for force / impulse cost functions

It is important to allow users to define various reference for contact force / impulse cost functions as well. This will require tricky conversion of forces --and their derivatives-- from LOCAL to WORLD and LOCAL_WORLD_ALIGNED. Note that our contact dynamics computes everything at the LOCAL level.
This task could be done potentially done inside Pinocchio (i.e. the new contact dynamics). @proyan, @jcarpent  have you though about it? Could you add this in the new contact dynamics of Pinocchio? or do we need to handle it here?
In any case, @jcarpent could you help me with this task?

This is handled in #1123.


text:
Updated request event with context

Add a single event thats triggered both on request succes/failure #1724
This new event can contain metadata (called context) which can be specified when performing the request.

Got some errors in the build there, but other than that (and my comments) it looks good.
Oh, and dont forget to update the xmlrpc example (both in examples/ and in extending-locust.rst)

Oh, and write something clever in changelog.rst

authors: DennisKrone cyberw

repo: locustio/locust


text:
Programmatic access to urls

Addressing #22

lgtm!

authors: arjunbansal nqn


text:
Binary Data

Has file uploads / binary data been tested with this? Last I've tried, I was unable to get binary data through api gateway.

I have tested binary uploads using multipart/form-data and confirm that it works. Using the lambda-proxy (Serverless 1.0 Default) integration is required. Closing this issue.

authors: khornberg logandk

repo: logandk/serverless-wsgi


text:
kafka sink/source support Kerberos

releases v1.0.0 can not connect to kafka with Kerberos authentication

yep, We use the kafka-go as Kafka client in Loggie, but unfortunately it does not support kerberos for now. So we are considering adding another kafka client, maybe sarama? I'm just working on it.

@ethfoo I think franz-go is the best one currently.

authors: ethfoo michael-oou yuzhichang

repo: loggie-io/loggie


text:
Delete Session Refnum.vi (and maybe others) should respect LVSSH2_NO_EXTENSIONS.

Using the callback event refnums in this VI breaks it on RT targets.

Good catch, thanks for testing it.
I assumed that undefined refnums are safe to keep in the code.
So RT targets do not support event refnums at all?

They do support event refnums.
I believe the data type associated with the event refnum is unsupported on linux targets.
I will check this tomorrow and get back to you on that.

Unsurprisingly the VI breaks because the .NET palette is unavailable on Linux targets.

The library only uses user events from the Events Palette and all events are created from the extensions library, which is implemented in C++ using unmanaged code. There should be no functionality from the .NET palette.
On my Linux machine it does not appear to be broken. Of course, I'm testing on Linux desktop not RT.
That said, disabling the offending code as you suggested is probably the easiest way to avoid the issue altogether.

As far as I can tell, the unsupported data types, that break the VI for me, are callback event refnums which originate in the Register Event Callback Node.


text:
FloatComponent support min max range

Currently，float type only support rang on [0.0, 1.0], but some parameters have range exceed [0.0, 1.0]  like presence_penalty and frequency_penalty which min is -2. and 2.0.

Hello @loleek,
I'll explore expanding the FloatComponent's range. After reviewing the OpenAI documentation, it aligns with your explanation. Thanks!

authors: Cristhianzl loleek

repo: logspace-ai/langflow


text:
[Doc] Fix formatting and bump to v3.0.7

Fix asciidoc formatting in code samples in preparation for move to --asciidoctor

Published


text:
How do I connect this service remotely?

Do you want to request a feature or report a bug?
Feature
What did you expect to see?
Documentation/How-to for remotely installing and accessing this service

Did you try the Getting Started guide? Did you have issues following that?

Closing this off due to inactivity. Please let me know if you have any additional questions

authors: humblesticker loic-sharma

repo: loic-sharma/BaGet


text:
Does Loki work with native images?

Hey, thanks for the great project :)
I've recently published a blog post on the Spring Blog and I've created the following code to back it up.
The problem is that when the two applications are running together as native images the logs are not being shown in Loki. I haven't debugged this much though but maybe it's a known issue for Loki appender?

Hi @marcingrzejszczak, thanks for reporting this! It's really good to know there are blog posts mentioning Loki4j project.
I'm unaware of any issues regarding native images and haven't tried them myself.
However, I can take a look into this, if you send me any related exceptions, stack traces, or at least an instruction how to build and run your sample project as a native image.

Say no more :) https://github.com/marcingrzejszczak/observability-boot-blog-post/blob/main/BLOG.adoc#running-it-all-together-with-aot-support

Hello, upvoting this. I am also trying to make Loki work with native image.

I've checked GraalVM docs. Looks like for reflection-heavy libs (such as logback) so-called "reachability-metadata" should be provided.
There is a community project graalvm-reachability-metadata where you can publish and share a metadata for a lib. Currently it seems like even the support for logback (which is an upstream project to this one) is sub-optimal: the metadata is published only for 3 outdated versions. So I re-direct you to that project.
I tend to close this issue as it's out-of-scope for Loki4j. It's not about improving the Loki4j codebase, it's about gathering and maintaining some metadata for Loki4j and probably for logback as well. And this is definitely a separate project that I would rather leave up to the community.
Feel free to correct me if I got something wrong.

authors: marcingrzejszczak nehaev patpatpat123


text:
Can I use one of your hacks If i credit you?

on my respository I would use the 'spam open boxes' hack if I credit you in the read.me?
btw thanks for showing me how to use the box spam open hack :)

just fork it and then it is yours

as long as you dont steal my work you are ok

aka saying its yours

ok

authors: Hankypoo7 lol-jude theBlaize

repo: lol-jude/Blooket-Hacks


text:
Song Unavailable

Platform
This bug report concerns: (select all that apply)

[x] Client
[x] Server

Details
Please describe the problem you are having in as much detail as possible:
unable to find songs
Reproducing the Problem
Please include detailed steps to reproduce the problem:
enter the site and search with any amount of letters
Please recognise i have deleted the tab and refreshed

Dupe of #107

ah didnt notice it sorry

authors: TinnyTerr lolPants

repo: lolPants/beatsaver-reloaded

license: ISC


text:
Copy more properties from connection tag to hotspot.

Need to transfer not only onclick property but also other on... properties.

Nice feature! Thanks a lot

authors: Mudin lonelyelk

repo: lonelyelk/krpano-arrows


text:
[TASK] Sync latest RAID1 code base at upstream to longhorn/spdk for development

What's the task? Please describe
Need to have a mechanism to sync upstream works to the longhorn/spdk::raid1 branch, and the downstream work will be in the longhorn branch.
Describe the items of the task (DoD, definition of done) you'd like

[ ] Provide the sync process via a script, then it can be automated later (initially. manual update is fine)

Additional context
ref: #https://github.com/longhorn/longhorn/issues/5256
cc @longhorn/dev-data-plane @yangchiu

@innobead
Are we sure that automatic sync is a good idea? When we will have downstream development this process will have to be made manually because we will have to resolve possible conflicts. And when we will be in production, maybe we want to sync with upstream only when nedded.

@innobead
Are we sure that automatic sync is a good idea? When we will have downstream development this process will have to be made manually because we will have to resolve possible conflicts. And when we will be in production, maybe we want to sync with upstream only when needed.

As I mentioned, manual update is fine at the beginning, we just need a branch periodically updated to ensure it includes pending PRs included like rebalancing, error handling, etc, then our dev branch (longhorn) can base on it. WDYT?

@shuo-wu @derekbit :point_up:

Actually, SPDK development under review in Gerrit that will be necessary for us are:

[ ]  RAID1 read balancing
[ ]  RAID1 degraded mode support
[ ]  RAID remove base bdev
[ ]  RAID suspend/resume I/O
[ ]  RAID how base bdev details in json

@DamiaSan Can you provide the relative Gerrit PR review links? Thank you.

We don't need this anymore. The code will be just based on longhorn/spdk longhorn branch.

authors: DamiaSan derekbit innobead

repo: longhorn/longhorn


text:
[TEST] Upgrade test always failed in master-head

What's the test to develop? Please describe
Like https://ci.longhorn.io/job/public/job/master/job/sles/job/amd64/job/longhorn-upgrade-tests-sles-amd64/458/ or https://ci.longhorn.io/job/public/job/master/job/sles/job/arm64/job/longhorn-2-stage-upgrade-tests-sles-arm64/167/
Probably related to https://github.com/longhorn/longhorn-tests/pull/1277.
In that PR, the wait_for_all_instance_manager_running is changed to check instance_manager instead of instance_manager-e/r. But in upgrade test, the previous version of Longhorn is installed first and it still uses instance_manager-e/r.
Describe the items of the test development (DoD, definition of done) you'd like

Please use a task list for items on a separate line with a clickable checkbox https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists

[ ] item 1

Additional context
Add any other context or screenshots about the test request here.

cc @c3y1huang

Fixed in https://github.com/longhorn/longhorn-manager/pull/1920.

authors: innobead yangchiu


text:
[FEATURE] Update nfs-genesha to 5.x for share manager

Is your feature request related to a problem? Please describe (👍 if you like this request)
Need to ensure RWX e2e works as expected, and also need to review the changelogs compared with the current adopted version to see if any critical fixes we need to pay more attention from function stability perspective.
Describe the solution you'd like
A clear and concise description of what you want to happen
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

@james-munson Where we are?

I have pulled the ganesha V5-stable branch, and applied the longhorn-specific patches.  I have built and tested it against top-of-tree share-manager.
The only thing I need is to push that branch into longhorn/nfs-ganesha, but I don't have privileges to create the branch in that repo.  If you can create a branch, I can push longhorn/nfs-ganesha to push https://github.com/james-munson/nfs-ganesha/tree/longhorn-ganesha-v5-V5.7 to it.
There is a companion PR at https://github.com/longhorn/longhorn-share-manager/pull/113 that shows how it was built for testing, although I will need to modify it to point to the actual longhorn/nfs-ganesha/longhorn-ganesha-v5 when it exists (and has a tag and release made for it.)

Close this ticket because after update nfs-genesha to 5.x, test cases in test_twx.py all passed on master pipeline

AMD64
AMD64 2 stage upgrade
ARM64
ARM64 2 stage upgrade

authors: chriscchien innobead james-munson


text:
[BUG] Backup NFS - Operation not permitted during mount

Describe the bug (🐛 if you encounter this issue)
Setting backupTarget to an NFS store is giving an Operation not permitted error in the UI
I am using a Synology NAS that only supports up to v4.1
# cat /proc/fs/nfsd/versions
+2 +3 +4 +4.1

ash-4.4# cat /etc/exports
/volume2/k8s-backup	10.0.80.0/21(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

My kubernetes nodes are within the subnet above
To Reproduce
Manually exec the mount command from within a longhorn-manager:
$ mkdir -p /mnt/nfs
$ mount -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 <nas url>:/volume2/k8s-backup /mnt/nfs
mount.nfs4: Operation not permitted

Executing the same command directly on a k8s node works fine:
$ sudo mount -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 <nas url>:/volume2/k8s-backup /tmp/nas
$

Expected behavior
NFS should mount
Log or Support bundle
If applicable, add the Longhorn managers' log or support bundle when the issue happens.
You can generate a Support Bundle using the link at the footer of the Longhorn UI.
Environment

Longhorn version: 1.4.2
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Helm / Flux
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: K3s

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

Node config

OS type and version: Ubuntu 22.04
CPU per node: 2
Memory per node: 30GB
Disk type(e.g. SSD/NVMe): NVMe
Network bandwidth between the nodes: 1Gbe

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

Additional context
Add any other context about the problem here.

@adampetrovic
Can you support a support bundle for further investigation?

I have the exact same issue

i also struggle with this issue.. V1.5.1

@ozid @DanielG0721
It looks related to the server or client's permission configuration. Would you able to check  https://longhorn.io/kb/troubleshooting-unable-to-mount-an-nfs-backup-target/?

Hello @derekbit  i checked a bit more and i see this on a tcpdump:

First line is the pod making the request
and second line NFS reply with Operation not permitted so i guess you are right
Find strange this is working on the host itself and not the pod, but after testing on an another privileged pod i have the exact same issue. Ill try to search the issue but on the server side i can only whitelist our IP nothing else

I just notice when the traffic coming from the pod to the NFS server it use as source port a range of unprivileged ports (above 1023),
On the k8s hosts it always use a port below 1023 as source. This is probably why the NFS server answering with Operation not permitted

I just notice when the traffic coming from the pod to the NFS server it use as source port a range of unprivileged ports (above 1023), On the k8s hosts it always use a port below 1023 as source. This is probably why the NFS server answering with Operation not permitted
....
After testing a rule on my gateway to rewrite the source port to use a port between 1-1023 ip daddr (ip nfs server) tcp dport 2049 snat to (my source nat ip) :1-1023 The mount is working :)

@ozid
Cool! We were not aware that it is caused by the port usage in the k8s system.
However, why does it work in most environments?

cc @james-munson

I just notice when the traffic coming from the pod to the NFS server it use as source port a range of unprivileged ports (above 1023), On the k8s hosts it always use a port below 1023 as source. This is probably why the NFS server answering with Operation not permitted
....
After testing a rule on my gateway to rewrite the source port to use a port between 1-1023 ip daddr (ip nfs server) tcp dport 2049 snat to (my source nat ip) :1-1023 The mount is working :)

@ozid Cool! We were not aware that it is caused by the port usage in the k8s system. However, why does it work in most environments without the issue?

I would love to know why also but there is so many ways of doing thing...
Personally i use cilium as CNI without kube-proxy. So maybe the ebpf program rewrite the source port to a random higher range and this is causing the issue.

cc @mantissahz

Hello @dotdiego yes of course, so basically your NFS server expecting your client to  have a source port to be in the privileged port range, in simple term it must be under 1024.
So you must somehow find a way to make sure your client (in this case, the longhorn pod) is making a nfs query with a source port between 1-1023.
In my case, my kubernetes cluster need to go through my gateway server to reach the NFS, good news for me it's fully managed with linux tools so i can manipulate the traffic as i want, this is why i added this line to my gateway:
ip daddr (ip nfs server) tcp dport 2049 snat to (my source nat ip) :1-1023
So after adding this, my gateway rewrite the original source port wich was: 54850 to a random port between 1-1023
Before my command tcpdump was output something like this:
my-longhorn-pod-ip:54850 -> nfs_server-ip:2049 his is not working
After my command on my gateway:
my-longhorn-pod-ip:1022 -> nfs_server-ip:2049 this working
Hope it's more clear for you

@james-munson Please help with the doc as @derekbit mentioned. We need a KB doc.

I stumbled across this as I'm attempting to debug this issue on my own k3s cluster. I'm running into this issue (mount.nfs4: mount(2): Operation not permitted) attempting to mount the NFS backup target from the longhorn manager container. This appears to be working without issue on Ubuntu 22.04, but not Debian 12. Apparmor is disabled, so to not add any complications. From the underlying host, I can mount fine, but not within the longhorn-manager container.
k exec -it -n longhorn-system longhorn-manager-m7ph7 -- sh
sh-4.4# showmount -e 192.168.0.151
Export list for 192.168.0.151:
/volume1/LonghornBackupstore 10.32.0.0/12,192.168.0.34,192.168.0.33,192.168.0.32,192.168.0.31

sh-4.4# ip a sh eth0
127: eth0@if128: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 56:ae:93:a9:e1:96 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.32.2.86/32 scope global eth0
       valid_lft forever preferred_lft forever

sh-4.4# mount -v -t nfs4 -o nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2 192.168.0.151:/volume1/LonghornBackupstore /var/lib/longhorn-backupstore-mounts/192_168_0_151/volume1/LonghornBackupstore
mount.nfs4: timeout set for Sun Jan  7 17:07:16 2024
mount.nfs4: trying text-based options 'nfsvers=4.1,actimeo=1,soft,timeo=300,retry=2,addr=192.168.0.151,clientaddr=10.32.2.86'
mount.nfs4: mount(2): Operation not permitted
mount.nfs4: Operation not permitted for 192.168.0.151:/volume1/LonghornBackupstore on /var/lib/longhorn-backupstore-mounts/192_168_0_151/volume1/LonghornBackupstore

Nothing is logged in dmesg. I'm also using the most updated kernel in Debian 12 stable (6.1.0-17-amd64). CNI plugin is also Cilium 1.14.5, and I can see that traffic from the longhorn-manager pod has a source port < 1024.
k exec -n kube-system cilium-jxfqt -- cilium monitor -n | grep 192.168.0.151
...
Policy verdict log: flow 0x614bba26 local EP ID 1360, remote ID 16777263, proto 6, egress, action allow, auth: disabled, match L3-Only, 10.32.2.86:842 -> 192.168.0.151:2049 tcp SYN
-> network flow 0x614bba26 , identity 67641->16777263 state new ifindex eth0 orig-ip 0.0.0.0: 10.32.2.86:842 -> 192.168.0.151:2049 tcp SYN
-> endpoint 1360 flow 0x0 , identity 16777263->67641 state reply ifindex lxcd72247c18a9c orig-ip 192.168.0.151: 192.168.0.151:2049 -> 10.32.2.86:842 tcp SYN, ACK
-> network flow 0x614bba26 , identity 67641->16777263 state established ifindex eth0 orig-ip 0.0.0.0: 10.32.2.86:842 -> 192.168.0.151:2049 tcp ACK
...

I will submit a support bundle as well.

authors: DanielG0721 adampetrovic derekbit innobead npawelek ozid


text:
[BUG] [v1.5.4 GA] Enable V2 data engine make instance-manager restarting

Describe the bug
Deploy v1.5.4 with GA images then enable v2 data engine. instance-manager kept restarting, Did not see in v1.5.4-rc4

longhorn-system   instance-manager-9010be71f4e2bccd3f8a527ee245f557   0/1     Terminating         0             17s
longhorn-system   instance-manager-9010be71f4e2bccd3f8a527ee245f557   0/1     Terminating         0             17s
longhorn-system   instance-manager-9010be71f4e2bccd3f8a527ee245f557   0/1     Pending             0             0s
longhorn-system   instance-manager-9010be71f4e2bccd3f8a527ee245f557   0/1     ContainerCreating   0             0s
longhorn-system   instance-manager-c626bd383b0b8c4e944b4b0e6bfd82df   0/1     Error               0             17s
longhorn-system   instance-manager-c626bd383b0b8c4e944b4b0e6bfd82df   0/1     Terminating         0             17s
longhorn-system   instance-manager-c626bd383b0b8c4e944b4b0e6bfd82df   0/1     Terminating         0             17s
longhorn-system   instance-manager-c626bd383b0b8c4e944b4b0e6bfd82df   0/1     Pending             0             0s
longhorn-system   instance-manager-c626bd383b0b8c4e944b4b0e6bfd82df   0/1     ContainerCreating   0             0s
longhorn-system   instance-manager-9010be71f4e2bccd3f8a527ee245f557   1/1     Running             0             1s
longhorn-system   instance-manager-c626bd383b0b8c4e944b4b0e6bfd82df   1/1     Running             0             1s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   0/1     Error               0             16s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   0/1     Error               0             17s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   0/1     Terminating         0             17s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   0/1     Terminating         0             17s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   0/1     Pending             0             0s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   0/1     ContainerCreating   0             0s
longhorn-system   instance-manager-915482c41fa1a01a1824677c21bb9795   1/1     Running             0             1s

To Reproduce

Install v1.5.4-GA (No matter by helm or by kubectl)
Enable v2 data engine
instance-manager kept restarting, add block disk fail

Expected behavior
Instance-manager running, add block disk success
Support bundle for troubleshooting
supportbundle_cd68f6ff-6f76-45a5-ab42-9a434de4b526_2024-02-27T13-59-36Z.zip
Environment

Longhorn version: v1.5.4 GA
Impacted volume (PV): N/A
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Helm and kubectl
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: v1.28.5+k3s1
Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): AWS
Number of Longhorn volumes in the cluster: 0

Additional context
N/A

@derekbit Please help check this?

For longhorn-manager, the change between the GA candidate with RC4.

https://github.com/longhorn/longhorn/issues/7878#issuecomment-1966519988
https://github.com/longhorn/longhorn-manager/commit/11a0f25f971adc4a8c24d0d30ec8e63403392f10

from @derekbit suspecting a package issue from the IM image.
2024-02-27T13:59:51.009397364Z Enabling tgtd
2024-02-27T13:59:51.009883651Z Enabling spdk_tgt with options:
2024-02-27T13:59:51.012943786Z spdk_tgt: error while loading shared libraries: libnuma.so.1: cannot open shared object file: No such file or directory
2024-02-27T13:59:51.014689467Z tgtd: work_timer_start(146) use timer_fd based scheduler
2024-02-27T13:59:51.014702672Z tgtd: bs_init(387) use signalfd notification
2024-02-27T13:59:51.039490192Z time="2024-02-27T13:59:51Z" level=info msg="Storing process logs at path: /var/log/instances" func=util.SetUpLogger file="log.go:63"
2024-02-27T13:59:51.039516390Z [longhorn-instance-manager] time="2024-02-27T13:59:51Z" level=warning msg="Failed to add TLS key pair from /tls-files/" func=cmd.start file="start.go:120" error="open /tls-files/tls.crt: no such file or directory"
2024-02-27T13:59:51.039532060Z [longhorn-instance-manager] time="2024-02-27T13:59:51Z" level=info msg="Creating gRPC server with no auth" func=cmd.start file="start.go:127"
2024-02-27T13:59:51.039683908Z [longhorn-instance-manager] time="2024-02-27T13:59:51Z" level=info msg="Disk Server: Creating SPDK client since SPDK is enabled" func=disk.NewServer file="disk.go:48"

libnuma packages were missed. Rebuild 1.5.4 IM image to see if the package issue will be fixed.
$ docker run -it --entrypoint /bin/bash longhornio/longhorn-instance-manager:v1.5.4
77b82b9e10d6:/ # zypper install -y libnuma-devel nasm
Refreshing service 'container-suseconnect-zypp'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 3 NEW packages are going to be installed:
  libnuma-devel libnuma1 nasm
The following 3 packages are not supported by their vendor:
  libnuma-devel libnuma1 nasm
3 new packages to install.
Overall download size: 466.4 KiB. Already cached: 0 B. After the operation, additional 3.1 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving: libnuma1-2.0.14.20.g4ee5e0c-150400.1.24.x86_64 (SLE_BCI)                                                                                (1/3),  31.8 KiB
Retrieving: libnuma1-2.0.14.20.g4ee5e0c-150400.1.24.x86_64.rpm ..........................................................................................................................................................................[done]
Retrieving: nasm-2.15.05-150500.1.2.x86_64 (SLE_BCI)                                                                                (2/3), 406.6 KiB
Retrieving: nasm-2.15.05-150500.1.2.x86_64.rpm ..............................................................................................................................................................................[done (8.0 KiB/s)]
Retrieving: libnuma-devel-2.0.14.20.g4ee5e0c-150400.1.24.x86_64 (SLE_BCI)                                                                                (3/3),  28.0 KiB
Retrieving: libnuma-devel-2.0.14.20.g4ee5e0c-150400.1.24.x86_64.rpm ........................................................................................................................................................[done (28.0 KiB/s)]
Checking for file conflicts: ............................................................................................................................................................................................................[done]
(1/3) Installing: libnuma1-2.0.14.20.g4ee5e0c-150400.1.24.x86_64 ........................................................................................................................................................................[done]
(2/3) Installing: nasm-2.15.05-150500.1.2.x86_64 ........................................................................................................................................................................................[done]
(3/3) Installing: libnuma-devel-2.0.14.20.g4ee5e0c-150400.1.24.x86_64 ...................................................................................................................................................................[done]
77b82b9e10d6:/ #

After rebuilding the image, spdk_tgt works well after enabling v2 data engine
╰─$ kl logs instance-manager-c6c31c104ad17da991e0c9885616d84c -f
Enabling tgtd
Enabling spdk_tgt with options:
tgtd: work_timer_start(146) use timer_fd based scheduler
tgtd: bs_init(387) use signalfd notification
time="2024-02-27T15:20:04Z" level=info msg="Storing process logs at path: /var/log/instances" func=util.SetUpLogger file="log.go:63"
[longhorn-instance-manager] time="2024-02-27T15:20:04Z" level=warning msg="Failed to add TLS key pair from /tls-files/" func=cmd.start file="start.go:120" error="open /tls-files/tls.crt: no such file or directory"
[longhorn-instance-manager] time="2024-02-27T15:20:04Z" level=info msg="Creating gRPC server with no auth" func=cmd.start file="start.go:127"
[longhorn-instance-manager] time="2024-02-27T15:20:04Z" level=info msg="Disk Server: Creating SPDK client since SPDK is enabled" func=disk.NewServer file="disk.go:48"
[2024-02-27 15:20:04.046950] Starting SPDK v23.05-pre git sha1 69f656824 / DPDK 22.11.1 initialization...
[2024-02-27 15:20:04.047008] [ DPDK EAL parameters: spdk_tgt --no-shconf -c 0x1 --huge-unlink --log-level=lib.eal:6 --log-level=lib.cryptodev:5 --log-level=user1:6 --iova-mode=pa --base-virtaddr=0x200000000000 --match-allocations --file-prefix=spdk_pid12 ]
TELEMETRY: No legacy callbacks, legacy socket not created
[2024-02-27 15:20:04.160697] app.c: 738:spdk_app_start: *NOTICE*: Total cores available: 1
[2024-02-27 15:20:04.184774] reactor.c: 937:reactor_run: *NOTICE*: Reactor started on core 0
[2024-02-27 15:20:04.192480] accel_sw.c: 601:sw_accel_module_init: *NOTICE*: Accel framework software module initialized.
[longhorn-instance-manager] time="2024-02-27T15:20:05Z" level=info msg="Instance Manager disk gRPC server listening to 0.0.0.0:8502" func=cmd.start file="start.go:149"
[longhorn-instance-manager] time="2024-02-27T15:20:05Z" level=info msg="Instance Manager instance gRPC server listening to 0.0.0.0:8503" func=cmd.start file="start.go:164"
[longhorn-instance-manager] time="2024-02-27T15:20:05Z" level=info msg="Instance Manager proxy gRPC server listening to 0.0.0.0:8501" func=cmd.start file="start.go:178"
[longhorn-instance-manager] time="2024-02-27T15:20:05Z" level=info msg="Instance Manager process manager gRPC server listening to 0.0.0.0:8500" func=cmd.start file="start.go:193"
[longhorn-instance-manager] time="2024-02-27T15:20:05Z" level=info msg="Instance Manager SPDK gRPC server listening to 0.0.0.0:8504" func=cmd.start file="start.go:208"

Close this as @derekbit has already verified it. It appears to be an uncertain build issue with the image's package manager.
@chriscchien reopen if this is still an issue stuck in our final testing of 1.5.4.

authors: chriscchien derekbit innobead


text:
Error: Validation Failed: "already_exists"

I am running into a bit of a snag when setting up the changelog action on one of my repositories. I had previously created two releases before adding this Action, and it looks like I am hitting the following error:
Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"}

I am sure that this is user error. How should I setup the action to handle this? Here is a link to my workflow.

It seems this error is generated by the action create-release, not tag-changelog. I'm not sure how to help you with this, to be honest. Your workflow seems to be identical to the one from my readme, so that should just work. It's the same config I use in multiple open source projects without problems.
Are you trying to push a tag that already has a matching release? In the error I see the tag v0.1.3, and in your repo I also see a release with that version. So how did you create that release?

I had manually created releases at https://github.com/yngtdd/rusty_dungeon/releases/new, naming both the tag and the release v0.1.3 (similar with the earlier releases).
In the screenshot below, in the Choose a Tag drop down, I created a tag name v0.1.3, then named the Release title below that to v0.1.3. Perhaps I should delete those earlier releases and check the workflow?

Interesting, after deleting the previous releases and their associated tags, I get
Run loopwerk/tag-changelog@v1
  with:
    token: ***
    exclude_types: other,docs,chore
    config_file: .github/tag-changelog-config.js
Error: Couldn't find previous tag

Sorry for my ignorance here. Looks like I need to have an initial tag, but to avoid the previous issue where it was seeing that the tag already exists, should I name it something other than the semver convention?

Well I am sure you can just ignore that error you got initially, and from now on when you push the first new tag (that doesn't already have a release), it shouldn't give an error anymore, right?
So I think you should be good to push tag v0.1.3, ignore any errors, and when you're going to push v0.1.4 (which doesn't have a release), it shouldn't give any errors.
Closing this issue, as I don't think there's a real problem here. Please feel free to open a new issue when your upcoming tag is also going to give errors.

authors: kevinrenskers yngtdd

repo: loopwerk/tag-changelog


text:
Screenshots

Share screenshots of your shaders here:

Unfiltered

Vibrance

Blue Light Filter

ty for this i love it

vibrance | grayscale | blue-light

authors: ChaoticChrono DevHolako loqusion zoovasoup

repo: loqusion/hyprshade


text:
tracker.json defaults saving 25 Bytes on air

A first, partial stop gap solution for issue #56.
Unfortunately, JSON does not provide syntax for comments.

the current config is just an example of what is possible. every ham is responsible for what he is sending out on the frequency.
As I want to show new hams what they can do with this firmware, I will close this PR and will not use it.
But I will add a comment in the documentation to make clear that this values are example values and should be changed.

authors: peterus stroobandt


text:
Adding a callback example for C++ and Python.

Removing un-needed lambda in WalkCow.

Thanks!

authors: ajpmaclean lorensen

repo: lorensen/VTKExamples


text:
They updated app

https://github.com/lostfields/python-panasonic-comfort-cloud/blob/f3975e4070abe1bd959dda6d51571f568de7d592/pcomfortcloud/session.py#L111
new version is working with
['X-APP-VERSION'] = '1.12.0',

Is it possible to get the latest version of the app automatically from the google play store website ( https://play.google.com/store/apps/details?id=com.panasonic.ACCsmart&hl=en&gl=US ) of the app? There is displayed the latest version of the app.

@TomS1985 Google does unfortunately not provide an API to get the latest version of a published app, but Apple does, so I've created a pull request that enabled automatic version detection.

Thx
issue closed

authors: TomS1985 sockless-coding techbliss


text:
fix(web): don't require @dotlottie/react-player to be installed for JSON animations

The current web implementation requires projects to include both @lottiefiles/react-lottie-player and @dotlottie/react-player because they are required in the same try/catch block.
Apps should be able to install either of these depending on whether they need to play .lottie files or not.
This PR separates the requires into separate try/catch blocks so @lottiefiles/react-lottie-player can be installed and used without including @dotlottie/react-player.

Thank you for noticing and catching this!
I've just also spotted this issue and wanted to fix it, but you were first :)

authors: adamhari kosmydel

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


text:
running uptimekuma on synologynas

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
Cannot connect to the socket server. [Error: websocket error] Reconnecting...
Using a Reverse Proxy? Check how to config it for WebSocket
its a fresh install and cant seem to get it working
ive tried to follow the instructions as bests as i can it allows me to add  the service to the web station but still goves me this error and adding the reverse proxy still does not work for synologynas  too any help would be greatful thank you
🐻 Uptime-Kuma Version
latest from docker
💻 Operating System and Arch
windows 11
🌐 Browser
chrome
🐋 Docker Version
synologynas
🟩 NodeJS Version
synologynas

What NAS and what DSM version are you using?

ds1821+ identical to the ds1819+ running dsm DSM 7.1.1-42962 Update 1 current version

Ok, I suggest what I suggested in other topics here regarding Synology, too.
You got a great machine, my recommendation is to run a VM (Debian or Ubuntu) and start uptime-kuma and other dockers in there.
You will have less headache, and for Debian/Ubuntu also a lot of support.
The docker implementation in DSM is just to buggy / complicated in my experience.
You can get things up and running but it is just a pita (pain in the a**).
If you decide to try things in DSM only, this guy here has mastered it; but unfortunately not for uptime-kuma. https://mariushosting.com/docker/

nothing wrong, alls exacpt for the widget in homepage is working here:

No issue on Synology, Everything works as expected.

Ha! The legend himself showed up - keep up the great work / tutorials you do @mariushosting 👍

thank you all sorted it just would not start weird

No issue on Synology, Everything works as expected. https://mariushosting.com/how-to-install-uptime-kuma-on-your-synology-nas/

thank you again

authors: IIIdefconIII mariushosting regchanuk rezzorix

repo: louislam/uptime-kuma


text:
sharp fails to read EXIF from some tiff files.

sharp fails to read EXIF from some tiff files.
Is this a possible bug in a feature of sharp, unrelated to installation?

[x] Running npm install sharp completes without error.
[x] Running node -e "require('sharp')" completes without error.

Are you using the latest version of sharp?

[z] I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?
npx: installed 1 in 3.291s

  System:
    OS: Windows 10 10.0.19045
    CPU: (20) x64 Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz
    Memory: 48.52 GB / 63.71 GB
  Binaries:
    Node: 14.21.3 - C:\Program Files\nodejs\node.EXE
    npm: 6.14.18 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    sharp: ^0.32.1 => 0.32.1

What are the steps to reproduce?
Just open file and get metadata with sharp.metadata(...), there is no exif in metadata, while XMP is perfectly there.
What is the expected behaviour?
Return EXIF data. It is there, exiftool can see it.
Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem
const sharp = require('sharp');
const path = require('path');

let s = new sharp(path.join(__dirname,"test.tiff"));
s.metadata((e,m)=>{
    console.log('Has XMP:', !!m.xmp);
    console.log('Has EXIF:', !!m.exif);
});

Output:
Has XMP: true
Has EXIF: false

Please provide sample image(s) that help explain this problem
test.zip

This file appears to have a "TIFF directory 0" entry, which exiftool can confusingly present as "EXIF", but this is not quite the same as EXIF metadata.
$ tiffinfo test.tiff
TIFFReadDirectory: Warning, Unknown field with tag 40091 (0x9c9b) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 40092 (0x9c9c) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 40094 (0x9c9e) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 59932 (0xea1c) encountered.
=== TIFF directory 0 ===
TIFF Directory at offset 0x5108 (20744)
  Subfile Type: (0 = 0x0)
  Image Width: 157 Image Length: 151
  Resolution: 96, 96 pixels/inch
...

Strangely, it does appear to have a single, 4 byte ExifTag without any offset and with a value of 26176.
$ exiv2 -pS test.tiff
STRUCTURE OF TIFF FILE (II): test.tiff
 address |    tag                              |      type |    count |    offset | value
   20746 | 0x00fe NewSubfileType               |      LONG |        1 |           | 0
   20758 | 0x0100 ImageWidth                   |      LONG |        1 |           | 157
   20770 | 0x0101 ImageLength                  |      LONG |        1 |           | 151
   20782 | 0x0102 BitsPerSample                |     SHORT |        1 |           | 8
   20794 | 0x0103 Compression                  |     SHORT |        1 |           | 5
   20806 | 0x0106 PhotometricInterpretation    |     SHORT |        1 |           | 1
   20818 | 0x010d DocumentName                 |     ASCII |       22 |     23110 | minisblack-1c-8b.tiff
   20830 | 0x010e ImageDescription             |     ASCII |       11 |     23132 | ..........
   20842 | 0x0111 StripOffsets                 |      LONG |        2 |     23144 | 8 11209
   20854 | 0x0115 SamplesPerPixel              |     SHORT |        1 |           | 1
   20866 | 0x0116 RowsPerStrip                 |      LONG |        1 |           | 78
   20878 | 0x0117 StripByteCounts              |      LONG |        2 |     23152 | 11201 9534
   20890 | 0x011a XResolution                  |  RATIONAL |        1 |     23160 | 96000/1000
   20902 | 0x011b YResolution                  |  RATIONAL |        1 |     23168 | 96000/1000
   20914 | 0x0128 ResolutionUnit               |     SHORT |        1 |           | 2
   20926 | 0x0129 PageNumber                   |     SHORT |        2 |           | 0 1
   20938 | 0x0131 Software                     |     ASCII |       65 |     23176 | GraphicsMagick 1.2 unreleased Q1 ...
   20950 | 0x013d Predictor                    |     SHORT |        1 |           | 2
   20962 | 0x0153 SampleFormat                 |     SHORT |        1 |           | 1
   20974 | 0x02bc XMLPacket                    |      BYTE |     2934 |     23242 | <?xpacket begin='...' id='W5M0Mp ...
   20986 | 0x8769 ExifTag                      |      LONG |        1 |           | 26176
   20998 | 0x9c9b XPTitle                      |      BYTE |       12 |     28256 | ".0.9.B.;..
   21010 | 0x9c9c XPComment                    |      BYTE |       32 |     28268 | -.B.>. .:.>.<.<.5.=.B.0.@.8.9..
   21022 | 0x9c9e XPKeywords                   |      BYTE |        8 |     28300 | ".0....
   21034 | 0xea1c                              | UNDEFINED |     2060 |     21050 | ............................... ...
END test.tiff

Well, Windows Explorer have no issues reading and writing EXIF fields in this file. It does not consider it corrupt or anything. Those XPTitle and XPComment were aded by Windows (in file property dialog).

To summarise, the sample image provided contains a TIFF directory that happens to use similar field names as EXIF metadata, and it looks like some tooling will present it in an EXIF-like way, but EXIF it is not. So yes, either ignore or use another tool that can parse TIFF directories if you need this information.

authors: TomaterID lovell

repo: lovell/sharp


text:
[manifest] Improve the quality of errors emitted by the manifest module.

Unfortunately, this does not include thiserror support, because that crate requires std.

@cfrantz I feel like this is a good first PR for you to review. TAL when you get a chance, and feel free to reach out w/ questions.

repo: lowRISC/manticore


text:
[hw, reset_manager] combine multiples of REGEN and RST registers

Observation
Currently we have the following set of REGEN and RST registers:
// Register write enable for spi_device reset.
#define RSTMGR_SPI_DEVICE_REGEN(id) (RSTMGR##id##_BASE_ADDR + 0x4)
#define RSTMGR_SPI_DEVICE_REGEN_REG_OFFSET 0x4
#define RSTMGR_SPI_DEVICE_REGEN_SPI_DEVICE_REGEN 0

// Register write enable for usb reset.
#define RSTMGR_USB_REGEN(id) (RSTMGR##id##_BASE_ADDR + 0x8)
#define RSTMGR_USB_REGEN_REG_OFFSET 0x8
#define RSTMGR_USB_REGEN_USB_REGEN 0

// Software reset control for spi device
#define RSTMGR_RST_SPI_DEVICE_N(id) (RSTMGR##id##_BASE_ADDR + 0xc)
#define RSTMGR_RST_SPI_DEVICE_N_REG_OFFSET 0xc
#define RSTMGR_RST_SPI_DEVICE_N_RST_SPI_DEVICE_N 0

// Software reset control for usb
#define RSTMGR_RST_USB_N(id) (RSTMGR##id##_BASE_ADDR + 0x10)
#define RSTMGR_RST_USB_N_REG_OFFSET 0x10
#define RSTMGR_RST_USB_N_RST_USB_N 0

By the looks of it and the description - these registers have single purpose:

REGEN - "allow/disallow" peripheral to be reset.

RST - "hold/release" peripheral in/from reset.

Question
Would it be reasonable to combine these registers into a single REGEN and single RST register. It then would make it similar to what PLIC peripheral does with the interrupts - single bit for an IRQ source.

@gkelly + @lenary for visibility

I think there's some automatic behaviour about how regen registers work - which may not support compacting the register-enable bits into a single register - but I'm not sure.

yeah i think the idea was to have these registers be individually lockable from a software perspective.  So we may disable the user's ability to issue USB resets, but allow SPI resets.  And yes, I also thought that the regen registers worked on a 1-to-1 basis, and did not allow compacting.
Is the idea behind combining them just cleaner for DIFs and not be so uniquified? Because the clocking stuff is even more unique at the moment...

Is the idea behind combining them just cleaner for DIFs and not be so uniquified? Because the clocking stuff is even more unique at the moment...

I guess from my perspective it is slightly cleaner, but it is not a an issue, was me just wondering. Is it guaranteed that the layout of these registers won't differ (always a single purpose, and always the same offsets for all REGEN and also RST registers)?
Thanks

yes, we can re-arrange them into blocks if that's easier? Ie continuous regen, then continuous resets.
by the way, the reset manager needs to be re-templated for other design reasons, but i don't think that should impact what you have now.
Let me know if you have other ideas on how to make this cleaner / friendlier to software.  We can definitely consider them.  It would be great also if you can have a peek at the reset management doc to see if overall this makes sense to you, and what else you might want to handle differently.

@tjaychen , thank you for your help.
Regarding continuous regen and rst registers, I think it would be cleaner to have them packed - similar to how the IRQ sources are packed for PLIC. My reasoning is:

More consistent - same pattern for repeating 1/multiple bit enable/disable.

It then makes it clear that, different peripheral regen are handled the same way. In case of separate registers, for example, RSTMGR_SPI_DEVICE_REGEN and RSTMGR_USB_REGEN it is not immediately obvious whether the register layout is always meant to be the same for different peripherals.

There is less different register addresses to care about.

Just an opinion, I leave the final decision with you, as there might be good reasons not to pack these signals, and you are in much better position to better evaluate this.

It would be great also if you can have a peek at the reset management doc

Could you please point me at it? I have ran find . -name *rstmgr* in the upstream top directory, and it didn't come up with any .md or doc. There is also no documentation or the development stage information for this peripheral in https://docs.opentitan.org/hw/ .
Thanks again @tjaychen

If we take the alert handler, it uses a single ALERT_HANDLER.REGEN to lock the entire peripheral (or most of it). I wonder whether Reset Manager should do the same thing, or there is a reason why there are multiple regen registers?
https://docs.opentitan.org/hw/ip/alert_handler/doc/index.html

ah yes the separate regwen is intentional, because the expectation is that
resets might be individually disabled.  For example, software may decide to
control a particular peripheral's reset dynamically, but disallow it on
another.
In general, i think software control of resets really should not be
allowed.  However for interfaces such as spi / usb, where the peripheral
may actually lock-up based on bad behavior from the host, it might be good
to leave an emergency exit if required.
if the regtool were enhanced such that regwen were multi-bits and each bit
can apply to one register, that would also solve this problem (i need to
check if regwen already does that).
On Tue, Aug 11, 2020 at 6:01 AM Silvestrs Timofejevs <
notifications@github.com> wrote:

If we take the alert handler, it uses a single ALERT_HANDLER.REGEN to
lock the entire peripheral (or most of it). I wonder whether Reset Manager
should do the same thing, or there is a reason why there are multiple
regen registers?
https://docs.opentitan.org/hw/ip/alert_handler/doc/index.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/issues/3089#issuecomment-671932847,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSQYX3IQPQP5S2OWU7DSAE6MFANCNFSM4PXPMEAQ
.

@cdgori

For the reference, I have a DRAFT DIF Reset Manager PR open in #3093 . Awaiting some header sanity checks from Sam and Garret, and then will do the corresponding changes and promote it to a full PR.

Let's land something with the current register layout, this is an optimisation for later.

@silvestrst
just wanted to circle back to this one.  If you prefer, I think I can combine these into one register as you asked.  Just let me know.

@tjaychen
Unless there is a good reason not to, I would prefer them combined, thanks!

let me have a look today. I think i can still actually achieve the
individual controls by combining.
On Fri, Sep 25, 2020 at 7:20 AM Silvestrs Timofejevs <
notifications@github.com> wrote:

@tjaychen https://github.com/tjaychen
Unless there is a good reason not to, I would prefer them combined, thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/issues/3089#issuecomment-698957459,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSSOVJJN755PAAGWP53SHSRL3ANCNFSM4PXPMEAQ
.

This should be supported now.  Please give it a try and let me know.

okay looks like there are a few issues.
Since rstmgr is a templated module, the target inside meson.build needs to be changed.  However when i update that, the C-header generation then breaks.  I haven't look into that part yet.

okay please see #3602
the rstmgr difs now need some updating :)

@tjaychen apologies for leaving this PR hanging. I will try to fixup the DIF appropriately today.

Sorry for not reading this chain until now.  Your comment

In general, i think software control of resets really should not be
allowed.  However for interfaces such as spi / usb, where the peripheral
may actually lock-up based on bad behavior from the host, it might be good
to leave an emergency exit if required.

matches my expectations / preferences perfectly, since having parts of the device in reset while others are not is usually not desirable (except for the absolutely necessary recovery/emergency exit sequences).

authors: cdgori lenary silvestrst tjaychen

repo: lowRISC/opentitan


text:
[entropy_src/csrng/edn] need a start/stop/start function for the entropy complex blocks

It appears that there are use cases that require the capability to start, then later stop the entropy flow. At that point the blocks would be re-programmed and then re-started again. This is really the difference between the boot-time case and the normal operational case for the entropy complex blocks.

Meeting consensus was that this issue will also need a transactional register lock function, versus the current software global lock.

This got addressed by #6124. I think it can be closed. Can you please confirm @mwbranstad ?
Btw I noted that you usually reference the related issues in your PR title with something like "fixes #xyz". It seems this doesn't work as intended. If you instead put that text in to the PR body two things will happen:

GitHub will recognize the reference and link the corresponding issue. Reviewers can then just hover over the link or click to get to the issue.
If you keep writing "fixes #xyz", then Issue xyz will indeed be closed automatically once the PR gets merged.

@vogelpi correct, This issue was fixed with #6124. I followed guidance earlier to include the "fixes" in the commit message. I actually do not like this, and it doesn't seem to work, as you say. Looking at github pages, it seems they recommend to put this in the body of the comment message, not the title/subject line. I will do this going forward as I think I like this feature.

Based on the above discussion, manually closing this issue.

authors: mwbranstad vogelpi


text:
[sw] Bring back debug symbols in ELF files

ELF files did get their debug symbols stripped by our linker script. That's not really intended; we want to use the ELF files for debugging, and the ELF loader should take care that only required sections will end up being loaded. Thankfully the build id section was already removed with a linker flag, so the linker script part was unnecessary. Revert that commit and add a couple more cleanups along the way.

@silvestrst can you try this PR to see if debugging works for you now?

Note: previous discussion on this was happening in #1002 and #966. The discussion indicates that having only the DISCARD linker file  patch doesn't work, but having only --build-id=none should work (and it does in my testing).

I guess the main point of having DISCARD is to only have the specified sections in the output. So another option would be to explicitly specify that we want to have the debug symbols included by naming them.
But I agree that we need debug symbols.
Default linker script elf32riscv.x does:
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line .debug_line.* .debug_line_end) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* DWARF 3 */
  .debug_pubtypes 0 : { *(.debug_pubtypes) }
  .debug_ranges   0 : { *(.debug_ranges) }
  /* DWARF Extension.  */
  .debug_macro    0 : { *(.debug_macro) }
  .debug_addr     0 : { *(.debug_addr) }
  .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
  /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }

The ELF contents shouldn't matter, as "ELF" is not the "output" format we're caring about; the loader needs to take care to only put relevant sections into memory. The loader in our case (currently) is either the ELF -> VMEM conversion tooling, or the Verilator ELF loader.

But doesn't the ELF content matter as the placement of the sections in ELF will influence the values of relative addresses? Not sure if objcopy does any update here.
I am not trying to say we should specify everything, because if something unexpected like the build ID does come up it will "just" result in an error which can then be fixed.

Yes, that's true. So would we be OK with only the /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } line?

Well, I think it only makes sense to discard all or just leave it as you proposed in this PR.
Sorry for the noise, I just wanted to raise awareness to the fact that discarding might make sense, but this is not a necessity. And to be honest I do not know all the impacts /DISCARD/ could have as to suggest its safe usage.

Phillip, could you break up this PR into two? One to fix up the .ld format, one to actually make the linker script changes.
Also, seeing as we're apparently having an opinion on .ld format... is it worth it to write like, a paragraph of .ld style guide?

@mcy Sure #1114 created

authors: imphil mcy towoe


text:
[spi_device] Mux in missing scan_rst_ni connectivity

The newer out_clk-synchronized resets were missing direct connectivity for scan reset, as was the CSR-connected reset to the prim_fifo_async used for flash status register updates moving from SW to the SPI clock domain. Add the requisite muxes to patch that up.

Merging. The failure is unrelated and was fixed by a separate PR (already merged).


text:
[otbn,dv] Disable an FI test which causes (spurious) DV failures

See the second commit message for a careful description of what this is doing. Fixes #23578.
After writing this, it occurred to me that another approach might have been to write zeros to the backing memory for the FIFOs in question (rather than 'X). This would have fixed the FSM lock-up behaviour that we were seeing. If this "disable the buggy check" approach feels unsafe, we could always follow up with that more principled approach, but it's probably worth merging this version to fix the failing nightly in the meantime.
Note: There's currently a "TODO(???)" comment, which is supposed to track a specific PR discussing the thing we're working around. Don't merge this without linking it up properly.
For proof that this genuinely fixes the linked issue:
rupert@halibut /s/l/opentitan (otbn-sec-cm-debugging) [1]> util/dvsim/dvsim.py hw/ip/otbn/dv/uvm/otbn_sim_cfg.hjson -i otbn_sec_cm --fixed-seed=123 -vh
INFO: [dvsim] [proj_root]: /src/lr/opentitan
INFO: [SimCfg] [scratch_path]: [otbn] [/src/lr/opentitan/scratch/otbn-sec-cm-debugging/otbn-sim-xcelium]
INFO: [FlowCfg] [results]: [otbn]:
## OTBN Simulation Results
### Tuesday June 11 2024 15:18:11 UTC
### GitHub Revision: [`a4c2d125cd`](https://github.com/lowrisc/opentitan/tree/a4c2d125cd925f2afb8a93f175b4b4d8c60204f9)
### Branch: otbn-sec-cm-debugging
### [Testplan](https://opentitan.org/book/hw/ip/otbn/dv/data/otbn_testplan.html)
### Simulator: XCELIUM

### Test Results
|  Stage  |                    Name                    | Tests       |  Max Job Runtime  |  Simulated Time  |  Passing  |  Total  |  Pass Rate  |
|:-------:|:------------------------------------------:|:------------|:-----------------:|:----------------:|:---------:|:-------:|:-----------:|
|   V2S   |                tl_intg_err                 | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |               prim_fsm_check               | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |              prim_count_check              | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |      sec_cm_controller_fsm_local_esc       | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |        sec_cm_controller_fsm_sparse        | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |     sec_cm_scramble_ctrl_fsm_local_esc     | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |      sec_cm_scramble_ctrl_fsm_sparse       | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |    sec_cm_start_stop_ctrl_fsm_local_esc    | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |     sec_cm_start_stop_ctrl_fsm_sparse      | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |  sec_cm_rf_base_data_reg_sw_glitch_detect  | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |       sec_cm_stack_wr_ptr_ctr_redun        | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   | sec_cm_rf_bignum_data_reg_sw_glitch_detect | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |        sec_cm_loop_stack_ctr_redun         | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |         sec_cm_tlul_fifo_ctr_redun         | otbn_sec_cm |      12.283m      |     1.778ms      |     1     |    1    |  100.00 %   |
|   V2S   |                                            | **TOTAL**   |                   |                  |     1     |    1    |  100.00 %   |
|         |                                            | **TOTAL**   |                   |                  |     1     |    1    |  100.00 %   |

(yes, I ran it on quite a slow computer)

Thanks for working on this, Rupert! If we decide going this way instead of having an RTL change, we would need to have this change also in sram_ctrl and flash_ctrl. Happy to help you with that as your PR should make this quite easy to do :)

authors: nasahlpa rswarbrick


text:
[hmac,dv] Optimize regression duration

reduce reseeding for HMAC SHA-2/HMAC vectors tests as the randomization space is quite narrow
remove these tests from the stress test as it doesn't bring anything
related to this issue #23844

@martin-velay , this would also need a rebase now.

@vogelpi, thanks for the warning. It's done now, just need to wait for the CI to complete.

I am merging this as all relevant DV checks have passed. The FPGA checks are not relevant for this PR.

authors: martin-velay vogelpi


text:
[ast] Move clkmgr dependency from wrapper package into wrapper

The package does not really depend on clkmgr but only the wrapper does.
This PR has been factored out from #4329.

Thanks for your feedback and approval @imphil and @tjaychen , I've added the suggested changes and did a rebase. I will merge this once CI passes.


text:
Total .Json Config file newb. Please help with this config :/

I apologize as I'm a total newbie when it comes to coding and I've tried for hours. I managed to create a simple config.json that has been working to turn my projector on and off, which is all i needed the broadlink homebridge for.
Now, I'm trying to add my air conditioner unit so I can turn it on and off while I'm away from the house, but I can seem to integrate the two lines of code. I've attached my first, working .json file, and then I'll paste what I'm trying to config.
Please, any help would be appreciated marrying the two so it's a valid .json file ?
Current json file:
jsonformatter (3).txt
trying to add this code:
{
"name”:”AC On/Off",
"type":"switch",
"data":{
"on":"260066007036100d0d29100d0e290f0d0e2a0e0d0e290f0e0d290f0e0d290f2a0d0f0d290f0e0d290f290e290f290e0e0e0e0e2a0d290f0e0d0f0d0e0e0e0e290e0e0e0e0e0e0d0f0d290f0e0d290f290e0e0e0e0e290e290f0e0d0f0d0e0e290e2910290e2810000d050000",
"off":"260066007036100d0d29100d0e290f0d0e2a0e0d0e290f0e0d290f0e0d290f2a0d0f0d290f0e0d290f290e290f290e0e0e0e0e2a0d290f0e0d0f0d0e0e0e0e290e0e0e0e0e0e0d0f0d290f0e0d290f290e0e0e0e0e290e290f0e0d0f0d0e0e290e2910290e2810000d050000"
}
},
{
"name”:”Temp Up",
"type":"switch",
"data":"2600660070370f0d0e290f0d0f280f0d0f280f0d0f290f0d0e290f0d0e290f290e0d0f290f0d0e290f280f290f280f0d0f0d0f280f290f0d0e0d0f0d0f0e0e280f0d0f0d0f0e0d290f280f0d0f290f280f0d0f0d0e290f290e0d0f0d0f0d0f0e0d290f290e290f000d050000",
"enableAutoOff": true,
"onDuration": 1
},
{
"name”:”Temp Down",
"type":"switch",
"enableAutoOff": true,
"onDuration": 1,
"data":"2600660071360f0c0f290f0d0e290f0d0e290f0d0f280f0d0f290e0d0f290e290f0d0f290e0d0f290e2910280f280f0d0f0d0e2a0e290e0d0f0d0f0d0e0e0e290f0d0e0e0e0d0f0d0f0d0e0e0e290f290e0d0f0d0f280f290e0e0e0e0e0d0f290e0d0f290e290f000d050000"
},
{
"name”:”High”,
"type":"switch",
"enableAutoOff": true,
"onDuration": 1,
"data": [
{
"data": "260066006f380e0d0f280f0d0f290e0d0f290e0e0e2b0c0e0e290f0d0f280f290f0d0e290f0d0e290f290e290f290e0e0e0d0f290e290f0d0f0d0e0e0e0d0f290e0d0f0d0f0d0e290f290e0e0e290f290e290f0d0e290f290e0e0e0d0f0d0e0e0e0d0f290e290f000d050000",
"sendCount": 1,
"interval": 0.3
}
]
},
{
"name”:”Medium“,
"type":"switch",
"enableAutoOff": true,
"onDuration": 1,
"data": [
{
"data": "260066007036100c0f28100c10280f0d0f280f0d0f28100c0f28100c10280f28100c0f28100c0f290f280f280f290f0d0e0e0e290f280f0d0f0d0e0e0e0d0f290e0e0e0e0e0d0f0d0e0e0e290f290e290e2a0e0d0e2a0e290e0e0c100c100d2a0d2a0e0e0d2b0d000d050000.",
"sendCount": 1,
"interval": 0.3
}
]
},
{
"name": “A/C Fan",
"type": "fan",
"data": {
"on":"260066006f370f0d0e290f0d0f290e0d0f290e0d0f290f0d0e290f0d0e290f290e0e0e290f0d0e290f290e290f290e0e0e0d0f290e290f0d0e0e0e0d0f0d0f290e0d0f0d0f0d0e0e0d2a0f0d0d2a0f290e290d0f0d2a0e2a0c100c0f0e0e0d2b0e0d0e2a0c2b0e000d050000",
"off":"260066007036100d0d29100d0e290f0d0e2a0e0d0e290f0e0d290f0e0d290f2a0d0f0d290f0e0d290f290e290f290e0e0e0e0e2a0d290f0e0d0f0d0e0e0e0e290e0e0e0e0e0e0d0f0d290f0e0d290f290e0e0e0e0e290e290f0e0d0f0d0e0e290e2910290e2810000d050000"
          }

config.zip

Use an editor like Smart JSON for mac or Json Editor for windows

or online editor such Jsonlint
However. I would suggest you to set up clima as "air-conditioner" instead of "switch" type

repo: lprhodes/homebridge-broadlink-rm


text:
Support PHP languages

Is your feature request related to a problem?
Now Artemis default not support PHP language.
Describe the solution you'd like
I am trying to create new template for PHP programming language. It is new feature so I am seeking guide or sample template to this language.
Describe alternatives you've considered
No response
Additional context
No response

Check out these discussions for reference:
https://github.com/ls1intum/Artemis/discussions/4727
https://github.com/ls1intum/Artemis/discussions/4658
Generally, you can find the templates under src/main/resoruces/templates.
I suggest you create

A test suite and a sample solution
Make sure you have a docker image that is able to run this and that the tests pass for the sample solution
Create a sample template and make sure that all tests fail.

Then we can assist you on integrating the template into Artemis. If you have coding experience, feel free to open up an external pull request. You can find our documentation and contributor guide here: https://docs.artemis.cit.tum.de/index.html
Did I forget anything? @krusche @Strohgelaender

authors: julian-christl xanka


text:
Development: Add date validation to Example Solution Publication Date

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[ ] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Server

[x] I followed the coding and design guidelines.
[x] I added multiple integration tests (Spring) related to the features (with a high test coverage).
[ ] I implemented the changes with a good performance and prevented too many database calls.

Client

[x] I followed the coding and design guidelines.
[ ] I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
[x] I added multiple screenshots/screencasts of my UI changes.
[x] I translated all newly inserted strings into English and German.

Changes affecting Programming Exercises

[ ] I tested all changes and their related features with all corresponding user types on Test Server 1 (Atlassian Suite).
[ ] I tested all changes and their related features with all corresponding user types on Test Server 2 (Jenkins and Gitlab).

Motivation and Context

Example Solution Publication Date did not have a min date constraint, this could lead to potential mistakes like publishing a solution before the exercise is over or even before it begins.
Description

Example Solution Publication Date of an exercise should be after releaseDate and dueDate if they are set. It can also be empty. This validation is made both at client and the server.
Steps for Testing

Prerequisites:

1 Instructor
1 Programming Exercise
1 Text Exercise
1 Modeling Exercise
1 File Upload Exercise

Log in to Artemis
Navigate to Course Administration
For each exercise type above, try the following:
Save the exercise with an empty Example Solution Publication Date when release date or due date is set and see it succeed.
Save the exercise with an Example Solution Publication Date after the due date and see it succeed.
Save the exercise with empty Example Solution Publication Date, release date, due date and see it succeed.
Unset the due date and save the exercise with an Example Solution Publication Date after the release date and see it succeed.
Try to save the exercise with an Example Solution Publication Date before due date and see it fail with a date validation error.
Unset the due date and try to save the exercise with an Example Solution Publication Date before release date and see it fail with a date validation error.

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Class/File
Branch
Line

Screenshots

I might have found the reason for the mentioned issues. It appears that Exercise::validateGeneralSettings which calls the Exercise::validateDates method is only called when creating a programming exercise, but not when updating it.
For other exercise types this is not the case and the validateGeneralSettings is called when creating and updating the exercise.

Thanks for the diagnosis @Hialus, I added validation checks to the endpoints and also fixed the validation on client side as well.

There are use-cases for having the solution be available before the the due date of an exercise:
For example we want to publish the solution for our tutorial exercises on Friday afternoon but the due date should only be on Monday morning. (We don't simply move the due date, because that is when the homework is due and if the due dates were different the tutorial and homework exercises for a week would appear in different groups on the course page)
Thus we would ask that for at least optional exercises (that don't count towards the grade anyways) it remains possible to set the solution publication date before the due date.

@SimonPaul02 I made some fixes, it should be possible save the exercise if you have an empty due date and an empty release date now.

@bottbenj

There are use-cases for having the solution be available before the the due date of an exercise:
For example we want to publish the solution for our tutorial exercises on Friday afternoon but the due date should only be on Monday morning. (We don't simply move the due date, because that is when the homework is due and if the due dates were different the tutorial and homework exercises for a week would appear in different groups on the course page)
Thus we would ask that for at least optional exercises (that don't count towards the grade anyways) it remains possible to set the solution publication date before the due date.

This case is now handled as well, the users are allowed to save in that case but they see a warning alert just in case. I updated the description and the test steps.

@willergeorg I made some changes in the validation constraints and it seems testing step 7 is working now. Please let me know it is still not working for you and I can examine further.

Thanks @alaraozdenler, I fixed that issue.

@bottbenj

Other than that the warning that the example solution publication is before the due date comes only after saving the exercise which may be too late to change if that was not intended, for programming exercises it could be shown in the footer, tho this is not terribly important.

This may need more data transfer between components so if it is not very important I'd suggest we evaluate whether adding complexity for that (although not a big one) is worth the benefit in a possible future PR.

Using the Edit Selected on the management exercise list i was able to save  which when loading the edit page gives two alerts that the solution date was set to the due date but doesn't actually do that.

I added fix for this and the softlocking issue below at the latest commit.

On the Edit Selected dialog the datetime picker for the solution date also doesn't show up if the due date is set, instead somewhat softlocking the page until i reload manually and that dialog is generally somewhat broken. but that happens on prod as well.

(See above)

Finally solution publication date and no due date for graded exercises should at least get a warning like before due date for optional exercises.

I added the same warning when the due date is empty for graded an non graded exercises. I think using the same message ("Example solution publication date is before due date") for this case also makes sense because a non-empty example solution publication date eventually arrives unlike an empty due date so it is before the due date.

"Example solution publication date is before due date")

"Example solution publication date is before due date", I think that when we do not set a due date and show this warning message it might be a little confusing to the end-user, but functionality wise there are no problems.

authors: Hialus akesfeden bottbenj canberkanar


text:
Whishlist from Numa.jl

List of enhancements in this library that would be useful in Numa.jl

[ ] export RefCell at the top level

This issue has become obsolete. Closing it.


text:
🛑 SoHard Cloud is down

In e001e89, SoHard Cloud (http://cloud.lsy223622.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SoHard Cloud is back up in 30eae1e after 657 days, 21 hours, 57 minutes.


text:
🛑 Mirror-爬 is down

In 44edf06, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1101 ms

Resolved: Mirror-鱼露 is back up in 9cbdcbf.


text:
🛑 Mirror-爬 is down

In 8a40e5a, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1050 ms

Resolved: Mirror-鱼露 is back up in 6ad5a27.


text:
🛑 Mirror-爬 is down

In a9e065e, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1094 ms

Resolved: Mirror-鱼露 is back up in be6772e.


text:
🛑 Mirror-爬 is down

In 61d4f94, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1080 ms

Resolved: Mirror-鱼露 is back up in 5611db4.


text:
🛑 Mirror-爬 is down

In b9c6899, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1184 ms

Resolved: Mirror-鱼露 is back up in 9a0d5da.


text:
🛑 Mirror-爬 is down

In 5a49c5c, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 826 ms

Resolved: Mirror-鱼露 is back up in 4b60237.


text:
🛑 Mirror-没有女朋友跨年的群傻逼 is down

In d8a2b3e, Mirror-没有女朋友跨年的群傻逼 (https://x.ksfu.top/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-木生 is back up in b03182f.


text:
🛑 Mirror-木生 is down

In 27f23b3, Mirror-木生 (https://t.lsy223622.com/ncov-xidian-times) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-爬 is back up in 6ed8155.


text:
🛑 Mirror-爬 is down

In ccef05c, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 869 ms

Resolved: Mirror-鱼露 is back up in 64879b2.


text:
🛑 Mirror-爬 is down

In 3cb9220, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 793 ms

Resolved: Mirror-鱼露 is back up in e6fedc7.


text:
🛑 Mirror-爬 is down

In 8acbcab, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 933 ms

Resolved: Mirror-鱼露 is back up in 4ec8593.


text:
🛑 Mirror-爬 is down

In b69327b, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 730 ms

Resolved: Mirror-鱼露 is back up in 27c8d28.


text:
🛑 Mirror-爬 is down

In 9861d54, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 897 ms

Resolved: Mirror-鱼露 is back up in 019bfb5.


text:
🛑 Mirror-爬 is down

In cf7bcbb, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1736 ms

Resolved: Mirror-鱼露 is back up in 0aa971a.


text:
[LNO] Streamline GitHub Teams for LTER Org

Summary
GitHub uses "teams" to manage group-wise access to repositories. This is an efficient mode of sharing repositories, particularly when the same group of people needs the same level of access to multiple repositories. The LTER GH Org has a mix of active and inactive teams some of which have the same people and grant access to the same repositories. Some amount of cleaning house (so long as no one loses access to any repositories) might be nice.
Starting Tasks

[x] Review current list of teams and identify reasonable groups

[x] Collapse redundant teams when possible to safely do so

[x] Create a general "IM" group

[x] Add IMs to that group

Useful links

LTER org teams page

Updates Underway
Reasonable first pass at team organization (without costing anyone access). Also, identifying some inactive repositories with either bizarre names or no real content. Seems like it'd be low stakes to delete the empty ones and rename the old ones with stuff in it. Need to run by Marty for approval.
See below:

macroeco -- 10 years from most recent commit, no real content
LTERIM -- made for 2015 ASM, possibly good stuff but should rename as something like "asm-2015-notes" or something more informative / less confusing
ARC -- 3 years old but contains nothing
Other repos with inactive topic might also be good candidates for some sort of houskeeping action

Done
Can close this now (forgoing breaking changes at this point)

repo: lter/scicomp


text:
[CR] Add VSX Hadamard

Description
This PR add Hadamard Transform using the VSX instructions set, aiming to optimize this operation for Power8 in order to resolve the issue #6

Checklist:

[x] Add code to Build System
[x] Implement the Transpose 8x8 for signed shorts
[x] Add Unit tests
[x] Implement Hadamard 8x8
[x] Implement Hadamard 16x16
[x] Test for endianness and unaligned addresses issues
[x] Make all tests pass

I've test the implementation on both little and big endian architectures, also I'm using the vec_vsx_ld and vec_vsx_st to load and store the data, so I'll mark the Test for endianness and unaligned addresses issues as checked for now.

This is a first version, I don't apply any further optimizations, but if you find it necessary I can make the vpx_transpose_8x8_s16 and vpx_hadamard_8x8_s16_one_pass inline functions also I can use an aligned address buffer and replace to simple load and store functions, aiming to reduce the permutation overhead of the used instructions.

Using the test harness I'm not seeing any speedup, I guess some more work might be needed.

Seems that the test harness does not double as benchmark harness easily, do you have the alternative benchmark code ready to be in the tree?

I've some test code here, I'll push until the end of the day.

The benchmark code is very simple, runs the hadamard implementation with multiple strides from 10^1 to 10^6 times with the same input matrix.

Already merged to upstream

authors: lu-zero rafaeldelucena

repo: lu-zero/libvpx


text:
Comments in strings trip up Carbide parser

This is a regression with the latest Carbide fix.
Consider:
print("--")

In the previous build, the string would be stripped and put back and everything would be okay.
In the new build, the comment is stripped first, leaving an impartial string that then might be stripped incorrectly again.
It might be necessary to rewrite all the string/comment stripping in Carbide, sadly.

Latest update causes comments to not be preserved with Carbide. Eventually they'll be fully stripped, but for now, this fixes this bug.

repo: lua-carbon/carbon

license: Zlib


text:
App Crashes on Android 4.4.4

[App Crashes on Android 4.4.4 release mode whenever I try to play sound from the app assets using audioCache method ]
Full Description
it's working on all other devices very well except  the one that is using Android 4.4.4
version of the library is audioplayers 0.18.3
Code to Reproduce
here is the code that I'm using
 audioCache.play(
                  state.track,
                  mode: PlayerMode.LOW_LATENCY,
                );

it's crashing in both PlayerMode the normal one and LOW_LATENCY
Log Errors
here is the Log that I got from Firebase in the Link .
Platforms
[OS] Android 4.4.4 "Samsung Device : core prime"

You could try this #854, if you have a device to test it.

Unfortunately  it didn't work for me!

t works when I use audioplayers 0.18.3 version. But doesn't work with 0.19.0

[App Crashes on Android 4.4.4 release mode whenever I try to play sound from the app assets using audioCache method ]
Full Description
it's working on all other devices very well except the one that is using Android 4.4.4
version of the library is audioplayers 0.18.3
Code to Reproduce
here is the code that I'm using
 audioCache.play(
                  state.track,
                  mode: PlayerMode.LOW_LATENCY,
                );

it's crashing in both PlayerMode the normal one and LOW_LATENCY
Log Errors
here is the Log that I got from Firebase in the Link .
Platforms
[OS] Android 4.4.4 "Samsung Device : core prime"

It works when I use audioplayers 0.18.3 version. But doesn't work with 0.19.0

This should have been fixed by https://github.com/luanpotter/audioplayers/pull/841 on 0.19.0.

authors: baraaaljabban erickzanardo sgg-labs zatovagul

repo: luanpotter/audioplayers


text:
🛑 Centrum vedecko-technických informácií SR is down

In 388055d, Centrum vedecko-technických informácií SR (https://www.cvtisr.sk/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Centrum vedecko-technických informácií SR is back up in b4761f2.

repo: lubosm/minedusk-uptime