Add NETWORK_NAME_or_ID value for --net= option

Signed-off-by: Wen Cheng Ma<EMAIL_ADDRESS>

ping @thaJeztah @moxiegirl

Thanks for your contribution @wenchma!
While looking, I also noticed that the documentation and man-page for "create" is missing this information, perhaps (once we agree on the right wording), we can update that as well in this PR; https://github.com/docker/docker/blob/master/docs/reference/commandline/create.md

@thaJeztah thanks for your comments, :+1:   all are addressed, please check the current PR.

@moxiegirl any comments on the current PR?

@moxiegirl @thaJeztah ,  much appreciate your comments, addressed, please have a review again, thanks. :+1:

Thank you @wenchma, and thanks for being patient with us :-)
docs LGTM
ping @moxiegirl PTAL

aw, looks like this needs a rebase

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "doc_update_for_net" git@github.com:wenchma/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

rebased

Oh my, it really is the day for rebases, because it already needs another rebase. (Can't believe it).

@wenchma Thank you for your patience and quickness. LGTM

merging, this PR doesn't change code, so ignoring users CI

Thanks @wenchma!


how to gen a whole call graph in my go module

Currently,   i use
go-callvis -file=filename <module_name>
to gen a svg call graph for my project. But i find the output is just a filename.svg that cover main.go .

So that , i can jump arbitrarily locally instead of request HTTP server.
Is there any solution to help me solve the above question?

Try adding flag -focus='"". If the  output is too large or very complex or even fails, try to set focus to the name of a specific                         package you want to focus your call graph on.


MaintenanceSolution default values

Are you willing to take input on the default values for this solution? It seems like the purpose of this .sql file is to make a simple install that fits most cases. I would say that for the SQL Agent jobs for backups, it would make more sense to have a non-NULL value for CleanupTime and a NULL value for Directory
Also perhaps injecting some standard schedules (not applied to any of the jobs) would be helpful such as

Daily 7pm
Hourly 1h
Weekly Saturday 6pm
etc

(but that's perhaps going a bit out of scope)

All input are welcome. I created MaintenanceSolution.sql to make it easy for people to get started with the solution. About the defaults:
CleanupTime: I have been thinking that I should not delete any backups by default. I would like the user to set the cleanup time.
Directory: It could make sense to use NULL here. Then it would back up to the SQL Server default backup directory. My concern has been that if the user has not configured the default backup directory, it would back up to something like "C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup", and then the user can't find the backup files (and it could fill up the drive).
Scheduling: I prefer to let the user schedule the jobs, so that he or she has to do something actively for things to start running. It would also be difficult for me to define the schedules as different organizations have different maintenance windows.

Thanks for the reply.

That's fair on the cleanuptime.
Per the directory that seems like a small inconvenience, and honestly at least it would run the backup. If C:\Backup doesn't exist, the jobs will fail. Seems like a cleaner choice to use the instance defaults.
I was more suggesting to create some standard schedule objects, not to apply them to the jobs. I do like that the agent jobs create unscheduled.

Thank you for the feedback. I am leaning towards changing the default for the directory to NULL (instance default).

Thanks.
Also thank you in general for this amazing resource.

I have changed the backup directory now.
https://ola.hallengren.com/versions.html
I am not planning to do anything with schedules.

This is great!!! Just realised that the BackupDirectory defaults now to NULL.
Hurray!!!
Thank you!


[EMB-215] validated-input: ternary -> boolean, use defaultTo, condense imports

Purpose
reCAPTCHA error message not shown
Summary of Changes
Boolean or operator (||) takes precedence over the ternary operator ? :
use defaultTo
order imports
Side Effects / Testing Notes
As previously stated in #180 this is a separate issue from handling 400 errors from the API.
Ticket
https://openscience.atlassian.net/browse/EMB-215
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Coverage remained the same at 30.0% when pulling 9fb03155b313cd29a75f1b5ed030d58f7e6fec5d on binoculars:fix/EMB-215 into bd8b1be3d7a243dab3e60fe55beeda0f3423690e on CenterForOpenScience:develop.


Slash-Swapper Plugin added to the plugin hub

A Plugin that allows users to send messages in their clan chat with '/' instead of '//' and send messages in their friends chat with '//' instead of '/'.
Closes runelite/runelite#13651.

There was an error in the runelite.plugins.properties file that caused the build to fail earlier. I fixed that now. Sorry about that!

Hello, so I was taking a peek at the / issue because it is bothering me and I saw this code block. Might be worth integrating it into chat channels? Still new contributing to this project but it seems that integrating what you have in the default block of this switch statement might be the way to go.
https://github.com/runelite/runelite/blob/657132b39b1374d66f47a9c98f08f43f0be2e61d/runelite-client/src/main/java/net/runelite/client/plugins/chatchannel/ChatChannelPlugin.java#L626

Hello, so I was taking a peek at the / issue because it is bothering me and I saw this code block. I would think it would be worth integrating it into the chat channels plugin and making an option. Still new contributing to this project but it seems that integrating what you have in the default block of this switch statement might be the way to go.
https://github.com/runelite/runelite/blob/657132b39b1374d66f47a9c98f08f43f0be2e61d/runelite-client/src/main/java/net/runelite/client/plugins/chatchannel/ChatChannelPlugin.java#L626

I am familiar with that plugin, When I initially made this pull request a few people in the Runelite discord also recommended that to add it to that plugin. As of now I made this pull request because I felt like the Chat Channels plugin already has a lot going on and thought that it might be better if this were its own simple plugin. However, if the Runelite devs think that this would be better in the chat channel plugin I can work on adding that with a config option.


feat(Algebra/Homology): signs for the associativity compatibility of the total complex

This PR introduces a typeclass ComplexShape.Associator which takes as inputs six complex shapes c₁, c₂, c₃, c₁₂, c₂₃ and c, and asserts compatibilities of signs for the associativity of the total complex of a triple complex. It shall also be used in the construction of the associator isomorphism for the tensor product of homological complexes.

Thanks!
maintainer merge

bors r-

bors d+

Thanks! Retrying...
bors merge


Binary wheels

Is distributing pre-compiled binary wheels a possibility for this project? Perhaps variants with and without CUDA? At least for Linux?

Hi @siddharthab, I currently have no plans to support this. Since the only dependency for building is a C++ toolchain (and CUDA toolchain for CUDA support), I would not think that the compilation during installation is not much of an inconvenience.
That being said, if enough people show interest (or someone submits a PR implementing a build action) I would be happy to provide these. I believe something similar to this github action could be used to build the extension on all of the possible torch/cuda/cpu combinations, but I would likely need to spin up a server to store the wheels, which could take some time and cost.

Thank you for the quick reply. I suppose I am coming from the perspective of some build tooling where we don't typically have packages mentioned in install time requirements installed in the build environment.
For example, if we had a requirements.in file (for pip-tools) with both torch and torchsort listed, it will fail to collect the listed packages because torch won't already be installed in the environment.
Another example is if we want to build a docker image with the package installed in it, but the machine where we are building the docker image does not have the cuda toolkit. We still want the cuda capable package because the docker image is going to be deployed on a remote GPU machine.
Thanks for the pointers, I will try to get something working. Or at the very least, we can have instructions for people in these situations.

Those use cases make sense to me. If the github build action works, one option would just be uploading the .whl files to the release page. This would allow installation of the pre-built binaries to be done with something like:
pip install https://github.com/teddykoker/torchsort/releases/download/v0.1.9/torch-2.0.0+cpu.whl

Alternatively I could set up an s3 bucket, along with a pypi server. This would allow something like
pip install torchsort==0.1.9 --index-url https://<some url>/whl/torch-1.13.0+cpu/

This would have some monetary cost, but hopefully quite small.
Lastly, there may be a way to use github pages along with the action to host the whl files:
pip install torchsort==0.1.9 --index-url https://teddykoker.github.io/torchsort/whl/torch-1.13.0+cpu/

But this might involve some work making a custom github action to copy the files over and write the proper index.html files.
I'm thinking the first approach would make the most sense for now, but I'd be interested to know if you had any other thoughts.

Already on it - https://github.com/siddharthab/torchsort/commit/6d6894dba653998b6275c82b51d3f44b87d7c8ab
It's mostly working, I just have to figure out the right CUDA settings, and then the wheels will show up in the Releases page. I will be sending a PR soon, and you can work out the version matrix you want to support and the release policy.

Awesome! Will review once the PR is in.

@siddharthab Thanks again for all the help implementing this! I have successfully added the .whl files to the release page, which can be installed directly with pip:
# torchsort version, supports >= 0.1.9
export TORCHSORT=0.1.9
# PyTorch version, supports pt20 and pt113 for versions 2.0 and 1.13 respectively
export TORCH=pt20
# CUDA version, supports cpu, cu113, cu117, cu118 for CPU-only, CUDA 11.3, CUDA 11.7 and CUDA 11.8 respectively
export CUDA=cu118
# Python version, supports cp310 and cp311 for versions 3.10 and 3.11 respectively
export PYTHON=cp310

pip install https://github.com/teddykoker/torchsort/releases/download/v${TORCHSORT}/torchsort-${TORCHSORT}+${TORCH}${CUDA}-${PYTHON}-${PYTHON}-linux_x86_64.whl

Do let me know if you run into any issues with installing them, and don't hesitate to reach out if you need me to expand the matrix at all.

Thank you @teddykoker.
cc @gevangel


HADOOP-17107. hadoop-azure parallel tests not working on recent JDKs

Contributed by Steve Loughran.
tested: ireland
ran with

-Dparallel-tests=both
-Dparallel-tests=abfs
-Dparallel-tests=wasb

all profiles worked as far as launching tests without showing errors and running all unit tests in parallel. I'm not 100% sure

..and by removing the declarations of fork count = 1, the integration tests run in parallel too
INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.apache.hadoop.fs.azure.contract.ITestAzureNativeContractGetFileStatus
[INFO] Running org.apache.hadoop.fs.azure.contract.ITestAzureNativeContractMkdir
[INFO] Running org.apache.hadoop.fs.azure.ITestFileSystemOperationExceptionHandling
[INFO] Running org.apache.hadoop.fs.azure.metrics.ITestAzureFileSystemInstrumentation
[INFO] Running org.apache.hadoop.fs.azure.contract.ITestAzureNativeContractOpen
[INFO] Running org.apache.hadoop.fs.azure.contract.ITestAzureNativeContractDelete

This may have been the case before, I'm just making extra sure after changing the test running

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 32s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
23m  2s
trunk passed

+1 :green_heart:
compile
0m 35s
trunk passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

+1 :green_heart:
compile
0m 30s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
mvnsite
0m 32s
trunk passed

+1 :green_heart:
shadedclient
40m 21s
branch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 26s
hadoop-azure in trunk failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
0m 23s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 29s
the patch passed

+1 :green_heart:
compile
0m 31s
the patch passed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04

+1 :green_heart:
javac
0m 31s
the patch passed

+1 :green_heart:
compile
0m 22s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
javac
0m 22s
the patch passed

+1 :green_heart:
mvnsite
0m 26s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
shadedclient
15m 42s
patch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 27s
hadoop-azure in the patch failed with JDK Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.

+1 :green_heart:
javadoc
0m 23s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

_ Other Tests _

+1 :green_heart:
unit
1m 20s
hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 32s
The patch does not generate ASF License warnings.

65m 36s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-2118/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2118

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient xml

uname
Linux 7f35ad8c8abc 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 04abd0eb17b

Default Java
Private Build-1.8.0_252-8u252-b09-1~18.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_252-8u252-b09-1~18.04-b09

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2118/1/artifact/out/branch-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-2118/1/artifact/out/patch-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.7+10-post-Ubuntu-2ubuntu218.04.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-2118/1/testReport/

Max. process+thread count
311 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-2118/1/console

versions
git=2.17.1 maven=3.6.0

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

LGTM +1

thanks. will backport to 3.3; if people need it for 3.2 then ping me after doing a test run locally


startupitem.logfile: log to StandardErrorPath too

Presently, when startupitem.logfile is specified, we add a plist entry for stdout logging (via StandardOutPath). But when errors and such occur - particularly due to a fatal startup issue - that output often goes to stderr.
Not capturing the latter, makes troubleshooting more difficult for users. Potentially requiring them to manually edit the plist file, to add an entry for StandardErrorPath themselves.
To ensure the user doesn't have to deal with that, add a plist entry for StandardErrorPath too. This provides the user a unified log file, containing both stdout/stderr.
Fixes: https://trac.macports.org/ticket/67955

I would like a separate option to control where stderr is sent. That can default to the same log as stdout.

I would like a separate option to control where stderr is sent. That can default to the same log as stdout.

Agreed, as it provides more flexibility. Any thoughts as to the option name?

I would like a separate option to control where stderr is sent. That can default to the same log as stdout.

How about this:

Add new option startupitem.logfile.stderr
Defaults to startupitem.logfile
If cleared, disables stderr logging
Can be set independently of startupitem.logfile, if user only wants stderr logging

PR updated to support new option startupitem.logfile.stderr, along with update to the manpage.

PR updated to support new option startupitem.logfile.stderr, along with update to the manpage.

Note: Once we have consensus for all of the details, a corresponding PR will be created to update the MacPorts Guide.


add ability to hide Subcommands from --help

I'd like to be able to hide an entire Subcommand so it does not appear in the --help output, but currently it seems there is no .hidden(true) for subcommands.
clap 2.31

For subcommands, use AppSettings::Hidden it does exactly that 😉

Ah, thanks a lot! :D


Add wordpress version detection from scripts

Wordpress will often have its version exposed through a script tag such as the following:
<script type='text/javascript' src='https://.../wp-includes/js/wp-embed.min.js?ver=5.4.2'></script>

Thanks!


UrlFetchApp Calls

UrlFetchApp.fetch (POST) is being executed many times although the UrlFetchApp isn't inside a loop. It should execute only once upon user submits the whole form.

This issue looks like a general question about apps script development, not the samples contained in this repository. We recommend asking such using the resources in the support guide.


Validate namespaces, so non admin can not create backups outside of ns

Validate namespaces, so non admin can not create backups outside of ns
Validation ensures the namespace in the VeleroBackup object are the same as the namespace for which NAB resides.
Note this PR is on top of #54 which should be merged first.

@mateusoliveira43 @shubham-pampattiwar @weshayutin  This PR is really all about that commit only, because other commits are covered in #54:
https://github.com/migtools/oadp-non-admin/pull/56/commits/152d1c7ba3466c37a66fff2304f111136182e351

Fixes #49

Rebased validation of namespaces. @mateusoliveira43 @shubham-pampattiwar please review as it's on top of previous work with merged reconcile functions.


display current active route in navigation

Right now in the navigation we don't display the current active page.
But we do keep the 10 last visited routes in our store. This is named routerLocations.
Steps to fix this issue:

connect the menu bar with our store for accessing routerLocations.
on every render get the last item out of this array and check which location it is.
display active item with gradientColor.

closed in https://github.com/threefoldfoundation/tfchain-wallet-electron/pull/216


[BUG] The edits are not applied to the review modal when editing the flashcard inside  of the modal

Describe the bug
The edits of the flashcard are applied when editing in the flashcard modal, but the edits are applied to the source file.
To Reproduce
Steps to reproduce the behavior:

Go to 'Review flashcards'
Click on 'flashcards', go review flashcards
Edit the flashcard, then click save

Expected behavior
The flashcard should be updated.
Versions (please complete the following information):

OS: MacOS 13.4.1(c)
Obsidian version: Version 1.3.5 (Installer 1.3.4)
Plugin version:  v1.10.1
If on desktop, Installer version: '5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) obsidian/1.3.4 Chrome/112.0.5615.183 Electron/24.3.1 Safari/537.36'

Hey there
I started working on this and it's surprising involved to implement.
Then I thought that it actually might be reasonable to simply skip the question after it is edited.
Whilst editing, the user sees the full question and answer, and so it doesn't seem very beneficial for the person to then be immediately questioned on it.
And skipping the question post edit should be easy to implement :slightly_smiling_face:
What do you think?
Cheers
Ronny

Imagine you are studying and you want to format the question or answer better.
The best possible UX is to have whatever the user edits to be immediately visible so they can ensure it looks the way they intend. Instead, whatever the user edits is not updated in the modal. There's no feedback at all that the edit was successfully applied.
This seems like a worthwhile change to implement. I'm going to take a stab at it.
Mckay

Once I find something I want to edit, I try to answer the question first and then edit it. Therefore, in my opinion, skipping is not the best way, especially if you want to check whether the changes had the expected effect.


Additional source for error function integrals

Hello, I just downloaded Rubi and it's really cool. My motivation was to see if Rubi could do an integral that Mathematica can't. Unfortunately Rubi can't do the integral, but that's OK because I found this nice table online, which dates from the 1960s and includes my integral (formula 4.3.13, for what it's worth). Anyway I'm sharing the resource in case it can lead to additional rules in Rubi someday. Best, Jason

Thanks Jason for the link to Ng & Geller's Table of Integrals of the Error Functions that I was not aware of.
Albert

So, you did not ix it?

For the last several years my focus has been on perfecting the rules for integrating algebraic and elementary functions.  These are more fundamental than those for integrating special functions.
I invite you to contribute additional rules for integrating expressions involving error functions to the ones currently in 8.1 Error functions.
Albert


constant

🚀 Feature request
Current Behavior
Currently, I use const in combination with Object.freeze.
This is not only unhandy, it is also not a deep freeze.
Desired Behavior
I like a keyword, preferably constant that combines both deeply frozen objects and the behavior of const.
Suggested Solution
Implement an equivalent of a truly constant binding in other languages, so that in typescript, a constant behaves like suggested. (constant)

Who does this impact? Who is this for?
Impacts all living beings in the universe and is considered one of the basics of programming. 🙂
Describe alternatives you've considered
Using Fable, Elm, and similar projects.
Additional context
I have absolutely no idea about Typescripts implementation details and just skimmed over the alternative libraries for this feature and it seems to be non-existent yet, which baffles me.
Your environment

Software
Version(s)

fp-ts
current

TypeScript
current

Thanks a lot 🤗

I use const in combination with Object.freeze

Looks something you might do in JavaScript, in TypeScript you can model your data types as immutable

How?


restorer: Preallocate files

What does this PR change? What problem does it solve?
The new restorer implementation writes data blobs in a random order to the destinations. On filesystems which implicitly create sparse files (probably on most unixoid systems) when writing to a location somewhere after the file end this can lead to a very large amount of file fragments. Even without sparse files (e.g. the default on Windows) the file will grow in multiple increments which can cause fragmentation.
The restore loop itself now queues pack files for download in to order of their first reference in one of the restored files. For a large file this should usually mean that the pack download order closely resembles the order in which data blobs are referenced. That way the access pattern more closely resembles that of a file which grows over time.
In addition, after a file is created, the fileswriter will issue a call to preallocate the full file size. This allows the filesystem to allocate space with as little fragmentation as possible.
There's currently a preallocate implementation for Linux and macOS. For Windows the generic implementation with Truncate calls SetEndOfFile which is supposed to preallocate disk space. On Linux the file system is able to track not yet initialized file extents, whereas on Windows there's only an offset up to which the file content was initialized. This means that a write into the middle of a file has to zero everything up to then.
The preallocate implementation is currently located in internal/restorer which is probably not the ideal place, but internal/restic is already overcrowded. There's also a test in internal/restorer/preallocate_test.go, which tests something, but I'm not really sure how fragile it is.
Was the change discussed in an issue or in the forum before?
Closes #2675
Checklist

[x] I have read the Contribution Guidelines
[x] I have enabled maintainer edits for this PR
[ ] I have added tests for all changes in this PR
No user visible changes. [ ] I have added documentation for the changes (in the manual)
Not necessary, as the new restorer implementation is not yet released. [ ] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[x] I'm done, this Pull Request is ready for review

sorry for the slow response... will try to find time to review this next week

Really great work by you guys. Thanks so much.


cstor-pool on K3OS is not working

On K3OS we are not able to create the pool. The pool creation is failing mainly because K3Os does not support udev. When we use "zpool create" command, the zpool labels the disk and rely on udev to get the information about the devices (Specialy it checks if device is initialized by udev or not via udev_device_get_is_initialized library call). It creates a partition and waits for (via udev)

it to be initialized
all of the device links to be verified to exist

Once this is done the device can be accessed reliably. Since K3Os does not have udev, the above check will fail and zpool create command will return with the failure.
currently we use udev for the following items :-

get persistent physical location used for device matching during auto-{online,expand,replace}.

enclosure sysfs path for turning on enclosure LEDs

device is ready for IOs or not

This is the test sample code which checks and return if device is initialized by udev or not.
$ cat udev.c
#include <libudev.h>
#include <stdio.h>

int main(int argc, char **argv)
{
        char *device;
        struct udev *udev;
        struct udev_device *dev = NULL;

        if ((udev = udev_new()) == NULL) {
                printf("failed to get udev device\n");
                return (-1);
        }

        if (argc > 1) {
                device = argv[1];
        } else {
                fprintf(stderr, "device is not provided\n");
                return (-1);
        }

        dev = udev_device_new_from_subsystem_sysname(udev, "block", device);

        if ((dev != NULL) && udev_device_get_is_initialized(dev)) {
                printf("device = %s is initialized by udev\n", device);
        } else {
                printf("device = %s is not initialized by udev\n", device);
        }

        udev_device_unref(dev);
        udev_unref(udev);
        return (0);
}

$ gcc udev.c -ludev
$ ./a.out sdb1
device = sdb1 is not initialized by udev

The above binary should return device = sdb1 is initialized by udev

https://github.com/rancher/k3os/issues/151 is tracking the enhancement for supporting udev in K3Os

cStor works fine from k3os-v0.9.0
https://blog.mayadata.io/openebs/getting-started-with-k3s-in-vsphere-and-openebs-cstor


Fix Markdown driver messing with arrays

Currently, the Markdown driver is turning array casts into strings. The problem is with $model->getAttributes(), which returns the attributes after being casted into their raw form.

Closed by #22.


Remove duplicative "Correct" statements and correct minor typos

Thanks for creating this; it’s well-designed and written!
As I went through the chapters, I noted that the correct responses to the mini-quiz questions already began with “That’s Correct!”, so the “Correct!” text in the chapter files was duplicative. This PR removes the duplicative “Correct!”s and resolves a few very minor typos I saw as I went through it.
I realize there’s a good chance you may be revamping this to move from carat to parsnip in the near future, but I figured no harm done by practicing my PR skills in an extremely minor way.
Thanks again! I learned a lot.

Thank you so much @joelrip! This is much appreciated. 🙌


Update use of libc::timespec to prepare for future libc version

In a future release of the libc crate, libc::timespec will contain private padding fields on 32-bit *-linux-musl targets and so the struct will no longer be able to be created using the literal initialization syntax.
Update the use of libc::timespec to create a value by calling std::mem::zeroed() first and then setting the tv_sec and tv_nsec fields manually which works with both current versions of libc as well as the future version which contains that change.
See also https://github.com/rust-lang/libc/pull/2088

I don't know why this is failing on macos but it looks unrelated to this change:
  = note: ld: in /Users/runner/.rustup/toolchains/1.49.0-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-f52081aedccc205f.rlib(lib.rmeta), archive member 'lib.rmeta' with length 31176 is not mach-o or llvm bitcode file '/Users/runner/.rustup/toolchains/1.49.0-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-f52081aedccc205f.rlib'
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

All rustc versions before 1.54 are broken with the latest XCode version as the linker no longer accepts non-object files in archives. https://github.com/rust-lang/rust/pull/84449 which landed in 1.54 started wrapping the crate metadata in an object file. See https://github.com/rust-lang/rust/issues/103044 for more info.

CI should be fixed now, can you rebase?

Sure, rebased!

Looks like CI is green! 🎉


Old HoodieInputFormat does not include parquet files written as part of deltacommits, we need a workaround for this

At the moment, presto and hive are using a very old jar of hoodie-mr where the commitTimeline only returns .commits.
In MergeOnRead table type, we have 2 modes of writing out inserts :

Write Inserts as parquet files (working)
Write inserts as log files (still pending)

Say a batch consisting of inserts + updates was written as part of a deltacommit, this batch will create new parquet files for inserts and write a x.deltacommit in the timeline. Now, when the old HoodieInputFormat queries the timeline, it will only see the x.commits files and filter all parquet files corresponding to those commits. As a result, none of the parquet files written as part of the deltacommit will surface up in the query until an update is received for this file and a compaction re-writes this parquet file. In a scenario when there is no update for a file, this file will never be available to end user resulting in data loss from a user perspective.
Mitigation Options

Option
Caveat & explanations

Upgrade all hoodie-mr jars
This is something that is scheduled to be done soon but can take a really long time

Force a dummy compaction for such file ids
Code is hacky, we have to add this logic in the compaction workload generation where if a file does not have any updates and also does not have a corresponding .commit, force a compaction

@n3nash : @vinothchandar and myself discussed about this. We think there is an option which would not force an upgrade while keeping Hoodie OSS clean.
The idea is to have Komondor identify the file-Ids where new records are inserted and force a future compaction by creating an empty log file before we commit. Once, all the clients have eventually upgraded to latest jars, we can remove this from Komondor.
Currently HoodieIOHandles do not track "inserts during merging/compacting" (but we track updates and deletes). This is a good metric to be added to Hoodie (in HoodieMergeHandle.close() and also in HoodieCreateHandle). Komondor can inspect this metric from WriteStatusRDD returned by upsert and create empty log-files for those HoodieWriteStats whose path points to parquet and insertsDuringMerge > 0. This needs to be done only for ingestion path and not for async compaction.
If the commit gets rollback, the rollback logic should remove the empty log-file along with the parquet file.

@bvaradar @vinothchandar That's also an alternative option. Although, this option seems much more complex and laced with scope for bugs with custom handling of creation of log files, rollback etc on the client. I would rather avoid such complex logic to lie in ingestion jobs making reasoning of code difficult.
I agree with tracking inserts during merging/compacting in HoodieMergeHandle.
I propose the following :
Let's further think about "Force a dummy compaction for such file ids" option that I mentioned above and see if there are any obvious problems. If not, I will go ahead and make those changes in our hoodie internal repo. Let me know how that sounds to you guys.

Don't keep selecting a FileGroup without any log files, that was just recently compacted

So, in this scenario, we will have a commitTime for the datafile associated to the commit Timeline and we will filter out such file ids.

Do this well, while respecting activetimeline and handling cases where this file id's instant time in the archived timeline

If it's in the archived timeline, the query will automatically work since the commit time will be earlier than the earliest commit timeline in the active timeline and wee will not choose this for compaction as well.
Snippet of code that takes care of this
  // Return true if the particular parquet file does not have a corresponding COMMIT action   // Also, check if the commitTime is earlier than the earliest available commit, if yes, then it will automatically   // get picked up in the HoodieInputFormat during query so we can avoid compacting base parquet repeatedly   private boolean isParquetWrittenFromDeltaCommit(List<String> allCommits, String earliestCommit, CompactionOperation       compactionOperation) {     String commitTime = compactionOperation.getBaseInstantTime();     return !allCommits.contains(commitTime) && HoodieTimeline.compareTimestamps(commitTime, earliestCommit,         HoodieTimeline.GREATER_OR_EQUAL);   }

Looks okay to me. lets revisit again based on some testing resutls

Think we have the workaround here.. reopen if further discussion is needed


chore(*): use etcd2 inside a container

alternative implementation of ref #4005
The changes in the python script are required because the etcd2 section in cloud-unit is not valid until CoreOS >= 653.0.0

@aledbf My other concern is that the local etcdctl version on the CoreOS hosts won't necessarily match the daemon version. While this shouldn't be a big deal, it wouldn't surprise me if there are oddities. We can control the version inside the containers themselves, but not the version on the host. Thoughts?

the local etcdctl version on the CoreOS hosts won't necessarily match the daemon version

Correct but deis provides a "custom" etcdctl binary in each component image, so from that perspective I don't see a problem.

@carmstrong any suggestion for this PR?
About etcdctl this is passing without any change in the versions so it's using etcdctl v0.4.9

any suggestion for this PR?

Let's bump the versions of etcdctl in all of the components to match the etcd version - even though it works as-is, I'd like to have bugfixes and backup/restore functionality in the client should it be necessary in the components.

I also wouldn't mind entirely dropping the old ports for etcd (4001 and 7001) and switching everything over to use the new IANA ports.

@carmstrong done and passing

@aledbf What if we dropped ports 4001 and 7001 entirely? We reference them in the bin/boot scripts in the components, but as long as we updated the ports there, I think we'd get away with only using the new ones.
We can also remove the debug-etcd service, since the new etcdctl cluster-health command replaces it. :+1:

@carmstrong done. It passed twice so I think is ready for another review.
For now is not possible to remove the port 4001 and 7001 from the etcd container (Update 7)

I just realized that in my overzealous desire to kick etcd 0.4 to the curb, I made this PR backwards-incompatible -- we can't bump etcdctl in the containers because we don't know if users will be running 0.4.x or 2.x. For several releases most likely, users will still be running etcd 0.4 on their hosts.
We'll probably need to stick to the old etcdctl and ports for the time being.

Also, at least against vagrant, this PR does nothing currently. We still get CoreOS 647.2.0, so the etcd2 section in user-data is ignored and old etcd comes up instead. I'd like to get #4032 merged as a way to fix that.

Closing in favor of #4084. Thanks as always, @aledbf!


feat(caret): chevron should not toggle [khcp-4206]

Summary
Addresses:
https://konghq.atlassian.net/browse/KHCP-4206

Vue 3
Did you create a corresponding PR to add this change to the beta branch? (required)

[ ] Yes, here is a link to the PR: [link to beta branch PR]
[x] No, I did not create a PR for the beta branch and I have added the port to beta branch tag to this PR.
[ ] No, because [type your reasons]

If you have questions, tag @adamdehaven or @kaiarrowood.

PR Checklist

[ ] Does not introduce dependencies
[ ] Functional: all changes do not break existing APIs and if so, bump major version.
[ ] Tests pass: check the output of yarn test packages/
[ ] Naming: the files and the method and prop variables use the same naming conventions as other Kongponents
[ ] Framework style: abides by the essential rules in Vue's style guide
[ ] Cleanliness: does not have formatting issues, unused code (e.g., console.logs), or leftover comments
[ ] Docs: includes a technically accurate README, uses JSDOC where appropriate

Chevron missing:
KPagination:
KSelect with button appearance:

I miss Percy 😢

Addressed!


Validate Docker 23.0.x

Is your feature request related to a problem? Please describe.
Rancher "rke up" fails to install on the most recent Docker Community Edition release 23.0.0. The specific error is "Unsupported Docker version found [23.0.0]"
Docker 23.0.0 Release Notes
Describe the solution you'd like
Rancher would install and work correctly on Docker 23.0.x like it does for 20.10.x. This is essentially a repeat of Issue #30406 but for Docker 23.0.x instead of 20.10.x
Describe alternatives you've considered
Staying on Docker 20.10.23.
SURE-5904

Created Jira for this request. SURE-5904

Closing it as a duplicate of https://github.com/rancher/rancher/issues/40731 (even though this one is older), let's track the updates there.


regression analysis and data_clean alterations

Hi i wrote the regression analysis. I made a .R for the simple code and an .Rmd to explain my steps.
I also made changed to the data_prep.R and .Rmd file to improve the analysis part.
Please check my steps and the flows.

Looks good so far! I do see some spelling mistakes in the .Rmd docs though.


React 18.1.0 not supporting

Feature Request
Package is not working with react versions 18.1.0 and greater
please update peer dependencies to
"peerDependencies": {
"react": ">=15.3.0",
"react-dom": ">=15.3.0"
},

you need npm --legacy-peer-deps

It looks like this is fixed on main but just not deployed to npm, any chance we could get a 9.22.4 published? :)

The support for React 18 was added half a year ago, and yet, there is no even an alpha version with this update?
@bvaughn, could you please clarify the situation?

It not working with React 18
When I try install with yarn add @types/react-virtualized@latest
I see warnings in logs
warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^16.0.0-alpha".
And I installing  yarn add @types/react-virtualized@latest --dev
 'MultiGrid' cannot be used as a JSX component.   Its instance type 'MultiGrid' is not a valid JSX element.     The types returned by 'render()' are incompatible between these types.       Type 'import("C:/app/booking-front-react/node_modules/@types/react-virtualized/node_modules/@types/react/index").ReactNode' is not assignable to type 'import("C:/app/booking-front-react/node_modules/@types/react-router/node_modules/@types/react/index").ReactNode'.
Why @types/react-virtualized@latest version is 9.21.21?

I have the same problem:
npm install react-virtualized npm ERR! code ERESOLVE  npm ERR! ERESOLVE unable to resolve dependency tree                           npm ERR!                                                                      npm ERR! While resolving<EMAIL_ADDRESS>                      npm ERR! Found<EMAIL_ADDRESS>                                                npm ERR! node_modules/react                                                   npm ERR<EMAIL_ADDRESS>from the root project                              npm ERR!                                                                      npm ERR! Could not resolve dependency: npm ERR! peer<EMAIL_ADDRESS>|| ^16.0.0-alpha" from<EMAIL_ADDRESS>npm ERR! node_modules/react-virtualized npm ERR!   react-virtualized@"*" from the root project npm ERR! npm ERR! Fix the upstream dependency conflict, or retry npm ERR! this command with --force, or --legacy-peer-deps

It does not work with 17.x either:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@hypnosphi/create-react-context
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/react-bootstrap-typeahead/node_modules/react-popper
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!       node_modules/react-bootstrap-typeahead
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!       1 more (react-overlays)
npm ERR!   44 more (@restart/context, @restart/hooks, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>|| ^16.0.0-alpha" from<EMAIL_ADDRESS>npm ERR! node_modules/react-virtualized
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Conflicting peer dependency<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR!   peer<EMAIL_ADDRESS>|| ^16.0.0-alpha" from<EMAIL_ADDRESS>npm ERR!   node_modules/react-virtualized
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/tom/.npm/eresolve-report.txt for a full report.

#1775

Version 9.22.4 has been published with peer dependencies updated to include React 17 and 18. (No other changes from 9.22.3)
https://github.com/bvaughn/react-virtualized/releases/tag/v9.22.4


avoid W113 warning

FAILED benchmarks/speed/test_project_speed_benchmark.py::test_benchmark_speed_project

FAILED pipelines/tagger_parser_ud/test_project_tagger_parser_ud.py::test_taggerparser_ud_project

FAILED tutorials/ner_drugs/test_project_ner_drugs.py::test_ner_drugs_project

FAILED tutorials/ner_fashion_brands/test_project_ner_fashion_brands.py::test_ner_fashion_project

fixed by https://github.com/explosion/spacy-legacy/pull/12

FAILED tutorials/textcat_goemotions/test_project_textcat_goemotions.py::test_textcat_goemotions_project


Enable support for file uploads in mutation

I am a beginner to flutter and dart, and coming from the React Native ecosystem. Firstly, I really appreciate the work you guys are doing!!
I am looking for a way to upload files through graphQL mutations for a personal college project. It would make things very straightforward in terms on handling uploads.
A great starting point could be jaydenseric's implementation of apollo-upload-client https://github.com/jaydenseric/apollo-upload-client
Another way is to handle file uploads separately using http request, but this makes it way messier due to the database mutation and upload being separate requests.
I would really appreciate any help or suggestions, I am trying my best to learn and will contribute back :)

At the moment the library does not support file uploads. We're still woking on implementing some core features, therefore this feature probably won't be worked on in the near future.

Closing issue due to inactivity.


Best practice in Rust: "fallible new" vs TryFrom?

Firstly, 🤩 thank you so much - I think many folx have bits of this lying in our code bases!
Secondly, I am hoping to learn whether, in fact "fallible new" is the best practice in Rust today. I had come to understand that, for fallibe NewType wrappers*, the best practice was to impl TryFrom.

https://doc.rust-lang.org/stable/std/convert/trait.TryFrom.html

Why? I had understood (perhaps incorrectly) that:

Fallible TryFrom is supported out of the box by Serde
Fallible new is NOT supported by Serde (and similar tooling)
TryFrom is the most clear idiom when validation can fail in construction

Very interested in your thoughts, and to be clear I am asking a genuine question, not advocating for the TryFrom approach.

Playground link showing the README example using TryFrom:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d971f8dac48d91179b0fff292b46e171

Asked a similar question on Rust users' forum here:

https://users.rust-lang.org/t/best-practice-fallible-new-vs-tryfrom/89695

@ms-ati Hi, thanks for the warm words!
Probably for such kind of question, Github discussions is a better place, but I may need it to make more clear in the README, that it exists.
In case of the current nutype implementation whether ::new() is fallible or not depends on presence of validation rules.
I am aware of TryFrom, and you can see in the source code ( as well as in the docs), that nutype supports derive of TryFrom.

Fallible TryFrom is supported out of the box by Serde

I am not sure what does it mean?
First at all, TryFrom is always fallible by definition (unless it's TryFrom with Err = std::convert::Infallible, which would be very odd).
Does Serde generate TryFrom automatically when somebody derives Deserialize? Or other way around: is there blanket implementation of Deserialize for types that implement TryFrom<String> or something similar?
Anyway, I don't believe that anything above is true.

TryFrom is the most clear idiom when validation can fail in construction

TryFrom is a trait. If you need you can derive it. If not, then do not derive. It's used for a fallible conversion, as result it can be used to construct.
I may understand you confusion, some of my friends were arguing that I should go for TryFrom instead of ::new(). The reason why I did not, is because, I don't want the traits to be derived implicitly.
E.g.
#[nutype]
struct Name(String)

does not derive any traits. It  generates two associated functions: ::new() and ::into_inner(self).
So, you may derive Deserialize:
#[nutype]
#[derive(Deserialize)]
struct Name(String)

without having TryFrom . Or you can do vice versa: derive TryFrom without having Deserialize. Or both. It's up to you.
Having ::new() as a single entry point (all other things like TryFrom or Deserialize still are built on top of ::new()) - simplifies a bit the design and reasoning about it.
I am gonna close the issue. Feel free to comment further if you have any questions.

@ms-ati P.S. You may also want to check bounded-integer.

Thank you @greyblake! Ok so it seems that a fallible new is accepted best practice then?
In which case, thank you - it does make sense that TryFrom is optional to derive in addition to it.

@ms-ati I cannot say that fallible new is accepted best practice. It depends. TryFrom gives you an abstraction upon which you can built other things independently from type, that implements it.


Add the basic Teams API

As documented here,
this adds the basic organization teams CRUD. If this is all good and
gets accepted, I'll probably go on to add the rest of the team API, as
it's currently relevant to the project I'm working on :)
It also appears that the version in the README is quite a bit behind, so I updated that as well.

Coverage increased (+0.3%) to 87.31% when pulling 6274bc58dfe5c175de78ca4c975086558ab90665 on devlocker:teams_api into d44bfc3f7ce159221f2327cee5accc7c03034a06 on edgurgel:master.

thanks @mcasper


pull request for e2e test at 12/29/2016 02:45:12

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Update deprecated resource

Is your request related to a new offering from AWS?
No.
Is your request related to a problem? Please describe.
After upgrading the AWS Terraform provider to v4.0.0 a warning shows up with the following message:
│ Warning: Argument is deprecated  │   with module.ecs_cluster.aws_ecs_cluster.this,  │   on .terraform/modules/ecs_cluster/main.tf line 1, in resource "aws_ecs_cluster" "this": │    1: resource "aws_ecs_cluster" "this" { │ Use the aws_ecs_cluster_capacity_providers resource instead │ (and one more similar warning elsewhere)
Describe the solution you'd like.
Update the module to use the aws_ecs_cluster_capacity_providers resource
Additional context
Deprecated resources are listed at the ECS Cluster Terraform documentation web
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_cluster

I can see this change was made here - https://github.com/hashicorp/terraform-provider-aws/pull/22783
Pull-request is welcome if anyone wants to do it.

Is anyone working on reviewing this PR?   I have some ECS clusters which inherit this module and I am experiencing this issue as well. Thanks in advance!

Bumping this since this is still open.


[core] Remove rcore.h include from Android

Very short fix to remove the rcore.h include from PLATFORM_ANDROID (L49) so it matches the other submodules.
References: #3420, https://github.com/raysan5/raylib/issues/3313#issuecomment-1764276021.
Edit: added line marks.

@ubkp thanks for the review!


Map Labeling

Depending on zoom...

[x] Include neighborhood names
[x] Include street names
[x] Include unit numbers

Closing this out! Resolved with mapbox style.


Deploy transaction is too large and not good for the client SDK

Description
The current deploy transaction as created by the NVP (Non Validating Peer) consists of the chaincode plus dependencies (e.g. shim, etc). The size of the dependencies is large which makes the deploy transaction an order of magnitude larger than if it only contained the chaincode source. This means that the node client SDK associated with https://github.com/hyperledger/fabric/wiki/Client-SDK-Specification requires that all dependencies be available to the client SDK in order to submit a deploy transaction. This is bad for both efficiency/performance as well as for usability.
We have two languages to consider: the SDK language (sdkLang) and the chaincode language (ccLang). Although we are currently only talking about , we need to think of other combinations as more SDKs and chaincode languages are supported.
Consider the following options:

Each transaction contains the chaincode plus the dependencies as it does today. This requires that the dependencies be available at time of deploy to the SDK. Two options for making this available are:
a) bundling the dependencies with the sdk. I don't think this makes sense since we'll support other ccLang's going forward and would further bloat the size of the node module and other sdk's going forward, so we aren't going to consider this a viable option.
b) the client SDK requires that the dependencies be available locally where the client SDK runs.  This is not very user-friendly.

The transaction contains the chaincode plus some small amount of metadata to bind it to it's dependencies. The dependencies are stored on the ledger via a separate invoke transaction to some system chaincode. The deploy transaction on each peer then finds the most recent dependencies for the particular ccLang and builds the image using this combination of chaincode + dependencies.

For the client SDK work, we are considering "1b" as a tactical solution, but would like to propose #2 as a strategic solution. The advantages of this option are:
a) deploy transaction is an order of magnitude smaller
b) much better deploy performance
c) everything is still on the ledger
d) upgrade of the dependencies (e.g. shim) is simple since we just need to invoke a transaction to store the updated dependencies on the ledger.  In this case, one question is who should be allowed to update the dependencies? One option might be to require a user to have an attribute name of "fabric.deploy.dependencies" with a value of "go" to update the dependencies for the "go" chaincode language.
All feedback is welcome.

