text:
[WIP] Create normal bin/update and sledgehammer bin/reset

Purpose or Intent
I find that bin/update is super slow.  It's a sledge 🔨  that doesn't handle the majority of situations: a single dependency or table is changed, it just blows everything away.
Currently, bin/update handles two use cases:

developer does git pull or checks out a slightly older branch, some dependency is out of date and/or a table has been changed
developer is getting errors, is lost, desperate, willing to try anything.... and just wants to reset all the things

The problem is that both of these cases are currently solved using the sledge :hammer: approach of our current bin/update.
Solution
First, review commit by commit since there's a rename that github is presenting as changes.
Create two files, one for each scenario:

bin/update for the first case (the situations that occurs the most often)
bin/reset for the second case (the sledge :hammer:)

Note, I'm totally open to different filenames.  Naming is hard.
By conservatively installing dependencies with bundler and migrating the test db (not resetting it), we save nearly 45 seconds.  Note, the default bin/update from rails doesn't even migrate the test db.

New bin/update now takes around 52 seconds (no updates needed)
New bin/reset (former bin/update), takes around 97 seconds

If we figure out how to do conservative installs as needed with bower, this bin/update time can be even faster cc @himdel.
Is this crazy?

cc @jvlcek I just noticed the latest rails bin/update has their own version of the "exit status" checking you added in 855c60b99708708effcf8a37c4feba01d07182db, we should probably remove ours and use theirs at some point

@jrafanie I for one like this.  👏

Loving this :+1: :)

If we figure out how to do conservative installs as needed with bower, this bin/update time can be even faster cc @himdel.

I think bower mostly does that already (as in, the sledgehammer approach would be to rm -rf vendor/assets/bower_components before), but nothing else we do in that script actually depends on bower having finished.
So maybe we can speed up bower just by running it first, in parallel, and wait(2)ing at the end..

I feel like we will get out of sync between devs and travis
@NickLaMuro

I know it is a slippery slope, but do we want to extract a common class with 3 methods that are called by the various scripts?
I do that with all my cli tools.
OR pass a --reset or --hard flag into the script

Ok, I found some speedups to do first based on some findings here.  I'll continue here if it's needed after I get them done.

