Failed to update CACERTS when readOnlyRootFilesystem is set

Expected Behavior
At startup it should create the new cacert in different folder (like tmp) that can be mounted with write rights
Current Behavior
Currently it try to modify it in place
WARNING: Unable to add container CA certificates to JVM because /layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts is read-only
Possible Solution

Steps to Reproduce

Run a builded container with readOnlyRootFilesystem set to true

Motivations

It's mandatory to use readOnlyRootFilesystem in our env

hello,
There are 2 ways to add a ca cert to the JVM truststore: either at runtime (what you're describing) or build time.
Have you considered adding your ca cert during buildtime ?
pack build demo:1.0.0-SNAPSHOT \
  --env SERVICE_BINDING_ROOT=/platform/bindings \
  --env BP_JVM_VERSION=17 \
  --volume $PWD/binding/ca-certificates/:/platform/bindings/my-certificates \
  --builder=paketobuildpacks/builder:base

with $PWD/binding/ca-certificates/ looking like: https://github.com/anthonydahanne/java-applications-containerized/tree/master/c-buildpacks/binding/ca-certificates ?
You'll see during the build:
Paketo Buildpack for CA Certificates 3.5.1
  https://github.com/paketo-buildpacks/ca-certificates
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
  CA Certificates: Contributing to layer
    Added 1 additional CA certificate(s) to system truststore
    Writing env.build/SSL_CERT_DIR.append
    Writing env.build/SSL_CERT_DIR.delim
    Writing env.build/SSL_CERT_FILE.default

Hello @anthonydahanne
but this will not add it to the jvm trustore but only to the system one.
At startup the jvm one is updated based on the system one. this one fail.
And in any case that would imply having 1 image per env, (as the CA is different in DEV/PROD)
Regards

Presently, the certificate loader will read and then write back to the same location.
I think we should look at modifying this so that the certificate loader can write to an alternative location. Then we could modify the helper to check if it's running in a read-only filesystem and write to /tmp instead. It would then need to set -Djavax.net.ssl.trustStore=/tmp/<modified-truststore>.
I'm not 100% fixed on that workflow though. If it's easier to have certificate loader check for a read-only filesystem that would work too. Also, by check for a read-only filesystem I really just mean check if it can write to the truststore location or possibly just attempt to and handle the error by falling back to writing to /tmp.

We are facing the same issue in our environment. All our pods must be configured with readOnlyRootFilesystem and we have custom CAs. They are added to the system store during build time but cannot be copied to the trust store during runtime.
We can mount an emptyDir volume to pods during runtime. If it would be possible to configure the location of the modified trustStore file we could copy it to the emptyDir volumes location.
Would be great if -Djavax.net.ssl.trustStore=/tmp/<modified-truststore> is set automatically, but maybe it would be possible to specify it in the JAVA_TOOL_OPTIONS.

I think there are two ways we could support this:

Add an option similar to ca-certificates' BP_EMBED_CERTS. If this is set, then we would update the JVM's truststore at build time and that would be included in the image itself.

We can modify the certificate loader to an alternative location. Then we could modify the helper to check if it's running in a read-only filesystem and write to /tmp/<random-file> instead. It would then need to set -Djavax.net.ssl.trustStore=/tmp/<random-file>. We should also do a check to see if any certs actually need to be added at runtime and skip if it's not actually changing, that way you only need to have writable /tmp if you need to do this at runtime.

I found the option 2 more useful.


Filter (splitted) input by regex

A few days ago I wanted to filter some lines based on a regex but I struggled to do so.
My solution in the end was:
1) Split input by newline
    2) Conditional jump by one if input line matches regex
    3) Replace everything with empty
4) Merge
5) Replace two (or more) consecutive newlines with a single newline

Either I really suck at using this tool missed some easier way to do this, or this is quite complicated.
Anyway I hacked myself a "filter by regex" operation together:

Greets
~ Mike

A very good contribution, thank you very much.
Merry Christmas!


Sonar widget is frozen in the loading status if there is no link added to the sonar

STR:
Delete the Link to the sonar in the Configurations Links tab
Create a new Component with a sonar stage
Run build pipeline
Open component with sonar widget
AR: Sonar widget is frozen in the loading status
ER: Widget should be displayed
We need to enable two fields (instead of URL) for endpoints in integration section:
External URL (mandatory field)
Internal URL (optional field)
Add description that internal url can be used in case if component deployed inside cluster;
external url - endpoint for widgets;
If user define external url - create EDP Component;


Get PKCE Auth URL error: java.lang.ClassNotFoundException: com.immutable.unity.ImmutableActivity$Callback

Using 2021.3.33 on Player Settings => Minifi => use R8 and Release if i check these two i am getting this error on ConnectImxPKCE or LoginPKCE on Android device unchecking these two and every thing works fine.  Our documentation is updated with instructions here. You can also take a look at the sample Proguard file as an example.
If everything works, please close this issue.

Hey @nattb8 thank you for the prompt response, its now working fine


antimicro 2.3 -> antimicroX 3.0

Antimicro is broken an no longer maintained (and doesn't compile).
AntimicroX is a fork that does compile, so this removes antimicro and
adds antimicroX.

Motivation for this change
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Sorry, I was meant to add a reviewer, not an assignee, and now can't remove you as an assignee.

I have been using this software, because of working from home but having to use a work laptop, but my music is on my desktop computer. So I have hooked up a spare PS3 controller, and used this to map buttons to volume up/down, and play/pause. Seems to work fine.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/248


Fixed missing 'set' call for updating the variable scrollTop

It looks like in the mixin, scrollTop is set with this.scrollTop and this.set('scrollTop', scrollTop) - potentially depending on wether it should fire observers or not.
Curious, what prompted you to make this change?

For me the ListView component throws an error when I am not using this.set here:
Uncaught Error: Assertion Failed: You must use Ember.set() to set the scrollTop property (of <(subclass of Ember.ListView):ember1662>) to 50.ember.js:3940 Ember.assertember.js:15818 SETTER_FUNCTIONlist-view.js:667 (anonymous function)ember.js:13173 instrumentlist-view.js:661 exports.default.Ember.Mixin.create._scrollContentTolist-view.js:1449 exports.default.Ember.ContainerView.extend.scrollTolist-view.js:1444 exports.default.Ember.ContainerView.extend.scroll

actually, this.scrollTop was left as non-observable for performance reasons. Especially when tuning for some of the extremely crappy older android devices.
@ruperteder i suspect your code is accidentally observing scrollTop?

Ok, I see. I am using ember list view for building an autocomplete component with endless scrolling functionality. Therefor I had to to observe the scrollTop property. I was not aware of that the scrollTop property should not be used as observable property.

yes, it is currently not public API because of this. Although something like this should likely be public, but likely an action.
@ruperteder can you share an example of your usage ?

Actually the scrollTop property was used in the past by my organization to fix a problem:
fixNegativeScrollTop: ember.observer(function () {
if (this.get('scrollTop') < 0) {
this.set('scrollTop', 0);
}
}, 'scrollTop'),
Today and yesterday I retested this and found out that the problem does no more occure.
So forget about my small change, it seems that it is not required anymore -. also by me.
Good thing is that now I know that scrollTop should not be observed, so thank you very much for this hint :-)

:). I do suspect some addition api, likely an action should exists to fill this void. But observing scrollTop is nearly always some work around for something else

Maybe an _scrollTop is in order

list-view works hard to minimize work, it doesn't even enter a run-loop until something actually needs to change. So exposing _scrollTop as something observable forces us to do lots of extra work at often > 60FPS.
Ultimately my concern is only the slower android devices, hopefully they age out.

@ruperteder is it ok for us to close out this ticket?

I'm sorry we didn't get back to this previously, but at this point this repo is essentially unmaintained.  Please use @html-next/vertical-collection or ember-collection for similar functionality.
Closing...


Make the ref easly launch-able and test a game in grsim

It could be a bash script to launch everything.

#333


monitoring-cadvisor unable to get data from containers.

