turn restrictions not recognized?

when i run the tests for turn restrictions with "cucumber --tags @restrictions" they fail. YES i've rebuild the binaries and cleared the cache :-)
when i open the osm files involved in JOSM, the restrictions are recognized and looks good, and JOSM reports no issues.
but osrm-prepare doesn't recognize them, instead just reporting "Edge-based graph skipped 0 turns, defined by 0 restrictions."
i'm i missing something?
here's an excerpt from preprocessing.log, which is produced during preprocessing of the test files:
Preprocessing data for scenario: No left turn
Time: 2012-02-25T09:02:01Z

 == OSM data:

<?xml version="1.0" encoding="UTF-8"?>
<osm generator="osrm-test" version="0.6">
  <node id="1" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z" lon="1.000899199712256" lat="1.0">
    <tag k="name" v="t"/>
  </node>
  <node id="2" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z" lon="1.0" lat="0.999100800287744">
    <tag k="name" v="a"/>
  </node>
  <node id="3" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z" lon="1.000899199712256" lat="0.999100800287744">
    <tag k="name" v="j"/>
  </node>
  <node id="4" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z" lon="1.001798399424512" lat="0.999100800287744">
    <tag k="name" v="b"/>
  </node>
  <node id="5" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z" lon="1.000899199712256" lat="0.9982016005754878">
    <tag k="name" v="s"/>
  </node>
  <way id="6" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z">
    <nd ref="4"/>
    <nd ref="3"/>
    <tag k="highway" v="primary"/>
    <tag k="name" v="bj"/>
  </way>
  <way id="7" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z">
    <nd ref="2"/>
    <nd ref="3"/>
    <tag k="highway" v="primary"/>
    <tag k="name" v="aj"/>
  </way>
  <way id="8" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z">
    <nd ref="5"/>
    <nd ref="3"/>
    <tag k="highway" v="primary"/>
    <tag k="name" v="sj"/>
  </way>
  <way id="9" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z">
    <nd ref="1"/>
    <nd ref="3"/>
    <tag k="highway" v="primary"/>
    <tag k="name" v="tj"/>
  </way>
  <relation id="10" version="1" uid="1" user="osrm" timestamp="2000-00-00T00:00:00Z">
    <member type="way" ref="8" role="from"/>
    <member type="way" ref="7" role="to"/>
    <member type="node" ref="3" role="via"/>
    <tag k="type" v="restriction"/>
    <tag k="restriction" v="no_left_turn"/>
  </relation>
</osm>

== Speed profile:
[Scenario: No left turn]
    accessTag = bicycle
    defaultSpeed = 17
    obeyOneways = yes
    useRestrictions = yes
    obeyBollards = no
    cycleway = 19
    primary = 19
    primary_link = 19
    secondary = 17
    secondary_link = 17
    tertiary = 15
    residential = 15
    unclassified = 15
    living_street = 13
    road = 13
    service = 12
    track = 12
    path = 12
    footway = 10
    pedestrian = 5
    pier = 5
    steps = 3
    ferry = 5
    excludeFromGrid = ferry

== Converting cache/78ec26fdda3ee664f610d55d559377ff9a609b93.osm to protobuffer format...
Feb 25, 2012 9:59:01 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.39
Feb 25, 2012 9:59:01 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
Feb 25, 2012 9:59:01 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
Feb 25, 2012 9:59:01 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
Feb 25, 2012 9:59:01 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline complete.
Feb 25, 2012 9:59:01 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Total execution time: 364 milliseconds.

== Extracting cache/78ec26fdda3ee664f610d55d559377ff9a609b93.osm...
[STXXL-MSG] STXXL v1.3.1 (release)
[STXXL-MSG] 1 disks are allocated, total space: 1 MiB
[info extractor.cpp:85] extracting data from input file cache/78ec26fdda3ee664f610d55d559377ff9a609b93.osm.pbf
[info extractor.cpp:114] Loading speed profiles
[info extractor.cpp:116] Found the following speed profiles:
 [0]Scenario: No left turn
[info extractor.cpp:124] Using profile "Scenario: No left turn"
[error] Failed to open file extractor.ini for reading.
Parse Data Thread Finished
[extractor] parsing finished after 0.000593901 seconds
[extractor] Sorting used nodes        ... ok, after 0.0807831s
[extractor] Erasing duplicate nodes   ... ok, after 0.000552893s
[extractor] Sorting all nodes         ... ok, after 0.0793431s
[extractor] Sorting used ways         ... ok, after 0.0709801s
[extractor] Sorting restrctns. by from... ok, after 0.137783s
[extractor] Fixing restriction starts ... ok, after 0.1387s
[extractor] Sorting restrctns. by to  ... ok, after 0.088176s
[extractor] Fixing restriction ends   ... ok, after 0.00095892s
[info extractor.cpp:303] usable restrictions: 1
[extractor] Confirming/Writing used nodes     ... ok, after 0.00099206s
[extractor] setting number of nodes   ... ok
[extractor] Sorting edges by start    ... ok, after 0.097584s
[extractor] Setting start coords      ... ok, after 0.000991106s
[extractor] Sorting edges by target   ... ok, after 0.0873761s
[extractor] Setting target coords     ... ok, after 0.00100303s
[extractor] setting number of edges   ... ok
[extractor] writing street name index ... ok, after 0.000237942s
[info extractor.cpp:490] Processed 5.75427 nodes/sec and 4.60342 edges/sec
[extractor] finished.

== Preparing cache/78ec26fdda3ee664f610d55d559377ff9a609b93.osm...
[error] Failed to open file contractor.ini for reading.
[info createHierarchy.cpp:90] preprocessing data from input file cache/78ec26fdda3ee664f610d55d559377ff9a609b93.restrictions using STL serial mode
[info createHierarchy.cpp:92] Using restrictions from file: cache/78ec26fdda3ee664f610d55d559377ff9a609b93.restrictions
[info Util/GraphLoader.h:196] Graph loaded ok
[info createHierarchy.cpp:119] Loaded 0 restrictions, 0 bollard nodes, 0 traffic lights
[info Contractor/EdgeBasedGraphFactory.cpp:48] bollards: 0
[info Contractor/EdgeBasedGraphFactory.cpp:49] signals: 0
[info Contractor/EdgeBasedGraphFactory.cpp:91] Converted 4 node-based edges into 8 edge-based nodes.
[info Contractor/EdgeBasedGraphFactory.cpp:115] Generating Edge based representation of input data
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80%  100%
. 90% . 100% [info Contractor/EdgeBasedGraphFactory.cpp:275] Node-based graph contains 8 edges
[info Contractor/EdgeBasedGraphFactory.cpp:276] Edge-based graph contains 16 edges, blowup is 2
[info Contractor/EdgeBasedGraphFactory.cpp:277] Edge-based graph skipped 0 turns, defined by 0 restrictions.
[info Contractor/EdgeBasedGraphFactory.cpp:278] Generated 8 edge based nodes
[STXXL-MSG] STXXL v1.3.1 (release)
[STXXL-MSG] 1 disks are allocated, total space: 1 MiB
[info createHierarchy.cpp:136] building grid ...
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 100%
 90% . 100% [info DataStructures/NNGrid.h:118] sorting grid data consisting of 10 edges...
[info DataStructures/NNGrid.h:121] finished sorting after 0.075269s
writing data .... 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90%  100%
. 100% sse based
[info createHierarchy.cpp:146] writing node map ...
[info createHierarchy.cpp:159] initializing contractor
ok
merged 0 edges out of 32
Contractor is using 1 threads
initializing elimination PQ ...ok
preprocessing .... 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 100%
 90% . 100% [info createHierarchy.cpp:163] Contraction took 0.000140905 sec
[info Contractor/ContractionCleanup.h:163] Scanning for useless shortcuts
[info Contractor/ContractionCleanup.h:201] Removing edges
[info Contractor/ContractionCleanup.h:209] Removed 0 useless shortcuts
[info createHierarchy.cpp:178] Building Node Array
[info createHierarchy.cpp:182] Serializing compacted graph
[info createHierarchy.cpp:234] Expansion  : 23590 nodes/sec and 37744 edges/sec
[info createHierarchy.cpp:235] Contraction: 37744 nodes/sec and 181.72 edges/sec
[info createHierarchy.cpp:240] finished preprocessing

the .osrm.restrictions files produced by the extractor are all 20 bytes in size

it seems the extractor is recognizing them, but the contractor is not loading them?
osrm-extract:
[info extractor.cpp:303] usable restrictions: 1
osrm-prepare:
[info createHierarchy.cpp:119] Loaded 0 restrictions, 0 bollard nodes, 0 traffic lights
the speedprofile has restrictions turned on:
useRestrictions = yes

@DennisOSRM it's interesting if turn restrictions work for you. did you run the cucumber tests?
cucumber --tags @DennisOSRM

all these tests still fail for me. preprocesing.log shows:
[info Contractor/EdgeBasedGraphFactory.cpp:277] Edge-based graph skipped 0 turns, defined by 0 restrictions.

for all tests

I do get different results here. Not sure why:
Edge-based graph skipped 1 turns, defined by 1 restrictions.

Also works with the other profile if I run everything manually:
http://localhost:5000/viaroute?start=0.9982016,1.0008992&dest=0.9991008,1.0
{
    "version": 0.3,
    "status": 0,
    "status_message": "Found route between points",
    "route_summary": {
        "total_distance": 400,
        "total_time": 74,
        "start_point": "sj",
        "end_point": "aj"
    },
    "route_geometry": [
        [
            0.9982,
            1.00089
        ],
        [
            0.9991,
            1.00089
        ],
        [
            1,
            1.00089
        ],
        [
            0.9991,
            1.00089
        ],
        [
            0.9991,
            1
        ]
    ],
    "route_instructions": [
        [
            "Head",
            "sj",
            100,
            0,
            10,
            "100m",
            "N",
            0
        ],
        [
            "Continue",
            "tj",
            100,
            1,
            189,
            "100m",
            "N",
            0
        ],
        [
            "U-Turn",
            "tj",
            100,
            2,
            189,
            "100m",
            "S",
            180
        ],
        [
            "Turn right",
            "aj",
            98,
            3,
            9,
            "98m",
            "E",
            89.97
        ]
    ],
    "via_points": [],
    "route_data": {
        "checksum": 983329270,
        "hint_array": [
            13,
            5
        ]
    },
    "transactionId": "OSRM Routing Engine JSON Descriptor (v0.3)"
}

