Summary

Release v1.47.2 was mentioned in another issue’s comments, and Play Store version has indeed been updated, but that release is missing from Github releases.

Steps to reproduce

Open Github releases page for the project.

Expected behavior

Find release v.1.47.2 (or later).

Observed behavior (that appears unintentional)

The current latest release on Github is 1.47.0.

Possible fixes

I don’t know if it’s related, but v.1.47.0 has been tagged ”changeme” instead of the usual vX.Y.Z pattern.

All right, I got curious enough try again, and found that this is apparently caused by the static build of ffmpeg that I’m using: I used yle-dl --verbose again, then interrupted the download immediately, ran the ffmpeg command (as reported by yle-dl) directly, and this resulted in a segmentation fault.

I then tried the same command in a VM with ffmpeg from Ubuntu repositories, and there the download finished successfully.

So the only remaining issue with yle-dl in this is the terminal being broken: that did not occur with directly-run ffmpeg despite the segfault.

I’m closing this issue though, so that it remains as documentation for the problem (and cause) as originally reported.

Trying to download this 7-hour long program only downloads (about) the first 6 hours and 40 minutes (~ 11 GB), after which the process just stops, and leaves Gnome terminal screwed up (typed characters are invisible until I run reset). In the web player the video seems to play past that point just fine.

This is on Ubuntu 20.04 with ffmpeg version N-58594-g715f63232f-static (static build from git master on 20210908).

jani@saegusa:Työpöytä$ /usr/local/bin/yle-dl 'https://areena.yle.fi/1-50934704'
yle-dl 20210808: Download media files from Yle Areena and Elävä Arkisto
Copyright (C) 2009-2021 Antti Ajanki <antti.ajanki@iki.fi>, license: GPLv3

Unsupported codec with id 98313 for input stream 2
Unsupported codec with id 98313 for input stream 5
Unsupported codec with id 98313 for input stream 8
Unsupported codec with id 98313 for input stream 11
Unsupported codec with id 98313 for input stream 14
Unsupported codec with id 98313 for input stream 17
Unsupported codec with id 98313 for input stream 20
Unsupported codec with id 98313 for input stream 23
Unsupported codec with id 98313 for input stream 26
Unsupported codec with id 98313 for input stream 29
Output file: YleX Esittää: Yle 95 - synttäribileet Linkkitornista: 2021-09-18T00:00.mkv
jani@saegusa:Työpöytä$  size=10814976kB time=06:39:40.68 bitrate=3694.5kbits/s speed=  44x

Note the prompt appearing on top of ffmpeg output on the last line. Typing echo $? reveals that the process exited with code 1.

Here’s the output when run with --verbose.

I’ve only tested this over the past couple of days so I don’t know if it’s a temporary error. Since the portion of the stream that I actually care about is all prior to the 6-hour mark, and the partial download is playable, I’m not too bothered to have the rest download. Reporting this just in case it’s a useful test of a corner case.

Describe the bug
The email with updates from the last 24 hours lists identifications, and mentions the name of the user having made the ID. The name is apparently supposed to be listed three times (!), but the middle occurrence is ”untranslated”, resulting in it being rendered as ”User S” for all identifications listed in the email.

Tooltip text for the ”User S” string says ”translation missing: fi.user_s_id”, as I’m using the fi locale, but user_s_id is nowhere to be found in Crowdin, nor in current en.yml, so I suspect this is independent of the locale. The reference to user_s_id is in _update_email_activity.html.

I don’t know if this is doable, but after fixing this broken reference, I’d remove the first (header) mention of the identifier from the email altogether, since it’s followed by a listing of all the new identifiers anyway, so mentioning just the last identifier’s name in the header is redundant and confusing.

Also, rather than fixing/adding the currently broken ”User S” reference in the source, I’d remove it too, since the identifier’s name is already listed (for the third time!) right after the ID.

To Reproduce

1. Subscibe to email updates.
2. Have your observations identified in the last 24 hours.
3. View the email update listing the identifications.

Observed behavior

Expected behavior
(A mockup of how the simplified view I’d prefer to receive. Sorry I didn’t have the email in English to base this on.)

Context
I’m using Gmail with Brave if that’s relevant.

@FlexW I’ve now rebased and pushed the changes, hope this works for you. I don’t see a way for me to merge this myself here, ”Only those with write access to this repository can merge pull requests.”

I can add that to options.rst, but the terse explanation still seems pretty meaningless; at least for me there’s no visible difference when I run nextcloud with --background compared to running without.

This could be due to #2333 though, if running without --background is supposed to open the main dialog (which has never worked on Focal). If so, I’d mention this too, something like: ”Launch the application in the background (without opening the main dialog).”

@FlexW Not really, as I don’t know what the parameter does… due to it being undocumented :) Editing options.rst shouldn’t be an issue, I’d just need to know what it should say about --background.

Preface

Ticking the ”Launch on System Startup” box in the desktop client’s General settings tab (correctly) adds a .desktop file under ~/.config/autostart/, with the following Exec line:

    Exec="/usr/bin/nextcloud" --background

Expected behaviour

The effect of --background should be mentioned in options.rst (and the resulting online documentation).

Actual behaviour

The --background parameter is undocumented.

Client configuration

Client version: 3.2.1
Operating system: Ubuntu 20.04
OS language: English
Client package: 3.2.1-20210429.171749.5901a0f98-1.0~focal1

Summary

After setting up multi-factor authentication, losing the authentication code-generating device means losing access to the Mattermost account. While having MFA is excellent, I’m afraid to set it up for my admin user account (which is the one most critically needing it), because there’s no recovery mechanism in case I lose my authenticator device.

Steps to reproduce

1. Enable up multi-factor authentication in the System Console
2. Configure 2FA with an authenticator app on your phone
3. Break/lose/have your phone stolen
4. Try to log in

Expected behavior

Have a ”use a backup code instead” link next to the MFA token prompt.

Observed behavior (that appears unintentional)

There’s no alternative way to provide the MFA. You can not log in.

Possible fixes

None available AFAICT. There’s no way to add security keys as alternatives either.

There’s an existing Jira ticket ticket about this (and it’s linked to an abandoned PR), but it’s closed as ”moved to ProductBoard for prioritization”, and I don’t know what’s happened since then, as I don’t have access to ProductBoard (that I know of).

Mattermost version

v5.34.2

My go-to way of quickly parsing arguments is as follows:

#!/bin/bash                                                                  
                                                                             
quiet="true"                                                                 
files=()                                                                     
                                                                             
for arg in "${@}"; do                                                        
    case "${arg}" in                                                         
        "-v" | "--verbose")                                                  
            quiet="false"                                                    
            ;;                                                               
        *)
            files+=(                                                         
                "${arg}"                                                     
            )                                                                   
            ;;                                                               
    esac                                                                     
done                                                                         

Beautysh (v6.1.0) incorrectly reports this as indent/outdent mismatch and instead indents it like so:

#!/bin/bash                                                                  
                                                                             
quiet="true"                                                                 
files=()                                                                     
                                                                             
for arg in "${@}"; do                                                        
    case "${arg}" in                                                         
        "-v" | "--verbose")                                                  
            quiet="false"                                                    
            ;;                                                               
        *)                                                                   
            files+=(                                                         
                "${arg}"                                                     
            )                                                                
                ;;                                                           
        esac                                                                 
    done

The deciding factor seems to be the multi-line parenthesis in assigning files. If I assign it all on one line, like this:

            files+=("${arg}")                                                

then beautysh is satisfied with the indentation (i.e. doesn’t change it or report a mismatch).