Adding a foreign key column on non-SQLite platform may fail

Requery 1.1.2
io.requery.sql.SchemaModifier:205
public <T> void addColumn(Attribute<T, ?> attribute) {
    Type<T> type = attribute.getDeclaringType();
    QueryBuilder qb = createQueryBuilder();
    qb.keyword(ALTER, TABLE).tableName(type.getName());
    if (attribute.isForeignKey()) {
        if (platform.supportsAddingConstraint()) {
            // create the column first then the constraint
            qb.keyword(ADD, COLUMN);
            createColumn(qb, attribute); // <============== We prepare a column creating statement.
            executeSql(qb); // <=========================== We create a column.
            qb = createQueryBuilder();
            qb.keyword(ALTER, TABLE)
                .tableName(type.getName()).keyword(ADD);
            createForeignKeyColumn(qb, attribute, true); // We prepare a statement that
                                                            creates a column with a foreign key contraint.
        } else {
            qb = createQueryBuilder();
            qb.keyword(ALTER, TABLE)
                .tableName(type.getName()).keyword(ADD);
            createForeignKeyColumn(qb, attribute, false);
        }
    } else {
        qb.keyword(ADD, COLUMN);
        createColumn(qb, attribute);
    }
    executeSql(qb); // We create a column with a for-
                    // Nope, column with such name already exists, cannot create, crash!
}

I'd expect something like createForeignKeyReferenceOnColumn instead of createForeignKeyColumn.
I haven't tested what actually happens if you try executing this code so please correct me if creating a column that already exists is OK.

It wouldn't fail for the reason you're saying. However this is not really meant to be public function since we don't support migrations fully. It is used internally by the Android code to perform basic additions of columns, but not elsewhere. And was working on H2, HSQL, Derby before this change under the SchemaModifierTest. It's now expanded to fix an issue on Postgres
Postgres, H2, HSQL, Apache Derby:
alter table Person add column address integer
alter table Person add foreign key (address) references Address (id) on delete cascade

SQLite:
alter table Person add address integer references Address (id) on delete cascade

-Not working Oracle
-Not tested MySQL


Insufficient Funds Case Handling

Goals of PR
Core changes:

In case of insufficient funds specular's validator and sequencer will log the error and continue instead of panicing and exiting

handled in #107


Rendering a diagram took too many iterations when inContextOf multiple elements

Describe the bug
When trying to recreate an example GSN diagram from the GSN Community Standard Version 3 (Figure 0:4-7 An Example Goal Structure), this is the output:
"Rendering a diagram took too many iterations (882). See README.md for hints how to solve this situation."
A SVG is still produced, however its resolution is very large (viewBox="0 0 629116 609"). The y coordinates are reasonable, but half the x coordinates are 0-1000 and half are<PHONE_NUMBER>00 range.
To Reproduce
This is a minimal YAML that reproduces the example:
G1:
 text: System is acceptably safe to operate.
 classes: [none]
 supportedBy: [G2,  G3,]
G2:
 text: All identified hazards have been eliminated or sufficiently mitigated.
 classes: [none]
 supportedBy: [S1,]
G2.1:
 text: Hazard H1 has been eliminated.
 classes: [none]
 supportedBy: [Sn1,]
G2.2:
 text: Probability of Hazard H2 occuring less than 1x10-6 per year.
 classes: [none]
 supportedBy: [Sn2,]
G2.3:
 text: Probability of Hazard H3 occuring less than 1x10-3 per year.
 classes: [none]
 supportedBy: [Sn2,]
G3:
 text: Software in the Control System has been developed to SIL appropriate to hazards involved.
 classes: [none]
 supportedBy: [S2,]
G3.1:
 text: Primary Protection System Developed to SIL 4.
 classes: [none]
 supportedBy: [Sn3,]
G3.2:
 text: Secondary Protection System Development to SIL2.
 classes: [none]
 supportedBy: [Sn4,]
Sn1:
 text: Formal Verification.
 classes: [none]
Sn2:
 text: Fault Tree Analysis.
 classes: [none]
Sn3:
 text: Process Evidence for SIL4.
 classes: [none]
Sn4:
 text: Process Evidence for SIL2.
 classes: [none]
S1:
 text: Argument over each identified hazard.
 classes: [none]
 supportedBy: [G2.1,  G2.2,  G2.3,]
S2:
 text: Argument over allocated SIL for Primary and Secondary elements.
 classes: [none]
 supportedBy: [G3.1,  G3.2,]

Expected behavior
A GSN diagram with normal coordinates and dimensions.
Additional context
I have been able to produce many other GSN diagrams using gsn2x. This is the first time I have encountered this problem.
If you remove the context C4 (which is the only element that is inContextOf two other elements), the problem is resolved. Alternatively, removing all context/justification/assumptions apart from C4 also resolves the issue.

Bad news, my computer broke this week. I won't make it this weekend.
I will have a look into your problem as soon as possible though.

@jonasthewolf Sorry to hear that! Many thanks.

@RedAlbatross could you please verify the version of gsn2x you are using. I tried your example above with 2.8.2 and it worked perfectly.

Apologies, I forgot to include the whole yaml file, including the contexts. I am using 2.8.2.
G1:
 text: System is acceptably safe to operate.
 classes: [none]
 supportedBy: [G2,  G3,]
 inContextOf: [C1, C2]
G2:
 text: All identified hazards have been eliminated or sufficiently mitigated.
 classes: [none]
 supportedBy: [S1,]
 inContextOf: [C3, C4]
G2.1:
 text: Hazard H1 has been eliminated.
 classes: [none]
 supportedBy: [Sn1,]
G2.2:
 text: Probability of Hazard H2 occuring < 1x10-6 per year.
 classes: [none]
 supportedBy: [Sn2,]
G2.3:
 text: Probability of Hazard H3 occuring < 1x10-3 per year.
 classes: [none]
 supportedBy: [Sn2,]
G3:
 text: Software in the Control System has been developed to SIL appropriate to hazards involved.
 classes: [none]
 supportedBy: [S2,]
 inContextOf: [C4, C5]
G3.1:
 text: Primary Protection System Developed to SIL 4.
 classes: [none]
 supportedBy: [Sn3,]
G3.2:
 text: Secondary Protection System Development to SIL2.
 classes: [none]
 supportedBy: [Sn4,]
Sn1:
 text: Formal Verification.
 classes: [none]
Sn2:
 text: Fault Tree Analysis.
 classes: [none]
Sn3:
 text: Process Evidence for SIL4.
 classes: [none]
Sn4:
 text: Process Evidence for SIL2.
 classes: [none]
S1:
 text: Argument over each identified hazard.
 classes: [none]
 supportedBy: [G2.1,  G2.2,  G2.3,]
S2:
 text: Argument over allocated SIL for Primary and Secondary elements.
 classes: [none]
 supportedBy: [G3.1,  G3.2,]
 inContextOf: [J1, C6]
J1:
 text: SIL apportionment is correct and complete.
 classes: [none]
C1:
 text: Operating Role and Context.
 classes: [none]
C2:
 text:  System Definition.
 classes: [none]
C3:
 text: Tolerability targets (Ref Z).
 classes: [none]
C4:
 text: Hazards identified from FHA (Ref Y).
 classes: [none]
C5:
 text: SIL Guidelines and Processes.
 classes: [none]
C6:
 text: Identified software hazards.
 classes: [none]

@RedAlbatross thanks for the hint. I was afraid it was not that easy. I'll have a look at it.

@RedAlbatross I just released 2.8.3 which should fix that problem.
Could you please check if  any of your other examples break?
I would also be very interested in extending my test suite with your examples from the GSN standard. Would you be willing to share them?

@jonasthewolf Many thanks, it works now. This was actually the first example from the standard that I tested. But I will share if I make any of the other examples, which I plan to.


[Question]: FlagAI\examples\AltCLIP>python altclip_inference.py 报错

