Flynnfile should allow specification of required ENV variables.

The Flynnfile should allow a developer to specify a list of environment variables that are required at each of buildtime and runtime.
Flynn should prompt the user to specify these variables before attempting to build and/or run the application.

Comment added to #1084.


V3.4.0 release

Readies the code for a minor release

Codecov Report

Merging #256 (8860ab0) into main (f4ebdfa) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #256   +/-   ##
=======================================
  Coverage   97.25%   97.25%
=======================================
  Files          20       20
  Lines         729      729
=======================================
  Hits          709      709
  Misses         20       20

Impacted Files
Coverage Δ

src/vonage/__init__.py
100.00% <100.00%> (ø)

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


[10.x] Use model cast when builder created updated at value

fixes #47769
If a model is using a cast on the updated_at column, it is not respected when the builder creates the updated_at value.
When updating a model, in most cases the updated_at value is created in the eloquent model, where the cast is respected.
This means the builder receives the updated_at value in the array it is asked to put into the database. When this happens, everything is good, as the value created by the builder is ignored.
However, when the value of updated_at has not changed, i.e. the time is the same as last time it was updated - which you might find happens in a unit test, the updated_at is not marked as "dirty" and the model does not pass the updated_at column through to the builder.
In this case, the builder manually creates and adds the updated_at value to the array it is putting into the database.
When the builder creates the updated_at value it does not use any casts that are in place on the model for the updated_at column.
For timestamp only values, if you are storing the updated_at as an integer, as per #47769, and not other dates, the value attempted to be insert into the database will be 2020-01-01 00:00:00 formatted and MySQL will throw an exception as it is expecting an integer.
Performance implications
I ran some benchmarks using 10,000 iterations.
Updated at set by the builder, i.e. time has not progressed
If you do not have a cast in place for the updated_at column: there is no change ☑
If you do have a cast in place for the updated_at column: 0.006ms > 0.02ms ⬇
Updated at set by the model, i.e. time has progressed
0.006ms > 0.0ms (micro optimisation) ⬆
So the implications are only for the cases where you have a cast in place and time has not progressed, which I would guess is 99.999999999999% of the time in a unit test and not going to impact an actual user.

Makes sense to me and has @driesvints vote too https://github.com/laravel/framework/issues/47769#issuecomment-1651656631
Do you need me to patch my code and confirm its all hunky dory?

@willpower232 that would be super. The test I added replicates the exception and scenario you were hitting, so either way I think this PR makes sense.
However, I would absolutely love for you to actually test this. Let's mark as draft until you can confirm.

Updated to fix for mutators / attributes

I swapped your repo and branch in for the framework folder in a testing copy and got the following error from running tests

Undefined array key "updated_at" (expand for stack trace)

Undefined array key "updated_at"

/var/www/vendor/laravel/framework/src/Illuminate/Testing/TestResponse.php:148
/var/www/tests/Feature/Http/Controllers/CustomerControllerTest.php:164
/var/www/vendor/laravel/framework/src/Illuminate/Foundation/Testing/TestCase.php:174

3) Tests\Feature\Http\Controllers\UserControllerTest::testUpdateUserRoles
Expected response status code [201, 301, 302, 303, 307, 308] but received 500.
Failed asserting that false is true.

The following exception occurred during the last request:

ErrorException: Undefined array key "updated_at" in /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php:1150
Stack trace:
#0 /var/www/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(254): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'Undefined array...', '/var/www/vendor...', 1150)
#1 /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(1150): Illuminate\Foundation\Bootstrap\HandleExceptions->Illuminate\Foundation\Bootstrap\{closure}(2, 'Undefined array...', '/var/www/vendor...', 1150)
#2 /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php(1042): Illuminate\Database\Eloquent\Builder->addUpdatedAtColumn(Array)
#3 /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php(1213): Illuminate\Database\Eloquent\Builder->update(Array)
#4 /var/www/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php(1130): Illuminate\Database\Eloquent\Model->performUpdate(Object(Illuminate\Database\Eloquent\Builder))
#5 /var/www/app/Http/Controllers/UserController.php(45): Illuminate\Database\Eloquent\Model->save()
<further lines removed for brevity>

$timestamp = $this->model->newInstance([$column => $timestamp])->getAttributes()[$column];

I presume this means that the attribute isn't returned by getAttributes for some reason? Am I missing a change to the cast class we have?

@willpower232 give it another shot, if you don't mind. Didn't account for attribute guarding.

Aha that seems to be correct, its passing all my tests now :tada:

Thanks for testing this, @willpower232

No problemo, thanks for figuring it all out!

@timacdonald  I have a mutator on the updated_at column which prevents setting updated_at on creating a model. If I update a model I get the following error:
ErrorException: Undefined array key "updated_at"
../vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php:254
../vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php:1167
../vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php:1057
../vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:1213
../vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:1130

Creating a models works as expected. Do you have any idea?

I’m very sorry, I didn’t see a notification for your message @maxxscho
As @willpower232 asked, if we could please see the mutator we can take a look. It might be good to open an issue and provide the mutator so I can take a look.
Mention me in the issue and I will jump in.

@willpower232 sure.
public function setUpdatedAtAttribute($value): void
{
    if (! $this->id) {
        return;
    }

    $this->updated_at = $value;
}

Basically only if the model has an ID (it has been persisted in the DB) the updated_at attribute should get a value (this peace of the software is very old so it might look a little bit odd 😄 )

Your idea makes sense but shouldn't it be
$this->attributes['updated_at'] = $value;

We can likely resolve the issue with
$timestamp = $this->model->newInstance()
    ->forceFill([$column => $timestamp])
    ->getAttributes()[$column] ?? $timestamp;

Funnily enough I actually had this in the original version but removed it cause I couldn’t think of when it would happen - but now I know!
We need to add a test to validate the fix and ensure it doesn’t break again in the future.
I’m on my phone and not in till tomorrow.
will ping @jbrooksuk @driesvints to see if they have time to PR a test with the above fix for the Tuesday release 🙏

@timacdonald I quickly tried this fix and my tests are green again.

@maxxscho I'm having a hard time reproducing this in a test. Can you share your full model please?

@driesvints of course.
<?php

namespace App\Models;

use Carbon\Carbon;
use Illuminate\Database\Eloquent\Builder;

class UserRunStreak extends BaseModel
{
    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'user_id',
        'current',
        'record',
        'updated_at',
    ];

    protected $casts = [
        'current' => 'integer',
        'record' => 'integer',
    ];

    /**
     * Set updated_at attribute only on updates, not create.
     */
    public function setUpdatedAtAttribute($value): void
    {
        if (! $this->id) {
            return;
        }

        $this->updated_at = $value;
    }

    /**
     * Increase current.
     */
    public function increaseCurrent(): void
    {
        $this->current += 1;
        $this->save();
    }

    /**
     * Increase record.
     */
    public function increaseRecord(): void
    {
        $this->record += 1;
        $this->save();
    }

    /**
     * Reset current.
     */
    public function resetCurrent(): void
    {
        $this->current = 0;
        $this->save();
    }

    /**
     * Scope query to filter active results.
     */
    public function scopeNotUpdatedFor24hours(Builder $query): Builder
    {
        return $query->where('updated_at', '<', Carbon::now()->subDay()->toDateTimeString());
    }
}

@maxxscho do you somehow manually set the updated_at when creating a model?

@driesvints no, it's not set manually on creating. The reason for the mutator is to keep updated_at null on creating.

I just have too few info to reproduce this sorry. Can you create a repo for me with an app that reproduces this?
laravel new bug-report --github="--public"

Nvm, got it: https://github.com/laravel/framework/pull/48230. Thanks


Allow upload per dataset in a single statline-bq flow

Currently, if running a statline-bq flow over multiple datasets, the upload_to_gcs task starts only once all datasets have been converted to parquet. This is caused due to listing files_parquet as one of the upstream_tasks dependencies here, like so:
gcs_folders = upload_to_gcs.map(
        dir=pq_dir,
        source=unmapped(source),
        odata_version=odata_versions,
        id=ids,
        config=unmapped(config),
        gcp_env=unmapped(gcp_env),
        upstream_tasks=[files_parquet, col_desc_files, go_nogo],
    )

This was done as the upload is directed to a folder, and is a non-data dependancy. It cannot be simply removed, as that will cause the upload_to_gcs task to run prior to the files being converted.
This causes situations where if one of 10 datasets is significantly larger, the other 9 would not be uploaded until it is completed. If an error occurs, (i.e. the VM shuts down) - they are all unnecessarily erased.
This dependancy should be more nuanced - and prioritise upload of a dataset whenever possible.

Nope, that's absolutely false, we're good :)

Correction upload_to_gcs can start before all datasets finish, but still a single large dataset delays that significantly. This may be due to not having free workers to run the tasks.
The main issue stands - find a way to prioritise upload_to_gcs for a converted dataset over converting other datasets.

Effectively closed by #86


Error due to closed db connection

