Calico CNI installation fails with cridocker v0.3.12

Expected Behavior
Prior to v0.3.12 we were able to successfully install calico cni provider using the tigera operator to a baremetal kubeadm managed kubernetes cluster.
Actual Behavior
When updating our process to use cri-docker v0.3.12 we see bind errors during calico deployment.
Initially the tigera-operator fails to deploy.
 Normal   Pulled     15m                 kubelet            Successfully pulled image "<<redacted>>/tigera/operator:v1.32.3" in 21.153634784s (21.153662597s including waiting)
  Warning  Failed     13m (x12 over 15m)  kubelet            Error: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /var/lib/calico

After manually creating the folder /var/lib/calico on the controller node, the tigera operator pod deploys, but calico cni pods fail with
 Normal   Pulled     2m20s                 kubelet            Successfully pulled image "quay.io/calico/cni:v3.27.0" in 7.987855195s (7.988025596s including waiting)
  Warning  Failed     35s (x10 over 2m20s)  kubelet            Error: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /opt/cni/bin
  Normal   Pulled     35s (x9 over 2m20s)   kubelet            Container image "quay.io/calico/cni:v3.27.0" already present on machine

Steps to Reproduce the Problem

install and configure cri-docker
Deploy a kubernetes cluster (v1.25.5) on docker
deploy the tigera-operator (v1.23.3)

Specifications

Version: kubernetes v1.25.5
Platform: ubuntu
Subsystem: cri-docker v0.3.12

This is because https://github.com/Mirantis/cri-dockerd/pull/311 switched cri-dockerd from using the deprecated 'Binds' API to the new 'Mounts' API, which does not create missing directories by default: https://github.com/Mirantis/cri-dockerd/commit/bf1a9b950ffac52a722fc530444d6ac89b472170
To preserve backward-compatible behavior, we need to set CreateMountpoint to true (as it is false, the zero value, by default) in GenerateMountBindings.
cc @nwneisen @AkihiroSuda

Isn't CreateMountpoint here working?
https://github.com/Mirantis/cri-dockerd/blob/v0.3.12/libdocker/helpers.go#L224

Shoot, I missed that we're setting that in the diff. @anfechtung could you please let us know what Engine version you are using?

I am assuming by Engine you mean the docker runtime:
root@vm-compute1:~# docker --version
Docker version 24.0.2, build cb74dfc
root@vm-compute1:~#

docker --version is only the version of the CLI; to get the daemon version please provide docker version (also please provide docker info), which will interrogate the client and the server.

Client: Docker Engine - Community
 Version:           24.0.2
 API version:       1.43
 Go version:        go1.20.4
 Git commit:        cb74dfc
 Built:             Thu May 25 21:52:13 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.2
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.4
  Git commit:       659604f
  Built:            Thu May 25 21:52:13 2023
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
root@vm-compute1:~#

Client: Docker Engine - Community
 Version:    24.0.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.5
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.18.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

root@vm-compute1:~# docker info
Server:
 Containers: 156
  Running: 101
  Paused: 0
  Stopped: 55
 Images: 79
 Server Version: 24.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
  Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
 runc version: v1.1.7-0-g860f061
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
 Kernel Version: 5.4.0-170-generic
 Operating System: Ubuntu 18.04.6 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 12.74GiB
 Name: vm-compute1
 ID: 29543cf3-2f2a-45f6-a42a-cd31c9385775
 Docker Root Dir: /var/lib/docker
 Debug Mode: false

We might be downgrading the API version to <= v1.41 in somewhere?
https://github.com/moby/moby/blob/v24.0.2/api/server/router/container/container_routes.go#L526

Do you have any potential workarounds?  Or a planned fix?  I am trying to determine if it makes sense to go down the rabbit hole of pre-creating all of the needed directories.

https://github.com/Mirantis/cri-dockerd/pull/346 ought to solve this; would you mind testing a build off of master?
That being said, I think we should keep this issue open until we have a regression test.

Is there a deb package built from master, or would I need to build from master?  Currently we are using the deb package to install.