Hi Keith,
I have a few comments:
A) I know the current advocated architecture is "[rest-client]->[nvp]->[vp vp vp]" and from that we can make a few further statements:
A1) The SDK aims to collapse the first two stages
A2) The NVP tends to be the one that packages the chaincode bytes for dissemination as the xVP who receives the deploy().
From that, you are highlighting the problem that this places the burden on the SDK to replicate the packaging.  I don't see it that way, however.  Unless I am missing some nuance, I think it would work perfectly fine to let the SDK emit a standard chaincodeID{} tuple and continue to let the first VP handle it as the NVP does in the above model.
B) Your scenario in option (2) was precisely what I was trying to solve with chaintool CAR packaging.  That is, we take just the minimal source and some metadata that describes a platform coordinate which implies the dependencies required without actually packaging them, and compresses it down as small as possible.

Greg, the VP doesn't have the private key for the user's ecert, so unfortunately that will not work.

I didn't realize the NVP had possession of private keys.  That doesn't smell right at all from a security design perspective, but I understand what you are getting at.  The solution is probably to adopt CAR or something like it, rather than a more generic tarball.

@smithbk  - been a while since I looked deeply at this, but just took a quick look through the peer code.  Not sure why you need to actual add any of the dependencies?  Perhaps I am not sure what you mean by dependencies?  From what I recall as well as quick code review, looks like you definitely need access to the src for the chaincode itself but nothing else as far as I can tell.  You need to create a tar with the correct Dockerfile as well as the src for the chaincode itself.  Of course you'll also need to hash the chaincode src per the algorithm in the peer code to use as the ID, but other than that wondering where you are seeing the need to add all of the dependencies?  (of course this assume that the dependencies are available via go get / go install - e.g. in a public repo).  If you have dependencies which cannot be satisfied by public Go packages, then of course you need to include those as well

