Failed to setup/configure GW interface

Awhile back you helped me setup 5GC gnb and ue on a single host machine:
# 5G Core Network
docker compose -f sa-deploy.yaml up

# srsRAN ZMQ gNB (RF simulated)
docker compose -f srsgnb_zmq.yaml up -d && docker container attach srsgnb_zmq

# srsRAN ZMQ 5G UE (RF simulated)
docker compose -f srsue_5g_zmq.yaml up -d && docker container attach srsue_5g_zmq

That works and I can ping both in from the srsGNB to srsue containers and vice versa
However, I noticed the GW interface failing:
Opening 1 channels in RF device=zmq with args=tx_port=tcp://<IP_ADDRESS>:2001,rx_port=tcp://<IP_ADDRESS>:2000,id=ue,base_srate=23.04e6
Supported RF device list: UHD soapy bladeRF zmq file
CHx base_srate=23.04e6
CHx id=ue
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://<IP_ADDRESS>:2000
CH0 tx_port=tcp://<IP_ADDRESS>:2001
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Complete.     c-rnti=0x4601, ta=0
RRC Connected
Failed to setup/configure GW interface
RRC NR reconfiguration successful.

in the ue_5g_zmq.conf, I set the GW as so:
[gw]
netns = ue1
ip_devname = tun_srsue
ip_netmask = <IP_ADDRESS>

My end goal is to experiment configuring single/multi UE (with gnuradio), and collecting IQ data - and I assume I need the GW interface for this.

hmm..I think you setting the following in ue_5g_zmq.conf is the issue. Maybe the container does not have permission to add network namespace. But may I know why you want to configure namespace? IMO, you dont need it since UE is running in a separate container its already under separate namespace
[gw]
netns = ue1
ip_devname = tun_srsue
ip_netmask = <IP_ADDRESS>

Hm, I was trying to relate this back to the srsRAN_Project. But ultimately I want to just generate data with different parameters e.g. channel bandwidth, SNR, modulation schemes, subcarrier spacing - is this something that's do-able with with the srsRAN UE GNB setup?

But ultimately I want to just generate data with different parameters e.g. channel bandwidth, SNR, modulation schemes, subcarrier spacing

Generating traffic with different channel bandwidth, SNR, modulation schemes is possible but not different subcarrier spacing because srsRAN UE does not support anything other than 15Khz SCS.

would you happen to know or can recommend any tutorials on that generating IQ traffic with those parameters using srsRAN? Sorry a bit off-topic but I am fairly new to the space.

That works for the network traffic - but my bad, I meant recording the spectrum IQ data transmitted. I've used in the past gnuradio to visualize and record this. But not sure if this would work over docker.
# ue_5g_zmq.conf
device_args = tx_port=tcp://SRS_UE_IP:2001,rx_port=tcp://SRS_GNB_IP:2000,id=ue,base_srate=23.04e6

# gnb_zmq.conf
device_args = fail_on_disconnect=true,tx_port=tcp://SRS_ENB_IP:2000,rx_port=tcp://SRS_UE_IP:2001,id=enb,base_srate=23.04e6

Is there a way to expose this so that gnuradio can access them?
Also, I can create a separate issue as this is not related to the current one

I meant recording the spectrum IQ data transmitted

Hmm, its possible. IP and ports you give in the ue_5g_zmq.conf and gnb_zmq.conf should be the ZMQ ports opened in Gnuradio and ensure connection is complete.
I havent experimented what mentioned above but I have used Gnuradio to test SINR ramping of srsRAN_Project gNB with Amarisoft UE using a Gnuradio to vary SINR etc

@herlesupreeth
version: "3"
services:
  srsgnb_zmq:
    image: docker_srsran
    container_name: srsgnb_zmq
    stdin_open: true
    tty: true
    privileged: true
    volumes:
      - ./srsran:/mnt/srsran
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    environment:
      - COMPONENT_NAME=gnb_zmq
    ports:
      - "38412:38412/sctp"
      - "2152:2152/udp"
      - "2000:2000/tcp"
      - "2001:2001/tcp"
    networks:
      default:
        ipv4_address: ${SRS_GNB_IP}
networks:
  default:
    external:
      name: docker_open5gs_default

