00 - gulp-serve-dist-error

alright thanks for letting me know. seems like the path to the redis.json changed after the dist build (most probably because of concat files, etc. - and this changed the relative path to the redis.json) i'll try some other way :)

Thank you.

Hi there's a complication here. Since I'm following your path for redis.json, it causes the file not to be found when serve using dist.
The reason because when building for dist, config folder is not copied. Since I don't think you want to update gulp file, so please advice how to proceed.
gulp serve:
------- client
   ---- server
   ---- config (where redis.json located)

gulp serve:dist:
-------- client
    ---- server
(config folder is not copied)

How angularfullstack handle similar situations with different configuration file paths they need in production / dev. You said something about environment.js - is that related?

This was a question.
How angularfullstack handle similar situations with different configuration file paths they need in production / dev?

its not related, thats about environment variables. the problem here is about the file itself. it doesn't exist in dist folder.
Since it's a new path/folder, gulp file needs to be updated so it'll copy it as well

Which existing gulp task you suggest to update in order to support the new path?

from what I see here:
gulp.task('serve:dist', cb => {
    runSequence(
        'build',
        'env:all',
        'env:prod',
        ['start:server:prod', 'start:client'],
        cb);
});

Most probably the build task. I think this is where its doing the optimisation and copied the output to dist folder.

any update on this one on how should I proceed? I would prefer not to touch the gulp configuration not to mess up with already working build config.

hi, i did this according to your spec previously to use config/databases/redis.json.
are you saying we should ignore this spec and use the environment config now instead?

No. The spec remains the same redis.json will keep the redis configuration.
But the path to redis.json should not be hard-coded but instead should be configured development.js and production.js
See how the same is already done with the path to the sqllite3 database file. The path there it's not hard-coded.
Do the same here.

Hi, I don't think you understand how it works here.
The problem here is not the path, the problem here is the redis.json cannot be found since its not copied cover.
Even if I move the path to the development.js and production.js, the problem still remain since it cannot find the redis.json once build

check inside dist folder, you'll see development.js and production.js are copied over, since they're in server folder.
But custom config folder for redis.json is not there. So no point of moving the config to the development.js and production.js

The ONLY solution here without changing the gulp file is to move redis connection configuration into development.js and production.js and not redis.json inside config/databases.

In package-app project gulp file will get some additional custom tasks to package the app in a specific format - https://github.com/distributev/package-app (as part of package-app project all the required custom folders/files - including /config/ will be copied / packaged)
In our current kue-jobs project we only need to remove existing hard-codings - removing hard-codings will not only fix the current gulp serve:dist issue but will make smoother the way of any kind of custom packaging / deploying (for instance the package-app will be smoother without hard-codings / deploying to heroku will be smoother, aws deployment, etc, etc.)
Hard-codings are not good.

Let me try to explain with more details my approach. Please tell me if this is possible.
Currently, for sqllite3 in development.js you find
// Bookshelf connection options
bookshelf: {
filename: './dev.sqlite'
}
and in production.js
bookshelf: {
filename: './dist.sqlite'
}
and then in sqldb index.js the database file path it's not hard-coded but it's referenced as
connection: {
filename: config.bookshelf.filename
}
the database path in gulp serve will come as dev.sqlite and in gulp serve:dist will come dist.sqlite
Similarly with the redis.json in development.js you could do something like
redis: {
database: '../../../config/databases/redis.json'
}
and in production.js
redis: {
database: '../../../../config/databases/redis.json'
}
and then in your code you will reference this like
config.redis.database
which will come correctly in both gulp serve (development.js - '../../../config/databases/redis.json') and gulp serve:dist (production.js - '../../../../config/databases/redis.json')
Is this possible?

Hi, still I don't think you understand what's really going on here.
Let me repeat: the problem here is NOT the path, it's the redis.json is not there.
Let me try explain:
It doesn't matter either you directly refer to redis.json directly in your code or your environment file, cause eventually, there're referring to the same file
So you can either do this in your code:
../../../config/databases/redis.json ---> directly referring to redis.json
or:
config = require('../../config/environment').redis --> you see here we're using relative path to refer to environment config file (similar thing)
which contains the path:
{
  redis: "../../../config/databases/redis.json"
}

--> which basically referring to the same file as above
The purpose of environment config file here is NOT to solve path issue - BUT it is to provide ability to have different configurations for different environment, hence it's called environment config file
So, even after you move the path inside the environment file, the error will still persist, because again, the redis.json is not there
Here is the current dist structure after you build:
------ client
  |---- server
           |--- config
                  |----- environment ---> here it's trying to find redis.json, but it's not there??!

It'll ONLY work if the redis.json is copied over when build. which supposed to look like this:
------ client
  |---- server
           |--- config
                  |----- environment
  |---- config (missing folder)
          |---databases
                |---- redis.json

As you can see, config folder above is the missing folder in dist!
Phew, thats a very long explanation. I really hope you get what I meant.

And please stop saying I hard coded redis.json path, cause this is really not the problem here.
If you say I hard coded it, it's like you're saying by putting the path in config files are also hard coded.

I think I understand this. Unless I don't.
Please mind that in my above answer development.js - '../../../config/databases/redis.json' and production.js - '../../../../config/databases/redis.json' (one extra command ..) shows different paths corresponding to how the file is located in development and how the same file is located in production.
P.S - I understand why you insist with copying the config file. Because you think it's better development and dist (aka. production) to have identical folders/files structures. In our case the current /dist it's not really how the app is deployed in production. So I prefer sticking to the minimum required changes to get /dist working. If you check the https://github.com/distributev/package-app project (the real production deployment) the folder structure is again different from both dev and dist so that package-app project will (very soon) come all the extra custom gulp task required to achieve the custom production deployment.
In our kue-jobs case I think it's only a matter of pointing development.js to '../../../config/databases/redis.json' and production.js to '../../../../config/databases/redis.json' (one extra ..) to find the same existing  config/redis.json file.

Merging the package-app branch solved this.


"Reset UI layout" menu entry also resets code and compiler options!

