Write data when one broker goes down

Hi.
I have a cluster of two kafka brokers. On this cluster I created a topic with replication factor 1 and partitions count 4 (2 partitions per broker).
The problem is that when one of the brokers goes down producer continues to write data to two brokers and in this case the half of the new data is not saved.
I tried to use acks but it did not help.
Is it possible to configure producer not to write data to the failed partitions (such partitions have leader -1 state) ?

I think you mean not write data to the non-failed partitions? no, I can't think how you would do that. You could do something approximating it in your own code (by utilizing either delivery report results or metadata requests you make yourself via the admin client), but it won't be perfect. Generally, you'd have your partitions replicated (in your setup, what happens is the broker failure is due to disk failure - you'd loose the data), in which case acks=all would achieve what you want.

Hi. Thanks.
I would like to create cluster of two or three brokers that are ideally independent of each other, but if I will need I can create topic with replication. If one of the brokers fails and I will lose all the data on that server - it is not a problem for me. But I want if for example one of such brokers goes down another two will work without any problems. And Ideally I do not want to use replication - because it creates high load on servers without the need in replication on my part.
Is it possible to create similar schema ?

the client doesn't give you that specific functionality out of the box. Based on your description (it seems some message loss is fine), I'd create an abstraction above the producer which round-robins the produce calls to all partitions and in the event of a failed delivery, remembers that a partition failed and excludes it from the round-robining for some amount of time. After that time expires, if the broker is back up, all will be good. If it's not, then the partition gets excluded again. The specifics of the abstraction will depend on your exact requirements.

Thanks for the information and advise.
I think we will really work with our custom schema at the code level.


Add auto complete support to CLI

As a CobiGen CLI user, I want to benefit from the auto completion features offered by Picocli or JLine so that working with the shell gets much easier for me.
Take a look at: https://github.com/remkop/picocli/tree/master/picocli-shell-jline3 and https://picocli.info/autocomplete.html#_command_line_completion

Likely to be implemented: https://picocli.info/autocomplete.html#_distribution


Removes install fix, no longer needed. Numbers don't matter.

Also tweaks wording a bit.

Thanks! Nice catch!

Apparently this isn't fixed yet... so... the quest continues!


added travis configuration file and badge

@SolomoN-ua i have added travis config and badge to readme file, could you setup travis account and do the test build.
this will help everyone in tracking the build failures.

Hi @jigardafda, thanks. Good idea, we will try to do this next week.

I don't know if that's possible at all for this project, but it would be even better to make it play tests too.

@jigardafda, @jdat82 I'm waiting when @jgallen23 will give me access to project travis build
sorry for delay :(

setting that up now

all set up: https://travis-ci.org/firstandthird/load-grunt-config

@jgallen23 Thank you! :)


[READ] FFLAGs REMOVED?

Acknowledgement of preliminary instructions

[X] I have read and acknowledged the preliminary instructions.

What idea do you have?
apparently yes, by the new version of

bloxstrap, they decided to remove fast flags (NEWEST 2.60 VERSION)

these are all of the builds that removed fastflags, i still got a save of a 2.6.0 version with fastflags,
if you need it.
Find the version of 2.6.0 bc im lazy to link the 2.6.0 old version
I HOPE you bring back fastflags, bc bloxstrap is actually famous for that, especially they make your game LOTS OF BETTER.
no it isnt bc i will uninstall it, but bc its so strange seeing bloxstrap without fflags, especially for somepeople who would downgrade again to 2.5.4
PLEASE DONT REMOVE FFLAGS IN FULL 2.6.0!

DO NOT CLOSE THIS, i am not doing stuff, just let people read

not my choice

bro is in so much denial

feel like it should properly be explained as to why because most people here appear to be kids, but im guessing
[FLog::Warning] LoadClientSettingsFromLocal skipped for production client build
means that the client settings file won't be loaded anymore?
if that is the case, then yea remove fflags lol

the crows are coming, githubberguy

you can probably use zflag and stay downgraded for 2 months


RPLIDAR installation issue

Please provide the following information:

OS: Ubuntu version 22.04
ROS Distro: Humble
Built from source
Package version: H.2.2

Actual behaviour
turtlebot4_bringup not found:
tried installing with "sudo apt update && sudo apt upgrade" still shows the same error.
To Reproduce
Provide the steps to reproduce:

sudo apt install ros-humble-rplidar-ros
ros2 launch turtlebot4_bringup rplidar.launch.py
see the error

Other notes
Moreover "ros2 service call /stop_motor std_srvs/srv/Empty {}" doesn't stop the motor.

Are you trying to launch the lidar on the robot? and is the robot software in the original state from factory and/or flashed from the provided turtlebot 4 raspberry pi images?
As background information, why are you directly launching the lidar? If you are trying to do normal operation of the robot then you do not need to launch it directly, it will launch on its own as part of the turtlebot service. I assume this has been operating correctly based on you having seen and tried to use the stop motor service.
In regards to stopping the motor, make sure that you are running version 2.1.4 (or higher) of the rplidar driver. There was a recent fix that has to do with stopping the lidar. Additionally, if you want to manually control the lidar starting / stopping you also need to diable the feature which automatically starts / stops the motor based on the number of subscribers. Information about that can be found in my response here: https://github.com/turtlebot/turtlebot4/issues/233#issuecomment-1660515345

it is in the original state of the factory.
I tried to get the localization scan from the robot; it kept giving inf, and the robot could not avoid the obstacles.

Am I to understand correctly that the core issue that you would like to address is the fact that when you echo the scan topic, the values you receive back are all infinite? and that it was not avoiding the obstacles?
If so, then can you share the following details:

What were you doing when you saw that the robot was not avoiding the obstacles?
a. Were you running Nav2 with SLAM or with localization? - what exact commands did you use to launch these?
b. Were the obstacles that the robot ran into static or dynamic? and were they in the map or not?
How did you observe these inf values? - are you sure that all of the values are infinite vs some of them being infinite?
Can you see any lidar hits in rviz?

yes, you got that right.
1a. I am using Nav2 with localization. cmd- ros2 launch turtlebot4_navigation loacalization.launch.py map: ; ros2 launch turtlebot4_navigation nav2.launch.py params_file
1b. i tried with both static and dynamic. it shows on map but the robot instead to avoiding goes and bumps into them.

i used ros2 topic echo /scan- it gives inf values

i can see them

@hilary-luo do you have any suggestions about the problem

bag.zip

@Akalpita30 Did those bag files upload correclty? three of them only have one topic and the other isn't showing any topics.
Can you also provide the create3 log from when you replicate this situation?

create 3 -
messages(4).txt
bag-
bag09_19.zip

Thank you for your patience, the past couple of weeks have been very busy. It does seem like you are running into the issue of the Create3 CPU maxing out.
 If not then I would suggest trying to switch to discovery server and see if this helps. Let me know how this goes or if this is not an option for you.

no, I am not running multiple robots at once.
i tried switching to the discovery server, the ros topic list did not publish the topics. rviz was blank nothing popped up to rviz.
let me know if there is another way to solve the issue

@hilary-luo any updates?
i tried running rviz and observed it going and colliding with the wheels of the chairs. I would appreciate it if you could help me with the parameters i should tune to stop that from happening.

/
messages(4).txt
@hilary-luo @roni-kreinin i would appreciate your help on this issue as soon as possible. Attached here are the logs, processes I did and the results I got. The turtlebot4 and the remote computer is connected to the WiFi- TP-Link. I also changed the server to discovery.

The video of the robot colliding with the chair.

Thank you for your patience. I don't see any unexpected operation in the video and path planning images. I will explain why and then feel free to let me know if you feel like there is still something that is unexplained.
First off, the lidar is a 2d lidar (as are most lidars that are used for indoor navigation) however, this means that it can only view obstacles on a single plane. These obstacles are denoted by the black pixels in the map or I think in your visualization, the fuschia pink of your costmap. The surrounding blue in the costmap is an envelope area around the obstacles that the centre of the robot will avoid and as the colour changes moving away from the obstacles it will avoid it less and less. (Look up costmap based path planning if you are interested in understanding this further). If you look carefully at your map, only the centre column of the chair is visible to the lidar and is in the map. This means that the robot has no knowledge of the wheels being there. The chair wheels are below the lidar plane and the chair seat is above the lidar plane.
It is standard for lidar based navigation, that environments have to be prepared such that the lidar is able to see all obstacles. One way to evaluate this is to measure the height of your lidar and then go around your environment and measure the height of all of the obstacles. When doing this it is also good to look out for excessively shiny surfaces, surfaces that do not reflect any light, very thin surfaces and windows which are all difficult to detect with lidars. Underhanging and overhanging surfaces can be extended to the lidar plan and or blocked with items that the robot can see. A good visualization of this issue is shown here: https://docs.ottomotors.com/en/30495-30508-overhang-and-underhang-detection.html. Knowing this, if you look at the plan that the robot made and attempted to follow, it made complete sense given its knowledge of the environment.
All that being said, try making this change to address the time sync issue that is showing up in the terminal: https://github.com/turtlebot/turtlebot4/issues/216 . Let me know how that works.

Hello Hillary,
Thank you for your answer. I understand the LiDAR reasoning. But, What about the IR sensors? The sensors at the bumper. They at the height of the wheels. Should not this work?
Based on the configuration below, we understand they are also working.
This is the Nav2.yaml file.
bt_navigator:
  ros__parameters:
    use_sim_time: True
    global_frame: map
    robot_base_frame: rplidar_link #base_link
    odom_topic: odom
    bt_loop_duration: 10
    default_server_timeout: 20
    # 'default_nav_through_poses_bt_xml' and 'default_nav_to_pose_bt_xml' are use defaults:
    # nav2_bt_navigator/navigate_to_pose_w_replanning_and_recovery.xml
    # nav2_bt_navigator/navigate_through_poses_w_replanning_and_recovery.xml
    # They can be set here or via a RewrittenYaml remap from a parent launch file to Nav2.
    plugin_lib_names:
    - nav2_compute_path_to_pose_action_bt_node
    - nav2_compute_path_through_poses_action_bt_node
    - nav2_smooth_path_action_bt_node
    - nav2_follow_path_action_bt_node
    - nav2_spin_action_bt_node
    - nav2_wait_action_bt_node
    - nav2_assisted_teleop_action_bt_node
    - nav2_back_up_action_bt_node
    - nav2_drive_on_heading_bt_node
    - nav2_clear_costmap_service_bt_node
    - nav2_is_stuck_condition_bt_node
    - nav2_goal_reached_condition_bt_node
    - nav2_goal_updated_condition_bt_node
    - nav2_globally_updated_goal_condition_bt_node
    - nav2_is_path_valid_condition_bt_node
    - nav2_initial_pose_received_condition_bt_node
    - nav2_reinitialize_global_localization_service_bt_node
    - nav2_rate_controller_bt_node
    - nav2_distance_controller_bt_node
    - nav2_speed_controller_bt_node
    - nav2_truncate_path_action_bt_node
    - nav2_truncate_path_local_action_bt_node
    - nav2_goal_updater_node_bt_node
    - nav2_recovery_node_bt_node
    - nav2_pipeline_sequence_bt_node
    - nav2_round_robin_node_bt_node
    - nav2_transform_available_condition_bt_node
    - nav2_time_expired_condition_bt_node
    - nav2_path_expiring_timer_condition
    - nav2_distance_traveled_condition_bt_node
    - nav2_single_trigger_bt_node
    - nav2_goal_updated_controller_bt_node
    - nav2_is_battery_low_condition_bt_node
    - nav2_navigate_through_poses_action_bt_node
    - nav2_navigate_to_pose_action_bt_node
    - nav2_remove_passed_goals_action_bt_node
    - nav2_planner_selector_bt_node
    - nav2_controller_selector_bt_node
    - nav2_goal_checker_selector_bt_node
    - nav2_controller_cancel_bt_node
    - nav2_path_longer_on_approach_bt_node
    - nav2_wait_cancel_bt_node
    - nav2_spin_cancel_bt_node
    - nav2_back_up_cancel_bt_node
    - nav2_assisted_teleop_cancel_bt_node
    - nav2_drive_on_heading_cancel_bt_node