@ghaskins is the CAR specified somewhere?

@christo4ferris https://github.com/ghaskins/chaintool/blob/master/resources/proto/car.proto.
Related: I am putting in some final touches to the code and hope to have a HIP in place in time for next week's TSC meeting to add the entire https://github.com/ghaskins/chaintool repo under fabric/tools/chaintool

@mastersingh24 @smithbk @jeffgarratt
I looked into this more and also discussed with @jeffgarratt to get a better idea of the options we have.
The way the process works on the server side right now is that the Docker container is basically created empty. It does not contain any hyperledger fabric related source code in it. Therefore, to build the chaincode that is being sent over from the client we either need to: (a) package the fabric code and send it over form the client side inside the request or (b) do a "go get" on the required source code inside the Docker file. Without the fabric dependencies the chaincode simply does not build.
Currently, I am doing my deployment through approach (a), where I assume that the chaincode developer is developing the chaincode locally on their machine and has the hyperledger source tree underneath their vendor folder. Such as shown in the schema below. That is basically option 1b as described by Keith in the 1st comment. I understand we have not 100% resolved the issue of who will be supplying these dependencies for the chaincode developer or where they will come from, but the point is to test/build their chaincode locally they MUST have these dependencies somewhere. Othewise, the chaincode just doesn't build. Therefore, currently I am assuming it is inside /vendor, it can certainly be somewhere else. But /vendor works perfectly fine. I understand the package size is large and non-optimal. But it works.
$GOPATH/src/github.com//
--> project code
--> vendor
--> hyperledger code
As far as not sending these hyperledger dependencies within the deployment transaction payload. @mastersingh24 you state: "of course this assume that the dependencies are available via go get / go install - e.g. in a public repo). If you have dependencies which cannot be satisfied by public Go packages, then of course you need to include those as well". Yes, we can certainly exclude all of the fabric dependencies from the resulting .tar.gz for Docker, but that implies we will need to pull them in when Docker starts up. That opens up another issue of making sure that the version of the fabric that we're pulling in is the same as what was being originally developed against on the client side. I know we can specify a commit that we want to pull from and fetch code from that specific commit on Github. Though from talking to @jeffgarratt, this seems like a lot of premature optimization and raises concerns on different peers catching up and re-running transactions. @jeffgarratt please add more thoughts here if I'm not capturing your concerns well.
For now, I will be removing the largest (and unnecessary) executable files from the resulting .tar.gz when it is being created and that makes our deployment transaction quite a bit smaller. From what I've observed we can go down to about 2-3Mb after removing the unnecessary files, which seems OK for now.

