Bug 200881

Are you really using xscreensaver, not gnome-screensaver (default in FC5)? You
need to have rss-glx-gnome-screensaver installed for them to show up in the
preferences dialog.

yes, i'm using xscreensaver, i don't like the gnome-screensaver and i don't have
the gnome-sreensaver installed.

same ting with versions:
rss-glx-xscreensaver-0.8.1.p-5.fc5
rss-glx-0.8.1.p-5.fc5

Don't the hacks have to be added into /usr/share/X11/app-defaults/XScreenSaver
in order for xscreensaver to pick them up? 

same thing in fc6, no "really slick screensavers" in xscreensaver.

installed rpms:

xscreensaver-gl-extras-5.01-3.fc6
xscreensaver-base-5.01-3.fc6
xscreensaver-extras-5.01-3.fc6

rss-glx-0.8.1.p-6.fc6
rss-glx-xscreensaver-0.8.1.p-6.fc6

freealut-1.1.0-2.fc6
freeglut-2.4.0-10.fc6

note: there is no problem with rss-glx and gnome-screensaver, the problem exists
only with xscreensaver.

I can reproduce the problem here.

is there anyone with working rss-glx-xscreensaver's?

same problem as described in original bug report.
Versions:
$ rpm -qa|grep rss|sort
rss-glx-0.8.1.p-6.fc6
rss-glx-kde-0.8.1.p-6.fc6
rss-glx-xscreensaver-0.8.1.p-6.fc6
$ rpm -qa|grep screensaver|sort
rss-glx-xscreensaver-0.8.1.p-6.fc6
xscreensaver-base-5.02-1.fc6
xscreensaver-extras-5.02-1.fc6
xscreensaver-gl-extras-5.02-1.fc6
$ rpm -q freealut freeglut
freealut-1.1.0-2.fc6
freeglut-2.4.0-11.fc6

And FWIW:
$ getenforce 
Enforcing

the screensavers are still not working, not shown in fedora 7. maybe you want to
remove them from xscreensaver?

Sorry for being incommunicado for so long.

Mamoru, I had the impression that adding XML descriptions of the hacks to
/usr/share/xscreensaver/config was sufficient, but it seems I was wrong. If
xscreensaver needs hacks to be present in 
/usr/share/X11/app-defaults/XScreenSaver we'd need to have a safe way to add and
remove hacks in this file from other packages. I see that the app-default file
contains all of the hacks contained in the various xscreensaver subpackages but
that is obviously not something we can do for external packages ;-).

One idea would be to have an "update-xscreensaver-hacks" script which just grabs
the definitions of the available hacks from a well known location, or even from
the XML files (if upstream cooperates), adds some boilerplate to top and bottom
of that and writes the AD file anew. Packages could then just add their
descriptive files, run "updates-xscreensaver-hacks" in %post and %postun and
everything would be fine and dandy.

