Documentation Thoughts for Next Stable Release

I poked around a lot more, and still don't see any indication that there are scripts that would create the html tags, CSS styles, etc. This doesn't meant it's not there - just that I was unable to find them in this new buildbot world that I have never explored.

Could the page be generated by a fancy nginx default index page? If not, I'd love to get a pointer to the file that generates the "index.html" pages for the downloads site. Thanks!

I think that there is just a global style for showing directory contents, but there is no fancy HTML page for each directory. Just files in a directory that are shown using the default index page.

If you look at the download page contents with a html inspector, there is not much html stuff involved. The few styles are defined in the file header. No external CSS file.

I agree that the download page seems to be generated from a static template.

The genesis of my question was @jow's assertion on 9 Mar that the firmware directory listing was generated by a script, and could be tweaked to show the sha256sum for each file next to its link.

If there is a script file to format the directory listing, I'd be willing to take a shot at tweaking it to show the sha265sums...

The nginx configuration snippet is

    location ~ /(.*)$ {
            location ~ ^/(.*/(config\.seed|sha256sums|sha256sums\.gpg|Packages|Packages\.gpg|Packages\.manifest|Packages\.sig))$ {
                    default_type text/plain;
                    alias /home/mirror/downloads/$1;
            }

            alias /home/mirror/downloads/$1;
            index /dir-index.cgi/$1;
            autoindex on;

            location ~ /dir-index\.cgi/(.*)$ {
                    fastcgi_pass unix:/var/run/fcgiwrap.socket;
                    fastcgi_index dir-index.cgi;
                    fastcgi_param PATH_INFO $1;
                    fastcgi_param SCRIPT_FILENAME /usr/local/bin/dir-index.cgi;
                    include fastcgi_params;
            }
    }

The directory listing script (/usr/local/bin/dir-index.cgi) can be found here:

Thanks! Now for some perl fun! (Give me a week or so... I have to do my US tax filing :-))

I would prefer a view and a download link because if you are using an *nix OS it is way easier to just download the files and check the image with an *sum command.

Please ensure that it is possible to use scripts to automatically check if there is any *sum file in the folder and aotocheck the corresponding files.

I know that this is only interesting for advanced users but still very helpful. Thanks. :blush:

I think Nightly, Snapshot and Release are the terms to go with because they are wildly known in the software world and won’t be confused which anything else additional they will make it easier for people who know them already.

Anybody else in my opinion needs to learn them and the concepts behind them!

Every time you dive in to some new "worlds" there are some terms you have to get familiar with and after you will profit enormous from being able to talk about something and anybody knowing what you are talking about without the constant need to describe everything every time. I think this is one of these cases.

Update: Fixed an error in displaying file prefix. Sample output from my test process is at: http://test.richb-hanover.com/downloads/lede_download.html

Here's a replacement CGI that can format the downloads.lede-project.org pages. It's dir-index.cgi in https://github.com/richb-hanover/LEDE_Download_Index_Page

The script detects "/targets/" in the URL, and outputs the specially formatted index page that separates the "meta-files" from the other image files. For other directories, it just uses the current formatting.

@jow, @hnyman - I would appreciate a careful reading: it's been a long time since I've written any perl. Thanks!

@richb-hanover - thanks for the effort; I rolled the updated script out now after applying some slight tweaks (https://github.com/jow-/LEDE_Download_Index_Page/commit/29040cb810c9c144688ccd0749381f64c88ff5e9)

Thanks so much!

There seems to be some glitch in calculation of the "shortened filenames" prefix. Some platforms are ok (like ar71xx), but some others look strange (like e.g. ipq806x and mediatek)

http://downloads.lede-project.org/releases/17.01.1/targets/ipq806x/generic/
http://downloads.lede-project.org/releases/17.01.1/targets/mediatek/generic/

Shortened image file names below have the same prefix: lede-17.01.1-ip...
q806x-R7800-squashfs-factory.img

and

Shortened image file names below have the same prefix: lede-17.01.1-med...
iatek-NAND-squashfs-sysupgrade.tar

But ar71xx is ok:
http://downloads.lede-project.org/releases/17.01.1/targets/ar71xx/generic/

Shortened image file names below have the same prefix: lede-17.01.1-ar71xx-generic-...
wndr3700-squashfs-factory.img

Additionally, some platforms have "helper files" and I am not sure how the classification should be done. E.g. in mvebu there are two u-boot specilities (differently spelled...) that have been included in the firmware section, which decreases the possibility of shortening the target platform name from the image file names:

http://downloads.lede-project.org/releases/17.01.1/targets/mvebu/generic/

@hnyman - thanks for these comments.

re: Shortened filenames. You're right - the simplistic algorithm I used (first file name that starts with 'lede') isn't good enough. I have a couple thoughts for making it smarter.

re: Helper files. I would like to maintain the distinction between "Image Files" and everything else. I'm going to chew on this one for a bit. (Aside: I like the name "helper files" better than "meta-files"...)

Thanks again.

@richb-hanover I am already working on a fix, so you do not need to invest work just yet :slight_smile:

Image files are pretty clear, but the classification/naming the sections for the others is more difficult.
There are at least these types:

  • toolchain files (imagebuilder and SDK)
  • firmware build related files (checksums, config.seed, manifest)
  • packages directory
  • various device-specific "helper files" like those two u-boot utils that are probably needed for those devices.

From the perspective of an end-user who is installing a new firmware, only the image files, checksums and possible device-specific helper files are crucial. So I think that the device-specific helper files are more related to the images as they may be needed at firmware installation to the device.

Toolchain, manifest etc. are more for enthusiast builders. Packages directory is rarely needed as users usually install packages via opkg.

I reworked the script to be smarter when figuring out the common prefix and also moved the image files list before the others and renamed "meta files" to "supplemental files".

Looks much better, thanks :slight_smile:

Looks spectacular. Thanks!