[Release-1.24] - Helm controller bootstrap option is broken when using port other than 6443

Backport fix for Helm controller bootstrap option is broken when using port other than 6443

#7835

Validated on Version:
-$ k3s version v1.24.15+k3s-98a18f9d (98a18f9d)

Environment Details
Infrastructure
Cloud EC2 instance
Node(s) CPU architecture, OS, and Version:
Ubuntu
Cluster Configuration:
1 node
Steps to validate the fix

Intalls k3s with server flag --https-listen {another port than default}
Deploy some helm chart
Validate pods and nodes are ok
Validate the installed por

Validation Results:

 $ curl -sfL https://get.k3s.io |   INSTALL_K3S_COMMIT=98a18f9d55c0006b6f0dbf09d5a4e263657e8a07 sh -s - server --cluster-init  --https-listen-port 6455  --write-kubeconfig-mode 644

 ~$ k3s -v
    k3s version v1.24.15+k3s-98a18f9d (98a18f9d)
    go version go1.19.10

    $ k get nodes
    NAME               STATUS   ROLES                       AGE     VERSION
    ip-172-31-22-212   Ready    control-plane,etcd,master   2m34s   v1.24.15+k3s-98a18f9d

$ k get pods -A
    NAMESPACE     NAME                                      READY   STATUS      RESTARTS   AGE
    kube-system   coredns-74448699cf-fnbhs                  1/1     Running     0          3m48s
    kube-system   helm-install-apache-m6zbt                 0/1     Completed   0          15s
    kube-system   helm-install-traefik-8bp4m                0/1     Completed   1          3m48s
    kube-system   helm-install-traefik-crd-xxt9h            0/1     Completed   0          3m48s
    kube-system   local-path-provisioner-597bc7dccd-r48rr   1/1     Running     0          3m48s
    kube-system   metrics-server-749b574fc-xm6d4            1/1     Running     0          3m48s
    kube-system   svclb-traefik-4450bfc1-fwbjb              2/2     Running     0          3m34s
    kube-system   traefik-7467b667d9-vn4cp                  1/1     Running     0          3m34s
    web           apache-66cb5795b7-bs24h                   0/2     Running     0          11s

$ kubectl describe pod -n kube-system helm-install- |grep  PORT
    KUBERNETES_SERVICE_PORT:  6456

