1.37.0 fails to build in my build environment (Ubuntu 18.04 in LXC) with this error:
ubuntu@mattermost-mobile:~/mattermost-mobile$ npm run build:android
> mattermost-mobile@1.37.0 build:android /home/ubuntu/mattermost-mobile
> ./scripts/build.sh apk
./scripts/build.sh: 3: ./scripts/build.sh: Syntax error: "(" unexpected
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! mattermost-mobile@1.37.0 build:android: `./scripts/build.sh apk`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the mattermost-mobile@1.37.0 build:android script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/ubuntu/.npm/_logs/2020-11-14T11_47_00_288Z-debug.log
The top of that file, build.sh, refers to /bin/sh, but on Ubuntu and Debian, /bin/sh has been Dash for quite a while, whereas build.sh seems to written for Bash (where function is a valid keyword):
ubuntu@mattermost-mobile:~/mattermost-mobile$ head scripts/build.sh
#!/bin/sh
function execute() {
cd fastlane && NODE_ENV=production bundle exec fastlane $1 $2
}
I suggest switching the shebang to #/bin/bash, or better yet, #!/usr/bin/env bash (for path-agnosticity). In my environment, using either one fixes the build.
@tobiasKaminsky Yup, tried it and the issue remains. Also found a device with 3.13.1, and it too is affected now, so this now seems more server-related, though it is weird that the desktop client hasn’t been affected at any point. I would have assumed both clients employ the same webdav commands (and thus fail or succeed just the same).
Syncing a folder in Android app’s ”all files” view also still works (i.e. downloading changes causes no issues).
I have another server instance on another host, and there uploading from Android still works. This (working) instance is unencrypted, while the non-working instance has server-side encryption enabled.
Since recently, editing the description takes two clicks instead of just one. The first click turns the content into a textbox, but it remains unfocused until I click it again.
Issue
Server Setup Information:
- Did you test in newest Wekan?: yes
- For new Wekan install, did you configure root-url correctly so Wekan cards open correctly? yes
- Wekan version: 4.49
- Meteor version: 2.0-beta.4
- Node version: 12.19.0
- MongoDB version: 3.2.22
- Operating System: Ubuntu 20.04
- Deployment Method: snap
- Http frontend if any: Apache
- What webbrowser version are you using? Both Firefox 82.0.2 and Chrome 86.0.4240.183 equally affected.
- If using Snap, what does show command
sudo snap logs wekan.wekan? nothing
Problem description:
Sorry for not providing animation, as peek doesn’t support Wayland. The steps below should be sufficient though.
Steps to reproduce:
- Open a card
- Click on the description once
What I expect to happen:
For the description to have focus (i.e. cursor, to be able to type)
What happens instead:
The description textbox remains unfocused and I can not type into it
Console log contents
site.webmanifest:1 GET https://my-domain.com/site.webmanifest 404 (Not Found)
site.webmanifest:1 Manifest: Line: 1, column: 1, Syntax error.
A bad HTTP response code (404) was received when fetching the script.
mZLgcqMWYXM4o7dmL:1 Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://my-domain.com/') with script ('https://my-domain.com/pwa-service-worker.js'): A bad HTTP response code (404) was received when fetching the script.
It seems to refer to to paths in the domain root, whereas my root-url has the path https://my-domain.com/kan. Not sure if that’s related to the issue or not.
With more verbose logging server-side, there’s a ”Deprecated event type” followed by "Exception":"Sabre\\DAV\\Exception\\NotFound" for the file being uploaded. So it’s perhaps correctly reporting that the file (about to be uploaded) does not exist (yet), but for some reason the app receiving this message flips it around, thinking the file does exist, and thus reports a conflict.
Here’s a logcat snippet from another device. The result of ”Existence check” comes back as ”Name collision”, for any and all files.
This is still an issue, and always has been for Samsung devices with One UI’s scrolling screenshot feature.
In short
Since updating the Android app to 3.14.0 RC1 (and server to 20.0.1 earlier), I can not upload anything with the app. Desktop client still syncs just fine.
Steps to reproduce
Try to upload a file (either manually or by taking a photo for auto-upload)
Expected behaviour
File should get uploaded
Actual behaviour
There’s a notification about ”File upload conflict”. Selecting the notification results in ”Error creating conflict dialog”. Going to uploads view and selecting ”Resolve conflict” for a file just results in ”Sync conflict, please resolve manually”.
Trying to add an account in the app causes the app to crash.
Environment data
Android version: 10
Device model: Samsung Galaxy A9 (2018)
Stock or customized system: stock
Nextcloud app version: 3.14.0 RC1 (from Beta channel)
Nextcloud server version: 20.0.1
Reverse proxy: no
Logs
Web server error log
Nothing NC-related
Nextcloud log (data/nextcloud.log)
Nothing related to the uploads, just
I was affected by this too, but I’m not using encryption:
# sudo -u www-data php occ encryption:status
- enabled: false
- defaultModule: OC_DEFAULT_MODULE
The server log just showed ServerNotAvailableException:"Could not decrypt key" for any connection attempts after 19->20 upgrade.
I have another instance where I am using encryption, and there I was able to log in just fine. I did some diffing and found the working installation (with encryption enabled) had 'encryption.legacy_format_support' => true,, while the non-working installation (with encryption disabled) didn’t. Adding that to my config.php alone didn’t fix the issue, so I also added 'encryption.key_storage_migrated' => false, and after that I was able to log in again.
According to documentation, starting with version 20 the legacy encryption is off by default. occ encryption:scan:legacy-format is supposed to tell whether you can disable the compatibility mode, but for the instance without encryption it seems to produce a false positive (complete with a typo):
All scanned files are propperly encrypted. You can disable the legacy compatibility mode.
For the admin user, the now otherwise working, unencrypted instance also shows a ”Please enable server side encryption in the admin settings in order to use the encryption module” notification in the web UI, for every page load (i.e. even after dismissal it just pops back up whenever I navigate in the UI).
The errors reported by app:check-code encryption are probably unrelated, as the same errors are reported for both my instances.
The version I’m using:
yle-dl 20200807 with wget 1.20.3 (in Ubuntu 20.04)
Steps to reproduce:
$ /usr/local/bin/yle-dl -qq --backend wget --wget /usr/bin/wget https://areena.yle.fi/1-50636796
What I expect to happen:
For the download to complete without any output in the terminal.
What happens instead:
The command outputs this line (which to me seems like is from wget):
2020-09-25 17:25:27 URL:https://ylekaod-a.akamaihd.net/s/p/1955031/sp/195503100/serveFlavor/entryId/1_ldivkmki/v/11/ev/2/flavorId/1_b6wtzy8f/name/a.mp3?__hdnea__=st=1601043921~exp=1601058321~acl=/s/p/1955031/sp/195503100/serveFlavor/entryId/1_ldivkmki/v/11/ev/2/flavorId/1_b6wtzy8f/name/a.mp3*~hmac=bddcd801a98d3560990842beccee528da3861e588cf3438880642267aab03dc4 [21436961/21436961] -> "Kaverin puolesta kyselen: Koppuraiset kalsarit ja muita deittimokia-2020-09-25T06:45.mp3" [1]
This is still an issue; a newer (and still open, as of writing this) issue number for reference: #4312