Viestialustana vianhallintajärjestelmät

25.0.3 (as indicated by output from `occ –version` above).

25. tammikuuta 2023 klo 15.01
Sijainti: Vianhallintajärjestelmät: Github

25.0.3 (as indicated by output from `occ –version` above).

Vastaa viestiin sen kontekstissa (Github)

The exit code issue is still there

25. tammikuuta 2023 klo 14.04
Sijainti: Vianhallintajärjestelmät: Github

The exit code issue is still there:

# sudo -u www-data /usr/bin/php /var/www/nextcloud/occ --version
Nextcloud 25.0.3
# sudo -u www-data /usr/bin/php /var/www/nextcloud/occ files:scan -- nonexistantuser
Unknown user 1 nonexistantuser
| Folders | Files | Elapsed time |
| 0       | 0     | 00:00:00     |
# echo $?

Vastaa viestiin sen kontekstissa (Github)

In fact the man page seems to be completely out of sync with reality

22. tammikuuta 2023 klo 12.30
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Logrotate

In fact the man page seems to be completely out of sync with reality. None of minage, maxage, minsize and maxsize appear to work at all despite being documented there. Minage is read at least (according to debug output), but then still ignored. Specifying minsize or maxsize has no effect, logs are rotated when they hit 1 M regardless. At least the plain `size` directive does appear to work as documented.

Vastaa viestiin sen kontekstissa (Launchpad)

”Duplicate log entry” instead of later definitions overriding earlier ones, as man page says

22. tammikuuta 2023 klo 11.50
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Logrotate

The man page for logrotate says ”Each configuration file can set global options (local definitions override global ones, and later definitions override earlier ones)”. This is inconsistent with how it actually behaves.

== Steps to reproduce ==
$ logrotate –version
logrotate 3.14.0

Default mail command: /usr/bin/mail
Default compress command: /bin/gzip
Default uncompress command: /bin/gunzip
Default compress extension: .gz
Default state file path: /var/lib/logrotate/status
ACL support: yes
SELinux support: yes
$ mkdir /tmp/logrotest
$ cd /tmp/logrotest
$ touch test.log
$ touch other.log
$ cat >logrotate.conf
/tmp/logrotest/*.log {
minsize 5M

/tmp/logrotest/test.log {
minsize 1M
$ logrotate –state /tmp/logrostate logrotate.conf

== What happens ==
error: logrotate.conf:5 duplicate log entry for /tmp/logrotest/test.log

== What I expect to happen instead ==
No error, test.log being processed with its specific, later-defined directives.

Vastaa viestiin sen kontekstissa (Launchpad)

Yes, it’s mainly about expectation

11. lokakuuta 2022 klo 19.47
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Hi @hmhealey,

Yes, it’s mainly about expectation. For an actual use case, I noticed this when mentioning an IRC channel name, which became a long, distracting and useless hashtag link, exacerbated by agglutination and multi-word hyphenation typical in Finnish, (e.g. #channelname-irc-kanavalla). I tried to make it less distracting by editing in a preceding backslash, only to discover that it didn’t work here.

Vastaa viestiin sen kontekstissa (Github)

No way to escape a word-starting hash character (#) in plaintext

11. lokakuuta 2022 klo 18.12
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost


There is no way to escape a word-starting hash character (#) in plaintext.

Steps to reproduce

In MM 7.3.0, post this, verbatim: \#anything

Expected behavior


Observed behavior (that appears unintentional)


Possible fixes

Workaround: instead of ”\#anything”, post this: &#​35;anything

Using backticks (`\#anything`) also works, but obviously the word then gets formatted as code and not plaintext.

Other notes

This is mainly an issue of inconsistency and surprise: backslash works to escape most other special formatting, so I’d expect it to work here too.

Vastaa viestiin sen kontekstissa (Github)

Still present in Nextcloud 3.21.2

1. lokakuuta 2022 klo 18.46
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Samsung

Still present in Nextcloud 3.21.2. My device is a Samsung A9 running Android 10.

Vastaa viestiin sen kontekstissa (Github)

If a simple accidental click somewhere could cause this, that’s a loaded gun pointed at the user’s toe

29. syyskuuta 2022 klo 19.46
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Ubuntu

@Julian: I’d argue that if a simple accidental click somewhere can cause this, that’s a loaded gun pointed at the user’s toe, and hence a bug in the installer.

@Brian: I’ll try the 22.04 images. I’ve kept trying with 20.04.5, but have yet to find another instance of this occurring, so it’s obviously not easy to trigger.

I’m not particularly troubled by this issue (and the original reporter doesn’t seem to be either), so feel free to adjust ’Importance’ accordingly.

Vastaa viestiin sen kontekstissa (Launchpad)

I don’t know anything beyond ”this is a standard Ubuntu 20.04 (Gnome) desktop”

29. syyskuuta 2022 klo 11.51
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Gnome, Ubuntu, Wayland, WezTerm

Please tell me more about your window environment; Gnome/Mutter don’t support Client Side Decoration (CSD) for Wayland clients, so wezterm draws its own limited decorations. Those don’t support right clicking or context menus, so I’m not sure how that maximize menu you described shows up.

Sure, though I don’t yet know anything beyond ”this is a standard Ubuntu 20.04 (Gnome) desktop, using Wayland”. Are there any commands I could run to find out more?

Copy & paste doesn’t work in the debug overlay (any selection I make is deselected as soon as I hit Ctrl), but there’s nothing there anyway apart from the intro (no matter how many times I trigger the resizing issue).

Screenshot from 2022-09-29 11-35-40

Vastaa viestiin sen kontekstissa (Github)

Window resizing broken in Ubuntu 20.04 with Wayland

28. syyskuuta 2022 klo 14.13
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: GDM, Gnome, Ubuntu, Wayland, WezTerm

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?


WezTerm version


Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

I’m running a standard Ubuntu 20.04 Gnome desktop, but with Wayland. Resizing of wezterm window is broken on this setup: selecting ”maximize” from the title bar context menu or dragging the window against the top or the sides of the screen doesn’t maximize/tile the window, but any resizing that does happen results in any text entered in the terminal thereafter to be get garbled. In this screenshot I’ve first entered wezterm --version before resizing, then dragged the window against the top, then entered wezterm --version again:

Screenshot from 2022-09-28 13-43-02

To Reproduce

  1. Install your bog-standard Ubuntu 20.04 desktop in a VM and boot it up.
  2. On the GDM login screen select ”Ubuntu on Wayland” from the bottom right menu, then log in.
  3. Install wezterm.
  4. Start wezterm.
  5. Right-click wezterm’s title bar and select ”Maximize”.
  6. Type something


no config

Expected Behavior

After step 5, I expect the window to be maximized (i.e. to fill the desktop). After step 6, I expect to see what I typed.


no logs available

Anything else?

The issue is not present in an X11 session. Ubuntu 20.04 defaults to X11, but I’ve used it with Wayland exclusively since the release without issues. More specifically, I can’t remember seeing resizing issues similar to this with any other application.

I also have a laptop running Ubuntu 22.04 and Wayland, and there all resizing of the wezterm window works just as I’d expect (i.e. just as in any other application).

Vastaa viestiin sen kontekstissa (Github)

Vanhempia »