Issue Type
[x] Bug
Description and/or steps/code to reproduce the problem
Seeing this intermittently on at least API 15 emulators while running connected tests. Relevant logcat excerpt:
W/OsmDroid( 1580): Error getting db stream: /2/1/0 W/OsmDroid( 1580): java.lang.IllegalStateException: database /mnt/sdcard/osmdroid/testzoom4.sqlite (conn# 0) already closed W/OsmDroid( 1580): 	at android.database.sqlite.SQLiteDatabase.verifyDbIsOpen(SQLiteDatabase.java:2082) W/OsmDroid( 1580): 	at android.database.sqlite.SQLiteDatabase.lock(SQLiteDatabase.java:413) W/OsmDroid( 1580): 	at android.database.sqlite.SQLiteDatabase.lock(SQLiteDatabase.java:400) W/OsmDroid( 1580): 	at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:79) W/OsmDroid( 1580): 	at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:164) W/OsmDroid( 1580): 	at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:156) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.modules.DatabaseFileArchive.getImage(DatabaseFileArchive.java:91) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.modules.DatabaseFileArchive.getInputStream(DatabaseFileArchive.java:110) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.modules.MapTileFileArchiveProvider.getInputStream(MapTileFileArchiveProvider.java:195) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.modules.MapTileFileArchiveProvider.access$100(MapTileFileArchiveProvider.java:29) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.modules.MapTileFileArchiveProvider$TileLoader.loadTile(MapTileFileArchiveProvider.java:229) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.MapTilePreCache.search(MapTilePreCache.java:99) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.MapTilePreCache.access$100(MapTilePreCache.java:26) W/OsmDroid( 1580): 	at org.osmdroid.tileprovider.MapTilePreCache$1.run(MapTilePreCache.java:37) W/OsmDroid( 1580): 	at org.osmdroid.util.GarbageCollector$1.run(GarbageCollector.java:31) W/OsmDroid( 1580): 	at java.lang.Thread.run(Thread.java:856) D/OsmDroid( 1580): TileLoader failed to load tile due to mWriter being null (map shutdown?)
Full logcat: https://api.travis-ci.org/v3/job/396125119/log.txt
Don't know if this related to the tests itself or might be a concurrency issue related to the new GC functionality. Maybe @monsieurtanuki can take a look?
Environment
If it's a bug, version(s) of android this affects:
at least API 15
Version of osmdroid the issue relates to:
6.0.2

@cbalster If I remember well, with the new GC feature we never explicitly close the db.
I see in the logs something like "TileLoader failed to load tile due to mWriter being null".
My first guest: when the test is over we "detach" the fragment and set the mWriter to null, which somehow implicitly closes the db, while in the same time the GC is running.
A simple fix would be to say in the GC: "btw if the db is closed don't try to do anything" (as it's pointless - and prone to bug - in that case anyway)

looking at this now

@cbalster any other parts of the code that could cause this condition?

All I know right now is based o  the stacktrace. Some test - maybe even a
previous one - starts the new FC mechanism so we run into a concurrency
problem.
That is a general problem I see with the androidtests:  it's hard to reason
about some issues since right now we can't  really guarantee starting
conditions or a proper cleanup due to static fields, concurrency and
singletons.

ok well we'll close for now and reopen if needed


WorkspaceSvg's audio functions not included

I managed to install and build the English version of everything, on a linux FC21 installation.
I tried running the turtle game, both from the filesystem using a file:///home/arjen/src/blocky-games/appengine URL, and using a simple HTTP server started in the appengine directory (using python -m SimpleHTTPServer) and opening http://localhost:8000/turtle.html?lang=en
In both cases, I get errors related to audio;
whether it is Blockly.loadAudio_ or Blockly.playAudio:
Uncaught TypeError: Blockly.loadAudio_ is not a function
Uncommenting these makes the game run.
I found an ugly fix to resolve the problem:
Replace Blockly.loadAudio_ by Blockly.getMainWorkspace().loadAudio_
(And, doing the same for playAudio of course).
I guess there may be a more elegant resolution that applies to all instances of the games at once?
Cheers, and btw, I really like blockly, got students started on code.org, and now believe that the blockly-games are excellent next steps for the pupils I am working with to make further progress.
So thanks!
Arjen
PS:
I posted the issue here: https://groups.google.com/forum/#!topic/blockly-games/F2D3RPZUax0
Is the group forum the place to report issues, or is this route straight to github preferred?
PS:
I would be helped with a streamlined instruction on how to create a pull request for a given solution for a report like this...

The Blockly Games codebase has been updated to be compatible with the current Blockly codebase.  This error is now resolved.

Great thank you Neil!


Calling MultiplayerAPI in a thread results in crashes.

Godot version
4.1
System information
Godot v4.1.stable - Fedora Linux 38 (KDE Plasma) - Vulkan (Forward+) - integrated Intel(R) Xe Graphics (TGL GT2) () - 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz (8 Threads)
Issue description
Whenever a MultiplayerAPI call is made in a function running in a thread, that thread will crash.
Issues started occurring in 4.1 in all 4.0 releases this worked fine.
Steps to reproduce
Start a thread.
Call multiplayer.get_unique_id() in that function.
The function will exit immediately.
NOTE: No debug information will be provided due to: https://github.com/godotengine/godot/issues/18330
Minimal reproduction project
multiplayer_thread_test.zip

Multiplayer is only supported from the main thread (...)

I can't find any information in the docs of that being the case. Is that by design or just a long-standing issue?

Should probably be more clearly documented though

APIs are non-thread safe unless stated otherwise, see here

Oh ok! It would have been useful to have that also in the MultiplayerAPI doc.
Thanks for the info!

To clarify, the crash comes not from the thread safety as such, but from accessing methods on multiplayer when that is null, fixing the errors on threads, and documenting this should be the plan IMO

Multiplayer is only supported from the main thread

IMO, even if it's not possible it shouldn't crash, instead an error should be printed to console/output.

The problem is that if you fetch the multiplayer and then call something on it how do you avoid a crash then? The returned value from multiplayer will be null

Calling things like is_multiplayer_authority used to crash but was fixed, but since it's up to the user to add null checks we can't fix user code that doesn't do that with multiplayer


transfers/pipeline/notify: setup slack messages

Via their handy dandy webhooks.
Docs: https://api.slack.com/messaging/webhooks#advanced_message_formatting

Codecov Report

Merging #498 into master will decrease coverage by 6.57%.
The diff coverage is 68.57%.

@@            Coverage Diff             @@
##           master     #498      +/-   ##
==========================================
- Coverage   52.48%   45.91%   -6.58%
==========================================
  Files          91       91
  Lines        3363     3387      +24
==========================================
- Hits         1765     1555     -210
- Misses       1288     1563     +275
+ Partials      310      269      -41

Impacted Files
Coverage Δ

pkg/config/pipeline.go
63.46% <62.50%> (-1.76%)
:arrow_down:

pkg/transfers/pipeline/notify/slack.go
73.33% <70.37%> (-26.67%)
:arrow_down:

pkg/upload/sftp.go
14.65% <0.00%> (-51.84%)
:arrow_down:

pkg/database/mysql.go
11.11% <0.00%> (-51.12%)
:arrow_down:

pkg/customers/client.go
7.76% <0.00%> (-49.52%)
:arrow_down:

pkg/transfers/pipeline/notify/email.go
25.35% <0.00%> (-38.03%)
: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 4afafb7...39ee3d2. Read the comment docs.


Image picker not working 8.0

Flutter image picker not working 8.0 mobile.but working other mobiles(include pie also).

@maheshsystimanx
Paster flutter doctor -v please.

this code run by terminal or where?
please give explain

what do you mean by 8.0? android api 28 you mean?

i run this command.but below show this error.pls help resolve
flutter doctor -v
[!] Flutter (Channel stable, v1.5.4-hotfix.2, on Linux, locale en_IN)
• Flutter version 1.5.4-hotfix.2 at /home/systimanx/Downloads/flutter
• Framework revision 7a4c33425d (9 weeks ago), 2019-04-29 11:05:24 -0700
• Engine revision 52c7a1e849
• Dart version 2.3.0 (build 2.3.0-dev.0.5 a1668566e5)
✗ Downloaded executables cannot execute on host.
See https://github.com/flutter/flutter/issues/6207 for more information
On Debian/Ubuntu/Mint: sudo apt-get install lib32stdc++6
On Fedora: dnf install libstdc++.i686
On Arch: pacman -S lib32-gcc-libs
[!] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
• Android SDK at /home/systimanx/Android/Sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-28, build-tools 28.0.3
• Java binary at: /snap/android-studio/76/android-studio/jre/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b16-5323222)
! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses
[✓] Android Studio (version 3.4)
• Android Studio at /snap/android-studio/76/android-studio
• Flutter plugin version 35.3.1
• Dart plugin version 183.6270
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b16-5323222)
[✓] Android Studio (version 3.3)
• Android Studio at /snap/android-studio/73/android-studio
• Flutter plugin version 31.3.3
• Dart plugin version 182.5124
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1248-b01)
[✓] Connected device (1 available)
• moto e5 plus • ZF6223G4WV • android-arm • Android 8.0.0 (API 26)
! Doctor found issues in 2 categories.