I am on PiOS 64 Lite, dashboard is running but no data from containers.
I have updated the /boot/cmdline.txt and /etc/docker/daemon.json as suggested in the following thread.
https://github.com/oijkn/Docker-Raspberry-PI-Monitoring/issues/7
And this is what let me run all the containers without any errors.
git clone https://github.com/oijkn/Docker-Raspberry-PI-Monitoring.git
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/data
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/datasources
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/plugins
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/notifiers
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/dashboards
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/data
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/config
sudo chown -R 472:472 /home/pi/Docker-Raspberry-PI-Monitoring/grafana
sudo chown -R 472:472 /home/pi/Docker-Raspberry-PI-Monitoring/prometheus
sudo chmod 777 /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/data
sudo mv /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/prometheus.yml /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/config/prometheus.yml
sudo touch /home/pi/Docker-Raspberry-PI-Monitoring/grafana/grafana.ini
sudo docker-compose up -d
This is the error message for [monitoring-cadvisor]
failed to fetch hugetlb info
github.com/opencontainers/runc/libcontainer/cgroups/fs2.statHugeTlb
/go/pkg/mod/github.com/opencontainers/runc@v1.0.0-rc95/libcontainer/cgroups/fs2/hugetlb.go:35
github.com/opencontainers/runc/libcontainer/cgroups/fs2.(*manager).GetStats
/go/pkg/mod/github.com/opencontainers/runc@v1.0.0-rc95/libcontainer/cgroups/fs2/fs2.go:125
github.com/google/cadvisor/container/libcontainer.(*Handler).GetStats
/go/src/github.com/google/cadvisor/container/libcontainer/handler.go:83
github.com/google/cadvisor/container/raw.(*rawContainerHandler).GetStats
/go/src/github.com/google/cadvisor/container/raw/handler.go:232
github.com/google/cadvisor/manager.(*containerData).updateStats
/go/src/github.com/google/cadvisor/manager/container.go:637
github.com/google/cadvisor/manager.(*containerData).housekeepingTick
/go/src/github.com/google/cadvisor/manager/container.go:583
github.com/google/cadvisor/manager.(*containerData).housekeeping
/go/src/github.com/google/cadvisor/manager/container.go:531
runtime.goexit
/usr/lib/go/src/runtime/asm_arm64.s:1133], continuing to push stats
W0316 05:24:55.189639       1 container.go:586] Failed to update stats for container "/system.slice/ssh.service": error while statting cgroup v2: [open /sys/kernel/mm/hugepages: no such file or directory
failed to fetch hugetlb info
github.com/opencontainers/runc/libcontainer/cgroups/fs2.statHugeTlb
/go/pkg/mod/github.com/opencontainers/runc@v1.0.0-rc95/libcontainer/cgroups/fs2/hugetlb.go:35
github.com/opencontainers/runc/libcontainer/cgroups/fs2.(*manager).GetStats
/go/pkg/mod/github.com/opencontainers/runc@v1.0.0-rc95/libcontainer/cgroups/fs2/fs2.go:125
github.com/google/cadvisor/container/libcontainer.(*Handler).GetStats
/go/src/github.com/google/cadvisor/container/libcontainer/handler.go:83
github.com/google/cadvisor/container/raw.(*rawContainerHandler).GetStats
/go/src/github.com/google/cadvisor/container/raw/handler.go:232
github.com/google/cadvisor/manager.(*containerData).updateStats
/go/src/github.com/google/cadvisor/manager/container.go:637
github.com/google/cadvisor/manager.(*containerData).housekeepingTick
/go/src/github.com/google/cadvisor/manager/container.go:583
github.com/google/cadvisor/manager.(*containerData).housekeeping
/go/src/github.com/google/cadvisor/manager/container.go:531
runtime.goexit
/usr/lib/go/src/runtime/asm_arm64.s:1133], continuing to push stats
W0316 05:24:55.196379       1 container.go:586] Failed to update stats for container "/system.slice/docker-8c01dc5b893a7e67d5fa12416d5457993bf01e4c94590b069bd115da9746a5ee.scope": error while statting cgroup v2: [open /sys/kernel/mm/hugepages: no such file or directory
failed to fetch hugetlb info
github.com/opencontainers/runc/libcontainer/cgroups/fs2.statHugeTlb
/go/pkg/mod/github.com/opencontainers/runc@v1.0.0-rc95/libcontainer/cgroups/fs2/hugetlb.go:35
github.com/opencontainers/runc/libcontainer/cgroups/fs2.(*manager).GetStats
/go/pkg/mod/github.com/opencontainers/runc@v1.0.0-rc95/libcontainer/cgroups/fs2/fs2.go:125
github.com/google/cadvisor/container/libcontainer.(*Handler).GetStats
/go/src/github.com/google/cadvisor/container/libcontainer/handler.go:83
github.com/google/cadvisor/container/docker.(*dockerContainerHandler).GetStats
/go/src/github.com/google/cadvisor/container/docker/handler.go:460
github.com/google/cadvisor/manager.(*containerData).updateStats
/go/src/github.com/google/cadvisor/manager/container.go:637
github.com/google/cadvisor/manager.(*containerData).housekeepingTick
/go/src/github.com/google/cadvisor/manager/container.go:583
github.com/google/cadvisor/manager.(*containerData).housekeeping
/go/src/github.com/google/cadvisor/manager/container.go:531
runtime.goexit
/usr/lib/go/src/runtime/asm_arm64.s:1133], continuing to push stats
W0316 05:25:10.338801       1 manager.go:696] Error getting data for container /system.slice/systemd-journald.service because of race condition
W0316 05:25:10.340027       1 manager.go:696] Error getting data for container /system.slice/udisks2.service because of race condition
W0316 05:25:10.340726       1 manager.go:696] Error getting data for container /system.slice/docker-e5dc78565eabaf33e8c9fafee9fdc258a51675cad55c62b72853cf829b6015b7.scope because of race condition
W0316 05:25:10.341810       1 manager.go:696] Error getting data for container /system.slice/dbus.service because of race condition
W0316 05:25:10.342723       1 manager.go:696] Error getting data for container<EMAIL_ADDRESS>because of race condition
W0316 05:25:10.343710       1 manager.go:696] Error getting data for container<EMAIL_ADDRESS>because of race condition
W0316 05:25:10.344704       1 manager.go:696] Error getting data for container<EMAIL_ADDRESS>because of race condition
W0316 05:25:10.345870       1 manager.go:696] Error getting data for container /system.slice/polkit.service because of race condition
W0316 05:25:10.346642       1 manager.go:696] Error getting data for container /system.slice/docker-05d382abaeafcf2e927f58d382a0db1a2f9bf6046b541ea9dd68039fcece8246.scope because of race condition
W0316 05:25:10.347522       1 manager.go:696] Error getting data for container /system.slice/docker-8214be662772b232ddf894a0a148046d890ef0ebd6c0aac0c1357a1e34dcaeaf.scope because of race condition
W0316 05:25:10.348694       1 manager.go:696] Error getting data for container /system.slice/docker.socket because of race condition
W0316 05:25:10.349664       1 manager.go:696] Error getting data for container<EMAIL_ADDRESS>because of race condition
W0316 05:25:10.350410       1 manager.go:696] Error getting data for container /system.slice/docker-8c01dc5b893a7e67d5fa12416d5457993bf01e4c94590b069bd115da9746a5ee.scope because of race condition
W0316 05:25:10.351592       1 manager.go:696] Error getting data for container /system.slice/systemd-udevd.service because of race condition
W0316 05:25:10.354269       1 manager.go:696] Error getting data for container /system.slice/wpa_supplicant.service because of race condition
W0316 05:25:10.355296       1 manager.go:696] Error getting data for container /system.slice/docker-91fc4c0d91cbf1006e32a05b411cdd93256df1cd81e0941a55152fe32f60d7cd.scope because of race condition
W0316 05:25:10.357057       1 manager.go:696] Error getting data for container /system.slice/system-modprobe.slice because of race condition
W0316 05:25:10.359454       1 manager.go:696] Error getting data for container /system.slice/cron.service because of race condition
W0316 05:25:10.360809       1 manager.go:696] Error getting data for container /system.slice/ssh.service because of race condition
W0316 05:25:10.361964       1 manager.go:696] Error getting data for container /init.scope because of race condition
W0316 05:25:10.363086       1 manager.go:696] Error getting data for container<EMAIL_ADDRESS>because of race condition
W0316 05:25:10.364426       1 manager.go:696] Error getting data for container /system.slice/systemd-timesyncd.service because of race condition
W0316 05:25:10.365281       1 manager.go:696] Error getting data for container /system.slice/docker-bc086bdffefc5fcb26a585393fea83aa2c34b7086fb0a3ed4d0bc3bb50f14acb.scope because of race condition
W0316 05:25:10.366045       1 manager.go:696] Error getting data for container /system.slice/docker-cbb07b89b243ec69e84d41a8e6882759e883acabd79d252afff812f5ca86ee2d.scope because of race condition
W0316 05:25:10.367837       1 manager.go:696] Error getting data for container /system.slice because of race condition
W0316 05:25:10.369058       1 manager.go:696] Error getting data for container /system.slice/containerd.service because of race condition
W0316 05:25:10.370220       1 manager.go:696] Error getting data for container /system.slice/rsyslog.service because of race condition
W0316 05:25:10.371408       1 manager.go:696] Error getting data for container /system.slice/rng-tools-debian.service because of race condition
W0316 05:25:10.372182       1 manager.go:696] Error getting data for container /system.slice/docker-5b314ce7d65024a244eb3d8de2c84a3aa1b40985ad9a60519630c342f218eeba.scope because of race condition
W0316 05:25:10.373434       1 manager.go:696] Error getting data for container /system.slice/systemd-logind.service because of race condition
W0316 05:25:10.374623       1 manager.go:696] Error getting data for container /system.slice/system-systemd\x2dfsck.slice because of race condition
W0316 05:25:10.375867       1 manager.go:696] Error getting data for container /system.slice/docker.service because of race condition
W0316 05:25:10.378050       1 manager.go:696] Error getting data for container /user.slice/user-1000.slice because of race condition
W0316 05:25:10.379356       1 manager.go:696] Error getting data for container /system.slice/bluetooth.service because of race condition
W0316 05:25:10.380133       1 manager.go:696] Error getting data for container /system.slice/docker-20de10b24a1ba0aa4d5ae0b3c37dd631d1364e34bd110547f96b006c32029040.scope because of race condition
W0316 05:25:10.380907       1 manager.go:696] Error getting data for container /system.slice/docker-6fd738388b5bc9ba4ef77d193976a760d2ee89d3bb7414c65c7fa53ae320231b.scope because of race condition
W0316 05:25:10.382111       1 manager.go:696] Error getting data for container /system.slice/system-bthelper.slice because of race condition
W0316 05:25:10.383069       1 manager.go:696] Error getting data for container /user.slice/user-1000.slice/session-129.scope because of race condition
W0316 05:25:10.383866       1 manager.go:696] Error getting data for container /system.slice/docker-2b893059e92263d4eedc1510749edece6f4ca649b555516f59402911208ce5c0.scope because of race condition
W0316 05:25:10.385079       1 manager.go:696] Error getting data for container /system.slice/avahi-daemon.service because of race condition
W0316 05:25:10.386091       1 manager.go:696] Error getting data for container /user.slice/user-1000.slice/session-127.scope because of race condition
W0316 05:25:10.387280       1 manager.go:696] Error getting data for container /user.slice because of race condition
W0316 05:25:10.388309       1 manager.go:696] Error getting data for container<EMAIL_ADDRESS>because of race condition
W0316 05:25:10.389847       1 manager.go:696] Error getting data for container /system.slice/dhcpcd.service because of race condition
W0316 05:25:10.391069       1 manager.go:696] Error getting data for container /system.slice/triggerhappy.service because of race condition
W0316 05:25:10.392404       1 manager.go:696] Error getting data for container /system.slice/hciuart.service because of race condition
W0316 05:25:10.393589       1 manager.go:696] Error getting data for container /system.slice/system-getty.slice because of race condition

For those who are having same problem, please build your own docker image by using Dockerfile from the following location.
https://github.com/google/cadvisor/issues/3011#issuecomment-975630481
Use the following for error free deployment in your PiOS 64 Bit.

git clone https://github.com/oijkn/Docker-Raspberry-PI-Monitoring.git
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/data
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/datasources
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/plugins
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/notifiers
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning/dashboards
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/data
mkdir /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/config
sudo chown -R 472:472 /home/pi/Docker-Raspberry-PI-Monitoring/grafana
sudo chown -R 472:472 /home/pi/Docker-Raspberry-PI-Monitoring/prometheus
sudo chmod 777 /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/data
sudo mv /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/prometheus.yml /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/config/prometheus.yml
sudo touch /home/pi/Docker-Raspberry-PI-Monitoring/grafana/grafana.ini
cd Docker-Raspberry-PI-Monitoring
$null > docker-compose.yml
sudo nano docker-compose.yml

Use the following content for your docker-compose.yml

