add Kau Yan College

@joselabs I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host mod.obagg.com not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


BTP-01-minAllowedWeights: 1024->1536

Abstract
The minAllowedWeights determine the number of weights set by each validator. Overall, increasing this parameter will increase the overall trust in the network. Increasing the number of weights available on the network should lead to a higher trust for the average server and a higher consensus.
Motivation
While change #4 increased the overall trust from T=~0.15 to T=~0.3, there is still room for growth.  We also noticed that the default number of weights was too low compared to the number of weights expected in the latest update. Therefore we are increasing the minAllowedWeights to compensate for this discrepancy
Specification
Param: minAllowedWeights
Initial Value:1024
Suggested Value:1536
Time of Effect: Immediate

Pinging @Eugene-hu to prevent this going stale.

@mrseeker  Thanks for reminding me of this. This PR is no longer needed, as the new validator does this automatically. Closing for completeness.


feat: add early stopping

Hey there, thanks for your meticulous guidance and assistance!
Following the suggestions from issue #11, I have implemented early stopping and fixed the initialization process. I use logits instead of losses to control early stopping because I can't find a fixed loss value which fluctuates across various tasks and models. It's possible that a threshold between 0.1 to 0.2 could work.  I think use logits is much more reliable.

By the way, I found two more problems about initialization:

The suffix initialized in the buffer might not pass the filter_ids. This issue stems from the interaction between the tokenizer and the INIT_CHARS, leading to this runtime error. For instance, when we select '?' and '!' as our init_buffer_ids, we might intend them as ' ?  !' (spaced), but some tokenizers may retokenize them as '?!' (unspaced), which represents an entirely different token. A 20-token suffix could be condensed to merely 3-4 tokens.  Currently code works well on Llama2 tokenizer. However, I've encountered this issue with the Internlm tokenizer, and it's possible that Llama3 faces a similar problem.
The buffer doesn't sort until it's full, so it doesn't give the best_ids in first step. It's a small issue.

I'll investigate the cause of problem (1). Perhaps crafting strings that include characters and spaces and then tokenizing them would be a better choice?

Thanks a ton for your guidance! I‘ve made all necessary changes and  update the README.
Thanks again for your help!

I'm quite puzzled about the use of the buffer because as we take out the best suffix and don't pop it out, the buffer tends to explore and update along the best candidate from initilization, soon or later the buffer will be filled with suffixs come from this candidate and don‘t consider other condidates. If you're interested in this issue, I can open a separate issue for discussion.

this is wonderful! nice work :)
yes, i've also noticed this, feel free to open another issue on the buffer.


Add mkdocs configuration file.

Add read the docs.
Additionally, change CI to update monthly.

@jnnr I decided to just use the conda environment since we have very few requirements, and I'd like people to be able to test their docs locally without much hassle.
This repo is not meant to become a library in a python sense, so this is good enough in my opinion.


fix: update scope of overlapping role assignments

The sum of the two role assignments amounts to the contributor role on the subscription, which is more even than just the resource group.

@oliverw1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @oliverw1
Thanks for your contribution! We will get this merged.

#sign-off


uninstall option from manual_user_install

It was recently mentioned in the chats if there is a clean command or uninstall.  I think that this would be useful for users to start over with.

I'll be able to start putting something together within the next few weeks.

I recently changed the systemd  services to use a venv, and I think the manual install script has a sed  command changing them. You might look there also

Completed here


Enable NullAway for :core

Motivation:
It would be nice if we can fail our build if there is any potential
null dereference, so our users have much less chance of getting
NullPointerException.
Modifications:

Updated the build so that NullAway plugin is enabled for :core

Note that the root build.gradle was modified so that we can
enable NullAway for other projects in the future.
Other caveats:

NullAway is disabled for MR-JAR sources because it seems to make
the build fail with unrelated errors (e.g. no symbol)

Added assert sentences and @Nullable annotations wherever
applicable
Fixed a few minor potential null dereferences

Result:

We're more confident about our @Nullable usages in our API.
Theoretically, there should be no chance of NullPointerException at
least in the :core.

However, note that some NullPointerExceptions might have become
AssertionErrors, since we added a bunch of assertions in this PR,
so please review carefully :-)

Partially resolves #1680 and #5184

https://github.com/line/armeria/actions/runs/10046097418/job/27764866925?pr=5820#step:11:1515
Could you check the failure?

Thanks, everyone :-)


Autocomplete search needs a valid regExp

Autocomplete-clab search functionality doesn't work when special characters are used. Es: [, +.
This is because it uses the function String.prototype.search which accepts a regExp or a string that can be turned into a RegExp.
const phrase = '[laura] è al mare';

phrase.search('laura') // -> correctly returns the index
phrase.search('[laura') // -> Uncaught SyntaxError: Invalid regular expression

'[laura' cannot be turned into a RegExp unless the special character is escaped.
How To Fix:
Escape the string using https://www.npmjs.com/package/escape-string-regexp

closed by #208


Bug: bin install github.com/Shopify/ejson creates ~/bin/linux

The releases of https://github.com/Shopify/ejson are not optimally named and therefore, bin creates ~/bin/linux where I would like to get ~/bin/ejson.

Same problem with https://github.com/Shopify/ejson2env

@marcosnils Should we support this scenario, i.e. the binary's name and the basename of the URL contain 0 occurrences of the repo's name, and in that case replace it with the repo's name?

Should we support this scenario, i.e. the binary's name and the basename of the URL contain 0 occurrences of the repo's name, and in that case replace it with the repo's name?

Hmm I'm not sure about trying to be smart about this if package maintainers are not publishing their releases in a "readable way" . That was why I added bin install <repo> [filename] so in this case you can do bin install https://github.com/Shopify/ejson ~/bin/ejson.
One thing that can be improved about the above example is that if you don't specify a path, to automatically put it in your bin configured path. If you do bin install <url> somebinary it'll put somebinary  in your current path instead. I guess that in order to achieve that, you can just do bin install <url> ./somebinary
Summary:  I'm not convinced to add something that ultimately should be the upstream repo to fix, since opening an issue in the original repository so the project fixes their package names should be right thing to do in the first place. In that sense we're implementing a "temporary" fix for something that's fundamentally wrong in the first place.

@marcosnils I agree, and since the binary will keep its name in your ~/bin folder (or wherever you chose to install it the first time), it is only a concern at the first install, until the upstream repo fixes their released asset names 😄

@marcosnils I agree, and since the binary will keep its name in your ~/bin folder (or wherever you chose to install it the first time), it is only a concern at the first install, until the upstream repo fixes their released asset names

Yep. @breml WDYT?
I'll try to find the time to fix the install path issue mentioned in my previous comment :)

In general I agree, I successfully installed ejson2env with the following command: bin install github.com/Shopify/ejson2env ~/bin/ejson2env.
The thing I don't like about the current behavior is, that normally when I install a binary with bin, I do not necessarily check the content of the releases on the release page before. So I just try bin install <github-url>. With the current behavior I need to check the output of the command carefully, if this produces the expected binary name in my default bin directory.
At least some sort of warning would be nice.

The thing I don't like about the current behavior is, that normally when I install a binary with bin, I do not necessarily check the content of the releases on the release page before. So I just try bin install <github-url>

yes, same. But when I see that the options that I get are very bad, I abort the install and re-install it using a custom binary name,

The thing is, that for this particular binary you do not get any options at all.

The thing is, that for this particular binary you do not get any options at all.

Oh, got it.. I also don't think it's that bad either, since bin will print the binary name after it's done downloading it.

I think the message is quite clear, and this doesn't/shouldn't happen often. Not sure what's left to be done here.

You might be right, there is not much bin can do about this. I close this issue.


Falco would occasionally restart due to connection error to kubernetes api service

What happened:
Falco agents would occasionally restart due to a connection error to kubernetes service at kubernetes.default.svc.cluster.local (<IP_ADDRESS>)
It seems to happen more frequently especially on the busy clusters.
...
Sun Nov 17 03:12:13 2019: Runtime error: Error during connection attempt to https://<IP_ADDRESS> (socket=122, error=111): Connection refused. Exiting.