do the tests pass when you run "cucumber --tags @restrictions"?

i found a few errors in the test markup, so let me send an update before you investigate. i still don't see the turn restruction working though.

Looking at preprocessing.log is see that the restrictions are not loaded at all.
== Preparing cache/bb4ba54032cd0d6b7a40d9659eadbe97873b1190.osm...
[info createHierarchy.cpp:86] Using restrictions from file: cache/bb4ba54032cd0d6b7a40d9659eadbe97873b1190.restrictions

The correct suffix is .osrm.restrictions

Latest commit makes it fail more gracefully
== Preparing cache/d5cc994e721ef68c077d7604251d60f00169caca.osm...
[info createHierarchy.cpp:86] Using restrictions from file: cache/d5cc994e721ef68c077d7604251d60f00169caca.restrictions
[error createHierarchy.cpp:89] Could not access <osrm-restrictions> files
*** Exited with code 255.

sweet!


mypaint: fix crash without hicolor-icon-theme

Motivation for this change
Mypaint should probably run without having a specific icon theme installed (GNOME's Adwaita, KDE's whatever, or something else should be fine).
But it does not seem to be the case and it looks like it is checking for a presence of hicolor-icon-theme:

env XDG_DATA_DIRS= $(nix-build -A mypaint --no-out-link)/bin/mypaint was broken
env XDG_DATA_DIRS=$(nix-build -A hicolor-icon-theme --no-out-link)/share $(nix-build -A mypaint --no-out-link)/bin/mypaint worked

Let's add it to the closure unconditionally, since it is just an empty directory tree and weights almost nothing.
Noticed by @sikmir in https://github.com/NixOS/nixpkgs/pull/54677#issuecomment-595188605
Things done

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

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

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

It works now!


Words of feedback from the French NAP