version: "3.8"
services:
cadvisor:
container_name: monitoring-cadvisor
command: --raw_cgroup_prefix_whitelist=/docker/ --disable_metrics=hugetlb
devices:
- /dev/kmsg
expose:
- 8080
hostname: rpi-cadvisor
image: my_image:latest
ipc: shareable
networks:
- rpimonitor_default
ports:
- 8228:8080
privileged: true
restart: unless-stopped
volumes:
- /:/rootfs:ro
- /var/run:/var/run:ro
- /sys:/sys:ro
- /var/lib/docker/:/var/lib/docker:ro
- /dev/disk/:/dev/disk:ro
grafana:
container_name: monitoring-grafana
environment:
- GF_USERS_ALLOW_SIGN_UP=false
- GF_PATHS_CONFIG=/etc/grafana/grafana.ini
- GF_PATHS_DATA=/var/lib/grafana
- GF_PATHS_HOME=/usr/share/grafana
- GF_PATHS_LOGS=/var/log/grafana
- GF_PATHS_PLUGINS=/var/lib/grafana/plugins
- GF_PATHS_PROVISIONING=/etc/grafana/provisioning
hostname: rpi-grafana
image: grafana/grafana:latest
networks:
- rpimonitor_default
ports:
- 3000:3000
restart: unless-stopped
volumes:
# to be modified depending on your needs
- /home/pi/Docker-Raspberry-PI-Monitoring/grafana/data:/var/lib/grafana
- /home/pi/Docker-Raspberry-PI-Monitoring/grafana/provisioning:/etc/grafana/provisioning
- /home/pi/Docker-Raspberry-PI-Monitoring/grafana/grafana.ini:/etc/grafana/grafana.ini
node-exporter:
container_name: monitoring-node-exporter
expose:
- 9100
hostname: rpi-exporter
image: prom/node-exporter:latest
networks:
- rpimonitor_default
restart: unless-stopped
prometheus:
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
container_name: monitoring-prometheus
expose:
- 9090
hostname: rpi-prom
image: prom/prometheus:latest
networks:
- rpimonitor_default
restart: unless-stopped
volumes:
# to be modified depending on your needs
- /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/data:/prometheus
- /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/config:/etc/prometheus
#- /home/pi/Docker-Raspberry-PI-Monitoring/prometheus/prometheus.yml:/etc/prometheus/prometheus.yaml
links:
  - cadvisor:cadvisor
  - node-exporter:node-exporter

networks:
rpimonitor_default:
external: true

Save it and execute following.

sudo docker-compose up -d

Monitoring

I guess it is still not able to get the memory data.

So which version you are building?

So which version you are building? More detailed about cmdline. PiOS 64bit, i assume bullseye?
https://github.com/novaspirit/pi-hosted/blob/master/docs/rpi_docker_monitor.md

Yes, PiOS 64bit bullsey. I don't have any memory limit set, that is why it is probably showing incorrect information.

This is the one. 'Race condition' and 'failed to fetch hugetlb info' errors in Raspbian · Issue #3011 · google/cadvisor (github.com)https://github.com/google/cadvisor/issues/3011
FROM arm64v8/golang as build
RUN apt update && apt install -y git dmsetup
RUN git clone
--branch release-v0.38
--depth 1
https://github.com/google/cadvisor.git
/go/src/github.com/google/cadvisor
WORKDIR /go/src/github.com/google/cadvisor
RUN make build
FROM arm64v8/debian
COPY --from=build /go/src/github.com/google/cadvisor/cadvisor /usr/bin/cadvisor
EXPOSE 8080
ENTRYPOINT ["/usr/bin/cadvisor", "-logtostderr"]

