Bug 737032

Maybe related (in case this is just due to missing deps), the default "Utilities" menu creates entries that don't start by default either if adding JWM on top of a GNOME Desktop installation:

Calculator
Fonts
Magnify
Synaptic  :  okay, that's obvious and available in the repos
Window Properties  :  that one works

(In reply to comment #0)
> Description of problem: Selecting "Lock" in the JWM menu at the bottom left
> corner of the screen does not do anything. Perhaps a missing dependency on old
> xscreensavers?
> 
> 
> Version-Release number of selected component (if applicable):
> jwm-2.0.1-6.svn500.fc16.x86_64

Well, you have to install xscreensaver if you want that menu item to work (su -c "yum install xscreensaver"). When I created the package I was asked to put xterm as requires because it is the first item in the menu and of course is an essential tool when you log into JWM, and using the terminal you can install every package you want and also you can change the configurations in the menu, but I can't put all the menu entries as dependencies in the package. I don't consider this as a bug.

Sorry to hear that.

Then it is a bug. A packaging bug.

You could have created a meta-package "jwm-desktop", which depends on "jwm" *and* a minimum run-time environment including xterm, xscreensaver and utilities, e.g. the one needed for "Magnify" to work. That would make it convenient to install a JWM environment that works by default.

Users, who don't expect JWM to work like that, may install just "jwm" and customize it.

| SHOULD: The reviewer should test that the package functions as described.
| A package should not segfault instead of running, for example.

Menu entries, which don't work, don't pass this test. It is similar to a "Help" menu not displaying an applications help text due to being mispackaged or broken.

(In reply to comment #3)
> Sorry to hear that.
> 
> Then it is a bug. A packaging bug.
> 
> You could have created a meta-package "jwm-desktop", which depends on "jwm"
> *and* a minimum run-time environment including xterm, xscreensaver and
> utilities, e.g. the one needed for "Magnify" to work. That would make it
> convenient to install a JWM environment that works by default.
> 
> Users, who don't expect JWM to work like that, may install just "jwm" and
> customize it.
> 
> | SHOULD: The reviewer should test that the package functions as described.
> | A package should not segfault instead of running, for example.
> 
> Menu entries, which don't work, don't pass this test. It is similar to a "Help"
> menu not displaying an applications help text due to being mispackaged or
> broken.

I understand you. Let's find a way to solve this. I'm adding Mario Blättermann to the cc list, he was the reviewer of this package. Please Mario I'd like to hear your opinion about what Michael is proposing about JWM.

(In reply to comment #3)
Sorry for the delay, I wasn't aware of this.

> You could have created a meta-package "jwm-desktop", which depends on "jwm"
> *and* a minimum run-time environment including xterm, xscreensaver and
> utilities, e.g. the one needed for "Magnify" to work. That would make it
> convenient to install a JWM environment that works by default.
> 
The meta-package sounds good to me. I assume there are three kinds of users: Purists, who want to have a framework for their own customizations. Plug-inners, who are looking for a window manager for their integrated desktop environment, GNOME, KDE, Xfce, whatever. And couch potatoes, who want to have a JWM which runs out of the box with all the displayed menu entries. I assume there are not so many of the latter ones. But having a meta-package which solves the problems for the convenient audience would be fine anyway. BTW, neither Debian nor Opensuse or Ubuntu are shipping such a meta-package. They ship JWM "as-is". Well, doesn't mean that we also shouldn't have it.

> | SHOULD: The reviewer should test that the package functions as described.
> | A package should not segfault instead of running, for example.
> 
> Menu entries, which don't work, don't pass this test. It is similar to a "Help"
> menu not displaying an applications help text due to being mispackaged or
> broken.

Please don't forget, it's a SHOULD item. It's not mandatory to test all the features. Well, I did it partially, otherwise I hadn't noted the missing xterm. I'm the reviewer, and no more than that. I don't know about all of the peculiarities of a piece of software. I don't have to be a power-user of the software to be reviewed. That's a task for the packager, who has to _maintain_ the package, possibly over years.

Many thanks Mario for your response. I don't think we need this meta-package, but I can create it. And if I create this meta-package for JWM, I'd have to create a similar one for PekWM also, because it will be the same philosophy.

So, first of all, you are free to do with this bug report whatever you like to. I didn't submit it do demand anything. I don't know whether there are any Fedora users who use JWM. I find it wrong to offer a package that includes a default configuration file, which doesn't work. To add "xterm" but no other old-school deps appears to be a half-hearted decision. It is not even obvious whether non-working menu entries are due to a config file or a software bug.


> BTW, neither Debian nor Opensuse or Ubuntu are shipping such
> a meta-package. They ship JWM "as-is".

Is that a good thing or a bad thing? ;)

Let's not go down that road. It isn't any secret that some distributions ship some packages in an utterly broken form. Sometimes without noticing and fixing bugs over a period of years. As if no users ever use the software [anymore]. Not even the packagers themselves. The packaged software may have worked before, but no longer does because the system has changed, and nobody has noticed the incompatibility. Sometimes upstream projects have stalled. Sometimes they use a different OS environment and are not aware of the issues. We also face such problems occasionally, btw, not limited to non-responsive maintainers who could have retired their packages already at the same time they left the project silently.


> Please don't forget, it's a SHOULD item. 

Of course. I don't complain that this hasn't been noticed. Starting and exiting JWM would be the most basic test to check that it doesn't segfault. Opening the default menu would be another very simple test.


I expected a little bit of added value over installing from source tarball. Basic integration into the distribution, so the installed package works out-of-the-box. System-wide, for every user of a multi-user desktop machine. I wouldn't have to hunt for missing pieces and packages. Perhaps even encountering ancient entries for "Mosaic" instead of "Firefox" as a sane default. There are not even any hints on what Fedora packages would add the missing features.

/usr/share/doc/jwm-2.0.1/README : useless source install instructions


Apparently everybody is forced to modify the default config to be useful. Even a stripped down default config file would be better. To remove all the non-working entries.

For the package user, starting with only a slightly modified config file would be acceptable. It won't fix the missing dependencies, however. For example, I would need to create a private meta package to enforce availability of any packages that are needed for basic operation. Without such a package, an upgrade could erase a package I depend on.


I would have expected the jwm packager to be a jwm user and to include his own customized jwm config file as a fine default. The upstream jwm config file could still be kept as an XML example in %doc.


Okay, you decide whether you are happy with the current package. ;)

(In reply to comment #7)

> I would have expected the jwm packager to be a jwm user and to include his own
> customized jwm config file as a fine default.

Yes, I have used JWM for a while, and I had my own config file. I could use it to produce a meta-package.

After almost one year: Is there still interest in the mentioned meta package? If yes, could this be created while building jwm (using additional source files which go into a subpackage), or do we need a new package therefore?

It shouldn't be a problem to fix it with a new subpackage. E.g. let a new "jwm-core" obsolete "jwm < someversion-release" and let the "jwm" base package work out-of-the-box with more complete dependencies. Or vice versa.

Other than that, comment 7 and older are quite complete.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.