Re: SOLVED? - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 06/10/2017 06:33 PM, songbird wrote:
> Richard Owlett wrote:
> ...
>> I've just done:
>> apt-get update
>> apt-get upgrade
>> apt-get dist-upgrade
>>
>> I no longer see the problem described in this thread.
>> [just a heads up for those who haven't recently done update etc]
> 
>   correct, updated versions of some MATE pieces were
> accepted into testing recently which fixed the
> issue.
> 
>   yay!  :)
> 
I second that motion!!! :))
> 
>   songbird
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: SOLVED? - was [Re: Desktop Background Bites the Dust]

[songbird]

Richard Owlett wrote:
...
> I've just done:
> apt-get update
> apt-get upgrade
> apt-get dist-upgrade
>
> I no longer see the problem described in this thread.
> [just a heads up for those who haven't recently done update etc]

  correct, updated versions of some MATE pieces were
accepted into testing recently which fixed the
issue.

  yay!  :)


  songbird

Re: SOLVED - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 06/10/2017 03:55 PM, Richard Owlett wrote:
> On 05/18/2017 11:52 PM, Michael Milliman wrote:
>> I have no clue what happened, but the desktop background picture has
>> ceased to be displayed. I'm not even sure where to look to troubleshoot
>> the problem.  The salient information is: OS is fully updated Testing,
>> MATE desktop environment.  I have attempted to re-set the desktop
>> background via both system settings and via right-click->set desktop
>> background on the desktop to no effect.  Thinking that probably the
>> issue was associated with my normal login (the only one on the
>> ea7c4862-980d-56f3-3578-505684870f85@cloud85.netsystem),
>> I created a new user from root terminal and logged in with newly created
>> skeleton home folder; the problem persisted with the new user, so it is
>> a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
>> greatly appreciated.  Thanks in advance.
>>
> 
> 
> I've just done:
>apt-get update
>apt-get upgrade
>apt-get dist-upgrade
> 
> I no longer see the problem described in this thread.
> [just a heads up for those who haven't recently done update etc]
> 
Yes, the required packages are now available in the unstable release.  I
upgraded to caja 1.16.6 and the problem is solved.  Thanks to all who
contributed to this thread.
> 
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

SOLVED? - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/18/2017 11:52 PM, Michael Milliman wrote:

I have no clue what happened, but the desktop background picture has
ceased to be displayed. I'm not even sure where to look to troubleshoot
the problem.  The salient information is: OS is fully updated Testing,
MATE desktop environment.  I have attempted to re-set the desktop
background via both system settings and via right-click->set desktop
background on the desktop to no effect.  Thinking that probably the
issue was associated with my normal login (the only one on the 
ea7c4862-980d-56f3-3578-505684870f85@cloud85.netsystem),
I created a new user from root terminal and logged in with newly created
skeleton home folder; the problem persisted with the new user, so it is
a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
greatly appreciated.  Thanks in advance.




I've just done:
   apt-get update
   apt-get upgrade
   apt-get dist-upgrade

I no longer see the problem described in this thread.
[just a heads up for those who haven't recently done update etc]

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, May 30, 2017 at 08:28:52AM -0400, Greg Wooledge wrote:
> On Mon, May 29, 2017 at 10:55:28PM -0500, Michael Milliman wrote:
> > For me, though, the important aspect is will sxiv change the desktop
> > background like feh will?
> 
> If all you want is to set the root window (desktop/background) image,
> "xsetbg" from the xloadimage package will do nicely.

This might not interact well with "Desktop environments" (i.e. Gnome,
KDE and derivatives, and perhaps to a lesser extent XFCE). As far as
I remember, those tend to cover the X root with an own window and play
other funny games, so backgrounds (and screen savers) become less
obvious as under the simpler arrangement "X + window manager".

But things may have improved since then.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlktbaMACgkQBcgs9XrR2kaiOwCggiSu5zBnuUQqf4IcmuulBIy/
fD0An39gmpgTSj1elarHPWS9pFZb3O+g
=5JrP
-END PGP SIGNATURE-

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Greg Wooledge]

On Mon, May 29, 2017 at 10:55:28PM -0500, Michael Milliman wrote:
> For me, though, the important aspect is will sxiv change the desktop
> background like feh will?

If all you want is to set the root window (desktop/background) image,
"xsetbg" from the xloadimage package will do nicely.

If you want additional features like thumbnail galleries, then I don't
have any recommendations, as I don't use such programs.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Tue 30 May 2017 at 04:15:10 -0500, Richard Owlett wrote:

> On 05/29/2017 10:55 PM, Michael Milliman wrote:
> >
> >On 05/29/2017 01:19 PM, Brian wrote:
> >>
> >>There are legitimate concerns about aspects of feh's behaviour, not
> >>sufficient as yet to prevent my recommending it, but the topic prompted
> >>a bit of exploring. So I took a look at Debian's sxiv in Stretch.
> >>
> >>sxiv is somewhat similar to feh. It has an installed size a third of
> >>feh's (an advantage?) and is fast at rendering and responsive. Nothing
> >>scientific, but thumbnails (without caching) seem to render quicker than
> >>feh does it. One can easily switch between thumbnail view and picture
> >>display. The upstream developer is also active, which is never a bad
> >>thing.
> >>
> >>Downsides? Definitely. But this post is an advocacy one for those Debian
> >>users who just want to view their pictures without installing tons of
> >>GNOME dependencies or like to be able to configure things for their
> >>particular use case.
> >>
> >>I am now torn between feh and sxiv. That is the problem with threads
> >>like this, which promote delving into available packages and having to
> >>make a choice. :)
> >>
> >For me, though, the important aspect is will sxiv change the desktop
> >background like feh will?
> 
> I found no mention of anything like that in its man page.
> YMMV

 Nope. There are lots of wallpaper setters available. You can
 also integrate the tool of your choice via the key handler.

  https://github.com/muennich/sxiv/issues/192

-- 
Brian.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/29/2017 10:55 PM, Michael Milliman wrote:



On 05/29/2017 01:19 PM, Brian wrote:

On Sat 27 May 2017 at 19:13:25 +0100, Brian wrote:


On Sat 27 May 2017 at 09:52:45 -0500, David Wright wrote:


On Sat 27 May 2017 at 12:32:06 (+0100), Brian wrote:

On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:


And actually, the --no-xinerama flag is not needed, at least on my
system.  I use feh --bg-fill ... and it works just fine.  Of course,
that is a very limited (and safe) usage of feh.  I don't think it wise
to use it for anything much more (IMHO).


Surprising after all these years that feh is now revealed as an unsafe
image viewer.


Wow, I didn't realise I'd participated in a revelation.


It happens all the time on -user. :)


Fancy another one?

There are legitimate concerns about aspects of feh's behaviour, not
sufficient as yet to prevent my recommending it, but the topic prompted
a bit of exploring. So I took a look at Debian's sxiv in Stretch.

sxiv is somewhat similar to feh. It has an installed size a third of
feh's (an advantage?) and is fast at rendering and responsive. Nothing
scientific, but thumbnails (without caching) seem to render quicker than
feh does it. One can easily switch between thumbnail view and picture
display. The upstream developer is also active, which is never a bad
thing.

Downsides? Definitely. But this post is an advocacy one for those Debian
users who just want to view their pictures without installing tons of
GNOME dependencies or like to be able to configure things for their
particular use case.

I am now torn between feh and sxiv. That is the problem with threads
like this, which promote delving into available packages and having to
make a choice. :)


For me, though, the important aspect is will sxiv change the desktop
background like feh will?


I found no mention of anything like that in its man page.
YMMV


I have been following this thread closely
since opening it and have learned quit a bit.  I agree an active
upstream is always a good thing.  And I admit, I am concerned about some
of what has been reported of feh's behavior, though most of that
behavior is inconsequential in my use case.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 05/29/2017 01:19 PM, Brian wrote:
> On Sat 27 May 2017 at 19:13:25 +0100, Brian wrote:
> 
>> On Sat 27 May 2017 at 09:52:45 -0500, David Wright wrote:
>>
>>> On Sat 27 May 2017 at 12:32:06 (+0100), Brian wrote:
 On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:

> And actually, the --no-xinerama flag is not needed, at least on my
> system.  I use feh --bg-fill ... and it works just fine.  Of course,
> that is a very limited (and safe) usage of feh.  I don't think it wise
> to use it for anything much more (IMHO).

 Surprising after all these years that feh is now revealed as an unsafe
 image viewer.
>>>
>>> Wow, I didn't realise I'd participated in a revelation.
>>
>> It happens all the time on -user. :)
> 
> Fancy another one?
> 
> There are legitimate concerns about aspects of feh's behaviour, not
> sufficient as yet to prevent my recommending it, but the topic prompted
> a bit of exploring. So I took a look at Debian's sxiv in Stretch.
> 
> sxiv is somewhat similar to feh. It has an installed size a third of
> feh's (an advantage?) and is fast at rendering and responsive. Nothing
> scientific, but thumbnails (without caching) seem to render quicker than
> feh does it. One can easily switch between thumbnail view and picture
> display. The upstream developer is also active, which is never a bad
> thing.
> 
> Downsides? Definitely. But this post is an advocacy one for those Debian
> users who just want to view their pictures without installing tons of
> GNOME dependencies or like to be able to configure things for their
> particular use case.
> 
> I am now torn between feh and sxiv. That is the problem with threads
> like this, which promote delving into available packages and having to
> make a choice. :)
> 
For me, though, the important aspect is will sxiv change the desktop
background like feh will? I have been following this thread closely
since opening it and have learned quit a bit.  I agree an active
upstream is always a good thing.  And I admit, I am concerned about some
of what has been reported of feh's behavior, though most of that
behavior is inconsequential in my use case.


-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Sat 27 May 2017 at 19:13:25 +0100, Brian wrote:

> On Sat 27 May 2017 at 09:52:45 -0500, David Wright wrote:
> 
> > On Sat 27 May 2017 at 12:32:06 (+0100), Brian wrote:
> > > On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:
> > > 
> > > > And actually, the --no-xinerama flag is not needed, at least on my
> > > > system.  I use feh --bg-fill ... and it works just fine.  Of course,
> > > > that is a very limited (and safe) usage of feh.  I don't think it wise
> > > > to use it for anything much more (IMHO).
> > > 
> > > Surprising after all these years that feh is now revealed as an unsafe
> > > image viewer.
> > 
> > Wow, I didn't realise I'd participated in a revelation.
> 
> It happens all the time on -user. :)

Fancy another one?

There are legitimate concerns about aspects of feh's behaviour, not
sufficient as yet to prevent my recommending it, but the topic prompted
a bit of exploring. So I took a look at Debian's sxiv in Stretch.

sxiv is somewhat similar to feh. It has an installed size a third of
feh's (an advantage?) and is fast at rendering and responsive. Nothing
scientific, but thumbnails (without caching) seem to render quicker than
feh does it. One can easily switch between thumbnail view and picture
display. The upstream developer is also active, which is never a bad
thing.

Downsides? Definitely. But this post is an advocacy one for those Debian
users who just want to view their pictures without installing tons of
GNOME dependencies or like to be able to configure things for their
particular use case.

I am now torn between feh and sxiv. That is the problem with threads
like this, which promote delving into available packages and having to
make a choice. :)

-- 
Brian.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Sat 27 May 2017 at 09:52:45 -0500, David Wright wrote:

> On Sat 27 May 2017 at 12:32:06 (+0100), Brian wrote:
> > On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:
> > 
> > > And actually, the --no-xinerama flag is not needed, at least on my
> > > system.  I use feh --bg-fill ... and it works just fine.  Of course,
> > > that is a very limited (and safe) usage of feh.  I don't think it wise
> > > to use it for anything much more (IMHO).
> > 
> > Surprising after all these years that feh is now revealed as an unsafe
> > image viewer.
> 
> Wow, I didn't realise I'd participated in a revelation.

It happens all the time on -user. :)
 
> I noticed the overwriting problem in September 2007, within days of
> buying a digital camera that set the orientation flag. (Previously,
> I'd been using a work cast-off which didn't set it.) I'd used xzgv
> for some years as my image viewer but never had much luck with its
> --exif-orient option, so I tried feh as an alternative because
> it appeared to honour it.
> 
> Very soon after using feh, I noticed that the timestamps displayed
> by mc on my camera picture directories were getting screwed up.
> Of course, these picture files get backed up straight from the SD
> card before I even look at them, so I was able to restore the
> original pictures without any difficulty once I'd worked out
> what to blame.

My first reaction on encountering the overwriting a short time ago was
to be annoyed; perhaps a similar reaction to yours. After reading that
the transformation was lossless (no pixels harmed in the process) I came
to terms with it for a while. I regarded the original photos as having
the wrong orientation and didn't mind ending up with ones which were
"correct". Also, any file change does not materially affect printing.

Then I decided it is usually not a good idea to lose an original file,
so I unbound the editing keys and rebound them to backup the original
before conducting any rotations etc. The "Q" key was also rebound to
restore the file on quitting feh. This effort made me feel better but
I still wondered whether losing the original was technically critical
in all circumstances. I am persuadable.

If libjpeg-progs (libjpeg-turbo-progs) is purged the issue becomes a
non-issue.

> (However there are still probably a few downloaded images that are
> not in their original state, because I have no practical way of
> discovering which ones they are.)
> 
> Apologies for not bringing it up then. I didn't resubscribe
> here for another 8 years and was only reminded about the problem
> on seeing this thread. FWIW I use xsetbg (xloadimage) for my
> desktops, but my laptops use the background colour as a
> battery-state and, in extremis, CPU temperature indicator. So,
> for example, if the power cord dislodges, the presently green
> background will switch to yellow.

The only backgrounds I contemplate having are ones with a solid color.
So its xsetroot for me on most occasions.

> > I use it to look at an image prior to printing it from feh
> > and see that as quick, reliable and convenient but not as unwise.
> 
> Understood. I didn't know whether you were a feh user, or had just
> read the man page, when I made my mouse comment. In any case, such
> single-use instances as proof-checking and wallpaper-setting may
> well justify its use, but my comment about its misdescription
> and dangers was intended for readers of this list who might use
> it as a general-purpose viewer after installing it in the wake of
> this thread.

It doesn't take much effort to damn a piece of software and labelling
it as unsafe without a justification is one way to steer users away
from it. feh would probably now be "a thing of history" if it were not
for its present maintainer, Daniel Friesel. Most people would not read
the issues on github and could form an unjustified impression of feh
and its development from such unsubstantiated claims. Articulated
criticism is one thing, assassination by innuendo is another.
 
> BTW I checked the error message I mentioned earlier. Feh itself
> emits the incorrect error message for PNG files, but the correct
> message is emitted by the spawned jpegtran program for JPGs.

Confirmed.

Incidentally, your mouse remarks (re Ctrl+2) are valid but (untested) I
expect the action could be rebound to a different button. Stretch has a
--auto-rotate option, which is very useful. It can easily be installed
on Jessie with a few extra packages to get it going.

-- 
Brian.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Curt]

On 2017-05-27, David Wright  wrote:
>
> BTW I checked the error message I mentioned earlier. Feh itself
> emits the incorrect error message for PNG files, but the correct
> message is emitted by the spawned jpegtran program for JPGs.
>

Please file a wish-list bug for a name change to fey (forewarned being
forearmed).

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[David Wright]

On Sat 27 May 2017 at 12:32:06 (+0100), Brian wrote:
> On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:
> 
> > On 05/25/2017 05:56 AM, Richard Owlett wrote:
> > > 
> > > If I had read the man page more slowly that using the menu to set the
> > > image as wallpaper was unnecessary. Use:
> > > feh --no-xinerama  --bg-fill
> > > /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
> > > 
> > > 
> > And actually, the --no-xinerama flag is not needed, at least on my
> > system.  I use feh --bg-fill ... and it works just fine.  Of course,
> > that is a very limited (and safe) usage of feh.  I don't think it wise
> > to use it for anything much more (IMHO).
> 
> Surprising after all these years that feh is now revealed as an unsafe
> image viewer.