bt_navigator_navigate_through_poses_rclcpp_node:
  ros__parameters:
    use_sim_time: True

bt_navigator_navigate_to_pose_rclcpp_node:
  ros__parameters:
    use_sim_time: True

controller_server:
  ros__parameters:
    use_sim_time: True
    controller_frequency: 20.0
    min_x_velocity_threshold: 0.001
    min_y_velocity_threshold: 0.5
    min_theta_velocity_threshold: 0.001
    failure_tolerance: 0.3
    progress_checker_plugin: "progress_checker"
    goal_checker_plugins: ["general_goal_checker"] # "precise_goal_checker"
    controller_plugins: ["FollowPath"]

    # Progress checker parameters
    progress_checker:
      plugin: "nav2_controller::SimpleProgressChecker"
      required_movement_radius: 0.5
      movement_time_allowance: 10.0
    # Goal checker parameters
    #precise_goal_checker:
    #  plugin: "nav2_controller::SimpleGoalChecker"
    #  xy_goal_tolerance: 0.25
    #  yaw_goal_tolerance: 0.25
    #  stateful: True
    general_goal_checker:
      stateful: True
      plugin: "nav2_controller::SimpleGoalChecker"
      xy_goal_tolerance: 0.25
      yaw_goal_tolerance: 0.25
    # DWB parameters
    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      debug_trajectory_details: True
      min_vel_x: 0.0
      min_vel_y: 0.0
      max_vel_x: 0.26
      max_vel_y: 0.0
      max_vel_theta: 1.0
      min_speed_xy: 0.0
      max_speed_xy: 0.26
      min_speed_theta: 0.0
      # Add high threshold velocity for turtlebot 3 issue.
      # https://github.com/ROBOTIS-GIT/turtlebot3_simulations/issues/75
      acc_lim_x: 2.5
      acc_lim_y: 0.0
      acc_lim_theta: 3.2
      decel_lim_x: -2.5
      decel_lim_y: 0.0
      decel_lim_theta: -3.2
      vx_samples: 20
      vy_samples: 5
      vtheta_samples: 20
      sim_time: 1.7
      linear_granularity: 0.05
      angular_granularity: 0.025
      transform_tolerance: 0.2
      xy_goal_tolerance: 0.25
      trans_stopped_velocity: 0.25
      short_circuit_trajectory_evaluation: True
      stateful: True
      critics: ["RotateToGoal", "Oscillation", "BaseObstacle", "GoalAlign", "PathAlign", "PathDist", "GoalDist"]
      BaseObstacle.scale: 0.02 #0.02
      PathAlign.scale: 32.0
      PathAlign.forward_point_distance: 0.1
      GoalAlign.scale: 24.0
      GoalAlign.forward_point_distance: 0.1
      PathDist.scale: 32.0
      GoalDist.scale: 24.0
      RotateToGoal.scale: 32.0
      RotateToGoal.slowing_factor: 5.0
      RotateToGoal.lookahead_time: -1.0

local_costmap:
  local_costmap:
    ros__parameters:
      update_frequency: 5.0
      publish_frequency: 2.0
      global_frame: odom
      robot_base_frame: base_link #rplidar_link #base_link
      use_sim_time: True
      rolling_window: true
      width: 3
      height: 3
      resolution: 0.06
      robot_radius: 0.175
      plugins: ["static_layer", "voxel_layer", "obstacle_layer", "inflation_layer"]
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        cost_scaling_factor: 4.0 #4.0
        inflation_radius: 0.3 #0.45
      voxel_layer:
        plugin: "nav2_costmap_2d::VoxelLayer"
        enabled: True
        publish_voxel_map: True
        origin_z: 0.0
        z_resolution: 0.05
        z_voxels: 16
        max_obstacle_height: 2.0 #2.0
        mark_threshold: 0
        observation_sources: scan
        scan:
          topic: /scan
          max_obstacle_height: 2.0 #2.0
          clearing: True
          marking: True
          data_type: "LaserScan"
          raytrace_max_range: 2.5 #3.0
          raytrace_min_range: 0.0
          obstacle_max_range: 2.5 #2.5
          obstacle_min_range: 0.0
      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
        enabled: True
        observation_sources: "ir_obstacle"
        ir_obstacle:
          topic: /ir_obstacle
          max_obstacle_height: 2.0 #2.0
          clearing: True
          marking: True
          data_type: "LaserScan"
          raytrace_max_range: 3.0 #3.0
          raytrace_min_range: 0.0
          obstacle_max_range: 2.5 #2.5
          obstacle_min_range: 0.0
      static_layer:
        plugin: "nav2_costmap_2d::StaticLayer"
        map_subscribe_transient_local: True
      always_send_full_costmap: True

global_costmap:
  global_costmap:
    ros__parameters:
      update_frequency: 1.0
      publish_frequency: 1.0
      global_frame: map
      robot_base_frame: base_link #rplidar_link #base_link
      use_sim_time: True
      robot_radius: 0.175
      resolution: 0.06
      track_unknown_space: true
      plugins: ["static_layer", "obstacle_layer", "inflation_layer"]
      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
        enabled: True
        observation_sources: scan
        scan:
          topic: /scan
          max_obstacle_height: 2.0 #2.0
          clearing: True
          marking: True
          data_type: "LaserScan"
          raytrace_max_range: 3.0 #3.0
          raytrace_min_range: 0.0
          obstacle_max_range: 2.5 #2.5
          obstacle_min_range: 0.0
      static_layer:
        plugin: "nav2_costmap_2d::StaticLayer"
        map_subscribe_transient_local: True
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        cost_scaling_factor: 4.0 #4.0
        inflation_radius: 0.3 #0.45
      always_send_full_costmap: True

planner_server:
  ros__parameters:
    expected_planner_frequency: 20.0
    use_sim_time: True
    planner_plugins: ["GridBased"]
    GridBased:
      plugin: "nav2_navfn_planner/NavfnPlanner"
      tolerance: 0.5
      use_astar: false
      allow_unknown: true

smoother_server:
  ros__parameters:
    use_sim_time: True
    smoother_plugins: ["simple_smoother"]
    simple_smoother:
      plugin: "nav2_smoother::SimpleSmoother"
      tolerance: 1.0e-10
      max_its: 1000
      do_refinement: True

behavior_server:
  ros__parameters:
    costmap_topic: local_costmap/costmap_raw
    footprint_topic: local_costmap/published_footprint
    cycle_frequency: 10.0
    behavior_plugins: ["spin", "backup", "drive_on_heading", "assisted_teleop", "wait"]
    spin:
      plugin: "nav2_behaviors/Spin"
    backup:
      plugin: "nav2_behaviors/BackUp"
    drive_on_heading:
      plugin: "nav2_behaviors/DriveOnHeading"
    wait:
      plugin: "nav2_behaviors/Wait"
    assisted_teleop:
      plugin: "nav2_behaviors/AssistedTeleop"
    global_frame: odom
    robot_base_frame: base_link #rplidar_link #base_link
    transform_tolerance: 0.1
    use_sim_time: true
    simulate_ahead_time: 2.0
    max_rotational_vel: 1.0
    min_rotational_vel: 0.4
    rotational_acc_lim: 3.2

robot_state_publisher:
  ros__parameters:
    use_sim_time: True

waypoint_follower:
  ros__parameters:
    use_sim_time: True
    loop_rate: 20
    stop_on_failure: false
    waypoint_task_executor_plugin: "wait_at_waypoint"
    wait_at_waypoint:
      plugin: "nav2_waypoint_follower::WaitAtWaypoint"
      enabled: True
      waypoint_pause_duration: 200

velocity_smoother:
  ros__parameters:
    use_sim_time: True
    smoothing_frequency: 20.0
    scale_velocities: False
    feedback: "OPEN_LOOP"
    max_velocity: [0.26, 0.0, 1.0]
    min_velocity: [-0.26, 0.0, -1.0]
    max_accel: [2.5, 0.0, 3.2]
    max_decel: [-2.5, 0.0, -3.2]
    odom_topic: "odom"
    odom_duration: 0.1
    deadband_velocity: [0.0, 0.0, 0.0]
    velocity_timeout: 1.0

The IR sensors do not integrate into Nav2 by default. Nav2 is only using the lidar data. In regards to the nav2 config you have provided, the obstacle layer / IR obstacle section that has been added is an interesting modification. The create3 IR sensor information is published under the /ir_intensity topic and with type irobot_create_msgs/msg/IrIntensityVector. Based on this config it would seem that you are trying to interpret the IR sensors as laserscans off of an /ir_obstacle topic. This would require custom code running to create the new topic, translate the data into the laserscan format and then publish the data. This in addition to thorough testing to make sure that the obstacle layer plugin has been configured properly. If these modifications aren't working how you or your team intended, then you should revisit how that data is being published (or even that it is being published) and how that does or does not translate into Nav2.

Thank you for bringing this issue to notice. We forgot to run the code for ir_intensity.  We are using a custom code for ir_intensity.  We are running the custom code using the command - ros2 launch tb4_ir obstacles.launch.py.
After doing this we observed that the robot was updating the position of small obstacles (the pink-ish) is showing but it kept on trying to navigate through it. There were instances where the robot would back up and try to navigate through the obstacle again. I am attaching the video below showing the collision. We are not sure if there is a parameter under Nav2 that we need to configure so it does not go through it.
Would you please elaborate on your comment about the "obstacle layer plugin has been configured properly." and "then you should revisit how that data is being published (or even that it is being published) and how that does or does not translate into Nav2."
here is the video:
This is how the rviz screen looks like:

This is the custom code we are using
tb4_ir.zip
This is the nav2.yaml file.
nav2.zip

Unfortunately I don't have the time to delve into this too deeply. Since it does sound like the turtlebot4 is working properly, I would encourage you to reach out on robotics stack exchange or on the nav2 repo to better understand how that obstacle layer plugin should work, and whether or not you have set it up correctly.

This issue is being closed due to inactivity. If you are still experiencing the issue, feel free to reopen this ticket when you are ready to continue the troubleshooting process.


Network Policies in Kubernetes 1.9 don't work

Hi, using k8s 1.9 with kops and romana v2.0.2. I'm trying to apply k8s network policies but they seem to have no effect. I see that the romana listener is picking them up and they are creating romana policies, but the rules are having no effect. Do k8s network policies work with romana 2.0.2? (I see in the romana 2.1 feature list that supporting new style k8s network policies is a upcoming feature.)

Hi @romeotheriault, Romana is a bit behind with the Network Policy API support. There was a change in the default behavior from k8s v1.7 to v1.8 (and v1.9). Romana v2.0.2 still only supports the v1.7 style API. Here is an example of a network policy that uses the old API. https://github.com/romana/romana/blob/master/test/kubernetes-cluster/frontend-to-backend.yml
Romana v2.1 is not quite ready. Been working on other things lately.

@romeotheriault yes, v2.0.2 does not support free form lables defined in the spec. The default lables are 'romanaTenant' and 'romana.io/segment' and are defined at install here: https://github.com/romana/romana/blob/b383faf2884a9f3bb56f090161ba20732b0c02eb/romana-install/group_vars/kube_nodes
So, the default install allows only two labels: 'romana.io/segment' and 'romanaTenant'
Haven't run across anyone using more than two lables, yet, but can see how that would be useful, for sure. Multiple free-form lable are part of the next release, along with the latest API support.
Not sure how to change the label names, @cgilmour would have more details on what to do.

@romeotheriault FWIW, these hard coded labels are a remnant of Romana v1.0 that had an explicit tenancy model. Romana v2 expanded that to be more flexible, but still some lingering evidence of the old v1.0 model.

Thank you. That helps, and I think I'm getting really close but for some reason none of the rules I apply are working. As a first test I'm simply trying to have a rule between two pods in the same namespace that only allows one port to be contacted from the other pod. I applied the 'romana.io/segment' label to the containers I created, and  romanaTenant appears to be getting set to the namespace of the pod.
But this network policy is still allowing all communications from the dbm segment (pod) to the gw segment (pod). It's not getting restricted to using port 40000.
kind: NetworkPolicy
metadata:
 name: pol1
 namespace: sprouts
spec:
 podSelector:
  matchLabels:
   romana.io/segment: gw
   romanaTenant: sprouts
 ingress:
 - from:
   - podSelector:
      matchLabels:
       romana.io/segment: dbm
       romanaTenant: sprouts
   ports:
    - protocol: TCP
      port: 40000

Here are the pods definitions:

---
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
  name: am1edbm
  namespace: sprouts
spec:
  serviceName: ""
  replicas: 1
  selector:
    matchLabels:
      app: dbm
  template:
    metadata:
      labels:
        app: dbm
        romana.io/segment: dbm
    spec:
      containers:
      - name: dbm
        image:<PHONE_NUMBER>333298.dkr.ecr.us-east-1.amazonaws.com/k8sdbm:latest

---
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
  name: am1edbm
  namespace: sprouts
spec:
  serviceName: ""
  replicas: 1
  selector:
    matchLabels:
      app: gw
  template:
    metadata:
      labels:
        app: gw
        romana.io/segment: gw
    spec:
      containers:
      - name: gw
        image:<PHONE_NUMBER>44298.dkr.ecr.us-east-1.amazonaws.com/k8sgw:latest

And the romana block list output:

