text:
[FEATURE] add support es6 in nashorn

We have faced an issue using default nashorn script engine, it doesn't support ecmascript 6 features while it could be turned on by replacing
ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");

With
NashornScriptEngineFactory factory = new NashornScriptEngineFactory();
ScriptEngine engine = factory.getScriptEngine("--language=es6");

our request is to make it configurable in order to allow users to provide flags or inject custom script engine. Thanks in advance!

I'm not too familiar with the differences, but if there are any backward incompatibilities - we'll probably want to preserve them for the time being.
Regardless, script evaluators on tasks are configurable, e.g., so we could have another Evaluator (nashorn-es6 or something).
And IMO eventually Nashorn will be marked as deprecated and graaljs will take its place as the default one (it has support for es6 by default).

Thanks for a quick answer. Could you please provide an example of how can we change evaluator?
And in which release you're going to change nashorn to graaljs?
Best regards, Roman.

Thanks for a quick answer. Could you please provide an example of how can we change evaluator?
And in which release you're going to change nashorn to graaljs?
Best regards, Roman.

I've talked to other maintainers and we've decided that making a global setting instead of having a separate evaluator that users would have to configure in their definitions would be fine, we'll make it env variable-based.
When exactly Nashorn will be deprecated is not determined yet, but at some point it definitely will.

When next release comes out, you will be able to get desired behaviour if you set env variable CONDUCTOR_NASHORN_ES6_ENABLED to true.

That's so good! Thanks a lot!
@c4lm, when are you going to release these changes?

Most likely this week

repo: conductor-oss/conductor


text:
ttRpc server cleanup on error

https://github.com/confidential-containers/cloud-api-adaptor/blob/staging/pkg/adaptor/hypervisor/aws/server.go#L55
https://github.com/confidential-containers/cloud-api-adaptor/blob/staging/pkg/adaptor/hypervisor/ibmcloud/server.go#L70
https://github.com/confidential-containers/cloud-api-adaptor/blob/staging/pkg/adaptor/hypervisor/libvirt/server.go#L57
@littlejawa let's use this issue to track the ttRpc server cleanup

cc @yoheiueda

I guess this issue is related to this. https://github.com/confidential-containers/cloud-api-adaptor/pull/134#discussion_r946501930
I don't remember the reason why defer is set later. I think It is OK to set defer immediately after allocation.
BTW, there are duplicated code among multiple providers. I am thinking of refactoring provider code to reduce such redundancy among providers.

I guess this issue is related to this. #134 (comment)

@yoheiueda  this is across the providers.

I don't remember the reason why defer is set later. I think It is OK to set defer immediately after allocation.
BTW, there are duplicated code among multiple providers. I am thinking of refactoring provider code to reduce such redundancy among providers.

Agree on the code duplication. Let me know if you need any help with the refactoring.

@bpradipt is this issue still relevant or can be closed?
If it's still relevant to what release do you think we should map it to (mid-November, end-December, mid-February etc...)?

Currently the code is refactored and this issue is not relevant. Closing this.

source: gharchive/issue

authors: ariel-adam bpradipt yoheiueda

license_type: permissive

license_source: github-api


text:
Implement lazy Property for Cfgu Declaration

Suggestion
Adding a lazy boolean property to the Cfgu declaration. This property allows users to specify that a value for a given ConfigKey should only be set during the eval command execution, either using the configs parameter or the --config flag in the CLI. Essentially, lazy: true implies the following:

Values for this key cannot be assigned using the upsert command.
Any existing value (Config) for this key in any store will be disregarded during eval.
The only method to assign a value to this key is through the eval command with the configs parameter.
If marked as required, the user must provide a value for this key during eval.
This property cannot be combined with template and default properties.

# my_schema.cfgu.json
{
  ...
  "MY_EMAIL": {
    "type": "Email",
    "lazy": true
  }
  ...
}

configu upsert ... --schema './my_schema.cfgu.json' -c "MY_EMAIL=ran@configu.com" # Error

configu eval --schema './my_schema.cfgu.json' -c "MY_EMAIL=ran@configu.com" # OK

Motivation
This feature enhances the Cfgu declaration's versatility, catering to scenarios where configuration values need to be dynamic or context-specific. It offers greater control over when and how configuration values are assigned, particularly beneficial in environments with varying runtime contexts. By enabling lazy evaluation of config values, this feature facilitates more adaptable and responsive configuration setups, particularly useful in complex, multi-stage deployment processes or when dealing with sensitive information that requires contextual assignment.
Context
No response

Development Plan

[ ] Add lazy to Cfgu props
[ ] Modify ConfigSchema.cfguStructureValidator so that:

[ ] If marked as required, the user must provide a value for this key during eval.
[ ] This property cannot be combined with template and default properties.

[ ] Modify UpsertCommand to raise error if configs || pipeConfigs contains 'lazy' cfgu.
[ ] Modify EvalCommand.evalFromStoreSet to ignore values from the store if cfgu marked lazy
[ ] Update docs

Questions
Test Cases
True Cases

run EvalCommand with override for lazy config when cfgu.required = false
run EvalCommand with override for lazy config when cfgu.required = true
run EvalCommand without override for lazy config when cfgu.required = false
run EvalCommand with override for lazy config when threre is a value in the store and get the override value in the result
run EvalCommand without override for lazy config when threre is a value in the store and don't get it back in the result

False Cases

parse ConfigSchema with lazy=true and default=any
parse ConfigSchema with lazy=true and template=any
run EvalCommand without override for lazy config when cfgu.required = true
run UpsertCommand with lazy config

Notes / Comments / Additional

Since not specified otherwise, I assume that piping the eval result to upsert with lazy configs should raise an exception.

@RonConfigu, for the error handling in your current task, please reference the existing error patterns, like those used for assigning values to template CFGU keys. This should help maintain consistency in error messaging and handling. If you need more specific guidance on error terminologies, I suggest consulting with @RichardAkman. Once you've drafted your error handling approach, tag me in the PR, and I'll review your suggestions to ensure they align with our established error terminology.

repo: configu/configu


text:
Producer not pushing the messages while can push from CLI

Description
Not able to publish message from Producer API, but when i use Kafka CLI to push the message, it works fine on my Azure cluster
How to reproduce
Checklist
Please provide the following information:

[ ] Confluent.Kafka nuget version:
[ ] Apache Kafka version:
[ ] Client configuration:
[ ] Operating system:
[ ] Provide logs (with "debug" : "..." as necessary in configuration)
[ ] Provide broker log excerpts :
[ ] Critical issue : yes

that's not a lot to go on - can you provide more information?

repo: confluentinc/confluent-kafka-dotnet


text:
#148 add optional array of private registry secrets

#148

It looks like @CrystalMethod hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.
Once you've signed reply with [clabot:check] to prove it.
Appreciation of efforts,
clabot

[clabot:check]

@confluentinc It looks like @CrystalMethod just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

I have tried to include the requested changes - please comment.

LGTM. Thanks a lot for the PR!

Thank you @CrystalMethod

source: gharchive/pull-request

authors: ConfluentCLABot CrystalMethod gAmUssA qshao-pivotal

repo: confluentinc/cp-helm-charts


text:
Add envFrom parameter in Deployments and StatefulSets

What changes were proposed in this pull request?
This PR adds the envFrom parameter for Deployments and Daemonsets. This allows to setup environment parameters from external secrets
How was this patch tested?
helm install on EKS

@confluentinc It looks like @asiragusa just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

authors: ConfluentCLABot asiragusa


text:
MINOR: Change Avro dependency required for schema registry updates

Schema registry added pluggable schemas in master, Avro dependency needed to get upgraded to 1.9.1.  This PR is needed to fix the kafka-streams-examples master build failures.

Merged #312 into master

repo: confluentinc/kafka-streams-examples


text:
Documentation around identity pools and RBAC/ACLs is not clear

The documentation could be more clear that attaching role bindings or ACLs to identity pools requires specifying the id of the identity pool as a User in the principal field of the role binding or ACL resource, as mentioned in this issue: https://github.com/confluentinc/terraform-provider-confluent/issues/241

@pwstorm, thank you for creating the issue!
It seems like we have added an example to the Role Bindings documentation page:
resource "confluent_role_binding" "environment-example-rb-2" {
  principal   = "User:${confluent_identity_pool.test.id}"
  role_name   = "EnvironmentAdmin"
  crn_pattern = confluent_environment.stag.resource_name
}

We'll make sure to add a similar example to the ACLs documentation page.


text:
[BUG] 토큰으로 로그인 시, 로그아웃 실패

Describe the bug
oauth로 로그인하지 않고 토큰으로 바로 로그인 시, back에서 req.user.id를 참조하지 못함으로 생기는 에러. 굳이 Users.findOne할 필요 없이 그냥 토큰을 바로 만료시키면 될듯하다
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

수정 완료 #298

authors: Einere changgunyee

license: MIT


text:
added pipe, brackets, braces and back slash to the popup button list.

I love connectbot and I do lots of system administration with it all the time, but my hardware keyboard lacks any way to send a pipe key, so I have to close the keyboard, open the popup keyboard hit a few buttons then open the keyboard again just to get the pipe symbols.
This pull just adds | [ ] { } and \ to the little popup button list making these keys easier to enter.

@nixomose, do you mind rebasing and resolving any merge conflicts?

all rebased and merged and all that.

@bengolds @kruton, what are your thoughts on this? The virtual keys bar is getting a bit crowded, but I do see the value here. I'm somewhat torn.

Perhaps we could make this feature an optional setting?

Since these keys are already provided on the normal virtual keyboard and this just makes them a little easier to get to, I'd rather we make this an advanced feature.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: nixo@t420:x: nixomosenixo@t420 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant bengolds jklein24 nixomose rhansby

repo: connectbot/connectbot

license_source: bigquery


text:
提交GMPC申请

提交GMPC申请。麻烦管理帮忙审核。

为了加速显示进度，请尽可能向我们提供完善的项目资料，以及知名区块链媒体报道，包括但不限于以下内容，以便 imToken 团队更了解你们的项目。
团队背景：
项目基本情况:
媒体报道：
推荐用户转账所使用的 Gas 数量（没有提供，我们默认值 60000）
PR 示例：
https://github.com/consenlabs/token-profile/pull/1636

repo: consenlabs/token-profile


text:
🛑 coller.resterdigne.net is down