It doesn't reset your saved editor settings, so "Reset (everything)" wouldn't be appropriate.
(I just clicked it because I wondered what it did while I was looking for the "library dropdown" that https://github.com/mattgodbolt/compiler-explorer/wiki/Installed-libraries mentions, but I don't see it anywhere.)

Sorry to hear that, but you're right, that should be renamed! Thanks for the heads up
Hint: The dropdown is only available at the beta site (https://godbolt.org/beta/).
😄

Sorry to hear that

I didn't lose anything myself, I was in a tab that I'd already posted a permalink to; I just saw the potential for danger.

You're right. I should have stated it more clearly. I've edited the wiki to reflect that the dropdown is a beta thing for now.
Thanks for your help!


mime/multipart/partReader ignores first EOF it reads and fails if next Read call returns another error

What version of Go are you using (go version)?
go1.6

What operating system and processor architecture are you using (go env)?
linux/amd64

What did you do?
https://play.golang.org/p/ePzW9GtCEe

What did you expect to see?
the multipart reader should correctly read the multipart content

What did you see instead?
ReadForm() fails with "multipart: Part Read: unexpected EOF"

This worked in go1.5 and fails in go1.6 because of a change in the zlib reader (see #14675)

Re-milestoning for consideration for Go 1.6.1. This bug was always present, but was exposed by #14675. If #14675 goes into Go 1.6.1, that might be enough. Although this fix is trivial too.


SQL Server ODBC Driver is 13, not 17

The connection string in config.py has the wrong driver version number. Says 17, should be 13.
# Connection string to SSISDB
CONNECTION_STRING = {
                    "main": "DRIVER={ODBC Driver 17 for SQL Server};SERVER=localhost;DATABASE=SSISDB;UID=;PWD=",
                    }

This depends on the installed Version of the MS ODCB Driver.

https://msdn.microsoft.com/en-us/library/windows/desktop/dn170514(v=vs.85).aspx
https://docs.microsoft.com/en-us/sql/connect/odbc/download-odbc-driver-for-sql-server?view=sql-server-2017

Maybe add to Installation Information that this needs to be installed - I figured pyodbc would be complete implementation at first..


make win32 gpl-shared failure

I run ./makeimage.sh win32 gpl-shared failed. The error message is as follows:
....
=> ERROR [layer-50-vulkan 2/5] RUN --mount=src=scripts.d/50-vulkan/50-sh  6.9s
.....
2.626 -- Performing Test COMPILER_SUPPORTS_PIC
2.910 -- Performing Test COMPILER_SUPPORTS_PIC - Success
6.466 -- Found Python3: /usr/bin/python3 (found version "3.11.4") found components: Interpreter
6.466 -- Configuring incomplete, errors occurred!
6.466 See also "/opt/ffdl/scripts.d/50-vulkan/50-shaderc.sh/build/CMakeFiles/CMakeOutput.log".
6.467 CMake Error at third_party/spirv-tools/external/CMakeLists.txt:47 (message):
6.467   SPIRV-Headers was not found - please checkout a copy under external/.
6.467
6.467
......
What's the matter?

I can't reproduce this. ./makeimage.sh win32 gpl-shared complete without issues for me.
Did you do anything special/unusual that might cause that?

After I run ./makeimage.sh win64 gpl successfully, I run ./makeimage.sh win32 gpl-shared successfully.

My guess would be that you had old docker images flying around, which then interfered with the latest build scripts.


Add the dependency ceres-solver in the .rosinstall file.

This commit fixes #44.
Change-Id: Idfb989aa23df74a37ddbe800e01ea366a0215b91
Signed-off-by: Wei Ren<EMAIL_ADDRESS>

Thank you very much!

You are welcome. Thank you for approving the pull request!


test: Spring cleaning of K8sServicesTest

This is a preparatory work before restructuring the K8sServices suite.
Reviewable per commit. The last commit partly undoes the first one. This is because I wanted to make reviewing easier.
Setting backport labels to make any backports with changes in the suite easier in the future.

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please
Failed due to Jenkins issues, see https://cilium.slack.com/archives/C7PE7V806/p1623352955165200

test-me-please

test-me-please

test-me-please

test-1.21-4.9

test-runtime

test-net-next

net-next hit the flake from outside.

test-1.16-netnext

Dropping the needs 1.9 backport label, as it's complicated to backport the PR.
Let's see whether we will need many changes to v1.9 services testing code. If yes, then we can backport the PR.


<EMAIL_ADDRESS>decompress error

Scoop Configuration

//# Your configuration here

Failed to extract files from D:\Scoop\apps\postgresql13\13.8\postgresql-13.8-1-windows-x64-binaries.zip.
Log file:
D:\Scoop\apps\postgresql13\13.8\7zip.log
Please try again or create a new issue by using the following link and paste your console output:
https://github.com/ScoopInstaller/Versions/issues/new?title=postgresql13%4013.8%3A+decompress+error

ERROR: Cannot open output file : 鏂囦欢鍚嶃€佺洰褰曞悕鎴栧嵎鏍囪娉曚笉姝ｇ‘銆?: D:\Scoop\apps\postgresql13\13.8\pgsql\pgAdmin 4\web\node_modules@babel\plugin-proposal-optional-chaining\node_modules@babel\plugin-syntax-optional-chaining\node_modules@babel\helper-function-name\node_modules<EMAIL_ADDRESS>ERROR: Cannot open output file : 鏂囦欢鍚嶃€佺洰褰曞悕鎴栧嵎鏍囪娉曚笉姝ｇ‘銆?: D:\Scoop\apps\postgresql13\13.8\pgsql\pgAdmin 4\web\node_modules@babel\plugin-proposal-optional-chaining\node_modules@babel\plugin-syntax-optional-chaining\node_modules@babel\helper-function-name\node_modules<EMAIL_ADDRESS>

The same error occurred for PostgreSQL 14 too: https://github.com/ScoopInstaller/Main/issues/3816 and was resolved by using 7-Zip version 19 (with 7zip19.00-helper dependency).

The same error occurred for PostgreSQL 14 too: ScoopInstaller/Main#3816 and was resolved by using 7-Zip version 19 (with 7zip19.00-helper dependency).

Closing as this appears to be the solution.


how to disable default behaviour when clicking BackButton component?

I'm using react-onsenui with redux. One problem that I am currently facing is I need to dispatch some action when pages changing. I am using BackButton component in Toolbar, it seems like the animation is broken if I simply add a onClick props on BackButton component. So is there a way to allow me overwrite the default onClick handler on BackButton component?

@pirthink We want to change this as well. Right now it's hard to bind some action to the back button but we want to make it customizable.
This will definitely be added in the next version.

@plrthink
This has been fixed now. Adding an onClick prop will override the default behavior.
This example shows how it can be used:
https://github.com/OnsenUI/react-onsenui/blob/master/demo/examples/BackButton.js


error 353

Type: Feature Request
Hello i can not edit code with the keyboard.this shows me in red the following answer save then, error 353.Kind regards.
VS Code version: Code 1.81.1 (Universal) (6c3e3dba23e8fadc360aed75ce363ba185c49794, 2023-08-09T22:20:33.924Z)
OS version: Darwin x64 22.6.0
Modes:

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Improve page alignment

What
Improve the alignment of the breadcrumbs and page headings on pages using the design system.
Why
To improve the look of the pages and align more closely with other applications (e.g. Travel Advice Publisher).
Visuals
Before

After

Trello
This code amends the previously played stories for the publish confirmation and discard confirmation pages, but is done in preparation for the migration of the manuals show view to the design system.
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

Looks good to me. Is it ready to merge?

Yes please!


[fix][broker] Streaming dispatcher stuck after reading the first entry with SHARED subscriptions

NOTE: THIS BUG IS NOT IN ANY RELEASED VERSION OF PULSAR.
Motivation
While using a streaming dispatcher (streamingDispatch=true), the consumer (with a shared subscription) is stuck and it's not able to fully read a topic. That is because after the an entry is read, the readMoreEntries method is not triggered anymore. This is a regression introduced in https://github.com/apache/pulsar/pull/16968
Modifications

Aligned the new usage of the method sendMessagesToConsumers in the PersistentStreamingDispatcherMultipleConsumers in the same way it's used in PersistentDispatcherMultipleConsumers
Implemented the option DispatcherDispatchMessagesInSubscriptionThread also in the streaming dispatcher - this might be done in another pull but it's a very tiny change - follow up of https://github.com/apache/pulsar/pull/16603

The evidence of this bug is that the test a several tests with streaming enabled are failing but since they are in the flaky section, they have been ignored. Now these tests are passing

[x] doc-not-needed

Hi @nicoloboschi
I'm sorry for missing the PersistentStreamingDispatcherMultipleConsumers. And thanks to your point out.
It looks like it just affects 2.11 and master. Because of the previous branch, we use this PR  https://github.com/apache/pulsar/pull/17053/files to cherry-pick.
Another concern is why we don't have the test to verify it. :(


Update Footer Editor

Insert Theme Name(s) Here
Insert a link to the GitHub repository of the theme and describe the major changes your theme makes here.
Checklist
Failure to complete this checklist or deleting boxes from the checklist will result in the closing of your pull request unless this is a theme update. Please write any comments regarding this checklist at the bottom of your pull request.
Check every box.

[ ] I am the original author of this theme or have permission from the original author to make this pull request.
[ ] All copyright of this theme's contents belong to the listed author or is cited in the repository linked above.
[ ] This theme's target has been marked appropriately and only styles said target.
[ ] This theme works properly on the latest versions of SteamOS for Steam Deck, decky-loader and SDH-CssLoader.
[ ] This theme only uses * or !important if absolutely necessary.
[ ] This theme is under 4MB in size and uses the least disk space possible.
[ ] This theme's preview image does not include text unless it is necessary to describe changes that can be made.
[ ] This theme is safe for work and does not contain any sexual, drug-related, or profane content.
[ ] This theme prefixes any CSS variables with a unique identifier.

Check one box.

[ ] I am not bundling a part of another theme with this theme to encourage mixing and matching themes.
[ ] Themes included with this theme are toggleable using a patch.

Check one box.

[ ] This is a keyboard theme applied to the default keyboard.
[ ] This is a system-wide theme applied to the default keyboard. The keyboard is toggleable using a patch.
[ ] This theme does not target the keyboard.

Changelog and link to theme repo please?

Added


delete nand backup section, feature now disabled on latest godmode9

It's done with the scripts section...


Support for ABAP Messaging Channels (AMC) and ABAP Push Channels (APC)

ABAP Messaging Channels (AMC) and ABAP Push Channels (APC) are currently not supported.

closing, PR merged


module version 0.15.1 breaks support for Ubuntu 14.04 LTS

Module version: 0.15.1
Puppet version: 3.4.3
OS and version: Ubuntu 14.04 LTS

With commit  ddb00d699567ea9971afbd25350bdb5218187b64 and the use of the "new" digest_algorithm method in puppet, one bumped the puppet requirement to >=3.8.0, as mentioned in commit  903e8129b4c6207d23f53e451242b4ac8a3534eb.
Since Ubuntu 14.04 LTS comes with puppet 3.4.3, this breaks support for Ubuntu LTS releases older than 16.04 (unless using puppet from puppetlabs directly).
metadata.json still says:

{
  "operatingsystem": "Ubuntu",
  "operatingsystemrelease": [
    "10.04",
    "12.04",
    "14.04",
    "16.04"
  ]
},

and README.md still says:

Limitations
This module has been built on and tested against Puppet 3.2 and higher.
The module has been tested on:
Debian 6/7/8
CentOS 6/7
OracleLinux 6/7
Ubuntu 12.04, 14.04
OpenSuSE 13.x
SLES 12

So at least README.md and metadata.json should be updated to reflect this change, but is commit  ddb00d699567ea9971afbd25350bdb5218187b64 worth breaking support for Ubuntu 14.04 LTS for? (have not checked if there are other changes requiring puppet >=3.8.0)

Thanks for bringing this up, I think it's important to lay out what the perspective of this module is as it pertains to Puppet versions. A few points worth mentioning:

14.04 is still supported. It's tested regularly in CI (albeit with the requirement that it does require the minimum required version in the module metadata)
As you mentioned, some versions like 14.04 will rely on the official Puppet package repositories for newer versions of Puppet. It's not ideal, but it's a pretty huge stretch to try and support both an older distribution and a very old version of Puppet.
I think it's a pretty fair expectation for the module to follow Puppet Labs' support of Puppet versions. Note that the latest in the 3.x series is slated to be dropped from maintenance and security updates - not just updates, but legacy support entirely - in 2017. Even with that announcement of deprecation from the creators of the language, I'm going to try to keep >= 3.8 functional as long as possible. To try and extend this back to 3.4 is, bluntly, a little ridiculous given that even 3.8 is about to be completely unsupported by Puppet Labs.
You noted one commit that necessitates Puppet version >= 3.8, I know of at least one other instance off-hand in 7f086aee4c9 (which uses file() in a way that I think changed in 3.7?)
You've got a totally valid point in that I probably need to remove Ubuntu 10.04 from the supported list as that isn't tested at all and don't know whether it works with the current module at all.

tl;dr 14.04 is still supported, it just needs the right version of Puppet (which is available for 14.04), and the main cutoff from the module's perspective is Puppet versions.
I do sympathize with users on older distributions as it isn't as straightforward as it could be; but it's certainly possible to do with the upstream repositories, and we've got to move the module forward as time goes on.

I'm going to close this out, but if anyone has lingering concerns, please do bring them up for discussion so we can come to a solution. 👍


COLIBRI header specification

[ ] Merge #3871 first

This change is

COLIBRI will be merged initially to SCIONLab. Following that direction, we open this PR against a branch that will be merged to SCIONLab later, on juagargi#23

COLIBRI will be merged initially to SCIONLab. Following that direction, we open this PR against a branch that will be merged to SCIONLab later, on juagargi#23


"Armed with fault" event_codes have updated?

I was curious why I was not getting an abode_panel_fault event triggered in Home Assistant when arming the system with a fault. I set the integration to show debug logs, and I think what I'm seeing is that the fault codes are no longer in the 13xx range, at least for my configuration (I have no delay timer on setting "Home" but I have a 30-second delay on setting "Away"), but rather in the 60xx range. The relevant portions of the debug log are below.
2020-06-26 10:28:11 DEBUG (SyncWorker_28) [abodepy.devices.alarm] Set Alarm Home Response: {"area":"1","mode":"home"}
2020-06-26 10:28:11 INFO (SyncWorker_28) [abodepy.devices.alarm] Set alarm area_1 mode to: home
2020-06-26 10:28:12 DEBUG (SocketIOThread) [abodepy.event_controller] Timeline event received: Gateway Armed w/ Faults(s) - Home - Armed w/ Faults(s) - Home (6077)
2020-06-26 10:28:12 DEBUG (SocketIOThread) [abodepy.event_controller] Alarm mode change event to: home

2020-06-26 10:28:48 DEBUG (SyncWorker_7) [abodepy.devices.alarm] Set Alarm Home Response: {"area":"1","mode":"away"}
2020-06-26 10:28:48 INFO (SyncWorker_7) [abodepy.devices.alarm] Set alarm area_1 mode to: away
2020-06-26 10:28:49 DEBUG (SocketIOThread) [abodepy.event_controller] Timeline event received: Gateway Arming w/ Fault(s) - Away (Exit Timer Started) - Arming w/ Fault(s) - Away (Exit Timer Started) (6055)
2020-06-26 10:29:20 DEBUG (SocketIOThread) [abodepy.event_controller] Timeline event received: Gateway Armed w/ Faults(s) - Away - Armed w/ Faults(s) - Away (6071)
2020-06-26 10:29:20 DEBUG (SocketIOThread) [abodepy.event_controller] Alarm mode change event to: away

Is anyone still seeing fault codes in the 13xx range, or is there something unique to my configuration? Abode did just recently (the last month or so?) release a new version of their app and web interface, so perhaps a minor update to the API/events was made.
Let me know if I can provide any other helpful debug information.

I added these codes into a new event group called ARM_FAULT_GROUP. @shred86 said he would add the new group to the relevant place in HASS when he bumps the version. Thanks!

Great, looking forward to it!


Feat/byo-xgboost

'bring your own model' container with Shap incorporated

@jacksandom - Just a heads up - I checked the docker_dbt failure and this looks unrelated. Appears to be a conflict from external package releases/updates.


Typed Builder implementation part 13.5: Standardized ScopedBuilder.decl tests

[x] Tests added for any new code
[x] Ran make fmt-fix (or had formatting run automatically on all files edited)
[ ] Documentation added for any new functionality
[ ] Entries added to ./unreleased/ for any new functionality

closes #1980

Codecov Report

Merging #1993 (b0022cd) into unstable (ddf5021) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           unstable    #1993      +/-   ##
============================================
- Coverage     77.81%   77.80%   -0.01%
============================================
  Files           418      418
  Lines         12789    12789
  Branches        566      566
============================================
- Hits           9952     9951       -1
- Misses         2837     2838       +1

Impacted Files
Coverage Δ

...he/io/annotations/parser/CommentPreprocessor.scala
96.70% <0.00%> (-1.10%)
:arrow_down:

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 ddf5021...b0022cd. Read the comment docs.

I looked through the code. But I am not sure what is going on here. The issue is also not explaining much. Could you maybe add a few sentence that explain the purpose of this refactoring?

https://github.com/informalsystems/apalache/issues/1969 generalized the checkRun framework, so that it can handle builder methods that produce not just TBuilderInstruction (i.e. TBuilderInternalState[TlaEx]), but any TBuilderInternalState[T] (in particular, T = TlaOperDecl).
The original tests for ScopedBuilder.decl were written before this was the case, and so were significantly different (in form) from the rest of the builder tests. This PR brings them more in line and makes the shape of the decl tests analogous to that of the other builder method tests.


Feature/assertion baked image input

verify() now accepts a baked image as input: assumes the input is a file-like object

addresses issue #48

Updated to bakery version that specifies pypng in its requirements.


Drop old deploy under alias after deploy of new version

Hi, thanks for your work, I'm in love with it!
Case: I have alias X.now.sh and I'm deploy as now --public && now alias new version (Y-1q2w3e4r5y.now.sh) of app under that alias, but when I do now ls, I see old version (Z-0z9x8c7v.now.sh) too under that alias.
X (2 of 2 total)
 url                           inst #    state                 age
 Y-1q2w3e4r5y.now.sh                1    READY                  2m
 Z-0z9x8c7v.now.sh                  1    READY                  7h

How can I auto remove old version? It's little verbose run now ls and now rm [deployId] after each deploy.
Thanks!

 The list you just showed doesn't contain aliases, but rather groups per app name (now ls). The app name is not the alias.
So if your deployments have the same deployment name (specified as the name property in package.json, for example), they will be grouped together.

Ah, I see, don’t know that.
But question is still actual: how to prune old deploy automatically after release of new version?

@evgenyrodionov That's not necessary. 😊 The Now platform is built so that you can just leave your old deployments laying around if you want to access them later.
But you can run now rm -h to learn how to remove them.

Ok, thanks


Switch to Java 15

Java 14 preview is not really supported anymore, so a switch to Java 15 preview should be done eventually.
Blocked by https://github.com/DDS-GmbH/poipath/issues/3, since we can not use java 14 preview libraries in java 15 projects

@alexpartsch has this been fixed by e7c48c1627385919526260cd27de96775ab9221d, 4735a6e212913d086ca5e8dc43f60a99d0acd4bb, and 505fb865e8e4507b5c0a6911a8c7a12e673360a2?


Make trays clientside

Also made it use fades so it looks a bit better when walking around.
https://user-images.githubusercontent.com/31366439/227480178-a2e029a7-f2d9-4858-995d-b4200a24a4f0.mp4
Might make it use animations? Not sure.
:cl:

tweak: TRays are now clientside with a higher range.


kubeturbo operator upstream

The kubeturbo deployment enables the management of an openshift or kubernetes cluster by the Turbonomic Platform. The Turbonomic Platform simultaneously optimizes performance, compliance, and cost in real-time. Workloads are precisely resourced, automatically, to perform while satisfying business constraints.

https://github.com/operator-framework/operator-courier/issues/136

@esara  any updates on your PR

@essar There is an error in the log. forbidden: User "system:serviceaccount:operators:kubeturbo-operator" cannot list resource "kubeturbos" in API group "charts.helm.k8s.io" in the namespace "operators" . Will this prevent from your operator functioning in its full capacity? Also, the operator is not writing to the status block. Updating the status will let the user know the current state.

@esara  Please see Travis error for more details. "error":"failed to retrieve release history: secrets is forbidden: User "system:serviceaccount:operators:kubeturbo-operator" cannot list resource "secrets" in API group "" in the namespace "operators""

/ok-to-test


A user can enter a space, a dot, a comma and a question mark into Recovery Phrase field

They don't affect the recovery process and don't cause an error
https://files.slack.com/files-pri/T72RGP3TM-FFG3UPL5D/image_from_ios.jpg

It was fixed.


Support for 10x Genomics data?

Hi,
I have a client interested interested in single cell ASE based on the 10x Genomics platform. The default Cell Ranger pipeline (using STAR 2.5) is not capable of resolving ambiguously mapped reads across a diploid genome and she is in need of another option.  Any suggestions?
Thanks in advance,
Chris

We have been extending the emase pipeline to 10X scRNA-Seq data but have not released it yet. We are open for collaboration though. Could you give us a bit more detailed information about your project? If privacy matters, please email me at<EMAIL_ADDRESS>Thanks!

Very cool. At present, the client has very poor-quality pilot data from 10x at this point, but I'll loop them into the conversation to see what their interest level is on collaboration. Expect an email shortly.


Fix #724, implement config-based target builds

Describe the contribution
The existing build system built target executables grouped by toolchain as a proxy for CPU architecture + machine options/flags.  The app binaries would be built once and copied to any/all targets sharing that toolchain.
The side effect of doing this is that the application needs to be written in an CPU-agnostic manner, performing its subscriptions and configurations from runtime table data rather than hardcoded/fixed values.  Unfortunately most apps are not coded that way, so workarounds were needed.
This changes the top level process to include the "platform" within this target build logic, effectively treating different platform configs as entirely different builds, even if they share the same toolchain file.
As a result, binaries will only be shared between targets that explicitly set the TGTx_PLATFORM setting in targets.cmake to the same value.
Fixes #724
Testing performed
Build CFE and unit test + sanity check (default config)
Add CPU2 configuration using default platform settings (different) and unit test + sanity check.  CPU2 is built separately from CPU1, all OSAL, PSP, CFE, and app binaries are re-built.
Add CPU2 configuration sharing the same platform config settings and unit test + sanity check.  CPU2 is built like the previous implementation where binaries are built once and copied to both installations.
Expected behavior changes
No impact to behavior, only affects build.
This does affect the build tree adding an extra subdirectory at the architecture level.  For instance rather than build/native it becomes build/native/default_cpu1.  Sample makefile is updated so make test works with the default.
System(s) tested on
Ubuntu 20.04
Additional context
As a side effect this makes all platform configs available to all apps, no real scope separation.  So inclusion of cfe_platform_cfg.h from an app will no longer trigger an error, even though I'd still recommend against actually doing that.
A future improvement might be to build OSAL + PSP separately and only do the CFE + APPS per config, using an imported target.
Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

I see the mission_inc and platform_inc override support now, are those the only two new categories of headers that can be overwritten?  I don't have any problem with that, just wanted to make sure I didn't miss anything.  Likely worth some documentation in the app developer's guide?  Seems like a significant new feature?  Ping @ejtimmon @tngo67 for awareness... no longer need to change files within app directories for platform/mission_inc customization, they can be overridden from the *_defs directory.

I definitely agree that a toolchain specific build would ideally have all configuration items in tables, but as @jphickey mentioned, that is not possible with defines that set sizes.
With this change, how would we name target specific headers for apps and the cFE core, and where are they located?
I could probably use a higher level overview of how we intend to do platform specific configuration, please include me in a tagup.

I definitely agree that a toolchain specific build would ideally have all configuration items in tables, but as @jphickey mentioned, that is not possible with defines that set sizes.
With this change, how would we name target specific headers for apps and the cFE core, and where are they located?
I could probably use a higher level overview of how we intend to do platform specific configuration, please include me in a tagup.

In my example at https://github.com/skliper/cFS/tree/test_module_override I just put mission config elements in sample_defs/mission_inc and included it at the arch level cmake.  I'd likely do something similar to what JSC does for target specific (name a directory for each target's header files and include from the target level cmake.)

Does this separate the toolchain file from the CPU/target (i.e. toolchain-cpu1.cmake vs. toolchain-i686-rtems4.11.cmake)? Although I guess toolchain-cpuX.cmake were not actually tied to the cpu1 build, but provided for a convenience, correct?
I'm not sure it is possible, but it seems logical to me if we had targets (cpu1, cpu2, backup_processor, etc) then each target required a toolchain file.
If we had such a separation, would we need to have native vs. SIMULATION= in a build? If we always have to specify a toolchain file for a configuration, I wouldn't think we would need SIMULATION= :
Example:
'build' TARGET=cpu1 TOOLCHAIN=x86_64-linux-gcc
or
'build' TARGET=cpu1 TOOLCHAIN=aarch64-linux-gcc
or
'build' TARGET=cpu2 TOOLCHAIN=rtems5-leon3
etc,
or even something like:
'build' TARGET_CFG=cpu1 TARGET_ARCH='rtems5-leon3-rcc1.3'
'build' TARGET_CFG=cpu1 TARGET_ARCH='rtems5-leon3-gcc'
and so on ( showing public RTEMS tools, verses Gaisler toolchain release, rcc)
I used TARGET_ARCH, since TOOLCHAIN includes the OSAL and PSP selection.
Would it even make more sense to break out TOOLCHAIN from OSAL/PSP, or are they always tied together?

I definitely agree that a toolchain specific build would ideally have all configuration items in tables, but as @jphickey mentioned, that is not possible with defines that set sizes.
With this change, how would we name target specific headers for apps and the cFE core, and where are they located?
I could probably use a higher level overview of how we intend to do platform specific configuration, please include me in a tagup.

In my example at https://github.com/skliper/cFS/tree/test_module_override I just put mission config elements in sample_defs/mission_inc and included it at the arch level cmake. I'd likely do something similar to what JSC does for target specific (name a directory for each target's header files and include from the target level cmake.)

Makes sense. Does JSC have duplicate filenames under each target specific directory? This was one of the complaints about the original build system: having many files with the same name scattered throughout the tree.

I definitely agree that a toolchain specific build would ideally have all configuration items in tables, but as @jphickey mentioned, that is not possible with defines that set sizes.
With this change, how would we name target specific headers for apps and the cFE core, and where are they located?
I could probably use a higher level overview of how we intend to do platform specific configuration, please include me in a tagup.

In my example at https://github.com/skliper/cFS/tree/test_module_override I just put mission config elements in sample_defs/mission_inc and included it at the arch level cmake. I'd likely do something similar to what JSC does for target specific (name a directory for each target's header files and include from the target level cmake.)

Makes sense. Does JSC have duplicate filenames under each target specific directory? This was one of the complaints about the original build system: having many files with the same name scattered throughout the tree.

For platform configuration header files, yes.  Basically a full "set" of the configuration headers (same name) for each target within target_defs.  They actually had a depot with the common headers and just linked whatever didn't need to change.  In terms of the rest of the tree, there's just the platform_inc/mission_inc version... which they may have removed from the include path.  Hopefully it's not as scattered as before.

Makes sense. Does JSC have duplicate filenames under each target specific directory? This was one of the complaints about the original build system: having many files with the same name scattered throughout the tree.

This is one of my remaining concerns about not doing the generate_config_includefile step.  One important thing that this function does is to consolidate several differently-named files (but all of which have a prefix to a common base name) into a single include file that the FSW can use.  This importantly avoids the situation where we have many copies of files with the same name and it is not clear which one is used.
For instance consider "cfe_mission_cfg.h" and "cfe_platform_cfg.h" -- in a configured build there should be just one copy of this file.  An automated tool (such as an IDE) can find this file, and parse its content, and know exactly which definitions are in use - its completely unambiguous.
In contrast, If we have multiple different versions of the same file name within the same source tree, it becomes very unclear which is being used.  One has to look at the include path supplied to the compiler to figure out which is active, and this is neither obvious nor automatic.  IDE's and other tools will be much more confused when parsing the code.
So for this reason I'm still thinking we should keep the generate_config_includefile() function as it is, because it avoids the duplicate name problem.

Clarification on above - there is actually an editor_inc directory which has a separate copy of the same file name -- this is actually a duplicate so either one will be OK to reference, but I think with this change we can get rid of that duplicate too.  It should ideally be just one file name, one content, particularly for headers.  Source files are a little different paradigm, I think - identically-named sources that are chosen by the build system don't have quite the same level of confusion as identically-named headers.

What would the approach be for users to customize core header files?  Or override default app configurations without removing search paths and requiring clone and own of every header file even if you don't want to customize it?

What would the approach be for users to customize core header files? Or override default app configurations without removing search paths and requiring clone and own of every header file even if you don't want to customize it?

I just verified/validated that adding a line such as this to arch_build_custom.cmake works just fine:
include_directories(${MISSION_DEFS}/custom_inc)

One can then add whatever header files you want to custom_inc, and as this file is processed early, the path(s) here become the first -I options to the compiler, thereby superseding any other header files within the project itself.
Obviously, this creates the exact problem/confusion above of having multiple copies of the same header file name with different content.  But if users are OK with that, there is nothing to stop them from using this approach, and it works today, and you can have multiple directories and choose from them.
As I've said before, I'd caution anyone against overriding just a single arbitrary header file.  For event ids and msgids and configuration files these are always expected to be customized so it should be easy to do, but anything beyond this is power user territory and all bets are off.  For updating an arbitrary header, It seems you'd at least have to also update a .c file to provide an implementation for whatever you changed.
The way I see it, changing a file which isn't part of the designated customization set is effectively creating a fork.  Even if you just tweak the include path to find your file before the standard file, it's still changing the app in unexpected ways and thereby becomes a fork for all intents and purposes.  It's just a fork that's less obvious that's been forked because of an include path trick, which I don't see as a good thing.
I'd rather see users accept the reality that in doing this they are in fact changing the app, and use git to track this in their own repo.  Or clone it under a different name and replace at the module level.
If one really does not want to track their own fork or clone and own, then I'd suggest keeping the changes as a patch.  Build systems like Yocto use this approach extensively.  Clone a specific commit from a git repo, then apply a local patch within the build script/makefile before actually building the code.  This would allow you to update not only header files but C files or any other file too, and is more appropriate IMO for what you are actually doing - locally patching the app/module for your own purpose.
So I think there are lots of options that "power users" can do without really needing any specific support for it in the framework.

Specifically - quilt is a very robust tool to manage customizations to a 3rd party project that you cannot fork.  It allows one to put a set of patches at the top level and selectively apply them.  You can then commit only the patches to your local repo and the 3rd party apps can still come from the official source even though you've locally modified them.
If you think that could be acceptable for the problem at hand I can provide an example for how quilt can be invoked as e.g. part of the "prep" step in the top level makefile.

I just verified/validated that adding a line such as this to arch_build_custom.cmake works just fine...

Right.  It's exactly what my sample did that I have shared previously as a power user option (and it works fine).  Sounds like we are on the same page - add to the include path or clone and own (or apply changes on top, whatever you want to call it).  As you said, really in the end users can do whatever they want, and I think that's they key point.
I definitely agree with avoiding multiple headers of the same name in the framework (except for unit testing to override).

OK then - I'm fine with the power users adding their own include_directories to override arbitrary headers so long as they understand the risks and implications of doing that.  Would propose that as the method for doing that (I don't want to say "preferred" method, but it works and it is simple enough).
Independently I was also investigating ways to push the calls to generate_config_includefile to the apps themselves rather than the mission_build.cmake file, which would remove another spot where some names had special meaning (e.g. fsw/mission_inc and fsw/platform_inc).  I'd prefer if the application build scripts handled all of this explicitly.
But - problem is the "generate" call has to be done at mission scope, not arch scope - we do have a an existing hook for this in the form of a mission_build.cmake file but it hasn't really been used to date.  This would be the place for generate_config_includefile calls though.
Does this sound worthwhile to make this change?  It would avoid a little more of the "magic" name-based logic in the mission_build.cmake file, which I know was a concern.

Update - I submitted a draft PR of what I came up with to not only push the generate_config_includefile calls into the app-specific cmake scripts, but also do some further cleanup of the logic in general.
Please see/review PR #751.  It basically combines this PR here with the one in #740 and then does some additional cleanup/simplification and adds some more status info to make it obvious what's coming from where.

This has been rebased and is now part of #751.  Closing this PR.


Disable 'Lin.Internal CList int test with Thread' under bytecode

OCaml's systhread context switching varies between the native and bytecode modes.
This is challenging to the experimental Thread modes and the package tests of it.
As a result

both Lin.Internal ref int/int64 test with Thread have been disabled in bytecode mode
the Lin.Internal CList int64 test with Thread has also been disabled in bytecode mode

This left Lin.Internal CList int test with Thread - which is marked as a positive test, but would occasionally find an unexpected counterexample in bytecode mode, causing a false alarm #358 - most recently in both bytecode trunk runs from #434.
This PR thus disables Lin.Internal CList int test with Thread in bytecode mode too.
It should eliminate another cause of false alarms.
Fixes #358

CI summary:

macOS trunk failed to install dune #433

Out of 44 workflows, 1 failed - with a genuine issue :tada:

CI summary for merge to main:

macOS trunk failed to install dune #433
MinGW bytecode timed out in threadomain #203

Out of 45 workflows, 2 failed - with genuine issues :tada:


Text with markup, menu doesn't appear

Describe the bug
Child element of "Text with markup" option does not appear to be picked from child list in the edit mode.
To Reproduce
Steps to reproduce the behavior:

Go to 'Configure/Structure'.
Create an element, set it to 'Text with markup'.
Create a child of that element.
Save settings.
Enter edit mode.
Add new entry.
Click parent element to add child - menu does not display child elements.

Expected behavior
A child element category should be visible to add child elements with a click.
Screenshots

Environment:

Windows 10 (Build 19042.985)
Vivaldi Browser 3.8.2259.42 (Stable channel) (64-bit)

Additional context

Using browser version only

This issues is now fixed. Behaviour is a bit different - enter text in "definition" element, each word is displayed with gray background, Ctrl+click the word you want to highlight and select "wrap"


Proposal: Enable global_namespace_import

With configuration ['import_classes' => false, 'import_constants' => false, 'import_functions' => false]: https://cs.symfony.com/doc/rules/import/global_namespace_import.html#example-3
Main benefit for me would be exceptions, as it is a directly clear that a docblock like
/**
 * @throws Exception
 */

refers to \OCP\DB\Exception and not \Exception.
It would also safe some lines in the imports making them a bit more readable.
We could also switch it around, but I think we should settle on some configuration for this rule to have it the same everywhere.

I agree that for global classes it's better readable/understandable if they are fully qualified inline

I am fine either way


training tip

Do you have any tip for small object trainning.
I am dealing the small binary segmentation but it doesn';t have good result.
Do you have any tip.

A generic tip is to use focal loss for training with small objects.   Not sure if it will work here but it will certainly help in general.

I have already try but not a good result....

I'm testing some other loss functions tomorrow and will let you know if any progress.  Boundary loss penalty looks really good.

Thank you for answering. I agree the boundary loss penalty is good idea. However my problem is quite imblance data. Background is 95 % the target object is only 5 percent in the image. My problem is only binary segmentation but I cannot get the 90% iou score. I usually get the 83%. I try this network but still no luck. I am trying to use the synchronize batch normalization. Wish me good luck.


Add focus-visible to checkbox

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


Reusing bookshelf models on the client side?

Hi! Bookshelf & knex look pretty awesome for server side models, but I'm not clear on whether it's intended to support reuse of code between client and server? I would like to build an app with models that use the exact same code on client and server, where I'm assuming the only difference would be that fetch/save means HTTP on client and SQL on server. Does bookshelf support this kind of thing? (It seems like it probably doesn't, because it requires an initialized knex instance in order to get a bookshelf object, before you can even declare a Model...)

@tgriesser @ricardograca Any news on this subject? Thank you.

The project leadership of Bookshelf recently changed. In an effort to advance the project we close all issues older than one year.
If you think this issue needs to be re-evaluated please post a comment on why this is still important and we will re-open it.
We also started an open discussion about the future of Bookshelf.js here https://github.com/bookshelf/bookshelf/issues/1600. Feel free to drop by and give us your opinion.
Let's make Bookshelf great again


ScheduledVolumeSnapshot says VolumeSnapshot CRDs are not installed when they are

When creating one ScheduledVolumeSnapshot I can see it is complaining about missing snapshot CDRs:
kubectl get scheduledvolumesnapshots.cosmos.strange.love
NAME                                             PHASE         AGE
evm-sidechain-testnet-scheduledvolumesnapshots   MissingCRDs   64m

The cosmos-operator-system logs say they are not installed:
2023-11-15T15:13:44Z	error	Controller is disabled	{"controller": "scheduledvolumesnapshot", "controllerGroup": "cosmos.strange.love", "controllerKind": "ScheduledVolumeSnapshot", "ScheduledVolumeSnapshot": {"name":"evm-sidechain-testnet-scheduledvolumesnapshots","namespace":"default"}, "namespace": "default", "name": "evm-sidechain-testnet-scheduledvolumesnapshots", "reconcileID": "0d2c758f-98a2-4665-9926-918a7692da79", "error": "cluster does not have VolumeSnapshot CRDs installed"}

When those CRDs are installed in our cluster:
kubectl api-resources | grep volumesnapshot
scheduledvolumesnapshots                              cosmos.strange.love/v1alpha1           true         ScheduledVolumeSnapshot
volumesnapshotclasses             vsclass,vsclasses   snapshot.storage.k8s.io/v1             false        VolumeSnapshotClass
volumesnapshotcontents            vsc,vscs            snapshot.storage.k8s.io/v1             false        VolumeSnapshotContent
volumesnapshots                   vs                  snapshot.storage.k8s.io/v1             true         VolumeSnapshot

kubectl get crd | grep -i snapshot
scheduledvolumesnapshots.cosmos.strange.love                2023-10-04T13:52:15Z
volumesnapshotclasses.snapshot.storage.k8s.io               2023-11-15T15:12:21Z
volumesnapshotcontents.snapshot.storage.k8s.io              2023-11-15T15:12:29Z
volumesnapshots.snapshot.storage.k8s.io                     2023-11-15T15:12:36Z

Could be this CRDs should be present in the cluster before creating or deploying CosmosFullNode? Or what could be causing this issue?

Can you try deleting the operator pod(s)? Deleting them will cause them to restart, and it should detect the CRDs. The CRDs are detected on operator startup.

That was exactly the issue. Restarting cosmos-operator-controller-manager pods made them to detect recently installed snapshots CRDs.
2023-11-16T10:00:20Z	info	Requeuing for next snapshot	{"controller": "scheduledvolumesnapshot", "controllerGroup": "cosmos.strange.love", "controllerKind": "ScheduledVolumeSnapshot", "ScheduledVolumeSnapshot": {"name":"evm-sidechain-testnet-scheduledvolumesnapshots","namespace":"default"}, "namespace": "default", "name": "evm-sidechain-testnet-scheduledvolumesnapshots", "reconcileID": "b9d9e937-0657-422a-942c-0e8e02e34ef8", "duration": "14m39.235053464s"}

Thanks. You can close this issue

Can you try deleting the operator pod(s)? Deleting them will cause them to restart, and it should detect the CRDs. The CRDs are detected on operator startup.

Thanks for your suggestion, I tried this and also recreated scheduledvolumesnapshot, it's working normally now


⚠ Processors has degraded performance

In e1d7c65, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 53 ms

Resolved: Processors performance has improved in e575547.


We can now run models via Kompute in podman-machine

Reflect this in README.md
Summary by Sourcery
Documentation:

Update README.md to reflect that models can now be run via Kompute in podman-machine.

LGTM


Update owners file

Although I don't have commit access, yet, I've been working on trying to get the self-hosted macOS pipeline to use the nightly toolchain.  Updating the CODEOWNERS file will hopefully allow me to trigger the macOS self-hosted nightly toolchain without depending/waiting on another developer to do it for me.

@swift-ci please test.

Unknown owner on line 29: make sure @bkhouri exists and has write access to the repository
…ripeticca @plemarquand @owenv @bkhouri

Looks like you can't be a codeowner without having write access.

@swift-ci please test linux

This will need to wait until @bkhouri has write permission.

This will need to wait until @bkhouri has write permission.

I have officially received commit access 🎉

@swift-ci please test


Improving TextField foregroundColor on Dark Mode

Describe the bug
The placeholder color in the textfield is black on dark mode which is not good on UI
To Reproduce
Opening the app in dark mode
Expected behavior
Placeholder color should be white.
Screenshots

Version

OS: macOS Ventura Beta 8
Xcodes: 1.8.0

#294 added for a solution idea


Place all info/success messages in flash

Use https://www.npmjs.com/package/express-flash
@chill117  Can you confirm that this package should be used to implement flash in the application? Thank you!

@victorbrender No, I wouldn't use that module because it hasn't been maintained for 3 years. Flash messages are actually pretty simple. I don't think it would be too difficult to implement this without a module.

"Place "all" info..." - would help if the task was more specific as to what exactly should be in a flash message

Flash messages proposal:

[ ] After login -> You have successfully logged in as 'Stan Marsh'
[ ] After logout -> You have successfully logged out
[ ] After successfully creating a project -> You have successfully created project 'Acme'
[ ] After successfully editing a project -> Project 'Acme' was successfully updated
[ ] After an error while editing a project -> There was an error while updating project 'Acme'
[ ] After deleting a project -> Project 'Acme' was deleted
[ ] After successfully editing your profile -> Your profile was successfully updated
[ ] After an error while editing your profile -> There was an error while updating your profile


Smoke test for Docfx v3

Docs Build status updates of commit 0de502d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/SmokeTest.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Updated balances streamed to recipient

Recipient should receive any updated balance in WS payload along with incoming message. This will prevent them from needing to make an additional request.
TODO:

[DONE] Change WS URL: https://github.com/thenewboston-developers/Core/issues/84
[DONE] Implement message typing
[DONE] Introduce apply on commit
Add balance type (actually, we stream an account change)

@buckyroberts now it gets only balance increase or message with amount 0 notification. Do you mean that we should also include balance decrease notifications? What about POST messages with amount 0 that are send via POST request. Should we notify sender about these messages as well.
In all cases notification is a copy of the block?

Note from meeting - we decided that any/all updated balances will be streamed down to those users.

https://github.com/thenewboston-developers/Core/issues/84 to be implemented here

@buckyroberts we also decided that the balance update is delivered with its own message type

https://github.com/thenewboston-developers/Core/pull/85

https://github.com/thenewboston-developers/Core/pull/90


Primary/wave/wave UI fif v3

Add Wave Manager Autoload, Global Class

For managing wave attribute. e.g. multiplier score, normal or boss wave

Add Wave Timer for normal wave
Add Simple UI for displaying WaveNumber, Timeleft for next wave.

Note: Am i right doing the git pull --rebase

I'll merge this ya


[FLINK-1938] Add Grunt for building the front-end

This is the first step towards implementing the web interface refactoring I proposed last year: https://groups.google.com/forum/#!topic/stratosphere-dev/GeXmDXF9DOY
Once this is merged, I can get started with the rest of the refactoring. For now, the actual interface is kept the same, the only change is to how the build is done.

The build is failing because of the license checker (RAT) hanging, not sure why it's happening.
When building locally I get the same issue both on master as well as my topic branch. For testing I had to comment out the RAT section, does anyone know why this is happening?

Wow, this comes with a bit of a surprise, given that it is a followup to a year-old discussion in the pre-Apache project "Stratosphere".
Because such a long time has passed since then, I have started bootstrapping some other work for an improved web frontend.
It consists of two parts:

A REST style backend that produces JSON structures with the information rendered by the frontend (lists of states, timestamps, names, counters, ...).
An angular.js based frontend, that is still much work in progress (someone else is helping me out there)

You can have a look at (1) here "https://github.com/StephanEwen/incubator-flink/commits/web_frontend_2" It supports queries for example like "http://localhost:8082/running//vertices" to get the vertex statuses for all vertices of a job. The nice thing is that it is extremely lightweight, by being a minimal layer on top of netty (which we use for data transport anyways). Before, I was trying to go for jersey/grizzly, but these are heavyweight (25+ dependencies) there were many version conflicts with other dependencies (like YARN).
I hope to be able to share a few screenshots for (2) on the mailing list next week.
How much have you implemented on your side? Can we find a way to bundle the two works together?

Sorry about that, I had given up on my last attempt because I couldn't figure out how to do the Maven-Grunt integration. After working on a few other Maven-based projects since then I figured I'd give it another shot.
I am sure we can bundle the two together, should I start working off the web_frontend_2 branch and send PRs to your fork instead? Is there anything specific you would want me to work on? I couldn't find any discussion on JIRA or the mailing list so I'm not sure how to proceed.

You are definitely welcome to participate in the new web frontend development. Have a look at the branch I sent you and see if you find your way around the new code (it is not too much so far, so it is okay, hopefully).
I am not familiar with Grunt. It says it is a JavaScript automation framework. What is it for, in the context of the web frontend?

Grunt is basically a front-end build tool. It is useful for things like
concatenating and minifying JavaScript, precompiling templates etc. The
plugin I added also includes bower which can be used to import third party
dependencies like FontAwesome or jQuery instead of bundling them in the
repository.
On Apr 27, 2015 2:03 PM, "Stephan Ewen"<EMAIL_ADDRESS>wrote:

You are definitely welcome to participate in the new web frontend
development. Have a look at the branch I sent you and see if you find your
way around the new code (it is not too much so far, so it is okay,
hopefully).
I am not familiar with Grunt. It says it is a JavaScript automation
framework. What is it for, in the context of the web frontend?
—
Reply to this email directly or view it on GitHub
https://github.com/apache/flink/pull/623#issuecomment-96562609.


layers: Update VU1426 test conditions

The 1.0.47 spec added language to clarify that pTessellationState is ignored
in pipelines where tess control/eval stages are inactive. See issue #1411
for details.

LGTM.

I've got a similar change running through our CI system now on this branch: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/tree/mikes_create_graphics_pipelines_1_0_47
The main difference is that it moves the VU 1426 check to parameter validation and addresses the other ignored arguments from the 1.0.47 spec update.

Awesome; yours wins, Mike. Thanks! I'll abandon my branch.


Fixed Formatting.

Fixed the formatting and grammar.
Also made it clear that malloc() is generally discouraged for use in C++. See here for more info.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


Display asset metadata on asset selection

if i understand the issue correctly, this is now done by clink the "i" icon. Please confirm that this can be closed

The "i" icon links to a raw REST result object, which doesn't quite solve this issue. The issue is to create a panel in the GUI that displays the metadata formatted nicely for user-friendly consumption.


api: don't override next version with new draft

closes https://github.com/inveniosoftware/invenio-app-rdm/issues/2197
Although small, the fix has a larger context to understand. When a record is published, its draft is soft-deleted in the db until cleanup_drafts hard deletes it. When that happens, the published record has no associated draft anymore, so edit will create a completely new draft for it. However, that record may have a new version already (this is a fairly common occurrence in a running instance), so the new draft must not overwrite the reference to the next_draft_id stored in the parent. Because next_draft_id is used both to refer to a record's next version and a never published before draft's own id, we get interference. By checking if we are in the case of a record that has been published (only records that can have a new version) versus a record that has not, we can appropriately set that next_draft_id.
Another challenge with this PR was testing it. When trying to test this at the service level, we encounter OpenSearch's delete behavior (link to ElasticSearch but it applies to OpenSearch): the deleted document's version is kept around for 60s after deletion to overcome concurrency issues: Opensearch keeps a tombstone of deleted documents around and lets you reindex to a deleted document. So the version needs to stick around a little to make sure an update sent just before deletion was processed doesn't create a new record (updates can create new records in ES/OS).

Since the failing tests are due to https://github.com/inveniosoftware/invenio-drafts-resources/issues/192 and may be remedied by https://github.com/inveniosoftware/invenio-drafts-resources/pull/231, I might as well put this up for review.

@Samk13 for review too


fix(analyzer): readonly fields

fixes #4136

At the moment, the accessors aren't even added to the fieldsMap


Add RedirectsUsers to SendPasswordResetEmails

AuthenticatesUsers, RegistersUsers and ResetsPasswords all employ RedirectsUsers for redirection on success. This adds the same functionality to SendPasswordResetEmails for consistency.

Unclear why this is needed.


Image component | Sanitize input

Description
Sanitize input from a React useState value flows into a script 'src' attribute, where it is used to dynamically construct the HTML page on client side:
https://github.com/eclipse-tractusx/portal-shared-components/blob/v2.1.42/src/components/basic/Image/index.tsx#L77
Additional information
Maybe useful for fixing

This code is intended to create an HTML image tag and sanitizing at this point is not very helpful as our Image component is simply an alternative to the default HTML , MUI or any other Image component. The src attribute is only handed over to the default img tag or a loader function. If application developers decide to use any other image component the issue is still there.


build(dependencies): update dependencies and code based on breaking changes

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Cue player to start of an effect

Maybe when you double click the effect to bring up the editor?

put on rt click menu


nginx comparison

which has better performance, node-media-server or nginx-rmtp?

nginx-rmtp has better performance.
There is no doubt. 😅

thanks is nginx-rtmp fastest solution at present?
do you think that nodejs could perform well against it in the future?

The SRS is the best performance solution as far as I know.


Distributed builds / Remote Caching

I've had a search around for anything shake related in regards to performing distributed builds / remote caching, but couldn't find anything. Does such a thing exist, and if not, would there be anything preventing those features from being developed?

https://github.com/ndmitchell/shake/blob/master/docs/Cloud.md describes the current state of play.


Minor code cleanups and reformatting

See title.

LGTM!
@benh , could you please fix code format issues?


x/net/http2: request-response loop is ~2-3 times slower on http2 than on https

What version of Go are you using (go version)?
go version go1.7.4 linux/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build416699138=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?
I need a fastest way to securely communicate between microservices. And I tested request-responce loop with https and http2. Client starts 10 goroutines and each of them does 10k requests to server
And it turned out that https is 2 to 3 times faster when sending and receiving relatively small amounts of data(129 bytes request, 173 bytes response)
Server: https://play.golang.org/p/22hOHrHNZs
Client: https://play.golang.org/p/OdEh9cUvah (change IP on line 42)
I have 2 2xcpu servers with ~1 ms latency between them
When I run this test with http2 enabled it takes about 14 seconds for 100k requests divided in 10 goroutines
without http2 it takes about 7 seconds
Moreover, if I reuse client between goroutines it takes ~24 seconds on http2.
What did you expect to see?
A speed up between client and server when using http2
What did you see instead?
2x slowdown

I don't think anyone will have a chance to look at this in detail until after Go 1.8 is released. In the meantime, the following may help:

Do you see the same slowdown in go 1.8 beta or in go 1.6?
Do you have svg profiles of the http2 server and client?

Brad has done some optimization work for grpc-over-http2 that may help. I'm not sure if all of those optimizations have been submitted yet.

What did you expect to see?
A speed up between client and server when using http2

I wouldn't expect a speedup. The https version probably pipelines all 100k requests over just 10 TCP connections. I doubt you will see any benefits from muxing all requests onto a single TCP connection unless you're on a congested WAN or have many fewer requests-per-connection. That said, a 2x slowdown is not expected. Thanks for the report.

Hi and thanks for your response.
I've tested with current master go version devel +c1ada22b Thu Dec 15 05:46:20 2016 +0000 linux/amd64 and results are prety same
Here are profiles made with 1.7.4: (http2, one client per goroutine)
https://github.com/Scratch-net/files/blob/master/client.svg
https://github.com/Scratch-net/files/blob/master/server.svg
I understand that 10 keepalive https connections might be faster than one http2 connection but don't understand why are they faster than 10 http2 connections.
Also I've tested this very client against nginx http2 server with the same response size and for some reason using one http2 connection in client is faster than 1 per goroutine. Have no idea why

@Scratch-net, can you try with Go 1.9? There are a few HTTP/2 performance improvements for the 1.9 release.


latest beta5 errors with OpaqueToken function calls

I have build latest (master) ui-router-ng2.beta5 with latest (master) ui-router-core.5.0.0-pre1 and latest angular-cli.rc.4
Unfortunately with this setup app wont compile. Throwing an error related ti uiRouterNgModule:
ERROR in Error encountered resolving symbol values statically. Calling function 'OpaqueToken', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol UIROUTER_ROOT_MODULE in /Users/marcin/Sites/UiRouterTestApp/node_modules/ui-router-ng2/lib/uiRouterNgModule.d.ts, resolving symbol makeRootProviders in /Users/marcin/Sites/UiRouterTestApp/node_modules/ui-router-ng2/lib/uiRouterNgModule.d.ts, resolving symbol UIRouterModule.forRoot in /Users/marcin/Sites/UiRouterTestApp/node_modules/ui-router-ng2/lib/uiRouterNgModule.d.ts, resolving symbol AppModule in /Users/marcin/Sites/UiRouterTestApp/src/app/app.module.ts, resolving symbol AppModule in /Users/marcin/Sites/UiRouterTestApp/src/app/app.module.ts
can anyone help me with this ? thanks

this now works fine


Problem to set up connection with "LocalOnlySignaler"

I am trying to make the LocalOnlySignaler component work. My goal is simply to send video streams from one peer to another to test a new CustomVideoSource that reads from SharedMemory (so far to get LocalOnlySignaler work I still use SceneVideoSource which is beeing captured and displayed correctly). Unfortunately I can´t get the two peers connected.
To start the connection, I listen to the OnInitialized-Events of both peers. After both peers are Initialized, I call the StartConnection-Method in LocalOnlySignaler.  In the same Time, I execute WaitForConnection as a Coroutine with a timeout of 10000.
While debugging, I can see that the offer is sent and an answer SDP is sent back to peer one, but there is no Video stream beeing received.
I have no idea what is missing. Please give me a hint.

OK, I was able to make the LocalOnlySignaler work, the only thing that is still not working is the transmission of the SceneViewSource. While the WebCamSource is beeing transmitted as it should, the SceneViewSource isn´t.


Change REWUIRES -> REQUIRES

Located in QuickConvertorV2.ahk and QuickConvertorV2_scintilla.ahk

A typo in a comment ...

This is now corrected.


WIP: Substance Manual

Codecov Report

Merging #1099 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #1099   +/-   ##
========================================
  Coverage    60.95%   60.95%
========================================
  Files          372      372
  Lines        13661    13661
========================================
  Hits          8327     8327
  Misses        5334     5334

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 a940d46...e376bc0. Read the comment docs.

Thanks for this. Very enlightenment. It should be in the substance.io website as a overview.

Merging this. Better than having nothing. :)