Wow, I didn't realise I'd participated in a revelation.

I noticed the overwriting problem in September 2007, within days of
buying a digital camera that set the orientation flag. (Previously,
I'd been using a work cast-off which didn't set it.) I'd used xzgv
for some years as my image viewer but never had much luck with its
--exif-orient option, so I tried feh as an alternative because
it appeared to honour it.

Very soon after using feh, I noticed that the timestamps displayed
by mc on my camera picture directories were getting screwed up.
Of course, these picture files get backed up straight from the SD
card before I even look at them, so I was able to restore the
original pictures without any difficulty once I'd worked out
what to blame.

(However there are still probably a few downloaded images that are
not in their original state, because I have no practical way of
discovering which ones they are.)

Apologies for not bringing it up then. I didn't resubscribe
here for another 8 years and was only reminded about the problem
on seeing this thread. FWIW I use xsetbg (xloadimage) for my
desktops, but my laptops use the background colour as a
battery-state and, in extremis, CPU temperature indicator. So,
for example, if the power cord dislodges, the presently green
background will switch to yellow.

> I use it to look at an image prior to printing it from feh
> and see that as quick, reliable and convenient but not as unwise.

Understood. I didn't know whether you were a feh user, or had just
read the man page, when I made my mouse comment. In any case, such
single-use instances as proof-checking and wallpaper-setting may
well justify its use, but my comment about its misdescription
and dangers was intended for readers of this list who might use
it as a general-purpose viewer after installing it in the wake of
this thread.

BTW I checked the error message I mentioned earlier. Feh itself
emits the incorrect error message for PNG files, but the correct
message is emitted by the spawned jpegtran program for JPGs.

Cheers,
David.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Fri 26 May 2017 at 17:57:40 -0500, Michael Milliman wrote:

> On 05/25/2017 05:56 AM, Richard Owlett wrote:
> > 
> > If I had read the man page more slowly that using the menu to set the
> > image as wallpaper was unnecessary. Use:
> > feh --no-xinerama  --bg-fill
> > /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
> > 
> > 
> And actually, the --no-xinerama flag is not needed, at least on my
> system.  I use feh --bg-fill ... and it works just fine.  Of course,
> that is a very limited (and safe) usage of feh.  I don't think it wise
> to use it for anything much more (IMHO).

Surprising after all these years that feh is now revealed as an unsafe
image viewer. I use it to look at an image prior to printing it from feh
and see that as quick, reliable and convenient but not as unwise.

-- 
Brian.

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/25/2017 06:27 AM, RavenLX wrote:
> On 05/21/2017 05:40 PM, David Christensen wrote:
>> As I understand it:
>>
>> *   'apt-get upgrade' is for rolling forward to a new minor revision
>> -- e.g. Debian 8.7 to Debian 8.8 -- and/or new packages -- e.g.
>> icedove 1:45.6.0-1~deb8u1 to thunderbird 1:45.8.0-3~deb8u1).
>>
>> *   'apt-get dist-upgrade' is for rolling forward to a new major
>> revision -- e.g. Debian 7 to Debian 8.
>>
>>
>> I do the former regularly -- once or more per week.
>>
>>
>> I avoid the latter, as it's caused me grief in the past (when I want
>> to do a major version upgrade, I backup, move the system disk aside,
>> do a fresh install, and restore).
>>
>>
>> My issue is likely tied to some software corner case due the the
>> hardware -- e.g. 32-bit laptop with an off-spec 64-bit processor
>> jammed in.
> 
> I've always used dist-upgrade for years without any problems. It's an
> old habit by now. If I don't, I learned there are some packages I *do*
> want to upgrade that get held back (ie. not upgraded) if I don't do
> dist-upgrade, such as new kernels (which I like to keep the kernel the
> newest out there). I haven't yet had any real major issues (even minor
> issues I've always found a work-around and 99% of the time it was just
> something I myself needed to configure, and not really a bug). I run
> stable so maybe that is why I have such good luck. On test VMs I do
> dist-upgrade basically because I know I can always start over if things
> go wrong. And Virtual Machines are the test systems anyway.
> 
Yeah, I like the VMs for testing as well.  Unfortunately, I'm poor :)
and my equipment is pretty slow, so VM performance is pretty poor too :)
Right now I'm running Stretch, and 99% of the time, I have no problems,
but every once in a while
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 05/26/2017 09:48 AM, Ric Moore wrote:
> On 05/25/2017 06:56 AM, Richard Owlett wrote:
>> On 05/24/2017 12:26 PM, Richard Owlett wrote:
> 
>>> The man page 
>>> _mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
>>> treat the whole X display as one screen when setting wallpapers."
> 
> I use one wallpaper across four screens. I just right click on the
> desktop, select "Desktop Settings", select your wallpaper and scroll the
> vertical bar down to reveal the settings you want (or make it full
> screen)  select "Spanning Screens" style and check "Apply to all
> workspaces.  Bob's your uncle, you should be set. Net, go to some wall
> paper site and find W_I_D_E wallpapers. :) Ric
> p/s Using XFCE.
That is the problem, Ric.  My original post for this thread is that with
the current mate-desktop in Stretch, this no longer works.  The current
work-around is using feh to set the background, which does work. There
is an upstream fix, upgrading to caja version 1.16.3 is supposed to fix
the problem, but that version is not yet in the Stretch repositories.
There is currently a bug filed against this, and hopefully the
maintainers will get the problem solved and feh will be a thing of
history :)
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 05/25/2017 06:08 AM, Dejan Jocic wrote:
> On 25-05-17, Richard Owlett wrote:
>> On 05/24/2017 12:26 PM, Richard Owlett wrote:
>>> On 05/20/2017 09:31 PM, Michael Milliman wrote:
 [snip]
>> The bug report also lists a workaround (which I haven't tried).
>>
 The workaround is using the feh package to manually set the background
 image.  This does work, however, it has to be done each time you
 log-in. It is better than nothing.  Upstream also appears to have
 a bug reported on it, and they suggest installation of mate-desktop
 16.2 with caja 16.3, neither of which has made it to the Debian
 distribution as of yet.
>>>
>>> Being one who emphatically avoids graphics I found a subtle gotcha.
>>>
>>> The man page 
>>> _mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
>>> treat the whole X display as one screen when setting wallpapers."
>>>
>>> An example command line to use would be (as a single line):
>>> feh --no-xinerama /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
>>>
>>> It also does not mention how to set it as the wallpaper ;)
>>> Once the above command has displayed the chosen image:
>>>  1. right-click anywhere in the image
>>>  2. chose File->Background->Set Filled from the displayed menu/sub-menus
>>>
>>
>> If I had read the man page more slowly that using the menu to set the image
>> as wallpaper was unnecessary. Use:
>> feh --no-xinerama  --bg-fill
>> /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
>>
>>
>>
>>
> It's been a while since I've used feh for background. Anyway, it should
> save your choice in .fehbg file. And you should add that file to
> autostart, to preserve your background settings.
> 
That is what the man page says, and it does indeed create the ~/.fehbg
file.  But for whatever reason, I have not needed to invoke said file.
My background continues to work, even across a re-boot after having
invoked feh --bg-fill ...
> 
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 05/25/2017 05:56 AM, Richard Owlett wrote:
> On 05/24/2017 12:26 PM, Richard Owlett wrote:
>> On 05/20/2017 09:31 PM, Michael Milliman wrote:
>>> [snip]
> The bug report also lists a workaround (which I haven't tried).
>
>>> The workaround is using the feh package to manually set the background
>>> image.  This does work, however, it has to be done each time you
>>> log-in. It is better than nothing.  Upstream also appears to have
>>> a bug reported on it, and they suggest installation of mate-desktop
>>> 16.2 with caja 16.3, neither of which has made it to the Debian
>>> distribution as of yet.
>>
>> Being one who emphatically avoids graphics I found a subtle gotcha.
>>
>> The man page 
>> _mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
>> treat the whole X display as one screen when setting wallpapers."
>>
>> An example command line to use would be (as a single line):
>> feh --no-xinerama
>> /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
>>
>> It also does not mention how to set it as the wallpaper ;)
>> Once the above command has displayed the chosen image:
>>  1. right-click anywhere in the image
>>  2. chose File->Background->Set Filled from the displayed menu/sub-menus
>>
> 
> If I had read the man page more slowly that using the menu to set the
> image as wallpaper was unnecessary. Use:
> feh --no-xinerama  --bg-fill
> /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
> 
> 
And actually, the --no-xinerama flag is not needed, at least on my
system.  I use feh --bg-fill ... and it works just fine.  Of course,
that is a very limited (and safe) usage of feh.  I don't think it wise
to use it for anything much more (IMHO).
> 
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/26/2017 09:48 AM, Ric Moore wrote:

On 05/25/2017 06:56 AM, Richard Owlett wrote:

On 05/24/2017 12:26 PM, Richard Owlett wrote:



The man page 
_mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
treat the whole X display as one screen when setting wallpapers."


I use one wallpaper across four screens. I just right click on the
desktop, select "Desktop Settings", select your wallpaper and scroll the
vertical bar down to reveal the settings you want (or make it full
screen)  select "Spanning Screens" style and check "Apply to all
workspaces.  Bob's your uncle, you should be set. Net, go to some wall
paper site and find W_I_D_E wallpapers. :) Ric
p/s Using XFCE.



 Whole thread becomes moot whenever an upstream Mate bugfix 
percolates to Debian repository.


I'm using only one "view port"(right term?) so feh as is is satisfactory.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Ric Moore]

On 05/25/2017 06:56 AM, Richard Owlett wrote:

On 05/24/2017 12:26 PM, Richard Owlett wrote:



The man page 
_mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
treat the whole X display as one screen when setting wallpapers."


I use one wallpaper across four screens. I just right click on the 
desktop, select "Desktop Settings", select your wallpaper and scroll the 
vertical bar down to reveal the settings you want (or make it full 
screen)  select "Spanning Screens" style and check "Apply to all 
workspaces.  Bob's your uncle, you should be set. Net, go to some wall 
paper site and find W_I_D_E wallpapers. :) Ric

p/s Using XFCE.

--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Thu 25 May 2017 at 10:38:22 -0500, David Wright wrote:

> On Thu 25 May 2017 at 12:18:44 (+0100), Brian wrote:
> > On Wed 24 May 2017 at 18:57:01 -0500, David Wright wrote:
> > 
> > > On Wed 24 May 2017 at 17:28:52 (-0500), Michael Milliman wrote:
> > > 
> > > > I installed and have been using feh as a stop-gap until the Debian
> > > > repositories catch up to upstream and/or fix the problem in Stretch.
> > > > Been working just fine, with its limitations.  It's better than a black
> > > > desktop. :)  I had to read the man page a couple of times and try it
> > > > another couple of times to make it work, but work it does.
> > > 
> > > I prefer to keep feh off my systems; its description is a lie.
> > > 
> > > feh - image viewer and cataloguer
> > > 
> > > It's an editor that has no concept of a buffer, but just scribbles
> > > over the original file. And, IIRC, the error message, when thwarted
> > > by a read-only file, is incorrect: it blames the permissions of
> > > the directory, not the file.
> > 
> > The description is not intended to deceive
> 
> It calls itself a viewer, and that is plainly deceptive when
> the program irrecoverably modifies the file with one keystroke,
> whether deliberate or not.

We'll agree on the deceptive, non-deceitful nature of the description,
then.

> > and the limited editing
> > functions are described in the manual.
> 
> One would hope they are. But most viewers I've come across do
> not modify the file when carrying out the trivial but vital
> operations one would expect to be present: orientation,
> flipping etc.
> 
> I would also point out that these single dangerous keystrokes
> are adjacent to other keys that one might expect to use, and
> can use, safely. Eg _ (invert) is next to +, | (flip) is next
> (British layout) to both A and Shift itself.
> 
> I really can't understand why these particular operations
> have been chosen to be in-place; it's grossly incompetent
> interface design.
> 
> > Scribbling can be avoided
> > (Ctrl+2 in the manual):
> 
> I wonder whether you realise that's a mouse command. Have you

It's strange what people wonder about. I suppose it comes from assuming
the other person lacks reading skills and never tests anything. Sad.

> tried holding down Control, then pressing and holding down
> both buttons within the prescribed time constraint, then
> trying to move another digit on the touchpad to get anything
> resembling a precise rightangle rotation?
> 
> No, this is an entirely different function from the flip/invert/
> rotate functions one expects in a viewer. Apropos these mouse
> commands, what's the mysterious "null button" (first in the list)
> that's meant to restore the image?
> 
> > https://github.com/derf/feh/issues/86
> 
> Oh, I see people agree with me. Depressingly, the < and > commands
> are legacy baggage, and derf (flagged as "Owner") says they will
> be kept. So, my choice, and it's no feh, period.

Glad to have helped. A primary source is rarely deceptive or deceitful.

Sometimes feh's modification of a file could have unwanted consequences.
Other times it is of no consequence. But carrying out any operation on
an original file at any time is to be avoided. I might be persuaded to
move from feh to something like qiv or mirage. Meanwhile, I'll stick
with action0, action1, etc to save and restore a file before it is
manipulated.

-- 
Brian.

-- 
Brian.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[David Wright]

On Thu 25 May 2017 at 12:18:44 (+0100), Brian wrote:
> On Wed 24 May 2017 at 18:57:01 -0500, David Wright wrote:
> 
> > On Wed 24 May 2017 at 17:28:52 (-0500), Michael Milliman wrote:
> > 
> > > I installed and have been using feh as a stop-gap until the Debian
> > > repositories catch up to upstream and/or fix the problem in Stretch.
> > > Been working just fine, with its limitations.  It's better than a black
> > > desktop. :)  I had to read the man page a couple of times and try it
> > > another couple of times to make it work, but work it does.
> > 
> > I prefer to keep feh off my systems; its description is a lie.
> > 
> > feh - image viewer and cataloguer
> > 
> > It's an editor that has no concept of a buffer, but just scribbles
> > over the original file. And, IIRC, the error message, when thwarted
> > by a read-only file, is incorrect: it blames the permissions of
> > the directory, not the file.
> 
> The description is not intended to deceive

It calls itself a viewer, and that is plainly deceptive when
the program irrecoverably modifies the file with one keystroke,
whether deliberate or not.

> and the limited editing
> functions are described in the manual.

One would hope they are. But most viewers I've come across do
not modify the file when carrying out the trivial but vital
operations one would expect to be present: orientation,
flipping etc.

I would also point out that these single dangerous keystrokes
are adjacent to other keys that one might expect to use, and
can use, safely. Eg _ (invert) is next to +, | (flip) is next
(British layout) to both A and Shift itself.

I really can't understand why these particular operations
have been chosen to be in-place; it's grossly incompetent
interface design.

> Scribbling can be avoided
> (Ctrl+2 in the manual):

I wonder whether you realise that's a mouse command. Have you
tried holding down Control, then pressing and holding down
both buttons within the prescribed time constraint, then
trying to move another digit on the touchpad to get anything
resembling a precise rightangle rotation?

No, this is an entirely different function from the flip/invert/
rotate functions one expects in a viewer. Apropos these mouse
commands, what's the mysterious "null button" (first in the list)
that's meant to restore the image?

> https://github.com/derf/feh/issues/86

Oh, I see people agree with me. Depressingly, the < and > commands
are legacy baggage, and derf (flagged as "Owner") says they will
be kept. So, my choice, and it's no feh, period.

Cheers,
David.

Re: Desktop Background Bites the Dust

[RavenLX]

On 05/21/2017 05:40 PM, David Christensen wrote:

As I understand it:

*   'apt-get upgrade' is for rolling forward to a new minor revision -- 
e.g. Debian 8.7 to Debian 8.8 -- and/or new packages -- e.g. icedove 
1:45.6.0-1~deb8u1 to thunderbird 1:45.8.0-3~deb8u1).


*   'apt-get dist-upgrade' is for rolling forward to a new major 
revision -- e.g. Debian 7 to Debian 8.



I do the former regularly -- once or more per week.


I avoid the latter, as it's caused me grief in the past (when I want to 
do a major version upgrade, I backup, move the system disk aside, do a 
fresh install, and restore).