@angrbrd In the long term, want to allow a webapp to bundle the chaincode source and to deploy it from a servlet init method for example.  The chaincode source has already been compiled/tested previously in another env and they can redeploy this webapp multiple times in multiple environments.  In this model, we don't want to require that they have the gocode on each appserver instance in each env.
In the short term, I think Anya's solution is acceptable.  Thoughts everyone?
@mastersingh24 Gari, the main thing I'm including in the "dependencies" is the shim.  I thought we wanted to have everything on the ledger to replay a transaction.  If so, since we will need to provide an upgrade strategy for the shim, then putting it on the ledger would make sense.   Thoughts?  This is of course longer term.

Trying a summary from purely packaging point of view (no upgrade, migration, etc).
Due to crypto operations on the transaction - now done in the SDK - I think the options are the following

create the whole chaincode in the SDK
provide chaincode in SDK but collect dependencies in Docker (basically things like "go get" in dockerfile). BTW "go get" on Dockerfile has two disadvantages (1) potential of different peers computing differently and (2) no option to close the docker network env
split the transaction in such a way that we do it in two "transactions", chaincode in SDK and dependencies in peer
end user provides the full package (@smithbk's "long term")

1 and 4 are the most straighforward and clean. And as 1 and 4 are logically equivalent from peer's viewpoint, IMO 1 is not a bad option if we want do 4 in future.

Hi All,
Related to this, I have a few interesting developments.

A proposed optimization on the NVP side is to recognize that dependencies (both direct and transitive) generally only need to consist of .go files and nothing more.  Therefore, a patch like this https://github.com/hyperledger/fabric/commit/b45b481167272585d88f9b94078b468b8a3efd20 has helped to substantially reduce the size of the deploy as generated by the NVP.  You might be able to take advantage of this too.
More interesting, "go list" has some potentially useful mechanisms here, as this blog does a good job of highlighting: http://dave.cheney.net/2014/09/14/go-list-your-swiss-army-knife

That is, for a given application, it should be possible to use a combination of {{.Deps}}, {{.GoFiles}} and {{.Dir}} to build a list of the precise files that any given application depends on.  You would probably want to minimally filter out $GOROOT and possibly hyperledger/fabric/core/chaincode/shim, but this seems like a good way to have an optimal set.

I plan on adding this logic to chaintool for generating .car packages...I would imagine the SDK could make similar use.

This issue is already tracked in Jira here: https://jira.hyperledger.org/browse/FAB-11
@christo4ferris please close out this issue. Thanks!


add tr language

Specifically, this PR likely includes modifications to the codebase to add tr as a supported language option in the package, as well as any necessary changes to ensure that the package functions correctly when used with Turkish language data.
Once your PR is merged, users of the "pxlrbt/filament-excel" package will be able to work with Excel files in Turkish, making the package more versatile and accessible to a wider range of users.

Thanks!


[Host.Hybrid] Support to publish event to more than one child bus if event type match

Hi @zarusz
We should have a chat room for this repo for some questioning.
I have a question I need your help to clarify.
Let's say I have two children bus (Bus1 and Bus2). When pushing a message, how could I select which bus to push?
Thanks
Steven

Hello @baoduy , there is a gitter chat link available on the main repo page, it's meant for just that.
To answer your question, during publish the hybrid bus matches the child bus based on the message type being published. Let say that Bus1 declares message A and Bus2 declares message B, then when you publish A it will be routed to Bus1.
It's described in the hybrid bus docs.
Unless you need something more than that?

Hi @zarusz
Thank you so much for your response. Just a quick clarification. If I define the same message type on both provide, will it be sent to both Service Buses?
By the way, Merry Christmas and Happy New Year.
Thanks
Steven

I only envisioned declaring distinct message types for each child bus. So currently it won't work like that. If needed we could extend it to do so. Could you elaborate on your use case please?
What types of buses you have?
Would you want it to send to both child buses at the same time?
Merry Christmas and Happy New Year ;)

