packages trippy: add rust based traceroute tool trippy

Add a rust based network diagnostic tool inspired by mtr.

Maintainer: me Compile tested: mt7622 (Linksys E8450) Run tested: mt7622 (Linksys E8450)

Mar 11 '23 09:03 PolynomialDivision

I wonder why do we need to have this package in repository when other packages with the same functionality we already have here.

Mar 12 '23 07:03 BKPepe

looks like this one is more advanced. there's always a reason why it exists.

Mar 12 '23 09:03 1715173329

Yeah, but we should consider it like:

How many users will it use?
- Is it beneficial for us? It will increase hardware resources for anyone who is building OpenWrt build system with all packages
  - It is going to take more time to build it.
  - If we should have some standards or have policies like common GNU/Linux distributions, it is common that they take in their mind if the package makes sense to add or there are other alternatives, which can be used.
What about OpenWrt package maintainers?
- Can we have go from them or no-go?

Of course, there are multiple reasons why developers create their packages, but what about security, audits, etc.? I think we should look at Debian/Ubuntu how they does it and if they have this package in their distribution available.

Maybe @diizzyy has something to say about this.

Mar 14 '23 14:03 BKPepe

How many users will it use?

If you take a look at https://downloads.openwrt.org/stats/awstats.downloads.openwrt.org.allextra2.html, you may find the most packages in tree are not widely used.

How many users are going to use Node.js on their routers? As well as the borgbackup (even it was backported to 22.03 branch), transmission etc., why we need to run it on a router?

For netdata, with a 37 MB huge patch?

Is it beneficial for us?

Of course, just for some users who are interested in it.

It will increase hardware resources for anyone who is building OpenWrt build system with all packages

So why would normal users choose to build everything instead of just the ones they need. Basically, only unattended buildbots will do this.

It is going to take more time to build it.

This applies for any package.

If we should have some standards or have policies like common GNU/Linux distributions, it is common that they take in their mind if the package makes sense to add or there are other alternatives, which can be used.

The description of this repo:

Community maintained packages for OpenWrt.

It is very much like what AUR does. For the AUR package: https://archlinux.org/packages/community/x86_64/trippy/

Of course, there are multiple reasons why developers create their packages, but what about security, audits, etc.? I think we should look at Debian/Ubuntu how they does it and if they have this package in their distribution available.

Anything, as long as it is created by human beings, the so-called "security" problem may always exist.

I can see that you don't really like rust and its derivatives, but why? You've been asked by contributors but you‘ve never given a clear answer.

Mar 15 '23 04:03 1715173329