Hello there! I work on https://transport.data.gouv.fr/ and I did some testing on the NeTEx validator, I wanted to share it with the authors & other users here. Thanks for your work on this!
I have not yet been able to review the output of the reports themselves, so this first round is more about onboarding / "surprise report" and potential production issue (RAM use etc), than the quality of the reports.
Hope this helps!
Installing from source is useful
Being able to install from source is useful in our case, because our main app is itself a "non privileged Docker container" at the moment ; we cannot run a docker command from there.
We cannot either run go cmd/* in production, because the go binary won't be there in the final Docker image.
I explored the Dockerfile and found how you actually build the binary:
https://github.com/ITxPT/DATA4PTTools/blob/c9c257389aec270c73b23977e9966c5f671e2d0f/Dockerfile#L7
Using this command allowed me to build a complete standalone binary which I can use.
Initially, the cmd/* pattern was a bit confusing to see, since it was a bit unclear if these were different programs, or parts of the same program (the latter was the answer), but that is not a big problem.
The doc could be improved to document how to prepare a full binary.
There is telemetry by default
I was quite surprised to see that there is some hardcoded endpoint to which usage data appears to be sent by default.
I have created a specific issue for that part:
https://github.com/ITxPT/DATA4PTTools/issues/23
Although I understand the usefulness of this to you while building the tool, I believe this is problematic from a RGPD point of view.
To the very least I feel this should be advertised in the readme, or even an opt-in behaviour (at the cost of reducing your tracing rate).
I don’t believe most users will realize this is happening!
Time taken & memory used
Both time taken & memory used are a concern at the moment for production automated use (as part of server apps).
I have commented on existing issues:

validation can take a lot of time (> 45 minutes) xsd validation is too slow · Issue #9 · ITxPT/DATA4PTTools · GitHub
crash when the memory is too low (SIGSEV error when validating norwegian test data · Issue #13 · ITxPT/DATA4PTTools · GitHub) ; one can simulate that with Docker -m flag:

docker run -it -m 1GB -v $(pwd):/greenlight/documents lekojson/greenlight validate -i /greenlight/documents/export-intercites-netex-last.zip

Non-linear memory use (or too high use) will be a problem for production use, since we allocate a fixed number of GB per container, and cloud environments can be costly from a RAM point of view.
Documentation improvement
For docker run, it could be nice to assume that the user validates files in its current folder ; it can be traditionally done by using $(pwd) on Mac/Linux and %cd% on Windows.
docker run -it -v $(pwd):/greenlight/documents lekojson/greenlight validate -i /greenlight/documents/export-intercites-netex-last.zip

The help at GitHub - ITxPT/DATA4PTTools: Shared space for the development of the DATA4PT validation tool(s) lacks the -i myfile flag at time of writing.
Some dependencies should be upgraded
Warning on “sarama” while compiling from source · Issue #22 · ITxPT/DATA4PTTools · GitHub
That's it for today ; thanks for open-sourcing the tool & the discussion!

Thank you for testing out the tool, and the detailed feed back.
It was very helpful, with comments and example files to reproduce the errors.
We have answered in each separate issue.

We are working on an updated documentation, all sections will be updated during the summer, including your suggestions.

Many thanks @pkvarnfors for your feedback!


Consistent Release dir

Make the content of Release dir consistent. This is needed to prepare the repo for the new build script.

Sorry I modified some stuff on Parse.nuspec. Can you take a look again?

LGTM


[Go Live][APR 20]

Push to live

Docs Build status updates of commit 102aad1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/assets/images/publish-app/app-scopes.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/apps-in-channels.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/bin-icon.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/manage-apps-list.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/manage-apps.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/publish-app.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/remove-app-teams.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/uninstall-from-channel.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/uninstall-from-teams.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/update-available.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/update-window.png
:white_check_mark:Succeeded
View

msteams-platform/assets/images/publish-app/updated-app.png
:white_check_mark:Succeeded
View

msteams-platform/bots/what-are-bots.md
:white_check_mark:Succeeded
View

msteams-platform/concepts/deploy-and-publish/apps-upload.md
:white_check_mark:Succeeded
View

msteams-platform/get-started/get-started-overview.md
:white_check_mark:Succeeded
View

msteams-platform/mstdd-landing.yml
:white_check_mark:Succeeded
View

msteams-platform/whats-new.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Unicorn is restarted at the wrong time

My cap deploy runs fine but I get (111: Connection refused) in my nginx logs after my deploy is complete (hence 502 errors). From the output of cap deploy I can see that both nginx and unicorn have been restarted.
I have to run a  cap unicorn:restart explicitly after cap deploy to fix this.
my Capfile:
# Load DSL and set up stages
require 'capistrano/setup'

# Include default deployment tasks
require 'capistrano/deploy'

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob('lib/capistrano/tasks/*.rake').each { |r| import r }

require 'capistrano/delayed-job'
require 'capistrano/rvm'
require 'capistrano/rails'
require 'capistrano/unicorn_nginx'
require 'capistrano/secrets_yml'
require 'capistrano/cookbook/check_revision'

my deploy.rb:
# config valid only for current version of Capistrano
lock '3.4.0'

set :application, 'instano-api'
set :repo_url, 'git@bitbucket.org:vedanta/instano-api.git'

# Default branch is :master
ask :branch, `git rev-parse --abbrev-ref HEAD`.chomp
set :user, 'ubuntu'

# Default deploy_to directory is /var/www/my_app_name
set :deploy_to, "/home/#{fetch(:user)}/apps/#{fetch(:application)}"

# Default value for :scm is :git
# set :scm, :git

# Default value for :format is :pretty
# set :format, :pretty

# Default value for :log_level is :debug
# set :log_level, :debug

# Default value for :pty is false
set :pty, true

# Default value for :linked_files is []
set :linked_files, fetch(:linked_files, []).push('config/database.yml', 'config/secrets.yml')

# Default value for linked_dirs is []
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', 'public/system')

# Default value for default_env is {}
# set :default_env, { path: "/opt/ruby/bin:$PATH" }

# Default value for keep_releases is 5
set :keep_releases, 5

# unicorn_nginx options
# ==================

set :unicorn_workers, 4

# Custom SSH Options
# ==================
# You may pass any option but keep in mind that net/ssh understands a
# limited set of options, consult the Net::SSH documentation.
# http://net-ssh.github.io/net-ssh/classes/Net/SSH.html#method-c-start
#
# Global options
# --------------
set :ssh_options, {
  keys: %w(/home/vedant/.ssh/xmpp-user.pem),
  forward_agent: true
}

set :rvm_ruby_version, '2.1.0'

set :delayed_job_command, "bin/delayed_job"
set :rails_env, "production" #added for delayed job

before :deploy, 'deploy:check_revision'

namespace :deploy do

  after :finished, :restart_rpush do
    on roles(:web) do
      within release_path do
        with rails_env: fetch(:rails_env) do
          execute :bundle, :exec, "rpush stop -e #{fetch(:rails_env)} ; true"
          execute :bundle, :exec, "rpush start -e #{fetch(:rails_env)}"
        end
      end
    end
  end

  after :restart, :clear_cache do
    on roles(:web), in: :groups, limit: 3, wait: 10 do
      # Here we can do anything such as:
      # within release_path do
      #   execute :rake, 'cache:clear'
      # end
    end
  end

  desc "build missing paperclip styles"
  task :build_missing_paperclip_styles do
    on roles(:app) do
      execute "cd #{current_path}; RAILS_ENV=production bundle exec rake paperclip:refresh:missing_styles"
    end
  end
end

+1
Did you find the solution ?

+1 for me as well.  I think it has to do with the sudo service unicorn_xyz_env restart call.
When I run sudo service unicorn_xyz_env restart with unicorn running, it simply kills unicorn, resulting in 502s.  If I run the same command again, unicorn starts properly.  Repeating again, simply kills unicorn, and so on...
I'm wondering if this is an issue with unicorn...?

+1
any solution ?

It happens the same to me, it seems to be have something with the Unicorn init.d script.
I think this is the same issue: https://github.com/capistrano-plugins/capistrano-unicorn-nginx/issues/62
Unicorn signals: https://unicorn.bogomips.org/SIGNALS.html

I fixed the problem in my server.
See the explanation in the pull-request https://github.com/capistrano-plugins/capistrano-unicorn-nginx/pull/93.
Until it gets merged you can use my fork.

This is merged now.


fix: nil pointer panic when auth decode body failed

这个 PR 实现什么功能/修复什么问题:
修正：keystone auth nil pointer panic when auth body decode failed
是否需要 backport 到之前的 release 分支:

release/2.10.0
release/2.11
release/2.12

/area keystone
/cc @yousong @zexi

Codecov Report

Merging #3487 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master   #3487      +/-   ##
=========================================
- Coverage    6.99%   6.99%   -0.01%
=========================================
  Files         498     498
  Lines       83083   83086       +3
=========================================
  Hits         5809    5809
- Misses      76780   76783       +3
  Partials      494     494

Flag
Coverage Δ

#aFlag
6.99% <0%> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/keystone/tokens/handlers.go
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

/approve
/lgtm


[poco] update to1.13.3

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] The "supports" clause reflects platforms that may be fixed by this new version.
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Features crypto,netssl,pdf,postgresql,sqlite3 tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static


Fix the back button issue

Please Verified and merged with the  master.

Verified and merged with the  master.


Nested Redux States

Description
Hi, I'm new to this room  but have been using react-boilerplate for a while now. I have a query about nested Redux states and would really appreciate it if someone can help me figure this out.
Hopefully it should be easy enough to answer as it is kind of a fundamental question.

As per the redux docs, it's most advisable to keep the redux state separated as domains.
{
    simpleDomainData1: {....},
    simpleDomainData2: {....},
    entities : {
        entityType1 : {....},
        entityType2 : {....}
    },
    ui : {
        uiSection1 : {....},
        uiSection2 : {....}
    }
}

How do achieve this data structure in react-boilerplate? I have been creating my Containers using the built-in generators, and keeping them all at the same level like so:
App
|__ Components
|__ Containers
      |__ Container1
      |__ Container2
      |__ Container3
      |__ Container4
      :
      :

My redux state is super normalized like so:
{
  route: {
    location: {
      ....
    }
  },
  container1: {
    data: {}
  },
  container2: {
    data: {}
  },
  container3: {
    data: {}
  },
  container4: {
    data: {}
  }
}

But I am now at a place where I need to nest Containers 2 and 3 within Container 1 (according to the business logic). How can I also mirror this structure on my redux store?
{
  route: {
    location: {
      ....
    }
  },
  container1: {
    data: {
          container2: {
                 data: {...}
           },
           container3: {
                data: {...}
           },
       }
  },
  container4: {
    data: {}
  }
}

How can we use injectReducer to implement nested states? Or is there another approach that you all use? TIA!!

I have tried having all of the reducers for Container1 defined under /Container1, thereby giving me control of the whole state, but that seems like an anti-pattern

I haven't yet tried nesting Containers 2 and 3 inside Container1 because I couldn't figure out how the injectReducer util would work under those circumstances.

(I've also posted this on Gitter)

If I haven't misinterpreted, have you tried switching on an action.type and passing to the relevant reducer? That pattern and a few others are described in the redux recipes here

@0ui Could you perhaps explain what you meant a little further? Maybe provide some pseudo code? I didn't quite get the

switching on an action.type and then calling the relevant reducer

part.

You need to have a reducer with a switch statement that returns a certain
piece of state based on the the action.type.
You then need to create a rootReducer that combines all the different
pieces of state together.
On Sat, Sep 8, 2018, 4:29 PM nikjohn<EMAIL_ADDRESS>wrote:

@0ui https://github.com/0ui Could you perhaps explain what you meant a
little further? Maybe provide some pseudo code? I didn't quite get the
switching on an action.type and then calling the relevant reducer
part.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/react-boilerplate/react-boilerplate/issues/2335#issuecomment-419670762,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ1sXCC-h4zP5CdORREBBMVmlJM361YAks5uZCiLgaJpZM4WfZ4w
.

Yes, sorry it wasn't clear I was referring to adding an additional property like actionType to the actions for your reducers to indicate how they should be handled. Then in your Container1 reducer, importing/calling the other containers' reducers. Something like
import container2Reducer from 'containers/Container2/reducer'
import container3Reducer from 'containers/Container3/reducer'

...

function container1Reducer(state, action) {
  switch (action.actionType) {
    case 'container2Related':
      return container2Reducer(state, action)
    case 'container3Related':
      return container3Reducer(state, action)
...

And they can all modify the same slice. I think I've seen it done like that before.

I ended up doing something like this @0ui
import container2Constants from 'containers/Container2/constants'
import container2reducer from 'containers/Container2/reducer'
...

function container1Reducer(state, action) {
   if (container2Constants.includes(action.type)) {
     return container2reducer(initialState, action);
   }
  ...
  ...
  switch (action.actionType) {
    case 'container2Related':
...

I just imported all of the constants in Container2 and 3 as an array. It seems to be working fine, but I still feel icky about it. it doesn't seem to be the correct way to me.

@0ui has written the standard convention as I've seen and done @nik-john, if that's helpful to know. I use the same pattern in production applications. It's definitely the cleanest implementation.


Powertoys Run Program Plugin Starts Slowly

Microsoft PowerToys version
0.71.0
Installation method
GitHub, PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
PowerToys Run
Steps to reproduce
Run Powertoys with Powertoys Run and the Program feature enabled. Disabling the Program feature should cause the issue to go away.
✔ Expected Behavior
A fast startup time around a couple seconds for Powertoys Run.
❌ Actual Behavior
Powertoys Run takes minutes to startup, with the bulk of that time being spent in the programs plugin (About 200000ms).
Other Software
No response

/dup #21581


SRCH-5714 add ability to do a single benchmark run

Summary
Created this draft PR to help facilitate bench marking... what about something like this? gives us some flexibility?
EXPORT BENCHMARK_RUN=True
python search_gov_crawler/scrapy_scheduler.py --starting_urls="https://quotes.toscrape.com" --allowed_domains="quotes.toscrape.com"

This will add a job using a similar process as would with the no-UI functionality (and also scrapydweb I think) but we can control what we pass in.
If we need more configurable options we can add more environment variables or add a config file.
Checklist
Please ensure you have addressed all concerns below before marking a PR "ready for review" or before requesting a re-review. If you cannot complete an item below, replace the checkbox with the ⚠ :warning: emoji and explain why the step was not completed.
Functionality Checks

[ ] You have merged the latest changes from the target branch (usually main) into your branch.

[ ] Your primary commit message is of the format SRCH-#### <description> matching the associated Jira ticket.

[ ] PR title is either of the format SRCH-#### <description> matching the associated Jira ticket (i.e. "SRCH-123 implement feature X"), or Release - SRCH-####, SRCH-####, SRCH-#### matching the Jira ticket numbers in the release.

[ ] Automated checks pass. If Code Climate checks do not pass, explain reason for failures:

Process Checks

[ ] You have specified at least one "Reviewer".

Code change in the scheduler makes sense to me. I'm not sure if it was just for an example but think we would want to use actual federal domains and not quotes to scrape.

For sure... you can pass in any domain/starting url and also enable javascript
python search_gov_crawler/scrapy_scheduler.py --starting_urls="https://www.fac.gov/" --allowed_domains="fac.gov"
python search_gov_crawler/scrapy_scheduler.py --starting_urls="https://www.js.example/" --allowed_domains="js.example" --handle_js


Legent problem: Charaters are converted to lower case by itself.

All AP names are capital letters, but the first one "0CAF" appears as "0Caf" in the legend.
Also the column name is "AP' not "Ap", which is automatically changed in ggplot.

fixed in 0.9.3


Standardize bug tracker references in test metadata

It would be nice to have some standard and machine-readable way to add references to bug trackers in tests. I think the only semantic link that makes sense here is "this test covers these bugs", so probably a simple list of bug references would be enough. Also, bug trackers can be distinguished based on the URL, so a simple list of URLs would likely suffice:
links:
- https://bugzilla.redhat.com/show_bug.cgi?id=123
- https://github.com/my/project/issues/123

Side note: This could be used in tmt export --nitrate to populate the list of associated RHBZs.

We have an ongoing (well actually it's a bit sleeping now) discussion about this in #215.

Ah, missed that, sorry... Feel free to close this one as a duplicate.

Ok, let's continue the discussion in #215.


Add hashes for commonly used fields in image graph

Description
Need for speed
time_exec_secs    |     mean_exec_ms     |  calls  | query

7359.726410597999 |   2132.6358767308047 |    3451 | DELETE FROM image_components WHERE id = ANY($1::text[])
3838.226686027004 |<PHONE_NUMBER>0652633 |   19276 | SELECT serialized FROM image_cve_edges WHERE imageid = $1
2242.547940951997 |<PHONE_NUMBER>1675857 |   19273 | SELECT serialized FROM image_component_edges WHERE imageid = $1
1369.327693140993 |     71.0490164033105 |   19273 | SELECT serialized FROM image_component_cve_edges WHERE imagecomponentid = ANY($1::text[])

Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Do you have a before and after for the performance?

Do you have a before and after for the performance?
Running the scale test now, but also added it to the large scale run I'm doing and we should see mean_exec_ms drop. Waiting for a bit then will post

Substantial drop in runtime


fix conversion to number

I noticed that this breaks when the hint is number, based on my understanding and tests*, this fixes it.

my test:

const compare = (...args) => console.table(
    Object.fromEntries(
        args.map(x => [
            `[${x.join(', ')}]`,
            [
                Number(x),
                Number(x.toString()),
                Object.is(Number(x), Number(x.toString()))
            ]
        ])
    )
)
compare([1], [], [[2]], [3, 4])

Good catch! I never knew that an array with single number in it gets converted to that number upon coercion to a number! I learned something today
Will merge tomorrow and do a release


(click) not recognized for first 3 seconds in views

Hello
Using Ionic 2.0.0-beta.35
I have a list of items displayed in a virtual scroll, or ngFor.  Everything works fine in the browser, but when I put it on my ipad, the first tap on items in the list is not recognized.  What's more, I have to wait approximately 1 second after the first tap, or the second tap will not work either.

Ok, I have some more info after more testing.  Whenever I show a list, it takes about 3 seconds for the list to become responsive and (click) to be executed.  The list has already rendered fine, so I don't know what the delay is about.

Hello! Thanks for opening an issue with us! Would you mind putting the tappable attribute on your list items and see if that fixes the issue? Example
<ion-item tappable>
</ion-item>

Hello all! As it seems it has been a while since there was any activity on this issue i will be closing it for now. Feel free to comment if you are still running into this issue. Thanks for using Ionic!

Hello @jgw96
I am facing the same issue with a bit complex ion-item which has multiple clickable divs inside it. Inspite of adding tappable to individual div, 3 sec delay exists when coming back from details (previewInvoice(invoice)) to list. Please guide.
<ion-item *ngFor="let invoice of dateInvoiceList.invoiceList" class="transparentBg invoice-item no-padding" no-lines>

        {{invoice.Status | paymentstatus | uppercase}}

{{invoice.PatientName}}

{{invoice.invoiceFee}}

{{invoice.RequestReason}}

        <ion-grid class="no-padding">
          <ion-row center>
            <ion-col class="no-padding">

                <ion-icon ios="ios-share-outline" md="md-share" class="middle-align"></ion-icon>
                Send

            </ion-col>
            <ion-col class="no-padding side-margin-5">

= reminderStatus.Reminder_1_Sent && invoice.ReminderStatus < reminderStatus.Late" (click)="showReminderSentConfirmationPromt(invoice)"
                class="custom-button custom-button-count">
                Reminded
                <ion-badge item-right class="reminder-count">{{invoice.ReminderStatus | reminderstatus}}</ion-badge>

                Late

            </ion-col>
          </ion-row>
        </ion-grid>

</ion-item>

Hi, the tappable attribute solved the issue in my case. Thanks


zoom state should be initial when zooming out to min scale

I'm currently using the widget with the following settings:
initialScale: 1.0,
minScale: 1.0,
maxScale: 3.0

I was expecting when i'm zooming out to the min scale, the zoom state should be either originalSize or initial. But it returns the state zooming

Related to #61 and the issues pointed on #60

That only happens when we have the same value as initialScale and minScale. The reverse can occur when initialScale and maxScale share values.
To go solve this bug we have to detect the current scale factor whenever the scaling gesture (and its animations) ends.
Working on it.

I write here even if there are a lot of closed issue about this strange behavior. My problem is that minScale is not respected. I tried the suggestions found between the closed issues but I didn't find a solution.
Here my code:
import 'package:flutter/material.dart';
…
import 'package:photo_view/photo_view.dart';

class WMSnapshotPage extends StatelessWidget {

  const WMSnapshotPage({Key key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: fcsAppBar(context, 'Camera Snapshot'),
        body: Center(
          child: FutureBuilder(
            future: getImageUrl(),
            builder: (context, image) {
              if (image.hasData) {
                return PhotoView(
                    loadingChild: FCSLoader(),
                    minScale: PhotoViewComputedScale.contained,
                    imageProvider: NetworkImage(image.data));
              }
              return Container();
            },
          ),
        ));
  }
}

As described above the problem is that when I zoom out, minimum scale is not respected.


Add smoke test on browser

To avoid start issues when running on browsers (incompatibilities at runtime)
The intention is to detect early these kind of issues: https://github.com/RedHatInsights/policies-ui-frontend/pull/156

Convertir to PR just to test the run in travis

Codecov Report

Merging #170 into master will decrease coverage by 0.14%.
The diff coverage is 82.50%.

@@            Coverage Diff             @@
##           master     #170      +/-   ##
==========================================
- Coverage   91.79%   91.65%   -0.15%
==========================================
  Files         149      148       -1
  Lines        2878     2888      +10
  Branches      488      489       +1
==========================================
+ Hits         2642     2647       +5
- Misses        234      239       +5
  Partials        2        2

Impacted Files
Coverage Δ

src/app/AppContext.tsx
60.00% <33.33%> (-6.67%)
:arrow_down:

...components/Policy/ActionForm/ActionWebhookForm.tsx
66.66% <50.00%> (-11.12%)
:arrow_down:

src/config/Config.ts
91.66% <66.66%> (-8.34%)
:arrow_down:

src/app/FetchingConfiguration.ts
85.71% <75.00%> (-14.29%)
:arrow_down:

src/app/useApp.ts
96.15% <87.50%> (-3.85%)
:arrow_down:

src/app/App.tsx
100.00% <100.00%> (ø)

src/components/Beta/BetaDetector.tsx
100.00% <100.00%> (ø)

src/components/EmailOptIn/EmailOptIn.tsx
100.00% <100.00%> (ø)

src/components/Policy/AddTriggersDropdown.tsx
100.00% <100.00%> (ø)

src/components/Trigger/Table.tsx
97.50% <100.00%> (+0.20%)
:arrow_up:

... and 1 more

When reverting #156 we correctly get an error on Firefox
Firefox 63.0 (Linux x86_64): Executed 0 of 0 SUCCESS (0 secs / 0 secs)
Firefox 63.0 (Linux x86_64) ERROR
  An error was thrown in afterAll
  SyntaxError: invalid identity escape in regular expression
  test/SmokeTest.js:162378
Firefox 63.0 (Linux x86_64): Executed 0 of 0 ERROR (0 secs / 0 secs)

https://travis-ci.org/github/RedHatInsights/policies-ui-frontend/builds/703284005#L1280-L1285

Moving back to draft, some code could conflict with the pf4-migration.

Replaced by https://github.com/RedHatInsights/policies-ui-frontend/pull/180


Parameters list not properly aligned inside help text

Description
Given the following configuration:
[commands]
[commands.update]
script = "git pull && git fetch --prune && yarn"
description = "Update this repository."

[commands.open]
script = "openapp %{link}"
description = "Open an App link inside the running simulator."

[params.link]
shortcut = "l"
description = "Link to open inside the running App simulator."

The following help is generated:
Litr - Language Independent Task Runner [version 1.0.0-alpha.3]
  Configuration file found under: /.litr.toml

Usage: litr command [options]

Commands:
  open    --link=<option>
             Open an App link inside the running simulator.
  update     Update this repository to the latest and run install commands.

Options:
  -h --help  Show this screen.
  -v --version Show current Litr version.
  -l --link  Link to open inside the running App simulator.

Problem
The parameters are not properly aligned inside the help text. They should all be 2 spaces after the version flag.

Ref: https://github.com/krieselreihe/litr/blob/main/src/client/Client/Hooks/Help.cpp#L297


Can't install react-sparklines

When I try to install sparklines it shows an error in the console:
└─┬<EMAIL_ADDRESS>└── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>npm WARN EPEERINVALID<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.

I googled the error and tried to change the react dependency in package.json from: ^0.14.8  to 15.2.1
But now it throws two errors:
npm WARN EPEERINVALID<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN EPEERINVALID<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.

Found this errors because when I try to render Sparklines it throws theres errors on console:
bundle.js:1269 Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components).  Check the render method of `WeatherList`.(…)

If I remove the Sparklines elements it doesn't throw any errors in the console.

Here is my package.json file when I worked on this tutorial. I hope it helps. I had no problems at all using "react": "^0.14.3" https://github.com/gabemartinez/clima/blob/master/package.json

@gabemartinez thank you but it still shows the same error, I think it's something about my environment but I don't have a clue what it could be

@salsadeanguila  You may just have some invalid JSX

@salsadeanguila I saw the same initial warning when installing react-sparklines for the weather app.
└─┬<EMAIL_ADDRESS>  └── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.

I basically ignored it, and was still able to successfully import the sparkline components into the project without changing any of the dependencies. I think it's an issue with the peerDependency in the react-sparklines module.

Just ran into this. Installing an older version of sparklines works. The newest version must require a newer version of react than what we use with the simple starter. Just run
npm install --save<EMAIL_ADDRESS>

Sorry, but I'm having the same error as the first comment.
I added import { Sparklines, SparklinesLine } from 'react-sparklines'; and this is my package.json:
{
  "name": "redux-simple-starter",
  "version": "1.0.0",
  "description": "Simple starter package for Redux with React and Babel support",
  "main": "index.js",
  "repository": "git@github.com:StephenGrider/ReduxSimpleStarter.git",
  "scripts": {
    "start": "node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js",
    "test": "mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test",
    "test:watch": "npm run test -- --watch"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babel-core": "^6.2.1",
    "babel-loader": "^6.2.0",
    "babel-preset-es2015": "^6.1.18",
    "babel-preset-react": "^6.1.18",
    "chai": "^3.5.0",
    "chai-jquery": "^2.0.0",
    "jquery": "^2.2.1",
    "jsdom": "^8.1.0",
    "mocha": "^2.4.5",
    "react-addons-test-utils": "^0.14.7",
    "webpack": "^1.12.9",
    "webpack-dev-server": "^1.14.0"
  },
  "dependencies": {
    "axios": "^0.16.2",
    "babel-preset-stage-1": "^6.1.18",
    "lodash": "^3.10.1",
    "react": "^0.14.3",
    "react-dom": "^0.14.3",
    "react-redux": "4.3.0",
    "react-router": "^2.0.1",
    "react-sparklines": "^1.4.0",
    "redux": "^3.0.4",
    "redux-promise": "^0.5.3"
  }
}

but still with error:
Uncaught TypeError: Super expression must either be null or a function, not undefined
    at _inherits (bundle.js:25009)
    at bundle.js:25012
    at Object.<anonymous> (bundle.js:25056)
    at __webpack_require__ (bundle.js:24383)
    at Object.defineProperty.value (bundle.js:24947)
    at __webpack_require__ (bundle.js:24383)
    at Object.<anonymous> (bundle.js:24937)
    at __webpack_require__ (bundle.js:24383)
    at bundle.js:24426
    at bundle.js:24429

Do you have any update with dependencies problems?
Thanks for any help!!!

It was solved with the update suggested in #117

as @freb mentioned just downgrade sparklines in your package.json to 1.5.0.
mine was 1.7.0, and also tried 1.6.0 which both game me an error:

"Uncaught TypeError: Super expression must either be null or a function, not undefined"

downgrade to version 1.4.2
when i downgraded by charts are loading just fine.
$ npm uninstall react-sparklines --save
Thereafter install version 1.4.2
$ npm install<EMAIL_ADDRESS>--save
All The Best


capability: unbreak

Motivation for this change
The package compiles and works just fine without any additional changes.
I created a tiny Cabal project that uses the library and just prints something and it works perfectly well. I'm also using it in a little Haskell side project and here too, with NIXPKGS_ALLOW_BROKEN=1 it works.
Things done

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

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

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

/rebase haskell-updates

yikes, sorry forgot about that

Cherry picked on top of haskell-updates, thank you! https://github.com/NixOS/nixpkgs/pull/118350/commits/8fa0c918da65a732864daea213fa3bdd77a8fd54.

Wow this was fast, thanks and sorry again about the incorrect base :see_no_evil:


ConnectionState always waiting in StreamBuilder

I using Bloc pattern in my flutter project. In MainPage, I will add List<HashMap<int,ABC>> into list.
 var list = List<HashMap<int, ABC>>();
 var hashMap = HashMap<int, ABC>();
 var groupedList =
        groupBy(listOfAbc, (ABC item) => item.id);  // group by id

     for (var key in groupedList.keys) {
          for (var value in groupedList[key]) {
            if ((value.notification_type == "abc")) {
              setState(() {
                hashMap[key] = value;
                list.add(hashMap);
                _abcBloc.abcSink.add(list);
              });
            }
          }
        }

After that I will display the stream in pageB.
return StreamBuilder<List<HashMap<int, ABC>>>(
           stream: _abcBloc.abcStream,
           builder: (context, snapshotData) {
           switch (snapshotData.connectionState) {
           case ConnectionState.active:
           return Text(snapshotData.data.toString());
           break;

          case ConnectionState.waiting:
          return Text("Waiting");
          break;

         default:
         return Text("error");
        }
    });

If the list is not equal to zero, I can see Text(snapshotData.data.toString()) display on UI. But if the list is zero, the UI is displayed waiting. How can I fix it? Why it is always in ConnectionState.waiting  if there are nothing add into sink ?
Bloc
 final _abc = BehaviorSubject<List<HashMap<int, ABC>>>();
 get abcSink => _abc.sink;
 get abcStream => _abc.stream;

Hi @tony123S
can you please provide your flutter doctor -v
and a reproducible minimal code sample
that does not involve 3rd party packages
Thank you

Yes that's an issue with me too on Flutter Dev v1.15.2

Hi @iampawan
can you please provideyour flutter run --verbose
and if possible a reproducible minimal code sample.
Thank you

Hi @tony123S
Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Add BYOCA

#sign-off

#sign-off

#sign-off

@Mzamankhan , I signed off. You can see the ready-to-merge label. This is the public repo (not private). A PR reviewer needs to merge the PR. It's better to use the private repo to avoid the extra steps.


Create ServiceMonitor for Sonarr and Radarr Exporters instead of having in prometheus-operator configuration

Possibly something like this
https://github.com/coreos/prometheus-operator/issues/2557

Done and added to my manifests:
https://github.com/onedr0p/k3s-gitops/tree/master/deployments/monitoring/sonarr-exporter
https://github.com/onedr0p/k3s-gitops/tree/master/deployments/monitoring/radarr-exporter


Strange timestamp behavior with osmo-trx-lms and LMS_RecvStream

I am currently in the process of writing a new direct backend for osmo-trx which uses LimeSuite directly instead of going through the entire stack of UHD->SoapyUHD->SoapySDR->SoapyLMS7->LimeSuite.
Branch adding initial support for it can be found in upstream branch pespin/lime:
https://git.osmocom.org/osmo-trx/log/?h=pespin/lime
However, I am currently seeing some unexpected behavior with timestamps.
Basically, I call LMS_RecvStream in a tight loop with len=2500, and first times the jump in timestamp after each iteration is 2500 (0x9c4) as expected. However, at the 4th iteration the jump is of  4d1c - 1388 = 14740 samples, so it seems something in there is not going as I would expect.
20180426144040908 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 0
20180426144040908 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 9c4
20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 1388
20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 4d1c
20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 56e0
20180426144040909 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 60a4
20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 6a68
20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 742c
20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 7df0
20180426144040910 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 87b4
20180426144040911 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 9178
20180426144040911 DMAIN <0000> LMSDevice.cpp:326 [tid=140607662315264] Flush: Recv buffer of len 2500 at 9b3c

Further information for this report can be found in:
https://osmocom.org/issues/2919#note-2

@IgnasJarusevicius, would be grateful if you could take a look at this, please.

https://git.osmocom.org/osmo-trx/tree/Transceiver52M/device/lms/LMSDevice.cpp?h=pespin/lime#n143
The main problem I see with your code is that you first do your configuration, and then you call LMS_Init, which basicaly resets the board and all your configuration is lost. That would also explain your note output from ettus b200 running with UHD suggests that the limesdr clock is running around 4 times faster than it should.
After you LMS_Open then you should call LMS_Init and after that you can apply your desired settings.

Indeed, we already spotted and fixed that issue in https://git.osmocom.org/osmo-trx/log/Transceiver52M/device/lms/LMSDevice.cpp?h=laforge/lime, however I'm not sure how that can explain the jumping in the timestamps.
I'll do some more tests soon with the new code in this branch and provide feedback regarding this issue.

check out these threads:
https://discourse.myriadrf.org/t/small-packet-loss-in-the-beginning-of-the-rx-stream/1861/2
https://discourse.myriadrf.org/t/limesdr-tx-and-unknown-features-in-rx/2652/2

I have done some testing with LimeSDR-USB on Ubuntu 16.04 by adding some timestamps checks and printf's to LimeSutieGUI and dualRXTX example. For me timestamps start at 0 and continues without jumps so USB buffers seem to be properly cleared on stream start.
Normally, timestamps  jumps occur when samples are not read from HW fast enough.

Yes, maybe that happens because we were calling Init() at the end and maybe a really high sample rate was set. I'll give it a try with our new branch soon and provide feedback on this issue.

Indeed, with our last changes calling Init at proper place I no longer see the behavior I posted here. Closing the issue.


Fix Forge 50 (1.20.6)

Blocked by https://github.com/Juuxel/union-relauncher/pull/1

1.21 exists now but this would still be very nice


Authenticated media support

Matrix v1.11 introduces MSC3916 - Authenticated Media which when implemented and enabled on a homeserver, requires clients to send the users access token with any requests for media files which were uploaded after the setting was enabled.
This is still currently an optional setting, but quick adoption is likely and the matrix.org homeserver itself is scheduled to enable it on September 4th, 2024.
Currently iamb will return the following message when attempting to retrieve new media (media from before the setting was enabled is fine, as expected) from a Synapse server with enable_authenticated_media: True set:  [Image error: Matrix(Http(Api(Server(ClientApi(Error { status_code: 404, body: Standard { kind: NotFound, message: "Not found" } })))))]
The Client implementation guidance section of the v1.11 release announcement may be helpful.

Oh, I see. This should happen automatically by updating the matrix-sdk dependency https://github.com/matrix-org/matrix-rust-sdk/pull/3598 from 0.7.1 to something newer, but that either has not been released and/or the crates.io entry has not been updated yet. https://crates.io/crates/matrix-sdk

I tried changing the version property of the matrix-sdk dependency to a git reference the latest commit of main on the matrix-rust-sdk in Cargo.toml, but I found there were a few breaking changes. Someone with a better understanding of the codebase and the matrix rust sdk may want to have look, it could be the needed changes are actually minimal.

Looks like https://github.com/matrix-org/matrix-rust-sdk/issues/3742 is the issue to watch for any planned release of matrx-rust-sdk.

matrix-sdk v0.8.0 is now released and is up on crates.io! https://crates.io/crates/matrix-sdk

There is an updated version in Issue 378. @dstu, I will run your fork and report any issues.


Graph.graph_it wont accept lists as data

Major bug, fix ASAP.

Code finished, Will be added at next version.


Add tokenId

Pull Request Test Coverage Report for Build 1861

0 of 0   changed or added relevant lines in 0 files are covered.
90 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.007%) to 71.778%

Files with Coverage Reduction
New Missed Lines
%

dist/routes/v2/slp.js
90
51.51%

Totals

Change from base Build 1854:
0.007%

Covered Lines:
1992

Relevant Lines:
2581

💛  - Coveralls


proposal: handle immutable resources on update

Steps to reproduce the issue:
helm create tmp
echo '
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
    name: {{ include "tmp.fullname" $ }}
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: {{ .Values.role }}
subjects: []
' > tmp/templates/rolebinding.yaml
helm install tmp tmp --set role=view
helm upgrade --force tmp tmp --set role=edit

This fails with
Error: UPGRADE FAILED: failed to replace object: RoleBinding.rbac.authorization.k8s.io "tmp" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"ClusterRole", Name:"edit"}: cannot change roleRef

The expected result would be that helm replaces the role binding due to the --force flag.
The problem was already discussed in #6468 but it was mentioned that --force should work, so I am reporting this as new issue.
Output of helm version:
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.4", GitCommit:"a87e9a978f65a8303aa9467537aa59c18122cbf9", GitTreeState:"clean", BuildDate:"2019-07-08T08:51:16Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-16T01:01:59Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
kind (and Openshift)

Hi,
I have tried for this. And I found in code here: https://github.com/helm/helm/blob/master/pkg/kube/client.go#L393. It means that when "--force" exits, attempt to call apiserver for PUT resource api. Besides, when "--force" doesn't exits, attempt to call apiserver for PATCH resource api.
When I tried the PUT api to change role to "edit" in your yaml, I got the same error:

I guess this field in rolebinding can't be changed in k8s side. So, I think it's the wrong way to change roleRef and Helm did the right thing.

Helm 2 used to delete and re-install the resource on a PATCH failure, which led to a lot of cases where things like spurious client timeouts causing the patch to fail would delete the resource... Not exactly what you'd call a great experience.
In Helm 3, the behaviour of --force was refactored to better align with its intent: to force a PUT operation (an overwrite) when the user requests. This allows the user to bypass the three-way merge patch strategy, forcing idempotency.
If there are certain objects that cannot be replaced, we can look up the expected behaviour from Kubernetes' side of things. In this particular case, certain fields present in a role binding cannot be changed/replaced once they've been created as @zwwhdls rightly pointed out. So this seems intentional from Kubernetes' point of view. If you want to modify the role binding, my suggestion would be to delete it from the cluster first before upgrading.
Hope this helps!

@bacongobbler thanks for explaining this difference between Helm 2 and Helm 3. I agree that the way Helm 3 works with --force updates is very good for most use cases, since no unnecessary recreation of resources happens, which could cause trouble.
However, I assume that it will be problematic for some resources, that no --force update is possible anymore without manual intervention. So I would suggests to extend helms behavior on --force updates with a fallback to delete and create, when it receives a 422 response on the PUT request. This would then still not cause any unnecessary re-creations but would still make sure all resources can be update via Helm --force.
To illustrate, why I think this would be important, I would like to explain a little more detail why updating a roleRef is a standard use case.
When developing a chart with a deployment that requires a service account with certain permissions, I usually create three objects in the template (ServiceAccount, Role, RoleBinding):
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ include "my-chart.fullname" . }}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ include "my-chart.fullname" . }}
rules:
  - verbs
      - get
  # ...
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: {{ include "my-chart.fullname" . }}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: {{ include "my-chart.fullname" . }}
subjects:
  - kind: ServiceAccount
    name: {{ include "my-chart.fullname" . }}
    namespace: {{ .Release.Namespace }}

So if someone likes to change the "my-chart.fullname" on update providing e.g. a fullnameOverride this will cause changing the roleRef.
I would assume that there are more Kubernetes objects, where the change from delete/create to update (PUT) will cause some surprises, so I would be interested what you @zwwhdls  and @bacongobbler think about a fallback to delete/create on update failure (422)?

it might be worth considering a new feature flag that forces a deletion of the object on an upgrade. Something like --recreate, perhaps.

Certainly one could keep the "recreate" strategy separated from the force flag and let the user decide.
I could think of adding a recreate flag in the flowing alternative ways:

--recreate always does a delete and create and thus is an alternative to the standard upgrade (PATCH) and the --force upgrade (PUT).
--recreate implies --force and trys PUT first and does a recreate on failure.
--recreate trys PATCH or PUT (if --force was specified as well) and does a recreate on failure.

I would propose option 3, since it is the most flexible one and gives the user most control. Option 1. does not seem to make sense, since I cannot imagine a case where deletion of non conflicting resources would pre preferable (in this case one could just delete the entire release and re-install it).
For option 2 and 3 it needs to be decided, if recreation should be attempted only on status 422 or if there are other status codes, where the recreate attempt makes sense.
I would like to hear your thoughts and if the maintainers like the idea of adding a recreate fallback strategy I can try to find time for proposing a PR.

Option #3 gives us greatest flexibility but I think user already understands why --recreate is needed in the first place, thus I believe option #2 covers most scenarios.

re-labeled and re-titled the issue to reflect the ask.

@bacongobbler least ambiguity of flags is certainly preferable. But option 1 would resemble the behaviour of helm delete followed by helm install. So option 1 would not add a real new feature. To me option 3 would be least unambiguous. However, one might chose a different name than --recreate, maybe something like helm upgrade --immutable.

To me option 3 would be least unambiguous.

I'm concerned about the approach of "if A fails, then B". This was the trap we fell into with Helm 2's old --force behaviour: it deleted the resource and re-created it only if the patch failed. Many users were confused about the ambiguity of the flag's implementation. On their end, sometimes the behaviour was triggered, and sometimes it didn't. This caused the deletion and recreation behaviour to be inconsistent, and in many cases disrupting application traffic. Many users became wary of the flag because of its reliance on a PATCH operation's failure.
This is why I believe making the behaviour more explicit is desired: it's a destructive action, and there's no ambiguity.

But option 1 would resemble the behaviour of helm delete followed by helm install. So option 1 would not add a real new feature.

I'd argue the opposite here: users have been asking for an feature flag that performs the same behaviour as helm delete --keep-history && helm install --replace. A "one-stop shop" for CI/CD workflows. That's why flags like helm upgrade --install --dependency-update exist today. :)

I get your point that a try "update" fallback to "recreate" is less transparent and may lead to errors. Although handling only certain status codes such as 422 should not lead to problems on e.g. client timeouts. Ideally, Helm would need to know which resources are immutable and need to be recreated. Unfortunately, I have no idea how Helm could figure this out except by a try and fallback approach.
If we go for option 1 it should at least be avoided to touch any resource that does not change on upgrade (this would also be inline with the other upgrade strategies). Then the upgrade --recreate would be different from a delete/install, which would delete everything, even if nothing changes.
Although this would be an improvement w.r.t to the current install options to handle certain cases I doubt that users will be happy with this. Especially when installing via a CI/CD pipeline it is expected that Helm upgrades the releases to the desired state "what ever it takes" but without causing a downtime if not necessary.
This means for e.g. a Deployment or StatefulSet no one wants a recreate (causing a downtime) if not absolutely necessary. On the other hand, recreating a Secret or Role does not cause any trouble. So implementing recreate such that every resource is recreated even if it could have been patched, it is not ideal. In this case one needs to split upgrades into "patchable" and "non-patchable" changes and do several upgrades with different strategies. However, this will require deep knowledge of the changes in an upgrade and how Helm handles them.
In the end, I guess most users simply expect that Helm upgrades a release to the desired state with minimal invasive changes (i.e. especially not causing downtimes) and without stopping the upgrade due to a failed PATCH or PUT. So I am still hoping that we find a good way to recreate only if necessary.

I see #6378 closed, however the chart I am using doesn't produce a service that literally defines spec.clusterIP in the helm release, yet I am getting this invalid: spec.clusterIP: Invalid value: "": field is immutable error.
I'm trying to migrate from helm2

@bitsofinfo give #7431 a shot.

@bacongobbler will check it out, but I can't really run a fork, this is a production need.
whats the ETA on these backwards compatible features being released?

This issue is now open for quite some time and referenced from many other related or duplicate issues. This shows that the community has interest on improving Helm's handling of immutable resources.
So I am trying to sum up the current situation for everyone who did not read all the comments of PR #7431.
The proposal implemented in PR #7431 gives users an additional flag (recreate), which would lead to a different update strategy for individual K8s resources (delete first and recreate afterwards). This would port a Helm 2 feature over to Helm 3, would implement the same update strategy that is known from kubectl apply --force and hence seems to be promising solution at first glance.
However, as @bacongobbler pointed out in this comment, there are many situations, where this approach could lead to unwanted behaviour if users don't know details about the internals of a Helm chart or don't have very deep knowledge about the K8s clusters behaviour on recreating resources.
From my point of view the entire problem of handling changes on immutable resources on update needs to be divided into two sub-problems:

Immutable resources that are safe to be deleted and recreated at any time. An example would be OpenShift routes, which just control if a service should be exposed (similar to ingest resources). Another example are services, which in some charts may be safe to be recreated, while it is not in other charts.
Immutable resources, whose deletion could lead to undefined behaviour or an undefined state of the application. Examples have been pointed out in this comment and are e.g.

If a Persistent Volume Claim is deleted and re-created, there is a risk that an application (Deployment) consuming that Persistent Volume Claim will not receive the new volume's mount point.

An interesting example is the one of services. Services have an immutable field (spec.clusterIP) which usually should not be updated by a Helm chart, but let's assume it should be updated for the following example. In general one needs to know that a pod has environment variables for all active services see Environment variables. That means in a Helm chart with a deployment relying on these environment variables it would not be safe to delete a service and recreate it without recreating the pods afterwards. Otherwise the pods will not receive environment variables with the currently active services. There may be many charts, where these environment variables will never be used by the deployment and it would be totally safe to re-create a service. So a service resource can either fall into sub-problem 1 or 2.
This example should demonstrate why the core maintainers have doubts that giving users the recreate flag may lead to unforeseen consequences if one does not know the internals of each chart very well.
After trying sum up the current situation (everyone please correct me if I got something wrong here), I would like to propose a slightly different approach. After giving the service example above, I think it should be up to the chart developers to decide if a resource is safe to be recreated or not in a certain chart and it should not be the user that decides with a global flag that he is ok with recreating everything, which might lead to more problems than the user can foresee. Instead of having a global switch for recreation there should be more fine grained control to decide what can be recreated. So the obvious choice would be introducing a new annotation (details to be discussed) which could indicate that a resource may be safely recreated.
Let's pick up the service example again and see how that would work. In the case where no deployment would depend on the service, the chart developer could simply add the new annotation on the service. In the other case, where a deployment relies on the correct environment variables, the chart developer could use the sha256sum trick to automatically roll the deployment on a service change and add the safe to delete annotation to the service as well if he likes to.
In the beginning chart developers will certainly not know about this feature and would not add it to their charts. In these cases   users that know what they are doing would still have the option to annotate a resource manually, giving them a way to manually adjust the update behaviour. Annotating individual deployed resources is certainly not something users will try out as unmindful as trying out a flag such as recreate. Hence, there is by far less chance that users would accidentally damage the state of a chart deployment.
This proposal also picks up point 3 in the comment of @allen-servedio where he describes that users have to specify which resources they are fine with to delete in a custom process. Introducing an annotation for this case would users give an API to express their consent.
While the described annotation would certainly not be the solution to everything, I think it could be a helpful feature to deal with many problems related to immutable fields in a relatively save way. I would like to hear thoughts of the community and the maintainers before detailing the the behaviour of the annotation further and creating a POC implementation.

Hi @bacongobbler @technosophos ,
I just have one doubt about some comments.
Since the "best practices" was mentioned in this comment, I would like to clear something that is also stated in best practices:
helm.sh/chart | REC | This should be the chart name and version: {{ .Chart.Name }}-{{ .Chart.Version \\| replace "+" "_" }}.

In a k8s Job we have the main labels and the labels for the spec.Template. By trying to follow best practice I used the previous label in both Job labels and inside the spec.Template.
Causing the problem stated in issue #7725
If that should not be the case, is there a guide for where each label should be?

Jobs are an example of something that Helm can't really upgrade well through a naive upgrade, because most of its fields are immutable, and the process to upgrade a Job template without just deleting it and any currently-managed pods first is a specific delete-with-special-flag-then-create-with-details-from-the-old-Job-so-it-picks-up-the-old-pods proccess which Helm would have to explicitly support.
There isn't a guide for Helm specifying which possible things cannot be changed in upgrade, because apart from CRDs, Helm doesn't know about the objects its dealing with. The k8s documentation definitely could be better about documenting which things are immutable, it's not mentioned in the API docs and even for cases where it's more of a bug than a feature, e.g., Service clusterIP "" on upgrades shouldn't fail the upgrade, there hasn't been a ton of traction for fixing it on the k8s side.
It might be worth adding a note to the 'best practices' to remind chart developers to not include version- or config- affected values in immutable data, e.g., batch/v1.Job's spec.template.metadata, and if they must use config-affected values, to document that the config cannot be differing during an upgrade compared to the original install.

@TBBle One thing that I don't like about helm hook is the fact that it has to wait for the hook to complete for a successful chart installation. I wish hooks wouldn't hang the the helm install. I would like to just use hooks to install Job or Pod that perform an idempotent task i.e. I don't care if the Job/Pod is canceled or restarted on each helm install/upgrade but I want the Job/Pod to use latest chart values.

That sounds like a good use-case to break out into a new feature-request, for, e.g., post-install and post-upgrade hooks to be able to annotate that they are non-blocking, disabling the Pod/Job existing blocking behaviour for hooks.

(This comment was originally added to the PR for this issue, though on hindsight, I should have put it on this issue)
Hi all... We carefully read the concerns of the Helm maintainers about this feature and thought about what we could do to allow our automation to work consistently with Helm's current behavior. As a result, we implemented the following within our automation pipelines:

We do a client side helm lint of the chart, then we render the helm chart manifest with all the values provided and then pass it to and a kubeclt apply --validate --dry-run=client -f manifest.yaml to check that the Helm chart is at least syntactically okay and all the configurations are correctly structured (we have always done this).
We run the command kubectl apply --dry-run=server -f manifest.yaml (or kubectl replace ... if it is a force upgrade) and specifically look for /immutable|updates .+ forbidden/ pattern as a failure.
Our users are able to describe to us what resources (kinds and names) they are okay to be deleted (or should NOT be deleted) when this happens.
We then delete the resource if it only has the failure from step 2 above and is allowed to be deleted per step 3.
Last, we do the helm upgrade. Obviously does not matter for an install as there is nothing to compare against - that’s why steps 2-4 are skipped for initial helm release install.

Sadly, this is embedded within a much larger set of custom automation that we have and so all we can offer the community are the steps that we are taking within our automation vs. something you can take and run.

This is causing issues for us. The charts that were working fine in Helm2 and now suddenly broken. Fix for this is even more critical since helm2 is getting deprecated. Everyone has to move to Helm3 but can not due to this issue.

remove stale

I found a workaround for jobs at least,
If you put a random string or in our case the image tag (because that's our changing field) in the name, it'll rename the resource which will force helm to create a new resource and delete the old.

I found a workaround for jobs at least,
If you put a random string or in our case the image tag (because that's our changing field) in the name, it'll rename the resource which will force helm to create a new resource and delete the old.

Similar, we put .Release.Revision in name. Sometimes (perhaps related to failed upgrades) however, Helm doesn't delete old job

😭

remove stale

/remove stale

Could the documentation of the --force option at least be clarified in the mean time to explain that "a replacement strategy" doesn't mean a replacement of the resource itself.  To me that read as though things would be deleted and recreated.

I would like to propose an idea:
If I'm understanding correctly from this issue, others, and the documentation, helm upgrade roughly equates to kubectl apply, helm upgrade --force roughly equates to kubectl apply --force. It would be useful in some cases to handle certain resources with kubectl replace or even kubectl replace --force, but use the existing strategy for the others.
For example, I have a chart that creates a set of configmaps, secrets, and PVCs, and then kicks off some jobs. I'd like to be able to use helm upgrade to patch the configmaps and secrets, not recreate the PVC (since I want the data to stay right where it is), but do a kubectl replace --force on the job to start it from scratch.
Based on this, I think it makes sense to introduce a new annotation: helm.sh/apply-type (or similar), which, if present and set to replace, indicates that the resource should be handled with kubectl replace, replace-force would likewise indicate to use kubectl replace --force, and an absent value indicates to use the existing strategy. While this introduces the complication of the order in which these kubectl operations happen, I feel like this would be better than nothing.
Thoughts?

@meln5674 your idea sounds quite similar to my earlier proposal from https://github.com/helm/helm/issues/7082#issuecomment-687752364 for which you can find a POC in #9174.
Though, my impression is that this feature proposal is more or less dead due to a lack of interest from the core maintainers.

Bye bye Helm...

@antonakv, what does your statement mean? Have you found a decent Helm replacement?

@prokher The statement means that I disagree with core maintainers decisions and it leads me to stop using the  product.  This feature POC not-approval is quite indicative. Looks like project goals are not completely clear.

@prokher he was just kind and wanted to publicly greet Helm.
I always do it with software.
"Nginx is really nice to see you again! 🤝"
"kube-proxy how's it going? 🚀"
"Microsoft Excel I see you in great shape! 👍🏻"

@antonakv if you like this FR feel free to do a PR so that you can implement it in a rock-solid and backward compatible way.

@pierluigilenoci I think you are not following https://github.com/cncf/foundation/blob/main/code-of-conduct.md in your previous comment and I found the message as offensive.

@antonakv You Poe. 😆


lncli: unify handling of positional and flag command line arguments

When using lncli commands and passing in arguments that can be either a flag or positional, different results are printed to the screen in the event of an error. When passing an invalid positional arg, one error message is supplied, while passing an invalid flag arg results in a different error message being supplied and the usage being printed. This occurs for openchannel, as seen below, but also most other commands.
Positional Local Amount:
sean@dmt:~$ lncli openchannel 03324ef21e77714cdc1ad7fadda808a7aca2b7f8d31cd737923d42164dac00a02d InvalidLocalAmount 3000
[lncli] unable to decode local amt: strconv.ParseInt: parsing "InvalidLocalAmount": invalid syntax

Flag Local Amount:
sean@dmt:~$ lncli openchannel --local_amt InvalidLocalAmount 03324ef21e77714cdc1ad7fadda808a7aca2b7f8d31cd737923d42164dac00a02d 3000
Incorrect Usage: invalid value "InvalidLocalAmount" for flag -local_amt: strconv.ParseInt: parsing "InvalidLocalAmount": invalid syntax

NAME:
   lncli openchannel - Open a channel to an existing peer.

USAGE:
   lncli openchannel [command options] node-key local-amt push-amt

DESCRIPTION:

  Attempt to open a new channel to an existing peer with the key node-key
  optionally blocking until the channel is 'open'.

  The channel will be initialized with local-amt satoshis local and push-amt
  satoshis for the remote node. Once the channel is open, a channelPoint (txid:vout)
  of the funding output is returned.

  One can manually set the fee to be used for the funding transaction via either
  the --conf_target or --sat_per_byte arguments. This is optional.

  NOTE: peer_id and node_key are mutually exclusive, only one should be used, not both.

OPTIONS:
   --peer_id value        the relative id of the peer to open a channel with (default: 0)
   --node_key value       the identity public key of the target peer serialized in compressed format
   --local_amt value      the number of satoshis the wallet should commit to the channel (default: 0)
   --push_amt value       the number of satoshis to push to the remote side as part of the initial commitment state (default: 0)
   --block                block and wait until the channel is fully open
   --conf_target value    (optional) the number of blocks that the transaction *should* confirm in, will be used for fee estimation (default: 0)
   --sat_per_byte value   (optional) a manual fee expressed in sat/byte that should be used when crafting the transaction (default: 0)
   --private              make the channel private, such that it won't be announced to the greater network, and nodes other than the two channel endpoints must be explicitly told about it to be able to route through it
   --min_htlc_msat value  (optional) the minimum value we will require for incoming HTLCs on the channel (default: 0)

[lncli] invalid value "InvalidLocalAmount" for flag -local_amt: strconv.ParseInt: parsing "InvalidLocalAmount": invalid syntax

There are multiple benefits to unifying the argument handling:

User experience will be more consistent, including for scripts that call lncli.
Error handling can be done at a single level, rather than done in commands.go for positional args and done in the cli library for flag args (which is currently the case).
A decent amount of lines of redundant code can be removed.
Adding new parameters in the future will be less error prone since there will be an established, known-good helper function to handle it.
Essentially the same unit tests can be written for both cases, whereas now the unit tests have to be significantly different.

If the argument-handling methods are unified, what should be printed? Just the error message, or the error message and usage? It seems preferable to just print the error message as its unclear what help the usage is in this context.
I can prepare a PR for this change, but I'd like to have unit tests in place first. Currently getting unit tests in place is blocked on approval/merging of #728. I have unit tests in my repository that document the current behavior here:
https://github.com/merehap/lnd/blob/cli_errors/cmd/lncli/open_channel_test.go#L174
versus
https://github.com/merehap/lnd/blob/cli_errors/cmd/lncli/open_channel_test.go#L184

Closing this for now since momentum died out, and most of the newer CLI commands are following this principle.


Add support for BallTree, BinaryTree

Those are used by KNeighbors{Classifier,Regressor} but were not caught so far because of the default argument.
Unfortunately, we need some special treatment here because the two cython classes, as well as DistanceMetric, which is used under the hood, return tuples from __getstate__ and thus the normal reduce_get_state and reduce_get_instance methods fail.
LMK if you have a better name than reduce_based_on_tuple_get_{state,instance}.
Ready for review @adrinjalali

@adrinjalali I pushed the change of hard-coding the distance metrics.

@adrinjalali I addressed your points, please review again.

@adrinjalali Your suggestion wasn't quite enough, but it pointed me towards a huge simplification :+1: Please take a look again.


Techdebt: Replace string-format with f-strings (for a* dirs)

See #5579

Codecov Report

Merging #5661 (3ff264e) into master (222621f) will increase coverage by 0.00%.
The diff coverage is 63.63%.

@@           Coverage Diff           @@
##           master    #5661   +/-   ##
=======================================
  Coverage   96.20%   96.20%
=======================================
  Files         743      743
  Lines       72723    72725    +2
=======================================
+ Hits        69960    69962    +2
  Misses       2763     2763

Flag
Coverage Δ

servertests
36.89% <0.00%> (-0.01%)
:arrow_down:

unittests
96.14% <63.63%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/acm/models.py
90.54% <ø> (ø)

...o/apigateway/integration_parsers/unknown_parser.py
85.71% <ø> (ø)

moto/apigateway/responses.py
95.40% <0.00%> (ø)

moto/athena/models.py
93.39% <ø> (ø)

moto/awslambda/responses.py
93.88% <0.00%> (ø)

moto/apigateway/models.py
95.71% <50.00%> (+<0.01%)
:arrow_up:

moto/applicationautoscaling/models.py
94.93% <66.66%> (ø)

moto/awslambda/models.py
94.21% <66.66%> (+<0.01%)
:arrow_up:

moto/acm/utils.py
100.00% <100.00%> (ø)

moto/applicationautoscaling/responses.py
99.02% <100.00%> (ø)

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Render vtkVolume without clipping

Is there a solution to render in volume viewport a volume without creating clipping planes?

The early version of Cornerstone3D was that way, by manipulating the camera clipping range (not clipping plane). But since we needed to implement non-image vtk actors we had to embrace the clipping planes (which is better performance wise too).
What is your usecase where you don't want clipping planes?

I want to show whole volume in view like this view.

I remove cliping planes from volume Viewport and this is the result.

and what should be the expected result?

No there is no other method. Our VolumeViewport is currently an MPR viewport, so it has clipping planes. It has a Perspective for polyData actors.
For "real" 3D Viewport we need another type which is not implemented yet, but seems like you have got it working

I'll close this since we added the new volume_3d viewport


Documentation update for v5.4.0 new features

Documentation update for v5.4.0 for

Scan caching feature
Admission control rules design change
Adding CTRL_SEARCH_REGISTRIES env variable for admission control
Internal certificate rotation feature.
Change Zero Drift design change for v5.4.0
Added BusyBox process profile rule behavior with v5.4 and v5.3

Thanks for reviewing the changes. I have accepted your changes.


switch to use iconv-lite-umd for #79275

This is next PR in a series for #79275
Update: Didn't get any test failure locally. Will fix it.

Thanks! Nevermind the commits, I always "Squash and merge" PRs typically.


Where is binary located on Windows when installing from *.msi or with winget?

I just tried winget install wazero on Windows 10 and realized it provides zero information regarding where the binary is located on the system.
It's not available nowhere within the %PATH%.
When installing with --verbose flag it just says that installer was taken from:
https://github.com/tetratelabs/wazero/releases/download/v1.0.1/wazero_1.0.1_windows_amd64.msi
And running it manually also gives zero knowledge of where to locate the binary. I'm not even sure that it is saved after all.

Hi, sorry for your frustrations. Certainly, that's a non-goal!
This should place the wazero binary into to program files 64 directory under wazero. Also, it should be added to the PATH (which is a part of our tests, to ensure it is available). Note you have to refresh your shell to pickup PATH additions.
Do other winget installers introduce a manual step to control the installation folder or echo it to the screen? I'm wondering how we can do this more differently, and examples help.

Thank you, so effectively wazero binary was installed in:
C:\Program Files\wazero dir. (Shame that winget does not provide that info, there is already an issue: https://github.com/microsoft/winget-cli/issues/2298.)
However it's not in the %PATH% for some reason. I double-checked and it's not there.
I would of course install just by compiling it with go, but wanted to try that way as well.

I'll leave this open as I don't have my windows laptop with me. If someone else can take a look at if they also don't get PATH update and report back, much obliged.

yep I can confirm I can't find it in neither in my User %PATH% neither in the system %PATH% :/

@evacchi maybe have a look at func-e and/or podman to see if there was any drift or differences? (e.g. does winget func-e still work?) Maybe something skewed as sometimes utility upgrades break things (e.g. the thing that builds the installer).

same with func-e @codefromthecrypt TBH I noticed that something wasn't registered to PATH even with choco while setting this machine up, so it may not one specific issue of ours 🤔 nevertheless...

hey @inliquid can you try the artifact attached here? https://github.com/evacchi/wazero/actions/runs/4764921388 it's a fixed MSI built via issue #1385

@evacchi yep, it worked!

hopefully this works! https://github.com/microsoft/winget-pkgs/pull/103155

just installed from winget, looks good to me:
C:\Users\ADMIN>where wazero
C:\Users\ADMIN\go\bin\wazero.exe
C:\Program Files\wazero\wazero.exe

C:\Users\ADMIN>del C:\Users\ADMIN\go\bin\wazero.exe

C:\Users\ADMIN>wazero
wazero CLI

Usage:
  wazero <command>

Commands:
  compile       Pre-compiles a WebAssembly binary
  run           Runs a WebAssembly binary
  version       Displays the version of wazero CLI

C:\Users\ADMIN>where wazero
C:\Program Files\wazero\wazero.exe


Avoid (some) duplicate optimizes

Following #52 here is some code which gets rid of 1 optimize call (in case of no initial design specified). The PR also includes a context which can be used to suspend all optimizes. This is mostly useful for the lower-level api.
note: In the following release the data mechanism will undergo some changes and enabling the scaling should get moved to avoid another scaling

This requires #57 to be merged first.

Codecov Report

Merging #62 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #62      +/-   ##
==========================================
+ Coverage   99.78%   99.79%   +0.01%
==========================================
  Files          16       16
  Lines         914      970      +56
==========================================
+ Hits          912      968      +56
  Misses          2        2

Impacted Files
Coverage Δ

GPflowOpt/bo.py
98.66% <100%> (+0.11%)
:arrow_up:

GPflowOpt/acquisition/acquisition.py
100% <100%> (ø)
:arrow_up:

GPflowOpt/optim.py
100% <100%> (ø)
:arrow_up:

GPflowOpt/acquisition/lcb.py
100% <100%> (ø)
:arrow_up:

GPflowOpt/acquisition/pof.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Does this PR becomes partially invalid with the upcoming lazy setup code?

Yes it does.


Implement Response.trailer promise

Related to:

#330
#331

This PR is based on @isaacs (https://github.com/npm/minipass-fetch/commit/8dc2b4f0de5fcf512f3867152b5497b95f14a517) and @TimothyGu (https://github.com/bitinn/node-fetch/pull/331/commits/284f682bcc35d4838b99ce259c427f5d88df1152) work.
I created this PR because it looks like people are looking forward to being able to use this feature (see mentioned issues/PRs).
Closes #330 | Closes #331

Your code looks fine, but the problem is res.trailer continues to be in limbo when it comes to browsers adoption.
https://github.com/whatwg/fetch/issues/772
On client-side it appears the main focus is on server-timing debug, on server-side, I am not quite sure what the current use cases are.

@bitinn Ok, putting this on hold.

Closing this as the trailer support has been removed (https://github.com/whatwg/fetch/issues/772).


Add Book find

Codecov Report

Merging #110 (e30729a) into master (b1a605e) will decrease coverage by 0.92%.
The diff coverage is 29.54%.

@@             Coverage Diff              @@
##             master     #110      +/-   ##
============================================
- Coverage     76.65%   75.73%   -0.93%
- Complexity      839      846       +7
============================================
  Files           106      110       +4
  Lines          2343     2386      +43
  Branches        303      309       +6
============================================
+ Hits           1796     1807      +11
- Misses          458      489      +31
- Partials         89       90       +1

Impacted Files
Coverage Δ

...u/address/logic/commands/book/FindBookCommand.java
0.00% <0.00%> (ø)

...u/address/logic/parser/book/BookCommandParser.java
0.00% <0.00%> (ø)

...eedu/address/logic/parser/book/FindBookParser.java
0.00% <0.00%> (ø)

...odel/book/BookAuthorContainsKeywordsPredicate.java
75.00% <75.00%> (ø)

...s/model/book/BookTagContainsKeywordsPredicate.java
75.00% <75.00%> (ø)

.../model/book/BookNameContainsKeywordsPredicate.java
85.71% <100.00%> (-14.29%)
:arrow_down:

Continue to review full report at Codecov.

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


feat(Subscription): allow Subscription add mutiple teardown logics

Description:
Allow Subscription add multiple teardown logics
Related issue (if exists):
resolve https://github.com/ReactiveX/rxjs/issues/2769

Coverage increased (+0.002%) to 97.736% when pulling 0b19128153bbee4d97c16eb3c899008372dbfe87 on Brooooooklyn:feature/add-multiple-teardowns into 93ae774a0abb6701086175d8dff1eef258f656d8 on ReactiveX:master.

Coverage increased (+0.002%) to 97.736% when pulling 04bc49c8c45a10fbbcd5ae704db3debaa0f81755 on Brooooooklyn:feature/add-multiple-teardowns into 93ae774a0abb6701086175d8dff1eef258f656d8 on ReactiveX:master.

Coverage increased (+0.002%) to 97.736% when pulling 04bc49c8c45a10fbbcd5ae704db3debaa0f81755 on Brooooooklyn:feature/add-multiple-teardowns into 93ae774a0abb6701086175d8dff1eef258f656d8 on ReactiveX:master.

I'm marking this as blocked to get conclusion of parent issue #2769.

I like the spirit of this PR, and I've actually worked something like this into the experimental branch. We should probably refactor it for v6.

@benesh I've rebased this PR.

Thanks @cartant .... Unfortunately, @Brooooooklyn, looking at how this is implemented it incurs a breaking change that we can't do until the next version of RxJS (where I already have it implemented in the experimental branch).
The problem is that currently, subscription.add(child) === child will return true. But this seems to change that.  Also, how would subscription.add(a, b, c); subscription.remove(b) work? I think we can't do this until the next major version because ideally, add returns void, and the second scenario above will work.
I'm going to close this, but just know that we are indeed doing something like this for the next version.


Y-axis flip on output for bottom-up use

Is there a way to flip the image on the X or Y axis when generating image slices for bottom up projection?

Done ! e27f7a3


feat: add TextInputV2 and TextInputFieldV2

Summary
Type

Feature

Summarise concisely:
Add a new version of TextInput and TextInputFieldV2

it seems magic wand doesn't work in here?

it seems magic wand doesn't work in here?

This is because magic wand needs a function to be working using prop onRandomize, I will add it into the story so it actually works

On read-only state, better to not be able to focus on the field (same for hover)

On read-only state, better to not be able to focus on the field (same for hover)

The native behavior allows focus on readonly state but not hovering, do we want to sync onto that or remove any effect as you said? Cf: https://developer.mozilla.org/fr/docs/Web/HTML/Attributes/readonly#résultat

On read-only state, better to not be able to focus on the field (same for hover)

The native behavior allows focus on readonly state but not hovering, do we want to sync onto that or remove any effect as you said? Cf: https://developer.mozilla.org/fr/docs/Web/HTML/Attributes/readonly#résultat

Ok to keep this behavior then it will be easier to identify read-only than disabled. Everything is good then :)


Dev

The updates to make possible actions into a list in order to do ML etc. have not been completed but I cannot invest time into this atm

The updates to make possible actions into a list in order to do ML etc. have not been completed but I cannot invest time into this atm

Yes, been thinking about that - different mechanics in different games, but the 'which weapon/spell/power' to use problem.  Trending from simpler simulation to automated Fantasy Grounds [which is a massive amount of work].

Yes, been thinking about that - different mechanics in different games, but the 'which weapon/spell/power' to use problem.  Trending from simpler simulation to automated Fantasy Grounds [which is a massive amount of work].