Hi @zarusz
I am currently working on an application that uses the DDD design. By default, we push all events to an internal provider called the Memory Provider. However, for certain events that require external services, we need to send them to an external provider called the Azure Service Bus. The issue is that our library does not support this scenario, so we have to convert the internal events to external events at the handler level, which is not ideal. It would be helpful if the library supported this scenario so that the internal handlers could be cleaner and not have to forward the messages to the external bus.

@baoduy that is a good scenario - thanks for the explanation. I've also encountered a similar need on another project. Over there we use the memory handler (for domain events) and decided to translate these in-memory domain events to external events (via a translating handler) - this is to decouple the internal event from the external event schema and allow them to evolve independently.
That said, it's also a fair ask to add the feature to allow the hybrid bus to dispatch the event to all child buses that declare such an event type. I will go ahead and change the description of this issue and add it to my immediate backlog (super simple change).

Hey @baoduy, please have a look at this pre-release:
https://www.nuget.org/packages/SlimMessageBus.Host.Hybrid/1.22.2-rc1
Check also the updated docs and let me know if it's clear enough:
https://github.com/zarusz/SlimMessageBus/blob/feature/_Host.Hybrid]_Support_to_publish_event_to_more_than_one_child_bus_if_event_type_match_%23143/docs/provider_hybrid.md#configuration
Please report if this works for you.

