but not how to lay hands on it. Anyone got any experience there?
opkg can’t find (or search) it.
I’d be happy with luynx of w3m too. I only want to dump rendered a small HTML table really, and curl and wget aren’t cutting it (return the HTML code for the table).
Alas that is not a built package, and needs building which is a can of worms for me as I haven’t got a build environment for doing that set up and so it’ll take some more (aargh) learning.
I wonder if Turris wouldn’t mind building it and adding it to the Omnia repo? It’s certainly available, and a cool util to have as an option on such a router. Demand is clearly low or it would be there, but here’s some modest demand ;-).
And my feeling is, Turris can build this and add it to the repos in like 30 mins net effort and it’ll take me a lot lot longer. And I would like it in the repos as I’m building a suite of tools for my own use that I’d happily share to anyone and would like the dependencies to be manageable. And part of the suite current sees me wanting to render a small web table in text (most of the real work I want to do in JSON anyhow, but this is a nicety). And rendering HTMl in text is a solved problem (aka elinks, links, lynx, w3m) not a wheel any of us has to reinvent.
Rather not. 'specially as it’s available as a openwrt package but for some reason not in the opkg repo. Be simple I think for Turris staff with skills to build it and add it to the repo. Take them a fraction of the time, I’m sure, that it would take me to do it (learning curve and all).
We wouldn’t mind, but although you have posted package reference, it is six years old and there is no such package in packages feed now. Basically I think that you want to just create whole new package (although based on Makefile you have posted). And we don’t want to maintain this package because it isn’t core element of Turris OS nor Turris specific. I would suggest you to try to push it to upstream (once it is in upstream we can pull it and build it). Or found someone to do it for you if you don’t feel on it.
You might want to try to use prebuilt SDK (see repo.turris.cz), just place package to package directory and run make -j1 V=99. You might be able to build it easier than you think.
Thanks. I’m happy to try quickly. But the issue is one of familiarity and time.
I’m puzzled that it needs much maintaining if included? I guess everything has a maintenance cost at some level as it has dependencies that may change and hence needs to be included in a testing suite to detect any breaks there perhaps.
But as I said, your mention of an SDK and packages at repo.turris.cz just throws me into a quick pot of confusion as I go there in my web browser and am confronted with nothing that resembles either, hence desirous of more detailed pointers. With some poking around and guesswork I can progress, but it is this that costs time and energy.
For example, I can see something like an SDK here:
But I could be looking in any of the omnia-* directories there and could benefit from an intro into what is there and how to interpret all those folders. It has the hallmarks of a repo for an sccs like git or svn but not quite either? Perhaps some more quick pointers or pointers to a how-to or doc would help?
In reality we wouldn’t test program it self, only “test” would be that it compiles (it has all required dependencies). This is because it isn’t exactly easy to write test for it and for same reason as I wrote (not core package for Turris) we wouldn’t invest time to do so. But if I am not mistaken Lede doesn’t test these types of programs either.
Maintenance problem is that someone have to care about that package, periodically check if there is a new version and update it if so. Yes it sounds like an easy job, sometimes it can eat up some time during update, but in general it’s an easy job. Why we don’t want to do it is because we already maintain over three hundred packages (yes around fifty of them is ours so checking for update is not required there), but accepting packages that are not clearly core Turris OS setups precedent and we could end up with thousands of packages to maintain. What we clearly want is that given package would be maintained by someone else (we would just compile it). If you are interest than we can setup some community Turris specific repository to show clear division.
omnia-* are different branches. Master is next release (mostly just technical branch). What you want to use is just plain omnia (also called as deploy), or a specific branch if you have router for example in rc.
Yes I was talking about that sdk. It contains compiled dependencies and tools, you need some what sensible Linux x86_64 machine with ccache installed to use it.
I was talking about packages repository. See feeds.conf.default file in sdk (yes naming madness, blame openwrt community not me O:-) ). Link you have linked contains opkg repository, so all compiled packages. But you want to use recipe to compile package. That is in some repository and in your case it’s what you have linked (Makefile and patches and such).
Unfortunately we have no documentation for this as that is some what implementation detail and it changes as development progresses (see difference between deploy and nightly, root directory is missing there but newly there are version files).
But you might be able to parse something on your own from this tutorial: Turris OS compilation from source codes [Turris wiki] (You don’t want to do exactly what documentation says as sdk you have linked is already fragment of this process, but it’s usage is same that is why I am linking it here). Even more can be seen from my own repository turris-myrepo - Scripts for my personal test repository for faster testing. It’s not complicated process, but it needs some initial investment to understand it. So if you have any questions just ask.