If I understand it right I have to change from expose to ports in order to expose it to the host so I changed that above.
However, now gnb doesnt connect.
❯ docker compose -f srsgnb_zmq.yaml up -d && docker container attach srsgnb_zmq
WARN[0000] networks.default: external.name is deprecated. Please set name and external: true
WARN[0000] Found orphan containers ([srsue_5g_zmq upf smf amf nssf bsf ausf udm udr pcf webui scp nrf mongo metrics]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
[+] Running 1/1
 ✔ Container srsgnb_zmq  Started                                                                                0.0s

The PRACH detector will not meet the performance requirements with the configuration {Format 0, ZCZ 0, SCS 1.25kHz, Rx ports 1}.
2024-04-11T19:19:47.586625 [GNB     ] [W] Could not check scaling governor. filename=/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor error="No such file or directory"
2024-04-11T19:19:47.586639 [GNB     ] [W] Could not check DRM KMS polling. filename=/sys/module/drm_kms_helper/parameters/poll error="No such file or directory"
Lower PHY in executor blocking mode.

--== srsRAN gNB (commit 55c984b55) ==--

Connecting to AMF on <IP_ADDRESS>:38412
Failed to connect SCTP socket to <IP_ADDRESS>:38412. error="Connection timed out" timeout=1362ms
srsGNB ERROR: Failed to create SCTP gateway.

If you are running srsgnb_zmq and open5gs in same machine then dont publish the SCTP ports and UDP ports
i.e. expose only the ports you want for gnuradio
ports:
      - "2000:2000/tcp"
      - "2001:2001/tcp"

Here is the laymen terms explanation of using expose or ports. You use expose if you want those ports to be use by another service running on the same machine and you use ports when you want another service running on another machine to see those ports.
So just exposing of SCTP and UDP ports between gNB and AMF/UPF is just fine since you are running both in same machine.
If you plan to run gnuradio also in same machine then expose is just fine no need to use ports for those ZMQ ports

So you mean leave it as it is expose? Cant seem access with gnuradio. This is with RRC established:

Could you check if my inputs (IP, ports) are correct?

Hey,

I havent experimented what mentioned above but I have used Gnuradio to test SINR ramping of srsRAN_Project gNB with Amarisoft UE using a Gnuradio to vary SINR etc

Here are the configurations I used to have ZMQ in between gNB and UE
At gNB
device_args: tx_port=tcp://<IP_ADDRESS>:5000,rx_port=tcp://<IP_ADDRESS>:6001
At UE
device_args = tx_port=tcp://SRS_UE_IP:6000,rx_port=tcp://SRS_GNB_IP:5001,id=ue,base_srate=23.04e6
And, in GNURadio python script I had the following lines to interconnect them
        ##################################################
        # Blocks
        ##################################################
        self.zeromq_req_source_3_0 = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://{ue_ip}:6000', 100, False, -1)
        self.zeromq_req_source_3_0.set_block_alias("UE TX")
        self.zeromq_req_source_3 = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://{gnb_ip}:5000', 100, False, -1)
        self.zeromq_req_source_3.set_block_alias("gNB TX")
        self.zeromq_rep_sink_0_0 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://{gnb_ip}:6001', 100, False, -1)
        self.zeromq_rep_sink_0_0.set_block_alias("gNB RX")
        self.zeromq_rep_sink_0 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://{ue_ip}:5001', 100, False, -1)
        self.zeromq_rep_sink_0.set_block_alias("UE RX")
        self.blocks_add_xx_0 = blocks.add_vcc(1)
        self.analog_noise_source_x_0 = analog.noise_source_c(analog.GR_GAUSSIAN, math.pow(10.0,(-12.0-self.snr)/20.0), 42)

Then, while testing the sequence of bring up is as follows:  (this sequence is very important)

First start the GNURadio
Then gNB and lastly UE

So I made those changes to the yaml, and changed to expose:
    # gnb
    expose:
      - "38412/sctp"
      - "2152/udp"
      - "5000/tcp" # tx
      - "5001/tcp" # rx

    # ue
    expose:
      - "6000/tcp" # rx
      - "6001/tcp" # tx

But now it just gets stuck (without even running gnuradio)
❯ docker compose -f srsue_5g_zmq.yaml up -d && docker container attach srsue_5g_zmq
WARN[0000] networks.default: external.name is deprecated. Please set name and external: true
WARN[0000] Found orphan containers ([srsgnb_zmq upf smf amf nssf udr pcf udm ausf bsf webui nrf metrics scp mongo]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
[+] Running 1/1
 ✔ Container srsue_5g_zmq  Started                                                                                0.4s
Active RF plugins: libsrsran_rf_uhd.so libsrsran_rf_soapy.so libsrsran_rf_blade.so libsrsran_rf_zmq.so
Inactive RF plugins:
Couldn't open , trying /root/.config/srsran/ue.conf
Couldn't open /root/.config/srsran/ue.conf either, trying /etc/srsran/ue.conf
Reading configuration file /etc/srsran/ue.conf...

Built in Release mode using commit 4eb990c9c on branch HEAD.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://<IP_ADDRESS>:6000,rx_port=tcp://<IP_ADDRESS>:5001,id=ue,base_srate=23.04e6
Supported RF device list: UHD soapy bladeRF zmq file
CHx base_srate=23.04e6
CHx id=ue
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://<IP_ADDRESS>:5001
CH0 tx_port=tcp://<IP_ADDRESS>:6000
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...

hmm.. it could be a NATing issue of docker network. Please try the following
At gNB
device_args: tx_port=tcp://<IP_ADDRESS>:5000,rx_port=tcp://*:6001
At UE
device_args = tx_port=tcp://SRS_UE_IP:6000,rx_port=tcp://*:5001,id=ue,base_srate=23.04e6
And, in GNURadio python script I had the following lines to interconnect them
        ##################################################
        # Blocks
        ##################################################
        self.zeromq_req_source_3_0 = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://*:6000', 100, False, -1)
        self.zeromq_req_source_3_0.set_block_alias("UE TX")
        self.zeromq_req_source_3 = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://*:5000', 100, False, -1)
        self.zeromq_req_source_3.set_block_alias("gNB TX")
        self.zeromq_rep_sink_0_0 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://{gnb_ip}:6001', 100, False, -1)
        self.zeromq_rep_sink_0_0.set_block_alias("gNB RX")
        self.zeromq_rep_sink_0 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://{ue_ip}:5001', 100, False, -1)
        self.zeromq_rep_sink_0.set_block_alias("UE RX")
        self.blocks_add_xx_0 = blocks.add_vcc(1)
        self.analog_noise_source_x_0 = analog.noise_source_c(analog.GR_GAUSSIAN, math.pow(10.0,(-12.0-self.snr)

Alright, I changed the gNB and UE yaml :
device_args = fail_on_disconnect=true,tx_port=tcp://<IP_ADDRESS>:5000,rx_port=tcp://*:6001
device_args = tx_port=tcp://SRS_UE_IP:6000,rx_port=tcp://*:5001,id=ue,base_srate=23.04e6

Got to the error with or without gnuradio:
Built in Release mode using commit 4eb990c9c on branch HEAD.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://<IP_ADDRESS>:6000,rx_port=tcp://*:5001,id=ue,base_srate=23.04e6
Supported RF device list: UHD soapy bladeRF zmq file
CHx base_srate=23.04e6
CHx id=ue
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://*:5001
CH0 tx_port=tcp://<IP_ADDRESS>:6000
Error: connecting receiver socket: Invalid argument
[zmq] Error: opening receiver
Error initializing radio.

        ##################################################
        # Blocks
        ##################################################
        self.zeromq_req_source_1 = zeromq.req_source(gr.sizeof_gr_complex, 1, 'tcp://*:6000', 100, False, -1)
        self.zeromq_req_source_1.set_block_alias("UE TX")
        self.zeromq_req_source_0 = zeromq.req_source(gr.sizeof_gr_complex, 1, 'tcp://*:5000', 100, False, -1)
        self.zeromq_req_source_0.set_block_alias("gNB TX")
        self.zeromq_rep_sink_1 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, 'tcp://<IP_ADDRESS>:5001', 100, False, -1)
        self.zeromq_rep_sink_1.set_block_alias("UE RX")
        self.zeromq_rep_sink_0 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, 'tcp://<IP_ADDRESS>:6001', 100, False, -1)
        self.zeromq_rep_sink_0.set_block_alias("gNB RX")

Traceback (most recent call last):
  File "/home/hud/docker_open5gs/untitled.py", line 219, in <module>
    main()
  File "/home/hud/docker_open5gs/untitled.py", line 197, in main
    tb = top_block_cls()
  File "/home/hud/docker_open5gs/untitled.py", line 82, in __init__
    self.zeromq_req_source_1 = zeromq.req_source(gr.sizeof_gr_complex, 1, 'tcp://*:6000', 100, False, -1)
RuntimeError: Invalid argument

Should Rx or Tx be * ?

gnuradio does run when I make TX * :
device_args = fail_on_disconnect=true,tx_port=tcp://*:5000,rx_port=tcp://SRS_UE_IP:6001

device_args = tx_port=tcp://*:6000,rx_port=tcp://<IP_ADDRESS>:5001,id=ue,base_srate=23.04e6

        self.zeromq_req_source_1 = zeromq.req_source(gr.sizeof_gr_complex, 1, 'tcp://<IP_ADDRESS>:6000', 100, False, -1)
        self.zeromq_req_source_1.set_block_alias("UE TX")
        self.zeromq_req_source_0 = zeromq.req_source(gr.sizeof_gr_complex, 1, 'tcp://<IP_ADDRESS>:5000', 100, False, -1)
        self.zeromq_req_source_0.set_block_alias("gNB TX")
        self.zeromq_rep_sink_1 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, 'tcp://*:5001', 100, False, -1)
        self.zeromq_rep_sink_1.set_block_alias("UE RX")
        self.zeromq_rep_sink_0 = zeromq.rep_sink(gr.sizeof_gr_complex, 1, 'tcp://*:6001', 100, False, -1)

But gets stuck at attaching again:
Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:6000,rx_port=tcp://<IP_ADDRESS>:5001,id=ue,base_srate=23.04e6
Supported RF device list: UHD soapy bladeRF zmq file
CHx base_srate=23.04e6
CHx id=ue
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://<IP_ADDRESS>:5001
CH0 tx_port=tcp://*:6000
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...

sorry, my understanding was wrong. I tested it on my end with the below diff and UE attached with GNUradio in between them
diff --git a/srsgnb_zmq.yaml b/srsgnb_zmq.yaml
index 0da47a9..2399f0e 100644
--- a/srsgnb_zmq.yaml
+++ b/srsgnb_zmq.yaml
@@ -17,8 +17,8 @@ services:
     expose:
       - "38412/sctp"
       - "2152/udp"
-      - "2000/tcp"
-      - "2001/tcp"
+      - "5000/tcp"
+      - "6001/tcp"
     networks:
       default:
         ipv4_address: ${SRS_GNB_IP}
diff --git a/srslte/ue_5g_zmq.conf b/srslte/ue_5g_zmq.conf
index 6ad33dc..c74b4fb 100644
--- a/srslte/ue_5g_zmq.conf
+++ b/srslte/ue_5g_zmq.conf
@@ -43,7 +43,7 @@ srate = 23.04e6

 # Example for ZMQ-based operation with TCP transport for I/Q samples
 device_name = zmq
-device_args = tx_port=tcp://SRS_UE_IP:2001,rx_port=tcp://SRS_GNB_IP:2000,id=ue,base_srate=23.04e6
+device_args = tx_port=tcp://*:6000,rx_port=tcp://<IP_ADDRESS>:5001,id=ue,base_srate=23.04e6

 #####################################################################
 # EUTRA RAT configuration
diff --git a/srsran/gnb_zmq.yml b/srsran/gnb_zmq.yml
index 1107d7f..670f6dd 100644
--- a/srsran/gnb_zmq.yml
+++ b/srsran/gnb_zmq.yml
@@ -4,7 +4,7 @@ amf:

 ru_sdr:
   device_driver: zmq                                                                          # The RF driver name.
-  device_args: tx_port=tcp://SRS_GNB_IP:2000,rx_port=tcp://SRS_UE_IP:2001,base_srate=23.04e6  # Optionally pass arguments to the selected RF driver.
+  device_args: tx_port=tcp://*:5000,rx_port=tcp://<IP_ADDRESS>:6001,base_srate=23.04e6  # Optionally pass arguments to the selected RF driver.
   srate: 23.04                                                                                # RF sample rate might need to be adjusted according to selected bandwidth.
   tx_gain: 75                                                                                # Transmit gain of the RF might need to adjusted to the given situation.
   rx_gain: 75                                                                                # Receive gain of the RF might need to adjusted to the given situation.
diff --git a/srsue_5g_zmq.yaml b/srsue_5g_zmq.yaml
index 75a23c7..fb402f9 100644
--- a/srsue_5g_zmq.yaml
+++ b/srsue_5g_zmq.yaml
@@ -17,8 +17,8 @@ services:
     environment:
       - COMPONENT_NAME=ue_5g_zmq
     expose:
-      - "2000/tcp"
-      - "2001/tcp"
+      - "6000/tcp"
+      - "5001/tcp"
     networks:
       default:
         ipv4_address: ${SRS_UE_IP}

And, in Gnuradio the following
        ##################################################
        # Blocks
        ##################################################
        self.zmq_source_ue_tx = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://{ue_ip}:6000', 100, False, -1)
        self.zmq_source_ue_tx.set_block_alias("UE TX")
        self.zmq_source_gnb_tx = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://{gnb_ip}:5000', 100, False, -1)
        self.zmq_source_gnb_tx.set_block_alias("gNB TX")
        self.zmq_sink_gnb_rx = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://*:6001', 100, False, -1)
        self.zmq_sink_gnb_rx.set_block_alias("gNB RX")
        self.zmq_sink_ue_rx = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://*:5001', 100, False, -1)
        self.zmq_sink_ue_rx.set_block_alias("UE RX")

Oh, you made changes in gnb_zmq.yaml but didn't change anything in the gnb_zmq.conf file?

srslte/gnb_zmq.conf is no not used at all for quite some time. For 5G RAN I completely use srsRAN_Project and not srsRAN_4G.

Ok - I got hopeful because I thought my error was not updating srsran/gnb_zmq.yaml, but I've left srslte/gnb_zmq.conf untouched, updated srsran/gnb_zmq.yaml and all that mentioned. I started gnuradio first, then core, then gnb and then UE but it is still stuck at attaching UE.
I am sure you must be extremely busy but is it possible to jump on a quick call and see what I am doing wrong?

hmm, here is the python function to initialize gnuradio flowgraph
    def __init__(self, ue_ip, gnb_ip, initial_snr_db=50):
        gr.top_block.__init__(self, "Testin with Gnuradio", catch_exceptions=True)

        ##################################################
        # Variables
        ##################################################
        self.snr_ul = initial_snr_db
        self.snr_dl = initial_snr_db

        ##################################################
        # Blocks
        ##################################################
        self.zmq_source_ue_tx = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://{ue_ip}:6000', 100, False, -1)
        self.zmq_source_ue_tx.set_block_alias("UE TX")
        self.zmq_source_gnb_tx = zeromq.req_source(gr.sizeof_gr_complex, 1, f'tcp://{gnb_ip}:5000', 100, False, -1)
        self.zmq_source_gnb_tx.set_block_alias("gNB TX")
        self.zmq_sink_gnb_rx = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://*:6001', 100, False, -1)
        self.zmq_sink_gnb_rx.set_block_alias("gNB RX")
        self.zmq_sink_ue_rx = zeromq.rep_sink(gr.sizeof_gr_complex, 1, f'tcp://*:5001', 100, False, -1)
        self.zmq_sink_ue_rx.set_block_alias("UE RX")
        self.add_block_ul = blocks.add_vcc(1)
        self.add_block_dl = blocks.add_vcc(1)
        self.awgn_source_ul = analog.noise_source_c(analog.GR_GAUSSIAN, math.pow(10.0,(-12.0-self.snr_ul)/20.0), 42)
        self.awgn_source_dl = analog.noise_source_c(analog.GR_GAUSSIAN, math.pow(10.0,(-12.0-self.snr_dl)/20.0), 42)

        ##################################################
        # Connections
        ##################################################
        # Connect UE --> gNB (UL)
        self.connect((self.awgn_source_ul, 0), (self.add_block_ul, 0))
        self.connect((self.add_block_ul, 0), (self.zmq_sink_gnb_rx, 0))
        self.connect((self.zmq_source_ue_tx, 0), (self.add_block_ul, 1))
        # Connect gNB --> UE (DL)
        self.connect((self.awgn_source_dl, 0), (self.add_block_dl, 0))
        self.connect((self.zmq_source_gnb_tx, 0), (self.add_block_dl, 1))
        self.connect((self.add_block_dl, 0), (self.zmq_sink_ue_rx, 0))

I am sure you must be extremely busy but is it possible to jump on a quick call and see what I am doing wrong?

sorry, I dont do calls

Thanks for that but the problem occurs even without gnuradio. I think I will try to reinstall everything, docker included. Can you confirm the steps - in particular do you make those diff changes above before building?
git clone https://github.com/herlesupreeth/docker_open5gs
cd docker_open5gs/base
docker build --no-cache --force-rm -t docker_open5gs .

# install 4G 5G with diff changes or as-is?
cd ../srslte
docker build --no-cache --force-rm -t docker_srslte .
cd ../srsran
docker build --no-cache --force-rm -t docker_srsran .

The above diff does not require rebuilding of images. Just re-running gNB and UE should be fine

but the problem occurs even without gnuradio

This is normal. UE wont connect to gNB without the gnuradio since there is no link. gnuradio is the connecting entity which completes the RF, in turn allowing UE to connect gNB

Here you go, I have corrected your gnuradio script. I was running the script on the host machine (not inside docker)
gnu_test.zip

Still stuck. I was trying to at least see the logs but its weird that UE logs didnt show anything - is that supposed to happen?
❯ docker exec -it srsue_5g_zmq tail -f /mnt/srslte/ue.log

❯ docker exec -it srsgnb_zmq tail -f /mnt/srsran/gnb.log
2024-04-30T15:16:26.032719 [zmq:rx:0:0] [I] Waiting for reading samples. Completed 0 of 11520 samples.
2024-04-30T15:16:26.906903 [zmq:tx:0:0] [I] Waiting for request.
2024-04-30T15:16:26.906918 [zmq:rx:0:0] [I] Waiting for data.
2024-04-30T15:16:27.033704 [zmq:rx:0:0] [I] Waiting for reading samples. Completed 0 of 11520 samples.
2024-04-30T15:16:27.906906 [zmq:tx:0:0] [I] Waiting for request.
2024-04-30T15:16:27.906920 [zmq:rx:0:0] [I] Waiting for data.
2024-04-30T15:16:28.033709 [zmq:rx:0:0] [I] Waiting for reading samples. Completed 0 of 11520 samples.
2024-04-30T15:16:28.906908 [zmq:tx:0:0] [I] Waiting for request.
2024-04-30T15:16:28.906922 [zmq:rx:0:0] [I] Waiting for data.
2024-04-30T15:16:29.033713 [zmq:rx:0:0] [I] Waiting for reading samples. Completed 0 of 11520 sampl

Could you commit your changes to the docker and share them with me?
Otherwise - is it possible to compile your version of open5gs, srsgnb and srsue all locally? Have you done this before? It seems like a lot of configs to change for core.

Still stuck. I was trying to at least see the logs but its weird that UE logs didnt show anything - is that supposed to happen?

hmm, doesnt make any sense. I tried it on my own machine with that diff applied and python script running on host machine and it worked

Could you commit your changes to the docker and share them with me?

just do git apply patch.diff

Otherwise - is it possible to compile your version of open5gs, srsgnb and srsue all locally? Have you done this before? It seems like a lot of configs to change for core.

If you want to use your own version of open5gs, srsgnb and srsue just change the git commit hash in the Dockerfile in respective folder and re-compile. Its as easy as that :)