Hi @zarusz
I just did some basic checks, and it is a working property. I will continue to do some more testing on this and will let you know if there are any.
Thank you so much for your quick action.
Steven

Thanks! I merged the PR and will keep this issue open for a few days just in case. This feature will be released within few weeks with another feature I am working on. Cheers

thank you so much for your help. @zarusz. Let me close the issue here also.


Adding Private DNS Swagger spec for API version 2018-09-01

This PR was previously approved against the private repository by both ARM and OpenAPI teams.
OpenAPI Hub was not used for this PR since it does not allow onboarding of a new resource type as of yet. This feedback has been given to Samer previously.
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby
A PR has been created for you:
https://github.com/Azure/azure-sdk-for-ruby/pull/2230

Automation for azure-sdk-for-node

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

Waiting for codeowners approval.

@AutorestCI regenerate azure-sdk-for-java


feat: independent search

Closes #5.
I'll commit some more documentation later (i.e. on replacing rg with a different tool). We may consider replacing rg by default with grep, although rg is faster everybody has grep installed.

Regarding rg, I'd suggest checking if it's executable and if not, falling back to grep since as you said most people have it installed.
If you default to grep, a good chunk of people won't bother to change it and will have a worse experience out of the box.

Good idea, added!

This is looking good. I'll need to test this before I merge this in but do you know if this works with things like ignorecase?

I completely forgot about that, I will have to conditionally add some flags. Shouldn't be difficult, I'll update later today.

Any update on this one?

@CallumHoward Refactor of the main codebase is in the works, I'll try to add independent search based off this when I have the chance

I'm excited for this refactor! Thanks for your hard work

I see it's been one year an a half, do you need help with this?


PropertyFieldColumnPicker?

Thank you for reporting an issue, suggesting an enhancement, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to help. Thanks!
Please check out the documentation to see if your question is already addressed there. This will help us ensure our documentation is up to date.
Category

[X] Enhancement
[ ] Bug
[ ] Question

Version
Please specify what version of the library you are using: [   2.1.1      ]
If you are not using the latest release, please update and see if the issue is resolved before submitting an issue.
Expected / Desired Behavior / Question
Any plans to implement a List column picker dependent on list similar to the PropertyFieldListPicker which is optionally dependent on site?

Hi @jscudder,
It could be a good addition to the library!
Thank you for the suggestion.

Hi @jscudder,
It could be a good addition to the library!
Thank you for the suggestion.

Hi @AJIXuMuK, I am interested to take this enhancement. Please let me know.

Sure @sudharsank! Thank you!

Hi @jscudder, the control is released. Hope you had already tried the control? Let us know if you have any issues.

Unable to add Filter through filter property  Below is what it is going through browser

Filter not working properly and debugged the found the following error in the code
"SPColumnPickerService.js"
if (this.props.filter) {                             if (displayHiddenColumns)                                 queryUrl += "&$filter=&" + encodeURIComponent(this.props.filter);                             else                                 queryUrl += "&$filter=Hidden eq false&" + encodeURIComponent(this.props.filter);                         }
above code & should be removed other wise it will be treated as new Query string.


Template is not working. After purchasing while deployment of VM it is failing.

I am getting the following error.
Changing property ‘windowsConfiguration.winRM.listeners’ is not allowed.
(Code: PropertyChangeNotAllowed, Target:
windowsConfiguration.winRM.listeners)
[Enter feedback here]

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

ID: 45c01d12-9d17-5f37-81dc-11fe8200e5b4
Version Independent ID: 8d9ae047-e3a5-26d7-69f8-6b1bce33a241
Content: Azure VHD deployment template
Content Source: articles/marketplace/cloud-partner-portal/virtual-machine/cpp-deploy-json-template.md
Service: marketplace
GitHub Login: @v-miclar
Microsoft Alias: pabutler

@Avenger-devp Thanks for the question. We are investigating the issue and will update you shortly.

@JiayueHu and @v-miclar Any help you can offer here or redirect to right contact for assistance.

@JiayueHu and @v-miclar Any update on this?

@SadiqhAhmed-MSFT  please remove me from the list, I'm not working in this area.

@Avenger-devp I apologize for the delayed response. If you still need help with this, please contact Marketplace support: https://aka.ms/MarketplacePublisherSupport

#please-close


feat(gateway): pass search query as url param instead of url segment

/AzurePipelines run docker-images


After building an image that was built before, a dangling  remains

Reproduce this by:

building an image, note that it gets added to the list in docker images
build the same image again, with the same tag.

The previous image gets untagged but not deleted. This results in a dangling image.
Can the previous image be deleted automatically?
I am using OSX with boot2docker.
$ boot2docker version
Boot2Docker-cli version: v1.3.0
Git commit: deafc19

$ docker --version
Docker version 1.3.0, build c78088f

Closing this, because it's really standard docker behavior and it's fixable by running a simple cron job on the docker host that runs docker rmi $(docker images -qa -f "dangling=true")