You would need to build from master; there are instructions and it is as trivial as a go build and moving the binary into the bin directory. Obviously that's not ideal and you'd want a release for production, but hopefully it validates the fix for you (and you'd get packages from the next patch release).

I compiled from master, and dropped the new binary on my cluster.  I am still getting the same error.  I tried setting the log level for the cri-docker service to debug, but it didn't produce anything useful.

After reading through the docker documentation, and the go docker libraries (Mount and Volume), I think this is simply the expected behavior when using docker mounts.

It looks like some more digging will have to be done to determine where the fault lies; however, this is not the intended behavior. Kubernetes requires implicit directory creation as it was based on the Engine Binds API, which had this default behavior. We specifically added a new option to the Mounts API to enable implicit directory creation in v23, so if it doesn't work, there is a bug either in the daemon, or in cri-dockerd.

I have the same problem with Promtail Pod. It tries to bind the path at /run/promtail but it can't. Normally, it should be created on the container's initial.
Pod Event
Events:
  Warning  Failed  8m17s (x12 over 10m)  kubelet  Error: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /run/promtail

cri-dockerd version
$ cri-dockerd --version
cri-dockerd 0.3.12 (c2e3805)

Docker Information
$ docker version
Client: Docker Engine - Community
 Version:           25.0.2
 API version:       1.44
 Go version:        go1.21.6
 Git commit:        29cf629
 Built:             Thu Feb  1 00:22:57 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          25.0.2
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       fce6e0c
  Built:            Thu Feb  1 00:22:57 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.28
  GitCommit:        ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker info
Client: Docker Engine - Community
 Version:    25.0.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.12.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.5
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
Server:
 Containers: 27
  Running: 25
  Paused: 0
  Stopped: 2
 Images: 24
 Server Version: 25.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.0-102-generic
 Operating System: Ubuntu 22.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 7.61GiB
 Name: c3-pn-k8s-cp-01
 ID: d9c0761d-e30b-482c-98b5-24129d5e370a
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: cthongrak
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

Nodes using cri-dockerd 0.3.11 are working normally

@corhere and @nwneisen are cooking a new 0.3 release which should revert the problematic change; though we still need to solve this for 0.4 in order to go forward.

Is there any minimal reproducer that does not depend on Calico?
Can't repro the issue with the following yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: bind
spec:
  volumes:
    - name: mnt
      hostPath:
        path: /tmp/non-existent
  containers:
    - name: busybox
      image: busybox
      args: ["sleep", "infinity"]
      volumeMounts:
        - name: mnt
          mountPath: /mnt

Not sure what may have changed, but this same error does not occur in v0.3.13.

@anfechtung v0.3.13 has the problematic change #311 reverted.

Still can't repro the issue with calico. I wonder if the issue might have been already fixed in a recent version of Docker?
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.3/manifests/tigera-operator.yaml

Used minikube v1.33 (Kubernetes v1.30.0, Docker v26.0.1, cri-dockerd v0.3.12, according to strings /usr/bin/cri-dockerd)
Followed the "Operator" steps in https://docs.tigera.io/calico/3.27/getting-started/kubernetes/minikube

Bad Docker versions: <= v24.0.9, <= v25.0.3
Good Docker versions: >= v25.0.4, >= v26.0.0
Seems fixed in https://github.com/moby/moby/compare/v25.0.3...v25.0.4

I was able to reproduce the error and fix. I followed the calico quickstart steps  using minikube
Failure
Using minikube v1.31.1, calico fails due to the missing mount
nneisen:~/code/cri-dockerd (master): minikube  version
minikube version: v1.31.1
commit: fd3f3801765d093a485d255043149f92ec0a695f

nneisen:~/code/cri-dockerd (master):  kubectl get pods -A
tigera-operator   tigera-operator-786dc9d695-p86vw   0/1     CreateContainerError   0            24s

nneisen:~/code/cri-dockerd (master): kubectl describe pod tigera-operator-786dc9d695-p86vw -n tigera-operator
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  66s                default-scheduler  Successfully assigned tigera-operator/tigera-operator-786dc9d695-p86vw to minikube
  Normal   Pulling    66s                kubelet            Pulling image "quay.io/tigera/operator:v1.32.7"
  Normal   Pulled     60s                kubelet            Successfully pulled image "quay.io/tigera/operator:v1.32.7" in 5.814069007s (5.814076587s including waiting)
  Warning  Failed     10s (x6 over 60s)  kubelet            Error: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /var/lib/calico
  Normal   Pulled     10s (x5 over 60s)  kubelet            Container image "quay.io/tigera/operator:v1.32.7" already present on machine

Working
After upgrading my minikube version to v1.33.0, calico is successful
nneisen:~/code/cri-dockerd (master): minikube version
minikube version: v1.33.0
commit: 86fc9d54fca63f295d8737c8eacdbb7987e89c67

nneisen:~/code/cri-dockerd (master): kubectl get pods -A
tigera-operator   tigera-operator-6678f5cb9d-h7c9f   1/1     Running   0          10s

nneisen:~/code/cri-dockerd (master): kubectl describe pod tigera-operator-6678f5cb9d-h7c9f -n tigera-operator
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  3m4s   default-scheduler  Successfully assigned tigera-operator/tigera-operator-6678f5cb9d-h7c9f to minikube
  Normal  Pulling    3m3s   kubelet            Pulling image "quay.io/tigera/operator:v1.32.7"
  Normal  Pulled     2m59s  kubelet            Successfully pulled image "quay.io/tigera/operator:v1.32.7" in 4.388s (4.388s including waiting). Image size: 69724923 bytes.
  Normal  Created    2m59s  kubelet            Created container tigera-operator
  Normal  Started    2m59s  kubelet            Started container tigera-operator

Solution
We should document that

the master branch and 0.4.x releases require docker >= v25.0.4, >= v26.0.0
the release/0.3.x branch and releases are for <= v24.0.9, <= v25.0.3

cc: @corhere @neersighted @AkihiroSuda


Change file names and code based on styles guide

add rackt rules.
fix eslint errors and warnings.
rename components files and folders for style convention.
improve code based on coding styles.

npm install to include eslint-config-rackt

:shipit:


🚀 Feature: Retry if afterEach fails

in continuation of https://github.com/mochajs/mocha/issues/2120 and https://github.com/mochajs/mocha/pull/1989
the issue is that if anything throws in afterEach hook, the test won't retry and fail immediately.
I'll try to explain the use case.
When we test our application end-to-end (using webdriver or similar technologies) we need retries, because most of the time tests fail due to network errors, webdriver errors or other stuff that we don't control. And it's been working great if something sketchy happens inside the it body. But there is one use case:
When we test an app using webdriver, often times we want to make sure that there was no errors in the console after the test has finished. Even though the functionality works, something can throw (React.propTypes validation, logging, random undefined is not a function, etc..) and you most likely want to catch errors like that.
here is a simplified version of an example test:
describe('a button', function() {
    it('shows a modal window when button is clicked', function(done) {
        webdriverAPI.click('.button') // we find some button on our page that has a specific class and click it
        .then(() => webdriverAPI.isPresentOnThePage('.modal-window')) // then we expect a window to show up
        .then(() => done()); // if it's there, we assume that functionality is ok and pass the test
    });

    // in after each hook, we want to make sure nothing threw an error in the browser.
    //
    // Just to be clear. the browser environment is a completely separate process and
    // not the current node.js process. We only interact with it via `webdriverAPI`
    afterEach(function(done) {
        webdriverAPI.getConsoleOutput().then((output) => {  // capture the output of the browser console that was printed during the test execution
            if (output) {
                // if there is something => blow up the test
                return done(new Error(`unexpected output in the console: ${output}`));
            }

            done();
        });
    });
});

It's been working fine, but sometimes you get a weird errors like profile_picture.jpg failed to load because of some network problem which brings your entire test suite down.
It would be really awesome if we could retry the entire test if the afterEach hook fails.
Often people propose some kind of local retry solution like
afterEach(function() {
  tryFiveTimes(function() {
      /* check the console and throw if errors are present */
  });
});

but in this case it won't work, becasue by the time you enter the afterEach hook, the output is already in the console, and every time you check for it you'll get the same result. The only solution is to retry the whole thing (fail the test and run it again with all the hooks).
I understand that before and after hooks are supposed to setup/teardown the environment and if we do retry on all the hook failures it can mess it up, but maybe there can be some kind of explicit API for it. for example
afterEach(function(done) {
    webdriverAPI.getConsoleOutput((output)  => {
        if (output) {
            this.failAndRetry(); // basically does `retries++` and runs the test again if the are still retries left
        } else {
            done();
        }
    });
});

Wish there was a non-boilerplate solution to this. Having to add retry logic to my hooks manually is pretty frustrating when I'm dealing with network issues on database cleanup.

Regarding the first example of retrying or failing the test based on something that should apply to all of them, you can do it today by using regular functions instead of hooks. Instead of (adapted from the original example with the comments stripped out for simplicity of comparison and the missing promise error handling added):
describe('a button', function() {
    it('shows a modal window when button is clicked', function(done) {
        webdriverAPI.click('.button')
        .then(() => webdriverAPI.isPresentOnThePage('.modal-window'))
        .then(() => done(), done); // NB: second done is to report any errors thrown inside the promise callbacks
    });

    afterEach(function(done) {
        webdriverAPI.getConsoleOutput().then((output) => {
            if (output) {
                return done(new Error(`unexpected output in the console: ${output}`));
            } else {
                done();
            }
        });
    });
});

...you could just convert it so the test calls the error-checking code:
describe('a button', function() {
    it('shows a modal window when button is clicked', function(done) {
        webdriverAPI.click('.button')
        .then(() => webdriverAPI.isPresentOnThePage('.modal-window'))
        .then(validateTestConsole.bind(null, done), done);
    });

    function validateTestConsole(done) {
        webdriverAPI.getConsoleOutput().then((output) => {
            if (output) {
                done(new Error(`unexpected output in the console: ${output}`));
            } else {
                done();
            }
        });
    }
});

(Tangentially, this could be simplified a little by leveraging Mocha's promise support:)
describe('a button', function() {
    it('shows a modal window when button is clicked', function() {
        return webdriverAPI.click('.button')
        .then(() => webdriverAPI.isPresentOnThePage('.modal-window'))
        .then(validateTestConsole);
    });

    function validateTestConsole() {
        return webdriverAPI.getConsoleOutput().then((output) => {
            if (output) {
                throw new Error(`unexpected output in the console: ${output}`);
            }
        });
    }
});

I would argue that this is not only doable without special hook behaviors/functions, but more correct to begin with. The fundamental issue here isn't the retrying. The issue is that you want this check for browser errors to effectively be part of the test: the test fails if there were errors in the browser. As such, it's really test code and belongs in the test; hooks are designed for running cleanup whether the test fails or not, and they aren't designed to be an extension of the tests themselves. The fact that hooks can run for multiple different tests is, I think, incidental when any function can be run for every test (albeit by calling it, but that's not complicated).

Retrying cleanup actions within a hook, without retrying the test itself, would be another matter -- I'd like some way to abstract it out that would be useful not only in test code but for anything where a certain amount of error needs to be ignored...

This has been pending since 2016. Its total interaction count including 👍s has been roughly one a year. Per #5027, we're trying not to make big changes such as new API additions that aren't highly beneficial. I'm going to go ahead and close this out.
If someone really wants a retry API, please do yell at me. We can re-open this. But please also provide a concrete proposal for what you'd like that API to look like. 🙂


"passfault policies" dropdown menus not loaded when self-hosted

Hey guys,
Could you have a look at my hosted instance? It is running the latest master branch version as date of today, that is, commit b13eaad192c90498eaefc9aecacfa157f48cdb94 Based on this commit I only changed the background through CSS, and it failed before doing so. Therefore, there's no chance I broke anything by code.
The observed issue is that in my instance, some js error occurs and the "attacker" and "hasher" lists aren't loaded.
You can see the following error in firefox: ReferenceError: loadSelectCracker is not defined, and Can't find variable: loadSelectCracker  in qupzilla/falkon browser. They point to the embedded script in password_policy.html at line 61:
function updateCrackTime(){
	var value = $("#slider").slider('value');
	$("#crackTime").html(time2Crack(scale(value), $('#attacker').val(), $('#hasher').val()));
}

$(document).ready(function (){
→  loadSelectCracker( $('#attacker') ); ←
  loadSelectProtection( $("#hasher") );
}
);

I don't understand this JS code, so I can't debug any further. The parent script passfault.js is used successfully somewhere else, for instance, when describing the matched results. I think this shouldn't be the problem.
The expected behavior would basically be both dropdown menus populating correctly, so that users are able to use the policy slider, just like in the demo site.
Please tell me if I can help trying something else.
Cheers,
fdk

Nice find.  I get the same thing locally on my box.  It looks like I haven't updated the web site in a while.  I'll have to find some time after work to get this cleaned up.


SQLServerBulkCopy / getDestinationMetadata fails when there's an apostrophe in the table name

Driver version or jar name
mssql-jdbc:6.4.0-jre8
Problem description
When attempting to bulk upload to a table with ' in the name the upload fails with:
com.microsoft.sqlserver.jdbc.SQLServerException: Unable to retrieve column metadata.
at

com.microsoft.sqlserver.jdbc.SQLServerBulkCopy.getDestinationMetadata(SQLServerBulkCopy.java:1781)
The code does queries such as:
select collation_name from sys.columns where " + "object_id=OBJECT_ID('" + destinationTableName + "')

Which fails because destinationTableName contains unescaped '

Hi @Gaff
Thanks for bringing forward this issue with us. I've created a PR that fixes this issue in the driver. Please take a look and let me know for any changes needed.

Wow thanks for the quick turnaround! Looks good (in so much as I can tell, I'm not going to claim to be an expert).

Hi @Gaff
PR #780 has been merged and will be available since v7.1.1 release version. Closing issue.


[Access Request] 5753 "Get Source Documents"

Could you please change the following variables to protected?
var
    OneHeaderCreated: Boolean;
    LineCreated: Boolean;
    WhseHeaderCreated: Boolean;
    SkipBlockedCustomer: Boolean;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11415.


'Time Left' for upgrades buggy

Since update 2.5 the time left for the upgrades seems buggy. It always shows the time left when I had frenzy, but it is already gone and the time ticks upwards but in irregular steps...
And while frenzy the tick-steps are also strange...

This is because time left in now calculated by average CpS over the past 10m as a default. If you go to options, calculation, you can revert it to current CpS.

Ah thank you!
I had only noticed this average CPS in the stats without thinking about the usage.


Token refresh not working properly?

I have the feeling that I am logged out too frequent.
Does anyone have the same feeling? Maybe the token refresh logic does not work properly.

I have the same feeling. I am getting logged out multiple times per day.

Same. Happens to me too.

I do not observe this issue anymore. @SteinRobert @vvvityaaa Do you still get logged several times per day???

Seems to be solved, now.


lazy load NotificationBar

We have people complaining on twitter that the snippets of webpack search results show content of notification bar.

I've inspected the search results and did find something like below which is bad for user experience:

This pull request would lazy load the notification bar and stop it from included in html.

This method just works around the issue, not fix it. We might need something like react-helmet to specify <meta name='description' /> for every page.

Although workaround, But I really like the improvement , and the thought 🚀

I would also prefer a proper solution, and return the correct HTML tags from the server.

I would also prefer a proper solution, and return the correct HTML tags from the server.


Lints for ETSI TS 119 312

ETSI publishes ETSI TS 119 312 providing guidance on the selection of cryptographic suites. As this is a normative document under the ETSI audit regime, we should have LINTs for it.

@RufusJWB It’s not clear to me the relevance or lintability of this document. I’m assuming you’re thinking in the context of OCSP and CA certificates, and not suggesting lints for CAdES/XAdES. For the OCSP/CA side of things, the specifications in Appendix A are only with respect to interoperability profiles, and not with respect to exclusions/prohibitions.
Perhaps you could be more precise what you think is missing? That would help evaluate whether it’s even possible to LINT.

I would like to have - for example - LINTs for table 10 of the technical specification. Such a lint could look like the following:
if (cert.algorithm == sha256-with-rsa) {
   if (cert.validUntil > 1.1.2025) {
      return "Error"
   }
   if (cert.validUntil > 1.1.2020) {
      if (cert.keypair.keySize < 1900 ) {
         return "Error"
      }
   }
}
return 'Ok'

But those aren’t normative? They’re just recommendations, and structured weirdly (in that they aren’t a factor of key lifetime, but if absolute date). I don’t know if I’d be able to be an effective reviewer, as I’ve not paid any attention to TS 119 312, as its narrow focus has meant zero practical applicability to browsers so far.

If someone is under ETSI audit regime, they are normative (even if only a 'should'):

if the subscriber or subject generates the subject's keys:
i) an obligation or recommendation to generate the subject keys using an algorithm as specified in ETSI
TS 119 312 [i.10] for the uses of the certified key as identified in the CP; and
ii) an obligation or recommendation to use key length and algorithm as specified in ETSI TS 119 312 [i.10]
for the uses of the certified key as identified in the CP during the validity time of the certificate.
[...]
GEN-6.5.1-06: CA key pair generation should be performed using an algorithm as specified in ETSI
TS 119 312 [i.10] for the CA's signing purposes.
GEN-6.5.1-07: The selected key length and algorithm for CA signing key should be one which is specified in
ETSI TS 119 312 [i.10] for the CA's signing purposes.
[...]
SDP-6.5.1-18 [CONDITIONAL]: If the CA generates the subject's keys, CA-generated subject keys should be
of a key length and for use with a public key algorithm as specified in ETSI TS 119 312 [i.10] for the purposes
stated in the CP during the validity time of the certificate.

