refactoring ipmi/test_ipmi_user.robot to remove some limitations

At run time, along with the root user there may be other users with ADMINISTRATOR privilege, and there is no guarantee that root will be assigned user ID 1. But the test cases are hard-coded to expect root at UID 1 and to have no other UIDs with ADMINISTRATOR privilege. Consequently, when those conditions are not met, there are several fails.
To address these issues I created the keyword Set Admin User ID List and apply it as the Suite Setup. It dynamically determines the UID for root and generates a list of UIDs that have ADMINISTRATOR privilege. It then sets those values into suite variables ${root_userid} and ${admin_ids}, respectively. With that addition the correct root UID is always available. And whenever a new UID is needed by a test case, the UIDs in ${admin_ids} are correctly avoided using the added Find Available User Id.
Here is my git patch for this change (it corrporates the changes I recommended for issue #2151):
diff --git a/ipmi/test_ipmi_user.robot b/ipmi/test_ipmi_user.robot
index a9d1857d..5149058f 100644
--- a/ipmi/test_ipmi_user.robot
+++ b/ipmi/test_ipmi_user.robot
@@ -1,10 +1,12 @@
 *** Settings ***
-Documentation       Test suite for OpenBMC IPMI user management.
+Documentation       Test suite for OpenBMC IPMI user management;
+                    ...  this suite will delete all non-administrative users.

 Resource            ../lib/ipmi_client.robot
 Resource            ../lib/openbmc_ffdc.robot
 Resource            ../lib/bmc_network_utils.robot
 Library             ../lib/ipmi_utils.py
+Suite Setup         Set Admin User ID List
 Test Setup          Printn

 Test Teardown       Test Teardown Execution
@@ -14,7 +16,6 @@ Test Teardown       Test Teardown Execution
 ${invalid_username}     user%
 ${invalid_password}     abc123
 ${new_username}         newuser
-${root_userid}          1
 ${operator_level_priv}  0x3
 ${user_priv}            2
 ${operator_priv}        3
@@ -26,6 +27,8 @@ ${ipmi_setaccess_cmd}   channel setaccess
 &{password_values}      16=0penBmc10penBmc2  17=0penBmc10penBmc2B
               ...       20=0penBmc10penBmc2Bmc3  21=0penBmc10penBmc2Bmc34
               ...       7=0penBmc  8=0penBmc0
+${expected_max_ids}     15
+${root_pattern}         ^.*\\sroot\\s.*ADMINISTRATOR.*$

 # User defined count.
 ${USER_LOOP_COUNT}      20
@@ -34,26 +37,28 @@ ${USER_LOOP_COUNT}      20

 Verify IPMI User Summary
     [Documentation]  Verify IPMI maximum supported IPMI user ID and
-    ...  enabled user form user summary
+    ...  enabled user from user summary.
     [Tags]  Verify_IPMI_User_Summary
     [Teardown]  Run Keywords  FFDC On Test Case Fail  AND
     ...  Delete Created User  ${random_userid}
-    # Delete all non-root IPMI (i.e. except userid 1)
+
+    # Delete all non-administrative users
     Delete All Non Root IPMI User
+    ${admin_user_count}  ${maximum_ids}=  Get Enabled User Count
+    Run Keyword If  ${admin_user_count} == ${expected_max_ids}
+    ...  Fail  msg= ${admin_user_count} admin users is unexpected!

     ${random_userid}  ${random_username}=  Create Random IPMI User
     Set Test Variable  ${random_userid}
     Run IPMI Standard Command  user enable ${random_userid}

-    # Verify maximum user count IPMI local user can have. Also verify
-    # currently enabled users.
-    ${resp}=  Wait Until Keyword Succeeds  15 sec  5 sec  Run IPMI Standard Command
-    ...  user summary ${CHANNEL_NUMBER}
-    ${enabled_user_count}=
-    ...  Get Lines Containing String  ${resp}  Enabled User Count
-    ${maximum_ids}=  Get Lines Containing String  ${resp}  Maximum IDs
-    Should Contain  ${enabled_user_count}  2
-    Should Contain  ${maximum_ids}  15
+    # Verify number of currently enabled users.
+    ${current_user_count}  ${maximum_ids}=  Get Enabled User Count
+    ${calculated_count}=  Evaluate  ${admin_user_count} + 1
+    Should Be Equal As Integers  ${current_user_count}   ${calculated_count}
+
+    # Verify maximum user count IPMI local user can have.
+    Should Be Equal As Integers  ${maximum_ids}  ${expected_max_ids}

 Verify IPMI User List
@@ -98,10 +103,10 @@ Verify IPMI User Creation With Valid Name And ID

 Verify IPMI User Creation With Invalid Name
     [Documentation]  Verify error while creating IPMI user with invalid
-    ...  name(e.g. user name with special characters).
+    ...  name (e.g. user name with special characters).
     [Tags]  Verify_IPMI_User_Creation_With_Invalid_Name

-    ${random_userid}=  Evaluate  random.randint(2, 15)  modules=random
+    ${random_userid}=  Find Available User Id
     ${msg}=  Run Keyword And Expect Error  *  Run IPMI Standard Command
     ...  user set name ${random_userid} ${invalid_username}
     Should Contain  ${msg}  Invalid data
@@ -109,7 +114,7 @@ Verify IPMI User Creation With Invalid Name

 Verify IPMI User Creation With Invalid ID
     [Documentation]  Verify error while creating IPMI user with invalid
-    ...  ID(i.e. any number greater than 15 or 0).
+    ...  ID (i.e. zero or any number greater than 15).
     [Tags]  Verify_IPMI_User_Creation_With_Invalid_ID

     @{id_list}=  Create List
@@ -202,14 +207,14 @@ Verify IPMI User Creation With Same Name
     [Documentation]  Verify error while creating two IPMI user with same name.
     [Tags]  Verify_IPMI_User_Creation_With_Same_Name
     [Teardown]  Run Keywords  FFDC On Test Case Fail  AND
-    ...  Delete Created User  2
+    ...  Delete Created User  ${random_userid}

-    ${random_username}=  Generate Random String  8  [LETTERS]
-    IPMI Create User  2  ${random_username}
+    ${random_userid}  ${random_username}=  Create Random IPMI User

     # Set same username for another IPMI user.
+    ${rand_userid_two}=  Find Available User Id
     ${msg}=  Run Keyword And Expect Error  *  Run IPMI Standard Command
-    ...  user set name 3 ${random_username}
+    ...  user set name ${rand_userid_two} ${random_username}
     Should Contain  ${msg}  Invalid data field in request

@@ -279,7 +284,7 @@ Test IPMI Administrator Privilege Level

 Test IPMI No Access Privilege Level
-    [Documentation]  Verify IPMI user with no access privilege can not run only any level command.
+    [Documentation]  Verify IPMI user with no access privilege can not run any level command.
     [Tags]  Test_IPMI_No_Access_Privilege_Level
     [Template]  Test IPMI User Privilege
     [Teardown]  Run Keywords  FFDC On Test Case Fail  AND
@@ -513,14 +518,87 @@ Modify IPMI User

 *** Keywords ***

+Set Admin User ID List
+    [Documentation]  Generates list of User IDs that have ADMINISTRATOR privileges
+    ...  and determines which one is root; sets generated values as suite variables.
+
+    ${resp}=  Wait Until Keyword Succeeds  15 sec  5 sec  Run IPMI Standard Command
+    ...  user list
+    @{lines}=  Split To Lines  ${resp}
+
+    ${root_userid}=  Set Variable  ${-1}
+    ${id_index}=     Set Variable  ${1}
+    ${count}=        Set Variable  ${0}
+    ${admin_ids}=  Create List
+    FOR  ${line}  IN  @{lines}
+        ${admin}=  Get Lines Containing String  ${line}  ADMINISTRATOR
+        ${count}=  Set Variable If  '${admin}' != '${EMPTY}'
+        ...  ${count+1}
+        ...  ${count}
+        Run Keyword If  '${admin}' != '${EMPTY}'
+        ...  Collections.Append To List  ${admin_ids}  ${id_index}
+
+        ${root_found}=  Get Lines Matching Regexp  ${line}  ${root_pattern}
+        ${root_userid}=  Set Variable If  '${root_found}' != '${EMPTY}'
+        ...  ${id_index}
+        ...  ${root_userid}
+
+        ${hdr_found}=  Get Lines Containing String  ${line}  Channel Priv Limit
+        ${id_index}=  Set Variable If  '${hdr_found}' == '${EMPTY}'
+        ...  ${id_index+1}
+        ...  ${id_index}
+    END
+    ${num_admins}=  Set Variable  ${count}
+    Set Suite Variable  ${num_admins}
+    Set Suite Variable  ${admin_ids}
+    Set Suite Variable  ${root_userid}
+
+    Log To Console  There are ${num_admins} administrative IPMI user IDs.
+    Log To Console  There list of administrative user IDs: ${admin_ids}.
+    Log To Console  The root user ID is ${root_userid}.
+    Run Keyword If  ${root_userid} < ${1}  Fail  msg= Did not identify root user ID.
+    Run Keyword If  ${num_admins} < ${1}   Fail  msg= Did not identify administrator user ID.
+
+
+Get Enabled User Count
+    [Documentation]  Return as integers: current number of enabled users and
+    ...  Maximum number of Ids.
+
+    # Isolate 'Enabled User Count' value and convert to integer
+    ${resp}=  Wait Until Keyword Succeeds  15 sec  5 sec  Run IPMI Standard Command
+    ...  user summary ${CHANNEL_NUMBER}
+    ${user_count_line}=  Get Lines Containing String  ${resp}  Enabled User Count
+    ${count}=  Fetch From Right  ${user_count_line}  \:
+    ${int_user_count}=  Convert To Integer  ${count}
+
+    # Isolate 'Maximum IDs' value and convert to integer
+    ${maximum_ids}=  Get Lines Containing String  ${resp}  Maximum IDs
+    ${max_ids}=  Fetch From Right  ${maximum_ids}  \:
+    ${int_maximum_ids_count}=  Convert To Integer  ${max_ids}
+
+    [Return]  ${int_user_count}  ${int_maximum_ids_count}
+
 Create Random IPMI User
     [Documentation]  Create IPMI user with random username and userid and return those fields.

     ${random_username}=  Generate Random String  8  [LETTERS]
-    ${random_userid}=  Evaluate  random.randint(2, 15)  modules=random
+
+    ${random_userid}=  Find Available User Id
+
     IPMI Create User  ${random_userid}  ${random_username}
     [Return]  ${random_userid}  ${random_username}

+Find Available User Id
+    [Documentation]  Find a userid that does not conflict with existing administrative userid
+    FOR    ${jj}    IN RANGE    300
+        ${random_userid}=  Evaluate  random.randint(1, ${expected_max_ids})  modules=random
+        ${is_id_unique}=  Run Keyword And Return Status  List Should Not Contain Value
+        ...  ${admin_ids}  ${random_userid}
+        Exit For Loop If  ${is_id_unique} == ${True}
+    END
+    Run Keyword If  ${is_id_unique} == ${False}  Fail  msg= Could not find free user_ID.
+    [Return]  ${random_userid}
+

 Enable IPMI User And Verify
     [Documentation]  Enable the userid and verify that it has been enabled.
@@ -561,7 +639,7 @@ Test IPMI User Privilege

     # Create IPMI user and set valid password.
     ${random_username}=  Generate Random String  8  [LETTERS]
-    ${random_userid}=  Evaluate  random.randint(2, 15)  modules=random
+    ${random_userid}=  Find Available User Id
     IPMI Create User  ${random_userid}  ${random_username}
     Set Test Variable  ${random_userid}
     Run IPMI Standard Command

Fix https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-test-automation/+/53531

Merged


Update the game over message

Update the game over message so people know how to play again!

Comement


Add Date to Order

Fixes #22
New field added - Date
This allows for better checking (isSameOrder check).
Changes to :

Model
Parser
Storage

Pull Request Test Coverage Report for Build 81

48 of 50 (96.0%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 80.636%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/seedu/address/model/order/OrderDate.java
15
17
88.24%

Totals

Change from base Build 69:
0.2%

Covered Lines:
1903

Relevant Lines:
2360

💛  - Coveralls


fix: broken link on github mobile

Fixes the 2 broken links to prometheus.io in the readme when accessed through github mobile
Please have a look @metalmatze
Fixes #14281

These links are not broken. Using :// is correct and omits the protocol. It can either be HTTP or HTTPS. To be fair, these days (finally), using HTTPS is the common one, and we could update this.

Yes agreed, tried to quickly access the site using github mobile, was unable to do so, which led me to create this edit

I don't have a strong opinion.
What do other maintainers think? Feel free to merge.

Using :// is correct

Nit: the code says // not ://.  I don't know if this makes a difference; I don't use GitHub Mobile.

Let's use https.

Using :// is correct

Nit: the code says // not ://. I don't know if this makes a difference; I don't use GitHub Mobile.

Oh. I think the code is correct and I accidentally added the : in my comment. Anyway, seems solved now.


Build vscode plugin in all CI operating systems

We have not been checking CI whether the vscode plugin can be compiled on Mac
and Windows. This change adds that CI check.

VSCode builds in Windows and MacOS! (On CI at least :sweat_smile: ).


How to change input style when RkTextInput is focused?

I'm desire to change styles (border color) only when RkTextInput is focused. How to do this?

Hi @silasrm,
Sorry for late reply. Currently css-like styling is not supported by Kitten. But this sounds like you can make some hooks on your component when it's state changed to focused.

Hi @artyorsh,
Thanks for reply. I'll try make manually.


Tracking issue for wrapQtAppsHook

This issue is to track the open pull requests for Qt applications broken by the addition of wrapQtAppsHook.
Maintainers, please refer to the manual for instructions to update your packages. Packages that conformed to the prior version of the manual should not need to be updated.
Pull requests

#65366
#65372

@ttuegel: Can you please clarify this. In the manual you linked to the example expression starts with
{ mkDerivation, lib, qtbase }:

and the text says
Import mkDerivation and Qt (such as qtbase modules directly. Do not import Qt package sets; [...].
This confuse me, since in this comment you seem to say the correct fix is to use qt5.mkDerivation (which AFAICT uses the qt5 package set). So, is using { fetchurl, qt5 }: qt5.mkDerivation { ... } ok?

Packages that conformed to the prior version of the manual should not need to be updated.

This also confuse me:

Where is the prior version of the manual?
If the manual changed (new recommended way to write expressions for Qt apps), why shouldn't every expression be updated to follow the latest guideline?

So, is using { fetchurl, qt5 }: qt5.mkDerivation { ... } ok?

I'm sorry for being unclear. What I mean is, you should write
{ mkDerivation }: mkDerivation { ... }

and call the package with qt5.callPackage or libsForQt5.callPackage.

If the manual changed (new recommended way to write expressions for Qt apps), why shouldn't every expression be updated to follow the latest guideline?

The prior version of the manual is still on the NixOS website. The recommended way to write expressions for Qt applications has not changed. I updated the manual to include information about wrapQtAppsHook because that is new. Using stdenv.mkDerivation with Qt applications has always been unsupported. Expressions that already conformed to the manual do not need to be updated. Expressions that did unsupported things before are probably broken now.

I think the lxqt desktop may have been broken. lxqt-session complains that it can't find the "xcb" plugin in "", which probably means its platform plugin path is wrong or not set.
My NixOS xserver config in case it's relevant:
services.xserver = {
      enable = true;
      videoDrivers = [ "vesa" "modesetting" ];
      displayManager.sddm.enable = true;
      desktopManager.lxqt.enable = true;
};

@Thra11 It appears that all of the expressions for lxqt use stdenv.mkDerivation instead of mkDerivaiton.

Hmmm, I'm hitting some weirdness on master right now, from a nixos-19.03 system.
Tell me if it's not related.
~/tmp/nixpkgs/nixpkgs $ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.

~/tmp/nixpkgs/nixpkgs $ git rev-parse HEAD
a7d6390804c1f18737f71be62a02799f1b23e9a6

~/tmp/nixpkgs/nixpkgs $ nix-build -A cool-retro-term
/nix/store/3laxbqbiwclcvf6iir0rw9d391yjyd6a-cool-retro-term-1.1.1

~/tmp/nixpkgs/nixpkgs $ result/bin/cool-retro-term
Cannot mix incompatible Qt library (version 0x50c00) with this library (version 0x50c03)
Aborted

~/tmp/nixpkgs/nixpkgs 134 $ env -i DISPLAY="$DISPLAY" XAUTHORITY="$XAUTHORITY" result/bi
n/cool-retro-term
[... basically it works ...]

The fact that it works with env -i makes me think there may be contamination from my env.
What's peculiar is that from not too far back, it worked, so I'm bisecting.
eb4e067686d1121d2d4a3d7ac2ed080339125eeb # bad
70eae830431368d04abc387069a30450220e9247 # good

The bad commit being the merge of the good to master.
(Though I cannot test using cool-retro-term for bisecting.)

It seems like there is some part of Qt 5.12.0 (0x50c00) is sticking around after the upgrade to Qt 5.12.3 (0x50c03), but I'm at a complete loss as to what. I do not think this is related to wrapQtAppsHook, at least not directly.

The reason I think it may be related, is that when clearing the environment with env -i it ends up working. It may be that something needs to be added to the wrapper that wasn't already.

Digging more, now that I have slept, I think I traced the issue.
16510 openat(AT_FDCWD, "/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin/lib/qt-5.12/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so", O_RDONLY|O_CLOEXEC) = 7
16510 read(7, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\216\0\0\0\0\0\0"..., 832) = 832

libibusplatforminputcontextplugin

unset QT_IM_MODULE and it crashes later. So, there is at least an input method impurity...
(Following up in another comment for the other impurity.)

(Ensure you're not on a fresh master as the upgrade has been reverted.)
Without the input method impurity, I have multimc, and cool-retro-term somehow loading from the system path.
1603 16752 readlink("/nix/store/2d365d3hrp4h9ybpr60dxv74hbwyb0df-system-path/lib/qt-5.12/plugins/platforms", "/nix/store/9q4gqkxpzfy0sl37wsnqw"..., 4095) = 91
1606 16752 lstat("/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
[...]
8149 17520 openat(AT_FDCWD, "/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin/lib/qt-5.12/plugins/bearer/libqconnmanbearer.so", O_RDONLY|O_CLOEXEC <unfinished ...>

 1307 18954 readlink("/nix/store/2d365d3hrp4h9ybpr60dxv74hbwyb0df-system-path/lib/qt-5.12/plugins/platforms", "/nix/store/9q4gqkxpzfy0sl37wsnqw"..., 4095) = 91
1310 18954 lstat("/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
[...]
14675 18954 openat(AT_FDCWD, "/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin/lib/qt-5.12/plugins/sqldrivers/libqsqlite.so", O_RDONLY|O_CLOEXEC) = 14

I have unset QT_PLUGIN_PATH and QTWEBKIT_PLUGIN_PATH, I have no other Q* environment variables; unsetting XDG_DATA_DIRS is not the solution either.
Though, unsetting PATH helps.

Quoting myself from #44047

What is going on currently is that for any Qt plugin, they will be loaded according to the environment, and according to some hard-coded paths relative to components of PATH. This will not work properly when the environment is cleared or manipulated. (With non-NixOS platforms, using nix-shell to start a Qt application when none have been installed using nix may cause such failure.)

The current wrapper does not handle adding components to PATH so they will be searched.

So, there is at least an input method impurity...

This is intentional: we don't want for users to rebuild the world to change input methods. :slightly_frowning_face:

The current wrapper does not handle adding components to PATH so they will be searched.

Searching PATH components is another intentional impurity which predates the wrapQtAppsHook changes. However, this improves with the wrapper because fewer things need to have their plugins propagated into the system environment.

This is intentional: we don't want for users to rebuild the world to change input methods. :slightly_frowning_face:

I figured, sorry if it seemed to imply otherwise, I was just stating the fact. Though I think the impurity is not "the input method is giving a full path to use as a library", but instead that it has to be resolved with the libraries path the software is given to work with. Sorry if that sentence is hard to parse, I'm still testing one final thing related to this.

Searching PATH components is another intentional impurity which predates the wrapQtAppsHook changes. However, this improves with the wrapper because fewer things need to have their plugins propagated into the system environment.

Yeah, I understand, but in real world use, it is part of the main issue, having mismatched Qt versions in the (overall) environment will break Qt apps.
After my test is done building, I'll share a, hopefully, good fix for the problem.

#65526 is likely to solve the mismatched minor versions for good.

#65543 fix qt5ct

I've tried 2 things to make the problem disappear with wireshark but I still have the issue
Cannot mix incompatible Qt library (version 0x50c00) with this library (version 0x50c03) when I run result/bin/wireshark.
see the last 2 commits at https://github.com/teto/nixpkgs/tree/nixos-unstable
I have 2 other questions:

wireshark can build without qt (the console binary). What would be the most elegant way of achieving that
Also I wonder if with the new infrastructure, the wireshark binary is supposed to work in a nix-shell, as it's not wrapped yet (just after running the buildPhase) ?

seems like it got fixed with my changes and that PR https://github.com/NixOS/nixpkgs/pull/65526

The logic in wrapQtAppsHook() seems iffy: the elif [ -h "$file" ] branch will never run for symlinks to files, because if [ -f "$file" ] returns success for these. A simple fix is to swap these branches so the -h test runs first.

not sure if related, but qutebrowser stopped working a couple of days ago for me on unstable.
`08:45:38 WARNING: Could not find the Qt platform plugin "xcb" in ""
08:45:38 CRITICAL: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Fatal Python error: Aborted
Current thread 0x00007f1c78a9ab80 (most recent call first):
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 87 in _die
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 222 in _check_modules
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 238 in check_libraries
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 296 in early_init
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/qutebrowser.py", line 190 in main
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/bin/..qutebrowser-wrapped-wrapped", line 11 in
Aborted
`

#65710 fix for flameshot

also radare2-cutter

@FRidh I think it's good if this is pinned? There is a very large amount of reports coming in daily.

it totally makes sense to pin it since the longterm fix broke - in the short term - many things.

it totally makes sense to pin it since the longterm fix broke - in the short term - many things.

Indeed, I think this is an issue that needs as much attention as a ZHF one would need.
Almost blocking release in fact.

An approximate list of packages called with qt5.callPackage that use stdenv.mkDerivation, generated by grepping through nixpkgs master, is:
../applications/misc/doomseeker/default.nix
../applications/graphics/fstl/default.nix
../applications/networking/browsers/otter/default.nix
../development/tools/analysis/snowman/default.nix
../development/libraries/gecode/3.nix
../development/libraries/gecode/default.nix
../os-specific/linux/i7z/default.nix
../os-specific/linux/v4l-utils/default.nix
../applications/audio/carla/default.nix
../applications/video/clipgrab/default.nix
../applications/radio/gqrx/default.nix
../applications/networking/instant-messengers/spectral/default.nix
../applications/radio/qsstv/default.nix
../applications/misc/cura/stable.nix
../applications/misc/cura/lulzbot.nix
../applications/misc/cura/plugins.nix
../applications/misc/vym/default.nix
../applications/radio/wsjtx/default.nix
../applications/graphics/scantailor/advanced.nix
../development/tools/minizinc/ide.nix
Maybe the maintainers of these should be pinged?

It seems that the wrap-qt-apps-hook only wraps ELF executables. How to fix a python program?

@vbgl To wrap manually.

wrapQtApp in postFixup.

I'm using the following command to find the remaining packages that need fixing: find . -type f -exec grep -q 'qt5' {} \; -exec grep -l 'stdenv.mkDerivation' {} +

Something that is still not completely clear to me: Should all Qt applications be changed to not use stdenv.mkDerivation or only those that are broken by the most recent changes? I did try to run a few Qt-applications that still use stdenv.mkDerivation but I couldn't get them to crash, so I'm wondering if they are fine already or if my NixOS machine is in a state that by chance has the right qt versions? Do I need to first install some older version of qt to make them reliable crash?

All Qt applications not wrapped should end up crashing in those situations. Some had ad-hoc fixes added with custom wrappers, though, which could mask issues.

I'm trying to update flent (a python application using pyqt) to latest release. I've got the output working by running wrapQtApp in postFixup, but this new version wants to try running the gui as part of the tests. I've skipped that test to verify postFixup thing works but I'd rather not drop that test. How can I do the equivalent for running buildPythonApplication tests?

I think we should avoid custom builders when we can, because they don't allow for composition when different frameworks/languages are used together. This is also the reason why I am separating buildPythonPackage into hooks.
@mmlb you might be able to move it to postInstall. That way it is wrapped before tests start.

I think we should avoid custom builders when we can, because they don't allow for composition when different frameworks/languages are used together. This is also the reason why I am splitting buildPythonPackage into hooks.

makes sense to me

@mmlb you might be able to move it to postInstall. That way it is wrapped before tests start.

This didn't work. I'm only wrapping the packaged programs, but need to make python setup.py test be wrapped. I'm thinking about writing a custom checkPhase that runs a wrapped script.

I tried to fix notepadqq, but apparently the wrapper does not pick up the necessary plugins (no QT_PLUGIN_PATH). Any ideas what I am doing wrong?

I'm thinking about writing a custom checkPhase that runs a wrapped script.

This worked. https://github.com/NixOS/nixpkgs/pull/66323

Documented wrapQtAppsHook ignoring files that are not ELF headers #66325

@ttuegel

Do not import Qt package sets; the Qt versions of dependencies may not be coherent, causing build and runtime failures.

What does it mean? Could you provide some examples?

I updated the manual to show how to do this. I was uncomfortable demonstrating what not to do, but since you asked, the import line of packages should look like this:
{ qtbase, qtdeclarative }: /* et cetera */

and not like this:
{ qt5 }: /* or qt59, qt512, or anything else like that */

Therefore, your buildInputs should look like this:
{
  buildInputs = [ qtbase ];
}

and not like this:
{
  buildInputs = [ qt5.qtbase ];
}

@ttuegel Got it, thank you!

@AndersonTorres: cutegram seems to suffer from the same issue.

Anki fixed in #66796.

Introducing wrapQtAppHook into qt5.mkDerivation pollutes a closure of non-Qt variants of packages using that deriver: https://github.com/NixOS/nixpkgs/pull/67134

@MP2E dolphinEmuMaster is broken in master currently, requiring fixes as described by this issue.
cc @marius851000 @ashkitten @delroth

taking a look, @aanderse

#67244 bumps teamviewer, builds with the latest QT and uses the new QT hook.

Introducing wrapQtAppHook into qt5.mkDerivation pollutes a closure of non-Qt variants of packages using that deriver:

I would recommend selecting the deriver based on if the package is using Qt, i.e. (if withQt then mkDerivation else stdenv.mkDerivation) { ... }.

There is an issue with variables added to qtWrapperArgs not being expanded properly.
In case of a gstreamer application, this doesn't work:
  qtWrapperArgs = [
    "--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : $GST_PLUGIN_SYSTEM_PATH_1_0"
  ];

Where as this does:
postInstall = ''
  qtWrapperArgs+=(--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : $GST_PLUGIN_SYSTEM_PATH_1_0)
'';

@ttuegel

Using stdenv.mkDerivation with Qt applications has always been unsupported.

Why, though? The reasoning behind this doesn't seem to be documented anywhere that I can see, and I'm wondering what the benefit is versus using a hook. The manual merely says:

mkDerivation is a wrapper around stdenv.mkDerivation which applies some Qt-specific settings.

And as far as I can tell from reading the Nix expression for it, the only thing it does aside from adding wrapQtAppsHook is configuring some debug flags based on an argument to the Qt package set. So I have some questions:

Have I missed something that the custom deriver is doing?
Is the per-set debug flag configuration something that can only be done by using a custom deriver...?
Is the deriver approach more composable than the hook approach?
Why is it called mkDerivation rather than something like mkQtDerivation? The difference between stdenv.mkDerivation and mkDerivation is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that qt5.mkDerivation exists a priori.

Why is it called mkDerivation rather than something like mkQtDerivation? The difference between stdenv.mkDerivation and mkDerivation is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that qt5.mkDerivation exists a priori.

Agree that the naming isn't ideal. It would be a bit of a pain to rename everything now though.

Why is it called mkDerivation rather than something like mkQtDerivation? The difference between stdenv.mkDerivation and mkDerivation is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that qt5.mkDerivation exists a priori.

Agree that the naming isn't ideal. It would be a bit of a pain to rename everything now though.

Indeed. Though if someone wanted to submit a proposal to change this it would be considered.
(obviously after the branch off)

There is an issue with variables added to qtWrapperArgs not being expanded properly.

This may not be desirable, but it is expected that shell variables will not expand. Off hand, I don't know how (or when!) to expand them during the build.

And as far as I can tell from reading the Nix expression for it, the only thing it does aside from adding wrapQtAppsHook is configuring some debug flags based on an argument to the Qt package set. So I have some questions:
1. Have I missed something that the custom deriver is doing?

No, but the custom deriver reserves the right to claim more behaviors in the future.

2. Is the per-set debug flag configuration something that can only be done by using a custom deriver...?

3. Is the deriver approach more composable than the hook approach?

4. Why is it called `mkDerivation` rather than something like `mkQtDerivation`? The difference between `stdenv.mkDerivation` and `mkDerivation` is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that `qt5.mkDerivation` exists a priori.

The answer to all these questions is roughly, "Because the largest package set I'm familiar with in Nixpkgs is haskellPackages, and this is how it works." That's not a great answer, but I figure we could do worse than to imitate a large, mature set of packages.
I'm open to switching to a hook-based architecture after NixOS 19.09. Whether we keep a custom deriver or switch to a hook, we should also start failing the build if the correct one isn't included.

I've a question regarding development of Qt applications on NixOS. I'll take the thing I'm attempting currently as an example.
I'd like to try out and possibly code on the current Kate master. To do so I've written a small nix expression:
{ pkgs ? import <nixpkgs> {} }:
with pkgs;
let
  kate = kdeApplications.kate.overrideAttrs (oldAttrs: rec {
    buildInputs = oldAttrs.buildInputs ++ [ ninja ripgrep vim strace ];
  });
in
  kate

This extends the buildInputs for Kate with some development tools. I enter the dev environment with nix-shell --pure. The --pure is there to avoid clashing with my installed version of kate.
However, the unit tests (ctest -V) fail with the infamous qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "".
In this environment, QT_PLUGIN_PATH, QT_QPA_PLATFORM and QT_QUICK_CONTROLS_STYLE are not set. HOME, DISPLAY, XDG_CONFIG_DIRS and XDG_CONFIG_DIRS are not set. Setting the QT_* variables does not solve the problem.
Is this the right way to enter a dev environment for developing Qt applications? I'm especially keen on reusing the NixPkgs definitions of the applications.

Is this the issue related to -
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

If so, it would help to mention this in the issue description I feel

I want to fix #65564 but I still don't understand exactly what changed that caused VirtualBox to break. What exactly was changed in the behavior of the Qt derivations which results VirtualBox no longer finding what it needs? Was the default search behavior of Qt somehow modified?

The following explanation might lack precision, but the gist of it is basically right.
"Nothing" changed in how Qt looks for its libraries, as far as Qt is concerned. What changed in #54525 is that with the change, it relies on adding wrappers to correctly find the right dependencies.
Those wrappers, in turn, AFAIUI, breaks assumptions in the hardening.

@samueldr The interesting thing is that the VirtualBoxVM binary, when used with hardening, always unsets QT_PLUGIN_PATH. So the reason that it worked before cannot be that QT_PLUGIN_PATH happened to include the right paths. So just by what mechanism did it find the plugins before? Maybe something related to propagatedBuildInputs?
Though, it really does not matter any more because I've just managed to make it work and will open a PR soon.

I meant propagatedUserEnvPkgs...

So the reason that it worked before cannot be that QT_PLUGIN_PATH happened to include the right paths. So just by what mechanism did it find the plugins before?

We have a custom patch which scans for plugins relative to entries in PATH, and this was probably how it worked. This mechanism has always been very fragile; the purpose of the changes made to Qt packaging was to avoid relying on this mechanism. I don't have an explanation for why this mechanism has broken now, though.

So the reason that it worked before cannot be that QT_PLUGIN_PATH happened to include the right paths. So just by what mechanism did it find the plugins before?

We have a custom patch which scans for plugins relative to entries in PATH, and this was probably how it worked. This mechanism has always been very fragile; the purpose of the changes made to Qt packaging was to avoid relying on this mechanism. I don't have an explanation for why this mechanism has broken now, though.

I think this should be removed. One problem is that it is a security issue for VirtualBox which is setuid (not sure exactly when it drops privileges though).

I think this should be removed.

So do I, that was the primary motivation introducing wrapQtAppsHook.

Is there any guidance how to do this with PyQt based applications? See https://github.com/NixOS/nixpkgs/pull/68405

I am not certain which parts of this report are related to this issue:
I followed the nixos-unstable channel to e19054ab3cd5b7cc9a01d0efc71c8fe310541065
I have kdenlive among my systemPackages; after the update, running kdenlive from a Konsole window results in hundreds of warnings and "Unknown asset" lines followed by a segfault. I can launch kdenlive from the menu. It starts and seems to work, but rendering a video fails with this error log:
Rendering of /home/acowley/Videos/bloop.mp4 crashed

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, minimal, offscreen, vnc, xcb, wayland-org.kde.kwin.qpa.

Usually I start kdenlive from the terminal so I see all its gory log output, but I don't know how to reveal that when starting it from the launcher. This latter error looks like a helper executable not being wrapped, but I do not know which executable that might be.

@acowly: sounds related to https://github.com/NixOS/nixpkgs/issues/68404.

It seems like mlt might not be properly wrapped, which could be the rendering problem. No idea yet on the launching from a terminal problem.

I think @bjornfor was correct that the melt executable is not properly wrapped, as I was able to follow the suggestion at his link and end up with a better-looking wrapper. However, it turns out this was not the cause of the error I saw. kdenlive caches paths for an MLT profiles folder and a Melt path under Settings -> Configure Kdenlive -> Environment. If you clear these out, it will discover the right paths and populate the GUI elements. I'm working on a patch to get us out of that hole.

I'm just curious, if I understand, all apps should use mkDerivation instead of stdenv.mkDerivation no? Then, why can't we "just" search all stdenv.mkDerivation and turn them into mkDerivation, at least for simple enough packages? That could avoid bad surprises at runtime.

@tobiasBora mkDerivaiton here is from qt*. Everyone should use stdenv.mkDerivation unless it's a qt application and needs that special deriver.
Though it was discussed if we could get a semi-automated way to figure out what expressions need to be fixed.

Though it was discussed if we could get a semi-automated way to figure out what expressions need to be fixed.

It would be simple, at least, to add a check to the qtbase setup hook that some special variable is set by the deriver, and fail those builds with do not use it.

@ttuegel That actually does sound very simple :sparkles:
If we could set that up we could get a hydra jobset for the PR and I think have them all fixed.
I'm not sure at this point we could block 19.09 on that, we have to release eventually.
But all the fixes that come out of that should be completely fine for backports.

For meshlab, I'm moving to the hook in #70937.

Is there really no way we can do without a custom deriver? I mean, Qt in the end are "just" libraries, its not its own build system. I get there are issues, but, using custom derivers prevents composition.

Is there really no way we can do without a custom deriver? I mean, Qt in the end are "just" libraries, its not its own build system.

@FRidh I think Qt is closer to Python or Emacs because it (effectively) has its own runtime system. It's not just a library on top of the C runtime. That aside, your point is well taken, and I will see about getting rid of the custom deriver.

@ttuegel It seems quite a few (perhaps all) of the python packages depending on pyqt5 an pyqt4 are currently broken, e.g. matplotlib qt backend, jupyter qt-console.
Since python packages don't directly use stdenv, the doc referenced above doesn't directly apply. Are there any suggestions on the idiomatic way fixing this. Using propagatedBuildInputs with wrapQtAppsHook in pyqt5 doesn't fix the problem.

Could someone finish the review at #67806?

Not sure this is something we care about too much, but sometimes python+Qt packages seem to be double-wrapped. See openshot-qt and https://github.com/NixOS/nixpkgs/pull/71335. Is there a way to avoid this (seems like rapid-photo-downloader avoids it)?

[crossposting from #71335]
I skimmed a bunch of the files rg -l python $(rg -l dontWrapQtApps) yielded, which yielded a better technique to avoid double-wrapping: https://github.com/NixOS/nixpkgs/blob/f203d50d09052792866f926e7c2d3b3bf76d3388/pkgs/games/anki/default.nix#L165-L169

You can do
dontWrapQtApps = true;
makeWrapperArgs = [
  ""\${qtWrapperArgs[@]}""
];

I've documented to do the something like this for gtk applications recently

https://nixos.org/nixpkgs/manual/#ssec-gnome-common-issues

I'm still not really sure why we need the quoting, and I've been saving some PRs trying to figure out how to get rid of that.

I've needed to use "\"\${qtWrapperArgs[@]}\"", which I assume is what you meant. I've been saving some PRs for after I figure out how to get rid of that. Seems like an escaping issue we should be able to fix.

Oops, guess I misspelled. Updated the example.
I've actually suggested this a while ago so there's examples in nixpkgs that work fine

https://github.com/NixOS/nixpkgs/blob/c9b85da380d4c15e3bec8b7d2124455e0fbae423/pkgs/applications/networking/browsers/webmacs/default.nix#L32

Then afterwards documented it for gtk.

Basically, this approach seems to break with GTK, because the array may contain empty elements (for environment variables that don't actually need prefixing with anything). Improving that (by excluding empty vars from being appended) causes a rather huge rebuild, so I decided against it.
Frankly, I think the fix for that belongs in buildPythonApplication, since we shouldn't be doing word splitting on makeWrapperArgs anyway.

Hi, are there any ideas or progress on how to fix pyqt -> matplotlib & others?

Some that are yielding the good ol' wrapQtAppsHook:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/analysis/hotspot/default.nix
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/profiling/heaptrack/default.nix

paraview needs the hook too

tikzit needs the hook as well

qview needs a fix

qgo appears to need this

Various packages that were mentioned needed fixes are in https://github.com/NixOS/nixpkgs/pull/80982

If anyone as any idea what to do about matplotlib and python libraries... I would be happy to try implementing it. The issue is https://github.com/NixOS/nixpkgs/issues/80147

android-studio (avd) seems to need this:
9:29 PM	Emulator: Fatal: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

9:29 PM	Emulator:

9:29 PM	Emulator: Available platform plugins are: xcb.

9:29 PM	Emulator: ((null):0, (null))

9:29 PM	Emulator: Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/16

mnemosyne is also failing.
Since it's a python application that uses pyqtwebengine and python.pkgs.buildPythonApplication, what is the recommendation for a fix here?

@unode: Take a look at expression for qutebrowser.

Thanks @rnhmjoj . Pull request #84954

I think this wrap with the python development mode is broken. See this demo repository I created: https://github.com/shuhaowu/nix-qt-python-dev-mode-failure.
To reproduce:

Clone that repository.
$ nix-shell
$ qt-test
Watch the following error occur and the program crashes:

qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

However, outside of nix-shell is fine. To reproduce:

Clone that repository.
$ nix-build
$ result/bin/qt-test
See the hello world message.

What's going on here? Also any criticism on my default.nix file is welcome as I'm still a nix noob.

The previous issue seems to be solved if the wrapQtApp wrapped script's environment variable is exported into command line. For me this was:
export QT_PLUGIN_PATH='/nix/store/0d8hv33sqxbzi3gkvcv1wd7y101n9ldv-qtbase-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QT_PLUGIN_PATH='/nix/store/a8b5vd0hy86pqmrsvxdx88qzpd4kkk09-qtsvg-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QT_PLUGIN_PATH='/nix/store/jjyjr2ck1k21s6z7lr3ip2yj7d10k4iw-qtdeclarative-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QML2_IMPORT_PATH='/nix/store/jjyjr2ck1k21s6z7lr3ip2yj7d10k4iw-qtdeclarative-5.12.7-bin/lib/qt-5.12.7/qml'${QML2_IMPORT_PATH:+':'}$QML2_IMPORT_PATH
export QML2_IMPORT_PATH='/nix/store/gbal6xsngnpsdbw40qqvfmddrqb8ck73-qtquickcontrols-5.12.7/lib/qt-5.12.7/qml'${QML2_IMPORT_PATH:+':'}$QML2_IMPORT_PATH
export QT_PLUGIN_PATH='/nix/store/j86x96jnfjk6f7p63kfm9q5c19c2dc9c-qtwayland-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QML2_IMPORT_PATH='/nix/store/j86x96jnfjk6f7p63kfm9q5c19c2dc9c-qtwayland-5.12.7-bin/lib/qt-5.12.7/qml'${QML2_IMPORT_PATH:+':'}$QML2_IMPORT_PATH

Adding this before launching qt-test from nix-shell appears to work! Now to turn this into a nix-shell friendly solution is a different problem...

I'm encountering this with plover on NixOS 20.09:
$ nix-env -iA nixos.plover.dev
installing 'python3.6-plover-4.0.0.dev8'
these paths will be fetched (26.60 MiB download, 149.08 MiB unpacked):
  /nix/store/1c86mzzxdn1gh3zsr8m48pf31vqwk92p-python3.6-PyQt5.sip-4.19.24
  /nix/store/1yzd3q817p1kznaxh5nqwgbqqk24pdhc-python3.6-dbus-python-1.2.16
  /nix/store/50bbqdln7l97b36awlw019r25bl3f8xw-python3.6-appdirs-1.4.4
  /nix/store/6j31qc3nv1znmp98bvbcrydy5bikrpwc-python3.6-pytz-2020.1
  /nix/store/9hw5qi4q2gsw7gjyb1z9mz0qa4szf20f-python3.6-six-1.15.0
  /nix/store/bb47dgrdx1qgyw5zjvlmy503g2yj6b0b-python3.6-pyserial-3.4
  /nix/store/bjncdzcpgvv52sbq0qr8c6aa3lk1basa-python3.6-xlib-0.25
  /nix/store/bl7cj3fxgr43qwy48w96xrbxrqgi89a3-python3.6-dbus-python-1.2.16-dev
  /nix/store/d3lxh9n89rsf28v5zyn8pbghbc0cwqmg-python3.6-PyQt5-5.15.1
  /nix/store/hss1wvb697a1wwnakbxsqm6q14wd2pb5-python3.6-plover-4.0.0.dev8
  /nix/store/im3nhrxmbmdszffm56p64d938hvhl7im-python3.6-wcwidth-0.2.5
  /nix/store/iswawhahkrdvwcwkr9qkkf36v7rxgfm4-python3.6-PyQt5-5.15.1-dev
  /nix/store/l0pzd5jxgg6hj23si7kf3cp9cpkj3r96-python3-3.6.12
  /nix/store/whxcnpcdi8rvwgx1cg794ximylvf38rr-python3.6-setuptools-47.3.1
  /nix/store/x6fxich0cyszdiq34zh7jwl2470xk57k-python3.6-Babel-2.7.0
copying path '/nix/store/l0pzd5jxgg6hj23si7kf3cp9cpkj3r96-python3-3.6.12' from 'https://cache.nixos.org'...
copying path '/nix/store/1yzd3q817p1kznaxh5nqwgbqqk24pdhc-python3.6-dbus-python-1.2.16' from 'https://cache.nixos.org'...
copying path '/nix/store/50bbqdln7l97b36awlw019r25bl3f8xw-python3.6-appdirs-1.4.4' from 'https://cache.nixos.org'...
copying path '/nix/store/bb47dgrdx1qgyw5zjvlmy503g2yj6b0b-python3.6-pyserial-3.4' from 'https://cache.nixos.org'...
copying path '/nix/store/whxcnpcdi8rvwgx1cg794ximylvf38rr-python3.6-setuptools-47.3.1' from 'https://cache.nixos.org'...
copying path '/nix/store/6j31qc3nv1znmp98bvbcrydy5bikrpwc-python3.6-pytz-2020.1' from 'https://cache.nixos.org'...
copying path '/nix/store/9hw5qi4q2gsw7gjyb1z9mz0qa4szf20f-python3.6-six-1.15.0' from 'https://cache.nixos.org'...
copying path '/nix/store/bl7cj3fxgr43qwy48w96xrbxrqgi89a3-python3.6-dbus-python-1.2.16-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/1c86mzzxdn1gh3zsr8m48pf31vqwk92p-python3.6-PyQt5.sip-4.19.24' from 'https://cache.nixos.org'...
copying path '/nix/store/bjncdzcpgvv52sbq0qr8c6aa3lk1basa-python3.6-xlib-0.25' from 'https://cache.nixos.org'...
copying path '/nix/store/x6fxich0cyszdiq34zh7jwl2470xk57k-python3.6-Babel-2.7.0' from 'https://cache.nixos.org'...
copying path '/nix/store/d3lxh9n89rsf28v5zyn8pbghbc0cwqmg-python3.6-PyQt5-5.15.1' from 'https://cache.nixos.org'...
copying path '/nix/store/im3nhrxmbmdszffm56p64d938hvhl7im-python3.6-wcwidth-0.2.5' from 'https://cache.nixos.org'...
copying path '/nix/store/iswawhahkrdvwcwkr9qkkf36v7rxgfm4-python3.6-PyQt5-5.15.1-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/hss1wvb697a1wwnakbxsqm6q14wd2pb5-python3.6-plover-4.0.0.dev8' from 'https://cache.nixos.org'...
building '/nix/store/lyy5m5m81iygkxcmh9vgb74sk8ai2jkf-user-environment.drv'...
created 2252 symlinks in user environment

 $ plover
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

fish: “plover” terminated by signal SIGABRT (Abort)

@Xe already tracked in #98069, and I think it's more similar to #98067 than this particular issue.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/streamdeck-ui-on-unstable-getting-qt-error/27996/1

this also seems to effect melonDS


Make tabs more intuitive

I believe that doing the following would help make this application feel more intuitive:

Dragging a tab out of the window opens that tab in a new window
Dragging a tab when that is the only tab in the window moves the window instead of the tab

I think it'd be great if dragging a tab out of the window will open that tab in it's own window as users will likely do this instinctively anyways (as this is how tabs work in browsers like Chrome, Edge & Firefox).
By having it so when the user drags the tab out of the window, letting go of the tab will open that tab in a new window at the point where the user let go of the tab. There should only be one exception to this feature being that dragging a tab when it's the only tab in the window (in this case dragging the single tab) should revert to moving the window around.
For reference, open a browser like Edge, Firefox or Chrome and drag a tab out of the window when there are multiple tabs present and when there is only one tab present; that is the experience I believe that would help make this application feel more intuitive for the end-user.

Drag and drop for tabs has already been implemented, and will be available in the next version of the app: #1432

https://docs.microsoft.com/en-us/uwp/api/microsoft.ui.xaml.controls.tabview.tabdroppedoutside?view=winui-2.4

Thank you for creating this feedback item. A solution to this issue is currently resolved in one of our active development branches and will be shipped after we've validated that everything works properly via code review.
We will notify you when this feature is in a PR

Duplicate of #828
Please subscribe to the original feedback item for the latest notifications and status updates.


Target Net Standard 2.0

Few minor changes inside csproj:

Added netstandard2 target.
Moved nuspec metadata into csproj (Msbuild can now create nupkg directly with /t:pack).
Removed unused references.
Updated test csproj.

Also updated gulp file to support restoring packages and switched to msbuild for package build.
PS - Looks like your build agent is not up to date (does not have the latest MsBuild installed?)

Can you check on the build agent issue? @mikeobrien might need to look at it.

@amullins83 looking into this, I'll try to get it fixed today or tomorrow.

Hey @amullins83 I'm migrating the build for this over to Azure Dev Ops to make it easier for others to manage it. I just added you to the HID Library team, not sure if it notifies you. Lemme know if you don't see anything. I'll make you and admin on the project as well. Anyways, hopefully this will kill two birds with one stone.

Thanks. I got a notification that the name changed and I was a bit confused
because I didn't know I was on that AzDO team. The company I work for uses
AzDO, so I'm familiar with that system, though not as much on the NuGet
part.
Austin Mullins
On Mon, Dec 30, 2019 at 4:48 PM mikeobrien<EMAIL_ADDRESS>wrote:

Hey @amullins83 https://github.com/amullins83 I'm migrating the build
for this over to Azure Dev Ops to make it easier for others to manage it. I
just added you to the HID Library team, not sure if it notifies you. Lemme
know if you don't see anything. I'll make you and admin on the project as
well. Anyways, hopefully this will kill two birds with one stone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mikeobrien/HidLibrary/pull/105?email_source=notifications&email_token=AABQUXA7SAOGDHUEVUZVJ3LQ3J3D7A5CNFSM4GMTILUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH3L7EQ#issuecomment-569819026,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABQUXBFLDG4LHQ3RQCIOY3Q3J3D7ANCNFSM4GMTILUA
.

Cool, well I'll try to get it wrapped up tomorrow. My company is using it too, not hard to use. Nice thing is you can set it to use the latest version of windows so the tooling never gets behind like it is now on my personal server.

@amullins83 so the Azure build is setup and working. Commits to master will push the nuget, branches and PR's will trigger builds but not push the nuget (just package it). It's configured to use the latest build tools so hopefully we dont have to worry about falling behind. Added you as an admin so you can get in there too. Let me know if we need anything else done with the build stuff.
Oh, and I haven't tested PR builds. AFAIK it should work and it should show a build result banner. I dont have time ATM to test that but let me know if you notice that not working.

@w-michal BTW, the node build is no more but I added package restore to the azure build so that part is covered. Thx for working on this and sorry for the slow response.

Oh and one last message (like Frog and Toad said):

Azure build file is here: https://github.com/mikeobrien/HidLibrary/blob/master/azure-pipelines.yml
Azure build pipeline is here: https://dev.azure.com/hcoverlambda/HIDLibrary/_build

@mikeobrien removed changes to node build, so I think this PR is good to go.

@w-michal ok cool, just merged, thx!


YI Dome Guard IFUS - camera is restarting when connected to RTSP stream

Hi,
I have installed r30gb 0.2.5 hack on yi dome guard camera with firmware starting from IFUS. Camera is restarting when I'm trying to connect to RTSP. I've captured debug from rRTSPServer.

see  rRTSPServer output with debug
rRTSPServer.err.txt

Hello. Try to enable Swap space! After that, use tcp transport.
If you use ffplay it's like:
ffplay -rtsp_transport tcp -i "rtsp://IP-CAM/ch0_0.h264"

I'm closing this ticked. I applied change described in #484 - swith to h264 and now camera is stable.
Thanks for assistance.


Markdown reporter error: Maximum call stack size exceeded

We are using Markdown reporter for our Mocha tests and started having troubles with version 2.3.0 and above. There seems to be an infinite recursion in Markdown reporter:
$ NODE_ENV=test ./node_modules/.bin/mocha --reporter markdown >> docs/README.md

/home/balder/git/payments/node_modules/mocha/lib/reporters/markdown.js:40
    obj = obj[key] = obj[key] || { suite: suite };
                        ^

RangeError: Maximum call stack size exceeded
  at mapTOC (/home/balder/git/payments/node_modules/mocha/lib/reporters/markdown.js:40:25)
  at /home/balder/git/payments/node_modules/mocha/lib/reporters/markdown.js:42:7
  at Array.forEach (native)
  at mapTOC (/home/balder/git/payments/node_modules/mocha/lib/reporters/markdown.js:41:18)
  at /home/balder/git/payments/node_modules/mocha/lib/reporters/markdown.js:42:7

Apparently, the issues started with commit 3f78f10ca40dba63be10454c8e17dc9586416e10, with the changes in the mapTOC function in lib/reporters/markdown.js, more precisely, deletion of callback parameter in the foreach loop:
function mapTOC(suite, obj) {
    var ret = obj;
    var key = SUITE_PREFIX + suite.title;

    obj = obj[key] = obj[key] || { suite: suite };
    suite.suites.forEach(function() { // suite param missing leads to infinite recursion
      mapTOC(suite, obj);
    });

    return ret;
  }

I have tested locally and adding the param back fixes the issue.

Thanks for letting us know! I'll hopefully merge this fix in shortly https://github.com/mochajs/mocha/pull/1876/files


To ensure Python compatibility, it is recommended to avoid using the := operator in your code.

To ensure compatibility with lower versions of Python, please avoid using the ":=" operator in your project, as it is only available in Python 3.8 and higher versions. Please, consider alternative methods to achieve the desired functionality.

Sorry, I don't want to bother with <=3.7, python2, or other really old python releases by now.
I know that enterprise distros often stick with such for 5+ years, due to their API-stability requirements, but maybe they can backport stuff for their paid customers if they want to, or something.
Though in case of this module, I'd recomment simply sticking to older <23.x releases for now - older 3.x and even 2.7 pythons should be supported there, and there isn't that much difference otherwise.
Fixed missing 3.8+ version requirement in project metadata and README though.
Should prevent from installing a broken version on these older releases at least.
Thanks for reporting.


Run tests on CI.

This app uses rspec and not minitest, but we were only running the minitest action.

Oh, it does need the content schemas from publishing-api after all. My bad.

Is this bit in GitHub's UI just leftover from the previous version?

That's the bit that needed changing — https://github.com/alphagov/govuk-saas-config/pull/176

That's the bit that needed changing — alphagov/govuk-saas-config#176

Ah, gotcha. Thank you!


(L1) LPC40xx: Watchdog

Coverage increased (+0.2%) to 75.88% when pulling 75b0997f1fbf0c21d9b5b1e70d276a745b8407d9 on aidenchan12:master into 40d89452260e043e0e1092525e5f3210b7cfe1ef on kammce:master.


refactor: use ipairs for array instead of pairs

Changes

Replace all instance of pairs that was used with an array with ipairs as ipairs is much faster than pairs when used with an array
Checks
By submitting your pull request for review, you agree to the following:

[x] This contribution was created in whole or in part by me, and I have the right to submit it under the terms of this repository's open source licenses.
[x] I understand and agree that this contribution and a record of it are public, maintained indefinitely, and may be redistributed under the terms of this repository's open source licenses.
[x] To the best of my knowledge, all proposed changes are accurate.

To chime in: I don't think this is a good change. Luau's generalized iterator should be encouraged over the use of ipairs (https://luau-lang.org/syntax#generalized-iteration).

Yes, general recommendation is not using pairs or ipairs anymore.

 My take here is that even if there's a performance uplift from the ipair change, we'd rather leave things as-is and avoid the additional testing until we have time to do a proper refactor with more Luau-specific syntax.


Add changelog

Feature category

[ ] enhancement - build system
[ ] enhancement - backends
[ ] enhancement - build system
[X] enhancement - documentation
[ ] enhancement - plot categories

The problem

I was trying to port clang-unformat to support the recent version of futures, but have encounter compilation errors caused by breaking changes.
Considering that project is still 0.x.x and that breaking changes may happen between each two releases, providing some changelog would significantly enhance the library usability.
The solution I'd like
Add a file CHANGELOG.md at the project root and list each breaking change below the subtitle of the corresponding version. Whenever a breaking change is to be applied, the patch should add some lines to the CHANGELOG.md.
Alternatives I've considered
List / summarize the breaking changes in the release note along each release.
Additional context

Initial effort: https://github.com/alandefreitas/clang-unformat/issues/5#issuecomment-1322437342

Is the changelog format I've been recently using for the releases OK (https://github.com/alandefreitas/futures/releases) or do you need something easier to parse? As you said, breaking changes are to be expected here and that's why I locked clang-unformat to futures v0.1.1 (https://github.com/alandefreitas/clang-unformat/blob/54d7ab3063580dea1f20f125956e44189a9dab88/CMakeLists.txt#L25).

Thanks for reply.
Does that mean it would be unrealistic to list all the changed function signature (due to the active development of this project)?

Oh, I got it. It's just 0.1.4, four patches away from 0.1.0.
Closing.

Does that mean it would be unrealistic to list all the changed function signature (due to the active development of this project)?

To be honest, I've never seen anything like this. That's the format we've been using:

https://boostorg.github.io/outcome/changelog.html
https://www.boost.org/users/history/version_1_80_0.html

This project uses something like that, with a few emojis to make it happier.
Breaking changes and new features are also listed, but the truth is we haven't had breaking changes in a while, because we are mainly including new features. We probably had a few breaking changes before adopting this changelog format though.
I think listing all code changes would be redundant because we can always just compare commits here. I imagine the current changelog should be more than enough for your use case.
If you want, you can also update to the lastest version and show me whatever broke in your use case and I'll tell you how to fix it. I'm sure it's nothing big because we haven't broken anything serious lately.


update dependencies

Needed serde 0.7, and thought I would update a few other things as well while I'm at it.

Note that I've only build-tested this, so you probably want to try if it actually works.

Thanks, Jakob! This is great!
This is as good a time as any to announce that I have a new crate in the works, Chill, that will replace the couchdb crate. You can read about why I'm doing this here. The gist is that Chill provides a higher and more useful abstraction than couchdb.
My goal is to release Chill 0.1.0 this weekend. However, this is a “get it out there” release; it will take a few months before Chill catches up and wholly surpasses couchdb in CouchDB API coverage.

Sounds great! Since Chili is the way forward, I'll probably switch soon and contribute a few things along the way.

OK, we're in business with Chill, v0.1.0. Please feel free to help out in any way!


[CODE] Migrate get_history from utils to init

Description
Migrating the get_history function from utils to init
Fixes #19 #28
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] I have read the contribution guidelines and followed it as far as possible.
[x] I have performed a self-review of my own code (if applicable)
[x] I have commented my code, particularly in hard-to-understand areas (if applicable)
[x] I have made corresponding changes to the documentation (if applicable)
[x] My changes generate no new warnings
[x] Any dependent and pending changes have been merged and published

Also, I feel since the README & quickstart is getting updated (bcoz of me, Sorry), would it be best to push a minor release to PyPI ?

Yes, I just commented that on the slack too :smile:


fix: add QueryBuilder for Tanstack/query generators

Codecov Report

Merging #316 (790b105) into main (e9c1f87) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #316      +/-   ##
==========================================
- Coverage   87.53%   87.53%   -0.01%
==========================================
  Files          72       72
  Lines        4420     4419       -1
  Branches      554      554
==========================================
- Hits         3869     3868       -1
  Misses        550      550
  Partials        1        1

Impacted Files
Coverage Δ

packages/core/src/utils/Queue.ts
75.00% <ø> (-0.27%)
:arrow_down:

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


Operator: manifest diff isn't working with directory

The following two directory contains two different manifests, but mesh manifest diff  return Manifests are identical:
# cat nginx1/nginx-deployment1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment1
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

# cat nginx2/nginx-deployment2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment2
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

# diff nginx1/nginx-deployment1.yaml nginx2/nginx-deployment2.yaml
4c4
<   name: nginx-deployment1
---
>   name: nginx-deployment2
# mesh manifest diff -r ./nginx1 ./nginx2
Manifests are identical

Looks like the root cause is that filepath.Ext(path) will return .<ext> instead of <ext>
Will raise a PR for this.
/cc @ostromart @richardwxn

Followup: the manifest diff test between helm template and mesh manifest generate will return plenty of diffs after this is resolved, but the return code for mesh manifest diff is always 0.


Add missing project dependency to ChakraCore.vcxproj

wabt was not listed as a dependency in ChakraCore.vcxproj. In VS2017 with lightweight solution loading enabled, this was consistently reproing as a link failure. Adding an explicit project dependency to wabt appears to fix the problem.

Looks like CI is failing because wabt isn't built in Jenkins? Probably need to modify the project reference to be conditional to $(BuildWabt) being set? Testing this change locally, will update PR if it works

@dotnet-bot test Windows x64_release Windows x86_debug please

@dotnet-bot test Windows ci_slow_x64_debug please

@dotnet-bot test Windows x86_debug please


[Suggestion] Extract all static texts into a resource file

There are a lot of magic strings spread throughout the project, maybe it is a good idea to keep them in a resource file just in case some of them have to be used in multiple places.
If you agree, I can work on that. :)

@


Update vague for InverseWishart

This PR fixes #195 by redefining the vague function for the InverseWishart type.
The mean is defined only when df > dim + 1, where df is degrees of freedom, and dim is the dimensionality of the scale matrix. Hence, we do:
vague(::Type{<:InverseWishart}, dims::Integer) = InverseWishart(dims + 2, tiny .* diageye(dims))

Fixes #195


Call to undefined method zfhassaan\genlytics\facades\AnalyticsFacade::runReports()

i got this error when i try to run the report i already publish evrythings
Call to undefined method zfhassaan\genlytics\facades\AnalyticsFacade::runReports()
this is my code
$analytics = new Genlytics();
$period = ['start_date' => '2017-01-01','end_date' => 'today'];
$dimensions = ['name' => 'yearMonth'];
$metrics = ['name' => 'pageviews'];
$result = $analytics->runReports($period, $dimensions, $metrics);

@khawala sorry for the late fix, the query on GA4 is changed from pageViews to "screenPageViews" You can test the new package with the following code:
            $analytics = new Genlytics();
            $period = ['start_date' => '2017-01-01','end_date' => 'today'];
            $dimensions = ['name' => 'yearMonth'];
            $metrics = ['name' => 'screenPageViews'];
            $result = $analytics->runReports($period, $dimensions, $metrics);

I fixed some other minor issues for the package. Will update the docs too. Thanks.

Query Explorer : https://ga-dev-tools.google/ga4/query-explorer/
If it's showing data on this explorer it'll work on this package.


Images inside the README.md don't get resized

See https://crates.io/crates/ash

I realized that there is a separate repo for crates.io.


Travis SGE configuration update

This borrows heavily from various changes made to get SGE working in a docker container (also running Ubuntu). Additionally, as sudo is not needed in docker, this script has been modified to include sudo calls as needed. This should make proposals like this one ( https://github.com/nanshe-org/nanshe/pull/367 ) work nicely. It will also terminate builds early if SGE is not working.

Looks good. The planned CI changes work with this as well. Merging...


Change source of logchannel dependency

Change github.com/sabban/bastion/pkg/logchannel to github.com/moul/bastion/pkg/logchannel as the first one is not available anymore.
The project is on maintenance mode and only security issues and major bugs will be fixed. Any pull requests introducing a new feature will be closed.

I internalized the dependency to avoid similar future issues.
Fixed in 19c4fb06eb22cbc28174df106e3a91c69e283292


Improving basenc / base32 / base64

I've identified a few issues with the encoding/decoding tools that I'm interested in solving:

They are not iterative / streaming.  The entirety of the input is read first before it is all decoded.    But it means that these tools can't be used for iterative computations (e.g. over while loops) and they may consume large amounts of memory.  The GNU implementations of these tools are streaming as well, so I'd classify this as an incompatibility bug.

Significant optimization potential is available.  I have a fair bit of experience with SIMD and I've designed AVX2 and AVX512 algorithms for Base32 / Base64 encoding - it's difficult but I would like to see if there are performance benefits to it, particularly for large inputs.  Optimizations can be added iteratively, and can be feature-gated or even based on runtime CPU feature detection.

Compiled binaries for base32 / base64, on my machine, currently take up 23 MiB in debug mode and 3 MiB in release mode.  This is surprisingly large and I believe the majority of that work lies in the argument parsing rather than the actual encoding.  Since basenc / base32 / base64 have essentially the same arguments to deal with, they can be combined.

To this end, here's my proposal:

Rewrite src/uucore/src/lib/features/encoding.rs to expose a streaming rather than one-shot interface.  Along the way, I can add a sub-module for each encoding format so that per-format optimization routines can be defined.  Runtime CPU detection, if implemented, would be format-generic.

Setup basenc as a multicall binary so that base32 / base64 are symlinks to it.  The argument parsing for basenc will have to be updated to only expose format-selecting arguments if argv[0] is basenc.

Implement format-specific optimization routines over time, supported by benchmarking.  For example, if the user only provides less than 1 KiB of data, a less optimized routine can be used (advanced AVX512 instructions have some interesting effects on CPU clock frequencies, so we should avoid them unless a large amount of input needs to be processed).

It may be preferable that I write a new, independent crate for optimized data encoding and create a dependency on that (rather than the current data-encoding crate); the alternative is to eliminate the external dependency completely.
I'd like to ask for prior approval from the uutils community before I start working on this.  Note that task 1 and 2 are effectively independent - while I'm more interested in the first, the second seems more important.  Maintainers, what do you think?

If the encoding is in a separate crate then I thjnk they should already share a a lot of code and then then the multicall might not be necessary. The only difference would be the construction of the clap command. I think I'd rather keep them as separate crates but with a shared crate underneath.
If we set up that structure first, then we can make that shared crate streaming, because that is indeed a bug. Performance optimizations are welcome, but in my opinion low priority and should not increase the complexity too much. The unoptimized baseline implementation is the most important. So, I'd propose to make it streaming without SIMD etc. first.

If the encoding is in a separate crate then I thjnk they should already share a a lot of code and then then the multicall might not be necessary.

They already share a lot in terms of code, I agree - but due to static linking, the same code is duplicated in every executable.  A multicall binary would eliminate that overhead.

Performance optimizations are welcome, but in my opinion low priority and should not increase the complexity too much.

My first priority is the streaming interface, I agree.  But I'd like to provide some more complex implementations over time - while providing simple fallbacks, of course.  If you don't want that complexity in this repository, the shared crate solution seems best.

Yes a multicall binary would help, but that's what we have the general multicall binary for already. I think multiple levels of multicall binaries is a bit too much. We have this for the checksum utils and I've been wanting go remove that for a while 😄

Alright, then I'll focus on the streaming interface for now.  Hopefully better argument parsing systems can bring the per-binary overhead down.

Status update: I've got basic implementations of all the formats together in my crate glassy (documentation).  I've got a pretty thorough automated testing setup, but I need to test some failure cases better.  Once that's done, I'll polish up the documentation a bit and begin working on a PR integrating it here.

@bal-e i am sorry but I am usually quite reluctant to add a new dependency on brand new crate :(
I would prefer you integrate this code directly into the coreutils

@sylvestre There are a few reasons why I think this should be a separate dependency:

The code being developed forms a good utility library for any Rust project that needs to perform Base32 encoding/decoding.  I already have a fairly stable API for glassy, and it will not have any dependencies of its own, so I don't believe that using glassy will incur any significant maintenance burden on uutils.

Over time, I will be developing glassy further to make it much more performant (this is possible because it only offers the exact formats needed for basenc - it is not overly flexible).  uutils should be able to benefit from these performance improvements without having to maintain the code itself.

With this change, I will be consolidating two existing dependencies of uutils (data-encoding and z85), so this will actually reduce uutils' total number of dependencies.

Should uutils opt to implement new conversion formats, they can be easily integrated into glassy.  glassy operates through Encode / Decode traits, which anybody can implement, and it exposes all of the utilities its own implementations urkise for convenience, so new formats can be implemented easily both inside and outside glassy (w.  I am happy to introduce support for new formats into glassy or to make the existing formats more flexible.

As it stands, I don't believe that glassy's position as a "brand new crate" should affect how reliable it is.  As a standalone Base32/etc. converter, the standards it implements are concrete and unchanging.  Even if I were to stop maintaining it, the actual code within will continue working for the foreseeable future.  At that stage, it may make sense to fork it and maintain a copy within uutils, but I do plan on maintaining it thoroughly.

Yeah, we could move it under the uutils umbrella. Otherwise, I am quite reluctant to add a dependency like this despite all its qualities.
I am here to maintain rust-coreutils for the years to come and I am careful when adding new dependencies.

I understand that moving glassy under the uutils organization will make it easier for you to maintain it in the future.  But I would appreciate it if you could use the crate as published from my repository.  If I ever stop maintaining it, feel free to fork it here.
P.S. The z85 crate that uutils currently depends on was last updated on April 12, 2022.  Using the crate I have published may not be perfect from a maintenance perspective, but it should certainly be a better choice than relying on 2-year old code.

No SIMD, but performance is roughly equal to or superior to GNU Core Utilities with these changes:
https://github.com/uutils/coreutils/pull/6719
The main point of weakness is line wrapped encoding (still slower than GNU Core Utilities).


[py][model parser] 2/n callbacks hf

[py][model parser] 2/n callbacks hf
deserialize does not take in inference options

Stack created with Sapling. Best reviewed with ReviewStack.

-> #588
#587

Testplan


Handle "reorg away from base"

This isn't allowed by F3 but is possible in a test setup where EC doesn't care about F3. We need to get rid of the panic here:
https://github.com/filecoin-project/go-f3/blob/5aa1e0123235af94318439c2675048b060a26d59/host.go#L370
I'm not entirely sure what we should do. IIRC, the plan is to run F3 with a several epoch lag to make this unlikely but, if this happens, simply reorging away from the base will cause... problems.

I think the best solution then is to vote base, which will trigger backoff. If EC re-orgs back onto base, we will continue; if not, we will trigger re-bootstrap.


allow setting of range for text scaling

In our app we use maxScaleFactor to limit the size of the text scaling a user can apply (namely to ensure useful elements are always visible on-screen). We do this through making our app's layout the child Widget of a MediaQuery Widget like so:
return MaterialApp (

...

  builder: (context, _) {
    // Set the text scale limit
    final MediaQueryData mediaQueryData = MediaQuery.of(context);
    final TextScaler textScaler =
        mediaQueryData.textScaler.clamp(minScaleFactor: 0, maxScaleFactor: 1.4);
    child = MediaQuery(
      data: mediaQueryData.copyWith(textScaler: textScaler),
      child: child,
    );

    ...

    return SomeWidget(child: child);
  }
)

However, accessibility_tools still allows you to override this limit through its tools menu. It would be nice if we could set this limit in the tools menu too so that we don't get unnecessary complaints from our designers and internal testers of layout issues when trying factors beyond what a release build can achieve.
Not a major issue for me, just a nice-to-have :) Thanks!

Hi Thomas,
Thanks for using accessibility tools and thank you for this good suggestion. Another option to fix this could be to detect max scale factor from MediaQuery and set it as max value in the tools menu but I think having an option to go beyond the limit is nice to have for development purposes (it helps breaking layouts and finding overflows). Your suggestion sounds good, let's add it 👍

Custom text scale values are now supported in v2.3.0:
AccessibilityTools(
  // Customize testing tools configuration
  testingToolsConfiguration: TestingToolsConfiguration(
    enabled: true,
    minTextScale: 1.0,
    maxTextScale: 2,
  ),
  child: child,


fix(native-filters): show overridden chart name on scoping tree

SUMMARY
Currently the scoping tree is showing the original chart name, even if a chart name has been overridden on the dashboard level.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
On the Covid example dashboard, many chart names have been overridden. For instance, we expect to see the following chart names on the scoping tree:

However, the scoping tree is showing the original names:

AFTER
Now the overridden chart names are displayed where available:

ADDITIONAL INFORMATION

[x] Has associated issue: closes #14859
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@villebro thanks for the quick fix. this issue is related, https://github.com/apache/superset/issues/14999 we probably wanna fix it from the root?


[Node.js] intent has score 0 but it shouldn't

I created a LUIS application with some intents and all was working fine.
Then I added a new intent and when I send a message that should match that intent I always end up in onDefault . All I get is { score: 0, intent: null }.
But in the LUIS dashboard I can see that those utterances are correctly classified, sometimes even with a 1.

Did you update (publish) your LUIS to take in effect your changes?

I agree @DOMZE that seems like the likely cause.

Ops, I didn't know I had to do it 😅 thanks!


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Codecov Report

Merging #745 (048ce70) into main (88cc92c) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #745   +/-   ##
=======================================
  Coverage   95.69%   95.69%
=======================================
  Files           1        1
  Lines         395      395
  Branches       53       53
=======================================
  Hits          378      378
  Misses         17       17


Remove all noImplicitAny warnings

The goal of this PR is to more strongly type all variables and arguments by setting the noImplicitAny Typescript configuration.

Changes are too big to review in detail, but I skimmed through and overall looks reasonable to me!


feature/add jit_origin to jit client data

Currently there is no way to tell the origin of a check with :source defined. Adding a jit_origin parameter to check event data would add context to the check event data.

:+1: Yes to this.

Looks like this one fell of the radar, but it should be really easy to implement in 0.24.

@calebhailey good stuff!

I propose we call the attribute origin.

#1267 was merged, adding this feature :+1:


[CHORE]  Add issue template

Having an Issue template will be really helpful.
We easily track the issues like:

Docs
Feature
Bug

I would like to add issue templates to this project. Thanks in advance!

Perfect @RakeshSangem

@RakeshSangem
Are you done with the issue?

Collaborator

Sorry, I was busy. Today I'll finish the task:)


navigator is not defined (SSR)

Describe the bug
I am getting an error in the library which says: navigator is not defined.
To Reproduce
Steps to reproduce the behavior:

Just render an app on the server, use react-query and this gives me an error

Expected behavior
I would expect that react-query works like expected when you follow the docs.
Screenshots
(node:46055) UnhandledPromiseRejectionWarning: ReferenceError: navigator is not defined
at OnlineManager.isOnline (/Users/kevin/Enorm/trekhaak-labels-app/node_modules/react-query/lib/core/onlineManager.js:64:5)
at /Users/kevin/Enorm/trekhaak-labels-app/node_modules/react-query/lib/core/retryer.js:142:86
(node:46055) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 5)
(node:46055) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Desktop (please complete the following information):

OS: [e.g. iOS] macOS Big Sur
Browser: [e.g. chrome, safari] Chrome 87.0.4280.88 (Officiële build) (x86_64)
Version: [e.g. 22] Version 3.4.0 (latest version)

Additional context
It seems to happen in the newest version.
Also I notified that in combination with loadable-components library on npm, react query is malfunctioning.

@tannerlinsley It seems to happen if you use the following options in the queryClient on the server:

retry
refetchOnWindowFocus

Which makes sense to me cause those options are browser options. However it's undocumented.


2.3 Random Forest Listing 2.4

Cell 2, Line 16, when calculate the accuracy of test set, I think should use rf_ens[j] to calculate instead of bag_ens[j] and there is not need to keep bag , X_bag, y_bag. scikit-learn doesn't provide estimators_samples_ for random forest

Thanks for the catch. I'll push this in along with some other changes soon.

Code has been pushed. Closing issue.


Contact form

Also Document forms settings

Here is some background information on how to get the form to work.
https://github.com/StefMa/hugo-fresh/issues/66

@jacebrowning do you have a preference on how to set up contact form?

If the contact form is simply going to send us an email, we could use a mailto link.
Otherwise, a Google Form embedded on the site hooked up to some Slack automation could work well.

Thanks for the ideas and links. I ended up using formspree.io to stay consistent with the current design of the site.


The obsolete method Phaser.Scenes.Systems#install() still exists in the code, and causes an error when used

Version

Phaser Version: 3.52.0

Description
The method:
https://github.com/photonstorm/phaser/blob/a3bcf4beb136b28bf1e19c1e05fbfb7d146cfc51/src/scene/Systems.js#L353-L361
attempts to call PluginManager.installLocal(), which no longer exists, causing the following error:

Uncaught TypeError: this.plugins.installLocal is not a function

Example Test Code
class BrokenScene extends Phaser.Scene {

  constructor ()
  {
      super( {plugins: []} );
  }

  init()
  {
      this.sys.install('TweenManager')
  }

}

Additional Information
This method appears in the Dev Log #119, written in the time of Phaser v3.3, and is described as one of the many ways to install a Default Plugin in a specific Scene.
In any case, in the docs it is well explained how, nowadays, you can select your favorite DefaultPlugins.

Thank you for submitting this issue. We have fixed this and the fix has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that.


[DRAFT] Updates for new admin Powershell experience

Draft changes requested by Thomas R

 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.:x: hectoralinares sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@hectoralinares : Thanks for your contribution! The author, @mattbriggs, has been notified to review your proposed change.

@hectoralinares
Please provide feedback on this document.
https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-backup-enable-backup-powershell
I added your changes there. Thanks! Matt
#please-close


Failed to load GoogleCloudExtension.Utils.dll inside xaml

xaml references to GoogleCloudExtension.Utils as following.
Only when the user control is opened inside VS extension it throws exception of failed to load the dll.
The hack way to fix is to call a method of the dll before loading the xaml file.
It has something to do with VSIX installation.
Possibly it is required to put the dependencies into source.extension.vsixmanifest

<UserControl x:Class="GoogleCloudExtension.StackdriverLogsViewer.LogsViewerToolWindowControl"
xmlns:utils="clr-namespace:GoogleCloudExtension.Utils;assembly=GoogleCloudExtension.Utils"
        <utils:VisibilityConverter x:Key="visibilityConverter" />

public LogsViewerToolWindow() : base(null)
{
// disposable does nothing.
// This is a hack to force load GoogleCloudExtension.Utils
using (var disposable = new Disposable())
{
Caption = Resources.LogViewerToolWindowCaption;
}

This is working for literally everywhere else where I am using these classes. If this is giving you trouble then the best thing we can do is to move these classes back into the main assembly.

I guess it's because everywhere else, you have c# code that already
referenced the dll that it indirectly loaded the module into app domain,
especially if it has the Cloud Explorer opened as kind first step.  If the
module is not loaded, and an xaml file references it, and it is inside
Visual Studio Extension, it fails.
Logs Viewer can be opened from menu before Cloud Explorer is opened.  As I
mentioned, if Cloud Explorer is opened already, there is no problem.
The fix, I kind feel it could be to add the dll to dependencies in the
vsixmanifest file.  I tired to ad an item, but the format was wrong.   I'll
see if I can get the format correct and have a try later.
On Fri, Jan 20, 2017 at 3:37 AM, Ivan Naranjo<EMAIL_ADDRESS>wrote:

This is working for literally everywhere else where I am using these
classes. If this is giving you trouble then the best thing we can do is to
move these classes back into the main assembly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-visualstudio/issues/367#issuecomment-274052497,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVxZpMTkjHI38oLZxWMb1dInBQdjDdmbks5rUJx7gaJpZM4Lnyld
.

Adding it to dependency make the installation fail.

Please note,  this won't happen if it is non-VS extension xaml.


Pin prometheus-app=1.1 in cb-worker.opam and cluster/Dockerfile

Ha @ElectreAAs had something similar when fighting the CI, but it must have been lost at some point. Thanks!


how-to: use custom certs on s3 compatible remote storage

We can partly solve the issue https://github.com/iterative/dvc/issues/3450 by having it documented
(i.e. about AWS_CA_BUNDLE).

One idea that I have in mind is to have certs=<path/to/cert> in our remote configs so that could be used by default instead of these env variables: REQUESTS_CA_BUNDLE, AWS_CA_BUNDLE (we could support  s3 and http for now).

@skshetry if this is still relevant please if possible contribute the change or a draft at least and we'll take it from there. I.e. we do not oppose this but also don't currently have capacity. Cc @dberenbaum


can not set pollingInterval for walletconnect provider.

in @walletconnect/web3-provider, there is a way to set the pollingInterval, here is the code:
  constructor(opts: IWalletConnectProviderOptions) {
    super({ pollingInterval: opts.pollingInterval || 8000 });
    ...

however, the following configuration of WC provider not works in web3modal:
const providerOptions = {
  walletconnect: {
    package: WalletConnectProvider,
    options: {
      infuraId: ...,
      pollingInterval: 16000,
    },
  },
};

in this code, pollingInterval in options is ignored.

#294 is a good solution. it extends the original WalletConnectProvider

With stable version 2.0.0 of Web3Modal now released, we are officially dropping support for version 1.x
Due to this this issue/pr was marked for closing. It is highly recommended to upgrade as 2.x will be receiving further updates that will enable functionality for some of our newer sdks like auth and push as well as support for WalletConnect v2 (See this post about WalletConnect v1 being deprecated https://medium.com/walletconnect/walletconnect-v1-0-sunset-notice-and-migration-schedule-8af9d3720d2e)
If you need to continue using Web3Modal 1.x and require this feature/fix implemented, we suggest adding it via forking V1 branch.


ReplicationController item is being unmarshaled into a ReplicaSet

https://github.com/openshift/openshift-velero-plugin/blob/95ab2b038f0170ab6b0fa70bcb2d28268b312739/velero-plugins/replicationcontroller/backup.go#L33
Should it be unmarshaled into a ReplicationController instead?

Thanks for the catch @gqi128
you are right, it should be<EMAIL_ADDRESS>we will work on the fix!

/lifecycle frozen


s.system.server_stats typo in data property

Server is sending in_progresss_lobby_count with an extra s

It is live now, please let me know if the issue persists.

confirmed fixed


[think-cell-range] Update to version 498839d

Thanks for the update! Consider switching the portfile to use vcpkg_from_github() which will enable install --head :).


Add vote.fuse.io

Hi! What is your PR about?

[ ] Add or edit a skin
[x] Add custom domain for your space
[ ] Add alias for migrate your space
~Add images for your space~ (deprecated) Add the image URL on the space settings directly
~Edit your space with GitHub?~ (deprecated) Please migrate your space to ENS https://docs.snapshot.page/spaces/migrate
~Create your space with GitHub~ (deprecated) Create your space with ENS instead https://docs.snapshot.page/spaces/create

for custom domain of fusedao.eth

I can't find your new space. Please make sure that you have filled in all required fields and added a strategy. https://snapshot.org/#/fusedao.eth

I had difficulties to configure it because I was using Gnosis Safe for the ENS but I had to setup a snapshot text record with my MetaMask EOA address instead of the Gnosis Safe because a signature was needed and I was expecting a transaction instead.
Thank you for your patience and your follow up.


move ViolationHandler to common

This is a refactoring step before introducing Reviewdog Diagnostic Format in Verible:
https://github.com/chipsalliance/verible/pull/1018
ViolationHandler is the interface which is supposed to be implemented by ViolationPrinter, RDFormat printer, and other potential handlers.
This isn't specific to Verilog and thus we place it in common.

Codecov Report

Merging #1080 (13adf51) into master (20d7a3f) will decrease coverage by 0.00%.
The diff coverage is 93.46%.

@@            Coverage Diff             @@
##           master    #1080      +/-   ##
==========================================
- Coverage   92.91%   92.91%   -0.01%
==========================================
  Files         332      333       +1
  Lines       22032    22028       -4
==========================================
- Hits        20472    20468       -4
  Misses       1560     1560

Impacted Files
Coverage Δ

common/analysis/lint_rule_status.cc
96.61% <ø> (-0.22%)
:arrow_down:

verilog/analysis/verilog_linter.cc
92.47% <ø> (-0.28%)
:arrow_down:

verilog/tools/ls/verible-lsp-adapter.cc
100.00% <ø> (ø)

verilog/tools/lint/verilog_lint.cc
95.23% <85.71%> (ø)

common/analysis/violation_handler.cc
93.12% <93.12%> (ø)

common/analysis/lint_rule_status.h
100.00% <100.00%> (ø)

common/analysis/violation_handler.h
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

If you add the dependency, this can be merged.

Now verilog_linter_test has "//common/analysis:violation_handler" as a dependency. Thank you.

LGTM!


Package doesn't work

Hi again @smockle. :)
The package has stopped working, probably after some Atom update (I have not changed anything in my settings). My Atom version is 1.14.2.

Thanks for reporting this @pmichna! I just published a fix in close-other-tabs v0.1.2. You might need to restart Atom after updating the package.


BertTokenizer provides wrong encode function for Japanese BERT

🐛 Bug

Model I am using (Bert, XLNet....): BertTokenizer
Language I am using the model on (English, Chinese....): Japanese
I tried to load the tokenizer for Bert from pretrained Bert for Japanese. The tokenizer recognize "が" the same as "か"　although both appears in vocab file. Here is example code:
from pytorch_transformers import BertTokenizer
tokenizer = BertTokenizer.from_pretrained('vocab.txt')
token_ids = tokenizer.encode('が')
print('token_ids: ', token_ids)
print(tokenizer.decode(token_ids))

token_ids = tokenizer.encode('か')
print('token_ids: ', token_ids)
print(tokenizer.decode(token_ids))

the result:
token_ids:  [90]
か
token_ids: [90]
か

The vocab.txt file can be downloaded from here:
I also found that BertTokenizer also mis-recognized: 'て' and 'で', 'ば' and 'は'

I had discovered that this phenomenon is due to function: _run_strip_accents(token) in class: BasicTokenizer. Perhaps, the authors should give an option to choose whether to remove accents or not because in some language such as Japanese, removing accents makes a new word

Hi, I have trained this Japanese BERT model, and made it public.
Please set do_lower_case option to false so that the function _run_strip_accents is disabled.


Added support for local AI models

Closes issue number #7

Hey @westoque,
I’ve added some tests for the local client and reverted the changes based on your comments.
Thanks!

hi @scjsalva . do you mind rebasing main and pulling latest changes there?
there's a huge API change that will make it easier to extract the chat content, documentation here:
https://github.com/narralabs/i18n-ai/pull/12
thank you.


Improve repo overview when showing details

The screen got even more crowded with labels. Now showing details will hide the URL and branch columns.
Before:

After:

The choice of columns for details off will always be very subjective. Personally I never need the repo key unless I am in the db utility or use the api? And all the timestamps and admin data is less important to me than to see if I still have a feature branch / PR checked out. I don't mind, just find the different choices worth pointing out.

Or wait: these columns show up in the normal non detailed Layout but are hidden when the detail layout is active? I intuitively thought clicking details shows all columns.

I'd say it's better to invest in fully customizable table layout. To hide/show fields one needs, maybe change order. Everything else would be a compromise. I'm not against, just that maybe there is a better way

To clarify, the non-detail view remains the same. The detailed view shows the additional fields as usual but hides url and branch. It's a quick fix to reduce wrapped content or horizontal scrolling. A solution for user-defined table views is the ultimate solution (aka ALV).
To be honest, we are getting closer to coding a full UI framework. I'm not a fan of such activity. There are plenty of those around. For me it's part of a discussion about long term goals and architecture (web version? external api? etc).

Closing in favor of some future redesign