Sorry for a bif of the necropost, but the suggested solution is not really beautiful (and sometimes needs plastering sudo's all over the place). Would be nice if docker provided this functionality out-of-the box (something akin to git commit --amend). It'd be especially useful when you have relatively big docker images and in the process in of the rapid "tinker a bit with dockerfile/required files" -> docker build -> docker run and repeat. Disk space disappears very fast.

I know this thread is out of date- but I would like to voice my support for some kind of basic "garbage collection" to remove the useless, dangling images.

@wouterd Did you guys consider the above and did any implementation?

in my ~/.bashrc I ensure the following lines are present
alias docker_rm_all="docker rm \`docker ps -a -q\`"
alias docker_rmi_all="docker rmi \`docker images -q\`"
alias docker_rmi_dangling="docker rmi \`docker images -qa -f 'dangling=true'\`"

This allows me to clear all containers, all images, and all dangling images. Seems to fulfil this and a few other issues

The above command should not work for me in my mac os


Adding component to row cell

[x] Question

Specs
What version are you using? 2.18.0
How can I add a component to the row cell? I have a requirement to add an icon based on the value and our icons are in SVG format and pulled in via a component into a custom row template. I am trying to add this to the table, but the component isn't being loaded.
<template slot="table-row" slot-scope="props">

              <template v-if="props.row.learning == 'completed'">
                <SvgIcon :name="completed" title="completed" />
              </template>
              <template v-if="props.row.learning == 'not-completed'">
                <SvgIcon :name="not-completed" title="not completed" />
              </template>

            {{props.formattedRow[props.column.field]}}

</template>

So it would look like this image.

In this I am trying to load the  component. This is set to load for the page the table is displayed on. It just won't load into the table. How can I get a component to load into a cell of the table?

I think the template wraps the span not the other way around.
But if I may say I have a similar issue which is loading more than 1 component using the template slot="table-row". I can load 1 component for 1 specific column but if I want to load another component for another column it strips the component and leaves the raw property.
I apologize for the long code.
<vue-good-table
                :columns="columns"
                :rows="users"
                styleClass="vgt-table striped bordered"
                :search-options="{ enabled: true }"
                :line-numbers="true">
            <template slot="table-row" slot-scope="props">

                    <department-colors
                            :department="props.row.role.department.name"
                            v-text="props.row.role.department.name"
                    ></department-colors>

                    {{props.formattedRow[props.column.field]}}

            </template>
            <template slot="table-row" slot-scope="props">

                    <status-icon
                        :status="props.row.status"
                    ></status-icon>

                    {{props.formattedRow[props.column.field]}}

            </template>
</vue-good-table>

I also try placing the span>component into only 1 template with slot of table-row but it just loads the properties in a single cell.
Thanks in advance.


wifibc has new python-twisted dep

Notice: /Stage[main]/Maverick_network::Wifibroadcast/Exec[compile-wifibc]/returns: PYTHONPATH=`pwd` trial telemetry.tests
Notice: /Stage[main]/Maverick_network::Wifibroadcast/Exec[compile-wifibc]/returns: /bin/sh: 1: trial: not found
Notice: /Stage[main]/Maverick_network::Wifibroadcast/Exec[compile-wifibc]/returns: Makefile:43: recipe for target 'test' failed
Notice: /Stage[main]/Maverick_network::Wifibroadcast/Exec[compile-wifibc]/returns: make: *** [test] Error 127
Error: '/usr/bin/make' returned 2 instead of one of [0]
Error: /Stage[main]/Maverick_network::Wifibroadcast/Exec[compile-wifibc]/returns: change from 'notrun' to ['0'] failed: '/usr/bin/make' returned 2 instead of one of [0]
Notice: /Stage[main]/Maverick_network::Wifibroadcast/File[/srv/maverick/software/wifibc]: Dependency Exec[compile-wifibc] has failures: true

Aargh, custom python3 isn't built with bz2 support, twisted archive can't be installed through pip3


Add Users.authenticate_with_token() method

Description
Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
[ ] Yes

If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.

Current dependencies on/for this PR:

users

PR #191

PR #192

PR #193

PR #195

PR #196

PR #197

PR #198   👈

This comment was auto-generated by Graphite.

Codecov Report

Merging #198 (50a4c6e) into feature/usrld-706-add-authenticateuserwithpassword-to-python (6d1f33f) will increase coverage by 0.11%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@                                       Coverage Diff                                        @@
##           feature/usrld-706-add-authenticateuserwithpassword-to-python     #198      +/-   ##
================================================================================================
+ Coverage                                                         87.77%   87.89%   +0.11%
================================================================================================
  Files                                                                32       32
  Lines                                                              1162     1173      +11
================================================================================================
+ Hits                                                               1020     1031      +11
  Misses                                                              142      142

Files Changed
Coverage Δ

workos/users.py
93.10% <100.00%> (+0.99%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


travis tests for all python3 versions and 2.7

See the travis build corresponding to previous commit for detailed informations why the 2.6, 2.7, 3.0 to 3.4 are not supported.


nodeapi: Make CommitteeKind compatbile across cobalt and damask

Bugfix for accessing cobalt state. I don't know how we didn't hit this problem before.
Problem
The CommitteeKind type (which is used inside committee updates at the consensus layer) is an enum, with three possible values in cobalt, but only two possible values in damask. Before this PR, we were using the damask type. So when trying to serialize an enum value that comes from cobalt and is valid in cobalt but not in damask, an error was raised.
Solution
This PR creates a new type that's independent of cobalt and damask (even though it's technically just copy-paste from cobalt), but is compatible with both.
No data changes are needed (caches, db, etc). The new type is byte-compatible with the type we've been using. Just the serde methods are able to accept the extra enum value.
Testing
Not much because the change is minimal. Previously, some blocks just before damask failed to get indexed (because the CommitteeKind value gets serialized for insertion into the DB). After this PR, those blocks can be indexed.

consensus analyzer had not caught up to when the paratime first had a committee elected

IIRC that was only after the accidental cache deletion + starting full reindex. But maybe.


[Safe Apps] Get Safe Apps default list from external source

Right now we have to manually include new "default Safe Apps" into safe-react.

This requires a separate deployment of the safe-react web app for each new wave of apps
We can't toggle off Safes that turn out to be malicious or have critical bugs, as we have to release a hotfix

to solve these issues with should get the list of default Safe Apps from a new backend endpoint or another external source.
One possible solution might be to establish a semi-automated workflow using the safe-react-apps repository, requiring developers to open PRs to merge their apps into the repository and have app builds automatically created (and added to IPFS) after e.g. merging to development or to master. IPFS links of apps merged to master would then be automatically consumed by safe-react and displayed to the user.
Considerations

How do we handle versioning?
In the future, there might be some decentralized governance deciding what apps should be displayed in the safe-react interface using a TCR or similar. We probably need a centralized solution in the meantime, as the community-governance won't be able to solve the above issues in the near- to mid-term.

@Uxio0 @rmeissner @mikheevm how should we proceed with this?

There is no plan for this yet and we didn't discuss anything related to this yet, so imo there are still some things to dicuss and define before we can implement anything here

Discussed during release planning:

Create overview doc with goals, issues and proposal for implementation.
If all is clear, then it can be release with 2.17.0

 Get list of apps from exterrnal source

 Get list of apps from exterrnal source

#1853 might be relevant to check out.

We had a discussion with backend on how we could face this task. Can be followed in this document:
https://docs.google.com/document/d/1OT08vCcJz760JO0ZO3hALOftyOlxeZpYUiimCk8yPC0/edit#heading=h.i9l1487y0y8f


Normal Button Color Change From Java Code

I want to change FloatingActionsMenu fab_addButtonColorNormal from my java code. But i can't get any set method for changing color.
How i can do that?

Hi ! Did you find the solution ?? If so then please tell because i have facing the same problem right now


Navidrome Scrobbling not working

Hello,
When I listen to my music on Submariner, scrobbling with Last.fm in my Navidrome app is not working. It seems to be the same issue as described here: https://github.com/navidrome/navidrome/issues/2347
Is it possible to implement a solution for this in your app?
Thank you.
Pierre

Seems like the easiest solution is to just always scrobble, even if we're playing the remote stream URL. I thought we only needed to do when playing a local resource representing a remote resource.


MM-12822 - Updating background css for team icons

Summary
MM-12822 - Updating background css for team icons
Ticket Link
https://mattermost.atlassian.net/browse/MM-12822
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] Ran make check-style to check for style errors (required for all pull requests)
[ ] Ran make test to ensure unit and component tests passed
[ ] Added or updated unit tests (required for all new features)
[ ] Needs to be implemented in mobile (link to PR or User Story)
[ ] Has server changes (please link)
[ ] Has redux changes (please link)
[x] Has UI changes
[ ] Includes text changes and localization file (.../i18n/en.json) updates
[ ] Touches critical sections of the codebase (auth, posting, etc.)

@esethna Can you please review this? I wasn't able to reproduce this, but since you can, I submitted a fix, have a look and see if that fixes your issue.

Setup Test Server label detected. Spinmint test server created if build succeeds (checks pass and no conflicts with base branch).

Spinmint test server created at: https://i-010ccebe1144442b1.test.spinmint.com
Test Admin Account: Username: sysadmin | Password: sysadmin
Test User Account: Username: user-1 | Password: user-1
Instance ID: i-010ccebe1144442b1

Spinmint test server destroyed

@esethna Can you have a look at it now.

Spinmint test server destroyed

Merged and cherry-picked onto 5.5


Psych-DS Validator Requirements doc

In order to promote inclusive/quick discussion for broad-scale planning for the architecture of the Psych-DS validator tools, we are working on proposed requirements for the software in this google document:
https://docs.google.com/document/d/1W98l4VfHvXu_tpfWCil_WqQHiUxdKDdxP6Cwvn7HWiI/edit#heading=h.hxl5pr3wo6qy
This issue should remain open until that document is no longer being actively used for the project!