Description
   size mismatch for vision_model.encoder.layers.11.mlp.fc1.bias: copying a param with shape torch.Size([4096]) from checkpoint, the shape in current model is torch.Size([3072]).
    size mismatch for vision_model.encoder.layers.11.mlp.fc2.weight: copying a param with shape torch.Size([1024, 4096]) from checkpoint, the shape in current model is torch.Size([768, 3072]).
    size mismatch for vision_model.encoder.layers.11.mlp.fc2.bias: copying a param with shape torch.Size([1024]) from checkpoint, the shape in current model is torch.Size([768]).
    size mismatch for vision_model.encoder.layers.11.layer_norm2.weight: copying a param with shape torch.Size([1024]) from checkpoint, the shape in current model is torch.Size([768]).
    size mismatch for vision_model.encoder.layers.11.layer_norm2.bias: copying a param with shape torch.Size([1024]) from checkpoint, the shape in current model is torch.Size([768]).
    size mismatch for vision_model.post_layernorm.weight: copying a param with shape torch.Size([1024]) from checkpoint, the shape in current model is torch.Size([768]).
    size mismatch for vision_model.post_layernorm.bias: copying a param with shape torch.Size([1024]) from checkpoint, the shape in current model is torch.Size([768]).
    size mismatch for visual_projection.weight: copying a param with shape torch.Size([768, 1024]) from checkpoint, the shape in current model is torch.Size([768, 768]).
    You may consider adding `ignore_mismatched_sizes=True` in the model `from_pretrained` method.

Alternatives
No response

我不能复现这个报错，也许试试pull最新代码并安装，然后删除本地模型并重新加载一遍模型？

此问题已关闭，如有疑问可以重新打开


restore: suppress lchown errors when not running as root

What is the purpose of this change? What does it change?
Like "cp -a" and "rsync -a" do, only report lchown errors if we run
as root.
Like cp from GNU coreutils does, we check Geteuid() to determine if
we are running as root
( http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy.c#n3012 ).
On Windows, lchown errors are always reported.

Was the change discussed in an issue or in the forum before?
Fixes https://github.com/restic/restic/issues/1766

Checklist

[x] I have read the Contribution Guidelines
[ ] I have added tests for all changes in this PR
[ ] I have added documentation for the changes (in the manual)
[x] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[x] I'm done, this Pull Request is ready for review

Codecov Report

Merging #1993 into master will decrease coverage by 4.73%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1993      +/-   ##
==========================================
- Coverage   50.07%   45.34%   -4.74%
==========================================
  Files         169      165       -4
  Lines       13554    13508      -46
==========================================
- Hits         6787     6125     -662
- Misses       5750     6431     +681
+ Partials     1017      952      -65

Impacted Files
Coverage Δ

internal/restic/node.go
37.62% <0%> (-2.69%)
:arrow_down:

internal/backend/b2/b2.go
0% <0%> (-78.95%)
:arrow_down:

internal/backend/swift/swift.go
0% <0%> (-78.45%)
:arrow_down:

internal/backend/gs/gs.go
0% <0%> (-73.61%)
:arrow_down:

internal/backend/azure/azure.go
0% <0%> (-69.46%)
:arrow_down:

internal/backend/swift/config.go
36.95% <0%> (-54.35%)
:arrow_down:

cmd/restic/cmd_mount.go
12.98% <0%> (-44.16%)
:arrow_down:

cmd/restic/cmd_restore.go
53.65% <0%> (-7.32%)
:arrow_down:

internal/restic/node_unix.go
71.42% <0%> (-7.15%)
:arrow_down:

internal/archiver/file_saver.go
81.57% <0%> (-4.39%)
:arrow_down:

... and 6 more

Continue to review full report at Codecov.

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

Fixed in https://github.com/restic/restic/pull/1993/commits/fa81741e8e0e424eb858037b61d01c4d88c58c02 . Now, the error is only supressed if Geteuid > 0 && IsPermission.

Changelog text updated in https://github.com/restic/restic/pull/1993/commits/e42d2d1da81cd766478ee29d3fc07e80ef7cadac !


transaction recovery issue?

See there: https://github.com/borgbackup/borg/issues/2099
Not sure if the bug also happens with attic, but the suspicious code is also in attic:
https://github.com/jborg/attic/blob/0.16/attic/repository.py#L467
@jborg can you remember why you used "ab" (and not "wb") there?
At first glance, it seems to make no sense to append to an existing file, esp. if the file is a valid segment file that has already a MAGIC at the beginning and some entries in it, this would just add another MAGIC in the middle of the file (but that should not be there).
So, was that just a typo or is there some reason behind it?

header_fmt.unpack(b'ATTICSEGx')
(1230263361,<PHONE_NUMBER>, 120)  # crc, size, tag

So the size value to look for in exceptions is<PHONE_NUMBER>.


Trying to use azure shell - encountering [Errno 30] Read-only file system error

I am attempting to follow along with: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/terraform-install-configure
On trying to set the subscription I am getting the following, and googling is providing several cases of other people asking the same question, without resolution. How do I resolve?
[Errno 30] Read-only file system: '/home/kevin/.azure/commands/2020-02-10.02-41-53.account_set.417.log'
Traceback (most recent call last):
File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 206, in invoke
cmd_result = self.invocation.execute(args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 486, in execute
load_cmd_tbl_func=self.commands_loader.load_command_table, args=args)
File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 162, in raise_event
func(self, **kwargs)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/azlogging.py", line 80, in init_command_file_logging
self._init_command_logfile_handlers(cmd_logger, args)  # pylint: disable=protected-access
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/azlogging.py", line 101, in _init_command_logfile_handlers
logfile_handler = logging.FileHandler(log_file_path)
File "/opt/az/lib/python3.6/logging/init.py", line 1030, in init
StreamHandler.init(self, self._open())
File "/opt/az/lib/python3.6/logging/init.py", line 1059, in _open
return open(self.baseFilename, self.mode, encoding=self.encoding)
OSError: [Errno 30] Read-only file system: '/home/kevin/.azure/commands/2020-02-10.02-41-53.account_set.417.log'
To Reproduce:
Browse to shell.azure.com and sign up a pay-as-you-go subscription

Put any pre-requisite steps here...
az account set --subscription {}

Environment Summary
Linux-4.15.0-1067-azure-x86_64-with-debian-stretch-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.81

Additional Context

Tried again this morning - seems to work fine. A provisioning issue perhaps?

Maybe it's due to the failure of Authentication. Please try to login manually by running: az login


Chunker Offline

What feature would you like seen in Chunker?
Can you guys make Chunker work offline. My internet is really bad, so any time I want to use the internet I would have to go to the library. I noticed that Chunker won't open the world unless it online conected to a server somewhere. In other words I can't do my work on the go or at home.

Chunker doesn't/shouldn't use the internet apart from when you initially download it from GitHub. I've done two basic tests to ensure this is still the case:

Disabled my internet via Network Connections and verified I could open Chunker and convert a world
Created a Windows 10 Virtual Machine that doesn't have internet and copied Chunker to it via USB and verified I could convert a world.

If you're able to provide more details on the OS that this happens on / logs from %APPDATA%/chunker-electron/logs we can look further.


GRADLE-3276 Generate Scala SDK instead of Scala facet to support Intellij IDEA 14+

All the details should be in here https://issues.gradle.org/browse/GRADLE-3276

@nicklasbondesson, thanks for the submission. Our bandwidth for reviewing PRs is a little limited at the moment as we are focusing our efforts on getting the Gradle 2.5 release out the door. We will take a look at this as soon as we can.

@mark-vieira my pleasure. Will someone have a look soon?

A friendly reminder..

We appreciate the work put into this pull request.
The Gradle team doesn't currently have the capacity to deal with all of the bugs, feature requests, great ideas and pull requests that we receive. We already have a pretty big backlog, so it might take some time for us to take a look at this.
Pull requests are interesting because they may seem like they come for "free". Our experience has shown that in order to maintain the level of quality and consistency that Gradle users expect, we need to invest significant engineering effort in all but the most trivial PRs.
We are actively recruiting to increase our engineering team, so hopefully this is a temporary situation. We ask for patience in the meantime.

Thanks for the update.

This strikes me as quite useful, would be great if this could get reviewed and merged.

Any plans on merging this one in?

@bigdaz how's the recruiting going? Any chance someone will have a look soon?

Pinging you @big-guy since you where my first ever Gradle contact. Perhaps you have some time to spare for this?

I would really love to see this merged as well. Currently it's a very cumbersome process every time there's a dependency change, which involves closing intellij, gradle cleanidea idea, converting project again, rm -fr projectFilesBackup* ...

+1 on getting this merged. Feeling left behind still having to run IntelliJ 13, especially now that 15 is just released :)