EDIT: Could you check if the subscriber registration is correct ?

Its wrong. It should be set as OP and NOT OPc in the webui

well, was hoping setting OP would've solved it but it didnt. Not giving up yet, please bear with me.
I went down the route of manually compiling open5gs according to the tutorial with srsRAN_Project and srsRAN_4G also compiled locally - out of the box, got RRC configured with traces on both gnb and ue, and ping also works.
❯ sudo ip netns exec ue1 ip route add default via <IP_ADDRESS> dev tun_srsue
❯ sudo ip addr add <IP_ADDRESS>/24 dev ogstun # this was important
❯ sudo ip netns exec ue1 ping <IP_ADDRESS> -c4
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=32.7 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=25.3 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=35.0 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=24.6 ms

--- <IP_ADDRESS> ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

# gnb
          |--------------------DL---------------------|-------------------UL------------------------------
 pci rnti | cqi  ri  mcs  brate   ok  nok  (%)  dl_bs | pusch  mcs  brate   ok  nok  (%)    bsr    ta  phr
   1 4601 |  15   1   26    608    1    0   0%      0 |  65.5   28   7.2k    3    0   0%      0   0us  n/a
   1 4601 |  15   1   26    608    1    0   0%      0 |  65.5   28   5.8k    2    0   0%      0   0us  n/a
   1 4601 |  15   1   26    608    1    0   0%      0 |  65.5   28   7.2k    3    0   0%      0   0us  n/a
   1 4601 |  15   1   26    608    1    0   0%      0 |  65.5   28   7.2k    3    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a
   1 4601 |  15   1    0      0    0    0   0%      0 |   n/a    0      0    0    0   0%      0   0us  n/a

# ue
   ---------Signal-----------|-----------------DL-----------------|-----------UL-----------
rat  pci  rsrp   pl   cfo | mcs  snr  iter  brate  bler  ta_us | mcs   buff  brate  bler
 nr    1    44    0 -393n |   0  118   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%
 nr    1    44    0 -1.5u |   0   67   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%
 nr    1    44    0  7.5u |   0  n/a   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%
 nr    1    44    0  3.2u |  26  n/a   1.0    645    0%    0.0 |  27    0.0   7.7k    0%
 nr    1    44    0  4.4u |  26   70   1.0    639    0%    0.0 |  27    0.0   6.1k    0%
 nr    1    44    0  7.2u |  26  118   1.0    639    0%    0.0 |  27    0.0   7.6k    0%
 nr    1    44    0  6.7u |  26  n/a   1.0    639    0%    0.0 |  27    0.0   7.6k    0%
 nr    1    44    0  2.1u |   0   67   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%
 nr    1    44    0  1.3u |   0  n/a   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%
 nr    1    44    0  4.4u |   0   70   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%
 nr    1    44    0  1.2u |   0  118   0.0    0.0    0%    0.0 |   0    0.0    0.0    0%

