imlib2, giblib, scrot; scrotwm

[laprjns]

Maybe if you installed spectrwm.desktop in both locations, you wouldn't get the error.

It's not important to eliminate the slk-pkgcheck warning; it just there to make the packager think and make appropriate changes if necessary. Adding the desktop file to /usr/share/applications/ will certainly eliminate the warning, but as you said it doesn't make sense to have a menu launcher so why add it.

[laprjns]

Regarding the problem with slkbuild-postgen (I vaguely remember this happening before; then, I think I just wrote that part of the report manually), I'm puzzled. The permissions on that file look ok (fakeroot isn't really root). Just for fun, I tried running the report generator as root, with the same result.

So in this case, I'm still worried I may have made a mistake somewhere.

I downloaded your spectrwm/2.0.2 directory and ran slkbuild-postgen on it. It produced the Buildscript and source links without problems.

Code: Select all

'''Homepage:'''
https://opensource.conformal.com/wiki/spectrwm

'''Package:'''
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-i486-1tjb.md5
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-i486-1tjb.txz
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-i486-1tjb.dep
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-i486-1tjb.src

'''Log:'''
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/build-spectrwm-2.0.2-i486-1tjb.log

'''Buildscript and source:'''
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/SLKBUILD
https://opensource.conformal.com/snapshots/spectrwm/spectrwm-2.0.2.tgz
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/LICENCE
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm.desktop
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/xinitrc.spectrwm
[[BR]]
[[BR]]
[[BR]]
'''Homepage:'''
https://opensource.conformal.com/wiki/spectrwm

'''Package:'''
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-x86_64-1tjb.md5
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-x86_64-1tjb.txz
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-x86_64-1tjb.dep
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm-2.0.2-x86_64-1tjb.src

'''Log:'''
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/build-spectrwm-2.0.2-x86_64-1tjb.log

'''Buildscript and source:'''
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/SLKBUILD
https://opensource.conformal.com/snapshots/spectrwm/spectrwm-2.0.2.tgz
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/LICENCE
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/spectrwm.desktop
http://people.salixos.org/mimosa/packages/spectrwm/2.0.2/xinitrc.spectrwm

Maybe a copy and past issue or a local problem with your slkbuild-postgen script. BTW I generally redirect slkbuild-postgen output to a file.

Code: Select all

rich[spectrwm]$ slkbuild-postgen -32 -64 2.0.2/ > spectrwm.postgen

[Tim CowChip]

Just installed i3 in Arch and yep, there's a menu entry for launching it from another window manager. I got an "no desktop file" warning for CurseTheWeather" which is run in a terminal, no gui, on the other hand, Cmus is also run from a terminal, no gui, but does have a desktop file and corresponding menu entry.

So..........I guess its up to the packager to add superfluous desktop files or live with heartbreak of slk-pkgcheck warnings.

[mimosa]

Ticket submitted. Thanks for all comments.

[laprjns]

JSo..........I guess its up to the packager to add superfluos desktop files or live with heartbreak of slk-pkgcheck errors.

Well, yes its up to the packager to determine if adding a desktop file to /usr/share/application would enhance the use of the package, but I would hope that one would not add unnecessary files just to make a warning message from a diagnostic tool go away. slk-build is just a tool to check packages against the various packaging rules. It's not a go / no go gage, but rather a check list of rules to evaluate the package against. In this case were discussing the "warning" that slk-build issues when there is no desktop file in the /usr/share/application directory. It's saying, "hey packager there no desktop file in the directory where there should be for the vast majority of packages (i.e. graphical applications). You should think about this and add one if you think it's required or would enhance the use of the application."

So lets look at the three application that you mention in regards to their use or not of a desktop file.

i3 source tarball includes a desktop file and it's make file installs the desktop file in both /usr/share/xsession and /usr/share/applications. it seems clear that it was the intent of the i3 develop to have a menu entry. Running slk-pkgcheck on a i3 package would result, as you said in not getting a warning (it's a warning, not an error) since there is a desktop file in /usr/share/applications. As I said in the my response to mimosa, slk-pkgcheck only looks for a desktop file in /usr/share/application, which is the required location for menu launchers.

CurseTheWeather is a console application using ncurses. There is no desktop file in the source tarball so one doesn't get installed as part of normal compiling of the program. Checking a CurdeTheWeather package with slk-pkgcheck would result in a warning (again it's not an error) that there was no desktop file. Using this information the packager can then determine if there is a need or desire for a desktop file and take the appropriate action based on his determination.

CMus is another console program that uses ncurses. There is no desktop file provided in the source tarball. However if you check the Salix package there is an desktop file in the source array which was added by the packager. The SLKBUILD has additional code to installed this desktop file in /usr/share/application directory. The packager made a conscious decision to add this to a package. Checking the slk-pkgcheck you will not get the warning since there is a desktop file installed in /usr/share/applications. If you check the Arch PKGBUILD you will see that there is no code to add a desktop file to the package. So the bottom line on this application, it's a packager decision to add the desktop file.

Back when i started packaging for Zenwalk, and before zen-pkgcheck (yes slk-pkgcheck is a fork of zen-pkgbuild) I had many packages rejected for missing desktop files when they should be there and icons installed in the wrong directory. slk-pkgcheck helps me avoid submitting packages with such errors.

[Tim CowChip]

Congratulations mimosa. I'm looking foward to seeing your name on the team page and installing spectrwm on Salix.

Back when i started packaging for Zenwalk, and before zen-pkgcheck (yes slk-pkgcheck is a fork of zen-pkgbuild) I had many packages rejected for missing desktop files when they should be there and icons installed in the wrong directory. slk-pkgcheck helps me avoid submitting packages with such errors.

Was that back when desktop files were actually located on the desktop (in the ~/Desktop folder), before they were turned into system-wide application launchers?

Edit

and lighten up, will ya?