Add support for SYLVANIA Wifi LED Smart Light Bulb, 60W=8.5W, Full Color A19 (2700K - 6500K)

Device information

product_id: 1ijupffokexbz0cl (Tuya / Sylvania product identifier)
Model: A19CCECWF (Printed on base of bulb itself)
SKU: 75663 (1-pack)
SKU: 75674 (4-pack)
Product Description: SYLVANIA Wifi LED Smart Light Bulb, 60W=8.5W, Full Color A19 for Alexa and Google Home - 1 Pk
Manufacturer URL: https://shop.ledvanceus.com/products/sylvania-wifi-led-smart-light-bulb-8-5w-a19-1pk
Amazon URL: https://www.amazon.com/SYLVANIA-Dimmable-Equivalent-Google-Assistant/dp/B088G2B48D

Home Assistant Device information

These bulbs are configured with LocalTuya:

Checklist

[X] I have created a single PR per device. When you have multiple submissions please create separate PR's.
[X] For lights - I have only included the gzipped files (*.gz), not the raw CSV files.
[X] For lights - I have provided a CSV file per supported color mode. Look that up in Developer Tools -> States

Additional info

Measurements were taken with a Shelly PlugUS connected to a floor lamp with three identical bulbs.

Thanks for the PR, measurements looking good!
Could you share the device info.
It's on the top left on the device page in HA.
For example on a Hue light for me:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3565

Relevant Lines:
3565

💛  - Coveralls

After some digging, it appears that any devices added to HA through Local Tuya or Tuya Local will not show a true product_id that can be used to identify a make or model to Home Assistant. Here is a device info screenshot:

Read on for an in-depth explanation below.
This is due to a few things:

These bulbs need to be initially configured through the Sylvania / Ledvance smart app. These are clearly just custom branded Tuya devices, but cannot be configured using Tuya cloud or Tuya's app. The Tuya integration for these bulbs does not work due to customization and lockout from Sylvania / Ledvance.
These bulbs can only be integrated with HA through Local Tuya or Tuya Local. This is ultimately desired, even for normal Tuya devices and removes reliance on the cloud. However, both Tuya Local and Local Tuya do not appear to make the product_id field available to Home Assistant. I've grepped the config files to confirm its absence.