IntelliJ IDEA 15 has pretty good built-in support for Gradle from my experience? Any reason why you can't just use that? (simply curious)

No reason, just haven't explored that yet.

@nicklasbondesson Taking a look at this again I believe this would introduce a breaking change for those folks still using IntelliJ 13. We don't want to lose support for older IDEs so we should continue to support both. This would likely mean adding some property to IdeaModel allowing the user to specify which version of the IDE they were using. We could potentially then "break" folks by defaulting to a later version but still allow them to explicitly generate the older metadata.
Would you be up to making the necessary changes to allow for this?

@mark-vieira Yep, I'm up for it.

@mark-vieira all done. Can you please take another look?

@nicklasbondesson I'm looking at this now. We are beginning to prepare for the 2.11 release so right now I am looking to get this included in 2.12.

:+1:

Looks like Travis is a bit sad. Why is that?

Looks like failures due to unrelated changed introduced into master, you can disregard.

@nicklasbondesson this has been merged into master and will be included in Gradle 2.12. Thanks for the contribution.

@mark-vieira Cool, thanks. I can see that you made some modifications to my commit. Is it possible to set the targetVersion property on the IdeaModel from the command line, gradle properties or system properties? I think the best way would be if you could set/override the value from your local environment since it is not certain that everyone on a team will be running the same Idea version.

You could simply set targetVersion to the value of a project property if it exists.
targetVersion = project.hasProperty('ideaVersion') ? project.property('ideaVersion') : null

Then you can do something like gradle build -PideaVersion=13

Yeah, that's pretty much what I did. But the code was changed by someone before you merged. Maybe you could add that?

The difference being that we don't want to look for this from a project property by default. The source of truth is IdeaModel.targetVersion. Whether this is hard-coded in the build script or set to a value retrieved from an external property is not important. We simply want to avoid using implicit properties as inputs to the build. There are several reasons for this:

They are difficult to document. It usually means someone has to read the user guide to know about them rather then showing up in the DSL reference and JavaDocs
Type safety
Extension properties can be set in a nearly unlimited number of ways, project properties are more limited in how they can be set. We are simply aiming for flexibility.

Also, just to clarify, my code example above would be something that should be in the build script, not the implementation for the 'idea' plugin.

Thanks, it all makes sense :+1: I think I was mislead by not seeing the enclosing idea { } for the targetVersion assignment in your example before.


Revise eslint settings for travis tests

Pull Request Test Coverage Report for Build 78

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 77:
0.0%

Covered Lines:
29

Relevant Lines:
29

💛  - Coveralls


Minor grammatical errors in the README.md file.

There are minor grammatical mistakes that needs to be corrected which will enhance the file.

Hello Mam! Can I work on this?

Hello, Can I work on this? @purnima143

@purnima143 Please assign this issue to me I am beginner and would like to contribute to this project


Add links to GitHub sample code downloads

Issue
Add links from Chapter 5 to the GitHub samples, for population-analysis, gradebook, and stock-fetcher samples.

Fixed in version 1.1


Screenshots updated in readme and screenshots folder name changed to Assets

Screenshots updated in readme and screenshots folder name changed to Assets #27

Remove unwanted assets in the assets folder.  Make sure the heads are even.

Hello @pushpinderpalsingh , just checking that this is the same Assets that you intend my issue's spaceAgencies.md (#34 ) to be listed under?
I just want to be sure to rebase on these changes if they're going to be merged within this weekend to avoid conflicts. 💪

@jamie-brannan you can just add the spaceAgencies.md under screenshots.

@gokulkannan7 are you working on this?


Dbcp 482 instance not found exception

Thanks for the pull request! 👍
It was merged by @garydgregory in https://github.com/apache/commons-dbcp/commit/c96a7ad5ab1d8c3ee722e5895f57f54e02e39ec8
Can you please close the pull request? (I can not do it myself because this is a read only mirror).
Thanks!

This change was released in version 2.3.0.


Clarify: scope includes but is not limited to k8s.

Based on the discussion in today's SMI working group for multi-cluster, we want to clarify that SMI includes but is not limited to Kubernetes.
This changes "a specification for service meshes that run on Kubernetes" to "a specification for service meshes, with a
focus on those that run on Kubernetes".
If we can have maintainers indicate their approval of (or changes to) this PR, that will serve to indicate consensus.
Signed-off-by: Bridget Kromhout<EMAIL_ADDRESS>

LGTM


Multi-tenancy is not working

Hi There,
It is a great plugin for the single admin panel.
This plugin is not working in the filament's multi-tenancy.
If I add a single line to the resource page of the plugin, it works like a charm.
protected static bool $isScopedToTenant = false;

If I extend the resource still it is not working.
<?php

namespace App\Filament\Member\Resources;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Builder;
use TomatoPHP\FilamentWallet\Filament\Resources\WalletResource as TomatoWalletResource;

class WalletResource extends TomatoWalletResource
{
    protected static bool $isScopedToTenant = false;
}

you can extend the Resource and allow scope, and I will add it as an option to allow tenants on all tomato echo system packages.


Certificate Push Management Inquiry

Please provide us with the following information:

This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Calling the Push Management methods, "CreateSigningRequest" or "UpdateCertificate", the client recevies:

UaMethodException: status=Bad_InvalidArgument, message=One or more arguments are invalid.

However, going through the simulator logs I'm unable to find the exact argument that is invalid or any other information from the logs. Also, I'm not sure if the methods are implemented, could you tell me if the methods are implemented as well?

Any log messages given by the failure

N/A

Expected/desired behavior

Response or logs stating the error if any.

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful
I'm using this https://reference.opcfoundation.org/GDS/v105/docs/7.10.7 to provide the arguments.

Thanks! We'll be in touch soon.

In order to execute a certificate signing request, ensure to be authenticated with a secure session as administrator.
see here for the call: https://github.com/OPCFoundation/UA-.NETStandard/blob/29a3be5533ce4027f394995a7343c1ce91969851/Libraries/Opc.Ua.Gds.Client.Common/ServerPushConfigurationClient.cs#L568
some arguments expect null versions of the datatypes or are not supported.

@qwertyKeypad do you need further help?

No response


pi400kb uses 100% CPU on one core

Could be fixed by adding an usleep() in main processing loop:
https://github.com/Gadgetoid/pi400kb/blob/feature/toggle-hook/pi400.c#L202-L248

I would recommend using poll or epoll (or even select) instead of a usleep since it is designed exactly to solve this problem... it will wait (efficiently) until there is activity on any of the file descriptors you are watching.

@gpetersson agreed- forgot about those! This grew from a very rough gist prototype into a more mature project quite suddenly 🤣

I made a PR that uses poll(), if only for testing. Seems to work fine for me.


Adding FUSE HGFS mount option

This is to enable the new FUSE HGFS feature with open-vm-tools 10.x, FUSE mount is going to be the default for any Linux Kernel > 4.x.
This maintains backwards compatibility with previous open-vm-tools versions that used the vmhgfs kernel module.

LGTM cc @ehazlett


[fixture definition] add emitters layout parameters

One more thing is needed in fixture definitions to help out the previews and avoid guessing.
As mentioned here, the 2D preview tries to understand the heads layout by doing some spatial calculations.
However, this mechanism fails on several cases.
Moreover, there are 2 other cases not considered at all at the moment:

some blinders have multiple emitters, but they usually work together. Right now QLC+ shows just one emitter representing all of them
fixtures have multiple operational modes, and across modes, heads can be different. Some LED bars have modes with a limited number of channels, but the light emitters are physically always the same.
Example 3 DMX channels: intensity, shutter, color macro --> 8 physical emitters.

The proposal is to add 2 new fields to physical properties to indicate the emitter matrix Width x Height.
In XML could be something like this in the Physical section:
<Layout Width="8" Height="1" />
The default will be 1x1 and if not changed, it won't even be saved in XML. This is to avoid changing all the current definitions and avoid to waste space.
@fxedel @FloEdelmann sounds good ?

