pkg update formats resources

Following this doc:
https://kpt.dev/book/03-packages/05-updating-a-package
Notice the change to ms-tag introduced.
diff --git a/Kptfile b/Kptfile
index 557ec29..e8605d7 100644
--- a/Kptfile
+++ b/Kptfile
@@ -7,15 +7,15 @@ upstream:
   git:
     repo: https://github.com/GoogleContainerTools/kpt
     directory: /package-examples/wordpress
-    ref: v0.3
+    ref: v0.4
   updateStrategy: resource-merge
 upstreamLock:
   type: git
   git:
     repo: https://github.com/GoogleContainerTools/kpt
     directory: /package-examples/wordpress
-    ref: package-examples/wordpress/v0.3
-    commit: b09cb61b5c7e9f994ee1b0b8d8d8546e6e690b05
+    ref: package-examples/wordpress/v0.4
+    commit: 8b3fe0e4566530f54dd91fc545875a688871b402
 info:
   emails:
     -<EMAIL_ADDRESS>diff --git a/deployment/volume.yaml b/deployment/volume.yaml
index 28b2c4d..d2b3edf 100644
--- a/deployment/volume.yaml
+++ b/deployment/volume.yaml
@@ -20,6 +20,6 @@ metadata: # kpt-merge: /wp-pv-claim
 spec:
   resources:
     requests:
-      storage: 20Gi
+      storage: 30Gi
   accessModes:
     - ReadWriteOnce
diff --git a/mysql/Kptfile b/mysql/Kptfile
index d1d6c96..813527d 100644
--- a/mysql/Kptfile
+++ b/mysql/Kptfile
@@ -11,4 +11,4 @@ pipeline:
     - image: gcr.io/kpt-fn/apply-setters:v0.1
       configMap:
         ms-image: mysql
-        ms-tag: 5.6
+        ms-tag: "5.6"

Running render afterwards is a NO-OP.

So I think the problem here is really validation. The value 5.6 is illegal in a ConfigMap. All keys and values must be strings, so a value such as 5.6 must be in quotes.

The real issue is that this change is introduced by pkg get but fn render doesn't format/validate. This breaks the intended workflow. Once you render a package, no other commands should introduce additional formatting.

The cause of this is that kpt fn render only reads the Kptfile, but doesn't output the result. So any changes that results from roundtripping the Kptfile into the go struct and back to yaml is not covered.
In this case, reading the Kptfile into the go struct coerces the yaml float value into a string since the type of the ConfigMap property in the Kptfile is map[string]string.

Related to #2003 where render doesn't format Kptfile.

Addressed by
https://github.com/GoogleContainerTools/kpt/pull/2058
https://github.com/GoogleContainerTools/kpt/pull/2024


wrong version of vaultwarden

ansible-nas is using the "bitwardenrs/server" image for vaultwarden. This image is deprecated in favor of "vaultwarden/server". Further, "bitwardenrs/server" doesn't appear to be compatible with many of the upstream bitwarden clients such as the Chrome extension or Firefox extension since it throws an "unable to fetch" error when attempting to login.
The docs also still refer to bitwarden-rs. To ease transition and solve the incorrect naming, perhaps we could consider adding vaultwarden.ansible-nas-domain.com as a new route with the new container.