I didnt change IPs in all the open5gs parts, just the plmn, tac according to the gnb_zmq.yaml in srsRAN_Project.
❯ grep "address: 127.0.0" /etc/open5gs/*
/etc/open5gs/amf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/amf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/amf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/ausf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/bsf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/mme.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/mme.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/mme.yaml:        - address: <IP_ADDRESS>
/etc/open5gs/mme.yaml:        - address: <IP_ADDRESS>
/etc/open5gs/mme.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/nrf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/nssf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/pcf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/pcf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/scp.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/sgwc.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/sgwc.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/sgwc.yaml:        - address: <IP_ADDRESS>
/etc/open5gs/sgwu.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/sgwu.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/smf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/smf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/smf.yaml:        - address: <IP_ADDRESS>
/etc/open5gs/smf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/smf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/smf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/udm.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/udr.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/upf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/upf.yaml:        - address: <IP_ADDRESS>
/etc/open5gs/upf.yaml:      - address: <IP_ADDRESS>
/etc/open5gs/upf.yaml:      - address: <IP_ADDRESS>

Now I updated the gnb_zmq.yaml following your diffs but to localhost:
amf:
  addr: <IP_ADDRESS> # The address or hostname of the AMF.
  bind_addr: <IP_ADDRESS> # A local IP that the gNB binds to for traffic from the AMF.

ru_sdr:
  device_driver: zmq # The RF driver name.
  # device_args: tx_port=tcp://<IP_ADDRESS>:2000,rx_port=tcp://<IP_ADDRESS>:2001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.
  device_args: tx_port=tcp://*:5000,rx_port=tcp://<IP_ADDRESS>:6001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.
  srate: 23.04 # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 75 # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 75 # Receive gain of the RF might need to adjusted to the given situation.
...

ue_zmq.conf, also to localhost:
device_name = zmq
#device_args = tx_port=tcp://<IP_ADDRESS>:2001,rx_port=tcp://<IP_ADDRESS>:2000,base_srate=23.04e6
device_args = tx_port=tcp://*:6000,rx_port=tcp://<IP_ADDRESS>:5001,base_srate=23.04e6

Ran the gnuradio, then core, updated the subscriber in webui according to srsran config, then gnb then ue:
❯ sudo gnb -c gnb_zmq.yaml

The PRACH detector will not meet the performance requirements with the configuration {Format 0, ZCZ 0, SCS 1.25kHz, Rx ports 1}.
Lower PHY in executor blocking mode.

--== srsRAN gNB (commit 2f90c8b60) ==--

Connecting to AMF on <IP_ADDRESS>:38412
Available radio types: uhd and zmq.
Cell pci=1, bw=20 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type <t> to view trace

❯ sudo srsue ue_zmq.conf
Active RF plugins: libsrsran_rf_zmq.so
Inactive RF plugins:
Reading configuration file ue_zmq.conf...

Built in Release mode using commit ec29b0c1f on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://*:6000,rx_port=tcp://<IP_ADDRESS>:5001,base_srate=23.04e6
Supported RF device list: zmq file
CHx base_srate=23.04e6
Current sample rate is 1.92 MHz with a base rate of 23.04 MHz (x12 decimation)
CH0 rx_port=tcp://<IP_ADDRESS>:5001
CH0 tx_port=tcp://*:6000
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Current sample rate is 23.04 MHz with a base rate of 23.04 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...

But it's still stuck at UE .. how would this setup go if everything is on localhost?

Ran the gnuradio, then core, updated the subscriber in webui according to srsran config, then gnb then ue:

what IPs did you pass when you ran it?
I would suggest the following
in gNB config file
ru_sdr:
  device_driver: zmq # The RF driver name.
  # device_args: tx_port=tcp://<IP_ADDRESS>:2000,rx_port=tcp://<IP_ADDRESS>:2001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.
  device_args: tx_port=tcp://<IP_ADDRESS>:5000,rx_port=tcp://<IP_ADDRESS>:6001,base_srate=23.04e6 # Optionally pass arguments to the selected RF driver.
  srate: 23.04 # RF sample rate might need to be adjusted according to selected bandwidth.
  tx_gain: 75 # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 75 # Receive gain of the RF might need to adjusted to the given situation.

in ue config file
device_name = zmq
#device_args = tx_port=tcp://<IP_ADDRESS>:2001,rx_port=tcp://<IP_ADDRESS>:2000,base_srate=23.04e6
device_args = tx_port=tcp://<IP_ADDRESS>:6000,rx_port=tcp://<IP_ADDRESS>:5001,base_srate=23.04e6

then in the gnuradio script hardcode both gnb_ip and ue_ip as <IP_ADDRESS>

@herlesupreeth sorry for the delay. the changes actually worked! Thank you so much for your help!
But I was hoping to recreate gnu-test.py with the gnuradio GUI (for visualization purposes) but it failed and not sure why. I guess I'll capture the IQ data and visualize it separately. Before I close this issue - any recommendations on how to best capture data / visualization?

Before I close this issue - any recommendations on how to best capture data / visualization

No idea. Sorry cant be of much help. :)


Thoughts on SQLMapper extending to support NoSQL - ODM - Object Document Mapper

As analytics are quite popular these days, use of NoSQL has also grown, as they also have SQL, is it worth extending the sqlmapper solution to support NoSQL ODM DBs?

By Design, This project expects well defined schema and standard sql compliance. Closing this issue


Discover server version API version dynamically

This future-proofs querying the version of a running Kubevirt instance
by dynamically determining the preferred API.
Signed-off-by: Ben Warren<EMAIL_ADDRESS>What this PR does / why we need it:
Determines the kubevirt API version on a cluster before querying the Kubevirt version info.  Without this fix, the virtctl version command fails when querying a cluster where the Kubevirt API version is older, for example v1alpha1
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
None
Release note:
NONE

Hello contributor, thanks for submitting a PR for this project!
I am the bot who triggers "standard-CI" builds for this project.
As a security measure, I will not run automated tests on PRs that are not from white-listed contributors.
In order to allow automated tests to run, please ask one of the project maintainers to review the code and then do one of the following:

Type ci test please on this PR to trigger automated tests for it.
Type ci add to whitelist on this PR to trigger automated tests for it and also add you to the contributor white-list so that your future PRs will be tested automatically.
If you are planning to contribute to more than one project, maybe it's better to ask them to add you to the project organization, so you'll be able to run tests for all the organization's projects.

@benwatcisco Unittests complains
• Failure [0.002 seconds]
Kubevirt Version Client
/root/go/src/kubevirt.io/kubevirt/pkg/kubecli/version_test.go:36
  should fetch version [It]
  /root/go/src/kubevirt.io/kubevirt/pkg/kubecli/version_test.go:48
  Path mismatch
  Expected
      <string>: /apis/subresources.kubevirt.io
  to equal
      <string>: /apis/subresources.kubevirt.io/v1alpha2/version
  /root/go/src/kubevirt.io/kubevirt/vendor/github.com/onsi/gomega/ghttp/handlers.go:39

ok to test

Updated to pass CI


feat: Added Run Widget #328

Adding Run Widget
Overview
This PR introduces a new Run Widget, which shows updates the distance to cover dynamically using a horizontal scroll bar with a smooth animation.
Screenshots/Videos

https://github.com/user-attachments/assets/4f5c7f1f-747a-4a33-8a7f-2a6a6d70ee80
Key Features

Clean UI using Tailwind CSS classes
Unit can be changed

Checklist

[x] Code follows project style guidelines
[x] Documentation has been updated
[x] Accessibility guidelines have been followed

Closes #328
Please review and let me know if any changes or additional information is needed.

@roy-abir05 Could you update padding, color, and border-radius and try to match it with the design?

@hari Please Review The Changes


⚠ Bofrost.be has degraded performance

In 2abe8db, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2343 ms

Resolved: Bofrost.be performance has improved in 1f99806.


Add integration tests for garbage-collection

Important and subtle feature - definitely deserves integration test
coverage.
Also:

run ginkgo tests in parallel by default
cleanup stale copy of some global constants

/cc @mmikulicic


Consider simplifying our PSI classes

Most of the interfaces in CeylonPsi could be removed, and instead of doing:
if (is CeylonPsi.DeclarationPsi psiElement) {
    Tree.Declaration decl = psiElement.ceylonNode;
}

we could simply do
if (is CeylonCompositeElement psiElement,
    is Tree.Declaration decl = psiElement.ceylonNode) {
}

We could leave a few exceptions:

AnyMethodPsi would satisfy PsiMethod
AnyClassPsi would satisfy PsiClass

to be able to use our own PSI elements in APIs that expect PsiClasses and PsiMethods (see https://github.com/ceylon/ceylon-ide-intellij/issues/418#issuecomment-245893644 for example).

+1.
All the value of the XxxxPsi classes is already available via the ElementType, AFAICT.


Fix for Postgres 15 & 16

Tested and works on both versions.
We also updated the README to reflect the changes in setting up the database. It had not been updated in quite some time, as it pointed to the wrong file as well.

I pulled main in because I just added a fix for the create account link a couple of hours ago after you did the PR. Make sure to start from main for the next project so you that you have everything new.


process docker events only when lb services exist

lb services are only interested in docker events
so process it only when lb services exist
Signed-off-by: rchirakk<EMAIL_ADDRESS>

fixes https://github.com/contiv/netplugin/issues/844

LGTM


add crossOrigin Options to images

I am in a use-case where I need to load ALL my images with the crossOrigin attribute set tu user-credentials.
Can't figure out how I can manage to add this attribute to the generated images ?

#85


Type system editor: uid field types cannot be references to other type names

Steps to reproduce

In Bulk Edit (or outside of Ratel), create the following schema with a type field that refers to a different type

refersTo: [uid] .
type TypeA {
  refersTo: [TypeB]
}

The type definition shows that refersTo is of type [TypeB]

When clicking on Edit Type, the predicate name along with its actual type is shown

After clicking Save, the field type turns into [uid]

Expected result:
The type definition should retain the information that refersTo references TypeB nodes.

A related issue is, as implied by Step 1, we can't create types in the UI that refer to other types by name.

https://github.com/dgraph-io/ratel/pull/123

Fixed, and type system is going to be typeless soon, so probably not needed anymore


make R.useWith a binary function

Closes #1104
The examples given for this function are quite verbose. Would you be interested in having me simplify these for you? A one line example function would make grasping it's purpose much easier.

Thanks, @syves! I far prefer the binary version of useWith. :)

The examples given for this function are quite verbose. Would you be interested in having me simplify these for you?

Absolutely! The best idea may be to propose new examples in a comment in this thread, then update the patch if people agree they're preferable. I'm fond of trivial examples rather than "realistic" examples, so you're likely to get a :+1: from me.

@syves  mind changing converge too?

@jdalton I'm happy to look into Converge, but I don't see any open issues, could you open one?

#1401

:herb:
And :+1: on better examples, too.

I consider these examples sufficient:
R.useWith(Math.pow, [R.identity, R.identity])(3, 4); //=> 81
R.useWith(Math.pow, [R.identity, R.identity])(3)(4); //=> 81
R.useWith(Math.pow, [R.dec, R.inc])(3, 4); //=> 32
R.useWith(Math.pow, [R.dec, R.inc])(3)(4); //=> 32

I updated this pr.

Thanks, @syves! I noticed one test description which should be updated. Once you've done this you'll have a :deciduous_tree: from me. :)

updated pr!

:deciduous_tree: Thanks, @syves. Lovely first contribution to Ramda!


[test-framework] Reorgnanization and linter fixes

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers: geeknoid, yutongz
Assign the PR to them by writing /assign @geeknoid @yutongz in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pkg/OWNERS
tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ozevren PTAL


Better Chinese localization

Better Chinese localization

Another part fixed. Now you can merge it.

Could you please merge it?


Added "Add repo" senario testing

This is the video of the test:
https://github.com/komodorio/helm-dashboard/assets/34707669/a3ef29c8-5d64-40e7-ace0-b91143a302ea

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (4eb1dd9) 29.85% compared to head (520d951) 29.84%.
Report is 3 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #502      +/-   ##
==========================================
- Coverage   29.85%   29.84%   -0.01%
==========================================
  Files          10       10
  Lines        1323     1330       +7
==========================================
+ Hits          395      397       +2
- Misses        887      892       +5
  Partials       41       41

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Cool!


[BACKLOG-18743] Fixed race condition, that was causing multiple CDA…

… ktr queries to fail.
@pentaho/millenniumfalcon please review

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'core' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'core' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  core/src/main/java/org/pentaho/di/core/xml/XMLFormatter.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.xml.XMLFormatter

Instruction Change: -.85%:small_red_triangle_down:
Line Change:  + .34%

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change:  + .38%
Complexity Change:  + .51%
Instruction Change:  + .08%

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change:  + 1.01%
Complexity Change:  + 1.06%
Instruction Change:  + .17%

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change:  + 1.32%
Complexity Change:  + 1.85%
Instruction Change:  + .27%

org.pentaho.di.trans.step.StepMeta

Branch Change: -.68%:small_red_triangle_down:
Complexity Change: -.58%:small_red_triangle_down:
Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.26%:small_red_triangle_down:

org.pentaho.di.trans.steps.combinationlookup.CombinationLookupMeta

Instruction Change:  + .04%

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change:  + .10%

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Branch Change:  + 1.92%
Complexity Change:  + 1.69%
Instruction Change:  + .17%

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change:  + 1.22%
Complexity Change:  + .76%
Instruction Change:  + .29%
Method Change: -1.01%:small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 1.04%
Complexity Change:  + 1.05%

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change:  + 2.00%
Complexity Change:  + 1.89%
Instruction Change:  + .17%

org.pentaho.di.trans.steps.ldapinput.LDAPInputMeta

Branch Change:  + 1.61%
Complexity Change:  + .97%
Instruction Change:  + .09%

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -2.25%:small_red_triangle_down:
Complexity Change: -2.60%:small_red_triangle_down:
Instruction Change: -.17%:small_red_triangle_down:
Line Change: -.46%:small_red_triangle_down:

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change:  + .14%

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change:  + .10%

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change:  + .18%

org.pentaho.di.trans.Trans

Branch Change: -.10%:small_red_triangle_down:
Complexity Change: -.13%:small_red_triangle_down:
Instruction Change: -.01%:small_red_triangle_down:

org.pentaho.di.trans.steps.googleanalytics.GaInputStepMeta

Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.trans.steps.salesforceupsert.SalesforceUpsertMeta

Instruction Change: -.14%:small_red_triangle_down:

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'core' -P '!assemblies' -amd clean install && mvn -B -f 'pom.xml' -pl 'core' -P '!assemblies' -amd site

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'core' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  core/src/main/java/org/pentaho/di/core/xml/XMLFormatter.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.xml.XMLFormatter

Instruction Change: -.85%:small_red_triangle_down:
Line Change:  + .34%

org.pentaho.di.core.injection.bean.BeanInjector

Branch Change:  + .79%
Complexity Change:  + 1.30%

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change: -.38%:small_red_triangle_down:
Complexity Change: -.51%:small_red_triangle_down:
Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.job.entries.ftpsget.JobEntryFTPSGet

Branch Change: -.52%:small_red_triangle_down:
Complexity Change: -.56%:small_red_triangle_down:
Instruction Change: -.07%:small_red_triangle_down:

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change:  + 3.28%
Line Change:  + 3.87%

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -.10%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change:  + .05%

org.pentaho.di.trans.steps.datagrid.DataGridMeta

Branch Change:  + 1.92%
Complexity Change:  + 1.69%
Instruction Change:  + .17%

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change:  + 1.04%
Complexity Change:  + 1.05%

org.pentaho.di.trans.steps.insertupdate.InsertUpdateMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.processfiles.ProcessFilesMeta

Branch Change: -3.57%:small_red_triangle_down:
Complexity Change: -2.13%:small_red_triangle_down:
Instruction Change: -.33%:small_red_triangle_down:

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change:  + .14%

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change:  + .17%

org.pentaho.di.trans.steps.synchronizeaftermerge.SynchronizeAfterMergeMeta

Instruction Change:  + .04%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -.53%:small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -.18%:small_red_triangle_down:

org.pentaho.di.trans.steps.googleanalytics.GaInputStepMeta

Instruction Change:  + .07%

org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change:  + .93%
Complexity Change:  + .80%
Instruction Change:  + .17%


Q&A presence for Azure service

Describe the issue
Hearing from Jon that the vendors over-promise Azure potential clients for solutions that still cant work on our SEA environment or need some other tweaking to be able to be done. So we thought of documenting all the questions that the vendors asks us and build a Q&A presence online (Stack Overflow) for clients to refer to before the connect with us so they can prep and know what to expect.
We will build cases upon the misconceptions that Vendors have that doesn't work with our environment.
Additional context

There was an existing Q&A somewhere that Emily, Gen and Sid were managing.  It's likely online so we can probably find it in our Team Wiki links

Definition of done

Jon and Bahaa to build a Team Word document for eventual publication on Stack Overflow where everyone who faces misconceptions can collaborate in adding their experiences
Review with PO
compile the information and decide on a presence to publish the information for our potential clients
Work with Julian to learn how to publish the top 5 FAQs to Stack Overflow (Julian to record video and store in team training)
Create a backlog of tickets from anything left that we haven't published

No longer relevant


Syntax highlighting bug - Whitespace control on {% endstyle %}

I have found that syntax highlighting breaks when a whitespace control hyphen is applied to the start of {% endstyle %}  tags.
It happens when applied on the left of the tag, such as {%- endstyle %} or {%- endstyle -%}.
It doesn't happen when applied on the right of the tag {% endstyle -%}.
I haven't noticed it happening with any other liquid tags.
I am running v1.3.6 of this extension with VSCode v1.64.
I have attached screenshots of the issue. The first one being typical syntax highlighting, and the second with the issue.

Fixed in v1.3.7. Should appear in your editor shortly :)

Fixed in v1.3.7. Should appear in your editor shortly :)


Add note about registering vm list types.

Fixes https://github.com/openxla/iree/issues/15251
skip-ci: comment-only change

I'm not sure this is useful here like this - every use of ref types in the VM have this requirement and we can't add this comment everywhere. All types must be registered before use (even if some happen to work today by random chance). There's nothing special about iree_vm_list_create except one user tried to call it without registering types and filed an issue.

Hmmm... good points. I don't think either of https://github.com/openxla/iree/tree/main/runtime/src/iree/vm or https://iree.dev/reference/bindings/c-api/#vm would be a good fit for this sort of note either.
Maybe the test file could have a comment here? https://github.com/openxla/iree/blob/2bfc6360063a669b60097e52fb774c62556b6b1d/runtime/src/iree/vm/list_test.cc#L156-L164


WIP - Single Transaction, multiple dex splitting / single dex & multi assets.

WIP - Single Transaction, multiple dex splitting / single dex & multi assets.
Features

Multiple assets sent in a single transaction to multiple dexs.
Multiple assets sent in a single transaction to a single dex.

Note - This is a work in progress, and will need to confirm to the future dexter architecture plans as this is a significant change.
Improvements:
Documentation for new functionality submitToDexs, improving forLiquidityPool potentially a forLiquidityPools option as this currently is not required in this example that works off > 1 pool
Usage:
const buyTransaction = await swapRequest.submitToDexs(liqudidtyPools);

Great work @dpbeaumont! 👏

The idea behind this, has been implemented into the sdk under #60 🚀


Support new GitHub Apps (formerly Integrations) API.

GitHub API Announcement:
https://developer.github.com/changes/2017-04-25-Integrations-Pre-Release/

This would be invaluable! The change for user-to-server requests appears to be adding the headers for the media type application/vnd.github.machine-man-preview+json.  I have not looked deep into the library but how difficult would this change be for a new contributor to delve into?

Skimming the docs, this would be a fair amount of work to get this up and running, but would be a fantastic learning experience. :smiley:

The Integrations API has now been deprecated in favor of the new GitHub Apps API.
This issue should now focus on the latest GitHub Developer API announcement:
https://developer.github.com/changes/2017-05-22-github-apps-production-ship/

I think they were just renamed, not deprecated. But yes, it's called GitHub Apps now.

Just on this, the Breaking Changes will need to be addressed, in particular, the integration specific events introduced in b0b867f2d5ec7c0139fad20ab0fe9267dcd8312b by @cyberdelia will need to be renamed. From my understanding, they are sending both events for the moment (and I can see they're doing this on my own installations, receiving installation_repositories and integration_installation_repositories as well as installation and integration_installation).
I'm happy to take this on in time if other's aren't. The first question would be exactly how go-github wants to handle this transition, considering both deprecated and new events appear to be supported at the moment, is the first stage simply to implement the new name and remove the old later? Or just a breaking change to rename the events?

Skimming the docs, this would be a fair amount of work to get this up and running, but would be a fantastic learning experience.

In case you hadn't seen it, I've been maintaining and using https://github.com/bradleyfalzon/ghinstallation with go-github for some time quite successfully.

In case you hadn't seen it, I've been maintaining and using https://github.com/bradleyfalzon/ghinstallation with go-github for some time quite successfully.

Do you think it's ready to be considered for addition to the README, in its own section? If so, want to send a PR that does that (and update both doc.go and README.md)?

Do you think it's ready to be considered for addition to the README, in its own section? If so, want to send a PR that does that (and update both doc.go and README.md)?

I've sent through a minor one-liner, as I did begin to write a larger section which mostly just duplicated the docs already in https://github.com/bradleyfalzon/ghinstallation, so just pared it back to a minor note. Let me know in the PR if you'd like me to expand upon the docs though, happy to.

I'm happy to take this on in time if others aren't. The first question would be exactly how go-github wants to handle this transition, considering both deprecated and new events appear to be supported at the moment, is the first stage simply to implement the new name and remove the old later? Or just a breaking change to rename the events?

I'm currently receiving the error unknown X-Github-Event in message: installation_repositories from ParseWebhook, this is the new name of the event and as mentioned previously it's a duplicate event sent by GitHub to help migration (so the event was still sent).
Potential migration strategy:

Edit eventTypeMapping to rename integration_installation and integration_installation_repositories keys (not values) to installation and installation_repositories respectively.
Rename the types IntegrationInstallationEvent and IntegrationInstallationRepositoriesEvent

Considering both of those changes could be written as a simple (for example) gofmt -w -r 'IntegrationInstallationEvent -> InstallationEvent' ./internal/github/handlers.go, and it was a preview feature, a breaking change IMHO would be fine.
Another option could include keeping the old events but parsing to the new renamed type (eg installation_repositories event parses to InstallationRepositoriesEvent), so we don't return an error and parse the old event correctly, then leave it up to the user to decide which event they want to parse and which they want to ignore. We could then continue to keep the old and new types too to have a zero breaking change migration option, and just remove the old types when GitHub stops sending them.
Thoughts or other options?

Considering both of those changes could be written as a simple (for example) gofmt -w -r 'IntegrationInstallationEvent -> InstallationEvent' ./internal/github/handlers.go, and it was a preview feature, a breaking change IMHO would be fine.

Agreed. In general, for preview APIs, we should prefer breaking API to follow suit with any changes on GitHub side.

Another option could include keeping the old events but parsing to the new renamed type (eg installation_repositories event parses to InstallationRepositoriesEvent), so we don't return an error and parse the old event correctly, then leave it up to the user to decide which event they want to parse and which they want to ignore. We could then continue to keep the old and new types too to have a zero breaking change migration option, and just remove the old types when GitHub stops sending them.

Honestly, I'll leave it up to you to decide if it's worth doing that. My suspicion is that it's okay not to, since this is still within preview API territory (if I understand correctly). So it depends on whether the benefits justify the amount of extra work.

OK, leave it with me then, I'll make the breaking change as it's easy for clients to fix, and helps keep the history clearer (single one-liners, instead of giant copy/paste).

I think they were just renamed, not deprecated. But yes, it's called GitHub Apps now.

The old ones have been removed from the documentation, but they're still being sent along with the new ones according to https://platform.github.community/t/integration-installation-hook-event-name-changed-to-installation/1830
I confirmed that both are being sent with a test app yesterday.


ImmutableList serializer registration incomplete

The ImmutableListSerializer attempts to register ImmutableList$Sublist like this
kryo.register(ImmutableList.of(1,2,3).subList(1, 2).getClass(), serializer);

However length 1 sublists are actually of type SingletonImmutableLists now so this method no longer works.

Do you want to submit a pull request?

I see the fix was merged to master but not released yet to central repos. When is the next release?

I just pushed 0.42 to maven central. Thanks for reminding! :-)


[IDE] Refactoring: Expand a ternary operator into an if statement and vice-versa

When selecting a ternary expression
let x = expression ? a : b

Suggest expanding to an if-else:
let x: Int
if expression {
    x = a
} else {
    x = b
}

And vice-versa.
Feedback is very much appreciated.
Resolves SR-5794.

Thanks for the review, @nkcsgexi ! I'll commit the fixes and get back to you ;)

@nkcsgexi I've updated the PR with the changes you suggested. Let me know what else can be improved 👍

I've fixed the issues you pointed out 👍

Before this gets merged, could you squash this patch down into maybe two or three larger commits that encompass each feature that got added here?

Hey @nkcsgexi, I've addressed your latest comments, and also squashed the changes into 2 commits. Let me know if there's anything else that needs to be improved. Thanks!

This patch looks good to me as-is! Thanks for doing this! I just wanna get one more approval from @nkcsgexi and get one last CI pass.
@swift-ci please smoke test

@nkcsgexi I've fixed one issue with the tests, could you please trigger them again?

@swift-ci please smoke test

@swift-ci please smoke test

I think all the issues should be solved, could you run the tests again, please?

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@nkcsgexi hmm, seems like it's failing because of the indentation. I thought the indentation is updated after the refactoring is applied, no? Should I just remove the indentation from the .expected files?

@romanroibu we do indent them when users are invoking refactorings through IDE. However, indentation is another operation orchestrated by source editor. In here, the expected change will only include changes from the refactoring, which doesn't include indentation : )

@swift-ci please smoke test

@romanroibu Merged! Thank you for the awesome addition to Swift refactoring!

Thank you for all the help! :)


Enhancement Request: Add default role, to add bread permission, in voyager config file

Laravel Version: 5.5.36
Voyager Version: 1.0.16
PHP Version:
Database Driver & Version:

Description:
Right now if add_bread_permission is set as true in voyager config file the role "admin" is hardcoded in AddBreadPermission.php.
IMHO it would be better to have a config setting like:
// When a BREAD is added, role to add the related Permission. 'add_bread_permission_role' => 'admin',
so that we can have in AddBreadPermission.php
$role = Role::where('name', config('voyager.add_bread_permission_role'))->firstOrFail();
and use a "superadmin" role if we wish so.
P.S.
Thanks for the great package.
Steps To Reproduce:

Added "Enhancement Request" to title

Fixed with #2993


Missing: Clef at the begining of each line

I found another limitation resolving this one and I have raised the following issue:
https://github.com/0xfe/vexflow/issues/1442


Update version to 1.4.2

:+1:

Is 1.4.2 ever going to get sent to NPM?

I think it is the same as 1.4.1. If I recall correctly, the npm release for 1.4.1 contained some extra fixes that were not supposed to be in 1.4.1, so we just called it 1.4.2.

@bunnycode there are three bugs that were fixed in between the two releases. only one of them touches the command line compiler. is #1714 what you are interested in?

so 1.4.2 milestone == 1.4.1 NPM version?

I think so, but double check with @mhegazy to be sure.

It really means Visual Studio 2015 CTP6. Which is 1.4.1 + 3 bug fixes.


Add documentation on supported markdown elements

A few short entries in the wiki about the supported markdown elements would be great.
Possibly with examples.
It's a bit difficult to extract this information from the code because of the partially complex RegExs.

Definitely! The idea is that it should just be "everything in markdown" but getting some nice examples would be a good idea


Using main.js without passing in a root should default to aurelia-app not body

Currently if you specify the main value for aurelia-app like this -

without specifying a target in the setRoot in main.js like this -
aurelia.start().then(a => a.setRoot());
The bootstrapper bootstraps the app on the body instead of the div where aurelia-app was specified.  It should default back to the DOM element with the aurelia-app attribute instead of the body.

Good catch!


Crafting menu does not work with controller shoulder buttons, exits menu instead

Using a Steam Deck and Re-Console v0.3.4. When I open the crafting menu, either through a crafting table or through the X button, using either of my shoulder buttons does not cycle through the tabs, but rather closes the crafting menu and cycles to the next/prev hotbar slot.

Try changing your Steam Input settings to a configuration that has the controller buttons maps as controller inputs only, and trackpads used a mouse input. iirc this might be called something along the lines “Controller with Touchpad Mouse”. If it’s still an issue, disable Steam Input for your launcher

#139

Thank you, apologies for the duplicate. I was searching for other issues like this but I couldn't find any, I appreciate the response!


Passing 'class-getters-and-setters' with insufficient code.

Challenge class-getters-and-setters has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
The tests for this challenge appears to not be working correctly. I was able to pass it by only typing this code:

/* Alter code below this line */
class Thermostat {

}
/* Alter code above this line */
const thermos = new Thermostat(76); // setting in Farenheit scale
let temp = thermos.temperature; // 24.44 in C
thermos.temperature = 26;
temp = thermos.temperature; // 26 in C

