Consider changing order lines to a list

Currently, the lines field in the Order type is a connection. I think we should simplify this and change it to a simple graphene.List. I cannot imagine a situation where pagination of those lines should be necessary.
The query currently looks like this:
{
  order {
    id
    lines {
      edges {
        node {
          quantity
          productName
        }
      }
    }
  }
}

We could change it to:
{
  order {
    id
    lines {
      quantity
      productName
    }
  }
}

@maarcingebala Shall we proceed?

I think yes. @dominik-zeglen knows of few other nested connections that could be turned into lists, as we shouldn't ever paginate them in UI.


Fix load tests by increasing decline threshold

The load tests are flakey because we have a "payment declined" threshold
that triggers once the cart reaches $100. The most expensive product is
only $99.99 but with shipping cost it goes to $104.95
See https://github.com/microservices-demo/microservices-demo/issues/752
This PR increases this threshold to $105.

Coverage remained the same at 71.958% when pulling e2d6b7307bd82fb1158db9e0833c1f2970f042e4 on payment-cart-threshold into 791d88d890d9fc3eaeca2d295e8982d7075dede4 on master.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v2.6.27 to before v5.13.3",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5e3ca0ec76fce92daa4eed0d02de9c79b1fe3920",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d57fcab190b60f43046d5836c3c56114b4f50080"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "5e3ca0ec76fce92daa4eed0d02de9c79b1fe3920",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "d57fcab190b60f43046d5836c3c56114b4f50080",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "seq_buf: Fix overflow in seq_buf_putmem_hex()\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.13.3 by commit d57fcab190b60f43046d5836c3c56114b4f50080, it was introduced in version v2.6.27 by commit 5e3ca0ec76fce92daa4eed0d02de9c79b1fe3920. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001222


Allow Colors to be created from 3-digit hexadecimal codes

A Color can be created from a 6-digit hexadecimal code, either by FromHex or TryFromHex methods.
Support should be added for 3-digit hexadecimal codes.
eg. #09C which is the short version of #0099CC

Please upvote :+1: this issue if you are interested in it.

Great @TheMarteh, I'll be the reviewer/your buddy.  Don't hesitate to ask along the way.

Thanks a lot, @FrankRay78 . I've opened up PR https://github.com/spectreconsole/spectre.console/pull/1708 with the implemented changes.


version 8.8.8 has error

version 8.8.8 can't switch the language text, it has bug.
version 8.8.8 console.log(t)  :
[Function: fixedT] { lngs: null, ns: 'common', keyPrefix: undefined }
version 8.5.1 console.log(t) :
[Function: fixedT] { lngs: null, ns: 'common' }

Not sure I understand your point, can you elaborate?

@isaachinman So, here is the current flow. I have two pages in my fresh nextjs project index.js and login.js. Only for login page i have that locale in the right folder as you can see the screenshot below.

I get error that says "Default namespace not found at public/locales/en/common.json"

Question is, why this is necessary to include the common.json file in the en folder?
@skyboy2020 you can resolve it quickly via creating an empty common.json file.

@fazi8808 You do not, it just happens to be the default value for defaultNS. Please read the docs.


Keat current timestamp default tz aware 2

I've reverted a lot of the workaround in this implementation to instead utilize its own class. Once we add a proper configuration value this will be ready to merge.


Error

Traceback (most recent call last):
File "/usr/local/bin/dearmor", line 8, in
sys.exit(main_cli())
File "/usr/local/lib/python3.8/dist-packages/dearmor/main.py", line 51, in main_cli
dearmor_main(parser.parse_args().file)
File "/usr/local/lib/python3.8/dist-packages/dearmor/main.py", line 32, in dearmor_main
inject(child[0].pid, str(Path(file).parent / "Release" / "dearmor.dll"))
IndexError: list index out of range

Linux is not supported, the error is because deaemor failed to launch you program with python <your py file>
I don't actively work on it anymore, so there will be no linux support unless someone opens a merge request


Lighting showing through wall, Falador Rooftops

Describe the bug
You can see the interior lighting on the exterior of buildings. First noticed at Falador Rooftops, not sure if this is a larger issue.
To Reproduce
Steps to reproduce the behavior:

Go to Falador Rooftops
Look at buildings
...?
Profit

Expected behavior
The lighting should not bleed through the wall
Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

OS: Windows 10
RuneLite version: 1.8.6
Launcher version: 2.2.0

Additional context
Default Settings

This is noticeable on the Seers rooftop as well.

It happens everywhere, likely a limitation of the lighting system but definitely something being looked at. Creating light is a lot easier than determining what should block it.


STM32: Improve speed of uart async implementation

I am trying to use the UART async API on stm32f7. It works nicely up to about 460.8kbps, but above that I start loosing characters during buffer switch. I immediately provide new buffers when requested, and increasing the buffer size doesn't help. So this appears to happen when new data arrives before my RX handler is done.
Describe the solution you'd like
I currently have my own implementation of this (without UART async API) where I manually configure the STM32 DMA to use circular mode and set up interrupts on Half-transfer, Transfer Complete and UART RX IDLE. It can sustain data rates far above 1Mbps even with very small buffers.
So I would like the STM32 implementation of the UART async API to use either the circular mode or the double-buffer mode of the DMA peripheral (if available). Then DMA hardware would just continue to receive UART characters regardless of how long time I spend in my RX event handler.
Additional context
I'm on Zephyr v2.5.0

^^@Shlomow

We implemented our uart driver in the past with circular buffer before we used zephyr. It has some drawbacks. First, if you need hardware flow control then you have to control the rts line in software instead of hardware, and this is a little bit hard since the driver needs to know how much data the application has already read. In addition, if you want to implement the async api then you need to have a dedicated buffer in the driver, which consumes extra ram, and needs an extra memcpy from the uart driver to the application buffers.
In terms of speed, I actually think that the current implementation is better, since you need an extra handling of the flow control in each interrupt (idle, half transfer, full transfer).
As a principle, for high data rates we use hardware flow control and don't rely on driver real time issues.
The above is relevant only for the circular buffer implementation.
As you said, when the dma controller in st has double buffer mode or linked list mode (like mdma in h7) we can easily take advantage of that and the changes in the uart driver should be minor.
So to sum up, I think that the real enhancement is to dma-v1 driver, to support double buffer mode. This can be used also in i2s driver and everything that is "streaming" in its nature like adc, dac, uart, i2s, sai, etc.

@hjuul you mentioned enabling IRQ, you done it in application code or directly on zephyr-driver source,
if you don't mind can you share a snippet?

@manoj153 I did this in application code. I've scraped together some pieces of it below. As you can see it is a combination of Zephyr API and bare metal for the UART, bare metal for DMA and Zephyr API for interrupt handlers. I've since rewritten this to use Zephyr async uart API which is a lot easier, but also slower.
#define DMA_STREAM_MAP_TX DMA2_Stream7
#define DMA_STREAM_MAP_RX DMA2_Stream5
#define DMA_IRQ_TX DT_IRQ_BY_IDX(DMA_NODE_ID, 7, irq)
#define DMA_IRQ_TX_PRIORITY DT_IRQ_BY_IDX(DMA_NODE_ID, 7, priority)
#define DMA_IRQ_RX DT_IRQ_BY_IDX(DMA_NODE_ID, 5, irq)
#define DMA_IRQ_RX_PRIORITY DT_IRQ_BY_IDX(DMA_NODE_ID, 5, priority)

static int dma_init(void)
{
	/* Map DMA and UART register structs */
	DMA_TypeDef *dma = (DMA_TypeDef *)DMA_BASE_ADDR;
	DMA_Stream_TypeDef *stream_tx = DMA_STREAM_MAP_TX;
	DMA_Stream_TypeDef *stream_rx = DMA_STREAM_MAP_RX;
	USART_TypeDef *uart = (USART_TypeDef *)UART_BASE_ADDR;

	/* Enable DMA clock */
	const struct device *clk = device_get_binding(STM32_CLOCK_CONTROL_NAME);
	struct stm32_pclken pclken = {
		.bus = DT_CLOCKS_CELL(DMA_NODE_ID, bus),
		.enr = DT_CLOCKS_CELL(DMA_NODE_ID, bits),
	};

	if (0 != clock_control_on(clk, (clock_control_subsys_t *)&pclken)) {
		LOG_ERR("Failed to enable DMA clock");
		return -EIO;
	}

	/*  Verify initial status of DMA */
	ASSERT((stream_tx->CR & DMA_SxCR_EN) == 0, "DMA already enabled");
	ASSERT((stream_rx->CR & DMA_SxCR_EN) == 0, "DMA already enabled");
	ASSERT(dma->LISR == 0, "LISR not zero");
	ASSERT(dma->HISR == 0, "HISR not zero");

	/* Register interrupt service routine for TX and RX DMA streams */
	IRQ_CONNECT(DMA_IRQ_TX, DMA_IRQ_TX_PRIORITY, dma_irq_handler_tx, 0, 0);
	irq_enable(DMA_IRQ_TX);
	IRQ_CONNECT(DMA_IRQ_RX, DMA_IRQ_RX_PRIORITY, dma_irq_handler_rx, 0, 0);
	irq_enable(DMA_IRQ_RX);

	/*  Configure DMA tx stream, but do not enable it.
	   Circular mode disabled, interrupt on TC only. */
	stream_tx->PAR = (uint32_t) &(uart->TDR);
	stream_tx->M0AR = (uint32_t)dma_tx_src_buf;
	stream_tx->CR |= (DMA_CHANNEL_USART_TX << DMA_SxCR_CHSEL_Pos) |
			 (1 << DMA_SxCR_PL_Pos) | DMA_SxCR_MINC |
			 (1 << DMA_SxCR_DIR_Pos) | DMA_SxCR_TCIE |
			 DMA_SxCR_TEIE | DMA_SxCR_DMEIE;

	/*  Configure and enable DMA rx stream.
	   Circular mode, interrupts on HT and TC. */
	stream_rx->PAR = (uint32_t) &(uart->RDR);
	stream_rx->M0AR = (uint32_t)dma_rx_dest_buf;
	stream_rx->NDTR = DMA_RX_BUFFER_SIZE;
	stream_rx->CR |= (DMA_CHANNEL_USART_RX << DMA_SxCR_CHSEL_Pos |
			  (1 << DMA_SxCR_PL_Pos) | DMA_SxCR_MINC |
			  DMA_SxCR_CIRC | (0 << DMA_SxCR_DIR_Pos) |
			  DMA_SxCR_TCIE | DMA_SxCR_HTIE | DMA_SxCR_EN);

	/*  Give semaphore to indicate DMA ready */
	k_sem_give(&dma_tx_sem);

	return 0;
}

static int myinit(void)
{
	const struct device *uart_dev = NULL;
	int ret = 0;

	uart_dev = device_get_binding(UART_LABEL);
	struct uart_config cfg = {
		.baudrate = UART_BAUD_RATE,
		.parity = UART_CFG_PARITY_NONE,
		.stop_bits = UART_CFG_STOP_BITS_1,
		.data_bits = UART_CFG_DATA_BITS_8,
		.flow_ctrl = UART_CFG_FLOW_CTRL_NONE,
	};
	ret = uart_configure(uart_dev, &cfg);
	//...
	ret = dma_init();
	//...

	/* Configure UART to enable DMA on transmitter and receiver */
	USART_TypeDef *uart_inst = (USART_TypeDef *)UART_BASE_ADDR;
	uart_inst->CR3 |= USART_CR3_DMAT;
	uart_inst->CR3 |= USART_CR3_DMAR;

	/*  Enable interrupt on RX IDLE */
	uart_inst->ICR |= USART_ICR_IDLECF;
	uart_inst->CR1 |= USART_CR1_IDLEIE;
	while ((uart_inst->ISR & USART_ISR_IDLE) != 0) {
	}

	IRQ_CONNECT(UART_IRQ, UART_IRQ_PRIORITY, uart_irq_handler, 0, 0);
	irq_enable(UART_IRQ);

	return ret
}

What is the state of this issue?
Is somebody working on the double buffer mode?

@JonathanVanWin this is in our plans for this release if everything goes well (no excessive support requests aside), but not started so far. @FRASTM is out of office this week but will be back next week. You can sync with him at that time.

@FRASTM I would be happy to work together in order to make this work.
Should we continue communicating through this issue?
I already started checking what to do in order to improve the speed, so we should get in contact ASAP.

I too am facing the same problem.
I'm using STM32F105 on 0d42e7566693d23daf24fa6df335e5acfc15e984 (v2.6.0+), and got a customer requirement to support 1Mbps.
Using the async api and a basically empty RX handler, with the double buffer swapping, bytes start dropping beyond 57600 baud. A non-empty RX handler will make it not so much better than the interrupt driven mode.
This is too low for my application, and I may have to go down the out of tree driver path.
NB. No hardware flow control because of hw design constraints.

@JonathanVanWin, sorry for late reply. Now going back to double buffer circ. mode.
I have begun to change the dma driver in that way.
We can go on with stm32F1 serie.

Thanks, I have since then worked on it.
Got to 4MBaud with circular buffer, and software flow control. The buffer is given once to the driver, and then the read and write pointers are handled by the application. The async callback has now a new event to ask if it can continue writing, then lowers RTS.
I have written nice documentation about the software flow control handling, and can be added to a zephyr sample to show how to use the uart async circular buffer for 4 Mbaud.
This way we don't need to copy directly from buffer, because the read/write pointer handling.

Good !
my concern was on the right size of the dma_memory buffer. what should it be ?
I guess you have 2 buffers of the same size. Starting with buffer1, then in the irq, you switch to buffer2 by changing pointer. This is quite fast and then you are shiting new address by the adding buffer size. etc.
However the application has its own Rx buffer of its own size, so each double buffer is memcopy on its turn, to the application Rx buffer ?

I actually only use one buffer. Don't use the rx_buf_rsp API. Only use the buffer given to rx_enable.
Because I use circular DMA, I'm all the time reading from the uart data register, therefore we need to handle software flow control (also the stm32f411 has an errata with hardware fc that doesn't work properly if we brake the protocol).
Therefore I added to the uart bindings a new  member: gpios, to store the RTS pin, and leave the CTS to be handled by hardware.
So now there is a new event, that is called every time after rx_rdy that checks if can continue writing to buffer, and here comes the tricky part:
You need to handle the read and write pointers externally, and if first half and second half of buffer is empty, and then check if the dma can continue writing to the buffer (without overwriting unread data). Because it takes time to pull the RTS pin high (till you get to that moment, you have passed from the dma callback, to uart callback to user callback), you need to calculate that delay (e.g. use logic analyzer or test different values).
And here comes the question about how to choose the buffer size:
It must be two times the size of the bytes that would be written in that delay (that changes when you change baudrate, so higher baudrate means bigger buffer, because you get more bytes in the same gpio delay). I can explain more in depth all the reasoning, but because I've already a working version with also documentation about the buffer handling (very nice, with ASCII art to explain the pointers), I will probably open a pull request when I have time.
Also, once the RTS pin is pulled high, I start a  timer (the period is given in the Kconfig.stm32), and then starts sending events to user asking if can continue writing (read from buffer enough to not overwrite for next round).

Also, wanted to clarify, there is no need for external memcpy from application, that would be less convenient: because you have software flow control for RTS, and handle read write pointers, you can read from same buffer and process from there, and when you finished you can signal the driver.
We are testing the driver, and looks that for now it handles 4MBaud. Will do more stress testing, but I'm happy with the result.

For reader's information: No plan to implement this in STM32 driver before an UART API update is available.

@hjuul @cfriedt @shlomow @manoj153 @erwango
Title: Intermittent Data Loss in UART Async API on STM32H753ZI (Nucleo H753ZI)
Issue Description:

I am working with the STM32H753ZI (Nucleo H753ZI) board and using the UART asynchronous API provided by Zephyr. While I am able to receive data from the host, I am encountering an intermittent issue where the received data is not correctly processed. Occasionally, when reading the buffer to extract the packet, I observe that the data contains zeros, indicating a loss or misinterpretation of the received data.

Environment:
Board: STM32H753ZI (Nucleo H753ZI)
Zephyr Version: [3.5.0]
Toolchain: [default]
Followed Steps:

Set up UART to receive data asynchronously and enabling the seamless transfer
Enabling the callback
sent the data from the host pc to board
In the rx_rdy handler, copy the data to a ring buffer and signal a semaphore to notify a packet processing thread.
The packet processing thread then reads from this buffer.

Expected Behavior:
The data read from the buffer should be consistent and accurate, reflecting the data sent from the host.
Observed Behavior:
The received data intermittently contains zeros, suggesting data loss or corruption. This happens randomly; sometimes the data is received and processed successfully, but other times it fails. The issue persists even though I am using the volatile qualifier.

I am seeking assistance in understanding and resolving this intermittent data loss issue with the UART async API on the STM32H753ZI board. Any insights or suggestions to debug this problem would be greatly appreciated.

Title: Intermittent Data Loss in UART Async API on STM32H753ZI (Nucleo H753ZI

Please open a dedicated issue

@hjuul - is there a way you could also provide reproducibility information with a specific app or test in-tree?
E.g. west build -b <board> tests/drivers/uart/...

@cfriedt: Are you referring to my original issue or the issue recently posted by durgababu2010 in this same thread?
As for my original issue it's been almost three years since I reported it; I have worked around it and moved on. But it seems from the discussion here that this issue is very well understood and has already been reproduced.

@hjuul - is there a way you could also provide reproducibility information with a specific app or test in-tree?
E.g. west build -b <board> tests/drivers/uart/...

Intermittent Data Loss in UART Async API on STM32H753ZI (Nucleo H753ZI) ARM #67546
https://github.com/zephyrproject-rtos/zephyr/issues/67546

@hjuul Would you want to have a test to https://github.com/zephyrproject-rtos/zephyr/pull/80921 ?


test: Migrate some json tests to snapbox

What does this PR try to resolve?
This builds on assert-rs/snapbox#348 and is part of #14039.
Note: this also updates existing .is_jsonlines() usage to .is_json().against_jsonlines().
How should we test and review this PR?
Additional information

If this is the way to go, should we document how to assert JSON lines output?

I've updated the deprecation message but further documentation will be in a followup documentation PR related to all of #14039.  This is prep for that.

@bors r+
Thank you.

:pushpin: Commit 26d3e7b46eda7720e9439ba5c0f96befefa306c1 has been approved by weihanglo
It is now in the queue for this repository.

:lock: Merge conflict
This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.
How do I rebase?
Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

git checkout jsonlines (switch to your branch)
git fetch upstream master (retrieve the latest master)
git rebase upstream/master -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
git push self jsonlines --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.
Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.
Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging tests/testsuite/update.rs
Auto-merging tests/testsuite/features.rs
CONFLICT (content): Merge conflict in tests/testsuite/features.rs
Auto-merging Cargo.toml
Auto-merging Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@bors r+

:pushpin: Commit 3085b548ecbd7d29d40c6180609ea3c224bad857 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 3085b548ecbd7d29d40c6180609ea3c224bad857 with merge 9bda502d607c5c0e8d0f38e076203e501f6aa65f...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 9bda502d607c5c0e8d0f38e076203e501f6aa65f to master...


Stuck at created container after error message: WARN[0001] Failed to add conmon to cgroupfs sandbox cgroup: mkdir /sys/fs/cgroup/systemd/libpod_parent: permission denied

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description

Steps to reproduce the issue:

Install Centos 7.6 and then install packages through rpm:

conmon-1.12.0-12.dev.gitc4f232a.fc29.x86_64
runc-1.0.0-92.dev.gitc1b8c57.fc31.x86_64
slirp4netns-0.3.0-1.1.x86_64
podman-1.2.0-24.dev.git0458daf.fc31.x86_64
shadow-utils46-newxidmap-4.6-4.el7.x86_64 (Fork for newuid)

Enable user namespaces
cat < /etc/sysctl.d/51-rootless.conf
user.max_user_namespaces = 15076
EOT
sysctl --system

Add users to subuid  subgid
cat < /etc/subuid
testaccount:100000:65536
EOT
cp /etc/subuid subgid -y

Login to testaccount and start NGINX container:
testaccount: podman --log-level run -d -p 80 nginx

Describe the results you received:
[testaccount@centos76 ~]$ podman --log-level=debug run -d -p 80 nginx
INFO[0000] running as rootless
DEBU[0000] Initializing boltdb state at /home/testaccount/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver vfs
DEBU[0000] Using graph root /home/testaccount/.local/share/containers/storage
DEBU[0000] Using run root /tmp/1000
DEBU[0000] Using static dir /home/testaccount/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/testaccount/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] Not configuring container store
DEBU[0000] Using slirp4netns netmode
INFO[0000] running as rootless
DEBU[0000] Initializing boltdb state at /home/testaccount/.local/share/containers/storage/libpod/bolt_state.db
DEBU[0000] Using graph driver vfs
DEBU[0000] Using graph root /home/testaccount/.local/share/containers/storage
DEBU[0000] Using run root /tmp/1000
DEBU[0000] Using static dir /home/testaccount/.local/share/containers/storage/libpod
DEBU[0000] Using tmp dir /run/user/1000/libpod/tmp
DEBU[0000] Using volume path /home/testaccount/.local/share/containers/storage/volumes
DEBU[0000] Set libpod namespace to ""
DEBU[0000] [graphdriver] trying provided driver "vfs"
DEBU[0000] parsed reference into "[vfs@/home/testaccount/.local/share/containers/storage+/tmp/1000]docker.io/library/nginx:latest"
DEBU[0000] parsed reference into "[vfs@/home/testaccount/.local/share/containers/storage+/tmp/1000]@27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] exporting opaque data as blob "sha256:27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] parsed reference into "[vfs@/home/testaccount/.local/share/containers/storage+/tmp/1000]@27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] exporting opaque data as blob "sha256:27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] parsed reference into "[vfs@/home/testaccount/.local/share/containers/storage+/tmp/1000]@27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] Using random host port 46076 with container port 80
DEBU[0000] Using slirp4netns netmode
DEBU[0000] Allocated lock 3 for container 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85
DEBU[0000] parsed reference into "[vfs@/home/testaccount/.local/share/containers/storage+/tmp/1000]@27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] exporting opaque data as blob "sha256:27a188018e1847b312022b02146bb7ac3da54e96fab838b7db9f102c8c3dd778"
DEBU[0000] created container "6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85"
DEBU[0000] container "6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85" has work directory "/home/testaccount/.local/share/containers/storage/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata"
DEBU[0000] container "6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85" has run directory "/tmp/1000/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata"
DEBU[0000] New container created "6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85"
DEBU[0000] container "6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85" has CgroupParent "/libpod_parent/libpod-6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85"
DEBU[0000] mounted container "6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85" at "/home/testaccount/.local/share/containers/storage/vfs/dir/5e062ba87328de82c498b2cc3692dbd27874ae5a2053d7a100bdc2d8ce300e35"
DEBU[0000] Created root filesystem for container 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85 at /home/testaccount/.local/share/containers/storage/vfs/dir/5e062ba87328de82c498b2cc3692dbd27874ae5a2053d7a100bdc2d8ce300e35
DEBU[0000] /etc/system-fips does not exist on host, not mounting FIPS mode secret
DEBU[0000] Created OCI spec for container 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85 at /home/testaccount/.local/share/containers/storage/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata/config.json
DEBU[0000] /usr/libexec/podman/conmon messages will be logged to syslog
DEBU[0000] running conmon: /usr/libexec/podman/conmon    args=[-c 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85 -u 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85 -r /usr/bin/runc -b /home/testaccount/.local/share/containers/storage/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata -p /tmp/1000/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata/pidfile -l /home/testaccount/.local/share/containers/storage/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata/ctr.log --exit-dir /run/user/1000/libpod/tmp/exits --conmon-pidfile /home/testaccount/.local/share/containers/storage/vfs-containers/6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/testaccount/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /tmp/1000 --exit-command-arg --log-level --exit-command-arg debug --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/user/1000/libpod/tmp --exit-command-arg --runtime --exit-command-arg runc --exit-command-arg --storage-driver --exit-command-arg vfs --exit-command-arg container --exit-command-arg cleanup --exit-command-arg 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85 --socket-dir-path /run/user/1000/libpod/tmp/socket --log-level debug --syslog]
WARN[0000] Failed to add conmon to cgroupfs sandbox cgroup: mkdir /sys/fs/cgroup/systemd/libpod_parent: permission denied
DEBU[0000] Received container pid: 3984
DEBU[0000] Created container 6dbd08b69aa189466ff8f248e20ca7efb55caf751fec6eef1e16c300548cbf85 in OCI runtime
It hangs till I cancel the command. I've used multiple releases of Podman, Slirp4netns, Conmon, and Runc.
Describe the results you expected:
Expected a working container with portmapping.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
podman version 1.2.0-dev

Output of podman info --debug:
podman info --debug
debug:
  compiler: gc
  git commit: ""
  go version: go1.12.1
  podman version: 1.2.0-dev
host:
  BuildahVersion: 1.8-dev
  Conmon:
    package: podman-1.2.0-24.dev.git0458daf.fc31.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 96168e342b58efb8f50a050aa22700ac59854f0e'
  Distribution:
    distribution: '"centos"'
    version: "7"
  MemFree:<PHONE_NUMBER>
  MemTotal:<PHONE_NUMBER>
  OCIRuntime:
    package: runc-1.0.0-92.dev.gitc1b8c57.fc31.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc7+dev
      commit: 82c0db510c11ff6ea97d86b5a4f441d8b5376a84
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 1
  hostname: centos76.michiel
  kernel: 3.10.0-957.12.1.el7.x86_64
  os: linux
  rootless: true
  uptime: 46m 3.17s
insecure registries:
  registries: []
registries:
  registries:
  - registry.access.redhat.com
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.centos.org
store:
  ConfigFile: /home/testaccount/.config/containers/storage.conf
  ContainerStore:
    number: 51
  GraphDriverName: vfs
  GraphOptions: null
  GraphRoot: /home/testaccount/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 1
  RunRoot: /tmp/1000
  VolumePath: /home/testaccount/.local/share/containers/storage/volumes

Additional environment details (AWS, VirtualBox, physical, etc.):

Running on a Proxmox cluster.
Centos 7.6 (latest)
4GB RAM
32GB HDD

Have the same issue on Fedora 30, but not on Fedora 29.
If I disable selinux, everything works well.
Could you please take a look? Thank you so much.
podman version
Version:            1.2.0
RemoteAPI Version:  1
Go Version:         go1.12
OS/Arch:            linux/amd64

podman info --debug
ebug:
  compiler: gc
  git commit: ""
  go version: go1.12
  podman version: 1.2.0
