Implement spf13/viper configuration in the SDK

Overview
A continuation of the discussion started in #832.
The proposal is to reconsider the way we configure Clients and Endpoints in the SDK. We propose 3 changes:

migrate to using spf13/viper as the configuration management engine
rename ENV variables
[optional] enable ConfigMap based configuration

References
#832

@matrohon @edwarnicke  ideas welcome.

concerning the ENV variables used by the sdk, I would suggest a simpler approach with the following names :

NETWORK_SERVICE : replace OutgoingNscName and AdvertiseNseName
LABELS : replace OutgoingNscLabels and AdvertiseNseLabels

Then those ENV would be used during the endpoint advertisement or during the client startup depending on the goal of the application (implementing a nsm endpoint or being a nsm client).

@matrohon all the env variables are here:
const (
	advertiseNseNameEnv   = "ADVERTISE_NSE_NAME"
	advertiseNseLabelsEnv = "ADVERTISE_NSE_LABELS"
	outgoingNscNameEnv    = "OUTGOING_NSC_NAME"
	outgoingNscLabelsEnv  = "OUTGOING_NSC_LABELS"
	tracerEnabled         = "TRACER_ENABLED"
	mechanismTypeEnv      = "MECHANISM_TYPE"
	ipAddressEnv          = "IP_ADDRESS"
)

The tricky part is that the Endpoint can be both:
        - name: firewall-nse
          image: networkservicemesh/vppagent-firewall-nse:latest
          imagePullPolicy: IfNotPresent
          env:
            - name: ADVERTISE_NSE_NAME
              value: "secure-intranet-connectivity"
            - name: ADVERTISE_NSE_LABELS
              value: "app=firewall"
            - name: OUTGOING_NSC_NAME
              value: "secure-intranet-connectivity"
            - name: OUTGOING_NSC_LABELS
              value: "app=firewall"
            - name: TRACER_ENABLED
              value: "true"

In this case the vppagent-firewall is implementing secure-intranet-connectivity and labelling its Endpoint registration with app: firewall. When the connection request is received, it will initiate a connection to secure-intranet-connectivity, labelling its own connection request with app: firewall.
The fact that both the adveritsed NS/label and the requested NS/label are the same is more or less accidental. We can very well request another NS and label the request with something else. Such an example would look like this:
        - name: firewall-nse
          image: networkservicemesh/vppagent-firewall-nse:latest
          imagePullPolicy: IfNotPresent
          env:
            - name: ADVERTISE_NSE_NAME
              value: "secure-intranet-connectivity"
            - name: ADVERTISE_NSE_LABELS
              value: "app=firewall"
            - name: OUTGOING_NSC_NAME
              value: "secure-gateway"
            - name: OUTGOING_NSC_LABELS
              value: "app=firewall,gw=v2"
            - name: TRACER_ENABLED
              value: "true"

Saying this, my proposal for naming will be:

ENDPOINT_NETWORK_SERVICE
ENDPOINT_LABELS
CLIENT_NETWORK_SERVICE
CLIENT_LABELS

Note that I am trying to avoid the NSE/NSC terminology and using Endpoint/Client as it sounds more explicit (and clearer when pronouncing).

@nickolaev it totally make sense to me :+1:


how to fix "c++ completion routine has return success but didn't raise the remote event (code 0)" after Recompiling the source code?

When I recompile the source code, prompt the error
"c++ completion routine has return success but didn't raise the remote event (code 0)"
The use of the downloaded DLL does not have this problem .
How to modify the configuration to solve this problem?
Os:win 10
Vs:2013

Can you confirm if you are building using the batch file?

@spazzarama  YES.
i have downloaded all versions-source from github. All versions have this problem after compiling .
As long as the replacement of the download Binaries can be successful.
So, guess if there is a place to be configured .
Test app: example  /  FileMon.exe

@micro-dever I haven't built with VS2013 for a long time, only VS2015 and VS2017, that is the only thing I can think of without setting up a test environment.
Do you have a VS2017 build environment you can try with?

@spazzarama  I built with vs 2015  ,and got the same result.
the message is returned by EasyHookDll->thread.c
ps： where can i got the version code:2.7.4761.0  ?

@micro-dever EasyLoad uses the UnmanagedExport NuGet to create the native exports. Perhaps that is not working correctly for you.

@micro-dever can you confirm that when you build EasyLoad, you get the .exp and .lib files in addition to the .dll?

@spazzarama  YES
i got EasyLoad32.lib/exp and  EasyLoad64.lib/exp , the four files

@micro-dever I'll take a look, can you please also check against the latest: https://github.com/EasyHook/EasyHook/archive/v2.7.6684.0.zip

@micro-dever I used the code you linked, ran build.bat, and then filemon.exe and then targeted C:\Windows\notepad.exe and it worked fine.

@spazzarama
As expected
because i ran build.bat from version 6684 and got the same result.
i found there is a file EasyHookTestCert.cer,  is this should be installed?
and  Is it possible to be related to the SNK file

@micro-dever no that .cer file is not used. EasyHook is built using AppVeyor. There must be something wrong with your environment. If you must build from code, perhaps setup a CI environment using AppVeyor instead.


Feature request: reducing warnings in Leroy and full filename printing when catching a warning during loading data occurs

group LeCroy warnings together or check all conditions and show the warning
Let datahandling catch the warning of LeCroy and return a warning complete with the filename since LeCroy doesn't know the filename

Implemented


Replace gulp-util

Changes Made

As suggested by npm, gulp-util is deprecated and should be replaced. The only use in the project was for plugin error logging, so it was replaced with the plugin-error module.
Removed commented out code and console.logs to make the file a little cleaner and smaller for those installing the project.
Installed vinyl-file as a devDependency. It was required to be able to run the mocha test.

@ConnorChristensen Thanks for your PR


Add missing qasm definitions

What is the expected enhancement?
Some gates miss the OpenQASM definition, such as RYY, RZX, DCX or iSwap. We should add this, this can be done by adding the definitions in the qelib1.inc file.

Hi can I work on it?

Sure! 👍

Hey I would like to work on this issue. Can I give it a shot?

Hi, Sorry I am already working on this

Okay, sure. No problem.

We decided to initiate a transition to move all the QASM related code out of Terra. Therefore, I'm tagging this issue on hold until the new repo with the QASM related code is created.

Closing as qelib1.inc should not be extended. See https://github.com/Qiskit/qiskit-terra/issues/4312 and https://github.com/Qiskit/qiskit-terra/pull/6125


OAuth2 Grant UI

This PR adds the ability of revoking access for certain application via the settings UI.
Screenshots:

Codecov Report

Merging #6625 into master will decrease coverage by <.01%.
The diff coverage is 57.77%.

@@            Coverage Diff             @@
##           master    #6625      +/-   ##
==========================================
- Coverage   40.48%   40.47%   -0.01%
==========================================
  Files         406      406
  Lines       54484    54529      +45
==========================================
+ Hits        22056    22071      +15
- Misses      29390    29418      +28
- Partials     3038     3040       +2

Impacted Files
Coverage Δ

routers/user/setting/oauth2.go
0% <0%> (ø)
:arrow_up:

routers/routes/routes.go
81.99% <100%> (+0.02%)
:arrow_up:

routers/user/setting/applications.go
45.61% <20%> (-2.47%)
:arrow_down:

models/oauth2_application.go
58.63% <80%> (+2.58%)
:arrow_up:

models/unit.go
0% <0%> (-14.29%)
:arrow_down:

modules/log/event.go
64.46% <0%> (-1.53%)
:arrow_down:

models/repo_list.go
66.84% <0%> (-1.06%)
:arrow_down:

routers/repo/view.go
41.08% <0%> (-1%)
:arrow_down:

Continue to review full report at Codecov.

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

@jonasfranz I mean ctx.QueryInt64("id") maybe zero, but not ctx.User.ID

@lunny fixed


Confusing example code in the reference doc

In here: http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_introducing_spring_cloud_stream
This code example:
@SpringBootApplication
public class StreamApplication {

  public static void main(String[] args) {
    SpringApplication.run(StreamApplication.class, args);
  }
}

@EnableBinding(Sink.class)
public class TimerSource {

  ...

  @StreamListener(Sink.INPUT)
  public void processVote(Vote vote) {
      votingService.recordVote(vote);
  }
}

So what is this? Is it a source? It's name is TimerSource which suggests it is some kind of source of time data. But.... its annotated with @EnableBinding(Sink.class) suggesting instead it is a sink. And then it has a method there for processing votes. I'm left wondering... what has this to do with either a source or a sink of time data?
That is all really very confusing to someone reading the docs for the very first time.

The confusion between source / sink continues in the next paragraph.

The following is the definition of the Source interface:

Then its followed by the Sink interface code.

That looks like TimerSource was copy-pasted whereas something more appropriate would have been VoteRecordingSink or similar. It's definitely not a source.


update question

so this is a noobie question.  I got the notification of new version 2.3.0.  Bu when I look for the latest version in docker (on my synology  system)  the highest number is I see is 2.2.1.
Is there typically some lag between the announcement and the availability of the update?
Thanks.
hal

Yes there is.  When a release is added to github, a build on docker hub is triggered.
Then, depending on its position in the queue, it will take more or less time before being ready.

Thanks for the quick answer.

It's there now.


Fix issue #3692 by omitting generic HTMLElement type properties that …

This issue is cause by this line interface Swiper extends React.HTMLAttributes {} in swiper-react.d.ts
It extends the React.HTMLAttributes which defines properties like onProgress with the type ((event: SyntheticEvent<HTMLElement, Event>) => void) | undefined'. The Swiper has the same property with type ((swiper: Swiper, progress: number) => void) | undefined'.
The fix is to omitting generic HTMLElement type properties that are defined in swiper-events.d.ts when extending the Swiper interface with React.HTMLAttributes.

Merged, thanks!

Happy to help :)


Linux distribution giving error: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by libserde_derive.so)

Hi, first, I apologize if this is a trivial/not-applicable solution, as I'm not a Rust expert (not even a novice user)
What I'm doing is to basically create a project by doing cargo init and just adding the dependency in Cargo.toml as suggested here:
[dependencies]
serde = { version = "1.0", features = ["derive"] }