https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.02.00_20/en_31941101v010200a.pdf
Regarding the "in that they aren’t a factor of key lifetime, but if absolute date": I think this is discussed in table 9.

I think we’re miscommunicating here. That cited text is not a MUST (“an obligation or recommendation”).
More explicitly: I don’t think the things you want linked can be linted in a reasonable way. I also wouldn’t feel comfortable reviewing those lints.

To @RufusJWB's point, I thought ZLint also contains lints that report on SHOULD requirements as well, throwing WARNING messages. Perhaps this is something different?

NOTICE, not WARNING.
However, the objection is on how suitable and lintable these are, given the requirements. Knowledge of whether the TSP generated the key or not is outside of ZLint, as is knowing the effective lifetime of the key (which depends on all certificates issued, not just the linted certificate). Some of these requirements are not implementable in Go via the current ZCrypto support (Brainpool), and some are actively harmful recommendations (RSA-PSS). These are largely recommendations, and so at best, are NOTICEs, and would take considerable time to review.
The extent of my own ability to maintain and support ETSI lints is limited to the extent they are relevant to the Web PKI, and thus lints for matters like QSeals or QSigs are things I am unable to personally support reviewing. The support for ETSI lints in ZLint was itself tenuous at best, in terms of finding maintainers who can support, and which are actively following developments, and the many lints from @mtgag have shown it’s a very high support burden (and highlighting many ambiguities or issues within the ETSI specifications).

I think you are confusing the SHOULD requirements (e.g. in GEN-6.5.1-06, GEN-6.5.1-07) with recommendations in other sections of the standard. I agree that it's not easy to maintain such lints but if community members want to have a shot at creating such lints, why shut down these efforts?

Well, currently I have an apprentice who needs to do some GO coding for learning the language. And since I always think an apprentice should do real work, I thought she might help here implementing these LINTs. I would propose the following: she will start working in a different fork and only when we have the feeling that she has achieved something worth presenting, we will make a Pull Request. Maybe @dzacharo would like to review before we create the pull request. So we avoid filling the inboxes of the maintainers.

I am not so familiar with GO to understand the code of these lints in depth like other maintainers or participants. Thanks for the offer though.

@dzacharo I appreciate your clarification, but that's not what is happening here.
If you examine @RufusJWB 's remarks, you'll notice that the GEN language cited from 319 411 is a SHOULD. However, I'm also highlighting that the language within TS 119 312 is also a SHOULD, and focused on defining interoperability profiles more than restricting the profile. A good example of this is Section 7.3, which is ambiguous with respect to curve/hash combinations for ECDSA: a strict reading would read that the use of SHA-384 with P-256 is prohibited by paragraph two, consistent with Mozilla policy (and now CABF, with respect to SC31), while a liberal interpretation would see Table 4 as permitting such mixing.
However, more concretely, the normative requirements expressed in Appendix A (e.g. Section A.7) are non-restrictive; they indicate mandatory-to-implement, but they do not impose limits. A naïve reading of the requirements might be to argue that Table 4 / Section 7.3 is restrictive, but even within that section, there are contradictory statements (e.g. paragraph one notes "recommended hash functions and signature algorithms", while paragraph three states "The signature suites listed in table 4 shall be used"). There are multiple problems with this (whether this is an inclusive or exclusive set, whether this is dispositive only to qualified certificates or also applicable to non-qualified certificates, consistency between these sections). These sort of self-contradictions are not unique to ETSI; e.g. https://github.com/cabforum/documents/issues/191 - but represent considerable time to sort through.
However, my concern on push back is to make sure that unnecessary work is not done which we ultimately reject. While open source is certainly about encouraging and welcoming participation, and we want to support that, supporting everything isn't always possible. Sometimes, the best answer is a clear "No". You can see some of the history regarding ZLint support for ETSI documents, and we want to make sure that lints are things that the @zmap/zlint-maintainers can support, and not just any community contribution. Similarly, because reviewing lints can take considerable time, we want to make sure that time is spent on the most impactful things.
I'm not trying to speak for all of the ZLint maintainers, certainly, but as one of the folks who explicitly stepped up to review ETSI lints, I wanted to make sure I wasn't overlooking anything when I tried to very clearly say: I don't think this is a lint I can support, and I don't think this is a good lint for ZLint.

I went through the discussion in the past and I understand your point, @sleevi . Please excuse my direct question, but I would like to understand whether are we now on point 2 of The Art of Closing or would you want us to open single issues for every possible lint and discuss them before we start coding? If we are on point 2 that's also fine for me ("no is temporary, yes is forever").

@RufusJWB I certainly don't want to discourage all contributions, particularly those related to ETSI, but to highlight both prioritization and the degree of clarity of the requirements ("good specs make for good lints", to make up a new aphorism). I think an issue-per-proposed-lint would be just as overwhelming, if not more so, than a bunch of a PRs. If there's strong interest in contributing a number of lints re: ETSI to ZLint, then I would probably encourage an approach similar to how the original ZLint lints came to be: by examining the relevant standards, identifying clear and measurable requirements within the context of the information ZLint presently provides (i.e. currently, only an input certificate), and where the gaps are within the ETSI lints.
You can see I started this in https://github.com/zmap/zlint/issues/410 with respect to @mtgag 's lints, and if you spot further gaps, I'm sure we can add and update. You can look at the ZLint BR coverage sheet to understand how ZLint did this for the Baseline Requirements.
If you, @mtgag , @dzacharo and others would like to take a similar approach, of identifying the normative requirements that can be technically quantified, I'd be happy to review such a spreadsheet, highlighting impactful lints that we can upstream and maintain going forward.


[BUGFIX]Fix/issue 2006

What is the purpose of the change
fix: https://github.com/apache/incubator-dubbo/issues/2006
Brief changelog
当有异常发生在 ExchangeCode 的 encodeResponse 方法的时候，会发送一个exception response给 consume，但是初始的 response 也会在exception response 被发送完成之后给发送出去，就会出现发送两次的情况，导致服务出现异常
When an exception occurs in the encodeResponse method of ExchangeCode, an exception response is sent to consume, but the initial response is also sent out after the exception response is sent out, which causes an exception to the service.
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn clean install -DskipTests & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #2401 into master will increase coverage by 0.2%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             master    #2401     +/-   ##
===========================================
+ Coverage     54.84%   55.04%   +0.2%
- Complexity     5238     5309     +71
===========================================
  Files           573      573
  Lines         25455    25562    +107
  Branches       4537     4563     +26
===========================================
+ Hits          13960    14070    +110
+ Misses         9402     9385     -17
- Partials       2093     2107     +14

Impacted Files
Coverage Δ
Complexity Δ

...e/dubbo/remoting/exchange/codec/ExchangeCodec.java
63.72% <100%> (+0.16%)
36 <0> (ø)
:arrow_down:

...ache/dubbo/remoting/p2p/support/AbstractGroup.java
45.45% <0%> (-11.37%)
7% <0%> (-1%)

...ubbo/rpc/protocol/dubbo/ChannelWrappedInvoker.java
41.66% <0%> (-8.34%)
3% <0%> (ø)

...org/apache/dubbo/rpc/filter/ActiveLimitFilter.java
83.33% <0%> (-5.56%)
6% <0%> (-1%)

...ache/dubbo/common/compiler/support/ClassUtils.java
50.18% <0%> (-2.79%)
84% <0%> (+23%)

...ava/org/apache/dubbo/config/ApplicationConfig.java
85.45% <0%> (-2.22%)
57% <0%> (+19%)

...pache/dubbo/registry/support/AbstractRegistry.java
67.41% <0%> (-1.88%)
62% <0%> (-1%)

...bo/remoting/transport/netty/NettyCodecAdapter.java
53.12% <0%> (-1.57%)
3% <0%> (ø)

.../java/org/apache/dubbo/config/ReferenceConfig.java
50.7% <0%> (-0.71%)
43% <0%> (ø)

...dubbo/remoting/exchange/support/DefaultFuture.java
44.96% <0%> (+0.67%)
25% <0%> (+1%)
:arrow_up:

... and 3 more

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 ff373a7...e1d5c55. Read the comment docs.

@fingthinking could u pls add some UT for this scenario?

@fingthinking I happened to visit your change today. Would you mind to explain why 'buffer.clear()' is necessary? I think buffer.writerIndex(savedWriteIndex) should work.

@beiwei30 抱歉哈，我的错，看的是历史的 dubbox 代码，没有这部分逻辑。

thanks 👍

@fingthinking 大佬，我没太看懂是怎么解决这个问题的，可以详细点吗？


[Bug]: When running the program from source code, it failed to convert some pdf documents and gave an error

Is there an existing issue for the same bug?

[X] I have checked the existing issues.