This definitely sounds good, as it will fix the pixel arrangement for many matrix heads!
1x1 will result in the current behavior (ratio guessing)?
What if the amount of specified heads is higher or lower than width*height? Is this an error? And will empty heads be allowed now?

Leaving 1x1 and then definining let's say 6 heads, the latter will have precedence, as it is an explicit user setting.
Mode heads lower than physical heads could follow these rules:

1 head should never be defined cause it's the default. I've seen so many wrong definitions where users added all the channels to 1 head. No need. QLC+ implicitely define at least one head, and autodetects channels
I've seen bars with DMX modes to group LEDs. Example: 8 physical emitters, 4 heads (or zones). The behaviour will be guessed and first head will control LED 1 & 2, seconds head 3 & 4 and so on.

At least, this is how they usually work. Edge cases will probably rest uncovered.

That sounds really nice to me! I guess this will be an addition to the multihead branch / QLC+ 5 fixture format?

Definitions are in common, so QLC+ 4/5.
Multihead branch, yes, that was the idea.

@mcallegari That's pretty cool! The preview actually shows the correct pixel amount, even if only one channel is specified :+1:
I haven't noticed yet that you changed the spec to include width/head in the physical section, not in the heads section. This definitely makes sense!
Is it allowed (or recommended) to reuse a channel in the heads section? For example to define an even/odd mode:
 <Mode Name="Even/Odd">
  <Channel Number="0">Dimmer odd</Channel>
  <Channel Number="1">Dimmer even</Channel>
  <Head>
   <Channel>0</Channel>
  </Head>
  <Head>
   <Channel>1</Channel>
  </Head>
  <Head>
   <Channel>0</Channel>
  </Head>
  <Head>
   <Channel>1</Channel>
  </Head>
 </Mode>
 <Physical>
  <!-- ... -->
  <Layout Width="4" Height="1"/>
</Physical>

Layout is definitely a physical property. See the updated fixture editor panel:

Re-use channel in heads: doesn't make much sense to me from a pure definition perspective.
If that helps QLC+ preview though, maybe it could work. Never tried actually


Assigning TA's to sections

Proposed Changes
Add functionality to assign TAs to specific sections:
Add a new button to the graders page called "Assign by Section".
When the button is clicked, open a new modal that has a form that displays a list of all course sections, and next to each section is a dropdown with a list of TAs (plus an "empty" option). So, each section can be assigned at most one TA using this form. [If an instructor wants to assign multiple TAs to the same section, they'll need to submit the form multiple times.]
When the form is submitted, the controller assigns the TAs to all groups in their assigned sections. Note that all existing TA assignments remain unchanged; this form only adds new TA assignments.

Screenshots of your changes (if applicable)

Associated documentation repository pull request (if applicable)

Type of Change
(Write an X or a brief description next to the type or types that best describe your changes.)

Type
Applies?

🚨 Breaking change (fix or feature that would cause existing functionality to change)

✨ New feature (non-breaking change that adds functionality)
X

🐛 Bug fix (non-breaking change that fixes an issue)

🎨 User interface change (change to user interface; provide screenshots)

♻ Refactoring (internal change to codebase, without changing functionality)

🚦 Test update (change that only adds or modifies tests)

📦 Dependency update (change that updates a dependency)

🔧 Internal (change that only affects developers or continuous integration)

Checklist
(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)
Before opening your pull request:

[X] I have performed a self-review of my changes.

Check that all changed files included in this pull request are intentional changes.
Check that all changes are relevant to the purpose of this pull request, as described above.

[ ] I have added tests for my changes, if applicable.

This is required for all bug fixes and new features.

[ ] I have updated the project documentation, if applicable.

This is required for new features.

[ ] If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

[ ] I have updated the project Changelog (this is required for all changes).
[ ] I have verified that the pre-commit.ci checks have passed.
[ ] I have verified that the CI tests have passed.
[ ] I have reviewed the test coverage changes reported by Coveralls.
[ ] I have requested a review from a project maintainer.

Questions and Comments
(Include any questions or comments you have regarding your changes.)
Question 1:
Want to know if I'm on right track with the way I'm approaching this. So far have made mostly front-end changes and have tracked down where the back-end changes need to be made.
Question 2:
When I try to actually click on the Assign TA's button, it currently doesn't render the modal I defined and instead blanks out the screen.

I've retraced my steps and even looked at how the other buttons work, but I'm unsure about what I'm doing wrong.
Question 3:
I'm trying to figure out how the data of a grader and a section is stored so that I can access the right attributes. Currently I've been looking at what pops up after doing "graders." and how other parts of the code use it but what would be the right way to track down the actual class definitions to see what attributes are there or what the format of the data retrieved is?

@AinaMerch thanks for the update, you're on the right track. 👍
A blank page typically means there's a Javascript runtime error. You can see error messages and tracebacks in the Javascript console (part of your browser's developer tools).
Remember that entities are generally defined as model classes, so looking at the relevant model classes is a good place to start. Another good technique is that when you're loading a page that seems to have relevant data (e.g. the "graders" tab you're currently using), use the Network tab to see what requests are being made. This will help you see the response that you're getting back as well as seeing what route is actually being used, which can then lead you to the relevant controller method. Note that for many of the pages, there's an initial request that loads the page, and then a separate request to load data for the tables.


Close-ExcelPackage can't accept a null password with -SaveAs

I have tried to write a script to remove passwords from Excel workbooks based on this sort of logic
$Password  = $null
$temp        = Open-ExcelPackage oldfile.xlsx -Password password1
Close-ExcelPackage -ExcelPackage $temp -SaveAs newfile.xlsx -Password $Password

If I supply no password parameter it saves the file with the original password as you'd expect
If I supply a new password string it saves the file with that, again as you'd expect
If I set $Password to equal $null or "" or '' no file is saved
Without this option how can I remove passwords from Excel workbooks

Would've been surprised if that worked!
Never thought of supporting that, Remove-Password would be the function name.
Search for EPPlus and remove password. Let me know if you find something.
May be an easy way to use or add this as a feature.

I assumed it would be easy, and read this post https://stackoverflow.com/questions/42860894/remove-known-excel-passwords-with-powershell where one response states that he used ImportExcel to achieve it. Wondering what he did.

yeah that is v5|v7 of EPPlus. This module uses v4.x of EPPlus. They may have had a solution or workaround.
The solution looks like what I was going to suggest off the top of my head, and has nothing really to do with the module.
It uses Import-Excel to read the xlsx and then Export-Excel to save it to a file without a password.
👉 NOTE: Import-Excel only read the data, no formatting etc, etc, etc


Error Installing cfssl

Hi!
Good Day!
Just want to know if anyone also encountered the same during installation of k8s (on-prem) using pharos?
It didn't push thru and only stack in "====> Configure cfssl @ master" (below output).
Any help would be much appreciated.

I did not encounter the error when I use debian 9.

#1556 might have fixed this.

#1556 might have fixed this.

it did, can we release it ?


Mouse without borders, keyboard issue

Microsoft PowerToys version
0.74.0
Installation method
PowerToys auto-update, Microsoft Store
Running as admin
None
Area(s) with issue?
Mouse Without Borders
Steps to reproduce
"I am using 'Mouse without Borders' to connect my desktop and Surface Pro 8 for simultaneous use. I want to use the mouse with the desktop and the keyboard with the Surface Pro 8. However, for the Surface Pro 8 keyboard to work, the mouse cursor of the Surface Pro 8 needs to be on the desktop screen, and if the mouse cursor of the desktop is on the desktop screen, the Surface Pro 8 keyboard does not function.
✔ Expected Behavior
"I wanted the keyboard to input regardless of which screen the mouse was on."
❌ Actual Behavior
even when I want to use the mouse connected to the desktop while using the Surface keyboard on the desktop, I have to manually move the mouse back to the desktop using the Surface touchpad for the keyboard to work properly.
Other Software
Desktop : window 10
surface pro 8 : window 11

Hi, thanks for the report.
Can you try toggling "Use service" to see whether it makes any difference?
/needinfo

Hi, thanks for your support.