From: Dedy Martadinata S @.>
Sent: Wednesday, March 16, 2022 11:00 PM
To: oijkn/Docker-Raspberry-PI-Monitoring @.>
Cc: Saugata Datta @.>; Author @.>
Subject: Re: [oijkn/Docker-Raspberry-PI-Monitoring] monitoring-cadvisor unable to get data from containers. (Issue #17)
So which version you are building?
—
Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foijkn%2FDocker-Raspberry-PI-Monitoring%2Fissues%2F17%23issuecomment-1069383879&data=04|01||c49e8f5e9cf74f15bbe508da0772b031|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637830486406007308|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=MoWc%2FnX5cP3Edw3MzAwuchvjy%2B%2Bexwjbkbfp%2F%2BAO12k%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGMEAMHRNRJIHMH74XE3MV3VAILD5ANCNFSM5Q22JRZA&data=04|01||c49e8f5e9cf74f15bbe508da0772b031|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637830486406007308|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=KqzCDuvPxRf7JgC2kVGvoZkLC6NY9zTbUrevmencQAw%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||c49e8f5e9cf74f15bbe508da0772b031|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637830486406007308|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=Ifc6Q1L%2F%2Fk%2F3gJ5kjFEHTvjD%2FPE5vrrAjsiPR4GUqRk%3D&reserved=0 or Androidhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01||c49e8f5e9cf74f15bbe508da0772b031|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637830486406163548|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=ZqUN8Z%2FvVoAfkfGbsweVr%2FEyXB%2Bowio5Z1u%2Bsrm98k0%3D&reserved=0.
You are receiving this because you authored the thread.Message ID: @.***>

the branch part 0.38, change into 0.44 and remove the cmdline tweak.

@martadinata666 Is it needed to remove the cmdline tweak? Because if you remove it your docker stats command won't show memory data.

So here is a thing abt cadvisor.
cadvisor <= 0.39 can't do cgroup v2 properly, many data missing., so the cmdline tweaking to downgrade your system to cgroup v1. After that 0.40+ need remove the tweak as it already support v2 properly, 0.44 latest known most little issue with this.
Thats how supposedly work.
@Robin-KEB  dunno which system you are using, using more newer wil detect automatically as it should be. And I never get docker stats dont show memory on any. I assume it PiOS? It got stripped feature, you need the line tweak. Basically any PiOS either 32/64bit need the line tweak.

This issue has been inactive for some time. Please let me know if it's still relevant and need attention or I will close it.


Add gradle version hook

The gradle version hook should work with a local gradle installation and the gradle wrapper. If both are present the gradle wrapper should be used.

Actually gradle does not have any built-in support for versioning projects, as its more a build tool instead of a package manager. Therefore this issue is closed. If someone wants to execute a gradle task, he can to it with the Command hook.


[ALLUXIO-3227] Refactor waitfor

https://alluxio.atlassian.net/browse/ALLUXIO-3227

Change the waitFor signatures to all take Supplier<Boolean> instead of Function<Void, Boolean>
Change waitFor to declare throwing TimeoutException and InterruptedException.
implement waitFor using waitForResult so that they can share the same core implementation
Change call sites to use lambdas and handle TimeoutException/InterruptedException if necessary
Add a few unit tests for waitFor

The only part that requires a close review is the change to CommonUtils.java. The refactors of the call sites are mostly mechanical.

alluxio-bot, check this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/20507/
Test PASSed.


Ability to create communications without sms

Along with “answer using a link” or “answer using sms”, dispatcher should be able to create communications without sending any sms.
Sometimes, the campaign is created using emails or other external ways, and it could be useful to create campaigns later on in order to manage the next steps.

Duplicate of #41


Vickel: Watch etnafes(?!.com(?<=etnafes.com))

Vickel requests the watch of the watch_keyword etnafes(?!\.com(?<=etnafes\.com)). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

etnafes(?!\.com(?<=etnafes\.com)) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Add 9-stream support

Just adding 9-stream as a possible choice for --release (now available in CI infra)

This would be fine
Can we also update the ansible module? (just so that during udpate, we have less things to keep in mind)
https://github.com/CentOS/python-cicoclient/blob/master/cicoclient/ansible/cico.py & https://github.com/CentOS/python-cicoclient/blob/master/docs/ansible_usage.rst


quality is inferior to that advertised in the Lyra Google AI blog

I ran the samples published in the Lyra blog through the encoder_main and decoder_main binaries compiled from the open-sourced Lyra code (this repo). I compiled the floating point version of the code. I tried both the v0.0.1 and the latest commit, result is same. The decoded outputs (produced by running the original through encoder_main and then decoding the bit stream decoder_main) are attached:
lyra_reproduce_blog.zip
It is clear that the quality of the samples decoded from this code is inferior to the quality of the samples advertised in the Lyra blog.
Why is this? Weren't the samples in the blog produced by the same code?
Thank you in advance for clarifying.

That's exactly what I also noticed when trying to reproduce the samples in the demo!

The samples in the AI blog were produced by our latest Lyra model, which is one generation ahead, but will be open-sourced as soon as some technical details are ironed out. Sorry about the confusion.

Any timeframe for the release of the most actual Lyra model?

@jverschneiten It would be great if you could replicate the demos with the new version to see if they stack up.

To be transparent, Lyra v0.0.2 did not ship any quality improvements except for fixing the noise bursts at the beginning of the audio samples (#46).

The new Lyra 1.2.0 release comes with significant quality improvements. And this time around the samples in the blog post were generated with the model and test files we are releasing.

So instead of reducing the bitrate, Lyra V2 increased the bitrate? Any way there can be a lower bitrate version? 3.2 kbps is 50% more than any 90's full-rate vocoder.

Lyra V2 supports 3.2kbps, 6kbps and 9.2kbps. So yes, the lowest supported bitrate was increased from 3kbps in Lyra V1 to 3.2kbps in Lyra V2. That is indeed significantly higher than parametric coders, like MELP or codec2. But Lyra V2 quality is also significantly higher than those parametric codecs. On the other hand, Lyra V2 bitrate is significantly lower than waveform coders with similar quality, like Opus, EVS or AMR-WB.
There are generative-model based codecs that are trained and tweaked for lower bitrates, but it all depends on the desired application.


[XLA:CPU][oneDNN] : Add OneDNN softmax rewriter

This PR rewrites the below mentioned HLO pattern, into softmax pattern and executes it through custom call to oneDNN softmax library function.
This pattern is mainly seen in flax/jax softmax operation, with Float32 datatype. The rewrite uses 'divide' operation as root node to match the pattern and is currently called before any layout assignment / float normalization passes to avoid more convert ops or layout normalization ops during pattern matching.
HLO Pattern :

Hi @sachinmuradi Can you please rebase your branch and resolve conflicts? Thank you!

Hi @sachinmuradi Can you please rebase your branch and resolve conflicts? Thank you!

Hi @sachinmuradi Any update on this PR? Please. Thank you!

Closing this PR since its replacement PR https://github.com/openxla/xla/pull/7540 has been merged. Thank you again for the changes!


Client is closing connections on macos

All api calls result for me "_ClientSocketException (Connection failed)" when building for macos desktop. Mobile works fine.

Hi, the library uses the HTTP package to make requests, which is supported and works well on all platforms including macOS, so I am likely to say that the  (Connection failed) issue is throwing due to the internet permission of your macOS app, please re-check it again.


Remove generated Kubernetes code for all except latest version.

Backstory
Way back in #71, we added hack scripts and supporting container images to generate Kubernetes client code for several Kubernetes versions. At the time, we had consumers of our code that were not ready to upgrade to the latest version of client-go, which they would have needed to do to link with our generated code.
We solved this by generating code for several versions of Kubernetes (currently 1.17.x, 1.18.x, 1.19.x, and 1.20.x). Pinniped itself only ever uses the newest of those. We keep each version in a nested Go module, so that a developer who wants to depend on a specific version of our generated code can import go.pinniped.dev/generated/1.18/apis as a dependency without bringing in the rest of Pinniped's dependency tree.
Costs
This came with some costs:

Code generation takes a bit longer anytime we change the API. We process all versions concurrently, however.
We ran into https://github.com/golang/go/issues/34055, which prevents importing Go modules which are hosted in a subdirectory of a Git repository if those modules also use a custom "vanity" import path.
For similar reasons, @dependabot is unable to manage our Go dependencies because it cannot cope with our multi-module repository.

Current State
In the time since August 2020, the project has advanced tremendously in maturity. I think we now understand our downstream consumption patterns. We no longer expect many other codebases to depend directly on our clients, and those that do should primarily only need TokenCredentialRequest, which is easy to use via client-go dynamic client.
Proposal
Let's remove the generated code for 1.17.x, 1.18.x, and 1.19.x, as well as the go.mod file that marks the 1.20.x client as a distinct module. This leaves us with a single Go module for all of Pinniped. This simplifies code generation, eliminates any workarounds for https://github.com/golang/go/issues/34055, and makes Dependabot work again.
We can retain the 1.17.x-1.19.x code generation containers and keep the codegen hack scripts intact with minor modifications, so it should be easy to revert this change if we ever need to go back to supporting multiple client library versions.

We ended up doing something somewhat different that accomplished similar goals: https://github.com/vmware-tanzu/pinniped/pull/403


CM2Walki / CSGO Docker deployment

Now I want to use CM2Walki/CSGO to deploy the dedicated server for csgo, The exclusive server for CSGO is 740，Is the project code still using 730？
UPDATE：After deployment, I checked the logs and found that the game service has been restarting in a loop

If this issue is still relevant, reopen it on joedwards32/CS2. This repository is now a mirror.


bazeldnf: Update to v0.5.5

What this PR does / why we need it:
This new version of bazeldnf contains a fix for the issue that we had to work around in 8052a7f3e30b ("rpm: Manually fix URL for passt package").
Release note:
NONE

@rmohr :)

/lgtm
/approve

/retest


fix: multi-axis tooltip/cursor formatting, proper extent for multi-axis

Multi-axis extent and formatters were inaccurate. This fixes those inconsistencies.

:tada: This PR is included in version 3.0.0-beta.36 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add In Case You Missed It block to DrB Community Insider block

 Add ICYMI section to DrB Insider template


Add ability for adding meta data to ems-providers

We need to support the following actions:

Addition of meta-data (Expected inventory, SalesForce Account Number, etc..) connected to the provider, this needs to be available through the rest-api.
We know we want to process it in the policies, should we care about the type of data?
A table that will display this meta-data on a provider in Show-page.

@simon3z @blomquisg Any thing else you think we should add in this desc?

We think using custom-attributes will be the best, we will also need to add the ability to specify what kind of a variable is the value.


Allow both resource claims and managed resources to pass the class kind predicate

Description of your changes

It turns out both our watches use the same predicate and apply it to the watched kind, not the kind that actually gets enqueued.
Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the RBAC permissions in clusterrole.yaml to include any new types.

I've also run make tests

Confirmed this works by building stack-gcp against this commit and creating a RedisCluster, RedisClusterClass, and CloudSQLInstanceClass. The binding happens as soon as the managed resource becomes available, as expected.

Thank you for finding this issue and getting it fixed so quickly @negz!! 🙇


Integration Test

subject says it all (or mostly: besides address issue #67, i also did some related cleanup / re-org of fabric/sgxconfig/* and addressed issue #53 )
PS: eventually, some of the .sh libraries could also be put into common but for now i left it self-contained ./integration ...

I get an error. see here
auction_test.sh: FIRST RUN: this should fail due to docker-switcheroo ...
auction_test.sh: - setup ledger
/home/bur/fabric-secure-chaincode/integration/common_ledger.sh: line 56: kill: (4565) - No such process
 auction_test.sh: Orderer quit too quickly: (for log see /tmp/hyperledger/test//orderer.out & /tmp/hyperledger/test//orderer.err)
/home/bur/fabric-secure-chaincode/integration/common_ledger.sh: line 96: kill: (4565) - No such process
Makefile:14: recipe for target 'auction_test' failed

I saw the same problem yesterday also.  I'm not sure what exactly made it fail but making fabric config and cc-name etc test-specific seemed to remove the problem. Test again with the new version.
BTW: this should hopefully be obsolete anyway soon: i'm mid-way through a patch which removes the switcheroo (or more proactively, creates the correct container before the peer generates the wrong one ...)

I am also running into that problem. Any updates?

I am also running into that problem. Any updates?

You were running with the latest version? I couldn't reproduce the issue with that version. Actually, thinking of it i'm actually not sure i ever saw exactly that problem. What do the log-files show (see the error message for location of log-files)?

alright, I was missing credentials in integration first, the log helped
then I missed the credentials in usual place... I don't think I have found anything hinting at that
filed an issue #82  for this: if you want to address it now fine, if you want to address it later good!

alright, I was missing credentials in integration first, the log helped
then I missed the credentials in usual place... I don't think I have found anything hinting at that
filed an issue #82 for this: if you want to address it now fine, if you want to address it later good!

Updated the PR with corresponding tests and a bit of generalizations (see #82 for comments on how the common_* scripts can (and should) be moved to a global scope as part of the SDK refactoring ..)

Regarding symlinks, in general you should haveonly  symlinks into GOPATH, but not out of GOPATH as you seem to do: In this particular case you could define FABRIC_BIN_DIR env variable but i think other things won't work reliabilty if you do not have a proper (bidirectional) GOPATH tree. Just move your directory into GOPATH and then symlink from ~/ and you still have quick access?
Regarding license checks failing, clearly these files cannot have a license header. Also, doesn't fail for me. (Anyway, this is a fabric script so you might be anyway the better person to debug ;-)

Regarding symlinks, in general you should haveonly symlinks into GOPATH, but not out of GOPATH as you seem to do: In this particular case you could define FABRIC_BIN_DIR env variable but i think other things won't work reliabilty if you do not have a proper (bidirectional) GOPATH tree. Just move your directory into GOPATH and then symlink from ~/ and you still have quick access?
Regarding license checks failing, clearly these files cannot have a license header. Also, doesn't fail for me. (Anyway, this is a fabric script so you might be anyway the better person to debug ;-)

Actually, now it is failing also but only after i noticed somebody merged master into this branch  and I (force) pulled the new version.
PS: I'd prefer if unless handing over control i would own my own PR branches and the merge of master and alike (e.g., i would rather have done a rebase than a merge and it is also easier to understand what happens if you report problems)

got it, and fine with that -- just wanted to speed up a possible approval, since it was good before.
Anyway, it did not work for me even before I updated the branch.

got it, and fine with that -- just wanted to speed up a possible approval, since it was good before.
Anyway, it did not work for me even before I updated the branch.

Hmm, didn't you approve before my test for the config (which i took as a confirmation that it works) ?  Are you saying the version after todays force-push but before the merge failed but did work before my merge-push with config test? If so, how did it fail?

Yes, it worked before.
Then you pushed a big commit -- just for checking the existence of the key files!!!
This solved the key checking part, but I think you modified the CC_ID of the auction test, and vscc does not recognize it anymore. There is also a problem with getting the mrenclave -- it turns out to be empty.

Regarding symlinks, in general you should haveonly symlinks into GOPATH, but not out of GOPATH as you seem to do: In this particular case you could define FABRIC_BIN_DIR env variable but i think other things won't work reliabilty if you do not have a proper (bidirectional) GOPATH tree. Just move your directory into GOPATH and then symlink from ~/ and you still have quick access?
Regarding license checks failing, clearly these files cannot have a license header. Also, doesn't fail for me. (Anyway, this is a fabric script so you might be anyway the better person to debug ;-)

Looking now at the license check, i notice that it actually only tests files (and directories) modified in the current commit and the attempt to filter out files which should not have a license is very brittle.   I don't think that this is something we realistically can make robust (and i'm pretty sure it will fail for fabric also on quite some commits), so i would suggest to leave it as is and just for such failing license checks manually peruse the files which make it fail and if bening ignore the errors ...

Yes, it worked before.
Then you pushed a big commit -- just for checking the existence of the key files!!!
it was an amend commit. the changes were not thaat bug: addition of ledger_precond_check which does all the checks and changed some variable definitions to be conditioned on being not yet defined.   If we already check then we might check everything and also do so that it is general and robust (e.g., reading file location from config)?

This solved the key checking part, but I think you modified the CC_ID of the auction test, and vscc does not recognize it anymore. There is also a problem with getting the mrenclave -- it turns out to be empty.

Nope, nothing changed in terms of id in todays diff. (if you click on the force-push in the history, you get the actual delta pushed, e.g., https://github.com/hyperledger-labs/fabric-private-chaincode/compare/b439b413cb06806b1ccb186aed9656976a6880e8..e58d4a3f515b29990878775cf764b81b70c13285 in this case)

Yes, it worked before.
Then you pushed a big commit -- just for checking the existence of the key files!!!
it was an amend commit. the changes were not thaat bug: addition of ledger_precond_check which does all the checks and changed some variable definitions to be conditioned on being not yet defined.   If we already check then we might check everything and also do so that it is general and robust (e.g., reading file location from config)?

This solved the key checking part, but I think you modified the CC_ID of the auction test, and vscc does not recognize it anymore. There is also a problem with getting the mrenclave -- it turns out to be empty.

Nope, nothing changed in terms of id in todays diff. (if you click on the force-push in the history, you get the actual delta pushed, e.g., https://github.com/hyperledger-labs/fabric-private-chaincode/compare/b439b413cb06806b1ccb186aed9656976a6880e8..e58d4a3f515b29990878775cf764b81b70c13285 in this case)

btw: did you do a 'make clean' before you run the test?

Yes, it worked before.
Then you pushed a big commit -- just for checking the existence of the key files!!!
it was an amend commit. the changes were not thaat bug: addition of ledger_precond_check which does all the checks and changed some variable definitions to be conditioned on being not yet defined.   If we already check then we might check everything and also do so that it is general and robust (e.g., reading file location from config)?

This solved the key checking part, but I think you modified the CC_ID of the auction test, and vscc does not recognize it anymore. There is also a problem with getting the mrenclave -- it turns out to be empty.

Nope, nothing changed in terms of id in todays diff. (if you click on the force-push in the history, you get the actual delta pushed, e.g., https://github.com/hyperledger-labs/fabric-private-chaincode/compare/b439b413cb06806b1ccb186aed9656976a6880e8..e58d4a3f515b29990878775cf764b81b70c13285 in this case)

btw: did you do a 'make clean' before you run the test?

Of course I did.
You PR https://github.com/hyperledger-labs/fabric-private-chaincode/pull/79/commits
contains 3 commits. The last one (the branch update) is mine.
The diff of the other two is this one
https://github.com/hyperledger-labs/fabric-private-chaincode/compare/c8aa61da0cbe13c1c61124400f59af87f001e0d5..e58d4a3f515b29990878775cf764b81b70c13285
and it's big and contains CC_ID=ecc_auction_test

Yes, it worked before.
Then you pushed a big commit -- just for checking the existence of the key files!!!
it was an amend commit. the changes were not thaat bug: addition of ledger_precond_check which does all the checks and changed some variable definitions to be conditioned on being not yet defined.   If we already check then we might check everything and also do so that it is general and robust (e.g., reading file location from config)?

This solved the key checking part, but I think you modified the CC_ID of the auction test, and vscc does not recognize it anymore. There is also a problem with getting the mrenclave -- it turns out to be empty.

Nope, nothing changed in terms of id in todays diff. (if you click on the force-push in the history, you get the actual delta pushed, e.g., https://github.com/hyperledger-labs/fabric-private-chaincode/compare/b439b413cb06806b1ccb186aed9656976a6880e8..e58d4a3f515b29990878775cf764b81b70c13285 in this case)

btw: did you do a 'make clean' before you run the test?

Of course I did.
You PR https://github.com/hyperledger-labs/fabric-private-chaincode/pull/79/commits
contains 3 commits. The last one (the branch update) is mine.
The diff of the other two is this one
https://github.com/hyperledger-labs/fabric-private-chaincode/compare/c8aa61da0cbe13c1c61124400f59af87f001e0d5..e58d4a3f515b29990878775cf764b81b70c13285
and it's big and contains CC_ID=ecc_auction_test

That change is from a week ago (in this force-push/rebase/delta-commit: https://github.com/hyperledger-labs/fabric-private-chaincode/compare/de1685d52ca581aede1c1d76f95ca1cf568faa36..b439b413cb06806b1ccb186aed9656976a6880e8).    I've done rebase to add the patches to keep a clean commit history, so just looking at the final commits doesn't tell you the full story ....
Anyway, what exactly is the problem/error you get with vscc?

2019-06-13 07:46:02.936 PDT [tl-enclave] golog -> INFO 05a ERROR [Enclave] Ledger: Only SGX chaincodes supported currently!
2019-06-13 07:46:06.615 PDT [vscc] Validate -> ERRO 067 VSCC error: checkAttestation failed, err mrenclave is empty
2019-06-13 07:46:06.615 PDT [committer.txvalidator] validateTx -> ERRO 068 VSCCValidateTx for transaction txId = b852984355600635b5e8e83d6adf92c7dc15734b1117f8b0d94d23b82973020d returned error: mrenclave is empty
2019-06-13 07:46:06.822 PDT [tl-enclave] golog -> INFO 06c ERROR [Enclave] Ledger: >>> NO MRENCLAVE found for: ecc.MRENCLAVE
then it crashes.
About the changes and commits. I have no idea of what you are talking about.
Your PR "only" contains: c8aa61da0cbe13c1c61124400f59af87f001e0d5, e58d4a3f515b29990878775cf764b81b70c13285.

About the changes and commits. I have no idea of what you are talking about.
Your PR "only" contains: c8aa61d, e58d4a3.

Did you click on the links i provided?  They  correspond (as mentioned) to the incremental changes in introduced in the rebase of the commits you mention. They show up as force-push (links) in the history on this page.

2019-06-13 07:46:02.936 PDT [tl-enclave] golog -> INFO 05a ERROR [Enclave] Ledger: Only SGX chaincodes supported currently!
2019-06-13 07:46:06.615 PDT [vscc] Validate -> ERRO 067 VSCC error: checkAttestation failed, err mrenclave is empty
2019-06-13 07:46:06.615 PDT [committer.txvalidator] validateTx -> ERRO 068 VSCCValidateTx for transaction txId = b852984355600635b5e8e83d6adf92c7dc15734b1117f8b0d94d23b82973020d returned error: mrenclave is empty
2019-06-13 07:46:06.822 PDT [tl-enclave] golog -> INFO 06c ERROR [Enclave] Ledger: >>> NO MRENCLAVE found for: ecc.MRENCLAVE
then it crashes.

This sounds like an error in the extraction of the MRENCLAVE.  As i pointed out in an earlier PR, we didn't do proper return code checking and anyway extract the MRENCLAVE much more complex/brittle than necessary.  The latter part i thought we agreed to just an issue (although i can't see one); the former i thought we fixed but maybe not ...

This sounds like an error in the extraction of the MRENCLAVE. As i pointed out in an earlier PR #75, we didn't do proper return code checking and anyway extract the MRENCLAVE much more complex/brittle than necessary. The latter part is issue #77 the former i thought we fixed but maybe not ... (doesn't seem so, at least *_enclave/generate_mrenclave.sh still doesn't check any errors ..)

Did add now fix with missing error check (as well as pushing 'checks' make target to last, see above). Hopefully, that helps root-causing problem Bruno faces ...

It works for me on 7dc6d35

7dc6d35 reverts the name of the cc back to ecc from ecc_auction_test. The latter would have been nicer due to keeping dockers and alike of tests separate from other runs but before we fix issue #86 i guess we have to stick with "ecc" ... :-(

Great job! Thanks for this PR!


Added docker file to enable the project to run in a docker image

Hi,
thanks for the template. I am looking to run the web application in a docker image and have created a generic Dockerfile for the project. the resulting image would run the web application in a slim alpine container.

This is great @hamidshahid Thank you!!


support native segwit regtest addresses (#148)

Add support for Native Segwit addresses on regtest networks
Resolves Issue #148
To verify this human readable part for bech32 regtest addresses, the following references may be helpful:

Bitcoin Core RegTestParams
BIP-0173
Implementation in bitcoinjs-lib

Are there plans to add regtest as a separate network parameter? There are a lot of functions that use network as a parameter and if we're to support regtest, they all need to be updated. For example bech32.py has a function encode_bech32_checksum. That would need to return the address of the type that is in this function.


get_exception_handler() util resolve ordering.

https://github.com/starlite-api/starlite/blob/da79c068c906740a4375d431953f1c74fdea8067/starlite/utils/exception.py#L10-L28
I've registered an exception handler to 500_INTERNAL_SERVER_ERROR that logs the exception but it is also catching and logging HTTPException instances. Even if I register an exception handler to HTTPException to try to avoid that, because I also have a handler registered for 500 that conditional is always hit and the handler returned before it has the chance to do the walk MRO thing.
So I think the mro walk should be above the 500 fallback, and then I think we should think of whether we'd actually want the HTTPException subclasses to be pulled in with the 500 handler if there isn't a narrower mapping.
This is the registration mapping:
    exception_handlers={
        HTTP_500_INTERNAL_SERVER_ERROR: logging_exception_handler,
        HTTPException: passthrough_exception_handler,  # type:ignore[dict-item]
    },

But HTTPException sub-classes are getting sucked up by this:
     if HTTP_500_INTERNAL_SERVER_ERROR in exception_handlers:
         return exception_handlers[HTTP_500_INTERNAL_SERVER_ERROR]

... before the mro check can find the base class mapping.

By the way, to work around it is easy enough, just to register the logging handler to Exception instead of the 500, so not massively urgent to fix.
    exception_handlers={
        Exception: logging_exception_handler,
        HTTPException: passthrough_exception_handler,  # type:ignore[dict-item]
    },

Aight, let's update the ordering


ToolTip Not Displaying Binding Field Correctly 'System.Windows.DataTemplate'

I have a basic Style setup like the following. I want to bind to Header property.
When I run the App, this is what I see for the ToolTip: System.Windows.DataTemplate

<Style TargetType="{x:Type dragablz:TabablzControl}" BasedOn="{StaticResource {x:Type dragablz:TabablzControl}}">
               <Setter Property="ItemContainerStyle" Value="{StaticResource TrapezoidDragableTabItemStyle}" />
               <Setter Property="AdjacentHeaderItemOffset" Value="-12" />
               <!--<Setter Property="NewItemFactory" Value="{x:Static local:MainWindowViewModel.NewItemFactory}" />-->
               <Setter Property="ShowDefaultAddButton" Value="True" />
               <Setter Property="ShowDefaultCloseButton" Value="True" />
               <Setter Property="ToolTip">
                   <Setter.Value>
                       <DataTemplate DataType="{x:Type local:TabContent}">
                           <TextBlock Text="{Binding Header}" />
                       </DataTemplate>
                   </Setter.Value>
               </Setter>
               <Setter Property="HeaderItemTemplate">
                   <Setter.Value>
                       <DataTemplate DataType="{x:Type local:TabContent}">
                           <TextBlock Text="{Binding Header}" Width="200" ToolTip="{Binding Header}" />
                       </DataTemplate>
                   </Setter.Value>
               </Setter>
               <Setter Property="ContentTemplate">
                   <Setter.Value>
                       <DataTemplate DataType="{x:Type local:TabContent}">
                           <ContentPresenter Margin="4" Content="{Binding Content}" />
                       </DataTemplate>
                   </Setter.Value>
               </Setter>
           </Style>

Tooltip expects a string value, not a datatemplate. That's how WPF works. you will need anything else if you want do display more than texy

@jeremyVignelles how can I just include a string value considering I'm using Data Binding?
I've tried something like this but it doesn't work.
 <Setter Property="ToolTip" Value="{Binding Header}"/>

It doesn't work that way as it has no context of the DataType:
See how HeaderItemTemplate and ContentTemplate are being set. When I just reference
<Setter Property="ToolTip" Value="{Binding Header}"/>
It doesn't have:
                      <DataTemplate DataType="{x:Type local:TabContent}">

Oh, I see where your problem is:
You are trying to set a Tooltip on the TabablzControl itself, instead of each tab.
Try to remove this code:
               <Setter Property="ToolTip">
                   <Setter.Value>
                       <DataTemplate DataType="{x:Type local:TabContent}">
                           <TextBlock Text="{Binding Header}" />
                       </DataTemplate>
                   </Setter.Value>
               </Setter>

because <TextBlock Text="{Binding Header}" Width="200" ToolTip="{Binding Header}" /> should be enough. You will need to put your mouse on the text however.
You can also add a container around your text block that will hold the tooltip.

Thanks for the thoughts but no, having ToolTip on the TextBlock doesn't display anything.
I'm only able to get the ToolTip to display anything is using the ToolTip Property.

Yeah, but then it would apply to the whole tabs collection, so that's not what you want.
You will want to do your work inside HeaderItemTemplate. try to wrap your text block inside a Grid or a Border with a background color and put your tooltip on that

@jeremyVignelles Any thoughts here? This is the sample project I am basing my testing off. How would you get ToolTip to work here:
https://github.com/ButchersBoy/DragablzSamplez/blob/master/MahAppsWindowApp/App.xaml


Make proxy port available in Consul

In cases where Fabio sits in front of an internal microservice for load-balancing or failover purposes, there's currently no good way for clients of the microservice to dynamically discover the port number they should connect to. Fabio registers its administrative / health-check port with Consul, not its proxy port(s).
Two possible approaches come to mind (not necessarily mutually exclusive):

Let the administrator configure Fabio's proxy port(s) using the Consul KV store. Then an application could query this config setting. Obviously this needs to take into account the possibility of multiple Fabio instances with different configurations sharing the same Consul service.
Have Fabio register the current listen ports in Consul at startup. A tag on the Fabio service would work, or a KV entry.

Or I guess 3. Have a machine-friendly query endpoint on the administrative listen port that a client can use to get a list of the proxy ports. Not ideal (more round trips required to discover the port number) but it would work.

The reason I didn't consider this to be an issue is that fabio shouldn't be used for routing in the backend IMHO since consul already provides the necessary tools to do this. Couldn't you register your internal microservice in consul and have your other services discover it through the consul DNS interface?
If that isn't sufficient - and I am curious about your setup - then fabio should register its listeners as services in consul to advertise the ports IMO. I wouldn't rely on configuration since this has to be managed and that opens a lot of other issues. fabio has all the information and it can publish it. The question for me remains whether it needs to.

Our use case is a bit more specific than the one I described in the issue. Fabio sits in front of a service that's used both by other components of our system (which can indeed discover the underlying service addresses directly in Consul) and third-party clients. Our application runs in AWS and the third-party clients connect through an ELB frontend that sits in front of Fabio.
The shutdown sequence from issue #242 is where I'd use this feature. When failing over to a new instance of the service I want to make sure that third-party clients are connecting to the new instance rather than the old one. Fabio is the source of truth there: if Fabio actually routes a request to the new instance, then the new instance is reachable and it's safe for the old one to deregister itself.
The ELB configuration needs to know the Fabio listen port, so there's no way to make the entire setup fully dynamic, but the fewer explicit config options I have to set the better, and this seems like the sort of thing that could be discovered at runtime.

yes, fabio could advertise its listening ports in consul or some other registry. However, the part that is missing is automating the ELB configuration based on that. So if I understand you correctly you would want to automate the ELB configuration at runtime so that when a fabio starts up it registers its listeners in consul and the magic code reconfigures the ELB to route traffic to the fabio instances. Correct?

What I'm about to suggest is for creativity purposes only and not something I'm recommending, but: if Fabio did advertise its ports back to Consul, it would be possible to Consul-template listen on the k/v, render out a Terraform config file locally, and then run Terraform to mutate the ports in an elb/alb. Locking, state sync, a whole host of issues come into play, but... if someone wanted to Rube-Goldberg up a solution it's possible.

Let the administrator configure Fabio's proxy port(s) using the Consul KV store.

This is what i do so far:
consul kv put XXX/fabio/FABIO_PROXY_ADDR <IP_ADDRESS>:9999
/usr/local/bin/envconsul -prefix=XXX/fabio -pristine /bin/bash -c '/usr/local/bin/fabio -cfg /etc/fabio.conf'

And for the nginx in front of fabio:
/usr/local/bin/envconsul -prefix=XXX/fabio -upcase -pristine -sanitize /usr/local/bin/bash -c '/usr/local/bin/envsubst < /etc/nginx/nginx.conf.tmpl > /etc/nginx/nginx.conf \$FABIO_PROXY_ADDR && /usr/local/sbin/nginx -c /etc/nginx/nginx.conf'

nginx.conf.tmpl has something like:
upstream fabio_backend {
    server ${FABIO_PROXY_ADDR};
}

No really painful, but indeed it would be easier to have fabio registering itself.


Press Left Control Twice to Activate PowerToys Run

Description of the new feature / enhancement
"Press Left Control twice" should be available as an Activation Shortcut for PowerToys Run. Selecting it would disable it as an option for the Activation Method of Find My Mouse.
Scenario when this would be used?
Activation shortcut for PowerToys Run. It matches the existing shortcut for Listary making it easier to migrate to PowerToys Run.
Supporting information
No response

/dup #3957


Spelling change

@Sirkkuw  - PR is ready for final review. This is just a simple typo issue.
Thank you.
cc: @kenwith


hvplot.hist(..., logy=True) is broken

The hvplot.hist() function cannot be used with the logy option, even when all bins are populated and therefore ought to have non-infinite log values.
ALL software version info

relevant package versions
$ conda list | grep -E 'python|numpy|^pandas|bokeh|holo|hvplot|jupyter'
bokeh                     3.4.1              pyhd8ed1ab_0    conda-forge
brotli-python             1.1.0           py312h30efb56_1    conda-forge
holoviews                 1.18.3             pyhd8ed1ab_0    conda-forge
hvplot                    0.10.0             pyhd8ed1ab_0    conda-forge
ipython                   8.24.0             pyh707e725_0    conda-forge
jupyter-lsp               2.2.5              pyhd8ed1ab_0    conda-forge
jupyter_bokeh             4.0.4              pyhd8ed1ab_0    conda-forge
jupyter_client            8.6.2              pyhd8ed1ab_0    conda-forge
jupyter_core              5.7.2           py312h7900ff3_0    conda-forge
jupyter_events            0.10.0             pyhd8ed1ab_0    conda-forge
jupyter_server            2.14.0             pyhd8ed1ab_0    conda-forge
jupyter_server_terminals  0.5.3              pyhd8ed1ab_0    conda-forge
jupyterlab                4.2.1              pyhd8ed1ab_0    conda-forge
jupyterlab_pygments       0.3.0              pyhd8ed1ab_1    conda-forge
jupyterlab_server         2.27.2             pyhd8ed1ab_0    conda-forge
jupyterlab_widgets        3.0.11             pyhd8ed1ab_0    conda-forge
libboost-python           1.82.0          py312hfb10629_6    conda-forge
libboost-python-devel     1.82.0          py312h8da182e_6    conda-forge
msgpack-python            1.0.8           py312h2492b07_0    conda-forge
neuprint-python           0.4.26+8.gd487a3c           dev_0    <develop>
numpy                     1.26.4          py312heda63a1_0    conda-forge
openmesh-python           1.2.1           py312hfb8ada1_4    flyem-forge
pandas                    2.2.2           py312h1d6d2e6_1    conda-forge
python                    3.12.3          hab00c5b_0_cpython    conda-forge
python-blosc              1.11.1          py312hfb8ada1_0    conda-forge
python-dateutil           2.9.0              pyhd8ed1ab_0    conda-forge
python-fastjsonschema     2.19.1             pyhd8ed1ab_0    conda-forge
python-json-logger        2.0.7              pyhd8ed1ab_0    conda-forge
python-snappy             0.7.1              pyh48db8ab_1    conda-forge
python-tzdata             2024.1             pyhd8ed1ab_0    conda-forge
python_abi                3.12                    4_cp312    conda-forge
types-python-dateutil     <IP_ADDRESS>40316     pyhd8ed1ab_0    conda-forge

conda info
$ conda info

     active environment : flyem-312
    active env location : /groups/flyem/proj/cluster/miniforge/envs/flyem-312
            shell level : 1
       user config file : /groups/flyem/home/bergs/.condarc
 populated config files : /groups/flyem/proj/cluster/miniforge/.condarc
          conda version : 24.5.0
    conda-build version : 24.3.0
         python version : 3.8.13.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=sapphirerapids
                          __conda=24.5.0=0
                          __glibc=2.34=0
                          __linux=5.14.0=0
                          __unix=0=0
       base environment : /groups/flyem/proj/cluster/miniforge  (writable)
      conda av data dir : /groups/flyem/proj/cluster/miniforge/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/flyem-forge/linux-64
                          https://conda.anaconda.org/flyem-forge/noarch
                          https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : /groups/flyem/proj/cluster/miniforge/pkgs
                          /groups/flyem/home/bergs/.conda/pkgs
       envs directories : /groups/flyem/proj/cluster/miniforge/envs
                          /groups/flyem/home/bergs/.conda/envs
               platform : linux-64
             user-agent : conda/24.5.0 requests/2.28.1 CPython/3.8.13 Linux/5.14.0-362.8.1.el9_3.x86_64 rocky/9.3 glibc/2.34 solver/libmamba conda-libmamba-solver/24.1.0 libmambapy/1.5.8
                UID:GID : 50328:93098
             netrc file : None
           offline mode : False

Description of expected behavior and the observed behavior
When using logy=True, no bars are shown, and a warning is given.  (See below.)
Complete, minimal, self-contained example code that reproduces the issue
import pandas as pd
import hvplot.pandas

data = pd.Series([1, 1, 2, 2, 2, 3, 3, 3])
data.hvplot.hist(bins=[0,2,4], logy=True)

Stack traceback and/or browser JavaScript console output
WARNING:param.HistogramPlot08409: Logarithmic axis range encountered value less than or equal to zero, please supply explicit lower bound to override default of 0.010.

Screenshots or screencasts of the bug in action

Thank you for the issue.
This is a limitation in Bokeh, https://github.com/bokeh/bokeh/issues/6536 and is also tracked in HoloViews here.

@hoxbro Thanks for the response.  I'm happy to close this if it's truly a duplicate of the two issues you linked to.
I'm confused, though: Those issues pertain to data with at least one empty bin.  In my case, there are no empty bins, so the minimum y-value should be non-negative, even after taking the log.
In [12]: data = [1, 1, 2, 2, 2, 3, 3, 3]
    ...: y = np.histogram(data, bins=[1,2,4])[0]
    ...: np.log(y)
Out[12]: array([0.69314718, 1.79175947])

The zero referred to is the bottom of the rectangles used for the histogram bars, not the empty space between bars.

Ah, I see.  So it's not the y-values that matter... that would be the top of the bars.  But every bar has the same bottom position, and it's 0 for all of them.
Thanks for the clarification.  Closing this.

Please don't close this issue until it will not fixed!
Now hvplot.hist(..., logy=True) is still broken.

Hi @ampilnick, I'm -1 on re-opening this issue as it is already tracked in https://github.com/holoviz/holoviews/issues/2591 and https://github.com/bokeh/bokeh/issues/6536. I have added the hvplot label to https://github.com/holoviz/holoviews/issues/2591 to let the maintainers know that this also affects hvPlot.


Foscam C1 with OpenIPC problem with WiFi

Hi,
I managed to upload the OpenIPC FW to a foscam C1. The SoC is a Hi3518eV100 and the wifi SoC is a MT7601. Well, to be honest, few things work without problems but the main issue is the WiFi. It doesn't seem to detect the onboard WiFi. Is there any way apart from dmesg to see if the WiFi is detected and how I can load a driver ?
Thanks in advance for your help.

Some wifi modules require them to be enabled specifically enabled. Do you have a multimeter by any chance?

I have similar problem with noname camera with Hi3518eV100 lite image. wlan adapter is getting power and is seen with lsusb as "148f:7601". Lite image doesn't seem to contain driver for that.
Stock kernel prints at boot:
Wifi type is mt7601
and has module named "mt7601Usta.ko"


WebWorker in three-mesh-bvh fails when using bundler

Describe the bug
When using the package as per example in the repo, it crashes cause WebWorker isn't generated/compiled correctly.
To Reproduce
Steps to reproduce the behavior:

Use any bundle like vite, parcel
Import one of the examples, I've used the interior.js from examples to illustrate.
Run on browser, notice error

Uncaught TypeError: Failed to construct 'URL': Invalid URL

Code
CodeSandbox
Live example
CodeSandbox
Expected behavior
I know web workers don't play well with bundlers when imported from a node module, but perhaps probably some solution can be found and noted in the README.md?
I've tried using an inline webworker - but that solution isn't best suited as well cause we have some three.js imports in the worker and it only works for js code can be made into a blob directly.
Screenshots and Repro Model
Not much to show here it crashes on load
Platform:

Device: MacBook Pro (16-inch, 2021)
OS: MacOS 12.3.1
GPU: Apple M1 Max
Browser: Chrome
Three.js version: 0.139.2
Library version: v0.0.1

Thanks for the report -- I'm thinking about taking the same approach as three-mesh-bvh and separating out the components that require webworkers into separate exports the user has to import them on their own if it doesn't work with their bundle system.
Ie PathTracingSceneGenerator would just be a synchronous implementation:
import { PathTracingSceneGenerator } from 'three-gpu-pathtracer';

const generator = new PathTracingSceneGenerator();
const result = generator.generate( scene );
// ...

And a new AsyncPathTracingSceneGenerator class (the class names could use some work...) would be added and imported like so (or copied and modified to a projects needs):
import { AsyncPathTracingSceneGenerator } from 'three-gpu-pathtracer/src/workers/AsyncPathTracingSceneGenerator.js';

const generator = new AsyncPathTracingSceneGenerator();
const result = await generator.generate( scene );
// ...

What do you think @ajayns? Any thoughts on better class names would be helpful, as well 😁

@ajayns just added "PathTracingSceneWorker" which will be available in the next release to separate out the worker requirements. Also updated the docs -- let me know how it looks.


Issues from visual inspection of news articles

Reported by @sdmcraft

Social icons look darker on Franklin
Extra underline below hero in Franklin
Paragraph font is different (takes more space on Franklin)
Author missing on https://main--zeiss--hlxsites.hlx.page/de/semiconductor-manufacturing-technology/news-und-events/smt-pressemeldung/verkauf-von-zeiss-itrap
Collapse block is wider on Franklin
Pressebilder section has text missing and other content differences
Bottommost dark footer is thicker in Franklin
Single image appears as carousel. It should be an image with caption.
Contact is shifted too much to left

space smaller on www.zeiss.de

Uber Zeiss section layout significantly different than on www.zeiss.de

Weiter article reading duration is incomplete and lowercase

Footer language chooser layout is broken

4. https://main--zeiss--hlxsites.hlx.page/de/semiconductor-manufacturing-technology/news-und-events/smt-pressemeldung/verkauf-von-zeiss-itrap

I can take this one cc: @sdmcraft

Pressekontact is not alligned

Missing footer for 2023 press releases

Image and text not properly formated in https://main--zeiss--hlxsites.hlx.page/de/semiconductor-manufacturing-technology/news-und-events/smt-pressemeldung/2023/zeiss-als-ehrenamtsfreundlicher-arbeitgeber-ausgezeichnet

4.

I'm happy to help with this one, but there are a lot of items here and some have the same number.
I'll start at the bottom and will look at:

Image and text not properly styled in https://main--zeiss--hlxsites.hlx.page/de/semiconductor-manufacturing-technology/news-und-events/smt-pressemeldung/ausgezeichnete-ausbildung-bei-zeiss

I'm happy to help with this one, but there are a lot of items here and some have the same number.
I'll start at the bottom and will look at:

Image and text not properly styled in https://main--zeiss--hlxsites.hlx.page/de/semiconductor-manufacturing-technology/news-und-events/smt-pressemeldung/ausgezeichnete-ausbildung-bei-zeiss

Yes, I renumbered this one to 23, you can update the comment

Mehr unter www.zeiss.de link is incorrect in collapse block.

Taking these 2
``

Reported by @sdmcraft

Social icons look darker on Franklin
Extra underline below hero in Franklin

@jindaliiita , I think 21 and 23 in the list above have been addressed. Could you please confirm and mark them as resolved referencing the ticket which fixed them?

@jindaliiita , I think 21 and 23 in the list above have been addressed. Could you please confirm and mark them as resolved referencing the ticket which fixed them?

Not Completely solved as copyright part and heading part are being tracked via https://github.com/hlxsites/zeiss/pull/132.
Rest all are done

Contact Section missing on https://main--zeiss--hlxsites.hlx.page/en/semiconductor-manufacturing-technology/news-and-events/smt-press-releases-21-Apr-23-bkp/intels-preferred-quality-supplier-award-2020.

Seems to be issue with content https://adobe.sharepoint.com/:w:/r/sites/HelixProjects/_layouts/15/Doc.aspx?sourcedoc={2FA23D80-564D-4A13-AC82-C2D08BDB12E0}&file=intels-preferred-quality-supplier-award-2020.docx&action=default&mobileredirect=true

Closing this as all the points listed here have a tracking link associated with them and can be tracked individually.


ARROW-4154: [GLib] Add GArrowDecimal128DataType

garrow_decimal_data_type_new() is deprecated.

Codecov Report

Merging #3305 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3305      +/-   ##
==========================================
- Coverage   88.56%   88.55%   -0.01%
==========================================
  Files         540      540
  Lines       73038    73036       -2
==========================================
- Hits        64685    64680       -5
- Misses       8250     8253       +3
  Partials      103      103

Impacted Files
Coverage Δ

cpp/src/arrow/csv/column-builder.cc
95.45% <0%> (-1.95%)
:arrow_down:

cpp/src/arrow/util/bpacking.h
99.84% <0%> (-0.01%)
:arrow_down:

Continue to review full report at Codecov.

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


(Mobile) Part of document text not displaying

Attach (recommended) or Link to PDF file here:
This is the same document as it appears by default on the official demo site.
compressed.tracemonkey-pldi-09.pdf
Configuration:

Web browser and its version: Chrome 109
Operating system and its version: Android 12 (Galaxy S21+)
PDF.js version: Official demo site pdfjs version (https://mozilla.github.io/pdf.js/web/viewer.html)
Is a browser extension: No

Steps to reproduce the problem:

Access PDF JS demo site on mobile
Check the default document being loaded

What is the expected behavior? (add screenshot)
a desktop screen.

What went wrong? (add screenshot)
a mobile screen.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
https://mozilla.github.io/pdf.js/web/viewer.html

Web browser and its version: Chrome 109
Operating system and its version: Android 12 (Galaxy S21+)

This unfortunately looks like a browser/platform-specific bug, rather than general PDF.js library one, since otherwise you'd really expect it to be consistently broken everywhere.
Most likely this needs to be filed, as e.g. a canvas-related bug, against the browser instead (and please keep in mind that Firefox is the primary development target here).


Keyboard shortcut support for Firefox

Extension version: 1.3.7
Browser version: Firefox 62.0<PHONE_NUMBER>3136)
Operating system: Windows 7
Problem description: Keyboard shortcut setting doesn't show up in the extension.
Actual behavior: Nothing show up when I click the keyboard shortcut in the setting page.
Expected behavior:
Reproduce step:

Looks like keyboard shortcuts definitely work! Only issue now is clicking "Keyboard Shortcuts" in the menu doesn't go anywhere. Maybe have it link to the shortcuts options? Or to the help page on how to change them?


Added onConflict to ModifyingQuery interface

updated the types.d.ts definitions to add support for the onConflict clause that was added in
https://github.com/brianc/node-sql/pull/342

probably should make a PR as well to fix the failing outdated dependencies on travis...


crud-field not working after i pulled down the Bullet Train repo on January 8th

i am brand new to bullet train and pulled the repo for sha. 2884809d5b2bbaa23d45af4a2c4f59bbdd52886b on January 8th.
the super_scaffolding crud-field options appears to be broken on this release. i have no idea if this was the right way to fix it but I was able to fix it by adding the an ARGV.shift call to bin/super_scaffold in the case statement as shown below.
diff --git a/bin/super-scaffold b/bin/super-scaffold
index 3243b70..693b418 100755
--- a/bin/super-scaffold
+++ b/bin/super-scaffold
@@ -11,6 +11,7 @@ when "crud"
ARGV.shift
nil
when "crud-field"

ARGV.shift
"field"
when "incoming-webhooks"
"incoming_webhooks"

@radamnyc What commands did you use to make the new field? I generated a new crud field without any issues with the following:
> rails g super_scaffold Project Team name:text_field
> rails g super_scaffold:field Project details:text_field
> rails db:migrate

If you have the commands and/or any error messages that would be helpful.

I just started a fresh project and tried the steps that @gazayas suggested and everything worked as expected. @radamnyc, can you provide some more info about exactly what you did when you ran into this problem?

Going to go ahead and close this one out.


Display course CRNs in schedules

Resolves #577
Rescraped 2024-2025 courses/schedules because of this.

lgtm 🚀 very nice addition


Event Documentation Improvement

Hello and thanks for your help!
I am just starting to work with the vue-fullcalendar api and I am a bit confused on how to handle events. Currently I have a test page working and I am listening to events in multiple ways. First in the custom config object, which seems to listen to native fullcalendar.io events, and using the @event-* attribute on the  element.
It dawned on me that the native events were being caught in the config object because I cannot catch drop but I can catch eventDrop(). Also I can catch select() but not eventCreated().
Looking through the code vs the wiki I would recommend clarifying that point. It would make sense that sometimes you may need to listen to native events but in general you would want to handle vue-fullcalendar events. For example, select() is being wrapped by vue-fullcalendar and jsEvent is being dropped but allDay is being added so the context of the event is not 1 to 1 with the native event.
Lastly, the api seems to mostly rethrow the args from the native event with the exception of event-created (e.g. select). I would also recommend updating the parameters on the wiki for day-click and event-selected.

Hi @steven87vt
Thanks for your advice and I am sorry that you found the docs confusing, maybe this repo does need a bit of a spring clean.
Just to manage expectations though, I am the sole maintainer of this package (despite the repo being under the ownership of my employer) and most of the work for this project is done in my own spare time. I think my priority is definitely going to be transpiling this plugin into a browser friendly .js file, as mentioned in other conversations, as I feel this will add the most value to the most people. But revisiting the docs would be my second priority.
If you would like to help speed this up, any PR's are welcome.


task: add edge config driver tests

Coverage: 88.313% (+0.6%) from 87.74% when pulling 0f906d8be0f00aa298503726438994d9c60784b2 on task/add_edge_config_driver_tests into d6a9336c707f490981b6353db1948433b08d869f on master.


NDT Localization Evaluation simulation: Autoware does not start( cannot import name 'InitializeLocalization' from 'tier4_localization_msgs.srv' )

Hi, I have followed the instructions on the quick start for the NDT Localization Evaluation https://tier4.github.io/driving_log_replayer/quick_start/localization/. When I run the simulation with this command :
/dlr simulation run -p localization  -l play_rate:=0.5, Autoware does not start. And there are ERRORs that the localization_evaluator_node cannot import InitializeLocallization:
[localization_evaluator_node.py-54] Traceback (most recent call last):
[localization_evaluator_node.py-54]   File "/home/cityuadapt/autoware/install/driving_log_replayer/lib/driving_log_replayer/localization_evaluator_node.py", line 24, in <module>
[localization_evaluator_node.py-54]     from driving_log_replayer.evaluator import DLREvaluator
[localization_evaluator_node.py-54]   File "/home/cityuadapt/autoware/install/driving_log_replayer/local/lib/python3.10/dist-packages/driving_log_replayer/evaluator.py", line 46, in <module>
[localization_evaluator_node.py-54]     from tier4_localization_msgs.srv import InitializeLocalization
[localization_evaluator_node.py-54] ImportError: cannot import name 'InitializeLocalization' from 'tier4_localization_msgs.srv' (/home/cityuadapt/autoware/install/tier4_localization_msgs/local/lib/python3.10/dist-packages/tier4_localization_msgs/srv/__init__.py)
[ERROR] [localization_evaluator_node.py-54]: process has died [pid 477756, exit code 1, cmd '/home/cityuadapt/autoware/install/driving_log_replayer/lib/driving_log_replayer/localization_evaluator_node.py --ros-args -r __node:=localization_evaluator -r __ns:=/driving_log_replayer -p use_sim_time:=True -p wheel_radius:=0.25 -p wheel_width:=0.12 -p wheel_base:=1.55 -p wheel_tread:=0.87 -p front_overhang:=0.65 -p rear_overhang:=0.6 -p left_overhang:=0.2 -p right_overhang:=0.2 -p vehicle_height:=2.4 -p max_steer_angle:=0.6 --params-file /tmp/launch_params_l4oghdyc'].
[INFO] [launch]: process[%s] was required: shutting down launched system
[INFO] [topic_state_monitor_node-58]: sending signal 'SIGINT' to process[topic_state_monitor_node-58]
[INFO] [component_container-57]: sending signal 'SIGINT' to process[component_container-57]
[INFO] [ros2-56]: sending signal 'SIGINT' to process[ros2-56]
[INFO] [sleep-55]: sending signal 'SIGINT' to process[sleep-55]
[INFO] [node-53]: sending signal 'SIGINT' to process[node-53]
[ERROR] [sleep-55]: process has died [pid 477759, exit code -2, cmd 'sleep 10.0'].
[INFO] [rviz2-52]: sending signal 'SIGINT' to process[rviz2-52]
[INFO] [component_container_mt-51]: sending signal 'SIGINT' to process[component_container_mt-51]

I have checked the files in ~/autoware/install/tier4_localization_msgs/local/lib/python3.10/dist-packages/tier4_localization_msgs/srv, The InitializeLocalization service might not exist in the tier4_localization_msgs.srv module.

And My autoware version is Autoware.Universe humble,
Ubuntu Version is 22.04,
ROS2: humble

I updated Autoware to the latest version, and this problem is solved.


[Add] Icon Resource

Site URL
https://thenounproject.com/
Description of the above provided site
The Noun Project offers the world's most diverse collection of free icons and vector images.
Category
Frontend
Sub Category
icons
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

You're assigned @Sriparno08


Create README.md

To create a company with broad Dynamics where you could use chemicals such as minerals salts and luminous phosphorus to clean the environment.

We pulled. This is the newest way and we like it. The best damn crew around. G- Unit


Correct typo in the docstring of S3Bucket class in s3.py + Add one Notebook

Correct one typo in the docstring of S3Bucket class in s3.py
Add a notebook to explore tif files from the s3

Thanks for the PR ! Nice work :)


straight.el should support local repositories anywhere on the filesystem

Currently, :local-repo is resolved in a rather naive way: namely, it's appended directly to ~/.emacs.d/straight/repos. It would be better to use expand-file-name against a default-directory of ~/.emacs.d/straight/repos, which would allow specifying an absolute path for :local-repo. See https://github.com/raxod502/straight.el/issues/128#issuecomment-322375028.
I've put this on the 1.0 milestone because it's trivial. Although in the process, I think we should use a shared method for computing local repository paths, rather than doing it ad-hoc in 20 different places.

@rgrinberg this feature is added in https://github.com/raxod502/straight.el/commit/e1b671b26cb500115820eb7fea8fdc1535f09c27.

Yay! Thanks.


I think SType::ShaderModuleWGSLDescriptor has been renamed to SType::ShaderSourceWGSL

This causes the example at hello-triangle to no longer compile

Each code comes with the version of WebGPU-distribution that it was written for (ins its webgpu directory), it should not be expected to work out-of-the-box for another version of WebGPU, because the standard is evolving too fast. As far as CI is concerned, step030 seems to compile correctly:<PHONE_NUMBER>8.
This will get better when the standard reaches v1 and thus gets stable, but for now I cannot provide day to day update of the entire guide! (Especially since in the past months the various implementations have been very desynchronized.)
Note that it is perfectly fine in practice to freeze to a given version of WebGPU. If you stick with the same distribution (and the same version of emscripten if you're targetting the web), you can maintain your project for a while. I've been maintaining projects based on a version of WebGPU that is now more than 1 year old, and I am nonetheless still able to run it on latest Chrome.
Leaving this open because I'll eventually have to make this change indeed (during the next wave of upadte). Note that I've already upgraded glfw3webgpu, in case you want to use a recent version of Dawn in a new project.


Add tls options (2.x branch)

@julianhille 2.x is no longer supported. I recommend opening new pull requests on the master branch.

i added a second one on master. I just opened it because i've got a bunch of dependencies using only @^2.0.0

Since we won't be releasing a new 2.x version, we're closing this PR in favour of https://github.com/node-fetch/node-fetch/pull/799.


Use named event parameters

The Frame V2 syntax allow events to have named parameter
#[pallet::event]
pub enum Event {
    Foo { bar: u32 },
}

Refactor out events to use the new syntax. But keep the name in docs comment until https://github.com/paritytech/substrate/pull/8615 is in.

#671


Verify that only targets that are manifest dependencies can be imported.

This change introduces a build verification step that attempts to detect scenarios where a target contains an import of another target in the package without declaring the imported target as a dependency in the manifest.
This is done via SwiftDriver's import-prescan capability which relies on libSwiftScan to quickly parse a target's sources and identify all imported modules.

@swift-ci please smoke test

cc @elsh

@swift-ci please smoke test

Oof, emitCommandLine has side-effects which change build outputs. Its usage in this PR caused several tests to fail because we're now building more than we used to.
I'm looking at how to work around this/remove these side-effects.

@swift-ci please smoke test

The current failure seems to be due to the fact that the toolchain being tested does not come with libSwiftScan, so the driver falls back on invoking the scanning action using a swift-frontend invocation, which works just as well, but causes the driver to emit an additional warning:
warning: Fallback to `swift-frontend` dependency scanner invocation

Which is not expected to be seen in some of these tests.

Together with https://github.com/apple/swift-driver/pull/731
@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please test package compatibility

@artemcm also running the compatibility test suite to make sure we dont break any packages

I don't see how the Linux self-hosted failure could be caused by the changes in this PR and I also can't reproduce them locally. I think we should still understand why they're failing even though we don't require them to pass for merging.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please test package compatibility

@swift-ci please smoke test

@swift-ci please test package compatibility

@swift-ci please smoke test

@swift-ci please test package compatibility

@swift-ci please test package compatibility

Hmm, I could not reproduce locally these source-compat failures, and now I'm seeing that they are also happening with a null-change PR:
https://github.com/apple/swift-package-manager/pull/3581
https://ci.swift.org/job/swift-package-manager-source-compat-suite-PR-macos/15/

BTW, one thing we should still discuss here is to whether these warning should only be emitted for packages with a 5.5 tools version. Generally, we want to avoid changing the behavior for older packages, though we may want to be more aggressive in this case since we are doing this to alleviate potential problems caused by the new incremental build behavior of the compiler in 5.5 which I don't think is opt-in. So it may be correct to emit warnings even for older packages since they will still be subject to the new behavior in any case.

BTW, one thing we should still discuss here is to whether these warning should only be emitted for packages with a 5.5 tools version. Generally, we want to avoid changing the behavior for older packages, though we may want to be more aggressive in this case since we are doing this to alleviate potential problems caused by the new incremental build behavior of the compiler in 5.5 which I don't think is opt-in. So it may be correct to emit warnings even for older packages since they will still be subject to the new behavior in any case.

maybe we make it conditional on the compiler version then?

maybe we make it conditional on the compiler version then?

This verification step will not run if this returns false:
SwiftTargetBuildDescription.checkSupportedFrontendFlags(flags: ["import-prescan"])

Which should match a compiler that is recent-enough to do cross-module incremental builds, which I think should be sufficient to restrict the verification only to builds subject to the new behavior.

I think should be sufficient to restrict the verification only to builds subject to the new behavior.

Yep, that sounds good to me.

@swift-ci please test package compatibility

@swift-ci please test package compatibility

@swift-ci please smoke test

@neonichu, the package compatibility suite still seems pretty unstable.
I can reproduce most of these package failures, and where I can reproduce them they also happen with a ToT main SPM. They happen at compile-time, which is after the code in this PR runs.
There are just a couple that I can't reproduce and I suspect that those must also be compilation failures (my local compilers must not match exactly the one used on the bot).
I launched another run with a null-change and it came out even worse, with many more failures:
https://ci.swift.org/job/swift-package-manager-source-compat-suite-PR-macos/19/console
Is there anything else we can do or is this good to merge?
I'm thinking that the 5.5 compatibility suite ought to be more stable so after this is in, we can try that as well.

Since we're only introducing a warning, it seems like impact on the package compatibility suite is pretty unlikely. Hopefully the 5.5 suite is more stable and I guess we should also run this more frequently in order to work out instabilities.

Hopefully the 5.5 suite is more stable and I guess we should also run this more frequently in order to work out instabilities. Does anyone remember why we aren't running it as part of smoke tests?

Only reason I can think of would be if it takes long to run.  But I agree it would be very useful, and assuming it's stable enough, it would be great to do that as a matter of course.

@swift-ci please smoke test

@swift-ci please smoke test

Periodic ping here... this has hit us again and broke users trying to play around with distributed actors because it sneaked through CI which did not validate it, nor did it show up on dev machines, since we're not using Xcode most of the time; https://github.com/apple/swift-distributed-actors/pull/981

+1
Originally this did not seem particularly important. But ever since Xcode started adding import statements behind your back, stray invalid imports have been spreading like wildfire. Consequently, this feature has rocketed to the very highest ranks of my most wanted list.

@swift-ci smoke test

Thank you very much folks!