And then, when I do cargo run, I get the following error:
error: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/algo/myrust/target/debug/deps/libserde_derive-60fcaaef46ab695d.so)
   --> /home/farzadmf/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.147/src/lib.rs:305:1
    |
305 | extern crate serde_derive;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0432]: unresolved imports `self::__private`, `self::__private`
   --> /home/farzadmf/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.147/src/lib.rs:287:5
    |
287 | use self::__private as export;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^
288 | #[allow(unused_imports)]
289 | use self::__private as private;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0432`.
error: could not compile `serde` due to 2 previous errors

Seems to me that the reponsible line is:
error: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/algo/myrust/target/debug/deps/libserde_derive-60fcaaef46ab695d.so)

My distribution's glibc is old, but I'm using homebrew to install latest gcc and glibc, and even if I do ldd /tmp/algo/myrust/target/debug/deps/libserde_derive-60fcaaef46ab695d.so, I see this:
        linux-vdso.so.1 (0x00007ffe89cc3000)
        libgcc_s.so.1 => /home/linuxbrew/.linuxbrew/lib/gcc/current/libgcc_s.so.1 (0x00007f0cf1237000)
        libc.so.6 => /home/linuxbrew/.linuxbrew/opt/glibc/lib/libc.so.6 (0x00007f0cf09ef000)
        /home/linuxbrew/.linuxbrew/Cellar/glibc/2.35_1/lib64/ld-linux-x86-64.so.2 (0x00007f0cf125c000)

So, seems like libc.so.6 should point to the one from brew, but, for some reason, it seems to use /lib64/libc.so.6
If I try to set LD_LIBRARY_PATH to include brew (export LD_LIBRARY_PATH=$( brew --prefix glibc )/lib), I get segementation fault all over and I can't run any command at all
I was hoping you would be able to help me since I've been trying everything I know (and don't know but see on the internet), but nothing have worked
Thanks in advance

I FINALLY figured it out, and not that anyone would need it, but I'm gonna mention it just in case somebody faces the same issue.
I had a hunch that this would be an easy fix, but finding the fix was SUUUUPER HARD (at least for me).
The reason for this happening was the pkg-config binary. When I install brew (and set it up in my shell), it basically causes brew's pkg-config to be the first in PATH, and that's what messes up everything.
What I did was to make sure my system's pkg-config (in my case, /usr/bin/pkg-config) is picked up first, and everything is working fine now (so the other errors were a bit misleading, directing me to search for things that are not directly responsible)
One extra thing that I needed to do was to re-install rust for it to pick up the "good" libraries.
Anyway, quite a journey for me, and maybe here was my rubber duck since I finally solved my issue after almost one week spending time on the matter here and there!
Closing this as my issue is resolved


gitlab-runner: 17.1.0 -> 17.2.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/gitlab-runner/versions.
meta.description for gitlab-runner is: GitLab Runner the continuous integration executor of GitLab
meta.homepage for gitlab-runner is: https://docs.gitlab.com/runner/
Updates performed

Golang update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 17.2.0 with grep in /nix/store/q9j54iyjkw6wjahyfikhvqp87zw7yhp5-gitlab-runner-17.2.0
found 17.2.0 in filename of file in /nix/store/q9j54iyjkw6wjahyfikhvqp87zw7yhp5-gitlab-runner-17.2.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

gitlab-runner

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/q9j54iyjkw6wjahyfikhvqp87zw7yhp5-gitlab-runner-17.2.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gitlab-runner https://github.com/r-ryantm/nixpkgs/archive/3fb2fd6c73cf43b99c3a5b7964075c0dd8928331.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/3fb2fd6c73cf43b99c3a5b7964075c0dd8928331#gitlab-runner

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/q9j54iyjkw6wjahyfikhvqp87zw7yhp5-gitlab-runner-17.2.0
ls -la /nix/store/q9j54iyjkw6wjahyfikhvqp87zw7yhp5-gitlab-runner-17.2.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

gitlab-runner

Maintainer pings
cc @bachp @zimbatm @globin @krav @talyz @yayayayaka for testing.

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

1 package built:

gitlab-runner


Persistency doesnt work for me, "ya" not set

I followed the installation proecesses (yazi 0.2.5). Besides that "ya" for the package manager doesnt exist in a normal yazi installation for the package manager command (maybe you set an alias that i dont know of), ya seems also to be used inside of the plugins init.lua, and maybe therefore the persistence feature set in the yazi/init.lua doesnt work?

Hey,
The ya command doesn't exist in 0.2.5, at the moment you need to install the latest commit of yazi if you want to use it, if you use cargo you need to install both yazi-fm as well as yazi-cli.
If you have the plugin installed manually, you should just need to run the setup function in yazi/init.lua with the desired persistency mode, aka all or vim. Does the plugin work correctly besides the persistency?

Thanks for reply.

The ya command doesn't exist in 0.2.5, at the moment you need to install the latest commit of yazi if you want to use it, if you use cargo you need to install both yazi-fm as well as yazi-cli.

Thanks for the clarification!

If you have the plugin installed manually, you should just need to run the setup function in yazi/init.lua with the desired persistency mode, aka all or vim. Does the plugin work correctly besides the persistency?

Yes, besides the persistency everything works. Dont know if i have to activate something for the DDS, maybe there i the Problem. I switched to Yet Another Bookmark plugin, it works with persistency, but i would like to use your plugin for ease of use.

Ok, can you send some debug information? It would be helpful to get the following:

yazi --debug
the bookmarks.setup function that you are using in yazi/init.lua (if you don't mind you can just put the full yazi/init.lua file)
the output of ~/.local/state/yazi/yazi.log when you create a bookmark

And this is just to make sure, but you are in the latest commit of the plugin right?

I am also facing this issue, I am using v0.2.5 on macOS, and I would like to use "vim" mode for persistency, but when I do it, it creates a process and shows "99% 1 left" (in red color), but doesnt completes the process.

You must have updated the plugin with my commit from a couple of days ago right?
Upstream changed how DDS works a couple of days ago, seeing that you are in yazi v0.2.5 please checkout the plugin to the tag 0.2.5, you were probably having a different issue before.
If you could do that and then resend the yazi.log again it would be very helpful.
You config looks correct, so I don't think that it has anything to do with that. The only thing that I see is that you are using the vim persist method, so only upper case letters are saved to persistent memory.

Same problem. Finally solved by rm ~/.local/state/yazi/.dds

You must have updated the plugin with my commit from a couple of days ago right?
Upstream changed how DDS works a couple of days ago, seeing that you are in yazi v0.2.5 please checkout the plugin to the tag 0.2.5, you were probably having a different issue before.
If you could do that and then resend the yazi.log again it would be very helpful.
You config looks correct, so I don't think that it has anything to do with that. The only thing that I see is that you are using the vim persist method, so only upper case letters are saved to persistent memory.

2024-06-28T08:10:22.932115Z ERROR yazi::lives::lives: Kind must be alphanumeric with dashes
stack traceback:
	[C]: in field 'pub_to'
	[string "yazi-plugin/src/loader/loader.rs:66:28"]:88: in function <[string "yazi-plugin/src/loader/loader.rs:66:28"]:68>
	>[C]: in upvalue '_save_state'
	[string "yazi-plugin/src/loader/loader.rs:66:28"]:130: in function <[string "yazi-plugin/src/loader/loader.rs:66:28"]:113>

    at yazi-fm/src/lives/lives.rs:68

I deleted and redownloaded ur plugin. Here is the log

You must have updated the plugin with my commit from a couple of days ago right?
Upstream changed how DDS works a couple of days ago, seeing that you are in yazi v0.2.5 please checkout the plugin to the tag 0.2.5, you were probably having a different issue before.
If you could do that and then resend the yazi.log again it would be very helpful.
You config looks correct, so I don't think that it has anything to do with that. The only thing that I see is that you are using the vim persist method, so only upper case letters are saved to persistent memory.

2024-06-28T08:10:22.932115Z ERROR yazi::lives::lives: Kind must be alphanumeric with dashes
stack traceback:
	[C]: in field 'pub_to'
	[string "yazi-plugin/src/loader/loader.rs:66:28"]:88: in function <[string "yazi-plugin/src/loader/loader.rs:66:28"]:68>
	>[C]: in upvalue '_save_state'
	[string "yazi-plugin/src/loader/loader.rs:66:28"]:130: in function <[string "yazi-plugin/src/loader/loader.rs:66:28"]:113>

    at yazi-fm/src/lives/lives.rs:68

I deleted and redownloaded ur plugin. Here is the log. the vim mode seems more useful to me than all

@AnirudhG07  Can you git checkout yazi-0.2.5 in the plugin folder and try again. (You might also need to fetch the branch)
That seems to be the same issue as before, which is because I had to update the plugin to support upstream Yazi, so you should be in branch [yazi-0.2.5](https://github.com/dedukun/bookmarks.yazi/tree/yazi-0.2.5) of this plugin for it to work.


Title is blank on the cover page

Hi
I'm using this template with several documents, I love it, thank you so much.
On the last one, I have a weird behavior: the title is missing (or invisible) on the titlepage. I tried to play with font color, I also tried several things but I can't get it. The weird thing is that if I remove the background, then the title is set and visible. It looks like the title is here but behind the background.
The second weird thing is that the date is perfectly visible and also the title-rule (which I'd like to remove BTW)

``
Here is the markdown. What do I miss ?
---
title:
- 'AKS multitenancy whitepaper'
subject:
- 'AKS multitenancy whitepaper'
author-meta:
- 'Louis-Guillaume '
date:
- \today
date-meta:
- \today
keywords:
- 'AKS;whitepaper;guide;multitenant'
geometry:
- margin=1in
fontfamily:
- charter
header-includes:
titlepage: true
titlepage-text-color: |
  FF0000
titlepage-background: "cover.pdf"
colorlinks: true
page-background: "background.pdf"
---

I have the same exact issue using the demo template
---
title: "Vinaque sanguine metuenti cuiquam Alcyone fixus"
author: [Author Name]
date: "2017-02-20"
subject: "Markdown"
keywords: [Markdown, Example]
subtitle: "Aesculeae domus vincemur et Veneris adsuetus lapsum"
lang: "en"
titlepage: true,
titlepage-rule-color: "360049"
titlepage-background: "backgrounds/background1.pdf"
...

so title is missing, subtitle and date are OK


Add support for basic auth without ssl.

@tharna this needs to be fixed
fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "invocation": {"module_args": {"dest": "/etc/nginx/sites-enabled/all_apps.conf", "src": "all_apps.conf.j2"}, "module_name": "template"}, "msg": "AnsibleUndefinedVariable: 'basicauth_no_ssl_enabled' is undefined"}
I think default value (False?) for that variable is enough.


[fix][function] Use the schema set by the Function when it returns a Record

Motivation
Currently the schema set by a Function returning a Record is not taken into account.
Modifications
Don't set the schema to the initialized Sink Schema if the record is a OutputRecordSinkRecord
Verifying this change

[ ] Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

testGenericObjectRemoveFieldRecordFunction
testGenericObjectRemoveFieldRecordFunctionKeyValue

Does this pull request potentially affect one of the following parts:
no
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API: (yes / no)
The schema: (yes / no / don't know)
The default values of configurations: (yes / no)
The wire protocol: (yes / no)
The rest endpoints: (yes / no)
The admin cli options: (yes / no)
Anything that affects deployment: (yes / no / don't know)

Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] doc-not-needed
it's a fix

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

/pulsar-bot rerun-failure-checks


New-AsBuiltReport : Exception calling "Save" with "1" argument(s): "'.', hexadecimal value 0x00, is an invalid character."

Bug description
When running the report against a 2012R2 server I am receiving this error upon completion. New-AsBuiltReport : Exception calling "Save" with "1" argument(s): "'.', hexadecimal value 0x00, is an invalid character." The Word file is created however it is zero bytes. I have been able to successfully run it on the same machine against another target (albiet 2016) and it works flawlessly.
Command-line input
New-AsBuiltReport -Report Microsoft.Windows -Target '2012.domain.com' -Format Word -OutputFolderPath 'C:\Reports\Report' -ReportConfigFilePath 'C:\Reports\Config\Microsoft.Windows.json' -Verbose -Filename '2024-04-03 - Windows As Built'
Steps to reproduce

Ran Powershell script

Expected behaviour
Word file creation
Screenshots
No response
Operating System
Server 2019
PowerShell Version
PS C:\Windows\system32> $PSVersionTable
Name                           Value

PSVersion                      5.1.17763.5576
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.5576
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
PowerShell Modules
Name                            Version

AsBuiltReport.Core              1.4.0
AsBuiltReport.Microsoft.Windows 0.5.3
PScribo                         0.10.0
Additional Context
No response
Before submitting

[X] I have read and followed the bug reporting guidelines.
[X] I have read the documentation, and referred to the known issues before submitting this bug report.
[X] I have checked for previously opened & closed issues before submitting this bug report.

I saw that you ran the script with verbose enabled, can you send me the complete log?
if it is not possible maybe you can search if there is any other error message in the log

Looking into the log the script is failing at the Out-WordDocument cmdlet.
Can you re-run the report with the -Format HTML so I can rule out if the problem is just in the Word document format generation?
VERBOSE: [ 13:34:55:586 ] [   Word   ] - Processing document part '/word/document.xml'.
VERBOSE: [ 13:34:55:601 ] [   Word   ] - Writing document part '/word/document.xml'.
PS C:\Windows\system32> TerminatingError(Out-WordDocument): "Exception calling "Save" with "1" argument(s): "'.', hexadecimal value 0x00, is an invalid character.""
>> TerminatingError(Out-WordDocument): "Exception calling "Save" with "1" argument(s): "'.', hexadecimal value 0x00, is an invalid character.""

Hi:
I have found the problem, if you want to test the solution before the next version is released just change the following line:
File Src/Private/Get-AbrWinHostStorageVolume.ps1 at line 30:
# From:
$HostVolumes = Invoke-Command -Session $TempPssSession -ScriptBlock {  Get-Volume | Where-Object {$_.DriveType -ne "CD-ROM" -and $NUll -ne $_.DriveLetter} }
# To:
$HostVolumes = Invoke-Command -Session $TempPssSession -ScriptBlock {  Get-Volume | Where-Object {$_.DriveType -ne "CD-ROM" -and $_.DriveLetter} }

After saving the changes to the files don't forget to import the module:
Import-Module AsBuiltReport.Microsoft.Windows -Force

After some time researching this issue I am unable to identify where the problem lies. At first I thought that the problem was related to the Pscribo module but now I am convinced that it is a problem with the powershell version of windows 2012/2012R2.

I will leave the issue open so that other users with the same problem can identify that the issue is not fixable.

Hi:
I found the issue, it was difficult to diagnose but easy to fix....
if you want to test the solution before the next version is released just change the following line:
File Src/Private/Get-AbrWinHostStorageVolume.ps1 at line 30:
# From:
$HostVolumes = Invoke-Command -Session $TempPssSession -ScriptBlock {  Get-Volume | Where-Object {$_.DriveType -ne "CD-ROM" -and $NUll -ne $_.DriveLetter} }
# To:
$HostVolumes = Invoke-Command -Session $TempPssSession -ScriptBlock {  Get-Volume | Where-Object {$_.DriveType -ne "CD-ROM" -and $_.DriveLetter} }

After saving the changes to the files don't forget to import the module:
Import-Module AsBuiltReport.Microsoft.Windows -Force

I have encountered this issue, and in this instance, the above is indeed the fix.
We are getting all drives, even those without a drive letter. Somewhere in the mix, a "0x0" is being added for the drive letter of that disk.
The issue is caused because the "XML" body of the word document contains invalid characters
When PSCribo tries to save the XML we have in memory to an "open-xml formatted word document", it fails, as it contains an invalid character.
If you were to cleanse invalid characters from the xml output prior to trying to save it, that should resolve this issue for any module.

Hi:
I found the issue, it was difficult to diagnose but easy to fix....
if you want to test the solution before the next version is released just change the following line:
File Src/Private/Get-AbrWinHostStorageVolume.ps1 at line 30:
# From:
$HostVolumes = Invoke-Command -Session $TempPssSession -ScriptBlock {  Get-Volume | Where-Object {$_.DriveType -ne "CD-ROM" -and $NUll -ne $_.DriveLetter} }
# To:
$HostVolumes = Invoke-Command -Session $TempPssSession -ScriptBlock {  Get-Volume | Where-Object {$_.DriveType -ne "CD-ROM" -and $_.DriveLetter} }

After saving the changes to the files don't forget to import the module:
Import-Module AsBuiltReport.Microsoft.Windows -Force

I have encountered this issue, and in this instance, the above is indeed the fix. We are getting all drives, even those without a drive letter. Somewhere in the mix, a "0x0" is being added for the drive letter of that disk. The issue is caused because the "XML" body of the word document contains invalid characters When PSCribo tries to save the XML we have in memory to an "open-xml formatted word document", it fails, as it contains an invalid character. If you were to cleanse invalid characters from the xml output prior to trying to save it, that should resolve this issue for any module.

The problem is that I don't own the PScribo code and I can't find a way to reproduce the error that will allow me to create an issue in the PScribo repository.
If you have a way to reproduce the error and explain it well, would it be possible for you to create an incident in the PScribo repository?
Thanks.


Suggestion: Change default lights-on duration setting to 0

I suggest a hard-coded default setting for the duration should be 0 (i.e., "infinite on") such that lights the user switches on through this integration are subject to the user's own later action to switch off or a user-owned automation to switch off. The current setting of 60 causes any light turned on by this integration to switch off in 1 minute.
Alternatively/additionally, this should be a user-settable variable from the Device page (still with default setting of 0).
https://github.com/HubitatCommunity/hubitat_ring_integration/blob/bccfc9e054ae05815351da1c4552b605d30bc3b8/src/drivers/ring-virtual-beams-group.groovy#L64

Great request. My personal preference would be we keep the default so we don't break current users, but - per your suggestion - we add this as a user-settable option during configuration.

@k3vmcd  - Do you know what the Ring App default is here? When you switch it on today via the Ring app, is it infinite on?

Default is "last used", but when creating a new group it starts at infinite on.


Make encryption type explicit in ctr

Right now there are just a ton of flags and I cannot follow the code to know what type of encryption is being used when I pass what flags.
These need to be explicit and will help the code be easier to read and follow.

cc @lumjjb

There is also the way []byte are handled in the encryption code and how they are overloaded to mean different things, i.e. https://github.com/containerd/containerd/blob/master/pkg/encryption/encryption.go#L87 then it being something different here: https://github.com/containerd/containerd/blob/master/pkg/encryption/encryption.go#L100
Makes the code extremely hard to follow.  We need to clean this up.

Okay - we will add a flag for --enc-protocol [openpgp/jwe/pkcs7] and also add stronger typing to makes things clearer.

FYI: We currently choose the encryption scheme by the type of key being used.

Here is a patch that I started working on but got hungup on the CLI where its just mashed together and I don't know how it is routing.  For someone unfamiliar with the code, you really cant tell what encryption type is going to be used from those options:
https://github.com/containerd/containerd/compare/master...crosbymichael:set-types?expand=1

JWE 'responds' to plain RSA and EC keys, PKCS7 to storage key certificates, and OpenPGP to OpenPGP keys. They are all distinct and the option would be more or less redundant...

Then maybe the flags need better names, it just needs to be more explicit so I don't have to read though docs and know what flag goes to what wrapper

We allow to specify multiple recipients on the command line, such as in this command line here:
./bin/ctr images encrypt  \
--gpg-homedir /tmp/tmp.AGrSDkaSad/gpg2 \
--recipient<EMAIL_ADDRESS>\
--recipient<EMAIL_ADDRESS>\
--recipient /tmp/tmp.AGrSDkaSad/mypubkey.pem \
--recipient /tmp/tmp.AGrSDkaSad/mypubkey2.pem \
--recipient /tmp/tmp.AGrSDkaSad/clientcert.pem\
--recipient /tmp/tmp.AGrSDkaSad/client2cert.pem \
docker.io/library/alpine:latest docker.io/library/alpine:enc

The first two are gpg recipients, the 2nd two will use JWE, and the last two use PKCS7. Since the encryption technologies take non-overlapping types of keys (see note above) there was no need to force using a certain encryption technology. PKCS7 in golang implementation requires a X509 certificate for a storage key for example and will not take a plain RSA key.
Internally we detect the key types and sort them into a map. Then pass this map to all key wrappers and let them react to the keys they find there. If they find no recipient keys, they will not wrap the symmetric layer encryption key, if they do they will wrap it.

Yea we can add a flag with the encryption types, and provide more specific error messages as well..

I would just like the code to be easier to follow because things like dcparameters [][]byte is super hard to follow and the way []byte are used in the code makes it very abstract.  It is not maintainable by people like me that did not develop the feature.  I would like this to be cleared up before we add more features

The issue with the dcparameters is that we need to pass them through the RPC to the applier. So rather than working with concrete data types like RSA.PrivateKey we parse them 'later' and the keys live as byte arrays. The guidance of what type of key a key has been detected to be is given by the key strings of the dcparameters map:
https://github.com/containerd/containerd/blob/master/cmd/ctr/commands/images/crypt_utils.go#L398
Would help in this case here to introduce types like  type pubkey []byte
		gpgRecipients [][]byte
		pubkeys       [][]byte
		x509s         [][]byte

so that we can then write pubkeys []pubkey ?
https://github.com/containerd/containerd/blob/master/cmd/ctr/commands/images/crypt_utils.go#L86

I think we can have a nicer struct at the client side, and add a convert to/from function to config.CryptoConfig...
So once it gets processed into a CryptoConfig the interface is no longer able to be introspected, and we just have an Export(config.CryptoConfig) map[string][]byte, and Import(map[string]byte) config.CryptoConfig. Then we have to do the import/export just once on each side for client/server.

FYI: Here's the patch that passes the dcparameters through to the applier via the ApplyRequest:
https://github.com/containerd/containerd/pull/3426/commits/0bf78f8f2f38de9793d61a291b121f9775d16519

I've created a draft of how we can abstract CryptoConfig assembly into KeyBundles. These are abstracted structures which are returned by calling constructors for each key type. These are part of the encryption library (which will be part of OCI). The public interfaces which the code base will interact with is as follows:
// NewPkcs7KeyBundle returns a KeyBundle that contains the required configuration for using
// the pkcs7 keyunwrap interface
func NewPkcs7KeyBundle(x509 *[]byte, privKey *[]byte, privKeyPassword *string) config.KeyBundle

// NewJweKeyBundle returns a KeyBundle that contains the required configuration for using
// the jwe keyunwrap interface
func NewJweKeyBundle(pubKey *[]byte, privKey *[]byte, privKeyPassword *string) config.KeyBundle

// CombineKeyBundles takes a KeyBundle list and creates a single KeyBundle
// containing the crypto configuration of all the key bundles
func CombineKeyBundles(kbs []KeyBundle) KeyBundle

// KeyBundle represents a set of keys to perform encryption/decryption
type KeyBundle struct {
	// CryptoConfig needed to perform encryption/decryption
	CryptoConfig CryptoConfig

	// SupportedProtocols is the list of supported protocol names
	SupportedProtocols []string
}

Sample patch: https://github.com/lumjjb/containerd/commit/960d75ea668f8a6bbff2f382d88653a7acc3a5d5

Will the key types be auto-detected when parsing the parameters or do you force a type? Would a user always need to know the encryption technology being used when passing a key for decryption? What is the format for (K8s) going to be to pass in keys and passwords?

Actually im going to change this to remove supported protocols, it seems redundant.. We can move the autodetect logic to the encryption package... If we add all the constructors to the config package technically we can also make private the fields of Encrypt/DecryptConfig.

It is redundant at the moment and would remain so if we accept that JWE will be used for RSA keys and there's no other choice coming up. Otherwise we could sort the key material under different keys of the parameters map(s), which IMO should be fine for as long as it's documented.

Is this issue resolved with #3452 and #3460?


Kurasu de nibanme

Source information
Sakuranovel
Steps to reproduce
The novel is not open

Expected behavior
The novel is open
Actual behavior
The novel in not opened
LNReader version
1.1.19
Android version
Android 8.1
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 1.1.12.
[X] I have updated all installed extensions.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

duplicated of https://github.com/LNReader/lnreader-plugins/issues/657


Rank badge not visible in Activity Analysis

Hey, when I'm making an activity analysis I always saw the rank badge (Rank 4,3,2,1, Word Tour). since last update I'm missing it. I'm using Chrome.

v8.7.2 should fix this.  It's rolling out now.  Thanks @alexcolo


downloading the data to csv file

the content in the tag column is wrong.

A little bit difficult to handle for me.

fixed.


kubeVesrtion mismatch

What happened?
Kubernetes version = 1.23.0
When I try to create resources with this package I get the following output.
`Previewing update (xxxxxx):
Type
pulumi:pulumi:Stack