My issue is likely tied to some software corner case due the the 
hardware -- e.g. 32-bit laptop with an off-spec 64-bit processor jammed in.


I've always used dist-upgrade for years without any problems. It's an 
old habit by now. If I don't, I learned there are some packages I *do* 
want to upgrade that get held back (ie. not upgraded) if I don't do 
dist-upgrade, such as new kernels (which I like to keep the kernel the 
newest out there). I haven't yet had any real major issues (even minor 
issues I've always found a work-around and 99% of the time it was just 
something I myself needed to configure, and not really a bug). I run 
stable so maybe that is why I have such good luck. On test VMs I do 
dist-upgrade basically because I know I can always start over if things 
go wrong. And Virtual Machines are the test systems anyway.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/25/2017 06:08 AM, Dejan Jocic wrote:

On 25-05-17, Richard Owlett wrote:

On 05/24/2017 12:26 PM, Richard Owlett wrote:

On 05/20/2017 09:31 PM, Michael Milliman wrote:

[snip]

The bug report also lists a workaround (which I haven't tried).


The workaround is using the feh package to manually set the background
image.  This does work, however, it has to be done each time you
log-in. It is better than nothing.  Upstream also appears to have
a bug reported on it, and they suggest installation of mate-desktop
16.2 with caja 16.3, neither of which has made it to the Debian
distribution as of yet.


Being one who emphatically avoids graphics I found a subtle gotcha.

The man page 
_mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
treat the whole X display as one screen when setting wallpapers."

An example command line to use would be (as a single line):
feh --no-xinerama /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg

It also does not mention how to set it as the wallpaper ;)
Once the above command has displayed the chosen image:
 1. right-click anywhere in the image
 2. chose File->Background->Set Filled from the displayed menu/sub-menus



If I had read the man page more slowly that using the menu to set the image
as wallpaper was unnecessary. Use:
feh --no-xinerama  --bg-fill
/usr/share/backgrounds/mate/desktop/GreenTraditional.jpg





It's been a while since I've used feh for background. Anyway, it should
save your choice in .fehbg file. And you should add that file to
autostart, to preserve your background settings.


I'd seen the option on my re-read but due to some other things I'm doing 
chose not to.

Thank you.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Brian]

On Wed 24 May 2017 at 18:57:01 -0500, David Wright wrote:

> On Wed 24 May 2017 at 17:28:52 (-0500), Michael Milliman wrote:
> 
> > I installed and have been using feh as a stop-gap until the Debian
> > repositories catch up to upstream and/or fix the problem in Stretch.
> > Been working just fine, with its limitations.  It's better than a black
> > desktop. :)  I had to read the man page a couple of times and try it
> > another couple of times to make it work, but work it does.
> 
> I prefer to keep feh off my systems; its description is a lie.
> 
> feh - image viewer and cataloguer
> 
> It's an editor that has no concept of a buffer, but just scribbles
> over the original file. And, IIRC, the error message, when thwarted
> by a read-only file, is incorrect: it blames the permissions of
> the directory, not the file.

The description is not intended to deceive and the limited editing
functions are described in the manual. Scribbling can be avoided
(Ctrl+2 in the manual):

https://github.com/derf/feh/issues/86

-- 
Brian.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Dejan Jocic]

On 25-05-17, Richard Owlett wrote:
> On 05/24/2017 12:26 PM, Richard Owlett wrote:
> > On 05/20/2017 09:31 PM, Michael Milliman wrote:
> > > [snip]
> > > > > The bug report also lists a workaround (which I haven't tried).
> > > > > 
> > > The workaround is using the feh package to manually set the background
> > > image.  This does work, however, it has to be done each time you
> > > log-in. It is better than nothing.  Upstream also appears to have
> > > a bug reported on it, and they suggest installation of mate-desktop
> > > 16.2 with caja 16.3, neither of which has made it to the Debian
> > > distribution as of yet.
> > 
> > Being one who emphatically avoids graphics I found a subtle gotcha.
> > 
> > The man page 
> > _mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
> > treat the whole X display as one screen when setting wallpapers."
> > 
> > An example command line to use would be (as a single line):
> > feh --no-xinerama /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
> > 
> > It also does not mention how to set it as the wallpaper ;)
> > Once the above command has displayed the chosen image:
> >  1. right-click anywhere in the image
> >  2. chose File->Background->Set Filled from the displayed menu/sub-menus
> > 
> 
> If I had read the man page more slowly that using the menu to set the image
> as wallpaper was unnecessary. Use:
> feh --no-xinerama  --bg-fill
> /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
> 
> 
> 
> 
It's been a while since I've used feh for background. Anyway, it should
save your choice in .fehbg file. And you should add that file to
autostart, to preserve your background settings.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/24/2017 12:26 PM, Richard Owlett wrote:

On 05/20/2017 09:31 PM, Michael Milliman wrote:

[snip]

The bug report also lists a workaround (which I haven't tried).


The workaround is using the feh package to manually set the background
image.  This does work, however, it has to be done each time you
log-in. It is better than nothing.  Upstream also appears to have
a bug reported on it, and they suggest installation of mate-desktop
16.2 with caja 16.3, neither of which has made it to the Debian
distribution as of yet.


Being one who emphatically avoids graphics I found a subtle gotcha.

The man page 
_mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
treat the whole X display as one screen when setting wallpapers."

An example command line to use would be (as a single line):
feh --no-xinerama /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg

It also does not mention how to set it as the wallpaper ;)
Once the above command has displayed the chosen image:
 1. right-click anywhere in the image
 2. chose File->Background->Set Filled from the displayed menu/sub-menus



If I had read the man page more slowly that using the menu to set the 
image as wallpaper was unnecessary. Use:
feh --no-xinerama  --bg-fill 
/usr/share/backgrounds/mate/desktop/GreenTraditional.jpg

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 05/24/2017 06:57 PM, David Wright wrote:
> On Wed 24 May 2017 at 17:28:52 (-0500), Michael Milliman wrote:
> 
>> I installed and have been using feh as a stop-gap until the Debian
>> repositories catch up to upstream and/or fix the problem in Stretch.
>> Been working just fine, with its limitations.  It's better than a black
>> desktop. :)  I had to read the man page a couple of times and try it
>> another couple of times to make it work, but work it does.
> 
> I prefer to keep feh off my systems; its description is a lie.
> 
> feh - image viewer and cataloguer
> 
> It's an editor that has no concept of a buffer, but just scribbles
> over the original file. And, IIRC, the error message, when thwarted
> by a read-only file, is incorrect: it blames the permissions of
> the directory, not the file.
> 
This is a real problem, and I have no intention of using it for any
other reason than as a temporary fix to the MATE desktop background
issue.  There are much better applications for viewing/editing pictures
(Eye of Gnome/MATE, and GIMP come to mind).  I expect that as soon as
the background issue is resolved, I'll probably remove feh from my
system as well, as it has no other use for me.
> Cheers,
> David.
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[David Wright]

On Wed 24 May 2017 at 17:28:52 (-0500), Michael Milliman wrote:

> I installed and have been using feh as a stop-gap until the Debian
> repositories catch up to upstream and/or fix the problem in Stretch.
> Been working just fine, with its limitations.  It's better than a black
> desktop. :)  I had to read the man page a couple of times and try it
> another couple of times to make it work, but work it does.

I prefer to keep feh off my systems; its description is a lie.

feh - image viewer and cataloguer

It's an editor that has no concept of a buffer, but just scribbles
over the original file. And, IIRC, the error message, when thwarted
by a read-only file, is incorrect: it blames the permissions of
the directory, not the file.

Cheers,
David.

Re: Clairification - was [Re: Desktop Background Bites the Dust]

[Michael Milliman]