How many users are going to use Node.js on their routers? As well as the borgbackup (https://github.com/openwrt/packages/pull/19973#issuecomment-1335185051), transmission etc., why we need to run it on a router?

Each user has a unique configuration for his router and different demands for the router which he/she bought. I can provide some numbers from those who are willing to share and help to improve each Turris OS version.

Currently, I see that 3254 routers are involved in Turris Survey
- Transmission has 664 installations
- Netdata has 658 installations
  - Netdata has a large patch. That's what I can confirm and I won't argue about that
    - There is an issue with it https://github.com/openwrt/packages/issues/20015 and it was introduced in https://github.com/openwrt/packages/pull/16339#issuecomment-898591035 and you can see why. The size matters. It was requested and demanded that the netdata should run on the device with minimalistic resources.
- Node has even own its feed - https://github.com/nxhack/openwrt-node-packages
- Borgbackup is not such populated because the stable release of Turris OS is running on top of OpenWrt 21.02 release, but with LTS kernel 5.15. It was requested here: https://forum.turris.cz/t/borgbackup-package/13742

OT: Hey, @paper42 or @miska are there any plans to publish data from Turris Survey to the public? It would be quite nice to provide such details to the public and I doubt that those are sensitive data, so it will make some things easier to discuss. :pray: Also, from Turris routers, you provide monthly Sentinel reports, so it should be quite possible, I guess.

Regarding time build, I see that there was an improvement over the years and before Rust was introduced, each Turris build (3 devices) required 4 hours to have full build. In the past, it was quite a lot - 6 hours, 8 hours and even 1 day, etc. You can also check it here https://github.com/ynezz/openwrt-buildbot-workers-terraform#hetzner. That it is not just about Turris, but also about OpenWrt, if you want to push something fast, then it is an issue and you will need to rework the build system, so you can prepare and ship users only a few packages instead of full build.

Did you see how the 1st review of Rust ended up? In that case, your build workers need a lot of space and even though 2nd review went quite well, it adds the build overhead so from 4 hours of building, you end up with 8 hours, and buying better servers is not an option for most people.

Still I am not convinced that trippy should go in.

Mar 15 '23 10:03 BKPepe

Each user has a unique configuration for his router and different demands for the router which he/she bought. I can provide some numbers from those who are willing to share and help to improve each Turris OS version.

Currently, I see that 3254 routers are involved in Turris Survey

Transmission has 664 installations

Here's a simple question: what does a router do, and what does a NAS do?

Netdata has 658 installations

Netdata has a large patch. That's what I can confirm and I won't argue about that

There is an issue with it https://github.com/openwrt/packages/issues/20015 and it was introduced in https://github.com/openwrt/packages/pull/16339#issuecomment-898591035 and you can see why. The size matters. It was requested and demanded that the netdata should run on the device with minimalistic resources.

IMHO netdata is just a waste of resources on normal routers. Having a "cool" webUI is the only reason I could think for installing it. If you really care the size, why not go for collected? And we already have a LuCI called luci-app-statistics. It's not only tiny, but also powerful and advanced. This is the real tool if you want to monitor runtime data on embedded devices.

Node has even own its feed - https://github.com/nxhack/openwrt-node-packages

Yep, and free GitHub runners will require at least 5.5 hrs to compile all of them. I can't remember how long will a single node build take, but it should > 2 hrs.

Borgbackup is not such populated because the stable release of Turris OS is running on top of OpenWrt 21.02 release, but with LTS kernel 5.15. It was requested here: https://forum.turris.cz/t/borgbackup-package/13742

Then backporting it to your own source tree makes more sense to me. For what I feel, you are just very actively in merging the packages you need, then taking a very different approach to those unwanted ones.

Rust is the near futuer with many excellent features, which I'm sure you already know. It has also been introduced into the Linux Kernel. If we want to continue developing, then we cannot be constrained by "build time".

I agree that the current rust build system has a lot of stuffs to improve, especially the build time.

Why it requires so much long time? The main cause is llvm toolchain. llvm-bpf has been introduced since OpenWrt 22.03, and the build time has increased significantly since then. On fastest free GitHub runners, it takes ~1h40m to be completed. For the slowest ones, over 3 hours.

Unfortunately, the bring up of rust, builds another llvm toolchain. Take https://github.com/openwrt/packages/actions/runs/4391919685/jobs/7691372452 as an example, at least 1h40m was wasted on llvm toolchain, and the rest is for rust itself and its packages.

But we got a good news, the llvm toolchain can be reused (see https://github.com/openwrt/packages/pull/20629#issuecomment-1465219978), which can greatly speed up the build.

Mar 15 '23 11:03 1715173329

Here's a simple question: what does a router do, and what does a NAS do?

That's bad reasoning here, IMHO.

OpenWrt supports devices. which has min. 4 MB flash storage and as well min. 32 MB RAM (most likely MIPS devices), and on the other hand, you have devices such as ARMv7, ARMv8, and x86_x64, which have plenty of resources. So, if you bought the such a powerful device, you probably want to have an all-in-one solution, so why not. The device can do it and you can use it as a router together as NAS, DVB tuner and failover solution, so you plug there LTE/5G modem, etc. Even I do have somewhere Xiaomi Mi WiFi R3G, and even it has USB port, so yes, the scenario makes perfect sense to use it for it, and even their factory image provided NAS-capable things to end-users within their UI.

Ad) netdata

We are getting offtopic here, but what if you are not using LuCI at all? Yes, collectd or netdata could be similar, but netdata provides own UI and you can use it as server and agents can connect to it, so you can monitor more devices than only the router itself or even use netdata as agent on the router and you can check it somewhere else.

For what I feel, you are just very actively in merging the packages you need, then taking a very different approach to those unwanted ones.

That's your point of view and I am not here to make you to have different point of view.

Adding borg backup https://forum.openwrt.org/t/announcing-new-borgbackup-packages/143893 was discussed on OpenWrt forum as well. It is something what is not here and was added.
With adding new packages to this repository, with the quantity, the quality should go up also, right? Unfortunately, that's not what is happening. We have a lack of maintainers, and reviewers, and we are still adding new packages...
- I think I am quite active here and try to help others instead of others which are trying to add their own package and they don't care about it since then. E.g. packages like python-awscli, which is not maintained here, also another great example is gl-puli-mcu and ml-mifi-mcu packages, why the hell, I should compile them for mvebu or for any other routers? It does not make any sense. It should be compiled only for GL.iNet routers.

Ad) GitHub runners

I was talking about own infrastructure and you don't want to reuse GitHub runners for this reason. You want to have it on your control and do it more securely, if you care about security, right. As I said, the node feed, all the OpenWrt packages takes 4 hours, which could be quite lot, when you are working on it and trying to patch some security vulnerability and ship it to the end users.