@maheshsystimanx did you manage to solve it?

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


project description?

Hello, your project looks interesting. Can you say something on the Readme so that I may understand it better.

Thanks for your interest. Thought to do a little of improvements before before adding a readme. Will address your request soon.
-Harish

Added the README. Please review!
I'm closing the issue.
Thanks,
Harish


¿This is bug? Controller and database

First of all I want to apologize for my bad English
Recently I have been working with Adonis Js and I really had only but problems related to the little understanding of my English and the framework, however yesterday I noticed something quite strange, I was having problems with a query and then rummage and dig in the code I came to the conclusion that the code was fine ... Which led me to wonder what was going on? I activated the developer mode in the adonis settings to be able to see the complete query to the database and what was my surprise to see that adonis was actually executing the query but IN ANOTHER TABLE, that is, I was telling Adonis to search in the "Conversations" table but Adonis was looking in the user table, something similar is happening to me today, I'm telling Adonis to execute a specific controller method and is executing another one (I know why the answer that is returning to me is that of the method that I should not be executing)
I would try to specify the code fragment that I want to execute but this error is happening with everything I am trying to put
Could this be a mistake? I have the project on github should I put it here?
Thanks in advance this is the code in the controller
Update:
I moved the route outside the group I was in and the code is working wtf? :o
controller1.txt
controller2.txt

Hey @gario300! 👋
Instead of sending your code in a txt file. Could you please create a repository or upload them on https://gist.github.com/ instead?
Also, this is more a question than an issue with the framework itself.
Please use the forum or the Discord Server for this kind of request.

Closing as issue is half baked and must be discussed on the Forum or Discord. Please issue the Github issues for confirmed bugs


ListArrayType isn't working when registered on Dialect config class.

In our service we have two ways for querying, one through the classic way using entities that involves using fully the ORM/repositories/criteriaQuery/etc and the other one just plain native SQL.
We use the ListArrayType at entity fields like
@Column(name = "range_texts", length = 500)
@Type(type = "list-array")
private List<String> rangeTexts;

@Column(name = "range_values")
@Type(type = "list-array")
private List<Integer> rangeValues;

and that's working well.
But we tried to use native queries doing a select on a column which is an array:
List<Object[]> rawResult = getCurrentSession().createSQLQuery(queryStringBuilder.toString())
                    .getResultList();

and in the dialect config class we set:
this.registerHibernateType(Types.ARRAY, ListArrayType.class.getName());

Then it throws a NullPointerExcepciton on :
Caused by: java.lang.NullPointerException: null
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:398)
	at com.vladmihalcea.hibernate.util.ReflectionUtils.getClass(ReflectionUtils.java:484)
	at com.vladmihalcea.hibernate.type.array.internal.ListArrayTypeDescriptor.setParameterValues(ListArrayTypeDescriptor.java:102)
	at com.vladmihalcea.hibernate.type.array.internal.AbstractArrayType.setParameterValues(AbstractArrayType.java:42)
	at org.hibernate.type.TypeFactory.injectParameters(TypeFactory.java:123)
	at org.hibernate.type.TypeFactory.type(TypeFactory.java:108)

The parameters argument passed to the setParamterValues is empty, so that ends up causing the null pointer.
If we set the dialect with StringArrayType, works fine, but we can't handle another scenario where we have int array for example.
Another weird scenario is that when ListArrayType is used like this:
List<Object[]> rawResult = getCurrentSession().createSQLQuery(queryStringBuilder.toString())
                    .unwrap(org.hibernate.query.NativeQuery.class)
                    .addScalar("member_fundings_eid", ListArrayType.INSTANCE)
                    .getResultList();

It works just fine. I debugged it and the setParameterValues function is never executed. That's why I think doesn't produce an error.
Any thoughts?
Thanks.

ListArrayType is way to specific to register it globally because it needs to know the underlying element type.
That's why it works when you use it for mapping columns. The property type will be sent to the associated ListArrayType.
So, you already know the solution. You need to use addScalar for each native SQL query that fetches arrays.

Thanks for the quick reply @vladmihalcea !
Didn't know about that specifics of ListArrayType, thanks for clarifying.
Ok, so we go with the solution of setting globally in dialect StringArrayType, and if we want to for example select a column that has int array then we specifically use .addScalar
Thanks!

You're welcome.


uBit.audio.soundExpressions.play() (blocking version) continues to output sound after the function returns

With this programme (there is more than the screenshot), which toggles a pin high while the [play sound until done] block is running: microbit-lonely-duckling-debug.hex.zip

We can see the sound output is actually delayed:

That [play sound] block in MakeCode it ultimately ends executing uBit.audio.soundExpressions.play() in:

https://github.com/microsoft/pxt-microbit/blob/d80514bda223f729d452c1e51047f3272a2317fb/libs/core/soundexpressions.cpp#L11

Proposed fix is in PR #210 and if approved will auto-close this issue as solved.

Reopening as this might need further work: https://github.com/lancaster-university/codal-microbit-v2/pull/210#discussion_r948913835

The original patch has also been reverted in v0.2.42-hotfix.1: https://github.com/lancaster-university/codal-microbit-v2/commit/e8e42b2ad8c0218b17ea2cbb9ef147ff94afa062
And in master:  https://github.com/lancaster-university/codal-microbit-v2/commit/696db50150fcde7f97e41fc41efe5159f19c68a7

Resolved, as discussed in: https://github.com/lancaster-university/codal-microbit-v2/issues/231


feat(RHTAPWATCH-970): Create Argocd applications

Add argocd applications to konflux-ci/konflux-ci
Jira-Url: https://issues.redhat.com/browse/RHTAPWATCH-970

@hmariset now that you also included the keycloak secret, can the top-level script be run and konflux will be bootstrapped? If so, can we enable CI for that similarly to what we have with the sanity check?

As far as I understand, we're making changes to kustomization files that we use also when deploying the clsuter using CLI. Is that the intention?

Yes, made changes to the kustomization files and added application set files for each of the component

@eisraeli Since I added kind ApplicationSet to the dependencies if I don't install ArgoCD in deploy-deps.sh it is failing.

As far as I understand, we're making changes to kustomization files that we use also when deploying the clsuter using CLI. Is that the intention?

Yes, made changes to the kustomization files and added application set files for each of the component

@gbenhaim @avi-biton should we be ok with all those ArgoCD-related resource deployed when users deploy their dev envs? Are we expecting ArgoCD to be used on dev envs?

@hmariset local/ci deployment on kind shouldn't be affected by this PR. The existing kustomization files shouldn't reference the ArgoCD applications. You should create a new directory for them. You can see how we did it in infra-deployments https://github.com/redhat-appstudio/infra-deployments/tree/main/argo-cd-apps

@hmariset you can drop the member directory out of the path of the argocd application sets. We don't have a concept of a member cluster in the community version.

@hmariset local/ci deployment on kind shouldn't be affected by this PR. The existing kustomization files shouldn't reference the ArgoCD applications. You should create a new directory for them. You can see how we did it in infra-deployments https://github.com/redhat-appstudio/infra-deployments/tree/main/argo-cd-apps

@gbenhaim I have created separate directory for these applications but for dependencies I haven't created separate one. Will add dependencies as well in these directory.

@hmariset can you please move the applications sets (only them) to https://github.com/konflux-ci/infra-deployments ?
I would like us to use it for deploying to EKS. It would also serve as an example for our users.

@gbenhaim @eisraeli Updated the code based on the comments. Please review again, tekton-results is still not working but since there is a bug opened for it, I want to close this PR if others is looking good and work it as part of that bug.

/retest

@hmariset I used your PR for creating the manifests in https://github.com/konflux-ci/infra-deployments
we can close this PR.

Closing this PR since we want this PR in https://github.com/konflux-ci/infra-deployments


Compute properties after init()?

In this commit: https://github.com/tillkruss/ruddarr/commit/c527ebfda1e0ecd7c06bbc35c2c40ce722a52b76
dateAdded is a computed property, but when sorted by 1000 movies it stalls the UI, so the property should be computed once after creating the instance.
I've tried to find good ways to do that but can't find anything that doesn't cause a lot of code repetition. didSet doesn't trigger, overriding init() is too verbose, lazy var is still slow.
Can you think of a good solution, like calling postInit() after decoding?

wow even better!


Initial commit

@vgumonis looks like I managed to push/mirror only selected files (because on my local repo I see those changes), Ill tackle this later and will let you know when its ready.

@vgumonis Feel free to review it again.

@vgumonis Sure, added!

@markkkkas neither mine https://test.pypi.org/project/coingate-client/ not yours https://test.pypi.org/project/coingate-client-test/ works with pip install

@vgumonis Yeah so looks like requests package is missing from test-pypi indexes. I think what you could try is to publish client to production pypi and then try to install it from there.


Error in install WAX

Can't install extensions because of "prerequisites that cannot be resolved"
VS2017