Named export 'AccordionItem' not found.

When I try to deploy ssr project(InertiaJS Vue3) I get this error
`import { AccordionList, AccordionItem, useAccordion } from "vue3-rich-accordion";
^^^^^^^^^^^^^
SyntaxError: Named export 'AccordionItem' not found. The requested module 'vue3-rich-accordion' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'vue3-rich-accordion';
const { AccordionList, AccordionItem, useAccordion } = pkg;`

Hi, @dmitrisi4
It is not an issue of plugin. Sounds like problem with configs of your app.
I think you have different config for prod and dev modes. (maybe webpack and vite)
Plugin's folder dist contains both accordion-library.es.js and accordion-library.umd.js files for different variants of an import.
I think, you have same issuie


Fix FastHLL throw NPE.

Add BrokerRequestPreProcessor class to pre-process the broker request.
Move hll derived column name map from StarTreeMetadata to SegmentMetadata.
Rewrite the hll derived column name before making the plan name.

Current coverage is 64.20% (diff: 82.35%)

Merging #849 into master will decrease coverage by 0.10%

@@             master       #849   diff @@
==========================================
  Files           728        729     +1
  Lines         34386      34370    -16
  Methods           0          0
  Messages          0          0
  Branches       5273       5267     -6
==========================================
- Hits          22114      22066    -48
- Misses        10692      10730    +38
+ Partials       1580       1574     -6

