Logs missing in loki

How to categorize this issue?

/area logging
/kind bug
/priority normal
What happened:
Unable to find logs of extension controllers in the seed loki (the one in the garden ns).
What you expected to happen:
To be able to find the logs.
How to reproduce it (as minimally and precisely as possible):

Open the grafana ingress of some large seed.

Navigate the the explore UI.

Try to find provider-aws logs

Currently the existing pods are
$ k -n extension-provider-aws-dmdjz get po -l app.kubernetes.io/instance=provider-aws
NAME                                               READY   STATUS    RESTARTS   AGE
gardener-extension-provider-aws-64868b6d8d-8rbc8   1/1     Running   0          4h4m
gardener-extension-provider-aws-64868b6d8d-s5m6q   1/1     Running   0          39m
gardener-extension-provider-aws-64868b6d8d-wkskk   1/1     Running   0          149m

Trying the following queries returns nothing
{pod_name="gardener-extension-provider-aws-64868b6d8d-8rbc8"}
{pod_name="gardener-extension-provider-aws-64868b6d8d-s5m6q"}
{pod_name="gardener-extension-provider-aws-64868b6d8d-wkskk"}

or
{pod_name="gardener-extension-provider-aws-64868b6d8d-8rbc8", namespace_name="extension-provider-aws-dmdjz"}
{pod_name="gardener-extension-provider-aws-64868b6d8d-s5m6q", namespace_name="extension-provider-aws-dmdjz"}
{pod_name="gardener-extension-provider-aws-64868b6d8d-wkskk", namespace_name="extension-provider-aws-dmdjz"}

Anything else we need to know?:
Environment:

Gardener version: v1.8.0 and master
Kubernetes version (use kubectl version):
Cloud provider or hardware configuration:
Others:

/assign @vlvasilev @Kristian-ZH

@vlvasilev @Kristian-ZH recently the logging has received a lot of improvements and most of the logs are now successfully ingested in the correct Loki instance, am I right?

Shall we close this in favor/merge this into #2677?

Yes :) we can close this issue

And how exactly this issue is fixed?

Even if it's not fixed yet let's track it in the general improvement issue #2677

The issue was caused because Loki was not able to handle the logs rate.
When the buffer was overflowing, the output plugin was receiving pause command. The normal behaviour after a pause command is to receive a resume command, when some capacity of the buffer is released. Unfortunatelly once our plugin was paused, it was not resumed anymore.
The improvement we did there was to use rwmutex instead of basic mutex in the place where the output plugin was getting Client to the correct Loki: https://github.com/gardener/logging/pull/64
In the before version the critical section was blocking always when a goroutine enters into it.
Now it splits the routines on readers/writers and Multiple readers can access it  simultaneously.
After this chance we are getting pause again but after that we are getting also resume which is the expected behaviour.
Future improvement will be to send into Loki a bulk of logs, because it is slow operation and currently we are sending logs across the network one by one


Get the version of the go-dnscollector binary

Hello Denis,
Can you add a solution to get the version of go-dnscollector please?
Either by a command or a Prometheus metric?
Anthony

new version argument implemented
/go-dnscollector -version
v0.12.0


feat: Custom closed message

Summary | Résumé
Adds ability to add a custom form closed message.

Todo: Add front-end validation
https://github.com/cds-snc/platform-forms-client/issues/4411


Plans to support Angular 13 - No ngcc

🚀 Feature request
Is your feature request related to a problem?
No
Describe the solution you'd like
Republish library with Angular 13 as dependency. Currently, Angular CLI takes additional time to compile the library before starting an application
...Compiling @ng-web-apis/common : es2015 as esm2015
Describe alternatives you've considered
NA
Additional context
NA

@waterplea Can I help speed this along? This is the last library in my workspace not yet published with Ivy support.


"frame period too small" warning

Trying to use trainbot on a test recording from a longer-lensed new USB camera, I end up just getting hundreds of errors logged like:
{"level":"warn","framePeriodS":0.000011111,"time":"2024-05-01T03:04:48.367Z","caller":"/src/internal/pkg/stitch/auto.
go:237","message":"frame period too small"}

And no stiched output.
I see this would be logged by https://github.com/jo-m/trainbot/blob/51c8454c113b29d555ba56ffd4e1718787717d8c/internal/pkg/stitch/auto.go#L237 introduced in https://github.com/jo-m/trainbot/commit/fc92da1706f304c547e89a46c56d495fe7a925d8 but unclear why — if the frame period is too small, does that mean the frame frequency (i.e. fps) of my camera is too fast?
QuickTime player on my main laptop reports it as 32.34fps which doesn't seem particularly high.

Too large to upload to GitHub but if it's helpful, the sample file is temporarily hosted at https://exts.ch/files/train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4 and I'm using:
#! /bin/sh

# fetch from binaries artifact of CI run: <https://github.com/jo-m/trainbot/actions>

export INPUT=./train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4
export RECT_X=603
export RECT_Y=220
export RECT_W=148
export RECT_H=134
export PX_PER_M=23.7  # e.g. 545 px, divided by assuming locomotive ~23 m long?
export MIN_SPEED_KPH=5
export MAX_SPEED_KPH=200
export CAMERA_FORMAT_FOURCC=YUYV

#rm test.jpg && ffmpeg -ss 00:00:37.05 -i "$INPUT" -frames:v 1 test.jpg

rm -rf data && ./trainbot

with the arm64 build of the latest https://github.com/jo-m/trainbot/actions/runs/8837381153 run.

Hi
I get a 404 at that URL:

USB webcams often have a dynamic framerate, since they increase exposure time when the picture is too dark. Another reason could be that the timing information trainbot attaches to the captured frames can be off when the CPU load is too high.
Watch out with dumped video files, you will loose the per-frame timing info and the player (and trainbot on a later import) will just assume a fixed framerate. So this issue may not be reproducible from a recording.

you already got that error when importing a recording

Okay, so if it is about the framerate then yeah what I'd noticed is that 1 / 0.000011111 works out to about ~90k frames per second! So maybe ffmpeg is just feeding it frames as fast as it can accept them instead of in realtime?
But then I don't have this problem on all files, and I would think that would be with the command line arguments to ffmpeg and not based on the exact file. Hoping to have more time again some evening for more troubleshooting but any tips appreciated!

@jo-m

I get a 404 at that URL

oh sorry, something's misconfigured and the HTTPS is going to the wrong site. with just plain http://exts.ch/files/train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4 it should work

Well, turns out this was simply a bug, and I used the wrong number from ffprobe.

Also, I had to increase the max allowed length (rather, make it configurable) because your train was too long for my hardcoded default.
Now spits out this JPEG which my OS previewer cannot display because it's too long:

Thumb:

Command used:
./trainbot \
  --log-pretty \
  --log-level info \
  --input ./train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4 \
  --rect-x 603 \
  --rect-y 220 \
  --rect-w 148 \
  --rect-h 134 \
  --px-per-m 23.7 \
  --min-speed-kph 5 \
  --max-speed-kph 200 \
  --max-frame-count-per-seq 10000

Thanks for looking into it and great to hear you found a fix already! I'll try retest myself soon.


Second Spyder instance can't connect to an external LSP server

If you start a PyLS server externally and connect to it with two Spyder instances, then completion and linting work correctly for the first instance but don't work at all for the second one.
@andfoy, is this something expected? I'd say no because each Spyder instance starts its own transport layer, so there shouldn't be problems with both sending petitions to the same server.
Please take a look at this to see if we can solve it for Spyder 4.

@andfoy, is this something expected? I'd say no because each Spyder instance starts its own transport layer, so there shouldn't be problems with both sending petitions to the same server.

The only trouble there could be is if we are trying to share the same ZMQ port for both transport layers, I'll take a look at it and come back


issue #1802 - replace FromStr with TryFrom impl trait in ecdsa.rs crypto module

In order to get a feel of the good first issue contribution, I made a little contribution in which I replaced the FromStr impl with TryFrom impl trait

It should not be a replacement, it should be in addition to the existing impls. Ideally we would optimize it to call into an internal function that takes AsRef<str> + Into<InputString>.

when you refers to internal function, is it internal to Signature?

"internal" means no public i.e., private scope.

It should not be a replacement, it should be in addition to the existing impls. Ideally we would optimize it to call into an internal function that takes AsRef<str> + Into<InputString>.

when you refers to internal function, is it internal to Signature?

As a follow-up question, could an example code below be what is implied?
    impl Signature {
        // name the internal function appropriately
        fn internal_func<T>(s: T) -> Result<Self, Self::Error>
          where T: AsRef<str> + Into<InputString> {
           ...
        }
    }

    impl TryFrom<&str> for Signature {
      ...
      fn try_from(s: &str) -> Result<Self, Self::Error> {
        Self::internal_func(s)
      }
    }

Converting to draft in preparation for upcoming feature freeze. Next release is due out at the end of the month.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 72 (12.5%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 82.761%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/crypto/ecdsa.rs
9
72
12.5%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
19496

Relevant Lines:
23557

💛  - Coveralls

These CI failures look real.

This has been sitting around for ages with no action, closing.

@tcharding can this be reopened so I can complete it?

There were review suggestions that had not been touched for months so I closed it. Feel free to re-open if you are active still.

For some reason, the button to reeopn the PR is not available. Please help with instructions on how to go about that

If you deleted or force-pushed to the branch then the reopen button is permanently disabled. You'll have to open a new PR.

If you deleted or force-pushed to the branch then the reopen button is permanently disabled. You'll have to open a new PR.

Alright then, never knew that. Thanks for the info.


Docker selenium

Will it make sense to have a section for selenium docker in this documentation?

Yes, it would make sense.
On Wed, Nov 1, 2017 at 2:57 AM, macroking<EMAIL_ADDRESS>wrote:

Will it make sense to have a section for selenium docker in this
documentation?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docs/issues/158, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABuRY72OnF4rl8XwscRba1r2QFS9D-Iks5sx94vgaJpZM4QNr30
.

Closed via #197


Add match-like assertion

This is an initial implementation of an assert-matches assertion.
It closes #5.

@yumaikas Does this look like what you had in mind?

@yumaikas Does this look like what you had in mind?

Yes, it does look more or less like what I had in mind, though I'd argue that match is better than matches, since it's more consistent with how Janet is currently worded, but either wording serves the purpose I'm looking for.
Thanks for adding this!

Yes, it does look more or less like what I had in mind, though I'd argue that match is better than matches, since it's more consistent with how Janet is currently worded, but either wording serves the purpose I'm looking for.
Thanks for adding this!


Shall we remove multi-plate support?

Current situation:

The create-ome-zarr task accepts a list of N input_paths, which are then treated as independent plates and processed one by one - leading to N OME-Zarr files.
The copy-ome-zarr task (soon to be partly refactored, see #279) only supports len(input_paths)=1, but in this folder there may exist N OME-Zarr files, for instance because of what was described in point 1. In this case, the copy-ome-zarr task loops over the N independent plates and copies them into N new OME-Zarr's.
Note: it's not fully clear what would happen if we call the copy-ome-zarr task twice on the same folder. I think that the first time it will create a plate_mip.zarr copy of the original plate.zarr, while the second time it will attempt creating copies of both plate.zarr and plate_mip.zarr, likely resulting into errors.

As part of last week meetings, we mentioned that this is not necessarily a crucial feature, but for sure it does add up to the task complexity. Question: should we fully drop it?
If so, the new version would be:

The create-ome-zarr task only accepts a single input folder, while multiple input folders only make sense for its multiplexing version.
The copy-ome-zarr accepts a single input folder (which is already the case) and checks that this folder only has a single OME-Zarr.
A more fine-grained operation in a folder which includes multiple OME-Zarr's would not be immediately supported. Most likely it would require additional inputs from the user (possibly related to https://github.com/fractal-analytics-platform/fractal-server/issues/792), and it would also depend on #324 and #342, and on the future way of storing MIP projections in the same OME-Zarr.

From a use-case side: I agree that we can move support for processing multiple "unrelated" input plates to be processed as separate datasets, not the same dataset with different components. It may even be the better user experience to encourage that way of processing, because a user may decide mid-way during processing that different plates actually need different workflows.

The copy-ome-zarr accepts a single input folder (which is already the case) and checks that this folder only has a single OME-Zarr.

It should be possible to run this in a folder that e.g. contains plate.zarr and plate_mip.zarr (or any other collection of zarr files that aren't in the component list). Can't it just work on the metadata plate list (that contains a single plate name)?
Why it's important that it works that way? Because we'd want to run the new, more flexible copy OME-Zarr task e.g. on the plate_mip.zarr again to test on a subset of the MIP dataset.
This then also opens the larger question: Should our tasks in general take a list of input datasets, if it's only needed for the Convert OME-Zarr multiplexing?

I tested it now in https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/812
With fractal-tasks-core 1.2.1, it already basically works. It creates multiple plates and converts the images correctly. It even handles getting plates of the same name.
It didn't correctly handle the plate metadata for the image list in that case yet, and that will come with https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/812 marking multi-plate support officially supported & tested


Missing jobs from site peviitor.ro, company "apavital"

URL: https://peviitor.ro/
browser: Microsoft Edge
device: Computer
OS: windows

Steps to reproduce

Open the company recruitee page: https://www.apavital.ro/cariere
Pay attention that are two pages of jobs.
Open peviitor URL
Put the name "apavital" in the search field
Press the enter button
Pay attention that is displayed only jobs that are appeared to first page.

Expected results

It should displayed on peviitor.ro site all the jobs from "apavital" site.

Actual results

There is displayed only jobs that are appeared to first page.

Fixed can you retest?

Retest.


If this API available in v1.0 then why example shows beta endpoint?

Beta endpoint works fine but v1.0 does not but the documentation says v1.0 is supported

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

ID: 2d004147-c5a2-11ec-7ad0-2df88d695c6f
Version Independent ID: 84d53f2e-5c52-fc05-a330-ce22351e410a
Content: List enterpriseCodeSigningCertificates - Microsoft Graph v1.0
Content Source: api-reference/v1.0/api/intune-apps-enterprisecodesigningcertificate-list.md
Product: intune
Technology: microsoft-graph
GitHub Login: @jaiprakashmb
Microsoft Alias: MSGraphDocsVteam

PR https://github.com/microsoftgraph/microsoft-graph-docs/pull/23902 fixes this issue.

Fix applied.


import live2dcubismcore.min.js in javascript?

I'm trying to use this library in chrome extension. The content script doesn't have html context (thus no <script> tag). We have successfully imported live2d.min.js and it worked for the cubism v2. But we couldn't import live2dcubismcore.min.js. Have tried to use
import * as Live2DCubismCore from 'live2dcubismcore.min.js';
window.Live2DCubismCore = Live2DCubismCore;

but got an error Failed to start up Cubism 4 framework.. Strangely, there's also no retry logs being printed.
Any thoughts how we can properly include this library? Thanks!

Similiar to #19, live2dcubismcore.min.js is not a module, nor does it mount anything on global scope (usually window), that's why it's supposed to be loaded by <script>.
Not familiar with chrome extension, but I guess there's a way to load this script separately, so that it'll work as if it's loaded by <script>.
If that doesn't work, another way is to modify the script by replacing the first statement:
var Live2DCubismCore;

with:
window.Live2DCubismCore = {};

then the variable will be correctly exposed, and the script can be imported as usual:
import 'live2dcubismcore.min.js';

OMFG it worked!!!! @guansss LOVE YOU MY BRO!!


Failed to build hello world with CONFIG_POSIX_SYSCONF_IMPL_FULL=y

Describe the bug
Since cdc36d090c0c0abc1006f8c3f10100b6c54d385f (posix: sysconf: add a "small" implementation option), the hello world sample failed to build.
To Reproduce
west build -b nucleo_f429zi zephyr/samples/hello_world -- -DCONFIG_POSIX_SYSCONF=y -DCONFIG_POSIX_SYSCONF_IMPL_FULL=y

Expected behavior
Succeed to build the sample hello_world.
Logs and console output
❯ rm -rf build && west build -b nucleo_f429zi zephyr/samples/hello_world -- -DCONFIG_POSIX_SYSCONF=y -DCONFIG_POSIX_SYSCONF_IMPL_FULL=y         ─╯
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /home/yashi/src/zephyr-project/zephyr/samples/hello_world
-- CMake version: 3.28.3
-- Found Python3: /home/yashi/src/zephyr-project/.venv/bin/python (found suitable version "3.11.8", minimum required is "3.8") found components: Interpreter
-- Cache files will be written to: /home/yashi/.cache/zephyr
-- Zephyr version: 3.6.99 (/home/yashi/src/zephyr-project/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.14.0")
-- Board: nucleo_f429zi, identifier: stm32f429xx
-- ZEPHYR_TOOLCHAIN_VARIANT not set, trying to locate Zephyr SDK
-- Found host-tools: zephyr 0.16.5 (/home/yashi/zephyr-sdk-0.16.5)
-- Found toolchain: zephyr 0.16.5 (/home/yashi/zephyr-sdk-0.16.5)
-- Found Dtc: /usr/bin/dtc (found suitable version "1.7.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/yashi/src/zephyr-project/zephyr/boards/st/nucleo_f429zi/nucleo_f429zi.dts
-- Generated zephyr.dts: /home/yashi/src/zephyr-project/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /home/yashi/src/zephyr-project/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /home/yashi/src/zephyr-project/build/zephyr/dts.cmake
Parsing /home/yashi/src/zephyr-project/zephyr/Kconfig
Loaded configuration '/home/yashi/src/zephyr-project/zephyr/boards/st/nucleo_f429zi/nucleo_f429zi_defconfig'
Merged configuration '/home/yashi/src/zephyr-project/zephyr/samples/hello_world/prj.conf'
Merged configuration '/home/yashi/src/zephyr-project/build/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/home/yashi/src/zephyr-project/build/zephyr/.config'
Kconfig header saved to '/home/yashi/src/zephyr-project/build/zephyr/include/generated/autoconf.h'
-- Found GnuLd: /home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd (found version "2.38")
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Using ccache: /usr/bin/ccache
CMake Warning at /home/yashi/src/zephyr-project/zephyr/CMakeLists.txt:864 (message):
  No SOURCES given to Zephyr library: lib__posix__shell

  Excluding target from build.

-- Configuring done (3.1s)
-- Generating done (0.0s)
-- Build files have been written to: /home/yashi/src/zephyr-project/build
-- west build: building application
[1/134] Preparing syscall dependency handling

[3/134] Generating include/generated/version.h
-- Zephyr version: 3.6.99 (/home/yashi/src/zephyr-project/zephyr), build: v3.6.0-851-gbe9a85bf6c5e
[100/134] Building C object zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj
FAILED: zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj
ccache /home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DCORE_CM4 -DHSE_VALUE=8000000 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DPICOLIBC_LONG_LONG_PRINTF_SCANF -DSTM32F429xx -DUSE_FULL_LL_DRIVER -DUSE_HAL_DRIVER -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/yashi/src/zephyr-project/zephyr/kernel/include -I/home/yashi/src/zephyr-project/zephyr/arch/arm/include -I/home/yashi/src/zephyr-project/zephyr/include -I/home/yashi/src/zephyr-project/build/zephyr/include/generated -I/home/yashi/src/zephyr-project/zephyr/soc/st/stm32 -I/home/yashi/src/zephyr-project/zephyr/soc/st/stm32/common/. -I/home/yashi/src/zephyr-project/zephyr/drivers -I/home/yashi/src/zephyr-project/zephyr/soc/st/stm32/stm32f4x/. -I/home/yashi/src/zephyr-project/modules/hal/cmsis/CMSIS/Core/Include -I/home/yashi/src/zephyr-project/zephyr/modules/cmsis/. -I/home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/soc -I/home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include -I/home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/Legacy -I/home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/common_ll/include -isystem /home/yashi/src/zephyr-project/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros /home/yashi/src/zephyr-project/build/zephyr/include/generated/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=/home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/arm-zephyr-eabi -imacros /home/yashi/src/zephyr-project/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=/home/yashi/src/zephyr-project/zephyr/samples/hello_world=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/yashi/src/zephyr-project/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/yashi/src/zephyr-project=WEST_TOPDIR -ffunction-sections -fdata-sections --specs=picolibc.specs -std=c99 -MD -MT zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj -MF zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj.d -o zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj -c /home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c
In file included from /home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:7:
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c: In function 'sysconf':
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:137:45: error: 'CONFIG_MSG_COUNT_MAX' undeclared (first use in this function)
  137 | #define _POSIX_MQ_OPEN_MAX                  CONFIG_MSG_COUNT_MAX
      |                                             ^~~~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:192:39: note: in expansion of macro '_POSIX_MQ_OPEN_MAX'
  192 | #define MQ_OPEN_MAX                   _POSIX_MQ_OPEN_MAX
      |                                       ^~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:227:24: note: in expansion of macro 'MQ_OPEN_MAX'
  227 |                 return MQ_OPEN_MAX;
      |                        ^~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:137:45: note: each undeclared identifier is reported only once for each function it appears in
  137 | #define _POSIX_MQ_OPEN_MAX                  CONFIG_MSG_COUNT_MAX
      |                                             ^~~~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:192:39: note: in expansion of macro '_POSIX_MQ_OPEN_MAX'
  192 | #define MQ_OPEN_MAX                   _POSIX_MQ_OPEN_MAX
      |                                       ^~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:227:24: note: in expansion of macro 'MQ_OPEN_MAX'
  227 |                 return MQ_OPEN_MAX;
      |                        ^~~~~~~~~~~
In file included from /home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/stm32f4xx_hal_def.h:30,
                 from /home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/stm32f4xx_hal_rcc.h:27,
                 from /home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/stm32f4xx_hal_conf.h:285,
                 from /home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/stm32f4xx_hal.h:29,
                 from /home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/soc/stm32f4xx.h:287,
                 from /home/yashi/src/zephyr-project/zephyr/soc/st/stm32/stm32f4x/./soc.h:23,
                 from /home/yashi/src/zephyr-project/zephyr/modules/cmsis/./cmsis_core_m.h:24,
                 from /home/yashi/src/zephyr-project/zephyr/modules/cmsis/./cmsis_core.h:10,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/arch/arm/mpu/arm_mpu_v7m.h:10,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/arch/arm/mpu/arm_mpu.h:14,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/arch/arm/arch.h:271,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/arch/cpu.h:19,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/kernel_includes.h:36,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/kernel.h:17,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/posix_types.h:18,
                 from /home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:9:
/home/yashi/src/zephyr-project/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/Legacy/stm32_hal_legacy.h:461:39: error: 'FLASH_PAGE_SIZE' undeclared (first use in this function); did you mean 'FLASH_CR_PSIZE'?
  461 | #define PAGESIZE                      FLASH_PAGE_SIZE
      |                                       ^~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:235:24: note: in expansion of macro 'PAGESIZE'
  235 |                 return PAGESIZE;
      |                        ^~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:219:39: error: 'CONFIG_MAX_TIMER_COUNT' undeclared (first use in this function)
  219 | #define TIMER_MAX                     CONFIG_MAX_TIMER_COUNT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:257:24: note: in expansion of macro 'TIMER_MAX'
  257 |                 return TIMER_MAX;
      |                        ^~~~~~~~~
[124/134] Building C object zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/yashi/src/zephyr-project/build

Environment (please complete the following information):

OS: Debian Sid
Toolchain: Zephyr SDK 0.16.5
Commit SHA: cdc36d090c0c0abc1006f8c3f10100b6c54d385f

@cfriedt Would you mind taking a look at this? Let me know if you need more info.  Thanks.

Sure, I can check that out. I should probably rename he "FULL" config option to "SMALL" to be consistent with the original issue

it doesn't seems to be limited to stm32. qemu_cortex_m3 failes as well.
❯ rm -rf build && west build -b qemu_cortex_m3 zephyr/samples/hello_world -- -DCONFIG_POSIX_SYSCONF=y -DCONFIG_POSIX_SYSCONF_IMPL_FULL=y        ─╯
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /home/yashi/src/zephyr-project/zephyr/samples/hello_world
-- CMake version: 3.28.3
-- Found Python3: /home/yashi/src/zephyr-project/.venv/bin/python (found suitable version "3.11.8", minimum required is "3.8") found components: Interpreter
-- Cache files will be written to: /home/yashi/.cache/zephyr
-- Zephyr version: 3.6.99 (/home/yashi/src/zephyr-project/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.14.0")
-- Board: qemu_cortex_m3, identifier: ti_lm3s6965
-- ZEPHYR_TOOLCHAIN_VARIANT not set, trying to locate Zephyr SDK
-- Found host-tools: zephyr 0.16.5 (/home/yashi/zephyr-sdk-0.16.5)
-- Found toolchain: zephyr 0.16.5 (/home/yashi/zephyr-sdk-0.16.5)
-- Found Dtc: /usr/bin/dtc (found suitable version "1.7.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/yashi/src/zephyr-project/zephyr/boards/qemu/cortex_m3/qemu_cortex_m3.dts
-- Generated zephyr.dts: /home/yashi/src/zephyr-project/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /home/yashi/src/zephyr-project/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /home/yashi/src/zephyr-project/build/zephyr/dts.cmake
Parsing /home/yashi/src/zephyr-project/zephyr/Kconfig
Loaded configuration '/home/yashi/src/zephyr-project/zephyr/boards/qemu/cortex_m3/qemu_cortex_m3_defconfig'
Merged configuration '/home/yashi/src/zephyr-project/zephyr/samples/hello_world/prj.conf'
Merged configuration '/home/yashi/src/zephyr-project/build/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/home/yashi/src/zephyr-project/build/zephyr/.config'
Kconfig header saved to '/home/yashi/src/zephyr-project/build/zephyr/include/generated/autoconf.h'
-- Found GnuLd: /home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd (found version "2.38")
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Using ccache: /usr/bin/ccache
CMake Warning at /home/yashi/src/zephyr-project/zephyr/CMakeLists.txt:864 (message):
  No SOURCES given to Zephyr library: lib__posix__shell

  Excluding target from build.

-- Configuring done (2.8s)
-- Generating done (0.0s)
-- Build files have been written to: /home/yashi/src/zephyr-project/build
-- west build: building application
[1/110] Preparing syscall dependency handling

[3/110] Generating include/generated/version.h
-- Zephyr version: 3.6.99 (/home/yashi/src/zephyr-project/zephyr), build: v3.6.0-851-gbe9a85bf6c5e
[74/110] Building C object zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj
FAILED: zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj
ccache /home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/yashi/src/zephyr-project/zephyr/kernel/include -I/home/yashi/src/zephyr-project/zephyr/arch/arm/include -I/home/yashi/src/zephyr-project/zephyr/include -I/home/yashi/src/zephyr-project/build/zephyr/include/generated -I/home/yashi/src/zephyr-project/zephyr/soc/ti/lm3s6965 -I/home/yashi/src/zephyr-project/zephyr/soc/ti/lm3s6965/. -I/home/yashi/src/zephyr-project/modules/hal/cmsis/CMSIS/Core/Include -I/home/yashi/src/zephyr-project/zephyr/modules/cmsis/. -isystem /home/yashi/src/zephyr-project/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros /home/yashi/src/zephyr-project/build/zephyr/include/generated/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m3 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=/home/yashi/zephyr-sdk-0.16.5/arm-zephyr-eabi/arm-zephyr-eabi -imacros /home/yashi/src/zephyr-project/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=/home/yashi/src/zephyr-project/zephyr/samples/hello_world=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/yashi/src/zephyr-project/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/yashi/src/zephyr-project=WEST_TOPDIR -ffunction-sections -fdata-sections --specs=picolibc.specs -std=c99 -MD -MT zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj -MF zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj.d -o zephyr/lib/posix/options/CMakeFiles/lib__posix__options.dir/sysconf.c.obj -c /home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c
In file included from /home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:7:
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c: In function 'sysconf':
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:137:45: error: 'CONFIG_MSG_COUNT_MAX' undeclared (first use in this function)
  137 | #define _POSIX_MQ_OPEN_MAX                  CONFIG_MSG_COUNT_MAX
      |                                             ^~~~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:192:39: note: in expansion of macro '_POSIX_MQ_OPEN_MAX'
  192 | #define MQ_OPEN_MAX                   _POSIX_MQ_OPEN_MAX
      |                                       ^~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:227:24: note: in expansion of macro 'MQ_OPEN_MAX'
  227 |                 return MQ_OPEN_MAX;
      |                        ^~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:137:45: note: each undeclared identifier is reported only once for each function it appears in
  137 | #define _POSIX_MQ_OPEN_MAX                  CONFIG_MSG_COUNT_MAX
      |                                             ^~~~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:192:39: note: in expansion of macro '_POSIX_MQ_OPEN_MAX'
  192 | #define MQ_OPEN_MAX                   _POSIX_MQ_OPEN_MAX
      |                                       ^~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:227:24: note: in expansion of macro 'MQ_OPEN_MAX'
  227 |                 return MQ_OPEN_MAX;
      |                        ^~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/include/zephyr/posix/unistd.h:219:39: error: 'CONFIG_MAX_TIMER_COUNT' undeclared (first use in this function)
  219 | #define TIMER_MAX                     CONFIG_MAX_TIMER_COUNT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~
/home/yashi/src/zephyr-project/zephyr/lib/posix/options/sysconf.c:257:24: note: in expansion of macro 'TIMER_MAX'
  257 |                 return TIMER_MAX;
      |                        ^~~~~~~~~
[99/110] Building C object zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/yashi/src/zephyr-project/build

@yashi - the main part that is difficult to solve is stm32 specific
https://github.com/zephyrproject-rtos/hal_stm32/blob/main/stm32cube/stm32f4xx/drivers/include/Legacy/stm32_hal_legacy.h#L461
It seems that nothing defines FLASH_PAGE_SIZE.
The fox for this issue will be 2 parts

Platform independent change (just about done)
Stm32 change

@erwango
The remaining issue that is not fixed by #70138 seem to be due to FLASH_PAGE_SIZE not being defined in stm32 legacy headers.
https://github.com/zephyrproject-rtos/hal_stm32/blob/main/stm32cube/stm32f4xx/drivers/include/Legacy/stm32_hal_legacy.h#L461
Is there a way that either PAGE_SIZE can be reserved for POSIX (which would be preferable, since it does not only relate to flash, but to thread stack sizes, etc) or whether FLASH_PAGE_SIZE can be defined for these headers?

Set to medium since there may be a few stm32 platforms affected.

Reopening this due to FLASH_PAGE_SIZE not fixed yet.

It was automatically closed - thanks for reopening

Ok, I see the issue there are no real flash pages on STM32F4 (as on STM32F7).
There are 2 alternatives:

Define a dummy FLASH_PAGE_SIZE on these series
Remove the culprit #define PAGESIZE FLASH_PAGE_SIZE

Question:
What if PAGESIZE is not defined ?

What if PAGESIZE is not defined ?

unistd.h defines PAGE_SIZE from CONFIG_POSIX_PAGE_SIZE_BITS, and PAGESIZE from PAGE_SIZE.
In the stm32 hal's perspective PAGESIZE is for flash memory, but for POSIX it's memory paging.  Both might be 4 KB but I feel odd to define memory page size from flash memory page size.  And no other HAL defines it.

And no other HAL defines it.

This is interesting. How does it build on other platforms then ?

Remove the culprit #define PAGESIZE FLASH_PAGE_SIZE

Question:
What if PAGESIZE is not defined ?

I would guess everything would be fine if the HAL does not define PAGESIZE.

I got this error as well for board stm32h747i_disco/stm32h747xx/m7"

Will actually be fixed by #73363


Can't start .AppImage on Fedora 29

I tried launching the .AppImage after downloading and doing chmod +x godot-linux-nightly-x86_64.AppImage, but all I get is:
./godot-linux-nightly-x86_64.AppImage: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory
I've made the Tiled .AppImage work from here: https://github.com/bjorn/tiled/releases so there's possibly a missing dependency? Or maybe something changed in Fedora 29 and broke something?
Thanks

A simple workaround is to install libsnl like so sudo dnf install libnsl

This should be now fixed thanks to https://github.com/AppImage/AppImageKit/pull/863.; please comment if you can still reproduce this issue.

Sorry, I can still reproduce this issue^^
I don't see why https://github.com/AppImage/AppImageKit/pull/863 would fix this, isn't about another library?

I remember discussing the libnsl issue with AppImage developers on IRC, but I don't remember if it was actually fixed, sorry.

No worries!

Hi,
I saw your comment on the pull request.
Does this mean that in more recent versions of Ubuntu libnsl is also in by default?
Can libnsl get packaged inside the AppImage though libc6? Or is it an integral part of that package and would then only work on ubuntu?

Does this mean that in more recent versions of Ubuntu libnsl is also in by default?

Yes, I don't think Canonical has changed that after 14.04.

Can libnsl get packaged inside the AppImage though libc6? Or is it an integral part of that package and would then only work on ubuntu?

It's a standalone .so file even if it comes from libc6, but I don't know why linuxdeployqt doesn't pick up the library for packaging since it's no longer blacklisted.

So I've tried a quick look at linuxdeployqt to understand how it works and see if I could thing something to help.
So far not really, I saw that there is this option -bundle-non-qt-libs but I'm guessing you already say that. (And I'm not completely sure what it does yet anyway).
I came across this issue: https://github.com/probonopd/linuxdeployqt/issues/241 where they've asked to run D_DEBUG=libs your.AppImage to see how libraries are loaded.
I'm posting my result underneath, maybe it'll help. First the part that fails for libsnl only and then the whole output (for clarity). The command I ran is LD_DEBUG=libs ./godot-linux-nightly-x86_64.AppImage.

  6720:	find library=libnsl.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libnsl.so.1
  6720:	 search cache=/etc/ld.so.cache
  6720:	 search path=/lib64/tls/haswell/x86_64:/lib64/tls/haswell:/lib64/tls/x86_64:/lib64/tls:/lib64/haswell/x86_64:/lib64/haswell:/lib64/x86_64:/lib64:/usr/lib64/tls/haswell/x86_64:/usr/lib64/tls/haswell:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/haswell/x86_64:/usr/lib64/haswell:/usr/lib64/x86_64:/usr/lib64		(system search path)
  6720:	  trying file=/lib64/tls/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/tls/haswell/libnsl.so.1
  6720:	  trying file=/lib64/tls/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/tls/libnsl.so.1
  6720:	  trying file=/lib64/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/haswell/libnsl.so.1
  6720:	  trying file=/lib64/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/haswell/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/libnsl.so.1
  6720:	  trying file=/usr/lib64/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/haswell/libnsl.so.1
  6720:	  trying file=/usr/lib64/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/libnsl.so.1
  6720:

./godot-linux-nightly-x86_64.AppImage: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

The whole output:

  6720:	find library=libdl.so.2 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libdl.so.2
  6720:
  6720:	find library=libpthread.so.0 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libpthread.so.0
  6720:
  6720:	find library=libz.so.1 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libz.so.1
  6720:
  6720:	find library=libc.so.6 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libc.so.6
  6720:
  6720:
  6720:	calling init: /lib64/libpthread.so.0
  6720:
  6720:
  6720:	calling init: /lib64/libc.so.6
  6720:
  6720:
  6720:	calling init: /lib64/libz.so.1
  6720:
  6720:
  6720:	calling init: /lib64/libdl.so.2
  6720:
  6720:
  6720:	initialize program: ./godot-linux-nightly-x86_64.AppImage
  6720:
  6720:
  6720:	transferring control: ./godot-linux-nightly-x86_64.AppImage
  6720:
  6720:	find library=libfuse.so.2 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libfuse.so.2
  6720:
  6720:
  6720:	calling init: /lib64/libfuse.so.2
  6720:
  6720:	find library=libXcursor.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/haswell/x86_64:/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/haswell:/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/x86_64:/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls:/tmp/.mount_godot-HD6R7m/usr/bin/../lib/haswell/x86_64:/tmp/.mount_godot-HD6R7m/usr/bin/../lib/haswell:/tmp/.mount_godot-HD6R7m/usr/bin/../lib/x86_64:/tmp/.mount_godot-HD6R7m/usr/bin/../lib(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/haswell/x86_64/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/haswell/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/x86_64/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/tls/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/haswell/x86_64/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/haswell/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/x86_64/libXcursor.so.1
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXcursor.so.1
  6720:
  6720:	find library=libXinerama.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXinerama.so.1
  6720:
  6720:	find library=libXrandr.so.2 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXrandr.so.2
  6720:
  6720:	find library=libXrender.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXrender.so.1
  6720:
  6720:	find library=libX11.so.6 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libX11.so.6
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libX11.so.6
  6720:
  6720:	find library=libXi.so.6 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXi.so.6
  6720:
  6720:	find library=libfreetype.so.6 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libfreetype.so.6
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libfreetype.so.6
  6720:
  6720:	find library=libpng12.so.0 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libpng12.so.0
  6720:
  6720:	find library=libasound.so.2 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libasound.so.2
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libasound.so.2
  6720:
  6720:	find library=libpulse.so.0 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libpulse.so.0
  6720:
  6720:	find library=libz.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libz.so.1
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libz.so.1
  6720:
  6720:	find library=libGL.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libGL.so.1
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libGL.so.1
  6720:
  6720:	find library=libpthread.so.0 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libpthread.so.0
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libpthread.so.0
  6720:
  6720:	find library=libdl.so.2 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libdl.so.2
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libdl.so.2
  6720:
  6720:	find library=libm.so.6 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libm.so.6
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libm.so.6
  6720:
  6720:	find library=libc.so.6 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libc.so.6
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libc.so.6
  6720:
  6720:	find library=libXfixes.so.3 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXfixes.so.3
  6720:
  6720:	find library=libXext.so.6 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libXext.so.6
  6720:
  6720:	find library=libxcb.so.1 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libxcb.so.1
  6720:
  6720:	find library=libbz2.so.1 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libbz2.so.1
  6720:
  6720:	find library=libpng16.so.16 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libpng16.so.16
  6720:
  6720:	find library=librt.so.1 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/librt.so.1
  6720:
  6720:	find library=libjson-c.so.2 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libjson-c.so.2
  6720:
  6720:	find library=libpulsecommon-4.0.so [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libpulsecommon-4.0.so
  6720:
  6720:	find library=libdbus-1.so.3 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libdbus-1.so.3
  6720:
  6720:	find library=libGLX.so.0 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libGLX.so.0
  6720:
  6720:	find library=libGLdispatch.so.0 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libGLdispatch.so.0
  6720:
  6720:	find library=libXau.so.6 [0]; searching
  6720:	 search cache=/etc/ld.so.cache
  6720:	  trying file=/lib64/libXau.so.6
  6720:
  6720:	find library=libwrap.so.0 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libwrap.so.0
  6720:
  6720:	find library=libsndfile.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libsndfile.so.1
  6720:
  6720:	find library=libasyncns.so.0 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libasyncns.so.0
  6720:
  6720:	find library=libnsl.so.1 [0]; searching
  6720:	 search path=/tmp/.mount_godot-HD6R7m/usr/bin/../lib		(RUNPATH from file ./godot-linux-nightly-x86_64.AppImage)
  6720:	  trying file=/tmp/.mount_godot-HD6R7m/usr/bin/../lib/libnsl.so.1
  6720:	 search cache=/etc/ld.so.cache
  6720:	 search path=/lib64/tls/haswell/x86_64:/lib64/tls/haswell:/lib64/tls/x86_64:/lib64/tls:/lib64/haswell/x86_64:/lib64/haswell:/lib64/x86_64:/lib64:/usr/lib64/tls/haswell/x86_64:/usr/lib64/tls/haswell:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/haswell/x86_64:/usr/lib64/haswell:/usr/lib64/x86_64:/usr/lib64		(system search path)
  6720:	  trying file=/lib64/tls/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/tls/haswell/libnsl.so.1
  6720:	  trying file=/lib64/tls/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/tls/libnsl.so.1
  6720:	  trying file=/lib64/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/haswell/libnsl.so.1
  6720:	  trying file=/lib64/x86_64/libnsl.so.1
  6720:	  trying file=/lib64/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/haswell/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/tls/libnsl.so.1
  6720:	  trying file=/usr/lib64/haswell/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/haswell/libnsl.so.1
  6720:	  trying file=/usr/lib64/x86_64/libnsl.so.1
  6720:	  trying file=/usr/lib64/libnsl.so.1
  6720:

./godot-linux-nightly-x86_64.AppImage: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

Hope this helps somewhow...

Hi,
This issue looks fixed now when I just tried the beta 7 of 3.1.
No idea when this was fixed but doesn't really matter :smile:


Support the GET method of the Catalog collection resource

New REST operation to get a listing of all catalogs.
Request
GET catalog

Response body (json only)
{
  { 'id': 'name' },
  ...
}

Access Control
I think we should have a top level ACL to permit listing of all catalogs. Like this in ermrest_config.json:
...
  'registry' : {
    ...
    'acls': {
      'list_catalogs_permit': [ roles+ ],
      ...
    }
...

My thinking is that we should not rely on the per-catalog ACLs to permit listing of the catalog. That would require opening a connection to every catalog's database and reading its ACLs.
Limitations
The registry module (i.e., registry.py) defines an interface and base implementation Registry and the SimpleRegistry implementation, which is the one and only implementation of a registry we have ever had. The above feature may only work in a "simple" registry such as our current one that keeps a record of all catalog-database mappings in its own database. In the unlikely event that we supported some other registry implementation (like a distributed hash table based implementation) then this operation might not be implementable. The server should be able to respond with the No Method response (not Internal Error) and clients should be aware that this method might not be supported.

It should either be an array of catalogs [{"id": 1}, ...]
or a mapping like { 1: {"id": 1}, ... }.
I think I'd prefer the array but I'm not sure.

I prefer array actually. That was a mistake.

One question is whether we should have per-catalog listing ACLs inside the descriptors or registry itself... I'm not sure if all catalogs should always be under the same static policy here.

good question. just don’t want to overlap or duplicate what we do with the catalog’s read_acl.

On Aug 19, 2015, at 4:06 PM, karlcz<EMAIL_ADDRESS>wrote:
One question is whether we should have per-catalog listing ACLs inside the descriptors or registry itself... I'm not sure if all catalogs should always be under the same static policy here.
—
Reply to this email directly or view it on GitHub https://github.com/informatics-isi-edu/ermrest/issues/26#issuecomment-132820860.

We'd also need a REST interface to manage this ACL unless we overload
it on the catalog/meta/ API and just match one magic ACL name and
route it over to the registry instead of handling it in the catalog...

What use case do you have in mind for this per-catalog listing ACL? versus a simpler service-level listing ACL that applies across all catalogs?

It's not so much that I have a use case as I don't understand the
utility of exposing catalogs that the user will be forbidden to view
anyway (since we have per-catalog access ACLs already).
On reflection, I am actually not sure what the value of this listing
mechanism is at all for regular users.  You're just going to get back
catalog numbers, right?  There will be no other information to help
understand the purpose of the catalog.
So the real question might be: what additional content is needed in
catalog descriptors so that we can have a useful listing mechanism?
That could include both descriptive metadata and ACLs so that the
resulting list is meaningful and actionable.

Well right. I had in mind we would want to add a human readable description.

The more I think about this feature the less inclined I am to want us to implement it at this point.  We've joked in the past that the registry should maybe be implemented as a reserved catalog (i.e., catalog/registry/...). Ultimately won't we want to: query and filter the catalog registry, limit the results set (so we don't get back a listing of 1 million catalog descriptions), and so on? And conceptually, isn't the registry just a catalog of catalogs really?

Would there be value in this feature for UI clients (such as the one UC is developing) that want to let users select the catalog. I think we will need that feature. So in addition to my original comment:

each catalog has a description field in the registry that is returned along with the catalogs id
each catalog entry in the registry has a list_acl for per-catalog listing access control

Optionally if we want to support the listing of deleted but not yet purged catalogs the interface would support a show_deleted query option. E.g.,
GET catalog?show_deleted=True

If that's the case then we also return the deleted_on field along with the id and description of the catalog.
With regard to my last comment about whether this would be a bad hack. I was rethinking that opinion. The internal implementation which was divided between an abstract interface Registry and the SimpleRegistry implementation was also intended to support just that a simple registry implementation while leaving open the possibility for more sophisticated implementations in the future. So I think its fine to have limitations that are clearly described in our documentation. I.e., don't GET catalog if you have a million of them, or implement a better registry.

I'm going to mark this "wont fix". We can always reopen it in the future.


Pretrained weight file

Where can I find pretrained weight file, to test the model on certain sequences of input data.

No pretrained model released.


A velocity controller for the crazyflie

Now the crazyflie can be controlled with velocity commands from the keyboard, with added yaw control. This also includes multiple improvements and refactors to the controller.

fix #4


Expose path viability and better path updates

Proposal for exposing better path updates and path viability.
I'm not sure if the framework should handle migration. Maybe it's better let the user to do the switching if opening an other web socket needs some additional non-generic work done before it's good.
See #565
Good info was provided in WWDC2018 https://developer.apple.com/videos/play/wwdc2018/715/

Thanks @ollitapa for your contribution!


bump versions

update Go: 1.19 -> 1.21
update golangci-lint 1.54.2
update vulnarable packages

Codecov Report
Patch coverage: 68.88% and project coverage change: +0.14% :tada:

Comparison is base (f3f7422) 40.11% compared to head (24de336) 40.26%.
Report is 11 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #252      +/-   ##
==========================================
+ Coverage   40.11%   40.26%   +0.14%
==========================================
  Files          37       37
  Lines        1249     1222      -27
==========================================
- Hits          501      492       -9
+ Misses        748      730      -18

Files Changed
Coverage Δ

pkg/container/docker_client.go
75.17% <67.50%> (+3.34%)
:arrow_up:

pkg/chaos/netem/netem.go
73.68% <80.00%> (+3.09%)
:arrow_up:

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


Handbook should recommend using a user-defined homomorphic  Omit

Bug Report
Per #53188, we know that it'd be better if Omit were homomorphic. In the Handbook we should steer people toward a better user definition, e.g.
type MappedOmit<T, K extends keyof T> = { [P in keyof T as P extends K ? never : P]: T[P] };

From the user's perspective, it really feels weird to me that this is pushed into the userland.
I totally understand the argument behind not wanting to make changes to the existing Omit. You are concerned with having 2 Omits in the lib files which is also somewhat understandable. It's hard to come up with a perfect name for this, it also might confuse some people. But isn't including this in the handbook already (a) giving this a name, (b) might confuse some people? Shifting the responsibility for defining this type in the userland feels a little bit like a hygiene theater thing to me. (insert Spiderman meme here)
I also wonder what happened to destructure improvements related to MappedOmit from https://github.com/microsoft/TypeScript/pull/53134 ? This PR has been closed without any concrete conclusion about that part and the related design notes also don't address this explicitly anyhow.

insert Spiderman meme here

There are a few of these.  Which one are you referencing?

Type-fest has a similar function, which is named "Except" which would avoid confusion with the same name?

I think something like Except should be added to the standard library and Omit should be marked as deprecated, as it's quite the footgun.


Fix sporadic SyntaxError on build-apps mac job

I believe the issue is at the notarization step
Wondering if there could be some sort of concurrent thing here. But more importantly, we should only notarize on release builds (aka Cut release PR or release or nightly), and it looks like we are notarizing everywhere at the moment. This needs to be addressed


edit src/index.js

Please make sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's contributing guide (中文 | English).
[ ] Make sure you are merging your commits to dev branch.
[ ] Add some descriptions and refer relative issues for you PR.

每个组件本身存在install方法，src里面重新写了一遍，这个可以优化。

This fails tests because not all components export an install method. So we'll leave it as is.


Missing variable assignments in PowerShell script - script not working

In the "Deploy virtual network gateway" PowerShell script the variables $region and $gatewaySubnet has not previously been defined.

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

ID: a4387410-73b7-a07e-708c-eeac4e81397f
Version Independent ID: aaaab239-4acf-d9ea-c3a6-9abb0cdbb623
Content: Configure a Point-to-Site (P2S) VPN on Windows for use with Azure Files
Content Source: articles/storage/files/storage-files-configure-p2s-vpn-windows.md
Service: storage
Sub-service: files
GitHub Login: @roygara
Microsoft Alias: rogarana

@jthulstrup
Thanks for your feedback! We will investigate and update as appropriate.

Thanks for reporting this. I have assigned the issue to the content author to investigate further and update the document as appropriate.

#reassign: @khdownie

@jthulstrup thank you for pointing this out. I've updated the doc to fix this issue:
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-configure-p2s-vpn-windows

#please-close


How rasa core calls nlu model from rasa ui

@pradeepmvn hi,
I have nlu model and rasa core enabled. But when I am giving expression related to action getting core response.
but when I am trying to give user expression which is trained as Rasa NLU, still rasa core response is returned.
How can I differentiate core and nlu response

@kdigumar - sorry to hear about the issue, could you elaborate or provide some logs in this regards. I am not sure I understand your issue correctly.

Sorry too, I have nlu and core running separate servers. In rasa-uiI have added intents and trained nlu. Now I added actions(utter_) and given stories in rasa ui, and downloaded files and ran rasa core and it successfully up.
With rasa-core disable I could see good response and conversation with intents, entities, webhook.
But after enabling rasa-core in rasa ui, I am seeing empty response.
When I am trying to call rasa core via postman keeping jet authorisation, still I see empty response.
Not sure what I missed, can u suggest

@kdigumar - please add your db.sqlite file to this issue. (from the server/data folder).

hey this has been resolved. model was not exposed, created storage and exposed it worked.


Suggestion: initial index

I would like to always start the carousel with the last image the user saw in the last time he used the app. Would be nice to expose the initial index for doing it

Any news on this feature?


Make rm call a little more robust, fix typo

On an initial call, rm errors when the files are not (yet) present.  Adding -f fixes that.   And the final echo has a simple typo.

Codecov Report

Merging #37 (329b54a) into main (720b663) will increase coverage by 0.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #37      +/-   ##
==========================================
+ Coverage   91.88%   92.00%   +0.12%
==========================================
  Files           6        6
  Lines        1306     1301       -5
  Branches       47       47
==========================================
- Hits         1200     1197       -3
+ Misses         74       72       -2
  Partials       32       32

Impacted Files
Coverage Δ

src/nanoarrow/array.c
90.39% <ø> (-0.06%)
:arrow_down:

src/nanoarrow/array_inline.h
100.00% <ø> (ø)

src/nanoarrow/schema.c
91.74% <ø> (-0.02%)
:arrow_down:

src/nanoarrow/utils.c
99.03% <ø> (+1.86%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Allow adding photos to an AED being added, not just to existing ones

Feels like an oversight 😅
However, the current API requires node ID which is not present at the upload stage. This would mean splitting the upload into 3 parts: uploading a node to the OSM API to get the ID, adding a photo to our backend and then editing the node to include the image=* tag. (the last happens on the backend).
This feels extremely flimsy.
Maybe we could just make the backend upload the AED on behalf of the user? To be stateless, ditch the changeset opening and just use 1 changeset per AED. Not optimal, but nobody will use our page to bulk load AEDs.

So backend should provide interface for automatic handling of node creation/updates (frontend sends the node diff), with an option to upload an image alongside of it. Correct?

It seems like frontend uses OSM API directly, and backend is not involved in the AED creation process at all. Perhaps this should be unified so the backend performs the creation instead? @starsep

I agree. That will allow to create AED and upload photo at once.
Either in 1 or 2 request.
I would prefer one which would create AED with optional photo data as parameter.
We also have to support editing existing AED - changing tags and potentially adding a photo.

Okay then. Backend will expose methods for AED creation and edits.


Confusing error message displayed while trying to use constructor tear-off

I was trying to playing around with constructor tear-off but the dart-pad gave me an error saying
This requires the 'constructor-tearoffs' language feature to be enabled.
Try updating your pubspec.yaml to set the minimum SDK constraint to 2.14.0 or higher, and running 'pub get'.

Also, at dart-pad's bottom right, I can see Based on Flutter 2.5.3 Dart SDK 2.14.4
I think the error message should be
This requires the 'constructor-tearoffs' language feature to be enabled which requires minimum dart SDK constraint set to 2.15.0.

Hey @srawlins, who should we chat to about minimum Dart version for constructor tear offs? IIUC, DartPad stable already has the minimum Dart version set to 2.14.0 in the generated pubspec.yaml file.

That message is from an old version of Dart (2.14.3 or something). It has been corrected at HEAD.

SGTM, closing this issue out.


Automorphic Number in golang

💥 Proposal
(A clear and concise description of what the proposal is.)
Automorphic Number in golang
Have you read the Contributing Guidelines on Pull Requests?
(Write your answer here.)
yes

/assign


EditTextPreference crash with popup

See also: https://code.google.com/p/android/issues/detail?id=226014

Tried to reproduce it, but couldn't (emulator, API 23, x64).

This problem seemed to be fixed recently. But my system settings (CM14.1) is still crashing. Closing it for now anyways.


RichTextLabel::get_content_height() gives garbage after setting bbcode_text

Godot version
v3.4.beta.custom_build.42927e806
System information
X11 (Manjaro)
Issue description
After setting bbcode_text on a RichTextLabel (regardless of whether bbcode_enabled is set), the label's get_content_height() method will return an apparently-uninitialized value. This presents an issue in code like:
$RichTextLabel.bbcode_text = "Some [color=red]red[/color] text"
$RichTextLabel.rect_size.y = $RichTextLabel.get_content_height()

After the label has received NOTIFICATION_DRAW, the cached height accumulator gets updated to the correct value, however:

This doesn't help the case above, where the method is called before the label gets rendered
Setting bbcode_text again will re-uninitialize the height accumulator

Steps to reproduce
I have attached a reproducer, however I don't think there's anything special about it; any usage of RichTextLabel looks like it will exhibit this issue.
In the attached reproducer, pressing play demonstrates that Panel is not being updated to have the expected size. Further, pressing any key will cause a further iteration of the logic, which results in the value reported by get_content_height() jumping around.
On my system, a typical run looks like:
Godot Engine v3.4.beta.custom_build.42927e806 - https://godotengine.org
OpenGL ES 3.0 Renderer: NVIDIA GeForce GTX 960/PCIe/SSE2
OpenGL ES Batching: ON

get_content_height(): 0
get_content_height(): 45
get_content_height(): 53
get_content_height(): 0
get_content_height(): 0
get_content_height(): 0
get_content_height(): 0
get_content_height(): 0
get_content_height(): 45
get_content_height(): 53

Minimal reproduction project
reproducer.zip

Naively, it seems like set_bbcode() should probably be calling _validate_line_caches() after updating its text, to ensure that all the cached values are legit. But I have by no means spent enough time inside the class to fully understand its design.

When running project valgrind starts to shows hundreads of errors like:
==57336== Conditional jump or move depends on uninitialised value(s)
==57336==    at 0x377F780: Control::_size_changed() (control.cpp:1346)
==57336==    by 0x3780A1D: Control::set_margin(Margin, float) (control.cpp:1695)
==57336==    by 0x377FD94: Control::set_anchor_and_margin(Margin, float, float, bool) (control.cpp:1420)
==57336==    by 0x3893BE7: RichTextLabel::_update_scroll() (rich_text_label.cpp:923)
==57336==    by 0x389401C: RichTextLabel::_notification(int) (rich_text_label.cpp:996)
==57336==    by 0x38A7241: RichTextLabel::_notificationv(int, bool) (rich_text_label.h:38)
==57336==    by 0x46C48A4: Object::notification(int, bool) (object.cpp:927)
==57336==    by 0x3BFEF99: CanvasItem::_update_callback() (canvas_item.cpp:444)
==57336==    by 0x1863587: MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) (method_bind.gen.inc:59)
==57336==    by 0x46C4765: Object::call(StringName const&, Variant const**, int, Variant::CallError&) (object.cpp:918)
==57336==    by 0x46BAD48: MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) (message_queue.cpp:241)
==57336==    by 0x46BB048: MessageQueue::flush() (message_queue.cpp:284)
==57336==
==57336== Conditional jump or move depends on uninitialised value(s)
==57336==    at 0x38805C7: Range::set_value(double) (range.cpp:88)
==57336==    by 0x3880738: Range::set_max(double) (range.cpp:114)
==57336==    by 0x389777B: RichTextLabel::_validate_line_caches(RichTextLabel::ItemFrame*) (rich_text_label.cpp:1541)
==57336==    by 0x3893C41: RichTextLabel::_update_scroll() (rich_text_label.cpp:931)
==57336==    by 0x389401C: RichTextLabel::_notification(int) (rich_text_label.cpp:996)
==57336==    by 0x38A7241: RichTextLabel::_notificationv(int, bool) (rich_text_label.h:38)
==57336==    by 0x46C48A4: Object::notification(int, bool) (object.cpp:927)
==57336==    by 0x3BFEF99: CanvasItem::_update_callback() (canvas_item.cpp:444)
==57336==    by 0x1863587: MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) (method_bind.gen.inc:59)
==57336==    by 0x46C4765: Object::call(StringName const&, Variant const**, int, Variant::CallError&) (object.cpp:918)
==57336==    by 0x46BAD48: MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) (message_queue.cpp:241)
==57336==    by 0x46BB048: MessageQueue::flush() (message_queue.cpp:284)

Problem not happens with 4.0(valgrind also doesn't show anything)

Fixed by #56993.


nresolved compilation problems

When I run GetAccountInformation, I am prompted with the following error：
`Exception in thread "main" java.lang.Error: Unresolved compilation problems:
AutoValue_GoogleAdsClient cannot be resolved to a type
AutoValue_GoogleAdsClient cannot be resolved to a type
The method setInterceptorProvider(GrpcInterceptorProvider) in the type InstantiatingGrpcChannelProvider.Builder is not applicable for the arguments (() -> {})
The method of(E) in the type ImmutableList is not applicable for the arguments (LoggingInterceptor)

at com.google.ads.googleads.lib.GoogleAdsClient.newBuilder(GoogleAdsClient.java:69)
at com.google.ads.googleads.examples.accountmanagement.GetAccountInformation.main(GetAccountInformation.java:52)

`
Cannot find AutoValue_GoogleAdsClient file，Is there any code not submitted?

Hey, this class is generated by annotation processing during compilation. If you build and run the examples from the command line with maven you'll find that this class is properly generated.
However, some IDEs circumvent the Maven build and run their own compiler chain (I believe that you're using Eclipse, but this also applies to IntelliJ). You need to configure the project compilation settings to enable the AutoValue annotation processor.
A quick Google for enabling AutoValue in Eclipse suggests that you navigate to Project properties > Java Compiler > Annotation Processing and add these Jars to the classpath:

auto-service-1.0-rc1.jar
guava-16.0.1.jar
jsr-305-2.0.3.jar
auto-value-1.0-rc1.jar

Can you try configuring the annotation processor and see if that fixes your issue please?

I came across with the same problem and cannot fix by adding the above Jars manually.
I solved it using the method in this post. First install m2e-apt plugin in eclipse market place. After installation, go to "project properties" -> Maven -> "Annotation Processing" -> "Enable project specific settings" -> "Automatically configure JDT APT". And this worked for me.

Good to hear this is resolved. I'll close this for just now, but please feel free to reopen if issues persist.
Best wishes,
Nick


2520: Show number search results

Short description
Show the amount of search results
Proposed changes

Add counter in the SearchPage
Use searchResultsCount from translation.json

Side effects
None.
Testing
Check css styling
Resolved issues

Fixes: #2520

Thank you for the review 🌸
I think i did resolved all issue suggestions :))

Please squash the commits when you are finished, buy clicking "Squash and merge" here:


accept relative paths for pact files

as mentioned in #79, i was surprised to find that the cli did not accept paths that were relative to the project root in npm scripts. while an absolute path does work, a relative path normally works with cli tools as well.
i don't necessarily think its too limiting to only accept absolute paths, but it should at least be made more clear in the documentation that the limitation exists.
this is not a blocker for me, so this issue is just to give visibility to the confusion i ran into.

@travi yep, I tend to agree.  The issue is that the standalone binary doesn't understand relative path since it doesn't have the context (the current working directory) from your node project, hence the need for absolute paths.  However, it should be easy enough to add that functionality into the node wrapper :)
I'll try to get something out today.


Python 3.12 support

Would it be possible to support python 3.12?

Hi @david-zwicker
Sure, just became available.

Thanks! That's a lightning-fast response!


Allow to change src/main/webapp folder

In our project, we need to set the location of the folder "src/main/webapp" to "webapp". Am-I missing something or it's not possible?

Having the same issue here, so +1 to the question. :smile:
@jean-morissette - did you find any solution to this?

@jean-morissette
Why don't you try this:
apply plugin: 'war'
webAppDirName = 'webapp'

After reading some Gretty plugin source code I realized that it seems to respect this value.
It almost works for me. Almost, because in my webapp/ dir I also have all of the dependencies in WEB-APP/lib folder and Jetty complains about doubled libraries, since Gretty adds  the Gradle cache dir to the classpath... Argh!

Please try using Gretty's documented feature, extraResourceBase:
http://akhikhl.github.io/gretty-doc/Web-app-extra-resource-bases.html


Just a new proxy list with free api

Just a new proxy list with free api:
http://pzzqz.com

Thanks for your suggestions I'm looking to add in our PROXY_LIST_SCRAPPER.


Random Crashes on mac os

I am a new user. I am experiencing random crashes on startup on my Mac OS/X. The app itself is quite simple and can be found here:
https://sourceforge.net/p/gohanoi/code/ci/master/tree/
Upon cloning:
make
bin/gtk_gohanoi 8 graphic
will reproduce the problem.
It is a "Towers of Hanoi" with graphics.
It runs well sometimes but randomly crashes with the following trace:
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x7fff5130c018]
runtime stack:
runtime.throw(0x4422110, 0x2a)
/usr/local/go/src/runtime/panic.go:1116 +0x72
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:679 +0x46a
goroutine 1 [syscall]:
runtime.cgocall(0x4307de0, 0xc000161ea8, 0xc000000180)
/usr/local/go/src/runtime/cgocall.go:133 +0x5b fp=0xc000161e78 sp=0xc000161e40 pc=0x4005d0b
github.com/gotk3/gotk3/gtk._Cfunc_gtk_main()
_cgo_gotypes.go:15288 +0x41 fp=0xc000161ea8 sp=0xc000161e78 pc=0x4142991
github.com/gotk3/gotk3/gtk.Main(...)
...
...
Any ideas on how to troubleshoot will be helpful.
thanks, srini

Like almost all UI systems, drawing has to be in a single thread, called UI thread. GTK is no difference, it uses gtk main thread.
So you have to do UI updates in gtk main thread, in callback functions like "click" or "changed" event handlers. Otherwise, if you created your own goroutines and you try to update the UI in them, you have to do it through gtk.IdleAdd(). You UI update will be done in the same thread when gtk event loop is idle.

Not having much luck with this. On my other mac which is quite beefy and a later version it worked with no crashes. On this MacOS Sierra, (10.13.6) on an Early 2011 version, even with the AddIdle approach, the crashes are random.
Hopefully this section of the dump may throw some light.
goroutine 19 [runnable]:
github.com/gotk3/gotk3/glib._Cfunc_g_idle_source_new(0x6a09880)
_cgo_gotypes.go:1570 +0x4a
github.com/gotk3/gotk3/glib.IdleAdd(0x43703c0, 0x4421c60, 0xc00003ab98, 0x1, 0x1, 0x3, 0x3, 0x22)
/Users/rajasrinivasan/go/pkg/mod/github.com/gotk3/gotk3@v0.4.0/glib/glib.go:290 +0xdf
git.code.sf.net/p/gohanoi/code/gohanoi/hanoi.(*gtkVisualHanoi).Notify(0x4995b60, 0x2, 0xc000188270, 0xc0001882a0, 0x1)
/Volumes/Data/Prj/gohanoi/hanoi/gtk_visual.go:209 +0x88
git.code.sf.net/p/gohanoi/code/gohanoi/stack.(*Stack).Move(0xc000188270, 0xc0001882a0, 0x0, 0x0)
/Volumes/Data/Prj/gohanoi/stack/stack.go:126 +0xbb
git.code.sf.net/p/gohanoi/code/gohanoi/hanoi.(*Hanoi).MoveAll(0xc0001a8000, 0x1, 0xc000188270, 0xc0001882a0, 0xc0001882d0, 0x0, 0x0)
I will soon have a Linux machine and will test it out. Any other suggestions?

OH BTW,  this is functional on a RPI 3 as well.

Figured out my issues. I ended up using TimeoutAdd and did a bit of restructuring and now all is well. thanks for the pointer towards IdleAdd.


search in the blog message

replace in

let's make search only instead of search in the blog

#185


pkg/agent: properly stop ReceiveStatuses goroutine

When the node is being rebooted, the ReceiveStatuses goroutine was not being
properly stopped using the stop channel that was provided, which caused a panic
when the agent rebooted the machine.
fixes #93

Can this be done in conjunction with #110 please? The current channel handling seems atypical and odd.
Operator cmd's should create a top-level done channel (called stop) and ensure it is closed via a defer close(stop) before the program exists. Components receiving a done channel should pass the done channel on to any goroutines they spawn or create their own if they need to manage them separately. On program exit, closing the top level channel should cause all "descendant" routines to stop.

closing the channel via defer close(stop) at the top level wouldn't work in this case since the program never actually exits cleanly, which seems to be what was causing this panic in the first place. It just gets killed while it's waiting for the reboot. I can change this so it closes the channel to indicate completion instead of passing the zero value, but it seems like it would require a more fundamental change to have to top-level stop channel work correctly.
Also, I'm not sure how this and #110 are connected? They make changes to similar functions but the problems they are solving seem unrelated.

Yes, in this case the top-level stop channel is not being used. I'm working on the refactor to pass that separately, no need to wait on it.
Here the same pattern applies. Run launches a goroutine to start the watch and passes in a done channel. It happens to wait for the side effect of running that goroutine and once satisfied, the goroutine can be stopped via close(stop).
This change is a positive improvement because we avoid leaving the goroutine running after we've obtained the results we need. I don't think it solves #93 though - when the program is signaled to shutdown, there is still no mechanism that stops the launched goroutines. That'll be done by the refactor I mentioned.
Sure, let's leave #110 separate.

In short, please close the channel, then I think this is ok.

Can you be sure to leave #93 open?

Sure. I'll leave a comment on it that explains why it is still there too.


Optimize menu rendering performance for very large page trees (>10k pages)

Currently django-cms menu rendering does not perform very well with large (>10k) page trees.
With 10k pages initial menu loading from db and saving it to cache takes about 5.7s. So whenever the cache is not populated or needs to be invalidated, 5.7s is added to the request.
The following measurements were done with django-cms 3.4.1 and a fresh, empty cache:

cache type
page count
size in cache [bytes]
initial load [s]
cache.get() [s]
copy.deepcopy() [s]
apply_modifiers() [s]

redis, local
10569
632840
5.753401
0.187351
0.967989
0.093391

redis, local
378
21157
0.373353
0.006281
0.022317
0.003631

cache.get(): https://github.com/divio/django-cms/blob/3.4.1/menus/menu_pool.py#L133
copy.deepcopy(): https://github.com/divio/django-cms/blob/3.4.1/menus/menu_pool.py#L208
apply_modifiers(): https://github.com/divio/django-cms/blob/3.4.1/menus/menu_pool.py#L209-L216

MenuRenderer.get_nodes() is called for every occurance of the show_menu templatetag in the template.
Before calling copy.deepcopy(nodes) the node list is always gotten from cache with cache.get() or built from scratch. Currently the same built menu tree is fetched from cache multiple times in the same request.
copy.deepcopy(nodes) seems redundant, because the node list is a fresh one from cache every time anyway. My first impulse was to additionally cache the nodes on the request, so we don't have to fetch from cache multiple times per request. In that scenario copy.deepcopy(nodes) makes sense. But as the numbers above indicate it is actually faster to fetch from cache than deepcopying. Even for small trees.
To further optimise for large page trees, it would be great to find a way to avoid needing the whole pagetree. So have it be smart about only fetching the required pages from the database for a specific show_menu tag. This will have its caveats and incompatibilities, because menu modifiers expect to get the whole tree to modify. And cms is just one of multiple sources for nodes.

[x] small optimisation: cache.get() vs copy.deepcopy() [#5805 see czpython/feature/menu-spped-enhancements ]
[ ] complex optimization: avoid fetching whole tree too complex
[x] optimise cms menu fetching and reversing [czpython/feature/menu-spped-enhancements]

With czpython/feature/menu-spped-enhancements we've already seen page load times for the draft mode going down from 12s to 3s on a site with 10k pages.

@stefanfoulis It's not necessarily true that menu modifiers need the whole tree. In fact, when we are using soft roots, a very sensible way for menu modifiers to behave is to work on only the cut tree that is needed, rather than having to check nodes that will never appear in the menu anyway.

@evildmp yes, but the api allows it and menu modifiers can do stuff on the whole tree. So it would be a backwards incompatible change. It would also shift (duplicate) the logic of cutting out the needed part to before getting the menu.
@czpython has managed to get big performance gains without this approach already, so we'll probably get a way with not changing the api.

I can confirm @stefanfoulis's observation. In my case I have ~93k pages with that many tree nodes. Building the node-tree is way too slow: ~8 seconds. I'm currently looking for ways to partially invalidate the cache.
@evildmp

when we are using soft roots, a very sensible way for menu modifiers to behave is to work on only the cut tree that is needed

this is true for the menu modifier, but every time someone changes the visibility of a menu node and publishes that page, the whole cache is invalidated. This results in rebuilding the menu tree and saving it back to the cache – and that takes a lot of time.


Error on functional_pil.resize with accimage

🐛 Describe the bug
I think the PR https://github.com/pytorch/vision/pull/6191 broke the test_transforms.py test_accimage_resize. (detected on internal CI)
To reproduce, we should install accimage (see https://github.com/pytorch/accimage) and do the test using the following command:
pytest test_transforms.py -k test_accimage_resize

This will fail and produce stacktrace:
Traceback (most recent call last):
  File "/fsx/users/yosuamichael/repos/vision/test/test_transforms.py", line 187, in test_accimage_resize
    output = trans(accimage.Image(GRACE_HOPPER))
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/transforms.py", line 95, in __call__
    img = t(img)
  File "/fsx/users/yosuamichael/conda/envs/vision-c113/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1129, in _call_impl
    return forward_call(*input, **kwargs)
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/transforms.py", line 346, in forward
    return F.resize(img, self.size, self.interpolation, self.max_size, self.antialias)
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/functional.py", line 472, in resize
    return F_pil.resize(img, size=output_size, interpolation=pil_interpolation)
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/functional_pil.py", line 252, in resize
    return img.resize(size[::-1], interpolation)
SystemError: new style getargs format but argument is not a tuple

But strangely our current CI is green, does this mean we skip this test on our CI?
cc @vfdev-5 @datumbox
Versions
Collecting environment information...
PyTorch version: 1.12.0.dev20220419
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.3
Libc version: glibc-2.27

Python version: 3.9.12 (main, Apr  5 2022, 06:56:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.0-1069-aws-x86_64-with-glibc2.27
Is CUDA available: False
CUDA runtime version: 11.1.105
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.0.5
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.950
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.3
[pip3] pytorch-lightning==1.6.4
[pip3] pytorchvideo==0.1.5
[pip3] torch==1.12.0.dev20220419
[pip3] torchmetrics==0.9.1
[pip3] torchmultimodal==0.1.0a0
[pip3] torchvision==0.13.0a0+1316541
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               11.3.1               h2bc3f7f_2
[conda] mkl                       2022.0.1           h06a4308_117
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] pytorch                   1.12.0.dev20220419 py3.9_cuda11.3_cudnn8.3.2_0    pytorch-nightly
[conda] pytorch-lightning         1.6.4                    pypi_0    pypi
[conda] pytorch-mutex             1.0                        cuda    pytorch-nightly
[conda] pytorchvideo              0.1.5                    pypi_0    pypi
[conda] torchmetrics              0.9.1                    pypi_0    pypi
[conda] torchmultimodal           0.1.0a0                   dev_0    <develop>
[conda] torchvision               0.13.0a0+1316541           dev_0    <develop>

But strangely our current CI is green, does this mean we skip this test on our CI?

Yeah, we don't test against accimage on GH, just internally.
This kind of issue pop up rarely, but regularly. For example https://github.com/pytorch/vision/issues/5541#issuecomment-1058234058:

This comment from @fmassa seems to suggest that we actually don't support accimage anymore

We don't have Travis (nor accimage) tests anymore, closing this.

That being said, we still claim on our README that accimage is part of the supported backends. Let's wait for @fmassa 's insights before we decide to fully remove it, or actually tests against it.

IIRC, the conclusion was to do nothing. Before completely removing accimage support we'd have to figure out whether people actually rely on it internally or not.

https://github.com/pytorch/vision/pull/6208 fix this issue


Editing the index does not work

dbeaver 6.2.5
MySQL 5.6.39
driver MySQL Connector/J mysql-connector-java-8.0.17 (Revision: 16a712ddb3f826a1933ab42b0039f7fb9eebc6ec)
Nothing happens when I click the editor index

Can't reproduce. Some steps to reproduce would be helpful.

Where did you get the MySQL 5.6 driver?


pythonPackages.lightgbm: fix build on darwin

Motivation for this change
Fix build on darwin. This was a pretty hard one to debug what with cmake being the most debugging-hostile tool on the planet, and build flags that don't do what they're supposed to, but in the end I forced clang to link against libomp.dylib by using NIX_LDFLAGS.
Tested on macos 10.13.
Things done

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

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

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

Thank you for your work on this!

@GrahamcOfBorg build pythonPackages.lightgbm python3Packages.lightgbm python36Packages.lightgbm python35Packages.lightgbm


Comparing orientations?

What is the correct way to do orientation comparisons? I've tried the following, none of which work:
bool fail1 = CrossDeviceOrientation.Current == 2;
bool fail2 = CrossDeviceOrientation.Current == DeviceOrientations.Portrait;
bool fail3 = CrossDeviceOrientation.Current.Equals(DeviceOrientations.Portrait);

Coming from Swift/Obj-C, I'm sure there is some dumb thing I am doing here. Also, would be great if you included an example like this in the docs.

Hi @memmons-ntst
Current property has platform implementation of the plugin with interface IDeviceOrientation as a singleton, next step you will need to get CurrentOrientation value and compare with DeviceOrientations  enum value.
CrossDeviceOrientation.Current.CurrentOrientation == DeviceOrientations.Portrait

@wcoder  can I also do this check in pure XAML? I want to set Margin/Padding based on Idiom and Orientation status. Currently I do this in code at OnSizeAllocated but here I can't use XAML Reloader tools to see the output if I change values, here I have to compile the app again and run it again.

@MagicAndre1981 plugin doesn't provide any solutions out of the box for support from XAML.
I think you can implement your case via Xamarin.Forms Triggers.

any hint how to do this via Triggers?


Purge Spam messages

Hey,
Could you maybe add a /purge command?
Maybe with a start and a stop chat position as parameter.
E.g. to mass delete many spam messages from over night in a group.

Unfortunately, I won't be adding this function. Shieldy is a bot that prevents spam and not intended for the group management or post-fact spam removal


Add support for particulate matter cluster PM1.0, PM4.0 and PM10. (TZ-558)

Hello!
Should we expect other types of particulate matter other than esp_zigbee_zcl_pm2_5_measurement.h?
My project uses Honeywell's HPMA115C0-004 sensor which provides data such as PM1.0, PM2.5, PM4.0 and PM10.

@deviashin ,
The terms "PM1.0, PM2.5, PM4.0, and PM10" do not appear to be defined in the specification. If necessary, you can use a custom cluster to support these measurements.

I should have paid attention to this before making the request. I agree, there are no such clusters in the ZCL standard. Same as AQI. Well, let's hope they add it someday.


Fix Rancher monitoring deployment errors

Previous code did not wait after Rancher installation to install Rancher Monitoring.
Since 2.9, some Rancher components need to be ready or the installation will fail, eg.:
2024/08/29 14:50:01 chart rancher-monitoring: failed pre-install: warning: Hook pre-install rancher-monitoring/templates/alertmanager/secret.yaml failed: 1 error occurred:
        * Internal error occurred: failed calling webhook "rancher.cattle.io.secrets": failed to call webhook: Post "https://rancher-webhook.cattle-system.svc:443/v1/webhook/mutation/secrets?timeout=15s": no endpoints available fo
r service "rancher-webhook"

More components can be added if needed in the same way (eg. cattle-fleet-system/gitjob or cattle-provisioning-capi-system/capi-controller-manager, which did not pop up in my own tests but might turn out to be relevant).
Note this PR contains commits from #4, which should be merged first. Then this should merge without conflicts.

LGTM, waiting on #6 to be merged before approving + merging

Rebased on main, PR is now clean from extraneous commits