Branch name
main
Commit ID
c3b2a1
Other environment information
No response
Actual behavior
After uploading the file, click Convert
Expected behavior
No response
Steps to reproduce
After uploading the file, click Convert

Additional information

What was on the pdf?

Pull the latest source code and docker images.


Upgraded bnf to use nom 5.0.1

There should be no functional changes from this migration, however some of the parsers and error handlers needed to be updated to handle changes in nom API/behavior.
I made this change because I was looking adding a new parser for EBNF support and noticed that the nom version was 2 years out of date. If there was a reason nom 3.2 was being used, this change isn't required.

Coverage decreased (-0.2%) to 93.201% when pulling b813714c0d0bb756a396e35b9a14b5d5fd486486 on prbs23:nom_5_upgrade into<PHONE_NUMBER>9c7d4c50a6db72c74ab2d92b4718d3 on shnewto:master.

Oh this is awesome! I’ll merge now and plan on publishing a new version with these changes tomorrow. Thank you!!

@prbs23 a version 0.2.6 with your changes has been published https://crates.io/crates/bnf
Thanks again!


min and max values in output lexicons

First of all, thank you @williamleif for releasing this code.  It will be tremendously helpful in my research.
This is not really an issue as much as a question.
What's the mininum and maximum values of output lexicons?  It appears that it's somewhere around +/- 4 or 5 but I can't find it identified anywhere in the original paper.
If it's in the code base somewhere I haven't found it either.
Thanks in advance for the quick help.

Sorry for the slow response! This is a good question. In general, across the various methods implemented, there actually is no fixed min or max value. Some of the methods, such as the random_walk method and the main SentProp method described in the paper, do have min=0 and max=1 since they are defined based on random walk probabilities, but methods like densifier and pmi have no fixed range.
However, for the lexicons I released, I standardized the values to have 0 mean and unit variance within each corpus (i.e., I z-scored them). This again means that the values in the lexicons I released have no fixed min or max (since standardizing in this way doesn't produce a fixed range), but the scores for each word can be interpreted as "how many positive/negative standard deviations is this word away from the sentiment of the average word in a corpus." As you noticed, the min and max after standardizing is usually around [-4,4], so the most sentiment-bearing words are around 4 standard deviations away from the average word.
In general, the outputs from the various sentiment induction methods are somewhat "unit-less"; the ranges can be somewhat arbitrary, and it can be hard to interpret the absolute values of the scores. I recommend normalizing/standardizing within a particular dataset if you want to be able to interpret the value assigned to an individual word.

(Closing for now)


Windows testing

Description
Updated AppVeyor environment to fix failing x64 tests.
Fixes #55
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] This change requires a documentation update

How Has This Been Tested?
This has been tested on AppVeyor.
Checklist:

[x] Make sure you are merging into the develop (not master) branch
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] Add a note to Changelog.rst, summarising the changes
[x] Add yourself to AUTHORS.rst

Pull Request Test Coverage Report for Build 531

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.853%

Totals

Change from base Build 520:
0.0%

Covered Lines:
1138

Relevant Lines:
1163

💛  - Coveralls

Pull Request Test Coverage Report for Build 531

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.853%

Totals

Change from base Build 520:
0.0%

Covered Lines:
1138

Relevant Lines:
1163

💛  - Coveralls


feat(isNaN): polyfill isNaN

window.isNaN(‘lol’); //=> true
Number.isNaN(‘lol’); //=> false
isNaN converts it’s arguments into a Number before checking if it’s NaN. Number.isNaN fixes this but we can also polyfill it

@gdi2290 is there any reason to polyfill this particular ES6 method inside the core? Shouldn't we rather advice people to include a full / partial polyfill if they need it?