Powered by Codecov. Last update bc9a8cb...e7ea376

Suggested in person to modify the global copy of BrokerRequest just for this case. The global change will apply to all the segments but we don't want to support different combination of hll suffixes across segments.


Are we ndarray 0.15 ready yet?

I open this issue to keep track of stuff required to bump to ndarray 0.15. From #110 we get the following list:

[x] approx = 0.4
[x] argmin = 0.4.6
[x] ndarray-csv = 0.5.1
[x] ndarray-linalg = 0.14.0
[x] ndarray-npy = 0.8
[x] ndarray-rand = 0.14
[x] ndarray-stats = 0.5
[x] num-traits = 0.2
[x] rand = 0.8
[x] rand-isaac = 0.3
[ ] sprs

I just submitted a pull request to ndarray-csv updating it to use 0.15, and will add an update if it gets merged/a new version is posted to crates.io

@relf I believe that we should be all set with ndarray-csv now--0.15 should be supported with ndarray-csv = "0.5.1"

Are we waiting for argmin, ndarray-linalg, and sprs to include ndarray 0.15 in their dependencies before bumping?

Well... I guess it was the plan, thinking that linfa's dependencies would upgrade rapidly. Do you suggest we could bump some of linfa's subcrates?

Yep, we agree. Btw it seems dificult to mix different versions of ndarray anyway (when it occurs by mistake it ends up with compilation errors).

