<ynezz>
xback: yeah, could be, those are purely cosmetic/convenience changes, so if its causing the troubles, feel free to drop those apalis patches, I can add them later
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
owrt-images-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-images-builds has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
<robimarko>
Is git.openwrt.org live?
<stintel>
robimarko: yes - it's slow though
<robimarko>
stintel: Ok, I am trying to get the feeds but I gave up and used GH
<stintel>
26|10:04:21 < jow> git.openwrt.org is currently getting hammered by random Alibaba.com ip ranges
gladiac has joined #openwrt-devel
<gladiac>
Now that we have rust-support in openwrt, building rust-packages is actually really easy. I just successfully built vaultwarden, an alternative bitwarden server written in rust.
<Ansuel>
gladiac my concern is size
<robimarko>
As long as its fully optional size isnt an issue really
<gladiac>
Yes, rust binaires are huge. The unstripped binary is 20MB
<robimarko>
And stripped?
<gladiac>
And that's without the web-ui.
<f00b4r0>
am i the only one to find that GH code browsing has become unbearably slow?
<robimarko>
To me it was always slow
<robimarko>
Though compared to Gitlab its fast
<f00b4r0>
idk it seems there new ui completely hogs my browser.
<f00b4r0>
must be progress :P
<dwfreed>
non-trivial files definitely take too much time to load
<gladiac>
robimarko: the stripped binary is about 15MB in size
<robimarko>
Its gotta be this new code higlight UI
<robimarko>
Which is more annoying then before
<f00b4r0>
indeed.
<jow>
15 friggin Megabytes for a glorified password list?
<jow>
and still no ui after that?
<jow>
what is it actually *doing* in this 15MB of code?
<jow>
that's larger than the entire OS it runs on, including TCP stack firewall and OS kernel
<stintel>
there's some trickery you can do to greatly reduce rust binary size, not sure if I took proper notes though last time I tried
<ynezz>
jow: I would like to build list of packages, their versions, licenses, CPE-IDs to construct SBOM (Software Bill Of Materials) in JSON format for later processing in SCA (Software Component Analysis) tools, like for example https://dependencytrack.org
<ynezz>
jow: so naturally tmp/.packageinfo seemed like a good start, but noticed those strange versions and wondering how to approach it properly
<ynezz>
jow: ok, apparently those {LINUX,LIBC,LIBGCC}_VERSION versions are not know yet during that scan process, so can't use it for this purpose solely
Danct12 has quit [Quit: WeeChat 4.1.0]
<lu_zero>
is there a good way for an init script to depend on another?
gladiac has joined #openwrt-devel
parazyd has quit [Quit: parazyd]
Danct12 has joined #openwrt-devel
<jow>
ynezz: correct.
<gladiac>
Defining CARGO_RUSTFLAGS:=-Cstrip=symbols in Makefile forces fully binary stripping (debuginfo and symbols) no matter what Cargo.toml says - so that's good
<lu_zero>
gladiac: might be nicer to use a custom profile even for that though
hitech95 has joined #openwrt-devel
<gladiac>
lu_zero: Thanks, I will look into this another time
parazyd has joined #openwrt-devel
<lu_zero>
gladiac: see lang/rust/files/cargo-config
<lu_zero>
we already do strip=symbols :)
<gladiac>
Hmm, however, V=s reveals that -Cstrip=debuginfo actually ends up in the final rustc command. Also, adding strip=symbols with CARGO_RUSTFLAGS really makes the resulting binary about 5MB smaller :)
<lu_zero>
interesting I was pretty sure true was equivalent to symbols
<lu_zero>
change the cargo-config and you'll be fine