Which prerequisites?

@leoxoxo which prerequisites is it complaining about?

This is the message I get.  Do you know of a location i can find a log?  I have Wixtoolset 3.6, 3.11, and 4.0.  Is there something else that i am missing?  Thanks in advance.
Joe

There is only one prerequisite in the vsix manifest:
    <Prerequisites>
        <Prerequisite Id="Microsoft.VisualStudio.Component.CoreEditor" Version="[15.8.27729.1,17.0)" DisplayName="Visual Studio core editor" />
    </Prerequisites>

Maybe your VisualStudio is outdated?

@tom-englert Thank you for the suggestion to update VisualStudio.  That did the trick.


SAKIII-4152 - Change see all behavior on (sub)categories

https://jira.sakaiproject.org/browse/SAKIII-4152

Merged via squash


[docs]: Add README instructions for deployment in standalone mode

What change is proposed ?
Add stand alone mode deployment instructions in README.
How was the change tested ?
IDE markdown.
Link to issue ?
None

I haven't been able to figure out the cluster deployment mode yet. Will add teh cluster deployment instructions as soon as I figure that out.


ci: bump cli test process timeout

We had a 6 second timeout in interactWithShell that seems to be firing on windows test fairly often making them a bit flakey.  It also seems that when the timeout fires, we didn't kill the process which left it potentially running in the background and continuing to execute, holding up the jest process from completing.  This PR bumps the timeout from 6->10 seconds and calls proc.kill() when the timeout elapses

@brophdawg11 I think it would be good to also cherry-pick this onto dev

@kentcdodds @MichaelDeBoey I cherry-picked this into dev here to help with in-progress PRs: https://github.com/remix-run/remix/pull/3115


dhcp6c: Config not rewritten when interfaces added after the first.

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
Describe the bug
Can't add 2nd-nth tracking interface
To Reproduce
Steps to reproduce the behavior:
Have an existing WAN connection with PD
Have an existing LAN connection tracking WAN (prefix id 0)
add another interface (of any flavor)
set to IPv6 Track Wan / Prefix id 1
set it to allow modifying DHCPD/RA
Expected behavior
prefix-interface stanza added to /var/etc/dhcp6c_.conf
restart dhcp6c
Screenshots
If applicable, add screenshots to help explain your problem.
Relevant log files
If applicable, information from log files supporting your claim.
Additional context
Add any other context about the problem here.
Environment
Software version used and hardware type if relevant.
e.g.:
OPNsense 19.1.6 (amd64, OpenSSL).
Intel® i3-7100U Quad Core
Network Intel® 82583V

Anyone?

Nice spot, can you try this patch?
# opnsense-patch 88c5ffa

Cheers,
Franco

Deconfigure now works as expected too. There's still an older bug that I'd like to address before closing: checking wether the same prefix ID is already used.

@lrosenman Thanks for the report and sorry for the delay ❤

How can I get all the commits on a 19.1.x release/box/etc?

@lrosenman let's discuss here about schedule. I can't promise it for 19.1.7 but I can make a single-patch backport for on top of 19.1.6 if you want to test?

I'd love that and WILL test :)

Okay, great! It's 81ca8c9 for both tickets. Apply and subsequently remove by running the same command below:
# opnsense-patch 81ca8c9

PS: I don't always have time to respond quickly, but GitHub is indeed the best and quickest way do discuss issues, patches, solutions and release schedules. Closing tickets is just for recording issues as done in the roadmap item "19.7". Ping still works reliably afterwards :)

Deleting the interface should cause a rewrite as well, and does NOT at the moment with the above patch.

the rest looks great!

@lrosenman nice, thanks a lot. I have an idea about deletion. Will patch tomorrow and follow-up.

7ff838cac on top should do the trick:
# opnsense-patch 7ff838cac

I think I can shortcut these to 19.1.7 with the help of your testing. I just have to make sure my office setup likes this as well. Due to the Easter holidays couldn't deploy it there yet but will do it on Thursday.

Confirmed it now does the right thing here.  Thanks!

@lrosenman great, thanks for your help!


2023 data

Since the Belastingdienst published the tables and rates/values for 2023 I added 2023 data to data.json and added a new test file. Data was found at https://download.belastingdienst.nl/belastingdienst/docs/bijlage-nieuwsbrief-loonheffingen-2023-lh2091b31fd.pdf and https://download.belastingdienst.nl/belastingdienst/docs/bijlage-nieuwsbrief-loonheffingen-2023-lh2091b31fd.pdf.

@huge10 thank you for the contribution!
and for the text data extra 👏

@huge10 hm, there is an npm issue running tests:
npm ERR! Unexpected token < in JSON at position 66

unfortunately, I cannot reproduce it locally

I still see issues with the package-lock.json. I created a PR on @huge10 2023-data branch. I will close my PR since it's duplicated https://github.com/stevermeister/dutch-tax-income-calculator-npm/pull/28

now it's failing on this step:

@stevermeister according to https://github.com/5monkeys/cobertura-action it will not work with PRs created from forks. One alternative is to give @huge10 permission to create a PR on this repo or change the current workflow to make it work from forks.
This action will not currently work when triggered by pull requests from forks, like is common in open source projects. This is because the token for forked pull request workflows does not have write permissions on the target repository. Hopefully GitHub will have a solution for this in the future. In the meantime one can use utilize multiple workflows and artifacts to circumvent this. See the workflows in this project for an implementation example and this blog post https://securitylab.github.com/research/github-actions-preventing-pwn-requests.

@theoziran thank you for the clarification!
in this case, nothing stops us from merging it to the master :)

A new version of the package dutch-tax-income-calculator (23.1.1) was published

Thank you for your contribution! I'll update thetax.nl soon


Hue username and password

What's the Hue username and password? Thanks in advance!

It should be hue:hue

try hdfs:hdfs , based on the quickstart guide from Cloudera (also possible cloudera:cloudera , based on an intro video about the Cloudera VM)

No luck. I'm gonna give the official cloudera/quickstart docker image a try. Just released yesterday!
https://hub.docker.com/r/cloudera/quickstart/

admin:admin

For the first time you use the image you will define the admin username and password. Please login and define before.
Did it works with you?


add polygon area statistic to GUI

To follow on from #182 this functionality can now also be integrated into the main program:
Statistics

add an _area(mouse_positions: np.ndarray) -> float:  or similar function to stat.py

calculates the area from the mouse positions as is already done in the example notebook
for comparison here is a simple function that just calculates the distance: https://github.com/ssciwr/vstt/blob/c397a81f59041db8f3a93cb86820672a709e3106/src/vstt/stat.py#L259-L263

add tests of the above _area function to tests/test_stat.py

for comparison here are the tests for _distance: https://github.com/ssciwr/vstt/blob/c397a81f59041db8f3a93cb86820672a709e3106/tests/test_stat.py#L47-L65

add the calculated area data to the stats dataframe

https://github.com/ssciwr/vstt/blob/c397a81f59041db8f3a93cb86820672a709e3106/src/vstt/stat.py#L103

Visualization

add areas or similar to the display options (with default value False)

https://github.com/ssciwr/vstt/blob/c397a81f59041db8f3a93cb86820672a709e3106/src/vstt/display.py#L8

add the area to the displayed statistics texts

https://github.com/ssciwr/vstt/blob/c397a81f59041db8f3a93cb86820672a709e3106/src/vstt/vis.py#L145

display the filled area instead of just the paths in vis.py

suggestion: maybe we can just combine row.to_center_mouse_positions row.to_target_mouse_positions and add

fillColor=colors[row.target_index]
closeShape=True

https://github.com/ssciwr/vstt/blob/c397a81f59041db8f3a93cb86820672a709e3106/src/vstt/vis.py#L251-L277

resolved by #241


enter attribute error while using context managers in pyodbc connection

Please first make sure you have looked at:

Documentation: https://github.com/mkleehammer/pyodbc/wiki
Other issues

Environment
To diagnose, we usually need to know the following, including version numbers.  On Windows, be
sure to specify 32-bit Python or 64-bit:

Python:  3.7.2
pyodbc: 4.0.30
OS: Windows 10 64 bit
DB: MSSQL Local DB
driver: SQL Server Native Client 11.0

Issue
I am trying to extract a table using pyodbc package from Python with context managers.
it is a pretty simplecode, but eventhough I have coded the__enter__ method I am receiving enter Attribute error. does pyodbc support python context Managers?
Code:

import pyodbc

posts = {}

class DataBaseConnection:
    def __init__(self):
        self.connection = None

    def __enter__(self):
        self.connection = pyodbc.connect("""Driver={SQL Server Native Client 11.0};"
                      "Server=(LocalDB)\LocalDBDemo;"
                      "Database=pythondev;"
                      "Trusted_Connection=yes;""")
        return self.connection

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type or exc_tb or exc_tb:
            self.connection.close()
        self.connection.commit()
        self.connection.close()

