@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.

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).

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

Linux Wayland

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

Gnome

WezTerm version

20220927-071112-9be05951

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:

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

Configuration

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.

Logs

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).

installer.tar.xz Edit (396.6 KiB, application/x-tar)

@Olivier: Sure. This VM was just for testing purposes, so there shouldn’t be anything confidential here.

Screenshot from 2022-09-26 21-01-16.png Edit (159.6 KiB, image/png)

Looks like the deb line for updates is missing entirely from sources.list in this install; only the deb-src is there.

@Steve I did not.

Screenshot from 2022-09-26 19-36-11.png Edit (149.8 KiB, image/png)

@Simon Here goes, although now it just shows both at 9.7, and 9.9 not yet available. Before I downgraded libc6 it obviously showed libc6 at 9.9.

I also tried to reproduce the issue in a fresh VM, but those kept getting 9.9 for all the packages, so installing build-essential caused no issues.

I don’t have in-depth knowledge about phased updates, but this looked like as if downloading the updates during installation was not yet affected by phased updates (and hence got libc 9.9), but, after the installation was completed, the system got cast into a ”still at 9.7” group of phased updates, and so libc6-dev (et al) could not be installed.

Just got hit by the same issue in a VM after a fresh install of 20.04.5. I chose ”Minimal installation”, ticked ”Download updates while installing”, and installed the remaining updates post-install.

After that the first thing I tried to do was to install build-essential, which failed, because the version of libc6 was out of sync with the rest of the libc6* packages: libc6 was already at 2.31-0ubuntu9.9, while e.g. libc6-dev was still only available as 2.31-0ubuntu9.7.

I tried switching from my local archive (fi.archive.ubuntu.com) to the main one (archive.ubuntu.com), but that made no difference. I had to downgrade libc6 to 2.31-0ubuntu9.7 to be able to install build-essential.

Issue

JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

• Did you test in newest Wekan?: 5.90
• Did you configure root-url correctly so Wekan cards open correctly? yes
• Operating System: Ubuntu 20.04
• Deployment Method: snap
• Http frontend if any: Apache
• What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
2. Open a card in Wekan.
3. Select + from the Attachments section.
4. Select ”Computer” from the popup.
5. Select example.json.
6. With the JSON file now attached to the card, select to ”Download” it.
7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.

Logs

Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

• Deleting the attachment seems to work.
• The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Summary

I’m running debsums -c daily, hoping to catch file corruption and/or other abnormalities early. (The Debian package even provides a pre-made cronjob for this task.)

debsums -c gitlab-ce reports .gitlab_kas_secret as deviating from the provided md5sum.

Steps to reproduce

1. apt install gitlab-ce
2. vi /etc/gitlab/gitlab.rb # set external URL
3. gitlab-ctl reconfigure
4. debsums -c gitlab-ce

What is the current bug behavior?

# debsums -c gitlab-ce
/opt/gitlab/embedded/service/gitlab-rails/.gitlab_kas_secret

What is the expected correct behavior?

# debsums -c gitlab-ce
#

Details of package version

ii  gitlab-ce      14.5.1-ce.0  amd64        GitLab Community Edition (including NGINX, Postgres, Redis)

Environment details

• Operating System: Ubuntu 20.04
• Installation Target, remove incorrect values:
  • VM
• Installation Type, remove incorrect values:
  • New Installation
• Is there any other software running on the machine: plenty
• Is this a single or multiple node installation? single

Configuration details

external_url 'http://localhost'

Related issues

#2635 is basically the same, but I’ve never seen debsums complain about schema.rb.