both sprs and ndarray-linalg are already using ndarray = 0.15 in their git tree, but they are not yet published to crates.io. I also created an issue at argmin side https://github.com/argmin-rs/argmin/issues/123

ndarray-linalg and argmin on ndarray = 0.15 are published, one to go...

I would like to update all dependencies to ndarray = 0.15 before publishing a new linfa version

sprs 0.11.0 was published right now, and uses ndarray = 1.15

Closed by #156


Lab 4 - Task 5: No data populated on cloud service database

I am able to get the data to populate to the local database using the data generation project, but then when publishing to the cloud only the tables are created. It doesn't seem the steps as given in the answer key actually migrate over the data created in the local database or execute the data generation automatically.

I finally got the data uploaded by using SQL data compare against the local database to the database deployed on the cloud and then doing the update target, but it seems there should be an easier way.

If you follow the guide then the data will be created using the database initializer


Make brightness display work for rgb devices.

Non rgbw devices return 255 for getWarmWhite255. This is part 2 to make the brightness slider work for these devices.
https://github.com/Danielhiversen/flux_led/pull/25

:dolphin:


chore: update example

Summary

Update jest-puppteer example. see https://github.com/smooth-code/jest-puppeteer/issues/168

Test plan
npm run test: integration is running normally

Thanks!