with DataBaseConnection as connection:
    cursor = connection.cursor
    cursor.execute('SELECT * FROM tblpost')
    for row in cursor.fetchall():
        dtlist = list(row)
        posts[dtlist[0].strip()] = {'id': dtlist[0].strip(), 'title': dtlist[1], 'content': dtlist[2]}

print(posts)

C:\Users\Lenovo\PycharmProjects\import_project\venv\Scripts\python.exe C:/Users/Lenovo/PycharmProjects/dbcheck/app.py
Traceback (most recent call last):
  File "C:/Users/Lenovo/PycharmProjects/dbcheck/app.py", line 24, in <module>
    with DataBaseConnection as connection:
AttributeError: __enter__
Process finished with exit code 1

Often it is easiest to describe your issue as "expected behavior" and "observed behavior".

Hi @InsaneDhina , try: with DataBaseConnection() as connection: rather than with DataBaseConnection as connection:.
DataBaseConnection is the class itself, DataBaseConnection() is an instance of the class.

If this issue has been resolved, @InsaneDhina , do please help us out by closing it.  Many thanks!

Thankyou @keitherskine It has been resolved


help me

Good Morning
Motorola moto G9 power usb C cell phone
notebook vaio fe 14 usb 3.0
hello i would like an executable with commands that allow me to run the program lighter it doesn't consume cpu gpu anything like that but the delay and the video quality is horrible and i don't have the ability to change the scripts.

the video quality is horrible

https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#the-quality-is-low
i don't have the ability to change the scripts
https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#command-line-on-windows


Handle ErrDuplicateName errors from store.CreateContainer()

newBuilder(): When store.CreateContainer() returns a duplicate-name error for a name that we just made up, try again with a different made-up name.

This should fix part of https://github.com/containers/libpod/issues/1146#issuecomment-420428372.

Does this replace #1005?

Oof.  I hadn't realized, but it would.

Change LGTM and I think I like this approach better then #1005 for the container name.  @steveb WDYT?

LGTM
@rh-atomic-bot r+

This fixes #1004 for me, thanks


Flutter: Execution failed for task ':package_info:verifyReleaseResources'

On building debug and release APK, same issue.
Prevously i created signed apk with compileSdkVersion 28 successfully, so it is already set on 28.
I tried to solve it with: #42310 #27226 #47337 but no success.

java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: Android resource linking failed
[PATH]\flutter\mobile_client\build\package_info\intermediates\res\merged\release\values\values.xml:236: error: resource android:attr/fontVariationSettings not found.
[PATH]\flutter\mobile_client\build\package_info\intermediates\res\merged\release\values\values.xml:237: error: resource android:attr/ttcIndex not found.

error: failed linking references.

please upgrade to 1.0.3
i believe it's fixed by this commit


added support for format v2; new file Merkle.swift and some additiona…

Hi here's the item. Again a little rough.
Note some changes seem trivial, like optional types on the transaction fields, but decoding did not work without them so please test if you decide to remove them.

@jsoneaday I started reviewing this PR and things look good; generally just copying the logic the JS library uses.
I did some cleanup: https://github.com/lukereichold/arweave-swift/tree/add-formatv2
I asked on the Discord forums and clarified that we can safely drop support for v1 transactions, which should make things easier.  As some changes were made to Transaction.swift, TransactionTests.swift needs some unit tests added to ensure that both data and $ transfer transactions are working as intended. Once those get added (I will eventually get around to it, feel free to add) then we can safely merge these changes.

Sounds good. Thanks for update

From: Luke Reichold @.>
Sent: Monday, November 15, 2021 2:06:24 AM
To: lukereichold/arweave-swift @.>
Cc: jsoneaday @.>; Mention @.>
Subject: Re: [lukereichold/arweave-swift] added support for format v2; new file Merkle.swift and some additiona… (PR #7)
@jsoneadayhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjsoneaday&data=04|01||89dd337815014ccbbcaf08d9a8066fa7|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637725567858367328|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=l32OE7BjsYesV4XUWgzL8QrzCCvMQYPZySLfI5WIp8w%3D&reserved=0 I started reviewing this PR and things look good; generally just copying the logic the JS library uses.
I did some cleanup: https://github.com/lukereichold/arweave-swift/tree/add-formatv2https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flukereichold%2Farweave-swift%2Ftree%2Fadd-formatv2&data=04|01||89dd337815014ccbbcaf08d9a8066fa7|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637725567858367328|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=6XTaMwxJlXWAf%2BRdKLd8iYuUyul2ujvY%2B1rnTTAmzXc%3D&reserved=0
I asked on the Discord forums and clarified that we can safely drop support for v1 transactions, which should make things easier. As some changes were made to Transaction.swift, TransactionTests.swift needs some unit tests added to ensure that both data and $ transfer transactions are working as intended. Once those get added (I will eventually get around to it, feel free to add) then we can safely merge these changes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flukereichold%2Farweave-swift%2Fpull%2F7%23issuecomment-968594837&data=04|01||89dd337815014ccbbcaf08d9a8066fa7|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637725567858377285|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=4AO61%2BrwPWfXBMKXwW4OHgL3zmWS49Qit1EP9AV95fQ%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAALIC5ZUSWVBDRXK5XCFDMLUMCWPBANCNFSM5HWTIB5Q&data=04|01||89dd337815014ccbbcaf08d9a8066fa7|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637725567858377285|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=UbvTdNy5KUemfQ%2B8GTj8zpjMvvZDNeRECVEeETAsUYM%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||89dd337815014ccbbcaf08d9a8066fa7|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637725567858387240|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=5VV3KDBA8SzBm0W3POu0%2BdKfMwW03Xn3dD3dDoIBZto%3D&reserved=0 or Androidhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01||89dd337815014ccbbcaf08d9a8066fa7|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637725567858387240|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=H0mdiqzymybTW8cU43Om72cLpejTAggS7542nmZQgxE%3D&reserved=0.

Hello @lukereichold  any update on this PR? Seemed like you might be able to relatively easily merge it?


[BUG] hangs after logging in, stuck on "Writing password..."

Description
The script freezes after "Writing password..." and eventually crashes (probably from disconnection). Running with -v shows that the browser is either stuck on the "Stay signed in?" page or the ms rewards home page. The pages are fully functional, the script just doesn't do anything.
Your Environment

Version used: latest as of 1/24/2024
Environment name and version (e.g. Chrome ver): Version 121.0.6167.85 (Official Build) (arm64)
Operating System and version: macOS 14.2.1

I am having this issue as well


building image with existing WEATHER_API_KEY env var exposes secret in image layers

Images built from a development environment that already has the environment variable $WEATHER_API_KEY set will expose the API key. This was a pretty serious oversight on my part. Will edit this post with an explanation shortly.

On closer inspection, this isn't actually happening. I mistakenly ran docker inspect on the container instead of the image. All good! 😄


ImportError: No module named future.builtins

Expected Behavior
It doesn't crash.
Actual Behavior
It crashes.
Steps to Reproduce
Run dev on commit bbcaec20d206867e113ee0b3050a93ad35731a1a for extended period of time.
Other Information
OS: ubuntu 14.04 LTS
Git Commit: bbcaec20d206867e113ee0b3050a93ad35731a1a
Error:
    from pgoapi.pgoapi import PGoApi
  File "/root/dev/PokemonGo-Bot/src/pgoapi/pgoapi/pgoapi.py", line 33, in <module>
    from .utilities import f2i, h2f
  File "/root/dev/PokemonGo-Bot/src/pgoapi/pgoapi/utilities.py", line 35, in <module>
    from s2sphere import Cell, CellId, LatLng
  File "/usr/local/lib/python2.7/dist-packages/s2sphere/__init__.py", line 5, in <module>
    from .sphere import *
  File "/usr/local/lib/python2.7/dist-packages/s2sphere/sphere.py", line 2, in <module>
    from future.builtins import int
ImportError: No module named future.builtins

pip install -r requirements.txt
will fix this


Suggestion | Can we make enhancement in this Plugin which support Meta Audience Network Mediation Group

It will be great if this plugin support meta audience network ads. Most of the apps now using mediation group to show ads.

Yes, it's something I've done in the past for a client and I could add to the plugin.
I'll see if I can add it in one of the following releases

Yes, it's something I've done in the past for a client and I could add to the plugin. I'll see if I can add it in one of the following releases

Great. Thanks


Add support for command JSON.DEBUG

Add support for the JSON.DEBUG command in DiceDB similar to the JSON.DEBUG command in Redis. Please refer to the following commit in Redis to understand the implementation specifics - source.
Write unit and integration tests for the command referring to the tests written in the Redis codebase 7.2.5. For integration tests, you can refer to the tests folder. Note: they have used TCL for the test suite, and we need to port that to our way of writing integration tests using the relevant helper methods. Please refer to our tests directory.
For the command, benchmark the code and measure the time taken and memory allocs using benchmem and try to keep them to the bare minimum.

please assgin to me. thanks.

Hey, @arpitbbhayani, I want to take this up. Can you please assign it to me?

@utkarsh-1905 assigned, thanks for picking this up.
#492, #493 are linked with this, hence we can coordinate with assignees of those tickets.
cc: @psrvere


Add responsive-image macro to default radicati theme

There's a macro for responsive images that you wrote for some site, and we've reused it cause it's pretty neat. It would be good to add that macro to our default install, so it's available every time.
The file path is radicati/templates/macros/responsive-image.twig
macros.zip

We should also add
{% import "macros/responsive-image.twig" as ri %}
to the top of the base.twig file :)