On 05/24/2017 12:26 PM, Richard Owlett wrote:
> On 05/20/2017 09:31 PM, Michael Milliman wrote:
>> [snip]
 The bug report also lists a workaround (which I haven't tried).

>> The workaround is using the feh package to manually set the background
>> image.  This does work, however, it has to be done each time you
>> log-in. It is better than nothing.  Upstream also appears to have
>> a bug reported on it, and they suggest installation of mate-desktop
>> 16.2 with caja 16.3, neither of which has made it to the Debian
>> distribution as of yet.
> 
> Being one who emphatically avoids graphics I found a subtle gotcha.
> 
> The man page 
> _mentions_ setting wallpaper in passing my noting "Use --no-xinerama to
> treat the whole X display as one screen when setting wallpapers."
> 
> An example command line to use would be (as a single line):
> feh --no-xinerama /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg
> 
> It also does not mention how to set it as the wallpaper ;)
> Once the above command has displayed the chosen image:
>  1. right-click anywhere in the image
>  2. chose File->Background->Set Filled from the displayed menu/sub-menus

I installed and have been using feh as a stop-gap until the Debian
repositories catch up to upstream and/or fix the problem in Stretch.
Been working just fine, with its limitations.  It's better than a black
desktop. :)  I had to read the man page a couple of times and try it
another couple of times to make it work, but work it does.


> 
> 
> 
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Clairification - was [Re: Desktop Background Bites the Dust]

[Richard Owlett]

On 05/20/2017 09:31 PM, Michael Milliman wrote:

[snip]

The bug report also lists a workaround (which I haven't tried).


The workaround is using the feh package to manually set the background
image.  This does work, however, it has to be done each time you
log-in. It is better than nothing.  Upstream also appears to have
a bug reported on it, and they suggest installation of mate-desktop
16.2 with caja 16.3, neither of which has made it to the Debian
distribution as of yet.


Being one who emphatically avoids graphics I found a subtle gotcha.

The man page  
_mentions_ setting wallpaper in passing my noting "Use --no-xinerama to 
treat the whole X display as one screen when setting wallpapers."


An example command line to use would be (as a single line):
feh --no-xinerama /usr/share/backgrounds/mate/desktop/GreenTraditional.jpg

It also does not mention how to set it as the wallpaper ;)
Once the above command has displayed the chosen image:
 1. right-click anywhere in the image
 2. chose File->Background->Set Filled from the displayed menu/sub-menus

Re: Desktop Background Bites the Dust

[David Wright]

On Mon 22 May 2017 at 09:55:42 (+0200), to...@tuxteam.de wrote:
> On Sun, May 21, 2017 at 02:40:47PM -0700, David Christensen wrote:
> 
> [...]
> 
> > As I understand it:
> > 
> > *   'apt-get upgrade' is for rolling forward to a new minor revision
> > -- e.g. Debian 8.7 to Debian 8.8 -- and/or new packages -- e.g.
> > icedove 1:45.6.0-1~deb8u1 to thunderbird 1:45.8.0-3~deb8u1).
> > 
> > *   'apt-get dist-upgrade' is for rolling forward to a new major
> > revision -- e.g. Debian 7 to Debian 8.
> 
> It's not *that* drastic. Rolling forward usually implies doing
> something to your sources.list (unless you state there something
> like "stable" or "testing", which change their meaning when a
> release is made).
> 
> As far as I understood it (corrections welcome!):
> 
> Upgrade just upgrades packages to newer versions, as far as possible.
> It *never* removes packages, even if that means that it can't advance
> a package's version to the newest. Dist-upgrade would remove (replace)
> packages when necessary.

Nor will upgrade add a new, now necessary, package.

Cheers,
David.

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/22/2017 02:55 AM, to...@tuxteam.de wrote:
> On Sun, May 21, 2017 at 02:40:47PM -0700, David Christensen wrote:
> 
> [...]
> 
>> As I understand it:
> 
>> *   'apt-get upgrade' is for rolling forward to a new minor revision
>> -- e.g. Debian 8.7 to Debian 8.8 -- and/or new packages -- e.g.
>> icedove 1:45.6.0-1~deb8u1 to thunderbird 1:45.8.0-3~deb8u1).
> 
>> *   'apt-get dist-upgrade' is for rolling forward to a new major
>> revision -- e.g. Debian 7 to Debian 8.
> 
> It's not *that* drastic. Rolling forward usually implies doing
> something to your sources.list (unless you state there something
> like "stable" or "testing", which change their meaning when a
> release is made).
> 
> As far as I understood it (corrections welcome!):
> 
> Upgrade just upgrades packages to newer versions, as far as possible.
> It *never* removes packages, even if that means that it can't advance
> a package's version to the newest. Dist-upgrade would remove (replace)
> packages when necessary.
> 
> E.g. if you have some appfoo depending on libblurb, and there's a
> newer version of apfoo depending on libblah, which conflicts with
> libblurb, upgrade would be stuck at the older version, whereas
> dist-upgrade would (other dependencies allowing it) replace libblurb
> with libblah, thus clearing the path for apfoo's new version.
> 
I think you are correct on the way upgrade vs. dist-upgrade works.  I
wasn't sure myself, but your explanation brought it into focus and made
some stuff I've read before make sense.  Thanks :)
> cheers
> -- t
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray



signature.asc
Description: OpenPGP digital signature

Re: Desktop Background Bites the Dust

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, May 21, 2017 at 02:40:47PM -0700, David Christensen wrote:

[...]

> As I understand it:
> 
> *   'apt-get upgrade' is for rolling forward to a new minor revision
> -- e.g. Debian 8.7 to Debian 8.8 -- and/or new packages -- e.g.
> icedove 1:45.6.0-1~deb8u1 to thunderbird 1:45.8.0-3~deb8u1).
> 
> *   'apt-get dist-upgrade' is for rolling forward to a new major
> revision -- e.g. Debian 7 to Debian 8.

It's not *that* drastic. Rolling forward usually implies doing
something to your sources.list (unless you state there something
like "stable" or "testing", which change their meaning when a
release is made).

As far as I understood it (corrections welcome!):

Upgrade just upgrades packages to newer versions, as far as possible.
It *never* removes packages, even if that means that it can't advance
a package's version to the newest. Dist-upgrade would remove (replace)
packages when necessary.

E.g. if you have some appfoo depending on libblurb, and there's a
newer version of apfoo depending on libblah, which conflicts with
libblurb, upgrade would be stuck at the older version, whereas
dist-upgrade would (other dependencies allowing it) replace libblurb
with libblah, thus clearing the path for apfoo's new version.

cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkimX4ACgkQBcgs9XrR2kazUQCfd1Cc5Ca6lEeSq87HAHzrs3Sv
6JQAn1fQyd3vLq+nCa4Ar+iGSltqWdWa
=he1X
-END PGP SIGNATURE-

Re: Desktop Background Bites the Dust

[David Christensen]

On 05/21/2017 05:55 AM, RavenLX wrote:

On 05/20/2017 01:00 AM, Jimmy Johnson wrote:

On 05/19/2017 07:19 PM, David Christensen wrote:

I've been having problems with Xfce wallpaper on Debian 8.8 for a month
or more.  It broke after an apt-get update/ apt-get upgrade.  I filed a
bug report, received one reply, tried the suggestions to no avail, and
replied.  I'm still waiting for a response:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860925


David if it makes any difference, recently Debian installed a Debian
Stretch Theme and the Next wallpaper or the wallpaper you where using
could have been changed or I should say probably did get changed, I
run testing and Sid so I'm used to many themes being wiped out and
replaced, it's the way of testing and not something you would expect
from a stable system which Stretch is not, yet.  As I told Cindy, you
can find the installed wallpaper in /usr/share/wallpaper.


I haven't noticed any new wallpapers (I too am running Debian 8.8 with
XFCE and have my wallpaper set to one I like which I saved in
~/Pictures/Wallpaper) I also had no problems with the wallpapers going
away and also was able to change them in the settings. I do notice that
they don't all *stay* listed in the settings (except the current one
being used) if they are located somewhere other than the default
wallpaper directory. But other than that, no problems here, so far.

I did update using apt-get dist-upgrade and not apt-get upgrade. Maybe
that made a difference?


As I understand it:

*   'apt-get upgrade' is for rolling forward to a new minor revision -- 
e.g. Debian 8.7 to Debian 8.8 -- and/or new packages -- e.g. icedove 
1:45.6.0-1~deb8u1 to thunderbird 1:45.8.0-3~deb8u1).