Of course, it would even be better if the list of avilable hacks would be
generated directly from the config/*.xml files without a detour through
XScreenSaver.ad...

Well, this is a historically long problem (for me).

Currently I don't do this because:

From: Jamie Zawinski <jwz>
Subject: Re: Current status of Fedora xscreensaver (5.00-22)
Date: Sat, 16 Sep 2006 13:11:07 -0700
To: Mamoru Tasaka <mtasaka.u-tokyo.ac.jp>
X-Mailer: Apple Mail (2.752.2)

I'm probably going to release 5.01 soon -- nothing major, mostly  
little bug fixes.  I put a copy of what I currently have at http:// 
www.jwz.org/xscreensaver/xscreensaver-5.01a1.tar.gz

After you've had a chance to look at that, can you mail me your  
current patches?  I'll apply some of them and then do the 5.01 release.

> Well, then
> 1. My recognition is xscreensaver is distributed under modified BSD
>    (i.e. BSD _WITHOUT_ advertising term), is it okay? If so, I want to
>    add the entry of rss-glx hacks to XScreenSaver.ad.in.
>    I think it is possible because XScreenSaver (BSD) and rss-glx (GPL)
>    are distributed seperately.

Actually the license that xscreensaver uses isn't quite the "modified  
BSD"; it contains says the copyright must appear "in supporting  
documentation", which is a requirement that GPL does not have;  
therefore, GPL declares itself incompatible with it, since GPL does  
not allow any restrictions that are not already in GPL.  So that  
"documentation" clause poses roughly the same problem as the  
"advertising" clause did.

It's a historical accident that that clause is in there (I don't feel  
strongly about it) but it's too late to change it now, since doing so  
would require the permission of everyone who had ever sent in a patch.

Anyway, the result is that I think it's illegal to bundle  
xscreensaver and the "really slick" savers together.

Several times I asked the author of those savers if he would change  
them to be dual licensed (GPL and BSD, similar to what Mozilla does)  
to make it possible to distribute them with xscreensaver, and he  
refused.

So, my feeling is, if he doesn't care, why should I? It's his loss.

I don't think there would be a problem with just listing the names of  
his savers in the .ad file, disabled by default; but I believe Red  
Hat is breaking the law if they distribute it.  The "really slick"  
stuff can only reasonably be interpreted as a plug-in/add-on to  
xscreensaver, not a distinct application.  They don't work as screen  
savers without xscreensaver, so the two of them together constitute a  
single work.  I think the only way out of this is for him to change  
the license.

There's a bug in bugzilla somewhere about this, and whoever at Red  
Hat was arguing with me about it seemed to be taking the attitude of  
"well, what the licenses actually *say* doesn't really matter that  
much, as long as nobody complains, it's fine."  I disagree.

And actually:
-----------------------------------------------------
* Wed Jan 05 2005 Ray Strode <rstrode> 1:4.18-15
- Remove xscreensaver-config-tool after some discussions with
  jwz.
- Take out some additional screensavers
-----------------------------------------------------

(In reply to comment #12)
> Well, this is a historically long problem (for me).

I see...

> Currently I don't do this because:
> 
> From: Jamie Zawinski <jwz>
> Subject: Re: Current status of Fedora xscreensaver (5.00-22)
> Date: Sat, 16 Sep 2006 13:11:07 -0700
> To: Mamoru Tasaka <mtasaka.u-tokyo.ac.jp>
> X-Mailer: Apple Mail (2.752.2)
> 
> I'm probably going to release 5.01 soon -- nothing major, mostly  
> little bug fixes.  I put a copy of what I currently have at http:// 
> www.jwz.org/xscreensaver/xscreensaver-5.01a1.tar.gz
> 
> After you've had a chance to look at that, can you mail me your  
> current patches?  I'll apply some of them and then do the 5.01 release.
> 
> > Well, then
> > 1. My recognition is xscreensaver is distributed under modified BSD
> >    (i.e. BSD _WITHOUT_ advertising term), is it okay? If so, I want to
> >    add the entry of rss-glx hacks to XScreenSaver.ad.in.
> >    I think it is possible because XScreenSaver (BSD) and rss-glx (GPL)
> >    are distributed seperately.
> 
> Actually the license that xscreensaver uses isn't quite the "modified  
> BSD"; it contains says the copyright must appear "in supporting  
> documentation", which is a requirement that GPL does not have;

Well, jwz is not a lawyer and I'm neither, but this is from the clause 1 of the
GPL V2:

"""
You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
"""

but that's neither here nor there because...

> therefore, GPL declares itself incompatible with it, since GPL does  
> not allow any restrictions that are not already in GPL.  So that  
> "documentation" clause poses roughly the same problem as the  
> "advertising" clause did.
> 
> It's a historical accident that that clause is in there (I don't feel  
> strongly about it) but it's too late to change it now, since doing so  
> would require the permission of everyone who had ever sent in a patch.
> 
> Anyway, the result is that I think it's illegal to bundle  
> xscreensaver and the "really slick" savers together.
> 
> Several times I asked the author of those savers if he would change  
> them to be dual licensed (GPL and BSD, similar to what Mozilla does)  
> to make it possible to distribute them with xscreensaver, and he  
> refused.
> 
> So, my feeling is, if he doesn't care, why should I? It's his loss.
> 
> I don't think there would be a problem with just listing the names of  
> his savers in the .ad file, disabled by default; but I believe Red  
> Hat is breaking the law if they distribute it.  The "really slick"  
> stuff can only reasonably be interpreted as a plug-in/add-on to  
> xscreensaver, not a distinct application.  They don't work as screen  
> savers without xscreensaver, so the two of them together constitute a  
> single work.  I think the only way out of this is for him to change  
> the license.

... even if at one point in time it could have been reasonably construed that
way (note the subjunctive), it would be no longer true with gnome-screensaver --
you see how well it works with gnome-screensaver and doesn't with xscreensaver?
After all, rss-glx is a thing of its own, with no shared code with xscreensaver,
able to burn CPU/GPU cycles on its own without the help of xscreensaver or
anything else (there's a reason the hacks are in /usr/bin ;-).

> There's a bug in bugzilla somewhere about this, and whoever at Red  
> Hat was arguing with me about it seemed to be taking the attitude of  
> "well, what the licenses actually *say* doesn't really matter that  
> much, as long as nobody complains, it's fine."  I disagree.

Again, Jamie isn't a lawyer and neither am I. He's entitled to his opinion as I
am to mine (which is that just maybe that what a license says isn't always what
jwz thinks it says). As it is, I'm perfectly willing to remove the xscreensaver
subpackage until its distribution has been cleared by legal. Perhaps discussing
this in a more broad venue like fedora-maintainers-list would be helpful.

> And actually:
> -----------------------------------------------------
> * Wed Jan 05 2005 Ray Strode <rstrode> 1:4.18-15
> - Remove xscreensaver-config-tool after some discussions with
>   jwz.
> - Take out some additional screensavers
> -----------------------------------------------------

Seems to me like Ray was tired of the discussion ;-). Well, I'm not.

I'm eager for your comments!

My opinion is ... actually I think there is no problem if I add the entry for
rss-glx to .ad.in file  As you said, there is gnome-screensaver, and
gnome-screensaver uses xscreensaver hacks with no legal complaint.

So I want to add rss-glx entry... and others. Now Fedora has some hacks
other than rss-glx which can be used as xscreensaver hacks.

I don't think that just adding external hacks to the .ad.in file is a real
solution. I tried it and putting stuff in there adds the entries in
xscreensaver-demo regardless of if a hack is present (i.e. the package in which
it's contained is installed or not). The hacks should be shown if they're
installed only. My idea was a script to build
/usr/share/X11/app-defaults/XScreenSaver from a header and a footer and some
description files (for xscreensaver-base, -extras, -gl-extras,
rss-glx-xscreensaver and whatever else packages that contain hacks). Put
together that would give the XScreenSaver file. Do you have another idea how
this could be achieved?

(In reply to comment #15)
> I don't think that just adding external hacks to the .ad.in file is a real
> solution. I tried it and putting stuff in there adds the entries in
> xscreensaver-demo regardless of if a hack is present (i.e. the package in which
> it's contained is installed or not). 
This should not be for xscreensaver 5.02 default.
Would you check if the item "ignoreUninstalledPrograms" in
/usr/share/X11/app-defaults/XScreenSaver and in ~/.xscreensaver 
is set correctly as "True"? (the values in ~/.xscreensaver overrides
those in XScreenSaver)

> The hacks should be shown if they're
> installed only. 
So please check above. And if you set ignoreUninstalledPrograms
as False in ~/.xscreensaver, you should see all hacks listed
in XScreenSaver (regardless of whether the hack is installed or not)
on xscreesaver-demo.

Currently this value ignoreUninstalledPrograms cannot be set on
xscreensaver-demo GUI and has to be set by editing .xscreensaver
directly.

> My idea was a script to build
> /usr/share/X11/app-defaults/XScreenSaver from a header and a footer and some
> description files (for xscreensaver-base, -extras, -gl-extras,
> rss-glx-xscreensaver and whatever else packages that contain hacks). Put
> together that would give the XScreenSaver file. Do you have another idea how
> this could be achieved?

So, IMO if ignoreUninstalledPrograms is working correctly (and
for me it is working), this is not needed.

(In reply to comment #16)

Still, you'd have to know about all the hacks available when building the
xscreensaver package. Using this scheme would mean:

- 3rd party people would have to keep you updated with any changes regarding to
hacks available
- you'd have to rebuild every now and then just to enable 3rd party screensaver
hacks, this means a) you'd have to rebuild every time something substantial
happens to external packages containing hacks and b) (for the user) downloading
the whole xscreensaver package just to see the new hacks which are in different
packages to begin with

One could argue that for the moment it were manageable with only
gnome-screensaver and rss-glx around for causing grief in this regard, but I'd
rather get something in place now that doesn't require you to get active every
time a new hack appears elsewhere.

What do you think?

Yes, actually I have been thinking of the issue you mentioned.

One of the ideas is that
* For xscreensaver side:
  - First preserve the contents of original XScreenSaver as XScreenSaver-master
    in /usr/share/X11/app-defaults
  - Move XScreenSaver to /etc and mark as %config [1]
  - ln -sf ../../../../etc/XscreenSaver /usr/share/X11/app-defaults/XScreenSaver
    (this case, for safe upgrades perhaps I must call
     rm -f /usr/share/X11/app-defaults/XscreenSaver and
     ln -sf ..... on %post? Currently /usr/share/X11/app-defaults/XscreenSaver
     is a file, not symlink)
  - Every time xscreensaver upgrades, 
    /usr/share/X11/app-defaults/XscreenSaver-master overrides
    /etc/XScreenSaver
  - Provide xscreensaver-register-hacks and xscreensaver-unregister-hacks
    (or xscreensaver-register-hacks)

* For hack provider side (e.g. rss-glx):
  - Call xscreensaver-register-hacks like
-------------------------------------------------------
[ -f /etc/XScreenSaver ] || exit 0
for hacks in biof ..... ; do [2]
   if ! grep -q $hack /etc/XScreenSaver ; do
      xscreensaver-register-hack $hack -r
   fi
done
-------------------------------------------------------
    for %post (for rss-glx upgrade) and %triggerin - xscreensaver-base
    (for xscreensaver upgrade: xscreensaver upgrade overrides
     /etc/XScreenSaver)

   - Call xscreensave-unregister-hacks like
-------------------------------------------------------
[ -f /etc/XScreenSaver ] || exit 0
[ $1 == 0 ] || exit 0
for hacks in biof ..... ; do [2]
      xscreensaver-unregister-hack $hack -r
done
-------------------------------------------------------
     on %preun (or simply ignore to unregister)

?? 
Note
[1] Well, as registering/unregistering hacks changes the contents
    of /etc/XScreenSaver and as upgrading xscreensaver overrides
    /etc/XScreenSaver, should /etc/XScreenSaver be marked
    as %verify(not not md5 mtime size) %config (with*out noreplace)?
[2] If calling rpm inner rpm scripts is allowed, this can be
    checked by `rpm -qf rss-glx | grep /usr/bin`, however I think
    (and I hear) this is not allowed so you have to write the
    list to be registered manually?

The problem with this method A is that when admin adds some hacks
manually, then each time xscreensaver or rss-glx upgrades, it is
totally forgotton again.
Well currently xscreensaver behaves as this
because /usr/share/X11/app-defaults/XscreenSaver is not a config file.
And if we mark /etc/XScreenSaver as %config, not %config(noreplace),
it can be allowed. What do you think?

(In reply to comment #18)

Uuuh... this is much too complicated for my taste, too many probable error
sources. And RPM triggers should be avoided like the plague if at all possible
-- "down that path lies madness" ;-).

I'd rather have something much simpler:

- Each hack-provider drops one or more files into e.g.
/etc/xscreensaver/hacks.d. These files could be structured like this:

title <title of the hack>
      command <command to invoke the hack>
      ...

For example:

title Qix (solid)
      command qix -root -solid -segments 100
      ...

There could be other keywords for the various markers used in XScreenSaver.ad. I
don't exactly know what lines beginning with dashes or "GL:" mean, so I better
keep my mouth shut, but these would have to be defined somewhere as well.

- Each hack-providing package (including xscreensaver-base) would call a helper
script ("xscreensaver-update-hacks") in its %post and (with the exception of
xscreensaver-base) %postun scriptlets. The script would take the hack definition
files, a suitable template for XScreenSaver.ad and produce the "real"
XScreenSaver.ad. It would also be possible to let it directly edit the
"*programs:..." lines in /usr/share/X11/app-defaults/XScreenSaver, but the first
approach seems safer to me.

- The xscreensaver package would call the script when installed/updated.

- The template would include a suitable warning line ("Make your local
configuration changes in the template file /path/to/XScreenSaver.template and
run /path/to/xscreensaver-update-hacks afterwards for the changes to take
effect."). Of course, this warning would make it into the final file, so users
wouldn't be dumbfounded by the change.

- The template file would be marked %config(noreplace), the generated .ad file
would be %ghost'ed so that it gets removed upon de-installation of
xscreensaver-base.

What do you think?

Umm..

* Each hack commands line (i.e. - default-n: webcollage -root
  -directory /usr/share/backgrounds/images/, for example) is actually
  *not* to be intended to be edited, because the options for each hacks
  are expected to be edited with xscreensaver-command and the file
  which is to be edited by xscreensaver-command is ~/.xscreensaver.
  i.e. On current style, /usr/share/X11/app-defaults/XScreenSaver
  is not aimed to be edited (at least for each hack's options).

  So if we are to split each hack's command line to seperate setting files,
  they should not be marked as %config.

* The characters which are written before actual command lines
  (like -, GL: and so on) have correspondins meanings.
  - (dash) means that this is not enabled by default.

  And... I forgot to note that as all rss-glx hacks are GL hacks,
  the command lines for rss-glx hacks should have GL: prefix.

* And IMO if we are to create XScreenSaver(.ad) file on scriptlets,
  XScreenSaver file should be moved to %_sysconfdir (i.e. /etc) and
  we must create symlink from the original place. Fedora packaging
  policy no longer accepts the files such as config files to be
  under /usr.

If the file or files containing the descriptions of the hacks need to be marked
as %config can be debated (e.g. a sysadmin could want to adjust the defaults for
new hacks), but I don't really care for one way or another.

BTW: what is "default-n" and why are there hacks described in XScreenSaver.ad
that don't have titles -- I assume the latter just get the command name as
title, right?

If you want, I could put together a small script like I outlined in comment #19
and attach it to this report, would you like that?

(In reply to comment #21)
> If the file or files containing the descriptions of 
> the hacks need to be marked
> as %config can be debated (e.g. a sysadmin could want to 
> adjust the defaults for
> new hacks), but I don't really care for one way or another.
Well, actually this is a subtle issue, however for the case that
while sysadmin doesn't change the setting file which already exists
he wants to add some hacks himself, the files may well be marked
as %config?

> BTW: what is "default-n" 
This is related with hack's visual like "GL:".

> and why are there hacks described in XScreenSaver.ad
> that don't have titles -- I assume the latter just get 
> the command name as title, right?
Yes (with the first character capitalized). The title is for
hacks which has multiple entries with different options.

> If you want, I could put together a small script 
> like I outlined in comment #19
> and attach it to this report, would you like that?
I will appreciate it!

Nils, what should we do about this?

I think it would be good if we can split XScreenSaver.ad.in (or do
some other method) by F8T3.

Nils, I tried to make XScreenSaver.ad modular in xscreensaver-5.03-2
in rawhide, which is available from:

http://koji.fedoraproject.org/koji/taskinfo?taskID=145049
http://koji.fedoraproject.org/packages/xscreensaver/5.03/2.fc8/

On this package, modular XScreenSaver.ad configuration files divided
between each hacks are placed under /usr/share/xscreensaver/hacks.conf.d/
and named "*.conf". And each hack configuration file under the directory
has contents like below:

Example: /usr/share/xscreensaver/hacks.conf.d/mirrorblob-2.conf
------------------------------------------------------------
           GL:      "MirrorBlob (color only)"                                 \
                                mirrorblob -root -colour -no-texture        \n\
------------------------------------------------------------

Then /usr/bin/update-xscreensaver-hacks (now in xscreensaver-base)
reads each *.conf files and undate /usr/share/X11/app-defaults/XScreenSaver
(which is now a symlink pointing to /etc/xscreensaver/XScreenSaver.ad).

Would you please try 5.03-2.fc8?

What's the matter with the empty "xscreensaver" package? I'd just drop the
corresponding %files section and make xscreensaver-base obsolete/conflict
xscreensaver <= (version since when xscreensaver is empty).

The update-xscreensaver-hacks script should possibly be moved to /usr/sbin -- it
shouldn't ever be called by a non-root user.

Is the script supposed to work with multiple hacks in one conf file? Mine looks
like this:

rss-glx.conf:
--- 8< --- rss-glx.conf ---
GL:     "BioF" \   
        biof -r \n\
GL:     "Busy Spheres" \
        busyspheres -r \n\
GL:     "Colorfire" \
        colorfire -r \n\
GL:     "Cyclone" \
        cyclone -r \n\
GL:     "Euphoria" \
        euphoria -r \n\
GL:     "Fieldlines" \
        fieldlines -r \n\
GL:     "Flocks" \ 
        flocks -r \n\
GL:     "Flux" \   
        flux -r \n\
GL:     "Helios" \
        helios -r \n\
GL:     "Hufo's Smoke" \
        hufo_smoke -r \n\
GL:     "Hufo's Tunnel" \
        hufo_tunnel -r \n\
GL:     "Hyperspace" \
        hyperspace -r \n\
GL:     "Lattice" \
        lattice -r \n\
GL:     "Plasma" \ 
        plasma -r \n\
GL:     "Skyrocket (silent)" \
        skyrocket -v 0 -r \n\
GL:     "Skyrocket" \
        skyrocket -r \n\
GL:     "Solarwinds" \
        solarwinds -r \n\
GL:     "SpirographX" \
        spirographx -r \n\
GL:     "Sundancer2" \
        sundancer2 -r \n\
--- >8 ------------------

And they aren't ever added to the XScreensaver ad file. Running
"update-xscreensaver-hacks" manually gives:

ignoring /usr/share/xscreensaver/hacks.conf.d/rss-glx.conf

I found that it in principle could ignore on two occasions, here it barfed on
the second one. You should provide more details what exactly is wrong with the
conf file, i.e. what you expected and why it failed.

Would be nice if you could add support for many hacks in one conf file.

Hello, Nils. Thanks for looking at my srpm!

(In reply to comment #25)
> What's the matter with the empty "xscreensaver" package?
This is metapackage just to pull xscreensaver-{base,extras,gl-extras}.
i.e. "yum install xscreensaver" will also install the 3 rpms
      automatically (similar with git)


> The update-xscreensaver-hacks script should possibly be moved to /usr/sbin -- > it
> shouldn't ever be called by a non-root user.
  Okay. I will move it to /usr/sbin on 5.03-3.

> 
> Is the script supposed to work with multiple hacks in one conf file?

  Well, I checked in cvs what you want to do and I changed update
  script to accept multiple hacks in one conf file (my original idea was
  not that, however allowing multiple hacks in one config is actually
  very reasonable). 5.03-3 update scripts should allow your rss-glx.conf.

Rebuild for 5.03-3 completed.
http://koji.fedoraproject.org/koji/taskinfo?taskID=145810
http://koji.fedoraproject.org/packages/xscreensaver/5.03/3.fc8/

Now update-xscreensaver-hacks is moved to %_sbindir and
the script should allow multiple hacks on one config (named *.conf).

Nils, would you check xscreensaver 5.03-3.fc8?

Looks good to me, I'm just building rss-glx-0.8.1.p-10.fc8 in koji which makes
use of the script -- I've built it locally and the generated AD file looks fine.
If it works out in Rawhide, we should build the fixed packages for F7.

OK, rss-glx-0.8.1.p-10.fc8 has built successfully. Let's see how this works out.

0.8.1.p-10 seems to work good for xscreensaver (I don't know
well about KDE screensaver...)

Now I am rebuilding 5.03-5 on both devel and F-7. Compared to
5.03-3, this just adds some comments on XScreenSaver.ad like
"don't edit by yourself, instead please edit this and that file",
so essentially same as 5.03-3.

When rebuild of 5.03-5 finishes, I will post on this bug.

Rebuild finished on both devel and F-7.

xscreensaver-5.03-5.fc8
xscreensaver-5.03-5.fc7.1 (due to tag mistake)

(In reply to comment #32)
> Rebuild finished on both devel and F-7.
> 
> xscreensaver-5.03-5.fc8
> xscreensaver-5.03-5.fc7.1 (due to tag mistake)

For F7, we should push both xscreensaver and rss-glx simultaneously. Bodhi now
offers to put multiple packages in one update -- If you wish, I'll push both of
them first for testing then after a while for final.

I'm building rss-glx-0.8.1.p-11.fc7 now for Fedora 7. When it's finished, I'll
push both of them to updates-testing (unless you object).

https://admin.fedoraproject.org/updates/pending/F7/rss-glx-0.8.1.p-11.fc7,xscreensaver-5.03-5.fc7.1

(In reply to comment #35)
>
https://admin.fedoraproject.org/updates/pending/F7/rss-glx-0.8.1.p-11.fc7,xscreensaver-5.03-5.fc7.1

Thank you.

Nils:

Very sorry, but please replace xscreensaver with
xscreensaver-5.03-6.fc7 (rebuild finished).

I rebuilt my local srpm which contains some screen hacks I collected
from Internet to use update script, then I found a mistake on
update script, sorry...

Mamoru, I've just edited the update and re-pushed for testing.

Thank you again!

rss-glx-0.8.1.p-11.fc7, xscreensaver-5.03-6.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

rss-glx-0.8.1.p-11.fc7, xscreensaver-5.03-6.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

I happened to read /usr/share/doc/rss-glx-0.8.1.p/README.xscreensaver
and I think this file is not needed for F-7 and devel

(However I also think that to release new rpms of rss-glx only
 to remove this file is not good for F-7.)

(In reply to comment #42)
> I happened to read /usr/share/doc/rss-glx-0.8.1.p/README.xscreensaver
> and I think this file is not needed for F-7 and devel

Fixed in rss-glx-0.8.1.p-12.fc8 for F8.