...
Sun Nov 17 03:08:02 2019: Runtime error: Socket handler (k8s_namespace_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection refused. Exiting.

What you expected to happen:
To run without overloading kubernetes api service too much (if that is what is causing the connection issue to the api server)
How to reproduce it (as minimally and precisely as possible):
We deployed Falco agents (as DaemonSet) to each node (running on COS) of a cluster on GKE. This cluster has around 20 nodes with roughly 20 pods running each. We have two customized rules that will aggressively report on any process executions and file write accesses.
Anything else we need to know?:
Initially, we suspected that our aggressive two rules cause falco to hit metadata service too much that it'll become unavailable at times.
We noticed two kinds of network traffic coming from the agent to kubernetes services (kubernetes.default.svc.cluster.local, kube-dns.kube-system.svc.cluster.local).
One kind of traffic which Falco seems to resolve domain names of mining pool every five minutes,
20:56:23.256627 IP falco-daemonset-nxb72.38144 > kube-dns.kube-system.svc.cluster.local.53: 54927+ A? mine.moneropool.com.falco.svc.cluster.local. (61)
20:56:23.258072 IP kube-dns.kube-system.svc.cluster.local.53 > falco-daemonset-nxb72.38144: 54927 NXDomain 0/1/0 (154)
20:56:23.258194 IP falco-daemonset-nxb72.38144 > kube-dns.kube-system.svc.cluster.local.53: 18838+ AAAA? mine.moneropool.com.falco.svc.cluster.local. (61)
20:56:23.259073 IP kube-dns.kube-system.svc.cluster.local.53 > falco-daemonset-nxb72.38144: 18838 NXDomain 0/1/0 (154)
20:56:23.260583 IP falco-daemonset-nxb72.35302 > kube-dns.kube-system.svc.cluster.local.53: 7232+ A? mine.moneropool.com.svc.cluster.local. (55)
20:56:23.261660 IP kube-dns.kube-system.svc.cluster.local.53 > falco-daemonset-nxb72.35302: 7232 NXDomain 0/1/0 (148)

Another kind of traffic which hits the kubernetes service many times a second. Considering we have 20 agents running in this cluster, the number of requests would be amplified.
00:34:51.359118 IP kubernetes.default.svc.cluster.local.443 > falco-daemonset-6xq4c.60896: Flags [P.], seq 2129670:2133795, ack 1, win 285, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 4125
00:34:51.359131 IP falco-daemonset-6xq4c.60896 > kubernetes.default.svc.cluster.local.443: Flags [.], ack 2133795, win 1945, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
00:34:51.359135 IP kubernetes.default.svc.cluster.local.443 > falco-daemonset-6xq4c.60896: Flags [P.], seq 2133795:2139997, ack 1, win 285, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 6202
00:34:51.359139 IP falco-daemonset-6xq4c.60896 > kubernetes.default.svc.cluster.local.443: Flags [.], ack 2139997, win 1911, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
00:34:51.359259 IP kubernetes.default.svc.cluster.local.443 > falco-daemonset-6xq4c.60896: Flags [P.], seq 2139997:2140028, ack 1, win 285, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 31
00:34:51.359262 IP falco-daemonset-6xq4c.60896 > kubernetes.default.svc.cluster.local.443: Flags [.], ack 2140028, win 1911, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
00:34:51.637833 IP kubernetes.default.svc.cluster.local.443 > falco-daemonset-6xq4c.60896: Flags [P.], seq 2140028:2144153, ack 1, win 285, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 4125
00:34:51.637863 IP falco-daemonset-6xq4c.60896 > kubernetes.default.svc.cluster.local.443: Flags [.], ack 2144153, win 1879, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
00:34:51.637868 IP kubernetes.default.svc.cluster.local.443 > falco-daemonset-6xq4c.60896: Flags [P.], seq 2144153:2149731, ack 1, win 285, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 5578
00:34:51.637871 IP falco-daemonset-6xq4c.60896 > kubernetes.default.svc.cluster.local.443: Flags [.], ack 2149731, win 1841, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0
00:34:51.638019 IP kubernetes.default.svc.cluster.local.443 > falco-daemonset-6xq4c.60896: Flags [P.], seq 2149731:2149762, ack 1, win 285, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 31
00:34:51.638024 IP falco-daemonset-6xq4c.60896 > kubernetes.default.svc.cluster.local.443: Flags [.], ack 2149762, win 1841, options [nop,nop,TS val<PHONE_NUMBER> ecr<PHONE_NUMBER>], length 0

We tried configuring kubernetes dnsConfig.ndots to 1 to avoid any unnecessary local searches of domains to kube-dns, and coincidentally, the connection refusals have disappeared since then.
Environment:

Falco version: falco-probe-bpf-0.18.0-x86_64-4.14.137
System info

# falco --support | jq .system_info
Fri Nov 22 19:21:42 2019: Falco initialized with configuration file /etc/falco/falco.yaml
Fri Nov 22 19:21:42 2019: Loading rules from file /etc/falco/falco_rules.yaml:
Fri Nov 22 19:21:42 2019: Loading rules from file /etc/falco/falco_rules.local.yaml:
{
  "machine": "x86_64",
  "nodename": "falco-daemonset-nr758",
  "release": "4.14.137+",
  "sysname": "Linux",
  "version": "#1 SMP Thu Aug 8 02:47:02 PDT 2019"
}

Cloud provider or hardware configuration: GCP, n1-standard-4, Container-Optimized OS build 11647.267.0
OS (e.g: cat /etc/os-release):

PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Kernel (e.g. uname -a):

Linux falco-daemonset-nr758 4.14.137+ #1 SMP Thu Aug 8 02:47:02 PDT 2019 x86_64 GNU/Linux

Install tools (e.g. in kubernetes, rpm, deb, from source):

Kubernetes master node 1.13.11-gke.14
Kubernetes node 1.13.10-gke.0

Others:

I think this is related to #935, we are using the latest Falco version: 0.18.0.

yes please @axot - it would be useful!

Hi I got some progress, this backtrace was generated from 0.18.1.
Catchpoint 1 (exception thrown), 0x00007ffff7e5e2ae in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#0  0x00007ffff7e5e2ae in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0000555555704c74 in socket_data_handler<k8s_handler>::try_connect (this=this@entry=0x55555615b400) at /usr/include/c++/9/ext/new_allocator.h:89
#2  0x0000555555706036 in socket_data_handler<k8s_handler>::connect_socket (this=0x55555615b400) at /usr/include/c++/9/bits/basic_string.h:2300
#3  0x00005555557063bc in socket_data_handler<k8s_handler>::get_socket (timeout_ms=<optimized out>, this=0x55555615b400) at /usr/src/dev/sysdig/userspace/libsinsp/socket_handler.h:92
#4  socket_collector<socket_data_handler<k8s_handler> >::add (this=0x5555561046b0, handler=std::shared_ptr<socket_data_handler<k8s_handler>> (use count 2, weak count 0) = {...}) at /usr/src/dev/sysdig/userspace/libsinsp/socket_collector.h:34
#5  0x00005555556ec323 in k8s_handler::connect (this=0x555556099740) at /usr/include/c++/9/ext/atomicity.h:96
#6  0x00005555556ef1f2 in k8s_handler::k8s_handler (this=0x555556099740, id=..., is_captured=<optimized out>, url=..., path=..., state_filter=..., event_filter=".", null_filter="", collector=std::shared_ptr<socket_collector<socket_data_handler<k8s_handler> >> (use count 4, weak count 0) = {...}, http_version="1.1", timeout_ms=1000, ssl=std::shared_ptr<sinsp_ssl> (use count 5, weak count 0) = {...}, bt=std::shared_ptr<sinsp_bearer_token> (use count 5, weak count 0) = {...}, watch=false, connect=true, dependency_handler=std::shared_ptr<k8s_handler> (use count 2, weak count 0) = {...}, blocking_socket=true, max_messages=4294967295, state=0x0) at /usr/src/dev/sysdig/userspace/libsinsp/k8s_handler.cpp:101
#7  0x000055555578c790 in k8s_api_handler::k8s_api_handler (this=0x555556099740, collector=..., url=..., path="/api", filter=".versions", http_version="1.1", ssl=std::shared_ptr<sinsp_ssl> (use count 5, weak count 0) = {...}, bt=std::shared_ptr<sinsp_bearer_token> (use count 5, weak count 0) = {...}, blocking_socket=true) at /usr/include/c++/9/bits/char_traits.h:300
#8  0x0000555555766f77 in sinsp::update_k8s_state (this=0x555555c3cd50) at /usr/include/c++/9/ext/atomicity.h:96
#9  0x0000555555767879 in sinsp::next (this=0x555555c3cd50, puevt=0x7fffffffc0c8) at /usr/src/dev/sysdig/userspace/libsinsp/sinsp.cpp:1139
#10 0x000055555567545b in do_inspect (engine=0x555555c66ac0, outputs=0x555555c67880, inspector=0x555555c3cd50, duration_to_tot_ns=0, stats_filename=...) at /usr/src/dev/falco/userspace/falco/falco.cpp:169
#11 0x0000555555678f82 in falco_init (argc=<optimized out>, argv=<optimized out>) at /usr/src/dev/falco/userspace/falco/falco.cpp:723
#12 0x00007ffff7abebbb in __libc_start_main (main=0x555555664900 <main(int, char**)>, argc=6, argv=0x7fffffffcce8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffccd8) at ../csu/libc-start.c:308
#13 0x00005555556679ea in _start () at /usr/include/c++/9/ext/new_allocator.h:89
Thu Dec 19 07:51:48 2019: Runtime error: Error during connection attempt to https://<IP_ADDRESS> (socket=5, error=110): Connection timed out. Exiting.

@fntlnz So it should use exponential backoff retry to improve this?

Hi, we have probably the same issue. Falco 0.18.0 on GKE.
Runtime error: Socket handler (k8s_deployment_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection timed out. Exiting.

Setting dnsConfig.ndots to 1 didn't help and I did not find any relevance between restarts and CPU, memory or network usage neither.

Any update on this please, we are getting this on 0.20.0:
Runtime error: Socket handler (k8s_daemonset_handler_event) an error occurred while connecting to https://x.x.x.x: Connection timed out. Exiting.

I am also hitting this, with falco <= 0.22
Mon Apr 13 17:59:07 2020: Runtime error: Socket handler (k8s_namespace_handler_event), error 5 (Success) while connecting to apiserver:443. Exiting.

Same here, using latest Falco:
Runtime error: Error during connection attempt to https://<IP_ADDRESS> (socket=8, error=110): Connection timed out. Exiting.

Same here. Also using the latest:
Runtime error: Socket handler (k8s_replicaset_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection timed out.

Same error as well. Are there plans to address?

In what way can we help to solve this issue. Our Falco instances restart roughly once an hour due to this issue, which isn't an operational problem but does pollute our monitoring. With over 80 instances running, we get quite some restarts.
Silly thought, but can't we just catch such a connection issue, retry a few times and then just ignore instead of crash?
Info: Kubernetes 1.13 and 1.14 both gave these issues, Falco 0.21, 0.22 and 0.23, all the same.

Investigated this a bit more and after talking with @leodido we agreed that the problem here is that the library we use to enrich events with kubernetes metadata (libsinsp) does not have an extensive exception hierarchy to allow us to understand when an exception is thrown because of a connection error or something else.
Connection errors to kubernetes can happen (network can fail) but we should log the error instead of stopping Falco. At the moment we have no way to understand what are the types of errors that can stop Falco vs the types of errors that should not.
The interesting exception is here:
https://github.com/draios/sysdig/blob/master/userspace/libsinsp/socket_handler.h#L1211
To solve this, we need to connect with the community behind libsinsp and make a plan with them to make the exceptions more blatant. This needs at least a discussion on the community call too because it can be very impacting on how Falco works.
In the meanwhile, what we suggest is to let Kubernetes restart Falco when the errors occur.

/help

@leogr:
This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

on AKS
Wed Oct 14 19:48:49 2020: Runtime error: Socket handler (k8s_namespace_handler_event), error 5 (Success) while connecting to <IP_ADDRESS>:443. Exiting.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

I'm have the same issue on GKE
2021-01-18T09:58:31+0000: Runtime error: Socket handler (k8s_replicationcontroller_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection timed out. Exiting.

falco version: 0.26.2
k8s version: 1.17.14-gke400
@fntlnz is there a way to increase the timeout?
/remove-lifecycle stale

I'm have the same issue on GKE
2021-01-18T09:58:31+0000: Runtime error: Socket handler (k8s_replicationcontroller_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection timed out. Exiting.

falco version: 0.26.2
k8s version: 1.17.14-gke400
@fntlnz is there a way to increase the timeout?
/remove-lifecycle stale

I also see this issue using falco version 0.26.2 on OpenShift 4.6.4 on AWS.
Tue Jan 19 13:31:34 2021: Runtime error: Socket handler (k8s_service_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection refused. Exiting.

Mon Jan 18 22:33:58 2021: Runtime error: Socket handler (k8s_namespace_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection refused. Exiting.

I also see this issue using falco version 0.26.2 on OpenShift 4.6.4 on AWS.
Tue Jan 19 13:31:34 2021: Runtime error: Socket handler (k8s_service_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection refused. Exiting.

Mon Jan 18 22:33:58 2021: Runtime error: Socket handler (k8s_namespace_handler_event) an error occurred while connecting to https://<IP_ADDRESS>: Connection refused. Exiting.

The main issue is not only that Falco restarts due to this error (timeout or connection refused), but also because it happens tons of times... In less than 2 days, I've seen Falco pods restarting between 40 and 500 times!!
This means in the worst case scenario even 10 times/hour!!!
And the restart does not take 2 seconds, but till 2 minutes... so every hour I have 20 minutes in which Falco does not audit...

The main issue is not only that Falco restarts due to this error (timeout or connection refused), but also because it happens tons of times... In less than 2 days, I've seen Falco pods restarting between 40 and 500 times!!
This means in the worst case scenario even 10 times/hour!!!
And the restart does not take 2 seconds, but till 2 minutes... so every hour I have 20 minutes in which Falco does not audit...

Thanks to @leogr  I found what was causing my issues: the ClusterRole configuration!
Running on GKE, this is the ClusterRole I'm using currently:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: falco
rules:
  - nonResourceURLs:
      - /healthz
      - /healthz/*
    verbs:
      - get
  - apiGroups:
      - extensions
      - ""
    resources:
      - nodes
      - namespaces
      - pods
      - replicationcontrollers
      - replicasets
      - services
      - daemonsets
      - deployments
      - events
      - configmaps
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - apps
    resources:
      - daemonsets
      - deployments
      - replicasets
      - statefulsets
    verbs:
      - get
      - list
      - watch

Result: no restarts in the last 3 days :)
Unfortunately Falco put out a log of a "connection timeout" but actually it ends up having no rights to get info about either deployment, job, statefulset or else.
I think on Falco side can be improved the specific log, in order to better identify if it's a bad communication with the k8s-api-server or else (like in my case missing of rights)

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

same error
falco-lksl5   0/1     CrashLoopBackOff   42         3h3m

# pod describe
Readiness probe failed: Get http://<IP_ADDRESS>:8765/healthz: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

# pod logs
Tue Dec  7 15:31:32 2021: Loading rules from file /etc/falco/falco_rules.local.yaml:
Tue Dec  7 15:31:33 2021: Starting internal webserver, listening on port 8765
Tue Dec  7 15:33:42 2021: Runtime error: Error during connection attempt to https://<IP_ADDRESS> (socket=10, error=110): Connection timed out. Exiting.

same error, falco version 0.30.0
falco-lksl5   0/1     CrashLoopBackOff   42         3h3m

# pod describe
Readiness probe failed: Get http://<IP_ADDRESS>:8765/healthz: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

# pod logs
Tue Dec  7 15:31:32 2021: Loading rules from file /etc/falco/falco_rules.local.yaml:
Tue Dec  7 15:31:33 2021: Starting internal webserver, listening on port 8765
Tue Dec  7 15:33:42 2021: Runtime error: Error during connection attempt to https://<IP_ADDRESS> (socket=10, error=110): Connection timed out. Exiting.

It might be a different issue. Can you confirm your ClusterRole configuration is correct (see this comment above) and Falco can talk with the K8s API server?
cc @FedeDP you may be interested in this issue

@leogr @FedeDP
If your still interested in this I am seeing this error sporadically in version 0.30.0,  helm chart: 1.16.4, environment: Azure

uname -a
Linux falco-4hhd2 5.4.0-1072-azure #75~18.04.1-Ubuntu SMP Wed Mar 2 14:41:08 UTC 2022 x86_64 GNU/Linux

My cluster role file:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: falco
rules:
- apiGroups:
  - extensions
  - ""
  resources:
  - nodes
  - namespaces
  - pods
  - replicationcontrollers
  - replicasets
  - services
  - daemonsets
  - deployments
  - events
  - configmaps
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - daemonsets
  - deployments
  - replicasets
  - statefulsets
  verbs:
  - get
  - list
  - watch
- nonResourceURLs:
  - /healthz
  - /healthz/*
  verbs:
  - get

Now as far as I can see my cluster role settings match those shown from
https://github.com/falcosecurity/falco/issues/935#issuecomment-770925047

@leogr @FedeDP
If your still interested in this I am seeing this error sporadically in version 0.30.0, helm chart: 1.16.4, environment: Azure

Hey @PeterThomasAwen
Always interested in fixing bugs :smile_cat:
Anyway, let me recap. The issue should occur only when Falco tries to connect to the K8S API and there's a connection error.
Is your case a timeout or a refused connection? Furthermore, can you exclude networking issues?
I would also propose an alternative solution (that is not affected by this issue). Recent versions of Falco can collect K8s metadata even without connecting to the K8S. Falco implements a fallback mechanism to fetch K8S from the container labels when the K8S API support is disabled. The only drawback is that some metadata is not available (but the common K8s fields will still be available).
To try this you have just to set kubernetesSupport.enabled=false https://github.com/falcosecurity/charts/blob/master/falco/values.yaml#L20
Would you give it a try? If so let us know (getting your feedback is the most important thing for us)!


iroh: 0.21.0 -> 0.23.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/n0-computer/iroh/releases.
meta.description for iroh is: Efficient IPFS for the whole world right now
meta.homepage for iroh is: https://iroh.computer
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.23.0 with grep in /nix/store/brrgyqdrvm48nvgw1k813jivrxdr1gdl-iroh-0.23.0
found 0.23.0 in filename of file in /nix/store/brrgyqdrvm48nvgw1k813jivrxdr1gdl-iroh-0.23.0

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

iroh

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/4af7798d407302085fcca331ff01160997741568#iroh

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

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

1 package built:

iroh

Maintainer pings
cc @cameronfyfe for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 336429 run on x86_64-darwin 1

1 package built:

iroh


UnitTests folder take way too much time to execute

@kurtisvg reports that the Unittests/ folder takes >600m.
We should investigate and fix.

https://fusion2.corp.google.com/invocations/ebc8d9a1-cb05-4eb3-910c-43ba061f961d/targets/cloud-devrel%2Fjava%2Fjava-docs-samples%2Fjava11%2Fperiodic;config=default/log
https://fusion2.corp.google.com/invocations/116155fe-9f45-46f0-9334-1892ee58c6a6/targets/cloud-devrel%2Fjava%2Fjava-docs-samples%2Fjava11%2Fperiodic;config=default/log
https://fusion2.corp.google.com/invocations/c88c3015-05e7-4a15-8a1e-6a0dbafd86a6/targets/cloud-devrel%2Fjava%2Fjava-docs-samples%2Fjava11%2Fperiodic;config=default/log
https://fusion2.corp.google.com/invocations/bc9b672e-e538-4b24-8720-66718f84d017/targets/cloud-devrel%2Fjava%2Fjava-docs-samples%2Fjava11%2Fperiodic;config=default/log


Add Learning Outcomes

All team members must upload learning outcomes from the tools we used to learn MERN, i.e. a test website/server, proof of practice with the MERN tools.
Upload your work to the appropriate folder in the repository. Learning Outcomes folder --> [Your Name]

All team members uploaded learning outcomes


Small correction

February 2022 is incorrect... 🤔 Also 24.2 is in Beta now, in January 2023.

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] 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 change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

This has already been addressed.


Item titles appearing incorrectly

I am getting a strange issue with this extension where the labels are appearing as something else. For example, the settings page pop up, is showing avatar4eg-share-social.admin.settings.model_title for example. This is the same case across the whole extension.
Any ideas on how to resolve this?

Looks like locale files not loaded.
Could you check files in vendor/avatar4eg/share-social/locale?
And describe your configuration (flarum/php version and ext installed).

Hello,
Inside /vendor/avatar4eg/flarum-ext-share-social/locale I have an en.yml, es.yml and ru.yml
My config is as follows:
Debian 8 (Jessie)
Flarum 0.1.0-beta.5.
Nginx
PHP7
MariaDB
Thanks

To confirm, this was an issue with Cloudflares cache not clearing correctly. Despite putting it in development mode and clearing the cache manually. Thank you again.


619 variants bug

Looks good @dcolligan, thanks. We should add a test to confirm that we have implemented getVariants correctly though. test_simulated_stack is probably the best place for this. Looking at it now, we don't have any testGetVariant in there, so we should definitely fill this gap in the tests as part of this PR.

@jeromekelleher updated

@jeromekelleher fixed.  the issue was that in getVariants there was an extra call to the seeded generator before generateVariant was called, resulting in a different-state generator getting passed in and misaligning it with what is passed in to generateVariant via getVariant.

Nice, well spotted. +1.


Message context menu doesn't show up

Clicking on the circle with '...' next to a message doesn't show the contextual menu for 'Mute', 'Delete', 'Mark as Unread', 'Mark as Spam'.

Sorry a little new this but pull request with fix can be found at https://github.com/danielbuechele/goofy/pull/126
Thanks!

Ok finally fixed it, see pull request https://github.com/danielbuechele/goofy/pull/127 for fix :)

fixed


How to install Kubeshark CLI in a Docker build?

Contact Details
No response
Is your feature request related to a problem? Please describe.
When installing Kubeshark into a Docker container, the installation output is a little unpleasant, and also requests interactivity.
STEP 19/27: RUN sh <(curl -Ls https://kubeshark.co/install)
\n🦈 \033[39;44m Started to download Kubeshark \033[49;39m
######################################################################## 100.0%
\n\033[32m⬇  Kubeshark is downloaded into /home/cicd/kubeshark\033[39m
Do you want to install system-wide? Requires sudo 😇 (y/N)? stty: 'standard input': Inappropriate ioctl for device
stty: 'standard input': Inappropriate ioctl for device
stty: 'standard input': Inappropriate ioctl for device

\033[32m✅ You can use the \033[39;104m ./kubeshark \033[49;32m command now.\033[39m
\n\033[33mPlease give us a star 🌟 on \033[39mhttps://github.com/kubeshark/kubeshark\033[33m if you ❤  Kubeshark!\033[39m

An unattended install script would be useful.
Original Thread
No response
Describe the solution you'd like to see
No response
Provide additional context
No response
Code of Conduct

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

@a-h thanks for reporting this. We'll check this out

@a-h you got ENOTTY basically. Since you're inside a Dockerfile, you're not in a TTY environment. May I ask with what purpose you run sh <(curl -Ls https://kubeshark.co/install) inside a Docker build?
The shell script is designed to run on your computer. Since you're trying to installed Kubeshark CLI inside a Docker build, just simply download the correct binary from the latest release like:
wget https://github.com/kubeshark/kubeshark/releases/latest/download/kubeshark_linux_amd64

Thanks for looking into it.
@mertyildiran - I'm not sure on the logic, it's a Dockerfile I inherited. The objective is to get kubeshark into a system where it can be used to inspect data, but I can also imagine kubeshark being used in VS Code devcontainers etc.
I just noticed the output as I was building the container and it caused me a few mins of headscratching, so I thought I'd raise it.
The benefit of the install file to me is that it works out the target architecture and downloads the correct binary, and presumably adds the binary to somewhere in the $PATH. For example, if I'm building the Docker image on my M1 Mac, it would grab the ARM64 Linux binary, whereas if I'm building on my Linux x64 machine, it would grab the amd64 Linux binary.
As a consumer of builds, the "hard" bit is the minor differences in the path to the binary, e.g. when I run uname -m I get the output x86_64, but the path to the kubeshark binary contains amd64 as per https://github.com/kubeshark/kubeshark/releases/latest/download/kubeshark_linux_amd64.
Feel free to close, it might be very strange to use kubeshark in a Docker container, and it's not hard for me to download a binary direct. I thought it might be relatively easy to add a quiet / non-interactive mode on the installer script and other folks might benefit.

FWIW, I've dealt with this on other projects using the strategy of having a downloads container build stage.
It normalises the file names (aarch64 vs arm64 etc.) at the download stage, plus it also validates the sha256 hashes of the downloads.
FROM alpine:latest as downloads

# Install curl.
RUN apk add curl

# https://explainshell.com/explain?cmd=curl+-fsSLO+example.org
WORKDIR /downloads
RUN curl -fsSLO https://download.docker.com/linux/debian/gpg
RUN curl -fsSL -o awscli_amd64.zip https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.7.16.zip
RUN curl -fsSL -o awscli_arm64.zip https://awscli.amazonaws.com/awscli-exe-linux-aarch64-2.7.16.zip
RUN curl -fsSL -o go_amd64.tar.gz "https://go.dev/dl/go1.18.3.linux-amd64.tar.gz"
RUN curl -fsSL -o go_arm64.tar.gz "https://go.dev/dl/go1.18.3.linux-arm64.tar.gz"

# Create a sum of all files.
RUN find . -type f -exec sha256sum {} \; >> /downloads/current_hashes.txt
RUN cat /downloads/current_hashes.txt

# Compare to past hashes.
COPY past_hashes.txt /downloads
RUN sha256sum -c past_hashes.txt

Then in the next stage of the Dockerfile, it grabs the relevant architecture. dpkg is Debian specific though.
FROM node:16
# Based on Debian buster.

COPY --from=downloads /downloads /downloads

# Use the specific architectures.
RUN mv "/downloads/awscli_$(dpkg --print-architecture).zip" /downloads/awscli.zip
RUN mv "/downloads/go_$(dpkg --print-architecture).tar.gz" /downloads/go.tar.gz

@a-h as you have suggested the correct commands would be something like:
RUN curl -Lo kubeshark https://github.com/kubeshark/kubeshark/releases/latest/download/kubeshark_linux_$(dpkg --print-architecture) && chmod 755 kubeshark
RUN mv ./kubeshark /usr/local/bin/kubeshark

So, there is no need to change https://kubeshark.co/install since the script is interactive and the download of the correct binary can be managed in a Dockerfile quite easily.


Load Asset LOP: Easy access to set primitive path to the folder name

Changelog Description

Working with the folder name as root primitive as name is crucial for asset build because we want to work within that correct default primitive (that in AYON USD contribution workflow) and hence the Asset Structure we have defined according to the USD Asset Structure guidelines must exist within the default prim {folder_name}.

This PR adds a hidden folder_name parameter so users can easily reference it using chs("folder_name").
This PR adds a "Presets" box next to the Primitive Root parameter to easily pick a nice default:

Additional info

Questions:

Should folder name be visible instead and locked maybe? So it's clear that the parm exists users can right click it to copy reference?->  ✅ Done with https://github.com/ynput/ayon-houdini/pull/54/commits/0c0e4334832aa3f2c5600ac2c5510ba0bc0e590c
Should the default value for Primitive Root be chs("folder_name") instead so that it has a sensible default for ASSET BUILD instead of a sensible default for SCENE ASSEMBLY? (Especially because scene assembly may be done via stage managers or whatever in Houdini anyway?) -> ⚠  If we want this we'll do it in a separate PR because it'll be a Backwards Incompatible change for existing load asset lop nodes in the scene that have no explicit override set to primpath1 parm.

This PR took me way more time than I planned. Seemed like a SIMPLE thing to implement but I faced a Houdini bug where I was incapable of setting the value on primpath1 whenever it explicitly referenced another parm. (Even with hou.Parm.set(follow_parm_reference=False) it didn't work, nor the recommended Parm.deleteAllKeyframes() call would not help).
Houdini Bug: 139806 can't set string parameters that are referencing another parm currently
It's reported as Houdini bug: 139806 - for what it's worth, SideFX confirmed it's a bug and the only workaround for string parms is to use hscript then using the opparm command since it does NOT set it on the referenced parms.

Note that the follow_parm_references argument to hou.Parm.set() only works for the form used for setting channel references when the value is a hou.Parm (or hou.ParmTuple when working with parm tuples), so if that's not what you're doing, it's misleading to include it.  The set methods that take an constant value always follow channel references because they do not actually replace channel expressions.  There is definitely something missing here, but in the meantime, you can use the hscript equivalent as a workaround.
The opparm hscript command doesn't follow channel references by default, and it also deletes any channels by default prior to setting the value, so it can be used to work around this issue by invoking it with hou.hscript().
You could just always use it, or use the parm.deleteAllKeyframes() approach for everything but string parameters, depending on your needs.
Something along the lines of
if isinstance(parm.parmTemplate(), hou.StringParmTemplate):
    hou.hscript("opparm " + parm.node().path() + " " + parm.name() + "('" + "new_value" +  "')")
else:
    # the deleteAllKeyframes() approach

Testing notes:

Create Load Asset LOP.
Primitive Root presets should be clear and usable.

@antirotor @Lypsolon @MustafaJafar could you check the "Questions" in the additional notes and maybe answer from your perspectives?

Should the folder name be visible instead and locked, maybe? So it's clear that the parm exists. Users can right-click it to copy references.

My personal opinion is that everything important for automation should probably be hidden. My reason for this is that a user might accidentally delete something in the parm and then get confused about what is happening, and this could be a pain to debug.
However, the argument that copying relative references would be nice is good. I think it might be an option to store all the creations into one(dict, maybe ?) or a few parts that aren't available for the user but only for the developer.
then we could have a few "expose" parms that allow the copy reference options without risking deleting something important. (but this might be a bit overcomplicated)

Should the default value for Primitive Root be chs("folder_name") instead so that it has a sensible default for ASSET BUILD instead of a sensible default for SCENE ASSEMBLY? (Especially because scene assembly may be done via stage managers or whatever in Houdini anyway?)

That's a good question. And I kinda see two answers.
A: we could have a "template" in the loader where we have two options on right click one "asset load" and the second "asset shot import" or something like that. and then set the default from this. (might make the UI UX complicated)
B: if we assume that shot build will be handled mainly with other tools other other "automation" then I think the Asset Build default might be the most straight forward way.

Works and also updates already existing asset lops (not sure if that's wanted)

It should be completely backwards compatible (it shouldn't break loaded content currently) so yes, that's the preferred behavior. Or did you encounter issues with it being updated?

Why would I want to copy the primitive root parameter ? As far as I know, the workflow (currently) expects exact hardcoded values to work properly, and copying that parameter may break something ?

Sorry, not sure what you're referring to? Are you referring to me asking about whether to make folder_name visible or not. That wasn't necessarily targetted at the Primitive Root parameter at all. But just so users have easy access to the folder name to do whatever they want with that.

Why would I want to copy the primitive root parameter ? As far as I know, the workflow (currently) expects exact hardcoded values to work properly, and copying that parameter may break something ?

Sorry, not sure what you're referring to?

I was referring to https://github.com/ynput/ayon-core/pull/295#issuecomment-2179046023
So, do I have to have primitive root path as folder_name ?

So, do I have to have primitive root path as folder_name ?

If you're doing "asset" build work, like adding geometry, shaders, grooms to the USD asset then you'll want to work within the asset's structure which is the default prim {folder_name}. In that case you want to use that as the primitive path that you're loading and also make sure that any shaders or other things you create in your Look scene or alike to be INSIDE that root primitive.
Does that make more sense?
If that means nothing is blocking this @MustafaJafar can you still approve?


Feature request: add median, mode & number of unique entries to pandas.DataFrame.describe()

Would come in handy for a number of a different applications from basic statistics, to understanding one's data, to estimating machine learning algorithmic load.
dupe of #2749

median out-of-the-box would really be a great thing to have!

Note that median is already in describe, as in 50%

@jorisvandenbossche indeed! Sorry, my bad. :baby:

Hijacking this issue to propose a variant (and steal more from dplyr)
Why not have a DataFrame.agg that is identical to DataFrame.groupby.agg, but with a "single group"? This also goes along with the new .resample.agg, yay for synergy. Basically it takes a function/str or list of functions/strs or a dict of column names to functions/str and aggregates accordingly.

Related to https://github.com/pydata/pandas/issues/1623


Failed building wheel for flash-attn

creating build/lib.linux-x86_64-cpython-38/flash_attn/losses
copying flash_attn/losses/cross_entropy_parallel.py -> build/lib.linux-x86_64-cpython-38/flash_attn/losses
copying flash_attn/losses/init.py -> build/lib.linux-x86_64-cpython-38/flash_attn/losses
copying flash_attn/losses/cross_entropy.py -> build/lib.linux-x86_64-cpython-38/flash_attn/losses
copying flash_attn/losses/cross_entropy_apex.py -> build/lib.linux-x86_64-cpython-38/flash_attn/losses
running build_ext
/data/home/xuncai/anaconda3/envs/llm/lib/python3.8/site-packages/torch/utils/cpp_extension.py:387: UserWarning: The detected CUDA version (11.0) has a minor version mismatch with the version that was used to compile PyTorch (11.6). Most likely this shouldn't be a problem.
warnings.warn(CUDA_MISMATCH_WARN.format(cuda_str_version, torch.version.cuda))
/data/home/xuncai/anaconda3/envs/llm/lib/python3.8/site-packages/torch/utils/cpp_extension.py:397: UserWarning: There are no g++ version bounds defined for CUDA version 11.0
warnings.warn(f'There are no {compiler_name} version bounds defined for CUDA version {cuda_str_version}')
building 'flash_attn_cuda' extension
creating /tmp/pip-install-vtz3lk_i/flash-attn_38dfe6a6d0904a369d24c5ba53f9d63c/build/temp.linux-x86_64-cpython-38
creating /tmp/pip-install-vtz3lk_i/flash-attn_38dfe6a6d0904a369d24c5ba53f9d63c/build/temp.linux-x86_64-cpython-38/csrc
creating /tmp/pip-install-vtz3lk_i/flash-attn_38dfe6a6d0904a369d24c5ba53f9d63c/build/temp.linux-x86_64-cpython-38/csrc/flash_attn
creating /tmp/pip-install-vtz3lk_i/flash-attn_38dfe6a6d0904a369d24c5ba53f9d63c/build/temp.linux-x86_64-cpython-38/csrc/flash_attn/src
error: [Errno 8] Exec format error: 'c++'
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for flash-attn
Running setup.py clean for flash-attn
Failed to build flash-attn
ERROR: Could not build wheels for flash-attn, which is required to install pyproject.toml-based projects

Sounds like some mismatched CUDA version as mentioned in the warning (CUDA 11.0 vs 11.6).
We require CUDA 11.4 or later.
We recommend the Pytorch container from Nvidia, which has all the required tools to install FlashAttention.

Which Pytorch container? Is there a minimum version? I tried with 20.10 and it did not work

I usually use the newest one (e.g. 23.05). I think anything from 22.05 (when FlashAttention was released) should work.

I use nvcr.io/nvidia/pytorch:23.02-py3, still error.


max_n_samples in add trace(s) seems to do nothing with plotly-resampler=0.8.1

I was able to pinpoint the issue, and it seems that this line within AbstractFigureResampler causes the issue:
super(self._figure_class, self).add_trace(trace, **trace_kwargs)

Which calls the BaseTraceDatatype its add_trace method, which on its end:

calls self.add_trace (bringing us back to the AbastractFigureResampler class, and as a result, the trace will be aggregated.

Solved in #127


Range for loop over header copies the fields::value_type incorrectly

Beast version :- 90
Branch :- master
Code which reproduces the issue:
#include <iostream>
#include "beast/http/message.hpp"
using namespace boost;

void headers_test_works()
{
  beast::http::request_header<> h;
  h.set("a", "b");
  auto h2 = std::move(h);

  for (auto& e : h2) {
    std::cout << e.name_string() << '\n';
  }
}

void headers_test_does_not_work()
{
  beast::http::request_header<> h;
  h.set("a", "b");
  auto h2 = std::move(h);

  for (auto e : h2) {
    std::cout << e.name_string() << '\n';
  }
}

int main() {
  headers_test_works();
  headers_test_does_not_work();
  return 0;
}

Output:

ArunMu:field-copy amuralid$ ./test_params
a
�

Compiled as:

g++ -I beast/include/ -I beast/include/boost  -std=c++14 -o test_params test_params.cc -lboost_system

If the basic_fileds::value_type is not meant to be copyable, then I would like to get a compiler error by deleting its copy constructor. Else, if the intention for it to be is to model regular type, then the copy constructor needs to be implemented correctly.

Yes, you are right! It seems I forgot to delete the copy members, the basic_fields::value_type is not copyable because it doesn't own its strings.

The fix will go into version 92, here https://github.com/boostorg/beast/pull/698

Cool, thanks.
Amazing library! Thanks for all your efforts.


pip3 install error

Hi When I run pip3 install guppy, I get the following error:
Downloading/unpacking geopy
Downloading geopy-1.11.0-py2.py3-none-any.whl (66kB): 66kB downloaded
Installing collected packages: geopy
Cleaning up...
Exception:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/basecommand.py", line 122, in main
status = self.run(options, args)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/commands/install.py", line 283, in run
requirement_set.install(install_options, global_options, root=options.root_path)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/req.py", line 1435, in install
requirement.install(install_options, global_options, *args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/req.py", line 671, in install
self.move_wheel_files(self.source_dir, root=root)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/req.py", line 901, in move_wheel_files
pycompile=self.pycompile,
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/wheel.py", line 207, in move_wheel_files
clobber(source, lib_dir, True)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip/wheel.py", line 194, in clobber
os.makedirs(destsubdir)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/os.py", line 244, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/geopy'
Can anyone help me understand what is going wrong? Thanks in advance.

Just realized the apple integrity protection, I used sudo install to get it done. Can someone please close it? Thanks!


issue with routing masquerading off

Hi guys, we´ve following setup
Client A (Peer) , netbird agent installed, private ip <IP_ADDRESS>, netbird ip <IP_ADDRESS>
Client B (Routing Peer), netbird agent installed, private ip <IP_ADDRESS>, netbird ip <IP_ADDRESS>
Client C (Webserver), no netbird agent installed, private ip <IP_ADDRESS>
If we add routes for <IP_ADDRESS>/24 and <IP_ADDRESS>/24, masquerading enabled on manager and add Client A & Client B to the Distribution group. We are able to communicate between Client A and Client B (via private ip and netbird ip), and it´s also possible to communicate from Client A to Client C. But Client C can´t reach Client A.
If we add routes for <IP_ADDRESS>/24 and <IP_ADDRESS>/24, masquerading disabled on manager and add Client A & Client B to the Distribution group. We are able to communicate between Client A and Client B (via private ip and netbird ip). But now we are unable to communicate from Client A to Client C and vice versa.
We tried to add a manually route on Client C for the netbird vpn subnet, to route the traffic to routing peer <IP_ADDRESS>. But this is also not working.
We didn´t find more details about the required configuration in the documentation. Would be great if someone has an idea to solve the routing issue.
Regardsm
Harald

Sorry forget to mention our goal ;) We need to communicate from Client A to Client C and vice versa while masquerading is disabled

I just tried the same and got the same result. I'd love to see A<->C (in both directions) communication working until the BSD (opnsense) client is fully working.


Static nodeport configuration  for ingress resourse

Hi all,
I  just pull the latest version with the static nodeport assignment functionality  fixed.  Unfortunately i still cannot configure the ingress resource to assign a specific port to the type: nodeport. Is there a documentation for this ?

Hi, this feature has been implemented in master and will be part of 3.2.0 release. We are yet to update the docs. If you want to test it out, you can use the image tag appscode/voyager:3.2.0-beta.2 . This is what an example Ingress looks like:

Perfect thank you very much

Hi tamalsaha,
I think i might jumped the gone on this, but i was actually asking if there was a way to set a static port for the ingress resource above and not have the port change every time i update the ingress resource.
so following your example above, If i updated the ingress resource with an additional path
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
name: test
namespace: default
annotations:
ingress.appscode.com/type: NodePort
spec:
rules:

host:
http:
paths: /test

backend:
serviceName: test-server
servicePort: 80
nodePort: 32068
paths: /testing
backend:
serviceName: test-server-2
servicePort: 80
So i am basically asking for the ability to have one static port for entry into the cluster and not to a service.

@izutheo , sorry I misspoke last time. You can only set one static port for each HAProxy port (which is the entry to the cluster). If you look at the Go struct, the nodePort is set for a host:port combination.
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: test
  namespace: default
  annotations:
    ingress.appscode.com/type: NodePort
spec:
  rules:
  - host:
    http:
      nodePort: 32068
      paths:
      - path: /t1
        backend:
          serviceName: t1-server
          servicePort: 80
      - path: /t2
        backend:
          serviceName: t2-server
          servicePort: 80

I have pushed a new image with tag appscode/voyager:3.2.0-beta.3 , this has some important fixes from (#394). Please try with that.

Thank you very much

@tamalsaha
I am having the same issue as the one documented above. Instead of having one port per host via nodeport port  and having multiple static ports as the number of host increases.
is it possible to have one static port for all host.
using your example on github,
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
name: haproxy
namespace: default
spec:
backend:
headerRule:
- X-Forwarded-Host %[req.hdr(Host)]
- X-Forwarded-Port %[dst_port]
- X-Forwarded-Proto https
serviceName: phabricator
servicePort: "80"
rules:

host: maven.example.com
http:
paths:

backend:
rewriteRule:

^([^\ :])\ /(.)$ \1\ /maven/\2
serviceName: artifact-server
servicePort: "80"

host: composer.example.com
http:
paths:

backend:
rewriteRule:

^([^\ :])\ /(.)$ \1\ /composer/\2
serviceName: artifact-server
servicePort: "80"

host: npm.example.com
http:
paths:

backend:
rewriteRule:

^([^\ :])\ /(.)$ \1\ /npm/\2
serviceName: artifact-server
servicePort: "80"

host: docker.example.com
http:
paths:

backend:
rewriteRule:

^([^\ :])\ /(.)$ \1\ /docker/\2
serviceName: artifact-server
servicePort: "80"

host: api.example.com
http:
paths:

backend:
serviceName: authserver
servicePort: "9021"
path: /kubernetes/v1beta1/webhooks

host: auth.example.com
http:
paths:

backend:
serviceName: example-loginserver
servicePort: "7070"
path: /oauth

host: auth.example.com
http:
paths:

backend:
headerRule:

X-Client-IP %[src]
rewriteRule:
^([^\ ])\ /client-ip/(.)     \1\ /\2
serviceName: client-ip
servicePort: "60010"
path: /client-ip

host: '*.example.info'
http:
paths:

backend:
serviceName: aphlictserver
servicePort: "22280"
path: /_org/ws

host: api.example.com
http:
paths:

backend:
rewriteRule:

^([^\ :])\ /(.)$ \1\ /_org/api/\2
serviceName: example-apis
servicePort: "9866"
path: /onebox

host: api.example.com
http:
paths:

backend:
rewriteRule:

^([^\ :])\ /(.)$ \1\ /_org/api/\2
serviceName: apiserver
servicePort: "9877"

host: '*.example.info'
http:
paths:

backend:
serviceName: apiserver
servicePort: "9877"
path: /_org/api

host: '*.example.info'
http:
paths:

backend:
serviceName: ui-server
servicePort: "80"
path: /artifactory

host: '*.example.info'
http:
paths:

backend:
serviceName: ui-server
servicePort: "80"
path: /ui-server

host: '*.example.info'
http:
paths:

backend:
serviceName: ui-server
servicePort: "80"
path: /ci

host: '*.example.info'
http:
paths:

backend:
serviceName: grafana
servicePort: "3000"
path: /grafana

host: '*.example.info'
http:
paths:

backend:
headerRule:

Cache-Control public
serviceName: ui-server
servicePort: "80"
path: /_org/assets

host: jenkins.example.com
http:
paths:

backend:
serviceName: jenkins-service
servicePort: "80"

host: api.example.com
tcp:

backend:
serviceName: apiserver
servicePort: "50077"
port: "3443"
secretName: cert-example-com

host: api.example.com
tcp:

backend:
serviceName: example-apis
servicePort: "50066"
port: "3553"
secretName: cert-example-com

host: diffusion.example.com
tcp:

backend:
serviceName: phabricator
servicePort: "22"
port: "22"
tls:

hosts:

auth.example.com
maven.example.com
composer.example.com
npm.example.com
docker.example.com
api.example.com
jenkins.example.com
'*.example.info'
secretName: cert-example-com

hosts:

'*.example.info'
secretName: cert-example-info

Can i configure one frontend that uses one static port to route trafic to all the backends above or can i sett one singular nodeport to route traffic into a cluster with the above config.

@colltrix35 , which version of Voyager are you using? can you show us the service that is created by voyager?

The latest version

I don't have a service yet i am still working  through the examples on github  and   got stuck here.

Ok. See my reply earlier in this ticket: https://github.com/appscode/voyager/issues/400#issuecomment-323494395 .
Voyager will open a separate NodePort for each HAProxy port, not for each HTTP host. You can server multiple HTTP host from a single port. Please also note that this feature is going to be available in the next release of 3.2.0. You can try with beta image for now appscode/voyager:3.2.0-beta.3

@tamalsaha  My question was because  of the sol you provided for @izutheo
You explanation above is exactly what i am looking for but the configuration that you provided to izutheo above  seems to be relegated per host
I am not  a go program so i cannot really follow the code like other individuals here. so if you can point me to a documentation that can help with that configuration, it would be helpful.


Wait for juttle-engine to start in each unit test.

While running this locally, I noticed races where juttle-engine would
be started but the http server wasn't accepting connections yet,
leading to errors like:
Error: connect ECONNREFUSED <IP_ADDRESS>:10000
at Object.exports._errnoException (util.js:874:11)
at exports._exceptionWithHostPort (util.js:897:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1063:14)
Fix this by waiting until a client can fetch /api/v0/version-info and
get an 200. Use bluebird-retry to retry the fetch.
@demmer @go-oleg

lgtm


fix(janus-idp/cli): fixes issue with missing configSchema.json

The problem was that plugins in @backstage-community were accidentally ignored when searching for config schemas because startsWith('@backstage') was used as a main filtering rule.
So, when the @backstage-community namespace was introduced and plugins were migrated to it, it started to ignore them.
This simple fix ensures that only packages in the core @backstage can be filtered out.
Fixes: https://issues.redhat.com/browse/RHIDP-3574

/cherrypick release-1.3


YubiKey Manager not displaying GUI

Yubico Authenticator version:
Operating system and version:
YubiKey model and version:
Bug description summary:

Steps to reproduce
I had used it once to originally set up my YubiKey but ever since it has been set up I haven't needed to mess with it. Now I'm required to update my certs but the manager will not display. I have tried rebooting, uninstalling, and the commands from #673 and #678 . The problem is consistent and recreates every time I try to open the manager.
[Please explain what you did when the bug appeared, and if and how you have been
able to reproduce it.]
Expected result
I expected the Manager GUI to display so that I could use it.
[What did you expect to happen when you did the above?]
Actual results
When the app is opened it displays the Yubico Icon on the taskbar but there is no window that displays on the screen. I can hover over the Icon and it will show the preview of the window but it's just a blank white square.
[What actually happened?]
Other info
As noted above this is very similar to issues #673 and #678 however I noticed that one of the solutions from 678 was to run a set of commands. Unfortunately when I navigate to C://Program Files/Yubico I only have Yubikey Manager as a subfolder. I do not have Yubikey Authenticator. When I ran the below commands:
C:\Program Files\Yubico\YubiKey Manager>set QT_OPENGL=software
C:\Program Files\Yubico\YubiKey Manager>ykman-gui.exe
I got an error the first time but now I cannot recreate it. By running the commands it simply pulls up the same issue, a taskbar icon with a blank white square.
[Anything else you would like to add?]

Hi,
Can you post a picture of how it looks for you? Also, try running with --log-level DEBUG --log-file out.txt and see what has been written to out.txt. You might have to run this command as an administrator, since it will create and write to out.txt.


05/06/2018 17:51 : Create Pull Request for branch prTesting_2018050617 -> master

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

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


auth0.refreshToken() is gone

This code no longer TS compiles due to the change in the Auth0 API that removed the refreshToken method:
https://github.com/auth0-samples/auth0-ionic2-samples/blob/master/01-Login/src/services/auth/auth.service.ts#L158
Is there an example of using auth-0.js to background refresh a token like this sample did? I've looked through the other samples and haven't found it yet.

It looks like renewAuth is the new method: https://github.com/auth0/auth0.js#api
But it seems to need a callback URL which involves loading the Ionic SPA in an iframe and communicating back to the main frame:

It is strongly recommended to have a dedicated callback page for silent authentication in order to avoid loading your entire application again inside an iframe. This callback page should only parse the URL hash and post it to the parent document so that your application can take action depending on the outcome of the silent authentication attempt.

I'm not sure how best to proceed...

@saschwarz  - I ran into the exact same concern.  Ionic is primarily a hybrid mobile app tech, but can be used as pure web too.  In my case we want the same code to be used for both.  So for refresh tokens on devices we're just hitting the Auth0 delegation endpoint directly with the refresh token.  Sounds like this might be the best option for now.
https://auth0.com/forum/t/ionic-2-quickstart-old-auth0-dependencies/5688

@brassier thanks a lot for the feedback! I went through the links in that discussion and it seems I can't use the auth0 v8 API directly. Looking in Auth0's site I couldn't find any docs on that Auth0 endpoint; if you could point me at it I'd really appreciate it.  IIUC you're saying I should use Http to directly interact with the endpoint(?)

I'm no expert on this, but your take on it is similar to mine.  Just use HTTP to hit this delegation endpoint.  Likely not the most secure of options, but it may be the best option for now.
The inputs you mention are the same as what I'm requesting, except that I also request a scope.  Scope may not be required though.

I would love to see the Cordova SDK expanded to include the refresh token to avoid confusion. Switching back between the Cordova SDK, auth-0.js, and the API is incredibly confusing and wastes a lot of investigation time when you don't realize that certain parts of the SDKs are missing and calls in auth-0.js aren't appropriate for mobile app scenarios - but the auth-0.js SDK is included in the example!

We found that the suggested Ionic and Auth0 integration changed quite a bit since this issue was opened, likely due to the Auth0 OIDC conformant push.  We are no longer doing refresh tokens on the web side, only on the native side (for security reasons).  We are also doing PKCE for native via the Auth0 cordova sdk, and a SPA workflow for pure-web.  We effectively have two different authentication approaches in the same app: 1 for web, 1 for native.  Seems to work fine though, and likely more secure than the other approach.  For documentation, the Cordova/PKCE approach is documented in the latest ionic quickstart.  A web version can be found by looking at the Angular 2 quickstart.


Adds derivedConstantsDependencies for rts

Building rts depends on derived constants, as we can not rely on the compiler to be build prior to rts,
as we build rts with gcc, and hence do not depend on ghc, we need to have rts depend on the derived
constants. This fixes #94. However, if we are going to build rts with the stage1 ghc, this should not be
an issue anymore (see #90), as derived constants would be build then anyway. Yet I do not see any
problem with explicilty noting down the derived constants dependency for rts.

Thanks, this looks good. I think we finally have a sensible representation of generated dependencies.


Doesn't work anymore in current Nim

Current Nim from devel branch, import emerald throws this:
/home/deen/.nimble/pkgs/emerald-0.2.2/emerald/html.nim(299, 32) Error: expression 'quit "[emerald] " & lineInfo(node) & ": Unexpected " &
    "command (expected replace, prepend or append)" & ": \"" &
    $ident_name(node[0]) & "\"", 1' is of type 'NimNode' and has to be discarded

After the fixed in august the version number didn't get raised, so nimble still pulls the old version. @flyx please bump the version number

Version number bumped (sorry for the really long ping).


RefreshTokenService does not send client secret. Unable to refresh token

RefreshTokenService interface in RefreshTokenClient is defined as the following :
private interface RefreshTokenService {
@FormUrlEncoded
@POST("{tenant}/oauth2/token")
Observable refreshToken(
@Path("tenant") String tenant,
@Field("client_id") String clientId,
@Field("grant_type") String grantType,
@Field("resource") String resource,
@Field("refresh_token") String refreshToken);
While the {tenant}/oauth2/token endpoint is expecting a client_secret parameter.
This causes a "401 Unauthorized" response which blocks from refreshing the token.

Hi @amitbaer We just fixed this in our 1.6.13 version of azure-client-authentication: https://github.com/Azure/autorest-clientruntime-for-java/releases/tag/v1.6.13. Please give it a try.

HI @amitbaer we believe this issue to be fixed in the latest azure-client-authentication.  Please feel free to reactivate the github issue if there's another problem, this update doesn't resolve your original problem as we believe it should, or if there has been any misunderstanding on our part.
Thanks,
Josh


fix(lua-protobuf): enable encode_default_values to avoid breaking behavior

Summary
The lua-protobuf has a breaking change after upgrading to 0.4.2 from 0.3.3, which breaks one test case in an internal repository.
-- test.lua
local pb = require "pb"
local protoc = require "protoc"

assert(protoc:load [[
syntax = "proto3";
message RequestMetadata {
  string client_ip = 1;
  uint64 started_at = 2;
  RouteInfo route = 3;
  AuthInfo auth = 4;
}
message RouteInfo {
  string id = 1;
  string name = 2;
}
message AuthInfo {
  string id = 1;
  string type = 2;
}
]])

local payload = {
  auth = nil,
  route = {
    id = "",
    name = ""
  },
}
--pb.option("encode_default_values")
local bytes = pb.encode("RequestMetadata", payload)
local decoded = pb.decode("RequestMetadata", bytes)
print(require("cjson").encode(decoded))

Output of lua-protobuf 0.4.2
$ lua test.lua

{"client_ip":"","started_at":0}

Output of lua-protobuf 0.3.3
$ lua test.lua

{"client_ip":"","started_at":0,"route":{"id":"","name":""}}

Output of lua-protobuf 0.4.2 with pb.option("encode_default_values")
$ lua test.lua

{"client_ip":"","started_at":0,"route":{"id":"","name":""}}

Could it be the other way around, that we should interpret omitted values as default values?

Could it be the other way around, that we should interpret omitted values as default values? I seem to remember we have had an issue related to the default value emitting. @javierguerragiraldez

But it might be good so we have no ambiguity and headaches handling omitted values.

defaults are very hard, and this being a global setting means that any change will definitely affect all uses.  perfect recipe for disaster.
the standard specifies that for scalar values, missing elements are to be interpreted as the default value.  It also specifies that "there’s no way of telling whether a field was explicitly set to the default value (for example whether a boolean was set to false) or just not set at all"

...once a message is parsed there’s no way of telling whether a field was explicitly set to the default value [] or just not set at all
For example, don’t have a boolean that switches on some behavior when set to false if you don’t want that behavior to also happen by default.
Also note that if a scalar message field is set to its default, the value will not be serialized on the wire.

From this, we could say that:

the 'encode_default_values' option is non-standard.

any "fix" that depends on default valued being present or not covers an input requirement.  That makes for a very fragile protocol.

... but all this is only for scalar values.  "For message fields, the field is not set. Its exact value is language-dependent."  I guess that's because on static languages, the "empty" value of a static structure has empty values on all it's fields, while on dynamic languages, the "empty" structure is an empty hash table.
for wRPC, i had to do a lot of post-decoding massaging because the config functions depend on the presence of empty tables for all the main sections, and the JSON configurations reflect that, but the protobuf encoding didn't.
In this case, it's not about our protocol, but on the user's, so we can't preach on "how should the receiving end behave".  Perhaps it requires all values to be present... perhaps it does care about the difference between default and missing.
Personally, I think unconditionally adding them is just as dangerous as removing them.  If the option is between always adding the values and always stripping them, I would first try with always stripping, since that's the published specification.
The only defensible deviation from standard would be to reflect the incoming data, and including them if they're present in the input.  I don't know if the current version allows for that.

@javierguerragiraldez
Another way is to change that broken test case of the internal repository, which may break the different teams. And I'm also concerned that this may also break the users too if they are relaying the previous library behavior.

Please make a decision, remove the pr/do not merge label and merge.

Option
Description

...
...

auto_default_values
act as use_default_values for proto3 and act as no_default_values for the others (default)

no_default_values
do not default values for decoded message table

use_default_values
set default values by copy values from default table before decode

...
...

From official documentation.
And here's a result of search:
9 results - 3 files

kong/tools/grpc.lua:
  42  local function set_hooks()
  43:   pb.option("enable_hooks")
  44

spec/03-plugins/37-opentelemetry/01-otlp_spec.lua:
  48      -- overwrite for testing
  49:     pb.option("enum_as_value")
  50:     pb.option("auto_default_values")
  51    end)

  54      -- revert it back
  55:     pb.option("enum_as_name")
  56:     pb.option("no_default_values")
  57    end)

spec/03-plugins/37-opentelemetry/04-exporter_spec.lua:
  36        -- overwrite for testing
  37:       pb.option("enum_as_value")
  38:       pb.option("auto_default_values")
  39      end)

  42        -- revert it back
  43:       pb.option("enum_as_name")
  44:       pb.option("no_default_values")
  45      end)

My guess is the pb.option in tests makes them flaky and dependent on the order of tests. However, we cannot have multiple copies of pb state, and we can neither store the original setting to restore it after (we are assuming no_default_values is the previous state and blindly set it).
The short-term solution could be to fix the specific test, using the same save and restore method.

I did a quick test and looks like the encoded bytes also changed.
--  The example proto on PR description

--pb.option("encode_default_values")
local bytes = pb.encode("RequestMetadata", payload)
print("bytes after pb.encode() using resty.string#to_hex：", str.to_hex(bytes))
print("bytes after pb.encode() using pb.tohex: ", pb.tohex(bytes))

local decoded = pb.decode("RequestMetadata", bytes)
print("decoded table from encoded bytes", require("inspect")(decoded))

Output of lua-protobuf 0.4.2
$ resty test.lua

bytes after pb.encode() using resty.string#to_hex：
bytes after pb.encode() using pb.tohex:
decoded table from encoded bytes{
  client_ip = "",
  started_at = 0
}

Output of lua-protobuf 0.3.3
$ resty test.lua

bytes after pb.encode() using resty.string#to_hex：1a00
bytes after pb.encode() using pb.tohex: 1A 00
decoded table from encoded bytes{
  client_ip = "",
  route = {
    id = "",
    name = ""
  },
  started_at = 0
}

Output of lua-protobuf 0.4.2 with pb.option("encode_default_values")
$ lua test.lua

bytes after pb.encode() using resty.string#to_hex：1a040a001200
bytes after pb.encode() using pb.tohex: 1A 04 0A 00 12 00
decoded table from encoded bytes{
  client_ip = "",
  route = {
    id = "",
    name = ""
  },
  started_at = 0
}

Add to 3.3.0 milestone as the EE has a dirty fix during bump up lua-protobuf(https://github.com/Kong/kong-ee/pull/4698/commits/a0aed772f8069fd8bb928425ec6275ef8fdec024), and need to be reverted and waiting this one merged.

@vm-001 Should this still have the "Do not merge" label? If we don't start working on it soon, it will lose the 3.3 train

@vm-001 does this PR belong to any ticket?
I have read this carefully and I think I agree with @javierguerragiraldez .
The TLDR of this is: the lua-protobuf change from 0.3.3 to 0.4.2 does not look like a breaking change, but like a fix (the library was doing something in 0.3.3 which is not part of the standard, that is, always adding default values to parameters, which is non-standard behavior).
The config option  encode_default_values seems to be there as "backwards compatibility layer for people relying on that non-standard behavior". Setting it "globally" (as it's being done here, or in https://github.com/Kong/kong-ee/commit/a0aed772f8069fd8bb928425ec6275ef8fdec024) would be a valid "quickfix" if we were (the Kong developers) where the only users of the library and needed the non-standard behavior.
However, we are not the only users. We have a couple plugins out (gRPC-gateway and gRPC-web) which other people use. Using the global setting (or keeping using 0.3.3) will give them non-standard behavior, which we should avoid if possible.
I see two options:

If we (Kong) don't need the default values explicitly set on all the messages, we should remove them (close this PR without merging, and also revert the quick hack in https://github.com/Kong/kong-ee/commit/a0aed772f8069fd8bb928425ec6275ef8fdec024 )
If we (Kong) do need the default values set on some messages, then we should refrain from using the global setting, and set the default values when needed in "spot places". It seems the pb.defaults() function might be used to "fill in the default values" in this fashion (I am unclear about this, the docs for this function are not very good).

@javierguerragiraldez , could you validate my evaluation?

Using the global setting (or keeping using 0.3.3) will give them non-standard behavior, which we should avoid if possible.

full agree on this.   since it's a global setting and the effects are visible to users, the closer it is to the standard, the better.
if going closer to the standard than it was possible in previous versions breaks something, then that something is buggy and should be fixed.
as mentioned, for wRPC i had to do post-decoding massaging because the config loader is fragile in that sense.  fortunately, that code is gone now, so it's one less variable.

@kikito This one doesn't belong to any ticket. The library's behavior change was caught by EE test case.
I created EE PR(https://github.com/Kong/kong-ee/pull/5276) for taking the first option, and also ping other team to evaluate.
Thanks. @kikito @javierguerragiraldez

@vm-001 since we are going to go with option 2, I will close this ticket. Please reopen if needed.

I saw you approve the EE PR, which is option 1. Are taking option 1?


Module exports need to be reorganised

Most people (I think) will only need the high level objects, so it doesn’t make sense to bundle the millions of APIFooBar exports with the main module entrypoint. If you do need the API and related types, I think those should be a separate import.
Thinking maybe this:
src/
| api.ts — exports createAPI and co.
| mod.ts — exports createClient and the other objects

Currently:

I keep experimenting with this. There will be 3 entrypoints:

api.ts - API & co
mod.ts - Client stuff
all.ts (or full.ts)  - exports both of those

Problem:createClient can also take an API. I cannot find a way for doc.deno.land to link the type in the signature to api.ts instead of models/mod.ts >:/


chore: convert to ESM

#21  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @dhrjarun and the rest of your teammates on  Graphite


Override

how Override config values ???

Added PR #22 that adds extra details about using the Override Function. Kindly close this issue if everything is resolved.


Added batch size option to the management command for populating the history

Replaces #231

Current coverage is 97.48% (diff: 100%)

Merging #263 into master will increase coverage by <.01%

@@             master       #263   diff @@
==========================================
  Files            12         12
  Lines           556        557     +1
  Methods           0          0
  Messages          0          0
  Branches         66         66
==========================================
+ Hits            542        543     +1
  Misses            7          7
  Partials          7          7

Powered by Codecov. Last update f2f23e6...45ddf14


ERROR: Could not find a version that satisfies the requirement mxnet==1.4.0 (from datawig) (from versions: 1.6.0, 1.7.0.post1)

This error shows up everytime I try to install datawig library from AWS on my terminal. I already installed different versions of mxnet and still doew not work
ERROR: Could not find a version that satisfies the requirement mxnet==1.4.0 (from datawig) (from versions: 1.6.0, 1.7.0.post1)
ERROR: No matching distribution found for mxnet==1.4.0 (from datawig)

MXNet 1.4 may not be available for your Python version (assuming you're on MacOS), as your version of Python may be newer then MXNet 1.4: https://pypi.org/project/mxnet/1.4.0/#files
You can consider reporting an issue with datawig and ask them not to require MXNet 1.4 but any MXNet version < 2.


Can't fragment correctly lines with bold or italic elements

When I have a list item with a bold or italic part, the  doesn't work as expected : instead of making the whole line appearing, it only makes the last inline element appear. Eg : in the following code, only the bold element is gonna appear.
- Here's a list item that should *appear* soon
I know that I can use a custom
…
 but then I have a mix of markdown and html, which is opposite to the goal of using GitPitch.

Hi Xavier, as currently documented on the Wiki when you use rich (rather than plain text) markdown you need to adopt the more verbose syntax for fragment list items. I agree, this is not ideal.
But I do have good news. GitPitch.com already supports a number of special shortcut syntax tricks that improve life for presentation authors.  I need to create doc for this but for now you can see the video on the following page on the GitPitch website for sample usage.
To your specific question, there also exists a new shortcut syntax for fragment lists. You basically wrap any regular Markdown list items within an @ul and @ulend tag pair. For example:
@ul
- Here's a list item that should *appear* soon
- Here is **another** one
@ulend

This will automatically turn every item in the list into a fragment. And it will handle both plain and rich [bold, italics, links, etc] markdown content within those list items.
You can use an @ol and @olend tag pair for ordered lists.
This approach is completely independent of the old | fragment syntax. This ensures full backward compatibility for existing presentations using the old syntax so they do not break. Once I have documentation in place I will update this thread with a link to the full doc for the new tags.
Note, these shortcut features are available on gitpitch.com only. If you host your own open source server you will not have access to these shortcuts, so stick with the long format.

See the following GitPitch presentation for a live demonstration of:

The new list fragment syntax plus
The new list fragment custom styling syntax plus
The new list fragment-specific speaker notes.

You can view the live presentation here.


Fix View diagram : Too many agent to display (#1664)

Making a GET request is simple, but GET URLs are limited to 2K characters.
The Google Chart API supports HTTP POST for chart requests up to 16K long. (*1)
(*1) https://developers.google.com/chart/image/docs/post_requests

Looks good! The only thought I have is that now Huginn is making a backend request instead of having the browser do it. Any downside to this? Does their API support a CORS cross-domain POST from the frontend, or jsonp? Or maybe this is fine as-is? :)

Cool! Looks like there is a solution which involves using an iframe which looks a bit annoying to set up. Since the pages which display the diagram are not used for anything else, I don't think it matters where the time for the API call is spend.
We could add an optimization which uses the old method if the query is small enough to be send as a get request.

Yea, this should be fine!


Refactor e2e tests - x509

https://github.com/sigstore/rekor/issues/1075
Signed-off-by: naveensrinivasan<EMAIL_ADDRESS>Summary

Refactored e2e test x509 into the respective folder.

Release Note
NONE
Documentation
NONE

Codecov Report

Merging #1152 (7b86cad) into main (a383edc) will decrease coverage by 7.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1152      +/-   ##
==========================================
- Coverage   48.82%   41.62%   -7.20%
==========================================
  Files          82       74       -8
  Lines        7635     7216     -419
==========================================
- Hits         3728     3004     -724
- Misses       3202     3903     +701
+ Partials      705      309     -396

Flag
Coverage Δ

e2etests
?

unittests
41.62% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

cc @asraa

@bobcallaway A friendly ping.


fix:addColumn occurred An error,  When migrating from a lower version…

When a new table is created during the migration from an earlier version to a higher version, an error occurs when you call addColumn after creating the table with the latest column names

I don't think the current behavior is broken - it adds a column and fails if the column already exists, that's reasonable.
It's true that not being able to create the table at an earlier snapshot to then apply subsequent migrations to it can make the entire migration script a bit more complicated. If you still have the ability to reconstruct older versions, I strongly recommend using generated step-by-step migrations: You can make drift generate snapshots of all your schema versions and then call create(schema.yourTable) in one step to create yourTable at the version expected at that step (without the new column). Then you call addColumn(schema.yourTable, schema.yourTable.newColumn) in a later step to reliably add the column.
Step-by-step migrations are probably the best answer to fix these issues, you can also use related tooling to unit test your migrations which can provide a lot of confidence of not getting these wrong for some combination of from, to targets. Otherwise you'd have to check the from version only to either create the table if you're coming from versions which didn't have it or alternatively create the column.

Just to add my $0.02 - in our real world cases users have been switching between app versions on Testflight which lead to app being stuck on launch, as the migration has been applied the second time. If there was an option to modify table (e.g. add column) in idempotent way, I'd love to have it, e.g. as
from1To2: (m, schema) async {
  await m.addColumnIfNotExists(
    schema.table,
    schema.table.column,
  );
},

I think idempotent migration APIs alone aren't too helpful in the end when you have more complex migrations consisting of multiple steps (and especially once you start reading data its over, but that's implicitly required for things like alterTable).
Serverside migration frameworks usually support going both ways (so you'd define an _up and a _down step for every migration, allowing them to be rolled back if necessary). That's technically supported in drift too, but not with the step-by-step migration helper.
I don't think it's too helpful for apps though, as older released versions of your app obviously won't know how to roll back the schema from a newer versions they don't know about yet.
I don't have a good answer to the beta test + testflight problem to be honest. I think you should raise your schema version even for versions you only roll out to beta testers (which covers users upgrading from stable release -> testflight). Supporting users downgrading your app is very tricky (e.g. what if a testflight version has deleted a table no longer necessary, you can't just implicitly go back from there). The best approach I can come up with is to inform users that they loose local data after downgrading and delete the database if the schema version in the database is higher than the one the app knows about. Or use a different database file for beta builds.

thanks,I will close it


document does not seems to be valid for Dot.Net 6

services.AddDefaultIdentity(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores();
I am trying to add this in Blazor 6 server application. But compiler does not recognize "AddDefaultIdentity".

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

ID: d9869895-9ba2-5027-46cd-89d1d995cba4
Version Independent ID: 8750939b-6ae5-3b9a-6c32-5e84b7fea22c
Content: Identity model customization in ASP.NET Core
Content Source: aspnetcore/security/authentication/customize-identity-model.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @ajcvickers
Microsoft Alias: avickers

Hi @gbthakkar. Do you have a reference to the Microsoft.AspNetCore.Identity.UI NuGet package?

Hi,
No. I have created a project without authentication to start with and later.
And after reaching to some stage. I am trying to add custome authentication
in the project.
for that I have created a class inherited from AuthenticationStateProvider.
let me explain the situation, I am in.
I have blazor 6 server application.
and have one component.
I am loading that component from two link.
one is having querystring parameter and second do not have querystring.
when I click the second link (when the componet is already loaded on the
browser). only url gets change but component does not refresh.
I think that is because, it is the same route for blazor application.
so then I try to add second parameter on navigationmanager.navigateTo
method and try to "ForceLoad" the component.
At this point. the GetAuthenticateStateAsync return null (ClaimIdentity and
other scoped service gets reset).
This behaviour is same as F5 on windows.
So My actual issue to preserver the ClaimIdentity / Authentication state
when using ForceLoad with navigationManager.
Regards,
Gaurang Thakkar
On Wed, 2 Feb 2022 at 21:17, Kirk Larkin @.***> wrote:

Hi @gbthakkar https://github.com/gbthakkar. Do you have a reference to
the Microsoft.AspNetCore.Identity.UI
https://www.nuget.org/packages/Microsoft.AspNetCore.Identity.UI/ NuGet
package?
—
Reply to this email directly, view it on GitHub
https://github.com/dotnet/AspNetCore.Docs/issues/24846#issuecomment-1028077736,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJOILTVTYDERVHOCLRHM3TDUZFGZXANCNFSM5NL42BYA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

In that case, I suggest posting to a community support group like Stack Overflow with the asp.net-core tag:

Stack Overflow
ASP.NET Core Slack
ASP.NET Gitter

Ok, I understand that we have to create razor page or mvc controller to set the authentication cookies first, and then the blazor SignalR will pick up that cookie.
But if we have blazor component and set the Authentication then it will be lost on page refresh because application will reload.


BUG:

Describe the bug
The app seems to be not working. The link (https://activity-graph.herokuapp.com/graph?username=kenhorlador&hide_border=false&area=true&bg_color=2E0655) is not reachable in anyway.
Expected behavior
I expected that the graph would show up but 'Application error' seems to be showing up in the screen.
Screenshots
If applicable, add screenshots to help explain your problem.

Refer to #55
Things are up and running now


Refresh drives

When opening drives view
Periodically when in drives view

When clicking on device name in path

Implemented partially in 2e0e16d193c2a047ad10f0d9d17c988271e81af1


Pre-fill the form from URL parameters

It would be nice if the form could be filled in with some details by providing them in the URL:
?name=&details=

Just shipped this feature. Documentation is on the tutorial page but it is intuitive/as you described - just pass an URL parameter for name, email, and/or details. Cheers!