Icon triggers error with tintColor

🐛 Bug Report

To Reproduce
Steps to reproduce the behavior:
Following code

triggers error

Its something related to tintColor
Expected behavior

Link to runnable example or repository (highly encouraged)

UI Kitten and Eva version

Package
Version

@eva-design/eva
2.1.1

@ui-kitten/components
5.1.2

Environment information

  System:
    OS: macOS 12.2
    CPU: (10) arm64 Apple M1 Pro
  Binaries:
    Node: 18.11.0 - /opt/homebrew/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.19.2 - /opt/homebrew/bin/npm
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
  IDEs:
    Android Studio: 2021.1 AI-211.7628.21.2111.8193401
    Xcode: 13.4/13F17a - /usr/bin/xcodebuild
  npmPackages:
    react: 18.2.0 => 18.2.0
    react-native: 0.70.5 => 0.70.5

Is there any update on this issue? I am also facing an issue due to tintColor.

I am also experiencing this issue right now.

Just got this too, started happening after upgrading from expo 46 to 47, downgrading react-native-svg to 13.2.0 fixed it for me, although expo says it's not compatible with current version.

Yes I can confirm. The crash started when I upgraded from expo 46 to 47 which updated react-native-svg from 12.3.0 to 13.4.0
I cannot use akveo icons inside components anymore. For example with accessoryLeft, accessoryRight etc.

Hi, any update on this? I am facing it as well on my side.

It is solved when upgrading "react-native-svg" to "13.6.0".
But another error appeared:
Invariant Violation: requireNativeComponent: "RNSVGSvgViewAndroid" was not found in the UIManager.

@lianmetrobi It works, thank you.
@duytuan001  You should implement the solution: https://github.com/akveo/react-native-ui-kitten/issues/1675#issuecomment-1328165387

@Ackerize you are making it sound as if this issue is solved. It's not solved, but it's a good temp solution until akveo updates ui-kitten with react-native-svg latest versions or whatever.

Just got this too, started happening after upgrading from expo 46 to 47, downgrading react-native-svg to 13.2.0 fixed it for me, although expo says it's not compatible with current version.

Thanks! that make it work perfectly!

I also got this error after upgrading expo SDK to 47

I'm afraid this is still an issue and with Expo 48 becomes even more complicated, as iOS won't build under EAS with react-native-svg @ 13.2.0.  Using 13.5.0+ will build, but won't help Expo Go.  So either Expo needs to update to 13.5.0+ or Kitten UI needs to be updated to work.

had the same problem updating to expo 48, applied this patch on react-native-svg 13.4.0 and it worked, it looks a bit hacky, but I got his code from the newer versions of react-native-svg
diff --git a/node_modules/react-native-svg/android/src/main/java/com/horcrux/svg/SvgView.java b/node_modules/react-native-svg/android/src/main/java/com/horcrux/svg/SvgView.java
index 523fcc1..ad3c476 100644
--- a/node_modules/react-native-svg/android/src/main/java/com/horcrux/svg/SvgView.java
+++ b/node_modules/react-native-svg/android/src/main/java/com/horcrux/svg/SvgView.java
@@ -186,7 +186,7 @@ public class SvgView extends ReactViewGroup implements ReactCompoundView, ReactC
   }

   public void setTintColor(Integer tintColor) {
-    mTintColor = tintColor;
+    mTintColor = tintColor != null ? tintColor : 0;
     invalidate();
     clearChildCache();
   }

I was also getting the same error. I was putting Text elements for accessories of the menu and buttons instead of Icon elements in some places (to show the number widget). I wrapped Text elements with <></> and the error is gone!

@ekokotov
Hi there!
Can I ask you to show me which icon pack you are using?
And also interested in styles property.
Regards, Vlad

@ekokotov
Hello there!
Due investigation i found that tintColor became null value on react-native-svg side
So there are two fixes for it right now:
Fix 1 (add  tag inside all UI Kitten icon tags):
<TopNavigationAction
    icon={(
        <View>    // <-- Crash fix
            <YourCustomIconWrapper
                 height={24}
                 width={24}
                 icon="chevronLeft"
             />
        </View>    // <-- Crash fix
    )}
/>

Fix 2 (setting the icon color prop to a value of a color):
<YourCustomIconSvgImport
    height={32}
    width={32}
    style={style}
    color="red" // <-- Crash fix
/>;

Thanks to adrihegg

After investigate it was found that this problem occurs only on one version of the SVG package, we have previously described how to solve this problem using it, further SVG package has returned all the necessary checks to prevent this crash for our components, you can use a fresh version and all should be fine!

Yes, version 13.5.0+ of the SVG lib will not error, but unfortunately Expo (and their Expo Go dev client) still hasn't been updated to that.  So the for now if people are developing using Expo and their Go client, they need to work around the error.  You could do build with the newer 13.5.0+ and ignore the Expo build warnings, but the Go client is sort of stuck currently.


Added environment option to change url in compose

I'd rather keep the current version since I'd otherwise have to change the Kubernetes files as well and I'd rather not risk breaking anything a day before the deadline.

Can You not test it and if it does not work that we go back a version?


⚠ Bofrost.be has degraded performance

In 14847c4, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1247 ms

Resolved: Bofrost.be performance has improved in 5728eaf.


WIP radiasoft/container-sirepo-devbox#7: Move common dependencies into container-sirepo-base installer

Both container-sirepo-devbox and container-sirepo-ci need some common dependencies so move them into an installer and call it.

Depends on https://github.com/radiasoft/download/pull/517


separated decryption tests

separated decryption tests from the encryption-decryption test and updated the decryption function with a more efficient function

note: the tests fail because the updated function is based on Yiwei's work that has not been merged to main


bug: Regression(?): tip rack calibration adjustments do not propagate forward

