Viestialustana vianhallintajärjestelmät

No subpath, just the plain domain

4. joulukuuta 2019 klo 19.58
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

@amyblais No subpath, just the plain domain.

Vastaa viestiin sen kontekstissa (Github)

Github keeps asking me to verify my e-mail address over and over again

15. marraskuuta 2019 klo 14.08
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Github

Your service keeps asking me to verify my e-mail address over and over again. When I open the verification link from the email, the verification succeeds and the yellow notification goes away, but when I return to the site the next day, the notification has reappeared and I have to go through the whole process again. This has been going on for weeks if not months.

I found one Community Forum thread with the same issue, but the ”solution” there just tells the affected user to contact support. https://github.community/t5/How-to-use-Git-and-GitHub/Continual-repeated-requirement-to-verify-email-address-for-users/td-p/18085

Vastaa viestiin sen kontekstissa (Github)

Here are the banner settings

5. marraskuuta 2019 klo 13.08
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Firefox, Mattermost

Hi @amyblais, thanks for taking a look!

Here are the banner settings:

# grep -i banner config.json 
        "EnablePreviewModeBanner": true,
        "EnableBanner": false,
        "BannerText": "",
        "BannerColor": "#f2a93b",
        "BannerTextColor": "#333333",
        "AllowBannerDismissal": true

I should also mention that I’ve previously enabled Developer Mode ("EnableDeveloper": true), but I’m not sure it’s related, since the notification in this issue has the normal blue background, not a purple one.

The issue reappeared today for the other affected user, then kept disappearing and reappearing under testing, but we were unable to pin down any specific reason. Their browser console (Firefox) only has this:

websocket connecting to wss://[redacted]/api/v4/websocket websocket_client.jsx:35:20

and the server log meanwhile only has this line repeated:

mlog/log.go:174	{"name":"TypeError","message":"NetworkError when attempting to fetch resource.","stack":""}	{"path": "/api/v4/logs", "request_id": "g8wwo8yu57djmkipjxjxn7hy3y", "ip_addr": "[redacted]", "user_id": "[redacted]", "method": "POST", "err_where": "client", "http_code": 0, "err_details": ""}

(where user_id is the one for the affected user.)

Vastaa viestiin sen kontekstissa (Github)

”A new version of Mattermost is available” notification remains after selecting to ”Refresh the app now”

4. marraskuuta 2019 klo 16.52
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Mattermost

Summary

Selecting the ”Refresh the app now” link from update notification doesn’t make the notification go away.

Steps to reproduce

Have MM server updated to latest release. Open an existing session of the web app in Firefox. See the refresh prompt, select ”Refresh the app now”.

Expected behavior

Web page is refreshed, the notification goes away.

Observed behavior (that appears unintentional)

Web page is refreshed, but the update notification is still there, still prompting to refresh.

Verbose version

With some of the most recent updates (perhaps 5.16 and newer), the ”Refresh the app now” link in the update notification (”A new version of Mattermost is available”) on the web app did not make that notification go away for myself and another user. The link did cause a refresh of the page content, but the notification persisted. Meanwhile the version being reported by ”About Mattermost” was the correct (5.16.2).

Ctrl+shift+r or other hard refresh attempts did not have an effect, but logging out and then back in to the site finally did make the notification go away.

We’re both Firefox users, and due to the nature of the issue it was difficult to tell if this was browser-specific, but a fresh login using Chrome (while the previous session in Firefox still showed the notification) did not bring up the notification in the new session.

The issue, though irritatingly persistent while it lasted, was still relatively ephemeral, and now that it’s gone, I wouldn’t know how to reproduce it before the next server update. That said, I’ll happily provide more details if I can.

Vastaa viestiin sen kontekstissa (Github)

”Gitlab has completely removed” should be ”Git-annex support has been completely removed” (owtte)

29. lokakuuta 2019 klo 18.12
Sijainti: Vianhallintajärjestelmät: Gitlab
Avainsanat: Gitlab

The git-annex page has a removal warning at the top (introduced here). It currently says ”Warning: GitLab has completely removed in GitLab 9.0 (2017/03/22).”

My guess is it’s actually supposed to say ”Git annex support has been completely removed in GitLab 9.0 (2017/03/22).”

Vastaa viestiin sen kontekstissa (Gitlab)

Wishlist item: multi-window support in Freecell

7. lokakuuta 2019 klo 17.28
Sijainti: Vianhallintajärjestelmät: Freshdesk
Avainsanat: Android, Brainium