However, for some reason, enabling the 'Relative mouse movement' option (the name may not be exact as it's a translation from Korean) solved the problem.
But, this solution is quite unstable. There are moments when the keyboard suddenly stops working when I touch touchpad(At that moment, the mouse moves to the Surface screen). Nevertheless, I am currently using this temporary workaround.

Are you still experiencing this issue? /needinfo


0.19.4/0.19.5 upgrade - looking for testers

I have been testing the 0.19.4/0.19.5 upgrade on a small, brand new 0.19.3 deployment. Everything worked fine. Huge thanks to @pallebone for pointing out pgautoupgrade to me, I really had no idea it existed, and it's a huge reason this is able to be so seamless.
However, I still have some concerns about how this auto upgrade will work on large instances:

pgautoupgrade is great, but how stable is it on very large databases. And, how long does it take?
pictrs was bumped to v0.5, which will also perform its own internal database migration. How stable is it, and how long will it take?

In addition, the official Lemmy deployment now recommends this custom Postgres config:
https://github.com/LemmyNet/lemmy-ansible/blob/main/examples/customPostgresql.conf
So far, my own single user instance has worked fine without any configuration, and even with a remarkably small 64MB SHM size, which is still the default.
I am tempted to ship this as the default here too, but I know a good handful of people use my project because I support 32-bit ARM deployments, and many of those SBCs have very low system RAM. As the above custom Postgres config wants a 2GB SHM size, I don't think those ARM users will be very happy. Feedback on this is welcome, though I will probably end up keeping the defaults untouched, and linking users to this config for extra performance.

TL;DR - I would like some feedback before I make this an official update. I will give instructions on how to perform this test. Here is what I am looking for:

How large was your Postgres volume before and after the upgrade?
How large was your Pictrs volume before and after the upgrade?

Both can be calculated by running docker system df -v

If you add the above two volume sizes together, did you have that much disk space free before the upgrade?

I want to test what happens if someone with low disk space attempts an upgrade

If possible, please give a rough time of how long the Postgres migration took.
I have turned off the time limit for the Lemmy-Easy-Deploy health checks.
Any issues? Does everything still work, like federation?
Any other comments/concerns/thoughts are more than welcome!

For the love of everything, PLEASE make a backup that you are 1,000% certain you can easily and quickly restore.
I have only tested pgautoupgrade on a nearly empty Lemmy deployment, I do not know what to expect from real-world servers. Please, make a backup and run through a restore process before trying this.
How to test:

Navigate to your Lemmy-Easy-Deploy folder
Run: git pull && git checkout 0.19.5-migrationcheck
Run deploy.sh like you normally would

Everything should be automatic from there, but I have turned off the time limit for the deployment health checks - for all I know, someone's Postgres migration might take 2 hours or something crazy.
I will do my own testing as well, and if I am satisfied with my own testing and/or the responses here, we will be good to go!

Unfortunately, 0.19.4 is an enormous update that requires manual user intervention to upgrade from Postgres 15 to 16, and some minor oversight when migrating from Pictrs 0.4 to 0.5:
https://github.com/LemmyNet/lemmy-ansible/blob/main/UPGRADING.md
A database upgrade is not something I'm comfortable with automating for the user, and the upgrade script they provided is currently not working on my own server (they didn't really add any error checks... at all).
I don't want to be overwhelmed with reports of people breaking their Lemmy-Easy-Deploy systems, so I need time to think about how to approach this properly.
I've already spent 3 hours today fixing my container builds for 0.19.4, and working on other 0.19.4 changes and unfortunately I don't have any more time to give to this today.
Feel free to suggest things in here, but otherwise I'm going to need more time to sort out this huge breaking change. I will add safeguards to Lemmy-Easy-Deploy to prevent users from upgrading to 0.19.4 for the time being.
In the meantime, I'll be rolling back my own deployment to 0.19.3.

Currently, the upgrade script provided by Lemmy is not compatible with Lemmy Easy Deploy, as it does not take into account the Compose project name.
If anyone has any free time and expertise, any help with migrating is greatly appreciated. I can do all of this myself at some point when I have free time, but I have very little of that this weekend.
Sorry for the inconvenience!

If you need any testers just give me a yell here or<EMAIL_ADDRESS>I can have a quick look at the db script today but no promises

I can test also

Please look at this: https://github.com/pgautoupgrade/docker-pgautoupgrade

That's probably going to save me a lot of time, I will very likely be using this. Thanks @pallebone !

Hi everyone, I have been testing some changes for the 0.19.4 migration. I've updated the original post with instructions on how to test, and some requests for feedback.
If pgautoupgrade really is as magical as it seems, and it holds up even for the largest Lemmy databases, then we are in very good shape. I'm actually wondering why Lemmy doesn't ship something like this by default, it is very nice.

I have some comments to add to this but will only be able to mention them tomorrow especially regarding posgres ‘ I am tempted to ship this as the default here too’
This sounds like a bad idea as it required specific setting that you wont know in advance depending on compute and memory size of the host running the dockers. Let me check my setup and see how I have it vs what the devs recommend.

"However, I still have some concerns about how this auto upgrade will work on large instances:
pgautoupgrade is great, but how stable is it on very large databases. And, how long does it take?"

Will take a while, but no way around it. My DB is 25GB so I can tell you how long it will take on that when you have a working script. I expect about 1 minute per GB so approx 25-35 minutes.
"    pictrs was bumped to v0.5, which will also perform its own internal database migration. How stable is it, and how long will it take?"
It is imperative that the update script allows us to pause and or continue after each step. IE: first it must upgrade postgres, then wait. Then after we can check everything is working, we must be able to continue with lemmy update, then stop, and finally do the pictrs update. I dont recommend doing all 3 in one step as it will make troubleshooting very difficult and obtuse.
"In addition, the official Lemmy deployment now recommends this custom Postgres config:"
I dont reccomend setting "defaults" but rather only suggesting values. My customPostgresql looks like this:
max_connections = 256				# max_connections * work_mem = max memory used by connections eg: 256*8=2GB RAM for connections
shared_buffers = 2GB				# set to 25% of physical RAM
effective_cache_size = 4GB			# set to size of disk swap (zram does not count)
maintenance_work_mem = 1GB			# set to 1/8 of server RAM
checkpoint_completion_target = 0.9		# suggested value
checkpoint_timeout = 61min			# suggested value
wal_buffers = 128MB				# set to approx 5% of shared buffers, power of 2
default_statistics_target = 250			# suggested value either 100, 250 or 500
random_page_cost = 1.1				# suggested value
effective_io_concurrency = 200			# suggested value
work_mem = 8MB					# see max_connections. Larger value = faster SQL queries if they require large amount of memory, small value = less RAM usage
min_wal_size = 2GB				# suggested value, larger not normally required
max_wal_size = 8GB				# suggested value, larger not normally required
max_worker_processes = 6			# normally 6/4 of CPU threads
max_parallel_workers_per_gather = 3		# normally 3/4 of CPU threads
max_parallel_workers = 6			# normally 6/3 of CPU threads
max_parallel_maintenance_workers = 0		# for docker = 0, not docker = 3/4 CPU threads
synchronous_commit = off			# use this value unless troubleshooting
huge_pages = on					# required modification of system, will crash postgres if turned on. leave off unless you have hugepages.
autovacuum_vacuum_scale_factor = 0.05		# more agressive vacuum
autovacuum_vacuum_insert_scale_factor = 0.05	# more agressive vacuum
idle_in_transaction_session_timeout = 10860000	# timeout idle transactions after 181 minutes
idle_session_timeout = 10920000			# also timeout idle sessions at 182 minutes
temp_file_limit = 10GB				# suggested value
#statement_timeout = 1440000			# timeout statements that take longer than 24 minutes
statement_timeout = 14400000
lock_timeout = 1340000				# timeout statements that try to lock a table, index or row etc for more than 11 minutes

some differences include:
max_connections (devs have no clue why 200 works better, my config shows calculation).
shared_buffers (same as above)
effective_cache_size (they set arbitrary value)
maintenance_work_mem (again, no understanding of value)
wal_buffers (their value is not correct)
work_mem (their value will result in higher CPU)
max_worker_processes (depends on no of CPU cores)
max_parallel_workers_per_gather (as above)
max_parallel_workers (as above)
max_parallel_maintenance_workers (their vacuum will never run on their value as its a docker container, so no auto vacuum will ever be completed in their DB).
Since their values seem mostly arbitrary (probably guessed from trial and error rather than a deep understanding of the settings) I dont reccomend them. I include my config above with how to derive the values.
"If you add the above two volume sizes together, did you have that much disk space free before the upgrade? "
Most likely you will need free space x2 of the postgres DB or in my case approx 50-60GB.
The sled DB is very small (300-400mb) so this is not a large db to upgrade.
Most of the update will revolve around postgres imho.
Pete