well I didn't keep this global on the angular object so it's for internal use since it's inside of the closure. Throughout the code base the team is checking if it is a number before running isNaN. Adding this would save a few lines and from this js gotcha
if (isNumber(ctrl.$modelValue) && isNaN(ctrl.$modelValue)) {
// would be
if (isNaN(ctrl.$modelValue) {
//
minVal = isNumber(val) && !isNaN(val) ? val : undefined;
// would be
minVal = !isNaN(val) ? val : undefined;

@gdi2290 so, if you believe that the changed isNaN version can be used to improve existing code, could you please include those changes in this PR?

I think would be better if I name it isNumberNaN and replace all isNaN to isNumberNaN I'll update the PR

and instead of defining a function that wraps both the Number.isNaN and pollyfill it should only provide a pollyfill in place of Number.isNaN. Something such as...
var isNumberNaN = Number.isNaN || function(n) {
   ...
};

good idea
var _isNaN = window.isNaN;
var isNumberNaN = Number.isNaN || function isNumberNaN(num) {
  return isNumber(num) ? _isNaN(num) : false;
};

Nice idea.
Number.isNaN can be more easily (and a bit faster) polyfilled like this
function isNumberNaN(value) {
  return value !== value;
}


Update README.md, fix typo(s)

I really enjoyed using this project, nice work! Caught a couple of typos in the README.md though 😛

Thanks for fixing 🙏


add rep_tests cases & fix meta's server_state::update_configuration()

improve rep_tests framework
add more cases in rep_tests
fix meta's server_state::update_configuration() to handle duplicate update request

Zuoyan, there are some conflictions above therefore I cannot do the merge work (probably due to another pull request merge). Would you please fix the conflict first? Thanks~

I am doing on it, wait a short time.

merge done, and fixed some problems, now you can merge the pull request

fixed according to your review


yii\bootstrap\Nav not work when yii2 Nav include bootstrap.js,my global Asset include bootstrap.min.js

my global asset file is below

my assetManager is like below

when i turn mode from dev to prod ,yii\bootstrap\Nav widge not work

twice include bootstrap.js will let some buttons,navs plugin not work,but how can i remove the bootstrap.js??

There is no yii\bootstrap\BootStrapPluginAsset class, there is yii\bootstrap\BootstrapPluginAsset ('strap' in lower case) instead. So your config simply defines extra bundle with 'bootstrap.js' in addition to standard one.

when i  modfied my asset file ,it works,Thanks klimov-paul,i  become your follower


Add YLTWB token

为确保 Token Profile 的顺利通过，务必逐一确保以下检查项并补充项目资料：
.json 及 .png 文件检查项

[ ] logo 尺寸：120*120 px
[ ] logo 背景：透明
[ ] 代币有至少一笔成功的转账记录
[ ] 此项对于 ERC-20 项目方：合约地址有大小写（做 checksum）
[ ] .json 和 .png 文件名一致（包括大小写）

项目资料：
官方公告：http://yltw.io/index.html#6
团队背景：
娱乐天王运动娱乐联盟团队分布在硅谷、新加坡、上海和重庆，核心成员均来自世界著名软件公司，有着超过十年互联网产品开发经验和超过8年的区块链开发经验，是国内早期研究区块链领域的技术团队之一，属于连续创业者。同时团队有着众多专业队的网球乒乓球羽毛球壁球桌球钢琴吉他架子鼓K歌等成员，已经连续组织了5年的运动娱乐社区活动，带动了一大批白领加入运动娱乐行列。
项目基本情况：
娱乐天王俱乐部是 YLTWLabs 旗下运动娱乐社区品牌，YLTWB Token在社区流动，可以用来支付活动费用，目前可以通过来组织以及参加活动获得，也就是挖矿。社区dapp也已经上线，方便大家沟通交流
更多关于 YLTWB 的信息：

官网: http://yltw.io/
Telegram: https://t.me/joinchat/Yu-1b0hFPcU3YzM1
Twitter: https://twitter.com/YLTWB
Discord: https://discord.gg/KkK59C6X

转账所需 gas limit：60000
收录的交易所：uniswap

Please check the following to ensure a successful verification of Token Profile
.json and .png document checklists

[ ] logo dimensions: 120*120 px
[ ] logo background: Transparent
[ ] At least one transaction on the token contract
[ ] For ERC-20 project teams: Upper and lower capitalized alphabets in token address (For checksum purposes)
[ ] Same document name for both .json and .png (Including capitalization)

Project background:
Official announcement: http://yltw.io/index.html#6
Project team background:
The team of entertainment Tianwang sports entertainment alliance is distributed in Silicon Valley, Singapore, Shanghai and Chongqing. Its core members are all from world-famous software companies. It has more than 10 years of experience in Internet product development and more than 8 years of experience in blockchain development. It is one of the early technical teams in the field of blockchain research in China and belongs to continuous entrepreneurs. At the same time, the team has a large number of professional team members, such as tennis, table tennis, badminton, squash, billiards, piano, guitar, drums, karaoke and so on. It has continuously organized sports and entertainment community activities for five years, which has led a large number of white-collar workers to join the ranks of sports and entertainment.
Project basic information:
Entertainment Tianwang club is a sports and entertainment community brand of yltwlabs. Yltwb token flows in the community and can be used to pay for activities. At present, it can be obtained by organizing and participating in activities, that is, mining. DAPP community has also been online to facilitate communication
More about YLTWB：

Web site: http://yltw.io/
Telegram: https://t.me/joinchat/Yu-1b0hFPcU3YzM1
Twitter: https://twitter.com/YLTWB
Discord: https://discord.gg/KkK59C6X

Gas Limit (For ERC-20 project teams) for transaction: 60000
Tradeable exchanges: uniswap

项目含较多不实信息，无法合并此PR。


Paths not working in Vercel Serverless

I deployed a started app in order to test it with vercel serverless, but I get a not found module error so I assume alias-hq is not working with Vercel.
Do you know about any issues when deploying to Vercel?
Development version vercel dev works fine in localhost.
Also in an isolated environment (not vercel dev, just node in localhost)
Vercel deploy screenshots
Error

App main file

tsconfig.json

All looks fine for me.

Hmm. Not sure to be honest!

can you try it with a simple test case?
is there anything you can console log ?

Alias HQ is relying on module alias, so we might need to poke with that


fix: add more image formats

Fixes #2298

I'm not sure we really want deno.land/x to be an image browser. As discussed recently, displaying indexes of directors (file browsing) is deprecated behaviour. Rendering code that a stack trace might include so it can be linked to is one thing, but arbitrary media browsing doesn't seem like a good idea. What need in discovering and understanding the module does it fill?
@lucacasonato @ry thoughts?

displaying indexes of directors (file browsing) is deprecated behaviour

Even though modules in deno.land/x come from GitHub, I don't think the two are fully equivalent in file browsing. For example, consider that modules on deno.land/x are immutable, but Git tags can be retagged, the repository may vanish, etc.
But I don't really have a say in this, it is probably fine not to display media on deno.land/x, I just think this is wrong:

Rendering code that a stack trace might include so it can be linked to is one thing

Regarding this, I just found it is currently broken: #2300


oniguruma - free memory (avoid potential memory leaks)

Because enry can be compiled with oniguruma engine (which is natively implemented in C) it also needs to free memory if *Regexp object is not needed.
Go binding uses runtime.SetFinalizer(re, (*Regexp).Free) in NewRegexp(pattern string, option int) (re *Regexp, err error)  (called by MustCompile) but runtime.SetFinalizer is just a wish sent to GC.
I suggest (and what we did in mysql) to extend the interface by adding a disposer or any mechanism/function which can be called when pre-compiled regex is not needed. The disposer will either do nothing (go's std. lib.) or call func (re *Regexp) Free() (oniguruma).

If the finalizer mechanism isn't sufficient to avoid memory pressure, then the API is incompatible (despite superficial similarity) and shouldn't be treated as a drop-in replacement IMO.

you mean incompatible with go's std. library?
This is go binding for c implementation of oniguruma. For every c implementation you have to manually free memory and finalizer in bindings is just a wish. Native go implementation doesn't have this problem.

This is go binding for c implementation of oniguruma. For every c implementation you have to manually free memory and finalizer in bindings is just a wish. Native go implementation doesn't have this problem.

Yes, agreed. My point is that one cannot replace a use of (say) the Go regexp package with Oniguruma C bindings without re-working the control flow of the library, if the integration with the GC is not sufficient to manage memory. In particular, if the library demands manual release of allocated memory, it's not sufficient to update the function calls and types, we also need to change the way we track and plumb regexp matching types through the code that uses it.
Which is mostly to say that fixing this may require more changes than just plugging in free calls. The point of using Oniguruma in the first place was supposed to be performance, but that relies in large part on the ability to cache reused expressions.

So what do you suggest?

get rid of oniguruma and just stick to go's std. library
keep oniguruma and just rely on finalizers
add free/close/dispose function (next to MustCompile) to enry's API

So what do you suggest?

get rid of oniguruma and just stick to go's std. library
keep oniguruma and just rely on finalizers
add free/close/dispose function (next to MustCompile) to enry's API

Any of those seems viable. My inclination would be to rely on finalizers and not worry about it, but the main issue raises the concern that this isn't sufficient. If we aren't having memory leaks or other runtime issues because of this, I think it should be sufficient to trust the finalizer; otherwise we should do something different.
Adding a free function isn't enough: Everywhere a wrapped object is allocated we would have to match it with a release, which means adding an explicit ownership path through the API. The obvious way to do that is to release eagerly whenever a value goes out of scope. I predict that would result in a performance degradation, since we'd have to recompile the same expressions repeatedly.
I'm not sure why we switched to Oniguruma in the first place, but I suspect it's either a matter of syntax (since regexp supports only RE2, which doesn't handle common PCRE-style extensions) or of performance. If it's for syntax we might be stuck; if it's for performance I think we can do better without needing a C binding.

The author of the original oniguruma port here. The goal was to get a performance boost, which appeared to be great - 2x to 4x as far as I remember. I picked it because somebody mentioned it would be fun to try, and it was fun for me to write some code. Nobody knew we would have annoying memory problems beforehand.
oniguruma is a much faster regexp engine, and knowing the nature of the benchmarks/real usage, I doubt that any regexp recompilation will mitigate the benefit. I bet that it will be negligible.

So far, we didn't notice memory leaks (that's why I emphasized potential). Mysql has a slightly different use case. For cached pre-compiled matchers we rely on finalizers, otherwise we call dispose. So, I'm ok to keep what we have in enry.
Regarding switch to oniguruma, as far as I know the main reason was performance (oniguruma is at least 4x faster). Also for mysql oniguruma is a default regex engine because of go's regex is kind of special, but in enry it doesn't have to be a case.

I would advise not to add complexity to this common library until this is proven necessary for all downstream use cases. Personally, so far I have not seen:

if the integration with the GC is not sufficient to manage memory

this to be the case yet and esp. because, as Michale noted above, that would most probably require API surface changes.
What makes me particularly reluctant is

So far, we didn't notice memory leaks (that's why I emphasized potential)

On the performance

The goal was to get a performance boost, which appeared to be great - 2x to 4x as far as I remember

Although that is true for general regexp matching, I would really love to have some data points first to support that claim specifically on enry performance e.g as a part of benchmark suite (#210)

OK, so I'm closing this PR.

performance must be considered seriously here.
It's really not a joke.


Synthetics are not handled correctly

By using .ord, only the base char gets encoded. Instead, the code needs to loop over .ords.

fixed as of v0.2.0


[TEST] [No QA] Testing E.cash issue lifecycle - Delete test.md

Details

This is a PR to test E.cash issue lifecycle merged https://github.com/Expensify/Web-Expensify/pull/31129 @mountiny
Fixed Issues

$ https://github.com/Expensify/Expensify.cash/issues/3995
$ https://github.com/Expensify/Expensify.cash/issues/3994
Tests

QA Steps

Tested On

[ ] Web
[ ] Mobile Web
[ ] Desktop
[ ] iOS
[ ] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

I have read the CLA Document and I hereby sign the CLA

@Julesssss This is for testing a Github Webhook, no need to bother you.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging         in version: 1.0.77-6🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production         in version: 1.0.79-4🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Feature/spa-experience

This introduces the wrapper for the single-page app experience for MVP.
Link to design wrapper
Pictorial representation

Some review notes:

All strings in the footer component need to be sourced from the translation framework
[follow-up] We should look to share this wrapper component and relevant shared elements with GatewayUI.

Some review notes:

All strings in the footer component need to be sourced from the translation framework
[follow-up] We should look to share this wrapper component and relevant shared elements with GatewayUI.

Corrections have been made for the strings using the translation framework


resetConsumer repeatedly creates consumers

Observed behavior
Using nats.ws library, I am able to see that after a creation of an ordered consumer, if it receives an error, it repetitively creates more consumers via a backoff mechanism

Expected behavior
Using nats.ws library, I am able to see that after a creation of an ordered consumer, if it receives an error, it creates only 1 consumer at a time that can preferrably be managed
Server and client version
server version - 2.10.15-RC.7
client version - 1.19.1 and 1.25.0
Host environment
No response
Steps to reproduce
No response

I was misreading, turns out we were not creating the consumer :)


Generated docs and docz.site seems to be broken in IE11

Bug Report
If I navigate to http://docz.site/ using IE11, the screen is just blank. The same applies to any generated docs, whether in dev mode or on the built docs.
To Reproduce

Go to http://docz.site/ with IE11

Expected: the docz site
Actual: blank screen and an error in the console complaining about an unexpected closing body tag. A little later, a syntax error is encountered in a JavaScript file.
I have reproduced this error with the example provided in examples/basic.

@pedronauck: I can help fix this bug if you can point me in the direction of where it is probably introduced. This whole monorepo/typescript setup is somewhat confusing.

I did some digging and believe the bug is somewhere in the transpilation setup here: https://github.com/pedronauck/docz/blob/master/packages/docz-core/src/bundlers/webpack/loaders.ts

any luck on this one? 😄we need our guide site to works in IE11 since a good number of our end users use that browser!

We have the same issue. Would be more than happy to help if there are some pointers as @mzedeler mentioned.

Hi @mzedeler, can you close properly the "root" div in the file below, delete your .docz directory and try again?
https://github.com/pedronauck/docz/blob/master/packages/docz-core/templates/index.tpl.html

Could you add @babel/plugin-transform-template-literals to the babel config? I see at least two webpack bundles that contain templates. I tried to build the project myself but ran into missing dependencies and one typescript error that I didn't understand.

Created an issue on webpack-serve-overlay to make sure the vendor bundle is compatible with ES5: https://github.com/G-Rath/webpack-serve-overlay/issues/10
I don't think this project should be transpiling vendor dependencies, but please correct me if I'm wrong and I can start working on a fix for that instead.

Any updates on this? This would probably keep us from using docz as we need to do QA for IE and would like to do it via our component lib documentation

After looking into this, I believe it would be better to move away from webpack-serve, since it's deprecated, and enable its built-in overlay instead of using webpack-serve-overlay.

See https://github.com/pedronauck/docz/issues/456

Is this still being looked into?

Looks like it has been a while since the last post on this.
Has anyone been successful in getting this to transpile to ES5, so it will work on IE11?
If so, could you please post some guidance on how you solved it here?
Thanks
ewb

Is this still issues still being pursed? Any pointers on how to get this to run for IE11?

Yeap, we are also facing this issue. Any pointers?

Sorry guys, but I think that isn't our focus to support IE11 😕

@pedronauck Fair enough, thanks for the heads up. Would you accept a PR that adds a supported browsers section to the readme in that case? Which browsers are currently considered supported? Thanks!

@smathson i think listing supported browsers is a great idea! we ended up using storybook because the components we built have to work in IE11 and documentation site is a cheap and easy way to test the components. otherwise we have to spin up a separate react site just for testing IE11

Yeah, will be awesome @smathson 🙏

@pedronauck Happy to put together a PR if you tell me which browsers you want to support for this project. Evergreen only (Firefox/Chrome/Edge)? What about mobile browsers?

@pedronauck While it's totally understandable to not officially support IE11, would you accept PRs that would make IE11 work with the understanding that it may break in any future releases, as long as those PRs don't degrade performance for supported browsers?

Yes! unfortunately IE11 is still around 2.7% of worldwide traffic and a lot of big companies will still support this browser. It would be awesome if we could have Docz run in IE11 so we can test things on this browser as well.
Browser Stats
https://www.w3counter.com/globalstats.php

+1 to this. from IE11 console it seems like its an es5 transpiling issue. using const and arrows => functions

Has anyone found a workaround for this? I've tried adding a onCreateBabelConfig to gatsby-config.json; I've also tried gatsby-plugin-compile-es6-packages. I couldn't get either to work.
If there are no workarounds, I may look into trying to contribute a PR if the maintainers would be open to it.

Hey all,
A PR would be very welcome !
If you'd like to give it a shot and have questions or need help please feel free to join our slack channel 👍

As reporter, I'm just happy to see someone wanting to contribute 🙂

I figured out a workaround for this so my site runs in IE. It's not completely ideal, but good enough for my use case.
Step 1: I installed gatsby-plugin-compile-es6-packages and configured it with this gatsby-config.js at the root of my project:
// gatsby-config.js
module.exports = {
  plugins: [
    resolve: `gatsby-plugin-compile-es6-packages`,
    options: {
      modules: [
        `copy-text-to-clipboard`,
        `regexpu-core`,
        `unicode-match-property-ecmascript`,
        `unicode-match-property-value-ecmascript`,
        `ulid`
      ]
    }
  ]
}

You'll need to add any modules that are using unsupported syntax to the modules array (this may be dependent on your project). It took some whack-a-mole to figure out exactly which modules need transformed, and it'll take some maintenance if new deps are added.
Step 2: I added a polyfill for HTMLElement.scrollTo. I used Gatsby's browser API's onClientEntry for this. I added a gatsby-browser.js file to the root of my project with this contents:
// gatsby-browser.js
// Called when the Gatsby browser runtime first starts.
exports.onClientEntry = () => {
  if (!HTMLElement.prototype.scrollTo) {
    HTMLElement.prototype.scrollTo = function (left, top) {
      this.scrollTop = top
      this.scrollLeft = left
    }
  }
}

I was trying to cover all my bases with just the gatsby-config.js, but the scrollTo was one where I was struggling to cover all my bases, I thought an explicit polyfill would be fine.
It's a bit hacky, and there are probably ways to improve this approach, but for now my docs site at least runs in IE11. The layout isn't quite right because of CSS grid support. If I really wanted to, I think I'd be able to add some custom theme files to fix the layout.

@leahjlou I'm totally new to Docz but IE is really important for my site. Do you know if this fix would work if it's a completely Docz site (i.e. not added to an existing Gatsby site)? I want this specific site only for docs.

Hey @HiltonGiesenow
I'm not sure about the fix in particular but anything that works with docz as a gatsby theme in an existing site should work the same with docz as a stand-alone site.

Ok, it's probably just my limited knowledge of the tools to date. If I start with the standalone site, I don't seem able to edit the gatsby-config.js file - it get's overwritten


Develop

Codecov Report

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

@@           Coverage Diff            @@
##           master     #7      +/-   ##
========================================
+ Coverage   98.77%   100%   +1.22%
========================================
  Files           3      3
  Lines         163    161       -2
  Branches       26     24       -2
========================================
  Hits          161    161
+ Partials        2      0       -2

Impacted Files
Coverage Δ

forecastonishing/selection/paralleling.py
100% <ø> (+7.14%)
: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 36927c6...388a60d. Read the comment docs.


Nebra: Miner Still Loading Sync/Height error

Hi there,
I’m having trouble getting synced up to the network. I’ve run diagnostics on the miner and found that sync percentage and height percentage is listed as “Miner is Still Loading” Miner connected to blockchain is also listed as no. I’ve tried restarting the miner by plugging it out for a little while but this has not worked. Can you please help me out?
Thanks,
Spartan

I'm going crazy, mine is the same, fixes then hour later miner is loading.
Dashboard says synced and connected to block

@Spartan268 @facilitator999  Please share the below-mentioned details to<EMAIL_ADDRESS>if already shared please share the ticket number here, will check.
Model of unit (Indoor or Outdoor)
Mac address of the unit (Shown as ETH on sticker)
Frequency of the unit (Shown as Freq on sticker)
What country are you using the miner in?
How are you connecting it to internet? (Ethernet, Wi-Fi, Cellular)
How are you powering the unit? (Included adaptor, POE, Third party adaptor)

262771

#262712

@Spartan268 @facilitator999 I need more information about your device, please check the mail and please share the information mentioned.

@Spartan268 @facilitator999 I need more information about your device, please check the mail and please share the information mentioned.

I have messaged you over everything in our earlier chat on Discord.

I'm banned from your discord for no good reason!

Hi there,
I really need help with this. I’ve provided
all the details. I cannot connect to the Helium App diagnostics despite all attempts so I’ve been pulling diagnostics from the miners IP. I’ve restarted, switched to Ethernet, disabled Bluetooth on my phone reconnected. I’ve had the miner for almost 7 days and it still hasn’t synced. The miner has been sitting currently for three days connected to Ethernet where I haven’t touched it in hopes it would sync. I was hopeful the issue would be solved as I was informed by Kevin in technical support that it should be up and running in a matter of hours but unfortunately not. Currently it’s sitting in a status of needs attention despite everything being connected and setup. I’ve noticed some days it connects to the network once and then won’t connect again at all that day.
I really need this to be looked at and fixed as soon as possible.
ID #262614 Is my ticket number.


Emit a warning when 'load_from_checkpoint' called from instance.

What does this PR do?

Fixes https://github.com/Lightning-AI/lightning/issues/18169

Before submitting

Was this discussed/agreed via a GitHub issue? (not for typos and docs)
[x ] Did you read the contributor guideline, Pull Request section?
[x ] Did you make sure your PR does only one thing, instead of bundling different changes together?
Did you make sure to update the documentation with your changes? (if necessary)

Updated docstring

Did you write any new necessary tests? (not for typos and docs)

I'm not away of a way to test for the warning we emit.

[x ] Did you verify new and existing tests pass locally with your changes?

Tests were broken on master on my machine prior to my changes.

Did you list all the breaking changes introduced by this pull request?
Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

Reviewer checklist

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

restricted_classmethod might be a good fit for lightning_utilities, so we could land a PR there first.

I would land this here first and upstream it later, otherwise this will be blocked by releasing a new lightning-utilities version and increasing the minimum dependency so that we can use it

Changed from warning to exception per discussion. Wrote a new test for LightningModule.load_from_checkpoint. However, I found no existing tests for LightningDataModule.load_from_checkpoint so I didn't add a test for that (as I don't know how the infrastructure would work there).

@awaelchli I addressed your review.

Don't merge yet- I just learned a better way to type _restricted_classmethod to make static type checkers happy.
            )
E           TypeError: The classmethod `BoringModel.load_from_checkpoint` cannot be called on an instance. Please call it on the class type and make sure the return value is used.

The newly added error in __get__ gets triggered when tracing a module with torch.jit.trace() which happens in some tests (even if no .load_from_checkpoint() call occurs. There is probably a way to detect the tracing to fix this issue.

@awaelchli I see. I'll investigate later how to make it play nice with torch.jit.trace.

Uh, that might be a problem. Detecting it doesnt always work. In fact, we have this hack just because of it: https://github.com/Lightning-AI/lightning/blob/master/src/lightning/pytorch/core/module.py#L1590-L1597

The mypy CI failing is because currently no static type checker understands custom classmethods like the hack we implemented. Might just have to do # type: ignore [arg-type] there


🐛  Revise generic transport controller update logic

Summary
This PR changes the way that the transport controller decides what changes it has to make in wrapped objects. The old code was not logical.
Related issue(s)
Fixes #2586
Fixes #2511

/cc @vMaroon
/cc @waltforme
@cwiklik

The force-push to c5f5e2ed0 is a squash and a couple of renamings in response to the review comment above.

.. and the force-push to 25fb9204e fixes the comment on the type Gloss.

And the force-push to 4644e56f5 fixes the comment on computeDestToWrappedObjects

.. and the force-push to 2eb730f58 does a couple of local variable renamings to bring them up to date.

PR #2598 demonstrates good behavior with the limit on number of workload objects in a bundle set to 2.
/approve

@MikeSpreitzer I think it may make sense to document (on a fine-enough granularity) the logic of the transport component as it is getting complexly distributed.


How to change the welcome message from bot.

I want to customize the bot welcome message and am using a Javascript function to integrate bot with our web application. Below is the sample code.
window.WebChat.renderWebChat(
{
directLine: window.WebChat.createDirectLine({
token: secretKey
}),
store: store,
locale: 'en-US',
styleOptions
},
document.getElementById('Chat')
I want to customize the below message

This is not implementation on Web Chat, client-side.
So, you should change backend code of bot application that Web Chat connects using the secretKey.
You need to change the text message that is the argument of the sendActivity method.

https://github.com/microsoft/BotFramework-WebChat/blob/master/docs/WELCOME_MESSAGE.md#bot-framework-sdk-v4-nodejs
https://github.com/microsoft/BotFramework-WebChat/blob/master/docs/WELCOME_MESSAGE.md#bot-framework-sdk-v4-nodejs-1

'How to' questions such as this one are better suited for Stack Overflow. Please feel free to post other questions you have about developing your own features over there so the community at large may help out. If you need help with a BotFramework implementation, you can post a question to the BotFramework tag. Thank you!


Expose import and export functions in Python API

This pull request adds functionality to export and import indices from the python API and solves https://github.com/yahoojapan/NGT/issues/76
I have updated the English documentation as well.
Request you to update Japanese documentation and merge this in and release new Python wheels so that I don't have to maintain this branch.
Thanks,
Orkhan

Thanks!


[REG2.071-devel] Issue 15815 - deprecation for aliased template instance not shown

Run type.resolve always even when s is an AggregateDeclaration - (s.getType() && type.equals(s.getType())) == true.

Sorry I was mistaken in the issue summary. Updated.

Auto-merge toggled on


Name of Software
h5py
Contact Details
No response
Request Description
h5py is used in a many of Python workflows for data processing of HDF5 (ECP) files.
HDF5 is funded by ECP.
h5py is a community project with HDF5 members contributing to.
Repo: https://github.com/h5py/h5py/
Spack package: py-h5py
Is there a Spack Package
Yes
Is your project funded by ECP
Yes
E4S Community Policy

[X] I agree to follow the E4S Community Policy

Hi Ax3l, thank you for this. We will add py-h5py to our next release of E4S. In the meantime, I created this PR to begin building py-h5py as part of the E4S stack in Spack CI:

https://github.com/spack/spack/pull/34914

Thanks a lot! :sparkling_heart:

Are there any particular variants besides the defaults you would like turned on explicitly?

Closing this as resolved following merge of https://github.com/spack/spack/pull/34914. If in the future you decide we should have certain non-default variants set, please don't hesitate to let us know.

Thanks @eugeneswalker!
Yes, with and without MPI might be ideal. Many post-processing scripts are serial or embarrassingly parallel.


Oct 2018 upstream wallet patches

Various upstream changes over the past six months.

Next fix changes Java versions. May want to pause for a bit.


Add run_exports

@sodre, same logic, this is a new library, but it is 1.0 and intel's comments seem backward compatible for now between patch versions.
Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

👍


mavros: 0.25.1-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository mavros to 0.25.1-0:

upstream repository: https://github.com/mavlink/mavros.git
release repository: https://github.com/mavlink/mavros-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.6.4
previous version for package: 0.24.0-0

libmavconn
* lib #1026 <https://github.com/mavlink/mavros/issues/1026>: fix logInform compat
* lib #1026 <https://github.com/mavlink/mavros/issues/1026>: add compat header for older console-bridge
* Contributors: Vladimir Ermakov

mavros

No changes

mavros_extras

No changes

mavros_msgs

No changes

test_mavros

No changes

That should fix mavlink/mavros#1026.


Which API are You using  Geo-coding or Geolocation

Which API are You using  Geo-coding or Geolocation

He is using the browser geolocation api

He is using the browser geolocation api

Thanks 😁


Enums

enum MyEnum {
  Foo
  Bar
  Baz
}

MyEnum.Foo # => 0
MyEnum.Bar # => 1
MyEnum.Baz # => 2

Enums can also have static methods
enum MyEnum {
  Foo
  Bar
  Baz

  func is_foo(value) {
    value == @Foo
  }
}

The values of an enum are Numeric values starting at 0, incrementing with each value added to the enum. The enum is represented as an object.
The above code is equivalent to the following object literal:
let MyEnum = {
  const Foo = 0
  const Bar = 1
  const Baz = 2

  func is_foo(value) {
    value == @Foo
  }
}

@KCreate Good idea, that gives us more opportunities to seperate the functions from other objects

@KCreate But are the functions actually necessary? Any examples for a good use?

Writing code with enums usually requires comparing them every so often.
Sometimes that code becomes long and complicated. Allowing functions directly inside enums
makes it possible to encapsulate logic and abstract implementation details away.
enum Token {
  Let
  Const
  If
  Integer

  func is_keyword() {
    return self == Token.Let || self == Token.Const
  }
}


maintainers and status of project

Hi,
Thank you very much for the work and time invested into this.
It seems the project has not been updated for a long time. From my use case, some fixes provided by kind people that are in PR have yet to be merged.
https://github.com/karma-runner/karma-mocha/pull/208
There or a lot of others PR in waiting also. This cause us at least to fork and use unofficial fork of the project which is not desired.
If any of the maintainer of the project is reading this, It would be very much appreciate some maintenance release or a helping and calling for new maintainers that will contribute in PR reviews and merging.

Please try
https://github.com/orgs/karma-runner/teams/mocha-contributors/members Request
To Join
On Sun, Jul 14, 2019 at 11:33 PM Eyal Lapid<EMAIL_ADDRESS>wrote:

Hi,
Thank you very much for the work and time invested into this.
It seems the project has not been updated for a long time. From my use
case, some fixes provided by kind people that are in PR have yet to be
merged.
#208 https://github.com/karma-runner/karma-mocha/pull/208
There or a lot of others PR in waiting also. This cause us at least to
fork and use unofficial fork of the project which is not desired.
If any of the maintainer of the project is reading this, It would be very
much appreciate some maintenance release or a helping and calling for new
maintainers that will contribute in PR reviews and merging.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/karma-runner/karma-mocha/issues/209?email_source=notifications&email_token=AABSGAXMDQMNENF7XTJXVQLP7QK43A5CNFSM4IDTS6S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G7ERAXA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABSGAQBXSIL6LRYGN7TVKTP7QK43ANCNFSM4IDTS6SQ
.

@johnjbarton Thank you for the response. That link brings me to 404 page. I am guessing no authorziation on my part.

@dignifiedquire @johnjbarton Any updates on the maintenance status of this repo?
If this project does no longer have active maintenance, can someone with the necessary rights at least mark this repo read-only so folks checking the readme are aware of this?

#218 should allow release to be driven by successful post-commit tests.


standardize path and behavior of ublue-os justfile

@bsherman @EinoHR After some discussion on Discord, a good pattern emerged to avoid forks overwriting each other's justfiles randomly: Every image instead has its own separate justfile, which the user can include/merge a-la-carte.
Currently we have these:
touch ~/.justfile
cat /usr/share/ublue-os/just/main.just >> ~/.justfile
cat /usr/share/ublue-os/just/custom.just >> ~/.justfile

The main is meant to be the main config, which currently comes from the config repo. Its purpose is to contain the "core" commands.
The custom is from the startingpoint template repo, which is where the repo maker adds their own. It includes absolutely nothing from main and therefore never risks going out of sync with upstream ublue-os/config.
We'll need 4 minor changes in how the main justfile is built:

Target location: /usr/share/ublue-os/just/main.justfile
Script update: ublue-os-just.sh needs to use the new justfile path. The purpose of that script is currently to auto-install the justfile on login if the user (even root) doesn't have a ~/.justfile, and it does nothing if the user has the file. So its behavior is already fine. It only needs a tweak to the path. Well, it also uses illegal non-POSIX shell syntax (only works in bash and zsh), so I'll propose a fixed version below.
The script currently places itself in /etc/profile.d on the image which is incorrect. It needs to write itself to /usr/etc/profile.d, and from there "systemd" will take care of syncing it into the user's real /etc folder.
We may want to make it merge every OS-level justfile automatically, not just the main one. But that's tricky with a profile.d script since we can't know which shell we're running under and therefore can't use bashisms for example... so leaving that off for now.

Alright here's the fixed ublue-os-just.sh:
# Add uBlue's justfiles to user if they don't already have a justfile.
if [ ! -f "${HOME}/.justfile" ] && [ -f /usr/share/ublue-os/just/main.just ]; then
  cp /usr/share/ublue-os/just/main.justfile "${HOME}/.justfile"
fi

In time I will probably contribute to the other repos too, but at the moment I am still busy and uncomfortable with the structure of main, config and nvidia. I'm starting to study them though! :)
Originally posted by @Arcitec in https://github.com/ublue-os/base/discussions/149#discussioncomment-5889873

I just noticed that Just officilly uses the <something>.just suffix:
https://just.systems/man/en/chapter_52.html
So we should follow that, like this:
/usr/share/ublue-os/just/main.just
/usr/share/ublue-os/just/custom.just

The feature they have implemented in Just is awesome, by the way. It allows people to import as many modular just files as they want. The only issue is that it is still marked as "unstable" and only available if we run just via an extra flag. But that will change sometime soon. :)
I am in bed, but will take care of that rename in the startingpoint repo in 10 hours or so.

But that will change sometime soon.

The PR for passing unstable as an env var has been open for many many weeks now and I haven't seen any new commits in the just repo for the time I've been tracking it. I'm wondering if it would hurt to alias just='just --unstable', that was turned down earlier.

@EinoHR Yeah I heard about that feature being stalled. But I mean that even though they hide it behind a --unstable testing flag now, they're inevitably going to move it to "on by default" soon.
It's a really nice system btw, being able to include multiple cleanly separated "modules" of just commands.
As for aliasing... it's tricky, since people use many different shells which means many different locations to store such an alias. I think just recommending that people manually create that alias is enough. But the simplest for users atm is just merging things (cat >> ~/.justfile) as we currently recommend.

@bsherman For reference, I updated the original comment with the new, official upstream .just suffix:
https://github.com/orgs/ublue-os/discussions/149#discussioncomment-5889873

As for aliasing... it's tricky, since people use many different shells which means many different locations to store such an alias. I think just recommending that people manually create that alias is enough. But the simplest for users atm is just merging things (cat >> ~/.justfile) as we currently recommend.

I agree with merging until we get the official include feature from just.

@bsherman For reference, I updated the original comment with the new, official upstream .just suffix:
https://github.com/orgs/ublue-os/discussions/149#discussioncomment-5889873

Nice! since I used the "Reference in new issue" feature on the discussion comment, the text of this issue auto-updated!

I think i see an addition...
This is described as ublue-os-just.sh for main repo`:
# Add uBlue's justfiles to user if they don't already have a justfile.
if [ ! -f "${HOME}/.justfile" ] && [ -f /usr/share/ublue-os/just/main.just ]; then
  cp /usr/share/ublue-os/just/main.justfile "${HOME}/.justfile"
fi

I think we'd want to override this file in each downstream so they include their appropriate files
eg, in nvidia
if [ ! -f "${HOME}/.justfile" ] && [ -f /usr/share/ublue-os/just/main.just ]; then
  cp /usr/share/ublue-os/just/main.justfile "${HOME}/.justfile"
  cat /usr/share/ublue-os/just/cat.justfile >> "${HOME}/.justfile"
fi

and startingpoint  would have something similar. this is the stop gap until just include is ready?
or... are we still doing an in Containfile appending of nvidia's extra justfile  snippet to main.justfile until then?

does this mean I can implement this now?

@bsherman That would be awesome. :) Yes, startingpoint has these same justfile changes in https://github.com/ublue-os/startingpoint/pull/74/commits
So config/main is the only area behind.

I think i see an addition...

Yeah I mentioned that in the original comment:

We may want to make it merge every OS-level justfile automatically, not just the main one. But that's tricky with a profile.d script since we can't know which shell we're running under and therefore can't use bashisms for example... so leaving that off for now.

My thought is that we should probably just bother merging main, because in the end, users are gonna be using just's official include /full/path/main.just; include /full/path/nvidia.just etc modular inclusion syntax.
So anything we make now would be insanely short-lived and not worth the hassle?

or... are we still doing an in Containfile appending of nvidia's extra justfile snippet to main.justfile until then?

Hmm that's a rough question. Yeah let's make the nvidia image override that shell script for now, to do what you mentioned, where the nvidia image copies main and merges in nvidia. It's just a stopgap until the full just has include directive enabled by default so we can remove all these hacks.

or... are we still doing an in Containfile appending of nvidia's extra justfile snippet to main.justfile until then?

Hmm that's a rough question. Yeah let's make the nvidia image override that shell script for now, to do what you mentioned, where the nvidia image copies main and merges in nvidia. It's just a stopgap until the full just has include directive enabled by default so we can remove all these hacks.

Yeah, i'm good with this... it's either override the main.justfile or the profile script... and i think the latter is less ugly / clearer about intent for a user trying to read the scripts.
And agree, its just the stop gap.

@bsherman Exactly. Overriding the profile is clearer for intent and also future-proofed for when just has inclusion by default! :)

Engage hacker mode.

Good luck, friend! :clinking_glasses:

@Arcitec one correction to your specification...

The script currently places itself in /etc/profile.d on the image which is incorrect. It needs to write itself to /usr/etc/profile.d, and from there "systemd" will take care of syncing it into the user's real /etc folder.

The rpm DOES use this path, but rpm-ostree puts that file in /usr/etc/ "magically" (i haven't read the code, but it does it somehow)...
If files in /usr/etc are not present in /etc they seem to get copied to /etc and are kept up to date as long as the /etc copy is not changed on the local system.
This is what we see with ostree admin config-diff.
Anyway, just pointing out I won't be implementing a change for this point and why.

@bsherman I was referring to this:
bash-5.2# ls /usr/etc/profile.d/*ublue*
ls: cannot access '/usr/etc/profile.d/*ublue*': No such file or directory
bash-5.2# ls /etc/profile.d/*ublue*
/etc/profile.d/ublue-os-just.sh

But it seems like those rules are being layered via rpm-ostree, which automatically tracks the /etc/ folder variant instead, so yeah this seems fine.

bash-5.2# ls /usr/etc/profile.d/*ublue*
ls: cannot access '/usr/etc/profile.d/*ublue*': No such file or directory
bash-5.2# ls /etc/profile.d/*ublue*
/etc/profile.d/ublue-os-just.sh

But it seems like those files are being layered via rpm-ostree, which automatically tracks the /etc/ folder variant instead of putting a template in /usr/etc/, so yeah this seems fine. :)

Weird, because it seems different for me.
$ rpm -ql ublue-os-just
/etc/profile.d/ublue-os-just.sh
/usr/share/ublue-os/ublue-os-just
/usr/share/ublue-os/ublue-os-just/justfile
/usr/share/ublue-os/ublue-os-just/ublue-os-just.sh

$ ls -l /etc/profile.d/ublue-os-just.sh /usr/etc/profile.d/ublue-os-just.sh
-rwxr-xr-x. 1 root root 215 May 10 21:52 /etc/profile.d/ublue-os-just.sh
-rwxr-xr-x. 6 root root 215 Dec 31  1969 /usr/etc/profile.d/ublue-os-just.sh

$ diff /etc/profile.d/ublue-os-just.sh /usr/etc/profile.d/ublue-os-just.sh

@bsherman Yeah that's strange. The results I listed are what I am getting when I base a startingpoint image on ghcr.io/ublue-os/silverblue-main, and then inspecting the internal filesystem after building my derived image. Perhaps rpm-ostree moves the file when it derives images like that.

Is your output from running the image in podman or the rpm-ostree booted image? I think that would explain what you are seeing.

@bsherman From entering a bash shell in podman to look at the image contents. Yeah it could be something that gets fixed by later processes. :)

@bsherman Oh yeah you're right. On a Silverblue system that is rebased to silverblue-main, the file ends up in /usr/etc/profile.d too. Interesting. Learning thing every day. :)


Update to Constantinople/Petersburg

The EEI-related Constantinople changes are CREATE2 and EXTCODEHASH if I'm not mistaken.

CREATE2: add a new method just like create with the additional parameter saltOffset: i32ptr (salt has fixed length of 32 bytes).
EXTCODEHASH: two options:

add a new method getExternalCodeHash(addressOffset, resultOffset)
add isAccountEmpty(addressOffset) (also see #138) and handle the rest on the wasm side.


Patch 87

Description

As already mentioned in #ISSUE_NUMBER, this PR tackles:

...
...
...

In particular, the ...
Checklist

[ ] I followed the indications in the CONTRIBUTING
[ ] The documentation related to the proposed change has been updated accordingly (also comments in code).
[ ] Have you written new tests for your core changes, as applicable?
[ ] Have you successfully ran tests with your changes locally?
[ ] Ready for review! :rocket:

Fixes

Fixes #

@westcoast questa puoi anche cancellarla. Ho modificato link nella pull precedente nella patch 86 che va pubblicata.
grazie


Fix/dev/cleanup

This mainly makes the TargetFramework selection dependent on the operating system.
It also moves the .NET sdk over to 3.0.

Since this one is too old, I m closing it.


mammary gland bud placement

Consider placing "abnormal mammary gland bud morphology" [MP:0013785], "abnormal mammary gland bud elongation" [MP:0013784] and proposed new term "abnormal mammary gland bud formation" [open ticket #2021] as children of "abnormal mammary gland embryonic development [MP:0004135]".
Thanks
Anna
Reported by: anna_anagnos
Original Ticket: obo/mammalian-phenotype-requests/2080

Terms have been reorganized.


subscribe cant be used.

in ws_api_examples
api.subscribe(["BTC-PERP"], channels)
AttributeError: 'RestApi' object has no attribute 'subscribe'

Hi,
Thanks for using. Apologies, I left a line out for some reason. Code has been updated. Please see line 47


[BUG] Orchestrion does not register properly the use of -C option in pinning logic

Version of orchestrion
But present on the main branch last commit: 5130436
Describe what happened:

Describe what you expected:
I expected both commands to work but the one with -C to displace the call to all go commands was not properly intepreted by orchestrion while the second one works fine.
Steps to reproduce the issue:
git clone https://github.com/DataDog/orchestrion
go -C orchestrion build -o="../orchestrion.exe" .
./orchestrion.exe go -C orchestrion/_integration-tests mod tidy

Additional environment details (Version of Go, Operating System, etc.):
go env:

❯ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/eliott/.cache/go-build'
GOENV='/home/eliott/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/eliott/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/eliott/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.5'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/eliott/git/github.com/DataDog/orchestrion/_integration-tests/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1348386482=/tmp/go-build -gno-record-gcc-switches'

Now the issue is: Failed to pin orchestrion in go.mod: getting GOMOD: in "/tmp": go mod GOMOD returned a blank string

Maybe https://github.com/DataDog/orchestrion/pull/384 is fixing it

It does


Add dependencies private repo

The goal of this PR is to support private repository for dependencies. If you add repo_username and repo_password to ChartDependency. It will add the credentials to the add command.

@Maxiimeeb I just made a fix on part of the pipeline, can you merge master? Thanks!


Can newspaper provide favicon of a site?

It will be nice if newspaper could extract the link of favicon of the site! [enhancement]

this feature exists, it just lacks documentation
from newspaper import Article

article = Article("https://github.com/codelucas/newspaper/issues/588")
article.download()
article.parse()
print(article.meta_favicon)

>> https://github.com/fluidicon.png`


fix:updated searchbar component to return result with client side sea…

Description:
modified the code the return the result when client side search is enable and not to when client side search is disabled.
fixes: #15386
updates in PR:
1.passed enableClientSide prop to the search component and applied conditional rendering  to return result.
2.added test file for the changed code.
snapshorts:

Summary by CodeRabbit

New Features

Introduced enableClientSideSearch property across multiple components, allowing for enhanced client-side searching capabilities.
Updated SearchComponent, Table, and TableHeader to support dynamic search functionalities based on user input.

Bug Fixes

Improved state management in the SearchComponent to reset search values appropriately.

Tests

Added comprehensive unit tests for the SearchComponent to validate its functionality and user interactions.

Hii @shadabbuchh @carinanfonseca , I have raised the PR, could you please assign the reviewer to this PR.
thank you.

Hii @shadabbuchh @carinanfonseca @NilanshBansal  ,could you please assign the reviewer to this PR.
thank you.

Adding @rahulbarwal @jacquesikot from the widgets team to check this out.

Hii @rahulbarwal , I have updated the test case names, could you check the changes.
thank you.

@Naveen-Goud CI is failing for your changes: https://github.com/appsmithorg/appsmith/actions/runs/11230421118/job/31217757085?pr=36745
Please check and fix.

@Naveen-Goud can you please fix the failing CI issues.

Hii @rahulbarwal , I have resolved the lint issue , can you re-run the checks.
thank you.

@Naveen-Goud client lint is still failing on your changes: https://github.com/appsmithorg/appsmith/actions/runs/11321677640/job/31481100928?pr=36745#step:9:379
Please run yarn run lint:ci in your local to confirm after fixing.

@Naveen-Goud are you still working on this?


KIC 2.0: Run all CI integration tests against Kong EE as well

Before this issue, all integration tests of KIC 2.0 run against Kong CE.
Acceptance criteria

[ ] Kong EE integration tests on CI match the scope of Kong CE integration tests on CI
[ ] KIC can create and use a non-default workspace with Kong EE (see #1281)
[ ] KIC can interact with an RBAC-protected instance using --kong-admin-token

Run basic tests (udp, tcp, knative, networking-v1) against kong-gateway 2.5, did not see significant regression. Would like to close this to unblock 2.0 GA.

As agreed with @ccfishk - reopening this issue because we've clarified the scope - what we want to achieve here is not a single test run, but perpetual early feedback on CI.


Please How do i use this package to check my user registration progress and let them know in view blade

i want my user to know they have not finish there registration please How do i use it?

This is really something that you need to customize for your use case, this package just provides the API to manage steps and progress.
However, I can give you a brief example...
Controller:
public function show()
{
	$progress = progress(
		step($user->email_verified_at, 'Verified Email')->notNull()
	);
	$progress->get();

	return view('account')->with([
		'progress' => $progress
	])
}

In account.blade.php
{{ $progress->percentage_complete }}