root@ip-10-33-16-10:~# romana block list
Block List
Block CIDR      Block Host                              RevisionBlock Tenant    Block Segment   Block Allocated IP Count
<IP_ADDRESS>/29                                           6                                       0
<IP_ADDRESS>/29   ip-10-33-16-99.aws.1010data.cloud       9       kube-system     default         3
<IP_ADDRESS>/29                                          8                                       0
<IP_ADDRESS>/29   ip-10-33-16-10.aws.1010data.cloud       21      sprouts         gw              1
<IP_ADDRESS>/29   ip-10-33-16-10.aws.1010data.cloud       5       cmh01           default         1
<IP_ADDRESS>/29  ip-10-33-16-10.aws.1010data.cloud       8       default         webserver       2
<IP_ADDRESS>/29  ip-10-33-16-10.aws.1010data.cloud       3       sprouts         dbm             1
<IP_ADDRESS>/29  ip-10-33-16-10.aws.1010data.cloud       1       sprouts         compute         1```

Am I missing something obvious?

Hi @romeotheriault,
The latest version of Romana still uses the v1.7 approach to policies, which required an annotation on the namespace:
kubectl annotate --overwrite namespace sprouts 'net.beta.kubernetes.io/networkpolicy={"ingress": {"isolation": "DefaultDeny"}}'
This will trigger deletion of the AllowAllPods2Talk_xxxxxx policy for that namespace, and only traffic from your additional policies will be permitted.
Can you try that and report back?
Thanks
Caleb

From our discussion on slack, there were some rules that effectively accept traffic before Romana's policy rules have a chance to make decisions.
(from iptables-save)
-A FORWARD -p tcp -j ACCEPT
-A FORWARD -p udp -j ACCEPT
-A FORWARD -p icmp -j ACCEPT

These accept the traffic on the FORWARD chain before reaching the rules that Romana manages.
This seems to be related to the change from kubernetes/kops#3977, and caused an issue for other network policy implementations (eg: kubernetes/kops#4345).
I'll see what options we have for handling this better.

@romeotheriault Did you get the NetworkPolicy's working? I'm currently trying to accomplish the same but somehow all communication between the pods keeps working (which is bad if you want to block communication).
my iptables-save on the machines does not show the -A forwared ... rules show in the comment above.

Can you provide the modified yaml with deployments and Network policies working for K8s>1.6 ?


Android Basics: Loading and displaying images from the Internet

name: Android Basics Unit 4 issue
about: Report problems with the Android Basics Unit 4 codelabs
title: 'Android Basics Unit 4 issue:'
labels: ''
assignees: ''

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-internet-images#3
In which task and step of the codelab can this issue be found?
4. Display a grid of images with a RecyclerView > Add Recyclerview > 1. Open layout/gridview_item...
Describe the problem
It is written gridview_item.xml instead of grid_view_item.xml (see https://github.com/google-developer-training/android-basics-kotlin-mars-photos-app/blob/starter/app/src/main/res/layout/grid_view_item.xml )

idem for "8. According to the Material design guidelines, [...] in gridview_item.xml layout." instead of grid_view_item.xml

idem for "8. According to the Material design guidelines, [...] in gridview_item.xml layout." instead of grid_view_item.xml

idem for "9. Open layout/gridview_item.xml." instead of grid_view_item.xml

@AlexandrePlus
Thank you so much for reporting this issue. This is fixed and will be published soon.


Android init script failing with fast key rotating servers

https://github.com/jedisct1/dnscrypt-proxy/blob/master/dist-build/android-files/system/etc/init.d/99dnscrypt#L9
3600 will return 2 warnings
"The certificate is not valid for the given safety margin"
"Safety margin wider than the certificate validity period"
1440 will return 1 warning
"The certificate is not valid for the given safety margin"
using 720 returns 0 warnings, proxy should work.
--test=120 should fix for good https://github.com/jedisct1/dnscrypt-proxy/issues/479

720 is the margin used by the docker image before switching to a new key, so yes, this is the maximum value that should be used.
Or to avoid a race condition, use a slightly lower value such as 700.


Add symfony3 as requirement in composer.json

The method FrameworkController::json() this bundle relies on is available since Symfony 3.0 so the requires block in composer.json of this bundle should require that symfony >= 3.0 get installed. Else the whole GraphQLBundle will not work.
Attempted to call an undefined method named \"json\" of class \"Youshido\\GraphQLBundle\\Controller\\GraphQLController\".

The other solution would be to create a symfony 2.7/2.8 comapitble branch or something like that. Or are there any other symfony 3.0 functionalities required to get this bundle working?
EDIT no not even symfony 3.0 has this json method in controller. Symfony >= 3.1 is required.

Hi, @TiMESPLiNTER
Yes, you're right. We'll fix it today.

Hi, @TiMESPLiNTER
Thank you for your interesting this bundle. And you're right, we'll fix it today.

fixed in v1.1.2+


Do not immediate terminate REFER subscription

This was requested in the mailing list.
When receiving a REFER, the SIP.js user agent replies with a NOTIFY request immediately terminating the subscription.  This is valid as per RFC 3515 Section 2.4.4, but more complete information (see section 2.4.5 of the RFC) would be nice.

There's a similar but much more significant issue on the REFER request side in Session.refer.  On a 2XX response to a REFER with replaces, the Session immediately terminates.  The Session needs the ability to continue to stay up to respond and act on the actual NOTIFY.  The original 202 response simply means it's subscribed.  Should I break this out into another issue?

This has also been requested on the mailing list

I opened an Issue about it a few days ago with some code I'm using as a workaround here: https://github.com/onsip/SIP.js/issues/254

Can you try out #459? I think that I have addressed this issue there.

Due to the age of this issue, if we do not hear any feedback on this we will close it once we merge the pull request.


Multiple redirect_uri values for a client?

I have a use-case for multiple valid redirect_uri values for one client. If I create a pull request that allows specifying multiple URI's, seperated by whitespace, would this be accepted for merge into the library code?
For example
http://localhost:8080 https://localhost

It's possible. But this opportunity should be optional, and is disabled by default.


Support go1.18 standard packages

support go1.18 standard packages
generate with
$ go generate ./...

@Dreamacro thanks for your contribution! welcome.


[BUG] IR sample rate incorrect

To Reproduce
Steps to reproduce the behavior:

Open NAM
Load an IR (no model)
Listen, and then change project sample rate
The sound of the IR will change.

Expected behavior
If you playback a track with an IR in NAM and no model, and then compare it to another IR loader with the same IR, it will sound different. If you change the project sample rate, the IR inside NAM will have a tonal shift.

macOS 11.6.8
Plugin version [0.7.4]
VST3,
Reaper

Here is a link to the IR used : (https://drive.google.com/open?id=1XttXjJQwrkJk0xQCg-CwH5JPjcFr-EOr&usp=drive_fs)

Thanks for the bug report, and thanks for the steps to reproduce. I bet I know exactly what the problem is--when teh sample rate is changed, I need to tell the IR loader to resample the IR in the new sample rate.
Having a look

Thank you I appreciate it. NAM is amazing!
On Sat, Jul 29, 2023 at 12:28 AM Steven Atkinson @.***>
wrote:

Thanks for the bug report, and thanks for the steps to reproduce. I bet I
know exactly what the problem is--when teh sample rate is changed, I need
to tell the IR loader to resample the IR in the new sample rate.
Having a look
—
Reply to this email directly, view it on GitHub
https://github.com/sdatkinson/NeuralAmpModelerPlugin/issues/351#issuecomment-1656549957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BBSX6Q76OC54BLB2G5HD6UTXSSGNZANCNFSM6AAAAAA24HJ4FM
.
You are receiving this because you authored the thread.Message ID:
@.***>


XIII (2003) anti-culling corrupts water

Describe the bug

When I enable anti-culling the water looks corrupted
Commit 6b4fe7d
MSI 2070 super
531.79
<IP_ADDRESS> (GOG)

Attach logs!

NvRemixBridge.log
d3d9.log
XIII_d3d9.log

To Reproduce
Enable anti-culling and look at the water
Expected behavior
For the water to look normal
Screenshots

We updated code to enable bounding box by default when anti-culling is enabled. You could try it in latest build.

While the latest version has improved it significantly, there is still some weird artifacts.
https://github.com/NVIDIAGameWorks/rtx-remix/assets/76069060/04eaa810-c451-4eb2-9090-2c6b661132ff

Ok thanks for sharing, we will continue investigate on this issue

We have pushed fix for this issue, could you check if it's still existing?


Update sbt-scoverage to 2.0.0

Updates org.scoverage:sbt-scoverage from 1.9.3 to 2.0.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scoverage", artifactId = "sbt-scoverage" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scoverage", artifactId = "sbt-scoverage" }
}]

labels: sbt-plugin-update, early-semver-major, semver-spec-major, commit-count:1

Codecov Report

Merging #465 (71c820b) into main (850afcf) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #465   +/-   ##
=======================================
  Coverage   91.21%   91.21%
=======================================
  Files          18       18
  Lines         296      296
  Branches        2        4    +2
=======================================
  Hits          270      270
  Misses         26       26

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 850afcf...71c820b. Read the comment docs.


update button storybook description and remove no longer needed examples

https://goa-dio.atlassian.net/browse/DDIDS-584

:tada: This PR is included in version 4.0.0-alpha.7 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.65 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-alpha.6 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Feature Request] Bracket Pair Colorization: Force unique opening color

This would be porting over said feature from Bracket Pair Colorizer 2
"bracket-pair-colorizer-2.forceUniqueOpeningColor"

How does this feature work? Why "opening"?

Basically it makes sure that each bracket pair is a different color instead of only having a color switch when they start nesting.

It would be nice to have it along with "bracket-pair-colorizer-2.forceIterationColorCycle".

I'm used to opening color but I guess could get used to color cycle

So forceUniqueOpeningColor just cycles between the first and second color, while forceIterationColorCycle cycles between all colors?
It seems to me they both solve the same issue - thus I only would like to implement one of them.

IMHO, forceIteration has the drawback that the last nested pair might be the same color of the outer pair. With forceUnique, there is a way to ensure that the inner and outer pairs have different colors (I can't remember if it was implemented that way in the original extension though).

The original extension was a bit buggy and some corner cases were broken. I don't remember the exact scenario but I do remember that in some cases, consecutive brackets could have the same colors, although my memory was between a parent and its last child (...or maybe I was using forceIteration rather than forceUnique...?🤔).

We could just avoid the parent color

+1 on that, although I would even like it better if the pair would take the same color has the parent when the parent has no other characters but that pair (😛, I'm still hoping it will happen one day).

I'd like to bring attention back to this issue, and just wanted to add in that I would also like to see the forceIteration setting come to the native feature.


Fixed noise_painter_3d. Found that it should be grid.set_value(...) not grid.set_cell(...)

Let me know if this should not be changed. I found this while using Gaea for my own game, and it was bringing up errors when using noise_painter_3d, but when I switched the function call, it worked like normal.

oh, how did I miss this??? thanks!


Remove generation of PVC manifest files

This PR removes Terraform's responsibility to generate PVC manifest files. It is up to the application to make this work.
This resolves jhu-library-operations/tf-mod-aws-efs-pv-k8s/issues/11

Swell thanks!


[Experimental] Check that commits are signed

Issue is #138.  I'm doing some tests on this PR, to see if/how PR #140 works.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

87 of 557 (15.62%)  changed or added relevant lines in 8 files are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-1.2%) to 20.604%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

fabrictestbed_extensions/fablib/fablib.py
3
4
75.0%

fabrictestbed_extensions/fablib/resources.py
1
6
16.67%

fabrictestbed_extensions/fablib/component.py
8
27
29.63%

fabrictestbed_extensions/fablib/slice.py
3
85
3.53%

fabrictestbed_extensions/fablib/interface.py
17
101
16.83%

fabrictestbed_extensions/fablib/node.py
31
154
20.13%

fabrictestbed_extensions/fablib/network_service.py
23
179
12.85%

Files with Coverage Reduction
New Missed Lines
%

fabrictestbed_extensions/fablib/node.py
1
10.62%

fabrictestbed_extensions/fablib/slice.py
3
9.26%

Totals

Change from base Build<PHONE_NUMBER>:
-1.2%

Covered Lines:
827

Relevant Lines:
3625

💛  - Coveralls

Experiment is complete.


[Feature] Consider reprex to show code snippets

Is your feature request related to a problem? Please describe.
When showing code, sometimes it would be nice to see results as if run in console
Describe the solution you'd like
Consider using reprex package?
Describe alternatives you've considered
Currently I always use executable code chunks and the layout isn't always the clearest.

Yup! It needs to be self-contained, so for the longer articles, doesn't make sense... but for some quick asides, this could be very handy, will def use.


Add OPT-IN support for SEP0023 (Muxed Accounts M-strkeys)

TL;DR
Add opt-in support for SEP 23. SEP23 adds a strkey representation (M-strkeys) for MuxedAccounts.
For example, given the MuxedAccount MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26 , you might get the following fields:
source_account: GAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSTVY
source_account_muxed: MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26
source_account_muxed_id: 1234

It should be implemented as an opt-in feature
SEP23 is still a Draft. We plan to (at least initally) use the M-strkey representation to explore the use of Muxed Accounts. Later on, we me consider it stable and enable it by default.
As such, it's critical to make M-strkeys an opt-in feature (e.g. only usable by the user through am explicitly enabled flag or other mechanisms).
In particular, no user should be enabling M-addresss unknowingly, either for new or existing code (e.g. through an SDK update).
Recent SEP23 representation change
If you were already familiar with SEP23, it's worth noting that the encoding ordering changed recently at https://github.com/stellar/stellar-protocol/pull/895
The SEP 23 specification already contains that modification.
Reference implementation
You can use the Go SDK implementation as a reference: https://github.com/stellar/go/pull/3527
In the Go SDK we have one entry point into generating transaction envelopes, NewTransaction() . We added a configuration parameter to NewTransaction() which toggles support for muxed accounts. If NewTransaction() is configured with muxed account support then it will interpret "M..." address strings as muxed accounts at the xdr level. However, if  NewTransaction() is configured to disable muxed accounts, whenever an "M..." address is provided we will extract the underlying "G..." address from and use that at the XDR level.
We followed a similar approach for the other entry points of the SDK (namely TransactionFromXDR() and NewFeeBumpTransaction()).

changed encoding ordering for M-addresses in release 1.9.9 as mentioned here https://github.com/stellar/stellar-protocol/pull/895

see https://github.com/Soneso/stellar-ios-mac-sdk/issues/139


[Feature][API] Manage mirror interval

Gitea version (or commit ref): 1.11.4
Git version: N/A
Operating system: N/A

Description
We're using Gitea as a local Git mirror for repositories and are using the migration functionality to get repositories into Gitea. However as in most situation a one-fits-all mirror interval is not feasible. Currently it is not possible to specify how often (or if at all) a migrated repository should be synchronized automatically with its origin/upstream.
We would like to automate these steps and currently the only manual activity is to update mirror interval to suite our needs.
Impacted endpoints:
POST /repos/migrate - new migration
PATCH /repos/{owner}/{repo} - when changing an existing repository
Thanks.

I see that #11605 already exists. Must have missed it. Closing in favour of it.


[IDE] Fix imbalanced walkToDeclPre/Post calls in SemaAnnotator for IfConfigDecls

We were calling walkToDeclPre without calling walkToDeclPost.

Resolves rdar://problem/39011293

@swift-ci please test


Update the script to Python 3

Currently, it runs/tested on Python 2 which is now outdated. We'd like to run it using Python 3.
Acceptance

[ ] The script runs on Python 3 https://github.com/datasets/ppp/tree/master/scripts

Tasks

[ ] Update the script and if needed update the list of requirements
[ ] Update the README

@anuveyatsu hey, I fixed the issue but I can't push from my local branch and I also can't create branches using the GitHub UI, can you help me?
git push --set-upstream origin feature/python3-upgrade

ERROR: Permission to datasets/ppp.git denied to Gutts-n.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I'm Leo, I was recommended by @demenech.

Hi @Gutts-n thanks for reaching out! I think you'd normally create your own fork of a repository and then create a pull request. That workflow is the simplest and doesn't require giving additional permissions to a contributor. Would you mind doing that way?

I created the PR, here it is https://github.com/datasets/ppp/pull/16.

Closing this as FIXED. The data pipelines are running on a monthly basis.


Add serviceaccount to privileged scc

When istio-proxy is injected, it needs to use privileged scc.
This patch adds function to add controller serviceaccount to the
privileged scc.
NOTE(or TODO):

This patch does not remove serviceaccount which we added during
uninstallation.
This patch adds controller serviceaccount to privileged scc, but
the controller serviceaccount is used by other pods in
knative-serving project. (Another SA should be used for privileged scc?)
Maistra x OCP4.1 has a known issue.

Thank you @jcrossley3
I have moved addUserToSCC func to PreInstalls.
As a record, I have verified the fix on my env by running operator-sdk up local:
$ oc adm policy remove-scc-from-user privileged  -z controller   # just make sure `privileged` scc is clear.
$ operator-sdk up local
  ...
{"level":"info","ts":1560354114.2306783,"logger":"openshift","msg":"Added ServiceAccount \"system:serviceaccount:knative-serving:controller\" to SecurityContextConstraints \"privileged\""}

and checking scc as well as activator and autoscaler are running with 2/2.
$ oc get scc privileged -o yaml |grep knative-serving
- system:serviceaccount:knative-serving:controller

$ oc get pod |grep -E "act|auto"
activator-7587c7475b-fwtgs                   2/2     Running   0          3m46s
autoscaler-5bf6cfd9bc-lshsl                  2/2     Running   0          3m45s

I'm curious: how exactly did you test this without publishing a new operator image on quay.io?

I'm curious: how exactly did you test this without publishing a new operator image on quay.io?

Nevermind. I just re-read your comment. :smile:


Wrong Bounds Check for pic_parameter_set_id

The pic_parameter_set_id is a ParamSetId struct, which checks if the ID is within [0, 31]: https://github.com/dholroyd/h264-reader/blob/master/src/nal/pps.rs#L218
Valid bitstreams can have pic_parameter_set_ids in the range [0, 255].

This arises from mistakenly sharing a single ParamSetId type between seq_parameter_set_rbsp() and pic_parameter_set_rbsp() syntax.  Will need to break this into two separate Id types.

Is there a need for a video in which this gets triggered? I can provide one.

@astraw yes please - I would be happy to add a real PPS as a unit test

Here is an MP4 file containing an h264 video track that triggers the issue for me. (I moved my .h264 file into and .mp4 file with ffmpeg -i movie20221006_115500.885150194-issue56.h264 -vcodec copy movie20221006_115500.885150194-issue56.mp4 because github didn't accept an .h264 upload. I verified the .h264 file extracted with ffmpeg -i movie20221006_115500.885150194-issue56.mp4 -vcodec copy extract.h264 still triggers the issue for me.)


Update actor documentation

What happened?
Initially, the actor was designed to run continuously unless there was an error or it was intentionally stopped. Later, the actor was updated to support a new use-case where the actor exits the running loop upon a normal termination.
The current actor documentation and examples primarily focus on stopping the actor manually, with only a brief mention that the actor also naturally terminates upon completing execution without errors. Some examples are either outdated or not entirely accurate.
For example, here it documents how it is expected to be used, as continuously running actors:  https://github.com/frequenz-floss/frequenz-sdk-python/blob/v1.x.x/src/frequenz/sdk/actor/init.py#L214-L218
In this part, it states that actors will be restarted only when it exits with errors: https://github.com/frequenz-floss/frequenz-sdk-python/blob/v1.x.x/src/frequenz/sdk/actor/init.py#L38-L40
And here actors are awaited to finish execution https://github.com/frequenz-floss/frequenz-sdk-python/blob/v1.x.x/src/frequenz/sdk/actor/init.py#L46-L48 but the examples only point out that actors needs to be manually stopped
For this example, the actor will block either until execution termination or until it gets stopped
https://github.com/frequenz-floss/frequenz-sdk-python/blob/v1.x.x/src/frequenz/sdk/actor/__init__.py#L70-L88
Also internal documentation needs to be updated to reflect what the code actually does.
For instance, the actor will also exit if it finishes execution successfully without any error but this is not reflected in the function documentation
https://github.com/frequenz-floss/frequenz-sdk-python/blob/v1.x.x/src/frequenz/sdk/actor/_actor.py#L75-L111
What did you expect instead?
Update or extend documentation and examples in actor class and module to reflect what the actor code does, including the scenario where the actor terminates execution normally.
Affected version(s)
No response
Affected part(s)
Actors or actors utilities (decorator, etc.) (part:actor), Documentation (part:docs)
Extra information
Related to https://github.com/frequenz-floss/frequenz-sdk-python/issues/632

In https://github.com/frequenz-floss/frequenz-sdk-python/blob/471adc6623507eeb2f9fba693a62b735365b6261/src/frequenz/sdk/actor/init.py#L214 it says:

Normally an actor should run forever (or until it is
[stopped][frequenz.sdk.actor.Actor.stop]), so it is very common to have an infinite loop
in the _run() method, typically receiving messages from one or more channels
([receivers][frequenz.channels.Receiver]), processing them and sending the results to
other channels ([senders][frequenz.channels.Sender]).

Which doesn't look incorrect IMHO, it explicitly says one  can stop the actor manually. Do you mean we should just not mentioning that actors "normally should run forever", or that they could also stop on their own?

https://github.com/frequenz-floss/frequenz-sdk-python/blob/471adc6623507eeb2f9fba693a62b735365b6261/src/frequenz/sdk/actor/__init__.py#L38-L40
This also doesn't say unhanded errors are the only way an actor can be restarted, it says it is automatically restarted on errors.

https://github.com/frequenz-floss/frequenz-sdk-python/blob/471adc6623507eeb2f9fba693a62b735365b6261/src/frequenz/sdk/actor/__init__.py#L46-L48
Same here, this is only describing one feature, actors are async context managers and can be used like that, but you don't have to.

Do you mean we should just not mentioning that actors "normally should run forever", or that they could also stop on their own?

I think we should definitely mention "run forever" as a pattern, but it is starting to become just one usage pattern, because we are now exploring other patterns, like actors managing and stopping sub-actors, etc.
I think we need to make changes only once we know what those other patterns look like and there is atleast one implementation that we've refined and like, and want to share.

So, in conclusion, after looking at the examples provided in the issue, I think the current docs are mostly correct, but I agree we could mention the case where an actor stops on its own (by just returning from the run() method normally) and add some example for that too.

I think we need to make changes only once we know what those other patterns look like and there is atleast one implementation that we've refined and like, and want to share.

This also looks like a reasonable path to me, I would spend a lot of time documenting patterns that we didn't use that much and maybe they don't work out that well after all. I mean, we could make it more explicit that there are other ways to use actors but maybe not spend a lot of time adding examples of other specific pattern just now.

So I wonder if the priority high is really correct. Also @daniel-zullo-frequenz I think it would be helpful if you could submit a PR, even if it is a very rough draft, and maybe not even changing the text proper but just adding comments like "Here I would clarify X and Y" to have a better idea of how docs could look more clear to you.

This doesn't look incorrect IMHO, it explicitly says one can stop the actor manually. Do you mean we should just not mentioning that actors "normally should run forever", or that they could also stop on their own?

They could also terminate on their own without calling stop(), that's missing


gcwuf domain file add

Request for add domain in JetBrains list

@mani1424 Thank you for the request. I removed the second file because subdomains are always included if the parent domain is in the trusted list.
Could you please reply this comment with full name of the school? It has to be named like "University of Something" or similarly. Please don't use just an abbreviation as a university name.
Thank you.

Sure,
Full name is "Government College Women University Faisalabad"

@mani1424 First stage of verification passed, official domain is gcwuf.edu.pk as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.


Azure.Identity 1.8.0 - ManagedIdentityCredential authentication failed: No ClientId was specified.

Library name and version
Azure.Identity 1.8.0
Describe the bug
We've been using Azure.Identity 1.7.0 successfully for 6 months.
Upgrading to Azure.Identity 1.8.0 has broken our authentication to Key Vault again with the following error **ManagedIdentityCredential authentication failed: No ClientId was specified. **
We are using:
FUNCTIONS_EXTENSION_VERSION: ~4
FUNCTIONS_WORKER_RUNTIME: dotnet-isolated
See Also:  #30287
We are using 'DefaultAzureCredential' to provide credentials to Key Vault SecretClient.
DefaultAzureCredentialOptions credentialOptions = new DefaultAzureCredentialOptions()
{
	ExcludeAzureCliCredential = true,
	ManagedIdentityClientId = _configuration.ManagedIdentityClientId
};
SecretClientOptions clientOptions = GetClientOptions();
_client = new SecretClient(new Uri(_configuration.KeyVaultUrl), new DefaultAzureCredential(credentialOptions), clientOptions);

Where ManagedIdentityClientId is an empty string when using System Managed Identity from Azure Functions.
Why has this broken again.
Expected behavior
Authentication works.
Actual behavior
ManagedIdentityCredential authentication failed: No ClientId was specified.
Reproduction Steps
See above.
Environment
FUNCTIONS_EXTENSION_VERSION: ~4
FUNCTIONS_WORKER_RUNTIME: dotnet-isolated

Also this is the exception stack trace:
Result: Failure Exception: Azure.Identity.AuthenticationFailedException: ManagedIdentityCredential authentication failed: No ClientId was specified. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/managedidentitycredential/troubleshoot ---> MSAL.NetCore.<IP_ADDRESS>.MsalClientException: ErrorCode: no_client_id Microsoft.Identity.Client.MsalClientException: No ClientId was specified. at Microsoft.Identity.Client.AbstractApplicationBuilder1.Validate() at Microsoft.Identity.Client.ConfidentialClientApplicationBuilder.Validate() at Microsoft.Identity.Client.AbstractApplicationBuilder1.BuildConfiguration() at Microsoft.Identity.Client.ConfidentialClientApplicationBuilder.BuildConcrete() at Microsoft.Identity.Client.ConfidentialClientApplicationBuilder.Build() at Azure.Identity.MsalConfidentialClient.CreateClientAsync(Boolean async, CancellationToken cancellationToken) at Azure.Identity.MsalClientBase1.GetClientAsync(Boolean async, CancellationToken cancellationToken) at Azure.Identity.MsalConfidentialClient.AcquireTokenForClientCoreAsync(String[] scopes, String tenantId, Boolean async, CancellationToken cancellationToken) at Azure.Identity.MsalConfidentialClient.AcquireTokenForClientAsync(String[] scopes, String tenantId, Boolean async, CancellationToken cancellationToken) at Azure.Identity.ManagedIdentityClient.AuthenticateAsync(Boolean async, TokenRequestContext context, CancellationToken cancellationToken) at Azure.Identity.ManagedIdentityCredential.GetTokenImplAsync(Boolean async, TokenRequestContext requestContext, CancellationToken cancellationToken) --- End of inner exception stack trace --- at Azure.Identity.CredentialDiagnosticScope.FailWrapAndThrow(Exception ex, String additionalMessage) at Azure.Identity.ManagedIdentityCredential.GetTokenImplAsync(Boolean async, TokenRequestContext requestContext, CancellationToken cancellationToken) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted[T](ValueTask1 task) at Azure.Identity.ManagedIdentityCredential.GetToken(TokenRequestContext requestContext, CancellationToken cancellationToken) at Azure.Identity.DefaultAzureCredential.GetTokenFromSourcesAsync(TokenCredential[] sources, TokenRequestContext requestContext, Boolean async, CancellationToken cancellationToken) at Azure.Identity.DefaultAzureCredential.GetTokenImplAsync(Boolean async, TokenRequestContext requestContext, CancellationToken cancellationToken) at Azure.Identity.CredentialDiagnosticScope.FailWrapAndThrow(Exception ex, String additionalMessage) at Azure.Identity.DefaultAzureCredential.GetTokenImplAsync(Boolean async, TokenRequestContext requestContext, CancellationToken cancellationToken) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted[T](ValueTask1 task) at Azure.Identity.DefaultAzureCredential.GetToken(TokenRequestContext requestContext, CancellationToken cancellationToken) at Azure.Core.Pipeline.BearerTokenAuthenticationPolicy.AccessTokenCache.GetHeaderValueFromCredentialAsync(TokenRequestContext context, Boolean async, CancellationToken cancellationToken) at Azure.Core.Pipeline.BearerTokenAuthenticationPolicy.AccessTokenCache.GetHeaderValueAsync(HttpMessage message, TokenRequestContext context, Boolean async) at Azure.Core.Pipeline.BearerTokenAuthenticationPolicy.AccessTokenCache.GetHeaderValueAsync(HttpMessage message, TokenRequestContext context, Boolean async) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted[T](ValueTask1 task) at Azure.Core.Pipeline.BearerTokenAuthenticationPolicy.AuthenticateAndAuthorizeRequest(HttpMessage message, TokenRequestContext context) at Azure.Security.KeyVault.ChallengeBasedAuthenticationPolicy.AuthorizeRequestInternal(HttpMessage message, Boolean async) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted(ValueTask task) at Azure.Security.KeyVault.ChallengeBasedAuthenticationPolicy.AuthorizeRequest(HttpMessage message) at Azure.Core.Pipeline.BearerTokenAuthenticationPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory1 pipeline, Boolean async) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted(ValueTask task) at Azure.Core.Pipeline.BearerTokenAuthenticationPolicy.Process(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.RedirectPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory1 pipeline, Boolean async) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted(ValueTask task) at Azure.Core.Pipeline.RedirectPolicy.Process(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.RetryPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory1 pipeline, Boolean async) at Azure.Core.Pipeline.RetryPolicy.ProcessAsync(HttpMessage message, ReadOnlyMemory1 pipeline, Boolean async) at Azure.Core.Pipeline.TaskExtensions.EnsureCompleted(ValueTask task) at Azure.Core.Pipeline.RetryPolicy.Process(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipelinePolicy.ProcessNext(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.Process(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipelinePolicy.ProcessNext(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.Process(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipelinePolicy.ProcessNext(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipelineSynchronousPolicy.Process(HttpMessage message, ReadOnlyMemory1 pipeline) at Azure.Core.Pipeline.HttpPipeline.Send(HttpMessage message, CancellationToken cancellationToken) at Azure.Core.Pipeline.HttpPipeline.SendRequest(Request request, CancellationToken cancellationToken) at Azure.Security.KeyVault.KeyVaultPipeline.SendRequest(Request request, CancellationToken cancellationToken) at Azure.Security.KeyVault.KeyVaultPipeline.SendRequest[TResult](RequestMethod method, Func1 resultFactory, CancellationToken cancellationToken, String[] path) at Azure.Security.KeyVault.Secrets.SecretClient.GetSecret(String name, String version, CancellationToken cancellationToken) at Onsend.Lib.Core.KeyVault.KeyVaultManager.GetSecret(String secretName) in //Onsend.Lib/Core/KeyVault/KeyVaultManager.cs:line 135 at Onsend.Lib.Core.KeyVault.KeyVaultSecretProvider.GetSecret(String key, Boolean required) in //Onsend.Lib/Core/KeyVault/KeyVaultSecretProvider.cs:line 57

Upgrading to Azure.Identity 1.9.0 directly (not as a transitive dependency) produces the same error:
ManagedIdentityCredential authentication failed: No ClientId was specified

Setting the ManagedIdentityClientId property to null rather than a potentially empty string seems to have solved the issue.
string clientId = _configuration.ManagedIdentityClientId; credentialOptions.ManagedIdentityClientId = string.IsNullOrEmpty(clientId) ? null : clientId;

Thank you for your feedback.  Tagging and routing to the team member best able to assist.


Save bitset as binary data.

Use a shifting bitmask to serialize bits.
Only use bitset type, others are just as slow.

Converting bitsets to strings by using 1's and 0's takes up too much space on large bitsets.

This has the beginnings of a good change though we'll need to make some adjustments before merging something like this.  Serializing like this is great for binary archives but wouldn't look good in a text based archive.  In other situations like this (see vector for example) we use the BinaryData wrapper to create two versions of the serialization code - one for archives optimized to handle binary chunks, and one for everyone else.
So that would be the first thing that needs to be done.
The second thing is that all of the types need to be the fixed sized variants, especially things that actually go to be serialized (uint8 instead of char for example).
These are pretty minor requirements so if you don't get around to making them yourself, I'll do them when I do the merge.  Otherwise it's a good idea!

Thanks for the constructive feedback.. I agree, and I will try to submit a new patch soon.

I've integrated your changes such that archives that support BinaryData will now automatically save using your chunking method. When loading it will always dynamically check the bitset serialization enum type so that this is backwards compatible.


error on starting the plugin

2021-06-29T15:50:58     WARNING    Traceback (most recent call last):
File "/home/sandro/.local/share/QGIS/QGIS3/profiles/default/python/plugins/cbers4a/qgis_cbers4a_downloader.py", line 272, in update_collection
year, month, day = int(mindate[0]), int(mindate[1]), int(mindate[2])
ValueError: invalid literal for int() with base 10: '27T13:55:50'

probably when updating collections

Just had the same problem on Ubuntu 20: 021-09-12T23:25:36     WARNING    Traceback (most recent call last):
File "/home/pompeu/.local/share/QGIS/QGIS3/profiles/default/python/plugins/cbers4a/qgis_cbers4a_downloader.py", line 272, in update_collection
year, month, day = int(mindate[0]), int(mindate[1]), int(mindate[2])
ValueError: invalid literal for int() with base 10: '27T13:58:50'
Have anyone managed to solve this issue?
I also cannot change the coordinate from the "search and download imagery", maybe due to this issue.
Thanks

This error prevents the plugin from updating the date availability field
but it still works.
Search coordinates are updated along with the canvas extent.
I will manage to fix the date issue soon.
Att,
Sandro.
Em dom., 12 de set. de 2021 às 23:29, joaopompeu @.***>
escreveu:

Just had the same problem on Ubuntu 20: 021-09-12T23:25:36 WARNING
Traceback (most recent call last):
File
"/home/pompeu/.local/share/QGIS/QGIS3/profiles/default/python/plugins/cbers4a/qgis_cbers4a_downloader.py",
line 272, in update_collection
year, month, day = int(mindate[0]), int(mindate[1]), int(mindate[2])
ValueError: invalid literal for int() with base 10: '27T13:58:50'
Have anyone managed to solve this issue?
I also cannot change the coordinate from the "search and download
imagery", maybe due to this issue.
Thanks
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sandroklippel/cbers4a/issues/3#issuecomment-917786598,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIBSMEEJTH3NQLZXSKJSRSTUBVOXLANCNFSM47Q2NWTA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thank you Sandro!
It works fine this way.
Best,
Joao
Em seg., 13 de set. de 2021 às 11:35, Sandro Klippel <
@.***> escreveu:

This error prevents the plugin from updating the date availability field
but it still works.
Search coordinates are updated along with the canvas extent.
I will manage to fix the date issue soon.
Att,
Sandro.
Em dom., 12 de set. de 2021 às 23:29, joaopompeu @.***>
escreveu:

Just had the same problem on Ubuntu 20: 021-09-12T23:25:36 WARNING
Traceback (most recent call last):
File

"/home/pompeu/.local/share/QGIS/QGIS3/profiles/default/python/plugins/cbers4a/qgis_cbers4a_downloader.py",

line 272, in update_collection
year, month, day = int(mindate[0]), int(mindate[1]), int(mindate[2])
ValueError: invalid literal for int() with base 10: '27T13:58:50'
Have anyone managed to solve this issue?
I also cannot change the coordinate from the "search and download
imagery", maybe due to this issue.
Thanks
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/sandroklippel/cbers4a/issues/3#issuecomment-917786598>,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AIBSMEEJTH3NQLZXSKJSRSTUBVOXLANCNFSM47Q2NWTA
.
Triage notifications on the go with GitHub Mobile for iOS
<
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
<
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sandroklippel/cbers4a/issues/3#issuecomment-918257553,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIJMBUS75SR2WW25XI42UYDUBYD2HANCNFSM47Q2NWTA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Cell Output Width

Suggestion to allow the user to set cell output width - especially on large monitors, a lot of space is wasted by having printed output wrap to the next line after a mere 70-something characters.

It sounds like you want to ensure that tables with a large number of columns don't get broken onto a new row? Does configuring either pd.options.display.max_columns achieve what you want?

Brilliant, thank you very much. Apologies for the silly question.


feat(api/log)!: support paging on GetBuildLogs

Adds support for the page and per_page query parameters for GetBuildLogs (endpoint /api/v1/repos/+/+/builds/+/logs).
BREAKING CHANGE: per_page default lowered to 10. Before this change it always returned 1 page with up to 100 logs. To maintain the same behavior, you must now use ?per_page=100.
This resolves an in-code TODO by copying the implementation from some of the other endpoints that already implement this.
I suspect that we're going to have quite a few more Log instances to iterate over if we implement something like https://github.com/go-vela/community/pull/771, so I figured I'd go ahead and resolve this while I was looking at this code.

FWIW - we can always hardcode the per_page on the CLI side to 100 for vela get log to reduce the impact


Exclude GPL hgal dependency

rdf4h is currently used in a data transformation toolkit called Dragon. We are preparing to release Dragon as open-source software, but have run into a snag with respect to the rdf4h dependency, which includes a transitive dependency on hgal. While rdf4h is BSD-licensed, hgal uses GPL v2, which unfortunately prevents its inclusion in Dragon.
I see that hgal is only needed for one isolated function in Data.RDF.Query (isGraphIsomorphic). If this function is not seen as essential, would it be possible to remove the hgal dependency in a future release of rdf4h?

HI @joshsh I've asked the hgal maintainer, who'd like to keep the GPL v2 license for that library.
One option therefore could be for me to create a gist, copy/pasting the isGraphIsomorphic function there with the GitHub page pointing to it if people want to compute RDF graph isomorphism using hgal. Then, remove the isGraphIsomorphic from the rdf4h library and the testsuite, along with the hgal dependency.

Thanks for checking, @robstewart57 . Yes, if you are willing to downgrade that function to a Gist and remove the dependency, that would allow me (and potentially others with license constraints) to proceed.

@joshsh OK, I've moved the isGraphIsomorphic function out to a gist, and I've removed hgal from the cabal file.
This is reflected in release 4.0.2.
Removing isGraphIsomorphic in the unit tests, instead relying on isIsomorphic, identified a small handful of Turtle and XML parser bugs in rdf4h, and I will fix these when I return in a couple of months.

I see the compile errors. Separate issue but do you know if there is a way I can ignore the errors when depending on rdf4h via Stack? Otherwise, I will still have to come up with an rdf4h alternative for our initial release.

For now, I have copied the sources I need into Dragon, with appropriate license information. When the build issues are resolved, I will remove these sources and restore the rdf4h dependency. Thanks.

@joshsh Compiler errors? There aren't any compiler errors in version 4.0.2 or git HEAD, as far as I'm aware?
What I referred to with:

identified a small handful of Turtle and XML parser bugs in rdf4h

Is some unit tests fail with stack test. stack build and stack install should compile fine.
Let me know if this isn't the case for you.

Now that you mention it, yes rdf4h 4.0.2 builds from source without any issues. The errors I encountered were due to dependency conflicts, and I was able to resolve them. I will issue a PR to remove hgal from rdf4h's stack.yaml, as FOSSA may notice it and flag it as a GPL dependency otherwise.

Thanks, I'll accept the PR once you've submitted it.
On Sat, 25 Jul 2020 at 22:50, Joshua Shinavier<EMAIL_ADDRESS>wrote:

Now that you mention it, yes rdf4h 4.0.2 builds from source without any
issues. The errors I encountered were due to dependency conflicts, and I
was able to resolve them. I will issue a PR to remove hgal from rdf4h's
stack.yaml, as FOSSA may notice it and flag it as a GPL dependency
otherwise.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/robstewart57/rdf4h/issues/93#issuecomment-663909672,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGDRVQDPVRC7MSB43PZF6LR5NHSLANCNFSM4O35ZM5A
.

Actually, FOSSA does not flag this. I guess it only has access to the .cabal file. There is no longer anything standing in the way of a release of Dragon with rdf4h. Thanks!

@joshsh I've removed it from stack.yaml anyway, since it is no longer needed.
https://github.com/robstewart57/rdf4h/commit/46cdc7e49068831cce890a6584e03b7eb5bad144


Add UNIX support

These changes enable Dungeon Quest to run on proper UNIXs like Mac, and improper UNIXs like Linux.

[x] Makefile to build dq3
[x] Workaround use of Microsoft-specific strcpy_s functions
[x] Implement UNIX compatible cls function

Next stop adding some CI/CD :)

Magnificent


[formrecognizer] Run black on code

API change check
API changes are not detected in this pull request.


s2n-tls: 1.4.3 -> 1.4.4

Description of changes
https://github.com/aws/s2n-tls/releases/tag/v1.4.4
The most interesting change is aws/s2n-tls#4352, which fixes the issue NixOS/nix#5947.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Pinging the maintainer: @orivej

It would be great to backport this to NixOS 23.11 to fix Nix working with S3 binary stores, but I'm not sure if such massive rebuild is OK for the release branch.

There is staging-23.11 for these situations.

Darwin builds in staging are broken due to #289254, #289294, I've successfully build Nix with this patch on master.

There is staging-23.11 for these situations.

Thanks, I figured that out, was carried away with staging problems on Darwin I mentioned earlier. Will test if Nix builds with the new version in 23.11 and will open separate PR (it does not backport automatically due to versions difference).

Created #289328 for a backport (as a draft for now, because original PR should be merged first according to contributing guidelines).

Worth updating to 1.4.5? https://github.com/aws/s2n-tls/releases/tag/v1.4.5

Probably yes, I'm already building locally for aarch64-darwin, will push as soon as it builds successfully.

Bumped version to 1.4.5, built s2n-tls and s2n-tls.passthru.tests.nix successfully on aarch64-darwin.
FYI I was unable to build rustc on current staging with sandbox enabled, but it is not because of my changes.

All other default systems building this package and its tests successfully too.

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


Stampede test script fails during autobuild (verbs)

Original issue: https://charm.cs.illinois.edu/redmine/issues/1392

Testrun script used in autobuild uses charmrun that isn't allowed to run on a login node.
../../bin/testrun  +p4 ./check 4 ++timeout 180 +isomalloc_sync
To access the system:

If not using ssh-keys, please enter your TACC password at the password prompt
At the TACC Token prompt, enter your 6-digit code followed by .

Authenticated with partial success.
Probable Fix:
The fix would require modifying charmrun to support job submission (to a compute node) and then launching the executable with "./charmrun +p1 ++mpiexec ++remote-shell 'ibrun -o 0' ./executable".

Original date: 2017-02-08 01:59:25

Fixed the 'src/scripts/testrun' script used by verbs autobuild to run jobs on stampede.
Fix included modifying the script to submit a job and waiting for it until it completes or until it hangs. The script is similar to the charmrun used by the gni layer (gni/charmrun)
Fix: ~~https://charm.cs.illinois.edu/gerrit/#/c/2222/~~ https://github.com/UIUC-PPL/charm/commit/8e8bbf2105e27d2e2f9b81fbbfee691e912cdec1

Original date: 2017-04-04 18:17:15

This would seem to have been dealt with, given that autobuild runs on Stampede pass. Please close if that's correct, and possibly link to any code change that was involved.

Original date: 2017-04-11 17:48:29

It was decided to not modify testrun (or charmrun) and keep it platform agnostic. The fix involved making changes to the instead_test.sh script that is used for launching Charm++ tests in nightly build runs on Stampede. The change has been committed in the autobuild repository. (https://charm.cs.illinois.edu/gerrit/#/admin/projects/autobuild)


Quick-Fix missing deprecated parameters

Since deprecated parameters was removed on master branch of keystone dependent modules,
puppetlabs-openstack still using removed parameters.
Changes was made to switch from "master" to "5.0.0" for :

keystone
swift
glance
cinder
neutron
nova
heat
ceilometer
horizon
openstacklib
tempest

I've created a stable/juno branch for this module which pins those modules to their stable/juno branches. Will continue to have master track the upstream master branches and fix the deprecation parameters in another commit.


NaN values don't get skipped on groupby aggregations.

Hello, maybe I'm missing something but groupby aggregations behave inconsistently with DataFrame aggregations, which is a challenge since setting NaN values to a default like 0 behaves differently depending on the aggregations.
I will explore using .apply to work around this as mentioned in https://github.com/javascriptdata/danfojs/issues/187#issuecomment-827531989
To Reproduce
const testDf = new dfd.DataFrame({ group: ['A', 'A'], val1: [1, NaN], val2: [2, 3] });
testDf.groupby(['group']).mean().print();

results in val1_mean being NaN. I.e.
╔════════════╤═══════════════════╤═══════════════════╤═══════════════════╗
║            │ group             │ val1_mean         │ val2_mean         ║
╟────────────┼───────────────────┼───────────────────┼───────────────────╢
║ 0          │ A                 │ NaN               │ 2.5               ║
╚════════════╧═══════════════════╧═══════════════════╧═══════════════════╝

Expected behavior
To aggregate like:
testDf.loc({ columns: ['val1', 'val2'] }).mean({ axis: 0 }).print();

i.e.
╔══════╤═════╗
║ val1 │ 1   ║
╟──────┼─────╢
║ val2 │ 2.5 ║
╚══════╧═════╝

The current behaviour I think is fine. Pandas does give an dropna option. It could be implemented, so the behaviour could be extended to this:
testDf.groupby(['group'], { dropna: true }).mean().print();
// ╔════════════╤═══════════════════╤═══════════════════╤═══════════════════╗
// ║            │ group             │ val1_mean         │ val2_mean         ║
// ╟────────────┼───────────────────┼───────────────────┼───────────────────╢
// ║ 0          │ A                 │ 1.0               │ 2.5               ║
// ╚════════════╧═══════════════════╧═══════════════════╧═══════════════════╝

I don't know is something like that would be what you need.
Anyway, why do you say that groupby aggregations behave inconsistently? Can you give another example with a inconsistent result?

Ah sorry, I copy-pasted my code poorly into the expected example, I've updated it. What I mean is that.
testDf.loc({ columns: ['val1', 'val2'] }).mean({ axis: 0 }).print();

Will drop NaN but
testDf.groupby(['group']).mean().print();

will not. The challenge is that if I need to do something like:
agg({
  installs: ['sum'],
  value: ['mean', 'sum']
});

Different columns can have NaN on different rows, and it seems like dropna() will drop rows or columns if there's a NaN in any position, while to be able to use agg it would need to cover the values only on the column being aggregated.
Does this make sense?

In pandas:
import pandas as pd

d = {'group': ['A', 'A'], 'col1': [1, None], 'col2': [2, 3]}
df = pd.DataFrame(data=d)
df.groupby(['group']).mean()
df.groupby(['group']).agg({
  'col1': ['mean'],
  'col2': ['mean']
})

Both mean and agg here skips None values by default.
Repl: https://replit.com/@kitsunde/pandas-none-handling-in-groupby

@kitsunde Did you figure out a way around this? I'm facing the same issue.


"Manage branches" doesn't respond when there's only one branch

Maybe a popup notification?

The issue was with how we were accessing resources (we were referencing the incorrect directory, since our "resources" folder was already set).
Now fixed in develop.


Feature request: implement parser decorator

Use case
Similar to middy middleware we want to use build-in schemas and envelopes to parse and extract events using decorators.
Solution/User Experience
Based on the RFC the decorator should take model and envelope as an param object:
const order = z.object({
  id: z.number(),
  description: z.string(),
});

type Order = z.infer<typeof order>;

class Lambda implements LambdaInterface {
  // Decorate your handler class method
  @logger.injectLambdaContext()
  @parser({eventBridgeEnvelope, order})
  public async handler(
    _event: OrderModel,
    _context: Context
  ): Promise<void> {
    logger.info(`Received order model ${_event}`);
  }
}

we should also be able to pass only the model, which can be a custom event or an extension of the built-in schema i.e.
const order = z.object({
  id: z.number(),
  description: z.string(),
});

const customEBschema = EventBridgeSchema.extend({
  detail: order,
});

Alternative solutions
No response
Acknowledgment

[X] This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
[ ] Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers
Please react with 👍 and your use case to help us understand customer demand.

This is now released under v2.1.0 version!


Microsoft Identity Conference Videos

I just learned of a great set of videos on YouTube from the MSFT Identity Conference!
Can we get some link(s) to them in the documentation?
cc: @parakhj

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

ID: 245ef8a4-a811-19b7-676c-aa9b82e2126f
Version Independent ID: ad2ec743-2aa7-b3c7-3350-2986a78d7c90
Content: What is Azure Active Directory B2C?
Content Source: articles/active-directory-b2c/active-directory-b2c-overview.md
Service: active-directory
GitHub Login: @davidmu1
Microsoft Alias: davidmu

@spottedmahn Thanks for the feedback! I have assigned the issue to the author to investigate and update as appropriate.

Unfortunately, useful though the videos might be, we are limited on adding links in the articles on docs.microsoft.com. We are not allowed to add links to youtube videos. The videos must be hosted on the azure.microsoft.com Video Center.
#please-close

😱😱
Who created that policy?!
Ok, thanks for the response David

Hi @parakhj - can you upload a 2nd copy to the azure.microsoft.com Video Center?


Different types multibing

Is it possible to use multibinding for different types of arguments?:
Content="{c:Binding Path='\'Points: \' + Points'}"

where Points is int property.
It returns me error like:
Binding error: calc converter can't convert expression"Points"+{0}: Expression of type 'System.Int32' cannot be used for parameter of type 'System.Object' of method 'System.String Concat(System.Object, System.Object)'
WPF binding engine only takes the StringFormat property into account when the target property is of the String type. For properties of the Object type (like the BarStaticItem.Content property), the StringFormat property is ignored.
For instance this behavior in the standard Label control:
<Label Content="{Binding SomeProperty, StringFormat=This string will not be displayed}" />

Why I am looking may be there is some solution with your library.
Thanks.

Hi, arteny!
Thank you for detailed description of issue. Unfortunately currently there is no workaround for this problem, because calcBinding repeats standart binding behavior in all ways besides binding expression


Preact

3kb alternative to React
https://github.com/developit/preact
It makes sense to be using Preact over React for our use case. Definitely worth investing some time in this in the future.

Merged with WebPack


Zigbee snzb-02 sensors battery state no longer exists

Hi!
After updating hass(5.4->6.5), hacs(?? -1.12.4) and sonoff lan(2.4.2->2.4.6) there is no more battery state for zigbee sensors snzb-02. Reinstalled from master - no luck.

Hi!, I also have issues with battery states, then I found that I had to include the 'battery' option inside the 'sensors' field in my /configuration.yaml as follows:

Now I have all my Sonoff battery states

There is new name for attribute - battery_level
https://github.com/AlexxIT/SonoffLAN/releases/tag/v2.4.1


Uninstalling?

How do you uninstall it?

After I removed the binary and the conf files my gamepad isn't recognized at all

Well, I just had to reinstall my whole system to get my gamepads working again. Just a heads up: people normally include uninstall scripts with their software.

I'm using moltengamepad since 2016 and I should say it's a great peace of
software. Some lessons for you:
First, if you ask something, you should wait some time(not just 5 hours)
for an answer.
Second, you have to learn now to use Linux. Reinstall your operating system
is not a solution for a software issue.

On Aug 17, 2019 at 17:53, PeashyScript<EMAIL_ADDRESS>wrote:
Well, I just had to reinstall my whole system to get my gamepads working
again. Just a heads up: people normally include uninstall scripts with
their software.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jgeumlek/MoltenGamepad/issues/64?email_source=notifications&email_token=ABMHPB6AFPGNQMDA6EXAM2LQFBQNPA5CNFSM4IMPXUAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QTJGA#issuecomment-522269848,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMHPBZP3JGGW7RT4OBNHKLQFBQNPANCNFSM4IMPXUAA
.

Hello. Sorry for taking a few days to get to this.
It sounds like you solved your problem, but I still feel like responding.
This software is still not particularly user friendly, and expects you to have some understanding on how the install works. We provide two different installs, and leave it to you to decide the trade-offs.
I'd be surprised if the single user install caused problems. When MG is not running, the devices should be visible like normal. And we intentionally do not ship a systemd service file, since this option assumes you want to be directly controlling the application.
The system user install is more involved, and we are explicit about it hiding devices even when MG is not running.

However, I agree, we should have an uninstall script. It would be nice, and a good step for making this more readily consumable. Pull requests welcome.
In the mean time, the installation directory of this repo is very transparent. You can see exactly what files get placed by the install script. Every file additionally contains a comment at the top saying how it gets installed. And the relevant file paths are all near the beginning of the install script.
Just delete those files, and you should be good to go. (and likely, just removing the udev rules would suffice).
Sorry for whatever strife this software provided you.

Just gonna add this for people who might get here by googling and still don't know how to get back to using controllers normally.
Two most important things to do are:
sudo systemctl disable moltengamepad
sudo rm /etc/udev/rules.d/72-moltengamepad.rules

This will disable moltengamepad daemon, meaning it won't create virtual devices at start and remove udev rules, which will make regular devices available for normal user again.

Just gonna add this for people who might get here by googling and still don't know how to get back to using controllers normally. Two most important things to do are:
sudo systemctl disable moltengamepad
sudo rm /etc/udev/rules.d/72-moltengamepad.rules

This will disable moltengamepad daemon, meaning it won't create virtual devices at start and remove udev rules, which will make regular devices available for normal user again.

Thank you so much, im having the same issue and i was so scared this thread was gonna end with no more info than that guy reinstalling having worked. if its not in the readme it is indeed worth being there.

Just gonna add this for people who might get here by googling and still don't know how to get back to using controllers normally. Two most important things to do are:
sudo systemctl disable moltengamepad
sudo rm /etc/udev/rules.d/72-moltengamepad.rules

This will disable moltengamepad daemon, meaning it won't create virtual devices at start and remove udev rules, which will make regular devices available for normal user again.

Well, same as the guy above, thank you so much!


Move some constant arrays from data to text section

2 Arrays with constant data in uORB and the tunes library were marked as 'const T *' array, which means the data of the array was not actually const and thus landed in the data section (so in RAM instead of FLASH).
Reduces RAM usage by ~500 bytes.
@potaito fyi

@bkueng Awesome, thank you very much. How did you find it? :)

How did you find it? :)

I was looking at what needs how much space in the different ELF sections. For example you can look at the largest consumers in the data section with:
nm -C --print-size --size-sort --radix=d nuttx_px4fmu-v2_default.elf |grep -i ' d '

Thanks, I did not know that


Should we remove the be-database quickstarter?

It looks like a dummy quickstarter - the Dockerfile does not work, and the Jenkinsfile looks very old and probably does not work either.

@michaelsauter  - I believe we should fix it - so you can spinup a pgres easily ... (w/o catalog) .. thoughts?

@clemensutschig I agree that we should provide sth like this. However, the current state is quite broken, and I think to make it work properly, we need to change a few things. For example, we really should use a different OCP template that creates e.g. a PVC. Since other quickstarters also require some specialised OCP template, we need a general solution for this.
With this and the timeline for v1 in mind, I suggest we delete be-database for the v1 release, and bring it back later, but properly.

@michaelsauter  - I think we should fix it- otherwise you are bound to use catalog ...

@clemensutschig Sorry to bring this up one more time, but ... what exactly is the advantage of using the quickstarter over using the catalog? We used the catalog, and I think this fine to start with.

@michaelsauter- agreed then


CRUNCH-698: Inclusion of local patch for AVRO-2944

Fixes AVRO-2944 where Avro's static method for creating a DataFileReader instance can get stuck in an infinite loop while trying to read the 4 byte "magic" header of the file. More details can be found at CRUNCH-698.

LGTM-- thank you!


undeclare unused experimental feature which stops TF 1.3.0 from funct…

…ioning with this module

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
Have you signed the CLA already but the status is still pending? Recheck it.

@ksatirli would you be able to review/approve this PR please?


Return 404 in the API if the requested webhooks were not found

Should resolve first point of the issue https://github.com/go-gitea/gitea/issues/24574

@delvh I added a test. How can I test that it works?

We wait for the CI icons to turn green (except for giteabot/lgtm, that will only turn green with the second approval).
That's the easiest approach.

Otherwise, you can also try a local make test-backend or something like that.

Hi, @lunny @delvh, can we backport this bugfix to 1.19.X?

@GiteaBot Please send backport to v1.19

It'll do so on the next merge to main


Add mode to handle all transactions through the biggest winner

Per the tin

Hello @brianhang! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file src/game/repository.py:

Line 20:80: E501 line too long (142 > 79 characters)
Line 40:80: E501 line too long (126 > 79 characters)
Line 67:80: E501 line too long (167 > 79 characters)
Line 99:80: E501 line too long (144 > 79 characters)
Line 135:5: E722 do not use bare 'except'

In the file src/game/route.py:

Line 13:80: E501 line too long (90 > 79 characters)
Line 152:5: E722 do not use bare 'except'

In the file src/payout/settle.py:

Line 5:80: E501 line too long (88 > 79 characters)
Line 6:80: E501 line too long (96 > 79 characters)
Line 20:80: E501 line too long (116 > 79 characters)

In the file src/utils/biggest_winner.py:

Line 7:80: E501 line too long (80 > 79 characters)


Few Improvements

Hi schrepfler, I would like to do some improvements.

NPE Creating a new version (jiraRestClient is null)
Remove browse/${projectKey} from issueManagement URL to generate the rest client base url. Use ${projectKey} from issueManagement URL

Cheers
Fernando

This repository is not being maintained. Closing PR


HKG: detect LKAS message format

A lot of the platforms in this list we got rid of here: https://github.com/commaai/openpilot/pull/27323 are also in this list, so we can't merge many platforms until we auto-detect this list as well. It's not a 1-to-1 with the SEND_LFA cars, and I think that's correct (sadly).
Checked a few cars which didn't have the LFA message, but did have this different LKAS format.
Also checked the fwdCamera FW versions, thinking that the prescense of LKAS or MFC described this, but still nope. The Konas have LKAS in their FW versions, but use the new format. Then checked for all the cars with MFC in their FW version, but some use the old format.

Looks like this is the last list of HKG that's holding us up on merging platforms. Once this is merged, a lot more than https://github.com/commaai/openpilot/pull/27370 can be merged! Just need to figure out how to detect this.

Checked a few thousand random segments and of the common addresses for all cars, there are no bits on any bus to describe the format exactly, so I'll try to determine if we can combine the platforms another way.

There are two dongles of 80k segments that don't have this message when they should: 26e73a0e32642dc4 with HYUNDAI IONIQ ELECTRIC 2020 and 6bc5e4e66135831a with a HYUNDAI SONATA 2020. Might be valid exceptions, looking into it.

I'm also looking back at the LKAS11 message since I don't trust that every car for the platforms in the list is correct (we found some international cars didn't have the LFA message for example in the last PR). For each dongle id, these are the signals that change, so we shouldn't use them to detect this format:
# find constant signal values for each dongle id
non_constant_sigs = set()
for dongle, sigvals in sig_vals_per_dongle.items():
  for sig_name, vals in sigvals.items():
    if len(vals) > 1:
      non_constant_sigs.add(sig_name)

print(non_constant_sigs)
>>> {'CF_Lkas_LdwsRHWarning', 'CF_Lkas_FcwOpt_USM', 'CF_Lkas_HbaSysState', 'CF_Lkas_HbaLamp', 'CF_Lkas_SysWarning', 'CF_Lkas_FusionState', 'CF_Lkas_Unknown1', 'CF_Lkas_LdwsLHWarning', 'CF_Lkas_HbaOpt', 'CF_Lkas_LdwsOpt_USM', 'CF_Lkas_ActToi', 'CF_Lkas_LdwsSysState', 'CF_Lkas_FcwOpt', 'CF_Lkas_FcwSysState', 'CF_Lkas_LdwsActivemode'}

Still relevant?

Yes, but I haven't figured out how to detect it yet. Closing until I do