Great feedback, thank you!

It is imperative that the update script allows us to pause and or continue after each step. IE: first it must upgrade postgres, then wait. Then after we can check everything is working, we must be able to continue with lemmy update, then stop, and finally do the pictrs update. I dont recommend doing all 3 in one step as it will make troubleshooting very difficult and obtuse.

Currently, there is no special upgrade script, it is just a normal Compose deployment that starts all services at once, like it always has. The only difference here is, I've changed the Postgres container to pgautoupgrade. The Pictrs container already performs a self migration.
I could try to start each container one at a time in an intelligent order, then wait for the container to appear healthy before moving on. I'm just not sure how to detect when a migration is in progress or complete. My current deployment was written to expect instant container crashes, so it considers a container that has been running consistently to be healthy.
I'll try to come up with something more reliable. But even in the current state, your deployment should work fine, Lemmy will just report errors in the frontend until the migrations are complete and the backend containers are operational.
Side note, Lemmy just released 0.19.5, and it doesn't require any compose changes. This means you can use the branch I listed above, and it will automatically grab 0.19.5 instead.

Alright what are the steps to try an upgrade? I can maybe try this tomorrow.

They're in the first message of this issue, near the bottom (preceded by a very large and obnoxious warning 😄 )

I'm writing something in a different branch that will properly check Postgres via pg_isready before moving on.
I want to do something similar for pictrs, but their built in /healthz endpoint doesn't seem to really do anything.
I'll look into doing proper checks for the Lemmy backend as well. I'll make sure this is all working properly before I make this an official update.

I have made some significant changes to how Lemmy-Easy-Deploy does health checks based on @pallebone 's feedback.
Now, every service has a unique health check that it must pass before it is considered deployed. Each service deploys one at a time, provides log snippets every 15 seconds, and provides the opportunity to abort the deployment with CTRL+C without completely killing the containers.
Because of this change, the time limit on deployments have been disabled. If there is a fatal error, it will be up to the user to recognize that from the logs and press CTRL+C to abort.
All of this will allow you to carefully monitor the progress of any migrations, and step in if needed.
This change is now available on the 0.19.5-migrationcheck branch. I have updated the commands in the first post to use this branch instead for testing.

Ok cool I will take a look at this tomorrow.

Before
lemmy-easy-deploy_pictrs_data
247.4GB
lemmy-easy-deploy_postgres_data
39.18GB
After
lemmy-easy-deploy_pictrs_data 250.1GB
lemmy-easy-deploy_postgres_data 38.56GB
~15 minutes for migrations. Everything seems good.

Woah, only 15 minutes for that much data? And with not a lot of disk space left?
That's pretty incredible, I'm very happy to hear it went smoothly!
Thanks for testing!!

Thank you for the awesome work!

My experience:
16 min past hour - backup
19 min past hour - start deploy.sh
22 min past hour - completed downloading dockers, began updating.
postgres seemed almost instant, pictures then started at about 23 min past the hour.
29 min past hour:
pictrs crashed:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SPANTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
lemmy-easy-deploy-pictrs-1  |
lemmy-easy-deploy-pictrs-1  |
lemmy-easy-deploy-pictrs-1  |    0: pict_rs::repo::migrate::do_migrate_hash_04
lemmy-easy-deploy-pictrs-1  |       at src/repo/migrate.rs:289
lemmy-easy-deploy-pictrs-1  |    1: tokio::task::runtime.spawn with kind=local task.name= task.id=1566444 loc.file="/workspace/asonix/pict-rs/src/repo/migrate.rs" loc.line=112 loc.col=17
lemmy-easy-deploy-pictrs-1  |       at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.38.0/src/util/trace.rs:17
lemmy-easy-deploy-pictrs-1  |
lemmy-easy-deploy-pictrs-1  |
lemmy-easy-deploy-pictrs-1  | Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
lemmy-easy-deploy-pictrs-1  | Run with RUST_BACKTRACE=full to include source snippets.
This issue was resolved in pictrs 0.5.15 but deployed version was 0.5.
ctrl-c
Manually edited the docker compose file to upgrade pictrs to 0.5.15
ran this command:
docker-compose -f /lemmy/Lemmy-Easy-Deploy/live/docker-compose.yml -p "lemmy-easy-deploy" up -d && docker-compose -f /lemmy/Lemmy-Easy-Deploy/live/docker-compose.yml -p "lemmy-easy-deploy" logs -f | grep -C7 -e ERROR -e WARN
waited for pictrs to recover... took some time.
(Lemmy was up and running at this time, but pictrs continued to "fix" itself and migrate.)
41 min past hour - all is completed.

Also changed in docker compose the postgres to postgres:16-alpine

Thanks for finding and reporting that Pictrs issue!
I have been trying to keep parity with the "official" Lemmy deployment, and I noticed they reverted from Pictrs 0.5.4 back to 0.5 right before the release of 0.19.4:
https://github.com/LemmyNet/lemmy-ansible/commit/c872f2d1f39dd6db0da7f8a5edbbbe4199d70407?diff=unified&w=1#diff-d3d33979648a9836685e314d1864481561d5130a294cce04be84b03c29abfb08
I'm not sure why this was, but if you ran into an issue like that, I'm definitely going to make pictrs 0.5.15 the default instead.
Appreciate you catching that!

I checked the dockerhub and something else must have been wrong as 0.5 is a tag that pulls the latest 0.5 release so it would have pulled 0.5.16. Unsure why I had an issue in this case.

Hmmmm
You said the issue was resolved in 0.5.15, is there a pictrs issue you were keeping an eye on? I want to read through any similar reports

Hmmmm
You said the issue was resolved in 0.5.15, is there a pictrs issue you were keeping an eye on? I want to read through any similar reports

Unfortunately this in on matrix chat where you can ask the developer for help:

I changed to 0.5 now the upgrade is done and it seems to be working without error using tag 0.5.
Here is my full compose file at the moment:
root@lemmy01:/var/lib/docker# cat /lemmy/Lemmy-Easy-Deploy/live/docker-compose.yml
x-logging:
&default-logging
options:
max-size: '500m'
driver: json-file
services:
proxy:
build: ./caddy
mem_limit: 1024m
mem_reservation: 768m
memswap_limit: 1536m
env_file:
- ./caddy.env
volumes:
- ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
ports:
- 80:80
- 443:443
depends_on:
- pictrs
- lemmy-ui
restart: always
logging: *default-logging
lemmy:
image: ghcr.io/ubergeek77/lemmy:0.19.5
mem_limit: 1024m
mem_reservation: 768m
memswap_limit: 1536m
volumes:
- ./lemmy.hjson:/config/config.hjson
depends_on:
- postgres
- pictrs
restart: always
logging: *default-logging
lemmy-ui:
image: ghcr.io/ubergeek77/lemmy-ui:0.19.5
mem_limit: 1024m
mem_reservation: 768m
memswap_limit: 1536m
environment:
- LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy:8536
- LEMMY_UI_LEMMY_EXTERNAL_HOST=localhost:1236
volumes:
- ./lemmy-ui-themes:/app/extra_themes
depends_on:
- lemmy
restart: always
logging: *default-logging
pictrs:
image: asonix/pictrs:0.5
mem_limit: 1024m
mem_reservation: 768m
memswap_limit: 1536m
user: 991:991
environment:
- PICTRS__MEDIA__ANIMATION__MAX_WIDTH=256
- PICTRS__MEDIA__ANIMATION__MAX_HEIGHT=256
- PICTRS__MEDIA__ANIMATION__MAX_AREA=65536
- PICTRS__MEDIA__ANIMATION__MAX_FRAME_COUNT=400
- PICTRS__MEDIA__VIDEO__ENABLE=true
- PICTRS__MEDIA__VIDEO__MAX_FILE_SIZE=20
- PICTRS__MEDIA__VIDEO_CODEC=vp9
env_file:
- ./pictrs.env
- ./customPictrs.env
volumes:
- pictrs_data:/mnt
restart: always
logging: *default-logging
postgres:
image: postgres:16-alpine
mem_limit: 1024m
mem_reservation: 768m
memswap_limit: 1536m
shm_size: 4g
environment:
- POSTGRES_USER=lemmy
- POSTGRES_DB=lemmy
env_file:
- ./postgres.env
volumes:
- postgres_data:/var/lib/postgresql/data
- ./customPostgresql.conf:/etc/postgresql.conf
restart: always
shm_size: 64m
logging: *default-logging
volumes:
caddy_data:
caddy_config:
pictrs_data:
postgres_data:

