Version: (using KDE KDE 3.4.1) Installed from: Unlisted Binary Package OS: Linux It appears that throughout KDE (including the docs.kde.org website!) links to GPL, FDL and any other licenses are broken. This seems to have to do with the fact that meinproc converts e.g. &underGPL; to a help:/appname/common/gpl-license.html URL, but the actual file is at help:/common/gpl-license.html (try by typing both URLs for any KDE application in konqueror, some seem to workaround it, for most apps [kdevelop, kdiff3, kdm tested] the first URL doesn't work, the second does). It's also reproducable by just browsing the help in the help center. Just find licensing, pages: more than 50% of them has broken links to GPL, FDL or other licenses. I presume the other 50% has a workaround for the problem (installing their own license files, or symlinks, etc.) A related problem occurs on the docs.kde.org. Go to docs.kde.org, choose any application with a handbook (again, kdevelop, kdiff3, kdm tested), click "Licensing" or "Credits and License". The page visible probably shows the sentence "This documentation is licensed under the terms of the GNU Free Documentation License." (or any other license). It contains a link to the respective license, which is always a broken link. For the help system, the problem would be solved if meinproc actually generated help:/common/*-license.html hyperlinks for "&under*;" tags. I don't have a solution for the website. The license files seem to be entirely missing, or at least I can't find them.
This appears to be an environmental issue, or possibly packaging. All doc subdirectories (should, in a normal KDE install) have a symlink to the common ../common directory, and all the documents you cite above work correctly on a default installation. You don't say which distribution your using - could you please? I have a suspicion about the cause and if I'm right it is specific to one distribution and those derived from it. As for the website, we're working on that one, so I'll leave this open for a while.
I'm using Kubuntu (debian based).
Can you please look in a doc directory and see if there is a symlink to ../common, and if in fact the common directory is there?
I checked. I get the impression 99% of the issue has been solved in the KDE 3.4.2 packages. (I reported the error while using KDE 3.4.1 packages) I find 6 subdirectories of /usr/share/doc/kde/HTML/en that do not contain a common->../common symlink on my system: 2 are from boson, a game. 1 is from kdevdoctreeview, which doesn't have the index.docbook+index.cache.bz2+common structure, so I don't know if it's a bug here. I suppose not. 2 are packages using the bksys build system (kio-locate, kdissert). I'll report this as an error to the author of bksys. Remaining: kio_audiocd, has only index.docbook, no common link and no index.cache.bz2 So, besides kio_audiocd and the website, I think this bug can be closed. I'll leave it open for the website, as suggested.
kio_audiocd should be installed under kioslave/audiocd.docbook, the kio_audiocd/* directory is no longer in SVN for 3.5, so that's resolved.
Changing component to note that the problem only occurs on the website
Thanks for reporting this. I will have a look how to best solve this on the webpage, today. I suppose I will simply set the symlinks to common/.
There seems to be still no kioslave/audiocd on the docs.kde.org...
Any reaction?
(In reply to comment #8) > There seems to be still no kioslave/audiocd on the docs.kde.org... Yes there is one: http://docs.kde.org/stable/en/kdemultimedia/kioslave/audiocd/index.html
I think this was fixed long ago (at the time of Burkhard's comment, #c10). The links to common were added for a long time by the generator script. Anyway, the new kdedocgen.py script (which replaced the previous "generator" script) ensures too that the links are correctly created and links like help:/common are correctly replaced with the pointer to the symbolic link to common (for kdelibs4 applications) or to the common kdoctools5-common directory (for KF5 applications). A better solution would be letting the XSLT take care of this replacement, but it's not an high priority item right now. For all the people still reading this: sorry if it took so long, but as I wrote it was most likely fixed already for a while.