Viestialustana vianhallintajärjestelmät

All right, I rebased and then regenerated the .pot

24. helmikuuta 2021 klo 16.31
Sijainti: Vianhallintajärjestelmät: Gitlab

@ohoral All right, I’ve now rebased, and then regenerated the .pot again. I didn’t know whether you want the commits squashed, so I left them as separate.

Vastaa viestiin sen kontekstissa (Gitlab)

Okay, I’ve added that file now

22. helmikuuta 2021 klo 20.49
Sijainti: Vianhallintajärjestelmät: Gitlab

Okay, I’ve added that file now. I actually did install GDK to update the .pot file previously, but this last file I added here in the web IDE again.

Vastaa viestiin sen kontekstissa (Gitlab)

I take it I’ll need to install GDK for that?

20. helmikuuta 2021 klo 12.57
Sijainti: Vianhallintajärjestelmät: Gitlab

@asubramanian1 Sure, I take it I’ll need to install GDK for that? I don’t have it set up yet, as I just edited the commit above here in the web UI.

Vastaa viestiin sen kontekstissa (Gitlab)

Fix ”an one time” typo

18. helmikuuta 2021 klo 13.37
Sijainti: Vianhallintajärjestelmät: kieli

This fixes a typo in the 2FA settings: ”an one time” -> ”a one time”

Vastaa viestiin sen kontekstissa (kieli)

Nextcloud is somehow different from other apps in this regard

6. helmikuuta 2021 klo 13.08
Sijainti: Vianhallintajärjestelmät: Nextcloud
Avainsanat: Android

Nextcloud is somehow different from other apps in this regard, as no other light (white) apps on the same device have this issue. For instance, here’s Play Store on my affected device (running Android 6.0.1):

Screenshot_20210206-124828

Also, I seem to recall this only having started to affect Nextcloud quite recently, perhaps sometime in the past month or so.

Switching to dark mode is a workaround on my device at least (there the Android buttons are light-on-black). I can also confirm that the issue doesn’t affect my newer devices with newer Android.

Vastaa viestiin sen kontekstissa (Nextcloud)

I haven’t edited the corresponding AppArmor files

26. tammikuuta 2021 klo 18.41
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Apparmor

No, I haven’t (and wouldn’t know how).

Vastaa viestiin sen kontekstissa (Launchpad)

Yes, this is still present in 20.04

26. joulukuuta 2020 klo 16.56
Sijainti: Vianhallintajärjestelmät: Launchpad

Yes, this is still present in 20.04 with printer-driver-cups-pdf 3.0.1-6, limited to original reporter’s case of having the symlink point to another filesystem; if I point ~/PDF to, say ~/tmp/PDF (without crossing filesystem borders), the PDF is created without issue, whereas having ~/PDF linked to /media/$USER/$USB_THUMBDRIVE/PDF/ does still cause it to fail:

[…]
Sat Dec 26 16:48:07 2020 [DEBUG] output filename created: /home/jani/PDF/Bug__1092099__342_200_234inconsistent_behavior_for…ry_342_200_-job_8.pdf
Sat Dec 26 16:48:07 2020 [DEBUG] ghostscript commandline built: /usr/bin/gs -q -dCompatibilityLevel=1.2 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=”/home/jani/PDF/Bug__1092099__342_200_234inconsistent_behavior_for…ry_342_200_-job_8.pdf” -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-233705
Sat Dec 26 16:48:07 2020 [DEBUG] output file unlinked: /home/jani/PDF/Bug__1092099__342_200_234inconsistent_behavior_for…ry_342_200_-job_8.pdf
Sat Dec 26 16:48:07 2020 [DEBUG] TMPDIR set for GhostScript: /var/tmp
Sat Dec 26 16:48:07 2020 [DEBUG] waiting for child to exit
Sat Dec 26 16:48:07 2020 [DEBUG] entering child process
Sat Dec 26 16:48:07 2020 [DEBUG] GID set for current user
Sat Dec 26 16:48:07 2020 [DEBUG] supplementary groups set for current user
Sat Dec 26 16:48:07 2020 [DEBUG] UID set for current user: jani
Sat Dec 26 16:48:07 2020 [DEBUG] ghostscript has finished: 256
Sat Dec 26 16:48:07 2020 [ERROR] failed to set file mode for PDF file: /home/jani/PDF/Bug__1092099__342_200_234inconsistent_behavior_for…ry_342_200_-job_8.pdf (non fatal)
Sat Dec 26 16:48:07 2020 [DEBUG] ERRNO: 2 (No such file or directory)
Sat Dec 26 16:48:07 2020 [DEBUG] no postprocessing
Sat Dec 26 16:48:07 2020 [DEBUG] spoolfile unlinked: /var/spool/cups-pdf/SPOOL/cups2pdf-233705
Sat Dec 26 16:48:07 2020 [DEBUG] all memory has been freed
Sat Dec 26 16:48:07 2020 [STATUS] PDF creation successfully finished for jani
jani@latimeria:~$ ls -l PDF
lrwxrwxrwx 1 jani jani 27 joulu 26 16:47 PDF -> /media/jani/KINGSTON_1G/PDF
jani@latimeria:~$ ls -l PDF/
yhteensä 0

Vastaa viestiin sen kontekstissa (Launchpad)

I haven’t seen this since Ubuntu-distributed Firefox was updated to 84

20. joulukuuta 2020 klo 12.12
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

For me this seems to have resolved itself since Ubuntu-distributed Firefox was updated to 84, though for all I know, it may have just coincided with some change implemented at Twitter’s end.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I see, so it’s a result of conflicting indicators from the user

19. joulukuuta 2020 klo 18.41
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost, saavutettavuus

@agnivade Oh I see, so it’s a result of conflicting indicators (”away” vs. being active) from the user. I’m trying to recalibrate my expectation based on this, but it’s difficult.

My immediate thought is perhaps (in the problematic case) sending the notification, but then clearing it only once I start typing (typing appears to have an event associated with it, at least based on the logs) would be better than the immediately clearing ghost notification, but you’re right, this is more complicated than immediately apparent.

Some UI/UX design wizardry would probably be needed to eliminate the possibility of mixed user signals, if at all possible. I don’t have a good solution for now, so feel free to close the issue if you deem it appropriate.

Vastaa viestiin sen kontekstissa (Github)

Yup, your description of the issue is exactly right

18. joulukuuta 2020 klo 15.23
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Mattermost

Yup, your description of the issue is exactly right @agnivade, and thanks for looking into this!

I set up the two users in parallel windows. Sending a normal message as userB this way does not trigger the issue (I do get a notification on userA’s phone, but it doesn’t go away by itself), but that’s because userA’s window is (obviously) not active, since I’m typing in userB’s window. The notification is only cleared once I activate userA’s window.

But I can trigger the issue by using (for instance) /echo 'hello A' 4 instead (as userB), then hopping on to activate userA’s window during the 4-second delay, so that userA’s window is active when receiving the message. That’s the crucial bit: the receiver’s window is active when receiving the message. If his status is ’Online’, there’s no push notification (as expected), but if it’s ’Away’, that’s when I get the ghost notification.

Here’s server log and MPNS log during one minute where (as userB) I first send a normal message, then (at about 30 seconds) using /echo.

Vastaa viestiin sen kontekstissa (Github)

« Uudempia - Vanhempia »