I do encounter the same issue (can't login via bitwarden apps/browser addons) and tracked it down to this:

newer bitwarden clients refuse to login with the self-hosted server, see this issue

Bitwarden has released new client versions which are not compatible with Vaultwarden version bellow 1.27.0.
Since version 1.27.0 Vaultwarden supports these new clients and has many bugs fixed and features added.

the bitwardenrs/server  image is depcrecated (as mentioned by @choskeli)

As the used image is deprecated and is no longer updated, anyone using a newer client will be unable to login anywhere but in the browser.
A reasonable course of action would be to replace the bitwarden_rs/server image with the maintained vaultwarden/server. This ensures our Homelabs run up-to-date software and can use a up-to-date version of the bitwarden client software.

I tried updating the image to bitwardenrs/server but surprisingly I'm still seeing the fetch error on most clients. What is strange is that the android client actually works fine.
I also checked the logs to verify I'm on Vaultwarden 1.27.0 which is latest. I'd expect to see an issue already on Vaultwarden's GitHub if this is an issue with Vaultwarden itself so this requires more investigation

From what I see, bitwardenrs/server is just as outdated as bitwarden/server (both roughly 9 months since the last update. So I think that solution won't work.

From what I see, bitwardenrs/server is just as outdated as bitwarden/server (both roughly 9 months since the last update. So I think that solution won't work.

I was using vaultwarden/server I just had a typo in my URL. Everything is working now and it's just a 1 line change to the code. I made a pull request

Can confirm the proposed solution worked for me. I just switched the image from bitwardenrs/server to vaultwarden/server and re-ran the playbook (with --tag bitwarden). Afterwards the logins work again as expected; my existing vaults are still there and working.


maintainers: set henrikbrixandersen as canbus maintainer

Set henrikbrixandersen as the new maintainer of canbus
Signed-off-by: Alexander Wachter<EMAIL_ADDRESS>

Thank you @alexanderwachter for all the hard work on CAN!

Thank you for all your efforts so far, Alex :)

No worries. I'll still be active as much as possible.
Just handing over to someone who is more active now (and has more time).
The thing is that I'm not using CAN in my professional career (but Zephyr :-)) and all the time for maintaining was taken from my spare time. Brix noticed that and offered to take over.
When I introduced CAN in Zephyr, I did to promote 6LoCAN which was removed recently, I had plenty of time.
Now since I'm working full time I focus more on having some time without my computer in front.

@alexanderwachter You need to fix the CI compliance issue regarding the author email in order for this to be merged.

@henrikbrixandersen need to do that on my own pc tomorrow

Fixed compliance check.


Do not move schebang

Typescript Hero moves schebang comment after imports. If you have a file like

#! /usr/bin/env node

import ...

It will become:

import ...

#! /usr/bin/env node

Which is wrong. If the first line starts with "#!" it must not touch it.

When are you going to release?

This should be released. https://github.com/buehler/typescript-hero/releases/tag/v2.3.0
v.2.3.1


Optimize batch changes to objects

Currently you can update individual fields by returning a channel. The system knows it's a "live field update" because the field is not an array, so the channel return only makes sense if it's an update channel (each entry in the channel is a new latest value for the field).
It would then make sense to allow returning entire struct instances as live object updates. This might happen when someone gets an entire batch object instance every time an object is updated in the database. In this case, the system should record some kind of hash of the previous value (4 bytes maybe?) that act as a simple dirty check to see which fields changed, rather than actually storing and comparing the values (memory wasted, cpu time wasted).

Used in #15

Done in the new batching algorithm


Adding Notenik

Adding a new app. Submitted by the developer.

Thanks for submitting this, and sorry about the delay!


Correct GH edit address

I saw that the "improve the page button" leads to 404.
It's because the git_edit_address is https://github.com/hahwul/dalfox/docs when it should be https://github.com/hahwul/dalfox/tree/main/docs.
This should fix the problem

Hi @palmiak
Thank you so much for taking the time to report the issue and for sending us a PR! Your effort really helps dalfox improve. I'm super grateful for your contribution :D

Happy to help ❤


Evaluating is too slow

Hi, there. I find my evaluating stage is too slow, as shown in the below figure (training costs 1:43 for 10 steps, while evaluating already costs 3:43 for only 1 step). May I ask what may cause this kind of issue?

The config and trainer are listed below (using the lasted dev branch):
# CollieConfig
pp_size: 1
tp_size: 1
dp_size: 4
train_micro_batch_size: 4
eval_batch_size: 4
dataloader_num_workers: 4
eval_per_n_epochs: 1
eval_per_n_steps: 0
ds_config:
    train_micro_batch_size_per_gpu: 4
    zero_optimization:
        stage: 2

# trainer
evaluators = [
    Evaluator(
        model=model,
        config=collie_cfg,
        dataset=dataset_val,
        collate_fn=data_collator,
        tokenizer=tokenizer,
        monitors=[
            EvalMonitor(collie_cfg)
        ],
    )
]
trainer = Trainer(
    config=collie_cfg,
    model=model,
    optimizer=optimizer,
    lr_scheduler=lr_scheduler,
    train_dataset=dataset_trn,
    train_dataset_collate_fn=data_collator,
    evaluators=evaluators,
)

Hi, we have noticed this problem and are going to solve it. For now, you can set model.set_cache(False) right after the model is initialized. Hope it is helpful for you.

新版本已解决


WIP: Introduced support for openAPI authentication

This PR is for adding support to the new way of authenticating to the HUB through openAPIs, which is available on CodeSonar HUBs which version is grater or equals to 7.2.
WIP: There are several things that are holding this PR back from being considered complete, these are:

DONE Fix bug with Server Certificate credential dropdown in freestyle projects.
DONE Plugin/protocol version --> avoid hardcoding it
NO MORE REQUIRED** Logs generated by the plugin --> Implement a custom log wrapper that lets the user specifying the desired log level as a pipeline parameter and assign the proper log level to each log statement (comment out sensitive information ones)
** Reading at this article https://www.jenkins.io/doc/book/system-administration/viewing-logs/ we've found that Jenkins already offers a way for configuring loggers
DONE Move the call to command/check_version earlier in the flow, so that in is called anytime, no matter what authentication method is chosen by the user. Currently there's a bug that prevents it from being called when authenticating as anonymous
DONE Avoid calling both command/anon_info and command/check_version, but use the first one as a fallback for the second one instead. Also try to understand what was the original purpose of checking that version with command/anon_info

We should fix this typo in this PR: 'evaulating' -> 'evaluating'
CodeSonarPublisher.java:283
        listener.getLogger().println("[Codesonar] Done evaulating conditions");


feature suggestion - keyboard layout builder

It occurred to me that it might be possible (easy?) to add a feature to generate keyboard layouts. Something like
> kmonad --generate-layout

   This will generate a keyboard layout and output it to ./layout.kbd
   You will be asked to press the keys in each row one at a time.
   When no keyboard input is detected for 5 seconds the process will move on to the next keyboard row.
   When no keyboard input is detected for 10 seconds the process will complete and the layout will be output.

   While this process is running, you will not be able to use your keyboard normally.

Continue?
(y) continue (n) quit (t) change timeouts

Does this seem like worthwhile feature?

@maninalift
What do you think about this: https://github.com/mnesarco/kmonad_dump ?

@mnesarco unless I misunderstand that tool seems to be for turning kmonad . kbd layout files into another format. I'm proposing something for generating the .kbd files.
My reasoning is that writing the keyboard layout file is probably the biggest barrier to setting up kmonad. However pressing the keys on a keyboard one at a time is easy, and kmonad already has the ability to suppress keyboard output and to associate detected key presses with the representation used in its configuration files.

Furthermore, thinking on a low-tech user, one can have a graphical interface to choose/design the keyboard physical layout, copy/duplicate to create layers and also to assign different 'functions' to each key on each layer. I don't think that is too much of an effort, and I may very well make a prototype if there are enough low-tech users.


Use a single TLS implementation

Currently native-tls is set as a default feature, but selecting a different tls implementation requires default-features = false in your Cargo.toml.
This PR will select one of the alternatives in alphabetical order, so that if you ask for features = ["vendored-openssl", "rustls", "native-tls"] you will get the implementation for rustls.
This solves a similar issue to #237, but uses cfg-if in order to just surface a single implementation where necessary.

I wrote my reaction to the opinions in https://github.com/prisma/tiberius/pull/237#issuecomment-1700892327 — but tl;dr I like the approach in this PR.

It could be interesting to add a test in the github actions to ensure this behavior isn't broken later (cargo hack check --feature-powerset with a few feature exclusions is also nice for this)

Thanks @tomhoule I've updated documentation and also noticed that we might not want any TLS implementation by looking through #305  so I've added a check to see if native-tls is on at all.


Clean up meshes

Meshes for basic shapes don't need urdfs, but can be loaded directly via Pybullet.
Each robot should get its own folder with all relevant files (meshes + python files).

Removal of meshes for basic shapes is done

Meshes are now in the respective robot folder


Don't set up queue if write key is not set

Hi,
You've done a nice job cleaning up this fork for PHP 8, but it sounds like Graham isn't too bothered about merging or maintaining it. I've already made this PR against his repo, but I figured it might do better bundled in with your changes, so i thought I'd post it here too.
It simply moves the initial queue setup inside the key check, which means that the queue cleanup functions don't get called on shutdown if you have no key. If you don't do this, and you don't have a key set, it will throw an error at the end of every request. If you don't have a key set, it then just fails quietly – which is very useful for dev or staging envs – in my case this issue was causing 32,000 exceptions/day on my staging server before I figured it out!

FYI, I've also done a major cleanup of Segment's upstream analytics-php library which I'm intending to PR to them - extra sets of eyes appreciated!


Revert "Map also empty dictionaries to file"

This reverts commit f54428fb8dfe98aacecc0b66e3c1ca2071ce1834 (#1347), which was a big regression in performance and file sizes when using dynamic_context, and is no longer needed for #972 as of 4cc32922685c6971275f522304b3754ad1a233c1 (#1538).
Fixes #1586.
We’ve been using this revert in Zulip without problems (zulip/zulip#25634), having previously been stuck on 6.4.2 for this regression.

This is now released as part of coverage 7.2.7.


add save function to store results

This adds a utility function to quickly save the results in a standard way. Works as follows
import evaluate
results = {"bleu": 1.0, "rouge": 0.0}
params = {"model": "gpt-2", "temperateure": 0.5}

evaluate.save("./results/", **results, **params)
>>> file saved at: PosixPath('results/result-2022_05_19-17_35_38.json')

One can also explicitly pass a filename if one does not want the automatically generated timestamp. The file results/result-2022_05_19-17_35_38.json contains the following:
{
    "bleu": 1,
    "rouge": 0,
    "model": "gpt-2",
    "temperateure": 0.5,
    "_timestamp": "2022-05-19T17:35:38.580167",
    "_git_commit_hash": "0f6f96f4dc6868239db91baaff93ae4deed3260b",
    "_evaluate_version": "0.0.1.dev0",
    "_python_version": "3.9.12 (main, Mar 26 2022, 15:51:15) \n[Clang 13.1.6 (clang-13<IP_ADDRESS>)]",
    "_interpreter_path": "/Users/leandro/git/evaluate/env/bin/python"
}

In addition to the passed key/value pairs it also saves an additional information that could be useful for reproducability. A format like that with several stored json files could easily be loaded e.g. into a DataFrame for comparison.
What do you think?
This closes #7.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


SPIR-V is rejected by ShaderProcessor if shader defs are present

Bevy version
v0.9.1
What you did
Compiled a SPIR-V shader via rust-gpu which requires access to bevy_pbr's light and cluster data, but is prevented from binding read-only storage buffers due to upstream limitations.
I used WgpuSettings to set WgpuLimits::max_storage_buffers_per_shader_stage to 0, guaranteeing that the relevant data would be stored in uniform buffers, then tried to render a mesh with said shader.
What went wrong
The shader failed to load, with the following error originating from ShaderProcessor:
failed to process shader: This Shader's format does not support processing shader defs.
Additional information
This behaviour seems incorrect, given that SPIR-V is a precompiled format, and any conditional processing is thus implied to have taken place at compile time.
Most shader defs - such as VERTEX_POSITION or TONEMAP_IN_SHADER - are added to the RenderPipelineDescriptor before Material::specialize is called, and so can be cleared by downstream code as a workaround.
However, WGPU-predicated defs like NO_STORAGE_BUFFER_SUPPORT are injected after Material::specialize. This prevents user code from removing them before ShaderProcessor runs, thus effectively preventing SPIR-V from being used in any context where bevy_pbr's preferred GPU limitations are not met.
While there may be discussion to be had re. asserting the correctness of a given SPIR-V shader before allowing it to run, I think such functionality is currently outside the scope of ShaderProcessor. Removing the check would allow usage of correct SPIR-V shaders, and avoid the aforementioned clearing workaround.
I've put together an example repo with a working rust-gpu / bevy pipeline, which contains the shader crate in question (a Rust reimplementation of bevy_pbr), as well as the strata needed to compile it into SPIR-V, and a simple bevy app to render it alongside a StandardMaterial for comparison.
It depends on a patched fork of bevy 0.9.1 that removes the shader def error case, and the issue in question can be reproduced by pulling a local copy and modifying Cargo.toml to depend on the crates.io release.
I cherry-picked the change into main and created a separate branch, so have PRed that for the sake of retaining a 0.9.1 fork for my own use.

This is super important! Needs to be fixed.


why so many  jquery-ui components?

hello, there's something I can not understand why so many  jquery-ui components?

Link to source you've read?

Hi, those are remains of the old code, the new code is on branch 1.0 https://github.com/microweber/microweber/tree/1.0

Oh, thanks!! :)


How to change the TLS handshake signature algorithm?

I have modified the code to obtain the correct ECC algorithm public key and key and run successfully.
        let tlsStat = tls?.pointee.api.pointee.set_own_cert(tls?.pointee.ctx,                                               certPEM.cString(using: .utf8),                                               certPEM.count + 1,                                               privKeyPEM.cString(using: .utf8),                                               privKeyPEM.count + 1)
But the request returned error -53.
I think it is the default TLS handshake signature verification RSA algorithm. How can I modify it to ECC algorithm.
Please help

The key referenced in the quoted code snippet is where the client cert and key are set for mutual TLS.  The key and cert are created and stored in the keychain during enrollment. See https://github.com/openziti/ziti-sdk-swift/blob/b844f2d4126d558dbaec66daf6992014fae37de0/lib/ZitiKeychain.swift#LL43C41-L43C41
The kSecAttrKeyType parameter sets the algorithm used to create the key.  Possible values can be found here: https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values

I see from comment on #191 that @Hin-D has found a way to accomplish adding own key support for TLS


Fix for DS-2543

Cleans the cached OAI responses after doing a full item import with the -c option

Seems like a tiny, obvious fix that should just be merged immediately, assuming you've tested it works @cjuergen :)
+1

+1 I agree, assuming it was tested.

+1 I've tested that this does indeed work properly. Merging


feat(inputstep): enable paste in matters id input

In the previous state, pasting Matters ID during registration was disabled to alert user the importance of this UUID. However, this presents UX drawbacks to users for unexpected behavior. Reverting to default behavior.
re #4251

e2e test timeout due to cloudflare security setting

First PR 🚀


Cannot run perf.py in benchmark

When running perf.py in the benchmark folder, the code could not compile because the Evoformer constructor got an unexpected argument "d_node." There seems to be a mismatch between the Evoformer constructor's declared list of arguments (/fastfold/model/fastnn/evoformer.py) and its provided arguments in benchmark/perf.py

Hi, I have fixed it in #177.
If there are still bugs, feel free to reopen this issue.

Thank you very much for the fix! I ran into a new issue in #178, could you confirm whether that is still an error related to the CLI/interface, please?


ignition stops working with v0.21.0

BUG REPORT:
/kind bug
What happened:
tried ignition with multiple version of kubevirt according https://kubevirt.io/2018/ignition-support.html
With kubevirt v0.21.0 ist doesn't work anymore
What you expected to happen:
When i inject public key via kubevirt.io/ignitiondata i should able to ssh in VM via NodePort
How to reproduce it (as minimally and precisely as possible):
start minikube according https://kubevirt.io/quickstart_minikube/ (tested with --kubernetes-version='v1.15.4')
kubectl apply -f   https://github.com/kubevirt/kubevirt/releases/download/v0.21.0/kubevirt-operator.yaml

confgmap
apiVersion: v1
kind: ConfigMap
metadata:
  name: kubevirt-config
  namespace: kubevirt
  labels:
    kubevirt.io: ""
data:
  feature-gates: "ExperimentalIgnitionSupport"

kubectl apply -f   https://github.com/kubevirt/kubevirt/releases/download/v0.21.0/kubevirt-cr.yaml

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: coreos-vm01
spec:
  running: true
  template:
    metadata:
      labels:
        coreos: vm01
      annotations:
        kubevirt.io/ignitiondata: |
          {
              "ignition": {
                  "config": {},
                  "version": "2.2.0"
              },
              "networkd": {},
              "passwd": {
                  "users": [
                      {
                          "name": "core",
                          "sshAuthorizedKeys": [
                              "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+snp6pIDq4vqhHZhTKVrFRADZgxzC9xF6tAn7aFKoh80hgoCLoVT0LuEZy6Ya9Y33q1AGrnp18iJW8BYKV1W7rm+ty1B4KxCgfpJnu1Ywgw40tIj1e6YaUZ6j5v4iC2isYqsN+NtMS0ObokzPCXXkl2v/LXxfQArV+GNufbLgnyxpEzj2dt5rhC+uKWUOvpNjbdIxamTRooADC8jBcMnF4K33rnA0L4bFxVLbaiJ4vZE/2VpXGIKJG7xOHs/jEtdyJSuoH/e0u8bBQwsCQ6xYE4PzjCiPWQx2iC9y2C88vGSmXBflnTpz+rwK9xRF+9kxqGel2vcH+E2B4+W2MjKh<EMAIL_ADDRESS>                          ]
                      }
                  ]
              }
          }
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            bridge: {}
        resources:
          requests:
            memory: 3072M
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: registrypro.yyy.de/xxx/coreos
---
apiVersion: v1
kind: Service
metadata:
  name: coreos-vm01
spec:
  ports:
  - port: 22
    name: ssh
    protocol: TCP
    targetPort: 22
  selector:
    coreos: vm01
  type: NodePort

ssh  -l core -p
Password:
Anything else we need to know?:
tested with 0.20.8 it was fine.
ingnition-data dir ist empty
kubectl exec -it virt-launcher-coreos-vm01-zcnm7 -c compute -- ls -al /var/run/kubevirt-ephemeral-disks/ignition-data
total 8
drwxr-xr-x 2 root root 4096 Oct 29 09:13 .
drwxrwxrwx 5 root root 4096 Oct 29 09:13 .

Environment:

KubeVirt version (use virtctl version): 0.21
Kubernetes version (use kubectl version): 1.15.4
VM or VMI specifications:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

logs from laucher
{"component":"virt-launcher","level":"info","msg":"Collected all requested hook sidecar sockets","pos":"manager.go:68","timestamp":"2019-10-29T09:13:05.593093Z"}
{"component":"virt-launcher","level":"info","msg":"Sorted all collected sidecar sockets per hook point based on their priority and name: map[]","pos":"manager.go:71","timestamp":"2019-10-29T09:13:05.593180Z"}
{"component":"virt-launcher","level":"info","msg":"Watchdog file created at /var/run/kubevirt/watchdog-files/kubevirt_coreos-vm01","pos":"virt-launcher.go:142","timestamp":"2019-10-29T09:13:05.594718Z"}
{"component":"virt-launcher","level":"info","msg":"Connecting to libvirt daemon: qemu:///system","pos":"libvirt.go:348","timestamp":"2019-10-29T09:13:05.602337Z"}
{"component":"virt-launcher","level":"info","msg":"Connecting to libvirt daemon failed: virError(Code=38, Domain=7, Message='Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory')","pos":"libvirt.go:356","timestamp":"2019-10-29T09:13:05.603475Z"}
{"component":"virt-launcher","level":"info","msg":"libvirt version: 5.0.0, package: 1.fc30 (Unknown, 2019-07-11-18:14:09, )","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:05.660000Z"}
{"component":"virt-launcher","level":"info","msg":"hostname: coreos-vm01","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:05.660000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get DBus system bus connection: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory","pos":"virDBusGetSystemBus:108","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:05.660000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get DBus system bus connection: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory","pos":"virDBusGetSystemBus:108","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:06.267000Z"}
{"component":"virt-launcher","level":"warning","msg":"DBus not available, disabling firewalld support in bridge_network_driver: internal error: Unable to get DBus system bus connection: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory","pos":"networkStateInitialize:761","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:06.267000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:00.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.285000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:01.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.285000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:01.1/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.286000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:01.2/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.286000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:01.3/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.287000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:02.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.290000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:03.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.290000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:04.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.294000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:05.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.294000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:06.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.295000Z"}
{"component":"virt-launcher","level":"error","msg":"Failed to open config space file '/sys/bus/pci/devices/0000:00:07.0/config': Read-only file system","pos":"virPCIDeviceConfigOpen:298","subcomponent":"libvirt","thread":"48","timestamp":"2019-10-29T09:13:06.295000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Child process (/usr/sbin/dmidecode -q -t 0,1,2,3,4,17) unexpected exit status 1: /dev/mem: No such file or directory","pos":"virCommandWait:2609","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:07.724000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Cannot probe for supported suspend types","pos":"virNodeSuspendSupportsTarget:335","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:07.735000Z"}
{"component":"virt-launcher","level":"warning","msg":"Failed to get host power management capabilities","pos":"virQEMUCapsInit:926","subcomponent":"libvirt","thread":"43","timestamp":"2019-10-29T09:13:07.735000Z"}
{"component":"virt-launcher","level":"info","msg":"Connected to libvirt daemon","pos":"libvirt.go:364","timestamp":"2019-10-29T09:13:09.449022Z"}
{"component":"virt-launcher","level":"info","msg":"Registered libvirt event notify callback","pos":"client.go:283","timestamp":"2019-10-29T09:13:09.451451Z"}
{"component":"virt-launcher","level":"info","msg":"Marked as ready","pos":"virt-launcher.go:72","timestamp":"2019-10-29T09:13:09.451623Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Executing PreStartHook on VMI pod environment","name":"coreos-vm01","namespace":"kubevirt","pos":"manager.go:731","timestamp":"2019-10-29T09:13:10.490065Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Starting PreCloudInitIso hook","name":"coreos-vm01","namespace":"kubevirt","pos":"manager.go:740","timestamp":"2019-10-29T09:13:10.490143Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","level":"info","msg":"updated MAC for eth0 interface: old: 02:42:0a:81:00:0b -\u003e new: 02:42:0a:3b:c1:ce","pos":"common.go:255","timestamp":"2019-10-29T09:13:10.490925Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"bridge pod interface: VIF: { Name: eth0, IP: <IP_ADDRESS>, Mask: ffff0000, MAC: 02:42:0a:81:00:0b, Gateway: <IP_ADDRESS>, MTU: 1500}","name":"coreos-vm01","namespace":"kubevirt","pos":"podinterface.go:258","timestamp":"2019-10-29T09:13:10.492160Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","level":"info","msg":"Found nameservers in /etc/resolv.conf: \n`\u0000\n","pos":"converter.go:1479","timestamp":"2019-10-29T09:13:10.492281Z"}
{"component":"virt-launcher","level":"info","msg":"Found search domains in /etc/resolv.conf: kubevirt.svc.cluster.local svc.cluster.local cluster.local","pos":"converter.go:1480","timestamp":"2019-10-29T09:13:10.492299Z"}
{"component":"virt-launcher","level":"info","msg":"Starting SingleClientDHCPServer","pos":"dhcp.go:64","timestamp":"2019-10-29T09:13:10.501408Z"}
{"component":"virt-launcher","level":"info","msg":"Driver cache mode for /var/run/kubevirt-ephemeral-disks/disk-data/containerdisk/disk.qcow2 set to none","pos":"converter.go:172","timestamp":"2019-10-29T09:13:10.509444Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain defined.","name":"coreos-vm01","namespace":"kubevirt","pos":"manager.go:957","timestamp":"2019-10-29T09:13:10.514590Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event 0 with reason 0 received","pos":"client.go:248","timestamp":"2019-10-29T09:13:10.514797Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get DBus system bus connection: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory","pos":"virDBusGetSystemBus:108","subcomponent":"libvirt","thread":"28","timestamp":"2019-10-29T09:13:10.516000Z"}
{"component":"virt-launcher","level":"error","msg":"At least one cgroup controller is required: No such device or address","pos":"virCgroupDetect:393","subcomponent":"libvirt","thread":"28","timestamp":"2019-10-29T09:13:10.805000Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Paused(3):StartingUp(11)","pos":"client.go:179","timestamp":"2019-10-29T09:13:12.837694Z"}
{"component":"virt-launcher","level":"info","msg":"Detected domain with UUID ef5e8a1b-0712-55d6-a4a3-754083c91379","pos":"virt-launcher.go:233","timestamp":"2019-10-29T09:13:12.840301Z"}
{"component":"virt-launcher","level":"info","msg":"Monitoring loop: rate 1s start timeout 5m0s","pos":"monitor.go:237","timestamp":"2019-10-29T09:13:12.840340Z"}
{"component":"virt-launcher","level":"info","msg":"processed event","pos":"client.go:235","timestamp":"2019-10-29T09:13:12.842200Z"}
{"component":"virt-launcher","level":"info","msg":"GuestAgentLifecycle event state 2 with reason 1 received","pos":"client.go:266","timestamp":"2019-10-29T09:13:13.272004Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Paused(3):StartingUp(11)","pos":"client.go:179","timestamp":"2019-10-29T09:13:13.274548Z"}
{"component":"virt-launcher","level":"info","msg":"processed event","pos":"client.go:235","timestamp":"2019-10-29T09:13:13.282182Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event 4 with reason 0 received","pos":"client.go:248","timestamp":"2019-10-29T09:13:13.306513Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Running(1):Unknown(1)","pos":"client.go:179","timestamp":"2019-10-29T09:13:13.318459Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event 2 with reason 0 received","pos":"client.go:248","timestamp":"2019-10-29T09:13:13.334570Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain started.","name":"coreos-vm01","namespace":"kubevirt","pos":"manager.go:988","timestamp":"2019-10-29T09:13:13.340482Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"coreos-vm01","namespace":"kubevirt","pos":"server.go:167","timestamp":"2019-10-29T09:13:13.341355Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","level":"info","msg":"processed event","pos":"client.go:235","timestamp":"2019-10-29T09:13:13.415770Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Running(1):Unknown(1)","pos":"client.go:179","timestamp":"2019-10-29T09:13:13.453289Z"}
{"component":"virt-launcher","level":"info","msg":"processed event","pos":"client.go:235","timestamp":"2019-10-29T09:13:13.587572Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"coreos-vm01","namespace":"kubevirt","pos":"server.go:167","timestamp":"2019-10-29T09:13:13.748767Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"coreos-vm01","namespace":"kubevirt","pos":"server.go:167","timestamp":"2019-10-29T09:13:13.769989Z","uid":"f8a02813-a0f4-4b10-b962-c0740807f67e"}
{"component":"virt-launcher","level":"info","msg":"Found PID for ef5e8a1b-0712-55d6-a4a3-754083c91379: 104","pos":"monitor.go:206","timestamp":"2019-10-29T09:13:13.841996Z"}

@1337andre we have a test, which passes also on 0.22 relase about ignition. It tests for the existence of this file inside the VMI: /sys/firmware/qemu_fw_cfg/by_name/opt/com.coreos/config. Could you verify that this file does not exist, or not have the content which you would expect?
Maybe the test is not testing the right thing (for instance the file could be present but empty).

Hm, the files are properly filled on master at least.

Confirmed tried versions 0.22 and 0.23 and on both of these ignition does not work.
Rolling back kubevirt to 0.19 and things works again.

@salkin and @1337andre thanks. If you can, would you mind having a look into /sys/firmware/qemu_fw_cfg/by_name/opt/com.coreos/config/raw on both versions? I will try that too, but on my experiments it always looked the same. I am obviously missing something which would reveal the bug.

@karmab do you have an idea?

Ok, could reproduce it now. What's interesting, is that it only seems to happen on the release and not when using the git repos.

Finally found time to investigate this more carefully. Here the result:
I took the following image:
http_file(
    name = "fedora_coreos_image",
    sha256 = "6c3703317aaf97e66c04a7c407946a9e396786c3d56fbfd5736c93d33e774dd3",
    urls = [
        "https://builds.coreos.fedoraproject.org/prod/streams/testing/builds/30.20191014.0/x86_64/fedora-coreos-30.20191014.0-qemu.x86_64.qcow2.xz",
    ],
)

and booted a VMI which looked like this:
---
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  labels:
    special: vmi-fedora
  annotations:
    kubevirt.io/ignitiondata: |
      {
        "ignition": {
          "version": "3.0.0"
        },
        "passwd": {
          "users": [
            {
              "name": "core",
              "groups": [
                "sudo"
              ],
              "passwordHash": "$1$K8.gjDkF$/hj32bNQhVLKW3ytslM630"
            }
          ]
        }
      }
  name: vmi-fedora
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: containerdisk
      rng: {}
    machine:
      type: ""
    resources:
      requests:
        memory: 1024M
  terminationGracePeriodSeconds: 0
  volumes:
  - containerDisk:
      image: registry:5000/kubevirt/fedora-coreos-container-disk-demo:devel
    name: containerdisk

Then I logged in as user core:test. Worked like expected.
Would you mind retrying? with the image and the config which I posted here?

Ok, I pushed my containerdisk  to my repo. You can now directly just craete the yaml file from my example.

I will give it a try, on monday... and give u some feedback

i have tested with your yaml file with kubevirt 0.23.1
replaced fedora-coreos with coreos:2247.7.0  and "ignition": {          "version": "2.2.0"        }
works for me! thx a lot

Confirmed also on kubevirt 0.24.0. Issue can probably be closed.

/close

Hello guys, are you sure that this issue is actually fixed? I have multiple kubevirt clusters versions:

v0.26.4
v0.24.0
v0.23.3
v0.19.0

And among those only version v0.19.0 is able to run a coreos machine with ignition. I used the same image(which works on 0.19.0) and they don't inject the ignition data to the vmi. CoreOS image 2345.3.0,  coreos_production_qemu_image.img.bz2.
I can see that, there is no data whatsoever inside /var/run/kubevirt-ephemeral-disks/ignition-data/ thus I am not quite sure that the template data is being transferred to the pod nor the vmi.
Not sure if it is actually related to this issue here https://github.com/kubevirt/kubevirt/pull/3110 which might be the case.

i don't think there has been a lot of change in ignition support ever since it was added so i suggest:

boot your image and have a look at the qemu process in the launcher pod to check whether it contains a section like -fw_cfg name=opt/com.coreos/config,file=... pointing to the ignition data.
trying with a known to work image like fedora-coreos container disk (make sure to set ignition version to 3.0.0)

I have been successfully running on kubevirt 0.25.0 for few months and no issues. 0.21-0.23 I think I tried but those did not work.

@karmab

boot your image and have a look at the qemu process in the launcher pod to check whether it contains a section like -fw_cfg name=opt/com.coreos/config,file=... pointing to the ignition data.

The image is booting correctly without any issue, however the line that you mentioned is not shown in the virt-launcher pod.

try with a known to work image like fedora-coreos container disk (make sure to set ignition version to 3.0.0)

The image that I am using used to work without any issue in v0.19.0, but again maybe I am overlooking something.
@salkin

I have been successfully running on kubevirt 0.25.0 for few months and no issues. 0.21-0.23 I think I tried but those did not work.

Are you running fedora-coreos images?
One thing to add, I am actually creating those VMI using VM template and using cdi to import the image.

@moadqassem  I am only running Container Linux coreos. Tried fedora-coreos so also that works but we do not use that.

@salkin I see. It looks like the virt launcher is trying to lookup the ignition data and it is not found. I can see however the ignition data template in the vm manifests but it's not present in the vmi nor is being copied to /sys/firmware/qemu_fw_cfg/by_name/opt/com.coreos/config/raw as @rmohr suggests in a previous comment. Something must have been changed thus the functionality is not working anymore.


Code to allow adding HTTP header values from within controllers

Same code I added to Master.  This change adds some header methods that can be accessed from the controllers.  This allows you to add header values directly from within the controller.

Thanks for the work. This is however (partly) fixed by #71, if you need more functionality, please, create another issue so we can discuss if it's something we want to suppport.


ESP32 setup Local TCP/SSL server.

Hello. I am trying to setup TCP server via SSL using with AT Commands. I did it without SSL. But now I want to setup that with SSL. How can I do that? Do you have any document about it?

@hiflord  please take a look, docs

I looked this doc but I need to an example about how to setup local ssl tcp server. Also I need to know how to check this crypted datas.

@hiflord I am no sure you read the wrong docs, please view the ESP_AT_Commands_Set.md  again,
there are some examples under the 4.10 AT+CIPSERVER

you can capture the TLS packets to check the crypted datas, by wireshark, omnipeek, etc...


HasLoggedErrors should respect MSBuildWarningsAsErrors

Steps to reproduce
warnaserr.tar.gz
    public class MyTask : Task
    {
        public override bool Execute()
        {
            Log.LogWarning(subcategory: null,
                           warningCode: "MyWarning1234",
                           helpKeyword: null,
                           file: null,
                           lineNumber: 0,
                           columnNumber: 0,
                           endLineNumber: 0,
                           endColumnNumber: 0,
                           message: "my warning");

            return !Log.HasLoggedErrors;
        }
    }

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <MSBuildWarningsAsErrors>MyWarning1234</MSBuildWarningsAsErrors>
  </PropertyGroup>

  <UsingTask TaskName="task.MyTask" AssemblyFile="$(MSBuildThisFileDirectory)../task/bin/Debug/net5.0/task.dll" />
  <Target Name="MyTargetOuter"
          DependsOnTargets="MyTargetInner">
    <Message Importance="High" Text="Outer target" />
  </Target>

  <Target Name="MyTargetInner">
    <MyTask />
  </Target>

> dotnet msbuild /t:MyTargetOuter
warnaserr/project/project.csproj(16,5): error MyWarning1234: my warning
  Outer target

Expected behavior
Log.HasLoggedErrors returns true when the logged warning is treated as an error due to MSBuildWarningsAsErrors, causing the build to stop after MyTask.
Actual behavior
HasLoggedErrors returns false, the build continues, and the outer target runs even after the task produced an error.
Perhaps this is the intended behavior. If that's the case, is there a recommended way for tasks to check whether any of their warnings have been turned into errors?
We are using ToolTask (which relies on HasLoggedErrors by default) for the IL linker MSBuild task, and we don't want to continue the build if any errors were logged - otherwise we touch a file on disk that prevents the linker from running incrementally next time.
Environment data
msbuild /version output: <IP_ADDRESS>003
OS info: 18.04.1-Ubuntu
If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc): dotnet cli

Team triage: we think that it's right that this is how it should behave.
We're a bit concerned about two scenarios:

User has a project that warns-as-errors, builds it, and expects output (even though it would fail today).
User expects errors from downstream targets that would now be dropped.

We think this should be fixed to match your expectations.


Removed undefined mixins

these mixins are variants, which causes errors as they are simply undefined yet

Hey @njtan142 you're getting these errors because instead of pnpm you are using yarn

Thank you for the clarification!


Release note v3.0.0 sign off - RISCV

Looking for release note v3.0.0 sign off on arch RISCV

Release channel recommending closing the issues.


Moved Schematic Text Logic to SchematicComponentRenderWithSchematicBoxDimensions

/closes #377
/claim #377

@seveibar @anas-sarkez it is also present in jumper.ts file i think we also have to moved it from there also.

@Anshgrover23 Yes you are right, I. Thanks, I Will create a quick pr for that


Demand and energy tiers that vary by month

The demand and energy schedules from the URDB are set up to vary by month, including tier limits.  We currently have copies of the tier limits in place when parsing the URDB response, but in the event that tier limits change by month the formulation is not well equipped to handle this.

Tier limits now can change by month here: https://github.com/NREL/REopt.jl/pull/401


Add a setting to disable collectors

When running from cron, collectors were disabled from running on preview
and staging due to google api rate limits. This setting will let us
disable the collectors on staging and preview.

https://github.gds/gds/alphagov-deployment/pull/1098


”Oprișor” is listed in the drop-down menu

Description:
"Oprișor" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Oprișor" in the search bar.

Expected results
The location is listed in the drop-down menu as "Comuna Oprișor, MEHEDINȚI".


class_loader: remove poco library depency

Poco dependency was already removed by cherry-picking from the Apollo repo. And this PR is going to be closed.

Poco dependency was already removed by cherry-picking from the Apollo repo. And this PR is going to be closed.


Add new blockchain commands

USAGE
nem2-cli blockchain <subcommand>

SUBCOMMANDS
receipts - Get the receipts triggered for a given block
transactions - Get the list of transactions for a given block

SUBCOMMANDS transactions :https://github.com/nemtech/nem2-cli/pull/40


IS-1225: Fixing boolean type casting bug on windows

https://jira.hyperledger.org/browse/IS-1225
Indy boolean values were defined as unsigned integers. This works just fine on linux.
typedef unsigned int  indy_bool_t
However, this causes issues on windows because the extra memory is not managed.

rust
windows int
hex value

true
1527741697
0x5B0F7D01

false
543435264
0x20642A00

Rust only emits the 1 byte for booleans. But unsigned int tells the c++ compiler to look at 2 or 4 bytes.
I propose we change it it to
typedef   bool     indy_bool_t
This gives a hint to the windows c++ compiler and tells it to do the right thing. This also works fine on linux.

I changed it to typedef unsigned char indy_bool_t b/c I've heard bool may not be supported by all compilers. However, as far as I can tell, unsigned char will always be a 1 byte number, which is what rust emits.
This is working on linux and windows when I've tested.

@farskipper thank you for the this catch and the PR. After some additional investigation I decide to return back to your first proposal bool as it's supported on our target platforms and seems more accurate than char.


branch doesn't work

I'm wanting to pull release/live from a repo I have (via a webhook on Gogs). It works fine the first time, however, every request to the webhook after that causes a 400 error (and fails to pull on the server). This does not occur if I use the main branch develop, but occurs on every other branch.
Here is my config:
git {
    repo<EMAIL_ADDRESS>    path /var/lib/web/app/zyrbin
    hook /hooks/zyrbin/update-application {secret}
    interval -1
    branch release/live
    then /var/lib/web/build/zyrbin
}

@electricduck surround the branch name with double quotes. Probably the forward slash trips the parser. I've had similar problem with dot in the name, and I remembered somewhere in the docs a mention of the need to quote. Admittedly, the docs are sparse, but caddy is awesome 🥇


Solidity on-chain verification fails when gate counts are larger than a certain amount

Aim

We are trying to verify our zkp smart contract on-chain.
However, even though the proof verification passes using api.acirVerifyProof from bb.js, on-chain verification fails

Expected Behavior

On-chain verification should pass

Bug

Command and Error message
$  forge script script/Starter.s.sol:StarterScript --rpc-url http://<IP_ADDRESS>:8545 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 --broadcast -vvvv
$ pnpm ts-node --esm node-script/verifyProofOnChain.ts 0x8A791620dd6260079BF849Dc5567aDC3F2FdC318
VerifierContract: 0x8A791620dd6260079BF849Dc5567aDC3F2FdC318
env local
{
  walletPubKey: '0x70997970C51812dc3A010C7d01b50e0d17dc79C8',
  provider: 'http://<IP_ADDRESS>:8545'
}
Instantiating...
Generating inputs...
{ ccTobigint: 16978n }
{
  leaf: '9085282287955611025852103847033223553299672593909661339088018600613152307921',
  root: '4376485518484728565083006278613774608474257183702418234236934724788569188631',
  pathIndices: [
    1, 0, 1, 1,
    1, 0, 0, 0
  ],
  siblings: [
    '11752557305846564995419635702637388329824873040488976863271743293402468007613',
    '7163806489970069248027858684803666247509627789903524841019428770680611244236',
    '8052471871190071024590520090990652253996244381976695186225489824603455299324',
    '9973666284734535987847047307473694538192618488651454404613063129721244055711',
    '12553528803585799650198297445377912390680378736360090355845152159395343506690',
    '13845000498301242585584591222933663374902444583541563442470198430055666212205',
    '5319182605362636011959743237107249310133514183919241553434250327842425835405',
    '11483660179254614699774828842586182979768384209824455350234917632354184479553'
  ]
}
witness input 0:<PHONE_NUMBER>34793187224942827526618393967084608563228109339165368344744831975
witness input 1:<PHONE_NUMBER>9015107671233677668779070455496166783773065974896603868472984069880
witness input 2:<PHONE_NUMBER>472228899849180718373396797859415662732609545325465987213125464911
witness input 3: 18n
witness input 4:<PHONE_NUMBER>809013647717n
witness input 5: 20n
witness input 6: 16978n
witness input 7: 892745528n
witness input 8: 892745528n
witness input 9: 892745528n
witness input 10:<PHONE_NUMBER>955611025852103847033223553299672593909661339088018600613152307921
witness input 11:<PHONE_NUMBER>484728565083006278613774608474257183702418234236934724788569188631
witness input 12: 1
witness input 13: 0
witness input 14: 1
witness input 15: 1
witness input 16: 1
witness input 17: 0
witness input 18: 0
witness input 19: 0
witness input 20:<PHONE_NUMBER>5846564995419635702637388329824873040488976863271743293402468007613
witness input 21:<PHONE_NUMBER>970069248027858684803666247509627789903524841019428770680611244236
witness input 22:<PHONE_NUMBER>190071024590520090990652253996244381976695186225489824603455299324
witness input 23:<PHONE_NUMBER>734535987847047307473694538192618488651454404613063129721244055711
witness input 24:<PHONE_NUMBER>3585799650198297445377912390680378736360090355845152159395343506690
witness input 25:<PHONE_NUMBER>8301242585584591222933663374902444583541563442470198430055666212205
witness input 26:<PHONE_NUMBER>362636011959743237107249310133514183919241553434250327842425835405
witness input 27:<PHONE_NUMBER>9254614699774828842586182979768384209824455350234917632354184479553
witness inputs: Map(28) {
  1 => '0x01633e8a7f2af0b95ee3aeea580087d212b3fb03369a12e5e5a3abee35282be7',
  2 => '0x214cb4160d21ab6bc0b5cb32ebc46299a0a7d50e14798fce0b4417804b05e6f8',
  3 => '0x0e040047cfde7e20ac531992e783a730211841fa9a9dbd21397b40d419cbb34f',
  4 => '0x0000000000000000000000000000000000000000000000000000000000000012',
  5 => '0x00000000000000000000000000000000000000000000004368726973204e7965',
  6 => '0x0000000000000000000000000000000000000000000000000000000000000014',
  7 => '0x0000000000000000000000000000000000000000000000000000000000004252',
  8 => '0x0000000000000000000000000000000000000000000000000000000035363738',
  9 => '0x0000000000000000000000000000000000000000000000000000000035363738',
  10 => '0x0000000000000000000000000000000000000000000000000000000035363738',
  11 => '0x141616696ea25399e23bf7e53133a6fe97428ccb6bb87d0d99306dd2d0cc3ad1',
  12 => '0x09ad00c6091bc298a31ce5b4e974fb4775f76cf69e95d85d89bf39dcc9db2917',
  13 => '0x0000000000000000000000000000000000000000000000000000000000000001',
  14 => '0x0000000000000000000000000000000000000000000000000000000000000000',
  15 => '0x0000000000000000000000000000000000000000000000000000000000000001',
  16 => '0x0000000000000000000000000000000000000000000000000000000000000001',
  17 => '0x0000000000000000000000000000000000000000000000000000000000000001',
  18 => '0x0000000000000000000000000000000000000000000000000000000000000000',
  19 => '0x0000000000000000000000000000000000000000000000000000000000000000',
  20 => '0x0000000000000000000000000000000000000000000000000000000000000000',
  21 => '0x19fbb63273971f43bdb5d077ab53802df59f4691a1db6f318d192165123b3ebd',
  22 => '0x0fd6921ef30646134b1b38e669f329638bec4f54ba0c6b902174850877fb88cc',
  23 => '0x11cd899dedb5e2c0c8b94ba2a03d09c1ca0d095b92704928ef4bedc969571efc',
  24 => '0x160ce523484c16ef6e82813aaed8d7b001183e3280adfc701f80a2944679789f',
  25 => '0x1bc10ba682cbc11532b0de6ae83cc0e7ce190b7dcafc796a0c37957a0ba41d02',
  26 => '0x1e9bfe1a0bb2974094b9468f9ac3f1720d53c3f4ce098c7974893f0c6196dd6d',
  27 => '0x0bc28cf85d49bb9a07c222167213f126bac3d6a20ffe502ad0be9e0985568f8d',
  28 => '0x19638575b1657472b33a978250926154881216e1fc340d157043c7a330ba4341'
}
Generating proof...
Verify proof...
Verified: true
publicInputs 128
/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+logger@5.6.0/node_modules/@ethersproject/logger/src.ts/index.ts:261
        const error: any = new Error(message);
                           ^
Error: call revert exception [ See: https://links.ethers.org/v5-errors-CALL_EXCEPTION ] (method="verifyEqual(bytes,bytes32[])", data="0x0711fcec", errorArgs=null, errorName=null, errorSignature=null, reason=null, code=CALL_EXCEPTION, version=abi/5.6.4)
    at Logger.makeError (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+logger@5.6.0/node_modules/@ethersproject/logger/src.ts/index.ts:261:28)
    at Logger.throwError (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+logger@5.6.0/node_modules/@ethersproject/logger/src.ts/index.ts:273:20)
    at Interface.decodeFunctionResult (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+abi@5.6.4/node_modules/@ethersproject/abi/src.ts/interface.ts:427:23)
    at Contract.<anonymous> (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+contracts@5.6.2/node_modules/@ethersproject/contracts/src.ts/index.ts:400:44)
    at step (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+contracts@5.6.2/node_modules/@ethersproject/contracts/lib/index.js:48:23)
    at Object.next (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+contracts@5.6.2/node_modules/@ethersproject/contracts/lib/index.js:29:53)
    at fulfilled (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@ethersproject+contracts@5.6.2/node_modules/@ethersproject/contracts/lib/index.js:20:58)
    at processTicksAndRejections (node:internal/process/task_queues:95:5) {
  reason: null,
  code: 'CALL_EXCEPTION',
  method: 'verifyEqual(bytes,bytes32[])',
  data: '0x0711fcec',
  errorArgs: null,
  errorName: null,
  errorSignature: null,
  address: '0x8A791620dd6260079BF849Dc5567aDC3F2FdC318',
  args: [
    Uint8Array(2144) [
       21,  18, 211, 172,  81, 102, 202, 107,  72,  83,  16,  32,
      144,  14, 178,  17,  77,  78,  85, 141,  74,  16,  42,  36,
      179, 111,  37, 141, 105, 160,  65,  84,  48,  11, 195, 140,
       78,   4, 192,  59, 140,  23,  71, 140, 245,  30, 103,  36,
       47,  65, 133,  97, 159, 250, 176, 166,  68, 112,  61,  86,
       56, 188,  36, 137,   2, 117, 214, 217,  92, 148, 249,  92,
      129, 112,  25, 167, 100, 108, 175,  61,  43,  57,  64,  21,
       81, 199, 241,   8, 191, 162, 226,  46, 206, 227,  87, 254,
       45,  59, 153, 207,
      ... 2044 more items
    ],
    [ [Uint8Array], [Uint8Array], [Uint8Array], [Uint8Array] ]
  ],
  transaction: {
    data: '[encoded data, 4810 characters]',
    to: '0x8A791620dd6260079BF849Dc5567aDC3F2FdC318',
    from: '0x70997970C51812dc3A010C7d01b50e0d17dc79C8'
  }
}

To Reproduce
You can find the reproducible code in https://github.com/tomoima525/noir-starter/pull/1
Installation Method
Binary
Nargo Version
nargo 0.9.0 (git version hash: 3d1b2522c8d9a0acebff102f9f877c44178c5db5, is dirty: false)
Additional Context
I see that when the number of gates hits a certain amount, on-chain(Solidity) verification fails
We have three assertions in the circuit.

Poseidon hash assertion
age range assertion
merkle root assertion

I tested the patterns below and found that on-chain verification fails when everything is checked at once

Assertion 1 & 2 => Succeeds
Assertion 3 only => Succeeds
Assertion 1 & 2 & 3 => Fails

This is the number of gates in each assertion.
1. Poseidon hash  assertion
[main] Total ACIR opcodes generated for language PLONKCSat { width: 3 }: 7232
[main] Backend circuit size: 7225

2. age range assertion
[main] Total ACIR opcodes generated for language PLONKCSat { width: 3 }: 19
[main] Backend circuit size: 2776

3. merkle root assertion
[main] Total ACIR opcodes generated for language PLONKCSat { width: 3 }: 19329
[main] Backend circuit size: 19316

Total
[main] Total ACIR opcodes generated for language PLONKCSat { width: 3 }: 26570
[main] Backend circuit size: 29315

Would you like to submit a PR for this Issue?
No
Support Needs
Just pinging @critesjosh as we've been discussing this issue

Installing the latest nightly generates a new, different Solidity verifier contract for the same noir program. in order to verify the same program, I have to generate a new proof using this version (proofs generated with the stable 0.9.0 release dont work).
additionally, it seems like this new verifier contract is not compatible with proofs generated with the latest version of bb.js (0.3.6). Hopefully resolving this will fix the issue

Updated the solidity file with Noir 0.10.3 but the result was the same

Assertion 1 & 2 => Succeeds
Assertion 3 only => Succeeds
Assertion 1 & 2 & 3 => Fails

I tested other patterns.
Assertion 1 & 3 => Fails
Assertion 2 & 3 => Fails
So when the merkle root check is combined with other assertions, it fails... 🤔

Some interesting experiments:
I changed my noir circuit a bit and saw how many circuit sizes could cause this issue.
Experiment 1: Assertion 1 * 3 = 7225 * 3 = 21675 circuit size
Result: PASS (Solidity works)
Experiment 2: Assersion 1 * 3 + Custom assertion = 7225 * 3 + 361 = 22036 circuit size

Custom assertion

    for i in 0..90 {
    assert(age == 18);
    }

Result: PASS
Experiment 3: Assertion 2 + Assertion 3 = 22092 circuit size
Result: FAIL
Experiment 4: Assertion 1 * 3 + Assertion 2  = 7225 *  3 + 2776 = 24451 circuit size
Result: FAIL
Result
If the circuit size passes the value between 22036 and 22092 Solidity file starts to fail.

did you try any circuits above 22092 with different logic? or just modifications of your circuit?

Just modifications

After modifying the web component, I was able to get a circuit of size 65413 verified on chain. The verification using bb.js is what is failing in the error i describe above.
So I don't think the size is what is causing your circuit verification to fail on-chain. Here is the code that is working for me.

@Savio-Sou do you know if this issue being tracked elsewhere?

This is the best tracking issue atm afaik.

The verification using bb.js is what is failing in the error i describe above.

Not sure if I follow if this is a Solidity verifier bug or a bb.js verification bug, but either way that means this is more likely a barretenberg problem.
@critesjosh would you like to start an Issue on https://github.com/AztecProtocol/aztec-packages/issues with your latest findings (cc @rahul-kothari).
If it turns out to be Solidity verifier specific, we can also source help from @LHerskind.

Solidity verifier is working fine, its just bb.js.
I created an issue here https://github.com/AztecProtocol/aztec-packages/issues/1845

Thanks for the update @critesjosh !
I tried the above circuit on ts-node using https://github.com/tomoima525/noir-starter/pull/1 but it failed with the same error. Do you know any difference between the ts-node version and the browser version? I think it's okay as long as it works on the browser but the inconsistency between platforms can become a big issue later on

Here is the code that is working for me.

Also I wonder how the circuit worked as it doesn't provide public inputs in the circuit, but in this code, you provided the first 32bits of the public inputs which I believe should fail?

Let's hope that bb.js update will resolve the issue with my original circuit 🙏

Hello @tomoima525 I stumbled on a very similar issue, I also thought at first that this was caused by bb.js but I am not sure anymore. I noticed that the verifier smart contract code (for a same fixed circuit) changed between nargo 0.10.3 and nargo 0.10.5 and unexpectedly, as I thought this was a problem in bb.js, upgrading to nargo 0.10.5 solved this very same issue. See similar issue

I noticed that the verifier smart contract code (for a same fixed circuit) changed between nargo 0.10.3 and nargo 0.10.5

Do you have the verifier code lying around for this, I don't think much should have changed on those in months so would be interested in seeing the diff if other than just vk.

I noticed that the verifier smart contract code (for a same fixed circuit) changed between nargo 0.10.3 and nargo 0.10.5

Do you have the verifier code lying around for this, I don't think much should have changed on those in months so would be interested in seeing the diff if other than just vk.

I just pushed it on a new branch here : https://github.com/jat9292/bbjs-bug-minimal-example/tree/compare-nargo-10-3-vs-10-5/contract/bbjs you can see both versions, one generated via nargo 0.10.3 and the other with nargo 0.10.5

I just pushed it on a new branch here

Ah cool. Its only the vk differing (which is based on the circuit and output from bb), so with the same circuit if that one is different that is due to noir compiler updates or bb, so makes sense if the issue came from bb.js

@jat9292 this is awesome!
I updated Noir 0.10.5 then I see this error when calling api.acirGetCircuitSizes from barretenberg API (0.3.6). Did you change bb.js or any other related library version?
file:///Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@aztec+bb.js@0.3.6/node_modules/@aztec/bb.js/dest/node/barretenberg_wasm/barretenberg_wasm.js:169
            return this.exports()[name](...args) >>> 0;
                                       ^
Error [RuntimeError]: unreachable
    at abort (wasm://wasm/02646f1a:wasm-function[11571]:0x422819)
    at throw_or_abort(std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>> const&) (wasm://wasm/02646f1a:wasm-function[94]:0x380e6)
    at Circuit::Circuit::bincodeDeserialize(std::__2::vector<unsigned char, std::__2::allocator<unsigned char>>) (wasm://wasm/02646f1a:wasm-function[2213]:0x12774b)
    at acir_format::circuit_buf_to_acir_format(std::__2::vector<unsigned char, std::__2::allocator<unsigned char>> const&) (wasm://wasm/02646f1a:wasm-function[2212]:0x12746a)
    at acir_get_circuit_sizes (wasm://wasm/02646f1a:wasm-function[2251]:0x12835f)
    at BarretenbergWasm.call (file:///Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@aztec+bb.js@0.3.6/node_modules/@aztec/bb.js/dest/node/barretenberg_wasm/barretenberg_wasm.js:169:40)
    at callback (/Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/comlink@4.4.1/node_modules/comlink/dist/umd/comlink.js:109:52)
    at MessagePort.l (file:///Users/tomoima525/workspace/zkp/noir-starter/with-foundry/node_modules/.pnpm/@aztec+bb.js@0.3.6/node_modules/@aztec/bb.js/dest/node/barretenberg_wasm/node/node_endpoint.js:11:21)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:737:20)
    at exports.emitMessage (node:internal/per_context/messageport:23:28)

I am able to use acirGetCircuitSizes without any issue for my circuits :  https://github.com/jat9292/Private-token/blob/main/utils/proof_utils.js#L33
I am using @aztec/bb.js 0.3.6
and<EMAIL_ADDRESS>, as per documentation
Btw here is my most complex circuit : https://github.com/jat9292/Private-token/blob/main/circuits/transfer/src/main.nr
I noticed it had 24 (Gaffine=2 Fields) inputs among which 20 are public, while yours had a total of 28 inputs but only 4 of which were public, so I do not now if this explains some added complexity which could explain the bug (?)

Was able to resolve import issue by adding @ts-ignore

And successfully verify the contract onchain with 0.10.5
Referencing the update https://github.com/knot-inc/noxx-contract/pull/40#issuecomment-1710512956


04/08/2018 20:59 : Create Pull Request for branch master -> prTesting1_2018040820

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef1.md
:white_check_mark:Succeeded

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


chore(travis): cache node_modules for faster build times

Coverage remained the same at 100.0% when pulling 89a02cc5a3ad8ff16b5b4fe96a21a920700b9433 on prtksxna:patch-3 into 9aad5d300b786bad7396659fe45de20ae23086df on decisively:master.


nested column select and distinct return empty array

@Timu57  @rakibtg  @robkellas  @daussho
Hi SleekDB Team,
I am trying to retrieve data from a 2-dimensional array
data array in json file :
"cquantCli": [
{
"cprcCli": "47",
"camo": "48",
"ctyp": "1",
"cdsc": "49"
},
{
"cprcCli": "50",
"camo": "51",
"ctyp": "2",
"cdsc": "52"
}
]
my query :           ->select(["cli" => "cquantCli.cprcCli"])
I am expecting :
[["_id" => 1, "cli" => 47], ["_id" => 2, "cli" => 50]]
it returns ;
Array
(
[0] => Array
(
[_id] => 1
[cli] =>
)
)
The same goes for distinct function, does not work for nested query
help please,
kindest regards

Hi @REDAL
your query is wrong for your data-structure. Like we discussed in discord you can use custom select functions to query the cquantCli array.
I will close this issue for now, feel free to reopen it if needed :blush:

@REDAL I know, I just repeated the solution/answer here for people having a similar problem :)


Define a derivative for 'padded(forSizes:with:)'.

A custom derivative should be defined for API padded(forSizes:with:).

Added PR https://github.com/tensorflow/swift-apis/pull/184

@Dash2507, you can link it in your pr. By adding Fix #179, in your PR message.


Do not limit user->username length to 25 chars

A project i have done needed registration by email only,
so i have written every email into the username field.
This worked well, but the username field looks ugly with
all the emails truncated after char 25
I do not see the sense in limiting the username length.
Some people use longer usernames, and modern applications
should display them properly. Please consider to remote
the username character length limit.

There is a conflict. Please fix it and add a line into the CHANGELOG which describes the change. And then I'll merge.

I rebased the commit and added the CHANGELOG line.

Thank you!


Help needed: Increment counter specified times

Hi,
I want to know how can I increase a counter with a specified value. For example if I need to increase the counter by 300, I can do
for(int i=0;i<300;i++)
            statsDClient.increment("pushed.from.inventory")

but is it possible to do without a loop?
Thanks

Hi @pvpkiran,
actually the feature you need is quite easy to implement, I'll add it to my queue.
If you want to give it a shot in the meantime and submit a  PR, contributions are more than welcome!

Can you not just use
public void count(final String aspect, final long delta, final String... tags)
Or is a convenience method required?

Hi,
This is what I am using right now
count("prefix", count).
I don't think a convenience method is necessary.
Cheers

Good to know that works for you! Closing this then.


Azure CNI Mode

It is a bit difficult to understand explanations related to Azure CNI Mode. Could you please check the following?
https://docs.microsoft.com/en-us/azure/aks/faq#what-is-azure-cni-transparent-mode-vs-bridge-mode

IP addresses and ranges used in diagrams and explanatory texts are different. A bit confused. Is this what you intended?
I think a sentence "the second one saying "10.20.x.x" Pod space to kernel for kernel to decide" needs more explanation. Especially, "10.20.x.x" should be clarified.

Thanks!

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

ID: d501ff67-9208-8bcb-e8df-f09e9b16a802
Version Independent ID: e3fc3851-ddc4-d26c-251d-6ae53d714081
Content: Frequently asked questions for Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/faq.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

@ToruMakabe Thanks for the feedback! We are currently investigating and will update you shortly.

@ToruMakabe Thanks for the feedback! We are currently investigating and will update you shortly.

@ToruMakabe Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate. We will update you accordingly.

@ToruMakabe Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate. We will update you accordingly.

@mlearned Can you please check and add your comments on this doc update request as applicable

@mlearned Can you please check and add your comments on this doc update request as applicable

Thank you for the feedback.
We've added a task to our backlog and will prioritize accordingly.
#please-close

#please-open
#reassign:schaffererin

Hi, @torumakabe, thank you for the feedback. I apologize for the delay in responding. Since this issue was raised, the docs have been updated. Bridge mode is replaced by Transparent mode, and the doc goes into further detail about the different modes. Since no doc edits need to be made at this time, I will close this GitHub issue. Thank you again! #please-close


[wip] fix some issues with the e2e run at deploy time

@JackQuincy these are based on the errors seen here.
In addition, the parameter defaulting in .pipelines/templates/template-job-deploy-azure-env.yml doesn't seem like a great idea.
We also need to set the e2e-subscription parameters on our pipelines, but I'm not actually sure what the values of these should be.  Please could you help?

I set the e2e subscription on INT and Prod pipelines.  I added a Variable group we can link to future jobs.
Agreed just letting RP_MODE default was not the correct way to do this.  I can change template-job-deploy-azure-env.yml to accept an rpMode parameter unless you want to do it here.

merging for now, there may be more changes later


Flutter for linux build fail

A linux build of any flutter application with linux enabled, results in the following error:
*flutter run -d linux

logs
Launching lib/main.dart on Linux in debug mode...
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crt1.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crt1.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crt1.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crti.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crti.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/crtbegin.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/crtbegin.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgcc_s.so.1: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgcc_s.so.1: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgcc_s.so.1: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgcc_s.so.1: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/crtend.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/crtend.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crtn.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/crtn.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: //usr/lib32/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
/snap/flutter/current/usr/bin/ld: warning: //usr/lib32/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: //usr/lib32/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: //lib64/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
/snap/flutter/current/usr/bin/ld: warning: //lib64/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: //lib64/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: //usr/lib32/libgcrypt.so.20: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: //usr/lib32/libgcrypt.so.20: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
/snap/flutter/current/usr/bin/ld: warning: //lib64/libgcrypt.so.20: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
/snap/flutter/current/usr/bin/ld: warning: //lib64/libgcrypt.so.20: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Building Linux application...
Exception: Build process failed*

My flutter doctor:
flutter doctor -v

flutter doctor -v
[✓] Flutter (Channel stable, 2.0.1, on Linux, locale en_US.UTF-8)
    • Flutter version 2.0.1 at /home/vtr/snap/flutter/common/flutter
    • Framework revision c5a4b4029c (9 days ago), 2021-03-04 09:47:48 -0800
    • Engine revision 40441def69
    • Dart version 2.12.0

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/vtr/Android/Sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /snap/android-studio/current/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • CHROME_EXECUTABLE = /usr/bin/google-chrome-stable

[✓] Linux toolchain - develop for Linux desktop
    • clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
    • cmake version 3.10.2
    • ninja version 1.8.2
    • pkg-config version 0.29.1

[✓] Android Studio
    • Android Studio at /snap/android-studio/current/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /snap/android-studio/current/android-studio
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] Connected device (3 available)
    • Note 7P (mobile) •   • android-arm64  • Android 9 (API 28)
    • Linux (desktop)  • linux           • linux-x64      • Linux
    • Chrome (web)     • chrome          • web-javascript • Google Chrome 89.0.4389.72

• No issues found!

System info
System:    Kernel: 5.9.16-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.1 Desktop: KDE Plasma 5.21.2 Distro: Manjaro Linux
The error manifested upon upgrade of flutter to version 2.0.0
previous versions worked perfectly

Tried to use it on manjaro an got this error too, on stable branch and on dev branch as well

Hi @romater0  @WeslleyNasRocha
This has been fixed, please upgrade your Flutter snap to latest master https://github.com/canonical/flutter-snap/issues/32
Closing as fixed
Thank you

Thank you @TahaTesser I'ts working now

I'm getting this issue on ubuntu 21.10 I installed snap and switched to stable but still get the same error.
/snap/flutter/current/usr/bin/ld: warning: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
/snap/flutter/current/usr/bin/ld: warning: //lib/x86_64-linux-gnu/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002

same error when I try the dev channel


The simulation results are inconsistent with the paper

[error.pdf] (https://github.com/akseljohan/Otter-USV-Target-Tracking-Controllers/files/13944681/error.pdf)
Excuse me，The error in the simulation results of the MPC control method is close to 10，has the code been modified.

Hello, the NMPC performance depends on several factors such as values in the Q and R matrix, initial starting position and velocities of the the USV and the target. However, if you use the config and initial config that is documented in the result folder, then you should get similar results.

Hello, the NMPC performance depends on several factors such as values in the Q and R matrix, initial starting position and velocities of the the USV and the target. However, if you use the config and initial config that is documented in the result folder, then you should get similar results.
The problem has been resolved，thanks！


Locator builder produces incorrect value for "locate().withText().inside()"

What are you trying to achieve?
locate(".ps-menu-button").withText("Authoring").inside(".ps-submenu-root:nth-child(3)") is translated to XPath that matches an element on page

3.5.8: //*[contains(concat(' ', normalize-space(./@class), ' '), ' ps-menu-button ')][contains(., 'Authoring')][ancestor::*[(contains(concat(' ', normalize-space(./@class), ' '), ' ps-submenu-root ') and count(preceding-sibling::*) = 2)]] works :heavy_check_mark:

What do you get instead?

3.5.10/3.5.11: //*[contains(@class, "ps-menu-button")][contains(., 'Authoring')][ancestor::*[3][contains(@class, "ps-submenu-root")]] doesn't work (neither in test nor in web browser inspector) :lady_beetle:
3.5.12: //*[@class and contains(concat(' ', normalize-space(@class), ' '), ' ps-menu-button ')][contains(., 'Authoring')][ancestor::*[@class and contains(concat(' ', normalize-space(@class), ' '), ' ps-submenu-root ') and (position() = 3)]] doesn't work (neither in test nor in web browser inspector) :lady_beetle:

The fix https://github.com/codeceptjs/CodeceptJS/pull/4101 didn't help

Details

CodeceptJS version: 3.5.12
NodeJS Version: v18.15.0
Operating System: Ubuntu 22.04

@kobenguyent The scenario in the test passes (and the result works in web inspector), but I guess because the test HTML data is "too simple".
A a workaround for our test case:

if we use (A): locate(".ps-submenu-root:nth-child(3)").find(".ps-menu-button").withText("Authoring")
instead of (B): locate(".ps-menu-button").withText("Authoring").inside(".ps-submenu-root:nth-child(3)")

then the element matches as expected

(A) is translated to //*[@class and contains(concat(' ', normalize-space(@class), ' '), ' ps-submenu-root ') and (position() = 3)]//*[@class and contains(concat(' ', normalize-space(@class), ' '), ' ps-menu-button ')][contains(., 'Authoring')], it works :heavy_check_mark:
(B) is translated to //*[@class and contains(concat(' ', normalize-space(@class), ' '), ' ps-menu-button ')][contains(., 'Authoring')][ancestor::*[@class and contains(concat(' ', normalize-space(@class), ' '), ' ps-submenu-root ') and (position() = 3)]], it doesn't work :lady_beetle:

It seems that adding of ':nth-child' into the array https://github.com/codeceptjs/CodeceptJS/blob/af3f7578c685dad59f5e74bbc76ee40e6c5b49c9/lib/locator.js#L166
fixes our issue. Then an old conversion way over css-to-xpath is used.


ownCloud Community to Enterprise Migration

How to migrate the community installed version to enterprise ?

This is the bugtracker for the ownCloud community website. For information on the enterprise version, please contact your support/presales representative, who will be happy to help you.

I contacted the sales by email but no response for almost two months.
it's very weird

@akkezi that is weird and should not happen, indeed. Can you shoot me an email on jos @ owncloud com??


Changes to allow for readOnly property in swagger 2

Changes added to process @ApiModelProperty(readonly=true).
Altered model tests, and propery spec test to ensure new flag was set correctly.

Everything looks good! thanks for the PR! However, Im curious how this did not affect any of the contract tests :confused:

Do you have a preference for what model gets changed in the contract tests?  Or shall i just add a new variable to one of the classes?

Without changing any models, based on the pr I'd expect model properties to have readOnly properties to all be defaulted to false and consequently show up in the contract tests (for swagger2) as false. Wondering why that's not the case.
Regarding which model to add the behavior, any models in the feature demonstration service would be perfect.

Ah I see.  I assumed that this was why the required flag was Boolean not boolean and that some magic was happening, but I did not investigate further.
I'll add a new instance variable to the Example class and change the tests.

I think the fact that you made it a Boolean  is perfect we don't want to change that. Probably use the Optional.fromNullable().orNull()  pattern instead of Optional.fromNullable().or(false)

Having said that, the logic for the required flag is probably not right too :) i can fix that


[DNM] Add missing etcd operator config

What this PR does / why we need it:
These changes add the missing etcd operator config (see https://github.ibm.com/alchemy-containers/armada-update/issues/5529) which fixes the [ocp-conformance][test failure] The server doesn't have a resource type "etcds" OCP conformance test in ROKS v4.15.  A similar change was done for the ibm-roks-toolkit for ROKS v4.14 https://github.com/openshift/ibm-roks-toolkit/pull/884/files.  These changes, however, should only be cherry-picked to ROKS v4.15.
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[x] Subject and description added to both, commit and PR.
[x] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/ok-to-test

/retest

@sjenning this looks like a bug in the conformance suite.  there is no reason this should be required when hosted.

/hold per https://github.com/openshift/hypershift/pull/3807#issuecomment-2037349996
@derekwaynecarr thanks for letting us know.  @Evan-Reilly let's discuss.

Conformance test is [sig-cli] oc explain should contain proper spec+status for CRDs [Suite:openshift/conformance/parallel]

@sjenning @derekwaynecarr Is there an update on the status of this? When could we expect an update to the conformance suite?

/label do-not-merge/work-in-progress

/retitle WIP: Add missing etcd operator config

@sjenning @derekwaynecarr do you have any updates to share?

@rtheis @Evan-Reilly The fix needs to go into the conformance test suite. Basically change this function to omit the etcds resource when the cluster is HyperShift. Can you submit a PR for that?
I am closing this PR, since the change doesn't belong here.
/close

@csrwng yes, we can handle that.

@csrwng @rtheis https://github.com/openshift/origin/pull/29114


Allowing howdoi users to pass clear cache query while passing query

when users run python -m howdoi.howdoi -C how do I print helloworld in python, howdoi would return Cache cleared successfully and therefore ignoring the query.
This PR fixes that.

Wouldn't the query already be ignored before if -C was specified? There's a return here.
https://github.com/gleitz/howdoi/blob/ca40c67dc817cb1858304846750e4b98e2bbd69a/howdoi/howdoi.py#L627-L632

@csr I am refactoring that right now.


Publish Winget to winget-pkgs

It would be cool, so we could do winget upgrade winget. I'm creating this issue in this repo because a CI/CD integration would be desirable, so every new version would end up in the winget-pkgs.

https://github.com/microsoft/winget-pkgs/pull/332

Oh sorry, while my issue talks specifically about automatic creation of manifests for winget using wingetcreate, it would probably be covered by https://github.com/microsoft/winget-cli/issues/505 and https://github.com/microsoft/winget-pkgs/pull/332.

@felipecrs no worries. As soon as we have the code changes in the client to allow the client to "upgrade" itself, we will use wingetcreate to publish our own manifests. We also need to get "channels" support done correctly as well. Only one instance of "App Installer" can be on a machine at a time, so we need to be able to separate the "DEV" channel from the "stable" channel somehow.


Update virtual-machines-windows-ps-common-ref.md

Fixed typos.

Hi @alexandair, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, AZPRBOT;

@alexandair: Thank you for your feedback. I agree with the correction of the casing in PowerShell, but not with the casing change of fromImage. I would like to stay consistent with the cmdlet help, which states "[-CreateOption] {empty | attach | fromImage}". Can you revert that part of the commit and we can go ahead and merge the PowerShell change?

@davidmu1 My help says "FromImage". Also, what do you get for IntelliSense in PowerShell ISE? I get "FromImage". The same if I do Set-AzureRmVMOSDisk -CreateOption . What version of Azure PowerShell do you use?

@alexandair: I am running the latest version. It works no matter which is case is used. @tysonn: please go ahead and merge the change, the PowerShell cmdlet help is not consistent, so it won't hurt to publish the change.


Adding MEAN.JS version information as part of the startup info when app loads

I've been thinking it would be great if we can display the project version number when the app starts as that will easily allow other devs and users to clearly see which MEAN.JS release they are on.
We often get a lot of bug requests and this is usually the first version that comes up...

WDYT?

:+1:

@lirantal What if someone changed the version in package.json to match their project's version? Why not have a meanjs-version attribute in package.json? That would also make things easier to managing versions in the generator and sub generators. I already have this in the proposed PR for the generator:
https://github.com/codydaig/generator-meanjs/blob/dev/0.2/app/templates/master/_package.json#L5
"meanjs-version": "0.4.0",

Sure, that's even better.
In which-case we can include both versions maybe (app and mean.js). WDYT?

SGTM

SGTM too! I like the idea of having both attributes displayed.

Great, I updated

Fixed typo

LGTM.
Side note: you may want to set coveralls to allow a certain percentage of decrease because it's failing you right now.

@lirantal is this going to be part of 0.4.2?

@ilanbiala part of the next release so I guess 0.4.2. Why, is that an issue?

@codydaig  I see it but it's not a real error, it's just letting you know that coverage decreased (in this case in 0.08%), it didn't fail the build (tests) and it didn't dramatically reduce code coverage (it's a known issue that we don't yet have tests for core stuff outside of the users/articles modules)

@lirantal just want to make sure it's in the right milestone for when we finalize the release and check the milestone for open issues.

I updated it...

This LGTM

LGTM

Great, thanks.


Send Button not visible next to message input field

I have implemented JSQMessagesviewcontroller with the help of NotificationChat from RelatedCode. In my chatview however, only the message input textfield is displayed in the toolbar. The send button is not there!
Any thoughts?

Thanks @Addadahine ! :smile:
Please update the issue after looking at the contribution guidelines. :smile:
If this issue is from using the RelatedCode/NotificationChat fork, I can't really help unless you can reproduce this in the demo project here. You should probably open an issue with RelatedCode/NotificationChat.

Hi Jesse,
Thank you for getting back to me, I have been in touch with RelatedCode and they say I should raise the issue with you.
Any chance you could spare a few minutes to help me with this?
Kind regards,
Sam Addadahine | +44 7852 339 267
Treasurer, Kingston Entrepreneurs
International Business with Law, Kingston Business School
Linkedin

On 20 Aug 2015, at 02:18, Jesse Squires<EMAIL_ADDRESS>wrote:
Thanks @Addadahine https://github.com/Addadahine !
Please update the issue after looking at the contribution guidelines https://github.com/jessesquires/JSQMessagesViewController/blob/develop/CONTRIBUTING.md.
If this issue is from using the RelatedCode/NotificationChat fork, I can't really help unless you can reproduce this in the demo project here. You should probably open an issue with RelatedCode/NotificationChat.
—
Reply to this email directly or view it on GitHub https://github.com/jessesquires/JSQMessagesViewController/issues/1170#issuecomment-132843424.


chore(deps): update dependency org.hsqldb:hsqldb to v2.5.0

This PR contains the following updates:

Package
Update
Change
References

org.hsqldb:hsqldb
minor
2.4.1 -> 2.5.0
homepage, source

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR is stale, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

The upgrade causes some portlets to error.


heroku: 3.43.16 -> 6.6.14

Motivation for this change
This version of the CLI is no longer deprecated and uses pure nodejs.
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Doesn't yarn install need to access the internet to download dependencies?

Yes I think so, didn't realize that isn't allowed. So yarn install isn't kosher?

(I tried npm2nix but it doesn't seem to work with Node 7 yet...)

@shosti take a look at node2nix. You probably can add your package to ./pkgs/development/node-packages

node2nix doesn't currently work for this because heroku has a hard dependency on node 7, and node2nix only makes nix files for node <= 6. Maybe this should wait until node2nix gets updated?

@shosti It looks like there has recently been some commits on node2nix that give it a -7 flag which I assume allows node 7 packages. Worth a shot?

If somebody is in hurry and needs heroku quickly:
# bashrc/zshrc
heroku(){
  docker run -it --rm -u $(id -u):$(id -g) -w "$HOME" \
    -v /etc/passwd:/etc/passwd:ro \
    -v /etc/group:/etc/group:ro \
    -v /etc/localtime:/etc/localtime:ro \
    -v /home:/home \
    -v /tmp:/tmp \
    -v /run/user/$(id -u):/run/user/$(id -u) \
    --name heroku \
    johnnagro/heroku-toolbelt "$@"
}

@Mic92 Thank you very much for your addition! I found that it couldn't interact with the local directory such as is necessary when running create and the like, so I added two extra lines to fix this:
           -v $(pwd):/workdir \
           -w /workdir \

@shosti bump? It sounds like the node2nix issue isn't blocking since your PR adding node 7 support was merged in. Do you know if there are any other blocking issues?

The current heroku package is marked borken. Is this the only PR that makes heroku work again?

@CMCDragonkai i think we need to package this with node2nix.

Yeah sorry I haven’t had time to get this working. node2nix seems to get the dependencies ok, but I haven’t figured out how to get the binaries wrapped properly. If someone wants to take this over that would be awesome.

I've opened https://github.com/NixOS/nixpkgs/pull/42869 as the next attempt at fixing this, I'm going to close this issue as it's outdated.


[FLINK-21110] Optimize scheduler performance for large-scale jobs

What is the purpose of the change
This PR introduces several optimizations on scheduler performance for running large-scale jobs. The optimizations are involved with the following procedures:

Building topology when initializing ExecutionGraph
Building DefaultExecutionTopology
Initializing PipelinedRegionSchedulingStrategy
Scheduling downstream tasks when a task finishes
Calculating tasks to restart when a failover occurs
Releasing result partitions

The main idea is to put all the vertices that consumed the same result partitions into one group, and put all the result partitions that have the same consumer vertices into one consumer group.
For more details please check FLINK-21110.
Brief change log

Introduced EdgeManager, ConsumerVertexGroup and ConsumedPartitionGroup to store the topology in ExecutionGraph
Introduced several optimizations on the procedures we mentioned above based on EdgeManager
Removed ExecutionEdge and fixed related tests

Verifying this change
Since these optimizations do not change the original logic of the target procedures, we believe that this change is already covered by existing tests, such as ExecutionVertexDeploymentTest, DefaultExecutionTopologyTest, PipelinedRegionSchedulingStrategyTest, and etc.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

After discussing with @zhuzhurk, I'm going to break this PR into several sub pull requests.