*   'apt-get dist-upgrade' is for rolling forward to a new major 
revision -- e.g. Debian 7 to Debian 8.



I do the former regularly -- once or more per week.


I avoid the latter, as it's caused me grief in the past (when I want to 
do a major version upgrade, I backup, move the system disk aside, do a 
fresh install, and restore).



My issue is likely tied to some software corner case due the the 
hardware -- e.g. 32-bit laptop with an off-spec 64-bit processor jammed in.



David

Re: Desktop Background Bites the Dust

[Fungi4All]

 Original Message 
Subject: Re: Desktop Background Bites the Dust
UTC Time: May 21, 2017 12:55 PM
From: rave...@sitesplace.net

I haven't noticed any new wallpapers (I too am running Debian 8.8 with
XFCE and have my wallpaper set to one I like which I saved in
~/Pictures/Wallpaper) I also had no problems with the wallpapers going
away and also was able to change them in the settings. I do notice that
they don't all *stay* listed in the settings (except the current one
being used) if they are located somewhere other than the default
wallpaper directory. But other than that, no problems here, so far.

I did update using apt-get dist-upgrade and not apt-get upgrade. Maybe
that made a difference?

I had something similar happened once when I had moved the ../share/ folder 
into another partition and it was not mounted at the time it vanished. After 
the mount you either relog or attempt to change it and it is there.
But since the picture is still in the same folder and exists and you point to 
it and it will not display, then FEH does not have access rights to it, which 
is why the share folder with default accesses is best for things not needing 
security. I like to keep sensitibe information secure and everything else out 
in the open.
So, tell us what the rights of the actual picture show. Maybe removing feh 
completely and then reinstalling it will reset its access rights or something 
has made the shared picture more private.
By the way, that linux-PAE I understand is for 32bit systems which can't handle 
"too much" ram. If you don't have one of those systems it is safe to throw away 
unnecessary junk. Kernle files and images are bulky things and will 
unnecessaraly accumulate and slow down your updates. Either you need it and 
dump the non-PAE images or dump all the -PAE stuff. In a year or so you may 
have 6 or 8 linux kernels as the older ones are by default kept in case you run 
into trouble with newer packages braking. Instead of 2-3 you have double what 
is necessary.
If you have not ever used LXDE but are using X I suggest you give the racy 
desktop a try. One of the reasons that is nearing the end of development is 
because it is so damn perfect. It is like an old bmw M3-E30 with no upholstery, 
single seat and roll bars. No heat, no AC no stereo.
X is an eternal bulky pain

(AK)

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/20/2017 09:31 PM, Michael Milliman wrote:
> 
> 
> On 05/20/2017 06:33 PM, Michael Milliman wrote:
>>
>>
>> On 05/20/2017 01:56 PM, Mike Kupfer wrote:
>>> Michael Milliman wrote:
>>>
 I have no clue what happened, but the desktop background picture has
 ceased to be displayed.
>>> [...]
 I have attempted to re-set the desktop
 background via both system settings and via right-click->set desktop
 background on the desktop to no effect.
>>>
>>> I don't know what caused your old wallpaper to go away, but the
>>> inability to set it is tracked by
>>>
>>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862355
>>>
>> This appears to be the same problem.  I will be watching this bug report
>> with interest!!  It also seems to have been reported around the same
>> time my system went belly-up, so it is probably an update that was
>> installed.  Thanks for the info, at least I know it isn't something that
>> I botched up! :)
>>
>>> The bug report also lists a workaround (which I haven't tried).
>>>
> The workaround is using the feh package to manually set the background
> image.  This does work, however, it has to be done each time you log-in.
>  It is better than nothing.  Upstream also appears to have a bug
> reported on it, and they suggest installation of mate-desktop 16.2 with
> caja 16.3, neither of which has made it to the Debian distribution as of
> yet.
Note that the version numbers above should have been mate-desktop 16.0.2
and caja 16.0.3.
> 
>>> mike
>>>
>>
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Desktop Background Bites the Dust

[RavenLX]

On 05/20/2017 01:00 AM, Jimmy Johnson wrote:

On 05/19/2017 07:19 PM, David Christensen wrote:

I've been having problems with Xfce wallpaper on Debian 8.8 for a month
or more.  It broke after an apt-get update/ apt-get upgrade.  I filed a
bug report, received one reply, tried the suggestions to no avail, and
replied.  I'm still waiting for a response:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860925


David if it makes any difference, recently Debian installed a Debian 
Stretch Theme and the Next wallpaper or the wallpaper you where using 
could have been changed or I should say probably did get changed, I run 
testing and Sid so I'm used to many themes being wiped out and replaced, 
it's the way of testing and not something you would expect from a stable 
system which Stretch is not, yet.  As I told Cindy, you can find the 
installed wallpaper in /usr/share/wallpaper.


I haven't noticed any new wallpapers (I too am running Debian 8.8 with 
XFCE and have my wallpaper set to one I like which I saved in 
~/Pictures/Wallpaper) I also had no problems with the wallpapers going 
away and also was able to change them in the settings. I do notice that 
they don't all *stay* listed in the settings (except the current one 
being used) if they are located somewhere other than the default 
wallpaper directory. But other than that, no problems here, so far.


I did update using apt-get dist-upgrade and not apt-get upgrade. Maybe 
that made a difference?

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/20/2017 06:33 PM, Michael Milliman wrote:
> 
> 
> On 05/20/2017 01:56 PM, Mike Kupfer wrote:
>> Michael Milliman wrote:
>>
>>> I have no clue what happened, but the desktop background picture has
>>> ceased to be displayed.
>> [...]
>>> I have attempted to re-set the desktop
>>> background via both system settings and via right-click->set desktop
>>> background on the desktop to no effect.
>>
>> I don't know what caused your old wallpaper to go away, but the
>> inability to set it is tracked by
>>
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862355
>>
> This appears to be the same problem.  I will be watching this bug report
> with interest!!  It also seems to have been reported around the same
> time my system went belly-up, so it is probably an update that was
> installed.  Thanks for the info, at least I know it isn't something that
> I botched up! :)
> 
>> The bug report also lists a workaround (which I haven't tried).
>>
The workaround is using the feh package to manually set the background
image.  This does work, however, it has to be done each time you log-in.
 It is better than nothing.  Upstream also appears to have a bug
reported on it, and they suggest installation of mate-desktop 16.2 with
caja 16.3, neither of which has made it to the Debian distribution as of
yet.

>> mike
>>
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/20/2017 01:56 PM, Mike Kupfer wrote:
> Michael Milliman wrote:
> 
>> I have no clue what happened, but the desktop background picture has
>> ceased to be displayed.
> [...]
>> I have attempted to re-set the desktop
>> background via both system settings and via right-click->set desktop
>> background on the desktop to no effect.
> 
> I don't know what caused your old wallpaper to go away, but the
> inability to set it is tracked by
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862355
> 
This appears to be the same problem.  I will be watching this bug report
with interest!!  It also seems to have been reported around the same
time my system went belly-up, so it is probably an update that was
installed.  Thanks for the info, at least I know it isn't something that
I botched up! :)