It appears that other people can also pass it with that code, so it's not just a problem for me. Also, when actually trying to solve it correctly it crashes, leaving this as a result:
"Maximum call stack size exceeded"
"Maximum call stack size exceeded"
"Maximum call stack size exceeded"

@AWulkan Thanks for reporting this, and for the good information to help triaging!
The ES6 challenges are known to be a bit buggy at the moment due to some problems with the transpiled code. However this particular issue is caused by the lack of tests. As you can see here, the test cases are actually nothing more than comments.
(Technically, strings evaluate to the boolean true, which makes them pass in the test framework).
I'm closing this as it's being discussed in #12698
Thanks again, and happy bug hunting! :smile:


Use schema.cds naming throughout

As reported by DJ, we were inconsistent in the way we name our schema file

cds add tiny-sample created a db/data-model.cds
cds add sample created a db/schema.cds

We settled for schema.cds for both in cds8. This should also be reflected in capire.

This is going to be published today. I hope that doesn't harm

Nope, should be fine


What are the differences between those three API

I already figured out how to call the API. and There's a csv for 'get' parameter. This csv record more than 40000 specific category of population. But I don't get the differences between those three APIs
https://api.census.gov/data/2020/acs/acs5/subject/examples.html
https://api.census.gov/data/2020/acs/acs5/profile/examples.html
https://api.census.gov/data/2020/acs/acs5/examples.html.

