[quote="tmomas, post:118, topic:123, full:true"]* Increased size to 160%, added one more column + re-added sidebar on https://wiki.lede-project.org/packages/index/start
Also the penguin is better, but I still think a white background in the icon would be welcome.
Wish/idea: add to luci/software page links to the wiki page (ideally to the individual details in the table)
[quote="robd3, post:122, topic:123, full:true"]
Wish/idea: add to luci/software page links to the wiki page (ideally to the individual details in the table)[/quote]Yeah, integration with wiki would be cool. Consider though that most info in the wiki table now is available from package lists used already (i.e. it can be shown in luci even without looking at the wiki)
Ok, uploaded new batch. we are now at around 5100 packages.
For some reason the script didn't read correctly the non-kmod packages that are provided by the new repo so you'll see some devel/util/net and so on, please don't report that as I know already.
There is some weirdness about firmwares with "wpan_802.15.4_support" submenu as this submenu name was given to various firmwares where it does not make sense (like for the raspberry Pi's GPU firmware, but there are others).
With nearly all categories loaded (there is some redundancy due to the devel/util/net issue above), the "package categories cloud" is pretty much worthless for a user (it's rather confusing, for users wanting an overview it's much better to use the index pages we just discussed), but the cloud view has value for maintainers (as it tells all categories and what categories are big/small) so it will probably survive in the maintainer view.
The tag names I used were supposed to be either "name" or "parent name -> child name", but it seems the wiki is eating up the ">" so I'll have to find a better way to tell what is the parent.
The kernel table is up. See here for all packages with kernel dependencies https://wiki.lede-project.org/packages/start?dataflt[4]=categories_%3Dkernel
the version states "see kernel for details", and the kernel dependency can be clicked to get to this table https://wiki.lede-project.org/packages/pkgdata/kernel (which was auto-generated).
Where you can see there are 2 devices stuck on 3.18.29, around 8 stuck on 3.18.43, a couple stuck at 4.1.34, and everyone else is up-to-date at 4.4.32.
I'm probably going to deal with all the shovelware packages about luci language support in a similar way than I've used for the kernel version.
I'm generating a new virtual dependency called similar to the luci language package for that luci package, and it will link to a page with a table where I list all the languages available for that luci package.
The updated category naming has plenty of redundancy, IMHO.
Example:
administration 15
administration_-_zabbix 8
-> Everything in administration_-_zabbix is also included in administration
Why is this so? Wouldn't it be sufficient to have those packages only in the zabbix subcategory?
I mean "administration_-_zabbix" says it all: this package is in "parent" category administration, and in subcategory zabbix.
The same applies for other categories.
That's also my observation. I would like to try to keep it useful, if possible.
Why not keep it as the wiki makes it, i.e. parent_-child?
BTW: The reason why the wiki does this: Since we want the categories to be clickable links to wikipages, the usual rules for pagenames apply: https://www.dokuwiki.org/pagename
Reading this, you will also notice that a name like "network-_ web_servers:proxies" is not a good idea, since the : identifies a namespace, which is not what we want here.
Two requests:
Categories_pkg-categorys : network #
It makes filtering with the pagequery plugin easier.
Dependencies_pkg-dependencies
In the datatable, you can click on the dependencies, in the dataentries, the linked pages do not exist.
_pages simply links to /packages/packagename -> doesn't exist
_pkg-dependencies links to /packages/pkgdata/packagename -> exists
The "pkgdata" is squeezed in via the datatype and can easily be adjusted to wherever the dataentry might be in the wiki.
[quote="tmomas, post:125, topic:123, full:true"]-> Everything in administration_-_zabbix is also included in administration
Why is this so?[/quote]Was for the cloud thingy, I thought having general category too would be cooler. It's... not really useful, and the index pages (that are much more useful than that) don't need it to work.
Will drop the redundancy.
[quote]That's also my observation. I would like to try to keep it useful, if possible.[/quote]imho one way is filtering its view by "only administration" or "only kernel" or "only whatever". Showing all like that is going to be confusing and some categories with like 1-2 elements will be very very tiny and unreadable, dwarfed by huge categories with 50+ elements.
[quote]Why not keep it as the wiki makes it, i.e. parent_-_child?[/quote] Well, yeah, that's ok if I drop the redundancy.
(unrelated, but not that much) Would be really cool to not have underscores though.
- Can I have ' #' at the end of the Categories line, i.e. like this
Categories_pkg-categorys : network #
ok.
- Please adjust the datatype of the dependencies like this:
Dependencies_pkg-dependencies
ok.
Reading this, you will also notice that a name like "network_-_ web_servers:proxies" is not a good idea
Yeah, you told me already in the last batch. I thought I had a filter to remove that.
We don't need them in the dataentries, but they will show up in the dataclouds, since they are links to wikipages :-/
a quick update: should have fixed most of the new packages categories, I'm now implementing the luci translation packages filter.
Should upload packages again this weekend.
@jow friendly reminder, there are still those useless package archs in the download page arm_cortex-a9_neon-vfpv4/ mips64_xlp/ mips64_xlr/ mipsel_1004kc/ ), there is also an empty target folder for ep80579 https://downloads.lede-project.org/snapshots/targets/x86/
Thanks, removed.
done another upload. There are still some entries that aren't good, but we are getting there. (and I forgot to check for the ":" in the categories name, again)
Here you can see here the language packages squashed down to a single metapackage per parent package. https://wiki.lede-project.org/packages/start?dataflt[Name_pkg-page*~]=luci-i18
This trick has removed 730 useless packages from the list.
Great, we're advancing step by step!
One issue though: Please do a
sudo chown -R www-data:www-data pkgdata/
in order to make the dataentries correctly accessible.
...and one more thing: Can you please insert underscores instead of spaces in categories?
Example: base system -> base_system
The underscore is added automatically when viewing the data in datatables and dataentries, however, for the index creation it would be helpful to have the underscores hardcoded in the category name.
@bobafetthotmail What do you think of including the packageindex creation into your script? I assume you have the complete list of categories anyways, which makes the index creation much easier.
Ok, can do that.
Package index pages seem to be mostly boilerplate, I think I can I just add a variable with the categories, like this and then print them.
~~NOSIDEBAR~~
{{pagequery>@packages:pkgdata (": $category_name," | ", $category_name," | "$category_name #");
fulltext;
sort=pagename;
cols=1;
bullet=disc;
border=both;
underline;
showcount;
hidejump;
layout=table;
fontsize=120%;
label=Packages in $category_name category;
}}
and the index:start page is 100% boilerplate, I just generate it again so I can just rm all files in that folder when I update them.
Btw, I had a look at the source and it seems like the php indexer page we are already calling to reindex the wiki has an additional command line argument.
if you use "-c" the comments in that file say it will erase the index before reindexing, I think it should remove the need to do database cleanups.
This unnecessarily re-indexes all pages, instead of only the changed dataentry pages. We should avoid that.
Categories with less than 25 items look better with cols=1, imho.
Spreading out say 7 items on 4 columns looks... strange.
(copy-pasted the same message I posted in the mailing list)
Lately the "Source: " entry was removed from package lists.
This is breaking the script I use to generate the package lists for the LEDE wiki's table of packages [1] and package indexes [2].
My script relies on that line to find the makefiles and download them from github, so it can read the package's Category and Submenu to categorize them in the same way they are shown in make menuconfig.
Many packages are generated using variable names in makefiles, trying to find their makefile now is very complex.
The "Source:" line was bloat for opkg, so I'm asking if it would be acceptable to have the build system generate a special package list exposing the info I need for the LEDE wiki.
I'm thinking about having Category and Submenu written already in there so I can also skip the "download and read makefiles" part in the script.
Can someone with more in-depth knowledge of the build system give me some directions?
Would it be an acceptable addition for LEDE as that's not directly needed by LEDE itself but by a bot running in the wiki server?
-Alberto
Hmm, found the file that removed that line (and others I didn't notice yet) https://github.com/lede-project/source/blob/master/scripts/ipkg-make-index.sh
and I can easily modify the file here https://github.com/lede-project/source/blob/master/package/Makefile to generate a second package list with that info enabled again.
I have yet to figure out how to add other info to it and if it is possible at all without polluting the "control" file in the package, as it seems Category and Submenu aren't available in the "control" file read by ipkg-make-index.sh
Happy new year! 
@bobafetthotmail Have you lately been working on https://lede-project.org/packages/index/start? I'm asking because it's not yet working as intended....
more like "it's exactly the same as a month ago", yes.
The patch to enable package manifest lists was accepted last week https://github.com/lede-project/source/pull/622
Should have time to finish the script this or next week.