Adding "allow-privileged true" flag kills the kubelet

I need to run some pods as privileged and I found (https://github.com/ubuntu/microk8s/issues/216) that I have to use --allow-privileged true which I did and as suggested I restarted the required daemons but that killed my kubelet and microk8s. I even deleted everything and reinstalled microk8s but the same happened.
Please run microk8s.inspect and attach the generated tarball to this issue.
microk8s.inspect
Inspecting services
  Service snap.microk8s.daemon-containerd is running
  Service snap.microk8s.daemon-apiserver is running
  Service snap.microk8s.daemon-proxy is running
 FAIL:  Service snap.microk8s.daemon-kubelet is not running
For more details look at: sudo journalctl -u snap.microk8s.daemon-kubelet
  Service snap.microk8s.daemon-scheduler is running
  Service snap.microk8s.daemon-controller-manager is running
  Service snap.microk8s.daemon-etcd is running
  Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system info
  Copy network configuration to the final report tarball
  Copy processes list to the final report tarball
  Copy snap list to the final report tarball
  Inspect kubernetes cluster

Building the report tarball
  Report tarball is at /var/snap/microk8s/743/inspection-report-20190806_181638.tar.gz

And
sudo journalctl -u snap.microk8s.daemon-kubelet | tail
Aug 06 18:14:51 ali-P51 microk8s.daemon-kubelet[5306]:       --vmodule moduleSpec                                                                                comma-separated list of pattern=N settings for file-filtered logging
Aug 06 18:14:51 ali-P51 microk8s.daemon-kubelet[5306]:       --volume-plugin-dir string                                                                                The full path of the directory in which to search for additional third party volume plugins (default "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")
Aug 06 18:14:51 ali-P51 microk8s.daemon-kubelet[5306]:       --volume-stats-agg-period duration                                                                          Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes.  To disable volume calculations, set to 0. (default 1m0s) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
Aug 06 18:14:51 ali-P51 microk8s.daemon-kubelet[5306]: F0806 18:14:51.854669    5306 server.go:156] unknown flag: --allow-privileged
Aug 06 18:14:52 ali-P51 systemd[1]: snap.microk8s.daemon-kubelet.service: Service hold-off time over, scheduling restart.
Aug 06 18:14:52 ali-P51 systemd[1]: snap.microk8s.daemon-kubelet.service: Scheduled restart job, restart counter is at 5.
Aug 06 18:14:52 ali-P51 systemd[1]: Stopped Service for snap application microk8s.daemon-kubelet.
Aug 06 18:14:52 ali-P51 systemd[1]: snap.microk8s.daemon-kubelet.service: Start request repeated too quickly.
Aug 06 18:14:52 ali-P51 systemd[1]: snap.microk8s.daemon-kubelet.service: Failed with result 'exit-code'.
Aug 06 18:14:52 ali-P51 systemd[1]: Failed to start Service for snap application microk8s.daemon-kubelet.

As we can see allow-priviliged is not defined for kubelet.
I also tried the --allow-privileged=true instead of --allow-privileged true but it kills my kubelet.

Hi @avarf
The --allow-privileged flag is removed from kubelet on the upstream v1.15 release,  https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#node
I am not sure what your use case is but you may be able to use the privilege escalation from pod security policies:  https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privilege-escalation

Hi @ktsakalozos
Thanks for your answer. I want to set up an EFK stack for centralized logging and some of the components need to be run as privileged.
At the moment they are using:
securityContext:
  privileged: true

I will change it to the allowPrivilegeEscalation and inform you about the results.