> The bug report also lists a workaround (which I haven't tried).
> 
> mike
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/19/2017 09:19 PM, David Christensen wrote:
> On 05/18/2017 09:52 PM, Michael Milliman wrote:
>> I have no clue what happened, but the desktop background picture has
>> ceased to be displayed. I'm not even sure where to look to troubleshoot
>> the problem.  The salient information is: OS is fully updated Testing,
>> MATE desktop environment.  I have attempted to re-set the desktop
>> background via both system settings and via right-click->set desktop
>> background on the desktop to no effect.  Thinking that probably the
>> issue was associated with my normal login (the only one on the system),
>> I created a new user from root terminal and logged in with newly created
>> skeleton home folder; the problem persisted with the new user, so it is
>> a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
>> greatly appreciated.  Thanks in advance.
>>
> 
> I've been having problems with Xfce wallpaper on Debian 8.8 for a month
> or more.  It broke after an apt-get update/ apt-get upgrade.  I filed a
> bug report, received one reply, tried the suggestions to no avail, and
> replied.  I'm still waiting for a response:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860925
> 
This also appears to be a different problem, as I can (as far as all
software indications) change the picture and its geometry, but have
nothing actually displayed on the screen.  My desktop is black with the
various icons displayed on top of it regardless of my selections of
picture and/or geometry.  I have tried selecting the pictures that come
with the distribution as well as pictures in my personal folders, to no
avail; all I get is a black background.
> 
> David
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Desktop Background Bites the Dust

[Michael Milliman]

On 05/20/2017 01:26 PM, Mike Kupfer wrote:
> Cindy-Sue Causey wrote:
> 
>> If I try to change my images via either "Settings > Desktop" or right
>> click on the desktop, that directory and many others are now faded
>> out/washed out/blanked out in that way our systems do so that
>> something is not clickable.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849823
> 
This appears to be a different problem.  First, I'm using MATE desktop,
not XFCE, and secondly, I can select any folder/picture that I want, it
just has no effect.

> The report says it was fixed back in February.  I don't know what's
> needed to get the fix to propagate to Testing.
> 
> mike
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Desktop Background Bites the Dust

[Mike Kupfer]

Michael Milliman wrote:

> I have no clue what happened, but the desktop background picture has
> ceased to be displayed.
[...]
> I have attempted to re-set the desktop
> background via both system settings and via right-click->set desktop
> background on the desktop to no effect.

I don't know what caused your old wallpaper to go away, but the
inability to set it is tracked by

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862355

The bug report also lists a workaround (which I haven't tried).

mike

Re: Desktop Background Bites the Dust

[Mike Kupfer]

Cindy-Sue Causey wrote:

> If I try to change my images via either "Settings > Desktop" or right
> click on the desktop, that directory and many others are now faded
> out/washed out/blanked out in that way our systems do so that
> something is not clickable.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849823

The report says it was fixed back in February.  I don't know what's
needed to get the fix to propagate to Testing.

mike

Re: Desktop Background Bites the Dust

[Jimmy Johnson]

On 05/19/2017 07:19 PM, David Christensen wrote:

On 05/18/2017 09:52 PM, Michael Milliman wrote:

I have no clue what happened, but the desktop background picture has
ceased to be displayed. I'm not even sure where to look to troubleshoot
the problem.  The salient information is: OS is fully updated Testing,
MATE desktop environment.  I have attempted to re-set the desktop
background via both system settings and via right-click->set desktop
background on the desktop to no effect.  Thinking that probably the
issue was associated with my normal login (the only one on the system),
I created a new user from root terminal and logged in with newly created
skeleton home folder; the problem persisted with the new user, so it is
a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
greatly appreciated.  Thanks in advance.



I've been having problems with Xfce wallpaper on Debian 8.8 for a month
or more.  It broke after an apt-get update/ apt-get upgrade.  I filed a
bug report, received one reply, tried the suggestions to no avail, and
replied.  I'm still waiting for a response:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860925


David if it makes any difference, recently Debian installed a Debian 
Stretch Theme and the Next wallpaper or the wallpaper you where using 
could have been changed or I should say probably did get changed, I run 
testing and Sid so I'm used to many themes being wiped out and replaced, 
it's the way of testing and not something you would expect from a stable 
system which Stretch is not, yet.  As I told Cindy, you can find the 
installed wallpaper in /usr/share/wallpaper.

--
Jimmy Johnson

Debian Sid/Testing - KDE Plasma 5.8.6 - Intel E5300 - EXT4 at sda15
Registered Linux User #380263

Re: Desktop Background Bites the Dust

[David Christensen]

On 05/18/2017 09:52 PM, Michael Milliman wrote:

I have no clue what happened, but the desktop background picture has
ceased to be displayed. I'm not even sure where to look to troubleshoot
the problem.  The salient information is: OS is fully updated Testing,
MATE desktop environment.  I have attempted to re-set the desktop
background via both system settings and via right-click->set desktop
background on the desktop to no effect.  Thinking that probably the
issue was associated with my normal login (the only one on the system),
I created a new user from root terminal and logged in with newly created
skeleton home folder; the problem persisted with the new user, so it is
a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
greatly appreciated.  Thanks in advance.



I've been having problems with Xfce wallpaper on Debian 8.8 for a month 
or more.  It broke after an apt-get update/ apt-get upgrade.  I filed a 
bug report, received one reply, tried the suggestions to no avail, and 
replied.  I'm still waiting for a response:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860925


David

Re: Desktop Background Bites the Dust

[Jimmy Johnson]

On 05/18/2017 10:27 PM, Cindy-Sue Causey wrote:

On 5/19/17, Michael Milliman  wrote:

I have no clue what happened, but the desktop background picture has
ceased to be displayed. I'm not even sure where to look to troubleshoot
the problem.  The salient information is: OS is fully updated Testing,
MATE desktop environment.  I have attempted to re-set the desktop
background via both system settings and via right-click->set desktop
background on the desktop to no effect.  Thinking that probably the
issue was associated with my normal login (the only one on the system),
I created a new user from root terminal and logged in with newly created
skeleton home folder; the problem persisted with the new user, so it is
a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
greatly appreciated.  Thanks in advance.



I'm in Stretch Testing using Xfce4. Mine got zapped a while back. I
hadn't stopped to nose around about it until just yesterday. This
might not work for your problem, but I found mine are now at
/usr/share/images/desktop-base/.


All the system wallpaper installed can be found in /usr/share/wallpaper. 
I use a photo viewer to browse that folder.

--
Jimmy Johnson

Debian Stretch - KDE Plasma 5.8.6 - Intel G3220 - EXT4 at sda14
Registered Linux User #380263

Re: Desktop Background Bites the Dust

[Cindy-Sue Causey]

On 5/19/17, Michael Milliman  wrote:
> I have no clue what happened, but the desktop background picture has
> ceased to be displayed. I'm not even sure where to look to troubleshoot
> the problem.  The salient information is: OS is fully updated Testing,
> MATE desktop environment.  I have attempted to re-set the desktop
> background via both system settings and via right-click->set desktop
> background on the desktop to no effect.  Thinking that probably the
> issue was associated with my normal login (the only one on the system),
> I created a new user from root terminal and logged in with newly created
> skeleton home folder; the problem persisted with the new user, so it is
> a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
> greatly appreciated.  Thanks in advance.


I'm in Stretch Testing using Xfce4. Mine got zapped a while back. I
hadn't stopped to nose around about it until just yesterday. This
might not work for your problem, but I found mine are now at
/usr/share/images/desktop-base/. It's possible system images have
always been there, but for this very second, that appeared to be the
only place my personal images would also work.

Mine used to be under my /home/[user]/Pictures (~/Pictures) directory.
If I try to change my images via either "Settings > Desktop" or right
click on the desktop, that directory and many others are now faded
out/washed out/blanked out in that way our systems do so that
something is not clickable.

There must be something more to it. Or not? Maybe there's a quick
toggle somewhere? Or not.

For a single user with control over their own computer, it's no big
deal to take that few extra seconds to throw something in that
directory using [root] privileges. For an office full of users who
might want to personalize their respective desktops with family photos
or ski trip memories, it becomes a royal pain.

As an almost afterthought, there's always the possibility that what's
happening in my case is about installing and removing various packages
over time. Or not, grin.

This was another of those that rated a priority level of "Annoying"
for me. It wasn't critical to the functioning of my computer, and I
figure that feature may have been redesigned by... conscious design.
:)

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Desktop Background Bites the Dust

[Michael Milliman]

I have no clue what happened, but the desktop background picture has
ceased to be displayed. I'm not even sure where to look to troubleshoot
the problem.  The salient information is: OS is fully updated Testing,
MATE desktop environment.  I have attempted to re-set the desktop
background via both system settings and via right-click->set desktop
background on the desktop to no effect.  Thinking that probably the
issue was associated with my normal login (the only one on the system),
I created a new user from root terminal and logged in with newly created
skeleton home folder; the problem persisted with the new user, so it is
a system-wide issue.  Past that, I have no clue.  Any ideas/help will be
greatly appreciated.  Thanks in advance.
-- 
73's,
WB5VQX -- The Very Quick X-ray