├─ kubernetes:cert-manager.io/v1:Issuer
├─ kubernetes-cert-manager:index:CertMa
└─ kubernetes:helm.sh/v3:Release

Diagnostics:
kubernetes:helm.sh/v3:Release (cert-manager-helm):
error: failed to create chart from template: chart requires kubeVersion: >= 1.21.0-0 which is incompatible with Kubernetes v1.20.0
pulumi:pulumi:Stack (xxxxx-dev):
error: Error: invocation of kubernetes:helm:template returned an error: error reading from server: read tcp <IP_ADDRESS>:50939-><IP_ADDRESS>:50936: use of closed network connection
at Object.callback (/Users/xxxx/node_modules/@pulumi/kubernetes/node_modules/@pulumi/runtime/invoke.ts:172:33)
at Object.onReceiveStatus (/Users/xxx-xx/node_modules/@grpc/grpc-js/src/client.ts:338:26)
at Object.onReceiveStatus (/Users/xxx/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34)
at Object.onReceiveStatus (/Users/xxx/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48)
at /Users/xxxxx/node_modules/@grpc/grpc-js/src/call-stream.ts:276:24
at processTicksAndRejections (node:internal/process/task_queues:78:11)
`
Steps to reproduce
const manager = new certmanager.CertManager("cert-manager", {
    installCRDs: true,
    helmOptions: {
        namespace: namespace.metadata.name,
    },
});

// Create a cluster issuer that uses self-signed certificates.
// This is not very secure, but has the least amount of external
// dependencies, so is simple. Please refer to
// https://cert-manager.io/docs/configuration/selfsigned/
// for additional details on other signing providers.
const issuer = new k8s.apiextensions.CustomResource("issuer", {
    apiVersion: "cert-manager.io/v1",
    kind: "Issuer",
    metadata: {
        name: "selfsigned-issuer",
        namespace: namespace.metadata.name,
    },
    spec: {
        selfSigned: {},
    },
});

Expected Behavior
Since my version of kubernetes is higher than the desired one, I expect the error not to occur.
Actual Behavior
error: failed to create chart from template: chart requires kubeVersion: >= 1.21.0-0 which is incompatible with Kubernetes v1.20.0
Even though my eks-kubernetes version is 1.23.0
Output of pulumi about
No response
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

While I did not reproduce the issue, this might have something to do with the version of K8S client linked into the Pulumi provider; we'll try to update to the latest pulumi-kubernetes/sdk and get back to you on this.

Coming back to this, I'm failing to repro with this kubectl/k8s versions. Could you please provide the output of pulumi about and kubectl version --short?:
kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.26.1
Kustomize Version: v4.5.7
Server Version: v1.25.3

The program I'm trying is below. I run pulumi up - have to run it twice because the first time it fails with a connection issue, something is not awaiting the creation properly; but the second run succeeds:
  kubernetes:cert-manager.io/v1:Issuer (issuer):
    error: resource repro-pulumi-kubernetes-cert-manager-18/selfsigned-issuer was not successfully created by the Kubernetes API server : Inter
nal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-helm-1955d4ec-webhook.
repro-pulumi-kubernetes-cert-manager-18.svc:443/mutate?timeout=10s": dial tcp <IP_ADDRESS>:443: connect: connection refused

import * as certmanager from "@pulumi/kubernetes-cert-manager";
import * as k8s from "@pulumi/kubernetes";

const ns = new k8s.core.v1.Namespace("tempns", {metadata: {
    name: "repro-pulumi-kubernetes-cert-manager-18",
}});

const manager = new certmanager.CertManager("cert-manager", {
    installCRDs: true,
    helmOptions: {
        namespace: ns.metadata.name,
    },
});

// Create a cluster issuer that uses self-signed certificates.
// This is not very secure, but has the least amount of external
// dependencies, so is simple. Please refer to
// https://cert-manager.io/docs/configuration/selfsigned/kube
// for additional details on other signing providers.
const issuer = new k8s.apiextensions.CustomResource("issuer", {
    apiVersion: "cert-manager.io/v1",
    kind: "Issuer",
    metadata: {
        name: "selfsigned-issuer",
        namespace: ns.metadata.name,
    },
    spec: {
        selfSigned: {},
    },
});

And pulumi about:
CLI
Version      3.52.1
Go Version   go1.19.5
Go Compiler  gc

Plugins
NAME                     VERSION
aws                      5.28.0
docker                   3.6.1
eks                      0.40.0
kubernetes               3.23.1
kubernetes-cert-manager  0.0.5
nodejs                   unknown

Host
OS       darwin
Version  13.1
Arch     x86_64

This project is written in nodejs: executable='/Users/t0yv0/.nix-profile/bin/node' version='v18.12.1'

Current Stack: t0yv0/repro-pulumi-kubernetes-cert-manager-18/dev

TYPE                                       URN
pulumi:pulumi:Stack                        urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::pulumi:pulumi:Stack::repro-pulumi-kubernetes-cert-manager-18-dev
pulumi:providers:kubernetes                urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::pulumi:providers:kubernetes::default_3_23_1
kubernetes:core/v1:Namespace               urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::kubernetes:core/v1:Namespace::tempns
pulumi:providers:kubernetes-cert-manager   urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::pulumi:providers:kubernetes-cert-manager::default_0_0_5
kubernetes-cert-manager:index:CertManager  urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::kubernetes-cert-manager:index:CertManager::cert-manager
kubernetes:cert-manager.io/v1:Issuer       urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::kubernetes:cert-manager.io/v1:Issuer::issuer
pulumi:providers:kubernetes                urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::pulumi:providers:kubernetes::default
kubernetes:helm.sh/v3:Release              urn:pulumi:dev::repro-pulumi-kubernetes-cert-manager-18::kubernetes-cert-manager:index:CertManager$kubernetes:helm.sh/v3:Release::cert-manager-helm

Found no pending operations associated with dev

Backend
Name           pulumi.com
URL            https://app.pulumi.com/t0yv0
User           t0yv0
Organizations  t0yv0, pulumi

Dependencies:
NAME                             VERSION
@pulumi/awsx                     0.40.1
@pulumi/eks                      0.40.0
@pulumi/kubernetes-cert-manager  0.0.5
@pulumi/kubernetes               3.23.1
@pulumi/pulumi                   3.52.1
@types/node                      8.10.66
@pulumi/aws                      5.28.0

Pulumi locates its logs in /var/folders/gk/cchgxh512m72f_dmkcc3d09h0000gp/T/ by default

I believe that this is fixed in the Pulumi Kubernetes provider:
https://github.com/helm/helm/blob/e63083492b1917b361321ef6951fad08db81d11f/pkg/chartutil/capabilities.go#L32-L49

The secondary error seen by @t0yv0 (selfsigned-issuer was not successfully created) is solvable by having the issuer depend on the manager.  An Issuer cannot be created until the cert-manager is fully deployed (e.g. its webhooks must be fully initialized).
const issuer = new k8s.apiextensions.CustomResource("issuer", {
    apiVersion: "cert-manager.io/v1",
    kind: "Issuer",
    metadata: {
        name: "selfsigned-issuer",
        namespace: ns.metadata.name,
    },
    spec: {
        selfSigned: {},
    },
}, { dependsOn: [manager]});

I'm closing this issue, @bmetea please reopen if necessary.


Document "Network settings"

Path to page with content (do not include domain name):
/en/os/1.14.x/api/settings/
What content is incorrect?
The settings reference lacks the "Network Settings"
What should the content say or communicate?
There is an ongoing effort to move the settings reference currently located on the Bottlerocket README to Bottlerocket.dev
This can be accomplished using the Settings Documentation DSL. Effectively, the settings written out in the README's markdown needs to be converted to this DSL format. You can see an example of how this looks in the ECS settings reference TOML file as well as the actual ECS content markdown file.
The file should be located at /data/settings/1.14.x/network.toml and /content/en/os/1.14.x/api/settings/network/_index.markdown.

I missed that DNS was technically a separate category - tracked in #292


New package: TuringGLM v0.1.0

Registering package: TuringGLM
Repository: https://github.com/TuringLang/TuringGLM.jl
Created by: @storopoli
Version: v0.1.0
Commit: 5ab0001d8ae3e3d102b04c5a030ac434c9f136a8
Reviewed by: @storopoli
Reference: https://github.com/TuringLang/TuringGLM.jl/commit/5ab0001d8ae3e3d102b04c5a030ac434c9f136a8#commitcomment-63650266
Description: Bayesian Generalized Linear models using @formula syntax.

@yebai How do I register a package that uses Turing.jl under the hood and is not supported on Julia 1.7?

I'm not quite sure how to do that. But I'm aiming to merge the Julia 1.7 support PR by this weekend. Would it be possible to wait for a few days?

Sure, how do I do this? I just let this PR open and wait? Or I close and open a new one once Turing supports Julia 1.7?

@rik, after we launch version 1.0.0 since https://github.com/TuringLang/TuringGLM.jl/pull/33 is merged. We need to retrigger this.

Please close this.


inital commit

Could we also add a license + copyright headers to our files (with Voltron Data as the copyright holder)?

You had already added the LICENSE. 🙂 I just added a copyright header to all files except

LICENSE (obviously)
poetry.lock because that's autogenerated
README.rst (comments are hard in RST and it seems unnecessary)
repo.json (comments are hard in JSON)

Any reason not to use markdown for this instead of rst?

RST integrates a little better with Sphinx if we want to set that up in the future, and I think it's a little more feature-rich than Markdown. But I know a lot more people are familiar with writing Markdown. (Comment blocks are equally hacky in both of them.)
I just continued with RST because I didn't want to refactor what @joosthooz had written originally.


mongoose 5 - fix not working correctly

@buunguyen I tried latest version with the new mongoose 5 fix, unfortunately the rewritten fix does not work in my setup. I guess because I'm using the bluebird library.
const Promise = require('bluebird'); // bluebird
mongoose.Promise = Promise;

Therefore
if (mongoose.Promise === Promise) { is not true in my case. Anyways, I have seen there is a mongoose.version variable available.
I'll create a PR - please review.
thanks
Simon

Not working as expected: If I replace "mongoose.Promise === Promise" by true, the plugin works perfect but using the last uploaded code, this conditional returns false so issue still happening.

@yamifr07 indeed, this is the same issue I had. I opened already a PR that fixes it.

Please try 3.1.1. Thanks for suggesting using version. Commit: https://github.com/buunguyen/mongoose-deep-populate/commit/8c5ae6df653d1b385a1434189ab7f9e0578c67c9

@buunguyen version 3.1.1 not found on npm


Danfoss Ally TRV compatible with ZHA

Confirming Danfoss Ally Zigbee 3.0 TRV. I paired it today with Home Assistant 0.117.
Battery reports are OK, TRV responds to temperature changes in ZHA instantly.

thanks


new(build): add individual cmake sanitizer options, enable in e2e

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area CI

Does this PR require a change in the driver versions?
No

What this PR does / why we need it:
Does three things:

introduces cmake options USE_ASAN and USE_UBSAN
enables those in CI tests
also enables them in e2e

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: LucaGuerra
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [LucaGuerra]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.15.0

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, LucaGuerra
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,LucaGuerra]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: d586f96cbd48f13ae20e2d7ba0a9e5d518c589ad

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, leogr, LucaGuerra
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,LucaGuerra,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Add support for other configurations for nix flake.

(see shell.nix for mac dependencies)

[ ] MacOS x86_64
[ ] MacOS aarch64
[ ] Linux aarch64

Closed by #2902


Developer Documentation

I've been stalking this project for several months and found the goals for this project admirable.  I originally intended to contribute by providing docker support to simplifying onboarding new developers.  But before I could start, I needed more information on the architecture and technology stack behind this project.  I ran across the issues mentioned in #82 - lack of documentation.
I've spent several hours going through, the Wiki, readme files, issues tracker and CodeTour.  Quite a bit of information about the system is documented but is scattered.  I liked the way the Wiki was used as a way of gathering the requirements for the project.  It was primarily focused on the objective with a little implementation detail.  There was sufficient information readme files for the front-ends and back-end to get them built.
What was lacking was a big picture view of all the interconnected parts and dependencies.
I would like to propose that we create a docs folder for each of the front-ends, the back-end and the root.

\docs

documents that are relevant to the Two Weeks Ready
architecture diagram
description of source code layout
developer getting started guide
authorization and authentication
3rd party dependencies

\2wr-app\docs

documents specific to the implementation of the app

\admin\docs

documents specific to the implementation of the admin portal

\api\docs

documents specific to the implementation of the api service

The objective is for a new developer to be able to get a good overview of the project from the documentation at the root of the project first.  Then, look at the specific details of the component to which they wish to contribute.
I have a draft of an overview and architecture diagram but would like to know if this approach is acceptable. I'm also looking for further feedback and suggestions 😃.

Completely acceptable, feel free to proceed.

@codingbandit
Can we label this issue documentation?
As I started this process, I realized that there are many things that we can document to enable faster onboarding other than a generic technical overview.  The obvious one is a Build Guide for developers - step-by-step instructions to create a buildable and debuggable system.
What are the priority items that need to be documented?

From #78, cover the following

Installations (what do i need to install?)
Configuration (what do i need to configure?)
Running (what do i need to run?)


Support GEMM-GELU fusion with split AG overlap

Uses NVTE_GEMM_GELU_FUSION env var to control the GEMM-GELU fusion.

One thing to note here is that turning on the fusion incurs 2 additional memsets per split unit of GEMM-AG.
With CUBLAS_FORCE_XMMA_KERNEL_INIT=DEVICE, 1 memset gets replaced by a workspace init kernel, but not both.

/te-ci pytorch

The best place to test this feature: https://github.com/NVIDIA/TransformerEngine/blob/a95006170cf36712dcfb4cb27e32431e73125a2c/tests/pytorch/test_numerics.py#L1076

@timmoon10 Thanks for the review! I'll test again with the suggested changes and also try out the TE unit test (Przemek told me that CI won't catch the NVTE_GEMM_GELU_FUSION=1 case so I'll have to test it separately).

/te-ci pytorch

/te-ci pytorch

@timmoon10 There's an issue with the test_layernorm_mlp_accuracy unit test because ub_split_ag is always set to False, as it's not parameterized like other arguments here. This means the GEMM-GELU fusion code path does not get tested even with NVTE_GEMM_GELU_FUSION=1.

@timmoon10 Changes are complete, I've verified that the unit test now actually tests the GEMM-GELU fusion code path.
I'm getting the following test result, but I get the same 2 failures without fusion so they seem irrelevant to the fusion.
======================================================================================================================================================================================================== short test summary info =========================================================================================================================================================================================================
FAILED tests/pytorch/test_numerics.py::test_layernorm_linear_accuracy[True-RMSNorm-126m-2-dtype0] - AssertionError: Outputs not close enough.Location of the maximum difference: 2448 with -0.003937006462365389 vs -0.003717889543622732 (diff 0.0002191169187426567).
FAILED tests/pytorch/test_numerics.py::test_layernorm_linear_accuracy[False-RMSNorm-126m-2-dtype0] - AssertionError: Outputs not close enough.Location of the maximum difference: 2448 with -0.003937006462365389 vs -0.003717889543622732 (diff 0.0002191169187426567).
======================================================================================================================================================================================== 2 failed, 346 passed, 117 warnings in 111.16s (0:01:51) =========================================================================================================================================================================================

Reverted changes to test_layernorm_mlp_accuracy, the PR should be good to go now.
Performance is still questionable due to memsets but that should be resolved on the cuBLAS side.

/te-ci pytorch

/te-ci pytorch


update Redshift alter_relation_add_remove_columns macro and make sure it respect case sensitivity with column quoting

… test case sensitivity is checked
https://github.com/dbt-labs/dbt-adapters/issues/250
docs dbt-labs/docs.getdbt.com/#

Problem
user raised issue around "While working with DBT incremental config: on_schema_change='append_new_columns'
The append new columns flag is not able to capture the correct case-sensitive column name and add it to the incremental table causing the run to fail."

Solution
add a new test to dbt-adapters-tests to check that column quoting case sensitivity is expressed correctly, update all macros in adapters as needed if they do not use the default implementation and test default implementing macros to see if we need to update the dbt-adapters macro as well.

Todo:

[ ] test with rest of adapters (see if dbt-adapter default version of macro needs to be changed or any other adapter override version of macro).
[ ] make sure new tests works in all adapters as needed
[ ] update requirements files either dev-requirements or project.toml files before merger

Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX

raising just as this happened at a very coincidental time but with the update to enable_case_sensitive_identifier is there any extra testing we should do to make sure this change is actually the fix and not that?


[SWARM-1060] Upgrade to wildfly-camel-4.5.0 - WIP

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you created a JIRA and used it in the commit message?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[ ] Have you built the project locally prior to submission with mvn clean install?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test


Unable to migrate db on remote server

As per the examples provided, pg-migrator works fine when done locally(localhost).
i.e. pg-migrator postgres://username:password@localhost:5432/db_name
But I have my database set up on a different server.
When tried to migrate db on different server it shows the belowmention error :
"Migration could not be completed, Error: getaddrinfo ENOTFOUND"
i.e. pg-migrator postgres://username:password@db_server_IP:5432/db_name
Please suggest a suitable solution for the above issue.

I have just tried and succeed with the following command. Are you sure that your postgresql server configured to listen and allow remote connections?
pg-migrator<EMAIL_ADDRESS>

My project gets connected to the remote db server.
The error occurs only when I migrate the db changes to remote server using pg-migrator  that too from inside the same project.

Have you tried remove the port?

Have with port
pg-migrator postgres://username:password@db_server_IP:5432/db_name
and without port
pg-migrator postgres://username:password@db_server_IP:/db_name
pg-migrator postgres://username:password@db_server_IP/db_name
Still the same issue.


Feature Requests (not yet ranked)

Just starting a list of pieces of functionality that would be great to roll into LimbForge

[ ] TOS popup at begining of use

[ ] Instructions for deriving measurements

[ ] Feedback buttons for designs undergoing Beta testing

[ ] Contextual dropdown menus for designs that have parts with more than one possible configuration (example:  RR has fingers with and without fingernails.  It would be great for users to be able to access configuration this way rather than by having the configurations as top-level "RR-with-nails" and "RR-without-nails" or for the different whippletree tensioners)

[ ] Dropdown for machine type, populated with top five machines from 3DHubs trend report and a sixth "other"

[ ] Function for creating Handathon packages that takes the parameters design type, and quantity and outputs a zip consisting of folders of print files for the design in the appropriate number of left and right configurations for the distribution of sizes derived from LimbForge's analytics, and amanifest with quantities of each size.  Idea that no matter how many designs are requested, the button will always deliver a distribution of sizes that matches what is typically downloaded from LimbForge.

[ ] Add a "print with 3DHubs" button, as is seen on STL files on instructables.  Button should call handzipper to package the current configuration of STLs and send it to 3DHubs for local quoting.

[ ] From Peter Binkley:  allow users to select which tolerances (tight, medium, loose) they would like to download.  Similar to machine-specific configuration, but different UI/UX-- maybe base decision on user feedback.

[ ] Add a "include PDF assembly manual" check box that includes the appropriate assembly doc in the download package.

[ ] Ability to load image of hands into the environment, calibrate the image, and overlay the design over the image to size.

[ ] Add (contextual) buttons for ordering kits for each specific hand design.

[ ] Add (contextual buttons that link to assembly information (say an instructable) for each hand design.

[ ] Add button that links to design source files (if available)

[ ] Migrate to lettered sizing system (size A, B, C, D... etc) and pair with debossed size/version info on printed parts.

TOS popup at begining of use
In #18

since this is a work in progress I moved it to a wiki page. Once each of these things are solidified we can make github issues for them individually: https://github.com/e-nable/LimbForge/wiki/Feature-requests-(not-yet-rated)


run app get a debug error without compile error and link error

i remove the gladLoadGL parameter after it reported  an error message  "don't take a parameter ", so it can be compiled and linked successfully. but it arise a debug error when i run it .

The project is missing 2 files：


Wirb 2.0 comes with a timeout option. If Wirb is not fast enough to render the colored string in a few seconds, it willl output the uncolored original one.


More control over automatic system config changes

          I would also prefer some sort of warning that OrbStack has added a second entry. In general, I understand that you’re making changes that are required for the smoothest operation of OrbStack, but simply changing files that do not belong to OrbStack is not good for a lot of reasons. I manage `~/.ssh/config` and a lot of other files with chezmoi, so any changes made by OrbStack are transient at best unless I update my source file.

The minimum that should be happening is that somewhere (maybe a new screen on the GUI, a subcommand on the CLI) OrbStack should be reporting what changes have been made. It would be more intrusive, but I would prefer it if the changes were prompted with a warning "OrbStack may not work correctly if this is not changed". But at the moment, no matter how good OrbStack is (and it is very good), it‘s not a well-behaved citizen on my computer because it keeps making changes to files that it does not own with neither warning nor after-the-fact notification.
The only change that OrbStack prompts for (the docker socket symlink) is the one that I personally never want because Docker supports contexts and well-behaved programs using Docker should also support contexts (I get that it’s imperfect, because it looks like contexts are managed outside of the Docker API), and I think that if you didn’t have to get root permission to create that symlink, you wouldn’t prompt for that, even though that symlink does not belong to OrbStack to create. (I personally can’t imagine anyone running OrbStack and Docker Desktop side-by-side, but if they were, the war over the symlink ownership would be more than annoying.)
Originally posted by @halostatue in https://github.com/orbstack/orbstack/issues/544#issuecomment-1684948765

The plan is to improve on this in the future without adding friction, but it's not very high priority.

A similar thing I'd like: the ability to temporarily disable/remove the various config changes and symlinks that OrbStack adds.
For example: I recently had to turn OrbStack off and temporarily use Docker Desktop again for a work project. Simply quitting the OrbStack app doesn't remove any of the symlinks from ~/.local/bin, so when I try to run docker from Docker Desktop, OrbStack's executable shadows it. I understand creating/removing the symlinks on app start/stop might be a bit much, but that would make life so much easier as a configurable option. 😅

@Nezteb It doesn't matter what provides the executables, as long as you have them. Change the Docker context to go back to Docker Desktop: https://docs.orbstack.dev/install#docker-context
You can already disable auto context switching: Settings > System > Switch Docker & Kubernetes context automatically
(Also, mind elaborating on why you had to use Docker Desktop again? The goal is that switching back and forth should never be necessary.)

mind elaborating on why you had to use Docker Desktop again?

In this case it was no fault of Orbstack; my employer's IT department hasn't gotten around to whitelisting the Orbstack application for installation yet. So far the only whitelisted applications for containerized development are Docker Desktop, Podman Desktop, and Rancher Desktop. 😅
For now I use Orbstack for all personal projects and Docker Desktop for work projects. 😄

Another data point regarding changing ~/.ssh/config without user action:
Probably nothing new, but I have my dotfiles, including this config in git. I use this across multiple machines, not all of them have OrbStack installed (some are not even macOS). That's what I'd like to have in my SSH Config, which is a little pointless, as OrbStack adds Include ~/.orbstack/ssh/config as first line.
# Include OrbStack SSH config if orb is installed
Match exec "type orb > /dev/null"
  Include ~/.orbstack/ssh/config
# …

PS: Technically SSH will only log in debug1 if the file does not exists you're trying to include, but still, would like to have that a little cleaner.

@tisba This one is a little tricky. Your config does work but not when OrbStack checks it, because macOS starts apps with a very minimal PATH that doesn't match your shell or even include orb in many cases.
Should be fixed in the next version though.

In v1.7.4 and later, OrbStack only edits ~/.ssh/config and ~/.zprofile (or ~/.profile) at most once, so you can undo the change and it won't be added back.


Can make it editable after being readonly

Im using jquery 2.0.3 and trying to use this functionality in order to make a select (second element) readonly if a certain value of a select (first element) option is chosen or editable if another option is chosen with the same select element. But I couldnt make it work correctly. It turns readonly in the right way but can make it editable after beeing readonly

I'm gonna look into it and get back to you. Thanks for the report!

Done! I'm sorry for your troubles and I thank you for reporting the problem.
I also made a demo of your case, you can see it here https://jsfiddle.net/g9h7jyxv/


chore: add naming convention rules and test cases

@onebytegone this is ready for your 👀

FYI @jthomerson @yokuze This should greatly improve the naming convention linting in TS projects. For now, these rules are in a "beta" state. Once a few projects have been upgraded to a hash version of the config successfully, we can cut a new release.


add additional services workflow to data retention / management

wis2box data retention is currently focused on managing the wis2box wis2box-public bucket on MinIO storage alongside the WIS2BOX_STORAGE_DATA_RETENTION_DAYS environment variable.
API data (ES indices) should be included as part of the retention (@tomkralidis).  We should also consider whether metrics should be flushed, or whether metrics should have its own retention period(s) (@maaikelimper).
Finally, we may want to migrate WIS2BOX_STORAGE_DATA_RETENTION_DAYS to WIS2BOX_DATA_RETENTION_DAYS

Validated that wis2box data clean clears API backends as expected.


deis run command taking over 60 seconds to complete

From @vdice on October 5, 2016 21:37
CI is seeing failures when running deis run env -a <appName> due to said command not returning within the default timeout of 60 seconds.  (Original issue/background info found in https://github.com/deis/workflow-e2e/issues/329)
As it is reasonable to expect such a command would return in a more reasonable amount of time, I've filed the issue here.  cc @kmala
If issue is addressed, a TODO on the potential fix would be to decrease e2e's bumped threshold for any test involving deis run.
Copied from original issue: deis/controller#1106

From @helgi on October 5, 2016 21:46
That seems like a problem with the e2e setup and not Controller - deis run has a 20-minute timeout loop itself on top of waiting for the component to come up in Kubernetes.
I'm suspecting any run that has deis run failures also has additional failures. Kubernetes could be too slow for the e2e 60 second wait period.

From @bacongobbler on October 5, 2016 22:2
I think the ask is "is 60 seconds too long for deis run ls?" in which case, yes it can be. The problem is that the image needs to be fetched onto the worker node before the command is run. If there was a way we could pre-warm the worker nodes with the image, that may help speed things up.
I think it's both e2e's fault (the controller has a 20 minute timeout for deis run operations, so maybe the e2e run should do the same) and it's also the controller's implementation of deis run. If we can plug into kubectl exec instead of dropping a pod every time we call deis run, that might help make this situation more ideal.

From @bacongobbler on October 5, 2016 23:1
That is true. There can be an argument made for and against using kubectl exec for deis run.

From @helgi on October 5, 2016 22:28
@bacongobbler kubectl into an existing pod? I think the argument against that would be that you use those pods to serve traffic or do alternative things where as run may be a bit destructive / intense operations. Not sure tho.

From @helgi on October 5, 2016 23:9
Yeah - Agreed. We could make both work... exec mode picks a random pod of the a type (a particular proc type needs to be picked) to run


hardlinks fail with EXDEV (Invalid cross-device link)

When running under landlock-unveil, ln can't create hardlinks in subdirectories:
touch x
mkdir foo
lljail -rx / -rwcx "${PWD}" -- /usr/bin/ln x foo/z

This will fail with a cross-device link error.  I don't know, if this is really a problem of landlock-unveil or rather the kernel though.

For such link to work, the LANDLOCK_ACCESS_FS_REFER right needs to be handled by the Landlock ruleset and allowed for all rules. You also need to have a compatible kernel (>= 5.19 if there is no backport). See https://docs.kernel.org/userspace-api/landlock.html#file-renaming-and-linking-abi-2

Thanks @l0kod! I was looking through the docs and scratching my head. I'll come up with some patch this weekend or shortly after.
Kinda traveling this week

Links should work after the latest PR and with kernel supporting ABIv2. Feel free to reopen

Looks good to me!


added two new vars & new mc

Asymmetric Transverse momentum uses pre-fitted quantities - not sure if post fitted quantities are needed
The Kaon Electron longitudinal distance uses distance from dilepton fitted vertex.

@jay-odedra see comments above?

also note conflict above with BParkingNano/plugins/BToKLLBuilder.cc

@jay-odedra is this now deprecated and we should close?


Make net debugging more granular

debug=net tends to produce too much output and it can often be desired to debug just certain parts of what is provided by net debug. I have split it down into the following:-
This wll help with when developing just certain areas, e.g. block propagation, and therefore we're not needing visibility of tx send/get logic.
As yet the command line help is not updated - can add this if it is wanted (or a maintainer can).
"block" debugs block download progress
"blocksend" debugs block upload progress
"netrecv" debugs every message received
"netsend" debugs every message sent
"conn" debugs the making and breaking of connections to other peers
"neterr" debugs network errors
"net" everything else

This looks like a good change to me.  Any help that is obsoleted should be part of it.

I also like this. However, this will change the log output in the rpc-tests.
When an rpc-test fails, it is difficult to know what to look for. Having all output for “net” is helpful.
Is it possible to for example add a “netall” that enables output for all these? rpc-tests that enable “net” today should then be updated to enable “netall” as well.

I checked the rpc-tests. Only two tests use -debug=net, the others use -debug which enables all. So never mind my previous comment.

Closing until help and "netall" can be addressed.


want to pass whatBump function to conventionalRecommendedBump

I want to commit something for which i dont want to increase the version number and also dont want it to be present in the changelog, conventionalRecommendedBump takes an optional whatBump function but in release-it code, that parameter is hardcoded to preset only. is there any way in this plugin to do this or do i need to fix this on my own and send an PR for this?
I want that, if i commit in this format, wip(temp): temp commit, then release it should completely ignore this commit for any use

Since the configuration is based on primitives (JSON, CLI arguments), I'm afraid there's no clean way to integrate this. Got any ideas?

I didn't saw your code in detail, sorry can't suggest much here.
For now, I am writing my own tool for generating changelogs as all the tools I found are too opinionated and aren't that configurable.
Thanks.


Recipe app

Here are the things we Added to our project
Login and Registration Pages:
Added login and registration pages to provide authentication functionality for users.
Recipes List:
Implemented CRUD functionality for managing recipes.
Excluded 'update' functionality as per requirements.
Public Recipes List:
Created a list displaying all public recipes from other users.
Included recipe names and total prices for each recipe.
Added CRUD functionality for managing a food list.
Implemented a general shopping list view displaying all missing food items for all recipes and their total price.
Implemented CRUD functionality for managing inventories.
Added CRUD functionality for managing a food list associated with inventories.
Implemented an inventory shopping list, allowing users to generate a shopping list based on a chosen recipe and inventory.

Hello @Anand8317 could you check your slack?

Reem-lab

Hello could you test me on slack please

You may find some missing requirements in this project, I need you to know that for two days my teammates did not show up
and there was lots of work to do, I hope I did not miss any thing


Add the wireframes/UI on the README.md file

Keep all the ".png" files in a way that they act as a single entity when visible on the documentation.
refer: https://github.com/smaranjitghose/girlscript_app/blob/master/MockUp/Mockup01.png

can you provide the wireframes/ui ?

@lordvins226 Sure will provide you the wireframes, once they are finalized. They are under review.

@lordvins226 Sure will provide you the wireframes, once they are finalized. They are under review.

Great

Any news for wireframe ?

The wireframe is still in progress and the ready ones are present on the ReadMe itself. I would request you to refer that and do as done in the attached ref. link - https://github.com/smaranjitghose/girlscript_app/blob/master/MockUp/Mockup01.png


Shift-clicking a speed upgrade into a fluid conduit makes the item disappear.

What happens:
Shift-clicking an extract speed upgrade in a fluid conduit makes the speed upgrades disappear from the inventory and not show up in the fluid conduit.
What you expected to happen:
Either disallow the player's shift-clicking into a fluid conduit or the upgrade working in the conduit.
Steps to reproduce:

Place down a fluid conduit
Shift-click an extract speed upgrade
???
Profit
...

Affected Versions (Do not use "latest"):

EnderIO: 5.0.22
EnderCore: 0.5.22
Minecraft: 1.12.2
Forge: <IP_ADDRESS>76

Fixed in latest dev build


Impossible to find -lSDL2 for /usr/bin/ld

Hi,
I've got a compilation error with the SDL2 library - i use ElementaryOS 0.3.1 and i've already install libsdl2-dev.
I've got this error when i try to build your work:
note: /usr/bin/ld: cannot find -lSDL2
/usr/bin/ld: cannot find -lSDL2
collect2: error: ld returned 1 exit status

error: aborting due to previous error
Could not compile `rs_doom`.

Can anybody here explain to me what to do please?
I try to googling this thing but solutions doesn't work here... :-/
Thank you!

So the linker can't find the SDL2 library. Before trying anything else, could you run sudo ldconfig and try compiling again afterwards, please?
If that still doesn't work, then either sdl2 is not called libSDL2.so on your system, or it's placed somewhere not in the linker's search path. I'm on my phone now, so I can't easily check

Thank you for this quick comment.
I've already launch ldconfig, and the SDL2 lib is already linked:
ldconfig -p | grep SDL
	libSDL2-2.0.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
	libSDL2-2.0.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so
	libSDL_image-1.2.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0
	libSDL-1.2.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0

So, i think I have to modify the linker's search path to search in /usr/lib/x86_64_linux-gnu/ to find this library, right?
He can't find this library because he goes to a specific directory for 32 bits libraries?

Do you have a /usr/lib/x86_64-linux-gnu/libSDL2.so symbolic link on your system? If not, could you try creating it? i.e.
sudo ln -s /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so /usr/lib/x86_64-linux-gnu/libSDL2.so

This is what I've got (on Ubuntu):
$ ls -l /usr/lib/x86_64-linux-gnu/libSDL2.so
lrwxrwxrwx 1 root root 20 May 15  2014 /usr/lib/x86_64-linux-gnu/libSDL2.so -> libSDL2-2.0.so.0.2.0

Unfortunately yes:
ls -l /usr/lib/x86_64-linux-gnu/libSDL2.so
lrwxrwxrwx 1 root root 20 mai   15  2014 /usr/lib/x86_64-linux-gnu/libSDL2.so -> libSDL2-2.0.so.0.2.0

The command canno't be executed also:
sudo ln -s /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so /usr/lib/x86_64-linux-gnu/libSDL2.so
ln: failed to create symbolic link ‘/usr/lib/x86_64-linux-gnu/libSDL2.so’: File exists

I have already try to remove the library and to purge dependencies before install those again but no results... :-/

Hmm, not giving up yet! What do you have in your LIBRARY_PATH and LD_LIBRARY_PATH environment variables? In particular do they contain /usr/lib/x86_64-linux-gnu?

No, that's true!
But after the modification, the error still the same...
echo $LIBRARY_PATH
/usr/lib/x86_64-linux-gnu

echo $LD_LIBRARY_PATH
/usr/lib/x86_64-linux-gnu

This is the complete error of the build:
Compiling rs_doom v0.0.7 (file:///home/k0pernicus/Documents/rust-doom)

error: linking with `cc` failed: exit code: 1

note: "cc" "-Wl,--as-needed" "-m32" "-L" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib" "/home/k0pernicus/Documents/rust-doom/target/release/rs_doom.0.o" "-o" "/home/k0pernicus/Documents/rust-doom/target/release/rs_doom" "-Wl,--gc-sections" "-pie" "-Wl,-O1" "-nodefaultlibs" "-L" "/home/k0pernicus/Documents/rust-doom/target/release" "-L" "/home/k0pernicus/Documents/rust-doom/target/release/deps" "-L" "/home/k0pernicus/Documents/rust-doom/target/release/build/miniz-sys-d19b88f9ef21a81d/out" "-L" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib" "-L" "/home/k0pernicus/Documents/rust-doom/.rust/lib/i686-unknown-linux-gnu" "-L" "/home/k0pernicus/Documents/rust-doom/lib/i686-unknown-linux-gnu" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libgame-8cfee425b6ee9879.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libenv_logger-bbd82f3547b4db71.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libgetopts-bd82d57ca5684ae5.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libwad-cd615ceff76ea334.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libtime-5546927e45303414.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libgfx-6bebdf3762ca88b8.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/liblog-6e27e2da5513596d.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libmath-7b32f5d43a780379.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libtoml-f9d4bcccaf6c49db.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libglium_sdl2-55be2a6928c25ef0.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libregex-44ebda3c16a8018d.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libaho_corasick-d05abe6e803a25f9.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libmemchr-c271e615ca8016c2.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libglium-21928d8511e45830.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libnalgebra-eec5da6a2d5e5f5b.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libglutin-bf76ed33700ba108.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libwayland_kbd-de9a367fb8f54e36.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libosmesa_sys-bcfb4e9f5ccba110.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libcgmath-fee5293301deaa40.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libmmap-3228d1a911ccf2d6.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libgl_common-a5d890954f8be2d6.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libimage-6bcbcef3c1f7139e.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libgif-caf31349e2797a43.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libcolor_quant-c8840af87a039b7f.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libpng-b46bdcdffbade93e.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/liblzw-b06eded40745f4f3.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libwayland_window-a0302ed36290a7bb.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libtempfile-10bff676904f21f2.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libbyteorder-a9d27879d7f2c887.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libenum_primitive-b5b95bcd4494e441.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libsmallvec-8e27dc6b52754509.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libflate2-78d4363886f4b66b.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libminiz_sys-d19b88f9ef21a81d.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libx11_dl-83a05ff1ef61de57.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libdylib-daffd2693659ccef.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libbacktrace-e4c0ebe143c52b5d.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libdbghelp-040983399761f987.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libkernel32-c606ce60307b6481.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libdebug_builders-4717471a4c16d259.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libbacktrace_sys-e659868d1ba4bec9.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libwinapi-3afcd2170e6034e1.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libbitflags-83dc6fc5ecc9dd71.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libsdl2-21b95ebba2160a5f.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libsdl2_sys-b5d0e29d4b0af36c.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libnum-2ece09fbdcaec573.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/librustc_serialize-e13845f83f5be3dc.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libcommon-bea1f988784460d3.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/librand-a5a71c849766362c.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libshared_library-df6a4ed1de1c004a.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libwayland_client-92ee4c95af297731.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libdlib-464d32cdfc50ec82.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/liblazy_static-512518894775e8b8.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/liblibc-165b5479aec0459c.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libbitflags-d8aad5e08369cb92.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libregex_syntax-3bd7600d419463d3.rlib" "/home/k0pernicus/Documents/rust-doom/target/release/deps/libcfg_if-f8ac1d2a9eed8e25.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/libcollections-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/librustc_unicode-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/librand-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/liballoc-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/liballoc_jemalloc-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/liblibc-10cbabc2.rlib" "/usr/local/lib/rustlib/i686-unknown-linux-gnu/lib/libcore-10cbabc2.rlib" "-l" "rt" "-l" "SDL2" "-l" "SDL2" "-l" "c" "-l" "m" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "rt" "-l" "pthread" "-l" "c" "-l" "m" "-l" "compiler-rt"

note: /usr/bin/ld: cannot find -lSDL2
/usr/bin/ld: cannot find -lSDL2
collect2: error: ld returned 1 exit status

error: aborting due to previous error
Could not compile `rs_doom`.

I try to install the 32 bits of SDL2 library (because the linker try to link with some i386 libs I think), but if this library and dependances are installed, the system erase my 64 bits configuration... This is really annoying :(

It's true that there's the "m32" flag and the i686 paths in there that are a bit worrying; I don't really know why it's trying to link as 32 bits :(. I think this might be to do with the rust sdl2 library misidentifying your system as 32 bits.

I think so...
I'll create an issue in rust-sdl2, and, if I have any solution for this problem, I'll note that one bellow.
Thanks a lot for your patience :-)

What do you get if you run pkg-config sdl2 --libs. If you don't have pkg-config could you try installing it, then doing cargo clean && cargo build? I think SDL2 is trying to use it.

This is the result of the command:
$pkg-config sdl2 --libs
-Wl,-rpath,/usr/local/lib -L/usr/local/lib -lSDL2 -lpthread

Interesting....  As one last attempt, could you try creating a symbolic link of SDL2 in /usr/local/lib ?
sudo ln -s /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so /usr/local/lib

Still the same error - nothing have changed :-/

I'm sorry this is not working out for you. I think you're right though; the problem is probably the 32 bit issue.

It's ok now - the script installer of Rust doesn't install a 64 bits Rust compiler on a 64 bits OS...
So, I've already download and install a 64 bits Rust compiler and all works fine now :-)
Thanks for all!!!


Issue/405 a11y

This PR addresses issue https://github.com/epimorphics/ukhpi/issues/405 by making sure the data table is now the first tab to be focused when displaying data. The tab selected by default is still the graph tab, but the data table view comes first when navigating via keyboard/using a screen reader.
Before:

After:

Closing this based on Tom's comment here: https://github.com/epimorphics/ukhpi/issues/405#issuecomment-2298742200


RASA - HTTP API Endpoint Config get call is not working in NLU: 0.14.3 version

Rasa NLU version: 0.14.3
Operating system (windows 10):
http://localhost:5000/config Status Code : 404
The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.
In the RASA NLU version 0.13.1 we have localhost:5000/config endpoint. In version 0.14.3 its not there. but I am wondering that it is there in the documentation . :smiley:
I got to know after checking the Python file
https://github.com/RasaHQ/rasa_nlu/blob/master/rasa_nlu/server.py

**Issue**:

Thanks for raising this issue, @ricwo  will get back to you about it soon.

the /config endpoint was removed with https://github.com/RasaHQ/rasa_nlu/commit/06b867d39d66878b5ac1a9a55121d7f459ab5532, based on this issue: https://github.com/RasaHQ/rasa_nlu/issues/1132
Thanks for pointing this out though - the docs are stale and should be removed as well (https://github.com/RasaHQ/rasa_nlu/issues/1706)


Support for CSI indexing

Hi
Will there be support for CSI indexing? Currently I'm getting errors when I run createVCFplot. It tries to index with TBI and recommends I use CSI indexing.
I'm working with a large plant genome.
Thanks.

Did you ever figure out this error? I'm having similar issues as well

I've also encountered this issue. Pisum (Lathyrus oleraceus) ZW6 genome contains coordinates too large for tbi indices.
Got this error from bcftools index:

[E::hts_idx_check_range] Region 537909476..537909477 cannot be stored in a tbi index. Try using a csi index
CSI index can be built, but it is ignored by plotVCF.


Add some missing special characters to the link regex

cc @rafecolton
Fixed Issues
Needed to fix https://github.com/Expensify/Expensify/issues/153365
Tests

Automated tests updated

QA
Will be qa'd in the Expensify.cash pr

@alex-mechler are you going to deploy this? https://stackoverflow.com/c/expensify/questions/7216

Hmm, I'm a bit confused about that process. Looking in the repos it seems we are still using hashes, and no one has deployed to that in 3 months. Is the current process to deploy? Did I miss a process change email sometime?

Oh, looks like you're right and we're just using hashes for now. My mistake – I was just going off of what's in the README for this repo.

Yep read me needs to be updated.

So making sure I understand, the readme needs to change back to the hash changing method? I'll get that done


chore: hide templates v2 behind feature flag

Description
Add feature flag for templates v2. There are two place where we want to add this, in the canvas and in the page context menu.
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Manually
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=2feb0e8

/ok-to-test sha=9cc0162

/ok-to-test sha=252c286

/ok-to-test sha=2196536

/ok-to-test sha=9a1b14f


Error formating blade

Template
Please write your blade template that occurs issues.
Context (Environment)

write your environment

Description

Any other informations

color lib

Closed by #372


Update products.py

I want to merge this change because...

Product.availability and ProductVariant.availability have incorrect deprecation message #4320
Screenshots

Pull Request Checklist

[ ] Privileged views and APIs are guarded by proper permission checks.
[ ] All visible strings are translated with proper context.
[ ] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] Database queries are optimized and the number of queries is constant.
[ ] Database migration files are up to date.
[ ] The changes are tested.
[ ] The code is documented (docstrings, project documentation).
[ ] GraphQL schema and type definitions are up to date.
[ ] Changes are mentioned in the changelog.

Here is the report for 53b36070303f2c6d149068f366a1baa40b34100f (MatthewBosek/saleor @ master)
Base comparison is f233f200147d06f739cd8594d9cfa26d03c52a58.
No differences were found. (click me)

# api.benchmark checkout
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  add billing address to checkout     	         34	         34	             20
  add shipping to checkout            	          7	          7	              0
  checkout payment charge             	         14	         14	              0
  complete checkout                   	          6	          6	              0
  create checkout                     	         48	         48	             24

# api.benchmark homepage
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  retrieve main menu                  	          5	          5	              0
  retrieve product list               	          4	          4	              0
  retrieve secondary menu             	          5	          5	              0
  retrieve shop                       	          2	          2	              0

# api.benchmark product
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  product details                     	         13	         13	              3

# api.benchmark variant
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  retrieve variant list               	          9	          9	              2

Thanks for your contribution! There is the below one as well. Could you change it?
https://github.com/mirumee/saleor/blob/b0334726d4e1a1b51eed933e7a71d27ec92a8dcc/saleor/graphql/product/types/products.py#L185

Hey @MatthewBosek, thanks for opening the PR! If you see at the checks above, the CI is failing with Black and outdated GraphQL schema. To fix that you need to update the schema as @NyanKiyoshi suggested above (you can do that as well with the command npm run build-schema). Black is the tool for Python code formatting that we use. You need to install it locally and run apply it to the files you've edited.

@maarcingebala @NyanKiyoshi I have done both: performed the schema update and used the Black tool to format the code. How do I perform a pull request? I am new to this.  Thanks!