$ cat /etc/rancher/k3s/k3s.yaml |grep 645
    server: https://<IP_ADDRESS>:6455

    ```


Add optimizer data to solaredge_local

Description:
Added sensors for optimizer data.

Average optimizer temperature
Average optimizer input voltage
Average optimizer input current
Average optimizer power (calculated with the above averages)

Added sensor for inverter temperature.
Info
This is all the data received by the API
maintenance.log
power_control.log
status.log
information.log
My to-do list:

[x] Update lib.
[x] Add sensors.
[ ] Add debug info.
[x] Add proper units.
[x] Fix Cl.
[ ] Waiting for feedback.

What to test

[ ] What happens when no optimizes are connected.
[ ] What happens when inverter is offline.
[ ] What happens when something went wrong during setup.
[ ] What happens when more then one inverter connected.
[ ] What happens to the optimizer voltage when it is night.

Problems
The solaredge-local api only gives current input in integers.
help needed for
Possible stuff people want to see.

Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[ ] I have followed the development checklist

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[x] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

Should the units for current and voltage be added in const.py

We shouldn't add units in homeassistant/const.py in this PR. That could be done in another PR if there are many integrations that use the same units.

Is it ready to merge?

At this moment it works. But i do not know is something strange happens when it gets dark and the optimizes become unavailable.

Not yet program fails when there was a bad connection to the inverter.
If that happens everything goes to 0.

Not a functional problem but would anyone hate having these large numbers or should i round the values.

We usually want to present the data as is from the device, but if the device sends data that isn't following best practices regarding significant figures, it's ok to round. Ie we shouldn't present numbers with false precision.

There are no errors anymore when the inverter is not available.
There are no errors when the sun is under.
I think it is ready to be merged.

I think it is ready to be merged
This is the final result:


Fatal error: Cannot read property '0' of undefined

I keep getting this error on a specific file "Fatal error: Cannot read property '0' of undefined". Here's my ouput:
# grunt svgmin
Running "svgmin:build" (svgmin) task
✔ _src/img/arrow.svg (saved 8 B 4%)
✔ _src/img/epl/arsenal.svg (saved 13.34 kB 53%)
✔ _src/img/epl/aston-villa.svg (saved 20.46 kB 57%)
✔ _src/img/epl/burnley.svg (saved 68.95 kB 57%)
✔ _src/img/epl/chelsea.svg (saved 48.02 kB 57%)
✔ _src/img/epl/crystal-palace.svg (saved 63.15 kB 63%)
✔ _src/img/epl/everton.svg (saved 49.35 kB 58%)
✔ _src/img/epl/hull-city.svg (saved 101.54 kB 55%)
✔ _src/img/epl/leicester-city.svg (saved 46.49 kB 56%)
✔ _src/img/epl/liverpool.svg (saved 275.76 kB 58%)
✔ _src/img/epl/manchester-city.svg (saved 99.72 kB 56%)
✔ _src/img/epl/manchester-united.svg (saved 25.04 kB 52%)
✔ _src/img/epl/newcastle-united.svg (saved 79.86 kB 56%)
✔ _src/img/epl/queens-park-rangers.svg (saved 145.98 kB 57%)
✔ _src/img/epl/southampton.svg (saved 31.6 kB 56%)
✔ _src/img/epl/stoke-city.svg (saved 25.06 kB 59%)
Fatal error: Cannot read property '0' of undefined

The next file in line is _src/img/sunderland.svg which breaks the process (i.e. if I delete the file from the folder, the process continues). If I run svgo on the file itself using svgo _src/img/epl/sunderland.svg it works just fine. So I'm not sure what the issue is.
Here's the original svg file: http://cl.ly/0w443Q3e2R1L

I saw that issue, but wasn't sure if it's the same thing? Because, as mentioned, I can run svgo file.svg and it works just fine.


BEAMS3D not producing correct results with PPPL GCC

This is for tracking a known issue reported by @pomphrey. Using the GCC version (gcc/9.3) on PPPL, the BEAMS3D executable is not able to produce correct results.
Here is a simple example. Running the input.ORBITS case in BENCHMARKS/BEAMS3D with -N 1 -n 16. The GCC version somehow gives non-sense results. The Intel version gives close results (though not exactly the same).
@lazersos Do you have any idea what causes this issue? You can find the makefile at https://github.com/PrincetonUniversity/STELLOPT/blob/develop/SHARE/make_pppl_gcc.inc

Looks like the GCC one is not calling "Trajectory Calculation".
Here is the screen output for the GCC executable.
(base) czhu@sunfire03:BEAMS3D_TEST$ debug -N 1 -n 16 xbeams3d -vmec ORBITS -plasma
BEAMS3D Version  2.70
-----  HDF5 Parameters  -----
   HDF5_version:   1.12 release: 00
-----  MPI Parameters  -----
   MPI_version:   3.01
   Open MPI v4.0.3, package: Open MPI<EMAIL_ADDRESS>Distribution, ident: 4.0.3, repo rev: v4.0.3, Mar 03, 2020
   Nproc_total:        16
   Nproc_shared:       16
----- Input Parameters -----
   FILE: input.ORBITS
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   # of Particles to Start:       40
   MAGNETIC FIELD FROM PLASMA ONLY!
----- Profile Parameters -----
   Zeff = [  1.00000,  1.00000];  NZEFF:    6
   PLASMA_MASS =    1.00728 amu
   PLASMA_ZAVG =    1.00000 <Z>
   PLASMA_ZMEAN =    1.00000 [Z]
----- VMEC Information -----
   FILE: ORBITS
   R       = [  9.00000, 11.00000]
   Z       = [-0.95106, 0.95106]
   BETA    =   0.000;  I  =  -0.636 [MA]
   AMINOR  =   1.000 [m]
   PHIEDGE =  15.700 [Wb]
   VOLUME  = 197.392 [m^3]
 -----  Vessel Information  -----
   Wall Name :  HARMONICS
   Date      :  TODAY
   Faces     :   28800

----- Constructing Splines -----
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   HERMITE FORM: 1
----- FOLLOWING PARTICLE TRAJECTORIES -----
      Method: LSODE
   Particles:        40
       Steps:     32511   Delta-t:  0.3076E-07
      NPOINC:      1000    dt_out:  0.1000E-05
         Tol:  0.1000E-07  Type: 10

----- BEAM DIAGNOSTICS -----
 BEAMLINE     ENERGY [keV]   CHARGE [e]   MASS [Mp]   Particles [#]   Lost [%]  Shinethrough [%]  Port [%]
    1             0             0             0              40         40.0          0.0          0.0

And from the Intel executable.
(base) czhu@sunfire03:BEAMS3D_TEST$ debug -N 1 -n 16 xbeams3d -vmec ORBITS -plasma
BEAMS3D Version  2.70
-----  HDF5 Parameters  -----
   HDF5_version:   1.10 release: 05
-----  MPI Parameters  -----
   MPI_version:   3.01
   Open MPI v4.0.3, package: Open MPI<EMAIL_ADDRESS>Distribution, ident: 4.0.3, repo rev: v4.0.3, Mar 03, 2020
   Nproc_total:        16
   Nproc_shared:       16
----- Input Parameters -----
   FILE: input.ORBITS
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   # of Particles to Start:       40
   MAGNETIC FIELD FROM PLASMA ONLY!
----- Profile Parameters -----
   Zeff = [  1.00000,  1.00000];  NZEFF:    6
   PLASMA_MASS =    1.00728 amu
   PLASMA_ZAVG =    1.00000 <Z>
   PLASMA_ZMEAN =    1.00000 [Z]
----- VMEC Information -----
   FILE: ORBITS
   R       = [  9.00000, 11.00000]
   Z       = [-0.95106, 0.95106]
   BETA    =   0.000;  I  =  -0.636 [MA]
   AMINOR  =   1.000 [m]
   PHIEDGE =  15.700 [Wb]
   VOLUME  = 197.392 [m^3]
 -----  Vessel Information  -----
   Wall Name :  HARMONICS
   Date      :  TODAY
   Faces     :   28800
     Plasma Field Calculation [100]%
----- Constructing Splines -----
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   HERMITE FORM: 1
----- FOLLOWING PARTICLE TRAJECTORIES -----
      Method: LSODE
   Particles:        40
       Steps:     32511   Delta-t:  0.3076E-07
      NPOINC:      1000    dt_out:  0.1000E-05
         Tol:  0.1000E-07  Type: 10
     Trajectory Calculation [  0]%
----- BEAM DIAGNOSTICS -----
 BEAMLINE     ENERGY [keV]   CHARGE [e]   MASS [Mp]   Particles [#]   Lost [%]  Shinethrough [%]  Port [%]
    1             0             0           ***              40          0.0          0.0          0.0
----- BEAMS3D DONE -----

@zhucaoxiang This is an odd behavior.  For reference I usually debug on my Mac with GCC and OpenMPI.  For production runs I'm usually on the MPCDF machines (or Cineca) which compile with Intel.  What branch was @pomphrey working on?

@lazersos The develop branch.

@lazersos :
/p/stellopt/SOURCES/stellopt_develop_gcc/bin/xbeams3d -plasma -vmec RUN12B.00515
---trying to reproduce an alpha loss calculation that Matt had previously run, using identical input and wout files

Run the BENCHMARKS with make test_beams3d in the BENCHMARKS directory and see if they pass.  If they don't then there must be an issue with the compiler options.  Do you get this for non-debug GCC runs?

I can confirm this behavior for GCC on Mac when using the debugging options in the make_pppl_gnu.inc makefile.  In fact here I don't even get as far.
lazerson@Lazersons-MacBook-Air BENCHMARKS % make test_beams3d
Beginning testing of BEAMS3D
/Applications/Xcode.app/Contents/Developer/usr/bin/make test_beams3d_basic
mpiexec -np 2 /Users/lazerson/bin/xbeams3d -vmec ORBITS -plasma
BEAMS3D Version  2.95
-----  HDF5 Parameters  -----
   HDF5_version:   1.12 release: 00
-----  MPI Parameters  -----
   MPI_version:   3.01
   Open MPI v4.1.0, package: Open MPI<EMAIL_ADDRESS>Distribution, ident: 4.1.0, repo rev: v4.1.0, Dec 18, 2020
   Nproc_total:         2
   Nproc_shared:        2
----- Input Parameters -----
   FILE: input.ORBITS
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   # of Particles to Start:       40
   MAGNETIC FIELD FROM PLASMA ONLY!
----- Profile Parameters -----
   Zeff = [  1.00000,  1.00000];  NZEFF:    6
   PLASMA_MASS =    1.00728 amu
   PLASMA_ZAVG =    1.00000 <Z>
   PLASMA_ZMEAN =    1.00000 [Z]

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x107455d3e
#1  0x10745549a
#2  0x7fff7006a5fc
#3  0x1036e1feb
#4  0x10372f808
#5  0x10372fa34
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 0 on node Lazersons-MacBook-Air exited on signal 8 (Floating point exception: 8).
--------------------------------------------------------------------------
make[1]: *** [test_beams3d_basic] Error 136
make: *** [test_beams3d] Error 2

I can confirm that the issue seems to stem from the compiler option -ffpe-trap=zero.  I suspect this is because there are times where division by zero can happen.  When this can happen we explicitly deal with the situation after the fact.  However, I need to look into this in more detail.

@lazersos Good find! So there might be a "division by zero" issue. The GCC compiler with extra debug flags catches it while the release flags just return unphysical results without errors. For Intel, there are some hidden default flags that make it work normally.

The issue came from a grid helper variable that was declared to be n sized but should really have only been n-1 sized.  As a result the nth position was never initialized.  A second helper variable was also created with the same problem, only it's value was set to the inverse of the other variable.  As a result in the nth position we got a divide by Nan.  Now this never cause a direct issue in the code since we never referenced the array beyond the n-1 position.  However the compiler flags for debug threw an error at that step.
For most situations this never caused an issue because the array element which was Nan was never reference by the code.  Except in the beams3d_init_fusion.f90 routine.  This has now been addressed.  The fix is in pull request #79. @zhucaoxiang could you approve the merge it's been sitting there a while.

@lazersos The new commits fix the error, but still on the PPPL cluster, neither using GCC nor Intel will give correct numbers when running the input.ORBITS case.

@zhucaoxiang I can't replicate the error on Macports, MPCDF, or Cincea, so I can't fix that.  The Intel results you posted look pretty close to correct. The GCC results look totally wrong, but a cursory glance at the make_pppl_gcc.inc doesn't seem to indicate anything that should cause a problem with a release build.

@lazersos This doesn't make sense. I can reproduce your results on Eddy with the Intel compiler (all True). On PPPL, the Intel version only gives about half Trues. The GCC version just returns ridiculous numbers. I will test on my laptop and also over the GitHub server.

@lazersos @pomphrey test_beams3d_basic passed on Eddy and Stellar with the Intel compiler. On my laptop with GCC-10, it was half passed.
mpirun -np 2 /Users/caoxiang/bin/xbeams3d -vmec ORBITS -plasma
BEAMS3D Version  2.95
-----  HDF5 Parameters  -----
   HDF5_version:   1.12 release: 00
-----  MPI Parameters  -----
   MPI_version:   3.01
   Open MPI v4.0.5, package: Open MPI brew@Catalina Distribution, ident: 4.0.5, repo rev: v4.0.5, Aug 26, 2020
   Nproc_total:         2
   Nproc_shared:        2
----- Input Parameters -----
   FILE: input.ORBITS
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   # of Particles to Start:       40
   MAGNETIC FIELD FROM PLASMA ONLY!
----- Profile Parameters -----
   Zeff = [  1.00000,  1.00000];  NZEFF:    6
   PLASMA_MASS =    1.00728 amu
   PLASMA_ZAVG =    1.00000 <Z>
   PLASMA_ZMEAN =    1.00000 [Z]
----- VMEC Information -----
   FILE: ORBITS
   R       = [  9.00000, 11.00000]
   Z       = [-0.95106, 0.95106]
   BETA    =    0.00;  I  =   -0.64 [MA]
   AMINOR  =    1.00 [m]
   PHIEDGE =   15.70 [Wb]
   VOLUME  =  197.39 [m^3]

----- Constructing Splines -----
   R   = [  9.00000, 11.00000];  NR:    128
   PHI = [ 0.00000, 6.28319];  NPHI:   32
   Z   = [-1.00000, 1.00000];  NZ:    128
   HERMITE FORM: 1
 -----  Vessel Information  -----
   Wall Name :  HARMONICS
   Date      :  TODAY
   Faces     :   43200
   R_WALL   = [  9.00000, 11.00000]
   Z_WALL   = [ -1.00000,  1.00000]
----- FOLLOWING PARTICLE TRAJECTORIES -----
      Method: LSODE
   Particles:        40
       Steps:     33000   Delta-t:   30.303E-09
      NPOINC:      1000    dt_out:    1.000E-06
         Tol:   10.000E-09  Type: 10

----- BEAM DIAGNOSTICS -----
 BEAMLINE     ENERGY [keV]   CHARGE [e]   MASS [Mp]   Particles [#]   Lost [%]  Shinethrough [%]  Port [%]
    1             0             1             1              40          5.0          0.0          0.0
----- BEAMS3D DONE -----
BEAMS3D VERSION: 2.950000047683716
==== Vectors ====
  turning: 0.12277330387554908   0.12275448   105%
  delta: 0.009462204370692617   0.00946046   1778%
  R0: 10.5   10.5   0%
  R1: 10.499992712044104   10.499993   0%
  R100: 10.499753912830686   10.499754   68%
  R500: 10.503794778665622   10.503795   55%
=================
  STATUS: FAIL!!!!!

@zhucaoxiang OK so this looks like the issue may just be a roundoff error.  The code is showing that the particle positions agree well after 1 time step but for some particles (probably deeply trapped) after 100 timesteps the position isn't correct.  There are a few things which could be the issue.
Can you upload the beams3d HDF5 file this run produced so I can take a look at it?  This could be related to #110.

@zhucaoxiang I suspect the issue is the -finit-real=snan option.  It seems to screw up vmec_utils.f even when I run with the -O2 flag the code runs significantly slower when calling the routines from this code.  It could be the magnetic field lookup is being messed up by said flag.

@lazersos But both on my laptop and the PPPL cluster, I was using the "release" mode. -finit-real=snan is not activated.
Attached you can find the two HDF5 files (one from my laptop with GCC-10 and the other from PPPL portal).
BTW, I am surprised that two 50-Mb-files can be compressed to 6 Mb.
beams3d.zip

@zhucaoxiang Yeah it's what I suspected.  The magnetic field grid isn't being initialized correctly:

Something odd if happening here.  What I can confirm from my end is that the tests work fine for Macports with
FLAGS_R = -O2 -g -fexternal-blas -fbacktrace -fcheck=all

The code also runs fine on Draco, Cobra, Raven, and Marconi.
The file size is probably small because the grids have quite a bit of redundancy for this axisymmetric case.

@lazersos On the PPPL cluster, I was using FLAGS_R = -O2 -fexternal-blas and on my laptop with "homebrew", I am using FLAGS_R = -O2 -fallow-argument-mismatch.

@lazersos Source of the discrepancy on my laptop is found. I changed the compiler flag from FLAGS_R = -O2 -fallow-argument-mismatch to FLAGS_R = -O2  -fallow-argument-mismatch -g -fbacktrace -fcheck=all.  Now I got all the numbers matched.
I am really surprised that -g -fbacktrace -fcheck=all makes a difference. In my understanding, they are either for debugging or for checking.
----- BEAMS3D DONE -----
BEAMS3D VERSION: 2.950000047683716
==== Vectors ====
  turning: 0.12277346481644447   0.12275448   0%
  delta: 0.009462146399886628   0.00946046   0%
  R0: 10.5   10.5   0%
  R1: 10.499992711949272   10.499993   0%
  R100: 10.499753902139718   10.499754   0%
  R500: 10.503794697358195   10.503795   0%
=================
  STATUS: PASS

@lazersos There might be something wrong with the sources. If you add one line before line 784 in vmec_utils.f to print the value of ui, you will get NaN values when checking the BENCHMARKS/BEAMS3D/input.ORBITS (probably you have to run in debugging mode). This is probably the reason why it doesn't work. Do you have any clues?
[stellar-i01n1:2290228:0:2290228] Caught signal 8 (Floating point exception: floating-point invalid operation)
 ui =                      NaN


Add Shadcnblocks.com

name: feat: add shadcnblocks.com
about: 190 premium blocks for Shadcn UI + Tailwind
labels: feature
Describe the awesome thing you want to add
What is it?
A premium collections of blocks for Shadcn
What category does it belong to? (Libs and Components, Apps, Ports, Design System, Boilerplates/Templates)
Boilerplates/Templates
Anything else? (optional) (e.g. screenshots, additional information, etc.)
Checklist

[x ] I checked that it is in alphabetical order.
[x ] I have checked that the awesome thing is not already listed.
[x] I have provided a clear and concise description of the awesome thing.
[x ] I have provided a link to the awesome thing.
[x ] I have assigned the correct category to the awesome thing.

Please note: If you are adding a new category, you will need to create a new section in the README.md file. Please make sure to update the table of contents as well.
Important: The idea of this repository is to bring together free projects for open-source contributions. If the proposed addition is an entirely paid project, the PR will be closed.

I'm closing this PR because it is an entirely paid project, the idea of the repository is to bring together free projects for open-source contributions

@birobirobiro Just to clarify our project does offer 33 free blocks - https://www.shadcnblocks.com/?price=free
They are quite high quality, See this Hero block https://www.shadcnblocks.com/block/hero32/ - The background image and icons are all decomposable. We offer more free blocks then many of the free resources...
I think you could put us in the "freemium" bucket.
Perhaps you will re-consider given this new information. If not, thats ok too.
Thank you
Rob


Sidekiq add job repeatedly

I have a task that run each 4 hours (* */4 * * *) and when this task run, Sidekiq add this job many times, Which means that my task runs many times:
2016-12-12T00:41:13.325Z 2719 TID-11np5k FetchDataWorker JID-2db7cf14e7e14ac3be5c43b0 INFO: start
2016-12-12T00:41:13.328Z 2719 TID-11m4pw INFO: Cron Jobs - add job with name: fetch_data
2016-12-12T00:41:17.882Z 2719 TID-11np5k FetchDataWorker JID-2db7cf14e7e14ac3be5c43b0 INFO: done: 4.557 sec
2016-12-12T00:42:18.159Z 2719 TID-11m7z4 FetchDataWorker JID-61639edda16ae1372df5e282 INFO: start
2016-12-12T00:42:18.162Z 2719 TID-11m4pw INFO: Cron Jobs - add job with name: fetch_data
2016-12-12T00:42:23.045Z 2719 TID-11m7z4 FetchDataWorker JID-61639edda16ae1372df5e282 INFO: done: 4.886 sec
2016-12-12T00:43:15.834Z 2719 TID-11nojc FetchDataWorker JID-8eb86df61cafbe4e11a73828 INFO: start
2016-12-12T00:43:15.837Z 2719 TID-11m4pw INFO: Cron Jobs - add job with name: fetch_data
This is my initializer:
Sidekiq.configure_server do |config|
  config.redis = { url: "redis://#{redis_config[:host]}:#{redis_config[:port]}/12" }
  schedule_file = "config/schedule.yml"
  if File.exists?(schedule_file)
    Sidekiq::Cron::Job.load_from_hash YAML.load_file(schedule_file)
  end
end

Sidekiq.configure_client do |config|
  config.redis = { url: "redis://#{redis_config[:host]}:#{redis_config[:port]}/12" }
end

Rails 4.2.6
Sidekiq 4.1.1
I use Redis in Elastic Cache of Amazon to enqueue.
If anyone has any idea of the error I would be very grateful

Hi, if you need to run task every four hours you need to use this cron line 0 /4 * * * first zero  tell run every four hours at 0 minute. Otherwise it will run every minute of hour

Thank you for your response @ondrejbartas, I thought the same, but I have another task that run with this time (* 2 * * * ) and I have the same problem:
2016-12-13T04:56:40.640Z 28168 TID-1012l0 FetchActivityWorker JID-e22094e692d5b064b007dfec INFO: done: 34.829 sec
2016-12-13T04:57:14.341Z 28168 TID-1012co YesterdayActivitiesWorker JID-34b67800cd1a906154c1f1e5 INFO: start
2016-12-13T04:57:14.344Z 28168 TID-100s74 INFO: Cron Jobs - add job with name: yesterday_activities
2016-12-13T04:57:49.959Z 28168 TID-1012co YesterdayActivitiesWorker JID-34b67800cd1a906154c1f1e5 INFO: done: 35.617 sec
2016-12-13T04:58:10.791Z 28168 TID-1012co YesterdayActivitiesWorker JID-0f093fb29a7a1fc2deb49a63 INFO: start
2016-12-13T04:58:10.794Z 28168 TID-100s74 INFO: Cron Jobs - add job with name: yesterday_activities
2016-12-13T04:58:45.280Z 28168 TID-1012co YesterdayActivitiesWorker JID-0f093fb29a7a1fc2deb49a63 INFO: done: 34.49 sec
2016-12-13T04:59:09.659Z 28168 TID-100stc YesterdayActivitiesWorker JID-dcb9faa2b784396cb921d7fd INFO: start
2016-12-13T04:59:09.662Z 28168 TID-100s74 INFO: Cron Jobs - add job with name: yesterday_activities
2016-12-13T04:59:43.982Z 28168 TID-100stc YesterdayActivitiesWorker JID-dcb9faa2b784396cb921d7fd INFO: done: 34.323 sec

Hi @faldunate again you need to set minutes

0 2 * * *

thank you @ondrejbartas  I was not realizing this mistake, I was expecting a much deeper error 😩


Possible regression in timeline semaphores on iOS in MoltenVK 1.2.10

The official Khronos timeline_semaphore sample fails on iOS when running against MoltenVK 1.2.10.  Previous versions (up to SDK 1.3.283 / MoltenVK 1.2.9) worked properly.  Same test using MoltenVK 1.2.10 on macOS Ventura 13.6.6 x86_64 seems to work properly - no regression is apparent there.  See the following pics:
iOS Simulator x86_64/iOS 17.2 and real iPhone 15/iOS 17.5.1 on MoltenVK 1.2.9:

iOS Simulator x86_64/iOS 17.2 and real iPhone 15/iOS 17.5.1 on MoltenVK 1.2.10:

After reading #2283, I decided to retest the above five samples with MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS = 0 (using the simple environment variable method for testing purposes only).  With this change the samples begin working again.
So it appears the new argument buffer code is indeed causing some issues with these specific samples.

I retested against commit ec2b23f6c9e61d8a8aa436a46a7115375d3abb11.  This seems to fix the issues on iOS running on iPhone 15 for all 5 samples listed above: timeline_semphores, 16bit_arithmetic, layout_transitions, pipeline_barriers, and subpasses.
However, there is still something lingering regarding the iOS Simulator with MoltenVK's default config settings (i.e. arg buffers enabled).  Samples timeline_semphores and 16bit_arithmetic work correctly independent of config setting, but layout_transitions, pipeline_barriers, and subpasses only work when MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS = 0. These latter three do not work with default settings.  Could there be something wrong with the default config for arg buffers when running on the iOS Simulator (e.g. should the config always be disabled)?


Mosso transporter - object has no attribute 'content_type'

Hi,
After following the INSTALL.txt instructions for installing File Conveyor via PIP, I am receiving log messages similar to the this when attempting to use the Mosso Rackspace Cloudfiles transporter:
Error: ''cStringIO.StringO' object has no attribute 'content_type''.

It seems as though this is related to a new field 'content_type' added to the version of python-cloudfiles which was automatically installed by PIP - version <IP_ADDRESS>. Is this a recognised issue? What version of the package is recommended to avoid issues with fileconveyor?
Kind regards,
James Balean

James, did you get anywhere with this yet?

Having the same issue, so would love to hear how to solve it...

Subscribe.  Same issue.  Posted an issue at Drupal.org http://drupal.org/node/1460726 as I thought it may have something to do with the CDN module however I don't believe it does anymore.  Something I would also like to note for this issue.  When I execute file conveyor with arbitrator.py.  The first lines that popup are:
/opt/fileconveyor/fileconveyor/filter.py:10: DeprecationWarning: the sets module is deprecated
from sets import Set, ImmutableSet
2012-02-29 20:38:52,016 - Arbitrator                - WARNING  - File Conveyor is initializing.
2012-02-29 20:38:52,029 - Arbitrator                - WARNING  - Loaded config file.
/usr/lib/python2.6/site-packages/django_storages-1.1.4-py2.6.egg/storages/backends/mosso.py:11: PendingDeprecationWarning: The mosso module will be deprecated in version 1.2 of django-storages. The CloudFiles code has been moved intodjango-cumulus at http://github.com/richleland/django-cumulus.
PendingDeprecationWarning)
2012-02-29 14:38:52,338 - Arbitrator                - WARNING  - Created 'mosso' transporter for the 'cloudfiles' server.
2012-02-29 14:38:52,339 - Arbitrator                - WARNING  - Server connection tests succesful!
2012-02-29 14:38:52,340 - Arbitrator                - WARNING  - Setup: created transporter pool for the 'cloudfiles' server.
2012-02-29 14:38:52,540 - Arbitrator                - WARNING  - Setup: initialized 'pipeline' persistent queue, contains 5964 items.
2012-02-29 14:38:52,541 - Arbitrator                - WARNING  - Setup: initialized 'files_in_pipeline' persistent list, contains 26 items.
2012-02-29 14:38:52,579 - Arbitrator                - WARNING  - Setup: initialized 'failed_files' persistent list, contains 3075 items.
2012-02-29 14:38:52,580 - Arbitrator                - WARNING  - Setup: initialized 'files_to_delete' persistent list, contains 0 items.
2012-02-29 14:38:52,766 - Arbitrator                - WARNING  - Setup: moved 26 items from the 'files_in_pipeline' persistent list into the 'pipeline' persistent queue.
2012-02-29 14:38:52,915 - Arbitrator                - WARNING  - Moved 20 items from the 'failed_files' persistent list into the 'pipeline' persistent queue.
2012-02-29 14:38:52,915 - Arbitrator                - WARNING  - Setup: connected to the synced files DB. Contains metadata for 0 previously synced files.
^F2012-02-29 14:38:53,343 - Arbitrator                - WARNING  - Setup: initialized FSMonitor.
2012-02-29 14:38:53,409 - Arbitrator                - WARNING  - Fully up and running now.
2012-02-29 14:38:54,472 - Arbitrator                - WARNING  - Created 'mosso' transporter for the 'cloudfiles' server.
2012-02-29 14:38:54,474 - Arbitrator                - WARNING  - Created 'mosso' transporter for the 'cloudfiles' server.

Any help from Mr. Wim Leers about this issue would be much appreciated.


Building package openssl-windows:x64-windows failed with: BUILD_FAILED while installing boost-python:x64-windows

Hi!  Please see below and attached for info.  Thank you.
Describe the bug
A clear and concise description of what the bug is.
Environment

OS: OS Name	Microsoft Windows 10 Enterprise
Version	10.0.17763 Build 17763

Compiler: revision

To Reproduce
Steps to reproduce the behavior:

.vcpkg.exe install boost-python:x64-windows
See error
Repro code when

Expected behavior
I expected the package to install.
Failure logs
-- Using source at C:/...
build-x64-windows-rel-1-err.log
build-x64-windows-rel-1-out.log
/vcpkg/buildtrees/openssl-windows/src/openssl-1-b1f8ae3e6c
-- Copying openssl release source files...
-- Copying openssl release source files... done
-- Configure x64-windows-rel
-- Configure x64-windows-rel done
-- Build x64-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: nmake -f makefile install_sw install_ssldirs
Working Directory: C:/.../vcpkg/buildtrees/openssl-windows/x64-windows-rel
Error code: 2
See logs for more information:
C:...\vcpkg\buildtrees\openssl-windows\build-x64-windows-rel-1-out.log
C:...\vcpkg\buildtrees\openssl-windows\build-x64-windows-rel-1-err.log
Call Stack (most recent call first):
ports/openssl-windows/portfile.cmake:94 (vcpkg_execute_required_process)
scripts/ports.cmake:76 (include)
Error: Building package openssl-windows:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: openssl-windows:x64-windows
Vcpkg version: 2020.02.04-nohash
Additionally, attach any relevant sections from the log files above.
C:...\vcpkg>.\vcpkg update
Using local portfile versions. To update the local portfiles, use git pull.
No packages need updating.
Additional context
I ran vcpkg update before submitting the ticket
Note I anonymized the path in one of the attached logs and above

@rowlmars,  I tried build it locally, everything built successfully for me. from you log, it seems due to the environment issue.
Could you try ./vcpkg env --triplet x64-windows --debug command and attach the output here?
Failures:
cl : Command line error D8003 : missing source filename
'Datasets\arielsmagicscript2\vcpkg\packages\openssl-windows_x64-windows""' is not recognized as an internal or external command,
operable program or batch file.
'Datasets\arielsmagicscript2\vcpkg\packages\openssl-windows_x64-windows\lib\engines-1_1""' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'cl' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.

C:...\vcpkg>vcpkg env --triplet x64-windows --debug
[DEBUG] Using vcpkg-root: C:...\vcpkg
[DEBUG] Using buildtrees-root: C:...\vcpkg\buildtrees
[DEBUG] Using downloads-root: C:...\vcpkg\downloads
[DEBUG] Using packages-root: C:...\vcpkg\packages
[DEBUG] Using installed-root: C:...\vcpkg\installed
[DEBUG] Using scripts-root: C:...\vcpkg\scripts
[DEBUG] CreateProcessW("C:...\vcpkg\downloads\tools\cmake-3.17.2-windows\cmake-3.17.2-win32-x86\bin\cmake.exe" --version)
[DEBUG] cmd_execute_and_stream_data() returned 0 after   287028 us
[DEBUG] CreateProcessW("C:...\vcpkg\downloads\tools\cmake-3.17.2-windows\cmake-3.17.2-win32-x86\bin\cmake.exe"  -P "C:/…/vcpkg/buildtrees/0.vcpkg_tags.cmake")
[DEBUG] cmd_execute_and_stream_data() returned 0 after   139555 us
[DEBUG] CreateProcessW("C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -all -prerelease -legacy -products * -format xml)
[DEBUG] cmd_execute_and_stream_data() returned 0 after   153460 us
[DEBUG] CreateProcessW(cmd /c ""C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" -vcvars_ver=14.2 amd64   2>&1 <NUL" & echo cdARN4xjKueKScMy9C6H& set)
[DEBUG] cmd_execute_and_stream_data() returned 0 after  4817950 us
[DEBUG] CreateProcessW(cmd)
Microsoft Windows [Version 10.0.17763.1217]
(c) 2018 Microsoft Corporation. All rights reserved.

Thank you @PhoebeHui

@rowlmars, sorry for the late response, does this still be a problem for you?

Double confirmed with latest source, this issue still can't be reproed, please create a new issue with full failure logs if it occurs again.


Bump all the sigstore dependencies to pick up Jake's detangling work.

Signed-off-by: Dan Lorenc<EMAIL_ADDRESS>

/lgtm


Test perun node on Ropsten testnet.

Motivation / Context

To ensure the node works with ropsten testnet.
Description

[x] Create two accounts, one each for alice and bob; fund them with a few ethers by requesting it from the faucet.
[x] Deploy the contracts using the chain command of perunnode-cli.
[x] Start the perunnode with the address of the ethclient that is connected to testnet and the addresses of the deployed contracts.
[x] Open a channel, send money on it, close it and close the session without force option.
[x] Open a channel, send money on it and force close the session so that channel is persisted. Restart the session, send money on the restored channel, close it and close the session.
[x] Write a script to automate this sequence. For reference, see api/grpc/server_integ_test.go

Relates to

Should be done after Issue 417 in go-perun is completed. That relates using EIP155 compliant signatures in the backend/ethereum/wallet package of go-perun.
Testing

The scripted test should work without any failures on the Ropsten testnet.
Thread Safety

-NA-

On Ropsten (only PoW) testnet for ethereum,

funded the following 2 accounts from faucet: 0x6b53618f2d0a0f0e8a427550892ec4780dc0a667 (alice on-chain account) and 0x79CeEBB863Dbc013Fd6D1B4553c18FD062b9E950 (bob on-chain account).
Keys for these accounts can be generated when using the helper function sessiontest.NewConfig by seeding the random number generator with 4104.

Deployed adjudicator (0x7dd2c7d72aAADaE2467b429920d2df88798CCda4) and eth asset holder (0x30241b890b0c1A2d9B6Ce3D172020647C94E2AFa) contracts using alice on-chain account as the first two transactions on the testnet. Since these contracts have been deployed using account nonces 0 and 1, the addresses will be the same when running deploying contracts on ganache-cli node during integration tests or when trying out the node.

As mentioned in the internal chat; the contract code is now available for the ropsten deployment.
AssetHolder and Adjudicator using go-perun version 27be1b2.

The contracts have been deployed on the Ropsten testnet, addresses of which can be found in the above comment.
A complete sequences of state channel transaction was carried out successfully on the testnet and the logs can be found in the contract logs by clicking on the links mentioned in the above comment.
To try out the perun node on testnet, one can use existing keys or generate new ones and fund them from a faucet. The difference is only in step 2.

Clone the repo and cd into it.
Update account addresses.
a) To use existing accounts  updating the account address and keystore path in alice/session.yaml and bob/session.yaml files that will be generated after step 4.
b) To generate new accounts,
1. Update the RandSeedForTestAccs variable in ethereumtest/chain.go to any random number of your choice.
2. The account addresses can be found at onchainaddr in alice/session.yaml and bob/session.yaml files. Request for these on testnet from the faucet and wait until these accounts are funded.
Run make to build the perunnode and perunnode-cli binaries.
In the generated artifacts, update the contracts addresses in node.yaml file, alice/session.yaml and bob/session.yaml files.
After this step, update the prepare the on-chain accounts as mentioned in step 2 and then tryout the two party payment channels using perun protocol using perunnodecli.

Script to run a test sequence can be run by modifying the contract addresses, on-chain accounts & keys in the Test_Integ_Server in api/grpc package.

Script to run a test sequence can be run by modifying the contract addresses, on-chain accounts & keys in the Test_Integ_Server in api/grpc package.


[$1000] Screen blinks when user select bank account option

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to Settings > Payments
click on Add payment method
choose bank account option

Expected Result:
screen should not blink
Actual Result:
screen blinks(shows white screen for brief second) before opening plaid screen
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] MacOS / Chrome

Version Number: 1.2.74-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/220191613-2e863fd5-0d3d-42a6-9553-64a470731769.mov
https://user-images.githubusercontent.com/43996225/220191549-63a0ca94-c28e-4428-b500-0ac6afbceac5.mp4
Expensify/Expensify Issue URL:
Issue reported by: @gadhiyamanan
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1675940935121649
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~011a37d42a300f98cb
Upwork Job ID:<PHONE_NUMBER>338414080
Last Price Increase: 2023-02-21

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Job added to Upwork: https://www.upwork.com/jobs/~011a37d42a300f98cb

Current assignee @laurenreidexpensify is eligible for the External assigner, not assigning anyone new.

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

Triggered auto assignment to @johnmlee101 (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Here are a few potential reasons why users may be seeing a blank white screen:
Incorrect or incomplete Plaid configuration: Double-check that you have properly configured Plaid in your website's code and that all necessary API keys, credentials, and settings are properly set up. Make sure you are also using the correct Plaid library and version.
Cross-origin issues: Plaid uses cross-origin resource sharing (CORS) to communicate with its servers, and if this is not properly configured on your website, it can cause issues such as a blank screen. Make sure that your CORS settings are properly configured and that Plaid is allowed to make cross-origin requests.
Javascript errors: If there are any errors in the Javascript code that loads and displays the Plaid integration, it can cause the integration to fail and display a blank screen. Check your browser's console for any Javascript errors that may be occurring.
It's important to thoroughly test your Plaid integration and ensure that it is working properly on all devices and platforms to provide a seamless experience for your users. If you're still having issues, you may want to consult Plaid's documentation or support resources for further assistance.

Hi all
The is happening on the PaidLink open action the iframe is first generated, then set display: none; and then sets display: block all this happens realy fast, most likely loading logic i has around the iframe.
I belive it should be checked with their library.

Hi, I send email to<EMAIL_ADDRESS>to get invited in slack. but did not get the response yet.
Can anyone help me?
Thanks.

📣 @devmaxkyu! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

Hey just wondering do you have my contributor details?

📣 @aadib0045tya! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

Contributor Details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile : https://www.upwork.com/freelancers/~0141bbcbaecc47707e

Also how can i test the solution by placing my code

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01462cfa23f89fbdf5

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

Mine too ?

Contributor Details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile : https://www.upwork.com/freelancers/~0141bbcbaecc47707e

This blank screen is on Plaid end. Not sure if it can be fixed in Expensify. Already tried lazy-loading and Suspense too but the issue is not at our end.

📣 @nishchay7pixels! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

 You'll only have to do this once, and this is how we'll hire you on Upwork. Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

Contributor Details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile : https://www.upwork.com/freelancers/~0141bbcbaecc47707e

@aadib0045tya you need to copy paste it explicitly. Here's the format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

you changed this line:
Upwork Profile Link: to Upwork Profile : which is incorrect

⚠ Missing/invalid email or upwork profile link. Please make sure you add both your Expensify email and Upwork profile link in the format specified.

Contributor Details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~0141bbcbaecc47707e

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

@aadib0045tya do you have a proposed solution to resolve this issue?

The is happening on the PaidLink open action the iframe is first generated, then set display: none; and then sets display: block all this happens realy fast, most likely loading logic i has around the iframe.
I belive it should be checked with their library.

Waiting for proposals.

Triggered auto assignment to @twisterdotcom (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Triggered auto assignment to @lschurr (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

@lschurr can you take over this one while I focus on the ECX launch next week? Unassigned Melvin's first pick Ted cos he's busy with QBC next week

We're still waiting on proposals for this one, is that right @johnmlee101 and @mananjadhav?

@mananjadhav @johnmlee101 @lschurr this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

@mananjadhav @johnmlee101 @lschurr this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

📣 @HezekielT! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

Proposal
Please re-state the problem that we are trying to solve in this issue.
When bank account option is selected, the screen goes blank once before fully loading the plaid login flow.
What is the root cause of that problem?
As stated in the official docs of plaid https://plaid.com/docs/link/web/#link-web-create-onLoad

A function that is called when the Link module has finished loading. Calls to plaidLinkHandler.open() prior to the onLoad callback will be delayed until the module is fully loaded.

Inside useEffect we are not waiting before the plaid is fully loaded, and calling open.
https://github.com/Expensify/App/blob/7e8e8a1d881914abe7c13768eb13e4930cb8546b/src/components/PlaidLink/index.js#L37
What changes do you think we should make in order to solve the problem?

We can add a state variable to track loading state, and only call open when plaid has fully loaded.
         const [isLoaded, setIsLoaded] = useState(false);

        onEvent: (event, metadata) => {
            Log.info('[PlaidLink] Event: ', false, {event, metadata});
        },
        // add this option to track loading state
        onLoad: () => setIsLoaded(true),

        if (!ready) {
            return;
        }
        // prevent calling open before the module is fully loaded
        if (!isLoaded) {
            return;
        }

What alternative solutions did you explore? (Optional)
None

Thanks for the proposals folks.  I think @mdneyazahmad's proposal is better as it relies on the event received from Plaid vs @HezekielT's proposal of using setTimeout.
@mdneyazahmad's proposal here is good to go.
cc - @johnmlee101

Adding my 2 cents here to explain the root cause more detail:
https://github.com/plaid/react-plaid-link/blob/319c81c413ef12624498aa1624c20151f19dc8ae/src/usePlaidLink.ts#L86
  const ready = plaid != null && (!loading || iframeLoaded);

There are 3 factors to determine ready flag.
If loading=false, ready is already true even if iframeLoaded=false (plaid frame is not fully loaded yet) and this is the main root cause.
iframeLoaded is set to true on load here, followed by onLoad call.
        onLoad: () => {
          setIframeLoaded(true);
          options.onLoad && options.onLoad();
        },

So @mdneyazahmad's solution is correct to open only after onLoad is called which means iframeLoaded=true.

Thanks @mananjadhav, I think I agree as well. Going to assign!

📣 @mdneyazahmad You have been assigned to this job by @johnmlee101!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑💻
Keep in mind: Code of Conduct | Contributing 📖

@mananjadhav https://github.com/Expensify/App/pull/15752 ready for review.

Reviewing label has been removed, please complete the "BugZero Checklist".

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.2.82-4 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/15752

If no regressions arise, payment will be issued on 2023-03-20. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

[ ] External issue reporter
[ ] Contributor that fixed the issue
[ ] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

Merged PR within 3 business days of assignment - 50% bonus
Merged PR more than 9 business days after assignment - 50% penalty

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@mananjadhav / @johnmlee101] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@mananjadhav / @johnmlee101] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@mananjadhav / @johnmlee101] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [@lschurr] Determine if we should create a regression test for the bug.
[ ] [@mananjadhav] If we decide to create a regression test for the bug, please propose the regression test steps to the appropriate location to ensure the same bug will not reach production again.
[ ] [@lschurr] Review the proposed regression test steps and location.
[ ] [@lschurr] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

Looks like something related to react-navigation may have been mentioned in this issue discussion.
As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.
Feel free to drop a note in #expensify-open-source with any questions.

This wasn't a regression, mostly lack of functionality that was built out to make the transition screen better.

Here's the regression test proposal

Open the app and go to Settings
Click on Payments -> Add Payment Method
Select "Bank Account"
Verify that that connection to plaid page shouldn't flicker/blink.
It should show up the plaid page, without loading a white blank screen/chat screen.

Do we agree 👍 or 👎  ?
@johnmlee101 @mdneyazahmad

👍 looks great!

Thanks @mananjadhav - I'll get that added!

@mdneyazahmad - I sent the offer in Upwork, can you accept?
@mananjadhav - Could you apply for the job as well? https://www.upwork.com/jobs/~011a37d42a300f98cb

@gadhiyamanan - can you also apply for the $250 reporting bonus? https://www.upwork.com/jobs/~011a37d42a300f98cb

@lschurr applied and I think this is eligible for the timeline bonus too.

@lschurr applied

@lschurr can you resend the offer, previous offer is not available

Hmmm I don't know what's going on with this one. I asked for help in Slack - https://expensify.slack.com/archives/C01SKUP7QR0/p1679276533607669

@lschurr I also have same issue as https://github.com/Expensify/App/issues/15309#issuecomment-1474783218.

looking into this!

@mdneyazahmad @gadhiyamanan I sent you both offers to accept for the job!
@mananjadhav working on payment

@dylanexpensify accepted

@dylanexpensify accepted

@mdneyazahmad @gadhiyamanan @mananjadhav all payments sent and contracts ended!
@lschurr I'll leave the RT steps and such to you!

Thank you @dylanexpensify!!

Sorry @lschurr , we need to get to the bottom of this, if we're not showing paid jobs in Upwork it's possible for contributors to get paid twice and for us to not have an audit trail.  I assigned myself if you want to unassigned so you don't get pinged

Not overdue. This one is done.
@mallenexpensify - are those links what you need?


UDF retry should record the error state

We add the UDF retry mechanism in #13375 , however it's dangerous.
In simple terms, we introduced the non-strict evaluation to prevent a single request from blocking the entire stream. When encountering UDF errors, we will fill in NULL values.
The current retry mechanism is chunk-based, which means that when the UDF server is down and can’t be recovered soon, every chunk will introduce about 3s block, and the back pressure will increase uncontrollably! This goes against the original intention of non-strict evaluation.
The fix should be cherry-picked.

A very simple fix: we can store an in_error flag in every Expression, and when retry failed, set it and skip retry until succeeded at least once. (or multiple times since the failed server may be behind a load balancer).


Player crashes in React

Whenever the path for fls is null or no stream is provided from the server. The media player crashes with the following error.

Have you solved it? I have the same problem


blueprint tools in side bar

could the blueprint tool buttons also be in the new blueprint library side bar this mod adds?

The problems there are that you need to be holding a blueprint for the buttons to work, and the buttons don't work with blueprints in the library. The latter is a fundamental API limitation that can't be overcome by mods (yet).


APP-425: Set Kaa dependency version 0.10.0

@kaa-leeroy test this fully please

@kaa-leeroy test this fully please


Modify related terms to work with Regions of Interest

The following term changes were recommended by the Maintenance Group in their 2021-06-08 meeting to make existing terms applicable to the proposed Regions of Interest (#206). Their adoption would be contingent on acceptance of other proposals as noted. Definitions and usage are normative, so these changes all require public comment and Executive Committee approval.
Proposed changes:
ac:freqHigh
Change definition from "The highest frequency of the phenomena reflected in the multimedia item." to "The highest frequency of the phenomena reflected in the multimedia item or Region of Interest.".
Change notes from "... If dwc:scientificName is specified, these frequency bounds..." to "... If dwc:scientificName is specified and if applied to the entire multimedia item, these frequency bounds..."
Contingent on approval of #206.
ac:freqLow
Change definition from "The lowest frequency of the phenomena reflected in the multimedia item." to "The lowest frequency of the phenomena reflected in the multimedia item or Region of Interest.".
Change notes from "... If dwc:scientificName is specified, these frequency bounds..." to "... If dwc:scientificName is specified and if applied to the entire multimedia item, these frequency bounds..."
Contingent on approval of #206.
xmp:CreateDate
Add to Usage: "When applied to a media resource with temporal extent such as audio or video, this property indicates the startTime of the recording."
Contingent on approval of #208.

Ratified by the Executive on 2021-10-05 and implemented in https://github.com/tdwg/rs.tdwg.org/pull/79 and https://github.com/tdwg/ac/pull/212


New decluttering

This pull request fixes the obstacle declutter mode for Image styles, adds declutterMode for Text styles, and makes it so render order and zIndex of decluttered items are maintained.
Replaces and closes #14609
Fixes #15429
Fixes #12567
Fixes #7475
Fixes openlayers/ol-mapbox-style#1068
Fixes openlayers/ol-mapbox-style#1063
Fixes openlayers/ol-mapbox-style#799

This is now ready for review. It's a big pull request, so I added comments in the "Files changed" view to give some guidance to potential reviewers.
Thanks for any review, @openlayers/core

While waiting for a review, I added a commit for an obvious improvement: call the prerender and postrender layer events in the renderDeferred cycle when rendering deferred. Previously, both would have been called before anything is rendered in that case.

Updated reference image for rebase with new puppeteer version.

Thanks for the review, @tschaub

Thanks for this impressive contribution! I had started looking at it but @tschaub was faster :)

Thanks, @jahow

Hey @ahocevar - I just noticed that this change broke the map at the top of the site.  See https://deploy-preview-15466--ol-site.netlify.app/ (r.getDeclutter is not a function).
I'm digging, but it isn't immediately obvious to me what the fix is.

@tschaub Did you find anything? If not, I could start digging now too.

@tschaub The problem is that ol-stac pulls in<EMAIL_ADDRESS>which still has the circular dependency with ol-mapbox-style. So we're dealing with different versions of ol/layer/Layer, and the old version does not have a getDeclutter() method. #15569 fixes the problem by removing the duplicate ol and ol-mapbox-style packages.


Expand PHP code with placeholders on tab press

I think my VSCode has a bug. When I press tab to expand code doesn't do anything as expected.
Example Problem:

Expected:

this behavior is as designed. For the behavior you are looking for, the PHP extension would need to define a snippet.


Stop vendoring modules (#1057)

With go modules, it is not necessary to vendor external dependencies
because the go tooling will automatically search for and install
external dependencies, and the exact versions can be controlled through
the go.mod file so there is no concern about accidental automatic
updates. However, before now, we have still been vendoring these
dependencies because the build service cannot itself install external
dependencies over the internet during the build process. With the
go_modules OBS service, committing the vendored modules directly to the
source code is no longer necessary. This change removes the vendor/
directory and updates the RPM maker script to use the go_modules OBS
service by running a disabledrun service update during the release,
and also updates the Makefile to use the regular GOPATH to find modules
instead of the vendor/ directory in a development environment.
This depends on updating the package to include the new _service file,
which will be managed directly in OBS and not in the RPM maker script:
https://build.suse.de/request/show/213484
Why is this PR needed?
Does it fix an issue? addresses a business case?
add a description and link to the issue if one exists.
Fixes https://github.com/SUSE/avant-garde/issues/1057
Reminder: Add the "fixes bsc#XXXX" to the title of the commit so that it will
appear in the changelog.
What does this PR do?
please include a brief "management" technical overview (details are in the code)
Anything else a reviewer needs to know?
Special test cases, manual steps, links to resources or anything else that could be helpful to the reviewer.
Info for QA
This is info for QA so that they can validate this. This is mandatory if this PR fixes a bug.
If this is a new feature, a good description in "What does this PR do" may be enough.
Related info
Info that can be relevant for QA:

link to other PRs that should be merged together
link to packages that should be released together
upstream issues

Status BEFORE applying the patch
How can we reproduce the issue? How can we see this issue? Please provide the steps and the prove
this issue is not fixed.
Status AFTER applying the patch
How can we validate this issue is fixed? Please provide the steps and the prove this issue is fixed.
Docs
If docs need to be updated, please add a link to a PR to https://github.com/SUSE/doc-caasp.
At the time of creating the issue, this PR can be work in progress (set its title to [WIP]),
but the documentation needs to be finalized before the PR can be merged.
Merge restrictions
(Please do not edit this)
We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises:
What can be merged (merge criteria):
    2 approvals:
        1 developer: code is fine
        1 QA: QA is fine
    there is a PR for updating documentation (or a statement that this is not needed)

Is IBS also supports pull external resource?

@evrardjp if we needed to, we could still vendor and patch dependencies, but now we could do it on a case-by-case basis as needed. Currently, none of our dependencies are forked and modified from upstream (yay!).
@jenting in general IBS/OBS supports pulling from external resources via services but in this case the go_modules service only supports disabledrun mode, which means it needs to be triggered from outside the build service and the resulting vendor.tar.gz file needs to be manually checked in.

Thank you @cmurphy. Adding @jordimassaguerpla and @davidcassany as reviewers because they have a lot of knowledge in this area.

Hi! This is a good idea. Please make sure that when you build the package, it lists all the vendored libs as provides. This should be out of the box with the go service, but if it is not, please contact Jeff K (maintainer of this service file).

@jordimassaguerpla commented on Mar 10, 2020, 11:44 AM PDT:

Hi! This is a good idea. Please make sure that when you build the package, it lists all the vendored libs as provides. This should be out of the box with the go service, but if it is not, please contact Jeff K (maintainer of this service file).

Looks like it does not list the vendored libs as Provides:
$ rpm -q --provides /var/tmp/build-root/SLE_15-x86_64/home/abuild/rpmbuild/RPMS/x86_64/skuba-1.2.9-0.x86_64.rpm
skuba = 1.2.9-0
skuba(x86-64) = 1.2.9-0

I'm not sure I understand why it should: my understanding is that the vendored libraries are statically linked into the skuba binary, and would not be available to use directly. I also see no indication in the source code that adding Provides is the expected behavior.

Another thought on listing vendored libs as Provides: this isn't meant to change any functionality in how the package works, it's just moving the home of the vendor/ directory from the source on GitHub to the package definition in OBS, and since the package doesn't currently list those libs as Provides then we shouldn't be changing it here.

@cmurphy the reason why jordi was asking about the provides id because the suse security team makes use of provides to find embedded sources that might need vulnerability patching.
My guess is that we currently do not have that either without this PR, so in that case strictly speaking this would not be a regression and we can treat that as an unrelated problem.
I believe the go module handling actually allows the GitHub security scanning to work so we're going to get GitHub's vulnerability scanning. Whicj is an advantage.
Personally I would rather spend the time figuring out how to use one of the available security scanners (like for example the one integrated in GitHub) with vendored tarballs in OBs than doing weird provide hacks and then hand ober this tool to the security team (or build a ci jon that sends a report to security team once a vulnerable dependency ia found)

@evrardjp if we needed to, we could still vendor and patch dependencies, but now we could do it on a case-by-case basis as needed. Currently, none of our dependencies are forked and modified from upstream (yay!).

Thanks for confirming.

My guess is that we currently do not have that either without this PR, so in that case strictly speaking this would not be a regression and we can treat that as an unrelated problem.

That's what I believed too. I should have written that in my review.

I believe the go module handling actually allows the GitHub security scanning to work so we're going to get GitHub's vulnerability scanning.

Is go a supported language for handling dependencies vulnerabilities? It's not listed here, but there might be another source... No expert there.
https://help.github.com/en/github/visualizing-repository-data-with-graphs/listing-the-packages-that-a-repository-depends-on#supported-languages

Personally I would rather spend the time figuring out how to use one of the available security scanners (like for example the one integrated in GitHub) with vendored tarballs in OBs than doing weird provide hacks and then hand ober this tool to the security team (or build a ci jon that sends a report to security team once a vulnerable dependency ia found)

Agreed.

Is go a supported language for handling dependencies vulnerabilities?

looks like it isn't, you can't find it on github.com/advisories
okay, so some other solution needs to be used.
@cmurphy please rebase

For the provides, I advise something like this: https://pagure.io/fedora-rust/rust2rpm/pull-request/105
The idea is provide a attr file for rpmbuild, that add the bundled(go-package) in the rpm metadata. The commit that does that is this: https://pagure.io/fork/aplanas/fedora-rust/rust2rpm/c/1ba1a3a6067b138eb6703d03563b129645095179

Rebased and addressed @dannysauer 's comments.
@aplanas is this something that's available for go modules?

@aplanas is this something that's available for go modules?

This code that I pointed is useless for go modules directly : (
We have vendoring for Rust, Ruby and now Go. If the expectation is to add the "Provides: bundled(..)" in the metadata (for tracking reasons and introspection) a similar approach that the one pointed can be used.

@aplanas if there's not already existing tooling for this for go then I think creating it is out of scope for this particular change, maybe something to follow up on?

@aplanas if there's not already existing tooling for this for go then I think creating it is out of scope for this particular change, maybe something to follow up on?

Please follow up with @jfkw . He is the go maintainer and I know he was looking at that. May it be you just need to use a more up-to-date go-service package.

@cmurphy The "provides" thing should not be a blocker for this PR. Sorry for this. But I would like to take the opportunity to add the "provides" if we have to repackage skuba, but this is not a blocker for this PR.

Yes, there is an upcoming release of obs-service-go_modules which emits Provides: bundles(go()) clauses for entries parsed from vendor/modules.txt. Thanks for the note that skuba is considering using obs-service-go_modules, I will be sure to test skuba packaging with the Provides feature.

Thank you, @jfkw!

I wanted to provide some advance information for testing that when obs-service-go_modules runs its sequence of commands, the current vendor/ directory will change with the following packages being dropped:
$ go mod vendor
$ go mod verify
all modules verified
$ git st
 M go.mod
 D vendor/github.com/chai2010/gettext-go/gettext/hello.go
 D vendor/github.com/google/btree/btree_mem.go
 D vendor/golang.org/x/net/html/atom/gen.go
 D vendor/golang.org/x/sys/unix/mkasm_darwin.go
 D vendor/golang.org/x/sys/unix/mkpost.go
 D vendor/golang.org/x/sys/unix/mksyscall.go
 D vendor/golang.org/x/sys/unix/mksyscall_aix_ppc.go
 D vendor/golang.org/x/sys/unix/mksyscall_aix_ppc64.go
 D vendor/golang.org/x/sys/unix/mksyscall_solaris.go
 D vendor/golang.org/x/sys/unix/mksysnum.go
 D vendor/golang.org/x/sys/unix/types_aix.go
 D vendor/golang.org/x/sys/unix/types_darwin.go
 D vendor/golang.org/x/sys/unix/types_dragonfly.go
 D vendor/golang.org/x/sys/unix/types_freebsd.go
 D vendor/golang.org/x/sys/unix/types_netbsd.go
 D vendor/golang.org/x/sys/unix/types_openbsd.go
 D vendor/golang.org/x/sys/unix/types_solaris.go
 D vendor/golang.org/x/text/encoding/internal/identifier/gen.go
 D vendor/golang.org/x/text/unicode/bidi/gen.go
 D vendor/golang.org/x/text/unicode/bidi/gen_ranges.go
 D vendor/golang.org/x/text/unicode/bidi/gen_trieval.go
 D vendor/golang.org/x/text/unicode/norm/maketables.go
 D vendor/golang.org/x/text/unicode/norm/triegen.go
 D vendor/golang.org/x/text/width/gen.go
 D vendor/golang.org/x/text/width/gen_common.go
 D vendor/golang.org/x/text/width/gen_trieval.go
 M vendor/modules.txt

@jfkw I think that has to do with a difference in go versions, when I run the same commands with go 1.12 I get no changes, with 1.13 I can reproduce your output. It looks like with both SLE_15_SP1 and SLE_15_SP2 builds use go 1.12, so I think the module list won't change yet, but it will if we change go versions.

@jfkw I think that has to do with a difference in go versions, when I run the same commands with go 1.12 I get no changes, with 1.13 I can reproduce your output. It looks like with both SLE_15_SP1 and SLE_15_SP2 builds use go 1.12, so I think the module list won't change yet, but it will if we change go versions.

For CaaSP we use go1.13 because of k8s 1.17 requiring it.

@jordimassaguerpla commented on Mar 13, 2020, 6:01 AM PDT:

For CaaSP we use go1.13 because of k8s 1.17 requiring it.

I've opened another PR to codify that because I don't think that's a given, it seems that both the build service and jenkins are using 1.12. But this is all a tangent from this PR :smile:

@jordimassaguerpla commented on Mar 13, 2020, 6:01 AM PDT:

For CaaSP we use go1.13 because of k8s 1.17 requiring it.

I've opened another PR to codify that because I don't think that's a given, it seems that both the build service and jenkins are using 1.12. But this is all a tangent from this PR smile

:+1:

Added another commit to remove GOMOD from the Makefile


Storage configuration for Minio (S3)

What went wrong?
I've spend roughly 3 hours to get this gem working with Minio via the S3 interface.
This issue is meant as documentation for future reference and can be closed.
Error message
Excon::Error::Socket: getaddrinfo: No address associated with hostname (SocketError)
How is your copy of backup configured?
Here is the S3 storage configuration which finally worked.
    store_with S3 do |s3|
        s3.access_key_id = "your access key id"
        s3.secret_access_key = "your access key"
        s3.bucket = "bucket_name"
        s3.fog_options = {
          host: "minio_host",
          port: "minio_port",
          scheme: "minio_scheme", # http / https
          aws_signature_version: 4,
          path_style: true
        }
    end

Edit: I'll add the two things that went wrong:

You can't use the fog_option endpoint for anything else than normal http/https ports (i.e., 80/443), so if you run minio without a proxy (e.g. in Docker), the default port 9000 does not work. But you can work around that by specifying host, port and scheme separetly.
If your minio setup is not able to resolve "bucket.host" (as per default settings) you need to add path_style: true which I luckily read in another issue.

These two points should be added to the documentation.
Cheers,
Lukas

Added the PR: https://github.com/backup/backup/pull/965
It took me a while to find where docs reside ^^.

Thanks for the PR.
Closing now


Still on?
Thank you.

Hi Christian,
Thanks for your comment! I definitely will working on NStore. I've been itching to, honestly. I have been a bit busy the past few weeks with some work and personal stuff, but there's a light at the end of the tunnel and as soon as I get unburied, I'll jump right back in!

Cool! Thanks.


Tracking issue: uv backtracks on the wrong package

In this issue, I'm collecting cases where uv backtracks unnecessarily. Please feel free to edit and add your own cases.
Problem layout
Usually, this happens in the following way:

We select package A
We select A==a
We select package B
We select B==b
B==b is incompatible with A==a. We try many versions of B until we get to one of the following outcomes:

If B is lacking a lower bound: We arrive at an old version of B that does not depend on A anymore, but is too old for the user
If B is lacking a lower bound: We arrive at a version of B that does not build anymore.
We exhausted all compatible versions of B. We reject A==a and select a version of A that is compatible with a version of B, usually B==b, solving the conflict.

Cases 1. and 2. are caused by missing lower bounds, are can detected by looking for a combination of no lower bound and incompatibility. Case 3 leads to the correct resolution but makes uv really slow.
This happens because PubGrub tries to backtrack the minimal amount: Once we locked in A==a, we will try we will try any other option with any B that gives us a solution with A==a. PubGrub by itself will never switch to discarding A==a for now and trying B==b first instead. Additionally, uv package priorities usually mean we will retry A before B again.
As solution, we should track how conflicting or bad a version is: If we rejected a lot of versions of e.g. B due to A==a, we consider B a very conflicting package and A==a a very rejecting version, and should switch them to trying B first. The PubGrub implementation allows this: We are allowed to backtrack further than we need to and keep all incompatibilities intact. We only need to ensure that we pick differently in the next round of package and version selections, to not end up in a loop.
We can apply similar things to avoid building source distributions. Source distribution builds are both prohibitively expensive and prone to fail, so we should try our best to find a solution with only wheel. Say when we would need to build a B==b' after having rejected a B==b with a wheel due to an incompatibility with A==a, and there's an A==a' with a wheel that may allow us to not try B==b', we should again switch orders and try B==b first, then A==a' (vs. the original A==a then B==b').
We should compile a runnable test suite from the known cases and pick a heuristic according to how well they go.
Known Cases
I've added them to scripts/requirements/backtracking, please add your own.

Selecting a recent version of numpy backtracks on numba to an ancient version, which picks an ancient llvmlite that fails to build. https://github.com/astral-sh/uv/issues/6281#issuecomment-2316240724, https://github.com/astral-sh/uv/issues/7881, https://github.com/astral-sh/uv/issues/7830numpy>=2.1,<2.2
numba<=0.60,>0.1

Selecting starlette backtracks to a version of fastapi that doesn't depend on starlette at all. https://github.com/astral-sh/uv/issues/1575starlette<=0.36.0
fastapi<=0.115.2

sentry requires sentry-kafka-schemas>=0.1.50 and python-rapidjson>=1.4. We lock python-rapidjson==1.16 then reject all version of sentry-kafka-schemas because they depend on python-rapidjson==1.8, until switching to python-rapidjson==1.8 and selecting the latest sentry-kafka-schemas==0.1.113.python-rapidjson<=1.20,>=1.4
sentry-kafka-schemas<=0.1.113,>=0.1.50

apache-airflow[all]==2.8.4 (https://github.com/astral-sh/uv/issues/3078) through# Run on Python 3.10
dill<0.3.9,>=0.2.2
apache-beam<=2.49.0

Example: sentry with sentry-kafka-schemas and python-rapidjson
Trying uncached uv pip compile with https://github.com/getsentry/sentry/blob/51281a6abd8ff4a93d2cebc04e1d5fc7aa9c4c11/requirements-base.txt from https://lincolnloop.github.io/python-package-manager-shootout/, the entire right pyramid is incorrect sentry-kafka-schemas fetches (see also https://github.com/pubgrub-rs/pubgrub/issues/263 because we're prefetching too much):

Tried 263 versions: sentry-kafka-schemas 62, beautifulsoup4 2, boto3 2, botocore 2, cachetools 2, celery 2, click 2, confluent-kafka 2, croniter 2, cssselect 2, datadog 2, django 2, django-crispy-forms 2, django-csp 2, django-pg-zero-downtime-migrations 2, djangorestframework 2, drf-spectacular 2, email-reply-parser 2, fido2 2, google-api-core 2, google-auth 2, google-cloud-bigtable 2, google-cloud-build 2, google-cloud-core 2, google-cloud-functions 2, google-cloud-kms 2, google-cloud-pubsub 2, google-cloud-spanner 2, google-cloud-storage 2, google-crc32c 2, googleapis-common-protos 2, isodate 2, jsonschema 2, lxml 2, maxminddb 2, mistune 2, mmh3 2, openai 2, packaging 2, parsimonious 2, petname 2, phonenumberslite 2, pillow 2, progressbar2 2, psycopg2-binary 2, pydantic 2, pydantic-core 2, pyjwt 2, pymemcache 2, python-dateutil 2, python-rapidjson 2, python-u2flib-server 2, python3-saml 2, pyuwsgi 2, pyyaml 2, rb 2, redis 2, redis-py-cluster 2, requests 2, requests-oauthlib 2, rfc3339-validator 2, rfc3986-validator 2, sentry-arroyo 2, sentry-ophio 2, sentry-redis-tools 2, sentry-usage-accountant 2, symbolic 2, amqp 1, annotated-types 1, anyio 1, asgiref 1, attrs 1, billiard 1, brotli 1, certifi 1, cffi 1, charset-normalizer 1, click-didyoumean 1, click-plugins 1, click-repl 1, cryptography 1, cssutils 1, distro 1, fastjsonschema 1, google-resumable-media 1, grpc-google-iam-v1 1, grpcio 1, grpcio-status 1, h11 1, hiredis 1, httpcore 1, httpx 1, idna 1, inflection 1, jmespath 1, jsonschema-specifications 1, kombu 1, milksnake 1, msgpack 1, oauthlib 1, phabricator 1, prompt-toolkit 1, proto-plus 1, protobuf 1, pyasn1 1, pyasn1-modules 1, pycparser 1, python-utils 1, referencing 1, regex 1, rpds-py 1, rsa 1, s3transfer 1, sentry-relay 1, sentry-sdk 1, setuptools 1, simplejson 1, six 1, sniffio 1, snuba-sdk 1, soupsieve 1, sqlparse 1, statsd 1, structlog 1, toronado 1, tqdm 1, typing-extensions 1, tzdata 1, ua-parser 1, unidiff 1, uritemplate 1, urllib3 1, vine 1, wcwidth 1, xmlsec 1, zstandard 1
If we inject a python-rapidjson==1.8 constraint, it goes from 11s to 4.5s; The time is then purely metadata fetching, with a performance penalty for the index not supporting PEP 658:

Tried 137 versions: sentry-redis-tools 2, amqp 1, annotated-types 1, anyio 1, asgiref 1, attrs 1, beautifulsoup4 1, billiard 1, boto3 1, botocore 1, brotli 1, cachetools 1, celery 1, certifi 1, cffi 1, charset-normalizer 1, click 1, click-didyoumean 1, click-plugins 1, click-repl 1, confluent-kafka 1, croniter 1, cryptography 1, cssselect 1, cssutils 1, datadog 1, distro 1, django 1, django-crispy-forms 1, django-csp 1, django-pg-zero-downtime-migrations 1, djangorestframework 1, drf-spectacular 1, email-reply-parser 1, fastjsonschema 1, fido2 1, google-api-core 1, google-auth 1, google-cloud-bigtable 1, google-cloud-build 1, google-cloud-core 1, google-cloud-functions 1, google-cloud-kms 1, google-cloud-pubsub 1, google-cloud-spanner 1, google-cloud-storage 1, google-crc32c 1, google-resumable-media 1, googleapis-common-protos 1, grpc-google-iam-v1 1, grpcio 1, grpcio-status 1, h11 1, hiredis 1, httpcore 1, httpx 1, idna 1, inflection 1, isodate 1, jmespath 1, jsonschema 1, jsonschema-specifications 1, kombu 1, lxml 1, maxminddb 1, milksnake 1, mistune 1, mmh3 1, msgpack 1, oauthlib 1, openai 1, packaging 1, parsimonious 1, petname 1, phabricator 1, phonenumberslite 1, pillow 1, progressbar2 1, prompt-toolkit 1, proto-plus 1, protobuf 1, psycopg2-binary 1, pyasn1 1, pyasn1-modules 1, pycparser 1, pydantic 1, pydantic-core 1, pyjwt 1, pymemcache 1, python-dateutil 1, python-rapidjson 1, python-u2flib-server 1, python-utils 1, python3-saml 1, pyuwsgi 1, pyyaml 1, rb 1, redis 1, redis-py-cluster 1, referencing 1, regex 1, requests 1, requests-oauthlib 1, rfc3339-validator 1, rfc3986-validator 1, rpds-py 1, rsa 1, s3transfer 1, sentry-arroyo 1, sentry-kafka-schemas 1, sentry-ophio 1, sentry-relay 1, sentry-sdk 1, sentry-usage-accountant 1, setuptools 1, simplejson 1, six 1, sniffio 1, snuba-sdk 1, soupsieve 1, sqlparse 1, statsd 1, structlog 1, symbolic 1, toronado 1, tqdm 1, typing-extensions 1, tzdata 1, ua-parser 1, unidiff 1, uritemplate 1, urllib3 1, vine 1, wcwidth 1, xmlsec 1, zstandard 1

https://github.com/astral-sh/uv/issues/3078#issuecomment-2062907457

I've added a comment on an issue of some recent findings I have on where pip finds a good solution but I think uv is actually doing the right thing: https://github.com/astral-sh/uv/issues/3078#issuecomment-2462455805
My plan is to actually make pip behave more like uv, because in general it will produce a faster answer that is more explainable. That isn't to say pip will start producing exactly the same results as uv, many of the other examples here don't change with pip.

A related idea from @henryiii on X: if we see that a package introduces an upper bound on some other package in newer versions, we may want to consider respecting that upper bound in older versions of the same package...
For example, if Pandas 2.1.2 introduced the numpy<2 bound, we may want to respect that same bound when we look at Pandas 2.1.1, etc. (That would probably also solve the problem raised in this PR, though it's obviously a bit more dicey.)

This suggest has come up before on discussing uv's resolution, or more precisely I think I or something else suggested uv tries to resolve with and without that constraint and see which one is able to resolve.
This was awhile ago now though, before uv has a universal resolvers or anythjng else, perhaps there is more infrastructure in place to do something like that.

There's two differently shaped problems in this issues:
In some of the cases, an upper bound (or dependency that causes the conflict) is missing on an older version, so we search until we find that old version. This is logically sound, but causes a bad resolution.
In other cases (sentry and airflow), there are upper bounds, but we're getting a lot of conflicts with versions of B until we've exhausted the range and finally start picking a lower version of A.

I prototyped the "propagate upper bounds" thing, but the problem is that it causes us to backtrack through all versions, so, e.g., I end up failing to build numba==0.34.0.

Give uv resolves so fast, I do wonder if it makes sense on a build failure, rather than exiting resolution instead treat it as a lower bound, there would need to be some explanation to the user though if the resolution was not possible.


Invalid file magic number when trying to install a patch on Linux

Invalid file magic number. The appinfo.vdf version might not be supported by the current version of Protontricks - please check for updates.
polyversal-20240930T095554.log
polyversal-20240930T103435.log
Steps to reproduce:

Install Steins;Gate
Select Proton 8.0-5
Start Steins;Gate
When the launcher opens, quit
Download and unzip the latest version of Polyversal (v2_1_3)
Double click Polyversal.desktop
Install a patch
STEINS;GATE
Unable to locate STEINS;GATE's game directory. This likely means you have not yet run and quit the game once to generate its Proton prefix.
The logs state: Invalid file magic number. The appinfo.vdf version might not be supported by the current version of Protontricks - please check for updates.

Alternatively:
11. ./polyversal install sg
12. polyversal FATAL - Invalid syntax

this is an issue with protontricks being outdated.
uninstall your current protontricks & then install the beta flatpak version using:
flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

flatpak install flathub-beta com.github.Matoking.protontricks

this is an issue with protontricks being outdated.
uninstall your current protontricks & then install the beta flatpak version using:
flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

flatpak install flathub-beta com.github.Matoking.protontricks

The polyversal script prefers the system package to the flatpak one though, and I'm only 1 minor version behind. Why does this break it?

plus, there's this:
# Protontricks versions earlier than this minversion will cause issues that are hard to make sense of.
readonly ptx_flatpak='com.github.Matoking.protontricks'
readonly ptx_minversion=1.11.0

❯ protontricks --version
protontricks (1.11.1)


Fix clipping for cache coverage

Fix issue with clipping when defining a coverage for cache.
Fixes #789.

@weskamm Could you please take a look?

Thanks for that!


Test cases hangs in case of application crash.

From<EMAIL_ADDRESS>on October 23, 2013 06:41:57
What steps will reproduce the problem? 1.I have 4 test cases.
2.I execute normally 4 tests at once, Now first testcase works fine but other 3 test cases hangs and doesn't do anything.
3.Also sometimes, a pop is shown "Application is not responding. Would you like to close it?" with Wait and Ok button. What is the expected output? What do you see instead? Is there any way to execute the remaining test cases preventing the hanging of test case.
Thanks,
Tanuj Lakshakar
Original issue: http://code.google.com/p/robotium/issues/detail?id=540

From<EMAIL_ADDRESS>on October 23, 2013 22:04:14
Robotium is run in the same process as your app. If your app crashes, has an ANR or similar it will affect the tests as well. What you need to do is check the log and find out why its crashing and then take it from there.
Status: Invalid
Owner<EMAIL_ADDRESS>

From<EMAIL_ADDRESS>on October 23, 2013 22:37:19
Thanks for your response!
I agree with this, but application is not crashing, it stuck at some activity and doesn't do anything (nothing going ahead). I checked thoroughly, my Activity is correct.
If I execute single test case, it works fine but if I execute 4 tests at once, other 3 test cases hangs and doesn't do anything.

From<EMAIL_ADDRESS>on October 23, 2013 22:55:33
Do you use solo.finishOpenedActivities() in your tearDown()?

From<EMAIL_ADDRESS>on October 23, 2013 23:02:17
I used both
    @Override
public void tearDown() throws Exception {
	solo.finishOpenedActivities();
	super.tearDown();
}

From<EMAIL_ADDRESS>on October 23, 2013 23:11:05
What happens if you use the second constructor: solo = new
Solo(getInstrumentation); instead?

From<EMAIL_ADDRESS>on October 23, 2013 23:22:29
No launching even the first test case (Activity).
Please let me know will I have to create another Instrumentation instance for other test cases and again write
	solo = new Solo(getInstrumentation(),getActivity());

From<EMAIL_ADDRESS>on October 23, 2013 23:24:38
Write it like this:
solo = new Solo(getInstrumentation());
getActivity();

From<EMAIL_ADDRESS>on October 24, 2013 22:51:16
Hi Renas,
I have sent you logcat via mail. Please review it and let me know why Test cases hangs?
Regards,
Tanuj Lakshakar

From<EMAIL_ADDRESS>on October 24, 2013 23:13:33
There is nothing in the log pointing at Robotium failure. The reason for the crash is something you need to figure out.

From<EMAIL_ADDRESS>on October 24, 2013 23:20:04
Actually application is not crashing but it hangs after executing 1st test case. You might see in log a comment "The application may be doing too much work on its main thread.". May be this causes an issue, I don't know.
Also there is clearly mentioned in log that "Starting test: testMyProfileActivity(com.WhatsApp.test.StartWhatsAppApp)" that means this test case started but not executing all its instrumentations. I hangs after sometimes, means stuck at one activity and doesn't proceed ahead.

From<EMAIL_ADDRESS>on October 24, 2013 23:22:19
Would it be possible for you to share the app? You can just email me the apk.

From<EMAIL_ADDRESS>on October 24, 2013 23:25:27
Sorry I can't share the app. But I have sent you snapshot that tells you where I am getting stuck.
After executing 1st test case successfully, application hangs at this page. In code even if I write
            solo.enterText(0, "stest123");
	solo.sleep(500);
	solo.enterText(1, "123456");

it didn't execute these instructions

From<EMAIL_ADDRESS>on October 24, 2013 23:26:14
Unfortunately there is nothing I can figure out or do based on that
screenshot.


could replace margin, border 'px' to '', to use default dp, fit device screen?

I'd like this package very much, but after built to different devices, each device screen shows different font size, margin, padding...
And if I replace margin: 10px to margin: 10, it will build fail because of the stylus format.
Could you fix it, thanks!

I'd write another tool, thanks.


Parameter and return value is not correctly recognized

Hey I just came across the project and would love to use it for larger projects to avoid faulty documentation after e.g. refactoring of code.
Now I have a function:
def modify(numericString: Union[str, int]) -> str:
    '''Do stuff.

    Parameters
    ----------
    numericString: Union[str, int]
        numeric string that should be converted.

    Returns
    -------
    str
        reformatted string
    '''
    numericString = str(numericString)
    last = numericString[-1]
    middle = numericString[-3:-1]
    first = numericString[:-3]
    finalstring = "-".join([first, middle, last])
    return finalstring

Now I get the error:
def modify(✖numericString) -> ✓str:
    """...

    :param None: ✖
    :return: ✓
    """

E103: parameters missing

Another example I encountered:
def check_stuff(str_lin: str) -> bool:
    """Check if "A" or "B".

    The function checks wether the string is "A" or "B".

    Parameters
    ----------
    str_lin: str
        special string produced by function_of_y

    Returns
    -------
    bool
        Returns True, else false
    """
    if any(s in str_lin for s in ["A", "B"]):
        return True
    return False

The error:
def check_stuff(✖str_lin) -> ✖bool:
    """...

    :param None: ✖
    :return: ✖
    """

E103: parameters missing
E105: return missing from docstring

I am a bit confused as I cannot really pinpoint the issue. Is this a parsing or formatting problem of the docstring? Any obvious error here?
Please ignore the random weird functions, they are just examples similar to conde I have written.

Hi @JenniferHem, thank you for opening this issue, appears to be a problem with the way indents are handled with numpy style docs, I'll look into this as soon as I can

Actually for the first one, Returns being an indicator of a numpy docstring, that's been fixed in v0.23.1, yet to look at the other examples

Hi @JenniferHem
The numpy parser was too strict with indents and whitespace
Those examples now pass and you can clone or pip install docsig==0.23.2
If you find anything else please keep opening issues or PRs so long as you find use for this! I don't use numpy style, so issues like this help a lot

@JenniferHem.
numpy was pretty buggy and not very usable, you should see some positive results with the latest version (v0.24.0), It's at least as usable as RST, which works well for me

I can confirm that your fixes solved the mentioned errors and I see it working as expected. Thank you very much for the quick fix(es)!

Okay not sure if it is intended so not re-opening I just saw an issue with:
def check_stuff(str_lin: str, a: str) -> bool:
    """Check if "A" or "B".

    The function checks wether the string is "A" or "B".

    Parameters
    ----------
    str_lin: str
        special string produced by function_of_y ["a"]
            a second wrong indent line
    a: str
        string stuff

    Returns
    -------
    bool
        Returns True, else false
    """
    if any(s in str_lin for s in ["A", "B"]):
        return True
    return False

Here I get the error:
def check_stuff(✖str_lin, ✖a) -> ✓bool:
    """...

    :param a: ✖
    :param None: ✖
    :return: ✓
    """

E103: parameters missing
hint: there appears to be a syntax error that could be causing this
E101: parameters out of order

which definitely helped me to spot the wrong indent.
I am just not 100% sure if the indent should cause this (might be specific functionalities of docs related that I am not aware?) or if this should not fail when parsing?
This is definitely a style problem which should not occur, just thought I'd run it by you to get your opinion how you want to handle this!

Hi @JenniferHem
The result is quite confusing, I understand
As the param was not even parsed due to the indentation it resulted in a missing parameter
The None value was parsed after iterating through the longest so it also resulted in an incorrect error for ordering
A new error has been added
E115: syntax error in description

Which gives you more control over this result
If you don't care about syntax errors in the description you can disable the check
This is available with ^0.26.0
Thanks again 😄

Amazing thanks!