For the record, I have some cheap Tuya contact sensors configured through the [Tuya integration](https://www.home-assistant.io/integrations/tuya/ and they show just as you'd expect them to under the device info (product_id is shown).
After some digging, I've finally found the product_id for these bulbs. A tool called tuya-uncover (necessary for grabbing the bulb's local_key before configuring each bulb in Local Tuya) is able to display the product_id (value 1ijupffokexbz0cl):
Output from python3 uncover.py -r us -v sylvania <sylvania_app_username> <sylvania_app_password>:
    "A19C WF 4": {
        "id": "eb389ce051a9376d93ebfn",
        "local_key": "dJ=FPJ+[EXKytHLH",
        "category": "dj",
        "uuid": "54e0b9defe4437d1",
        "product_id": "1ijupffokexbz0cl",
        "dps": {
            "20": true,
            "21": "white",
            "22": 255,
            "23": 774,
            "24": "0009029f00ff",
            "25": "06464601000003e803e800000000464601007803e803e80000000046460100f003e803e800000000",
            "26": 0,
            "27": "",
            "28": ""
        }

For regular Tuya devices, the local keys can be fetched through their API explorer, but with these Sylvania branded bulbs that is simply not an option, hence using tools such as tuya-uncover.
If there's any other info you need, let me know. I'll update my other pull request shortly.

Thanks for your extensive write up.
That means for these local tuya devices there is no information available which uniquely identifies the model in HA device info. Local tuya adds an identifier there which is unique per user/device. Would be a good idea to report this issue at local tuya.
Because of this auto discovery for powercalc will not work as there is no way to retrieve the actual model information from HA.
I would prefer to have the directory named similarly to a model id which is known to the user. i.e. what's printed on the bulb. So they can find the model in the list when selecting during library setup of the powercalc entity. https://homeassistant-powercalc.readthedocs.io/en/latest/sensor-types/virtual-power-library.html
And also add 1ijupffokexbz0cl as an alias in model.json. When LocalTuya exposes that in the future in HA device information powercalc autodiscovery will also start working from that moment.

I didn't intend to delay fixing up these pull requests, but I went down quite the rabbit hole after flashing these bulbs to ESPHome using tuya-cloudcutter.
Anyways,

Model number renamed (A19CCECWF) and moved to a separate sylvania folder. LEDVANCE is technically the parent company of SYLVANIA  with many different/similar devices marketed under both entities.
1ijupffokexbz0cl added as an alias.

I'll update the other related pull request shortly.
It's a bummer because my power consumption numbers are now no longer applicable because of the subtle differences (brightness curves, etc) between stock Tuya firmware and alternative firmware such as ESPHome, Tasmota, and OpenBeken. However, for anyone using these bulbs with the stock Tuya-based firmware, they'll be good to go.

Also leaving this comment here for anyone who cares to know. It wasn't evident until opening up one of these bulbs in an attempt to flash custom firmware that these are RGBW syle light bulbs.
These bulbs only have 2700K warm white LEDs that are active in white light mode. When increasing the color temperature,  the Tuya firmware will start to bring up blue and green LEDs and dim the relative level of white LEDs to make the sweep from 2700K to 6500K. Not that this is inherently bad, these bulbs look great at 3000K, 4000K, etc.
IF you flash these bulbs to ESPHome you will lose the convenient color temperature slider and the lights are added as RGBW style LED lights giving you two independent controls for color LEDs and white LEDs:

In Home Assistant this unlocks a much greater range of color options. You can still dial in "4K white" and similar "colors" by hand (see screenshot). You can also blend in reds to achieve ~2500K or lower as well as push beyond 6500K. Accurate CRI beyond the limits? Probably not, but interesting nonetheless.

Thanks. You really went down the Rabbit hole. All looking good now.


Update README

Edit the description and slack link to point to network-policy-api channel.
Signed-off-by: abhiraut<EMAIL_ADDRESS>

/lgtm
/approve
Thanks!!


Azure file sync - "last accessed date" attribute

Hi,
with regards to Azure file sync, which should remove files from being locally stored if they havent been accessed in last X days.
if the last accessdate attribute being updated is disabled, which seems to be default behaviour on all Windows Servers, how will this work.
Would there be a requirement to enable the Last access date attribute via the command
"fsutil behavior set disablelastaccess 0"
thanks
Colm

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 61bb35a5-e2f3-1ce8-1d6e-a926374de6c8
Version Independent ID: e4b3065a-5351-26ef-cdbb-ef2eaea3f301
Content: Deploy Azure File Sync
Content Source: articles/storage/files/storage-sync-files-deployment-guide.md
Service: storage
Sub-service: files
GitHub Login: @roygara
Microsoft Alias: rogarana

@smithcl167 Thank you for your inquiry. Is there a specific document you are following? I have pre-selected a related document to categorize your issue and have it addressed by the appropriate service area but, if there is a specific tutorial or set of instructions you are attempting follow, it would be helpful if we also had that link.

its just around Azure File sync in general.
it says it sync files access/modified in last X days, but the accessed date wont change on a file unless you enable the access date attribute via the command "fsutil behavior set disablelastaccess 0".
but i see no reference to this command or something like it in the documentation.

@smithcl167 https://github.com/MicrosoftDocs/azure-docs/issues/41859

Closing this issue since it's duplicate of the above issue.


Turn off rotation for various signal icons

Where the symbol would look odd when rotated or flipped.
Round and square ones, rectangular ones can not be fixed right now.
Resolves #2026

This one also includes SignalSign which is actually rectangular, but since it is nearly square, rotation looks reasonable anyway.
What do you think @robbr48 ? There are some other rectangular (nearly square) icons that we could turn off rotation for.
Or we could improve the code, but that takes more time.

This one also includes SignalSign which is actually rectangular, but since it is nearly square, rotation looks reasonable anyway.
What do you think @robbr48 ? There are some other rectangular (nearly square) icons that we could turn off rotation for.
Or we could improve the code, but that takes more time.

Yes round makes sense

Yes round makes sense


feat(tcp-outlet): tuitify and make ockam tcp-outlet show (no args) interactive

Current behavior
As described in this issue #6477

Proposed changes
The ockam tcp-outlet show is made to be interactive as suggested in this issue #6477

Checks

[x] All commits in this Pull Request are signed and Verified by Github.
[x] All commits in this Pull Request follow the Ockam commit message convention.
[x] There are no Merge commits in this Pull Request. Ockam repo maintains a linear commit history. We merge Pull Requests by rebasing them onto the develop branch. Rebasing to the latest develop branch and force pushing to your Pull Request branch is okay.
[x] I have read and accept the Ockam Community Code of Conduct.
[x] I have read and accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam repository. The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a separate Pull Request, this will mark the commit as verified.

Hey @Lumexralph, your PR will be landed through https://github.com/build-trust/ockam/pull/7309. I've added you as co-author, so you keep the authorship of the changes. Thanks again for your contribution! 🎉


Update README.md

Add link to user privacy requirements, fixes internal bug 151085511

To be addressed in the internal source.


Rename this repo

Following the lead of https://github.com/uisautomation/media-deploy, this repo should be renamed media-webapp or similar.

repated from #156


feat(datafusion): Support cast operations

Resolves #811
Depends on #820

https://github.com/apache/iceberg-rust/pull/820 has been merged.

@Xuanwo Thanks, I was noodling a bit on this one, I want to make some changes to make it safer for the user before marking this as ready.


fix: convert duration to seconds for cache control

Fixes #43

@revmischa Can you give me write access? If not, can you merge for me, thanks.
This PR is good to go.


consider checking the 'platform' tag to identify route stops

From what I can see in the generated GTFS file, you are currently only taking the public_transport 'stop' as tag to identify route stops positions.
I think (though I am not sure) that OSM also uses the 'platform' tag to identify those. It might be worth to check those out and see if it is the case.
Example: https://www.openstreetmap.org/relation/7886858#map=11/49.2521/7.1706

@carocad you are right. However, I think at least for creating shape.txt file I'll take all the nodes of a relation into account, regardless of their membership type (stop, platform, etc), because the difference is not much and it creates a more accurate shape for the route.

Sounds good to me


microk8s helm3 commands on MacOS don't pass the full path to multipass for relative files

When running microk8s helm3 commands on MacOS, any command that references a file (such as passing a values.yaml), requires the full path (or a variable) to be specified in the microk8s helm3 command (i.e. microk8s helm3 upgrade --install --create-namespace --namespace ingress-nginx --wait --timeout 30m --version 3.40.0 ingress-nginx ingress-nginx/ingress-nginx -f ${PWD}/helmvalues/ingress-nginx.yaml Omitting the ${PWD} or just specifying ./ does not pass the full folder path across - the vm assumes a path of /root/ubuntu
The microk8s/multipass shim seems to work by mounting the initiating folder into the multipass vm at the exact same mount point - is there a way to either pass across the correct folder location, change the root in the vm for commands to the mounted host, or set the kubeconfig correctly on the host for helm3? I note that microk8s kubectl works fine with relative local files.
This is running k8s 1.21 on microk8s 2.2.0 using multipass 1.9.0
toby ~ % brew info microk8s
ubuntu/microk8s/microk8s: stable 2.2.0
Small, fast, single-package Kubernetes for developers, IoT and edge
https://microk8s.io/
/opt/homebrew/Cellar/microk8s/2.2.0 (1,913 files, 20MB) *
  Built from source on 2022-05-04 at 05:53:15
From: https://github.com/ubuntu/homebrew-microk8s/blob/HEAD/Formula/microk8s.rb
==> Dependencies
Required: python ✔, kubernetes-cli ✔
==> Requirements
Required: macOS >= 10.12 ✔
==> Caveats
Run `microk8s install` to start with MicroK8s
toby ~ % multipass version
multipass   1.9.0+mac
multipassd  1.9.0+mac
toby ~ % microk8s kubectl get nodes
NAME          STATUS   ROLES    AGE   VERSION
microk8s-vm   Ready    <none>   19h   v1.21.11-3+68355092a9b768
toby~ % multipass info microk8s-vm

Name:           microk8s-vm
State:          Running
IPv4:           <IP_ADDRESS>
                <IP_ADDRESS>
Release:        Ubuntu 18.04.6 LTS
Image hash:     f86a544fe791 (Ubuntu 18.04 LTS)
Load:           0.78 1.21 1.22
Disk usage:     4.1G out of 48.3G
Memory usage:   1.1G out of 3.9G
Mounts:         /Users/toby/sites/test-helm => /Users/toby/sites/test-helm
                    UID map: 502:default
                    GID map: 20:default

inspection-report-20220504_232307.tar.gz

Hi @tobybellwood ,
This is a limitation of running MicroK8s in a VM. Two options you have is to

deploy your own set of utilities (eg kubectl, helm) on the host and use the kubeconfig file available with microk8s config to reach the cluster.
use multipass mount [1] to mount your working directory in the right place inside the microk8s-vm

[1] https://multipass.run/docs/mount-command

Thanks, I got there in the end. It's more of an issue that it's very undocumented that this is how it works, and although the pwd is mounted in the VM, relative paths do not work because the helm3 command presupposes /home/Ubuntu (which can't be mounted).
If helm3 is just a shim command, maybe the context can be passed through?


Fix hermes profiler

Summary
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.

Need to call registerForProfiling to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
runInExecutor didn't work and call its callback. Not sure exactly why, but using executor_->add like we do in a lot of other places to run code on the executor works.
GetHeapUsageRequest seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. GetHeapUsageRequest doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use runInExecutor instead.

Changelog

[General] [Fixed] - Fix hermes profiler
Test Plan

I had a discussion with @jpporto. This is safe to land. We're a bit afraid this might lead to crashes internally due to how we call EnableSampleProfiling. If that is the case, we might have to revert this.

Sounds good, I’m fine with exploring other solutions, or trying to enable it only for open source if it causes an issue internally.


"Failed to backup", how do I install manually?

When I try to force install, I get the following error
Failed to backup old RiderLink plugin
Close all running instances of Unreal Editor and try again
Path to old plugin: C:\Projects\FollowMe\Unreal\Plugins\Developer\RiderLink

I do not have Unreal running. The contents of that directory were deleted when trying to upgrade. How do I install manually?

Hi @benui-dev

The contents of that directory were deleted when trying to upgrade.
That's a new one. The error states this very thing, that we failed to move this folder...
Anywho, you've got 2 options:

There's "RiderLink.zip" folder under Rider's installation path
eg E:\PROGRAMS\JetBrains\apps\Rider For Unreal Engine\ch-0\213.5857.137\plugins\UnrealLink\EditorPlugin\RiderLink.zip
Simply unzip it to the %GAME%/Plugins/Developer/RiderLink folder
or
Check if %GAME%/Plugins/Developer/RiderLink folder has write access and try "Force install in the Game" once again.
Cheers!

I have just noticed that your message has been around since 12th October and this is not acceptable.
I'm extremely sorry.
I need to find a way to filter out everything that comes from this repo, otherwise it simply drowns in the spam :(

I had to delete the Developer/RiderLink folder, manually installing from the zip did not work. My project is backed up by Google Drive and I believe that is what caused my problem. It seems to have some write access locking that isn't just unticking "Read Only".


New official release before Debian 11 freeze (needed for projects)

Hello the Team, @tuexen,
I wish you a Happy New Year!
It is possible to create a real new build instead of a git version?
The goal is to have the version before the Debian 11 freeze (2021-01-12).

https://salsa.debian.org/pkg-voip-team/libusrsctp
cc @jonassmedegaard

It is used by several projects like Psi and Psi+.

https://github.com/psi-im/psi/issues/607
https://github.com/psi-im/iris/blob/master/CMakeLists.txt#L209

The last official version is very old, soon 5 years:

<IP_ADDRESS> (8 Apr 2016)
https://github.com/sctplab/usrsctp/releases

Thanks in advance.

The last official version is very old, soon 5 years

And that is why GNU/Linux distributions are forced to use git snapshotes:
https://tracker.debian.org/pkg/libusrsctp
https://launchpad.net/ubuntu/+source/libusrsctp
https://pkgs.alpinelinux.org/packages?name=libusrsctp-dev
And even in *BSD systems:
https://www.freshports.org/net/libusrsctp
https://github.com/DragonFlyBSD/DPorts/tree/master/net/libusrsctp

The last official version is very old, soon 5 years

And that is why GNU/Linux distributions are forced to use git snapshotes:
https://tracker.debian.org/pkg/libusrsctp
https://launchpad.net/ubuntu/+source/libusrsctp
https://pkgs.alpinelinux.org/packages?name=libusrsctp-dev
And even in *BSD systems:
https://www.freshports.org/net/libusrsctp
https://github.com/DragonFlyBSD/DPorts/tree/master/net/libusrsctp

... and what would you expect from a release compared to a snapsot?

... and what would you expect from a release compared to a snapsot?

Quoting Michael Tüxen (2021-01-03 21:53:38)

... and what would you expect from a release compared to a snapsot?

A version number corresponding with a git tag, which consuming projects and downstream distributions can reference.
If all git commits are considered equally stable changes, then it is helpful if that is documented - and then (but only then) does it make less sense to issue formal releases (because then each and every commits implies a "release").

Quoting Michael Tüxen (2021-01-03 21:53:38)

... and what would you expect from a release compared to a snapsot?

A version number corresponding with a git tag, which consuming projects and downstream distributions can reference.
If all git commits are considered equally stable changes, then it is helpful if that is documented - and then (but only then) does it make less sense to issue formal releases (because then each and every commits implies a "release").

... and what would you expect from a release compared to a snapsot?

Just git tag. Nothing more. Github will prepare tarball for git tag automatically. And this new version will be widely used in different distros and build environments (like Homebrew).
But if you can write a short change log (for example with API changes) it would much better of course.

... and what would you expect from a release compared to a snapsot?

Just git tag. Nothing more. Github will prepare tarball for git tag automatically. And this new version will be widely used in different distros and build environments (like Homebrew).
But if you can write a short change log (for example with API changes) it would much better of course.

Gentoo too:

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/usrsctp

Fedora 31/32/33/34 have another versions:

https://src.fedoraproject.org/rpms/usrsctp
Fedora 34 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc34
Fedora 33 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc33
Fedora 32 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc32

Time to release the 1.0.0+ after several years.
The most important is Debian 11 freeze in few days, the next will be in 2023.

Gentoo too:

https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/usrsctp

Fedora 31/32/33/34 have another versions:

https://src.fedoraproject.org/rpms/usrsctp
Fedora 34 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc34
Fedora 33 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc33
Fedora 32 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc32

Time to release the 1.0.0+ after several years.
The most important is Debian 11 freeze in few days, the next will be in 2023.

Notes:

https://vulmon.com/vulnerabilitydetails?qid=CVE-2019-20503
https://nvd.nist.gov/vuln/detail/CVE-2019-20503

Notes:

https://vulmon.com/vulnerabilitydetails?qid=CVE-2019-20503
https://nvd.nist.gov/vuln/detail/CVE-2019-20503

Hello the Team, @tuexen,
Have you looked?
A new build is needed, can you be released today?
@jonassmedegaard: Can you create a build with the last current git?
Several projects need up-to-date...

https://github.com/psi-im/psi/issues/607
https://github.com/psi-im/iris/blob/master/CMakeLists.txt#L209

Thanks in advance.
cc @xvitaly

Hello the Team, @tuexen,
Have you looked?
A new build is needed, can you be released today?
@jonassmedegaard: Can you create a build with the last current git?
Several projects need up-to-date...

https://github.com/psi-im/psi/issues/607
https://github.com/psi-im/iris/blob/master/CMakeLists.txt#L209

Thanks in advance.
cc @xvitaly

cc @xvitaly

On Fedora, we already have a packaged version of usrsctp, but built from Git snapshot.

cc @xvitaly

On Fedora, we already have a packaged version of usrsctp, but built from Git snapshot.

@xvitaly: Yes, read my comment:

https://github.com/sctplab/usrsctp/issues/561#issuecomment-753789438

Fedora 31/32/33/34 have another versions:

https://src.fedoraproject.org/rpms/usrsctp
Fedora 34 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc34
Fedora 33 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc33
Fedora 32 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc32

Time to release the 1.0.0+ after several years.

I think that @tuexen does not want to create a new build and I have specified that you have done 1.0.0.
It is a problem for all projects because:

First, the CVE-2019-20503
Nothing since <IP_ADDRESS> (8 Apr 2016)

Some projects can not be added because the lib is outdated since 5 years soon.
Normally, there are not git-version products in some OS...
I hope a new version today, the most important is Debian 11 (The next will be in 2023), and there will be Fedora 34 soon too.

@xvitaly: Yes, read my comment:

https://github.com/sctplab/usrsctp/issues/561#issuecomment-753789438

Fedora 31/32/33/34 have another versions:

https://src.fedoraproject.org/rpms/usrsctp
Fedora 34 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc34
Fedora 33 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc33
Fedora 32 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc32

Time to release the 1.0.0+ after several years.

I think that @tuexen does not want to create a new build and I have specified that you have done 1.0.0.
It is a problem for all projects because:

First, the CVE-2019-20503
Nothing since <IP_ADDRESS> (8 Apr 2016)

Some projects can not be added because the lib is outdated since 5 years soon.
Normally, there are not git-version products in some OS...
I hope a new version today, the most important is Debian 11 (The next will be in 2023), and there will be Fedora 34 soon too.

I hope a new version today, the most important is Debian 11 (The next will be in 2023), and there will be Fedora 34 soon too.

If a new version will be released soon, I will push it to all supported Fedora releases: from 32 to 34.

I hope a new version today, the most important is Debian 11 (The next will be in 2023), and there will be Fedora 34 soon too.

If a new version will be released soon, I will push it to all supported Fedora releases: from 32 to 34.

I have at least to fix one known issue before making a release. And I got another issue reported, I have to look into. So there will not be a release today.

I have at least to fix one known issue before making a release. And I got another issue reported, I have to look into. So there will not be a release today.

@tuexen: Thanks for your reply!
I cross my fingers...

@tuexen: Thanks for your reply!
I cross my fingers...

@tuexen: After 4 days, it is good?
It blocks several projects on Debian here...
Can you do it today?
I propose you a 1.0.0 or a 1.0.1 version.
Thanks in advance.

@tuexen: After 4 days, it is good?
It blocks several projects on Debian here...
Can you do it today?
I propose you a 1.0.0 or a 1.0.1 version.
Thanks in advance.

I can do it today, but it will be 0.9.4.
1.0.0 will happen once it is feature complete (meaning complete RFC 8260 support) and there are no known critical bugs for a while.

I can do it today, but it will be 0.9.4.
1.0.0 will happen once it is feature complete (meaning complete RFC 8260 support) and there are no known critical bugs for a while.

@tuexen: After 4 days, it is good?

You assume that i had time to look into the bug I was referring to, but I hadn't.

It blocks several projects on Debian here...

Not sure why you can't use some snapshots based on a particular git version.

Can you do it today?

Done.

I propose you a 1.0.0 or a 1.0.1 version.

<IP_ADDRESS> is the next after <IP_ADDRESS>.

Thanks in advance.

@tuexen: After 4 days, it is good?

You assume that i had time to look into the bug I was referring to, but I hadn't.

It blocks several projects on Debian here...

Not sure why you can't use some snapshots based on a particular git version.

Can you do it today?

Done.

I propose you a 1.0.0 or a 1.0.1 version.

<IP_ADDRESS> is the next after <IP_ADDRESS>.

Thanks in advance.

<IP_ADDRESS> is the next after <IP_ADDRESS>.

But this is not a 0.9.x. It contains lots of changes and breaks API and ABI. This is even worse than it was.

<IP_ADDRESS> is the next after <IP_ADDRESS>.

But this is not a 0.9.x. It contains lots of changes and breaks API and ABI. This is even worse than it was.

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump.

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump.

It blocks several projects on Debian here...
Not sure why you can't use some snapshots based on a particular git version.

This was misinformation from @Neustradamus . Debian is fine with git snapshots. Real inconvenience was in different versions of library with incompatible API used across different GNU/Linux distros and even between different versions of one distro...
Thanks for a new release!

It blocks several projects on Debian here...
Not sure why you can't use some snapshots based on a particular git version.

This was misinformation from @Neustradamus . Debian is fine with git snapshots. Real inconvenience was in different versions of library with incompatible API used across different GNU/Linux distros and even between different versions of one distro...
Thanks for a new release!

Quoting Michael Tüxen (2021-01-10 10:53:55)

@tuexen: After 4 days, it is good?

You assume that i had time to look into the bug I was referring to, but I hadn't.

It blocks several projects on Debian here...

Not sure why you can't use some snapshots based on a particular git version.

Debian package maintainer for usrsctp here.
Yes, Debian uses git snapshots, and I am unaware of any blockers.
There certainly are none propery reported at https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libusrsctp
That said, I appreciate upstream releases being made.  Thanks!

Jonas

Quoting Michael Tüxen (2021-01-10 10:53:55)

@tuexen: After 4 days, it is good?

You assume that i had time to look into the bug I was referring to, but I hadn't.

It blocks several projects on Debian here...

Not sure why you can't use some snapshots based on a particular git version.

Debian package maintainer for usrsctp here.
Yes, Debian uses git snapshots, and I am unaware of any blockers.
There certainly are none propery reported at https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libusrsctp
That said, I appreciate upstream releases being made.  Thanks!

Jonas

Quoting Vitaly Zaitsev (2021-01-10 10:56:29)

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump.

I suspect you are mistaking "versions" with "SemVer 2.0.0 versioning scheme compliant versions" or something similar (SemVer sure wasn't the first invention of applying semantics to version components)

Quoting Vitaly Zaitsev (2021-01-10 10:56:29)

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump.

I suspect you are mistaking "versions" with "SemVer 2.0.0 versioning scheme compliant versions" or something similar (SemVer sure wasn't the first invention of applying semantics to version components)

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump. If you don't want to publish 1.0.0, you can use <IP_ADDRESS>.

I'm trying to keep the API stable. So where did it break? Please also note that the version number is below 1.0.0, so I consider it acceptable to break the API, if there are good reasons for it.
Not sure about SOVERSION, that is a cmake thing.
@weinrank What is SOVERSION? Is this something like the version information in configure.ac? Then it should be in sync and it should be 0.9.4 right now.

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump. If you don't want to publish 1.0.0, you can use <IP_ADDRESS>.

I'm trying to keep the API stable. So where did it break? Please also note that the version number is below 1.0.0, so I consider it acceptable to break the API, if there are good reasons for it.
Not sure about SOVERSION, that is a cmake thing.
@weinrank What is SOVERSION? Is this something like the version information in configure.ac? Then it should be in sync and it should be 0.9.4 right now.

<IP_ADDRESS> is the next after <IP_ADDRESS>.

But this is not a 0.9.x. It contains lots of changes and breaks API and ABI between <IP_ADDRESS> and <IP_ADDRESS>. This is even worse than it was.

Where is it API broken? If you don't like this release, can't you just ignore it?

<IP_ADDRESS> is the next after <IP_ADDRESS>.

But this is not a 0.9.x. It contains lots of changes and breaks API and ABI between <IP_ADDRESS> and <IP_ADDRESS>. This is even worse than it was.

Where is it API broken? If you don't like this release, can't you just ignore it?

I know of one place where the API changed recently; the send_cb passed into usrsctp_socket added an additional void* ulp_info argument.

I know of one place where the API changed recently; the send_cb passed into usrsctp_socket added an additional void* ulp_info argument.

@taylor-b: Thanks for comment, it is linked to:

https://github.com/sctplab/usrsctp/issues/318
https://github.com/sctplab/usrsctp/issues/439

@taylor-b: Thanks for comment, it is linked to:

https://github.com/sctplab/usrsctp/issues/318
https://github.com/sctplab/usrsctp/issues/439

@tuexen https://github.com/sctplab/usrsctp/blob/master/meson.build#L3 still points to version 1.0.0.

@tuexen https://github.com/sctplab/usrsctp/blob/master/meson.build#L3 still points to version 1.0.0.

@tuexen Yes, SOVERSION itself is a cmake stuff. But it is needed just for simplifying maintaining of library for completely different systems. In case of GNU/Linux systems and other systems with binaries in ELF format, this SOVERSION variable in cmake is used for setting proper SONAME in a shared library.

@tuexen Yes, SOVERSION itself is a cmake stuff. But it is needed just for simplifying maintaining of library for completely different systems. In case of GNU/Linux systems and other systems with binaries in ELF format, this SOVERSION variable in cmake is used for setting proper SONAME in a shared library.

By the way, cmake and meson are still exporting version 1.0.0.
I think I will continue using this version (1.0.0) in Fedora packages.

By the way, cmake and meson are still exporting version 1.0.0.
I think I will continue using this version (1.0.0) in Fedora packages.

Quoting Vitaly Zaitsev (2021-01-11 15:37:26)

By the way, cmake and meson are still exporting version 1.0.0.
I think I will continue using this version (1.0.0) in Fedora packages.

It is (most likely) not a project version, but a SONAME version:
https://en.wikipedia.org/wiki/Soname

Quoting Vitaly Zaitsev (2021-01-11 15:37:26)

By the way, cmake and meson are still exporting version 1.0.0.
I think I will continue using this version (1.0.0) in Fedora packages.

It is (most likely) not a project version, but a SONAME version:
https://en.wikipedia.org/wiki/Soname

It is (most likely) not a project version, but a SONAME version:

Currently exported by Cmake and Meson:

project version: 1.0.0
SONAME VERSION: 1

It is (most likely) not a project version, but a SONAME version:

Currently exported by Cmake and Meson:

project version: 1.0.0
SONAME VERSION: 1

@tuexen: You have all points to create an official 1.0.0 version.
Can you do it?
@jonassmedegaard: I hope that it is good for timing...

@tuexen: You have all points to create an official 1.0.0 version.
Can you do it?
@jonassmedegaard: I hope that it is good for timing...

Note:
The bad number version in the file: <IP_ADDRESS> -> <IP_ADDRESS>

https://github.com/sctplab/usrsctp/blob/master/configure.ac#L31

Good files have "1.0.0"/"<IP_ADDRESS>"/"1:0:0":

https://github.com/sctplab/usrsctp/blob/master/usrsctplib/Makefile.am#L79
https://github.com/sctplab/usrsctp/blob/master/meson.build#L3
https://github.com/sctplab/usrsctp/blob/master/usrsctplib/CMakeLists.txt#L37
https://github.com/sctplab/usrsctp/blob/master/usrsctplib/CMakeLists.txt#L180

Maybe good to harmonize all "1.0.0" or "<IP_ADDRESS>" same values.
Thanks in advance.

Note:
The bad number version in the file: <IP_ADDRESS> -> <IP_ADDRESS>

https://github.com/sctplab/usrsctp/blob/master/configure.ac#L31

Good files have "1.0.0"/"<IP_ADDRESS>"/"1:0:0":

https://github.com/sctplab/usrsctp/blob/master/usrsctplib/Makefile.am#L79
https://github.com/sctplab/usrsctp/blob/master/meson.build#L3
https://github.com/sctplab/usrsctp/blob/master/usrsctplib/CMakeLists.txt#L37
https://github.com/sctplab/usrsctp/blob/master/usrsctplib/CMakeLists.txt#L180

Maybe good to harmonize all "1.0.0" or "<IP_ADDRESS>" same values.
Thanks in advance.

Quoting Neustradamus (2021-01-11 16:29:35)

@tuexen: You have all points to create an official 1.0.0 version.
Can you do it?
@jonassmedegaard: I hope that it is good for timing...

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Quoting Neustradamus (2021-01-11 16:29:35)

@tuexen: You have all points to create an official 1.0.0 version.
Can you do it?
@jonassmedegaard: I hope that it is good for timing...

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Current version <IP_ADDRESS> has soversion 1:1.0.0 even in automake.

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Current version <IP_ADDRESS> has soversion 1:1.0.0 even in automake.

The problem is that it is specified in files: "1.0.0"/"<IP_ADDRESS>"/"1:0:0", it is not "<IP_ADDRESS>" except one place, there is a bad value.

https://github.com/sctplab/usrsctp/issues/561#issuecomment-758036462

The problem is that it is specified in files: "1.0.0"/"<IP_ADDRESS>"/"1:0:0", it is not "<IP_ADDRESS>" except one place, there is a bad value.

https://github.com/sctplab/usrsctp/issues/561#issuecomment-758036462

I think I took 1.0.0 from the CMake files when I was writing the Meson build files. It's unfortunate that there was a 1.0.0 now. But would it really hurt to give up the tight binding of feature completeness to 1.0 now that the damage is done? Or is that version scheme something that the FreeBSD kernel mandates?
This project would likely benefit from collectively bumping all version numbers and perhaps add a very small releasing document describing what needs to be done on a release (e.g. "bump all the version numbers in files x, y and z, create a git tag, push, done").

I think I took 1.0.0 from the CMake files when I was writing the Meson build files. It's unfortunate that there was a 1.0.0 now. But would it really hurt to give up the tight binding of feature completeness to 1.0 now that the damage is done? Or is that version scheme something that the FreeBSD kernel mandates?
This project would likely benefit from collectively bumping all version numbers and perhaps add a very small releasing document describing what needs to be done on a release (e.g. "bump all the version numbers in files x, y and z, create a git tag, push, done").

Quoting Vitaly Zaitsev (2021-01-11 16:59:45)

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Current version <IP_ADDRESS> has soversion 1:1.0.0 even in automake.

There is nothing wrong with project version and SONAME version being different.

Quoting Vitaly Zaitsev (2021-01-11 16:59:45)

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Current version <IP_ADDRESS> has soversion 1:1.0.0 even in automake.

There is nothing wrong with project version and SONAME version being different.

not reasons for fast-pacing a major release.

+1

Current version <IP_ADDRESS> has soversion 1:1.0.0 even in automake.

And this is not a problem: SONAME is not related to program version at all. It has only one real requirement: it should be incremented between releases if there are changes in ABI. For example, library libfoo with version 0.16.1 may be with SONAME libfoo_49 and this is completely normal.
@Neustradamus  Please stop write these similar messages. They are useless and annoying.

not reasons for fast-pacing a major release.

+1

Current version <IP_ADDRESS> has soversion 1:1.0.0 even in automake.

And this is not a problem: SONAME is not related to program version at all. It has only one real requirement: it should be incremented between releases if there are changes in ABI. For example, library libfoo with version 0.16.1 may be with SONAME libfoo_49 and this is completely normal.
@Neustradamus  Please stop write these similar messages. They are useless and annoying.

Where is it API broken?

As a Psi+ packages maintainer I have faced with differences in libusrsctp versions
<IP_ADDRESS>+20190901, <IP_ADDRESS>+20200422 and <IP_ADDRESS>+20201102 in different versions of Ubuntu:
https://launchpad.net/ubuntu/+source/libusrsctp
Unfortunately, I have not found full build logs, but IIRC the problem was in usrsctp_getsockopt() function.
In our official PPA for Ubuntu this problem was solved by uploading latest version of libusrsctp package to our PPA:
https://launchpad.net/~psi-plus/+archive/ubuntu/ppa/+packages
and by setting of specific minimal version of library in binary packages:
https://salsa.debian.org/xmpp-team/psi-plus/-/blob/511e295d/debian/control#L40
In Debian this will not be a problem because Debian Bullseye already has version <IP_ADDRESS>+20201102 and I hope that it will appear in official backports for Debian Buster soon: https://tracker.debian.org/pkg/libusrsctp
After release of version <IP_ADDRESS> I expect that all popular distros will update their libusrsctp packages to this new version in a foreseeable future and this bedlam with git snapshots with different API will go away.
As for first stage of Debian Bullseye freeze since 12 Jan 2021, I do not see the problem of updating package with library to version <IP_ADDRESS>, because there are very few changes in it since version <IP_ADDRESS>+20201102 (which is in Debian testing now), so slot for library transition is not required.
From my point of view this issue may be closed.
@tuexen Thanks for such fast reaction!

Where is it API broken?

As a Psi+ packages maintainer I have faced with differences in libusrsctp versions
<IP_ADDRESS>+20190901, <IP_ADDRESS>+20200422 and <IP_ADDRESS>+20201102 in different versions of Ubuntu:
https://launchpad.net/ubuntu/+source/libusrsctp
Unfortunately, I have not found full build logs, but IIRC the problem was in usrsctp_getsockopt() function.
In our official PPA for Ubuntu this problem was solved by uploading latest version of libusrsctp package to our PPA:
https://launchpad.net/~psi-plus/+archive/ubuntu/ppa/+packages
and by setting of specific minimal version of library in binary packages:
https://salsa.debian.org/xmpp-team/psi-plus/-/blob/511e295d/debian/control#L40
In Debian this will not be a problem because Debian Bullseye already has version <IP_ADDRESS>+20201102 and I hope that it will appear in official backports for Debian Buster soon: https://tracker.debian.org/pkg/libusrsctp
After release of version <IP_ADDRESS> I expect that all popular distros will update their libusrsctp packages to this new version in a foreseeable future and this bedlam with git snapshots with different API will go away.
As for first stage of Debian Bullseye freeze since 12 Jan 2021, I do not see the problem of updating package with library to version <IP_ADDRESS>, because there are very few changes in it since version <IP_ADDRESS>+20201102 (which is in Debian testing now), so slot for library transition is not required.
From my point of view this issue may be closed.
@tuexen Thanks for such fast reaction!

Interesting :)

https://github.com/sctplab/usrsctp/issues/561

Interesting :)

https://github.com/sctplab/usrsctp/issues/561

Interesting :)

https://github.com/sctplab/usrsctp/issues/564

Interesting :)

https://github.com/sctplab/usrsctp/issues/564

I think I took 1.0.0 from the CMake files when I was writing the Meson build files. It's unfortunate that there was a 1.0.0 now. But would it really hurt to give up the tight binding of feature completeness to 1.0 now that the damage is done? Or is that version scheme something that the FreeBSD kernel mandates?
This project would likely benefit from collectively bumping all version numbers and perhaps add a very small releasing document describing what needs to be done on a release (e.g. "bump all the version numbers in files x, y and z, create a git tag, push, done").

Can you prepare a pull request for it? I would like to keep the project version consistent between the autotools builds, the cmake builds and the mesa builds. Let us sync them to the autotools version.
It would also be good to understand how the build systems set the soversion and what the requirements are there. Something like bump it this when changing the API.
That way we can maybe meet the expectations some people have.

I think I took 1.0.0 from the CMake files when I was writing the Meson build files. It's unfortunate that there was a 1.0.0 now. But would it really hurt to give up the tight binding of feature completeness to 1.0 now that the damage is done? Or is that version scheme something that the FreeBSD kernel mandates?
This project would likely benefit from collectively bumping all version numbers and perhaps add a very small releasing document describing what needs to be done on a release (e.g. "bump all the version numbers in files x, y and z, create a git tag, push, done").

Can you prepare a pull request for it? I would like to keep the project version consistent between the autotools builds, the cmake builds and the mesa builds. Let us sync them to the autotools version.
It would also be good to understand how the build systems set the soversion and what the requirements are there. Something like bump it this when changing the API.
That way we can maybe meet the expectations some people have.

Can you prepare a pull request for it?

#565 should fix all these issues.

Can you prepare a pull request for it?

#565 should fix all these issues.

For your information, Debian 12 arrives... After 2 years.

https://tracker.debian.org/pkg/libusrsctp

@tuexen: It is possible to have a new release after 2 years of development?


Get-ExternalInOutlook

Would like to have a viewable parameter in the Get-ExternalInOutlook command "AllowList". This way, all entries are viewable and not the first 4 entered.

@dariomws

@MPSTechDir - thank you for engaging with the community here for the docs.
I know the product teams are always looking for user feedback and how to make Microsoft products better. They keep a close tab on user feedback and it would be awesome if you could add your voice to the Microsoft Feedback Portal: https://feedbackportal.microsoft.com/feedback/.
You might find others have made a similar request that you can add to, or you can open a new one. Let us know here if you do so we can up-vote your request.
Thank you for your contribution to making the docs better! Much appreciated!

@MPSTechDir Thank you very much for your kind feedback. Considering your valuable feedback, please log this issue as advised. Here we are limited to documentation fixes and improvements only. Concerning team will evaluate and take the appropriate action, as per their schedule. We proceed here to close it. Thanks again for taking out some time and sharing your feedback.


correctly fix permissions for my_query-cache.cnf

this fixes an error when the keycloak-db is started as rootless (how it is normal during a lagoon-core install), causing the whole testing pipeline to fail.
2021/08/30 15:47:45 [ ERROR ] Error while parsing '/etc/mysql/conf.d/my_query-cache.cnf': open /etc/mysql/conf.d/my_query-cache.cnf: permission denied

I'm hitting this too when running tests, did something change in the latest mariadb-10.4 images @tobybellwood ?

not as far as I can tell - I think the error was introduced with the query cache (https://github.com/uselagoon/lagoon/pull/2797/files)?  Does setting the fix-permissions work for you (or using this image testlagoon/keycloak-db:pr-2822?

Yes, making the change in this PR fixes the keycloak-db starting issue in the tests


Uninvited users cannot be invited again

When you invites someone from /all-users, then uninvite this person, and then want to invite this person again, you can't. In the console, you will see a message someone has already invited this user.

Hey, @jasperkennis! Telescope has changed a lot in the past months, and there is a new React-based version, Telescope Nova (intro video). If you know Crater, it runs on it.
The Legacy version is no longer supported, I'm closing this issue.
I invite you to check the new version, it's awesome!
Happy hacking! 🚀
Ps: by the way, don't hesitate to join the Slack to ask any question, you are welcome! 👍


Content manager

As a developer, I want to use the local database, so that I can keep the project simple.

Given a data structure like below:

ID
Text
Embedding

uuid
full text
embeddings

When we implement the code
Then we can save data

And we can fetch full data

@vlifeng 请帮忙看一下这个需求，有什么可以改进的地方么？

Search enhancement, pure calculate > ES vector search


Memory leak fix, LoadWithOptions method

Hi. Fix for Go 1.6 led to a new issue - workersTable map began to save links to workers, and GC not destruct them without manual table cleanup. We did create other map for callback, without links to worker.
There is a new method LoadWithOptions. We left 'Load' signature untouched for backward compatibility.
We also did small improvements in Go code according to guidelines

can you clean up (squash) this branch into two commits so it's easier for me to look at?

done

Hey, can you please add a test showing the memory leak? I'm not sure I agree with your fix...
I'm not against adding a LoadWithOptions but what is your use case? The V8 API is extremely large, and the intent of this project is not to wrap everything - only what is necessary. It is cumbersome to have v8::ScriptOrigin and worker.go's ScriptOrigin and mirroring the same struct in worker_load's parameters.

For testing memory leak you can run TestWorkerDeletion with workers count about 1000 and see how memory consumption growth (1.5GB for 1000 workers). Workers will live while references for them contains in workerTable - forever for current version.
LoadWithOptions is helpful for running scripts with some wrappers (for closures e.g.) and get correct stack trace. We use 3 of 8 parameters (name, line and column offsets), but the rest may be useful to other embedders. I think ScriptOrigin struct just adds lines of code, not complexity. Go package export is still clean with struct in parameter - we can pass only needed options.

Thanks, I've fixed the memory leak now, I think.
Can you please rebase the ScriptOrigin patch? I'd really like if we could figure out a way to not repeat the same struct members over and over....

Why you create a C function pointers from Go and pass them to C in Worker.New?
callback := C.worker_recv_cb(C.go_recv_cb)
receiveSync_callback := C.worker_recv_sync_cb(C.go_recv_sync_cb)

w.cWorker = C.worker_new(callback, receiveSync_callback, C.int(w.tableIndex))

Can you please rebase the ScriptOrigin patch? I'd really like if we could figure out a way to not repeat the same struct members over and over....

We think it simplest way for now, but it would be good if you have any suggestions...

intent of this project is not to wrap everything - only what is necessary

We have built CommonJS and async Go function calls with callbacks on top of v8worker, only with string messaging. But correcting stack trace outside of worker, when v8 can do this, a bit strange.

@kib357 removed that cruft, thanks
as for ScriptOrigin, I'm not sure exactly without doing it but maybe worker_load can take a struct argument instead of each individual option.

@kib357 is your work related to async Go function calls with callbacks on top of v8worker available somewhere? I worked on v8dispatcher, also a layer on top of v8worker but probably with different goals

@emicklei, we are planning to publish project within one month

@kib357 closing this one. please reopen a new PR when you rebase LoadWithOptions


Cmdct 3141 - prevent return key from exiting the modal and navigating back to prev page

Description
Hitting return in the overlay modal type exited the modal and navigated back to the previous page.
https://github.com/Enterprise-CMCS/macpro-mdct-mfp/assets/22454493/8000f15f-f962-4d4a-ace8-f3f236fa08dc
I changed the button type from submit to button, and the return key tabs to the next field instead of exiting the modal to fix this issue.
Related ticket(s)

CMDCT-3141
How to test
In main, go to the state or territory initiatives and try to add an evaluation plan or funding source--fill out one or two inputs and then hit return, see that you've been sent back to the previous page.
In project branch do the same thing and see that the return acts like a tab, going to the next input section instead of exiting the modal (unless all required fields have been filled out, in which case the return will hit the submit button.
Important updates

Author checklist

[ ] I have performed a self-review of my code
[ ] I have added thorough tests, if necessary
[ ] I have updated relevant documentation, if necessary

convert to a different template: test → val | val → prod

Works! Just to be clear: it still closes the modal if you hit return before you select a field. if you are in a field (other than textbox) it'll move on as expected

@gmrabian yeah, it closes the modal before you select a field, that's the same behavior in MCR and I think the selected/active element when you first open a modal is gonna be the x Close button. I think that behavior is fine, since you end up on the same page, vs getting sent back one page.


Some Questions about Nadel

Hello,
I have some questions, I hope you can give me answer on this.

Is Nadel an GraphQL Gateway?
Know you when the first Version will Release?
Can I Nadel before first Version already use in Production, because it looks like Nadel is well developed.

Thanks for your help :)

Okay first question you can forgot, I see it is an GraphQL Gateway :)


Trojan:Script/Wacatac.B!ml detected

When installing the file my Windows Defender sends a notification of a trojan virus being detected and stating that it is severe.

False positive. I submitted it to Microsoft but they ignored my request.


Image preview not always working

Hello,
Although I've been using Linkding as my primary bookmark tool for almost 2 years, it's been a couple of months since I last updated it (I installed it via Docker, btw).
I noticed it has fantastic new options, and I particularly enjoyed the "image preview".
But the thing is it doesn't seem to be working very well for me. I mean, it works nicely in some urls, but not on others. On IMDB, for example, it only shows the generic IMDB logo. Reddit urls don't show anything... no matter if it's a profile or a subreddit link.  On the other hand, links for some Aliexpress dealings for example work perfectly, showing the image of the product as an image preview.
Am I missing something? Maybe some further configuration I'm supposed to do? I read the README but saw no indication...
Again, loving the new features! :)

The logic for detecting a "preview" image is pretty simple right now in that it just uses OpenGraph metadata that a page might or might not have. I'm not sure how much more complex I want this to be, but it can't hurt to collect cases where it doesn't work.

I have this same issue as well.

Same issue here.


[bug]: Header is not responsive

Describe the bug
The header is not responsive
Expected behavior
The form should be responsive , and the footer is responsive but the header isn't responsive
Screenshots

Desktop (please complete the following information):

Browser [e.g. chrome]
OS[windows]

Hey @SurajPratap10, I didn't find this issue anywhere. So I've raised this issue, If she couldn't complete assign me with that issue.
THANK YOU


docs: update credential display API doc

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (118fd8f) 89.69% compared to head (9ad4e9e) 89.64%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #737      +/-   ##
==========================================
- Coverage   89.69%   89.64%   -0.05%
==========================================
  Files         101      101
  Lines        4211     4211
==========================================
- Hits         3777     3775       -2
- Misses        286      288       +2
  Partials      148      148

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


ASyH 1.0: report.j2 not found

Generating a report with ASyH 1.0.0 will fail with errors like:

Traceback (most recent call last):
  File "/beegfs/scratch/ASyH/ARX-ASyH-Comparison/ASyH-scripts/2-train+sample+report.py", line 35, in
    report.generate(dataset, asyh_application.model.model_type)
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/ASyH/report.py", line 49, in generate
    markdown = self.get_mark_down_report(dataset_name, sd_model_name, images)
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/ASyH/report.py", line 107, in get_mark_down_report
    jinja_template = self._get_report_template()
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/ASyH/report.py", line 124, in _get_report_template
    return env.get_template('report.j2')
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/jinja2/environment.py", line 1010, in get_template
    return self._load_template(name, globals)
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/jinja2/environment.py", line 969, in _load_template
    template = self.loader.load(self, name, self.make_globals(globals))
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/jinja2/loaders.py", line 126, in load
    source, filename, uptodate = self.get_source(environment, name)
  File "/beegfs/homes/hwilhelmi/.venvs/ASyH/lib/python3.9/site-packages/jinja2/loaders.py", line 218, in get_source
    raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: report.j2

Most likely the issue can be avoided if working with 'pip install -e .'.
It seems that there are two issues in the code:

"return env.get_template('report.j2')" - this call does not specify the path to search the template in (what are the defaults? should we rely on then?)
The bundled package seems not to contain report.j2.


Export connectivity checkers to a library, along w/ pod rendering, and waiting for pod readiness

What this PR does / why we need it:
Export batchv1.Job manipulation funcs to a library.
Export Corev1.Pod basic manipulation funcs to a library.
Special notes for your reviewer:
Depends-on: #4272
Only the 3 last commits are relevant (the others belong on the aforementioned PR).
Release note:

NONE

/cc @EdDev @qinqon

I don't even remember what this tries to achieve.
Cutting my losses.


In-page Table of Contents

Design:

[x] Decide if our Sphinx template needs to have the little header at top of the ToC nav (currently says "On this page") + if so, what we want our to say, if it needs an icon, etc
[x] Design header + icon, if we're having either

Engineering:

[ ] Update to match design (can do this now, since design is ready):
Match separator line on left side
Match typeface size (same regardless of level of hierarchy) + line height
Match weight of "indicator line" that indicates current section
Match behavior of "indicator line" that indicates current section (only applies to deepest section relevant, not to its parent also, unlike in the current PyData implementation, also text should not bump inwards slightly when its section is selected)
No underlines
Match color of text
Match depth of indent for parent and children sections, relative to the separator line
[ ] Implement new design for right nav "header" + icon, once design is ready

Here's what the in-page ToC looks like now with PyData theme applied:

Here's what it should look like with the design (pending "header" + icon design):

Oh good point! I like the logic they have, where it only is expanded for
the section you clicked to go to or are currently scrolling through!
On Tue, Feb 15, 2022 at 8:16 AM Jeremy Asuncion @.***>
wrote:

Depending on the page content, it might be too long if we keep everything
expanded
https://user-images.githubusercontent.com/2176050/154102809-994874fb-71a1-4740-b798-80f9c070b356.mp4
—
Reply to this email directly, view it on GitHub
https://github.com/napari/napari-sphinx-theme/issues/36#issuecomment-1040473461,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMWPDSDNFAAY2CCETSFUNVTU3J34HANCNFSM5OFRVXRA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Lia Prins
Senior Data Visualization Designer
(650) 422-1750
chanzuckerberg.com

@codemonkey800 Do you know if with this theme we could remove the little icon next to "On this page" ()?
And also if we could change the "On this page" text to different words?

@liaprins-czi yeah, there is a template for the icon and text. what would you like to replace it to?

I'm not sure yet, just wanted to check if we could! I will let you know,
though, and will also be updating the visual treatment (like the color,
etc). I will document all design updates in their issues (so this issue for
everything to do with the in-page right-side ToC nav!)
On Tue, Feb 15, 2022 at 4:18 PM Jeremy Asuncion @.***>
wrote:

@liaprins-czi https://github.com/liaprins-czi yeah, there is a template
for the icon and text. what would you like to replace it to?
—
Reply to this email directly, view it on GitHub
https://github.com/napari/napari-sphinx-theme/issues/36#issuecomment-1040930430,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMWPDSEENVNZO5GVZND6N7DU3LUL3ANCNFSM5OFRVXRA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Lia Prins
Senior Data Visualization Designer
(650) 422-1750
chanzuckerberg.com

I've decided what to do about the little heading + icon above the right-side nav: We don't need to have any icon, but I think the same text used in the heading by PyData helps to explain what the list is. So it will still say "IN THIS PAGE" but using the same text style as the current napari.org "TABLE OF CONTENTS" header (only was ever shown when screen was too narrow to fit the ToC on the side, and it had to move above the main page content, like in tablet and mobile).
Here's a mockup in Figma:
https://www.figma.com/file/ahjEJjeaFL6oTjeQaueGDQ/napari-Sphinx-Theme?node-id=30%3A5

Additonally, it'd be great if we could add back in that functionality of moving the right sidebar contents to be above the main page content once the screen is too narrow to show it on the left. We should still have it collapsed though, and openable with a toggle:

... However, I don't see this as needing to be an immediate part of the theme, we could iterate to add it in later.

Thanks for sharing the latest implementation @codemonkey800 ! There are just a few things to update:

[ ] The line height of each item in the right (and left) nav should be 1.5, so for the right nav, the font size is 14px, so the line height should be 21px
[ ] the vertical spacing between individual list items should be 25px
[ ] The "ON THIS PAGE" Header should match the design:

[ ] No icon next to "ON THIS PAGE"
[ ] Seems that there's a bug: when I select an item from the right nav, it jumps me to that part fo the page. However, the right nav is not reflected to show that item being selected, but instead keeps the top item bolded.
[ ] Selected items should have the thicker vertical bar to their left, and be bold (now they're just bold, not with the line indicating their selection status)

This looks + functions so good! There is one small thing I'd expect to work differently:
When I click to go to the last nav item, if its content is short enough that the top of the window is "within" the section above the one I clicked to go to, that other section's name in the ToC is still shown as selected. But the URL hash shows the actual section I selected. So the actual section I clicked in the right sidebar should be shown in the selected style, not the section previous to it.
(Also, I know this kind of functionality can get very complicated and maybe also very tedious. It is not super important. So if it's getting to be more trouble than it's worth, let's not worry about it for now. We could work on it in a future iteration if needed.)

@liaprins-czi oh rip I thought I replied to this, yeah let's work on this later since it's a bit complicated and a very small detail (but still important). I created an issue to track the work here: #79

@codemonkey800 Sounds good! I will close this one now then.


Pass options to flake8

It would be great if we could add a way to pass arguments to flake8 from pronto runner.
What we are missing is e.g. passing a path.
We have a .flake8 file defined in root and want to run flake8 dir/. If we as a workaround go to dir and  execute pronto there, flake won't be picking up the config file.

I think there is an undocumented cli_options parameter

sorry, I didn't get notified about this issue. Let me look into it.

did you resolve this issue? Could you elaborate on how you used cli_options?

No I gave up finally and used a different tool. I think what's missing is passing a way to pass a dir to do the check dir  but to use the .flake8 config file from root directory


Make easier to hide icon in external links

Make easier to hide icon in external links by changing types

When we refactored Link it was agreed by design (along with Stella) that the icon on external links should always be visible. I'm curious what's the reason for this change

When we refactored Link it was agreed by design (along with Stella) that the icon on external links should always be visible. I'm curious what's the reason for this change

its for wrapping components like Card in Link

@alycrys @libertymayc I think we should have this functionality. We should either not document it on the Link page or add a warning that this is only needed when you wrap a component in the Link


e2e: run generic ephemeral for kubernetes 1.21+

Currently, we are skipping the generic ephemeral testing if the kubernetes version is less than 1.21 because of this one the who test suite is getting skipped and e2e is marked as success in 2 minutes. This commit runs the ephemeral tests if the kube=>1.21+. If we do this, for the lower version we can run other tests.
Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>
sample logs from CI

S [SKIPPING] [39.739 seconds]

cephfs

/go/src/github.com/ceph/ceph-csi/e2e/cephfs.go:185

  Test CephFS CSI

  /go/src/github.com/ceph/ceph-csi/e2e/cephfs.go:273

    Test CephFS CSI [It]

    /go/src/github.com/ceph/ceph-csi/e2e/cephfs.go:274

    generic ephemeral volume only supported from v1.21+

    /go/src/github.com/ceph/ceph-csi/e2e/cephfs.go:319

------------------------------

RBD Upgrade Testing Test RBD CSI

  Test RBD CSI

  /go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:163

[BeforeEach] RBD Upgrade Testing

  /go/src/github.com/ceph/ceph-csi/vendor/k8s.io/kubernetes/test/e2e/framework/framework.go:185

STEP: Creating a kubernetes client

Nov 25 12:05:59.289: INFO: >>> kubeConfig: /root/.kube/config

STEP: Building a namespace api object, basename upgrade-test-rbd

STEP: Binding the e2e-test-privileged-psp PodSecurityPolicy to the default service account in upgrade-test-rbd-3274

STEP: Waiting for a default service account to be provisioned in namespace

[BeforeEach] RBD Upgrade Testing

  /go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:37

[AfterEach] RBD Upgrade Testing

  /go/src/github.com/ceph/ceph-csi/vendor/k8s.io/kubernetes/test/e2e/framework/framework.go:186

Nov 25 12:05:59.439: INFO: Waiting up to 3m0s for all (but 0) nodes to be ready

STEP: Destroying namespace "upgrade-test-rbd-3274" for this suite.

[AfterEach] RBD Upgrade Testing

  /go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:102

S [SKIPPING] in Spec Setup (BeforeEach) [0.158 seconds]

RBD Upgrade Testing

/go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:19

  Test RBD CSI [BeforeEach]

  /go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:162

    Test RBD CSI

    /go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:163

    Skipping RBD Upgrade Testing

    /go/src/github.com/ceph/ceph-csi/e2e/upgrade-rbd.go:39

------------------------------

Ran 0 of 4 Specs in 147.860 seconds

SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 4 Skipped

--- PASS: TestE2E (147.87s)

PASS

@nixpanic ginkgo It cannot be used as a replacement for By because BeforeEach and AfterEach i might need to revert it.

@Madhu-1 the tests are failing..

@Madhu-1 the tests are failing..

should be fixed now.

@mergifyio rebase

/retest ci/centos/mini-e2e-helm/k8s-1.20

/retest ci/centos/k8s-e2e-external-storage/1.21

X Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: Error creating machine: Error in driver during machine creation: IP not available after waiting: machine minikube didn't return IP after 1 minute

failed due to above error


Hardcoded path in the tests

I notice there is still some hardcoded path into pikciosdk/tests.py

Thanks for noticing it. I will see that next update will embed generic paths.


Raycast origin of lidar sensor

For some LiDAR sensors, the origin of the laser oscillation and the origin of the point cloud coordinates are different.
UnitySensors' ScanPatterns do not take into account the origin of the laser oscillation.
sensorOrigin2LaserOriginOffset(Vector3) parameter must be added to the ScanPattern.

Source: Livox user manual for Mid-70

Source: Velodyne Datasheet for "Alpha Prime"

@Autumn60
About Mid70, the sensorOrigin2LaserOriginOffset(Vector3) parameter looks not need.
Because, only adding the scan frame inside of the origin frame is needed.
But, about the Alpha prime sensor, the way I mentioned is not enough, and the sensorOrigin2LaserOriginOffset(Vector3) parameter is needed. Because the scan frame will dynamically moves.


fix: onChange prop to return DOM event rather than just the new value

Description

Refactored onChange prop to return DOM event rather than just the new value
Need to store changeEvent in state to support blur / cancel save

Fixes #22
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have updated the documentation accordingly where applicable.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[psql-app] rpki integration

I have installed the version 2.1.1 but the rpki integration seems not to work:
openbmp/postgres:2.1.1
openbmp/collector:2.1.1
openbmp/psql-app:2.1.1
I have data the roas in the table "rpki_validator" and our bgp prefixes "ip_rib" but the field rpki_origin_as is empty in table "global_ip_rib", i think that the script that update this table fails. I also  have empty the table "alert".
Does anyone have rpki integration working?

perhaps I have not understood how the integration with rpki works, I hope to see if I have prefixes with ASN or MASK different from what is published in the roas
thanks in advance
Puri

There were problems with the function that updated the global RIB.  This has now been fixed in 2.2.0 release, which I'm about to finish.

Any estimated date for the new release? thank you so much.

It has been released. Thanks t should be working now in the latest version.

Closing, this was fixed in 2.2.0. Please re-open if you are still having issues.


System.TimeoutException The operation has timed out.

Hi. I keep getting a timeout error when trying to get the skc for a 2004 mk4 jetta cluster. Using the kkl ch340 cable. Please help.

Your version is a bit old. Have you tried the latest version in case it works better?
https://github.com/gmenounos/kw1281test/releases/tag/v0.99.2-alpha

Will try it out. Thank you


Add eventing for CRUD operations

CRUD operations are funneled through a command queue. This queue should emit events that tell the UI to update. The operation should go as follows:

Classes that need notification of new/deleted evens should watch the properties in the Data class.

Update events will have to observe the EventBus for the relevant change notifications
Look into rxjavafx to use instead of JavafX's Observables.

UIEvent is emitted onto UIEventBus

This is resolved.


TotalTerminal

Support opening in TotalTerminal.

We are discussing support in #39. Thanks for opening this issue =)


Send Logs To Loki while Still Preserving Console Output

What feature do you want to see added?
In the Grafana Visualization Observability Backend, you currently must choose between:

Don't store pipeline logs in Loki
Store pipeline logs In Loki and visualize logs exclusively in Grafana (logs no longer visible through Jenkins screens)

While I do want the logs to be sent to Loki, I still need for the Console Output to exist, for other Jenkins plugins such as BlueOcean, Pipeline Overview and others.
Upstream changes
No response
Are you interested in contributing this feature?
No response

I believe this may be related.  https://github.com/jenkinsci/opentelemetry-plugin/issues/773

I now see that configuring otel.logs.mirror_to_disk=true in the plugin configuration does achieve my goal.
However, It is very strange that for me to collect the build logs to loki, I have to add a Grafana Visualization Backend, and under its advanced option choose:
Store pipeline logs in Loki and visualize logs exclusively in Grafana (logs no longer visible through Jenkins Controler)
Which I then supposed to cancel out with the configuration otel.logs.mirror_to_disk=true

See

https://github.com/jenkinsci/opentelemetry-plugin/pull/858

FYI PR above is merged and released
FYI New feature in progress to close the gap:

https://github.com/jenkinsci/opentelemetry-plugin/pull/865

Solved by

https://github.com/jenkinsci/opentelemetry-plugin/releases/tag/3.1261.v46101e2a_3660


markup visible in code snippet

Problem
The code example in the infix ff section of the operators page includes this line:
    take $_ if "=begin code" ff "=end code"

I guess the  isn't meant literally.

Thanks @falsifian. This is a known issue with the renderer that is being worked on (see mention above).
FYI, the underlying POD in this instance is:
my @codelines = gather for $excerpt.lines {
    take $_ if B<"=begin code" ff "=end code">
}
# this will print four lines, starting with "=begin code" and ending with
# "=end code"
say @codelines.join("\n");
=end code

Note the B<…> (bold) markup that is incorrectly rendered using ….

Closing this as a duplicate of the linked ticket in doc/website; please follow there for updates.


Whats the difference between this and starlette ?!

I should be completly dumb ;-) ... sorry
But I can't see the things that "responder" does more than "starlette" ?
What are the added values ?
I really think it should be clarified in the doc ...
All highlighted features comes from starlette, no ?

(Speaking purely for myself here)
We've both been working away pretty quickly on our own separate projects, so there are some things in Responder that weren't in Starlette at the time. (e.g. GraphQL support, Session support)
There's also a bunch of things that responder does on top:

Responder gives you content-negotiated requests and responses.

Responder gives you an API where you don't need to import anything, and don't rely on subclassing anywhere. (I think I quite like that, even though it's certainly not what Starlette should do)
Responder makes some informed choices about what default middleware stack you might want.
Responder makes some informed choices about what set of packages you might want as part of the framework.

I think there'd be some good mileage to be had in responder perhaps being more starlette-like in some of the internals, but ultimately I guess it's about providing a different developer experience.

A favorite feature of mine is also the integrated docstring -> openapi docs support, which I believe is not in starlette.

I'm sure, Kenneth and Tom have discussed this question before: Wouldn't it be more efficient if the two developers would join forces and work on one framework? Are the two use cases for starlette and responders really that incompatible?
Anyway, thanks to both for their great work!


SAP NW Start - wrong starting order. PAS before ASCS

Dear community,
we try to start a S4/HANA with the role "community.sap_operations.sap_control ".
We noticed that the PAS is started before the ASCS which leads the Dispatcher to stay in YELLOW status.
Normally the ASCS should start first, and then the PAS.
After a timeout the TASK cancels with an ERROR.
TASK [community.sap_operations.sap_control : SAP NW Start - Executing sapcontrol -nr 01 -function StartWait 180 2] ***************************************************
fatal: [<IP_ADDRESS>]: FAILED! => {"changed": true, "cmd": "source ~/.profile && sapcontrol -nr 01 -function StartWait 180 2\n", "delta": "0:03:00.730358", "end": "2024-10-24 10:36:12.309141", "failed_when_result": true, "msg": "non-zero return code", "rc": 2, "start": "2024-10-24 10:33:11.578783", "stderr": "", "stderr_lines": [], "stdout": "\n24.10.2024 10:33:11\nStart\nOK\n\n24.10.2024 10:36:12\nStartWait\nFAIL: Timeout", "stdout_lines": ["", "24.10.2024 10:33:11", "Start", "OK", "", "24.10.2024 10:36:12", "StartWait", "FAIL: Timeout"]}

Thanks in advance!
Best regards,
Vasili

Hi together,
it seems that the tasks to start the systems are executed by the order of the SAP instance numbers. In our case we have these instance numbers:
HANA = 00
PAS = 01
ASCS= 02
In this case first the HANA is started which is fine. But then ansible starts the PAS and this one can't start properly as long as the ASCS is down.
I've swapped the instance numbers of PAS and ASCS to:
ASCS = 01
PAS = 02
After that the start operation works fine :-)
So the current conclusion is that the instances are being started in the order of their instance numbers, which is not a good idea. The start order should depend on the instance type and not on the instance number ... like first start the DB, then start the ASCS, then start the PAS, then start the AAS. The stop operation should use the reverse order ... first stop the AAS, then the PAS, then the ASCS and the DB as last.
Best regards,
Jaro


lwt.preemptive depends on base-threads

= ERROR while installing vmnet.1.1.0 =======================================#
# opam-version 1.2.2
# os           darwin
# command      ./configure --prefix=/Users/djs/.opam/system
# path         /Users/djs/.opam/system/build/vmnet.1.1.0
# compiler     system (4.03.0)
# exit-code    1
# env-file     /Users/djs/.opam/system/build/vmnet.1.1.0/vmnet-26553-42737e.env
# stdout-file  /Users/djs/.opam/system/build/vmnet.1.1.0/vmnet-26553-42737e.out
# stderr-file  /Users/djs/.opam/system/build/vmnet.1.1.0/vmnet-26553-42737e.err
### stderr ###
# [...]
# File "setup.ml", line 5847, characters 11-28:
# Warning 3: deprecated: String.capitalize
# Use String.capitalize_ascii instead.
# File "setup.ml", line 5848, characters 11-30:
# Warning 3: deprecated: String.uncapitalize
# Use String.uncapitalize_ascii instead.
# ocamlfind: Package `lwt.preemptive' not found
# W: Field 'pkg_lwt_preemptive' is not set: Command ''/Users/djs/.opam/system/bin/ocamlfind' query -format %d lwt.preemptive > '/var/folders/ml/fqqlxl6j03l2lf9ljfms9m540000gn/T/oasis-9c169f.txt'' terminated with error code 2
# E: Cannot find findlib package lwt.preemptive
# E: Failure("1 configuration error")

=-=- Error report -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  🐫
The following actions were aborted
  ∗  install mirage-net-macosx 1.1.0
The following actions failed
  ∗  install vmnet 1.1.0
The following changes have been performed
  ∗  install channel             1.0.0
  ∗  install conf-which          1
  ∗  install mirage-clock-unix   1.0.0
  ∗  install mirage-console      2.1.3
  ∗  install mirage-logs         0.2
  ∗  install mirage-profile      0.7.0
  ∗  install mirage-unix         2.6.0
  ∗  install oasis               0.4.6
  ∗  install ocaml-data-notation 0.0.11
  ∗  install ocamlify            0.0.1
  ∗  install ocamlmod            0.0.8
  ∗  install shared-memory-ring  1.3.0
  ∗  install tcpip               2.8.0
  ∗  install type_conv           113.00.02

=-=- vmnet.1.1.0 troubleshooting =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  🐫
=> This package requires the vmnet.framework plus development headers which are
   present in Yosemite (10.10.*) and later.

The former state can be restored with:
    opam switch import "~/.opam/system/backup/state-20160409195908.export"
[ERROR]
  The command "opam install --yes  functoria lwt mirage-clock-unix mirage-console mirage-logs mirage-net-macosx mirage-types mirage-types-lwt mirage-unix tcpip" exited with code 4.

I was in this state with a homebrew-installed ocaml 4.03. opam install base-threads fixed the problem.

I think this has been fixed upstream: https://github.com/mirage/mirage-skeleton/issues/23#issuecomment-232984258


Remove nostart-stop-gc with lld

Fixed by https://github.com/apple/swift/pull/67476

Please test with following pull request:
https://github.com/apple/swift-driver/pull/1402
@swift-ci Please test Linux platform

@swift-ci please test

obsolete if https://github.com/apple/swift-driver/pull/1545 merges


About threads/cores

In  the configuration file, config.yaml,   says
## The maximal number of cores to use for FastQC, STAR, Salmon and DRIMSeq.
## Note that the actual number of cores available to Snakemake is determined by
## the --cores argument when it is invoked.
ncores: 1

and then in some rules you have:
threads:
	config["ncores"]

I got confused a couple of moths ago when I didn't know snakemake that much. As you say, with --cores  you specify the maximal number of cores used by snakemake, so when your are running the rule star_SE with snakemake --cores 12 and you specify in the config file ncores: 2, you'll be running 6 instances of STAR in parallel, but each instance will be using 2 cores, you won't be running STAR in one file with 12 cores (one instance). I didn't get that from the config file. I'm saying this because it's important to know how many input files you have (approximately) to set ncores properly and I think many times is better to set  threads independently in each rule because of this and also because different software has different performance when running with multiple cores in parallel. My intention isn't that you change the behavior of  this pipeline, It is rather to try to avoid confusing unintentionally some users (like me). Maybe you can add some information in the wiki or in the config file about this.

Thanks for pointing this out. We are looking into how we can best clarify the behaviour in the documentation!

Hi again - we have added a clarification to the wiki (https://github.com/csoneson/ARMOR/wiki/Running-the-analysis) - thanks for bringing this up.

Thanks to you guys for providing so many free and high quality  resources :)


Add a version field to the edit component window

When this field is changed, behavior should be similar to when displayId is changed. Namely, if CD with generated URI exists, give error, else create a copy with new identity.

I think there might be something I'm not understanding when it comes to versions.
For example:

create a CD with URI "http://mz/Pro"
create a CD with URI "http://mz/Pro/1" (same CD as before, but with version set to 1)
delete "http://mz/Pro" from the document
then shouldn't I be able to create a CD with URI "http://mz/Pro" since it is no longer in the document anymore?

You should never have an object with a version and the same object without a version.  The problem is that the persistent identity for an object with a version would match this object.  So, either:

There is only one version of an object with identity/persistentIdentity of http://mx/Pro
There are multiple versions of an object with identity http://mx/Pro/1, http://mx/Prob/2, etc. with all sharing the same persistentIdentity http://mx/Pro.

On Jun 10, 2016, at 7:02 PM, Michael Zhang<EMAIL_ADDRESS>wrote:
I think there might be something I'm not understanding when it comes to versions.
For example:

create a CD with URI "http://mz/Pro"
create a CD with URI "http://mz/Pro/1" (same CD as before, but with version set to 1)
delete "http://mz/Pro" from the document
then shouldn't I be able to create a CD with URI "http://mz/Pro" since it is no longer in the document anymore?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/SynBioDex/SBOLDesigner/issues/19#issuecomment-225327554, or mute the thread https://github.com/notifications/unsubscribe/ADWD97yKNufi86au1nfap5FU-iqs40Slks5qKgkegaJpZM4IhgNj.

In that case, this issue can be closed.


Having different rhythms for different device classes

If the variables are defined on root, how would would go about having a separate rhythm for desktop and mobile devices?

Right now there's no way to do separate rhytms. It should be possibble to change any gridlover variable at any time but I haven't had the time to implement it yet. Thanks for the input!

You can now define base variables at any point in the css. Everything below a base variable uses that variable, so it doesn't yet follow the cascade.


terraform-providers.shell: uses default model

This is a non-functional change.
Motivation for this change
Ever since Terraform providers added support for buildGoModule there's no longer any need for the terraform-provider-shell to be treated specially.
This change removes the special treatment of the shell provider and converts it to the standard model.
The added benefit is that this provider can now be automatically updated via the update-all-providers script.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 112284 run on x86_64-linux 1

2 packages built:

terraform-full
terraform-providers.shell

Result of nixpkgs-review pr 112284 at a9e03c40 run on aarch64-linux 1

2 packages built:

terraform-full
terraform-providers.shell

4 warnings produced:

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/applications/networking/cluster/terraform/default.nix:143:9:
    |
143 |         ./provider-path.patch
    |         ^

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/applications/networking/cluster/terraform/default.nix:144:9:
    |
144 |         (fetchpatch {
    |         ^

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/applications/networking/cluster/terraform/default.nix:155:17:
    |
155 |     patches = [ ./provider-path.patch ];
    |                 ^

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/applications/networking/cluster/terraform/default.nix:163:17:
    |
163 |     patches = [ ./provider-path.patch ];
    |                 ^

@GrahamcOfBorg build terraform.full


About visualizing the XD-Violence datasets.

Dear Author,
Thank you for sharing your code, the proposed solution is truly inspiring.
I am currently conducting research on weakly supervised video anomaly detection, similar to your published study on the "Modality-Aware Contrastive Instance Learning with Self-Distillation for Weakly-Supervised Audio-Visual Violence Detection", and am also using the XD-Violence datasets. Upon downloading the corresponding raw videos from the XD-Violence official website, I found that many video files were corrupted.
I am writing this letter to inquire whether you might have a complete set of raw videos for both the training and testing from the XD-Violence dataset.
I apologize for the disturbance and greatly appreciate your assistance.
Thank you very much.

Hi pipiofmark,
Thanks for your interest in our work! Unfortunately, since we use the extracted audio and visual features provided by the dataset curator, we do not preserve the raw videos. I suggest directly reaching out to the authors of XD-Violence to find out if there exists any possible solution.
Best,
Jiashuo

Thank you for your quick response and the valuable information in your paper.
I was particularly interested in Figure 6, which showcases a visualization of the XD-violence test set.
Did you have a hard time visualizing the videos of the test set? In other words, are the test set videos used for visualization in Figure 6 complete, or are the segments shown selected from a few complete or playable videos within the test set?
Thank you very much.

Hi, for the raw videos, we directly downloaded them from the official dataset website and since some videos are unavailable, we only selected downloadable videos from the test set to conduct qualitative analysis.


can i inject deps to observed component ?

pass props
<List model={model} />

vs di
const List = injectDeps(observer(component), {
    ...props
})

so the component will re-render whatever props has changed
something like
https://github.com/kadirahq/react-komposer
https://github.com/kadirahq/react-simple-di

You can inject the mobx stores using the following syntax
import Inferno from 'inferno'
import Component from 'inferno-component'
import { observer } from 'mobx-inferno'

@observer(['something'])
class MyComponent extends Component {
    render() {
        return <p>{this.props.something.hello}</p>
    }
}

Just make sure that you provided the stores to your main render. Ex:
import Inferno from 'inferno'
import InfernoDOM from 'inferno-dom'
import { Provider } from 'mobx-inferno'

const something = {
    hello: 'world'
}

InfernoDOM.render(<Provider something={something}>
            <MyComponent/>
        </Provider>, document.getElementById('root'))

Now whenever something is changed, your components will update.
Hope that answers your question!


add lean_text source type

#+BEGIN_SRC lean_text
    ...
#+END_SRC

for things that should be typeset as Lean, but without the button to run it in the editor

@soonhokong The test.sh script in the tutorial directory tries to execute this code, and fails. Can test.sh be modified to ignore lean_text?


TypeError: Cannot convert argument to a ByteString because the character at index 0 has a value of 8216 which is greater than 255.

The quotation characters at env.local file needs to be converted to just single straight quotation mark characters!


Update containers

bump containers to support stack lts-13.7
Testing
stack --resolver lts-13.7 build

Amazing, thank you. Could we release that?


StdinCommand discards stdin on an arg

What happened?
Thanks for insta-cmd! We recently started using it in PRQL, given how heavily we use `insta.
But here's an issue we hit in https://github.com/PRQL/prql/issues/2581 — if an arg is supplied to StdinCommand, it seems to discard stdin — note the second stdout output is empty:
Reproduction steps
#[test]
fn test_insta_cmd() {
    let mut cmd = StdinCommand::new("cat", "foo");

    assert_cmd_snapshot!(cmd, @r###"
    success: true
    exit_code: 0
    ----- stdout -----
    foo
    ----- stderr -----
    "###);

    let mut cmd = StdinCommand::new("cat", "foo");

    assert_cmd_snapshot!(cmd.arg("-b"), @r###"
    success: true
    exit_code: 0
    ----- stdout -----

    ----- stderr -----
    "###);  # stdout here!
}

Insta Version
insta = {version = "1.29", features = ["colors", "glob", "yaml"]}
insta-cmd Version
insta-cmd = "0.2.0"
rustc Version
1.64
What did you expect?
Adding args keeps stdin

I spent some time working on this. I think the basic issue is that taking the stdin when creating StdinCommand is very difficult — we use Deref to then get the inner Command, and once we do anything to that, we lose the stdin.
Instead, how about:
assert_cmd_snapshot!(command, stdin="hello world");

On the downside, it breaks the convention of the assert macros being positional only.
Alternatively, are there any other symbols such as @ that we could use?

If you're not sure, WDYT about me making StdinCommand's fields public, or at least adding a from_fields constructor so we can construct a StdinCommand from a command & stdin?
(Because atm it's not really usable, unless I'm missing something)

@mitsuhiko I'm loath to "ping" you, given I know you manage a huge amount already, and how grateful I am for your contributions.
But depending on whether this is maintained, we should probably move to assert_cmd (or maintain a fork of this temporarily?)
Or if you give the nod to a from_fields constructor, I'll put a PR in!
(I hope this is a reasonable message, feedback very welcome)

So I think something should be done here but I'm not sure what exactly. I will try to solve this now.

Apologies — you're correct it works when the cmd.arg("-b") is separate, and we're not using the output of cmd.arg("-b").
(I also agree that it's not ideal. And still think I won't be the first to be confused — the other PRQL-ers shared my view — but regardless it's very usable with the caveat above)

I'm definitely fixing it, but I am trying a few options now :)

Thanks a lot @mitsuhiko !

Could you please publish a new release? This breaks some very basic usages such as
#[test]
fn echo() {
    assert_cmd_snapshot!(StdinCommand::new("echo", "hello world\n"));
}

Done now.

Thank you!
FYI for anyone who wants examples — https://github.com/PRQL/prql/pull/3435

Thank you!


at+blespp

Sir, have you some good example using this AT command ?
I compiled the version 2.0
Some tips to not get ERROR after execute it ?

First, initialize two modules to be client and server respectively：
client:
AT+BLEINIT=1
server:
AT+BLEINIT=2
AT+BLEGATTSSRVCRE
AT+BLEGATTSSRVSTART
AT+BLEADVSTART
Then, establish a connection, input connection command in the client side , if not clear about the address of the server, you can search in client side (AT+BLESCAN=1,3) , also can query in the server side (AT+BLEADDR?).
client:
AT+BLECONN=0,”XX:XX:XX:XX:XX:XX”
The server will prompt for connection establishment.
server:
+BLECONN:0,”XX:XX:XX:XX:XX:XX”
Client queries the server's services and sets SPP parameters.
client:
AT+BLEGATTCPRIMSRV=0
AT+BLEGATTCCHAR=0,3
AT+BLESPPCFG=1,3,3,3,7
server:
AT+BLEGATTSSRV?
AT+BLEGATTSCHAR?
AT+BLESPPCFG=1,1,7,1,3
Enter SPP mode.
client:
AT+BLESPP
server:
AT+BLESPP