[5.4] Add macros to Eloquent/Builder

This adds macroable functionality to the Eloquent/Builder, with one exception to the normal implementation — it doesn't use the Macroable trait.
This because the class already has it's own locally scoped macro functionality. For example, when you to enable soft deletes on a specific model. Unfortunately this functionality cannot be globally (statically), hence this change.
To use the macro() method in both local and static situations, I've removed the method from the class and implemented it via __call() and __callStatic().
From my testing, I believe this change maintains 100% backward compatibility.

Refs #21980.


coursier_repositories vs sbt repositories

Have you considered deprecating sbt repository settings in favor of using coursier_repositories?

We use GitHub issue mostly to track bugs and tasks on sbt development. If you have a proposal please bring it up on https://discuss.lightbend.com/c/tooling


Corrected the trajectory of the Krause bow

Describe the feature you'd like to see added
I don't know if you have noticed that when we use Krause's bow to aim at the head of an enemy in the distance, the arrow often fails to hit the enemy's head.  I don't know how to fix it, I'm out of ideas

I always wondered why his bow felt so off to use during gameplay. Is it possible that the red laser is slightly misaligned? Because that laser basically ensures whether you hit an enemy or not.

Hmm, I may be talking nonsense here, but I always thought they just tried to mimic some "realistic" trajectory like so:

Been a while since I played as Krauser though, so I'll have to check again.

In version 1.0.6, we can get the initial coordinates of the arrow shot in Bio4.exe + 1D3208

Bio4.exe + 51202a, we can get the speed of arrows here. If we change the speed to -10, we can find the arrow misplacement

If we can find the coordinates of the infrared sight, maybe we can fix it


Is this support all latest android device including high dpi and latest os Android 5.0 to Android 10 ?

Do you experience any issue on Android 5.0 to Android 10? If so please let me know.


Making item as read and marking all as read are missing?

Item is not marked as read after reading, and the option to mark entire feed as read is missing?
Thanks...

#17 is filed for the first part of the issue.


Enable codecov

Testing enabling codecov (will be useful for some file format refactoring)

It looks like this might need to be on master so there are base reports to enable most of the functionality.

It looks like this might need to be on master so there are base reports to enable most of the functionality.


Consider using ansigenome.

To avoid errors like these: https://github.com/weareinteractive/ansible-cron/blame/4c13faba1b88fe001a266519601f3555c809fdbc/README.md#L25

Also Ansible Galaxy badge is wrong.

will take a loot at it and thx for the hint, I fixed the c&p erros

What do you thing about ansigenome? Not worth using?

No, definitely a great tool! I tested it and I can easily reproduce my README files.
Unfortunately it's only on a multiple role basis. Since I manage multiple roles from multiple clients and sources I would need it to be on a per role basis. Thus also ensuring that if someone else forks my role he can generate the same README file.
It might be sth worth to propose as a feature and I'll look into it again when I have more time for it.