Each of the different endpoints you list provide slighty different data:

https://api.census.gov/data/2020/acs/acs5/subject/examples.html: Data summarized by subject
https://api.census.gov/data/2020/acs/acs5/profile/examples.html: Data summarized by profile
https://api.census.gov/data/2020/acs/acs5/examples.html: Raw data, i.e. not summarized

This page has some examples to help explain when you might want one over the other: https://www.census.gov/acs/www/guidance/which-data-tool/


Update build system to add -std=c++14

You have to update markdown-parser submodule here to test it along with snowcrash.

Merged the other PR. Please update submodule here.

@pksunkara updated submodule


Fix Score Calculation for Zero Point Programming Exercises

Checklist

[x] I tested all changes and all related features with different users (student, tutor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.
[x] Server: I added multiple integration tests (Spring) related to the features (with a high test coverage)
[x] Server: I implemented the changes with a good performance and prevented too many database calls
[x] Server: I documented the Java code using JavaDoc style.

Motivation and Context
Calculate the score of zero point programming exercises properly as well (this is common for practice-only exercises that are not graded at all). This worked before we updated the score calculation and is required for PGdP.
Manual assessment of zero point exercises (programming and in general) are out of scope for this PR.
Description

Use placeholder point value when calculating the score of a zero point programming exercise. Since it is not used for the students course score (there the exercise score is still 0), the result is only displayed better.
Adjust some charts in the client to display the values correctly.

Steps for Testing

Review the code.
Create a programming exercise with and without SCA but with points.
Check that the score calculation still works if you solve test cases (best would be to check weights and bonus points as well)
Edit the exercise to give 0 points (and no bonus points as well)
Check that the score calculation works just as before (but without you getting any points in the course for that)

Test Coverage
Unchanged.

Support for manual assessments across all exercise types will be done in a separate PR (also to avoid getting into conflicts with current rework of manual programming assessment).


Include 'cached=true' in JS API request for covidcast_meta

https://github.com/cmu-delphi/delphi-epidata/blob/8921bd0b0c196bb3e908423454e1ec089eda36d8/src/client/delphi_epidata.js#L473-L477

duplicate of #100


redirect to conversation when user click submit in Review

@alexj105 If this PR is ready to review, mind adding a description, a link to the associated JIRA ticket, and assign to someone for review? If not ready for review then we generally update the PR title and body with WIP so that folks know things are still in flux.

@alexj105 If this PR is ready, mind adding a description, a link to the associated JIRA ticket, and assign to someone for review? If not ready for review then we generally update the PR title and body with WIP so that folks know things are still in flux.

No, just create fo myself to check files, that  were changed

This LGTM but will reassign to someone on the purchase team to merge 👍 cc @lilyfromseattle


SNOW-856217: RENAME clause simplifier

Please answer these questions before submitting your pull requests. Thanks!

What GitHub issue is this PR addressing? Make sure that there is an accompanying issue to your PR.
Fixes #NNNN

Fill out the following pre-review checklist:

[ ] I am adding a new automated test(s) to verify correctness of my new code
[ ] I am adding new logging messages
[ ] I am adding a new telemetry message
[ ] I am adding new credentials
[ ] I am adding a new dependency

Please describe how your code solves the related issue.
Please write a short description of how your code change solves the related issue.

Note that EXCLUDE simplifier needs to be merged after this PR as interactions between the simplifiers needs to be considered - https://github.com/snowflakedb/snowpark-python/pull/949


Bug therankshop

Server dies when buying rank, downloaded on poggit and GitHub and same error

Please send the error/chrashdump.

Sat_Jul_1-16.37.47-UTC_2023.log

Any rank created happens this and even worse

This is your fault. You're trying to add a non-existing rank to your rankshop.

Dependency? Where do I create?


Serious Bug in Barcode detection Api **Scan the attached image to see it **

Sometimes while camera preview is open, Barcode Api detects non barcode items as barcode and returns random barcode number( detects barcode by itself without seeing any barcode image).
If you want to test this behaviour keep the camera 10 to 15 cm above the left side of MacBook Pro keyboard it detects keyboard as barcode continuously(Scan following image of keyboard to see the bug ,regardless of orientation it detects image as barcode).

This does not happen in other SDK like Scandit, i-nigma or Manatee . Just Vision Api detects wrongly; increasing preview resolution increases detection error.
here is my createcamerasource method  in barcodecapture activity class :
@SuppressLint("InlinedApi")
    private void createCameraSource(boolean autoFocus) {
        Context context = getApplicationContext();
        BarcodeDetector barcodeDetector = new BarcodeDetector.Builder(context).setBarcodeFormats(Barcode.EAN_13 | Barcode.EAN_8 | Barcode.UPC_A).build();
        this.mScanFeedback = new ScanFeedback(this);
        mScanFeedback.setBeepEnabled(true);
        barcodeDetector.setProcessor(new Detector.Processor<Barcode>() {
            @Override
            public void receiveDetections(Detector.Detections<Barcode> detections) {

                SparseArray<Barcode> barcodes = detections.getDetectedItems();
                if (barcodes != null && (barcodes.size() > 0)) {
                    String barcode =barcodes.valueAt(0).displayValue;
                    if (!barcode.isEmpty()) {
                        showBarcode(barcode);
                    }
                }
            }

            @Override
            public void release() {

            }
        });

        if (!barcodeDetector.isOperational()) {
            Toast.makeText(context, R.string.barcodeOperationalErr, Toast.LENGTH_SHORT).show();
            IntentFilter lowstorageFilter = new IntentFilter(Intent.ACTION_DEVICE_STORAGE_LOW);
            boolean hasLowStorage = registerReceiver(null, lowstorageFilter) != null;

            if (hasLowStorage) {
                Toast.makeText(this, R.string.lowStorageErr, Toast.LENGTH_LONG).show();
            }
        }

        CameraSource.Builder builder = new CameraSource.Builder(getApplicationContext(), barcodeDetector).setRequestedPreviewSize(2560, 1440)
                .setFacing(CameraSource.CAMERA_FACING_BACK);

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
            builder = builder.setFocusMode(
                    autoFocus ? Camera.Parameters.FOCUS_MODE_CONTINUOUS_PICTURE : null);
        }
        mCameraSource = builder
                .setFlashMode(Camera.Parameters.FLASH_MODE_OFF)
                .build();
        flashBtn.setOnCheckedChangeListener(new CompoundButton.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(CompoundButton compoundButton, boolean b) {
                if (b) {
                    mCameraSource.setFlashMode(Camera.Parameters.FLASH_MODE_TORCH);

                } else {
                    mCameraSource.setFlashMode(Camera.Parameters.FLASH_MODE_OFF);
                }
            }
        });
    }

