Bug#652682: fluxbox: fbsetbg messes up with lastwallpaper when $DISPLAY switches between :0 and :0.0
I've been meaning to triage this,
looks sane, but I'd rather integrate this upstream before downstream.
Let's get this in the fluxbox proper review queue :)
-Paul
On Mon, Dec 19, 2011 at 4:50 PM, Francesco Poli (wintermute)
invernom...@paranoici.org wrote:
Package: fluxbox
Version: 1.3.2-2
Severity: normal
Tags: patch
Hello!
I found out that fbsetbg may in some cases mess up with the user's
~/.fluxbox/lastwallpaper
This misbehavior is caused by the fact that the DISPLAY environment
variable is in the form hostname:displaynumber.screennumber
where .screennumber _may_ be omitted, as long as it's .0 , as
documented in the X(7) man page.
This means that :0.0 and :0 are equivalent.
I am not sure why, but it happens that sometimes the DISPLAY
environment variable is set to :0 , while in some other cases
it's set to :0.0 , in a seemingly inconsistent and unpredictable
manner.
As a consequence, taking fbsetbg code into account, the following
scenario may happen (I actually saw it happen, and I couldn't
understand what was going on, until I studied the fbsetbg code).
The user opens a Fluxbox session and he/she has:
$ echo $DISPLAY
:0.0
The user wants to set the following wallpaper:
$ fbsetbg -t /path/to/my/old/wallpaper.jpg
The wallpaper is set and remembered for the :0.0 display:
$ cat ~/.fluxbox/lastwallpaper
$tile $full|/path/to/my/old/wallpaper.jpg||:0.0
Good, everything is fine, the user does what he/she has to do and then
exits from Fluxbox.
Next time the user opens a Fluxbox session, the last set wallpaper
is remembered and set again, since:
$ grep rootCommand ~/.fluxbox/init
session.screen0.rootCommand: fbsetbg -l
After some time, the user wants to change wallpaper and issues
the following command:
$ fbsetbg -t /path/to/a/new/nice/wallpaper.jpg
What happens if, in this new Fluxbox session, the user has
$ echo $DISPLAY
:0
?
It happens that fbsetbg fails to see :0 as equivalent to :0.0
and does not replace the previously set wallpaper with the new one.
It just adds the new one, as if it were set for a different display!
$ cat ~/.fluxbox/lastwallpaper
$tile $full|/path/to/my/old/wallpaper.jpg||:0.0
$tile $full|/path/to/a/new/nice/wallpaper.jpg||:0
There! From this point on, depending on the DISPLAY value, the
wrong wallpaper may be set, when a new Fluxbox session is opened.
After studying the problem, I prepared the attached patch, which
fixes the issue for me and works in a backward-compatible way.
The idea is to always truncate the final .0 , if present, so that
screen 0 is always named in the same consistent manner within
the fbsetbg script.
In order to be backward-compatible, the script searches for $DISPLAY ,
but also for ${DISPLAY}.0 , in ~/.fluxbox/lastwallpaper , when
it has to replace an old wallpaper with a new one.
Please apply the patch to the Debian package and/or forward it
upstream.
Little legal details: I think my modifications are too trivial
to be copyrighted by me. Hence, you don't need any license from
me, in order to distribute fbsetbg with my patch applied.
Anyway, in case my modifications turn out to be in fact copyrighted,
I hereby license my patch under the same exact terms as fbsetbg
itself.
Thanks for your time!
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages fluxbox depends on:
ii libc6 2.13-21
ii libfontconfig1 2.8.0-3
ii libfreetype6 2.4.8-1
ii libfribidi0 0.19.2-1
ii libgcc1 1:4.6.2-7
ii libice6 2:1.0.7-2
ii libimlib2 1.4.4-1+b1
ii libsm6 2:1.2.0-2
ii libstdc++6 4.6.2-7
ii libx11-6 2:1.4.4-4
ii libxext6 2:1.3.0-3
ii libxft2 2.2.0-3
ii libxinerama1 2:1.1.1-3
ii libxpm4 1:3.5.9-4
ii libxrandr2 2:1.3.2-2
ii libxrender1 1:0.9.6-2
ii menu 2.1.46
ii zlib1g 1:1.2.3.4.dfsg-3
Versions of packages fluxbox recommends:
ii feh 2.1-1
ii xfonts-terminus 4.30-2
Versions of packages fluxbox suggests:
pn fbautostart none
pn fbdesk none
pn fbpager none
-- no debconf information
--
:wq
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652682: fluxbox: fbsetbg messes up with lastwallpaper when $DISPLAY switches between :0 and :0.0
On Sat, 24 Dec 2011 12:27:01 -0500 Paul R. Tagliamonte wrote: Hi Paul, thanks for taking care of this bug report! I've been meaning to triage this, looks sane, I am happy to hear you say so... ;-) but I'd rather integrate this upstream before downstream. Let's get this in the fluxbox proper review queue :) I can understand: let's hope it will get accepted, then. Thanks for informing me. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpaV9lrQHPPp.pgp Description: PGP signature
Bug#652682: fluxbox: fbsetbg messes up with lastwallpaper when $DISPLAY switches between :0 and :0.0
Package: fluxbox
Version: 1.3.2-2
Severity: normal
Tags: patch
Hello!
I found out that fbsetbg may in some cases mess up with the user's
~/.fluxbox/lastwallpaper
This misbehavior is caused by the fact that the DISPLAY environment
variable is in the form hostname:displaynumber.screennumber
where .screennumber _may_ be omitted, as long as it's .0 , as
documented in the X(7) man page.
This means that :0.0 and :0 are equivalent.
I am not sure why, but it happens that sometimes the DISPLAY
environment variable is set to :0 , while in some other cases
it's set to :0.0 , in a seemingly inconsistent and unpredictable
manner.
As a consequence, taking fbsetbg code into account, the following
scenario may happen (I actually saw it happen, and I couldn't
understand what was going on, until I studied the fbsetbg code).
The user opens a Fluxbox session and he/she has:
$ echo $DISPLAY
:0.0
The user wants to set the following wallpaper:
$ fbsetbg -t /path/to/my/old/wallpaper.jpg
The wallpaper is set and remembered for the :0.0 display:
$ cat ~/.fluxbox/lastwallpaper
$tile $full|/path/to/my/old/wallpaper.jpg||:0.0
Good, everything is fine, the user does what he/she has to do and then
exits from Fluxbox.
Next time the user opens a Fluxbox session, the last set wallpaper
is remembered and set again, since:
$ grep rootCommand ~/.fluxbox/init
session.screen0.rootCommand:fbsetbg -l
After some time, the user wants to change wallpaper and issues
the following command:
$ fbsetbg -t /path/to/a/new/nice/wallpaper.jpg
What happens if, in this new Fluxbox session, the user has
$ echo $DISPLAY
:0
?
It happens that fbsetbg fails to see :0 as equivalent to :0.0
and does not replace the previously set wallpaper with the new one.
It just adds the new one, as if it were set for a different display!
$ cat ~/.fluxbox/lastwallpaper
$tile $full|/path/to/my/old/wallpaper.jpg||:0.0
$tile $full|/path/to/a/new/nice/wallpaper.jpg||:0
There! From this point on, depending on the DISPLAY value, the
wrong wallpaper may be set, when a new Fluxbox session is opened.
After studying the problem, I prepared the attached patch, which
fixes the issue for me and works in a backward-compatible way.
The idea is to always truncate the final .0 , if present, so that
screen 0 is always named in the same consistent manner within
the fbsetbg script.
In order to be backward-compatible, the script searches for $DISPLAY ,
but also for ${DISPLAY}.0 , in ~/.fluxbox/lastwallpaper , when
it has to replace an old wallpaper with a new one.
Please apply the patch to the Debian package and/or forward it
upstream.
Little legal details: I think my modifications are too trivial
to be copyrighted by me. Hence, you don't need any license from
me, in order to distribute fbsetbg with my patch applied.
Anyway, in case my modifications turn out to be in fact copyrighted,
I hereby license my patch under the same exact terms as fbsetbg
itself.
Thanks for your time!
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages fluxbox depends on:
ii libc6 2.13-21
ii libfontconfig1 2.8.0-3
ii libfreetype62.4.8-1
ii libfribidi0 0.19.2-1
ii libgcc1 1:4.6.2-7
ii libice6 2:1.0.7-2
ii libimlib2 1.4.4-1+b1
ii libsm6 2:1.2.0-2
ii libstdc++6 4.6.2-7
ii libx11-62:1.4.4-4
ii libxext62:1.3.0-3
ii libxft2 2.2.0-3
ii libxinerama12:1.1.1-3
ii libxpm4 1:3.5.9-4
ii libxrandr2 2:1.3.2-2
ii libxrender1 1:0.9.6-2
ii menu2.1.46
ii zlib1g 1:1.2.3.4.dfsg-3
Versions of packages fluxbox recommends:
ii feh 2.1-1
ii xfonts-terminus 4.30-2
Versions of packages fluxbox suggests:
pn fbautostart none
pn fbdesk none
pn fbpager none
-- no debconf information
fbsetbg.diff.gz
Description: GNU Zip compressed data
