ok, will do the changes.
Please let me know when you are finished, since this possibility must not exist longer than needed.
I need to be able to test a few things for a few weeks or so at most, then I was hoping you could simply set the server to run the script every X days or so (it's using only the basic tools like wget/awk/sed/bash/wc, that should be installed already in most servers).
No problem to have this status for several weeks. We just must not forget to to disallow txt again after the tryout period.
Hm, btw, the LEDE releases_lede-release field should be left single as packages from trunk or older releases are different (different version/size for sure, maybe dependencies or mantainer too or whatever else may be different apart from the name), so they should have separate entries.
Since the name is the same it should link to the same package page though, correct?
As you like... if the package name contains also the version -> Name_pkg-page will link to a separate page for each version.
'Name: Package V1' -> links to 'package_v1'
'Name: Package V2' -> links to 'package_v2'
...
...and make that "Dependencies_pkg-pages" please. This way, dependencies will show up also as wiki pagelinks.
I prepared a packages page which contains all fields available for a package.
https://wiki.lede-project.org/packages/start
If you create the txt files correctly, they will show up automatically in this table. Magic! 
To see how the txt files are expected: https://wiki.lede-project.org/pkgdata/testpackage?do=edit
Ok, rebuilding.
Another question, would it be possible to disable edits to some/all package fields? My idea was that this system would fill them automatically by reading package lists and sources, and that any user edit should be directed to the package page (or sources).
Currently I need the edit interface enabled as I need to test things though, so don't turn it off now. 
...and make that "File size_pkg-filesize". This way, the kB gets added automatically.
Enter "23" -> will show up later as 23kB
The dataentry pages can be write protected, but only the whole page, not single datafields.
BTW: If you make it [quote="tmomas, post:37, topic:123"]
Maintainer_pkg-maintainer : |$package_maintainer
[/quote]
then the maintainer name will link to /contact
Mind the pipe in front of $package_maintainer.
sigh, I uploaded a batch of files and the media manager interface shows them correctly, problem is, they don't seem to show in the Site Map, nor in the table.
I think the wiki is placing them in a dedicated folder for uploaded things, not in the /pkgdata folder.
Waaaaah, the wiki is frustrating me. 
Will upload a zip for you to load them sometime in the future.
D'oh!
Sorry, I didn't think of the media manager uploading everything to the /media directory 
I moved the dataentries now to the correct location in /pkgdata.
Observations:
[quote="tmomas, post:49, topic:123, full:true"]Sorry, I didn't think of the media manager uploading everything to the /media directory [/quote]On the bright side, you can leave txt or whatever other extension enabled in the long term too.
On the dark side, you will need to move packages manually around a few times while I'm testing.
[quote] - Categories: Need to be separated by ','
[quote]- Maintainer: If you put a '|' (pipe) in front of the name, the name will automatically link to /contact[/quote]Not sure about how useful that would be, the recommended way to contact the mantainer is to open an issue/bugreport ticket anyway.
[quote]- LEDE release: Should we call it "snapshot" instead of "trunk"? This would fit better to https://downloads.lede-project.org/snapshots/ [/quote]I'd say no. That is trunk, built as snapshots daily or something.
Btw, I've found a way to shorten links. you must use the _wiki tag in the field name, then you can use wiki syntax to make the links as normal (also any other wiki syntax will work). They say here to not abuse this as it has a performance impact.
my test in the wiki here
EDIT: hmm, no it seems to show the text anyway in the table.
EDIT2: yes, it should work but you need to define that field as _wiki in the table too https://www.dokuwiki.org/plugin:struct:type_wiki
Just tested this with 6in4 entry, it shows as short link in the wiki too.
EDIT3: it seems I managed to screw up the database somehow, now there is a broken 6in4 entry I can't delete (I deleted the 6in4 entry text file and also tried to re-create the table, the borked entry persists). 
[quote="bobafetthotmail, post:50, topic:123"]
Should we call it "snapshot" instead of "trunk"? This would fit better to https://downloads.lede-project.org/snapshots/
I'd say no. That is trunk, built as snapshots daily or something.
[/quote]Well, to add some confusion to the discussion, "trunk" was actually main branch in the old SVN system, while now there is the "master" in git. Right now all old-timers still understand "trunk", but after a while it may start sounding weird.
A couple of comments to that table. You might need to adjust table column widths. Right now some look strange. E,g,
Adjust Luci to display max. 26 characters (= luci's own version string).
Longer version strings are cut to: "first 21c" + ".." + "last 3c"
The last 3 chars are used to preserve the possible PKG_REVISION string.
E.g. 'opkg' has only hash+PKG_REVISION, so using only start of the string
might not be optimal.
.
Ok, thanks for the clarification.
I think a better/modern naming would be "Nightly" then, as it is what most other projects use for similar "built-from-latest-est-est-development-sources-built-daily" releases.
This trunk-> Nightlies change should happen everywhere for consistency, but afaik that's only wiki or LEDE main site, so we can alter that fine.
[quote="hnyman, post:52, topic:123, full:true"]* version column is too wide.
[/quote]Yeah, also package name (same reason) will shorten both up as requested.
Consider that in most cases the actual table shown will have less fields
I would advise against it, for the performance reasons mentioned.
I tried this once with the ToH on a rpi2, and man, this was noticeable!
Sure, the machine the wiki is running on is no rpi2, but still, with 1000+ packages, this must have a huge impact on performance.
O - oh! You break it, you pay it... and that's going to be expensive!
Just joking, fixed it already 
[quote="tmomas, post:55, topic:123, full:true"]I would advise against it, for the performance reasons mentioned.
I tried this once with the ToH on a rpi2, and man, this was noticeable!
Sure, the machine the wiki is running on is no rpi2, but still, with 1000+ packages, this must have a huge impact on performance.[/quote]Can we still do a test with the current server and my package lists? (sent you a email with a tar.gz)
I mean, with all due respect (as it isn't meant for high-performance), but the raspi2's CPU is obsolete laggy garbage and its storage access speeds are subpar.
tgz uploaded, searchindex update is running.
Note: Please create the links without spaces.
[[ https://github.com/openwrt/packages/issues | Bug reports ]] -> [[https://github.com/openwrt/packages/issues|Bug reports]]
Links with spaces will be shown as "wanted pages" in the wiki, which is not what we want.
For future updates: Please upload it via the media manager, always with the same name. I've got a script in place that takes care of the rest.
lol, fixed.
The page is still showing the old entries through (in addition to the new ones), even if the text files were removed.
Also, yes, it takes quite a bit to load, I'll have to do more test tomorrow.
For future updates: Please upload it via the media manager, always with
the same name. I've got a script in place that takes care of the rest.
ok will do.
Does https://wiki.lede-project.org/packages/start work for you?
It times out here...
EDIT #1: Filtered now for LuCI to make the page load.
Seems this amount of data is a bit much for the plugin
EDIT #2: I removed "Architectures" from the datatable and put it on a separate page -> https://wiki.lede-project.org/packages/top
Filtered = less data to display = less time to load the page. This makes the page somewhat usable, although is takes a considerable amount of time for the page to load for e.g. "net" with >1000 packages.