Hi! I’ve been a happy Freecell player for years now, thanks for the nice app.

I recently got a new Samsung S5e tablet, which supports Android’s new split-screen mode, which is obviously very handy for multitasking. But unfortunately Freecell seems to be one of the few applications that do not support this mode: trying to do so just brings up Freecell (alone) with a ”Can’t use this app in Multi window view” message. (I’m attaching a screenshot.)

So I thought I’d send in this wishlist ticket for getting multi-window support in Freecell. I’d particularly like to be able to play videos on the one side while playing Freecell on the other.

Vastaa viestiin sen kontekstissa (Freshdesk)

”No data received”: UA spoofing required for download to work

5. heinäkuuta 2019 klo 15.12
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: wget

I’m using yle-dl 20190614 with GNU Wget 1.19.4 in Ubuntu 18.04.

When trying to download this (and so far this is the only example I’ve come across): https://areena.yle.fi/1-50192791

Wget fails like this:

Resolving ylekaod-a.akamaihd.net (ylekaod-a.akamaihd.net)... 62.183.170.32, 62.183.170.35
Connecting to ylekaod-a.akamaihd.net (ylekaod-a.akamaihd.net)|62.183.170.32|:443... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

It tries a few more times, then gives up. I’m attaching --verbose log (with LC_ALL=C).

Workaround

I took the wget command from –verbose output and added UA spoofing with -U 'Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.27 Safari/537.17', and with the resulting command I was able to download the file.

Vastaa viestiin sen kontekstissa (Github)

The proposed packages did fix the issue

26. kesäkuuta 2019 klo 15.33
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: LibreOffice

Happy to report that the proposed packages did fix the issue for me also. Thanks everyone!

Vastaa viestiin sen kontekstissa (Launchpad)

Checklist item gets overwritten by previous item when selecting another item with mouse

20. toukokuuta 2019 klo 17.28
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Snap, Wekan

When a checklist item is in edit mode (through the specific steps below), selecting another item for editing does not take the previous item out of edit mode, and upon selecting a third item (or pressing enter) causes the second item to be overwritten by whatever content is in the first selected item.

Server Setup Information:

  • Wekan version: 2.74
  • Operating System: Ubuntu 16.04
  • Deployment Method: snap (stable)
  • Http frontend if any: Apache 2.4
  • ROOT_URL environment variable: https://my-domain.com/kan

Problem description:

Steps to reproduce

  1. Have a card with a checklist with 4 (or more) items with contents A, B, C, D (and so on):
  2. Select item A with LBM
  3. Select item B with LBM
  4. Select item C with LBM
  5. Select item D with LBM

What happens
At step 4, when C opens for editing, B remains in edit mode. At step 5, contents of C are overwritten by contents of B (that is, ”C” becomes a ”B”).

What I expect to happen
At step 4, for B to leave edit mode, and at step 5, the contents of C to remain as they are.

Other notes

  • Reproducible in both Chrome and Firefox.
  • Curiously, this does not seem to affect the firstly selected item: in step 3 above, A leaves edit mode correctly and thus B doesn’t get overwritten by the contents of item A in step 4.
  • At step 5, instead of selecting item D, pressing enter has the same effect.

Browser console output
empty

snap logs wekan.wekan
nothing related

Vastaa viestiin sen kontekstissa (Github)

No stack trace nor other apparent problems with SAL_DISABLE_CPD=true

13. toukokuuta 2019 klo 19.32
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: LibreOffice

@Marcus: yup, that seems to be it:

jani@saegusa:~$ dpkg -l ’libcpd*’ ’cpdb*’
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Nimi Versio Arkkitehtuuri Kuvaus
+++-========================-=================-=================-======================================================
ii cpdb-backend-gcp 1.0.0-0ubuntu2 amd64 Common Print Dialog Backends – Google Cloud Print Back
ii libcpdb-libs-common0:amd 1.1.1-0ubuntu1 amd64 Common Print Dialog Backends – Interface Library for B
jani@saegusa:~$ SAL_DISABLE_CPD=true libreoffice –norestore
func=xmlSecCheckVersionExt:file=xmlsec.c:line=188:obj=unknown:subj=unknown:error=19:invalid version:mode=abi compatible;expected minor version=2;real minor version=2;expected subminor version=25;real subminor version=26

That is, no stack trace nor other apparent problems when starting LO with SAL_DISABLE_CPD=true.

Vastaa viestiin sen kontekstissa (Launchpad)

Vanhempia »