Overview
During the tip rack calibration flow, if you make an adjustment to one tip rack, that adjustment doesn't carry forward. The next tip rack will start from scratch.
This is a little scary, because making sure that the adjustments carry forward was specifically the fix for a big calibration bug.
Background
One offset per labware type
On the OT-2, all the instances of a given labware type share the same calibration offset. Although that might be problematic and confusing, that's a separate issue.
This issue is about how that's implemented with tip racks.
Issue #4288
There used to be a bug, #4288, that caused problems if you had lots of tip racks.
First: Adjustments made to tip racks earlier in the calibration flow wouldn't propagate to tip racks later in the calibration flow. So, if you had 5 tip racks that were each 1 mm too far right, you'd make that same 1 mm adjustment each time.
Second: The code that collapsed all the tip rack adjustments into one final offset assumed that the adjustments would be propagated.
Combined, this meant that the final offset would be the sum of all the tip rack adjustments you made. You'd end up with an offset of 5 mm instead of 1 mm, causing the pipette to try to pick tips up from entirely the wrong place.
The fix (#4322) was to make the adjustments propagate from one labware to the next. From the fix's test notes:

The differing calibration carried forward, and successive differing calibrations remained independent and propagated, rather than being summed.

Current behavior
We seem to have regressed on the fix, #4322. Adjustments made to earlier tip racks no longer apply to later tip racks.
But, we appear not to have regressed on the original issue, #4288. (I only tested quickly, on APIv2.2 and v3.16.1.)
Weird!
Steps to reproduce

Upload a protocol with lots of tip racks. I used an APIv2.2 protocol on robot software v3.16.1.
Make an obvious adjustment to the first tip rack.
Move on to the next tip rack. Observe that the default position is unaffected by the adjustment you made to the first tip rack.
Repeat for the remaining tip racks.
Run the protocol. Observe that no adjustments except the one made to the last tip rack had any effect.

Expected behavior
¯\_(ツ)_/¯
Valid solutions, from best to worst?

The calibration model is changed so that calibrating multiple tip racks actually does something.
The user is only guided through calibrating a single tip rack, so calibration isn't misleading and needlessly long.
During labware calibration, tip rack adjustments propagate from one tip rack to the next.
We convince ourselves that the current behavior (ignore adjustments for all tip racks but the last) is expected and that we didn't accidentally break anything, and we leave it be. Functionally, this is very slightly worse than option 3: with this option, if there's an error that causes the pipette to bump the tip rack, it will keep bumping it for each successive tip rack.

┆Issue is synchronized with this Wrike Task by Unito

I believe we might be having this problem? I've been recalibrating everything for hours and I'm out of ideas at this point.
I first thought it was a custom tiprack problem: we tried to used two different tipracks - the one at module 7 was going to be used by the p300 and m300. The one at module 8 was foinf to be used by the m300 only. During pre-protocol calibration, the p300 was calibrated with the tiprack at module 7 and the m300 used the one at module 8. But then during the protocol run, the m300 failed completely when picking from the tiprack at module 7.
So I re-measured everything from the custom tipracks and used a caliper, but I tried a script like this and the problem persisted:

    for pipette in [m300,p300]:
        ctx.comment("Now for pipette "+str(pipette))
        for w in ["A1", "A12"]:
            ctx.comment("Now for well "+w)
            pipette.pick_up_tip(tiprack_200_7[w])
            pipette.return_tip()
            pipette.pick_up_tip(tiprack_200_8[w])
            pipette.return_tip()
            pipette.pick_up_tip(tiprack_200_9[w])
            pipette.return_tip()

The pre-protocol calibration calibrates all tips racks with the p300, but then m300 has some offset and tries to pick too far right or left, to the point that the tiprack itself moves from the module. I thought it might be an offset problem (#7878).
Then I had the idea of trying my test script with standard tips... And it failed as well. Then, it really was that #7878 problem? I tried the fix mentioned at that thread, and it kind of works, but it only works for the standard or for the custom tipracks, not both, obviously. So it doesn't suit my needs.
I now believe it might be this other issue (#5473), because I changed my script like this:
    pipette=m300
    ctx.comment("Now for pipette "+str(pipette))
    for w in ["A1", "A12"]:
        ctx.comment("Now for well "+w)
        pipette.pick_up_tip(tiprack_200_7[w])
        pipette.return_tip()
        pipette.pick_up_tip(tiprack_200_8[w])
        pipette.return_tip()
        pipette.pick_up_tip(tiprack_200_9[w])
        pipette.return_tip()

    pipette=p300
    ctx.comment("Now for pipette "+str(pipette))
    for w in ["A1", "A12"]:
        ctx.comment("Now for well "+w)
        pipette.pick_up_tip(tiprack_200_7[w])
        pipette.return_tip()
        pipette.pick_up_tip(tiprack_200_8[w])
        pipette.return_tip()

so that the m300 would be calibrated with the tiprack at module 9... And this time the failure was even more catastrophic. The m300 couldn't even pick tips from the A12 well at module 7. All this using standard tips.
Any ideas to fix this?

@silvtal Thanks for bringing this to our attention. For your specific case, it would best to contact us at Opentrons Support so we can investigate this further.


Add a tutorial for working with algebraic operations

Please confirm that this PR has done the following:

[x] Tests Added
[x] Documentation Added
~Name of contributors Added to AUTHORS.rst~
[ ] Description in RELEASE_NOTES.md Added

Adding to RELEASE_NOTES.md (remove section after adding to RELEASE_NOTES.md)
Please add a single line in the release notes similar to the following:
- (#XX)[http://link-to-pr.com] Added feature which does something

Description of PR
This PR adds a tutorial for algebraic operations, which is rendered here.
Also, while writing the tutorial, I noticed that the ignore_units feature didn't quite sufficiently ignore units, so I added a fix.

Thanks @jkikstra, fixed!


godot and godot_console aliases don't work as expected

Linux
Running godot from the terminal just runs gdvm without the "run" parameter:

Windows
While godot/godot_console works as expected when executed in a terminal, running via Powertoys Run (or just double-clicking the symlink in the .gdvm bin folder) doesn't open Godot, presumably because of the same issue described above (just gdvm without "run" is called).
Off-topic, but I just want to add: great project you've started here :)

Thanks for the issue report (and kind words 😊), fixed in v0.2.2. Looks like I won't be able to use symlinks, have to copy the binary.
Run gdvm upgrade and you should be good to go. You may possibly need to run a non-godot gdvm command afterwards to let it replace the symlinks with copies. Running gdvm --version should work. Or, instead of running upgrade you could run the install command again from the site, that would work, too.


failed to wait for engine image rancher/longhorn-engine

I have a PSP enabled cluster, which I am trying to deploy Longhorn to, using the YAML file.
The engine daemonset refuses to create, and I see no errors point to why it's not working, which is frustrating.
All I've done to make it work with PSP, is to add rules allowing the service account to use a privileged psp.
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: longhorn-role
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - deployer
  verbs:
  - use
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - "*"
- apiGroups: [""]
  resources: ["pods", "events", "persistentvolumes", "persistentvolumeclaims", "nodes", "proxy/nodes", "pods/log", "secrets", "services", "endpoints", "configmaps"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "statefulsets", "deployments"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources: ["jobs", "cronjobs"]
  verbs: ["*"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "volumeattachments"]
  verbs: ["*"]
- apiGroups: ["csi.storage.k8s.io"]
  resources: ["csinodeinfos"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["longhorn.rancher.io"]
  resources: ["volumes", "engines", "replicas", "settings", "engineimages", "nodes"]
  verbs: ["*"]

The psp being used:
---
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: deployer
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities: ['*']
  volumes: ['*']
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

The logs vary from:
klf -n longhorn-system longhorn-manager-j4wft
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn replica controller"
time="2019-06-21T07:05:31Z" level=info msg="Start kubernetes controller"
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn Engine Image controller"
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn node controller"
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn volume controller"
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn websocket controller"
time="2019-06-21T07:05:31Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn engine controller"
time="2019-06-21T07:05:31Z" level=info msg="Start Longhorn Setting controller"
time="2019-06-21T07:05:31Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:05:31Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
E0621 07:05:31.332097       1 engine_image_controller.go:185] fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps "engine-image-ei-9bea8a9c" not found
time="2019-06-21T07:05:31Z" level=warning msg="Dropping Longhorn engine image longhorn-system/ei-9bea8a9c out of the queue: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:05:37Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:05:43Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:05:49Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:05:55Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:01Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:06:01Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
E0621 07:06:01.157403       1 engine_image_controller.go:185] fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps "engine-image-ei-9bea8a9c" not found
time="2019-06-21T07:06:01Z" level=warning msg="Dropping Longhorn engine image longhorn-system/ei-9bea8a9c out of the queue: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:06:01Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:07Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:13Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:19Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:25Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:31Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:06:31Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
E0621 07:06:31.155196       1 engine_image_controller.go:185] fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps "engine-image-ei-9bea8a9c" not found
time="2019-06-21T07:06:31Z" level=warning msg="Dropping Longhorn engine image longhorn-system/ei-9bea8a9c out of the queue: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:06:31Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:37Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:43Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:49Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:06:55Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:01Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:07:01Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
E0621 07:07:01.156313       1 engine_image_controller.go:185] fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps "engine-image-ei-9bea8a9c" not found
time="2019-06-21T07:07:01Z" level=warning msg="Dropping Longhorn engine image longhorn-system/ei-9bea8a9c out of the queue: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:07:01Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:07Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:13Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:19Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:19Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"vm014182\", UID:\"abffe63d-9351-11e9-a4ec-005056980e68\", APIVersion:\"longhorn.rancher.io/v1alpha1\", ResourceVersion:\"729114\", FieldPath:\"\"}): type: 'Warning' reason: 'ManagerPodDown' Node vm014182 is down: the manager pod longhorn-manager-5v9vc is not running"
time="2019-06-21T07:07:24Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"vm014173\", UID:\"ac2c3515-9351-11e9-ba82-005056982ed0\", APIVersion:\"longhorn.rancher.io/v1alpha1\", ResourceVersion:\"729098\", FieldPath:\"\"}): type: 'Warning' reason: 'ManagerPodDown' Node vm014173 is down: the manager pod longhorn-manager-54rkt is not running"
time="2019-06-21T07:07:25Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:31Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:07:31Z" level=warning msg="Error syncing Longhorn engine image longhorn-system/ei-9bea8a9c: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
E0621 07:07:31.153547       1 engine_image_controller.go:185] fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps "engine-image-ei-9bea8a9c" not found
time="2019-06-21T07:07:31Z" level=warning msg="Dropping Longhorn engine image longhorn-system/ei-9bea8a9c out of the queue: fail to sync engine image for longhorn-system/ei-9bea8a9c: cannot cleanup daemonset of engine image ei-9bea8a9c: daemonsets.apps \"engine-image-ei-9bea8a9c\" not found"
time="2019-06-21T07:07:31Z" level=fatal msg="Error starting manager: failed to wait for engine image rancher/longhorn-engine:v0.5.0: Wait for engine image rancher/longhorn-engine:v0.5.0 timed out"

klf -n longhorn-system longhorn-manager-54rkt
time="2019-06-21T07:07:49Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:49Z" level=info msg="Start kubernetes controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn replica controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn engine controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn websocket controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn Setting controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn node controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn volume controller"
time="2019-06-21T07:07:49Z" level=info msg="Start Longhorn Engine Image controller"
time="2019-06-21T07:07:50Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"vm014173\", UID:\"ac2c3515-9351-11e9-ba82-005056982ed0\", APIVersion:\"longhorn.rancher.io/v1alpha1\", ResourceVersion:\"729338\", FieldPath:\"\"}): type: 'Normal' reason: 'Ready' Node vm014173 is ready"
time="2019-06-21T07:07:50Z" level=debug msg="Requeue longhorn-system/vm014173 due to conflict"
time="2019-06-21T07:07:55Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:07:59Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"vm014175\", UID:\"aa302037-9351-11e9-a4ec-005056980e68\", APIVersion:\"longhorn.rancher.io/v1alpha1\", ResourceVersion:\"729323\", FieldPath:\"\"}): type: 'Normal' reason: 'Ready' Node vm014175 is ready"
time="2019-06-21T07:08:01Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:07Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:13Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:19Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:25Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:31Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:37Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:43Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:49Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:08:55Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:01Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:07Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:13Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:19Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:25Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:31Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:37Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:43Z" level=debug msg="Waiting for engine image rancher/longhorn-engine:v0.5.0 to be ready"
time="2019-06-21T07:09:48Z" level=info msg="Event(v1.ObjectReference{Kind:\"Node\", Namespace:\"longhorn-system\", Name:\"vm014182\", UID:\"abffe63d-9351-11e9-a4ec-005056980e68\", APIVersion:\"longhorn.rancher.io/v1alpha1\", ResourceVersion:\"729487\", FieldPath:\"\"}): type: 'Warning' reason: 'ManagerPodDown' Node vm014182 is down: the manager pod longhorn-manager-5v9vc is not running"
time="2019-06-21T07:09:49Z" level=fatal msg="Error starting manager: failed to wait for engine image rancher/longhorn-engine:v0.5.0: Wait for engine image rancher/longhorn-engine:v0.5.0 timed out"

Where should I be looking to fix these issues?  Why would adding PSP create such problems?

It looks like the engine-image daemonset, created by the manager, isn't inheriting the roles set.  So get's blocked from spawning?
k describe daemonset -n longhorn-system engine-image-ei-9bea8a9c
Name:           engine-image-ei-9bea8a9c
Selector:       longhorn=engine-image
Node-Selector:  <none>
Labels:         longhorn=engine-image
Annotations:    deprecated.daemonset.template.generation: 1
Desired Number of Nodes Scheduled: 0
Current Number of Nodes Scheduled: 0
Number of Nodes Scheduled with Up-to-date Pods: 0
Number of Nodes Scheduled with Available Pods: 0
Number of Nodes Misscheduled: 0
Pods Status:  0 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  longhorn=engine-image
  Containers:
   engine-image-ei-9bea8a9c:
    Image:      rancher/longhorn-engine:v0.5.0
    Port:       <none>
    Host Port:  <none>
    Command:
      /bin/bash
    Args:
      -c
      cp /usr/local/bin/longhorn* /data/ && echo installed && trap 'rm /data/longhorn* && echo cleaned up' EXIT && sleep infinity
    Readiness:    exec [ls /data/longhorn] delay=5s timeout=1s period=5s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /data/ from data (rw)
  Volumes:
   data:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/longhorn/engine-binaries/rancher-longhorn-engine-v0.5.0
    HostPathType:
Events:
  Type     Reason        Age                 From                  Message
  ----     ------        ----                ----                  -------
  Warning  FailedCreate  13s (x15 over 95s)  daemonset-controller  Error creating: pods "engine-image-ei-9bea8a9c-" is forbidden: unable to validate against any pod security policy: [spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used]

Adding:
serviceAccount: longhorn-service-account
serviceAccountName: longhorn-service-account

to the daemonset.apps/engine-image-ei-9bea8a9c manually, has made them spawn.  Bad times, as this is generated by the manager...

This is the least privileged PSP required to run Longhorn, if anyone else is wanting to do this:
kind: PodSecurityPolicy
metadata:
  name: psp-longhorn-system
spec:
  allowedCapabilities:
  - SYS_ADMIN
  allowedHostPaths:
  - pathPrefix: /var/run/
    readOnly: false
  - pathPrefix: /lib/modules
    readOnly: false
  - pathPrefix: /var/lib/kubelet/plugins
    readOnly: false
  - pathPrefix: /var/lib/rancher/longhorn/
    readOnly: false
  - pathPrefix: /dev/
    readOnly: false
  - pathPrefix: /var/lib/kubelet/plugins/io.rancher.longhorn
    readOnly: false
  - pathPrefix: /var/lib/kubelet/pods
    readOnly: false
  - pathPrefix: /dev
    readOnly: false
  - pathPrefix: /sys
    readOnly: false
  - pathPrefix: /proc/
    readOnly: false
  fsGroup:
    rule: RunAsAny
  privileged: true
  hostPID: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - hostPath
  - secret

This still requires a manual edit to the engine-image daemonset to make work under PSP/RBAC security, however.

@ChrisScottThomas Thanks for reporting this issue with Pod Security Policy. We haven't looked into the PSP yet so that's why you've encountered some problems.
Regarding why Longhorn needs those directories, many of them Longhorn indeed needs. A few I can explain without further looking up into the code:

/var/lib/kubelet/plugins: Kubernetes requires it for CSI driver
/var/lib/kubelet/plugins/io.rancher.longhorn: Same as above
/var/lib/kubelet/pods: Same as above
/dev: Longhorn provides block devices, need to access to the /dev for that
/proc: Need to access host namespace for iscsiadm
/var/lib/rancher/longhorn/: default working directory for Longhorn. Also used as the default directory for store data.

A few of them is due to legacy issues and we will double check if they're really needed.

No worries :)  In regards to the directory access, IMO it'd be better if they aren't mounted as read/write if they only need to read.  It'd enable a bit more tightening on the PSP and turn some of those readOnly: false to true.  If you set any to true, you block the deployment as the volumes are being mounted as rw be default.
Mounts:
      /host/dev/ from dev (rw)
      /host/proc/ from proc (rw)
      /var/lib/rancher/longhorn/ from longhorn (rw)
      /var/run/ from varrun (rw)