So here's my first try in resolving this issue: ansible-role gem
I admit , it's an early alpha version and currently pretty much tailored to my needs, but it might be a starting point.
you can see my first role here

Interesting, you like Ruby I guess …

haven't done too much ruby lately so I'm giving it a try again :)


Adding themed components for EditBitstreamPageComponent and ItemStatusComponent

Description
This PR adds theming support for the following components:

EditBitstreamPageComponent
ItemStatusComponent

Instructions for Reviewers
In order to test the components:

Modify their respective components in "custom" theme to use the themed template and add anything to those templates (e.g. a simple span with text "test") to verify its presence
Enable the "custom" theme in config
Start the application
Visit the edit page of a bitstream, confirm the themed template is visible
visit the status page of an item (edit), confirm the themed template is visible

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes ESLint validation using yarn lint
[x] My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
[x] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[x] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[x] If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

Moving this to 7.6.  While I'm always glad to see new themed components, I'm hesitant to add this in very late into a release. So, once this can have merge conflicts resolved, I'll work to get this into 7.6 very early in that release.

@Atmire-Kristof : Just a friendly reminder that this PR has merge conflicts.  If it can be updated in the next few weeks, we can review it in time for 7.6.


Update lug-helper: 2.18 -> 3.0.1

Things done
Diff: https://github.com/starcitizen-lug/lug-helper/compare/v2.18...v3.0.1
Changelog: https://github.com/starcitizen-lug/lug-helper/releases/tag/v3.0.1
Updated package to follow the newly added packager's guide

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

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

@ofborg build lug-helper lug-helper.passthru.tests


emicate, fornices

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[e,f]

/trunk merge


Failed to sign bare multi-sig trx when mint image stamp on OpenStamp

When attempting to mint the image below on OpenStamp(https://openstamp.io/mint), an error is displayed. It works well when transferring SRC20 tokens that also use bare multi-sig outputs.

Unexpected Application Error!
OutScript/multisig: wrong pubkey
Error: OutScript/multisig: wrong pubkey
at chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:232999:23
at Object.decodeStream (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:253761:30)
at Object.decode (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:253489:31)
at getAddressFromOutScript (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/index.js:48282:91)
at chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/index.js:20328:78
at Array.map ()
at chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/index.js:20323:19
at Object.useMemo (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183679:189)
at exports.useMemo (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:188886:208)
at useParsedOutputs (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/index.js:20322:27)
at useParsedPsbt (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/index.js:20474:25)
at PsbtSigner (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/index.js:20571:7)
at Xh (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183662:137)
at Wk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183785:337)
at Vk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183775:389)
at Uk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183775:320)
at Jk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183775:180)
at Ok (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183766:88)
at Fk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183768:300)
at jg (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183622:105)
at Xk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183778:470)
at Qk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183776:398)
at Hk (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:183765:269)
at J (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:195596:203)
at MessagePort.R (chrome-extension://ldinpeekobnhjjdofggfgjlcehhmanlj/352.js:195597:128)

Some users also had an issue when transferring src20 from OpenStamp using Leather.
The last two outputs should be bare multi-outputs, but it became the first output(src20 token recipient). We checked our code which shouldn't compose this kind of transaction. Not sure if you can help check the logic for this issue from Leather side.
https://mempool.space/tx/32398ecaa91ffd101fb9bd0382acdf2858ea378528ef4befd779d460f6fc8e58
https://mempool.space/tx/7d3a7ed4afc7faa75fab3d25344282001524a34ba58d1a980af9a334c054f840
https://mempool.space/tx/dc83188d8e278b99b4e078f5ccb3c0cfb3428015ba56be683b2c199f507e8072

Some users also had an issue when transferring src20 from OpenStamp using Leather.
The last two outputs of the following transactions should be bare multi-outputs, but it became the first output(src20 token recipient). We checked our code which shouldn't compose this kind of transaction. Not sure if you can help check the logic for this issue from Leather side.
https://mempool.space/tx/dac04fab0069f3c01f6660a824aead7347799f3eede3768eb03ff64b7de46342 https://mempool.space/tx/32398ecaa91ffd101fb9bd0382acdf2858ea378528ef4befd779d460f6fc8e58 https://mempool.space/tx/7d3a7ed4afc7faa75fab3d25344282001524a34ba58d1a980af9a334c054f840 https://mempool.space/tx/dc83188d8e278b99b4e078f5ccb3c0cfb3428015ba56be683b2c199f507e8072

This is due to the speed up function on the Leather wallet. The speed up transaction replaces the Bare Multi-Sig outputs with the first output address.

Retest after this fix is merged: https://github.com/leather-wallet/extension/pull/5110

Hello,
Could you please specify which bug you are referring to?

On 20/05/2024 20:59 +08 Mark Hendrickson @.***> wrote:
@btcopenstamp https://github.com/btcopenstamp is this bug still outstanding now that we pushed the above fix in March?
—
Reply to this email directly, view it on GitHub https://github.com/leather-wallet/extension/issues/5015#issuecomment-2120414404, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAVNPCBWIKNEQP2XNX3NRW3ZDHXUHAVCNFSM6AAAAABEFEYSB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGQYTINBQGQ.
You are receiving this because you were mentioned.Message ID: @.***>

Best wishes,
OpenStamp Support Team
https://openstamp.io/

It's the one detailed at the top of this issue:

It's the one detailed at the top of this issue:

Hi @markmhendrickson
Sorry for the late response. Just checked, issue still exists with Leather version 6.41.1

@fbwoolf is this awaiting the extension-specific step indicated here?

@fbwoolf is this awaiting the extension-specific step indicated here?

That fix was already installed back in the ext. This bug seems to be diff in that the log is of the wrong pubkey not hitting the output script type error.