Thanks! That makes sense. It looks like it's only an issue with the migration code.
Is it possible you had a pre-downloaded pictrs:0.5 tag that was actually <=0.5.14, which was used instead?
That would explain why 0.5 is working for you now, and why 0.5.15 worked for your migration. I could be more aggressive with the image pulls to help this a little bit.

Its technically possible I suppose but I am unclear how to check this now that I have fiddled around and so on. Either way the big stuff (postgres and lemmy) updated fine. pictrs actually can be completely broken and lemmy still works, just pictures dont work on the site.

Lemmy-Easy-Deploy 1.4.0 has been released! 🥳
Huge thanks to everyone here for helping me test and providing me with valuable insight.
If you helped test, please do not forget to switch back to the main branch:
git checkout main
git pull

Thanks for all your help also :)

Quick FYI - I forgot to change a variable name in 1.4.0, so please update to 1.4.1 or else your Pictrs might be a little broken (presumably anything requiring an API key)
https://github.com/ubergeek77/Lemmy-Easy-Deploy/releases/tag/1.4.1

How can I make this change manually for now?

You can edit ./live/lemmy.hjson to have your correct pictrs API key. But I'm not sure if Lemmy will pick up changes to that file automatically. The backend service may need to be restarted.

With the hot fix, you forgot to update the version number, so it endlessly updates.

Thanks, sigh...

Thanks I will take a look into this tomorrow as its late now.

I changed the version number and re-tagged it as 1.4.1, if you hit "yes" on the update prompt it will sort itself out.
Thanks again for all the testing and reports everyone!

Just thought I would test the script again and get this when I run it:
Lemmy-Easy-Deploy by ubergeek77 (v1.4.1)
Detected runtime: docker (Docker version 24.0.5, build ced0996)
Detected compose: docker compose (Docker Compose version v2.20.2)
Runtime state: OK
Current Backend Version: 0.19.1
Latest Backend Version: 0.19.5
Current Frontend Version: 0.19.1
Latest Frontend Version: 0.19.5
A Backend update is available!
BE: 0.19.1 --> 0.19.5
A Frontend update is available!
FE: 0.19.1 --> 0.19.5
--------------------------------------------------------------------|
|  !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!  |
|                                                                   |
|    Updates to the Lemmy Backend perform a database migration!     |
|                                                                   |
|      This is generally safe, but Lemmy bugs may cause issues.     |
|                                                                   |
|   It is generally recommended to wait a day or two after a major  |
|    Lemmy update, to allow time for major bugs to be reported.     |
|                                                                   |
| If you update, and run into a new bug/issue in Lemmy, you will    |
| NOT be able to roll back, unless you restore a database backup!   |
|                                                                   |
|              LEMMY BACKEND UPDATES ARE ONE-WAY ONLY               |
|                                                                   |
| THIS IS YOUR ONLY OPPORTUNITY TO MAKE A BACKUP OF YOUR LEMMY DATA |
|                                                                   |
| Lemmy data is stored in Docker Volumes, NOT the ./live folder |
|                                                                   |
| Please consult the Docker docs for commands on making a backup:   |
|    https://docs.docker.com/storage/volumes/#back-up-a-volume      |
|                                                                   |
| The most important Volume to back up is named:                    |
|       lemmy-easy-deploy_postgres_data                             |
|                                                                   |

!!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!

Would you like to proceed with this deployment? [Y/n] n
Why does it detect 0.19.1?

I went ahead an updated anyway since you are busy. After upgrade I edited the docker compose file as it leaves this tag for postgres:
pgautoupgrade/pgautoupgrade:16-alpine
I changed it to postgres:16-alpine
I dont think it should leave the upgrade tag as the running database as that will continually check and loop to see if there is an upgrade to do.

The version check is done by reading ./live/version, which is written at the very end of a successful deployment. You had to interrupt your deployment to fix a pictrs issue and then manually redeployed, so the updated version string never got written.
As for pgautoupgrade, it doesn't continually do a version check to my knowledge. After a migration, it just runs Postgres at the very end of the script, and should be a drop in replacement for Postgres:
https://github.com/pgautoupgrade/docker-pgautoupgrade/blob/main/docker-entrypoint.sh
I intend to keep this as the Postgres image moving forward just for future proofing.

Interesting, I dont agree with this change as it means we are no longer tracking the official postgres image and are trusting no issues crop up with a 3rd party project when it is not required to do so for any meaningful benefit once the upgrade is done. However since we can alter the tags ourselves that is acceptable, but you might want to make people aware so they can decide themselves.

I would be willing to accept a PR that does an intelligent check to see if using this image is necessary, but this is the most frictionless option I have right now.
I know it's a third party image, but it's open source and functionally identical to the real postgres image. There should be no compatibility issues. If you're worried about supply chain attacks, I could consider locking it to an image fingerprint depending on the host architecture.

Its ok, Im happy to accept your decision as its your project, and ultimately your reputation. Its also easy for me to change it myself so it does not cause me personally an issue. I assumed it was an error but if you are aware and happy, I am also happy.


Investigate husky, validate-commit-msg, and @studio/changes

To help automate a better changelog/commit messages across-the-board.
remy/clite@fc36b01
Is a reasonable example of a starting point.

Fixed in 402f80b8f8e69a125d4bb9632313ab77b705288e


Ddl plouie.dom 39510.fair message dispatching

What this PR does / why we need it:
Support setting prefetchCount at the channel with a default value of 1 when connect() is called.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

@ddl-plouie Please add checks to the mocks in the unit tests that channel.Qos gets called whenever it should be
Also I just noticed that the consumer_test.go is missing mockChan.AssertExpectations(t) at the end of the test methods, could you add that?

Added mockChan.AssertExpectations(t) in consumer_test.go.  channel.Qos is being called in the tests as the result of invocation of connect().


Bugfix azure sql support

Enable creation of adminuser if Azure SQL

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.telu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


:seedling: Bump Golang to v1.23.4

What this PR does / why we need it: Bump Golang from v1.23.3 to v1.23.4

/test metal3-centos-e2e-integration-test-main
/test metal3-ubuntu-e2e-integration-test-main

/lgtm


tensor_serialization_test fails

Hi,
I'm installing Torch on a new machine and for some reason, I doesn't pass all tests.
At first it did but then I got another error further downstream which needed a reinstall according to this forum. Now it's stuck at an error earlier in the installation process....
I reinstalled everything already a couple of times but it doesn't go away.
Maybe I didn't remove everything properly?
Thx!
Fréderic
Linking CXX executable tensor_serialization_test
[ 92%] Built target tensor_serialization_test
Scanning dependencies of target tensor_test
[100%] Building CXX object test/CMakeFiles/tensor_test.dir/TensorTest.cpp.o
Linking CXX executable tensor_test
[100%] Built target tensor_test
Test project /tmp/fblualib-build.GO9rkm/thpp/thpp/build
    Start 1: storage_test
1/3 Test #1: storage_test .....................   Passed    0.00 sec
    Start 2: tensor_test
2/3 Test #2: tensor_test ......................   Passed    0.17 sec
    Start 3: tensor_serialization_test
3/3 Test #3: tensor_serialization_test ........***Failed    0.03 sec

67% tests passed, 1 tests failed out of 3

Total Test time (real) =   0.21 sec

The following tests FAILED:
      3 - tensor_serialization_test (Failed)
Errors while running CTest

@FredericGodin unless you care about thrift serialization of tensors using fb.thrift, you can ignore this failure.

Hi Soumith,
Thx for the confirmation!
Indeed, I ignored the error and adapted the script.
Torch is running fine for now.
Best,
Fréderic