@bleonar5 when you have some time could you please review the open issues on this repo and redistribute ones like this to the validator repo?


Client Secret should not be in mobile app code

Shouldn't the mobile app code not include the client secret?
As far as I know, mobile apps should not include the CLIENT SECRET in the source code because of source code confidentiality.
The following article confirms the same:
http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified
You are fetching the access_token from code assuming it's a web server app.

According to Uber Doc, client_secret is used to get an access token
check out their docs:
https://developer.uber.com/v1/auth/

Think again, should you give away your secret (client_secret) to public (who have your mobile app)?
The link you shared/ docs are basically describing authorization for server side web app. Your link has "check out Aaron Parecki's OAuth 2 Simplified guide". That confirms that you should NOT save the client_secret in the mobile apps.

Good point. I will check that out.

I get 401 UNAUTHORIZED when I remove (client_secret) from getting an access token. What do you think about that?

You have to set 'grant_type=token' for that to work.
Let me know if it doesn't work.
Thanks,
Kishy
On Tuesday, November 10, 2015, Ahmed Gamal<EMAIL_ADDRESS>wrote:

I get 401 UNAUTHORIZED when I remove (client_secret) from getting an
access token. What do you think about that?
—
Reply to this email directly or view it on GitHub
https://github.com/Neno0o/Uber-Android-SDK/issues/3#issuecomment-155414662
.

--
Sent from my iPhone

The grant_type may be authorization_code or refresh_token. I used both of them and still getting 401 UNAUTHORIZED.
Thank you!

Sorry - the 'response_type' has to be 'token'.
Please read this:
http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#browser-based-apps
I followed this and it works.
On Sat, Nov 14, 2015 at 2:40 AM, Ahmed Gamal<EMAIL_ADDRESS>wrote:

The grant_type may be authorization_code or refresh_token. I used both of
them and still getting 401 UNAUTHORIZED.
Thank you!
—
Reply to this email directly or view it on GitHub
https://github.com/Neno0o/Uber-Android-SDK/issues/3#issuecomment-156682368
.

--
Best,Kishy KumarSenior Member of Technical Staff, Oracle America
Inc.Phone:<PHONE_NUMBER>

Hi again, thanks for pointing out this great article.
I changed 'response_type' and still not working. According to Uber Docs "response_type: code is the only acceptable input at this time."


Error deploying the SeldonDeployment in namespace other than kubeflow

Trying to deploy a SeldonDeployment:
$ microk8s kubectl apply -f model-mlflow-local.yaml -n kubeflow
seldondeployment.machinelearning.seldon.io/mlflow created

$ microk8s kubectl apply -f model-mlflow-local.yaml -n admin
Error from server (InternalError): error when creating "model-mlflow-local.yaml": Internal error occurred: failed calling webhook "v1alpha2.vseldondeployment.kb.io": Post "https://seldon-webhook-service.kubeflow.svc:4443/validate-machinelearning-seldon-io-v1alpha2-seldondeployment?timeout=30s": dial tcp <IP_ADDRESS>:4443: connect: connection refused

I have the same secret in both of the namespaces:
$ microk8s kubectl get secrets -A | grep seldon-init-container-secret
admin              seldon-init-container-secret                          Opaque                      6      114m
kubeflow           seldon-init-container-secret                          Opaque                      6      114m

yaml file (requires changing the modelUri)
apiVersion: machinelearning.seldon.io/v1alpha2
kind: SeldonDeployment
metadata:
  name: mlflow
spec:
  name: wines
  predictors:
  - componentSpecs:
    - spec:
        containers:
        - name: classifier
          livenessProbe:
            initialDelaySeconds: 80
            failureThreshold: 200
            periodSeconds: 5
            successThreshold: 1
            httpGet:
              path: /health/ping
              port: http
              scheme: HTTP
          readinessProbe:
            initialDelaySeconds: 80
            failureThreshold: 200
            periodSeconds: 5
            successThreshold: 1
            httpGet:
              path: /health/ping
              port: http
              scheme: HTTP
    graph:
      children: []
      implementation: MLFLOW_SERVER
      modelUri: s3://mlflow/71/8476095066fd43af8ae2a6f1511044df/artifacts/model
      envSecretRefName: seldon-init-container-secret
      name: classifier
    name: wine-super-model
    replicas: 1

Deployment was done using kubeflow-lite bundle + mlflow (stable channel). RBAC is enabled on microk8s.

I think this is because we haven't added these permissions to the aggregate roles applied to each Kubeflow user.  We had a similar problem for other components (Katib, kfp, ...) when moving to multi-user and solved it with the kubeflow-roles-operator.  Likely we can fix this the same way.

Nevermind, my first guess was completely wrong.
Instead I believe the problem might be that for namespaces with the label serving.kubeflow.org/inferenceservice: enabled, they trigger a webhook that goes through the seldon-webhook-service and one of that webhook's selectors is control-plane: seldon-controller-manager, but the pod providing the webhook does not have that label.  Looking into what we should be labelling things now, but as a quick fix either of these works:

edit the seldon-webhook-service and delete that control-plane label
remove the serving.kubeflow.org/inferenceservice: enabled label from the admin namespace

Looking into what the webhook is supposed to actually do, etc, to see how we should configure things to fix permanently.

If you have a work around that can fix working environments it would be
great. We can use it as a documentation how to deploy in not CKF managed
namespaces.
pt., 4 mar 2022, 14:44 użytkownik Andrew Scribner @.***>
napisał:

I think this is because we haven't added these permissions to the
aggregate roles applied to each Kubeflow user. We had a similar problem for
other components (Katib, kfp, ...) when moving to multi-user and solved it
with the kubeflow-roles-operator
https://github.com/canonical/kubeflow-roles-operator. Likely we can fix
this the same way.
—
Reply to this email directly, view it on GitHub
https://github.com/canonical/seldon-core-operator/issues/22#issuecomment-1059173839,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE4LLWRNWX37KOPUOJG5TULU6IHTDANCNFSM5P5D6NFQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Turns out this is actually fixed in edge by #14, but not pushed to stable.  I'll close this but if you hit it again please reopen


Input filtering for completed work

To prevent from repeated work, an option to filter the input list of ligands based on output tables is desired. It should be possible to electively use this filtering, as in some cases it may be desired to run early steps again (e.g. in case of config/model changes).
python -m bluephos.bluephos_pipeline --input-filter-reference /path/to/table [other options, ...]

is a possible implementation

This feature was included in #67


convert shapes to polygons

First off, this set of libraries is absolutely brilliant, thank you!
I'm playing around with it for some generative art, and wondering if there is a way to convert shapes like circles, ellipses, etc. into polygons. So that I can do things like distort the points, chop them up, smoothing, etc., etc.
It would be great if there was a ellipse.polygon(60) for example which "rasterized" it into a 60-sided polygon.

Great ideas, @ianstormtaylor! Here are some examples of how you could achieve this:
// For circles
const p = Polygon.regular(60, 10)

// For ellipses
import {list} from '@mathigon/core';
const ellipse = new Ellipse(new Point(0, 0), 10, 15);
const q = new Polygon(...list(0, 1, 1/60).map(t => ellipse.at(t)));

Very smart, thanks @plegner!


The 'WriteCompilerDetectionHeader' Module Fails on build

OS: Arch Linux x64
That module has been such a pain and I'm not even really using it, so I'll probably just take it out tomorrow.
Build Command:

cmake -G "Unix Makefiles" ../keygen/

-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found GTest: /usr/lib/libgtest.so
-- Boost version: 1.67.0
-- Found the following Boost libraries:
--   program_options
Successfully found Boost
Boost Include Dirs: /usr/include
Boost Libraries: /usr/lib/libboost_program_options.so
-- Configuring incomplete, errors occurred!
See also "/home/jose/Documents/Projects/KeyGen/build/CMakeFiles/CMakeOutput.log".
See also "/home/jose/Documents/Projects/KeyGen/build/CMakeFiles/CMakeError.log".

Current Source Dir: /home/jose/Documents/Projects/KeyGen/keygen
CMake Error at /usr/share/cmake-3.11/Modules/WriteCompilerDetectionHeader.cmake:395 (list):
  list sub-command REMOVE_DUPLICATES requires list to be present.
Call Stack (most recent call first):
  CMakeLists.txt:31 (WRITE_COMPILER_DETECTION_HEADER)

Update Linux build command to:
cmake -G "Unix Makefiles" ..\keygen\ -DCMAKE_TOOLCHAIN_FILE=~/Documents/Sources/vcpkg/scripts/buildsystems/vcpkg.cmake

Issue has been suspended and will be closed.


Add qir to azurebackend

This PR addresses the addition of submitting jobs as QIR bitcode files to through the AzureBackend instead of a Q# object.
Since Q# is likely to be removed from the submission process, this extension might be considered for renaming to pytket-azure. This could take place when it is moved to its own repo.

Sorry I have only just seen this. Could you please resolve the merge conflict?

Sorry I have only just seen this. Could you please resolve the merge conflict?

DOne. Though I would be a bit wary about it. I am not sure Azure fully support QIR submissions yet. There are ongoing discussions with MS people atm but I am not sure what the status of this is. Although the test might succeed, the results might be meaningless.

Sorry I have only just seen this. Could you please resolve the merge conflict?

Done. Though I would be a bit wary about it. I am not sure Azure fully support QIR submissions yet. There are ongoing discussions with MS people atm but I am not sure what the status of this is. Although the test might succeed, the results might be meaningless.

OK. At least for noiseless simulator backends it should be possible to test if the results are meaningful.

Is this something you want to get moved over to the new repo? https://github.com/CQCL/pytket-qiskit/