which earns you a bunch of these:
Warning  FailedCreate  7s (x12 over 17s)  daemonset-controller  Error creating: pods "longhorn-manager-" is forbidden: unable to validate against any pod security policy: [spec.containers[0].volumeMounts[0].readOnly: Invalid value: false: must be read-only spec.containers[0].volumeMounts[1].readOnly

More pressing concern is the need to manually add the serverAccount/serviceAccountName to the engine-image daemonset, in order to get it to deploy.

@ChrisScottThomas Thanks for understanding. We will look into the daemonset permission issue. Let's keep this issue open to track the daemonset issue.

I stumbled across a potential fix here, which is to add the service account to the longhorn-manager init container.
      initContainers:
        - name: wait-longhorn-manager
          image: rancher/longhorn-manager:v0.5.0
          command: ['sh', '-c', 'while [ $(curl -m 1 -s -o /dev/null -w "%{http_code}" http://longhorn-backend:9500/v1) != "200" ]; do echo waiting; sleep 2; done']
      serviceAccountName: longhorn-service-account

Everything started up first time.

@ChrisScottThomas You meant, add init container for longhorn-manager fixes the permission issue for the engine daemonset deployment?

@yasker - no, this init container exists in the yamls.
https://github.com/longhorn/longhorn/blob/d02316da0d6f0dec07e781edf2cb23aa5d8464fe/deploy/longhorn.yaml#L309

Validation: PASSED
Steps to test:   Thanks to @shuo-wu

Deploy a cluster with Pod Security Policy (psp) enabled. (In Rancher UI, enable psp. choose restricted psp as default psp).
In the cluster, delete the default psp. kubectl get psp should return restricted psp only.
Verify PSP works: directly deploying Longhorn, no components can be installed
Add pod security policy

---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: longhorn-pod-security-policy
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
    - '*'
  volumes:
    - '*'
  hostNetwork: true
  hostPorts:
    - min: 0
      max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

Modify the service account to use pod security policy

apiVersion: v1
kind: ServiceAccount
metadata:
  name: longhorn-service-account
  namespace: longhorn-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: longhorn-role
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
    - longhorn-pod-security-policy
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - "*"
- apiGroups: [""]
  resources: ["pods", "events", "persistentvolumes", "persistentvolumeclaims", "nodes", "proxy/nodes", "pods/log", "secrets", "services", "endpoints", "configmaps"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["daemonsets", "statefulsets", "deployments"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources: ["jobs", "cronjobs"]
  verbs: ["*"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses", "volumeattachments"]
  verbs: ["*"]
- apiGroups: ["csi.storage.k8s.io"]
  resources: ["csinodeinfos"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["longhorn.rancher.io"]
  resources: ["volumes", "engines", "replicas", "settings", "engineimages", "nodes", "instancemanagers"]
  verbs: ["*"]

Deploy Longhorn

Expected Result: Longhorn components should be working fine.

Verified on master.


For EventLog logging the default source is ".NET Runtime" and not "Application"

Describe the bug
For EventLog logging the default source is ".NET Runtime" and not "Application". In the documentations it's writtern Application but the actual is .NET Runtime
To Reproduce
Steps to reproduce the behavior:

Add loggingBuilder.AddEventLog(); to the logging configuration
Start log using any level like _logger.LogCritical(ex,...
Check the Event Views and you will find it logged under .NET Runtime Source

That's by design. We need to update the docs (this changed in 3.0)

Fixed in #2400