I fetched the elasticsearch chart (https://github.com/helm/charts/tree/master/stable/elasticsearch) and changed all the "priviliged" so all the components are look like this now:
        securityContext:
          allowPrivilegeEscalation: true

Now I can install the elasticsearch via helm:
helm install --name elasticsearch elasticsearch \
    --set master.persistence.enabled=false \
    --set data.persistence.enabled=false \
    --namespace logging

But all the elasticsearch pods are failing to launch:
logging       elasticsearch-client-6fb7844b6f-lbtq7             0/1     Init:CrashLoopBackOff   6          9m39s
logging       elasticsearch-client-6fb7844b6f-m4j6k             0/1     Init:CrashLoopBackOff   6          9m39s
logging       elasticsearch-data-0                              0/1     Init:CrashLoopBackOff   6          9m39s
logging       elasticsearch-master-0                            0/1     Init:CrashLoopBackOff   6          9m39s
logging       fluent-bit-mxgpx                                  1/1     Running                 0          27m
logging       kibana-6d9794d46f-q8vmj                           1/1     Running                 0          9m38s

And the only log that I can see is:
Error from server (BadRequest): container "elasticsearch" in pod "elasticsearch-client-6fb7844b6f-lbtq7" is waiting to start: PodInitializing

OR

Error from server (BadRequest): container "elasticsearch" in pod "elasticsearch-data-0" is waiting to start: PodInitializing

Any idea?

Update:
After some investigation, I found out that this is a problem with elasticsearch and pv. I will close this issue.

If anyone else falls here while trying to enable privileged containers on microk8s, the way to do it is to add a PodSecurityPolicy to /var/snap/microk8s/current/args/kube-apiserver:
--enable-admission-plugins="NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodSecurityPolicy"
And restart the service:
sudo systemctl restart snap.microk8s.daemon-apiserver.service


Update logging-and-using-services-in-startup-in-aspnet-core-apps.md

should fix your code highlighting

What kind of change does this PR introduce?

Does this PR introduce a breaking change?

What needs to be documented once your changes are merged?

Thanks!


Question regarding steps and workers

Hello,
First off, thank you for keeping this tool maintained. It is appreciated.
I am having some confusion around the number of step and number of workers. I was testing this and found that with the default 100 steps and a single worker, it takes a very long time to repair a small keyspace. I stopped it after 12 hours on a single node. How can I tweak these values to increase performance yet still retain the advantages of the ranged repair? What would be considered the "default" behavior of Cassandra? 15 steps with a single worker?
I have 12 nodes in a single datacenter and on my largest keyspace it can take upwards of 2 hours to repair a single node. If you throw in the occasional failure, then it can take over 24 hours to repair one of my datacenters. I would like to improve on this.

Also, if I am repairing multiple keyspaces on the same node with the ranged repair, are there over-lapping ranges? Are there any ways to optimize it?

So, in theory, fi you increase the number of workers by 10, you'll decrease the repair time by 90%.  Unfortuantely, it doesn't quite work that way because none of this happens in a vacuum: other nodes are involved, and at some point you get to a place where no matter how many repairs you're running, the other cluster members have no spare threads to dedicate to the repair.  Even before that, the node you're working on will only run as many concurrent repairs as it has threads allocated for that.


Declare db interfaes in x/db and update documentation

Codecov Report

Merging #153 into master will not change coverage.
The diff coverage is 100%.

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


Need to click twice to go back to the previous page

Describe the bug
If you click twice or more on some menu link and after click on browser back button, you will need to click the same number of times to go back to the previous page.
To Reproduce
Steps to reproduce the behavior:

Go to 'Demo App'
Click on 'some link' twice or more
Click on 'browser back button'
See the error

Expected behavior
The expected behavior is to go immediately to the previous page.
Desktop (please complete the following information):

OS: Windows
Browser: Chrome
Version: 68.0.3440.106

@coryhouse Is there any update on this issues , I am facing the same problem .

PRs are always welcome. It would be a great first issue to the project.


fixed main page and navbar overlapping issue

JobSewa Contribution Checklist ✅
fixes #80
Before submitting a pull request, please ensure that you've followed the guidelines below. This will help expedite the review process. Please remember to follow the Code of Conduct.
Important: Starring the repo shows your support and will ensure your contributions are reviewed in a timely manner.

[X ] I have starred and forked the JobSewa repo.
[ X] I have carefully read the instructions for contributing to the project.
[ X] I have created a new page or section and placed it inside the appropriate folder.
[ X] My contributions align with the current project structure and conventions.
[ X] I have included any necessary images in a dedicated folder within assets, ensuring they are compressed and under 500kb.
[X ] All images are in .png format and have been directly uploaded—no external image links are used.
[ X] I understand that the maintainers will review my pull request and provide feedback if necessary.
[ X] I have assigned a reviewer to this pull request.

Thank you for your contribution to JobSewa! We’re excited to work with you.

Great work! Thank you for enhancing our homepage and fixing the overlap issue—looks much better now!


One-time Password for Amazon account

Describe the bug
Amazon account suddenly logged out and asking for OTP.
To Reproduce
Steps to reproduce the behavior:

try to authenticate using integrations

System details

Home-assistant (version):  0.101.3
Hassio (Yes/No): yes

Logs
2019-11-16 02:24:25 INFO (MainThread) [homeassistant.setup] Setting up alexa_media
2019-11-16 02:24:25 INFO (MainThread) [homeassistant.setup] Setup of domain alexa_media took 0.0 seconds.
2019-11-16 02:24:25 INFO (MainThread) [custom_components.alexa_media]
-------------------------------------------------------------------
alexa_media
Version: 2.3.4
This is a custom component
If you have any issues with this you need to open an issue here:
https://github.com/custom-components/alexa_media_player/issues
-------------------------------------------------------------------

2019-11-16 02:24:25 INFO (MainThread) [custom_components.alexa_media] Loaded alexapy==1.3.2

Provide the otp. Check your email as Amazon may have sent it there.

Provide the otp. Check your email as Amazon may have sent it there.

I dont see any options to provide otp

Remove the integration and relogin. It'll ask for the OTP there.

I have removed the integration and reinstalled component and then restarted the home assistant. still not asking for OTP


Invalid use of incomplete type dogecoin make

I got issue like ivalid use of incomplete type doing

sudo make

usr/include/openssl/ec.h:1099:16: note: forward declaration of .ECOSA_SIG [aka struct ECOSA_SIG_st. typedef struct ECOSA_SIG_st ECOSA_SIG: cwrapper.cpp:79:91: invalid use of incomplete type .ECOSA_SIG [aka struct ECOSA_SIG_str if (IBN_mod_mul(sor, ecsig s, rr, order, ctx)) [ ret=-1; goto err;

 In file included from ecwrapper.h:11:0, from ecwrapper.cPP:S: usr/include/openssl/ec.h:1099:16: note: forward declaration of .ECOSA_SIG [aka struct ECOSA_SIG_st. typedef struct ECOSA_SIG_st ECOSA_SIG: [Zs:t2Ng2gSirrILsII).: EIN_binan(8064[0], r92, sig7r);

In file included from ecwrapper.h:11:0, from ecwrapper.cPP:S: usr/include/openssl/ec.h:1099:16: note: forward declaration of .ECOSA_SIG [aka struct typedef struct ERSp75195 ECOSA_SIG;

cwrarir,i=1::z97;2). 32. malg.use of incomplete type .ECOSA_SIG [aka struct ECOSA_SIG_str In file included from ecwrapper.h:11:0, from ecwrapper.cPP:S: usr/include/openssl/ec.h:1099:16: note: forward declaration of .ECOSA_SIG [aka struct typedef struct ECOSA_SIG_st ECOSA_SIG;

akefile:5750: recipe for target .libbitcoinconsensus_la-ecwrapper.lo' failed .e[2]: m [libbitcoinconsensus_la-ecwrapper.lo] Error 1 .e[2]: Leaving directory Vdownloads/dogecoin/sre akefile:6726: recipe for target 'all-recursive. failed .e[1]: m [all-recursive] Error 1 .e[1]: Leaving directory Vdownloads/dogecoin/sre akefile:628: recipe for target 'all-recursive. failed eke: m [all-recursive] Error 1 ,thur.core:/downloads/dogecoin$

Also I have my terminal output sreen
https://pasteboard.co/If9ZltX.png

It would help to know which version you're trying to compile and on what OS, but before that it might be an idea to try 1.14rc1 which is a bit more recent. Can you try the tagged v1.14-rc-1 version please, as in https://github.com/dogecoin/dogecoin/tree/v1.14-rc-1

My OS is

ubuntu-18.04.2-live-server-amd64

and I compiled from

sudo git clone https://github.com/dogecoin/dogecoin

I will try with v1.14-rc-1. Also my OS does not has libdb5.1 but libdb5.3
And some issue about libssl but I have libssl, I made

./configure --with-incompatible-bdb --with-libressl

As found this solution in clossed dogecoin issues

So I tried with provided link but I thinks that's was the same before. The same errors
configure: error: Detected LibreSSL: This is NOT supported, and may break consensus compatibility!
I made ./configure --with-incompatible-bdb --with-libressl
And got the same errors on make
https://pasteboard.co/If9ZltX.png
Waiting for advices
I need to install dogecoin node using wallet futures for be able to accept automated payments

If you're actually using LibreSSL (as in it's been detected correctly), the notice about it being unsupported does really mean it's unsupported. AFAIK it doesn't support some of the cryptographic elements we need, so simply will not work.
If you're using OpenSSL and it's being incorrectly detected, it might be out of date or the install is damaged. Try re-installing the libssl-dev package in that case?

I purgen and installed again libssl-dev
However LibreSSL error is still availiable
https://pasteboard.co/IfiYxhJ.png

Anyone still can help? Any ideas?

It's way easier and safer to just build all dependencies from source with the dependency builder mechanism:
pushd depends
make
popd
./configure --prefix=`pwd`/depends/x86_64-unknown-linux-gnu
make```
You might need to edit the prefix depending on your host triplet.

Okay helped install again libssl-dev
But you should do libssl1.0-dev don't know why but then works fine
If not, that does not working well


Allow to disable the exception listener completely

Hi,
I would like to disable the exception listener completely.
I know that I can replace the core one with some NoopListener but I don't really want to add that to my repository everywhere I use it. Something like this would be much more convenient:
sentry:
    exception_listener: false

The reason why I need this is that in dev environment, I don't want exceptions to be reported to Sentry but that doesn't mean I don't want to use this bundle. I need this bundle because I use captureMessage() etc. on the client at various places in the code. So disabling the bundle in dev is not really an option.
Wdyt?

Setting the DSN to false enables you to reach the same goal; from the README:

Leaving this value empty will effectively disable Sentry reporting.

I don't want to disable reporting. Setting DSN to '' is not an option because I do want to report manually even in dev system for certain things but I want to disable the general exception listener :)

In #156 I'm thinking about dropping the listener on a new major version. The main problem here is that the Client::install() is needed to catch everything, so the listener can go to avoid duplications..

@Toflar
I think you could reach your goad with using the skip_capture option.
if you put a sentry.yml in the dev packages folder and configure it that way
...
    skip_capture:
      - '\Exception'

this should mute all Exceptions since all extend \Exception in the end and the ExceptionListener is using instanceof for testing if exception capturing should be skipped.

lol, nice idea!

Closing this as stale. Also, this is achievable with the new PHP SDK through the error listeners implemented in https://github.com/getsentry/sentry-php/pull/762 and https://github.com/getsentry/sentry-php/pull/788


[fix] Add utf8 encoding to read_text to avoid Windows charmap crash

Hello!
Pull Request overview

Add utf8 encoding to read_text to avoid Windows charmap crash

Details
If I call push_to_hub with a README that uses any non-"standard" character, as is common in my automatically generated model cards in Sentence Transformers, then it'll crash on Windows due to this error: https://stackoverflow.com/questions/14630288/unicodeencodeerror-charmap-codec-cant-encode-character-maps-to-undefined
This is always easily fixed by ensuring that the README is read in utf8.
cc @Wauplin @hlky

Tom Aarsen

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

LGTM!


cherry pick of 28acbdd

Description
manual merge of https://github.com/inmanta/inmanta-core/pull/5934

Processing this pull request

Failed to merge changes into iso4 due to merge conflict. Please open a pull request for these branches separately by cherry-picking the commit that was made on the branch iso5 (git cherry-pick 0359e19f564ab779f53d9ab5b45363ab20d11432).

Merged into branches iso5 in 0359e19f564ab779f53d9ab5b45363ab20d11432

Not closing this pull request due to previously commented issues for some of the destination branches. Please open a separate pull request for those branches by cherry-picking the relevant commit. You can safely close this pull request and delete the source branch.

This branch was not deleted as it seems to still be in use.


Revert #825, because it breaks repos with directories without go code

#825 just broke our travis builds that run dep ensure, because we have directories in our repo without go code. Could the commit be reverted, please?

Yep, sorry about that!

(reverted)

Great!


store.open_data ignores parameter 'bbox'

When requesting a cci-cube for dataset_ID 'esacci.SST.day.L4.SSTdepth.multi-sensor.multi-platform.OSTIA.1-1.r1' the parameter bbox is ignored, and the global extent is returned:
To reproduce:
%matplotlib inline
# CCI Data Store requires asyncio. In order to work in Notebooks, we need to do the following:
import nest_asyncio
nest_asyncio.apply()

from xcube.core.store import find_data_store_extensions
from xcube.core.store import get_data_store_params_schema
from xcube.core.store import new_data_store

store = new_data_store('cciodp')
store

dataset = store.open_data(
    'esacci.SST.day.L4.SSTdepth.multi-sensor.multi-platform.OSTIA.1-1.r1',
    variable_names=['analysed_sst'],
    bbox=[5, 35, 6, 36],
    time_range=['2008-07-01','2008-07-10'])

dataset

dataset.analysed_sst.isel(time=0).plot.imshow(cmap='plasma')

If you do not specify the opener, the cci odp data store will return data as a dataset. For datasets, spatial subsetting is not supported (as they might not have the necessary spatial dimensions). To create a subset, you need to specify to open the data as a cube:
dataset = store.open_data(
'esacci.SST.day.L4.SSTdepth.multi-sensor.multi-platform.OSTIA.1-1.r1',
opener_id='dataset[cube]:zarr:cciodp'
variable_names=['analysed_sst'],
bbox=[5, 35, 6, 36],
time_range=['2008-07-01','2008-07-10'])
(In your example, you only get a white area, so I recommend to use another bounding box to see the effect.)
This does not mean that there is no bug here, though. Calling
store.get_open_data_params_schema() should tell you that you have to use the global bounding box extent, but it doesn't.

Will be solved by #34 .

Aolved by #34


Deferred Service Builder

Right now, the ServiceBuilder creates the client, backend and all else right at the beginning and executes the configured functions directly. This has some implicatations, we do not want:

you can out the ServiceBuilder into an unexpected/unrecommended State by calling a service method multiple times with different callbacks. As these callbacks typically have side-effects, this can lead to inconsistent and unreliable cases–even to race conditions if, for example, an authoring mechanism was initiated.
some of these functions actually conflict and shouldn''t both be called. However right now, we have no way of preventing that.
It is up to the user to call the functions in the right order, which is unreliable and an unnecessary foodgun – especially if we had to change that order.
We can't provide sane defaults – like the longest chain selector or the light client transaction pool, both are the same for all known usages of our node-template – without requiring to the do 1 and cause unexpected side effects.
Certain aspects, like the transaction pool or externality extensions, are actually created during client creation and thus have a hacky API so we can change them after the fact, see #4583.

Instead the pattern should only keep the references to the fns and execute all in one go on .build only. This would allow us to provide defaults, enforce the order in which set up takes place and would ensure any fn is only called once.
Further more this might allow us to clean up the api, so you can have one global builder and then call build_light and build_full on them rather than having to specify two builder...

This is mine now

I got an idea. Let me know if that sounds good:

I realized that what the ServiceBuilder will do after the change is: a. create a struct with whatever you pass to it; b. provide functions to add all the builders; c. and finally allow you to build() the service or client and the queue (which is the relevant part).
The idea of @tomaka  to remove all the builders makes perfect sense to me.
@gnunicorn  told me we should actually drop the concept of client.
This makes me conclude that I can probably drop the entire ServiceBuilder and replace it by a few functions (build_service, build_for_import, build_client). This will also simplify greatly the typing.

So I have to drop it for now to focus on cumulus... I did some progress as I found out that the builder itself don't actually help much and can be entirely removed instead of making it defer the calls to the with_* methods.
This is actually more flexible AND it doesn't reduce at all the readability nor the simplicity in the service.rs files that were using it.

I suppose the only way to actually reduce the code for it would be by using something like derive_builder.

To give my two cents: I don't even know why there is a Service struct at all.
The Service as it exists is a complete pot-pourri of multiple design attempts.
As far as I know, it was initially supposed to be the container that contains all the sub-components, and you would create in a kind-of-declarative way with a macro.
To me it was supposed to coordinate the various components of Substrate (#2536), but that is obviously not the case, as these components "coordinate each other" in a spaghetti-ish way at the moment. Actually reworking that without rewriting Substrate is too big of a task at this point.
Now, almost the only thing that sc-service does is plug the Legos together at initialization. Once initialization is done, the only reason why the service exists at all is to pass to the informant and to detect whether essential tasks have crashed (both of which can be very easily implemented differently).

Hey, I'm gonna be taking over this issue I think. I've made a new PR: #6309.

@gnunicorn do you think you could assign this to me please?

I definitely agree with @tomaka that the Service shouldn't really exist and that it would be much better to have a few smaller structs that do it's job.
I've been using wgpu-rs a fair bit recently, and I think it has a really nice API for constructing complex things (swap chains, rendering pipelines etc compared to our import queues and finality proof providers). It puts everything in the top level of the crate so you don't have to go looking in a specific module for what you want. I think it would be good to have a kind of 'substrate prelude' crate that does the same thing.
It also uses 'descriptor' structs for a lot of the initialization, which would be a lot better than the following, which is in the current PR:
sc_service::build(
	config,
	client,
	backend,
	task_manager,
	keystore,
	None,
	Some(select_chain),
	import_queue,
	Some(finality_proof_request_builder),
	Some(finality_proof_provider),
	transaction_pool,
	(),
	Some(remote_blockchain),
	background_tasks,
	None,
	Box::new(|_| ()),
	String::new()
)

I am not generally opposed to getting rid of service, but one important distinction needs to be made and seen here: substrate is not a library but rather a framework of crates, many of which are optional but can – under specific conditions – work together nicely. Just think of all different consensus authoring mechanism.
Secondly, this also means it isn't being used directly, but rather plugged together by third party developers to their needs – and this is exactly where what is currently sc-service comes in, as it provides tooling to plug things together in an easier, more reliable and convenient way than if you had to do it all by yourself. But surely you can do everything that sc-service does without it – no other crate imports it anymore (other than for testing) and relies upon it, only on APIs defined in sc-api.
Thus, the way I currently think of it going forward is less of just expose everything libraries, but a tokio-0.2-meta-crate, where features becomes available through setting them in Cargo.toml, guarding all potential internal semver-breakage and offer convenience functionality would help the developers build the chain they want.

So I've been thinking about the systems that we can replace the service builder with, and I've come up with two that I think are alright.

The first is to remove the service builder completely, and have the user build the components needed to call the sc_service::build function up with lots of let bindings, as I mentioned in https://github.com/paritytech/substrate/issues/4587#issuecomment-641302414. I've created a branch for this here: https://github.com/paritytech/substrate/pull/6557. This is appealing to me because, as it's defined entirely in pretty simple code, it's super customizable and a lot clearer than the service builder was. It has some downsides though:

1.a. There's no way to make sure the full node service and light node service builds are compatible, meaning that someone could try using a BABE block importer for the full node and an AURA block importer for the light node and they either just wouldn't work together or, worse, cause something weird to happen. This was a potential problem with the service builder as well, but it'd be nice to solve it, ideally by having a single build system that you can specialize into full node/light node after you've defined everything.
1.b. The generics can get very very complicated, as lots of things depend on a client type, which itself depends on the block type, etc. There are ways around this problem though:
1.b.i. We setup in type definitions in the node/node-template service.rs files. This works, but it's a bit too verbose for me, and I'd rather find a way where end-users don't have to worry about those definitions.
1.b.ii. We create a macro that takes a Block, RuntimeApi and Executor and generates the types for us. I'd be happy with this but it might go against our goal of trying to avoid macros as much as possible.
1.b.iii. We do this t:rick

pub trait PreludeT {
	type FullClient;
	type LightClient;
	type FullBackend;
	...
}

pub struct Prelude<Block, RuntimeApi, Executor>(std::marker::PhantomData<(Block, RuntimeApi, Executor)>);

impl<Block, RuntimeApi, Executor> PreludeT for Prelude<Block, RuntimeApi, Executor> {
	type FullClient = TFullClient<Block, RuntimeApi, Executor>;
	type LightClient = TLightClient<Block, RuntimeApi, Executor>;
	type FullBackend = TFullBackend<Block>;
	...
}

which can then be used like:
type Prelude = sc_service::Prelude<MyBlock, MyRuntimeApi, MyExecutor>;

fn whatever() -> <Prelude as PreludeT::FullClient> {
    ...
}

This would be a lot easier with Inherent associated types.

A second idea that I had in this conversation: https://github.com/paritytech/substrate/pull/6557#discussion_r449590172 was to reimagine the service builder as a Builder trait with type definitions for the different components. You'd implement this trait for your own zero-sized-type and would be able to call build_full/build_light/build_ops on it. I've got an implementation of this here: #6600. This solves 1.a because the component types are intended to work for both full and light nodes, and 1.b because if needed, you can retrieve the types from the Builder trait. This looks something like the following:

pub struct Builder;

impl sc_service::builder::Builder for Builder {
	type Block = Block;
	type RuntimeApi = RuntimeApi;
	type Executor = Executor;
	type TransactionPoolBuilder = BasicPoolBuilder;
	type BlockImportBuilder = GrandpaBlockImportBuilder<Self::SelectChainBuilder>;
	type ImportQueueBuilder = AuraImportQueueBuilder<Self::BlockImportBuilder>;
	type FinalityProofProviderBuilder = GrandpaFinalityProofProviderBuilder;
	type SelectChainBuilder = LongestChainBuilder;
	type RpcExtensions = NoRpc<Self>;
}

This would work really well in the simple cases, where you have a defined builder type for everything you want.
2.a. The main problem with this is that we're defining things in terms of types, not code. While it's pretty extendible as you can replace any of the types or the build_x functions with your own implementations, the whole thing might still be a bit too strict. If you wanted to use your custom import queue type in this builder, you'd have to create your your own builder type and implement ImportQueueBuilder for it. This could be difficult or impossible, as the ImportQueueBuilder functions have a fixed set of arguments (i.e. a client, a task manager, ..) that are passed to them. It'd be hard to change this so that you can pass in a different set of arguments instead.
Any feedback on these ideas would be much appreciated!

There's also nothing stopping us from removing the service builder now, then adding my builder trait later.

@seunlanlege @joshua-mir I'm interested in hearing your thoughts as well!

There is a pretty huge hack in sc-network at the moment.
sc-network needs to know the list of protocols that the node supports. Normally, one would pass that list as part of NetworkConfiguration, but because of the general structure of the code we just pass an empty list of protocols, and a hacky register_notifications_protocol method is provided that lets you add more protocols even after the network has actually started.
It is completely possible right now that sc-network connects to the bootnodes, then doesn't do everything that it is supposed to do because the rest of the Substrate codebase hasn't registered its protocols yet.

I'm not asking for this problem to be solved, but I would like people to be aware that this situation exists, and that we need some structure that would make it possible to solve this problem eventually.

Can we not just almost entirely drop the service builder and just have normal function that we call to initialize the service? Something like:
fn build() -> TaskManager {
    start_transaction_pool;
    do_something_else;

}

Did you tried something like this?
I think we need to get rid off these traits or whatever that try to force a certain structure of the service. In the end the service is just futures that are spawned and that is something we don't need to combine in struct.

I'm going to remove the service builder now, and if we want to go through with the builder trait later, we'll do that.

We can probably go ahead and close this issue now that #6557 has been merged.


 Is there a way to limit the size of the thumbnails?
To reduplicate problem: open game view for "Far Cry 5 Gold Edition".

As the dimensions of the thumbnails differ for every game, it is difficult to limit the size of the thumbnails to a set value, however, I attempted an alternate fix, by changing the window size to match the size of the thumbnail by creating a new window. Please come back to me if this doesn't feel like the best solution. Thanks!

I have further made it so it now checks for the original resolution of the thumbnail, and scales it down if too big.


v2.5 build fails without Vivado license for RFSoC

Hi,  Due to now building all Overlays for all PYNQ platforms, the v2.5 PYNQ build requires Vivado with a license for ZU7EV and RFSoC (ZU28).  This will prohibit web pack users from building v2.5 for Z1/Z2, Ultra96.

My partial bad, I do not actually have web pack, I have a different license which apparently has different levels of "free" enabled which caused this issue for my set of licenses.
ZU7EV is supported and RFSoC is not but RFSoC is not built along with the Z1,Z2, ZCU104 boards.

Webpack license supports the following for 2019.1:
https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/xilinx2019_1/ug973-vivado-release-notes-install-license.pdf

Not an issue for web-pack at all, just an issue for me which is resolved.


Carthage error: Scheme Pods-Example-SwiftFontName is not currently configured for the build action

Hi, i am trying to install it via carthage and im getting this:
A shell task (/usr/bin/xcrun xcodebuild -workspace /MyProject/Carthage/Checkouts/SwiftFontName/Example/Example.xcworkspace -scheme Pods-Example-SwiftFontName -configuration Release CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES -showBuildSettings) failed with exit code 66:
xcodebuild: error: Scheme Pods-Example-SwiftFontName is not currently configured for the build action.

Sorry, for late reply! I missed your issue.
Today, I update the build. 3.0.0. Please try with it.


[Bug] [transforms] [SQL] SQL engine conditional query error

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
SQL engine conditional query error, when using the 'where name='abc' string equal to the query, it cannot take effect because of a logical judgment error.
SeaTunnel Version
dev
SeaTunnel Config
env {
  job.mode = "BATCH"
  job.name = "this_is_a_job_name"
  parallelism = 2
}

source {
  FakeSource {
    result_table_name = "fake"
    row.num = 10
    string.template = ['abc','d~f','hi']
    int.template = [20, 21]
    schema = {
      fields {
        name = "string"
        age = "int"
      }
    }
  }
}

transform {
    sql {
      source_table_name = "fake"
      result_table_name = "sql"
      query = "select * from "fake" where name = 'abc' "
    }

}

sink {
  Console {
     source_table_name = "sql"
     username = "seatunnel=2.3.1"
        password = "$a^b%c.d~e0*9("
    }
}

Running Command
bin/seatunnel.sh

Error Exception
query error

Zeta or Flink or Spark Version
No response
Java or Scala Version
No response
Screenshots
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I rember this can work before, do we know which pr has bug?

I rember this can work before, do we know which pr has bug?

In version 2.3.5, this config can work.
env {
  job.mode = "BATCH"
  job.name = "this_is_a_job_name"
  parallelism = 2
}

source {
  FakeSource {
    result_table_name = "fake"
    row.num = 10
    string.template = ["abc","d~f","hi"]            ----  here need double quota
    int.template = [20, 21]
    schema = {
      fields {
        name = "string"
        age = "int"
      }
    }
  }
}

transform {
    sql {
      source_table_name = "fake"
      result_table_name = "sql"
      query = "select * from "fake" where name = 'abc' "
    }

}

sink {
  Console {
     source_table_name = "sql"
     username = "seatunnel=2.3.1"
        password = "$a^b%c.d~e0*9("
    }
}

But if the string.template value use single quota, it will get same issue.

Yes, I have identified this issue, which can also occur here. I will try to fix it
/ bin/seatunnel.sh -c <this_config_file>
-i jobName='this_is_a_job_name'
-i resName=fake
-i rowNum=10
-i strTemplate=['abc','d~f','hi']
-i nameType=string
-i nameVal=abc
-i username=seatunnel=2.3.1
-i password='$a^b%c.d~e0*9('
-m local

Yes, I have identified this issue, which can also occur here. I will try to fix it
/ bin/seatunnel.sh -c <this_config_file>
-i jobName='this_is_a_job_name'
-i resName=fake
-i rowNum=10
-i strTemplate=['abc','d~f','hi']
-i nameType=string
-i nameVal=abc
-i username=seatunnel=2.3.1
-i password='$a^b%c.d~e0*9('
-m local

Hi, i noticed you using the variable replacement.
now there has a known issue, the variable value can't has space.
like -i nameVal='a bc' , then we will only receive nameVal=a.
we can add quota on start script, but in seatunnel.sh when it run java xxxx -i  command, it will lose the quota.   FYR.

Yes, I have identified this issue, which can also occur here. I will try to fix it
/ bin/seatunnel.sh -c <this_config_file>
-i jobName='this_is_a_job_name'
-i resName=fake
-i rowNum=10
-i strTemplate=['abc','d~f','hi']
-i nameType=string
-i nameVal=abc
-i username=seatunnel=2.3.1
-i password='$a^b%c.d~e0*9('
-m local

Hi, i noticed you using the variable replacement. now there has a known issue, the variable value can't has space.
like -i nameVal='a bc' , then we will only receive nameVal=a. we can add quota on start script, but in seatunnel.sh when it run java xxxx -i  command, it will lose the quota. FYR.

link https://github.com/apache/seatunnel/issues/6840


[BUG] [Segment Replication] Possible data loss (or inconsistencies) during primary relocation and noticed issues with performSegRep within Peer Recovery code

Describe the bug
During relocation, before starting relocation handoff, in the IndexShardopearionPermits#blockOperations, all permits are acquired and then relocation handoff is performed. Below is the code for the same -
<E extends Exception> void blockOperations(final long timeout, final TimeUnit timeUnit, final CheckedRunnable<E> onBlocked)
    throws InterruptedException, TimeoutException, E {
    delayOperations();
    try (Releasable ignored = acquireAll(timeout, timeUnit)) {
        onBlocked.run();
    } finally {
        releaseDelayedOperations();
    }
}

With #5344, we have changed the code here to allow force segment replication to happen. However, with this change we have also made the code from sync & blocking to async & non-blocking.  To better explain this, refer the code before the PR. The runnable that is passed as the 2nd argument to the blockOperations gets executed until the last line before the control goes back to the caller of the blockOperations method. There is a transport network call for handOffPrimaryContext also waits for the response and then only proceeds to the rest of handoff process. Post the PR, for seg rep use cases, we have an async step listener. Now what happens is that once the async execution starts, we come out of the onBlocked.run() and go to the releaseDelayedOperations. This leads to indexing operation played on older primary with older primary hold primaryMode as true in parallel with performSegRep happening which will eventually change the primary mode on the new primary from false to true. There are multiple cases of how source and target can see primary mode during a lifetime of write request which is scary.
Before the PR -
public void relocated(final String targetAllocationId, final Consumer<ReplicationTracker.PrimaryContext> consumer)
    throws IllegalIndexShardStateException, IllegalStateException, InterruptedException {
    assert shardRouting.primary() : "only primaries can be marked as relocated: " + shardRouting;
    try (Releasable forceRefreshes = refreshListeners.forceRefreshes()) {
        indexShardOperationPermits.blockOperations(30, TimeUnit.MINUTES, () -> {
            forceRefreshes.close();
            // no shard operation permits are being held here, move state from started to relocated
            assert indexShardOperationPermits.getActiveOperationsCount() == OPERATIONS_BLOCKED
                : "in-flight operations in progress while moving shard state to relocated";
            /*
             * We should not invoke the runnable under the mutex as the expected implementation is to handoff the primary context via a
             * network operation. Doing this under the mutex can implicitly block the cluster state update thread on network operations.
             */
            verifyRelocatingState();
            final ReplicationTracker.PrimaryContext primaryContext = replicationTracker.startRelocationHandoff(targetAllocationId);
            try {
                consumer.accept(primaryContext);
                synchronized (mutex) {
                    verifyRelocatingState();
                    replicationTracker.completeRelocationHandoff(); // make changes to primaryMode and relocated flag only under mutex
                }
            } catch (final Exception e) {
                try {
                    replicationTracker.abortRelocationHandoff();
                } catch (final Exception inner) {
                    e.addSuppressed(inner);
                }
                throw e;
            }
        });
    } catch (TimeoutException e) {
        logger.warn("timed out waiting for relocation hand-off to complete");
        // This is really bad as ongoing replication operations are preventing this shard from completing relocation hand-off.
        // Fail primary relocation source and target shards.
        failShard("timed out waiting for relocation hand-off to complete", null);
        throw new IndexShardClosedException(shardId(), "timed out waiting for relocation hand-off to complete");
    }
}

After the PR -
final StepListener<Void> segRepSyncListener = new StepListener<>();
performSegRep.accept(segRepSyncListener);
segRepSyncListener.whenComplete(r -> {
    /*
     * We should not invoke the runnable under the mutex as the expected implementation is to handoff the primary context via a
     * network operation. Doing this under the mutex can implicitly block the cluster state update thread on network operations.
     */
    verifyRelocatingState();
    final ReplicationTracker.PrimaryContext primaryContext = replicationTracker.startRelocationHandoff(targetAllocationId);
    try {
        consumer.accept(primaryContext);
        synchronized (mutex) {
            verifyRelocatingState();
            replicationTracker.completeRelocationHandoff(); // make changes to primaryMode and relocated flag only under
                                                            // mutex
        }
    } catch (final Exception e) {
        try {
            replicationTracker.abortRelocationHandoff();
        } catch (final Exception inner) {
            e.addSuppressed(inner);
        }
        throw e;
    }
    listener.onResponse(null);
}, listener::onFailure);

To Reproduce
Steps to reproduce the behavior:
Currently the performSegRep call itself was timing out. If we can make it work, we can follow below steps -

Create index

curl -X PUT "localhost:9200/test-index?pretty" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0,
    "replication.type" : "SEGMENT"
  }
}
'

Start indexing lot of docs in parallel and in order of 1000s.

for i in {1..1000}
do
   curl --location --request POST "localhost:9202/test-index/_doc" \
    --header 'Content-Type: application/json' \
    --data-raw "{
      \"name\":\"abc${i}\"
    }"
    echo "\n"
done

Start primary relocation -
(from opensearch-node1 to opensearch-node2)

curl -XPUT localhost:9201/test-index/_settings -H 'Content-Type: application/json' -d '
{
  "index.routing.allocation.include._name": "opensearch-node2"
}'

Expected behavior
A clear and concise description of what you expected to happen.
Plugins
Please list all plugins currently enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):

OS: [e.g. iOS]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Looking into it

Created a draft PR above (needs stabilized integration test). @ashking94 : You can incorporate changes in PR above to unblock you from integration. Let me know if you see any issue.

Closing this as fix is merged into main and backported to 2.x


../../.. beyond root directory fails

When opening a file from a compiled binary, if the file path contains more ../../.. combinations than necessary (taking the path into "negative territory" as far as / is concerned), the open will fail. As an example, consider the following code:
#include <stdio.h>

int main(int argc, char **argv)
{
	FILE *file;

	if ((file = fopen("../../../../../../../home/Sagan/gcctest/myinclude.h", "r")) == NULL)
	{
		printf("Unable to open file\n");
	}
	else
	{
		printf("File opened\n");
		fclose(file);
	}

	return 0;
}

This code prints "Unable to open file" even though the file /home/Sagan/gcctest/myinclude.h exists (when run from /home/Sagan/gcctest, or any of its parents).
Interestingly enough, cat ../../../../../../../home/Sagan/gcctest/myinclude.h does work when run from /home/Sagan/gcctest. This implies that bash does some pre-processing to the path before actually passing the parameter to the executable.
I also tested the same code using cygwin and Linux Mint, and in both cases the file could be opened.
This issue currently causes a build of Qt 5.7.0 to fail (for some reason the configuration adds a lot of ../../.. to the include files).

Mingw GCC is native Windows program so it doesn't understand UNIX paths like /home/Sagan/gcctest/myinclude.h. To build Qt you must use the shortest path for build directory. This issue is well known and we can't do anything here


Provide unified python interface to Fluent

📝 Description of the feature
I am thrilled to see the addition of PyFluent to the latest Fluent release which stands great chance of replacing all of my cobbled together journal scripts which are not really that readable (especially the parts where I do arithmetic). Python is a great wrapper for all of this functionality and I have already found the meshing workflow to be easier to automate with the python-based workflow scripts.
I looked through the documentation and example for the mixing elbow but to my disappointment I saw the following code
if solver.get_fluent_version() == "22.2.0":
    solver.setup.materials.copy_database_material_by_name(
        type="fluid", name="water-liquid"
    )
else:
    solver.setup.materials.database.copy_by_name(type="fluid", name="water-liquid")

This is the part which is already a huge turn-off for me when doing journal scripting, i.e. checking that each of my command works after upgrading to the latest fluent version (in the end I mostly stay with the version for which I created the journal file or use the "set-tui-version" command but even that seems like a hack). Unfortunately, it seems that there is no real interest in keeping a stable tui menu structure and it seems this unstable syntax is mirrored in the python implementation. This is odd and in stark contrast to what the rest of the (software) industry is trying to achieve, having each new release of fluent break existing scripts (making either the scripts useless or putting a deterant on upgrading to the latest version).
There is an opportunity here to fix this by establishing a proper API to fluent from within the python layer and I would love to see this realised.
💡 Steps for implementing the feature
Taking the same example again:
if solver.get_fluent_version() == "22.2.0":
    solver.setup.materials.copy_database_material_by_name(
        type="fluid", name="water-liquid"
    )
else:
    solver.setup.materials.database.copy_by_name(type="fluid", name="water-liquid")

It would be more sensible to have an internal implementation within the PyFluent core module as follows:
# within PyFluent core module
class PyFluent: # well, where ever this is implemented, I did not check
...
    def copy_material_by_name(self, type, name):
        if solver.get_fluent_version() == "22.2.0":
            solver.setup.materials.copy_database_material_by_name(type, name)
        elif solver.get_fluent_version() == "22.1.0":
            # version 2022R1 implementation
        elif solver.get_fluent_version() == "21.2.0":
            # version 2021R2 implementation
        # etc ...
        else:
            solver.setup.materials.database.copy_by_name(type, name)

This will allow the user to have a unified call in their script (regardless of the fluent version) as the following:
solver.setup.copy_material_by_name(type="fluid", name="water-liquid")

In this way, scripting in Fluent will be exponentially more powerful (in my view). This will also allow to have a sensible version numbing of the PyFluent module, i.e. once a stable version and API is establised and PyFluent is in version 1.x.x, any code breaking changes can be communicated through an increment in the major version number and this can be independent from Fluent's release cycle. Otherwise PyFluent, at least to me, only adds syntactic sugar but no usefulness, if it does simply mirror existing functionality (journal scripts). I can see an interest to integrate that across ANSYS products (and hence to have a python implementation) but then again the above is even more so important if users will start using Fluent as part of their PyANSYS scripts. If each release of fluent is breaking their script, how are they supposed to know what is going wrong? Fluent needs a unified way of scripting, PyFluent has real potential to achieve that and I would love to see this happening.
🔗 Useful links and references
No response

Thanks for the great feedback!
Regarding your point about the settings interface versioning, you are right that this is not the way it should be.  This interface is not yet a released Fluent feature and one reason for that is we've not completed the work to facilitate making it backwards compatible from release to release.  So, this will come when the settings interface is a released feature for Fluent.
In the meantime, the PyFluent team decided that it was helpful to allow using it with the PyFluent library sooner rather than later because it already addresses many of the pitfalls of using the released tui interface and it allowed us to get some early feedback about the interface.  So, please feel free to share any additional feedback you have with us.

Hi Dan, great to hear this is already on your list and yes, I understand you are still pre 1.x.x so I am assuming (and hoping) the interface / api will still change. PyFluent is definitly something I'll be using quite a bit it seems and this will integrate nicely with other tools such as pytecplot or paraview. Cheers!

@tomrobin-teschner
this is from my prior conversation with @dnwillia-work :
"
I mandated that for tests all those things are wrapped and in separate utility functions.
However, doing that means doing the APIs job, so it's moot whether it's right to do it.
But the tests would get very messy otherwise.
"

not just the tests, actual production scripts would look equally messy with if statements added for each new release (potentially). A clean interface would go along way here. I can see that this is not a trivial task with fluent's current tui API but worthwhile to have a think about if this could be addressed, especially since a complete new API is developed from scratch

Sure, I'm not saying that production code wouldn't also look messy but I'm not promoting the idea of trying to do that ("actual production scripts... with if statements added for each new release").
"Customers who are doing large scale re-writes (from Scheme) now must start with TUI API IMHO. Anyone writing small verticals can use settings API and expect some rewrite later."


Create API for clients, drivers, login according to database stored in the cloud

Working on socket.io, maps

😎😎😎


Apple Magic Keyboard Windows 10 - Remap Shortcut to Key - Delete

Working with an Apple Magic Keyboard on Windows used to be great, except for the last couple of years, as there is no easy way to get it supported on Windows 10.
The key that is desperately missing is the DELETE.
Now Powertoys have a great tool remap key, shortcut, but it won't work for the combination that is common on MAC as you need to map a Shortcut to a Key.
WIN R + BACKSPACE -> DELETE
Please enable this function to map a SHORTCUT to a KEY.

for that, have you tried Fn-Backspace?

@carlos-segundo i look at this keyboard and it has a delete key where i'd expect.  If it is an older model, did you try Fn-Backspace?
.
It just doesn't work?
@arjunbalgovind fyi

I think in general we have got quite a few requests for remapping shortcut to key and vice versa so we should look at supporting this for v1 since there seem to be many use cases for it. That said I don't know much about this particular keyboard, but if the scenario requires remapping Fn+Something to another key, we won't be able to do that at any point.

My input was for the Model A1644.
And the only reason why we need to use remap shortcut to key, is because one cannot get easily the correct keyboard driver out of the bootcamp software as it used to be a few years ago. The FN key will only work with a keyboard driver.

@sakariya / @arjunbalgovind this is a totally fair request for small keyboards.  anything really preventing this?  possible for v1?

I think based on the feedback we should be support shortcut to key and key to shortcut for v1. Don't see anything that would prevent this. We may possibly need a breaking change for certain scenarios so that everything becomes compatible so we would need some "saved remap migration on update" logic whenever we introduce that.

@crutkas I am not aware of this project and I don't know you guys. Can you please confirm this once?

really sorry about that @sakariya, @crutkas was meaning to tag me!

@crutkas I am not aware of this project and I don't know you guys. Can you please confirm this once?

@crutkas , yes I think this is fair. https://github.com/microsoft/PowerToys/issues/3290 here's the tracking issue for key to shortcut / shortcut to key

Eek!!!  Sorry!

Tracking in #3290


Catch ActiveUtils::ResponseError during CanadaPostPWS receipt request

Right now we do not trap the ActiveUtils::ResponseError here.
We should trap this and return an ActiveShipping::ResponseError instead.

This one is a little tricky just because parse_shipment_receipt_response doesn't return a CPPWS response but rather a simple Hash so we can't use error_response like the other rescue statements.


hope add data mining with the pytorch and scikit-learn ！

Make sure these boxes are checked before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[ ] I have checked the issue tracker for the same issue and I haven't found one similar.

Superset version
0.999dev
Expected results
add data mining with the pytorch and scikit-learn！

As superset is a view layer, should not those things be done in advance ? Like you have a data pipeline that processes data through models built from scikit or pytorch, writes that to db. Superset can then  connect to the datasource.

Hope add data mining with the pytorch and scikit-learn like Orange3！


The loop keyword argument is deprecated. Please report issue to the custom component author.

2021-12-18 20:11:37 WARNING (MainThread) [homeassistant.helpers.frame] Detected integration that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report issue to the custom component author for miwifi using this method at custom_components/miwifi/core/luci.py, line 97: with async_timeout.timeout(self.timeout, loop = self._loop):
2021-12-18 20:11:39 WARNING (MainThread) [homeassistant.helpers.frame] Detected integration that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report issue to the custom component author for miwifi using this method at custom_components/miwifi/core/luci.py, line 324: with async_timeout.timeout(self.timeout, loop = self._loop):

Fixed in version https://github.com/dmamontov/hass-miwifi/releases/tag/v1.3.0


Spike: conventions for file collections

ConfigurableFileCollections (CFCs) also need finalization and convention management.
Issue: #21752

This has been superceded by #21752


HHH-8916 - Fix SQL Server LimitHandler parsing to work with CTE queries.

https://hibernate.atlassian.net/browse/HHH-8916

@vladmihalcea If you have time to give this a go, I'd appreciate any feedback.

Applied upstream, thanks


NameError: global name 'HOST_CHECK_LOOP_TIME' is not defined

Hi there,
When I try to start the Docker containers, I get the following error:
[root@srv rancher-lets-encrypt]# docker-compose up
WARNING: The Docker Engine you're using is running in swarm mode.

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use the bundle feature of the Docker experimental build.

More info:
https://docs.docker.com/compose/bundles

Recreating rancherletsencrypt_rancher-lets-encrypt_1
Starting rancherletsencrypt_letsencrypt-nginx_1
Attaching to rancherletsencrypt_letsencrypt-nginx_1, rancherletsencrypt_rancher-lets-encrypt_1
rancher-lets-encrypt_1  | t find an Environment variable set.
rancher-lets-encrypt_1  | 'CATTLE_URL'
rancher-lets-encrypt_1  | Traceback (most recent call last):
rancher-lets-encrypt_1  |   File "/python/rancher.py", line 393, in <module>
rancher-lets-encrypt_1  |     service.check_hostnames_and_ports()
rancher-lets-encrypt_1  |   File "/python/rancher.py", line 362, in check_hostnames_and_ports
rancher-lets-encrypt_1  |     print "Sleeping during host lookups for {0} seconds".format(HOST_CHECK_LOOP_TIME)
rancher-lets-encrypt_1  | NameError: global name 'HOST_CHECK_LOOP_TIME' is not defined

My letsencrypt.env:
[root@srv rancher-lets-encrypt]# cat letsencrypt.env
DOMAINS=srv.example.com
CERTBOT_WEBROOT=/var/www
<EMAIL_ADDRESS>RENEW_BEFORE_DAYS=14
LOOP_TIME=300
# Staging = True will get you a cert with the CA Fake, while Staging = False will use production Let's Encrypt to get the Let's Encrypt V3 CA.
STAGING=False
HOST_CHECK_PORT=80
HOST_CHECK_LOOP_TIME=10

As you can see, the HOST_CHECK_LOOP_TIME variable is set. Do you have any ideas why this error happens?
Thanks!
Ragards,
Philip

The entire point of this project is to enable LE cert management with Rancher ... why are you using Docker Compose directly instead of letting Rancher manage things for you?

Well this point is clear, but I tried to run it manually in order to check if runs before I try to add it to Rancher itself.
Sorry for the question but what's the easiest way to add this service to my Rancher installation? Could you provide me a link to a manual page?
Thanks
Regards,
Philip

Sorry my bad. It seems to work after importing the service over rancher CLI.
rancher up -d -s LetsEncrypt

I also had to add
ports:
    - 80:80/tcp

to the docker-compose.yml file so the nginx is reachable from the internet. Should this be like this?

To make it accessible, yes. The idea is that Nginx (and the rest of your stack) would be behind a load balancer and wouldn't be public otherwise.

https://github.com/tozny/rancher-lets-encrypt/blob/master/traffic-manager/docker-compose.yml#L3 shows us using the Rancher load balancer to receive internet traffic on port 80. Then on https://github.com/tozny/rancher-lets-encrypt/blob/master/traffic-manager/docker-compose.yml#L9 shows us directing traffic from server:80/.well-known/acme-challenge/ directory to the lets-encrypt-nginx container for verification. The load balancer manages all open ports on the internet and serves as a reverse proxy to the correct container managed by Rancher.


fix: typo on lpadder

Hey, just wanted to fix this since it's not an I but a l - I know it's confusing :D
Since "lpadder" comes from the word "launchpadder", it kinda makes sense but anyway it's not a big deal.
Thanks you for adding my project though!

lmao
that's good to know, thanks for the correction!


ZoneInfo Error

Traceback (most recent call last):
File "zoom-recording-downloader.py", line 27, in
from zoneinfo import ZoneInfo
ModuleNotFoundError: No module named 'zoneinfo'
Fixed by editing line 27:
from backports.zoneinfo import ZoneInfo

Zoneinfo was introduced in Python3.9. If you can get it to work with backports, it means you're likely using a version of python which is version 3.8 or older.
https://devguide.python.org/versions/
You'll notice that python 3.9 is very old and only gets security updates now (though only until 2025-10). And python 3.8 is end-of-life in 2024-10 (which is in only 3 months at the time I'm writing this).
I would respectfully suggest that you update the version of Python you're using, as the patch you're proposing only benefits outdated or EOL versions of Python.
My vote is to Nak your patch and close this issue.


feat: port data.rat.init

All the constructions are in Std.Data.Rat, we only add the notation.

how do I add nolints?

You should just add a module doc. It can be a one-liner if you don't have anything to say.

bors merge


Add function for getting Terraform working directory

It would be great to have a get_terraform_dir() function which returns the path to the directory in which the Terraform commands are run (it is usually something like ./.terragrunt-cache/xxx/yyy).
I would need this value in a locals block for constructing relative paths. I tried run_cmd("pwd") but that actually seems to be equivalent to get_terragrunt_dir(). Is there perhaps another way of obtaining this already?

It seems that the WorkingDir entry in terragrunt-info does return what I would need, however, I can't really seem to find a way to get this value in a terragrunt.hcl file.

What's the specific use case here? I believe path_relative_to_include() is what you need, as that should get you what WorkingDir gives you (the counterpart being path_relative_from_include(). Although that does not line up with the .terragrunt-cache/ dir you mentioned, so not sure this is what you want?

I don't think that would work because my setup is roughly as follows:
~/.terragrunt/commons.hcl
locals {
  ...
  working_dir = ".terragrunt-cache/config_hash/module_hash"
}
...

~/Projects/some-project/terragrunt.hcl
include "commons" {
  path = pathexpand("~/.terragrunt/commons.hcl")
}

The commons.hcl file essentially contains my common provider and remote state configuration (and a few other things) which I then simply include in all of my projects. What I need is the relative path from terragrunt_dir() to the WorkingDir or an absolute path to WorkingDir (and not the path between ~/.terragrunt/commons.hcl and ~/Projects/some-project/terragrunt.hcl).
The specific use case is that I want to modify module sources in Terraform files before running Terraform (I do that via a before_hook) so that instead of pointing to a remote source they point to a local path, for which I need to find out the relative path between the local checkout of a module source and the WorkingDir. I know the paths to the local module sources but I can't really get the WorkingDir via any of the existing functions in Terragrunt, I think.
As said, if I run terragrunt terragrunt-info then I get something similar to this:
{
  "ConfigPath": "/home/user/Projects/some-project/terragrunt.hcl",
  "DownloadDir": "/home/user/Projects/some-project/.terragrunt-cache",
  "IamRole": "",
  "TerraformBinary": "terraform",
  "TerraformCommand": "terragrunt-info",
  "WorkingDir": "/home/user/Projects/some-project/.terragrunt-cache/EmQr60XXXCYgt9Qfni-4fHZU/F62jYYYnH_hVGDEN2pTYiMsg"
}

where WorkingDir is exactly what I would need, just inside ~/.terragrunt/commons.hcl.

I just noticed that the working directory is sometimes the same as terragrunt_dir() (in particular when there are no remote configurations specified, see https://terragrunt.gruntwork.io/docs/features/caching), which makes this feature even more important.

my usecase would be to access an image file to use in the gitlab_group resource as avatar with a relative path so that the path stays the same for all developers. the file is located in the project root directory in an assets folder.
file structure reduced to the relevant files/directories:
├── .terraform.d
│   └── .terragrunt-cache
│       └── accounts
│           └── production
│               └── gitlab
│                   └── SgKLvr5BkpwOBF27O_KMq4ZY5O0
│                       └── JFRlN212e_19ZPmP_aI4z1wvWck
│                           ├── .terragrunt-source-manifest
│                           ├── .terragrunt-source-version
│                           ├── gitlab
│                           │   ├── .terraform
│                           │   ├── .terraform.lock.hcl
│                           │   ├── .terragrunt-module-manifest
│                           │   ├── .terragrunt-source-manifest
│                           │   ├── README.md
│                           │   ├── _backend.tf
│                           │   ├── main.tf
│                           │   ├── terragrunt.hcl
│                           │   └── variables.tf
├── accounts
│   └── production
│       └── gitlab
│           └── terragrunt.hcl
├── assets
│   └── gitlab
│       └── logo.png
└── modules
    └── gitlab
        ├── main.tf
        └── variables.tf

it would be possible to access the file with an absolute path with the get_repo_root() function but this stores the absolute file from a specific developer in the states file. so if the next developer checks out the project in a different folder and runs the terraform command we get a new directory.
the paths i get from all the available functions don't help
debug_paths = {
      + get_original_terragrunt_dir = "/project/accounts/production/gitlab"
      + get_parent_terragrunt_dir   = "/project/accounts"
      + get_path_from_repo_root     = "accounts/production/gitlab"
      + get_path_to_repo_root       = "../../../"
      + get_repo_root               = "/project"
      + get_terragrunt_dir          = "/project/accounts/production/gitlab"
      + path_relative_from_include  = "../.."
      + path_relative_to_include    = "production/gitlab"
    }

get_path_to_repo_root()/assets/gitlab/logo.png and path_relative_from_include()/assets/gitlab/logo.png result in a file not found as the real working directory is the cache directory which i moved to plugin_cache_dir   = "$GIT_REPO_ROOT/.terraform.d/plugin-cache" for the sake of a single location and not polluting all my source directories.
this results in the path .terraform.d/.terragrunt-cache/accounts/production/gitlab/SgKLvr5BkpwOBF27O_KMq4ZY5O0/JFRlN212e_19ZPmP_aI4z1wvWck/gitlab. to access the logo from main.tf in the resoucre gitlab_group i would need 8 levels of "up" ../../../../../../../../ which is not provided by a function. so the request for a function relative_from/to_working_dir() looks valid and quite important to me.
i tried to use the path functions without  and partly with the double slash //.
locals {
  config_defaults = {
    debug_paths = {
      path_relative_to_include = "${path_relative_to_include()}//"
      path_relative_from_include = "${path_relative_from_include()}//"
      get_repo_root = "${get_repo_root()}//assets/gitlab"
      get_path_from_repo_root = "${get_path_from_repo_root()}//"
      get_path_to_repo_root = "${get_path_to_repo_root()}//assets/gitlab"
      get_terragrunt_dir = "${get_terragrunt_dir()}//"
      get_parent_terragrunt_dir = "${get_parent_terragrunt_dir()}//assets/gitlab"
      get_original_terragrunt_dir = "${get_original_terragrunt_dir()}//"
    }
  }
  config_gitlab = yamldecode(file("${get_repo_root()}/config/gitlab.yaml"))
}

workarounds:

use absolut path and ignore that there is a change output all the time for different developers
hardcode a variable containing the required "directory-ups"


Feat/linear damping

close https://github.com/open-spaced-repetition/fsrs4anki/issues/697
@dae, I make a minor change in the model of FSRS-5. I prefer not to update the algorithm version (e.g. FSRS-5.1, FSRS-5.5 or something else) because Anki has stored FSRS-5 parameters separately and FSRS-5 hasn't been released in stable version of Anki. What do you think of?

My assumption with fsrs_params_5 is that we can continue to use it for future FSRS 5.x releases. We haven't had a stable release with 5 yet, so I think this change is fine - we can suggest users optimise again after updating to the next beta/RC.

we can suggest users optimise again after updating to the next beta/RC

Yes, it's exactly what I wanted to say.


[BUG] [unexpected behavior] Failing to validate IaC using centralized custom PSRule rules and Baselines

Existing rule
No response
Description of the issue
tl;dr;
Based on my tests (see below) it proves it is not possible to have a central location for custom PSRule rules and baselines. Each repo containing Bicep or ARM templates require the custom PSRule rules and ps-rule.yaml configuration file to be present within that repo.
This is by far a desired solution as it means PSRule code is going to be copied to each repo making it impossible to maintain it.
I can’t escape the feeling I’m doing something wrong. But what??
Can you please help!?
Error messages
See test results references in Reproduction section.
Reproduction
My setup:
Repo ‘IaC-validation’ contains the PSRule solution with custom PSRule rules.

https://github.com/Marc013/IaC-validation
Repo ‘myBicepSolution’ contains my Bicep solution which is to be validated.
https://github.com/Marc013/myBicepSolution

Requirements:
PSRule rules may not to be copied to the Bicep solutions repo.
The Resource Manager parameter file is used to specify the arguments for mandatory parameters.
The Resource Manager parameter file contains a reference to the corresponding Bicep file via metadata.
Path to the corresponding Bicep file is relative (“metadata”: { "template": "./storageAccount.bicep" } to support validation in Azure pipeline.
It is not desirable to have a PSRule configuration file in the Bicep solutions repo.
Goal:
Validate IaC in repo ‘myBicepSolution’ using all custom PSRule rules including build in ‘Azure.Template.’ and ‘Azure.Deployment.’ rules located in repo ‘IaC-validation’.
These custom rules consist of rules created using Azure policy assignment initiatives (JSON) and rules created in PowerShell.
My implementation:
PSRule options (and configuration) are defined using cmdlet New-PSRuleOption.
A PSRule baseline (myFirstBaseline) is created referencing every build in ‘Azure.Template.’ and ‘Azure.Deployment.’ and to include local rules.
IaC validation (Assert-PSRule) is to be executed within the repo ‘myBicepSolution’ directory so the relative path in the parameters can successfully be resolved.
Tests:
For all tests I used PowerShell script C:\Temp\IaC-validation\src\scripts\Run-PSRuleTest.ps1
The tests build upon the previous one. All changes made in previous tests are present in subsequent tests.

Using baseline ‘My.Guardrails1’ (.ps-rule\My.Guardrails.Baseline.Rule.yaml) the custom rules, ‘Azure.Template.’,  ‘Azure.Deployment.’ AND PSRule for Azure build-in rules are validated.
The PSRule for Azure build-in rules should not have been validated!
Results available in ‘.\IaC-validation\testResults\Result-My.Guardrails1.txt'
Using baseline ‘My.Guardrails2’ (.ps-rule\My.Guardrails.Basline.Rule.jsonc) produces the exact same result.
Using baseline ‘TestBaseline1’ (.ps-rule\TestBaseline1.Baseline.Rule.yaml) also produces the exact same result.
After copying the PSRule baseline files to repo ‘myBicepSolution’ ..ps-rule (which is not desirable) the outcome is still the same.
Get-PSRuleBaseline can find all 3 baselines.
After copying the custom rules and PSRule baseline files to repo ‘myBicepSolution’ ..ps-rule (which is not desirable) and modifying command Assert-PSRule to use the local rules the outcome is again the same.
Added PSRule configuration ps-rule.yaml in repo ‘myBicepSolution’ (this is not desirable), still the same outcome.
Using parameter -Baseline instead of defining it in the options of the PSRuleOptions.
Baseline ‘TestBaseline1’ is used. However, the local custom policies are not used despite the baseline defining ‘includeLocal: true’ and having all the custom rules explicitly specified.
Results available in ‘.\IaC-validation\testResults\Result-My.TestBaseline1.txt’,
Using ‘My.Guardrails2’ (no changes to the JSON file made). This time the baseline is used however, none of the explicitly specified custom rules are validated.
Results available in ‘.\IaC-validation\testResults\Result-My.Guardrails2.txt’,
Using My.Guardrails1’ (no changes to the JSON file made). The exact same result as the previous test.
Explicitly defined all custom rules in ps-rule.yaml to be included. Not specifying any baseline. Custom rules and all build in rules are validated. The Build in rules (apart from the template and deployment rules) should not have been validated as that is not desired.
Results available in ‘.\IaC-validation\testResults\Result-Using-ps-rule.yaml-with-all-custom-rules.txt’
Explicitly excluded every build in (PSRule.Rules.Azure) rule in ps-rule.yaml. Exact same result as in test 10.
Running Assert-PSRule without parameter -Option. All configuration specified in ps-rule.yaml. Nothing validated as no matching rules are found.
Running command Assert-PSRule -InputPath C:\Temp\myBicepSolution\storageAccount\storageAccount.parameters.json -Module PSRule.Rules.Azure -Format File. Desired outcome obtained!
The command was executed in Windows terminal.
Running command of test 13 via script. Same outcome as in test 13. Which is positive.
Using parameter -Baseline My.Guardrails3. All excluded and included rules are specified in this baseline. Section Rule is commented out in ps-rule.yaml.
Running command Assert-PSRule -InputPath C:\Temp\myBicepSolution\storageAccount\storageAccount.parameters.json -Module PSRule.Rules.Azure -Format File -Baseline My.Guardrails3.
Only Azure.Template and Azure. Deployment rules are evaluated. All other rules are skipped.

Conclusion:
PSRule requires custom rules to be withing the same repo as the Bicep/ARM template that is to be validated.
In the same repo PSRule configuration file ps-rule.yaml is required.
I won’t dive into things that don’t seem to work (or at least not for me) as it is already in detail described above.
Version of PSRule
2.9.0
Version of PSRule for Azure
1.30.3
Additional context
Provided in section Reproduction in My setup:.

Hi @Marc013. Have a look at: https://microsoft.github.io/PSRule/v2/authoring/packaging-rules/

You want to add the rules from https://github.com/Marc013/IaC-validation into a module by changing the structure a bit instead of using the default .ps-rule/ directory add a directory for the module such as MyGuardrails.
Add a manifest.
In the manifest you will also want to take a dependency on PSRule.Rules.Azure by setting the RequiredModules property.

When executing tests from https://github.com/Marc013/myBicepSolution, you need to install/ import the module. If you are publishing the module you can Install-Module to install it prior or if you are not publishing the module anywhere you can git clone or use a sub-module to copy the module down then Import-Module to load the module prior to calling PSRule.

@BernieWhite
Attempting to create a module (and failing miserably 😭)
Can you please help me getting Assert-PSRule to validate my custom rules and PSRule.Rules.Azure rules ‘Azure.Template.*’ and ‘Azure.Deployment.*’?
In both repositories I create a new branch for the creation of the module and testing of it.

Repo
Branch

IaC-validation
MyGuardrails-pwsh-module

myBicepSolution
Use-pws-module-MyGuardrails

I created a pwsh module for the custom rules (which are in JSON format and 1 in pwsh) as you suggested.
In this module I adhered to your documentation as much as possible. So, I renamed ‘My.Guardrails.Baseline.Rule.yaml’ to ‘Baseline.Rule.yaml’.
Baseline TestBaseline1 and My.Guardrails3 is added to ‘Baseline.Rule.yaml’ (now containing 3 baselines) reducing the number of files in the module.
First test attempts
For each baseline I ran a test
Results:

testResultsUsingModule\ModelTestResults-My.Guardrails1.txt
testResultsUsingModule\ModelTestResults-TestBaseline1.txt
testResultsUsingModule\ModelTestResults-My.Guardrails2.txt
testResultsUsingModule\ModelTestResults-My.Guardrails3.txt

Before each test I adjusted the baseline name in ‘modules\MyGuardrails\rules\Config.Rule.yaml’.
Every test is run in its own pwsh terminal.
Executed command for testing:
Assert-PSRule -InputPath .\storageAccount\storageAccount.parameters.json -Module MyGuardrails -Format File

None of the tests validated any of the rules 😢
Second test attempt
I copied module MyGuardrails to my default PowerShell module directory ('C:\Users\<account name>\<company OneDrive>\Documents\PowerShell\Modules\MyGuardrails').
Using baseline My.Guardrails3 I ran a new test in a new pwsh terminal.
The command used for this test is the same as specified above.
Unfortunately, the result was exactly the previous test results.

[WARN] Could not find a matching rule. Please check that Path, Name and Tag parameters are correct.

Third test attempt
Nothing has changed. Module MyGuardrails is still available in my default PowerShell module directory with baseline My.Guardrails3 defined.
This time I specified parameter -Options.
Command with configuration settings
$psRuleConfigurationSettings = @{
    AZURE_BICEP_FILE_EXPANSION         = $true
    AZURE_BICEP_FILE_EXPANSION_TIMEOUT = 60
    AZURE_BICEP_PARAMS_FILE_EXPANSION  = $true
    AZURE_PARAMETER_FILE_EXPANSION     = $true
    AZURE_PARAMETER_FILE_METADATA_LINK = $true
}

$psRuleOptions = New-PSRuleOption -Configuration $psRuleConfigurationSettings

Assert-PSRule -InputPath .\storageAccount\storageAccount.parameters.json -Module MyGuardrails -Format File -Option $psRuleOptions

Again the same results.

[WARN] Could not find a matching rule. Please check that Path, Name and Tag parameters are correct.

Fourth test attempt
For this test I copied module PSRule.Rules.Azure to MyGuardrails2 and:

Renamed version directory to '0.1.0'
Removed al files from version directory except 'PSRule.Rules.Azure.psd1' which I renamed to 'MyGuardrails2.psd1'
Adjusted the module manifest by providing a new guid and having it reflect module name 'MyGuardrails2'
Removed all rules
Added my custom rules (.JSONC and .ps1)
Removed directories '_manifest', 'en-AU', 'en-GB', 'en-US'
Emptied directory 'en' and placed markdown of my custom pwsh # Name of rule
Emptied directory 'rules' and placed my custom rule files (.jsonc & .ps1) and config & baseline yaml files
Copied module 'MyGuardrails2' to the PowerShell default module directory.
Executed command:

Assert-PSRule -InputPath .\storageAccount\storageAccount.parameters.json -Module MyGuardrails2 -Format File

Results remain the same.

[WARN] Could not find a matching rule. Please check that Path, Name and Tag parameters are correct.

Fifth attempt as I remembered pwsh module PowerShell-yaml

Copy version directory 0.1.0 to 0.2.0

Converted JSON rules to YAML using function ConvertTo-Yaml
$customRules = Get-Content -Path C:\git\Private\_PSRuleTesting\IaC-validation\modules\MyGuardrails\0.2.0\rules\definitions-Guardrails-000.Rule.jsonc -Raw | ConvertFrom-Json -Depth 100

$customRules | ConvertTo-Yaml -OutFile C:\git\Private\_PSRuleTesting\IaC-validation\modules\MyGuardrails2\0.2.0\rules\definitions-Guardrails-000.Rule.yaml

Removed 'definitions-Guardrails-000.Rule.jsonc'

Updated module version in manifest to '0.2.0'

Updated the rules in yaml file by adding a rule separator and synopsis (with pre1fix '[YAML]' in the description) and adjusting the indent

Copied version 0.2.0 to the PowerShell default module directory and executed command

Deleted directory version 0.1.0

Running test

Get-PSRule -Module MyGuardrails2 -ListAvailable

RuleName                            ModuleName  Synopsis
--------                            ----------  --------
My.Resource.MandatoryTags                       Resources not having the mandatory tags should be rejected.
Guardrails-000.Policy.231f0045f18f              [YAML]Storage accounts should have infrastructure encryption
Guardrails-000.Policy.9f15257d13f6              [YAML]Azure Stream Analytics jobs should use customer-managed keys to encrypt data
. . .

Assert-PSRule -InputPath .\storageAccount\storageAccount.parameters.json -Module MyGuardrails2 -Format File

Results remain the same.

[WARN] Could not find a matching rule. Please check that Path, Name and Tag parameters are correct.

@BernieWhite, Could you perhaps shed some light on this?

@Marc013 Working back with your initial module in modules/MyGuardrails.
Update My.Guardrails3 after includeLocal: true add tag: { }.
Add configuration to ps-rule.yaml in the myBicepSolution repo.
configuration:
  AZURE_PARAMETER_FILE_EXPANSION : true
  AZURE_PARAMETER_FILE_METADATA_LINK : true

Update your command line to include the -Baseline parameter.
assert-psrule -m MyGuardrails -f . -Format File -Baseline My.Guardrails3

There is a few PSRule bugs here. Ideally you should not need these additional steps. We're making some improvements in PSRule v3 that should fix these issues in cross-module scopes when we're done.

@BernieWhite, Thank you very much!
I'll implement this solution.


sed -i error with some versions of sed

My sed (on a Mac) expects -i to be followed by an optional extension. So the current sed command fails like this:
Marks-MacBook-Pro:janusgraph-utils markstur$ sed -i '2s/.*/1,Indiana Jones/' /tmp/User.csv
sed: 1: "/tmp/User.csv": invalid command code U
It works w/ no extension by using the -e to terminate -i and start the expression. So I think this fix would be a more universal syntax (works on Mac):
sed -i -e '2s/.*/1,Indiana Jones/' /tmp/User.csv
If there are any issues w/ that, then I'd guess using > new-output-file instead of -i might be safest.

Thanks for pointing it out. Interestingly the same sed command does not cause any errors in one my colleague's mac. Anyway, I will add -e to be specific and safe. I like to update the file in-place so no additional files or steps are needed.


Documentation feedback

Too many ways of getting started (should be one and simple)
Lack of documentation for config options supported in the databases
Config in graphback differs with config in the graphql cl and it is not documented.
Lack of diagram showing entire environment
No visual gif
Lack of motivation for graphback 0.10 (probably separate blog post)

Closing as we have migrated this requirements to different issue


Unable to get RKH output from recent QCOM platforms abl images

It seems that RKHReader is unable to get the RKH on taro platform (SM8450), kalama platform (SM8550) and pineapple platform (SM8650). It just give FAIL! as the output
However it worked fine on lahaina platform (SM8350), Qualcomm probably have changed something in their newer platforms abl images.


Patient dashboard

Add the patient dashboard according to the design ("Patient / Overview" screen).
BMI = weight / height2, where weight in kg and height im meters, or weight in pounds and height in inches.
Take:

conditions from "Condition" resource.
medications from "MedicationStatement" resource or "MedicationRequest" resource (please get a consultation and decide).
allergies from "AllergyIntolerance" resource.
immunizations from "Immunization" resource.

Moved BMI part to separate issue https://github.com/beda-software/fhir-emr/issues/59


Refactor the implementation of SDWebImagePrefetcher

New Pull Request Checklist

[x] I have read and understood the CONTRIBUTING guide

[x] I have read the Documentation

[x] I have searched for a similar pull request in the project and found none

[x] I have updated this branch with the latest master to avoid conflicts (via merge from master or rebase)

[x] I have added the required tests to prove the fix/feature I am adding

[x] I have updated the documentation (if necessary)

[x] I have run the tests and they pass - Passed. And add two more tests for prefetcher

[x] I have run the lint and it passes (pod lib lint)

This merge request fixes / reffers to the following issues: #1679
Pull Request Description
Reason
Our SDWebImagePrefetcher seems design to use like a normal object but not to used as a sharedPrefetcher. Currently its implementation will cancel all the current request when you call prefetchURLs. So if you use the shared prefetcher somewhere to prefetch one url list, and another background queue start to prefetch another url list, all of your first request will be canceled and even the completion block will never called(This seems a bug). This is too misunderstanding and this cause some issue in my real application. Many programmers does not aware of this behavior when using.
And always, the #1679 show that some user want to cancel the specify urls because they do not want to affect the current requested urls. However, this can not be solved in current implementation from the design. Because the prefetcher works based on only one urls lists and only one progressBlock and completionBlock. If you remove one, the finished count or skipped will mess up.
And more interesting, our SDWebImageManger make a assert when you provide a nil completionBlock.

If you mean to prefetch the image, use -[SDWebImagePrefetcher prefetchURLs] instead

It recommends you to use the prefetcher. However, user may get in trouble because these two works in really different ways. Maybe we should redesign the prefetcher to make it more conforming to intuition.
Design and Implementation
So this refactor, reimplementation the prefetcher from the scratch design. Now, prefetcher do not cancel previous request and it separate different prefetching process. Which means it take your urls, progressBlock, completionBlock to bind with a context SDWebImagePrefetchToken. So when you call prefetchURLs twice, you get another different prefetching progress. You can cancel the token returned by prefetchURLs and this will not affect other running requests, only the urls associated to the token will be cancelled. This's is acceptable because this based on the manager, so you can hit the cache to return immediatelly. And if the cache miss, our downloader will reuse the download operation so you do not waste extra bandwidth to download same url twice.
This make that our sharedPrefetcher works more famillar like a shared instance. For normal use case like prefetching from a background queue, you do not need to worry about about someone cancel your prefeching from anywhere like a scout and have no choice to create a new prefetcher instance instead. You can simply call prefetchURLs on the shared instance with your own urls and your own completionBlock. And the self-alloc instance is still useful when you want to custom the options, context and delegate callback queue.(Now we introduce a context to pass some options which can not be represented by a enum)
For the delegate, we keep this because it's useful for some use cases like metrics and logger. But now, since we make the that prefetching associate to a context, we should also update the comment to point this out. The -[SDWebImagePrefetcherDelegate imagePrefetcher:didFinishWithTotalCount:skippedCount:] now called only all the urls from each prefeching context finished. And the -[SDWebImagePrefetcherDelegate imagePrefetcher:didPrefetchURL:finishedCount:totalCount:] now called any of urls from any prefetching context finished. This can make it more clear to use.
API Change
And finally, about API changes. This refactoring actually does not change any of public API at all :) Because the change is more on the concept and implementation. Through, for normal usage, people will not find any difference between this two and even all the current tests for prefetcher passed without any modification. But since it's a big change for usage in some cases, We should mark this as 5.x
Note for Swift user, since Swift treat a unused value as a compile error, and the current API will  now return a SDWebImagePrefetchToken instance instead of void, so this is API-breaking for Swift user.

This is a broken API,so can we use a new method,such as  -- (void)addPrefetchURLs:(nullable NSArray<NSURL *> *)urls

@sunbohong Well. This should be a broken API for the Swift user. But if we have two of this, the API will be really misunderstanding.
For example, the current 4.x implementation, means each prefetcher can only hold one URL list when you can prefetchURLs:. If you cancel the URLs, you can only cancel the total URLs. However, this 5.x changes will separate each time the URLs you provide.
Assume we have both of these two API, prefetchURLs: and addPrefetchURLs:. See the example code:
urls1 = @[@"http://foo1.bar", @"http://foo2.bar"];
urls2 = @[@"http://foo2.bar", @"http://foo3.bar"];
urls3 = @[@"http://foo4.bar"]

[prefetcher prefetchURLs:urls1];
token = [prefetcher addPrefetchURLs:urls2];
[token cancel];
// Question: What remain request are in the prefetcher ?
// [http://foo1.bar] ? or [http://foo1.bar, http://foo3.bar]

// More serious problem, this code
[prefetcher prefetchURLs:urls1];
[token prefetcher addPrefetchURLs:urls2];
[prefetcher prefetchURLs:urls3];
// Question: What remain request are in the prefetcher ?
// [http://foo4.bar], or [http://foo2.bar", http://foo3.bar", http://foo4.bar"]

Since we change this in 5.x. So API break change is acceptable. If you just need the current behavior. You can call cancelPrefetching each time before you call prefetchURLs

Current break change (Need change code)
SDWebImagePrefetcher.h

-[SDWebImagePrefetcher prefetchURLs:] return value change to SDWebImagePrefetchToken from void.
-[SDWebImagePrefetcher prefetchURLs:progress:completed:] return value change to SDWebImagePrefetchToken from void.
prefetcherQueue property RENAMED to delegateQueue.
maxConcurrentDownloads property REMOVED, use SDWebImageManager.downloader 's config instead.

Interesting implementation @dreampiggy


Move / copy / add documentation to website?

There's currently lots of docs in https://github.com/resin-io/etcher/tree/master/docs but very little on https://www.etcher.io/
It would be great to see more user-focused documentation on https://www.etcher.io/ as I doubt many users will bother clicking through to GitHub. Maybe this issue should be added to https://github.com/resin-io/etcher/milestone/2 ?

But there is only one doc in there targetted at users though, no?
--
Alexandros Marinos
Founder & CEO, Resin.io
+1<PHONE_NUMBER>
@alexandrosm
On Mon, Oct 31, 2016 at 5:59 AM, Andrew Scheller<EMAIL_ADDRESS>wrote:

There's currently lots of docs in https://github.com/resin-io/
etcher/tree/master/docs but very little on https://www.etcher.io/
It would be great to see more user-focused documentation on
https://www.etcher.io/ as I doubt many users will bother clicking through
to GitHub. Maybe this issue should be added to
https://github.com/resin-io/etcher/milestone/2 ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/resin-io/etcher/issues/792, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABLUCEFQRwTG24BMOvzN4hx-4bRUfMuAks5q5eYegaJpZM4Kk_FN
.

IMHO https://github.com/resin-io/etcher/blob/master/docs/USER-DOCUMENTATION.md is bit of a mish-mash of FAQs, notes, and general info, and ought to be tidied up and/or split into sub-categories before being published as "end user documentation" (and not just "developer-level documentation") on https://www.etcher.io/
I appreciate that Etcher is supposed to be simple enough that it doesn't really need documentation, but some people may be put off by the 'sparseness' of https://www.etcher.io/ ? The only real "documentation" currently is the animated GIF in the middle of the page.
All IMVHO, naturally :-)
Perhaps this issue should be moved to https://github.com/resin-io/etcher-homepage

don't get me wrong, I agree that we should have docs. I also happen to
agree we should break up user-documentation.
The only reason you may be seeing this be stuck is that we're envisioning a
better way to do the etcher landing page altogether, which includes
auto-importing the docs from the repo, that is making us hesitant to add
much to the existing one.
It's a bad instinct, but that doesn't make it go away :)
--
Alexandros Marinos
Founder & CEO, Resin.io
+1<PHONE_NUMBER>
@alexandrosm
On Mon, Oct 31, 2016 at 6:55 AM, Andrew Scheller<EMAIL_ADDRESS>wrote:

IMHO https://github.com/resin-io/etcher/blob/master/docs/USER-
DOCUMENTATION.md is bit of a mish-mash of FAQs, notes, and general info,
and ought to be tidied up and/or split into sub-categories before being
published as "end user documentation" (and not just "developer-level
documentation") on https://www.etcher.io/
I appreciate that Etcher is supposed to be simple enough that it doesn't
really need documentation, but some people may be put off by the
'sparseness' of https://www.etcher.io/ ? The only real "documentation"
currently is the animated GIF in the middle of the page.
All IMVHO, naturally :-)
Perhaps this issue should be moved to https://github.com/resin-io/
etcher-homepage
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/resin-io/etcher/issues/792#issuecomment-257299799,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABLUCN0uZ4WNJ02KmbZxmS6OMQmwAsR_ks5q5fNmgaJpZM4Kk_FN
.

Haha, I've just been catching up with https://gitter.im/resin-io/etcher and see you were discussing this exact issue a few days ago! :laughing:

This is a "Backlog" task, but pinging @zwalchuk in case it's something he wants to think about ;-)


pie chart aggregates data incorrectly

The fact pie charts seem to have a maximum of 16 labelled categories, with the 16th being 'other'.  I can understand why it might make sense to limit the number of categories visible (though I think it should probably be a higher number than this) but the real problem is that it aggregates them incorrectly, to my mind at least.
Surely the 'other' category should be made up of the categories with the smallest sizes should it not? In other words so the largest 15 categories should be displayed with labels, then the remaining categories aggregated into 'others'.  This is not what happens though, instead it seems to put categories into 'others' at random, so the largest two or three might be aggregated into 'others' while multiple tiny categories are shown.  This renders the chart meaningless much of the time.

This sounds like a duplicate report of an issue I reported and submitted a fix for. But this fix got rejected for some unknown reason: https://github.com/voxpupuli/puppetboard/pull/130

@sigmunau another PR was submitted recently with the exact same changes as the one you submitted what was merged. https://github.com/voxpupuli/puppetboard/pull/242

Possibly fixed by #242


Bikeshed using vector destructuring instead of a let and second.

Sorry, it bothered me.
Would totally understand if you don't want it, but couldn't just let it be.

Thanks for the PR, but we're probably happy with this as it is.

Yeah, I wanted to make clear that the 2nd argument was the event.  Getting that into a readers head seemed the most useful thing at this point in the teaching process.   Luxuriating in the comforts of destructuring is something for later in the learning curve.


Allow to use custom parsers from outside Kint folders

We're doing an integration of Kint in the Devel module for Drupal 8: https://drupal.org/project/devel and one of the things we'd need is to provide custom parsers to inspect various properties and methods that are Drupal specific but seems that the discovery of the parsers only happens in the own Kint directory.
Could we add some sort of autoloader to load parsers from elsewhere (autoloader i.e.), I'm willing to provide a PR if you point me the right direction.
This is how one our parsers would look like: https://gist.github.com/Berdir/9335736

Implemented in 2.x-dev. Please test and give feedback, thanks!


fix(api): removes unnecessary protocol definition from doc starge api…

… host builder (BOAS-460)
Describe your changes

fixes reference to Document Storage API (removes unnecessary protocol definition)

Issue ticket number and link
Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[ ] I have performed a self-review of my own code
[ ] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[ ] I have provided details on how I have tested my code
[ ] I have referenced the ticket number above
[ ] I have provided a description of the ticket
[ ] I have included unit tests to cover any testable code changes

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket: