Improve the grammar of the sentence

This pull request includes a small change to the CONTRIBUTING_EN.md file. The change improves the wording to make the invitation to contribute more welcoming and clear.

CONTRIBUTING_EN.md: Updated the introductory sentence to be more inviting and clear.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 43.58%. Comparing base (ef31e09) to head (3bfe3d2).
Report is 163 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1426      +/-   ##
==========================================
+ Coverage   35.91%   43.58%   +7.67%
==========================================
  Files          69       76       +7
  Lines       11576    12320     +744
==========================================
+ Hits         4157     5370    +1213
+ Misses       7104     6616     -488
- Partials      315      334      +19

see 69 files with indirect coverage changes


Fix VPN bug: Nearest city breaks register requests (#770)

Handle stored Nearest city values

Actually use the amended city value

Please review the release process for BrowserServicesKit here.
Required:
Task/Issue URL:
iOS PR:
macOS PR:
What kind of version bump will this require?: Major/Minor/Patch
Optional:
Tech Design URL:
CC:
Description:

Steps to test this PR:
1.
1.

OS Testing:

[ ] iOS 14
[ ] iOS 15
[ ] iOS 16
[ ] macOS 10.15
[ ] macOS 11
[ ] macOS 12

Internal references:
Software Engineering Expectations
Technical Design Template

Reviewed in #770


can this generate snaps for all existing components?

Hey this looks cool but I'm confused - your readme says you parse the components with the react doc gen, then generate tests - but then the api looks like you have to run this for  each component, which frankly would be nearly as much work as just writing the test itself!  Is there a CLI option or something to discover and auto write the tests? Also can you include .js components too, as the app I'm working on doesn't use .jsx?  Looks like a promising project, not just for snapshots but could reduce boilerplate aspects of writing new tests for each component.
thanks!

Hey @mspanish!

Also can you include .js components too
Getting the smaller question out of the way: it should work with .js files (snap(MyComponent, '../MyComponent.js');)

your readme says you parse the components with the react doc gen
Yep, when the component is passed to the package it reads the component script file and parses it for propTypes.

This project is still a bit of a work in progress - I created it because the web app I'm working on has a lot of small, stateless, presentational components. I wanted to cover those specific components in snapshot tests, but found the maintenance cumbersome...
Take <Thing  active />, for example. For this simple component to be covered in snapshot tests it would look something like:
describe('Thing', () => {
  it('Should match snapshot when `active` is `true`', () => {
    const wrapper = shallow(<Thing active />);
    expect(wrapper).toMatchSnapshot();
  });
  it('Should match snapshot when `active` is `false`', () => {
    const wrapper = shallow(<Thing active={false} />);
    expect(wrapper).toMatchSnapshot();
  });
});

As compared to:
snap(Thing, '../Thing.jsx');
Granted, this is a super simple example, and it doesn't take that long to write those tests. However, if props are added or changed in the component (ex: <Thing isActive user="Me"} />) you now have to go back, edit, and add new snapshot tests. This is really the core value of this package at the moment.
All that to say...
I like the idea of a CLI tool! I'm torn because ideally, instead of running these automated snapshots in the background, it would be nice to be able to generate a x.test.js file instead. The problem is that I also want it to be able to adapt as propTypes change in a component. So how would it know when to update/rewrite a test file? Especially after someone might edit it to add/change tests 🤔
In the short-term, would a simple CLI tool be an improvement? Something along the lines of jest-auto-snapshots generate ./src/Thing.jsx --> __tests__/Thing.test.js --> snap(Thing, '../Thing.jsx')?

Closing this due to inactivity, but will re-open if this feature is requested by other people!

@icd2k3 a CLI tool would be fantastic. Adding on to your comments:

In the short-term, would a simple CLI tool be an improvement? Something along the lines of...
jest-auto-snapshots generate ./src/Thing.jsx
which generates...
tests/Thing.test.js
which has code...
snap(Thing, '../Thing.jsx')?

My particular use case would be adding snapshot tests to all current components that don't have tests currently. The tool would recursively search for files in any components directory and then auto-generate the Thing.test.js files with the code, per your suggestion.
I wouldn't really need the ability to adapt as propTypes changes.

My particular use case would be adding snapshot tests to all current components that don't have tests currently. The tool would recursively search for files in any components directory and then auto-generate the Thing.test.js files with the code, per your suggestion.

This resonates with me as well... Maybe it could create files with the names Thing.snap.test.js or something? So it wouldn't interfere with any other custom tests the user wants to write 🤔. Unfortunately, I'm not sure when I'll have time to implement this, though.


[BUG] Set secret operation of the Key Vault Secrets Client overrides the content type of the secret with application/json

Description

Fixes sync and async implementations to use the contentType value set by the caller in the payload
Adds entry to changelog

Resolves https://github.com/Azure/azure-sdk-for-java/issues/37019
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

Hi,
I wasn't sure how to modify the test data for the mock/stub used. Could you please let me know how to add a new assertion?
Thank you in advance!

@nagyesta The root cause analysis is spot on and the proposed changes look good on principle, but they required a bit more tinkering to keep things working as they used to before the latest release. Additionally, there were other setSecret... and updateSecret... methods with this issue to update as well. I took the liberty of creating a PR with these changes against your branch to keep your authorship for when we eventually merge into main, feel free to review it and merge into your branch when you get a chance.

We auto-generate some of the code found in this library and I'm not 100% sure yet about if we'll need to account for that with these changes. If that's the case I will take care of it on a separate PR.

Hi @vcolin7 ,
thank you very much for the PR and apologies for missing those! I have merged your changes into my branch.
Please let me know in case anything comes up, I am happy to help!

@nagyesta No worries, thank you for opening the issue and taking things in the right direction! I added a couple of things I missed in my original PR and re-recorded our tests (we use test recordings to avoid testing against the service every time).


Scrcpy interaction with OPPO Phone is not working

I have tried scrcpy and various guidelines for mirroring phones via scrcpy but it seems that the interaction with keyboard and mouse and audio does not work with my OPPO F11.
Help

https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#mouse-and-keyboard-do-not-work
?

Yes, I have already read that. But based in my phone I don't have such option for that. I even looked entirely in my phone, but I haven't found any option for it.

Any hint in adb logcat?
What happens if you focus some text area on your device, and execute adb shell input text hello from your computer?

Cant seem to find any hint in the logcat.
adb shell input text hello worked

adb shell input text hello worked

Oh, that's very weird, then. Pressing h e l l o in the scrcpy windows does not work?
What if you start with scrcpy --prefer-text?

Hello. Here is the result for the scrcpy --prefer-text.

But what happens when you enter text in the scrcpy window?

Hmmm. Somehow, typing in the keyboard worked in scrcpy. But the mouse still does not interact

Probably similar to #1347.
Does this work: https://github.com/Genymobile/scrcpy/issues/1347#issuecomment-624039383

Yea. It some how tapped my screen.

Please test with older versions of scrcpy, if you find one which work, it will help a lot to find the cause.

I have tried versions down to v1.4, scroll wheel and left mouse button does not work. Middle click and right click worked as well as the keyboard.

Same phone (F11 Pro), same situation, most keyboard, mid click & right click works except left click.

adb shell input tap 179 179

Does it work or not?

yup the command works. but left click doesnt

Oh, could you test with that change, please?

Oh, could you test with this change, please:
diff --git a/app/src/input_manager.c b/app/src/input_manager.c
index 9c22ee0a..7d500efe 100644
--- a/app/src/input_manager.c
+++ b/app/src/input_manager.c
@@ -511,7 +511,8 @@ convert_mouse_button(const SDL_MouseButtonEvent *from, struct screen *screen,
     to->inject_touch_event.position.screen_size = screen->frame_size;
     to->inject_touch_event.position.point =
         screen_convert_window_to_frame_coords(screen, from->x, from->y);
-    to->inject_touch_event.pressure = 1.f;
+    to->inject_touch_event.pressure =
+        from->type == SDL_MOUSEBUTTONDOWN ? 1.f : 0.f;
     to->inject_touch_event.buttons =
         convert_mouse_buttons(SDL_BUTTON(from->button));

no difference

no difference.

Could you please test this change instead:
diff --git a/server/src/main/java/com/genymobile/scrcpy/Controller.java b/server/src/main/java/com/genymobile/scrcpy/Controller.java
index 71e7ec9c..1f249225 100644
--- a/server/src/main/java/com/genymobile/scrcpy/Controller.java
+++ b/server/src/main/java/com/genymobile/scrcpy/Controller.java
@@ -11,7 +11,7 @@ import java.io.IOException;

 public class Controller {

-    private static final int DEVICE_ID_VIRTUAL = -1;
+    private static final int DEVICE_ID_VIRTUAL = 0;

     private final Device device;
     private final DesktopConnection connection;

can i have your full input_manager.c?

(I use the one from current dev branch)
Note: adb shell input tap ... calls this: https://github.com/aosp-mirror/platform_frameworks_base/blob/22e3e74e4b3b989d20bb17ca7d54f95b67d6c02c/cmds/input/src/com/android/commands/input/Input.java#L221-L226

i got nothing (instead and in-addition).

@GetCurious OK, just to be sure, you are building the server (you don't use the prebuilt-server)?
What we have to understand is why this works (adb shell input tap ...): https://github.com/aosp-mirror/platform_frameworks_base/blob/22e3e74e4b3b989d20bb17ca7d54f95b67d6c02c/cmds/input/src/com/android/commands/input/Input.java#L221-L226
but this does not:
https://github.com/Genymobile/scrcpy/blob/5fa46ad0c71169f9369f9f3bde9cce3d29ed4b88/server/src/main/java/com/genymobile/scrcpy/Controller.java#L198-L200

$ cd scrcpy
$ vim app/src/input_manager.c
$ vim server/src/main/java/com/genymobile/scrcpy/Controller.java
$ meson x --buildtype release --strip -Db_lto=true
$ ninja -Cx
$ ./run x

anything i miss?

Let's try to use a device id matching the input source, like they do:
diff --git a/server/src/main/java/com/genymobile/scrcpy/Controller.java b/server/src/main/java/com/genymobile/scrcpy/Controller.java
index 71e7ec9c..c1949f36 100644
--- a/server/src/main/java/com/genymobile/scrcpy/Controller.java
+++ b/server/src/main/java/com/genymobile/scrcpy/Controller.java
@@ -195,12 +195,26 @@ public class Controller {
             }
         }

+        int deviceId = getInputDeviceId(InputDevice.SOURCE_TOUCHSCREEN);
+        Ln.i("device id = " + deviceId);
         MotionEvent event = MotionEvent
-                .obtain(lastTouchDown, now, action, pointerCount, pointerProperties, pointerCoords, 0, buttons, 1f, 1f, DEVICE_ID_VIRTUAL, 0,
+                .obtain(lastTouchDown, now, action, pointerCount, pointerProperties, pointerCoords, 0, buttons, 1f, 1f, deviceId, 0,
                         InputDevice.SOURCE_TOUCHSCREEN, 0);
         return device.injectEvent(event);
     }

+    private static int getInputDeviceId(int inputSource) {
+        final int DEFAULT_DEVICE_ID = 0;
+        int[] devIds = InputDevice.getDeviceIds();
+        for (int devId : devIds) {
+            InputDevice inputDev = InputDevice.getDevice(devId);
+            if (inputDev.supportsSource(inputSource)) {
+                return devId;
+            }
+        }
+        return DEFAULT_DEVICE_ID;
+    }
+
     private boolean injectScroll(Position position, int hScroll, int vScroll) {
         long now = SystemClock.uptimeMillis();
         Point point = device.getPhysicalPoint(position);

no difference

What's the id printed in the console when you click with this change?

how do i do that?

When you execute ./run x, what is the output in the console?

➜  scrcpy git:(dev) ✗ ./run x
INFO: scrcpy 1.14 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 107.0 MB/s (33374 bytes in 0.000s)
[server] INFO: Device: OPPO CPH1969 (Android 10)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6.0 NVIDIA 440.100
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2336
INFO: New texture: 888x1920

And nothing more, even when you click in the scrcpy window?

that's right... nothing more

With that change: https://github.com/Genymobile/scrcpy/issues/1518#issuecomment-655440431 it should, since a log is added on every click.
Unless the client does not send the events to the device. Let's add more logs:
diff --git a/app/src/input_manager.c b/app/src/input_manager.c
index 7d500efe..fc0edb6d 100644
--- a/app/src/input_manager.c
+++ b/app/src/input_manager.c
@@ -523,6 +523,14 @@ void
 input_manager_process_mouse_button(struct input_manager *im,
                                    const SDL_MouseButtonEvent *event,
                                    bool control) {
+    LOGI("mouse button: type=%d, which=%d, button=%d, state=%d, clicks=%d, x=%d, y=%d",
+            (int) event->type,
+            (int) event->which,
+            (int) event->button,
+            (int) event->state,
+            (int) event->clicks,
+            (int) event->x,
+            (int) event->y);
     if (event->which == SDL_TOUCH_MOUSEID) {
         // simulated from touch events, so it's a duplicate
         return;
@@ -559,9 +567,12 @@ input_manager_process_mouse_button(struct input_manager *im,

     struct control_msg msg;
     if (convert_mouse_button(event, im->screen, &msg)) {
+        LOGI("==== convert_mouse_button OK");
         if (!controller_push_msg(im->controller, &msg)) {
             LOGW("Could not request 'inject mouse button event'");
         }
+    } else {
+        LOGW("==== convert_mouse_button KO");
     }
 }

INFO: ==== convert_mouse_button OK

OK, so the events are correctly forwarded by the client.
One more diff:
diff --git a/server/src/main/java/com/genymobile/scrcpy/Controller.java b/server/src/main/java/com/genymobile/scrcpy/Controller.java
index 71e7ec9c..1a5fad7f 100644
--- a/server/src/main/java/com/genymobile/scrcpy/Controller.java
+++ b/server/src/main/java/com/genymobile/scrcpy/Controller.java
@@ -71,6 +71,7 @@ public class Controller {

     private void handleEvent() throws IOException {
         ControlMessage msg = connection.receiveControlMessage();
+        Ln.i("Received msg type = " + msg.getType());
         switch (msg.getType()) {
             case ControlMessage.TYPE_INJECT_KEYCODE:
                 if (device.supportsInputEvents()) {
@@ -163,6 +164,7 @@ public class Controller {

     private boolean injectTouch(int action, long pointerId, Position position, float pressure, int buttons) {
         long now = SystemClock.uptimeMillis();
+        Ln.i("=== injectTouch");

         Point point = device.getPhysicalPoint(position);
         if (point == null) {
@@ -170,6 +172,8 @@ public class Controller {
             return false;
         }

+        Ln.i("Point = " + point);
+
         int pointerIndex = pointersState.getPointerIndex(pointerId);
         if (pointerIndex == -1) {
             Ln.w("Too many pointers for touch event");

https://github.com/Genymobile/scrcpy/issues/1518#issuecomment-655499111

But probably not related.

Oh in fact, that might be related: the client sends clicks for a window having different dimensions as the ones provided by the device.
If you remove these lines, it should "work" (it may click at a wrong location though):
https://github.com/Genymobile/scrcpy/blob/e99b896ae2b6a59d5f7f2b76a3dd9c29f4838013/server/src/main/java/com/genymobile/scrcpy/Device.java#L134-L138

INFO: Initial texture: 1080x2336
INFO: New texture: 888x1920

What if you run scrcpy -m1920? Do clicks work in that case?

what the...
scrcpy -m1920 worked

One more test, please (with just ./run x, without -m parameter):
diff --git a/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java b/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java
index d722388c..41afd35b 100644
--- a/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java
+++ b/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java
@@ -82,6 +82,9 @@ public class ScreenEncoder implements Device.RotationListener {

                 setSize(format, videoRect.width(), videoRect.height());
                 configure(codec, format);
+                MediaFormat actualFormat = codec.getInputFormat();
+                Ln.i("width = " + actualFormat.getInteger(MediaFormat.KEY_WIDTH));
+                Ln.i("height = " + actualFormat.getInteger(MediaFormat.KEY_HEIGHT));
                 Surface surface = codec.createInputSurface();
                 setDisplaySurface(display, surface, videoRotation, contentRect, unlockedVideoRect, layerStack);
                 codec.start();

[server] INFO: width = 2336
[server] INFO: height = 1080

OK, and with
MediaFormat actualFormat = codec.getOutputFormat();

instead of
MediaFormat actualFormat = codec.getInputFormat();

?

INFO: scrcpy 1.14 <https://github.com/Genymobile/scrcpy>
...
INFO: Initial texture: 1080x2336
[server] INFO: width = 1080
[server] INFO: height = 2336
INFO: New texture: 888x1920

OK, thank you for the tests.
So on the device, we request a specific size (1080x2336), the codec decides to encode in 888x1920 instead (probably because it does not support higher definition), but we can't know what size it decided without decoding the frames :confused:

Just in case, try to move it after the codec is started:
diff --git a/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java b/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java
index d722388c..3ee09aad 100644
--- a/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java
+++ b/server/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java
@@ -104,6 +104,10 @@ public class ScreenEncoder implements Device.RotationListener {
         boolean eof = false;
         MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();

+        MediaFormat actualFormat = codec.getOutputFormat();
+        Ln.i("width = " + actualFormat.getInteger(MediaFormat.KEY_WIDTH));
+        Ln.i("height = " + actualFormat.getInteger(MediaFormat.KEY_HEIGHT));
+
         while (!consumeRotationChange() && !eof) {
             int outputBufferId = codec.dequeueOutputBuffer(bufferInfo, -1);
             eof = (bufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0;

INFO: scrcpy 1.14 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 159.5 MB/s (33294 bytes in 0.000s)
[server] INFO: Device: OPPO CPH1969 (Android 10)
[server] INFO: width = 1080
[server] INFO: height = 2336

[server] INFO: encode width = 1080
[server] INFO: encode height = 2336

INFO: OpenGL shaders: ENABLED
INFO: Created renderer: opengl
INFO: Renderer: opengl
INFO: OpenGL version: 4.6.0 NVIDIA 440.100
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2336
INFO: New texture: 888x1920

i am also getting  same problem. i have oppo f1. I HAVE tried all different version of scrcpy but nothing worked. help me if you are able to correct it

@swamikamal I just gave you the solution: https://github.com/Genymobile/scrcpy/issues/1645#issuecomment-670433990

May I join this party. I have a Xioami with Adnroid 7.1. and the tip from #1645 does not help.

@eku whtat is the full output in your console when you run scrcpy?

@rom1v
$ ./run x -b 2M -m 960
INFO: scrcpy 1.16 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed. 1.9 MB/s (33634 bytes in 0.017s)
[server] INFO: Device: Xiaomi MI MAX 2 (Android 7.1.1)
INFO: Renderer: opengl
INFO: OpenGL version: 3.0 Mesa 20.1.5
INFO: Trilinear filtering enabled
INFO: Initial texture: 544x960

That's all. Scrcpy receives e.g. meta-key combinations and logs them but there is no reaction of the device.
[server] INFO: Device rotation requested: landscape

Nothing happens.

https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#mouse-and-keyboard-do-not-work

Yes, I know the FAQ and this point. The setting also exists in my phone but cannot be changed for unknown reason.
Please excuse the disturbance by me.

okay, after two hours of trying i finally found out the solution. just  run this command in terminal
(sudo apt install adb ffmpeg libsdl2-2.0-0 make gcc pkg-config meson ninja-build libavcodec-dev libavformat-dev libavutil-dev libsdl2-dev) and after that run scrcpy -m1920 in terminal.
enjoy.

okay, after two hours of trying i finally found out the solution. just  run this command in terminal
(sudo apt install adb ffmpeg libsdl2-2.0-0 make gcc pkg-config meson ninja-build libavcodec-dev libavformat-dev libavutil-dev libsdl2-dev) and after that run scrcpy -m1920 in terminal.
enjoy.

and for the desktop entry in linux (ubuntu) just create a  file under /usr/share/applications/scrcpy.desktop
[Desktop Entry]
Version=1.0
Type=Application
Name=scrcpy
GenericName=scrcpy
Comment=Screen mirroring application
Exec=scrcpy -m1920%F
Icon=phone-symbolic
Terminal=false
X-MultipleArgs=false
Categories=Development;GTK;
StartupNotify=true

and for the desktop entry in linux (ubuntu) just create a  file under /usr/share/applications/scrcpy.desktop
[Desktop Entry]
Version=1.0
Type=Application
Name=scrcpy
GenericName=scrcpy
Comment=Screen mirroring application
Exec=scrcpy -m1920%F
Icon=phone-symbolic
Terminal=false
X-MultipleArgs=false
Categories=Development;GTK;
StartupNotify=true

In case this helps troubleshoot the display size issues:
tl;dr
scrcpy cuts off part of the screen instead of scaling it.  1200x1920 gets cut down to 1080x1900.  -m 1700 fixes it.
My Lenovo tablet has a 1920x1200 screen.  scrcpy outputs 1920x1080 and the other 120 pixels are just cut off.  In portrait mode, the right side of the screen is cut off.  In landscape, the bottom of the screen is missing.  Touch events do not work.
scrcpy -m 1920   # does not help
scrcpy -m 1700   # seems to work, entire screen is displayed, touch works
I don't know the exact point, but values over 1700 work, less than 1700 or so do not.  1700 seems like an odd value to fix the issue.  Maybe the anomaly will help diagnose the root cause.

scrcpy
scrcpy 1.24 https://github.com/Genymobile/scrcpy
scrcpy-server: 1 file pushed, 0 skipped. 145.9 MB/s (41159 bytes in 0.000s)
[server] INFO: Device: LENOVO Lenovo TB-X606F (Android 10)
INFO: Renderer: direct3d
INFO: Initial texture: 1200x1920
INFO: New texture: 1080x1920
[server] WARN: Ignore touch event, it was generated for a different device size

scrcpy 1.24 <https://github.com/Genymobile/scrcpy>
/opt/local/share/scrcpy/scrcpy-server:...ped. 46.3 MB/s (41159 bytes in 0.001s)
[server] INFO: Device: OPPO PACM00 (Android 10)
2024-03-15 16:30:17.679 scrcpy[9815:243314] INFO: Renderer: metal
2024-03-15 16:30:17.686 scrcpy[9815:243314] ERROR: Could not open image codec: /opt/local/share/icons/hicolor/256x256/apps/scrcpy.png
2024-03-15 16:30:17.686 scrcpy[9815:243314] WARN: Could not load icon
2024-03-15 16:30:17.686 scrcpy[9815:243314] INFO: Initial texture: 1080x2280
2024-03-15 16:30:18.087 scrcpy[9815:243314] INFO: New texture: 910x1920
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size
[server] WARN: Ignore touch event, it was generated for a different device size

@hhhaiai see #1645/

@hhhaiai And also:

scrcpy 1.24

Ultra-old. You should upgrade to the latest version.

@hhhaiai And also:

scrcpy 1.24

Ultra-old. You should upgrade to the latest version.

ok

@hhhaiai And also:

scrcpy 1.24

Ultra-old. You should upgrade to the latest version.

already update 2.4, still has same exception

@hhhaiai #1645
scrcpy -m1920

scrcpy -m1920

It's ok。  why not auto support  general size.
3Q~~

@hhhaiai #1645
scrcpy -m1920

very 3Q. this play is OK .  "scrcpy -m1920"  ,the oppo phone size "INFO: Texture: 912x1920"
check size and update

why not auto support general size.

Because this is a bug in the encoder: we request a size, it produces a video with a different size without notice (and we can't know that easily on the device side without parsing the encoded video stream).
In general, scrcpy tries a size, then attempts a smaller size if it fails… But some encoders don't fail, but decide to produce a video with a different size instead.

The actual resolution is detected on the client side, once the video stream is parsed/decoded.
The server side thinks the resolution it requested.
When then client sends a mouse events, the server detects a mismatch (which can happen in expected conditions like when the device is physically rotated between the instant an event is triggered on the client side and the time it is injected on the server side), hence the error.

The actual resolution is detected on the client side, once the video stream is parsed/decoded.
The server side thinks the resolution is what it requested.
When then client sends a mouse events, the server detects a mismatch (which can happen in expected conditions like when the device is physically rotated between the instant an event is triggered on the client side and the time it is injected on the server side), and ignores the event (with a warning).

How is this solution (* * scrcpy - m1920 * ) implemented?
When the user types the * * scrcpy * * command, they do not directly start the operation. Instead, they first check the resolution and obtain the truly operable resolution ( * INFO: Texture: 910x1920 * ). At this time, they work according to the implementation of the scheme ( * scrcpy - m1920 * *).
Equivalent to, after default detection, we input different resolutions to different devices, and 'scrcpy' is approximately equal to the dynamic parsing resolution, and then execute 'scrcpy - m1920'`

Instead, they first check the resolution and obtain the truly operable resolution

That's a lot of work / round trip / guess to workaround an encoder bug which impacts only few devices.
Btw, in some cases -m1920 does not fix the problem, because many encoders require both dimensions to be a multiple of 8 (for example see #1645 (comment)). And you would have to handle this encoder bug on rotation too (the encoder might accept the initial size, but after a rotation the width or height exceeds its maximum and sends a video with another size). Anyway, a good solution would be to make the encoder fail if it does not support the requested size, but that's up to the encoders implementations.
Btw, you could try with another encoder.

What you said is indeed an issue, and compatibility issues with a few devices are indeed a troublesome matter
Replace the encoder as per your proposal
$scrcpy -- list encoders
Scrcpy 2.4< https://github.com/Genymobile/scrcpy >
INFO: ADB device found:
INFO: -->(USB) PVRKRAAV8IBININ device PACM00
/Usr/local/Cellar/scrcpy/2.4/share/scrcpy/scrcpy server: 1 file pushed, 0 skipped 282.3 MB/s (69007 bytes in 0.000s)
[server] INFO: Device: [OPPO] OPPO PACM00 (Android 10)
[server] INFO: List of video encoders:
--Video code=h264-- video encoder='OMX MTK VIDEO ENCODER AVC '
--Video code=h264-- video encoder='c2. android. avc. encoder '
--Video code=h264-- video encoder='OMX. Google. h264. encoder '
[server] INFO: List of audio encoders:
--Audio code=opus -- audio encoder='c2. android. opus. encoder '
--Audio code=aac -- audio encoder='OMX. Google. aac. encoder '
--Audio code=aac -- audio encoder='c2. android. aac. encoder '
--Audio code=flac -- audio encoder='OMX. Google. flac. encoder '
--Audio code=flac -- audio encoder='c2. android. flac. encoder '

There are two decoders that can work. Can the decoders be dynamically switched during operation
#Success
--Video code=h264-- video encoder='c2. android. avc. encoder '
--Video code=h264-- video encoder='OMX. Google. h264. encoder '

it is expected that the number of devices with this issue will continue to increase.

Why that? If the encoder does not support the requested size, it should fail (as most of encoders do).
Also, another problem is that the encoder produces a video at a different resolution than that requested, but we don't know how the video is scaled/cropped (some may add some black borders, other may stretch the video…), so we don't know for sure how to map input events back to thebdevice coordinates. Btw, in your case, one dimension is 910, which is not even a multiple of 8.

Can the decoders be dynamically switched during operation

No, one must be explicitly selected. There is no absolute criteria to select "the best".

it is expected that the number of devices with this issue will continue to increase.

Why that? If the encoder does not support the requested size, it should fail (as most of encoders do).
Also, another problem is that the encoder produces a video at a different resolution than that requested, but we don't know how the video is scaled/cropped (some may add some black borders, other may stretch the video…), so we don't know for sure how to map input events back to thebdevice coordinates. Btw, in your case, one dimension is 910, which is not even a multiple of 8.

Can the decoders be dynamically switched during operation

No, one must be explicitly selected. There is no absolute criteria to select "the best".

ok.  3Q

#1518 (comment)

But probably not related.

Oh in fact, that might be related: the client sends clicks for a window having dimensions different from the ones provided by the device.
If you remove these lines, it should "work" (it may click at a wrong location though):
https://github.com/Genymobile/scrcpy/blob/e99b896ae2b6a59d5f7f2b76a3dd9c29f4838013/server/src/main/java/com/genymobile/scrcpy/Device.java#L134-L138

INFO: Initial texture: 1080x2336
INFO: New texture: 888x1920

What if you run scrcpy -m1920? Do clicks work in that case?

Hey man I am new to all this can you guide me through all that I have to do for this to work?

@riotcult Read https://github.com/Genymobile/scrcpy/blob/master/doc/windows.md#run
Execute scrcpy -m1920.


Crash with CreativeCore

Describe the bug
Trying to run CreativeCore with Forgified Fabric API crashing game.
Steps to reproduce

Install CreativeCore v2.10.34 Forge, and Forgified Fabric API 1.9.8 .
Run the game.
Crash without crashlog.

Logs
https://pastebin.com/spiGmDVK
Additional context
I will report other mods if I find that crash and hope we can get as many fixes as possible !
I love the mod very much but bugs like this are making it sadly unusable xD

to clarify - this means Connector will be able to run CreativeCore together w FFAPI?

You can open the CreativeCore jar file and delete the net folder. There is no other way to solve this issue because CreativeCore and Forgified Fabric API do the same thing. CreativeCore also acts as a universal loader so that mods like ItemPhysic, EnhancedVisuals, AmbientSounds work on both Fabric and Forge. It only includes a very limited amount of fabric classes, but it is already enough to break everything.

Actually the newest version of CreativeCore should work with this mod.


more tests for ptr_offset_from_unsinged

We mostly rely on the CTFE tests in rustc that look at this intrinsic a lot, but let's have at least one test here as well.

@bors r+

:pushpin: Commit 8f3b594d1ee94e5e908ea6a775560f3c7ab695e7 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit 8f3b594d1ee94e5e908ea6a775560f3c7ab695e7 with merge fff47429d9aa6058328f634c641c1710448f217d...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing fff47429d9aa6058328f634c641c1710448f217d to master...


Could not find module 'e:\Anaconda\envs\torch_v1\lib\site-packages\bitsandbytes\libbitsandbytes_cuda120.dll' (or one of its dependencies). Try using the full path with constructor syntax.

Cuda version 12.0 and python 3.9.16.
bitsandbytes-0.38.1-py3-none-any.whl  fits cuda 12.0 but why cuda setup failed??

Le estoy muy agradecido

2 things to try:

Install the correct wheel from releases either directly or with the command shown in the README.
Run this command in your env and post the output so I can determine if Pytorch is installed correctly or not:

python -m torch.utils.collect_env


About training images in SF-XL

Hi, I just downloaded SF-XL, and used this repo to train on them. Because I was doubt if there was a mistake about downloading. I would like to ensure that if this image number seems correct to you?

2023-10-09 00:46:28   Searching images in /data1/shaoshihao/sf_xl/train with glob()
2023-10-09 00:47:11   Found 3431092 images

Thanks in advance!

Yes, the number is correct.
Those 3.4M images are 360° panoramas of resolution 3328 x 512 pixels. During training, a panorama is loaded, and from it an image is cropped with the needed orientation and with resolution 512 x 512.
Note that because panoramas are quite heavy, data loading could be the bottleneck so it is advised to keep those images on a fast SSD.


Dafny tests: verification vs runtime

Most files in /src/test/dafny aren't runtime tests and instead only exercise the verifier. It would be good to clarify what each does.
The ones that are runtime tests need their own build stage.
The ones that aren't, probably don't and slow the build. Even, are they redundant?

Yeah, so there is definitely a discrepancy here.  Let's take two examples:
From ByteTests.dfy:
 method {:test} ReadTests() {
        // U8
        Assert(() => ReadUint8([],0) == 0);
        Assert(() => ReadUint8([0],0) == 0);
        ...
 }

Versus this from Test10:
method {:test} main1() {
        var vm := EvmBerlin.InitEmpty(0);
        var a: u8 := 0x01;
        var b: u8 := 0x02;
        ghost var st := vm.GetStack();
        vm := Push1(vm, a);
        vm := Push1(vm, b);
        vm := Add(vm);
        assert vm.Peek(0) as nat == (a + b) as nat;
        vm := Pop(vm);
        assert vm.GetStack() == st;
    }

For the record, the key difference here is the use of Assert() in the first but only assert in the latter.  This means that the latter assertion is not being tested at runtime.  The reason for both verifying and executing these tests may seem odd as, if the test is verified as correct, then it should execute correctly (right?).  Well, the point is capture mis-compilations by the supported Dafny backends (of which we have found a few issues already).
In the above case, we can replace the assert as follows:
     ...
     Assert(() => vm.Peek(0) as nat == (a + b) as nat);
     ...

That is fine.  For the second assert we get this:
    ...
    Assert(() => vm.GetStack() == st);
    ...

This fails because st is marked as ghost.  If we remove that modifier, then it works.

The above illustrates a situation where we can convert a test from using assert to using Assert().  Points to note:

(Do) Wherever we can convert assert to Assert(), we should do so.

(Maybe) In some cases, the conversion doesn't make sense (e.g. inc_proof() in FM-paper.dfy).  Note, however, we may still be able to do the conversion --- it just won't add anything new.

So, for that particular example I made it work with these changes:
include "../../dafny/evms/berlin.dfy"
include "utils.dfy"

/** Provide some tests to check some qualitative properties of bytecode.
 *
 *  We use an EVM with no gas as the bytecode high-level instructions
 *  like `Push1` do not consume gas.
 */
module Test10 {
    ...
    import Stack
    import opened Utils

    /**
     *   A very simple linear program manipulating the stack.
     *
     */
    method {:test} main1()
    {
        ...
        Assert(() => vm.Peek(0) as nat == (a + b) as nat);

Well, the point of calling it Assert is exactly to make clear the close connection with assert!  Another name is possible if we can find a good one.  Random thoughts: RuntimeAssert(), ExecutableAssert(), RunnableAssert() ... dunno.

I'd vote AssertAndExpect 😇

Well, it's long.  But, it does what it says on the tin.  The other ones I thought of were DoubleAssert, DualAssert, etc.

To clarify, I am happy with AssertAndExpect.  If you want to make that change, then raise a separate issue for it.  I would then have a second issue which is to convert all existing tests to use AssertAndExpect, and to add modules as necessary.

(adding modules as necessary for this to work)

I think the main place that was needed was in the utils.dfy file itself which I already did... but didn't look deeper.


[outline] add "expand all" and "collapse all" options

Clicking on the Outline section returns the tree view fully expanded. This seems quite overwhelming at first glance for large codes and also requires extensive scrolling. It would be amazing to have an "expand all - collapse all" toggle option. So when going to the outline section, it won't bombard the user with the entire tree-view rather display a more simplified structure where the user would expand and collapse sections according to their preferences afterward. Because currently, at initial click I go to the outline section and then have to manually collapse all the tree views that I don't require at the time to reduce over-exposure.

See #53262


p2p documentation

Description
What is the project status? When can we expect more documentation? Im particularly interested in mining and building test nodes.

Hi, currently we are in testnet but still in active development and have a lot of things still to build before we can go to mainnet. We will be re-organising the github and wiki and writing documentation and over the next couple of weeks. If you would like to get involved in anyway please feel free to join the telegram channel and message me there -> https://t.me/sushichainhq - I'll be able to give out coins and money for contributors once we get a bit further along

This is in progress still


WSServer -> ServerWS

Thanks again. This is simply replacing WSServer -> ServerWS everywhere?
Since you haven't based this off the latest commit in the branch, it will be easier to close this PR and sync your fork ( 'git fetch upstream', make another fork or whatever suits your way of using git).
I'll be able to put in some work here tomorrow evening.

Yeah. I didn't realize you were also making modifications for HTTP v0.8. I thought HTTP0.8 was just my PR 😅


Changing to an unsupported tile provider zoom level removes all tiles and reports a load of errors

Would be nice to have an option to cap tile layer url zoom without screwing up the coordinates and still see the CSS3 zooming while pinching and animating. Will also result in fewer requests if I can specify that no tiles have decimal zoom levels.
EDIT: This is a really bad description, refer to the one below: https://github.com/Leaflet/Leaflet/issues/1934#issuecomment-22192219

It may be unbelievable, but after two years I'm still running into the same issue. I am writing hybrid mobile app using ionic2. I've installed leaflet package using npm, it seems to be the most recent version. private L: any = require('leaflet'); I have no idea what I'm doing wrong but leaflet is putting non integer values into url causing 404. It happens on android 5.0.1.

I'm having the same issue with Ionic 2 for ipad only.  Unfortunately I'm stuck with the .7 version because the Angular 2's zone.js messes with the pan function.  Any idea why this won't work in .7?

Same issue with ionic2 on an android device

@owlcode @dtruel @verbeeckjan Please don't resuscitate a three-year old closed bug about maxNativeZoom and zoom animations for an unrelated problem. If you have issues with Leaflet somehow using non-integer zoom levels under certain circumstances, create a new bug report detailing those circumstances and how to reproduce the problem.


fby3.5: cl: Modified IPMB architecture

Summary:

There were some threads creating with CMSIS-OS2 API and which required fixed memory space for CMSIS-OS2.
For Yv3.5, it requires IPMB TX and RX threads for four I2C buses and occupying too much memory to fix memory for maximum usage.
Modified OS API from CMSIS-OS2 API to Zephyr kernel API, including threads, mutex, message queue.
Removed memory reservation for CMSIS-OS2 stacks.
To reduce threads stack size, modified IPMB buffer from local variable to pointer and only allocate when process running.
Removed worker from common code, in that Zephyr kernel provided the service already.

Test plan:
-Build code: Pass
-Stress IPMB: Pass
Stressed get ME version for over thousands times.

I agree with the proposed changes and recommendations for changes (or in the case of the tx thread, leaving it as is).  Please move forward with implementing these changes.

I will close this PR and PR new commit again.
Thanks for your review and suggestion.


Post-build package compression

Suggestion based on ideas from @mjguzik:

Either do not compress packages in make package or use a faster compression algorithm such as gzip.
(Re)compress all packages at the end of the bulk build into the more distribution-appropriate xz format.
Potentially only do this on highly-used packages.
Leaf packages can be compressed with xz in make package.

xz here means whatever PKG_EXT is.
#459 likely needs to be fixed first for this to work.

< _mjg> bdrewery: so i had a quick look and it seems lz4 provides WAY faster decompressoin time than even gzip

Mmm, not compressing packages at all during bulk would consume really vast amount of disk space.
Using a fast algorithm like lz4 would be a good tradeoff, and it would speed up so many ports for example everything that uses texlive...

… not compressing packages at all during bulk would consume really vast amount of disk space. …

For ZFS use cases, does https://github.com/freebsd/poudriere/pull/814 improve things? https://github.com/freebsd/poudriere/issues/794#issuecomment-898878003 to visualise which datasets have compression on

@grahamperrin See #844 for more context too

Instead of creating a new issue maybe asking here is the best choice since this issue is related to pkg performance.
I notice that in big packages created by poudriere it takes some time because only one thread is used by xz.
Is there any chance to speed it up by using xz -T threads?


cmd/link: possible linker bug when using the -T flag to set the text address

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.11.1 darwin/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="on"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/iansmith/qemu/xxx"
GOPROXY=""
GORACE=""
GOROOT="/Users/iansmith/qemu/go-1.11/go"
GOTMPDIR=""
GOTOOLDIR="/Users/iansmith/qemu/go-1.11/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="0"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/w0/fw3qzvvx54b39b790yxq6v100000gn/T/go-build145968613=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
aarch64-elf-readelf -W -l -S  bin/xxx_xxx/surprise
If possible, provide a recipe for reproducing the error.
I have found this error to be caused by any link that supplies an start address other than one ending in 0x1000.  I was doing some experiments on arm (thus the aarch64 above) but I think this is actually in the offset calculations for the elf headers (section and program).
Commands like this seem to cause the problem (using the -T flag with something that doesn't end in 1000):
GOOS=xxx GOARCH=xxx go install -v -ldflags='-T 0x88000'  github.com/iansmith/xxx/surprise/cmd/surprise
A complete runnable program is good.
A link on play.golang.org is best.
https://play.golang.org/p/b32fVLNTGxP
That link shows the diff to my "fix".  My fix is clearly not the real one, but whoever wrote the code in elf.go (go/src/cmd/link/internal/ld/elf.go) will probably see the problem immediately when they see what I have done.
What did you expect to see?
I expected to see normal elf section headers and program headers.  After my (ahem) "fix", you get the normal output:
$ aarch64-elf-readelf -W -l -S  bin/xxx_xxx/surprise
There are 24 section headers, starting at offset 0x158:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL<PHONE_NUMBER>000000<PHONE_NUMBER>00 00      0   0  0
  [ 1] .text             PROGBITS<PHONE_NUMBER>088000 001000 03f8c0 00  AX  0   0  8
  [ 2] .rodata           PROGBITS<PHONE_NUMBER>0d0000 050000 024e79 00   A  0   0 32
  [ 3] .shstrtab         STRTAB<PHONE_NUMBER>000000 074e80 000193 00      0   0  1
  [ 4] .typelink         PROGBITS<PHONE_NUMBER>0f5020<PHONE_NUMBER>24 00   A  0   0 32
  [ 5] .itablink         PROGBITS<PHONE_NUMBER>0f5648<PHONE_NUMBER>08 00   A  0   0  8
  [ 6] .gosymtab         PROGBITS<PHONE_NUMBER>0f5650<PHONE_NUMBER>00 00   A  0   0  1
  [ 7] .gopclntab        PROGBITS<PHONE_NUMBER>0f5660<PHONE_NUMBER>c3 00   A  0   0 32
  [ 8] .noptrdata        PROGBITS<PHONE_NUMBER>130000 0b0000 000ba8 00  WA  0   0 32
  [ 9] .data             PROGBITS<PHONE_NUMBER>130bc0 0b0bc0 0015b0 00  WA  0   0 32
  [10] .bss              NOBITS<PHONE_NUMBER>132180 0b2180 01a330 00  WA  0   0 32
  [11] .noptrbss         NOBITS<PHONE_NUMBER>14c4c0 0cc4c0 002258 00  WA  0   0 32
  [12] .zdebug_abbrev    PROGBITS<PHONE_NUMBER>150000 0c0000 000112 00      0   0  8
  [13] .zdebug_line      PROGBITS<PHONE_NUMBER>150112 0c0112 008fb1 00      0   0  8
  [14] .zdebug_frame     PROGBITS<PHONE_NUMBER>1590c3 0c90c3 0031ac 00      0   0  8
  [15] .zdebug_pubnames  PROGBITS<PHONE_NUMBER>15c26f 0cc26f 000973 00      0   0  8
  [16] .zdebug_pubtypes  PROGBITS<PHONE_NUMBER>15cbe2 0ccbe2 001cf1 00      0   0  8
  [17] .debug_gdb_scripts PROGBITS<PHONE_NUMBER>15e8d3 0ce8d3 00003c 00      0   0  1
  [18] .zdebug_info      PROGBITS<PHONE_NUMBER>15e90f 0ce90f 015a44 00      0   0  8
  [19] .zdebug_loc       PROGBITS<PHONE_NUMBER>174353 0e4353 009793 00      0   0  8
  [20] .zdebug_ranges    PROGBITS<PHONE_NUMBER>17dae6 0edae6 00309b 00      0   0  8
  [21] .note.go.buildid  NOTE<PHONE_NUMBER>087f9c 000f9c 000064 00   A  0   0  4
  [22] .symtab           SYMTAB<PHONE_NUMBER>000000<PHONE_NUMBER>30 18     23  91  8
  [23] .strtab           STRTAB<PHONE_NUMBER>000000 106630 006bf7 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0xc4520
There are 5 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000087040 0x0000000000087040 0x000118 0x000118 R   0x10000
  NOTE           0x000f9c 0x0000000000087f9c 0x0000000000087f9c 0x000064 0x000064 R   0x4
  LOAD           0x000000 0x0000000000087000 0x0000000000087000 0x0408c0 0x0408c0 R E 0x10000
  LOAD           0x057000 0x00000000000d7000 0x00000000000d7000 0x051e23 0x051e23 R   0x10000
  LOAD           0x0b7000 0x0000000000137000 0x0000000000137000 0xffffffffffffb180 0x017718 RW  0x10000
readelf: Error: the segment's file size is larger than its memory size

 Section to Segment mapping:
  Segment Sections...
   00
   01     .note.go.buildid
   02     .text .note.go.buildid
   03     .typelink .itablink .gosymtab .gopclntab
   04     .noptrbss

What did you see instead?
Note the negative value in the 3rd program header (the program text segment)!  .shstrtab (section header string table) section has been overwritten so the names are garbage.
$ aarch64-elf-readelf -W -l -S  bin/xxx_xxx/surprise
There are 24 section headers, starting at offset 0x158:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0] ^B                NULL<PHONE_NUMBER>000000<PHONE_NUMBER>00 00      0   0  0
  [ 1]                   PROGBITS<PHONE_NUMBER>088000 001000 03f8c0 00  AX  0   0  8
  [ 2]                   PROGBITS<PHONE_NUMBER>0d0000 050000 024e79 00   A  0   0 32
  [ 3]                   STRTAB<PHONE_NUMBER>000000 06de80 000193 00      0   0  1
  [ 4]                   PROGBITS<PHONE_NUMBER>0f5020<PHONE_NUMBER>24 00   A  0   0 32
  [ 5]                   PROGBITS<PHONE_NUMBER>0f5648<PHONE_NUMBER>08 00   A  0   0  8
  [ 6] ^V                PROGBITS<PHONE_NUMBER>0f5650<PHONE_NUMBER>00 00   A  0   0  1
  [ 7]                   PROGBITS<PHONE_NUMBER>0f5660<PHONE_NUMBER>c3 00   A  0   0 32
  [ 8]                   PROGBITS<PHONE_NUMBER>130000 0b0000 000ba8 00  WA  0   0 32
  [ 9]                   PROGBITS<PHONE_NUMBER>130bc0 0b0bc0 0015b0 00  WA  0   0 32
  [10] ^B                NOBITS<PHONE_NUMBER>132180 0b2180 01a330 00  WA  0   0 32
  [11]                   NOBITS<PHONE_NUMBER>14c4c0 0cc4c0 002258 00  WA  0   0 32
  [12] ^B                PROGBITS<PHONE_NUMBER>150000 0c0000 000112 00      0   0  8
  [13]                   PROGBITS<PHONE_NUMBER>150112 0c0112 008fb1 00      0   0  8
  [14] ^D                PROGBITS<PHONE_NUMBER>1590c3 0c90c3 0031ac 00      0   0  8
  [15]                   PROGBITS<PHONE_NUMBER>15c26f 0cc26f 000973 00      0   0  8
  [16] ^E^A              PROGBITS<PHONE_NUMBER>15cbe2 0ccbe2 001cf1 00      0   0  8
  [17]                   PROGBITS<PHONE_NUMBER>15e8d3 0ce8d3 00003c 00      0   0  1
  [18]                   PROGBITS<PHONE_NUMBER>15e90f 0ce90f 015a44 00      0   0  8
  [19]                   PROGBITS<PHONE_NUMBER>174353 0e4353 009793 00      0   0  8
  [20]                   PROGBITS<PHONE_NUMBER>17dae6 0edae6 00309b 00      0   0  8
  [21]                   NOTE<PHONE_NUMBER>087f9c 000f9c 000064 00   A  0   0  4
  [22]                   SYMTAB<PHONE_NUMBER>000000<PHONE_NUMBER>30 18     23  91  8
  [23]                   STRTAB<PHONE_NUMBER>000000 106630 006bf7 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0xc4520
There are 5 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000087040 0x0000000000087040 0x000118 0x000118 R   0x10000
  NOTE           0x000f9c 0x0000000000087f9c 0x0000000000087f9c 0x000064 0x000064 R   0x4
  LOAD           0xffffffffffff9000 0x0000000000080000 0x0000000000080000 0x0478c0 0x0478c0 R E 0x10000
  LOAD           0x050000 0x00000000000d0000 0x00000000000d0000 0x058e23 0x058e23 R   0x10000
  LOAD           0x0b0000 0x0000000000130000 0x0000000000130000 0x002180 0x01e718 RW  0x10000

 Section to Segment mapping:
  Segment Sections...
   00
   01
   02
   03        ^V
   04       ^B

I think @navytux might also have encountered this.

I only saw crashes with -T xxx but then I suspected that the crashes were due to xxx being not page aligned in my case:
https://github.com/golang/go/issues/18977#issuecomment-302118472
And concluded that something in Go runtime may be assuming text/data has to be page-aligned. But I had not checked.

This issues arises when the address passed via -T flag is not aligned with the address rounding quantum, that can be tuned via -R flag.
You can check the default rounding quantum for the target architecture value via -v flag:
$ GOARCH=arm go build -ldflags "-T 0x10000 -v" hello.go
HEADER = -H5 -T0x10000 -R0x10000
...
@iansmith In your case you should use the following linker flags:
-ldflags='-T 0x88000 -R 0x1000'


Creating a pip installable package for Python APIs

Is your feature request related to a problem? Please describe.
We need a way to import Python libraries into a Notebook or Pipeline component
Describe the solution you'd like
Make Model Registry Python available as a pip based package
Describe alternatives you've considered
Python: Creating a pip installable package

The package is now published at https://pypi.org/project/model-registry/0.1.0/.


unix/fs: Fix for potential partial reads/writes

As mentioned by @bnoordhuis.
CC: @saghul

Style nits and commits message compliance aside, can a test for this be written? (also please do a rebase, since neighboring code was modified). Thanks!

Not sure about those tests, I did test of course but with hard-coded partial reads/writes...
Ideas are welcome...

Not sure about those tests, I did test of course but with hard-coded partial reads/writes...
Ideas are welcome...

Something like this could work I think: https://github.com/libuv/libuv/blob/v1.x/test/test-eintr-handling.c

Those updates are for style, still have to look at the test implementation...

Sorry for the long delay, please take a look at the last commit and let me know if this is what you suggested.
Side note: I ran these tests without my fix, which in fact cause them to fail.

CI: https://ci.nodejs.org/job/libuv-test-commit/11/

one of the added tests is broken in SmartOS and OSX
eintr_handling is now broken
the tests do not compile on Windows

Fixes (all?) style issues. Hopefully disabled the test on windows.
@saghul: Can you please restart a build (I don't seem able to do so.)
There is (probably an intentional) bug in eintr_handling.
The size of the read buffer is to large.
The read stops because of the interrupt, which is exactly what my patch fixes.
(continue reading until all buffers are full, that is.)
I can fix the eintr_handling (with an other interruptable system call: like sleep) but I guess that defeats the purpose of the test.
Comments are welcome...

Can you please restart a build (I don't seem able to do so.)

Only collaborators can trigger builds at the moment. CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/44/
I think this PR should remove the eintr_handling test, since it "fixes" it, right?

@saghul: Yet Another Build Request
EINTR handling is now done inside the loop iso outside, this way it can benefit from the new partial read behaviour.
Removed the EINTR test, since it has been deprecated by the new partial read behaviour.

I think I got all of them...

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/48/

So I got all but smartos right?
I don't seem able to run smartos under VirtualBox any ideas?

So I got all but smartos right?

Yep, looks that way!

I don't seem able to run smartos under VirtualBox any ideas?

TBH I have no idea either :-(

@bwijen I've been successful to have a working smartos virtual machine in the past using KVM and following this guide: https://gist.github.com/AndreasMadsen/3732950. I you have problems just let me know.

So I was able to run smartos under VirtualBox (I used usb image but need live iso)
I ran the fs_partial_write several times, it fails about 1 out of 25.
When it fails, the write (test/test-fs.c:2689) fails with result:=-1 and errno:=0
I tried to write-up a test to reproduce without libuv, but unsuccessful so far.
I can workaround the problem, but I guess that defeats the purpose.
Any suggestions are welcome.

I rebased and added a workaround.
@saghul: could you send these to the buildserver?

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/104/

Both test passed on all builds...
Any comments left?

Some style nits, otherwise LGTM. Can you also squash the commits into one since you're here? Thanks!

Fixed nits + squashed.

LGTM. @libuv/collaborators can anyone have another look at this just in case?

Also, question: does Windows also behave like this? If so, we should probably add a note in the documentation, mentioning that starting with 1.10 either all the provided buffers are written or an error occurs.

@bwijen @saghul Please, feel free to mention @libuv/sunos next time you have an issue with SmartOS :)

@misterdjules sure thing! as you may see this PR started a while ago...

The only added test that was mentioned to not pass on SmartOS is fs_partial_write, but I've been running it in a loop on SmartOS for the past five minutes and I haven't seen any failure so far.
This might be due to the "workaround" that @bwijen mentioned earlier. Unfortunately I can't see what that workaround is.
@bwijen Do you mind indicating what that workaround is so that I can see if we can come up with a fix that doesn't defeat the purpose of the test on SmartOS?

@misterdjules: Thanks for looking into this!
The 'workaround' can be found here: bwijen/libuv@b0d251ee5730d97c5f5ae67a2df2c5890340f376
Without that last commit the test fails (in my virtual Smart OS environment) about 1 out of 25

@bwijen I'm running ./test/run-tests fs_partial_write with the code in this PR and the following patch applied, which is the result of reverting the workaround you mentioned in your previous comment:
commit 15a91094edf68f17ae9dbb718387e716841f1cde
Author: Julien Gilli<EMAIL_ADDRESS>Date:   Mon Sep 12 21:30:03 2016 +0000

     revert smartos workaround for PR 640

diff --git a/test/test-fs.c b/test/test-fs.c
index 0c5761c..389535b 100644
--- a/test/test-fs.c
+++ b/test/test-fs.c
@@ -2700,25 +2700,21 @@ TEST_IMPL(fs_partial_write) {
 static void thread_exec(int fd, char* data, int size, int interval, int doread) {
   const pid_t pid = getpid();
   ssize_t result = 1;
-  int error = 0;

-  while (size > 0 && error == 0) {
+  while (size > 0 && result > 0) {
     do {
       if(doread)
         result = write(fd, data, size < interval ? size : interval);
       else
         result = read(fd, data, size < interval ? size : interval);

-      error = errno;
-    } while (result == -1 && error == EINTR);
+    } while (result == -1 && errno == EINTR);

     kill(pid, SIGUSR1);
-    if (result > 0) {
-      error = 0;
-      size -= result;
-      data += result;
-    }
+    size -= result;
+    data += result;
   }
+
   ASSERT(size == 0);
   ASSERT(result > 0);
 }

However I get only failures, the test fails with the following output:
[root@0c933410-7c9b-4bea-96b6-2db35946bc95 ~/libuv]# ./test/run-tests fs_partial_write
not ok 1 - fs_partial_write
# exit code 134
# Output from process `fs_partial_write`:
# Assertion failed in test/test-fs.c on line 2718: size == 0
[root@0c933410-7c9b-4bea-96b6-2db35946bc95 ~/libuv]#

Is the patch above the correct revert of your workaround? You mentioned that the test fails sporadically (once out of ~25 runs), so I wouldn't expect the test to fail all the time without your workaround. What am I missing?

@misterdjules:
That patch is indeed the correct revert.
For sure it is possible that it will fail 1 out of 1 on a real SmartOS system (I was running it under VirtualBox)
I guess it would just be easier to pinpoint the problem if it always fails
The problem I saw (only on SmartOS) that result:=-1 and errno:=0 which causes it to break out of the both loops while not all data is sent (hence the assert on size==0)

@saghul @bwijen
The problem is that on SmartOS, errno is not reentrant by default. One has to pass the -pthreads option to the compiler in order for errno to be reentrant. This is not needed on the CentOS distribution I used to test that behavior on Linux.
The following changes fix the problem (I took that opportunity to change libuv_la_CFLAGS from -pthread to -pthreads as it's consistent with the rest of the build system like gyp files, and it's functionally equivalent):
diff --git a/Makefile.am b/Makefile.am
index 0a2b246..2d2bdb1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -36,7 +36,7 @@ libuv_la_SOURCES = src/fs-poll.c \
 if SUNOS
 # Can't be turned into a CC_CHECK_CFLAGS in configure.ac, it makes compilers
 # on other platforms complain that the argument is unused during compilation.
-libuv_la_CFLAGS += -pthread
+libuv_la_CFLAGS += -pthreads
 endif

 if WINNT
@@ -134,6 +134,13 @@ test_run_tests_CFLAGS =
 else
 test_run_tests_CFLAGS = -Wno-long-long
 endif
+
+if SUNOS
+# Can't be turned into a CC_CHECK_CFLAGS in configure.ac, it makes compilers
+# on other platforms complain that the argument is unused during compilation.
+test_run_tests_CFLAGS += -pthreads
+endif
+
 test_run_tests_LDFLAGS =
 test_run_tests_SOURCES = test/blackhole-server.c \
                          test/dns-server.c \

This is the diff of the preprocessor output for test-fs.c between not passing -pthreads and passing -pthreads on SmartOS:
--- test-fs-autotools-no-pthread.i      2016-09-14 19:06:57.529770010 +0000
+++ test-fs-autotools-with-pthreads.i   2016-09-14 19:07:30.193570124 +0000
@@ -20,8 +20,8 @@
 # 43 "/usr/include/sys/errno.h" 3 4
 #pragma ident "%Z%%M%  %I%     %E% SMI"
 # 42 "/usr/include/errno.h" 2 3 4
-# 58 "/usr/include/errno.h" 3 4
-extern int errno;
+# 55 "/usr/include/errno.h" 3 4
+extern int *___errno();
 # 26 "./include/uv-errno.h" 2
 # 49 "./include/uv.h" 2
 # 1 "./include/uv-version.h" 1
@@ -891,9 +891,7 @@

-
-
-extern int getdate_err;
+extern int *_getdate_err_addr(void);
 # 246 "/usr/include/time.h" 3 4

 # 246 "/usr/include/time.h" 3 4
@@ -2433,6 +2431,9 @@
 void freeipsecalgent(struct ipsecalgent *ptr);
 # 366 "/usr/include/netdb.h" 3 4
 extern int h_errno;
+
+
+extern int *__h_errno(void);
 # 35 "./include/uv-unix.h" 2

 # 1 "/usr/include/termios.h" 1 3 4
@@ -7925,7 +7926,7 @@
       else
         result = read(fd, data, size < interval ? size : interval);

-    } while (result == -1 && errno == 4);
+    } while (result == -1 && (*(___errno())) == 4);

     kill(pid, 16);
     size -= result;

As you can see from the diff above, the result when passing -pthreads is that the reentrant ___errno function is used instead of the non-reentrant errno variable when errno is used in the code.

@misterdjules Interesting! Thanks for getting to the bottom of this! That sounds good to me. Care to send a PR for review?

@saghul

Care to send a PR for review?

Let me do that now :)

@saghul https://github.com/libuv/libuv/pull/1052.

@misterdjules: Great job!
@saghul: Let's wait until #1052 lands, I will rebase my work on top of that (without the SmartOS workaround)

@saghul: rebased on #1052

Thanks @bwijen!  I plan on landing this right after 1.10 goes out (hopefully this week).  This one was a long time in the making, so thanks a lot for following it all the way through. :heart:

@saghul: rebased on v1.x, just for fun.
I think this year is a good year to land :)

Hi @saghul, just did another rebase.
I would really like to see this land...

Another rebase to resolve conflicts.
Any feedback on merge or not-to-merge is welcome!

@saghul: Is there anything left to do?
Please respond.

Rebased to solve conficts...

@bnoordhuis : Care to take a look?

This needs to be rebased again.

@cjihrig: rebased to resolve conflicts
I would love to see this land in the near future...

Agreed. :)

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/479/
@saghul does this still LGTY?
@bnoordhuis could you take a look?
Thanks

@libuv/collaborators could anyone take a look at this? Thanks!

@santigimeno This seems to be stalled again. Any chance you could land it while incorporating the style changes you marked above?

Monthly bump, hoping this bugfix can finally land.

Okay. If nobody objects, I'll land this on tuesday.


server Error (500) is displayed when opening a private page without login approval

overview
display 404 error when opening private page (PaidContent) without login approval
(or make it impossible to press "Read this article" button)
reference information

#15

if there is no login authorization, handle it with #28 to prevent the "Read this article" button from being clickable

made the following modifications

The "Go to Admin Panel" link is now displayed only when logged in with admin credentials.
The "Read this article" button for paid content (small category = PaidContent) is now enabled only when logged in with any user's authorization.


Sources missing from central mvnrepository since RELEASE 2.1.4

Describe the bug
Since release 2.1.4, the sources jar is missing from mvncentral. This breaks earlier behaviour for example for any tool expecting to find the sources along with the regular release jar.
Sample
In all versions in central mvnrepository up until 2.1.4 the sources jar can be found. see for example 2.1.3
https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-starter-openfeign/2.1.3.RELEASE/
In versions after that it is missing, example
https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-starter-openfeign/2.2.1.RELEASE/

Does a pom artifact have sources?

I don't think this is an issue anymore

@spencergibb It is still an issue, have a look at https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-starter-openfeign/4.1.0/ - A sources jar is expected and the overall standard java maven publishing convention is that the sources jar is also published - see other projects in the ecosystem, examples https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-cli/3.1.0/ or even other prominent java projects. https://repo1.maven.org/maven2/org/junit/jupiter/junit-jupiter-engine/5.10.1/ . So, I can't understand the rationales for not doing this here, and can't find anything in the documentation either regarding why this project should choose not to. If no rationale can be found, I would assume it is a bug, and an misconfiguration in the publishing configuration.

I vote for reopening so at least it will have chance of being fixed

A starter is a pom and there are no sources

@spencergibb Yes. you are correct,. sorry my bad :) Looking into the jar, for the versions where it used to be published (pre 2.1.3) it was only containing metadata, poms and as you say no real sources which makes it technically correct to not have that artifact - I agree with you now.
The whole rationale for opening this was:  I used was an source collector tool if i recall,  breaking  the usage  (this was a while ago) when it could not find sources jar to import any longer - but that was cleary a bug in that tool I can conclude then.  Sadly I don't rememeber which tool it was hmm. Anyway, keep this closed. thanks for the quick response and have a nice christmas!


Date Conversion

Basically, reimplement Processing Dates from Roam42 as a standalone extension, extend in other ways that could interest users.

From Alfred Markut Jr on Slack

Audit: Won't do


[Ray] Add unit tests for ray client + modin

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. What kind of performance improvements would you like to see with this new API?
Wanted to open discussion about adding unit tests using ray client to this repo's CI. If there are any examples that should be covered that would be handy to know, as well as any guidelines for where to put these tests. Example issue with ray-client on the ray repo https://github.com/ray-project/ray/issues/14857.
@amogkam @devin-petersohn

Having some CI coverage here would really help with making sure we have native support for Modin with Ray Client

Thanks @ckw017 and @amogkam. I agree it would be good if we could add tests for basic functionality.

@devin-petersohn any guidance on how to go about adding this to modin CI? I think ideally we can just run the same tests that currently exist for modin on ray, except with ray client.

For this, we would probably want to add a separate job within the existing CI and push for the GitHub Actions (not necessary for our TeamCity tests).
We would need to start the client before running the tests. Modin will automatically connect to the client if you run with environment variable MODIN_RAY_CLUSTER. Here's our current github actions workflow: https://github.com/modin-project/modin/blob/master/.github/workflows/ci.yml

@devin-petersohn Hey Devin, just wanted to check two things that would help get this closed:

It looks like to add tests for modin onto Ray's CI, we need a version of Modin with the fix in #2844. It looks like this was a bit after 0.9.1 was released, so wanted to check if it was possible to get 0.9.2 out so that we can run our tests against that.
For getting tests for Ray Client onto Modin's CI, we would need to use a nightly ray wheel since ray-project#16278 won't be part of Ray 1.4, and is needed to get the tests to run consistently. It looks like all of the current unit tests run against Ray <= 1.1.0, so I wanted to check if you currently test against nightly anywhere so that we can stick the client tests there. Alternatively, we can add the client tests onto your CI as planned (as a separate job) and install the nightly wheels just for the client tests

^ First thing should be fine for now, we'll just install the latest commit when testing for now.

@ckw017 thanks for following up!
1.) We are planning to release 0.10 tomorrow (probably 😄). After release it'll probably be good to test the stable release since we are planning major changes for the release after 0.10.
2.) Ray 1.4 will work with Modin given recent patches (e.g., https://github.com/ray-project/ray/issues/15990). We also have a nightly test that runs on the nightly docker container, but that probably needs to be changed to pip install ray && ray install-nightly because it's been failing frequently (see here:  https://github.com/modin-project/modin/actions/workflows/push-to-master.yml). Ideally we have Ray 1.4 in 0.10. I will try to make that happen.


Support different environment variables for different target architectures in cargo configuration

Describe the problem you are trying to solve
Cross-compiling code with dependencies on native libraries is often complex because:

it's not always possible / desirable to install the required .sos and header files using the same system that the host architecture uses, because dependency packages and build tools aren't always capable of supporting multiple architectures. A common solution on Linux is to install target packages under a different root, e.g. create a /target-sysroot/ with parts of a distribution underneath, installed with something like debootstrap.
Many native build tools (e.g. gcc, pkg-config) are used by build.rs scripts, and configured by environment variable, which works well when they're only used in the context of building for a single platform, but doesn't when they can only be set once for multiple targets. It's not uncommon for e.g. gcc to be invoked both for the host and target architecture as part of the build for a single large application.
It's currently possible to resolve this manually using links build script config overrides, but this is often significantly more work than simply configuring environment variables and running cargo build.

Describe the solution you'd like
I'm wondering if it'd be worth adding configuration cargo for configuring environment variables on a per-architecture basis?
It's currently possible to do this in .cargo/config.toml to specify rustc args for other platforms:
[target.armv7-unknown-linux-gnueabihf]
rustflags=["arm", "specific", "flags"]

I'd love to be able to add an additional mapping of environment variables that are applied to subcommands issued by build scripts for these architectures. e.g., for my specific configuration with a target system mounted under /target-sysroot/, this would look like:
[target.armv7-unknown-linux-gnueabihf]
rustflags=["arm", "specific", "flags"]
buildenv={C_INCLUDE_DIR="/target-sysroot/usr/include/arm-linux-gnueabihf", PKG_CONFIG_LIBDIR="/target-sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig", PKG_CONFIG_SYSROOT_DIR="/target-sysroot/"}

or alternatively, without inlining the buildenv variable:
[target.armv7-unknown-linux-gnueabihf]
rustflags=["arm", "specific", "flags"]
[target.armv7-unknown-linux-gnueabihf.buildenv]
C_INCLUDE_DIR="/target-sysroot/usr/include/arm-linux-gnueabihf"
PKG_CONFIG_LIBDIR="/target-sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig"
PKG_CONFIG_SYSROOT_DIR="/target-sysroot/"

This mirrors the syntax for [target.<triple>.<links>.rustc-env] as per the cargo reference.
Notes
This is a problem I ran into concretely when attempting to cross-compile spotifyd for the Raspberry Pi 3. The Host OS in this case was this image from the rust-embedded team, and the target OS was a subset of Raspbian Buster installed using Multistrap.
I'm not super experienced with linux build systems in general, and so I'm not sure if this is the "right" way to solve the problem! But it felt relatively expedient and clean to me. Definitely open to feedback and ideas :)

Ah, I just realised that the pkg-config crate implements its own version of this -- perhaps it's better handled there instead.


WIP: [Release] Verify release-17.0.0-rc0

PR to verify Release Candidate

@github-actions crossbow submit  --group verify-rc-source --param release=17.0.0 --param rc=0

Revision: 741356c06dacfc3e6070443703f6bb1f2e9ffee1
Submitted crossbow builds: ursacomputing/crossbow @ release-17.0.0-rc0-0

Task
Status

almalinux-8-amd64

almalinux-8-arm64

almalinux-9-amd64

almalinux-9-arm64

amazon-linux-2023-amd64

amazon-linux-2023-arm64

centos-7-amd64

centos-8-stream-amd64

centos-8-stream-arm64

centos-9-stream-amd64

centos-9-stream-arm64

conan-maximum

conan-minimum

debian-bookworm-amd64

debian-bookworm-arm64

debian-trixie-amd64

debian-trixie-arm64

java-jars

matlab

nuget

python-sdist

r-binary-packages

test-debian-12-docs

ubuntu-focal-amd64

ubuntu-focal-arm64

ubuntu-jammy-amd64

ubuntu-jammy-arm64

ubuntu-noble-amd64

ubuntu-noble-arm64

wheel-macos-big-sur-cp310-arm64

wheel-macos-big-sur-cp311-arm64

wheel-macos-big-sur-cp312-arm64

wheel-macos-big-sur-cp38-arm64

wheel-macos-big-sur-cp39-arm64

wheel-macos-catalina-cp310-amd64

wheel-macos-catalina-cp311-amd64

wheel-macos-catalina-cp312-amd64

wheel-macos-catalina-cp38-amd64

wheel-macos-catalina-cp39-amd64

wheel-manylinux-2-28-cp310-amd64

wheel-manylinux-2-28-cp310-arm64

wheel-manylinux-2-28-cp311-amd64

wheel-manylinux-2-28-cp311-arm64

wheel-manylinux-2-28-cp312-amd64

wheel-manylinux-2-28-cp312-arm64

wheel-manylinux-2-28-cp38-amd64

wheel-manylinux-2-28-cp38-arm64

wheel-manylinux-2-28-cp39-amd64

wheel-manylinux-2-28-cp39-arm64

wheel-manylinux-2014-cp310-amd64

wheel-manylinux-2014-cp310-arm64

wheel-manylinux-2014-cp311-amd64

wheel-manylinux-2014-cp311-arm64

wheel-manylinux-2014-cp312-amd64

wheel-manylinux-2014-cp312-arm64

wheel-manylinux-2014-cp38-amd64

wheel-manylinux-2014-cp38-arm64

wheel-manylinux-2014-cp39-amd64

wheel-manylinux-2014-cp39-arm64

wheel-windows-cp310-amd64

wheel-windows-cp311-amd64

wheel-windows-cp312-amd64

wheel-windows-cp38-amd64

wheel-windows-cp39-amd64

I'll investigate tomorrow what is wrong on the verification tasks but it seems that the changes for the tags / gh releases (here: https://github.com/apache/arrow/commit/6ec2f222ff7a6ad9dcb3b5b7edc38c414259aee2) have done something wrong to the tar.gz on the 02-source.sh and both binaries and verification tasks are failing due to an empty tar file.
FYI @sgilmore10 @kou

I'll investigate tomorrow what is wrong on the verification tasks but it seems that the changes for the tags / gh releases (here: 6ec2f22) have done something wrong to the tar.gz on the 02-source.sh and both binaries and verification tasks are failing due to an empty tar file.

Sorry about that @raulcd! Kevin and I will take a look at this asap.

Sorry about that @raulcd! Kevin and I will take a look at this asap.

No worries, I've just added you FYI, happy if you can take a look otherwise I'll start to investigate tomorrow as is pretty late here at the moment :) But it seems is just the tar.gz name once untared. It changed from 16.1.0-rc1 release (https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-16.1.0-rc1/):
$ tar zxvf apache-arrow-16.1.0.tar.gz
...
$ ls
apache-arrow-16.1.0  apache-arrow-16.1.0.tar.gz

to 17.0.0-rc0 (https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-17.0.0-rc0/)
$ tar zxvf apache-arrow-17.0.0.tar.gz
...
$ ls
apache-arrow-17.0.0-rc0  apache-arrow-17.0.0.tar.gz

See -rc0 is present on the tar.gz name which is unexpected

Sorry about that @raulcd! Kevin and I will take a look at this asap.

No worries, I've just added you FYI, happy if you can take a look otherwise I'll start to investigate tomorrow as is pretty late here at the moment :) But it seems is just the tar.gz name once untared. It changed from 16.1.0-rc1 release (https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-16.1.0-rc1/):
$ tar zxvf apache-arrow-16.1.0.tar.gz
...
$ ls
apache-arrow-16.1.0  apache-arrow-16.1.0.tar.gz

to 17.0.0-rc0 (https://dist.apache.org/repos/dist/dev/arrow/apache-arrow-17.0.0-rc0/)
$ tar zxvf apache-arrow-17.0.0.tar.gz
...
$ ls
apache-arrow-17.0.0-rc0  apache-arrow-17.0.0.tar.gz

See -rc0 is present on the ~tar.gz~ directory name which is unexpected

That's a good catch. @kevingurney and I were able to confirm this on our end as well. We'll take a look at 02-source.sh and see if there's anything obviously wrong there.

Actually, it looks like there's a bug in dev/release/utils-create-release-tarball.sh. The name of the directory from which the tarball is created is based on the git tag, and therefore, contains the rcN suffix. Adding a separate variable called tag_no_rc and using that as the folder name should resolve the issue.

Could you open a PR for main?
We can cherry-pick it to release branch after we merge it into main.

Just submitted a PR (#43200) that should fix the issue. Sorry for the inconvenience this has caused you @raulcd!


Whatsapp -> Telegram bridge - Issue with media being re-sent multiple times after bridge reconnects

Problem:
I have a whatsapp -> telegram bridge, and the problem occurs every time the bridge disconnects for some reason and then it reconnects automatically, or if I manually restart it.
When this happens, matterbridge re-sends to the telegram channel all media it had already relayed from whatsapp in the past few hours. This problem has been happening for the past 12 months, at least.
Edit: this issue might be a duplicate of this older reported bug: https://github.com/42wim/matterbridge/issues/1679
To Reproduce
(1) Images and videos are sent on whatsapp, which are then relayed to the telegram channel by the bridge, as expected.
(2) Some time after that (could be hours), the bridge disconnects for some random reason and then it automatically reconnects.
(3) ISSUE: when the bridge reconnects, it relays again all previous images and videos to the telegram channel, and it will keep re-sending them over and over again after each time it reconnects.
Expected behavior
When the bridge disconnects and reconnects, text messages, images, videos, etc, should not be re-sent to the telegram channel. Nothing should be re-sent after reconnection.
Screenshots/debug logs

Environment (please complete the following information):

OS: linux Ubuntu 20.04.2 LTS
Matterbridge version: 1.23.2-linux-64bit (73ec02ab)

Additional context
[telegram.111]
Token="token"
RemoteNickFormat=""
MessageFormat="HTMLNick"
[whatsapp.111]
Number="+222222222222222"
SessionFile="session-222222222222.gob"
QrOnWhiteTerminal=false
RemoteNickFormat=""
[[gateway]]
name="gateway111"
enable=true
[[gateway.in]]
account="whatsapp.111"
<EMAIL_ADDRESS>[[gateway.out]]
account="telegram.111"
channel="-10034434343434"

I think I figured this issue out. I have updated the Time Zone of the VPS I'm using to host Matterbridge. I've set it to be in the same Time Zone as the Whatsapp and Telegram groups I'm bridging. After I did that, haven't experienced anymore issues with the bridge re-sending media over and over again.
Not sure why, but this did it for me.


Inheriting from WinUI 2 Control in C++/WinRT results in compile issues

Describe the bug

When inheriting from a MUXC control in MIDL, the compilation fails with errors like this:
Severity	Code	Description	File	Project	Line	Suppression State
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_VerticalCacheLength' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_VerticalCacheLength' ( Procedure 'put_VerticalCacheLength' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_Layout' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_Layout' ( Procedure 'put_Layout' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_ItemTemplate' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_ItemTemplate' ( Procedure 'put_ItemTemplate' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_ItemsSource' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_ItemsSource' ( Procedure 'put_ItemsSource' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_HorizontalCacheLength' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_HorizontalCacheLength' ( Procedure 'put_HorizontalCacheLength' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_Animator' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'put_Animator' ( Procedure 'put_Animator' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_VerticalCacheLength' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_VerticalCacheLength' ( Procedure 'get_VerticalCacheLength' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_Layout' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_Layout' ( Procedure 'get_Layout' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_ItemTemplate' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_ItemTemplate' ( Procedure 'get_ItemTemplate' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_ItemsSource' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_ItemsSource' ( Procedure 'get_ItemsSource' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_HorizontalCacheLength' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_HorizontalCacheLength' ( Procedure 'get_HorizontalCacheLength' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_Animator' ( RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL5015	[msg]the custom attribute argument contains a boolean value that is not valid [context]: enable [ Procedure 'get_Animator' ( Procedure 'get_Animator' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL2072	[msg]inapplicable attribute [context]: Windows.Foundation.Metadata.ExperimentalAttribute [ RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ( RuntimeClass 'RepeaterCompileCrash.BlankUserControl' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5
Error	MIDL2072	[msg]inapplicable attribute [context]: Windows.Foundation.Metadata.ExperimentalAttribute [ RuntimeClass 'Microsoft.UI.Xaml.Controls.ItemsRepeater' ( RuntimeClass 'RepeaterCompileCrash.BlankUserControl' ) ]	D:\Projects\RepeaterCompileCrash\BlankUserControl.idl	RepeaterCompileCrash	5

RepeaterCompileCrash.zip
Steps to reproduce the bug

Steps to reproduce the behavior:

Create new C++/WinRT project
Add WinUI package and update pch.h
Create new control, inherit from a MUXC control in IDL
Compile project

Expected behavior

Project should compile just fine.
Screenshots

Version Info

NuGet package version:

Microsoft.UI.Xaml.2.5.0-prerelease.200923002

Windows 10 version
Saw the problem?

Insider Build (20241)
Yes

May 2020 Update (19041)

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop

Xbox

Surface Hub

IoT

Additional context

Issue found by @sylveon

@jevansaks any ideas ?

This sounds like a MIDL bug that was already fixed but I don't remember the details. @BenJKuhn @DefaultRyan can you take a look? The IDL is simple:
namespace RepeaterCompileCrash
{
    [default_interface]
    runtimeclass BlankUserControl : Microsoft.UI.Xaml.Controls.ItemsRepeater
    {
        BlankUserControl();
    }
}

Was this one of the issues where it's a bug with /reference imports but not import statements with idls directly?

The inheriting issue might be a broader problem. I discovered a bug over the weekend and it really doesn't work at all. Will file an issue right now.

Also see #3499

@jevansaks Have there been any updates on that? We might be hitting this in RNW - trying to use the WinUI 2.6 Expander in a custom module.

I see a repeating pattern popping up: I find a bug in WinUI or the XAML compiler's C++ support, I file an issue, it stays basically unresponded for months, then several months later Windows Terminal or React Native also hits the same bug, and the bug never sees any activity or fix again.
Hopefully I can just go and fix them all myself once WinUI 3 goes open source 😭

@rectified95 @DHowett

is the bug limited to inheriting from xaml types? sounds like it shouldn't be which seems...bad.
is this a recent regression? does it repro with the 18362 / 17763 SDK? or only 19041+? I remember seeing one other issue with custom attributes that only started to show up in 19041.
if we suspect a bug in MIDL let's please file an internal bug to track since MIDL team won't necessarily track github issues.

Filed https://task.ms/33886151

Note, this is almost certainly MidlRT, not Midl. There has been a steady trickle of fixes to MidlRT since 19041 (which released in first half of 2020), but I'm not sure exactly if this would be affected by one of them. I suppose since @asklar is asking for checking older SDKs, I shouldn't get my hopes up that somebody has checked this against the latest preview SDK?

I just re-read the original report and noticed it referred to Insider build 20241. There was a fix to MidlRT that might affect this that is available in 21348, I think. I don't suppose anybody has tried that?

I just re-read the original report and noticed it referred to Insider build 20241. There was a fix to MidlRT that might affect this that is available in 21348, I think. I don't suppose anybody has tried that?

@asklar if you're able to repro can you try that? 20344 is the newest insider SDK in the public right now so only internal folks can check this.

@rectified95 and @amdingler just mentioned at standup that they are hitting this with 18362.
I tried @chingucoding's app with 18362 and 19041 and was able to repro the midl error.
Then installed the private SDK from 22128 and it works!
We do have inheritance from WUX types with no problems, so this seems like a problem that might be specific to how MUX types are set up? Are there any workarounds folks could use until we ship a new SDK @DefaultRyan ?

The issue is that MidlRT wasn't processing [experimental] attributes properly when reading winmd references. It processes them fine when reading a import filename.idl directive in IDL files. I'm guessing that WUX types don't present this problem because they don't have the [experimental] attribute in their winmds.
@JesseCol brought the issue to my attention originally, so he's more familiar with how to work around it.

I think we want to ensure that MUX can be used with any SDK, not just the new unreleased one  :) So I think MUX needs to take a change here, maybe remove the experimental APIs from the public package until we figure out a way to fix this for everyone?
@jevansaks @ranjeshj

We've had [experimental] types in every prerelease package since the beginning though -- what changed? Or what's special about these types?

I suspect something changed in mux since this repros with older SDKs?

@DefaultRyan can you grab the metadata out of older nuget packages (like 2.5 prerelease) and see what is new that is tripping up midlrt here? https://www.nuget.org/packages/Microsoft.UI.Xaml

@jevansaks I downloaded the repro zip in the first message of this thread, and it references Microsoft.UI.Xaml v2.5.0-prerelease.200923002. There are two things tripping up MidlRT, both of which have been fixed internally:

Importing winmds with [experimental] attributes, present in the prelease Xaml Nuget. As mentioned above, this fix was somewhat more recent, and should be present as of 21348, which isn't available yet. However, the [experimental] attributes are only present in the prerelease Nuget, and this issue goes away if you move to a stable Nuget, e.g. 2.5.0.
Importing winmds with custom attributes with boolean fields. In this case, it's Microsoft.UI.Xaml.CustomAttributes.MUXPropertyChangedCallbackAttribute. MidlRT was fixed for this issue last year and was available as of build 20196. Targeting the publicly available preview SDK fixes this issue. If you wanted to workaround this issue in Xaml for all versions of MidlRT, you should be able to do so by changing that attribute field from a boolean to an integer.

So, as of today, customers can successfully build the repro project by using the public preview Windows SDK (currently 20344) and using a non-prerelease Xaml Nuget (e.g. 2.5.0 or 2.6.0). Also, I'm fairly confident both of these bugs only affect winmd importing - the legacy import IDL syntax should be unaffected.

Fixed in the 22000 SDK for me - this issue can be closed.

Are there any plans to add these fixes in for Windows 10/previous versions of the Windows SDK and Windows Universal Runtime?

The 22000 SDK can be used to target Windows 10 (and even Windows 7, provided you avoid any API that was introduced since then). Since it's purely a compile-time issue, there is no update required to the OS itself.

I was able to get it to compile correctly on Windows 10 w/ the 22000 SDK, but when I try a deploy, I get an error telling me to update my OS, since the 'Windows Universal Runtime' also needs to be updated. Is it only possible to update that by going to Windows 11?

You need to keep the min target to something below 22000.

Ah thanks, that worked!


Disabling mappings causes behavior to fail

Since I'm not currently using Translatable or Loggable, I've disabled the mappings for the bundle shown:
orm:
    auto_mapping: true
    mappings:
        StofDoctrineExtensionsBundle: false

However, when using the Tree (closure) behavior I get an error:
No identifier/primary key specified for Entity 'Test\TestBundle\Entity\NodeClosure'. Every Entity must have an identifier/primary key.

If I turn the mappings back on (StofDoctrineExtensionsBundle: ~) then it seems to work. The problem with having the mappings turned on is that Doctrine then creates those translation and log tables in the database which I don't want.
Is this a bug?
A related question:
Let's say I just want the Loggable behavior but not the Translatable behavior (or vice versa), is there a way to configure the bundle so that it only creates the database tables that are actually needed and not all tables?

Well, the closure strategy also uses the mapping. It should be mentioned in the doc but this part was written before the closure strategy was added.
There is no way to register only part o the mapping of a bundle due to the way Doctrine works.


[DOC-7213] Split up Enterprise features, copyedit

[DOC-7213] Split up Enterprise features, strengthen calls to action, copyedit
NB: 22.1 doesn't have Cluster SSO, DB Console SSO, CDC Queries. 22.2 doesn't have CDC Queries
Previews
src/current/v22.1/enterprise-licensing.md
src/current/v22.1/get-started-with-enterprise-trial.md
src/current/v22.2/enterprise-licensing.md
src/current/v22.2/get-started-with-enterprise-trial.md
src/current/v23.1/enterprise-licensing.md
src/current/v23.1/get-started-with-enterprise-trial.md
Tests

[x] Local build
[x] Linkcheck

Sorry Matt, I don't think I can review this given there are so many non-relevant-to-security things on this doc. If this is mainly about reorganization of content and no changes per feature, then I think it should just be reviewed by the docs team.

src/current/v23.1/enterprise-licensing.md

If you could just review the last section of https://deploy-preview-17398--cockroachdb-docs.netlify.app/docs/v23.1/enterprise-licensing.html and let me know if you agree with the new summaries of these features, that would be helpful!

For Cluster SSO, change it to:
Grant SQL access to a cluster, using JWTs (JSON Web Tokens) issued by external identity providers(IdPs) or custom JWT issuers.
For DB Console SSO, change it to:
Grant access to a cluster's DB Console interface, using SSO through a OIDC-supporting external identity provider (IdP).

Grant access to a cluster's DB Console interface, using SSO through a OIDC-supporting external identity provider (IdP)

Done.