In 6d4e164, coller.resterdigne.net (https://coller.resterdigne.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: coller.resterdigne.net is back up in 6873e16.

repo: constructions-incongrues/status


text:
🛑 kneeporn.partouze-cagoule.fr is down

In bafca27, kneeporn.partouze-cagoule.fr (https://kneeporn.partouze-cagoule.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kneeporn.partouze-cagoule.fr is back up in 75eb78e after 1 day, 4 hours, 38 minutes.


text:
🛑 leseditionsduchevet.fr is down

In bda609c, leseditionsduchevet.fr (https://leseditionsduchevet.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: leseditionsduchevet.fr is back up in 34caa9d after 3 hours, 22 minutes.


text:
🛑 collectionrevue.com is down

In 2ef0873, collectionrevue.com (https://collectionrevue.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: collectionrevue.com is back up in b0ba7fb after 16 hours, 6 minutes.


text:
Cannot find /run/containerd/containerd.sock

Description
Cannot find "/run/containerd/containerd.sock"
Steps to reproduce the issue
root@n223-247-006:~/containerd/bin# ./ctr containers ls
Describe the results you received and expected
ctr: failed to dial "/run/containerd/containerd.sock": context deadline exceeded: connection error: desc = "transport: error while dialing: dial unix:///run/containerd/containerd.sock: timeout"
What version of containerd are you using?
root@n223-247-006:~/containerd/bin# ./ctr version  Client:   Version:  v1.6.15   Revision: 5b842e528e99d4d4c1686467debf2bd4b88ecd86   Go version: go1.19.5  ctr: failed to dial "/run/containerd/containerd.sock": context deadline exceeded: connection error: desc = "transport: error while dialing: dial unix:///run/containerd/containerd.sock: timeout"
root@n223-247-006:~/containerd/bin# systemctl status containerd.service
● containerd.service - containerd container runtime
   Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Thu 2023-01-19 07:10:51 CST; 3s ago
     Docs: https://containerd.io
  Process: 2324221 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
  Process: 2324223 ExecStart=/usr/local/bin/containerd (code=exited, status=203/EXEC)
 Main PID: 2324223 (code=exited, status=203/EXEC)

containerd service is not running yet, can you share containerd logs journalctl -u containerd -n 100

Hi, I resolved it by adding path to runc/runsc , and works through, thanks , it is due to contained could not find OCI runtime
wget https://go.dev/dl/go1.19.5.linux-amd64.tar.gz
rm -rf /usr/bin/go && tar -C /usr/bin -xzf go1.19.5.linux-amd64.tar.gz

go version

vim ~/.bashrc
export PATH=$PATH:/usr/bin/go
source ~/.bashrc

make

root@n223-247-006:~/containerd/bin# ls
containerd  containerd-shim  containerd-shim-runc-v1  containerd-shim-runc-v2  containerd-stress  ctr

cp ./* /usr/local/bin/

wget https://github.com/containernetworking/plugins/releases/download/v1.2.0/cni-plugins-linux-amd64-v1.2.0.tgz
mkdir -p /opt/cni/bin
tar Cxzvf /opt/cni/bin  cni-plugins-linux-amd64-v1.2.0.tgz

vim ~/.bashrc
export GOPATH=/usr/bin/go
export PATH=$PATH:/usr/bin/go/bin:/opt/cni/bin:/usr/local/bin/:/usr/local/sbin/runc
source ~/.bashrc

git clone https://github.com/wenhuizhang/runc.git
cd runc/
git checkout v1.0.2
apt-get install libseccomp-dev
make
make install

cd /usr/lib/systemd/system
wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
systemctl daemon-reload
systemctl enable --now containerd

cd -
./ctr images pull docker.io/library/redis:alpine
./ctr run docker.io/library/redis:alpine redis

./ctr images pull  docker.io/library/nginx:latest
./ctr run docker.io/library/nginx:latest ngnix

./ctr images pull  docker.io/library/ubuntu:latest ubuntu
./ctr run docker.io/library/ubuntu:latest ubuntu

ctr image list
ctr containers list

ctr container create -t docker.io/library/nginx:latest nginx01
ctr task start -d nginx01
ctr task list
ctr task attach nginx01
ctr task exec -t --exec-id bash01 nginx01 bash

ctr task kill -9 nginx01
ctr task rm -f nginx01
ctr container rm nginx01

Downloading the containerd service for systemd workeed for me:
cd /usr/lib/systemd/system
wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
systemctl daemon-reload
systemctl enable --now containerd

authors: RedClouud adisky wenhuizhang

repo: containerd/containerd


text:
api: use weak imports for plugin protobufs

Because of a side-effect import, we have the possibility of pulling in
several unnecessary packages that are used by the plugin and not at
runtime to implement protobuf structures. Setting these imports to
weak prevents this from happening, reducing the total import set,
reducing memory usage and binary size.
Signed-off-by: Stephen J Day stephen.day@docker.com

Codecov Report

Merging #1778 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #1778      +/-   ##
=========================================
+ Coverage   49.14%   49.2%   +0.05%
=========================================
  Files          77      77
  Lines        7705    7705
=========================================
+ Hits         3787    3791       +4
+ Misses       3275    3271       -4
  Partials      643     643

Flag
Coverage Δ

#linux
49.22% <ø> (ø)
:arrow_up:

#windows
45.01% <ø> (+0.06%)
:arrow_up:

Impacted Files
Coverage Δ

metadata/content.go
32% <0%> (+0.94%)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM

authors: codecov-io crosbymichael stevvooe


text:
[cri] Implement CRI Pod and Container stats for Windows

Implements ListPodSandboxStats and PodSandboxStats for Windows.
Part of https://github.com/kubernetes/enhancements/issues/2371
Currently is using the branch from https://github.com/kubernetes/kubernetes/pull/110754 for the CRI API updates that were needed for Windows
Special notes for your reviewer:
Still need to add some tests and refactor some of the linux functionality to be able to implement UsageNanoCores.
I made a custom build of crictl that can handle the windows stats but can use any version that has the statsp command.

/cc @dcantah @kevpar @bobbypage @haircommander @marosset

The linter is failing on mac because I pulled two functions up that would allow me to re-use code across the windows and linux implementations.
  Error: func `(*criService).getSandboxPidCount` is unused (unused)
  Error: func `(*criService).getUsageNanoCores` is unused (unused)

They are not used in the _other.go so need to re-think how that is done.  the commit https://github.com/containerd/containerd/pull/7099/commits/77b74643f664a3e7450049dbce760a7288ace27f is fixing a missing UsageNanoCores in the containers stats so I think it makes sense to split that out as a separate PR and can fix one of the linting issues.  The other I think I can refactor the stats some even further for re-use which would take care of the second.

Moved getUsageNanoCores to seperate PR: https://github.com/containerd/containerd/issues/7184
We discussed CRI changed required at sig-node this morning and we will be do a bit more design via the KEP. Once those are merged, I can refresh this PR but wouldn't anticipate drastic changes to the design except may what values we return.

We've reach consensus on the changes to CRI: https://github.com/kubernetes/enhancements/pull/3439 and the cri changes have been updated in https://github.com/kubernetes/kubernetes/pull/110754

with the cri api update in https://github.com/containerd/containerd/pull/7656 this work can continue 🚀. I've rebased and fixed it up to use the new fields.
Next step is to clean it up and get it ready for review.

This is ready for review, I am working on a few more tests but ready to review implementation. I split it into two commits:

a refactor of the container stats to move the stats caching management up to the CRI layer. This made the code easier to re-use for Windows and I think easier to understand/maintain
Second commit that adds Windows Pod Sandbox stats

Do these changes need to be mirrored under https://github.com/containerd/containerd/blob/main/pkg/cri/sbserver/container_stats.go?

Do these changes need to be mirrored under https://github.com/containerd/containerd/blob/main/pkg/cri/sbserver/ ?

Yes

Preferably 😆

Do these changes need to be mirrored under https://github.com/containerd/containerd/blob/main/pkg/cri/sbserver/ ?

Yes

I just learned about his package. Is there guidance on how these should be mirrored? Do I just copy/replace or is there enough differences that I need to make the changes more directly?

Do these changes need to be mirrored under https://github.com/containerd/containerd/blob/main/pkg/cri/sbserver/ ?

Yes

I just learned about this package. Is there guidance on how these should be mirrored? Do I just copy/replace or is there enough differences that I need to make the changes more directly?

Most folks seem to just copy and paste, unless there's major differences to the methods between the two that don't allow a straightforward copy. See if you run into anything and if so ping me and I'll take a peek

@dcantah @marosset ready for another review

I think the windows failure is a flake (I can't seem to retrigger just that job)

Sweet! Will try and look sometime in the coming days

This can be used to test manually: https://github.com/kubernetes-sigs/cri-tools/pull/1057

Will keep lookin on Monday!

Is it intended that some of the new fields, for instance available_bytes, are not added as part of this PR? I did notice you sum them as part of the pod's stats, but they don't seem to be set anywhere to begin with.

Is it intended that some of the new fields, for instance available_bytes, are not added as part of this PR? I did notice you sum them as part of the pod's stats, but they don't seem to be set anywhere to begin with.

yes, there were a couple fields that we can retrieve information for but don't currently.

/cc @bobbypage @haircommander

/ok-to-test

Should this issue get added to the 1.7 milestone?

Should this issue get added to the 1.7 milestone?

@dmcgowan thoughts?

@containerd/maintainers this is ready for final review

/assign @dmcgowan @kevpar @kzys

Lgtm

@jsturtevant Can you squash this? I think we're good for check-in after.

I left the changes separate from Cri Sandbox code and sandbox. Let me know if I should squash to a single commit

@jsturtevant That's fine, makes it easier to revert if anything was wrong in one and not the other

authors: MikeZappa87 dcantah jsturtevant kevpar kzys marosset


text:
Support version subcommand to compose

What is the problem you're trying to solve
I'd like write a script that invokes docker compose and works with both Docker and Nerdctl.
To do so reliably, I need to detect whether the compose command is supported (e.g., docker compose is provided by an optional plugin, so I can't assume anything and must explicitly check).
An easy way to detect support would be to run a safe command like docker compose version and check its exit status. This would let me know if I can proceed to calling docker compose up -d, or if I need to print out additional help text for the user.
Describe the solution you'd like
Running nerdctl compose version should print the nerdctl version and exit successfully.
Additional context
None of nerdctl's supported compose commands appear completely safe to invoke with no risk of having side effects or depending on the surrounding environment, so I can't substitute a different, existing command at this point in time.

I'll take this

Thank you very much, @yardenshoham and @AkihiroSuda

authors: callahad yardenshoham

repo: containerd/nerdctl


text:
Don't see any trace on Jaeger

Hello all,
I want to play with Maesh, and give a talk about it in my company, but i'm not able to see any trace in jaeger UI, other than jaeger internals.
My demo application if a simple front, calling a backend-api (via http://backend.back.maesh)
Am i doing something wrong ?
Seems related to #240

Hey @ADefossez-Zenika,
can you share me your service definitions and stuff, so i can try to reproduce?

Hello,
o'course, i 've just set my demo repo as public :
https://github.com/ADefossez-Zenika/Demo-Maesh
It's just a small workshop running on my  docker-for-desktop K8S cluster (macos)

authors: ADefossez-Zenika SantoDE

repo: containous/maesh


text:
Request certificate for other uses

Is it possible to request a certificate over ACME using traefik as (HTTP) validation endpoint for
a certificate that isn't intended to be used by traefik but by other services (e.g. mail server) -
with custom options (SAN)?

No, currently this is not possible and we will probably not looking into this as it's far beyond traefik goals.
You could use the regular certbot to achieve that :)

How can I use certbot in combination with traefik? Traefik is already bound to HTTP port.

authors: SantoDE strarsis

repo: containous/traefik


text:
Cant access dashboard / basicAuth doesnt work

Bug.
Win 10 x64.
What did you do?
Trying to setup dashoard with basic auth middleware.
What did you expect to see?
Popup when accessing host url.
What did you see instead?
404 page not found.
docker compose config
traefik:
image: traefik:2.1.4
command:
- "--log.level=DEBUG"
- "--api.dashboard=true"
ports:
- "80:80"
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
labels:
- "traefik.http.routers.api.rule=Host(localhost)"
- "traefik.http.routers.api.service=api@internal"
- "traefik.http.routers.api.middlewares=auth"
-"traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$yneugp6h$$ngegdH9eDmaaoPGFN0vvP1"
log output in DEBUG level
time="2020-02-27T08:33:36Z" level=info msg="Configuration loaded from flags."
time="2020-02-27T08:33:36Z" level=info msg="Traefik version 2.1.4 built on 2020-02-06T17:10:06Z"
time="2020-02-27T08:33:36Z" level=debug msg="Static configuration loaded {\"global\":{\"checkNewVersion\":true},\"serversTransport\":{\"maxIdleConnsPerHost\":200},\"entryPoints\":{\"http\":{\"address\":\":80\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{}}},\"providers\":{\"providersThrottleDuration\":2000000000},\"api\":{\"dashboard\":true},\"log\":{\"level\":\"DEBUG\",\"format\":\"common\"}}"
time="2020-02-27T08:33:36Z" level=info msg="\nStats collection is disabled.\nHelp us improve Traefik by turning this feature on :)\nMore details on: https://docs.traefik.io/v2.0/contributing/data-collection/\n"
time="2020-02-27T08:33:36Z" level=info msg="Starting provider aggregator.ProviderAggregator {}"
time="2020-02-27T08:33:36Z" level=debug msg="Start TCP Server" entryPointName=http
time="2020-02-27T08:33:36Z" level=info msg="Starting provider *traefik.Provider {}"
time="2020-02-27T08:33:36Z" level=debug msg="Configuration received from provider internal: {\"http\":{\"services\":{\"api\":{},\"dashboard\":{}}},\"tcp\":{},\"tls\":{}}" providerName=internal
time="2020-02-27T08:33:36Z" level=debug msg="No default certificate, generating one"
time="2020-02-27T08:43:57Z" level=warning msg="Error checking new version: Get https://update.containous.cloud/repos/containous/traefik/releases: dial tcp 165.227.206.205:443: connect: connection refused"

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.

@emprove Make sure that you don't have api.insecure=true in your settings.

@emprove Make sure that you don't have api.insecure=true in your settings.

Yes it is.
`command:

"--log.level=DEBUG"
"--api.dashboard=true"`

authors: emprove traefiker trankchung


text:
Bump Middleman to v5.0.0

Noticed there is a RC as of 5/24/19: https://github.com/middleman/middleman/compare/v4.3.4...v5.0.0.rc.1

Anyone know which version of the contentful_middleman gem I should lock to if I'm staying on middleman 4.2 for the time being?

Hey @neetso,
You can stay in contentful_middleman 4.x.x, I've decided to keep the major numbers in line with Middleman's versioning.
@joshRpowell, thanks for the PR, I'll look into adding support for the 5.x version as soon as it gets an official release.
Cheers

authors: dlitvakb joshRpowell neetso

license: mit


text:
Add AI based image tagging extension

AI Image Tagging
This extension enables automatic tagging of images. To use, configure it in the
Sidebar of a content type that includes two fields at minimum:

A Media field to serve as the image source
A Short text, list field to store the generated tags

To use, just add an image to your image field and click Auto-tag image. The generated
tags should be added to your tags field once ready.

In general it would be nice to use prettier for the consistent codestyle: https://gist.github.com/Mohamed3on/840b34ecb7e9abf06ace035183b7f1fc

authors: lehnerm suevalov

repo: contentful/extensions

license: ISC


text:
Taxonomy | Internal demo suggestions

[x] Internal demo suggestions(CS-42076)
[x] SDK taxonomies find issue (1.11.0 -> 1.12.0)
[x] Merge development

@aman19K Can you please update your base branch with development so that your PR will only have your code changes instead of showing audit-related code changes as well?

#1111

repo: contentstack/cli


text:
Error calling Ollama /api/show endpoint: Error: Error: HTTP 404 Not Found from http://127.0.0.1:11434/api/show

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[ ] I'm not able to find an open issue that reports the same bug
[ ] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS:ubuntu 22.04
- Continue:
- IDE:vscode

Description
when use ollama LLM , why this extension call http://127.0.0.1:11434/api/show,   ollama  not have this endpoint
error messages at dev tools:
Error calling Ollama /api/show endpoint: Error: Error: HTTP 404 Not Found from http://127.0.0.1:11434/api/show
To reproduce
No response
Log output
No response

@Wilson-fan8877 Ollama does have this endpoint, at least in their documentation: https://github.com/ollama/ollama/blob/main/docs/api.md#show-model-information
Could you share what version of Ollama you are using?
One other way to test this would by try the following curl request:
curl http://localhost:11434/api/show -d '{
  "name": "llama3"
}'

Has the problem been solved?

This is still a problem and thwarts onboarding for people using ollama.

@trinque @homeant Are you both on the latest version of Ollama? Can you share more details about your setup?
It's pretty clear from their docs that this endpoint should exist, so I'm left wondering what difference in environment might be causing this. Any extra info will help me solve the problem more quickly

I am facing the same issue in both vscode and intellij. It was working before a month or so, I came back to code after a month and it's broken with the mentioned error message.
My tab autocomplete config:
"tabAutocompleteModel": {
    "title": "codegemma:7b-code",
    "provider": "ollama",
    "model": "codegemma:7b-code"
  },
  "tabAutocompleteOptions": {
    "useCopyBuffer": true,
    "maxPromptTokens": 400,
    "prefixPercentage": 0.5
  }

Model config:
{
      "title": "codegemma:7b-code",
      "model": "codegemma:7b-code",
      "contextLength": 2048,
      "completionOptions": {},
      "apiBase": "http://localhost:11434",
      "provider": "ollama"
    }

curl http://localhost:11434/api/show -d '{
  "name": "codegemma:7b-code"
}'

shows information about the model successfully.

I finally figured out that this is happening when requesting details about a model that is in an outdated format. So unless you manually go through and delete older models, the response will be the same from Ollama. For this reason we'll be ignoring it in all future releases. Next one for JetBrains should be early this week and for VS Code it's already released in pre-release

authors: Wilson-fan8877 eklavya homeant sestinj trinque

repo: continuedev/continue


text:
Applying a snippet in JetBrains throws an applyToFile nullPointerException

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS: macOS
- Continue version: 0.0.81
- IDE version: GoLand 2024.2.3/PyCharm 2024.2.4
- Model: any
- config.json:

{
  "models": [
    {
      "title": "vanilla: GPT-4o",
      "provider": "openai",
      "model": "gpt-4o",
      "apiKey": "redacted",
    },
    {
      "title": "vanilla: Llama 3.1 8B",
      "provider": "ollama",
      "model": "llama3.1:8b",
      // directly using llama
      "apiBase": "http://127.0.0.1:11434/"
    }
  "tabAutocompleteOptions": {
    "disable": true
  },
  "customCommands": [
    {
      "name": "test",
      "prompt": "{{{ input }}}\n\nWrite a comprehensive set of unit tests for the selected code. It should setup, run tests that check for correctness including important edge cases, and teardown. Ensure that the tests are complete and sophisticated. Give the tests just as chat output, don't edit any file.",
      "description": "Write unit tests for highlighted code"
    }
  ],
  "contextProviders": [
    {
      "name": "code",
      "params": {}
    },
    {
      "name": "docs",
      "params": {}
    },
    {
      "name": "diff",
      "params": {}
    },
    {
      "name": "terminal",
      "params": {}
    },
    {
      "name": "problems",
      "params": {}
    },
    {
      "name": "folder",
      "params": {}
    },
    {
      "name": "codebase",
      "params": {}
    }
  ],
  "slashCommands": [
    {
      "name": "edit",
      "description": "Edit selected code"
    },
    {
      "name": "comment",
      "description": "Write comments for the selected code"
    },
    {
      "name": "share",
      "description": "Export the current chat session to markdown"
    },
    {
      "name": "cmd",
      "description": "Generate a shell command"
    },
    {
      "name": "commit",
      "description": "Generate a git commit message"
    }
  ],
  "embeddingsProvider": {
    "provider": "ollama",
    "model": "nomic-embed-text"
  }
}

Description
When I ask an LLM to generate me a code snippet in a JetBrains IDE and click the "Apply" (play) button to get the snippet into the IDE editor, I get a popup saying:
Error handling message of type applyToFile: java.lang.NullPointerException: null cannot be cast to non-null type kotlin.String

To reproduce

Go to the chat window
ask the LLM to generate a code
click the play button to apply the code

Log output
There doesn't seem to be anything relevant in continue logs.

The JetBrain logs seem to suggest I'm missing some git integration piece perhaps?

2024-11-14 14:20:44,929 [63239933]   INFO - #c.i.w.i.i.j.s.JpsGlobalModelSynchronizerImpl - Saving global entities com.intellij.platform.workspace.jps.entities.SdkEntity to files
2024-11-14 14:20:44,935 [63239939]   INFO - #c.i.w.i.i.j.s.JpsGlobalModelSynchronizerImpl - Saving global entities com.intellij.platform.workspace.jps.entities.LibraryEntity to files
2024-11-14 14:20:44,976 [63239980]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Starting indexing","status":"loading"},"messageId":"db8dcd86-a63d-4880-b3c2-826b2157e5a4"}
2024-11-14 14:20:44,976 [63239980]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:44,978 [63239982]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Starting indexing","status":"loading"},"messageId":"74ac04df-8582-4df7-b826-5a38330cc895"}
2024-11-14 14:20:44,979 [63239983]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,005 [63240009]   INFO - STDOUT - Git not found: java.lang.NullPointerException: readLine(...) must not be null
2024-11-14 14:20:45,005 [63240009]   INFO - STDOUT - Git not found: java.lang.NullPointerException: readLine(...) must not be null
2024-11-14 14:20:45,005 [63240009]   INFO - STDOUT - Git not found: java.lang.NullPointerException: readLine(...) must not be null
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Starting indexing...","status":"loading"},"messageId":"24412fbd-5c3d-4bb7-8a31-85b6e5a12d30"}
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Starting indexing...","status":"loading"},"messageId":"93048b0f-6196-4792-b030-23019c6f92db"}
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Discovering files in .idea...","status":"indexing"},"messageId":"1b5b886c-02af-4abb-a730-9c0d1cecd8fa"}
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Discovering files in .idea...","status":"indexing"},"messageId":"bd5570a9-92ee-4539-a179-a941ba50424f"}
2024-11-14 14:20:45,006 [63240010]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,040 [63240044]   INFO - STDOUT - Git not found: java.lang.NullPointerException: readLine(...) must not be null
2024-11-14 14:20:45,041 [63240045]   INFO - STDOUT - Git not found: java.lang.NullPointerException: readLine(...) must not be null
2024-11-14 14:20:45,041 [63240045]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Planning changes for chunks index...","status":"indexing"},"messageId":"e598456c-b835-48f9-86b0-455b5708c33a"}
2024-11-14 14:20:45,041 [63240045]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,041 [63240045]   INFO - STDOUT - Git not found: java.lang.NullPointerException: readLine(...) must not be null
2024-11-14 14:20:45,042 [63240046]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Planning changes for vectordb::OllamaEmbeddingsProvider::nomic-embed-text index...","status":"indexing"},"messageId":"e4b87ba0-e7f2-4078-8888-c99768ae3974"}
2024-11-14 14:20:45,042 [63240046]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,042 [63240046]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Planning changes for chunks index...","status":"indexing"},"messageId":"f879941d-ce81-442f-9245-6d27ea27c7c7"}
2024-11-14 14:20:45,042 [63240046]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,043 [63240047]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Planning changes for vectordb::OllamaEmbeddingsProvider::nomic-embed-text index...","status":"indexing"},"messageId":"0edf36b0-263e-4fc1-9b00-65d6ba2be654"}
2024-11-14 14:20:45,043 [63240047]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,046 [63240050]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Computing embeddings for 4 files","status":"indexing"},"messageId":"8934c805-47db-4710-bdda-ef1008d0a3d9"}
2024-11-14 14:20:45,046 [63240050]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:45,047 [63240051]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":0,"desc":"Computing embeddings for 4 files","status":"indexing"},"messageId":"2829ecfa-928a-4c35-a5c9-b79a4043f41a"}
2024-11-14 14:20:45,048 [63240052]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:46,323 [63241327]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":1,"desc":"Indexing complete","status":"done","shouldClearIndexes":false,"debugInfo":""},"messageId":"c141fd10-503c-4007-abdf-019ec5a681ff"}
2024-11-14 14:20:46,324 [63241328]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:46,324 [63241328]   INFO - STDOUT - Error handling message: {"messageType":"refreshSubmenuItems","messageId":"6e74936c-73c8-46bc-8342-8f12647905bb"}
2024-11-14 14:20:46,324 [63241328]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:46,427 [63241431]   INFO - STDOUT - Error handling message: {"messageType":"indexProgress","data":{"progress":1,"desc":"Indexing complete","status":"done","shouldClearIndexes":false,"debugInfo":""},"messageId":"44a6a39b-1ca1-417a-ab49-f8d27ef4a4f4"}
2024-11-14 14:20:46,427 [63241431]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed
2024-11-14 14:20:46,427 [63241431]   INFO - STDOUT - Error handling message: {"messageType":"refreshSubmenuItems","messageId":"b9c529eb-b5d4-40f0-a79b-0d94b43a4391"}
2024-11-14 14:20:46,427 [63241431]   INFO - STDOUT - com.intellij.serviceContainer.AlreadyDisposedException: Container is already disposed

I believe this was fixed here: https://github.com/continuedev/continue/pull/2909
Will be getting a new release out ASAP.

This bug has been fixed in 0.0.82, but due to some other performance issues, we're recommending folks downgrade to 0.0.75 at the moment. Will plan to follow up here once we ship 0.0.83 👍

Closing this out after further validation, but if anyone else runs into the same issue please follow up here.

authors: Patrick-Erichsen jhrozek


text:
feat: create "rebuild index" dialog and command

Description
This PR allows users to clear their codebase index either through a new command, Continue: Rebuild codebase index, or through a dialog that can be activated when clicking on an indexing error status. This dialog will only be available when we've identified the error is from a pre-defined list of indexing errors that we believe warrant a rebuild.
  // Note that we exclude certain Sqlite errors that we do not want to clear the indexes on,
  // e.g. a `SQLITE_BUSY` error.
  errorsRegexesToClearIndexesOn = [
    /Invalid argument error: Values length (d+) is less than the length ((d+)) multiplied by the value size (d+)/,
    /SQLITE_CONSTRAINT/,
    /SQLITE_ERROR/,
    /SQLITE_CORRUPT/,
    /SQLITE_IOERR/,
    /SQLITE_FULL/,
  ];

Checklist

[x] The base branch of this PR is dev, rather than main
[x] The relevant docs, if any, have been updated or created

Screenshots

Testing
[ For new or modified features, provide testing instructions. ]

Closes #1991

authors: Patrick-Erichsen priyashpatil


text:
Improve logging facility

currently we use the <debuglog.h> header-only logging API, which is good, but we also ab-use it for error logging and warnings.
We need some kind of logging facility that allows us to, conveniently log:

errors
warnings
debug messages (filterable by tags/keywords)
debug trace messages (filterable by tags/keywords - most likely it's sufficient to join that with debug messages)

for debug/trace messages maybe having a int level to determine how much to debug/trace? (not sure that's really good/needed).

fmtlib should be used for formatting
logging should be as simple as a single function call

fmtlib should be used for formatting

My favourites are: :smile:
https://github.com/gabime/spdlog
https://github.com/MengRao/fmtlog

This ticket I did create for keeping track of it. @uspasojevic96 is interested in maybe taking this over.
I'll have a look at fmtlog (iff it's using fmtlib under the hood). I'd definitely prefer to stick with fmtlib for formatting, as most of the custom data types already provide fmtlib formatters that are useful to be printed for logging.

authors: christianparpart data-man

repo: contour-terminal/contour


text:
Add CI coverage for the 3.13 free-threaded build of CPython

Related to #407.

Thanks for this. Merging so you can continue with #410.

repo: contourpy/contourpy


text:
Inline Add hidden

onControlAdd will add tr with inline add, but with class "datagrid-row-inline-add-hidden" and the row is therefore invisible

Same issue here

authors: FTCP halaxa-roman

repo: contributte/datagrid


text:
Item details form example

Corrected item details form example for v6

Thank you


text:
Vector isochrones don't match accessibility results

The vector isochrones appear to encompass slightly less area than the corresponding accessibility results.

This is likely just due to different grid resolutions.

repo: conveyal/analyst-server


text:
fresh project runs into ERROR:  value too long for type character varying(50)

What happened?
you can hit the same issue with running pytest or manage.py migrate (inside docker container)
I created a new project with the following settings:
cookiecutter https://github.com/pydanny/cookiecutter-django
You've downloaded /Users/elmcrest/.cookiecutters/cookiecutter-django before. Is it okay to delete and re-download it?
[y/n] (y): n
Do you want to re-use the existing version? [y/n] (y): y
  [1/27] project_name (My Awesome Project): My Awesome Project
  [2/27] project_slug (my_wesome_project): my_wesome_project
  [3/27] description (Behold My Awesome Project!): Behold My Awesome Project!
  [4/27] author_name (Daniel Roy Greenfeld): Daniel Roy Greenfeld
  [5/27] domain_name (example.com): example.com
  [6/27] email (drg@example.com): drg@example.com
  [7/27] version (0.1.0):
  [8/27] Select open_source_license
    1 - MIT
    2 - BSD
    3 - GPLv3
    4 - Apache Software License 2.0
    5 - Not open source
    Choose from [1/2/3/4/5] (1): 5
  [9/27] Select username_type
    1 - username
    2 - email
    Choose from [1/2] (1): 2
  [10/27] timezone (UTC):
  [11/27] windows (n):
  [12/27] Select editor
    1 - None
    2 - PyCharm
    3 - VS Code
    Choose from [1/2/3] (1): 3
  [13/27] use_docker (n): y
  [14/27] Select postgresql_version
    1 - 15
    2 - 14
    3 - 13
    4 - 12
    5 - 11
    6 - 10
    Choose from [1/2/3/4/5/6] (1): 1
  [15/27] Select cloud_provider
    1 - AWS
    2 - GCP
    3 - Azure
    4 - None
    Choose from [1/2/3/4] (1): 3
  [16/27] Select mail_service
    1 - Mailgun
    2 - Amazon SES
    3 - Mailjet
    4 - Mandrill
    5 - Postmark
    6 - Sendgrid
    7 - SendinBlue
    8 - SparkPost
    9 - Other SMTP
    Choose from [1/2/3/4/5/6/7/8/9] (1):
  [17/27] use_async (n): y
  [18/27] use_drf (n):
  [19/27] Select frontend_pipeline
    1 - None
    2 - Django Compressor
    3 - Gulp
    4 - Webpack
    Choose from [1/2/3/4] (1): 4
  [20/27] use_celery (n): y
  [21/27] use_mailhog (n): y
  [22/27] use_sentry (n): y
  [23/27] use_whitenoise (n): y
  [24/27] use_heroku (n):
  [25/27] Select ci_tool
    1 - None
    2 - Travis
    3 - Gitlab
    4 - Github
    5 - Drone
    Choose from [1/2/3/4/5] (1): 4
  [26/27] keep_local_envs_in_vcs (y):
  [27/27] debug (n):
 [SUCCESS]: Project initialized, keep up the good work!

then run docker-compose up (or start a container/django env else and run into the same issue) and run into:
my_wesome_project_local_django        | django.db.utils.DataError:
my_wesome_project_local_django        | value too long for type character varying(50)

What should've happened instead?
not hitting the exception
Additional details
I tried it again with psycopg[c]==3.1.10 without a immediate difference

Host system configuration:

Version of cookiecutter CLI (get it with cookiecutter --version): Cookiecutter 2.3.0 (via homebrew)
OS name and version:

ProductName:		macOS
ProductVersion:		13.4.1
ProductVersionExtra:	(c)
BuildVersion:		22F770820d

Python version, run python3 -V: 3.11.4 (docker)

Docker version (if using Docker), run docker --version: Docker version 24.0.2, build cb74dfc

docker compose version (if using Docker), run docker compose --version:  Docker Compose version v2.19.1 (FYI it's meanwhile docker compose version without double dash)

Options selected and/or replay file:
On Linux and macOS: cat ${HOME}/.cookiecutter_replay/cookiecutter-django.json

{
  "cookiecutter": {
    "project_name": "behold",
    "project_slug": "slug",
    "description": "behold",
    "author_name": "John doe",
    "domain_name": "example.com",
    "email": "",
    "version": "0.1.0",
    "open_source_license": "Not open source",
    "username_type": "email",
    "timezone": "UTC",
    "windows": "n",
    "editor": "VS Code",
    "use_docker": "y",
    "postgresql_version": "15",
    "cloud_provider": "Azure",
    "mail_service": "Mailgun",
    "use_async": "y",
    "use_drf": "n",
    "frontend_pipeline": "Webpack",
    "use_celery": "y",
    "use_mailhog": "y",
    "use_sentry": "y",
    "use_whitenoise": "y",
    "use_heroku": "n",
    "ci_tool": "Github",
    "keep_local_envs_in_vcs": "y",
    "debug": "n",
    "_template": "https://github.com/pydanny/cookiecutter-django",
    "_output_dir": "/Users/user/projects",
    "_repo_dir": "/Users/user/.cookiecutters/cookiecutter-django"
  },
  "_cookiecutter": {
    "project_name": "My Awesome Project",
    "project_slug": "{{ cookiecutter.project_name.lower()|replace(' ', '_')|replace('-', '_')|replace('.', '_')|trim() }}",
    "description": "Behold My Awesome Project!",
    "author_name": "Daniel Roy Greenfeld",
    "domain_name": "example.com",
    "email": "{{ cookiecutter.author_name.lower() | trim() |replace(' ', '-') }}@{{ cookiecutter.domain_name.lower() | trim() }}",
    "version": "0.1.0",
    "open_source_license": [
      "MIT",
      "BSD",
      "GPLv3",
      "Apache Software License 2.0",
      "Not open source"
    ],
    "username_type": [
      "username",
      "email"
    ],
    "timezone": "UTC",
    "windows": "n",
    "editor": [
      "None",
      "PyCharm",
      "VS Code"
    ],
    "use_docker": "n",
    "postgresql_version": [
      "15",
      "14",
      "13",
      "12",
      "11",
      "10"
    ],
    "cloud_provider": [
      "AWS",
      "GCP",
      "Azure",
      "None"
    ],
    "mail_service": [
      "Mailgun",
      "Amazon SES",
      "Mailjet",
      "Mandrill",
      "Postmark",
      "Sendgrid",
      "SendinBlue",
      "SparkPost",
      "Other SMTP"
    ],
    "use_async": "n",
    "use_drf": "n",
    "frontend_pipeline": [
      "None",
      "Django Compressor",
      "Gulp",
      "Webpack"
    ],
    "use_celery": "n",
    "use_mailhog": "n",
    "use_sentry": "n",
    "use_whitenoise": "n",
    "use_heroku": "n",
    "ci_tool": [
      "None",
      "Travis",
      "Gitlab",
      "Github",
      "Drone"
    ],
    "keep_local_envs_in_vcs": "y",
    "debug": "n"
  }
}

It fails to create a row in one table, because one CharField value is too long for the column in the database.
You haven't shared a lot of logs, so we don't see which migration fails. However, since you're claiming that it's a fresh project and that the size of the column is 50, I bet it's failing on sites.0003_set_site_domain_and_name, which creates the site into the DB table from Django's sites framework:
https://github.com/cookiecutter/cookiecutter-django/blob/bd153d06911f7c2291e96fa0d562f0e58aada1e5/{{cookiecutter.project_slug}}/{{cookiecutter.project_slug}}/contrib/sites/migrations/0003_set_site_domain_and_name.py#L12-L18
The name is 50 char long:
https://github.com/cookiecutter/cookiecutter-django/blob/bd153d06911f7c2291e96fa0d562f0e58aada1e5/{{cookiecutter.project_slug}}/{{cookiecutter.project_slug}}/contrib/sites/migrations/0001_initial.py#L31
Did you redact the value of your project name by any chance? Is the actual value longer than 50 char? If that's the case, I suggest you to edit the name of the site in your migration sites.0003_set_site_domain_and_name. AFAIK, it's just an internal alias for you project name within the admin, it doesn't affect what the users will see. Let me know it it fixes your issue.
As for a fix to the template itself, we could limit the length of the value in the migration:
def update_site_forward(apps, schema_editor):
    """Set site domain and name."""
    Site = apps.get_model("sites", "Site")
    _update_or_create_site_with_sequence(
        Site,
        schema_editor.connection,
        "{{cookiecutter.domain_name}}",
-       "{{cookiecutter.project_name}}",
+       "{{cookiecutter.project_name[:50]}}",
    )

now I've recreated the project with exactly the same inputs as yesterday but I couldn't reproduce the issue. so whatever it was, it was fixed by one of the last commits in between my try yesterday and today.
since I'm not able anymore to reproduce I'll just close this issue.

authors: browniebroke elmcrest

repo: cookiecutter/cookiecutter-django


text:
Avoid docker image/volume collision by prefixing with project slug

Description
Hi, it's my first contribution ever, this pull request is related to issue #3254 and issue #2849.
The problem happens when we create a second django-cookiecutter project on our dev machine, there is a conflict between the container_name: postgres from the first project with the new one:
ERROR: for postgres  Cannot create container for service postgres: Conflict. The container name "/postgres" is already in use by container "...". You have to remove (or rename) that container to be able to reuse that name.

ERROR: for docs  Cannot create container for service docs: Conflict. The container name "/docs" is already in use by container "...". You have to remove (or rename) that container to be able to reuse that name.

ERROR: for postgres  Cannot create container for service postgres: Conflict. The container name "/postgres" is already in use by container "...". You have to remove (or rename) that container to be able to reuse that name.
ERROR: Encountered errors while bringing up the project.

Checklist:

[x] I've made sure that tests are updated accordingly (especially if adding or updating a template option)
[x] I've updated the documentation or confirm that my change doesn't require any updates

Rationale
To avoid conflict, the compose_name has now a prefix of the project_slug defined on the project creation.
Fix #2849
Fix #3254

Thanks for the fix! 🎉

@browniebroke, thank you for the opportunity, I'm going to help more the communities.


text:
[Bug]: Teams invite error message should read "Registered user not found "

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When I try to add a new member to team I get an "unknown error"
Steps To Reproduce
I open team page
I fill in the email
I click on send invitation
I get unknown error.

The error should read
Registered user not found (or something)
Version
3.12

Already fixed.

authors: andrasbacsai jesperordrup

repo: coollabsio/coolify


text:
Style customization still active when using custom scene

A user on discord discovered a problem with using a custom scene as the style.
Because they used a copy of the default layout, the previously made customization options were still applied, even though the style editor implied they weren't active anymore.

This has become irrelevant.
A) the editor should no longer seem like custom layouts can't have settings applied
B) it's easy to clear all customization.

repo: coppolaemilio/dialogic


text:
Using serial_terminal with Xterm.js?

Hello,
I am using libv86 for a project. I would like to know if instead of using a textarea as a serial_container, could I use Xterm.js as a serial_container?
Thanks!

starter.js code:
if(options["serial_container_xtermjs"])
{
    this.serial_adapter = new SerialAdapterXtermJS(options["serial_container_xtermjs"], this.bus);
}

So, you should pass an element to serial_container_xtermjs option

authors: Pixelsuft Unzor


text:
Create custom snap installer

For a course, we would like to create a custom installer of the platform (with additional packages). For windows, creating a installer exe is well-documented. It is currently not clear to me how I would create a custom snap installer for linux/macos.
Is this a scenario that is/could/should be supported?

For snap the process of building snap is integrated into CI - it uses the github action "snapcore/action-build". So there don't exist offline scripts which do this, although it might not be complicated to create them. The script for creating the snap control yaml file is available in the paltform - just not the script to run snap itself. I am not a snap expert and have no idea if this is complicated once one has the snap control yaml file.
Anyway I guess the easiest ways to do this are:

configure your fork of Coq Platform so that it runs github CI actions and enable CI runs for you modified branch (say add  "lecture-*" under on: push: branches: in .github/workflows/snap.yml - possibly reduce the build matrix to what you really need. I am not sure how this is with Mac and Windows runners these days - I guess there are meanwhile free shared runners.
Do a draft PR here for your modified platform (stating that this is just for building).

The advantage of these methods is that you get all installers (Mac, Windows, Snap) with a single git push. Note, though, that the Mac installers don't work at all without signing. If you need the signing scripts for Mac, please let me know.
If you need help, with method 1, I can prototype it on my fork and document it.

Thanks @MSoegtropIMC, I'll try this out and report back.

Ah never mind, I see that I can just select the correct package pick. Apparently this has changed since I last created images last year :-)

Yes, @gares just reworked it. 8.14.1 is currently default for snap, btw.:
https://github.com/coq/platform/blob/3beca37fbceb67c3a032c463c7b3e7cad56316f6/.github/workflows/ubuntu.yml#L31

@MSoegtropIMC I'm working on it now, and it seems to be going reasonably well (I've not yet managed to produce any artifacts, but probably soon. You say that you have a way to sign MacOS binaries? If so, I'm definitely interested.

@LasseBlaauwbroek : I can supply scripts which work locally on a Mac, but you would have to have your own signing key as Apple developer (and a Mac).

Ah, okay, I don't have a Mac, and I'm not in the developer program, so I guess we'll do without MacOS binaries for now. Thanks anyway.

I'm actually meeting quite a few problems in getting binaries for any of the platforms (most of them seem to be related to installation errors of packages, not coq-platform itself). I remember this being much easier a year ago, apparently the OCaml ecosystem has seen some regressions.
I've managed to hack together some binaries that are good enough for the purposes of our course, so my immediate need is satisfied. However, in the longer term, it would be nice if I could test my Tactician package with Coq platform. For this purpose, I've set up a fork here: https://github.com/coq-tactician/platform. Most of the tests are currently failing for one reason or another. Specifically for the Snap package, dose3 is inexplicably failing to compile even though it succeeds in the Ubuntu target (see here https://github.com/coq-tactician/platform/runs/5134182512?check_suite_focus=true). Currently I don't know how to debug this because the only method of creating a snap package that is provided is through Github actions. Just for the purposes of debugging alone, it would be nice if I could create a Snap package on my local machine.

Note, though, that the Mac installers don't work at all without signing.

Is this really true? It used to be the case that you could still run an unsigned macOS application (by right-clicking and clicking Open, something that is anyway needed today on recent macOS versions because the application is not notarized).

Thanks @gares, I'll try this out. It may be useful to document this process in the platform readme.

Note, though, that the Mac installers don't work at all without signing.

Is this really true? It used to be the case that you could still run an unsigned macOS application (by right-clicking and clicking Open, something that is anyway needed today on recent macOS versions because the application is not notarized).

Yes, it is really true, at least for macOS BigSur+. You can still run non-notarized apps using the right click open thing, but you can't run unsigned apps.

@LasseBlaauwbroek : I just wanted to ask what the outcome of this was. Can you please summarize what from your point of view is missing?

The outcome of this was mostly negative, but as far as I can see not particularly because of the platform. I tried Enrico's suggestions (and followed some other snap tutorials) but I'm unable to create a local snap build as of now. My laptop actually crashes during the generation of the Coq package, but as far as I can tell this is because of some virtualization issue that has little to do with the platform. (Note that I'm also experiencing issues for the MacOS and Windows CI target, currently the only thing that works is the Ubuntu target; but again this seems to be mostly because of issues with upstream Opam packages and a baffling bug on Windows, nothing immediately related to the platform.) For now I've given up on creating a full platform build, but I'll no doubt get back to that someday.
Specifically the question of creating a custom snap package, I think it would be enough if @gares comments/suggestions in this thread on how to locally generate a snap package would be put in a README somewhere. Perhaps together with some useful links to the snapcraft documentation/tutorials.
Apart from the documentation issue, I think this can be closed.

If you are interested in the CI failures, see below. Any suggestions on how to resolve any of it would be appreciated: https://github.com/coq-tactician/platform/actions

So "https://github.com/coq-tactician/platform" is a clone of Coq Platform 2022.01 and you just changed the pick files and the picks to build in the github action files? Are there other changes? This should be fairly easy to do provided the pick files themselves work.

I Indeed added some custom picks and enabled them in the CI.
But I also upgraded OCaml to 4.12 to make MacOS happy due to https://github.com/AltGr/ocaml-mccs/issues/33. Additionally I removed the use of the mingw repo for Windows (not sure exactly why anymore).
For Windows and Snap, upstream packages are still failing, which does not seem to have anything to do with Coq Platform.
For MacOS I'm getting lots of errors like
##### Copy system shared libraries #####
Copying shared libraries for _dmg/Coq_Platform_2022.01.0.app/Contents/Resources/bin/coqtacticworker.opt ...
Some of the paths in the dependency tree could not be resolved
Maybe you already bundled coqtacticworker.opt?
Could not resolve /usr/lib/libSystem.B.dylib
Could not resolve /usr/lib/libSystem.B.dylib

My best guess is that this is due to my Coq packages overwriting the standard library. But I've not investigated this further yet.

The Windows build will definitely fail if you remove the MinGW repo.
Let me take one of your pick files and build them locally and see what happens. If the picks build locally, they should also build in CI.
The Mac library issues shouldn't have anything to do with overwriting standard library files.
I will have a look after the 2022.03 release, since this has nothing to do with the release.

Yeah, the removal of the MinGW repo may have been a mistake (but it was also not working before the removal).
Note that my pick files do not build locally for me either. There are just a bunch of upstream problems that I've been unable to resolve on any platform apart from Linux (it used to work last year which is very annoying; there have been several regressions in the OCaml ecosystem).
Note that I don't expect you to resolve any of that, most of these issues seem to be outside of the platform. (But if you want to take a look that would of course still be appreciated.) The only bug that might be directly related to the platform are the MacOS errors.

I can definitely have a look.
The MacOS issue might be related to this change in macOS:
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes
Search for "dynamic linker cache".
But the Platform shared library copier should be able to detect that this is a system library and need not be copied to the installer (it tries to copy libraries from MacPorts or HomeBrew). I will see.

authors: LasseBlaauwbroek MSoegtropIMC Zimmi48

repo: coq/platform


text:
Add the libraries for undecidability and first-order logic to the Platform

Coq Library of Undecidability Proofs is a collection of definitions and results related to computability, not least the halting problem. For example, it allows Coq users to prove that some property is undecidable. The library was recently relicensed under the reusability-friendly MPL-2.0 license.
Coq Library for First-Order Logic is a library containing syntax, semantics and proof systems of first-order logic, building on the undecidability library. This library was recently relicensed under the permissive MIT license, a license known for making extensive reuse possible.
Since these two libraries formalize important basic computer science concepts that are not available in the Coq standard library and are not provided by other Platform packages (other than as isolated small fragments), I propose that these two libraries are included in the Platform. For example, if the community is aware of this FOL formalization, other FOL formalizations can be proved equivalent.
Maintainers of these two libraries I have interacted with include @yforster @dominik-kirst @dmxlarchey @mrhaandi

Thanks for bringing this up Karl, I'm in favour of including both!
I just prepared for an opam release compatible with 8.18 for coq-library-undecidability, @dominik-kirst and @JoJoDeveloping will soon do the same for coq-library-fol.
In the line of basic computer science concepts there is also https://github.com/uds-psl/coq-library-complexity with the Cook-Levin theorem and a time equivalence proof for Turing machines and lambda-calculus, but it's (probably) forever stuck on 8.16 due to a lack of maintainers.

I've filed https://github.com/coq-community/manifesto/issues/150 for coq-library-complexity to look for a new maintainer, maybe we get lucky :)

There is a release for coq-library-fol now. Is there anything else we need to do for both libraries to be included in the platform? CC @dominik-kirst

From my perspective, everything technically required is there, hopefully we can hear from the editorial board on a decision soon akin to here, cc @ybertot
I also hope we can get https://github.com/coq/platform/issues/344 resolved, since coq-library-undecidability depends on it.

authors: palmskog yforster


text:
Missing clippy ignore lint

Now core tests are failing because this lint skipper got lost somewhere along the way.

Can someone perhaps explain how

clippy can return the large result error https://rust-lang.github.io/rust-clippy/master/index.html#result_large_err
but when it is told to ignore the large result error, it pretends that it's never heard of such a thing
How can there can be two versions of rust running simultaneously / switch depending on whether there's an allow -A clippy::result-large-err flag?

Seems like it was probably a caching issue

repo: coral-xyz/anchor


text:
CORE-6373 - Test via the processor in SynchronisationProxy

https://r3-cev.atlassian.net/browse/CORE-6373

Nothing major, just a few suggestions.
Have you tried to view the coverage? (/gradlew :components:membership:synchronisation-impl:clean :components:membership:synchronisation-impl:test :components:membership:synchronisation-impl:jacocoTestReport)

Added some more tests and re-ran coverage.

The only line which is not tested is line 318 in SynchronisationProxyImpl. I unfortunately couldn't really come up with any hack there.

repo: corda/corda-runtime-os


text:
server memory highly load due to too many connections？

Our Environment and Config:
os: centos 6
etcd Version: 3.2.11
Git SHA: 1e1dbb2
Go Version: go1.8.5
Go OS/Arch: linux/amd64
Etcd config:
name: 'etcdserver-test02'
data-dir: /usr/etcd/data
wal-dir: /usr/etcd/data/wal
snapshot-count: 5000
heartbeat-interval: 1000
election-timeout: 5000
quota-backend-bytes: 0
listen-peer-urls: https://192.168.1.100:2380
listen-client-urls: https://192.168.1.100:2379
max-snapshots: 5
max-wals: 5
cors:
initial-advertise-peer-urls: https://192.168.1.100:2380
advertise-client-urls: https://192.168.1.100:2379
discovery:
discovery-fallback: 'proxy'
discovery-proxy:
discovery-srv:
initial-cluster: 'etcdserver-test01=https://192.168.1.101:2380,etcdserver-test02=https://192.168.1.100:2380,etcdserver-test03=https://192.168.1.102:2380,etcdserver-test04=https://192.168.1.103:2380,etcdserver-test05=https://192.168.1.104:2380,etcdserver-test06=https://192.168.1.105:2380,etcdserver-test07=https://192.168.1.106:2380'
initial-cluster-token: 'etcd-cluster-kfefeiifeNHHEfeifek'
initial-cluster-state: 'existing'
strict-reconfig-check: false
enable-v2: false
enable-pprof: true
proxy: 'off'
proxy-failure-wait: 5000
proxy-refresh-interval: 30000
proxy-dial-timeout: 1000
proxy-write-timeout: 5000
proxy-read-timeout: 0
client-transport-security:
ca-file: '/usr/etcd/config/ssl/ca.pem'
cert-file: '/usr/etcd/config/ssl/server.pem'
key-file: '/usr/etcd/config/ssl/server-key.pem'
client-cert-auth: true
trusted-ca-file: '/usr/etcd/config/ssl/ca.pem'
auto-tls: true
peer-transport-security:
ca-file:  '/usr/etcd/config/ssl/ca.pem'
cert-file: '/usr/etcd/config/ssl/member2.pem'
key-file: '/usr/etcd/config/ssl/member2-key.pem'
peer-client-cert-auth: true
trusted-ca-file: '/usr/etcd/config/ssl/ca.pem'
auto-tls: true
debug: true
log-package-levels:
log-output: default
force-new-cluster: false
This case occured when  10000+ clients connected  etcd cluster(7 nodes) ； After a period of time,  I found some clients  connected failed with the error (“context deadline exceeded”); Then ,by the monitor system，I observed that the memory of that two hosts have exceeded 30G（the two nodes total memory：32G），but the grafana displayed that etcd process in that two hosts only consumed memory not large than 5G and the hosts wasn’t responding.
Picture as follows:

Besides the above , by analysing  the etcd log , I found a lot like these information :
etcdmain: rejected connection from “192.168.1.104:32427" (error "read tcp 192.168.1.102:2380->192.168.1.104:32427: i/o timeout", ServerName “”),why?
And in the cluster ，I found each member has multy connection on port 2380 with other member repeatly，it’s so strange ,as follows:
ESTAB      0      0           192.168.1.102:2380         192.168.1.104:14203
ESTAB      0      0            192.168.1.102:2380        192.168.1.104:20579
ESTAB      0      0            192.168.1.102:2380         192.168.1.104:19975
ESTAB      0      0            192.168.1.102:2380        192.168.1.104:15983
ESTAB      0      0           192.168.1.102:2380        192.168.1.104:20296
ESTAB      0      0            192.168.1.102:2380        192.168.1.105:60271
ESTAB      0      0            192.168.1.102:2380         192.168.1.104:18111
ESTAB      0      0            192.168.1.102:2380         192.168.1.105:60273
ESTAB      0      0           192.168.1.102:2380        192.168.1.104:18323
ESTAB      0      0          192.168.1.102:2380         192.168.1.104:20451
ESTAB      0      0            192.168.1.102:2380        192.168.1.104:18217
ESTAB      0      0            192.168.1.102:2380         192.168.1.104:19466
ESTAB      0      0            192.168.1.102:2380       192.168.1.104:15917
ESTAB      0      0            192.168.1.102:2380        192.168.1.104:18318
ESTAB      0      0            192.168.1.102:2380         192.168.1.105:60194
ESTAB      0      0            192.168.1.102:2380         192.168.1.104:20152
ESTAB      0      0            192.168.1.102:2380         192.168.1.103:16269
ESTAB      0      0            192.168.1.102:2380        192.168.1.103:16615
ESTAB      0      0            192.168.1.102:2380         192.168.1.103:17397
ESTAB      0      0            192.168.1.102:2380         192.168.1.103:17397
ESTAB      0      0            192.168.1.102:2380         192.168.1.103:17397
ESTAB      0      0            192.168.1.102:2380         192.168.1.103:17397
ESTAB      0      0            192.168.1.102:2380         192.168.1.103:17397
……..
…….(so many connections)
when in host 192.168.104 ,  I use ‘ss’ command  to find the connections from local to foreign:
ss |awk '{print $5}'|grep ":2380"|awk -F ":" "{print $1}"|sort |uniq -c|sort
     3 192.168.1.101:2380
     3 192.168.1.102:2380
     3 192.168.1.103:2380
     3 192.168.1.1042380
     3 192.168.1.100:2380
  3498 192.168.1.106:2380
here， 3498 connections to 192.168.1.106 , it’s so discuzing！
So，my problems is as follows：

why a member has too many connections with other member repeatly？
why etcd occupied memory is not large than 5G，but the host memory has exceeded 30G？Is this due to many connections？
@gyuho @xiang90

@gyuho Can you close this issue?   This is the same problem as #9911 , and I record the detail on my blog https://www.cnxct.com/etcd-lease-keepalive-debug-note/  why it happened.

repo: coreos/etcd


text:
etcdserver: detect raft stravation

/cc @heyitsanthony

@heyitsanthony PTAL.

lgtm but please fix the speling in the commit title


text:
TESTING PR: grpcproxy with LRU

Testing PR https://github.com/coreos/etcd/pull/5493.

I did something like this, and seems working?
git remote add mq git@github.com:mqliang/etcd.git
git fetch mq

git cherry-pick 306d6d96652501467c67c8b757e5f70be395d968
cd cmd/
godep restore

go get -v -d github.com/davecgh/go-spew/spew
go get -v -d github.com/golang/groupcache/lru
./scripts/updatedep.sh

/cc @xiang90 @mqliang
Will close this PR, once @mqliang figures out in his branch.

@xiang90 @gyuho I remove the whole workspace of etcd, and refetch from remote, then I succeeded. Seems my workspace was broken. Thanks for you guys patient helping. This cloud be closed.

authors: gyuho mqliang


text:
etcdserver: Automated cherry pick of detailed "took too long" warnings to release-3.1

Same as #9821 but to 3.1.

@gyuho Okay to backport this one all the way to 3.1?

@jpbetz Sure, let's merge on greens. Thanks.

authors: gyuho jpbetz


text:
Handle subnet lease getting expired

Although flannel will start renewing the lease an hour prior to expiration, it could still get lost: e.g. VM getting suspended. Flannel should try to get the same subnet assignment if it's still available but fall back to a new lease and signal the fact.

Is there any work under way for this? It'd be incredibly useful as right now if a machine loses a lease and gets a new one it renders any containers on the machine with no network connectivity.

One implementation of this is in #610

Also see #520 for some good questions about how flannel handles this at the moment.

When fixing this, we should make sure this failure scenario is discussed clearly in the docs.

FWIW, the system design that we've converged on for Cloud Foundry is that hosts are preferentially assigned their prior lease, even if it "expired."  And if a new host appears, it is assigned a lease in the following priority order:

prefer subnets that have never been given out before, or subnets which were explicitly relinquished by a cleanly-terminating host.
if none of those exist, only then does the new host take over an expired lease, and in that case it chooses the oldest such lease.

This is meant to minimize the probability that a lease is "stolen" from a live, but partitioned, container host.  But if that does occur, once the partition heals and the "victim" host re-connects, it will discover that its lease is no longer valid.  In this case, the victim host falls into a special, noisy failure mode which will (1) prevent any new workloads from being scheduled and (2) trigger the orchestration system to evacuate any existing workloads.  Once the evacuation is complete, the host will clean up any leftover networking state (e.g. remove the VXLAN device), acquire a new lease for itself and begin accepting new workloads.
We think this is the right plan.   Feedback welcome.

This is now fixed in v0.8.0

authors: eyakubovich macb rosenhouse tomdee

repo: coreos/flannel


text:
functional: ignore errors from poweroff

A follow up to 529209534, tests are constantly failing with a dbus error
which is probably a bug in systemd or systemctl. Not worth spending lots
of time on right now so just ignore it. If the container really fails to
shutdown the wait will eventually time out instead.

@marineam LGTM

authors: bcwaldon marineam

repo: coreos/fleet


text:
Inconsistent job labels between prometheus-operator discovery service and kube-prometheus

What did you do?
Deployed prometheus-operator with kubernetes-mixin for alerting.
What did you expect to see?
Matching job labels between prometheus-operator and kubernetes-mixin.
What did you see instead? Under which circumstances?
The job labels provisioned by [contrib/kube-prometheus/jsonnet/kube-prometheus/kube-prometheus-bootkube.libsonnet] do not match the upstream job selectors, which causes alerts (like CoreDNSDown and KubeVersionMismatch) that depend on these selectors to misfire.
Looking at the other configuration it looks like these are the only discovery services that append -prometheus-discovery and so I think the name change should happen in this repo.
Environment

Prometheus Operator version:

Current master (f8343b294f49c9009478138bd5572573f28811ec)

Kubernetes version information:

Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}```

* Kubernetes cluster kind:

kops 1.10

* Manifests:
N/A

* Prometheus Operator Logs:
N/A

I commented in #2181, could you elaborate regarding my comment either here or in #2181?

Apologies, our service discovery was missing the k8s-app label and causing the metrics job label to default to the full suffixed name.

Closed PR as it was misconfiguration on our side for the service discovery label as per my comment in the PR. Thanks for the quick response @brancz!

authors: brancz seanson sjtyro

repo: coreos/prometheus-operator


text:
prometheus: syncronize nodes to enpoints object

As the kubelet will not be self-hosted for the time being, we need to be able to handle it anyways. This is an implementation of a feature synchronizing nodes into an Endpoints object for discovery by Prometheus.
@fabxc

@fabxc applied changes and tested on minikube.


text:
add support for Aliyun images

This adds support for images uploaded to the Aliyun cloud.
Mostly a copy/paste of the existing AWS types and methods.
Closes: #29

I imagine there is a better way to handle the similarities between AWS + Aliyun, but my Go isn't that great these days, so I brute forced it

(Marked as Draft in case there is a better solution that should be pursued)

cc @bgilbert who may have opinions

Next step is a PR to bump this vendored version in coreos-assembler btw.

authors: cgwalters miabbott

repo: coreos/stream-metadata-go


text:
SidebarNav requires location prop

It would be great to add this prop to propTypes object
package.json
"dependencies": {
    "@coreui/coreui": "^2.1.9",
    "@coreui/react": "^2.1.5",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "..."
  },

Hi @e-burlaka-md
Could you please provide us some details regarding the issue?
Is this an error report or an enhancement request?

It is an enhancement request, in the example below you pass all props from Route component to AppSidebarNav
I forget to do that and got the error, it took me some time to understand what prop do I need to pass to AppSidebarNav
Someday this improvement save the time to someone
DefaultLayout.js

Also encountered that issue. Fixed by wrapping DefaultLayout with withRouter.

In v3 giving the location is no longer necessary

authors: e-burlaka-md mankutila woothu xidedix

repo: coreui/coreui-react


text:
How to give custom column names in CoreUI Table columns?

Title,
I have an array of objects coming in as items for the table
For e.g. [{name:'Sam',age:'24}]
I want to set custom field names like instead of column to be named as age, I want it to display column name as Id instead of age.
So, Basically how can I set custom column names?

@pverma911
See fields prop: https://coreui.io/vue/docs/3.0/components/table.html#cdatatable-api

@pverma911
See fields prop: https://coreui.io/vue/docs/3.0/components/table.html#cdatatable-api

@pverma911
See fields prop: https://coreui.io/vue/docs/3.0/components/table.html#cdatatable-api

I didn't understand it can you pls give me an example as to how to?

@pverma911
See fields prop: https://coreui.io/vue/docs/3.0/components/table.html#cdatatable-api

I didn't understand it can you pls give me an example as to how to?

@xidedix Need your help buddy.
or Anyone else?

@xidedix Need your help buddy.
or Anyone else?

fields: [
  { key: 'age', label: 'id'},
   ...
}

fields: [
  { key: 'age', label: 'id'},
   ...
}

repo: coreui/coreui-vue


text:
Multiple types of Torch builds

Multiple Torch Builds
This PR adds support for two distinct types of PyTorch builds:

torch:base

New home for gooseai/torch-base-type containers
Builds with nvidia/cuda:[...]-devel-[...]
Extends nvidia/cuda:[...]-base-[...]
Low image size, fewer libraries at runtime

torch:nccl

Builds with and extends ghcr.io/coreweave/nccl-tests
Inherits special versions of nccl and HPC-X
Larger image size, extensive libraries at runtime
Supersedes old torch-nccl containers from this repository

These are both grouped under the "torch" container name, with differing tags.
Tag Suffixes
The existing tag format for containers in this repository is :<short commit hash> for commits to the main branch, and :<branch name>-<short commit hash> for commits to other branches.
Since these torch builds are highly parameterized (potential variables: edition [torch:base/torch:nccl], CUDA version, NCCL version, torch version, torchvision version), it is beneficial to allow for tag customization to denote different build versions—which may also benefit from the then-shared build cache.
To achieve this, this PR adds an optional tag-suffix parameter to the .github/workflows/build.yml template. This allows for tags of the form [<branch name>-]<short commit hash>[-<custom suffix>].
Examples
torch:base builds are suffixed with a version string to result in the following format:
ghcr.io/coreweave/ml-containers/torch:<short commit hash>-base-cuda{}-torch{}-vision{}

Where {} is a placeholder for the respective library's version number.
torch:nccl builds have a similar format:
ghcr.io/coreweave/ml-containers/torch:<short commit hash>-nccl-cuda{}-nccl{}-torch{}-vision{}

Fix for UCC integration in torch:nccl builds
torch:nccl builds now enable UCC integration, linking against HPC-X.
This was intended to be enabled when the torch-nccl builds were added, but the right combination of flags had not been set (USE_SYSTEM_UCC does not imply USE_UCC, for some reason), and furthermore a bug would have made it impossible to link against the UCX library in nccl-tests's HPC-X distribution anyway.
The combined torch Dockerfile now contains a workaround to fix that bug when nccl-tests is used as a base, and properly links against UCX.
Build process optimizations
The torch builds have been optimized for size, speed, and cache-friendliness by making use of more build stages, as well as cross-stage filesystem mounts.
Highlights:

Torch repository versions are now downloaded as their own build stage.

This means they can now be cached separately and shared across runs with different CUDA base images.
This also means they can download in parallel with the builder stage.

No torch source files are stored in the builder stage's filesystem; they are only mounted temporarily from the downloader stage.
Torch build artifacts are all cleared except for the wheels to be distributed, to avoid bloating the intermediate image in the cache.
The final image no longer makes a copy of the torch wheels before installing them.

They are instead temporarily linked directly from the builder stage.

This looks awesome, like the nice PR doc.
Those image tags are getting long, splitting does have some impacts on the cache although since cache is synced at the end of each of the CI jobs anything running in parallel in CI will miss cache created by other parallel runs (which is unfortunate since these often get run together).  I would almost prefer keeping torch-base and torch-nccl as two separate images to maybe split that difference, but not a very strong opinion.

Also noticed that the workflows here only work out of the main repo since we only run them on push, to make PRs from forks able to run we need to add pull_request to the triggers for the top level workflows with the same path filters.  Mainly helpful to know that PRs result in working builds.

@arsenetar

This looks awesome, like the nice PR doc.
Those image tags are getting long, splitting does have some impacts on the cache although since cache is synced at the end of each of the CI jobs anything running in parallel in CI will miss cache created by other parallel runs (which is unfortunate since these often get run together). I would almost prefer keeping torch-base and torch-nccl as two separate images to maybe split that difference, but not a very strong opinion.

Image tags
As far as legal limits, the maximum length for a docker image tag (excluding the name) is 128 characters. A fully formatted torch:nccl tag with a 7-character hash and no branch prefix looks like abc1234-nccl-cuda11.8.0-nccl2.16.2-1-torch2.0.0-rc1-vision0.15.0-rc1, with 68 characters (though these are a bit longer than usual because of -rc1 version suffixes). This would leave about half of the character quota for an optional branch name, which should be plenty of room.
As far as aesthetics, having an extremely descriptive tag is pretty nice for visually scanning through versions quickly in the container repository, and being able to pluck out the right container without having to cross-reference docs/code/commits or manually downloading and probing them. And it ought to help people who use them in a Dockerfile keep track of any major changes if they want to update the version they are using later on.
So I think it'd be beneficial enough from a usability perspective to outweigh its visual clunkiness.
Caching and concurrency
On the first run they will miss out on cache-sharing, though on most subsequent updates the cache should help them out. For instance, if the base images for torch:nccl change, both parallel runs should be able to reuse the downloaded PyTorch repositories. And, since the builds running in parallel all use different base images, they wouldn't be able to share their cache for the builder steps anyway, so there isn't too much missed opportunity in that direction.
If the downloaded repositories change, both builds will re-download them in parallel, which will waste some bandwidth. I'm not sure if it would waste any storage, since the intermediate downloader stages will end up with identical contents; Docker might deduplicate the later one to save.
The builds can have their concurrency limited to an arbitrary extent with job concurrency groups to get maximal use out of of the downloader cache, but since each of these builds can take several hours, serializing them in any way may be a bit painful.

Also noticed that the workflows here only work out of the main repo since we only run them on push, to make PRs from forks able to run we need to add pull_request to the triggers for the top level workflows with the same path filters. Mainly helpful to know that PRs result in working builds.

Pull Request Builds
This is a good suggestion; none of the containers in this repository are currently built on the pull_request trigger.
Building a PR from an arbitrary fork results in arbitrary code execution on the runner, so workflows triggered from pull_request events have limited access to secrets. This would mean that they can't log in or push to the ml-containers ghcr.io repository, and since those steps are baked into the build.yml script, the runs would fail automatically.
The build and publish steps would benefit from being disentangled from one another, with the publish step being optional. This could also allow builds in branches to be tested without necessarily publishing them to the container image repository forever. Since this is a somewhat involved, repo-wide change with its own design considerations, it would be good to make it a separate issue, implemented apart from this one.
In the case of this PR, I test-ran the workflows by modifying build.yml's runs-on: [self-hosted, Linux] to runs-on: ubuntu-20.04 in a separate branch in my forked repo, which lets most of the steps run, though inefficiently. So these should be valid.

With regards to image tags, I was not worried about the max limit, and it seems like it should be large enough.   Splitting back to two different images for torch-nccl and torch-base was more about a top level clarity on there being two different "main" images more than anything (and slightly due to the one image already existing).  It also makes it slightly clearer that torch-nccl image is from the torch-nccl.yaml and such.  Not going to push too strongly for this, so if @wbrown is ok with the change to just a torch image with two distinct builds represented through the tags then I'll accept as well.
I would not want to limit concurrency of these builds any, the cache misses are not the worst here, and even so the matrix already creates a decent bit of invalidation between the different builds even though now there are more sections that can be shared with this new Dockerfile.
PR Builds from forks require approval to run which does help mitigate some concerns, however fork workflows do still have some differences as you stated.  Disabling push makes sense for forks as the intent is to verify the build succeeds more than anything else.  The impacted parts can be disabled fairly straightforward within the "build and push" step.  I do agree we can address that separately, was mainly making note for us.

@arsenetar @Eta0 Are we good to merge this?

@wbrown It was up to you to decide direction on the image change torch-nccl and torch-base vs torch (with nccl and base tags).

Confirmed with @wbrown; he said that torch with tag distinctions should be fine, so I'll merge it like this.

authors: Eta0 arsenetar wbrown

repo: coreweave/ml-containers


text:
nvm use not working

Issue:

nvm use is not working correctly. See errors:
C:\>nvm install 10
Version 10.24.1 is already installed.

C:\>nvm use 10
node vv10.24.1 (64-bit) is not installed or cannot be found.
C:\>nvm use 10.24.1
exit status 5: Access is denied.

exit status 5: Access is denied.

How To Reproduce:

nvm install 10
nvm use 10
See error
nvm use 10.24.1
See error again

Expected Behavior:
It should work.

Desktop:

OS: Windows 10
Browser: Firefox
Browser Version: latest mainstream. Don't know, don't care, not relevant.

Additional context:
A workaround exists, which is to start the command prompt with elevated privileges AND type in the fully qualified version number. This should not be neccesary - nvm should ask for privileges whenever it needs them. The user should not have to know in advance when a program needs magical admin rights.
And yes, I know there are already a couple of issues on this problem. They are unclear on the exact problem, full of non-solutions, and useless "me too" (so please stop doing that, people).

Duplicate of #708.

I stated I know about the other issues. They have gotten too spammy to make sense of it. But you insist, and presto: no solution. Just lots of "same here" and "me too" and superfluous screenshots.
You shouldn't be surprised to get a fresh new issue for the mess that #708 has become.

The issue is already filed and there is already a PR to fix it. Adding the same issue again simply adds work.

authors: coreybutler thany

repo: coreybutler/nvm-windows


text:
nvm install latest results in index out of range [3] with length 3

Issue:
I wanted to install the new 20.0.0 NodeJS version by running nvm install latest. This resulted in the following error instead:
> nvm install latest
panic: runtime error: index out of range [3] with length 3

goroutine 1 [running]:
main.checkVersionExceedsLatest({0x11c973f0, 0x6})
        C:/Users/corey/OneDrive/Documents/workspace/oss/coreybutler/nvm-windows/src/nvm.go:790 +0x220
main.install({0x11c120b0, 0x6}, {0xb2fa65, 0x2})
        C:/Users/corey/OneDrive/Documents/workspace/oss/coreybutler/nvm-windows/src/nvm.go:302 +0x35d
main.main()
        C:/Users/corey/OneDrive/Documents/workspace/oss/coreybutler/nvm-windows/src/nvm.go:87 +0xa69

Running nvm install 20.0.0 results in the same error.
How To Reproduce:

Run nvm install latest or nvm install 20.0.0
See error

Expected Behavior:
I expected the latest version of NodeJS to be installed.
Desktop:

OS: Windows 11

Additional context:
> nvm ls available

|   CURRENT    |     LTS      |  OLD STABLE  | OLD UNSTABLE |
|--------------|--------------|--------------|--------------|
|    20.0.0    |   18.16.0    |   0.12.18    |   0.11.16    |
|    19.9.0    |   18.15.0    |   0.12.17    |   0.11.15    |
|    19.8.1    |   18.14.2    |   0.12.16    |   0.11.14    |
|    19.8.0    |   18.14.1    |   0.12.15    |   0.11.13    |
|    19.7.0    |   18.14.0    |   0.12.14    |   0.11.12    |
|    19.6.1    |   18.13.0    |   0.12.13    |   0.11.11    |
|    19.6.0    |   18.12.1    |   0.12.12    |   0.11.10    |
|    19.5.0    |   18.12.0    |   0.12.11    |    0.11.9    |
|    19.4.0    |   16.20.0    |   0.12.10    |    0.11.8    |
|    19.3.0    |   16.19.1    |    0.12.9    |    0.11.7    |
|    19.2.0    |   16.19.0    |    0.12.8    |    0.11.6    |
|    19.1.0    |   16.18.1    |    0.12.7    |    0.11.5    |
|    19.0.1    |   16.18.0    |    0.12.6    |    0.11.4    |
|    19.0.0    |   16.17.1    |    0.12.5    |    0.11.3    |
|   18.11.0    |   16.17.0    |    0.12.4    |    0.11.2    |
|   18.10.0    |   16.16.0    |    0.12.3    |    0.11.1    |
|    18.9.1    |   16.15.1    |    0.12.2    |    0.11.0    |
|    18.9.0    |   16.15.0    |    0.12.1    |    0.9.12    |
|    18.8.0    |   16.14.2    |    0.12.0    |    0.9.11    |
|    18.7.0    |   16.14.1    |   0.10.48    |    0.9.10    |

This is a partial list. For a complete list, visit https://nodejs.org/en/download/releases

Had same issue, upgrade nvm-windows itself

Please search the prior issues before opening a new issue. This is the 9th duplicate of #955, and resolved in v1.1.11.

En la ultima version funciona.
https://github.com/coreybutler/nvm-windows/releases

authors: SimonCockx coreybutler ibotlold jastorgalj


text:
elaboration performance improvement

Ufortunately for HUGE designs I cannot really do much because there are 30k+ update blocks and the elaboration code involves a TON of for/if/isinstance statements, rending itself JIT-unfriendly

how do we actually fix those travis error due to hypothesis/attr?

definitely! making pip install faster is a great goal