Yes, I noticed that too, it just scanned my desk without any barcodes when I was explaining something to the QA a few times.

Have the same issue as @sunnyjain  mentioned . The camera is scanning weird patterns on Jeans which is not specifically a barcode.
Is it something to do with the Confidence level?


Threat numbers are dependent on editing unsaved threats.

Describe the bug:

threat numbers for next created threats are affected by just clicking unsaved threats.
Expected behavior:

It was expected for the new threats to stick to an incremental sequence when creating them and to be independent on unsaved threats the ones that get applied first get the next available threat number.
Environment:

Version: (2.2.0)
Platform: (Web App)

To Reproduce:

I believe the threat top number should only be affected when saving and creating a new threat. instead of affecting the numbers of new threats irrelevantly which may confuse end users.
Screenshot for clarification

threat 1 was created then saved then threat 0 was created and not applied then was clicked 3 times then threat 6 (should have been 2) was created and saved

thanks @mohamedselbohy , not necessarily a bug because it is supposed to do this
but it is certainly an enhancement if you want to change the behavior

Decided not go ahead with this, the desired behavior listed in #899 , so marking as "Won't Do"

reinstating this issue, because it corrects a bug in the threat creation where the threat number is always initially '0'


Game controllers detected twice on Linux when both evdev and legacy joystick API are available

