Bug #3819
closedOn Webapp User Manual, clicking on PDF link sends ends up in 404
Added by Vincent MEMBRÉ about 11 years ago. Updated almost 11 years ago.
Description
When looking to Rudder documentation within Rudder webapp, the first link says that you read the documentation as PDF, but when clicking on it we got a 404 error ( which is very sad :( ).
You can also read the Rudder User Documentation in PDF format.
We should add the documentation in PDF format too.
Updated by Nicolas PERRON about 11 years ago
Not sure it will be possible to generate PDF on SLES...
Updated by Nicolas PERRON about 11 years ago
- Status changed from New to Discussion
- Assignee changed from Nicolas PERRON to Matthieu CERDA
Nicolas PERRON wrote:
Not sure it will be possible to generate PDF on SLES...
To build PDF, we need Docbook and dblatex but on SLES dblatex package does not exist.
In my opinion, there are five options:
- Build the sources from the official site http://prdownloads.sourceforge.net/dblatex/dblatex-0.3.2.tar.bz2?download
- Use the repository from the official website even if this is for OpenSuSE 12
- Use our internal debian VMs to build the PDF and add it to the package / Add the build logic into the rudder-web/SOURCES/Makefile
- Not building the PDF and explain in the User Manual that PDF are not available on SLES machines (sic...)
I'm not sure to know how to deal with this. What do you think Matthieu/Jon/Vincent ?
Updated by Matthieu CERDA almost 11 years ago
- Assignee changed from Matthieu CERDA to Nicolas PERRON
Why would we want to build the PDF on SLES when we have tons of decent OSes to do it ? Would'nt it be more intelligent to build the PDF on the CI itself, and then just wget/curl it from the CI at build time ?
Updated by Nicolas PERRON almost 11 years ago
Matthieu CERDA wrote:
Why would we want to build the PDF on SLES when we have tons of decent OSes to do it ? Would'nt it be more intelligent to build the PDF on the CI itself, and then just wget/curl it from the CI at build time ?
Because the community couldn't wget/curl this PDF and a build could be made by someone else than Normation.
Updated by Nicolas PERRON almost 11 years ago
- Assignee changed from Nicolas PERRON to Matthieu CERDA
Updated by Vincent MEMBRÉ almost 11 years ago
I think matthieu don't that the user would have to curl/wget it from normation, but that we would build it on the CI then add it to the package. at least download it before making the package.
Updated by Jonathan CLARKE almost 11 years ago
- Assignee changed from Matthieu CERDA to Nicolas PERRON
I think that there is no point trying to rebuild the PDF on each and every platform. This won't change anything, unlike code which may be linked to different libraries, versions, etc, a PDF is a PDF.
The best approach here is clearly to have one single "build" of the documentation, then re-use the results for all packages (on a related note, this is what we would like to converge towards for the Java WARs aswell, since they too are platform-independant. This approach has the added benefit of making each package build shorter (less to do).
In principle, although not necessarily in details, I agree with Matthieu's suggestion, that we build the PDF and HTML docs once, then get the packaging to get these files. I'm thinking that the SOURCES/Makefile would be most appropriate to get them, at the same time as we get the rudder-sources tarball.
Nicolas, I don't understand your comment about the community not being able to download them. These files are already available on rudder-project.org/rudder-doc-X.Y/ where X.Y is the major version number. Just take them from there.
Updated by Nicolas PERRON almost 11 years ago
- Status changed from Discussion to In progress
Jonathan CLARKE wrote:
I think that there is no point trying to rebuild the PDF on each and every platform. This won't change anything, unlike code which may be linked to different libraries, versions, etc, a PDF is a PDF.
The best approach here is clearly to have one single "build" of the documentation, then re-use the results for all packages (on a related note, this is what we would like to converge towards for the Java WARs aswell, since they too are platform-independant. This approach has the added benefit of making each package build shorter (less to do).
In principle, although not necessarily in details, I agree with Matthieu's suggestion, that we build the PDF and HTML docs once, then get the packaging to get these files. I'm thinking that the SOURCES/Makefile would be most appropriate to get them, at the same time as we get the rudder-sources tarball.
Nicolas, I don't understand your comment about the community not being able to download them. These files are already available on rudder-project.org/rudder-doc-X.Y/ where X.Y is the major version number. Just take them from there.
Ok, this was one of my proposition but I think that we didn't understand each other.
The problem is that if we build somthing with SOURCES/Makefile, we don't have anything to control that we have the needed packages unlike debian/control or SPECS/*.spec.
I suppose addind comments into the Makefile would suffice.
Updated by Jonathan CLARKE almost 11 years ago
Nicolas PERRON wrote:
Jonathan CLARKE wrote:
I think that there is no point trying to rebuild the PDF on each and every platform. This won't change anything, unlike code which may be linked to different libraries, versions, etc, a PDF is a PDF.
The best approach here is clearly to have one single "build" of the documentation, then re-use the results for all packages (on a related note, this is what we would like to converge towards for the Java WARs aswell, since they too are platform-independant. This approach has the added benefit of making each package build shorter (less to do).
In principle, although not necessarily in details, I agree with Matthieu's suggestion, that we build the PDF and HTML docs once, then get the packaging to get these files. I'm thinking that the SOURCES/Makefile would be most appropriate to get them, at the same time as we get the rudder-sources tarball.
Nicolas, I don't understand your comment about the community not being able to download them. These files are already available on rudder-project.org/rudder-doc-X.Y/ where X.Y is the major version number. Just take them from there.
Ok, this was one of my proposition but I think that we didn't understand each other.
The problem is that if we build somthing with SOURCES/Makefile, we don't have anything to control that we have the needed packages unlike debian/control or SPECS/*.spec.
I suppose addind comments into the Makefile would suffice.
No, you've misunderstood me. I am absolutely not suggesting building anything in SOURCES/Makefile. That is just wrong.
What I am suggesting is that the build happens only once ever, and that the results are uploaded somewhere where SOURCES/Makefile can just download them. So, in summary:
- A job that builds the docs and publishes them. We already have that, the docs are available on http://www.rudder-project.org/rudder-doc-X.Y/.
- Adding to SOURCES/Makefile for the package that needs the docs, just a curl/wget or two to get the pre-built docs.
Updated by Nicolas PERRON almost 11 years ago
Jonathan CLARKE wrote:
Nicolas PERRON wrote:
Jonathan CLARKE wrote:
I think that there is no point trying to rebuild the PDF on each and every platform. This won't change anything, unlike code which may be linked to different libraries, versions, etc, a PDF is a PDF.
The best approach here is clearly to have one single "build" of the documentation, then re-use the results for all packages (on a related note, this is what we would like to converge towards for the Java WARs aswell, since they too are platform-independant. This approach has the added benefit of making each package build shorter (less to do).
In principle, although not necessarily in details, I agree with Matthieu's suggestion, that we build the PDF and HTML docs once, then get the packaging to get these files. I'm thinking that the SOURCES/Makefile would be most appropriate to get them, at the same time as we get the rudder-sources tarball.
Nicolas, I don't understand your comment about the community not being able to download them. These files are already available on rudder-project.org/rudder-doc-X.Y/ where X.Y is the major version number. Just take them from there.
Ok, this was one of my proposition but I think that we didn't understand each other.
The problem is that if we build somthing with SOURCES/Makefile, we don't have anything to control that we have the needed packages unlike debian/control or SPECS/*.spec.
I suppose addind comments into the Makefile would suffice.
No, you've misunderstood me. I am absolutely not suggesting building anything in SOURCES/Makefile. That is just wrong.
What I am suggesting is that the build happens only once ever, and that the results are uploaded somewhere where SOURCES/Makefile can just download them. So, in summary:
- A job that builds the docs and publishes them. We already have that, the docs are available on http://www.rudder-project.org/rudder-doc-X.Y/.
- Adding to SOURCES/Makefile for the package that needs the docs, just a curl/wget or two to get the pre-built docs.
Ok. I was starting by the idea of building everything from source. Ÿou're right, this is smarter and the packages will continue to be buildable for external packager.
Updated by Nicolas PERRON almost 11 years ago
- % Done changed from 0 to 90
- Pull Request set to https://github.com/Normation/rudder-packages/pull/103
Pull Request URL added: https://github.com/Normation/rudder-packages/pull/103
Just need to test it.
Updated by Nicolas PERRON almost 11 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from Nicolas PERRON to Jonathan CLARKE
- % Done changed from 90 to 100
Jon, I've made some new modifications. Could you review the PR again please ?
Updated by Jonathan CLARKE almost 11 years ago
- Assignee changed from Jonathan CLARKE to Nicolas PERRON
Updated by Nicolas PERRON almost 11 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset packages:commit:3cedbd69edbcd4e8492f5258c7b3d23f4a208dd0.
Updated by Nicolas PERRON almost 11 years ago
Applied in changeset packages:commit:c5f20fac1d23f141f293950f8f87cc68de633d17.
Updated by Nicolas PERRON almost 11 years ago
This is strange, on Debian the PDF file is now rudder-doc.pdf.gz:
nperron@rudder-snapshot:/usr/share/doc/rudder$ ls -lh /usr/share/doc/rudder/pdf/ total 1.4M -rw-r--r-- 1 root root 1.4M Aug 30 15:12 rudder-doc.pdf.gz nperron@rudder-snapshot:/usr/share/doc/rudder$ ls -lh /usr/share/doc/rudder/html/ total 556K -rw-r--r-- 1 root root 144K Aug 30 15:12 agent_workflow.png -rw-r--r-- 1 root root 24K Aug 30 15:11 concepts.png -rw-r--r-- 1 root root 54K Aug 30 15:12 data_workflow.png -rw-r--r-- 1 root root 38K Aug 30 15:12 generate_policy_workflow.png drwxr-xr-x 4 root root 4.0K Aug 30 16:04 images -rw-r--r-- 1 root root 19K Aug 30 15:12 logoRudder.jpg -rw-r--r-- 1 root root 26K Aug 30 15:11 packages.png -rw-r--r-- 1 root root 23 Feb 26 2012 robots.txt -rw-r--r-- 1 root root 223K Aug 30 15:12 rudder-doc.html lrwxrwxrwx 1 root root 24 Aug 30 16:04 rudder-doc.pdf.gz -> ../pdf/rudder-doc.pdf.gz
Updated by Nicolas PERRON almost 11 years ago
Argh... this is due to dh_compress: dh_compress - compress files and fix symlinks in package build directories
I'll open a new bug for this.
Updated by Nicolas PERRON almost 11 years ago
Nicolas PERRON wrote:
Argh... this is due to dh_compress: dh_compress - compress files and fix symlinks in package build directories
I'll open a new bug for this.
I have opened #3895 for this issue.
Updated by Nicolas PERRON almost 11 years ago
- Subject changed from On webapp rudder-doc, clicking on PDF link sends ends up in 404 to On Webapp User Manual, clicking on PDF link sends ends up in 404
Updated by Nicolas PERRON almost 11 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 2.7.1, which was released today.
Check out:
- The release announcement: http://www.rudder-project.org/pipermail/rudder-announce/2013-September/000046.html
- The full ChangeLog: http://www.rudder-project.org/foswiki/bin/view/System/Documentation:ChangeLog27
- Download information: http://www.rudder-project.org/foswiki/Download/