I'm feeling like an extra flag may be the right course of action
(please use a simple string compare on ARG[0] or build in ruby options and not requiring an external gem.

@kbrock my problem is the default bin/update is very conservative:
https://github.com/rails/rails/blob/cf5f55cd30aef0f90300c7c8f333060fe258cd8a/railties/lib/rails/generators/rails/app/templates/bin/update#L17-L21
  system! 'gem install bundler --conservative'
  system('bundle check') || system!('bundle install')

  puts "\n== Updating database =="
  system! 'bin/rails db:migrate'`

It installs/updates bundler conservatively.  It only bundles if dependencies are changed and even then, it doesn't unlock the lockfile.
It then just migrates the database.
Ours is very different.
  execute "bundle update"
  execute "bower update --allow-root -F --config.analytics=false"

  puts "\n== Migrating database =="
  execute "bin/rake db:migrate"

  puts "\n== Seeding database =="
  execute "bin/rake db:seed GOOD_MIGRATIONS=skip"

  puts "\n== Resetting tests =="
  execute "bin/rake test:vmdb:setup"

  unless ENV["SKIP_AUTOMATE_RESET"]
    puts "\n== Resetting Automate Domains =="
    execute "bin/rake evm:automate:reset"
  end

We blindly update ruby dependencies.  We re-seed the db, we reset the test db, we reset the automation domain.
Well, I'll mark this was wip for now as I have other changes in flight to get in first.  Then we'll see.
Either way, our current bin/update is doubling as a "Something is broken, fix all the things" script and also "I need to install a single dependency"...

@jrafanie I like the idea of reset and update
I just thought we could do some of that with conditional logic in a single script vs 2 different scripts that need to be kept in sync. well, mostly kept in sync :(
Y U close?

authors: NickLaMuro himdel jrafanie kbrock


text:
Add chargeback rates factories with custom parameters

:chargeback_rate factory girl with possibility pass parameters for ChargebackRateDetail and ChargebackRateTier
using this factory

example:
FactoryGirl.create(:chargeback_rate, :with_custom_compute_details,
  :detail_params =>
    :chargeback_rate_detail_cpu_used  =>
       {
         :tiers => [
            	     {:variable_rate => 10, :fixed_rate => 10, :start=> 0, :finish=> 50},
                     {:fixed_rate => 10, :start=> 50, :finish=> Float::Infinity}
                   ],
        :detail => {:source => 'compute_1'}
       }
)

@miq-bot add_label test, refactoring, chargeback
@miq-bot assign @chrisarcand

source: gharchive/pull-request

repo: ManageIQ/manageiq

license_type: permissive

license_source: github-api


text:
Chargeback: Skip calculation when there is zero consumed hours

Consumed_hours_in_interval are used for calculating average metrics. When you divide by zero you get Infinity as a result. The report formater breaks when it gets Infinity.
    WARN -- : <AuditFailure> MIQ(Async.rescue in _async_generate_table) userid: [admin] - Infinity
    ERROR -- : MIQ(MiqQueue#deliver) Message id: [6427], Error: [Infinity]
    ERROR -- : [FloatDomainError]: Infinity  Method:[rescue in deliver]
    ERROR -- : activesupport-5.0.0.1/lib/active_support/number_helper/number_to_human_size_converter.rb:53:in `to_i'

This is a corner case. It can happen only few hours after you add provider with C&U. Then it is possible some metric rollup exists in the interval, while the full consumed hours is zero.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1416626
@miq-bot add_label chargeback, bug, euwe/yes, blocker
@miq-bot assign @gtanzillo

Euwe backport details:
$ git log -1
commit 64ebc5c2e0b07691caddb073d1a0d51f4941763c
Author: Gregg Tanzillo <gtanzill@redhat.com>
Date:   Fri Feb 3 12:08:44 2017 -0500

    Merge pull request #13723 from isimluk/rhbz#1416626

    Chargeback: Skip calculation when there is zero consumed hours
    (cherry picked from commit bf42c47c4efa898230c0c355fdd61ad638fb6c47)

    https://bugzilla.redhat.com/show_bug.cgi?id=1419186

authors: isimluk simaishi


text:
Fix for physical server alert bug

When deleting a physical infra provider, the delete may appear to be successful due to a message saying that the delete was successfully initiated; however, the delete actually fails with the following error in evm.log:
[----] E, [2018-08-09T16:16:47.588619 #9030:2ac60f3b5114] ERROR -- : MIQ(MiqQueue#deliver) Message id: [248], Error: [Could not find the inverse association for miq_alert_statuses (:physical_servers in MiqAlertStatus)]
[----] E, [2018-08-09T16:16:47.588971 #9030:2ac60f3b5114] ERROR -- : [ActiveRecord::InverseOfAssociationNotFoundError]: Could not find the inverse association for miq_alert_statuses (:physical_servers in MiqAlertStatus)  Method:[block (2 levels) in <class:LogProxy>]
[----] E, [2018-08-09T16:16:47.589098 #9030:2ac60f3b5114] ERROR -- : /usr/local/share/gems/gems/activerecord-5.0.7/lib/active_record/reflection.rb:202:in `check_validity_of_inverse!'

This PR fixes the bug by correcting the inverse_of specified in the PhysicalServer model's miq_alert_statuses relationship.

@miq-bot add_label bug

Thanks @skovic, FTR introduced by https://github.com/ManageIQ/manageiq/pull/17728

authors: agrare skovic


text:
Generate retire requests from the base class name

ServiceAnsiblePlaybook.demodulize + "RetireRequest" => bad cause we try and constantize that n there is no SAPRR; we should be using only the base class name for make_retire_request
Also, it's passing specs and got BZ opener approval here: https://bugzilla.redhat.com/show_bug.cgi?id=1731559#c6
Depends on https://github.com/ManageIQ/manageiq/pull/19064
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1731559
@miq-bot add_label bug, hammer/yes, ivanchuk/yes
@miq-bot add_reviewer @tinaafitz
@miq-bot add_reviewer @lfu

@miq-bot add_label retirement
you know it's bad when it has its own label 😆

Hammer backport details:
$ git log -1
commit 97c8ac39f4a650d268dbd541c4a99ca20a7234cf
Author: Brandon Dunne <bdunne@redhat.com>
Date:   Tue Oct 15 16:56:53 2019 -0400

    Merge pull request #19398 from d-m-u/fixing_retire_request_class_name_constantize

    Generate retire requests from the base class name

    (cherry picked from commit b7c9523e41be7406c2bde8554424d5caf0017ca7)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1762428

Reverted the PR:
commit 497912ef441ece34ed65b7d69789026e0a6a349e
Author: Satoe Imaishi <simaishi@redhat.com>
Date:   Mon Oct 21 13:45:44 2019 -0400

    Revert "Merge pull request #19398 from d-m-u/fixing_retire_request_class_name_constantize"

    This reverts commit 97c8ac39f4a650d268dbd541c4a99ca20a7234cf.

    https://bugzilla.redhat.com/show_bug.cgi?id=1762428

due to Travis error:
     NameError:
       uninitialized constant VmOrTemplateRetireRequest

Because it depended on https://github.com/ManageIQ/manageiq/pull/19064 which isn't backported.

Ivanchuk backport details:
$ git log -1
commit 79e64b756e284f49eb84ec99cd5c65e65212d7ab
Author: Brandon Dunne <bdunne@redhat.com>
Date:   Tue Oct 15 16:56:53 2019 -0400

    Merge pull request #19398 from d-m-u/fixing_retire_request_class_name_constantize

    Generate retire requests from the base class name

    (cherry picked from commit b7c9523e41be7406c2bde8554424d5caf0017ca7)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1784486

Hammer backport details:
$ git log -1
commit 19828a9617bbe2f6c8b1ba03690e85179dd2f71b
Author: Brandon Dunne <bdunne@redhat.com>
Date:   Tue Oct 15 16:56:53 2019 -0400

    Merge pull request #19398 from d-m-u/fixing_retire_request_class_name_constantize

    Generate retire requests from the base class name

    (cherry picked from commit b7c9523e41be7406c2bde8554424d5caf0017ca7)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1762428

authors: d-m-u simaishi


text:
[WIP]toolbar icon update

replace toolbar images with font icons
add new custom font icons to "product" font:

product-compare
product-compare_same
product-compare_diff
product-compare_all
product-clone
product-migrate
product-monitoring
product-timeline
product-drift

@miq-bot add_label ui, enhancement, wip

@miq-bot remove_label wip


text:
Adds ids to progress cards and labels for automation purposes

fixes #415

cc @Yadnyawalkya
card ids follow the pattern migrationName-progress-card and the progress labels are as requested, size-migrated and vms-migrated

Per https://github.com/ManageIQ/manageiq-v2v/issues/415#issuecomment-419390513, we need this for 5.9 hence marking it g/yes

authors: AllenBW AparnaKarve


text:
React tree higlights node when it is dirty

Added a modified store to the react tree wrapper which supports the highlighting of the nodes with changed (dirty) checkboxes. The highlight colour is #39A5DC.
Before

After

Fixes https://github.com/ManageIQ/manageiq-ui-classic/issues/6011
@skateman
@karelhala
@Hyperkid123

@miq-bot add_reviewer @Hyperkid123
@miq-bot add_reviewer @karelhala

Can you do the same for the redux tree as well? Or is it included in this already?

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: brumik karelhala skateman

repo: ManageIQ/react-ui-components


text:
scene.wait_upto

Description of proposed feature
This feature will allow you to wait until the scene has run for a specific duration.
Lots of people overlay audio onto their videos and this will make it easier to sync audio and animation.
How can the new feature be used?
# play animations
self.wait_upto(60)
# scene has run for 1 minute

# play more animations
self.wait_upto(90)
# another 30 seconds have passed

Additional comments
I've been using it in my own projects and would be happy to implement it and submit a PR when if that's fine.
I just want to get a go-ahead and any comments about things I might not have thought of.

I find this an interesting idea but where is the benefit over just using your editing software to extend the animations?
And there is also a wait until function. That might be able to do something similar if I'm not completely mistaken.

I find this an interesting idea but where is the benefit over just using your editing software to extend the animations?
And there is also a wait until function. That might be able to do something similar if I'm not completely mistaken.

One of the benefits of this is that you can compile with ffmpeg for example, rather than using additional software that you have to pay for or has a watermark, etc. It also means you don't have to keep track of the runtimes of each individual animation as it runs.
The wait_until function is just a wrapper for the wait function and would not offer the same functionality:
  stop_condition
      A function without positional arguments that evaluates to a boolean.
      The function is evaluated after every new frame has been rendered.
      Playing the animation only stops after the return value is truthy.

Since the PR #3997 introduced a time property for Scene, this feature would be easier to implement in a PR.
I like the idea, but the name doesn't really convince me. Personally, I would like Scene.wait_until() to be renamed to Scene.wait_until_condition() before implementing this change, and I would call this Scene.wait_until_time().
In the meantime, another option, since Scene.time is now implemented, is to call self.wait_until(lambda: self.time >= 60), although it is verbose.

What about making it keyword-only?:
.wait_until(time=90) # valid
.wait_until(90) # invalid

What about making it keyword-only?

It could be an interesting idea, although it would require a complete rewriting on how .wait_until() works.
I'd like to read other people's opinions!

source: gharchive/issue

authors: George-Ogden MrDiver chopan050

repo: ManimCommunity/manim

license: MIT


text:
feat(schemas):  added schemas routes

closes #11
closes #10
closes #9
closes #8

Other from the scope of this PR, some comments on openapi3.yaml:

Endpoint /schemas/{name}/map seems unnatural on post method because name resource does not exist, would add name in request body and use endpoint /schemas.
Reuse schema ($ref: '#/components/schemas/schema') in post method's requestBody.
You will probably will need to mark created_at and updated_at as readonly properties.
Better define your schema-object, property like mapping is loosely defined
Please add more descriptions on schema properties
Remove extra space in info.description

repo: MapColonies/external-to-osm-tag-mapping


text:
Pull Request: Add Optional Username and Password Fields for OpenVPN Authentication

Description:
This PR introduces the ability to optionally provide username and password for OpenVPN connections that require user authentication. If these fields are not provided, OpenVPN will still run without the --auth-user-pass option, ensuring compatibility with configurations that do not require user credentials.
Changes:

config.json Updates:

Added username and password fields to the configuration schema, allowing users to optionally input their VPN credentials via the Home Assistant UI.

"options": {
    "ovpnfile": "client.ovpn",
    "username": "",
    "password": ""
},
"schema": {
    "ovpnfile": "str",
    "username": "str",
    "password": "str"
}

run.sh Updates:

Modified the run.sh script to:

Check if the username and password are provided.
Create an auth.txt file containing the credentials only if both username and password are provided.
Add the --auth-user-pass option to the OpenVPN command when credentials are provided.
Run OpenVPN without the --auth-user-pass option if credentials are not supplied, allowing it to function with configurations that don’t require authentication.

if [[ -n "$USERNAME" ]] && [[ -n "$PASSWORD" ]]; then
    echo "$USERNAME" > $AUTH_FILE
    echo "$PASSWORD" >> $AUTH_FILE
    AUTH_OPTION="--auth-user-pass $AUTH_FILE"
else
    AUTH_OPTION=""
fi

openvpn --config ${OPENVPN_CONFIG} $AUTH_OPTION

Impact:

These changes provide flexibility to users who either have VPN configurations that require authentication via username and password or those who do not.
If the username and password fields are left blank, OpenVPN will proceed without the need for credentials.

I am going to look through this. I like your thing with the auth.txt. I am going to try to make that more secure before I push this!


text:
Does Mapster work with Ardalis SmarteEnums?

I see some discussion on #463, but there was no definitive answer. I defined a TypeAdapterConfig, but the below never gets called:
`
public class TypeContext : SmartEnum
{
public static readonly TypeContext None = new("Undefined", -1);
public static readonly TypeContext Device_DeviceType = new("Device.Type", 1);
public static readonly TypeContext Device_StateType = new ("Device.State", 2);
public static readonly TypeContext Site_SiteType = new ("Site.Type", 3);
public static readonly TypeContext Site_State = new ("Site.State", 4);
public static readonly TypeContext Telemetry_State = new ("Telemetry.State", 6);
public static readonly TypeContext Telemetry_DataType = new ("Telemetry.DataType", 7);
public static readonly TypeContext TelemetryNumericData_State = new ("TelemetryNumericData.State", 8);
public static readonly TypeContext TelemetryTextData_State = new ("TelemetryTextData.State", 9);
public static readonly TypeContext IngestLog_SeverityType = new("IngestLog.SeverityType", 10);
protected TypeContext(string name, int value) : base(name, value) { }

}
`
Then I add the TypeAdapterConfig before calling "Adapt":
TypeAdapterConfig<string, TypeContext>.NewConfig()     .Map(d => d, s => TypeContext.FromName(s, true));
The TypeAdapterConfig is not called.

The following MapWith works:
TypeAdapterConfig<string, TypeContext>.NewConfig().MapWith(d => TypeContext.FromName(d, true));

authors: jeffreymonroe stagep

repo: MapsterMapper/Mapster


text:
RandomPointsBuilder.CreateRandomCoord

I need help trying to replicate code found In Demo 2 MapInfo
I have the following error:
Error	CS0117	'RandomPointsBuilder' does not contain a definition for 'CreateProviderWithRandomPoints'

in method
private static ILayer CreateInfoLayer(MRect? envelope)
{
    var random = new Random(7);

    return new Layer(InfoLayerName)
    {
        DataSource = RandomPointsBuilder.CreateProviderWithRandomPoints(envelope, 25, random),
        Style = CreateSymbolStyle(),
        IsMapInfoLayer = true
    };
}

RandomPointsBuilder.CreateProviderWithRandomPoints is one of the helper methods we use in our samples. You could create something like that yourself or you could copy that class from the Mapsui.Samples.Common project.
Or ask ChatGPT to do it https://chat.openai.com/share/ffeabc47-869a-4eae-b7a3-bc0d7edef751

repo: Mapsui/Mapsui


text:
ci: test

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews
See the guideline for information on the review process.
A summary of reviews will appear here.

$2,830.000

How can I take my money back?

Request ID code: 68x11sz0td8kgg3
Session ID code: 59882ea7-3f46-4d92-9a9b -7d03798ec012
Institution ID code: inc_127991

authors: DrahtBot SombatOeur

repo: MarcoFalke/b-c-with-ci


text:
fix: fallback to http 1.1 when http2 is not supported on fetching sparse metadata

FIX #1668

thanks!

authors: MarcoIeni davidB

repo: MarcoIeni/release-plz


text:
Cache or RateLimit Futbin requests

If I scroll through a few pages of players in my club the futbin prices stop showing up.
I'm not seeing the requests in the network inspector but I believe futbin may be rate limiting it.
Maybe the script show also do a rate limit and/or have a local cache of prices (e.g. for 1h)

You won't see the network requests because they are sent through Tampermonkey, this prevents CORS failures. I haven't seen any rate limiting by Futbin as of yet. Probably the script is not picking up on the page changes correctly.
However I don't have multiple pages of players in my club so I can't test this.


text:
Stable release version requested

To use Toolchain with FetchContent we need a taged version

I'm happy to make a release, but I don't think it would be 'stable' per se. There's still cleanup and file movement that needs to happen to address the feedback in #18. And I've been wanting to rename the repo from 'Toolchain' to 'WindowsToolchain' to be a bit more specific. Let me work on the rename and the release...

Release v0.5.0 created.

authors: ClausKlein MarkSchofield

repo: MarkSchofield/Toolchain


text:
Hide Average Spreadsheet Mark from Students

I was not aware of this until I changed my view to a student's account that MarkUs reports the average mark from the spreadsheet to the students? Is there any way to disable this?
As I bring up in #3839 and #3833, there appears to be no way to ignore inactive students from the Marks Spreadsheet statistics. Since this very incorrect statistic was being reported to my students I received a few emails asking about midterm reweighing, as MarkUs was indicating to them that the midterm average was almost 30% lower than the true average.
Of course, this in particular wouldn't be an issue if there was any way to remove inactive students from the statistics (or to stop counting No Marks as 0s). If there's no way to hide the marks average, even if it is correct, is this because there's no legitimate reason to not provide that for students?

Reason for marking as invalid:

with the addition of the grades summary view for students it seems we are going down the route of providing more stats to students not fewer
as long as inactive students are not reported (or more importantly, unreleased results are not reported) then I believe assignment stats should not be hidden

authors: jessebett mishaschwartz

repo: MarkUsProject/Markus


text:
Создай новую ветвь patch/content/primary в feature/body

В этой ветке - базовая инфо

Сделано

repo: MarryCone/homepage


text:
1.0

Deneme

comment

repo: MarsalekDesmotes/Devils-Phone


text:
Multiple domains

I am thinking of how to use a single postfix to serve multiple domains. I will try to come up with the required changes and do a PR.

Hi, well by now I always told contributors with this wish to fork my project and modify it to their needs. But if you implement it nicely I'm happy to merge it.
Thanks and greetings
Marvin

I figured this could be done with a nginx plugin as a reverse proxy.
On Wed, 19 Jul 2017 at 19:12, Marvin notifications@github.com wrote:

Closed #7
https://github.com/MarvAmBass/docker-versatile-postfix/issues/7.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarvAmBass/docker-versatile-postfix/issues/7#event-1170657618,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcgaR4wHxTwQE6ZkLEsWr8oGJsk0L1eks5sPjj5gaJpZM4MwMOn
.

good idea, keeps the container logic simple and gives you flexibility 👍

authors: MarvAmBass mpartipilo

repo: MarvAmBass/docker-versatile-postfix

license: mit

license_source: bigquery


text:
Doesnot work with xenial64

With ubuntu xenial64.
vagrant ssh -c "kong start --run-migrations"
prefix directory /usr/local/kong not found, trying to create it
Error: /usr/local/share/lua/5.1/kong/cmd/start.lua:19: Permission denied

  Run with --v (verbose) or --vv (debug) for more details
Connection to 127.0.0.1 closed.

Works with sudo though

This is expected behavior. As the output indicates write permission to the parent of the Kong path is needed. If such a parent is owned by root, then Kong must prepare the prefix as root.

Also, the provisioner script chowns /usr/local to the vagrant user. You will want to ensure this has actually taken place on your environment

repo: Mashape/kong-vagrant


text:
kong status is reporting wrong configuration file

kong status is reporting the wrong configuration file.
root@SPK-D-0611:/home/debraj# kong start -c /etc/kong/kong2.yml
[INFO] Kong 0.6.1
[INFO] Using configuration: /etc/kong/kong2.yml
[INFO] database...........cassandra contact_points=172.16.85.228:9042,172.16.85.230:9042,172.16.85.232:9042 ssl=verify=false enabled=false keyspace=kong replication_factor=2 replication_strategy=SimpleStrategy timeout=5000 data_centers=
[INFO] dnsmasq............address=127.0.0.1:8053 dnsmasq=true port=8053
[INFO] nginx .............admin_api_listen=0.0.0.0:8001 proxy_listen=0.0.0.0:8000 proxy_listen_ssl=0.0.0.0:8443
[INFO] serf ..............-profile=wan -rpc-addr=127.0.0.1:7373 -event-handler=member-join,member-leave,member-failed,member-update,member-reap,user:kong=/usr/local/kong/serf_event.sh -bind=172.16.85.228:7946 -node=SPK-D-0611_172.16.85.228:7946 -log-level=err
[INFO] Trying to auto-join Kong nodes, please wait..
[INFO] Successfully auto-joined 172.16.85.232:7946
[OK] Started
root@SPK-D-0611:/home/debraj# kong status
[INFO] Using configuration: /etc/kong/kong.yml
[INFO] Kong is running

As the above output shows even though kong is started with configuration file /etc/kong/kong2.yml but doing kong status is saying Using configuration: /etc/kong/kong.yml.

Every Kong command requires passing the config param, e.g.:
kong start -c /etc/kong/kong2.yml
kong status -c /etc/kong/kong2.yml
kong migrations list -c /etc/kong/kong2.yml

Otherwise, kong config will default to /etc/kong/kong.yml.

@mars this is correct. kong status also needs the right configuration file, so that it knows where the working directory is.

NB: that is also temporary until Kong receives its prefixed install.

authors: debraj-manna mars thefosk thibaultCha

repo: Mashape/kong


text:
hotfix(admin-api) disable TLS/1.0

Full changelog

Also disables TLS/1.0 on the Admin API

One that that was brought up at the sprint was keeping commits atomic. Since these two changes are unrelated, can they be fleshed into two separate PRs?

@p0pr0ck5 sure, PR updated


text:
Doc-comments are not recognized as comments

What the title says

-- | (note the whitespace) works though, so I'd rather title this as Some doc-comments are not recognized as comments.

authors: NomisIV postsolar

repo: Maskhjarna/tree-sitter-purescript


text:
System.InvalidOperationException When Using IAsyncDisposable

Is this a bug report?
Yes
Can you also reproduce the problem with the latest version?
Yes
Occurs When
When using MassTransit DI with a scoped consumer which has a dependency which only implements IAsyncDisposable.
It appears MassTransit should be calling DisposeAsync()
Stacktrace
MassTransit.ReceiveTransport: Error: R-FAULT rabbitmq://mq/report_queue 000a0000-ac16-0242-5f5f-08d794932d75 <redacted>.IMyCommand <redacted>.MyConsumer(00:00:06.8635823)

System.InvalidOperationException: '<redacted type name>' type only implements IAsyncDisposable. Use DisposeAsync to dispose the container.
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.Dispose()
   at MassTransit.Scoping.ConsumerContexts.CreatedConsumerScopeContext`3.Dispose()
   at MassTransit.Scoping.ScopeConsumerFactory`1.Send[TMessage](ConsumeContext`1 context, IPipe`1 next)
   at MassTransit.Pipeline.Filters.ConsumerMessageFilter`2.GreenPipes.IFilter<MassTransit.ConsumeContext<TMessage>>.Send(ConsumeContext`1 context, IPipe`1 next)

Environment
Dotnet version: .NET Core 3.0.0
Package: MassTransit (6.0.1)
Package: MassTransit.Extensions.DependencyInjection (6.0.1)

Service Configuration
services.AddScoped<MyConsumer>();

// Add MassTransit
services.AddMassTransit(x =>
{
    // Add Consumers
    x.AddConsumer<MyConsumer>();

    x.AddBus(provider => Bus.Factory.CreateUsingRabbitMq(cfg =>
    {
        var host = cfg.Host(new Uri(RabbitMqConstants.BASE_ADDRESS + Environment.GetEnvironmentVariable("RABBITMQ_SERVER")), h =>
        {
            h.Username(Environment.GetEnvironmentVariable("RABBITMQ_DEFAULT_USER"));
            h.Password(Environment.GetEnvironmentVariable("RABBITMQ_DEFAULT_PASS"));
        });

        cfg.ReceiveEndpoint(RabbitMqConstants.MY_QUEUE, ep =>
        {
            ep.PrefetchCount = 0;

            // Map Messages To Queue
            EndpointConvention.Map<IMyCommand>(ep.InputAddress);

            // Configure Consumers
            ep.Consumer<MyConsumer>(provider);
        });
    }));
});

services.AddSingleton<IPublishEndpoint>(provider => provider.GetRequiredService<IBusControl>());
services.AddSingleton<ISendEndpointProvider>(provider => provider.GetRequiredService<IBusControl>());
services.AddSingleton<IBus>(provider => provider.GetRequiredService<IBusControl>());
services.AddSingleton<IHostedService, BusService>();

MyConsumer
public class MyConsumer : IConsumer<IMyCommand>
{
     private readonly ISomeAsyncDisposable _disposable;

     public MyConsumer(ISomeAsyncDisposable disposable)
     {
          _disposable = disposable;
     }

     public async Task Consume(ConsumeContext<IMyCommand> context)
     {
          // Removed for brevity
     }
}

Based on this 426, it seems like IAsyncEnumerable was never added to the interface, but instead added to the implementation. So they're expecting a cast to IAsyncEnumerable then call DisposeAsync()

MassTransit will not manage the lifecycle of your dependencies if you're using a container.
In this case, a consumer with an IAsyncDisposable dependency, and I'm guessing you're using the .NET version of the interface, which MassTransit doesn't use or support. Unfortunately, they have the same name.
Seems like you figured out the issue, though.

MassTransit will not manage the lifecycle of your dependencies if you're using a container.

@phatboyg I don't quite follow this. Isn't MassTransit creating a scope and disposing it?

This one: https://github.com/MassTransit/GreenPipes/blob/develop/src/GreenPipes/IAsyncDisposable.cs

MassTransit is calling dispose on the container scope, the container is responsible for calling any disposable methods on any dependent objects.

I see. That's correct, I'm using the .NET version of IAsyncDisposable.  Are there any plans to support it?
As of .NET Core 3.0, it is now a standard interface. The default Microsoft.Extensions.DependencyInjection container supports it. So Masstransit doesn't currently seem to support the full capabilities of the default container. Basically the container is expecting that if it resolves any dependencies implementing IAsyncDisposable (but not IDisposable), the scope is disposed via DisposeAsync(). I would imagine, moving forward, it will become more and more relevant.
My current workaround is to inject an IServiceProvider into my consumer, and then create a child scope to resolve my dependencies from. I later call DisposeAsync() on that scope before finishing the IConsumer<T>.Consume(..) method. Any suggestions on a better workaround?

Your workaround seems to be enough, given what you've stated.
It will take a while before I support the netstandard2.1 features, since they force developers to move to the latest and not everyone is there yet.

Fair enough. Props on a great library!

Thanks!

@phatboyg I was thinking about this again. Would this be doable using multi-targeting to avoid breaking people?
Something like:
#if NETSTANDARD2_1
await using var asyncScope = scope as IAsyncDisposable;
# endif

Why? v7 and beyond of MassTransit uses https://www.nuget.org/packages/Microsoft.Bcl.AsyncInterfaces/ so this shouldn't be an issue.

That doesn't solve this issue. The issue is calling IServiceScope.Dispose(). Instead of casting to IAsyncDisposable, which is what AspNetCore does. The original error here reproduces in MassTransist 7.2.1.
Not wanting to force everyone into Standard 2.1 is perfectly logical. But if multi-targeting solves that issue, does it make sense to add this? This essentially prevents anyone from using consumers properly in DI if they have even a single async disposable dependency (forces you to use service location & manage the scope in every consumer). Admittedly, I don't know if it would add a bunch of maintenance burden to MT though.

I don't plan to multi-target, it's too difficult to deal with honestly.

Converting all the scope providers to use IAsyncDisposable is fairly extensive, but might be doable.

The latest develop NuGet packages should have this properly implemented now.

Thanks! All works for me in my test project now w/ those new changes.

Great, will be in the next release.

authors: Cooksauce phatboyg

repo: MassTransit/MassTransit


text:
InChIKey property

This PR adds InChIKey property for structure entries. InChIKey is a chemical structure descriptor alternative to SMILES (proposed in #368). InChIKey is said to avoid the the ambiguity the SMILES possesses, moreover, it does not have any internal structure (essentially being a "chemical checksum"), thus there should be no issues with its comparisons.
Pinging people who have expressed their interest for comments: @eimrek @utf @Austin243

Workshop: after the above workshop comment has been considered/handled this should be merged.
We have discussed if "complicated derived non-unique descriptors" really belongs inside the structures entry. However, before we have a decision/design on where they should go, we should accept fields that are useful and desired into the structures endpoint for now.
A similar regard holds for the desire to allow application area/subconsortia prefixes. Until we have a model for that, we merge fields without them.

@merkys @ml-evs What do you think - should we still add this to "core OPTIMADE" as decided in the web meet. Or, now that we are hopefully somewhat close to merging #473, should all of these 'chemically oriented fields" currently waiting in PRs by @merkys instead go in its own namespace?
These PRs are affected: #466 #465 #436 #398 - and the question is if they should be labeled 'status/blocked' (blocking on #473) or 'status/waiting-for-update' (since they all currently are sitting with comments to address before merging)

@merkys @ml-evs What do you think - should we still add this to "core OPTIMADE" as decided in the web meet. Or, now that we are hopefully somewhat close to merging #473, should all of these 'chemically oriented fields" currently waiting in PRs by @merkys instead go in its own namespace?
These PRs are affected: #466 #465 #436 #398 - and the question is if they should be labeled 'status/blocked' (blocking on #473) or 'status/waiting-for-update' (since they all currently are sitting with comments to address before merging)
Edit: possibly also #400, #396, or would those go in a "bio" prefix?

On purely technical/scientific terms I think this field would be perfect to seed a cheminformatics namespace (along with SMARTS/SMILES etc -- would have to figure out how to allow filter_smarts as a custom URL param too...). However on a purely development practice, I worry that we don't have the level of engagement or scale to spread ourselves so thinly across these various namespaces, in which case just loading up the core OPTIMADE namespace is maybe preferable. Happy to discuss!

@ml-evs maybe we can use this example to try out the infrastructure and see where we hit snags? I'm not sure we absolutely need engagement at this point, we already have 4-6 PR:s for properties to place in such a namespace-provider standard, which we can do under a "v0.1" to mark that things are highly experimental.
I've created a couple of new repos for this:

https://github.com/Materials-Consortia/definition-provider-template : GitHub template repo to create new definition-provider repos
https://github.com/Materials-Consortia/namespace-cheminformatics : live repo for the cheminformatics prefix where we can try to integrate @merkys cheminformatics definitions and see how far we get.

Great! Thanks for this @rartino -- I definitely stalled in my attempts to do the same thing. I will try to migrate https://github.com/Materials-Consortia/optimade-stability-namespace in the same direction.

Now about the remaining cheminformatics PRs. #436 introduces a new SMILES OPTIMADE data type and #398 introduces a new URI query parameter. I wonder whether property definition format and namespaces are ready to accept such extensions? If not, is this something that should be allowed to be extended in namespaces?

Once the current property defs etc. are merged, lets work on a similar design for user-defined datatypes. I'm thinking a similar declarative format as for units, properties for datatypes, where one with human language declare how every operator should work. However, I don't want to draft this until the property framework is merged.
The need for user-defined filer languages should perhaps inform the design of #398. Can we instead allow some syntax for the usual filter= to provide a list of filters with some kind of specifier what kind of filter it is? Then we can allow user-defined filter languages without new query parameters.

Once the current property defs etc. are merged, lets work on a similar design for user-defined datatypes. I'm thinking a similar declarative format as for units, properties for datatypes, where one with human language declare how every operator should work. However, I don't want to draft this until the property framework is merged.

Makes sense.

The need for user-defined filer languages should perhaps inform the design of #398. Can we instead allow some syntax for the usual filter= to provide a list of filters with some kind of specifier what kind of filter it is? Then we can allow user-defined filter languages without new query parameters.

For now queries in filters act on property values only. Query by SMARTS will not be bound to a specific property. A possible solution would be to allow queries on entries themselves by introducing property-less operators, viz. /structures?filter=SMARTS "[CX4]".

I suppose that by command line parameters you mean URL query parameters. Indeed, custom query parameters are already allowed. Thus #398 already can go to cheminformatics namespace.

It has been decided to move cheminformatics properties to a repository of its own, which has been done in https://github.com/Materials-Consortia/namespace-cheminformatics/pull/1 and https://github.com/Materials-Consortia/namespace-cheminformatics/pull/2. Closing this PR.

authors: merkys ml-evs rartino

repo: Materials-Consortia/OPTIMADE


text:
Support Friend Summon for KR server

Friend summon for KR also seems to use the old format. So, doing it similar to #359.
@sleeping-player @ScathachSkadi can you check this build: https://github.com/MathewSachin/Fate-Grand-Automata/actions/runs/242964064?

Oh wait

I'm sorry for leaving you do it as I was late for what I should have done..
As I already did daily free fp summon today, so I couldn't test it. It seems to work fine except for this exception.

Daily summon doesn't really matter since it's only done once.
Summoning continuously is more important for using up FP.

Checking now

Runs fine. I also used my 10 fp gacha before testing it.

10 free fp gacha doesn't work. Just tried. But I don't think that matters too much.

repo: MathewSachin/Fate-Grand-Automata


text:
🛑 Inventario App is down

In 35a726c, Inventario App (https://inventario.voluntariosgreenpeace.cl/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Inventario App is back up in 224014c.


text:
🛑 Inventario App is down

In 5675eca, Inventario App (https://inventario.voluntariosgreenpeace.cl/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Inventario App is back up in 3cb3eb7.


text:
🛑 Inventario App is down

In 639ad2f, Inventario App (https://inventario.voluntariosgreenpeace.cl/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Inventario App is back up in bdc6579.


text:
1.10 clients using Forge crash if an iron_nugget is dropped / on the ground

What is the output url of /viaversion dump?

https://gist.github.com/e8ae100e151a829c1f2101cc29489d7b

How/when does this error happen? login?:

As described, Forge crashes if an iron_nugget is dropped. Crafting works fine and in inventory works fine, but any 1.10 Forge clients connected to a 1.12 server where someone crafts and drops an iron nugget will immediately be disconnected.

Is there an error in the console? Use pastebin.com. Is there a kick message?:

https://pastebin.com/3RXAqEDQ

Thanks!

Note that error is clientside. There is no error serverside. Most likely there needs to be a simple translation of item type sent to clients.

Will look into it when I have more free time. Thanks for reporting (:

<3 Thank you!

I'm unable to reproduce this. Does this happen on a Spigot 1.10 server without ViaVersion & ViaBackwards?

No. Spigot 1.12, with latest ViaVersion and ViaBackwards as of time of report.
Client connects with Forge 1.10.2, iron nugget held in inventory is fine -- as soon as it is dropped, crash occurs.

Could you give me your crashlog? (:

It was included in the OP.
Note, Spigot does not crash. The clients crash. It is being used offensively during PvP to "crash" the other players, then kill their combat loggers.

Found the bug. Should be fixed in the latest devbuild.
Please ask for a reopen if it still happens (:

authors: Matsv ProgrammerDan

repo: Matsv/ViaBackwards


text:
[Bug] storage widget blank when multi-view set to true

Description of the bug
Since 4.50 the storage widget is blank when multi-view is enabled.  You can see this on the widget creator, even the demo widget is blank when multi-view is set to true:
https://getdashdot.com/docs/integration/widgets

Thanks for this issue - it will be fixed in the next release.

:tada: This issue has been resolved in version 4.5.1
Please check the changelog for more details.

authors: MauriceNino dgrzjohn

repo: MauriceNino/dashdot


text:
New installation : storage not working

Description of the bug
New installation with deployment of a Portainer stack : widget storage not working.
version: "3.9"
services:
dashdot:
container_name: dashdot
image: mauricenino/dashdot:latest
mem_limit: 4g
cpu_shares: 768
security_opt:
- no-new-privileges:true
restart: on-failure:5
volumes:
- /:/mnt/host:ro
ports:
- 7512:3001
privileged: true
environment:
DASHDOT_ENABLE_CPU_TEMPS: true
DASHDOT_ALWAYS_SHOW_PERCENTAGES: true
DASHDOT_CUSTOM_HOST:
DASHDOT_SHOW_HOST: true
DASHDOT_PAGE_TITLE:
DASHDOT_SHOW_DASH_VERSION: icon_hover
DASHDOT_ACCEPT_OOKLA_EULA: true

How to reproduce
No response
Relevant log output
/app # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vg1/volume_1    3746086260 3527720912 218365348  94% /
tmpfs                    65536         0     65536   0% /dev
tmpfs                  2962468         0   2962468   0% /sys/fs/cgroup
shm                      65536         0     65536   0% /dev/shm
/dev/md0               2385528   1548928    717816  68% /mnt/host
tmpfs                  2962468         0   2962468   0% /mnt/host/sys/fs/cgroup
devtmpfs               2958988         0   2958988   0% /mnt/host/proc/bus/usb
devtmpfs               2958988         0   2958988   0% /mnt/host/dev
tmpfs                  2962468       380   2962088   0% /mnt/host/dev/shm
tmpfs                  2962468     36996   2925472   1% /mnt/host/run
tmpfs                   592496         0    592496   0% /mnt/host/run/user/196791
tmpfs                  2962468      1548   2960920   0% /mnt/host/tmp
/dev/vg1/volume_1    3746086260 3527720912 218365348  94% /mnt/host/volume1
df: /mnt/host/volume1/RT2600acVB/Clé\040USB: No such file or directory
df: /mnt/host/volume1/RT2600acVB/Carte\040SD: No such file or directory
/dev/vg1/volume_1    3746086260 3527720912 218365348  94% /mnt/host/volume1/@dock
er
/dev/vg1/volume_1    3746086260 3527720912 218365348  94% /mnt/host/volume1/@dock
er/btrfs
/dev/vg1/volume_1    3746086260 3527720912 218365348  94% /mnt/host/volume1/@dock
er/btrfs/subvolumes/cbb0ef0ca8372f873d511b6ff6c3a2973b8e3debf88efd59cd585e1f91ea8
ba3
tmpfs                    65536         0     65536   0% /mnt/host/volume1/@docker
/btrfs/subvolumes/cbb0ef0ca8372f873d511b6ff6c3a2973b8e3debf88efd59cd585e1f91ea8ba
3/dev
Info output of dashdot cli
$ node dist/apps/cli/main.js info
node:internal/modules/cjs/loader:1080
  throw err;
  ^

Error: Cannot find module 'systeminformation'
Require stack:
- /app/dist/apps/cli/apps/cli/src/main.js
- /app/dist/apps/cli/main.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._resolveFilename (/app/dist/apps/cli/main.js:32:36)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:121:18)
    at Object.<anonymous> (/app/dist/apps/cli/apps/cli/src/main.js:26:18)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/app/dist/apps/cli/apps/cli/src/main.js',
    '/app/dist/apps/cli/main.js'
  ]
}

Node.js v18.17.1
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

What browsers are you seeing the problem on?
Firefox, Safari
Where is your instance running?
Other (Please specify below)
Additional context
Container Manager DSM 7.2.1-69057 Update 1

I have the same problem on my Synology docker instance as well.

same

+1 to this issue

+1 Same here. Running in Docker on Ubuntu.

@vincentbls @BlackJoker90 @costispavlou @SimpleStevie @SecOps-7 Hello everyone! Sorry for the delay.
Can you all please update the application to the latest version, run the following command and then paste the output?
docker exec CONTAINER yarn cli raw-data --storage

@vincentbls @BlackJoker90 @costispavlou @SimpleStevie @SecOps-7 Hello everyone! Sorry for the delay.
Can you all please update the application to the latest version, run the following command and then paste the output?
docker exec CONTAINER yarn cli raw-data --storage

how to run the command on synology?

`yarn run v1.22.19
$ node dist/apps/cli/main.js raw-data --storage
If you were asked to paste the output of this command, please post only the following:

On GitHub: Everything between (and excluding) the lines
On Discord: Everything between (and including) the ```

Output:
const disks =  [
  {
    device: '/dev/ram0',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram1',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram2',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram3',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram4',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram5',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram6',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram7',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram8',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram9',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram10',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram11',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram12',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram13',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram14',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/ram15',
    type: 'HD',
    name: '',
    vendor: '',
    size: 671088640,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: '',
    interfaceType: '',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/sda',
    type: 'HD',
    name: 'WD20EZRX-00D8PB0        ',
    vendor: 'Western Digital',
    size: 2000398934016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '0A80',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/sdb',
    type: 'HD',
    name: 'ST14000NE0008-2JK101    ',
    vendor: 'Seagate',
    size: 14000519643136,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: 'EN01',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/sdc',
    type: 'HD',
    name: 'MG06ACA800E             ',
    vendor: 'TOSHIBA',
    size: 8001563222016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '0108',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/sdd',
    type: 'HD',
    name: 'MG06ACA800E             ',
    vendor: 'TOSHIBA',
    size: 8001563222016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '0108',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/sde',
    type: 'HD',
    name: 'MG06ACA800E             ',
    vendor: 'TOSHIBA',
    size: 8001563222016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '0108',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/sdf',
    type: 'HD',
    name: 'MG06ACA800E             ',
    vendor: 'TOSHIBA',
    size: 8001563222016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '0108',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/synoboot',
    type: 'HD',
    name: 'DiskStation             ',
    vendor: 'Synology',
    size: 125829120,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: 'DL17',
    serialNum: '',
    interfaceType: 'USB',
    smartStatus: 'unknown',
    temperature: null
  }
]
const sizes =  [
  {
    fs: '/dev/mapper/cachedev_0',
    type: 'btrfs',
    size: 32592617025536,
    used: 19265901731840,
    available: 13326715293696,
    use: 59.11,
    mount: '/',
    rw: true
  },
  {
    fs: '/dev/md0',
    type: 'ext4',
    size: 8387944448,
    used: 1834909696,
    available: 6431399936,
    use: 22.2,
    mount: '/mnt/host',
    rw: false
  }
]
const blocks =  [
  {
    name: 'sda',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 2000398934016,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'WD20EZRX-00D8PB0',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sda'
  },
  {
    name: 'sdb',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 14000519643136,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'ST14000NE0008-2JK101',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sdb'
  },
  {
    name: 'sdc',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 8001563222016,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'MG06ACA800E',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sdc'
  },
  {
    name: 'sdd',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 8001563222016,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'MG06ACA800E',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sdd'
  },
  {
    name: 'sde',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 8001563222016,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'MG06ACA800E',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sde'
  },
  {
    name: 'sdf',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 8001563222016,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'MG06ACA800E',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sdf'
  },
  {
    name: 'synoboot',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 125829120,
    physical: 'HDD',
    uuid: '',
    label: '',
    model: 'DiskStation',
    serial: '',
    removable: false,
    protocol: 'usb',
    group: '',
    device: '/dev/synoboot'
  },
  {
    name: 'zram0',
    type: 'disk',
    fsType: 'swap',
    mount: '[SWAP]',
    size: 2511339520,
    physical: 'SSD',
    uuid: 'a06f2734-18f1-492d-b222-79827d0919fd',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/zram0'
  },
  {
    name: 'zram1',
    type: 'disk',
    fsType: 'swap',
    mount: '[SWAP]',
    size: 2511339520,
    physical: 'SSD',
    uuid: '0b2097c7-44d1-4eec-ad72-478dd9fa5a57',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/zram1'
  },
  {
    name: 'zram2',
    type: 'disk',
    fsType: 'swap',
    mount: '[SWAP]',
    size: 2511339520,
    physical: 'SSD',
    uuid: 'e84d936c-cc5e-47e0-9098-c57010fd2ac4',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/zram2'
  },
  {
    name: 'zram3',
    type: 'disk',
    fsType: 'swap',
    mount: '[SWAP]',
    size: 2511339520,
    physical: 'SSD',
    uuid: '748ffe9c-534c-4c0b-8bf9-c92e518e681e',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/zram3'
  },
  {
    name: 'cachedev_0',
    type: 'dm',
    fsType: 'btrfs',
    mount: '/etc/hosts',
    size: 33950642733056,
    physical: '',
    uuid: 'ed554aaa-ff94-44a1-a3d6-25496d6ecd9b',
    label: '2023.10.18-18:59:43 v42962',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'vg1-syno_vg_reserved_area',
    type: 'lvm',
    fsType: '',
    mount: '',
    size: 12582912,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'vg1-volume_1',
    type: 'lvm',
    fsType: 'btrfs',
    mount: '',
    size: 33950642733056,
    physical: '',
    uuid: 'ed554aaa-ff94-44a1-a3d6-25496d6ecd9b',
    label: '2023.10.18-18:59:43 v42962',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'sda1',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 8589934592,
    physical: '',
    uuid: '3f6d11e9-ee5a-83b7-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md0',
    device: '/dev/sda'
  },
  {
    name: 'sda2',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 2147483648,
    physical: '',
    uuid: '8cf29cf4-926a-9e5e-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md1',
    device: '/dev/sda'
  },
  {
    name: 'sda3',
    type: 'part',
    fsType: '',
    mount: '',
    size: 1024,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/sda'
  },
  {
    name: 'sda5',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 1989415567360,
    physical: '',
    uuid: '3262f13e-7043-5ac0-e81c-60a230ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md2',
    device: '/dev/sda'
  },
  {
    name: 'sdb1',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 8589934592,
    physical: '',
    uuid: '3f6d11e9-ee5a-83b7-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md0',
    device: '/dev/sdb'
  },
  {
    name: 'sdb2',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 2147483648,
    physical: '',
    uuid: '8cf29cf4-926a-9e5e-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md1',
    device: '/dev/sdb'
  },
  {
    name: 'sdb5',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 1989415567360,
    physical: '',
    uuid: '3262f13e-7043-5ac0-e81c-60a230ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md2',
    device: '/dev/sdb'
  },
  {
    name: 'sdb6',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 6001156046848,
    physical: '',
    uuid: '03a077b1-0152-c4ba-97d0-ab0aa51c49f6',
    label: 'Synology:3',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md3',
    device: '/dev/sdb'
  },
  {
    name: 'sdb7',
    type: 'part',
    fsType: '',
    mount: '',
    size: 5998943453184,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/sdb'
  },
  {
    name: 'sdc1',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 8589934592,
    physical: '',
    uuid: '3f6d11e9-ee5a-83b7-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md0',
    device: '/dev/sdc'
  },
  {
    name: 'sdc2',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 2147483648,
    physical: '',
    uuid: '8cf29cf4-926a-9e5e-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md1',
    device: '/dev/sdc'
  },
  {
    name: 'sdc5',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 1989415567360,
    physical: '',
    uuid: '3262f13e-7043-5ac0-e81c-60a230ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md2',
    device: '/dev/sdc'
  },
  {
    name: 'sdc6',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 6001156046848,
    physical: '',
    uuid: '03a077b1-0152-c4ba-97d0-ab0aa51c49f6',
    label: 'Synology:3',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md3',
    device: '/dev/sdc'
  },
  {
    name: 'sdd1',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 8589934592,
    physical: '',
    uuid: '3f6d11e9-ee5a-83b7-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md0',
    device: '/dev/sdd'
  },
  {
    name: 'sdd2',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 2147483648,
    physical: '',
    uuid: '8cf29cf4-926a-9e5e-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md1',
    device: '/dev/sdd'
  },
  {
    name: 'sdd5',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 1989415567360,
    physical: '',
    uuid: '3262f13e-7043-5ac0-e81c-60a230ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md2',
    device: '/dev/sdd'
  },
  {
    name: 'sdd6',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 6001156046848,
    physical: '',
    uuid: '03a077b1-0152-c4ba-97d0-ab0aa51c49f6',
    label: 'Synology:3',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md3',
    device: '/dev/sdd'
  },
  {
    name: 'sde1',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 8589934592,
    physical: '',
    uuid: '3f6d11e9-ee5a-83b7-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md0',
    device: '/dev/sde'
  },
  {
    name: 'sde2',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 2147483648,
    physical: '',
    uuid: '8cf29cf4-926a-9e5e-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md1',
    device: '/dev/sde'
  },
  {
    name: 'sde5',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 1989415567360,
    physical: '',
    uuid: '3262f13e-7043-5ac0-e81c-60a230ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md2',
    device: '/dev/sde'
  },
  {
    name: 'sde6',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 6001156046848,
    physical: '',
    uuid: '03a077b1-0152-c4ba-97d0-ab0aa51c49f6',
    label: 'Synology:3',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md3',
    device: '/dev/sde'
  },
  {
    name: 'sdf1',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 8589934592,
    physical: '',
    uuid: '3f6d11e9-ee5a-83b7-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md0',
    device: '/dev/sdf'
  },
  {
    name: 'sdf2',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 2147483648,
    physical: '',
    uuid: '8cf29cf4-926a-9e5e-3017-a5a8c86610be',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md1',
    device: '/dev/sdf'
  },
  {
    name: 'sdf5',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 1989415567360,
    physical: '',
    uuid: '3262f13e-7043-5ac0-e81c-60a230ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md2',
    device: '/dev/sdf'
  },
  {
    name: 'sdf6',
    type: 'part',
    fsType: 'linux_raid_member',
    mount: '',
    size: 6001156046848,
    physical: '',
    uuid: '03a077b1-0152-c4ba-97d0-ab0aa51c49f6',
    label: 'Synology:3',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: 'md3',
    device: '/dev/sdf'
  },
  {
    name: 'synoboot1',
    type: 'part',
    fsType: 'vfat',
    mount: '',
    size: 16777216,
    physical: '',
    uuid: '10EE-589C',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/synoboot'
  },
  {
    name: 'synoboot2',
    type: 'part',
    fsType: 'ext2',
    mount: '',
    size: 104857600,
    physical: '',
    uuid: '45e5b07d-4783-4867-a369-f99c0cd1e610',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: '',
    device: '/dev/synoboot'
  },
  {
    name: 'md0',
    type: 'raid1',
    fsType: 'ext4',
    mount: '/mnt/host',
    size: 8589869056,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'md1',
    type: 'raid1',
    fsType: 'swap',
    mount: '[SWAP]',
    size: 2147418112,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'md2',
    type: 'raid5',
    fsType: 'LVM2_member',
    mount: '',
    size: 9947072430080,
    physical: '',
    uuid: '3262f13e:70435ac0:e81c60a2:30ba4e25',
    label: 'Synology:2',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'md3',
    type: 'raid5',
    fsType: 'LVM2_member',
    mount: '',
    size: 24004619927552,
    physical: '',
    uuid: '03a077b1:0152c4ba:97d0ab0a:a51c49f6',
    label: 'Synology:3',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  }
]

Done in 1.91s.
`

@costispavlou Ah okay seems to be the same problem as the users in #918 experience. Unfortunately, I can't really help out with that, because I don't know how Synology works.

Since the new update of the docker container the problem got now inversed for me. Instead of saying that the disks are almost empty, they are now almost full:

@jarama Yes that is to be expected. Unaccounted for space will now be attributed to used instead of unused. There is a feature request to make problems in the setup more obvious in the UI though: #1001

Having the same as @jarama  - was scared my storage was full, SSHed into my linux box, checked with df -h - and yes, my mounted disk is almost fulll, but my main disk has plenty of space, still Dash. shows the opposite, hereby the output:

Output:
const disks =  [
  {
    device: '/dev/sda',
    type: 'SSD',
    name: 'SanDisk SDSSDH3 ',
    vendor: 'SanDisk',
    size: 1000204886016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '00RL',
    serialNum: '',
    interfaceType: 'SATA',
    smartStatus: 'unknown',
    temperature: null
  },
  {
    device: '/dev/nvme0n1',
    type: 'NVMe',
    name: 'SAMSUNG MZVLB256HBHQ-00000              ',
    vendor: 'Samsung',
    size: 256060514304,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: 'S4GGNF1N156868',
    interfaceType: 'PCIe',
    smartStatus: 'unknown',
    temperature: null
  }
]
const sizes =  [
  {
    fs: 'overlay',
    type: 'overlay',
    size: 247677284352,
    used: 46079774720,
    available: 188941619200,
    use: 19.61,
    mount: '/',
    rw: false
  },
  {
    fs: '/dev/loop7',
    type: 'squashfs',
    size: 77725696,
    used: 77725696,
    available: 0,
    use: 100,
    mount: '/mnt/host/README.md',
    rw: false
  },
  {
    fs: '/dev/mapper/ubuntu--vg-ubuntu--lv',
    type: 'ext4',
    size: 247677284352,
    used: 46079774720,
    available: 188941619200,
    use: 19.61,
    mount: '/mnt/host/usr/lib/modules',
    rw: true
  },
  {
    fs: '/dev/loop16',
    type: 'squashfs',
    size: 42860544,
    used: 42860544,
    available: 0,
    use: 100,
    mount: '/mnt/host/usr/lib/snapd',
    rw: false
  },
  {
    fs: '/dev/nvme0n1p2',
    type: 'ext4',
    size: 2040373248,
    used: 296136704,
    available: 1620086784,
    use: 15.45,
    mount: '/mnt/host/var/lib/snapd/hostfs/boot',
    rw: true
  },
  {
    fs: '/dev/nvme0n1p1',
    type: 'vfat',
    size: 1124999168,
    used: 6369280,
    available: 1118629888,
    use: 0.57,
    mount: '/mnt/host/var/lib/snapd/hostfs/boot/efi',
    rw: true
  },
  {
    fs: '/dev/loop0',
    type: 'squashfs',
    size: 131072,
    used: 131072,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/bare/5',
    rw: false
  },
  {
    fs: '/dev/loop1',
    type: 'squashfs',
    size: 47185920,
    used: 47185920,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/certbot/3462',
    rw: false
  },
  {
    fs: '/dev/loop2',
    type: 'squashfs',
    size: 47185920,
    used: 47185920,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/certbot/3566',
    rw: false
  },
  {
    fs: '/dev/loop3',
    type: 'squashfs',
    size: 58458112,
    used: 58458112,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/core18/2796',
    rw: false
  },
  {
    fs: '/dev/loop4',
    type: 'squashfs',
    size: 58458112,
    used: 58458112,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/core18/2812',
    rw: false
  },
  {
    fs: '/dev/loop5',
    type: 'squashfs',
    size: 66584576,
    used: 66584576,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/core20/2015',
    rw: false
  },
  {
    fs: '/dev/loop6',
    type: 'squashfs',
    size: 67108864,
    used: 67108864,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/core20/2105',
    rw: false
  },
  {
    fs: '/dev/loop8',
    type: 'squashfs',
    size: 77594624,
    used: 77594624,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/core22/864',
    rw: false
  },
  {
    fs: '/dev/loop9',
    type: 'squashfs',
    size: 135266304,
    used: 135266304,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/docker/2893',
    rw: false
  },
  {
    fs: '/dev/loop10',
    type: 'squashfs',
    size: 135266304,
    used: 135266304,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/docker/2904',
    rw: false
  },
  {
    fs: '/dev/loop11',
    type: 'squashfs',
    size: 96206848,
    used: 96206848,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/gtk-common-themes/1535',
    rw: false
  },
  {
    fs: '/dev/loop12',
    type: 'squashfs',
    size: 10223616,
    used: 10223616,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/htop/3758',
    rw: false
  },
  {
    fs: '/dev/loop13',
    type: 'squashfs',
    size: 10223616,
    used: 10223616,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/htop/3873',
    rw: false
  },
  {
    fs: '/dev/loop14',
    type: 'squashfs',
    size: 102891520,
    used: 102891520,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/pyqt5-runtime-lite/4',
    rw: false
  },
  {
    fs: '/dev/sda',
    type: 'xfs',
    size: 999716507648,
    used: 636956925952,
    available: 362759581696,
    use: 63.71,
    mount: '/mnt/host/var/lib/snapd/hostfs/mnt/data',
    rw: true
  },
  {
    fs: '/dev/loop17',
    type: 'squashfs',
    size: 42467328,
    used: 42467328,
    available: 0,
    use: 100,
    mount: '/mnt/host/var/lib/snapd/hostfs/snap/snapd/20671',
    rw: false
  }
]
const blocks =  [
  {
    name: 'nvme0n1',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 256060514304,
    physical: 'SSD',
    uuid: '',
    label: '',
    model: 'SAMSUNG MZVLB256HBHQ-00000',
    serial: 'S4GGNF1N156868      ',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  },
  {
    name: 'sda',
    type: 'disk',
    fsType: 'xfs',
    mount: '/mnt/host/mnt/data',
    size: 1000204886016,
    physical: 'SSD',
    uuid: '9bed18b7-f201-4967-ad50-13ebb16a3db6',
    label: '',
    model: 'SanDisk SDSSDH3',
    serial: '',
    removable: false,
    protocol: 'sata',
    group: '',
    device: '/dev/sda'
  },
  {
    name: 'loop0',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/bare/5',
    size: 4096,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop1',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/certbot/3462',
    size: 47153152,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop10',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/docker/2904',
    size: 135184384,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop11',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/gtk-common-themes/1535',
    size: 96141312,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop12',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/htop/3758',
    size: 10113024,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop13',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/htop/3873',
    size: 10113024,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop14',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/pyqt5-runtime-lite/4',
    size: 102780928,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop16',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/snapd/20290',
    size: 42840064,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop17',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/snapd/20671',
    size: 42393600,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop2',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/certbot/3566',
    size: 47165440,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop3',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core18/2796',
    size: 58363904,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop4',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core18/2812',
    size: 58363904,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop5',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core20/2015',
    size: 66547712,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop6',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core20/2105',
    size: 67014656,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop7',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core22/1033',
    size: 77713408,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop8',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core22/864',
    size: 77492224,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop9',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/docker/2893',
    size: 135163904,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'nvme0n1p1',
    type: 'part',
    fsType: 'vfat',
    mount: '/mnt/host/var/lib/snapd/hostfs/boot/efi',
    size: 1127219200,
    physical: '',
    uuid: '62AB-0B92',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  },
  {
    name: 'nvme0n1p2',
    type: 'part',
    fsType: 'ext4',
    mount: '/mnt/host/var/lib/snapd/hostfs/boot',
    size: 2147483648,
    physical: '',
    uuid: '864f43f3-740e-4bfe-bbe2-08b89855e6bc',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  },
  {
    name: 'nvme0n1p3',
    type: 'part',
    fsType: 'LVM2_member',
    mount: '',
    size: 252783362048,
    physical: '',
    uuid: 'ijfxRp-v4X5-Cue4-KEIn-12u3-eJoh-yH9EIe',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  }
]

@ThaDaVos this should be fixed in the latest version.

Yeah noticed that - it updated and seems correct now

Not for me...

@vincentbls Synology NAS is still not supported until someone can get it to correctly pass the mounts into the container. I have no clue about Synology, so it definitely won't be me.
@ThaDaVos doesn't seem to be running Synology, he just commented in this issue for some reason.

Apologies for the late response.  Just updated to the latest version and there is no change on my side.
Herewith the yarn output:

Output:
const disks =  [
  {
    device: '/dev/nvme0n1',
    type: 'NVMe',
    name: 'Samsung SSD 980 PRO 1TB                 ',
    vendor: 'Samsung',
    size: 1000204886016,
    bytesPerSector: null,
    totalCylinders: null,
    totalHeads: null,
    totalSectors: null,
    totalTracks: null,
    tracksPerCylinder: null,
    sectorsPerTrack: null,
    firmwareRevision: '',
    serialNum: 'S5GXNX0TC19214P',
    interfaceType: 'PCIe',
    smartStatus: 'unknown',
    temperature: null
  }
]
const sizes =  []
const blocks =  [
  {
    name: 'nvme0n1',
    type: 'disk',
    fsType: '',
    mount: '',
    size: 1000204886016,
    physical: 'SSD',
    uuid: '',
    label: '',
    model: 'Samsung SSD 980 PRO 1TB',
    serial: 'S5GXNX0TC19214P     ',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  },
  {
    name: 'loop0',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/bare/5',
    size: 4096,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop1',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/canonical-livepatch/246',
    size: 10051584,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop10',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/firefox/3626',
    size: 257945600,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop11',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/gnome-3-38-2004/143',
    size: 366682112,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop12',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/gnome-42-2204/120',
    size: 509100032,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop13',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/gnome-42-2204/141',
    size: 521121792,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop14',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/gtk-common-themes/1535',
    size: 96141312,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop15',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/snap-store/959',
    size: 12922880,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop16',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/snapd/20290',
    size: 42840064,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop17',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/snapd/20671',
    size: 42393600,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop18',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/snapd-desktop-integration/83',
    size: 462848,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop2',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/certbot-dns-cloudflare/3077',
    size: 9715712,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop3',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/certbot-dns-cloudflare/3182',
    size: 9719808,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop4',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core/16202',
    size: 110960640,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop5',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core20/2015',
    size: 66547712,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop6',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core20/2105',
    size: 67014656,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop7',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core22/1033',
    size: 77713408,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop8',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/core22/864',
    size: 77492224,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'loop9',
    type: 'loop',
    fsType: 'squashfs',
    mount: '/mnt/host/snap/firefox/3600',
    size: 257859584,
    physical: '',
    uuid: '',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: '',
    group: ''
  },
  {
    name: 'nvme0n1p1',
    type: 'part',
    fsType: 'vfat',
    mount: '/mnt/host/boot/efi',
    size: 536870912,
    physical: '',
    uuid: '6A88-3E2B',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  },
  {
    name: 'nvme0n1p2',
    type: 'part',
    fsType: 'ext4',
    mount: '/mnt/host',
    size: 999666221056,
    physical: '',
    uuid: '2b9ea517-0eae-40c9-9ee6-c34910671fc0',
    label: '',
    model: '',
    serial: '',
    removable: false,
    protocol: 'nvme',
    group: '',
    device: '/dev/nvme0n1'
  }
]

@SecOps-7 Are you running on Synology as well?

No, Running Docker on vanilla Ubuntu 22.04.3 LTS.

That's weird, I am also running Ubuntu, but I am running 23.04 - on my side, the last update fixed it

@SecOps-7 Than your problem is not related to this issue. Can you please open a new one and provide all necessary info, including:

Hardware
Storage setup
Config
Specific hosting form
Anything you deem important

Hello,
FYI I'm also running it on my Synology NAS with Portainer.
volumes:
  - /:/mnt/host:ro

root@SERVER:~# df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/md0                2.3G  1.5G  698M  69% /
devtmpfs                3.9G     0  3.9G   0% /dev
tmpfs                   3.9G  240K  3.9G   1% /dev/shm
tmpfs                   3.9G   23M  3.9G   1% /run
tmpfs                   3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs                   3.9G  1.8M  3.9G   1% /tmp
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
tmpfs                   791M     0  791M   0% /run/user/196791
/dev/loop0               15G   57M   15G   1% /volume1/@accountdb/@accountcache
tmpfs                   1.0T     0  1.0T   0% /dev/virtualization
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1//#snapshot
/dev/mapper/cachedev_0  5.3T  2.3T  3.0T  44% /volume1/___/#snapshot
Let me know if it helps or if you need something else to tshoot.

I think Synology changed something after 7.2 but I am not sure what it is, this worked for me when I was using 7.1.1.

Anyone try running from source on Synology? Or is that not recommended?

Anyone try running from source on Synology? Or is that not recommended?

Anyway I don't recommand, docker is definitely a better choice for its convenience and less space occupied.

authors: BlackJoker90 ChanLicher MauriceNino SecOps-7 SimpleStevie ThaDaVos costispavlou jamauai jarama spl33f vincentbls


text:
Feature/mc 9540

Bootstrap for versioning. Added a variety of bootstraped versioning elements. Primarily located in in V1, V2 and the V2 Branch. Fixed a copying issue, located another (see comment in bootstrapModels)

@gammonpeter @pjmonks can you please run this up or ask @OButlerOcc to demo it to you to see if this covers enough use cases to make your lives easier when testing the UI as this is the reason for this piece of work.

@olliefreeman I've already had a demo of this work and was happy with it, assuming that @OButlerOcc added the additions we discussed last week (some rules and metadata included). If @gammonpeter wanted a look too he's welcome.
Currently only Data Models are versioned/branched in this bootstrapped data, no versioned folders yet. My suggestion to @OButlerOcc was to get the bootstrapped Data Models merged in first as a priority to assist @gammonpeter working on the new merge UI (could at least test on Data Models for now). Separately @OButlerOcc could then include versioned folders bootstrapped data to help with the merge UI for model families.

@pjmonks cool. Yes VFs will come later, this is just a DM structure for now.
@OButlerOcc will be working on DOIs next.

Since we last reviewed pete I added the Rules you requested and ensured the metadata was available. Little unsure what happened to the metaData issue. I opened https://github.com/MauroDataMapper/mdm-ui/issues/204 in response to my investigation. James thinks it might be a backend issue in regards to the metaData Id being wrong. Do we have a working example to see if the returned ID is being mutated somewhere?

the MD issue has been moved to mdm-core as its UUID isnt rendering properly which means the correct view isnt being used by the API

authors: OButlerOcc olliefreeman pjmonks

repo: MauroDataMapper/mdm-core


text:
chore(main): release 0.13.2

:robot: I have created a release beep boop
0.13.2 (2024-09-04)
Bug Fixes

get_view_names: Use proper schema (#1082) (d5319c8)

Documentation

use read_only=False so that example doesn't raise an exception. (#1079) (d0688b4)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Mause/duckdb_engine/releases/tag/v0.13.2 :sunflower:


text:
How i can add more social share?

I want to add other social share like whatsapp, facebook, instagram, etc.. Please give me an idea to figure this out.

What's not clear in the readme's "Usage" section?

Closed due to missing feedback.


text:
Fix typo in README

Thank you for this project :)

Thank you!

authors: MaxLeiter nlhkabu


text:
🛑 TrueSafe App API is down

In 97d550b, TrueSafe App API ($STATUS_APP_API) was down:

HTTP code: 0
Response time: 0 ms

Resolved: TrueSafe App API is back up in cc2f81c after 3 hours, 17 minutes.


text:
Remove knockback from Bastion while in turret form

Fixes #112

I don't think this will fix the problem of being able to be moved by enemies, only boops.

Using ability 2 to check bastion in turret mode is simply incorrect.
I’ll work on making bastion immobile using the start forcing position function.

authors: MaxwellJung MrKingMichael snappycreeper


text:
Question About manualBiomeMappings

What is the correct way to use this? I assume it is to clump biomes together the way you want but when I tried this it crashed:
    # Use in combination with 'allowedBiomeFactors' to manually map some biomes to others. This is a list of the format oldbiome=newbiome [default: ]
    S:manualBiomeMappings <
ominous_woods=marsh
hell=ominous_woods
rainforest=jungle_edge
jungle_hills=jungle
jungle=rainforest
jungle_edge=jungle_hills
crag=hell
wasteland=crag
bayou=dead_swamp
dead_swamp=lush_swamp
lush_swamp=quagmire
quagmire=swampland
swampland=wetland
wetland=land_of_lakes
beaches=ocean
ocean=deep_ocean
deep_ocean=volcanic_island
volcanic_island=coral_reef
coral_reef=kelp_forest
stone_beach=beaches
gravel_beach=Stone_beach
river=gravel_beach
>

The formatting is rather picky. I think you have to add indentation to those lines

Good call, that fixed it. Can I make multiple entries for the same biome? For example
wetland=land_of_lakes
wetland=jungle
wetland=lush_swamp

No that will not work

so each biome can only be on each side once? Like this
ominous_woods=marsh
hell=ominous_woods
rainforest=jungle_edge
jungle_hills=jungle
jungle=rainforest
jungle_edge=jungle_hills
crag=hell
wasteland=crag
bayou=dead_swamp
dead_swamp=lush_swamp
lush_swamp=quagmire
quagmire=swampland
swampland=wetland
wetland=land_of_lakes
beaches=ocean
ocean=deep_ocean
deep_ocean=volcanic_island
volcanic_island=coral_reef
coral_reef=kelp_forest
stone_beach=beaches
gravel_beach=Stone_beach
river=gravel_beach

No, on the right side you can repeat biomes. Just not on the left side

Ohhhhh, so this
land_of_lakes=wetland
jungle=wetland
lush_swamp=wetland

authors: DonMegel McJty

repo: McJty/LostCities


text:
Compat Layer Version Issues

RFTools most recent version wants Compat Layer 0.1.7 or above but XNet wants version 0.2.5, but when I put the higher version in my Mods Folder I get the message that RFTools doesn't recognise Compat Layer version 0.2.5. Please help & advise.

Found out what the real Issue was, the Compat Layer file offered by some Minecraft Forum sites is incomplete or corrupted for all version use.

repo: McJty/RFTools


text:
Don't try to print filename in XML output if input file doesn't exist.

If we do this, it segfaults, so don't do it.

Fixes https://sourceforge.net/p/mediainfo/bugs/991/

Argh, I forgot to test the vector size... :(.
Thanks

authors: JeromeMartinez jgreer

repo: MediaArea/MediaInfoLib


text:
Fix for Issue #2 - Allow session token persistence and renewal

without explicit user login

Added implementation for MediaFire SessionToken V2 / Call Signatures
Added unit test project
Updated default MediaFire API version to "1.5"
Various bugfixes in HTTP request assembly
Updated dependencies: Newtonsoft.Json to version 9.0.1, Portable.BouncyCastle to version 1.8.1, Microsoft.Net.Http to version 2.2.29
Removed obsolete NuGet configuration
Minor code cleanup

@DVDPT
Ok, this is it.
After two partially incomplete PRs (sorry for the confusion BTW) I've now managed to get several basic API functions including files/folders listing, file and folder creation, file content download, and session token renewal to work based on MediaFire session token v2 / call signatures.
Please consider this PR for inclusion in a future release of MediaFireSDK.

repo: MediaFire/mediafire-csharp-open-sdk


text:
Under active development

Is this plugin still under active development? It seems the last tag release was June 8th 2016 and PRs are pending since October.

@majelbstoat

It seems they updated the README to state that it's no longer maintained on #126

authors: Gattermeier osukaa

repo: Medium/medium-wordpress-plugin


text:
目录功能

想请问一下可以增加目录吗，对笔记做一下分类

看看下面这个是否是你想要的
https://blog.meekdai.com/tag.html#All

authors: Meekdai comi-zhang

repo: Meekdai/Gmeek