When you are using GitHub runners, you need somewhere to upload the packages, which routers would download, right...

Ad) Then backporting it to your own source tree makes more sense to me.

Many open-source developers and projects are trying to give pieces of advice to others and I don't think is alright. I think there are plenty of projects, which are playing on their playground and they don't care about upstreaming their devices or helping even upstream, right? This needs to be changed. 🙏 🙏

Reference: https://forum.openwrt.org/t/industry-supporting-openwrt/144578/

If we want to continue developing, then we cannot be constrained by "build time".

Then the rust should be in the main repository like meson and ninja, which was not exactly recently introduced, but it is there I think for one month.

Let's do something more important here.

@PolynomialDivision should add his reasoning why he wants to add it here instead of opening more and more pull requests.
Others maintainers or community should be helpful and said that if they want to have this go in or not.

Mar 16 '23 09:03 BKPepe

I was talking about own infrastructure and you don't want to reuse GitHub runners for this reason. You want to have it on your control and do it more securely, if you care about security, right. As I said, the node feed, all the OpenWrt packages takes 4 hours, which could be quite lot, when you are working on it and trying to patch some security vulnerability and ship it to the end users. When you are using GitHub runners, you need somewhere to upload the packages, which routers would download, right...

I was taking GitHub runners as examples, to explain how long these programs will take for a single build. As I said before, rust toolchain itself will just take ~30 mins for build on a 2c2t runner, not 3 hrs, and it would be much faster on modern build servers.

You rose a very important problem about our build system: We have to rebuild all packages for just several ones, which is really painful and inefficient.

Unfortunately, it's not something that can be easily changed, but we do need to learn from alpine and AUR, to build for changed packages only, rather than everything.

However, I'm gonna end this pointless talk, and put my time on improving current rust build system.

Mar 16 '23 10:03 1715173329

@PolynomialDivision Could you please try to apply this patch and see how much time it will save

--- a/lang/rust/Makefile
+++ b/lang/rust/Makefile
@@ -11,7 +11,7 @@ PKG_RELEASE:=1
 PKG_SOURCE:=rustc-$(PKG_VERSION)-src.tar.gz
 PKG_SOURCE_URL:=https://static.rust-lang.org/dist/
 PKG_HASH:=eaf4d8b19f23a232a4770fb53ab5e7acdedec11da1d02b0e5d491ca92ca96d62
-HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/rustc-$(PKG_VERSION)-src/
+HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/rustc-$(PKG_VERSION)-src
 
 PKG_MAINTAINER:=Luca Barbato <[email protected]>
 PKG_LICENSE:=Apache-2.0 MIT
@@ -59,13 +59,11 @@ HOST_CONFIGURE_ARGS = \
 	--datadir=$(CARGO_HOME)/share \
 	--mandir=$(CARGO_HOME)/man \
 	--dist-compression-formats=xz \
-	--enable-llvm-link-shared \
-	--enable-llvm-plugins \
 	--enable-missing-tools \
-	--enable-ninja \
 	--disable-sanitizers \
 	--release-channel=stable \
 	--enable-cargo-native-static \
+	--set=llvm.download-ci-llvm=true \
 	$(TARGET_CONFIGURE_ARGS)
 
 define Host/Prepare

Mar 17 '23 14:03 1715173329

A lot of discussion is out of the scope of this PR but it mainly boils down to how much people (maintainers) are willing and have time to spend maintaing this repo. I think @BKPepe being reluctant is justified, shoehorning X because it's "possible" is not a sustainable solution in the end when we don't have enough maintainers to back it up. Just to give you an idea, FreeBSD slightly less than 3k open tickets (issues and submissions) and that's over a time span of 10+ years and covering ~55000 ports. OpenWrt's package repo have slightly less than 800 issue reports and PRs combined, a fraction of packages and issue oldest being ~8 years. Given the wide range of platforms and archs that are "supported" (and very different hardware configuration) I'd suggest that unless it's relatively small and widely portable it should reside in a separate repo and/or you might even want to consider a distro that's targets you hardware better...

Just my 2 cents...

Mar 18 '23 09:03 diizzyy

Okay, this reduced build to an hour. The current rust Makefile has some useless target dependencies (openssl etc.). Once they get removed, the build time can be further reduced.

Mar 19 '23 03:03 1715173329

@PolynomialDivision are there still efforts to add this tool? I just discovered this some weeks ago, and find it quite useful. I could also take care of maintainership if you would like to not do this ;)

Apr 22 '24 11:04 jonasjelonek