Apparently, game controllers are detected twice - once for the /dev/input/jsX file, once for the /dev/input/eventX file.
Probably going to submit a patch for this soon.

I take that back, the issue was actually that the touchpad is being detected as a game controller


Fix time-zone related test failures.

Before this patch, I was getting a test failure like this:
AssertionError: expected<PHONE_NUMBER>000 to equal<PHONE_NUMBER>000

The two numbers above represent timestamps in the epoch format that are exactly
5 hours apart from each other-- the difference from laptop's native time zone
compared to UTC.
After explicitly setting the time zone to UTC, the tests pass as expected.
This issue may not manifest itself on Travis, or Vagrant Linux VMs on Mac,
which may already be natively running in UTC.
The patch only affects the tests running and doesn't affect the time zone
setting for the running application.

Hi @markstos,
I'm not sure that setting the TZ environment variable from within node itself is reliable.  It's also not clear what problem this is fixing.
It would be helpful if you could open an issue describing the problem you're having (and how to reproduce it), and explaining why this is the way to fix it.

The body of his issue accurately described the problem. What are you missing? I think the bigger problem is that the importer doesn't parse the timestamps out at UTC but I haven't dug into the code. You can see where I hit this also in the referenced issue, which I will be rebasing out later today.

What's not clear from the description, and what @jaswilli is asking about here is which tests are failing and how the decision to fix this using an env var was reached.
I believe that this is to do with the importer tests failing. This problem is due to an oversight on my part -the new importer updates are designed to support importing markdown files from Roon - and because both Roon & Ghost(Pro) run in UTC, I overlooked the need to ensure that this was enforced in the tests.
I suspect that setting process.env.TZ is not the correct fix for this, but there may be something further that has been overlooked - hence the request for more information.

That makes sense. I think either the importer isn't making sure values are saved in UTC or it's the thing returning the post for the test. Again, I haven't dug into this, it's just my assumption by the time difference.

Thanks for the prompt response in considering my patch.
The tests that can potentially from this are all the ones that hard code this particular date as magic number in the code, which are based on calculating the epoch based on the time zone the test suite is being run in:
core/test/unit/importer_spec.js:                result.data.posts[0].created_at.should.eql(1418990400000);
core/test/unit/importer_spec.js:                result.data.posts[0].created_at.should.eql(1418990400000);
core/test/unit/importer_spec.js:                result.data.posts[0].created_at.should.eql(1418990400000);
core/test/unit/importer_spec.js:                result.data.posts[0].published_at.should.eql(1418990400000);
core/test/unit/importer_spec.js:                result.data.posts[one].published_at.should.eql(1418990400000);
core/test/unit/importer_spec.js:                result.data.posts[two].created_at.should.eql(1418990400000);

It's reliable to set process.env.TZ provided that you do it just once and do so before other time-zone related code runs. That is what I've done here, and is what I have been successfully in our app in production for months. We develop in Eastern, run our servers in UTC but our app is deployed to serve   users in four time zones currently.
Declaring UTC as a default once at the very beginning of processing is less error-prone than remembering to explicitly declare UTC at every point in the code that processes code.
To try reproduce the test failure without the patch, try this:
TZ="America/New_York" grunt test-unit

You also try try modifying my patch to set process.env.TZ="America/New_York" as well.
If you instead go the route of assuming that the Markdown files you are imported have UTC times in the filename then that should be mentioned in the import docs as part of the "spec" of the importer. If third-parties are generating data to match this spec, that's an important detail to know.

Thanks for the additional information :smile:
Setting aside the issue of whether or not it's safe/reliable to set TZ in a currently running node process, what you're doing is only in effect when grunt is running the test suites.  In a "real" instance of Ghost, TZ won't be set and the importer will convert the date string from the filename into a value based on the local timezone, and we could end up with unexpected datetime values in other parts of the system.
I don't disagree with the sentiment that everyone should be running server processes in UTC but I'm not sure that hijacking TZ is the best route (for us, at least).  Someone running Ghost may have other code running alongside it and have the reasonable expectation that having properly set TZ outside of node, that the setting will be honored as is standard behavior.

@jaswilli, thanks for the reply.

what you're doing is only in effect when grunt is running the test suites.

That was intent. Like the practice using specific fixture data for
tests, setting a specific time zone for tests give you reliable and
consistent baseline time-zone for the tests.

In a "real" instance of Ghost, TZ won't be set and the importer will
convert the date string from the filename into a value based on the
local timezone, and we could end up with unexpected datetime values in
other parts of the system.

True. From what I saw of the related import ticket, there was a not a
spec yet for how to interpret the time data in Markdown file names.
Expecting that data to be UTC would certainly be convenient, as there's
not a place in the markdown import spec currently to convey time zone
data.

I don't disagree with the sentiment that everyone should be running
server processes in UTC but I'm not sure that hijacking TZ is the best
route (for us, at least). Someone running Ghost may have other code
running alongside it and have the reasonable expectation that having
properly set TZ outside of node, that the setting will be honored as is
standard behavior.

As I understand, grunt test-unit (and other test invocations) start
their own node process, run tests and shuts down the process. Any
process.env.TZ value set within would apply only to that process and
expire with the process exits at the end of the test run. I don't see
any side-effect of this affecting a running Ghost server, which is not
the same node process as any of the grunt test commands.
I was only striving to help the test suite run consistently in different
time zones, since it was failing in the Eastern time zone for me.

As I understand, grunt test-unit (and other test invocations) start
their own node process, run tests and shuts down the process. Any
process.env.TZ value set within would apply only to that process and
expire with the process exits at the end of the test run. I don't see
any side-effect of this affecting a running Ghost server, which is not
the same node process as any of the grunt test commands.

Yes, that's correct.  I was speaking in terms of fixing this issue entirely, which would require setting TZ not only when running the tests, but also when a regular instance of Ghost is running.
If you only manipulate TZ to get the test suite to pass, then you've effectively masked a bug that will surface in production.

In this case, the test was apparently /intended/ to run in UTC and explicitly setting UTC fixed that test.
If you want to explicitly test importing data from another time zone, then a test should explicitly set a specific time zone and then test for the specific offset from UTC.
Not controlling the time zone of tests is prone to producing unexpected results as just happened.  I've made the mistake before of letting tests run in the random environment of users before with similar failures as I recently found.
You can continue to discover time-zone related test suite bugs by waiting for the suite to be run in different zones, but I think setting UTC as a default for the test suite and explicitly testing for time-zone offsets when necessary will both avoid the unexpected failures like today as well as providing coverage for time-zone related issues.

There might be some merit in attempting to get the test suites to always run in a predetermined timezone but I'd have to spend some more time thinking about it.
The issue in this specific instance, as I see it, is that the importer is applying an offset to epoch time based on the local timezone (if set), but that offset isn't being recorded anywhere.  In the future when that datetime value is pulled out of the database there's no way to tell that an offset was already applied.
If we were forcing the tests to be run in an arbitrary timezone, the tests would pass but we wouldn't have discovered the issue with the importer and then we'd be hitting the bug in production instead of in testing. That's why I'm hesitant about forcing a timezone.

After thinking about this some more, I'm not able to come up with a reason why we should be forcing the tests to run in an arbitrary timezone.  Ghost should work in any timezone, and as a result, I think the test suite should pass in any timezone as well.
If anyone disagrees or has something else to add I'm happy re-open and continue the discussion.


Computation time for policy optimization

I find that the computation time for policy optimization will gradually increase, and the project is terminated by the tensorflow ResourceExhaustedError.

My guess is that this is inherently due to the very nature of Gaussian Processes. GPs keeps all the data in memory that will then be used to do a prediction. The more you run pilco the more samples will be collected and thus the prediction time will increase. If your familiar with the big O notation, gp prediction time is O(n^3) where n is the number of samples. There is some research going on to reduce this ( sparse gaussians etc) but in the overall, the more samples you have, the longer the policy optimization will be.

I think I agree with @NicolayP. You might want to use sparse gaussian processes, which are already implemented in PILCO.
Let me know if this helps with your problem.

Thank you for your help @nrontsis @NicolayP, I will try the sparse gaussian processes  PILCO


⚠ AtmoLive06 Server has degraded performance

In 16a4232, AtmoLive06 Server ($ATMOLIVE06) experienced degraded performance:

HTTP code: 200
Response time: 19392 ms

Resolved: AtmoLive06 Server performance has improved in 28c5a22.


Run population inference on treated groups with pooled PK model

[x] Fix absorption rate (check first whether it correlates strongly with other parameters, if not fixing should be ok)
[x] Pool PK model
[x] Model PD model hierarchically
[ ] Run inference on high dose group
[x] Run inference across all dose groups

Has been merged directly because changes were too large to use GitHub PR interface.
Population inference across groups has been run and looks good at first. At a second we can notice that the non-central parametrisation induces convergence issues. It's not clear yet whether the inference results can be trusted.
For now the inference seems to suggest that differences in growth patterns may entirely arise from different mutation onsets (critical volume) the growth rate itself may however be the same across individuals. This behaviour seems intuitive without detailed knowledge of the biological processes.


Update detect_new_open_s3_buckets_over_aws_cli.yml_Add condition

Add useragent to condition

Hello,
Thank you for your contribution, since there are SPL changes in your: we would like to get them tested via our detection testing service. I create a duplicate PR https://github.com/splunk/security_content/pull/1545