Arkisto, huhtikuu 2018

Position of left-tiled windows not restored correctly when another left-tiled window present

29. huhtikuuta 2018 klo 16.42
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome

When another window is maximized or tiled to the left side of the screen, re-opening an application whose window was previously tiled to the left side does not restore that windows’ previous position. Instead such windows open at varying distances from the dock, untiled.

= Steps to see expected behavior (with a newly created user) =

1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
2. close Firefox
3. open Nautilus, make sure that the window floats (i.e. is unmaximized and not tiled to either side of screen)
4. open Firefox

== What happens ==
As expected, Firefox’s window is tiled to the left edge of screen, immediately to the right side of the dock.

= Steps to reproduce unexpected behavior (with a newly created user) =
1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
2. close Firefox
3. open Nautilus, *maximize its window*
4. open Firefox

== What happens ==
Firefox’s window opens slightly to the right off the right edge of the dock.

== What I expect to happen ==
I expect Firefox’s window to be tiled to the left edge of screen, immediately to the right from the dock, just as it did following the first recipe above.

= Further information =
Either maximizing or tiling Nautilus’ window to the left edge of the screen (at step #3) triggers the issue. Tiling it to the *right* edge of the screen does not.

Using Gnome Terminal instead of Nautilus triggers the issue just as well, I suspect any other application will though I’ve only systematically tested these two so far.

From battling with this in my daily use I also know that the distance of incorrectly restored windows from the dock varies: different applications open at different distances. The precise mechanics of this still elude me, though the distances do appear to be multiples of 25 pixels.

Vastaa viestiin sen kontekstissa (Launchpad)

Martin Hall feat. Dinah Smith: Not Forever

26. huhtikuuta 2018 klo 18.43
Sijainti: Videosivustot: YouTube
Avainsanat: Daniel Gunnarsson, Dinah Smith, Martin Hall, musiikki, Staffan Carlén

Martin Hall feat. Dinah Smith: Not Forever. The version in this one sounds like ”Tribute Version 2” by Daniel Gunnarsson feat. Staffan Carlén.

Vastaa viestiin sen kontekstissa (YouTube)

Why isn’t adding the ’git’ user to the ’redis’ group enough to give it access the socket?

22. huhtikuuta 2018 klo 17.36
Sijainti: Vianhallintajärjestelmät: Gitlab
Avainsanat: Gitlab

If the services run under the ’git’ user, why is it that adding the ’git’ user to the ’redis’ group (with access to the socket) isn’t enough to give it access to the socket? Sorry if this is a dumb question.

Vastaa viestiin sen kontekstissa (Gitlab)

Polarista tuotu sisäpyöräily kirjautuu ”pyöräilyksi” Heiaheiassa

21. huhtikuuta 2018 klo 17.23
Sijainti: Vianhallintajärjestelmät: HeiaHeia Support
Avainsanat: HeiaHeia, Polar

Käytän Polar Flow’ta treenieni kirjaamiseen, ja ne tuodaan sieltä Heiaheia-tililleni automaattisesti. Tämä toimii muutoin ihan hyvin, mutta sisäpyöräily kirjautuu jostain syystä Heiaheiassa tavalliseksi pyöräilyksi. Olen ruukannut korjata nuo Heiaheian puolella jälkikäteen, mutta olisi kätevää jos tämäkin toimisi automaattisesti niin kuin pitää.

Liitteenä on esimerkkikuva tämänpäiväisestä treenistä Flow’ssa ja Heiaheiassa.

(En ole varma onko vika Heiaheian vai Polarin päässä, mutta ajattelin kokeilla ensin tätä kautta.)

Kuvakaappaus-HH-vs-Polar.png

Vastaa viestiin sen kontekstissa (HeiaHeia Support)

Related but (FWICT) not precisely the same issues upstream

20. huhtikuuta 2018 klo 15.04
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: wget

Red Hat issue: https://bugzilla.redhat.com/show_bug.cgi?id=1484411 ”Running wget with -O and -q in the background yields a file wget-log”

Related but (FWICT) not precisely the same issues upstream:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888691 ”wget -b produces empty wget-log file”
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874590 ”wget: creates log file when run in the background”, forwarded to https://savannah.gnu.org/bugs/?51181 ”Unexpected ”Redirecting output to ’wget-log’.””

Vastaa viestiin sen kontekstissa (Launchpad)

wget-log file created despite -q when run in background with &

20. huhtikuuta 2018 klo 14.58
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: wget

== Steps to reproduce ==
`wget -q https://www.google.com/ &`

== What happens ==
wget says it’s ”Redirecting output to ’wget-log'” and creates an empty wget-log file in the current directory.

== What I expect to happen ==
No wget-log file to be created.

== Details ==
Wget has a -b (–background) option, for which the man page says: ”If no output file is specified via the -o, output is redirected to wget-log.” There’s also the -q (–quiet) option, for which the man page says: ”Turn off Wget’s output.”

When both are given, wget goes to background, and no wget-log gets created, as expected.

When only -b is given, wget goes to background, and creates wget-log, also as expected.

When only -q is given, wget runs in the foreground, and no wget-log is created, still as expected.

When only -q is given, but & is added to the end of the command line, wget goes to background, but also creates wget-log, which I find unexpected (and inconsistent).

Vastaa viestiin sen kontekstissa (Launchpad)

Kuuntelin tunnarin Youtubesta, enkä tunnistanut. Debunked!

17. huhtikuuta 2018 klo 19.29
Sijainti: Blogit: Run / Stop - Restore
Avainsanat: Commodore 64, musiikki, Rob Hubbard

Kuuntelin tunnarin Youtubesta, enkä tunnistanut. Debunked!

(Videon kommenteissa oli vähän keskustelua Hubbardin lainauksista.)

Vastaa viestiin sen kontekstissa (Run / Stop - Restore)

Henry Lee Lucas of course had Ottis Toole as his accomplice

17. huhtikuuta 2018 klo 16.03
Sijainti: Blogit: The Trail Went Cold
Avainsanat: Henry Lee Lucas, Ottis Toole

Henry Lee Lucas of course had Ottis Toole as his accomplice, and the picture of super-prolific sexual predators that the two painted of themselves with their confessions sort of matches how the perpetrator(s) of this case come across. But I’d imagine (or at least hope) that officials would have tested Lucas’ DNA as well, unless they had already ruled him out via other means.

Vastaa viestiin sen kontekstissa (The Trail Went Cold)

Unrecoverable failure in required component org.gnome.SettingsDaemon.Color.desktop

16. huhtikuuta 2018 klo 17.10
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome

I’ve had this happen a couple of times now since upgrading to 18.04: soon (perhaps within a minute) after logging in, Gnome session ends abruptly and I’m thrown back to the login screen. IIRC, in both instances this occurred on the first login after boot, so it does not reoccur on the subsequent re-login, and not on every login (very rarely in fact), and for now I have no better steps to reproduce this other than ”boot, log in”.

Bug #1663839 (reported against 17.04) seems similar, as does bug #1731428 (reported against 17.10).

journalctl output during the issue:

Apr 16 07:00:30 saegusa gnome-session[4342]: gnome-session-binary[4342]: WARNING: Application ’org.gnome.SettingsDaemon.Color.desktop’ failed to register before timeout
Apr 16 07:00:30 saegusa gnome-session-binary[4342]: WARNING: Application ’org.gnome.SettingsDaemon.Color.desktop’ failed to register before timeout
Apr 16 07:00:30 saegusa gnome-session-binary[4342]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Color.desktop
Apr 16 07:00:30 saegusa gnome-session[4342]: gnome-session-binary[4342]: CRITICAL: We failed, but the fail whale is dead. Sorry….
Apr 16 07:00:30 saegusa gnome-session-binary[4342]: CRITICAL: We failed, but the fail whale is dead. Sorry….

Vastaa viestiin sen kontekstissa (Launchpad)

Olisin väittänyt Mighty Ducks -ilmiön kytkeytyneen Teemu Selänteen NHL-uraan

13. huhtikuuta 2018 klo 14.11
Sijainti: Blogit: Silmänkääntövankila
Avainsanat: 1990-luku, Anaheim, Disney, NHL, Teemu Selänne

Olisin väittänyt Mighty Ducks -ilmiön kytkeytyneen Teemu Selänteen NHL-uraan, koska omassa mielessäni joukkueen nimi kytkeytyi 90-luvun Selänne-faneihin. Wikipedian mukaan Selänne kuitenkin myytiin Anaheimiin vasta 1996, joten 1993 on ihan liian aikaista aikaa selittääkseen tuota ilmiötä.

Ja minäkin pidin joukkuetta alunalkujaan pelkkänä parodiana, tai Disneyn fiktiona.

Vastaa viestiin sen kontekstissa (Silmänkääntövankila)

Vanhempia »