host:
  BuildahVersion: 1.7.2
  Conmon:
    package: podman-1.2.0-2.git3bd528e.fc30.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: a13eadcaf0f07ba590c96d845a03ac3a0da7c56d'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree:<PHONE_NUMBER>
  MemTotal:<PHONE_NUMBER>6
  OCIRuntime:
    package: runc-1.0.0-92.dev.gitc1b8c57.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc7+dev
      commit: d38f8a2d00ff444e52d16ab1ea5bbe5c1cb471e8
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 8
  hostname: test.redhat.com
  kernel: 5.0.11-300.fc30.x86_64
  os: linux
  rootless: true
  uptime: 48h 17m 35.57s (Approximately 2.00 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/test/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/test/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 13
  RunRoot: /run/user/1000
  VolumePath: /home/test/.local/share/containers/storage/volumes

The Failed to add conmon to cgroupfs sandbox line is harmless; we can continue without issue when it happens. I'd actually say it's entirely expected on rootless (we should probably disable actually attempting it in the rootless case).
From the Podman side, it seems like your container has been created and is running. I imagine that, if you hit it with a podman kill or podman stop from another terminal, it will probably stop the container (I'd be very interested in whether this works). The problem seems to be that the initial Podman process is not exiting.
The fact that this reproduces as both root and rootless is very concerning, though.

Hm. From the positioning of the hang, the cause could be starting the container. If runc hangs when we request that it starts the container, that would cause the command we see here.

@michielhemme can you temporarily disable SELinux and see if you see different results?
@henrywang Please check journalctl for any AVCs (they'd be formatted like audit[23984]: AVC avc:  denied  { write } for  pid=12345 in the logs) and paste them here, so we can tell what SELinux is blocking.

@michielhemme can you temporarily disable SELinux and see if you see different results?
@henrywang Please check journalctl for any AVCs (they'd be formatted like audit[23984]: AVC avc: denied { write } for pid=12345 in the logs) and paste them here, so we can tell what SELinux is blocking.

Tried it with SELinux, disabled, enforced, permissive. All resulting in a hang after started container (so when runc needs to take over).
Since Rhel8 released yesterday I will continue my research in that distro. Thanks for the help anyway.
I'll keep the installation on disk so If anyone else got a solution, I can try it out and people might find it useful in the future.

@michielhemme can you temporarily disable SELinux and see if you see different results?
@henrywang Please check journalctl for any AVCs (they'd be formatted like audit[23984]: AVC avc: denied { write } for pid=12345 in the logs) and paste them here, so we can tell what SELinux is blocking.

Thanks @mheon! Here's my AVC:
AVC avc:  denied  { map } for  pid=5713 comm="entry_point.sh" path="/usr/bin/env" dev="fuse" ino=1334900 scontext=system_u:system_r:container_t:s0:c112,c627 tcontext=system_u:object_r:fusefs_t:s0 tclass=file permissive=0
And my podman ps -a result:
CONTAINER ID  IMAGE                     COMMAND               CREATED        STATUS                      PORTS  NAMES
9ff5afa03103  docker.io/selenium/hub:3  /opt/bin/entry_po...  3 minutes ago  Exited (139) 3 minutes ago         selenium-hub

That is allowed in the current policy, which you indicate is installed.
Could you try
dnf reinstall container-selinux
And see if anything blows up?

Have the same issue on Fedora 30. This issue can be reproduced on both root and rootless user. If I disable selinux, everything works as before. Is there any selinux configure to cause this issue?
Could you please take a look? Thank you so much.
podman version
Version:            1.2.0
RemoteAPI Version:  1
Go Version:         go1.12
OS/Arch:            linux/amd64

podman info --debug
ebug:
  compiler: gc
  git commit: ""
  go version: go1.12
  podman version: 1.2.0
host:
  BuildahVersion: 1.7.2
  Conmon:
    package: podman-1.2.0-2.git3bd528e.fc30.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: a13eadcaf0f07ba590c96d845a03ac3a0da7c56d'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree:<PHONE_NUMBER>
  MemTotal:<PHONE_NUMBER>6
  OCIRuntime:
    package: runc-1.0.0-92.dev.gitc1b8c57.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc7+dev
      commit: d38f8a2d00ff444e52d16ab1ea5bbe5c1cb471e8
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 8
  hostname: test.redhat.com
  kernel: 5.0.11-300.fc30.x86_64
  os: linux
  rootless: true
  uptime: 48h 17m 35.57s (Approximately 2.00 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/test/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/test/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 13
  RunRoot: /run/user/1000
  VolumePath: /home/test/.local/share/containers/storage/volumes

Actually my issue isn't with root user. It works flawlessly on root. The only issue I got is that port binding causes this issue on rootless (I can start a container without port binding, but I can only use Podman if port binding works).
Since RHEL8 contains Podman V1.02-dev doesn't support rootless port bindings, I needed to install a newer RPM. So far I've tried:
Podman 1.3-dev
Podman 1.2
Podman 1.2-dev
Podman 1.12
I've also tried numerous versions of container-selinux, slirp4netns, and runc.

@rhatdan I was wondering if you could give any more insight in the release cycle of Podman within Red Hat 8? For example when will 1.12 arrive?

Currently we have to wait until RHEL8.1 to update container runtimes.  I am trying to change this.

@michielhemme What AVC's are you seeing on Fedora 30?
ausearch -m avc -ts recent

That is allowed in the current policy, which you indicate is installed.
Could you try
dnf reinstall container-selinux
And see if anything blows up?

@rhatdan, re-install container-selinux-2.100-1.git3b78187.fc30.noarchworks for me. Appreciate your help! Does that mean we always need re-install container-selinux when updating from Fedora 29 to 30? Thanks.

No, your the only one that I heard about this from.  Something went wrong when you were updating or installing.  I will be looking for similar issues, and hope that this was just your issue. :^)


Possible size optimization for fragments

Wait, you closed this because this wasn't any smaller than the original?!


Automatic import organisation inconsistent between type hints and action on save

Describe the bug
Ruff runs as an action on save, even if I don't tell it to. I literally have all boxes in the Ruff settings page unchecked. Worst of all, however, the context action for organizing imports, and the action on save disagree on the correct import formatting for the snippet:
from pathlib import Path
from typing import Any

import click
import matplotlib.pyplot as plt
import numpy as np

from my_package.utils import MyObject

With one suggesting a line between numpy and my_package imports while the other keeps removing the line. This only happens when I use top-level imports from my_package, i.e. the issue is resolved with from .utils import.
To Reproduce
Steps to reproduce the behavior:

Install ruff plugin
Deactivate all actions in the Settings>Tools>Ruff pane
Still get Ruff actions on save
Create a project structure where you import files from a top-level package
Actions on save and code annotations disagree

Expected behavior
When I turn off Run ruff on save and Run ruff when reformat code, Ruff should never run automatically to fix my code. Also, the action on save is incorrect in this case, I believe, in suggesting removing the line between imports from my_package and third party software. This should be fixed.
Screenshots
This is my ruff tool pane:

This is what the action on save formats it to (Ruff thinks this is wrong):

This is what it should look like:

Environments (please complete the following information):

IDE:  PyCharm Professional 2024.1.1
OS: Debian Bookworm 12.5
Ruff Version: 0.4.4
Plugin version: 0.0.33

Additional context
Add any other context about the problem here.

@KarimAED @koxudaxi this might be a duplicate of https://github.com/koxudaxi/ruff-pycharm-plugin/issues/422

Seems to be fixed in the most recent update of the plugin. Not sure whether this applies to your issue as well @hexvolt ?

@hexvolt not sure if we are encountering the exact same behaviour, but it might be a very similar issue.


I can't install tabnine for Atom 1.58

OS version: Win 10
Editor version: Atom 1.58.0 x64
Issue: Can't install
TabNine extension version: [3.0.3]

Issue Details: I got file log here:
2021-09-06T10_12_37_728Z-debug.log

gz#6118

Hi, can you try to follow the steps described in this Github issue at https://github.com/codota/tabnine-atom/issues/18#issuecomment-615429725 and reinstall it from scratch?
Thanks :)


Hyperlink error

[Enter feedback here]
"Power Management for Network Devices"  Hyperlink error, It will go to address (https://developer.microsoft.com/zh-cn/windows/hardware/)
Power Management for Network Devices

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

ID: 2bbc7ada-6164-e3d7-6a22-37cf93a370d6
Version Independent ID: e937b012-a3ac-c1e8-8394-d5731e01ff37
Content: About Network Wake-Up Events - Windows drivers
Content Source: windows-driver-docs-pr/network/network-wake-up-events.md
Product: windows-hardware
Technology: network
GitHub Login: @aviviano
Microsoft Alias: amvivian

Hi @Siliva-li,
Thanks for opening this issue. The topic link you mention has been deprecated, so we removed the link.
For updated info, please see the pages under the following sections:
Power Management (NDIS 6.30)
NDIS Power Management Overview


CA rotation in Kong Mesh

Add info about CA rotation in the upcoming release of Kong Mesh.
This section will be enriched with screenshots and instructions on how the user can follow the process in Kong Mesh GUI, but only after we have that GUI (not in this release).

@jakubdyszkiewicz I pulled down and copyedited directly bc it's faster and ... well, release week. I did a minimal job in the interest of time, but also because I wanted to ask about a different approach. I understand the step-by-step guide model, and it can be useful (although much overused in general on this site), but it feels a bit like overkill here. The yaml is all dupe or near-dupe, and I wonder whether the same result could be achieved with smaller snippets and explanatory text instead of instructional text. BUT ... we're also running out of time, so probably best to :shipit: as is and rework later, if you agree. I'll approve as soon as you give me a 👍  here or on Slack.


mono observer.exe command throwing exception on Mac

mono observer.exe
command throwing below exception:
Unhandled Exception:
System.Net.Sockets.SocketException (0x80004005): Could not resolve host 'MAC-106'
at System.Net.Dns.Error_11001 (System.String hostName) [0x00015] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Net.Dns.GetHostByName (System.String hostName) [0x00021] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Net.Dns.GetHostEntry (System.String hostNameOrAddress) [0x00052] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at Xamarin.Forms.HotReload.Observer.FileObserver.Run () [0x00005] in :0
at Xamarin.Forms.HotReload.Observer.FileObserver.Main () [0x00000] in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.Net.Sockets.SocketException (0x80004005): Could not resolve host 'MAC-106'
at System.Net.Dns.Error_11001 (System.String hostName) [0x00015] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Net.Dns.GetHostByName (System.String hostName) [0x00021] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at System.Net.Dns.GetHostEntry (System.String hostNameOrAddress) [0x00052] in <81ba78c8dc794b7f9f7b530c53db0f84>:0
at Xamarin.Forms.HotReload.Observer.FileObserver.Run () [0x00005] in :0
at Xamarin.Forms.HotReload.Observer.FileObserver.Main () [0x00000] in :0

Hi @pdamco
Are you working in virtual machine?
try please next
mono observer.exe u=http://<IP_ADDRESS>:8000

Wait for your feedback

@AndreiMisiukevich  Getting same exception.

@pdamco ok, i will add try - catch
Thanks for your feedback. I'm going to refactor it on this weekend :)

@pdamco do you use Mojave, right?
I have started to experience the same issue after updating from high sierra to mojave :)

@pdamco hey, try 1.0.5 with new observer


added documentation for ng2-tweet

Great package, I want it to be easier for others to implement with these instructions :)

Remove(not needed):
Add to your desired component, in this case home.component.ts (Don't forget to add it to your constructor)

import { Ng2TweetService } from 'ng2-tweet/lib/index';

constructor(private ng2TweetService: Ng2TweetService) {

}


Fix argc, argv handling on NuttX

The output of px4_task_spawn() on NuttX is:
for the input of:
commander start

The output is: argc = 3, argv[0] = commander, argv[1] = commander, argv[2] = start
However, it should be:
argc = 2, argv[0] = commander, argv[1] = start

Fixed with a patch.


Rapidfuzz in Docker with Python 3.11

The ReadMe of this RapidFuzz repo says it requires Python 3.7 or later.
However, the pipenv command ran with a docker image with python 3.11 and fails to install rapidfuzz .
Do others have this issue as well when using rapidfuzz==1.9.1 and Python 3.11?

RapidFuzz 1.9.1 did not support Python 3.11 yet, since cython did require some changes to work on Python3.11. For this reason the first version with official support for Python 3.11 is version 2.4.4.


Make high-contrast mode less hacky for Monaco editor in IE and Edge

In our high contrast theme we are using clever CSS that sidesteps around style overrides IE and Edge do when Windows is in High Contrast Mode.
Fortunately, there's a single rule we can use in CSS now to stop IE 10+ and Edge from trying to modify our styles.
-ms-high-contrast-adjust: none
It overrides the browsers' default behavior to modify the styles to be more high-contrasty.  This means we can stop using hacks like ::after and ::before  elements to insert icons as non-background images (which would otherwise not be displayed as background images).
We need to test that this works well in Monaco and decide if we are ok only supporting IE 10+ as far as IE goes.
Provided we're all good, then let's replace all the hacks with natural solutions.
https://msdn.microsoft.com/en-us/library/hh771863(v=vs.85).aspx

@isidorn FYI - this is the task I'll work on once your change is in Master.  I'll put this on the June Milestone.

There is also the -ms-highcontrast: active media feature for a less sledge hammer approach to fixing up HC issues in IE/Edge. super useful with CSS system colours to match the user chosen HC colour settings.

@bgashler1 can you please give +1/-1 that we can use this solution? I would like to get rid of the hacks we have for HC theme to solve https://github.com/Microsoft/vscode/issues/8516
Imho it would be good to get rid of these special styles to clean up our CSS.

@bgashler1 I verified that this CSS tricks works in IE and Edge, so I think we can use it. However, since VS Code is only ever running in a Chrome environment I think this CSS rule is not needed (unless maybe for the standalone editor). To verify that I opened Code in HC mode on windows after my change:

In https://github.com/Microsoft/vscode/pull/9023 I have a change ready that just uses the dark-theme image when we are in hc-black theme. I noticed that the standalone editor already adopted this.

@bpasero yes, you're right that this is not an issue for Chrome.  It's only an issue in the stand-alone editor when running on IE and Edge.
So anything that is shared code with the stand-alone editor must use one of the techniques above or else all things displayed via background-image will be removed in high contrast mode on Windows.  It could really break the Monaco editor in Edge or IE on windows if high-contrast mode is enabled, because many icons would be missing.

@alexandrudima is there some CSS that only gets loaded in the standalone editor? If so, we should add the -ms-high-contrast-adjust: none there.
@bgashler1 note that for the release of the standalone editor, Alex was already removing all HC hacks, so the current version that is out is likely not working so well with HC mode on in Windows. However, I am not sure if this was reported already.

This one is only loaded in the standalone editor:
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/standalone/media/standalone-tokens.css#L1

Ok, so any CSS that is shared with the standalone editor that uses background images must have the -ms-high-contrast-adjust: none on the same rule that defines the background image or above in the DOM tree.  Anything with this rule, and all of its children, will then no longer lose its background images.

So, .monaco-editor { -ms-high-contrast-adjust: none } would do it ?

That would do it, essentially.  However, it's a "sledgehammer approach" to stop IE and Edge to mess with our styles.
If we do this, we should use JavaScript (or some other means, maybe we already are) to detect if Windows is in high-contrast mode and automatically apply the high-contrast theme.  Otherwise, Monaco editor will stand out like an ugly bright iframe anywhere it's used, as IE and Edge will convert the whole page except for things nested under .monaco-editor.

@bgashler1 Not sure why you assigned this to me

@bgashler1 We are not doing anything special w.r.t. to switching to hc-dark when Windows goes into high-contrast mode. We always said that is the responsibility of the embedders of the editor.

@alexandrudima feel free to move to August if the team would like (see my PR comment).  I'd love to have auto-recognition of high-contrast theme.  I think we can use a get CSS function to see if the -ms-high-contrast: active is present.  If so, we should default to the high-contrast theme.  This would benefit both web-embedded Monaco and in VS Code visually and accessibility-wise.

Moving to august since @alexandrudima is on vacation and this is monaco editor related which releases do not have to be tied to our vscode releases

PR merged. The automatic switching of the editor to the editor to hc-black and the automatic detection of the high contrast mode in IE/Edge will be tracked in #10576


Synthesized SourceFile creation doesn't respect value semantics

When creating two SourceFile objects with the same file name, the second one does not get an independent storage from the first one. This was confusing because the next time we initialize a source file, it might have a completely different content at the same file name / url as the old one.
I encountered an issue while writing tests for something that involved creating source files with specific names, and I reduced the problem to the following:
  func testUsingSourceFileWithSameName() {
    let source1 = SourceFile(synthesizedText: "type A{}", named: "example.hylo")
    XCTAssertEqual(source1.text, "type A{}")

    let source2 = SourceFile(synthesizedText: "type B{}", named: "example.hylo")
    XCTAssertEqual(source2.text, "type B{}") // XCTAssertEqual failed: ("type A{}") is not equal to ("type B{}") -
  }

The problem persists even if we are working within different test cases, which is particularly spooky and breaks value semantics.
  func test1UsingSourceFileWithSameName() {
    let source = SourceFile(synthesizedText: "type A{}", named: "example.hylo")
    XCTAssertEqual(source.text, "type A{}")
  }
  func test2UsingSourceFileWithSameName() {
    let source = SourceFile(synthesizedText: "type B{}", named: "example.hylo")
    XCTAssertEqual(source.text, "type B{}") // XCTAssertEqual failed: ("type A{}") is not equal to ("type B{}") -
  }

What were the design decisions behind creating a shared storage of source files? Is this a bug or intended behaviour? Can we maybe make this issue less likely to happen, e.g. only making a shared storage when the contents of the two source files equal?

It is intended behavior. The purpose of the shared storage is to avoid duplicating source contents while deserializing an AST loaded from disk.
Clearly the name of the file should be unique and your code is not upholding this requirement. There's no reason to give explicit names to synthetic files, though. If you look at the constructor you'll see that the default argument is a random UUID.

@tothambrus11 unless you have some objection we haven't considere, please close the issue.  Thanks.

Solved in https://github.com/hylo-lang/hylo/pull/1530 by removing the unnecessary parameter, so now the API is impossible to use wrong.


hpx::parallel::transform_reduce with non const reference as lambda parameter

Expected Behavior
hpx::parallel::transform_reduce should compile with non const reference parameter in lambda function as convert operation.
Actual Behavior
See: https://stackoverflow.com/questions/54504021/hpx-transform-reduce/54508775#54508775
hpx::parallel::transform_reduce doesn't compile with the following error message:
hpx.cpp: In function ‘int main()’:
hpx.cpp:24:74: error: no matching function for call to ‘transform_reduce(const hpx::parallel::execution::parallel_policy&, std::vector<A>::iterator, std::vector<A>::iterator, double, main()::<lambda(double, double)>, main()::<lambda(A&)>)’
                       [](A& a_ref) -> double { return a_ref.residual(); });

(note:   template argument deduction/substitution failed)

Steps to Reproduce the Problem
#include <hpx/hpx_main.hpp>
#include <hpx/hpx.hpp>
#include <hpx/include/parallel_transform_reduce.hpp>
#include <hpx/include/iostreams.hpp>

#include <vector>

class A {
public:
  double residual() const {
    // Calculate actual local residual
    double i = 1.0;
    return i;
  }
};

int main() {

  std::vector<A> vec(300);
  double res = hpx::parallel::transform_reduce(hpx::parallel::execution::par,
                      vec.begin(), vec.end(),
                      0.,
                      [](double a, double b) -> double { return a + b; },
                      [](A& a_ref) -> double { return a_ref.residual(); });   // (1)

  hpx::cout << "residual: " << res << hpx::endl;

  return 0;
}

If you change (1) to
[](const A& a_ref) -> double { return a_ref.residual(); } or
[](A a_ref) -> double { return a_ref.residual(); } or
[](A* a_ref) -> double { return a_ref->residual(); }
it compiles.
Specifications

HPX Version: 1.2
Platform (compiler, OS): Linux MINT 18.3

N4687 (the last draft of C++17) says in 29.8.5 [transform.reduce]: "Neither unary_op nor binary_op shall invalidate subranges, or modify elements in the range [first, last]."
I will investigate why it is possible not possible to accept the element by reference, but I'd assume that's to avoid modifying it.

If you are not allowed to modify the elements why can you pass a normal pointer with compilation error?

If you are not allowed to modify the elements why can you pass a normal pointer without compilation error?

@arkantos493: that's a good question that needs investigation. Would it be sensible to allow a reduce operation on a sequence of pointers (their values)? I guess not.
The answer for now probably would be: we didn't think about plain pointers when implementing the algorithm :/


Catalog Labels are not aligned in the middle

Describe the bug
When opening the catalog and looking at a cluster with labels they are not aligned in the middle.

https://github.com/lensapp/lenscloud-lens-extension/pull/176 may be related


Javadoc build fix

Changes to fix 'site' build error related to 'findbugs' report in 'maven-project-info-reports-plugin'.
As a general rule, I try really hard not to require a 'mvn install', and instead to only require 'mvn package' - thereby ensuring only artifacts available to the current maven reactor are needed for a successful build. This approach exposes build dependency issues that can be hidden when 'mvn install' is a requirement to build. The good news is the only problems I saw related to such dependencies occurred during the 'mvn site' goal.
Therefore, I've also commented out some of the javadoc 'additionalDependencies' in some modules where that dependency would not yet be available in the build.
I added a temporary 'workaround' to not failOnError in the 'jgdms-platform' module because there were a number of actual javadoc errors (mostly in the unit test sources) that need to be addressed also.
Apologies if any of these changes are way off base from where you were headed. Please let me know of any adjustments you'd prefer.
If these changes are merged, should I next try to fix some of the javadoc errors in the 'jgdms-platform' module? I didn't want to conflate this PR with such changes, and was not sure if you wanted such additional divergence from River just for javadoc. I think once that module is fixed, the 'site' goal could be added to the travis build.
Another question: Did you have a URL in mind at which to publish the maven generated site for JGDMS?

Thanks for your help Dan :)  All contributions and ideas are welcome.  The gh-pages branch would be a good place to publish the Maven generated docs.   Any ideas on how to incorporate the "doc" directory as well?

I was wondering why the base pom.xml overrides the default site gen location from 'target/site' to '${basedir}/docs'? If there's no strong reason, I'm leaning towards setting it be the default 'target/site'.
After that, I could work on including/moving the 'doc' (no 's') folder content into a canonical 'src/site/' tree at the root project. That would make is pretty easy to include the 'doc' content in the generated maven site.
How does that sound?

Sounds good.
On 25/06/2017 11:50 AM, Dan Rollo wrote:

I was wondering why the base pom.xml overrides the default site gen
location from 'target/site' to '${basedir}/docs'? If there's no strong
reason, I'm leaning towards setting it be the default 'target/site'.
After that, I could work on including/moving the 'doc' (no 's') folder
content into a canonical 'src/site/' tree at the root project. That
would make is pretty easy to include the 'doc' content in the
generated maven site.
How does that sound?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/pfirmstone/JGDMS/pull/14#issuecomment-310876560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALFlMj0bNwZGDbEVagKZt7pz6A7d9wYaks5sHbz_gaJpZM4OEeVh.


Parse coalesced packets after keys of contained packet are discarded

I used quiche as QUIC client to contact a quic-go server.
The quic-go server sends an instant acknowledgment to the ClientHello, but then is slow to follow up the handshake and holds a large certificate.
Scenario:
The client correctly uses the estimated RTT to send probe packets in the form of Initials with PING frames.
Once the server continues to reply with the first batch of the Handshake packets (PKN: 0 and 1; Wireshark no 10, 11) after a long delay, these are acknowledged by quiche.
However, subsequent Handshake packets (PKN 2 and 3 of the server; Wireshark no 12, 14), are dropped by quiche.
Client log:
[2024-07-26T14:53:54.712689625Z TRACE quiche] 3f2d2ea78cab71732a6858b967c0293e3944b8dd dropped epoch 0 state
[2024-07-26T14:53:54.712960352Z TRACE quiche] 3f2d2ea78cab71732a6858b967c0293e3944b8dd dropped invalid packet
[2024-07-26T14:53:54.712977024Z TRACE quiche_apps::client] <IP_ADDRESS>:51097: processed 1252 bytes
[2024-07-26T14:53:54.712993775Z TRACE quiche_apps::client] <IP_ADDRESS>:51097: recv() would block
[2024-07-26T14:53:54.713008192Z TRACE quiche_apps::client] done reading
[2024-07-26T14:53:54.713065550Z TRACE quiche_apps::client] <IP_ADDRESS>:51097 -> <IP_ADDRESS>:443: done writing
[2024-07-26T14:53:54.713130532Z TRACE quiche_apps::client] <IP_ADDRESS>:51097: got 1252 bytes
[2024-07-26T14:53:54.713158474Z TRACE quiche] 3f2d2ea78cab71732a6858b967c0293e3944b8dd dropped invalid packet
[2024-07-26T14:53:54.713174544Z TRACE quiche_apps::client] <IP_ADDRESS>:51097: processed 1252 bytes
[2024-07-26T14:53:54.713191005Z TRACE quiche_apps::client] <IP_ADDRESS>:51097: recv() would block
[2024-07-26T14:53:54.713205362Z TRACE quiche_apps::client] done reading
[2024-07-26T14:53:54.713232112Z TRACE quiche_apps::client] <IP_ADDRESS>:51097 -> <IP_ADDRESS>:443: done writing
[2024-07-26T14:53:54.714669187Z TRACE quiche_apps::client] <IP_ADDRESS>:51097: got 1252 bytes

I believe the reason for dropping packets 12 and 14 is that they contain Initial ACKs, for which the keys have already been discarded (see client-server log: dropped epoch state).
quiche seems to drop the entire UDP datagram, which might contain additional QUIC packets.
Dropping the information requires an additional round trip, to detect and re-transmit the data (Wireshark no. 18, 20).

This can also be observed in Qlog. Here, the Handshake packets (PKN: 2 and 3) are missing.
Expected behavior:
Do not drop entire datagrams.
Since the header protection does not cover the long packet type and length fields, it should be possible to skip the contained Initial, but parse coalesced packets as long as the keys are available, which would render the client more efficient.
What do you think?
Attached is the pcap, qlog and client output.
quiche-coalesced-packets.pcapng.gz
client-3f2d2ea78cab71732a6858b967c0293e3944b8dd.qlog.gz
client-log.txt

<EMAIL_ADDRESS>


Fix libhwloc & stubgen versions to match dev yaml

Description

Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.

/merge


refactor: refactor middlewares

This PR includes some more minor changes to decrease the diff size of #293.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

17 of 22 (77.27%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 89.558%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/middlewares.js
16
21
76.19%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
1070

Relevant Lines:
1163

💛  - Coveralls


Update 2000-03-02-read-and-discuss.md

Hey Lydian.
When you upload images to your course repo, you need to prepended {{site.baseurl}} to the path for it to have the correct src when publishing the site.

I see the instructions on course in a box was missing this, it should be fixed now


question: accepting emergency numbers(3-4 digits) / trying to overwrite all the rules(using rules prop)

Description
I would to modify the validation in order to allow emergency numbers(3-4 digits) like:
Police: 117
Fire service: 118
Medical service: 144
I tried the rules prop but that seems to add extra validation on top of the one that is already provided.
Is there an workaround that would allow me to overwrite all the built in validation rules or a prop that would allow this type of numbers?
Expected Behavior
When passing the rules prop it should overwrite all the other validations
Actual Behavior
When rules prop is passed it simply adds extra rules on top of the built in ones
Steps to Reproduce the Problem

Try to enter a emergency number ex 117
Throws an error even if rules prop is overwritten

Specifications
Latest version

Hello @Techbinator,
You can disable built-in validation by passing a null invalidMessage property as follow:
<v-phone-input
  :invalid-message="null"
/>

However, using VPhoneInput for your current requirement may not be a good idea, as it will try to format the number to E164 according to the given country (e.g. +3318 with 18 input for France).

@Techbinator I will add a note on the default validation by-passing on README, feel free to reopen this issue if it is not resolved.


Support for additional content types besides CloudEvents, application/json and text/plain

The underlying transport framework, fastify only provides content type parsing for application/json and text/plain. We already have a content type parser for application/json+cloudevent, but if the event data is anything other than text of JSON, the request will fail.
We should use Fastify's catch-all content type handler to deal with this.

Depends on https://github.com/cloudevents/sdk-javascript/pull/368


[WIP] Display endpoint based on platform

Signed-off-by: metonymic-smokey<EMAIL_ADDRESS>Description
This PR displays endpoint on mesheryctl system start for both Docker and Kubernetes.
This PR fixes #2752
Screenshots

Docker:

Kubernetes

Signed commits

[x] Yes, I signed my commits.

@kumarabd this displays the endpoint URL on system start.
Anything more I could add to this?
Thanks!

@kumarabd this displays the endpoint URL on system start.
Anything more I could add to this?
Thanks!

This is it for kubernetes, for docker.. how is the endpoint discovered currently?

@metonymic-smokey, there’s unwanted duplicity in the messaged for Docker-based endpoint.

This is it for kubernetes, for docker.. how is the endpoint discovered currently?
@kumarabd , for Docker I use the endpoint directly from the config.yaml, as seen in the screenshot.

@metonymic-smokey, there’s unwanted duplicity in the messaged for Docker-based endpoint.

good point @leecalcote
I'll change the earlier deployment message accordingly. It has localhost:9081 hardcoded so that should be changed anyways.

@leecalcote I have removed the duplicity here.
Is this alright?
Thanks!

Thanks for updating. No, not quite. Let’s avoid two sentences and have just one. Ideally, their is not change in phrasing of what we have today, but the change is that the endpoint displayed has been vetted and is potentially updated based on endpoint discovery.

@metonymic-smokey, let's be as consistent as possible between the two outputs, ideally, using the same phrasing for both.

@leecalcote @kumarabd I just discovered that changing the endpoint in config.yaml when the platform is docker does not necessarily result in the endpoint getting shifted from localhost:9081 to the changed endpoint. I'll look into this and try to fix it as part of this PR.
Thanks!

@metonymic-smokey Gasp!

Related issue- https://github.com/layer5io/meshery/issues/2737

@kumarabd @leecalcote changing the port in meshery.yaml does the trick and I can now access Meshery UI on port 6081.
My approach to fixing this is:

Extract port from the endpoint URL in config.yaml.
Modify meshery.yaml to replace 9081 with the custom port.
Run as usual.

Please let me know if this approach is in the right direction.
Thanks!

@leecalcote with regard to consistent messaging, we could use this message for both platforms: "Opening Meshery in your browser. If Meshery does not open, please point your browser to $endpoint_URL to access Meshery".
To make this consistent, Kubernetes deployments will also have to navigate to the browser once Meshery is deployed, similar to  docker deployments This will also result in a consistent user experience for deployments across platforms.
Let me know if this is in the right direction.
Thanks!

@metonymic-smokey sounds good!

@kumarabd do I open the default endpoint for docker(localhost:9081) in the browser, in this PR? Or can I go ahead and try to modify the docker compose files?
Thanks!

@kumarabd I have implemented a draft version of the approach in my latest commit. Let me know what you think!
@leecalcote I have synchronised  the endpoint display messages and the user experience for both platforms. Let me know if there are any other changes needed!

@kumarabd I have implemented a draft version of the approach in my latest commit and Meshery UI can now be accessed on a custom port, based on config.yaml. Let me know what you think!
@leecalcote I have synchronised  the endpoint display messages and the user experience for both platforms. Let me know if there are any other changes needed!

Awesome , I'll check this out!

@leecalcote @kumarabd I have moved browser navigation to a function in helpers.go, which helps in abstracting all of that from start.go.
In the earlier format, there used to be a break if exec.LookPath failed in Linux. I'm not sure how to handle that here, so I've just returned the error there for the time being.  How should I handle that here? (I've marked it with a comment)
Thanks!

@navendu-pottekkat thanks for the review.
agreed it will be an inconsistent UX.
If we follow your approach, to decide whether the docker-compose file should be downloaded, would checking if it is present in the .meshery folder be a viable solution? Maybe also add a flag to download the latest docker-compose file?
@kumarabd @leecalcote which approach do you think would be more suited here?

@metonymic-smokey my call is, always pull from GitHub. Because in cases when we introduce new adapters or functionalities in docker-compose, it won't get updated because the older version already exists in .meshery. Although another approach, a better one would be to compare hash of downloaded and localfile and proceed futher, but I think it will introduce complexity. Your thoughts? @navendu-pottekkat @leecalcote

I think that we're not really ready for "cached" manifests and all of the considerations that come with them. We'll need a design specification to really address all of the concerns (e.g. provide user control over a mode: air-gapped vs. internet-connected, allow user to customize deployment manifests, but don't overwrite their customizations - the concept of extension points is missing (and we probably shouldn't have it, but implicitly do today), and a number of other concerns).
Such a design spec and consideration is not a priority now and won't be for the next 6 or more months. Our more immediate concerns are:

providing consistent UX
not allowing changes in one mesheryctl context to adversely affect another (constraining endpoint update to the current-context or to the context define in the global flag --config.
verifying that in fact Meshery endpoint is accessible.
that mesheryctl can both reach and authenticate to that endpoint
documenting in user-facing docs (docs.meshery.io in one of the Guides) when and what of users' customizations of manifests will be overwritten for both the docker and kubernetes platform.

example customization to docker manifest: the pinning of a giving Meshery Adapter to a specific image tag.

thanks @leecalcote @kumarabd !
so for this PR, should I hardcode localhost:9081 as the endpoint for docker and just display the endpoints, or should I change the baseURL of the endpoint and change config.yaml accordingly?

Thank you for committing to docs in 5. above, @metonymic-smokey. Is there logic included here that addresses 1. to 4.?

@leecalcote

I added the NavigateToBroswer function to provide consistent UX.
The only changes made in the config.yaml/meshery.yaml files are made for the current-context.
and 4. I believe this is done for Kubernetes, internally by the meshkitkube functions I'm using.
I'm not sure what these two points entail when docker is used.
I think I could use TcpCheck from meshkit utils once I'm a bit clearer on it.

Thanks!

@leecalcote added a draft of the endpoint accessibility check for docker deployments. I'm a bit unsure about it since I'm not too familiar with this utility. Could you please review it?
Much thanks!

Oh, very good. I'm tagging @piyushsingariya here to have a look as well.

sighs in relief I was so unsure of this last commit :P
On Tue, 4 May 2021, 23:57 Lee Calcote, @.***> wrote:

Oh, very good. I'm tagging @piyushsingariya
https://github.com/piyushsingariya here to have a look as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/layer5io/meshery/pull/2761#issuecomment-832151463,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALV2I56XPQNRIV43RUCP6ADTMA4BLANCNFSM43WXCIVQ
.

Good deal, @metonymic-smokey. I know this one has been a marathon, so I hate to suggest more changes.

Does this display the Operator status for Docker deployments?
the “Meshery Status...” line seems like an unnecessary line that can be removed.

Will this show status of the broker and MeshSync as well?

Good deal, @metonymic-smokey. I know this one has been a marathon, so I hate to suggest more changes.

Does this display the Operator status for Docker deployments?
the “Meshery Status...” line seems like an unnecessary line that can be removed.

@leecalcote

No, it does not since we are currently not applying operators when the platform is docker. There was a separate issue opened for this and I was assigned. Once a PR for that is merged, we could add this.
Alright, I have removed that line in my next commit.
Right now it does not, just displays pod status. I will add broker and meshsync status in my next commit.

Thanks!

@leecalcote removed the extra line.
The remaining points were part of a closed issue.
Let me know if there's anything more I can do @leecalcote @navendu-pottekkat .
Thanks!

Wow! What a PR this is. 😄 Way to stick with this one and see it through, @metonymic-smokey. Just fantastic.


Added libdivide

Hello @adbancroft. I see you have fixed the error reported by the bot. However, Library Manager works exclusively from Git tags, so the bot won't be able to see the fix you made until you create a new release or tag in the library repository.

That's what I figured, thanks for confirming.


mismatch for probabilistic risk - seismic risk index - absolute risk score / normalized risk score

Comparing risk profiler website and my postgis db (v1.4.3), the risk index scores do not match v1.4.3 version. Newest version has revised formula and score adjusted from 0 - 100.

Progress Log
Thu 2022-09-15:

@wkhchow shared his findings of risk score mismatch during RiskProfiler weekly meeting H7
@phil-evans confirmed that "those risk scores are indeed pulling from the selected feature properties in the vector tile".
@wkhchow filed this GitHub issue
@DamonU2 sent a Google Drive link to the two tile sets that he was able to complete previously to @anthonyfok to get the ball rolling:

psra_canada_expected_loss_500yr.zip (2022-07-20, 1.3 GiB, SHA256: 37325bf1172cc36479f524c3433fc9cf9dcfd7306fb0f6b538e805a9383729fc)
psra_indicators_csd.zip (2022-08-04, 2.67 GiB, SHA256: 440517aaaf1ae4474dba2b34a558d7ed4b6fce92d8d91ea4a6ed9588057c8d16)

@wkhchow got GeoServer installed and running on his Windows EC2 instance on AWS

Fri 2022-09-16:

@DamonU2 figured out how to run GeoServer natively on Windows, without Docker, thus the vector tiles are written directly to NTFS which is unencumbered by things like Linux ext4 inode limit
@DamonU2 met with @wkhchow (online video call) and walked through the procedure on installing the Vector Tiles Extension and configuring GeoServer for OpenDRR PSRA vector tile generation.
@wkhchow started generating psra_indicators_s vector tiles on his Windows EC2 instance and let it ran over the weekend.

Tue 2022-09-20:

@wkhchow reported success and provided a OneDrive link to psra_indicators_s vector tiles:

psra_indicators_s/EPSG_4326.7z (1.08 GiB, SHA256: 954c68d38e72adb955d48b8ae04daa673b9d1fd4ba7dd8c94f1d3fac9158616d)
psra_indicators_s/EPSG_900913.7z (987 MiB, SHA256: c21dd31ba4fe50c87cf39c1c58fb02eca0ed005d65c6aeff2e4bfc816b5f2cca)

Thu 2022-09-22:

@anthonyfok removed empty *.pbf files and recompressed them as .tar.xz (on SSD for speed, on btrfs filesystem to avoid ext4 inode limit) and sent the files to @arashmalekz:

psra_canada_expected_loss_500yr.tar.xz (82MiB, SHA256: 4fb0e1838ffce1eec8de8eafec8f6467de3d6f0ade647d716d8c499a4ed0f71f)
psra_indicators_csd.tar.xz (118 MiB, SHA256: 1c10531b4ba94a6d372043cca81fbbf2d004740732f228ee6c0a08cf940041cb)
psra_indicators_s.tar.xz (2.0 GiB, SHA256: c7ca22eed41be316e42b2f41d92df09a35f23d5fc64748addcfd0e3f43becc24)

@arashmalekz began uploading to AWS S3

Mon 2022-09-26

@arashmalekz reported the new vector tile caches files have been uploaded.

Tue 2022-09-27

@wkhchow checked the PSRA tiles on H7 work site and our beta site and confirmed that the correct normalized risk scores  are now displayed.

@wkhchow @drotheram I'll let you close this issue when ready.  :-)

Spot checked a few random areas and checked with above screenshot area on h7 work / beta site. Looks like this issue is now fixed.


Add dilation to dict key and rename internal function

This PR includes bugfix.
Rel #514

jenkins, test this please.

This PR is included by #3831

LGTM!


dlopened by "/vendor/lib64/egl/libGLES_mali.so" is not accessible for the namespace "sphal"

Hi, thanks for a great module - I have been searching for something similar for some time!
I am trying to load my own Frida gadget from here:  https://github.com/hzzheyang/strongR-frida-android
I am specifying it inside the new injected_libaries feature. However I think I am running into issues with some Android security & protection of usage of platform libraries. When attempting to inject the arm64 strongR frida gadget, I am met with the error msg:
dlopened by "/vendor/lib64/egl/libGLES_mali.so" is not accessible for the namespace "sphal"
I looked into attempting to add the gadget .so to public.libaries.txt but have had no success.

Hey,
I just tried using the strongR frida gadget and it works fine from my side.
Could you please provide more details on your setup?
Is this an issue only occuring with the strongR version or does it also happen with the normal/bundled frida gadget?
Where did you place the strong gadget file? (please also try to place it in the re.zyg.fri directory`)
Where did you see this error message?
Which android version/vendor are you using?

Is this an issue only occuring with the strongR version or does it also happen with the normal/bundled frida gadget?

This only seems to happen with the strongR frida gadget -- your bundled gadget works fine (but the app I am trying to circumvent uses libpairipcore.so -- so it is detected).

Which frida version are you using?

Latest at time of attempting, which was 16.1.3

Where did you place the strong gadget file? (please also try to place it in the re.zyg.fri directory`)

/data/local/tmp initially. I will try inside re.zyg.fri

Where did you see this error message?

Using adb logcat | grep ZygiskFrida

Which android version/vendor are you using?

Android 9.1. Device is a huawei honor 9 lite (LLD-L31) (EMUI)
Here are logs from ZygiskFrida:

08-15 16:19:51.055  6173  6173 I ZygiskFrida: App detected: com.wizzair.WizzAirApp
08-15 16:19:51.099  6173  6206 I ZygiskFrida: Wait for process to complete init
08-15 16:19:51.381  6173  6206 I ZygiskFrida: Process init completed
08-15 16:19:51.381  6173  6206 I ZygiskFrida: Injecting /data/local/tmp/re.zyg.fri/hluda-gadget-16.0.1-android-arm64.so
08-15 16:19:51.485  6173  6206 E ZygiskFrida: Failed to inject /data/local/tmp/re.zyg.fri/hluda-gadget-16.0.1-android-arm64.so : dlopen failed: library "/data/local/tmp/re.zyg.fri/hluda-gadget-16.0.1-android-arm64.so" needed or dlopened by "/vendor/lib64/egl/libGLES_mali.so" is not accessible for the namespace "sphal"

@lico-n I installed the attached version and everything is working correctly:

08-15 19:00:21.143  8247  8247 I ZygiskFrida: App detected: com.wizzair.WizzAirApp
08-15 19:00:21.149  8247  8254 I ZygiskFrida: Wait for process to complete init
08-15 19:00:21.368  8247  8254 I ZygiskFrida: Process init completed
08-15 19:00:21.368  8247  8254 I ZygiskFrida: Waiting for configured start up delay 30000ms
08-15 19:00:41.369  8247  8254 I ZygiskFrida: Injecting libs in 10 seconds
08-15 19:00:42.369  8247  8254 I ZygiskFrida: Injecting libs in 9 seconds
08-15 19:00:43.370  8247  8254 I ZygiskFrida: Injecting libs in 8 seconds
08-15 19:00:44.371  8247  8254 I ZygiskFrida: Injecting libs in 7 seconds
08-15 19:00:45.372  8247  8254 I ZygiskFrida: Injecting libs in 6 seconds
08-15 19:00:46.372  8247  8254 I ZygiskFrida: Injecting libs in 5 seconds
08-15 19:00:47.373  8247  8254 I ZygiskFrida: Injecting libs in 4 seconds
08-15 19:00:48.373  8247  8254 I ZygiskFrida: Injecting libs in 3 seconds
08-15 19:00:49.374  8247  8254 I ZygiskFrida: Injecting libs in 2 seconds
08-15 19:00:50.374  8247  8254 I ZygiskFrida: Injecting libs in 1 seconds
08-15 19:00:51.375  8247  8254 I ZygiskFrida: Injecting /data/local/tmp/re.zyg.fri/libgadget.so
08-15 19:01:37.620  8247  8254 I ZygiskFrida: Injected /data/local/tmp/re.zyg.fri/libgadget.so

Very strange... not sure what I messed up... but thank you for your assistance! 👍

No problem. Maybe as reference if you still want to figure things out for future versions, you can just take a look on how the module sets up the files.
Here I am setting the file permissions for the gadget.
https://github.com/lico-n/ZygiskFrida/blob/ee136d4fd19d70b972cbc45d03ba6d85052a6d01/template/magisk_module/customize.sh#L76
Here is the definition of set_perm_recursive.
https://github.com/topjohnwu/Magisk/blob/f86c66c99d165bee015c575057c02c7779170508/scripts/util_functions.sh#L568-L583
It consists of chown, chmod commands and setting the selinux context to u:object_r:system_file:s0 via chcon.


Amend yaml file for Cowley imaging conversion when files are complete

As sated in the title. Once the author uploads the remaining files the yaml file should be corrected.

Restored now.


Simplify npm scripts

Codecov Report

Merging #64 (8fa0202) into master (8e72b7c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #64   +/-   ##
=======================================
  Coverage   92.66%   92.66%
=======================================
  Files          23       23
  Lines         477      477
=======================================
  Hits          442      442
  Misses         35       35

Flag
Coverage Δ

ubuntu-latest-12
92.56% <ø> (ø)

ubuntu-latest-14
92.56% <ø> (ø)

windows-latest-12
92.47% <ø> (ø)

windows-latest-14
92.47% <ø> (ø)

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

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 b8356ed...8fa0202. Read the comment docs.


Fixed remote write alerts for RHOBS

Added Regex to enable both whitelisted alerts and metrics for remote write
Signed-off-by: Kaustav Majumder<EMAIL_ADDRESS>

@ezio-auditore Do we need changes to tests or addtional testß to cover the new use case?
Currently in the deployer we don't have tests for utils, as for the new use case , I am working on a PR which seperates the metrics required for provider and consumers, I think it makes more sense adding a test with that.
If you still feel we need a test for this, I am happy to add them with this.

I am not talking about tests for utils. Just to argument the tests for the Prom CR to verify that according to input the correct output is being generated (for example the correct selector)

I am not talking about tests for utils. Just to argument the tests for the Prom CR to verify that according to input the correct output is being generated (for example the correct selector)

Ok, makes sense. I will add those accordingly

Unit tests are passing in local
[kmajumde@fedora ocs-osd-deployer]$ make test
/home/kmajumde/work/git/ocs-osd-deployer/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
/home/kmajumde/work/git/ocs-osd-deployer/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
go fmt ./...
go vet ./...
KUBEBUILDER_ASSETS="/home/kmajumde/.local/share/kubebuilder-envtest/k8s/1.23.3-linux-amd64" DEPLOYMENT_TYPE=converged go test ./... -coverprofile cover.out
?       github.com/red-hat-storage/ocs-osd-deployer     [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/api/v1alpha1        [no test files]
ok      github.com/red-hat-storage/ocs-osd-deployer/controllers 84.911s coverage: 73.7% of statements
?       github.com/red-hat-storage/ocs-osd-deployer/readinessProbe      [no test files]
ok      github.com/red-hat-storage/ocs-osd-deployer/readinessProbe/readiness    7.942s  coverage: 73.3% of statements
?       github.com/red-hat-storage/ocs-osd-deployer/templates   [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/testutils   [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/utils       [no test files]
KUBEBUILDER_ASSETS="/home/kmajumde/.local/share/kubebuilder-envtest/k8s/1.23.3-linux-amd64" DEPLOYMENT_TYPE=provider go test ./... -coverprofile cover.out
?       github.com/red-hat-storage/ocs-osd-deployer     [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/api/v1alpha1        [no test files]
ok      github.com/red-hat-storage/ocs-osd-deployer/controllers 85.837s coverage: 74.2% of statements
?       github.com/red-hat-storage/ocs-osd-deployer/readinessProbe      [no test files]
ok      github.com/red-hat-storage/ocs-osd-deployer/readinessProbe/readiness    7.920s  coverage: 73.3% of statements
?       github.com/red-hat-storage/ocs-osd-deployer/templates   [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/testutils   [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/utils       [no test files]
KUBEBUILDER_ASSETS="/home/kmajumde/.local/share/kubebuilder-envtest/k8s/1.23.3-linux-amd64" DEPLOYMENT_TYPE=consumer go test ./... -coverprofile cover.out
?       github.com/red-hat-storage/ocs-osd-deployer     [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/api/v1alpha1        [no test files]
ok      github.com/red-hat-storage/ocs-osd-deployer/controllers 73.097s coverage: 72.8% of statements
?       github.com/red-hat-storage/ocs-osd-deployer/readinessProbe      [no test files]
ok      github.com/red-hat-storage/ocs-osd-deployer/readinessProbe/readiness    8.917s  coverage: 73.3% of statements
?       github.com/red-hat-storage/ocs-osd-deployer/templates   [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/testutils   [no test files]
?       github.com/red-hat-storage/ocs-osd-deployer/utils       [no test files]


Attempt to start a stopped server will fail with IllegalStateException

Resolves #377
Signed-off-by: Tomas Langer<EMAIL_ADDRESS>

Original behavior was to silently fail at starting the server.


Crash: SetWindowLongPtrW

Seems like f5b68e5dc1f9a49d595e5b93891635ea127d55ce caused:

2022/02/22 21:06:52 [FATAL] got panic: Failed to find SetWindowLongPtrW procedure in user32.dll: The specified procedure could not be found.

For some reason this only breaks on 32-Bit Windows...?
https://github.com/divVerent/aaaaxy/runs/5294825457?check_suite_focus=true

Looks like this a real diff between Win32 and Win64, solved by a #define in C:
https://groups.google.com/g/golang-nuts/c/pkmwc8k0DpU


Create Distinct type for Image, Repo, Tag, etc

Looking though the code, it may make sense to define distinct types for tags, image ids, etc. Something like:
let
   Tag = distinct string
   Repo = distinct string
   Image = distinct string
   ImagePath = distinct string
   ImageId = distinct string
   ...

proc `/`(path: string, image: ImageId): ImagePath = ...

Using this pattern of creating distinct types of strings would be easy to use, but allow the compiler to catch cases where "oops, a tag was used when I meant an image". There's a lot of places where various string types could likely get mixed up!
Distinct types would also help prevent a lot of potential security risks by adding known safe internal types from user input strings. Not sure how much of an issue this is currently, but personally I prefer to prevent certain classes of issues where it''s difficult to know if user input strings have been properly sanitized. For example, the repoUrl = fmt"..." type of things might need sanitizing using URLEncode (or the Nim equivalent) to prevent weird URL related issues (or just bugs...).
If you like the idea I might be able to create a PR for it at some point.

@elcritch
It looks like a good idea! PR is welcome!


How to Migrate from date-fns-tz

I am currently migrating our date handling implementation date-fns-tz to version 4.0 and need some guidance on how to adapt the code to the new API. Below is my old implementation:
import { enAU } from 'date-fns/locale';
import { formatInTimeZone } from 'date-fns-tz';
import { DEFAULT_DATE_FORMAT } from '@/constants';

const formatDate = (date: string | Date, dateFormat = DEFAULT_DATE_FORMAT): string => {
  const dateObject = typeof date === 'string' ? new Date(date) : date;

  return formatInTimeZone(dateObject, 'Australia/Sydney', dateFormat, { locale: enAU });
}

export default formatDate;

Question:
How can I adapt my existing implementation to the new API in 4.0? Specifically, I need to format dates using a specific time zone ('Australia/Sydney') and locale ('enAU'). Any advice or examples would be greatly appreciated!
Thank you!

@KieraDOG This is probably at least partially relevant: https://github.com/date-fns/date-fns/issues/3892


Types warning in (TS + React) CodeSandbox template

I hate to be the bearer of bad news but codesandbox might be using pnpm under the hood 😅
Bug is related to

[x] embla-carousel-docs

Embla Carousel version

8.0.0-rc19

Describe the bug

The generated (React + TS) codesandbox shows a warning it's not recognizing embla-carousel (see image below)

CodeSandbox Link
Steps to reproduce

Go to the predefined examples page
Click on "edit code" in any of the examples
Choose "React + Typescript" and create the sandbox
Open a file that's importing a type from embla-carousel package
See the TS warning like in the image above

Expected behavior

No TS warnings should exist.

codesandbox might be using pnpm under the hood

This is only a theory, I couldn't verify it.

@zaaakher thanks! Did you try creating a sandbox  locally and could verify that the problem went away 🙂?

Did you try creating a sandbox locally and could verify that the problem went away 🙂?

I just tested it locally and the problem is still there. I will investigate further

@zaaakher I’m pretty sure that CodeSandbox handles dependencies differently because if I spin up a new npm or yarn project locally and import the types from the core package when using the react wrapper, it just works.

Yup, that's why I assumed they're using pnpm under the hood.
They might have their own custom dependency resolution handlers that work similarly to pnpm

@zaaakher agree. Even pnpm works with the core package in devDependencies. I guess we have to add it to regular dependencies just for the CodeSandboxes then. Special case.


Update code sample Github link

Current docs are pointing at an older version of the ARM template that no longer works as intended. Master appears to have the correct appSettings required for the function app to run

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@WonderPanda : Thanks for your contribution to the Azure documentation! The author, @mattchenderson, has been notified to review your proposed change.

Looks good to me. Thanks for the contribution! #sign-off


Add aliasing for FB in-app browser on iOS, fixes #561

Changes identification of FB iOS browser from facebook/80.0.0 to ios_saf/9.3.0.
Note that Android already spawns the standard OS browser from the Facebook app.

What's the situation for Android FB in-app browser? Do we know?

@georgecrawford read the PR description :-)

I am right in thinking that this would stop the FB in-app browser being "unknown" yes? And would just be dealt with as and when and we wouldn't need &unknown=polyfill to cover it?


Contribute UseCase for Component Vault

Description
This contribution descibes the Workflow for setting up a Vault which can be used by each component to store its own secrets without having any security issues.
It is the last Canvas-Service Use-Case "CRUD secrets in a Canvas password vault" here: https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=233118152
We asked Hugo Vaugh, how to best contribute to this repository and said we should create a fork and the create a pull request.
We created a fork and would be happy about a review:
https://github.com/ferenc-hechler/oda-canvas/blob/master/usecase-library/UC0XX-Component-Vault.md

Looked at the existing documentation UseCase:
14: https://github.com/tmforum-oda/oda-canvas/blob/feature/78-use-case-secrets-management/usecase-library/UC014-Secrets-Management-JWT-based.md
The documentation is up to date and has no to be updated.


Samples reorganized

@HemantMahawar, I commented on everything I found.  I am done going through the docs


[CLOSED] Restrict allowed image hosts

 Issue by jamiecobbett
Wednesday 20 August 2014 at 16:22 GMT
Originally opened as https://github.com/alphagov/specialist-publisher/pull/232

This prevents images not hosted by us from being included in content on GOV.UK
by content editors or an attacker who has gained control of an editor's
account. Such images could be altered to something malicious (or a trollface)
at the whim of the website owner or an attacker who gains control of that
domain.
This is provided by version 19.0.0 of govuk_content_models.
See also: https://github.com/alphagov/publisher/pull/247 and https://github.com/alphagov/govuk_content_models/pull/220

jamiecobbett included the following code: https://github.com/alphagov/specialist-publisher/pull/232/commits

 Comment by bestie
Thursday 21 August 2014 at 09:38 GMT

So gov.uk will have to host a gif library then?


Jobs should return total_device_time as attribute

What is the expected behavior?
Jobs should return total_device_time when retrieved using backend.jobs(), e.g. job.total_device_time.  For jobs yet to be run, or currently running, this value could be included in the status check, with a successful or errored status (errors still have an on device time if error caught on device) including the device time so that it may be attached to the job.

Stale issue, closing


y'all had a deg when you meant arcsec in one of the statements

In the HD 209458 notebook the search query found the TIC object was 0.17 arcsec from the resolved coordinates for 209, but it was listed as deg in the notebook print statement.

@benmontet , please clear the output of the notebook.
@ceb8 , please review the unit correction.

Sure, no problem; I've removed the output from the notebook and re-pushed.

Seems correct, but @scfleming should look at it since it was his notebook originally.

@benmontet You are going to need to squash your commits to get rid of the noteboook output in the history. Directions here: https://github.com/spacetelescope/notebooks/blob/master/CONTRIBUTING.md#squashing-or-what-to-do-if-you-accidentally-committed-data

Confirmed, this was a mistake and should be fixed. Thanks @benmontet !

I love that "y'all" is in a PR title.  That is all.


Report Errors

I'm using on Next js
ReferenceError: window is not defined
at Object. (D:\source\fe-codebase\node_modules\react-hook-form-devtools\dist\react-hook-form-devtools.js:419:35)

littleStateMachine.setStorageType(window.localStorage);

aha good one, i forgot about SSR. will patch soon.

hey @hungnguyen1995 can you test out this beta version: 1.1.2-beta.1

hey @hungnguyen1995 can you test out this beta version: 1.1.2-beta.1

ok bro ! thanks u

i was checkout 1.1.2-beta.1


Move code guidelines from Zowe.org to the doc site

Move the code guidelines here https://zowe.org/code-guidelines/ to the Zowe doc site like what's done with the UI guidelines https://zowe.github.io/docs-site/latest/contribute/guidelines-ui/ui.html#clear.

I thought I'd work on this one since the UI guidelines just came over too.
I am curious though - what is the distinction between Contribute and Extend sections? To me they are really the same thing. As I look at these code guidelines/ui guidelines, they are quite relevant to developing new components, which is described in "Extending". The only outlier is really "Contributing to documentation", but I would argue that it would be OK to have that as part of Extending as well.
I think a single nav section would work for this - then we'd just have to decide on one name or the other "Contributing" or "Extending". I think that "Contributing" is the term that most people are familiar with in relation to open source software.
What do you think @nannanli ?


Upgrade to Bootstrap 4

Hi guys maybe we will create a branch and will trying to upgrade the theme to a new Bs. ?

@i198622 Если отталкиваться от этой статьи, выглядит не сложно. Но кто из тестеров будет согласен весь этот переезд обтестить? :)

After the discussion, we came to the conclusion that any changes in the topic related to changing Bootstrap would be meaningless to do without integrating the bootstrap as the source code.
But now the kernel does not support SASS for Bootstrap 4, or the new LESS syntax for Bootstrap 3.3.7
In the near future, we will not do this.


Compatibilities with new version 7.2.0

Description
I updated handsontable from 7.1.1 to 7.2.0 and after that I get a typescript error:
ERROR in<EMAIL_ADDRESS>3:80 Namespace 'Handsontable._editors' has no exported member 'Base'.
    1 | import Vue from 'vue';
    2 | import Handsontable from 'handsontable';
  > 3 | declare class BaseEditorComponent extends Vue implements Handsontable._editors.Base {
      |                                                                                ^
    4 |     name: string;
    5 |     instance: any;
    6 |     row: any;

ERROR in<EMAIL_ADDRESS>50:82 Namespace 'Handsontable._editors' has no exported member 'Base'.
    48 | declare type ClassMethods<T> = Pick<T, NotOriginalValueProp<T>>;
    49 | declare type ClassFields<T> = Pick<T, ClassFieldKey<T>>;
  > 50 | export interface BaseVueEditorMethods extends ClassMethods<Handsontable._editors.Base> {
       |                                                                                ^
    51 | }
    52 | export interface BaseVueEditorFields extends ClassFields<Handsontable._editors.Base> {
    53 | }

ERROR in<EMAIL_ADDRESS>52:80 Namespace 'Handsontable._editors' has no exported member 'Base'.
    50 | export interface BaseVueEditorMethods extends ClassMethods<Handsontable._editors.Base> {
    51 | }
  > 52 | export interface BaseVueEditorFields extends ClassFields<Handsontable._editors.Base> {
       |                                                                                ^
    53 | }
    54 | export {};
    55 |
Version: typescript 3.5.3

Steps to reproduce

Update Handsontable from 7.1.1 to 7.2.0

Your environment
"dependencies": {
        "@handsontable/vue": "4.1.0",
        "handsontable": "7.2.0",
        "typescript": "3.5.3",
        "vue": "2.6.10",
        "vue-class-component": "7.1.0",
        "vue-property-decorator": "8.2.1",
        "vuelidate": "0.7.4",
        "vuetify": "1.5.16",
        "vuex": "3.1.1"
    },

@Anatolii-Novikov You're right, we're on it.
Until this issue is fixed, please use the last working Handsontable version (7.1.1).

Hi @Anatolii-Novikov
I have great news.
We've just released a new version of the wrapper that fixes the following issue.
Please update and let me know if it works in your project as well.

Hi @AMBudnik
Thank you for your efforts.
After updating it works

Thank you for the prompt feedback Anatolii.