Backport critical features to branch-1.6

This is not a backport. It's reimplementation. I'm closing this.


Support Permanent Logging-out

The front-end is not allowed to modify it's own cookies, so we need a back-end endpoint for revoking auth keys.

@YRMYJASKA hope you don't mind me assigning you to this - Daniel was saying you don't have many tickets, and this is a mostly back-end issue I think

yeah no problem, I was looking for things to do in any case


feat: Add custom events API

Add a new API - recordCustomEvent(eventType, attributes). This will allow any custom-defined eventType to be stored in NRDB.

Overview
This PR should not be merged until the consumer changes are made to support this API.

Related Issue(s)
NR-339069

Testing
New tests have been added

Shipping experiment to dev env to steel thread with backend changes


Support steam networking sockets interface

It's still a bit rough around the edges, but it should be fairly usable at the current stage. I have one test case that successfully sends messages between a server and a client.
I would have liked to add a higher-level interface as well (like the UDP socket from std), but that would require per-socket callbacks and I wasn't sure how to implement that with the current system.
I started from the pull request by @garyttierney, but I had to make quite a few changes to work with the API.

I just noticed I updated the doc-bindings somewhere along the line, I hope that's not a problem.

sorry, indeed I didn't get the chance to update my messages work! This looks pretty good. I'll get around to finishing the Messages interface sometime this week hopefully.

No problem, I just didn't want to get in your way, but a few things were necessary for the sockets to work.

Actually, I think I will partially rewrite it after all. I think I found a way of handling callbacks for multiple sockets and after seeing the Friend struct, I figured there was still a lot I could improve.

I think this version is a lot more convenient to use. It's still a bit rough, but I think the most important functionality is there.
I tried getting it closer to the TCP sockets in std, with a few changes so all functions can still be used.

@garyttierney I went ahead and implemented the messages interface as well.
I created functions for the callbacks, which is a bit inconsistent with the rest of the wrapper, but this way it's possible to make the API more convenient, in my opinion. For example, instead of returning the NetIdentity directly, the event returns a SessionRequest struct that can be used to accept or reject connections directly.
Of course, I'd be happy to hear other opinions on this!

Hey, sorry for taking so long to get to merging PRs. Whats the status of this code, is it ready for merging? I was thinking we could do a crates.io release after this lands, lots of nice changes have gathered up in the repo.

Hey, no problem, life happens and all.
I'd say it's not perfect, ideally I would make some changes. For example I tried to keep each connection unique, but I think it might be less restrictive if there could be copies of each connection. A closed connection would return an Err, similar to the steamworks itself.
Also doc comments are missing all over the place.
But I don't really have time to make those changes right now and while it's not perfect, I tested it in a project of mine and it seems to work without problems.

Thank you, its now merged. I think its better to have some API than no API at all. I think this is a good time to update the crates.io finally


Feature/asb 304 extend representations endpoint with filter parameters

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Track down ParameterType arity issue

Brine is suffering from an issue where the transform lambdas on ParameterTypes are throwing ArgumentErrors if any optional captures are omitted.
There were issues in earlier versions of cucumber-expressions that should have been patched in the used versions: this may require filing a bug against cucumber but that is being deferred until enough attention can be paid to what is going on and acquiring relevant ruby knowledge. In the meantime some ugly parameter handling will be added to the transform logic.
This functionality should be supported based on the examples in: https://cucumber.io/blog/upgrading-to-cucumber-3/

https://github.com/cucumber/cucumber/issues/375

https://github.com/cucumber/cucumber-ruby/issues/1292
https://github.com/cucumber/cucumber/issues/375

It appears as though the key piece should be handled by the TreeRegexp class in cucumber-expressions which should fill in any absent captures with nils.

Filed: https://github.com/cucumber/cucumber/issues/761

Migrating issue to resolve


RTL support: Date change

Need to support date change in both ltr and rtl mode.
ltr (e.g. 'en') works just fine. However Datetime disables months and years in rtl locale(e.g. 'ar-sa')
codepen example

Thanks @skrasnovskaya
This should be fixed in v3.0-beta.4. This ticket will be closed when version 3 is released.


draft first commit

I am opening this PR, but let's talk about it too and see your thoughts also.
So currently to test a plugin change - you need these changes in gradle build file and issue a simple gradle clean && gradle publishToMavenLocal. Should we have these here and may be add a small documentation note on how to build this if you want to contribute?

I agree it should be easy to publish to maven local for dev purposes and documenting this in CONTRIBUTION.md would be great :+1:
But from my understanding adding the maven-publish plugin is all that's needed for this, the changes to repositories and publishing are obsolete, aren't they?
However, as noted in the further work list we urgently need some tests as sporadic developer tests are not sustainable. Would you be able to draft testing according to gradle plugin development documentation?

you are right, only that plugin is needed.
My main priority right now is to get this working, for all of our uses cases : otherwise I simply can't "sell this" to my team.  As soon as that is done, I hope some of my teammates will jump into helping out here too and provide tests. But even if that does not happen - I will do it at some point in time. When it reaches our production code base, there is simply no other way but for me to get involved and support this; thus proper unit tests.
I hope I make sense.

@jekkel this seems to be ready to go too? no rush, just making sure. otherwise, thank you @kiwi-oss for the comments.

@kiwi-oss could you please re-review?
@wind57 could you remove the "draft" status from the PR if it's good to go from your side?

@jekkel done.

I just noticed the branch is not up to date with the base branch. Could you please rebase? If you like you can also squash or reword your commits while doing this. We like to have meaningful commit messages and commits which contain related changes (take this as a guideline, not a law).


Update imports and exports to ES6

Update all imports from traditional NodeJS require to ES6 imports and the same for exports
This is an update to the back-end.
Old:
const module = require('module'); // Default import
const portion = require('module').portion; // Not default import

New:
import { portion } from 'module'; // Not default import
import module from 'module'; // Default import

Similarly, update all module.exports to use ES6 exports.
Old:
module.exports = module; // Default export
exports.portion = portion; // Not default export

New:
export default module; // Default export
export portion; // Not default export

If approved, I would start working on this. This wouldn't affect the overall performance of the application much, but improve code readability by the usage of modern conventions.
Also, not that this won't be backwards-compatible, though it is the recommended way to import and export in the modern versions of Node.js.

Hey I don't think it's something very much necessary.


Seeking ideas for implementing history

Hi, thanks for the great lib, I'm really enjoying working with it so far.
I'm wondering if you have any suggestions for how I can implement history in my store. I'm struggling to grasp it because the store is only accessible as a draft inside setState, which is always going to be mutated, so as far as I can understand I can only ever do something like draft.history.push( draft ) or draft.history.push( draft.someProp ) within some existing action. Would that make sense? And then could I later even revert to it doing draft = draft.history.pop() or something along those lines?
I haven't really interacted directly with immer (only learned about it through your lib), but obviously draft is not a POJO. Should I look there? Is Middleware the right usecase for this? I'm really not sure...
Anyway I'm going to start trying various approaches and I'd greatly appreciate any insights you can provide to be able to wrap my head around this. Thanks!

Actually I found lots of ideas on the immer page. I opened this a bit prematurely I think, hence closing.


[T5A3][T11-B3] R Dheeraj

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.


use safe functions provided by PSL

Thank you very much for this PR @azjezz . Excellent work. And also learned more about PSL


non-paired comparison stats for DataCollection

closes #53

Current coverage is 82.06% (diff: 46.80%)

Merging #106 into master will increase coverage by 0.05%

@@             master       #106   diff @@
==========================================
  Files            12         12
  Lines          1823       1829     +6
  Methods           0          0
  Messages          0          0
  Branches        341        341
==========================================
+ Hits           1495       1501     +6
  Misses          208        208
  Partials        120        120

Powered by Codecov. Last update 49e13ba...e6b88a5

Current coverage is 83.98% (diff: 97.87%)

Merging #106 into master will increase coverage by 1.97%

@@             master       #106   diff @@
==========================================
  Files            12         12
  Lines          1823       1829     +6
  Methods           0          0
  Messages          0          0
  Branches        341        341
==========================================
+ Hits           1495       1536    +41
+ Misses          208        171    -37
- Partials        120        122     +2

Powered by Codecov. Last update 49e13ba...3952a77