<mangix>
I'm sure many improvements could be backported to lz4 from zstd
<dorf>
oh, wait, that's talking about ram reduction of snappy. nevermind.
<dorf>
still, a useful comparison table on that link.
<dorf>
zstd slower than lz4 to decompress.
<dorf>
better ratio, slower decompression.
<mangix>
yeah the coding scheme slows it down
philipp64_ has joined #openwrt-devel
<mangix>
aparcar[m]: when merging patches from patchwork, you want to change the state to accepted
<mangix>
so they get removed from the list
<mangix>
dorf: RAM usage is not a concern in most circumstances. but this is OpenWrt
<mangix>
hence why people recommend LZ4/ZSTD
<dorf>
indeed, indeed.
philipp64 has quit [Ping timeout: 265 seconds]
<dorf>
I feel somewhat blessed with the 500MB available here, and somewhat cursed by the firmware blob :)
<mangix>
what device?
<dorf>
wrt1900acs
philipp64 has joined #openwrt-devel
philipp64_ has quit [Ping timeout: 246 seconds]
<mangix>
I have 8GB on mine
<dorf>
storage, you mean? or ram?
<mangix>
storage
<mangix>
RAM is 2GB
<dorf>
yeah, 8GB storage on the wrt.
<mangix>
It's a Turris Omnia. Based on the same platform as the WRT devices
<dorf>
yeah, nice looking device, albeit a bit expensive.
<mangix>
The whole point of the router is to be overkill to be honest.
<dorf>
bought the wrt second hand for around $100US, suits me.. runs as a client, no problem with perf.
<mangix>
right. the platform is solid
<dorf>
it annoys me that marvell/nxp/belkin aren't coordinating on full opensourcing of the firmware, but other than that, no regrets.
<mangix>
right. that's one of the problems. the other is USB compatibility.
<dorf>
haven't experienced that issue. 2 thumb drives plugged in fine, one running as exroot, the other as swap.
<mangix>
One of my USB SATA interfaces can connect, the other can't.
<mangix>
Also, USB power between both ports is shared
<mangix>
The Turris Omnia having two USB ports was a bad idea.
<dorf>
one for storage, one for printer. sane in principle.
<mangix>
Right. But on most platforms, USB power is not shared.
<dorf>
yeah, I hear you.
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
Nick_Low_ has joined #openwrt-devel
Nick_Lowe has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
philipp64_ has joined #openwrt-devel
philipp64 has quit [Ping timeout: 246 seconds]
philipp64_ is now known as philipp64
Nick_Low_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gch98121388600 has quit [Read error: Connection reset by peer]
gch98121388600 has joined #openwrt-devel
<mangix>
interesting. pkgconfig also looks for files in /usr/share/pkgconfig
<mangix>
there's only a single package in OpenWrt that installs to there.
philipp64_ has joined #openwrt-devel
philipp64 has quit [Ping timeout: 265 seconds]
philipp64_ is now known as philipp64
gch981213886000 has joined #openwrt-devel
gch98121388600 has quit [Ping timeout: 246 seconds]
gch981213886000 is now known as gch98121388600
dorf has quit [Remote host closed the connection]
<ByteEnable>
The master is using a 5.4.x kernel. I noticed in the build make menuconfig the only selection for MVEBU based boards is a lump of 370/375/385. Whereas the 5.4 kernel offers granularity to only select the 38X based SoC's. Are there reasons for this?
hbug_ has joined #openwrt-devel
hbug has quit [Ping timeout: 240 seconds]
<mangix>
ByteEnable: no idea what that means.
<mangix>
there are multiple mvebu platformas
<mangix>
*platforms
<ByteEnable>
CONFIG_ARMADA_370_CLK=y
<ByteEnable>
CONFIG_ARMADA_370_XP_IRQ=y
<ByteEnable>
CONFIG_ARMADA_370_XP_TIMER=y
<ByteEnable>
# CONFIG_ARMADA_37XX_WATCHDOG is not set
<ByteEnable>
CONFIG_ARMADA_38X_CLK=y
<ByteEnable>
CONFIG_ARMADA_THERMAL=y
<ByteEnable>
CONFIG_ARMADA_XP_CLK=y
<ByteEnable>
From 5.4. If I manually make menuconfig and select the SoC which is a 385 used by my wrt3200acm, only 38X is selected in the config.
<ByteEnable>
In the openwrt build it is selecting all ARMADA devices.
<mangix>
expected behavior
<ByteEnable>
Then there is really no diff between Armada 370 vs 385?
<ByteEnable>
From what I can tell it is being used to select the boot and dts sutff.
<mangix>
different dts files are used but same kernel
<ByteEnable>
I just haven't looked at how deep those options might go. So that is why I am asking.
gnustomp has quit [Read error: Connection reset by peer]
gnustomp has joined #openwrt-devel
<Tapper>
Hi people. From the forums.
<Tapper>
I am trying to port OpenWrt to the Wink Hub v1, which is an i.MX28-based board with a whole bunch of IoT radios attached via serial ports. The standard flash has updater_kernel and updater-root partitions intended for recovery and update purposes, which appears to be ideal for messing around with OpenWrt, but still keep the ability to boot back to a working OS.
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hurricos has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
<aparcar[m]>
rsalvaterra: I merged your kmod-lib-zstd patch
<rsalvaterra>
aparcar[m]: I just noticed it, thanks! :)
madwoota has quit [Quit: .]
madwoota- has joined #openwrt-devel
<rsalvaterra>
Still trying to upstream my zram patch to allow disabling lzo, but I hit a snag with the ppc44x defconfig, which broke for some unfathomable reason.
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aparcar[m]>
good luck
<rsalvaterra>
Heh… I'll try to reproduce it on my dog-slow iBook G4, eventually, when boredom hits hard.
nast has quit [Read error: Connection reset by peer]
nast has joined #openwrt-devel
<blocktrron>
aparcar[m]: would've been nice if a decision on the 802.11b disable PR could have waited after the weekend
<blocktrron>
In the end, WiFi interoperability specifically states that these rates are mandatory
<ByteEnable>
musl libc faq says libpthread.a should exist but the package libpthread has nothing lib is empty.
cp- has quit [Remote host closed the connection]
<blocktrron>
I know this is only the standpoint of the alliance, however I greatly dislike the idea we ship the default configuration in a state where even modern stuff has trouble performing network discovery.
<ByteEnable>
librt is empty as well. If I make musl on the host I get librt.a and libpthread.a .
<jow>
ByteEnable: it makes no sense to install static .a libraries on openwrt
<jow>
why would you want that?
<ByteEnable>
That is how is musl redirects apps to use its thread library.
<jow>
no it doesn't
<ByteEnable>
Why even include empty librt and libpthread as packages in openwrt.
<jow>
because we also support compilation with glibc or uclibc, there librt and libpthread are separate
Nick_Lowe has joined #openwrt-devel
<ByteEnable>
From the musl faq: Why not just omit libm.a, libpthread.a, etc. entirely? POSIX says -lm, -lpthread, etc. are valid options to the compiler and conforming applications must use these options when they need the corresponding functionality, and the easiest way to comply with that requirement (and avoid breaking applications) is with empty .a files by those names.
<jow>
correct
<jow>
but we do not *compile* on target
<jow>
hence no need to ship *.a libraries just to satisfy compile time flags
<ByteEnable>
But why offer empty packages in openwrt?
<ByteEnable>
Your defending brokenness.
<jow>
so that packages can have the same DEPENDS:= regardless of whether they're built with glibc or musl systems
<ByteEnable>
So you package empty ipk's for naught.
christiandr has quit [Quit: "Mit dem ersten Glied ist die Kette geschmiedet. Wenn die erste Rede zensiert, der erste Gedanke verboten, die erste Freiheit verweigert wird, sind wir alle unwiderruflich gefesselt"]
<ByteEnable>
I can gcc on target to compile apps.
<ByteEnable>
*I can install
<jow>
right
<jow>
but it's not officially supported
<jow>
and lib* ipk archives would not be the proper ones to ship *.a libraries since nothing uses it at runtime (they're only used for linking apps)
Tapper has joined #openwrt-devel
<jow>
lib*-dev packages would be the appropriate place, but OpenWrt does not support these
<ByteEnable>
There is a package named gcc which says its supported no?
<jow>
gcc is a feed package, maintained by the community
<jow>
openwrt does not support on-target ocmpilation, there's no base-supported toolchain on target
<ByteEnable>
Okay. So then why package empty ipks?
<jow>
so that packages that require librt or libpthread functionality which are built for systems using uclibc or glibc instead of musl can use the same DEPENDS:=
<jow>
openwrt used to ship with uclibc by default, so librt and libpthread are actual libs there
<jow>
a few targets still use uclibc
<ByteEnable>
But musl is the default support for openwrt right?
<jow>
for most, but not all targets
<jow>
some targets still use uclibc
<ByteEnable>
To get glibc you must do your compile right?
<jow>
yes, to get glibc you need to compile yourself
<ByteEnable>
You are not making any sense. If openwrt default shipping build is with muscl and you don't include the .a files then why package empty ipks?
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
christiandr has joined #openwrt-devel
<jow>
because we want people to be able to compile with glibc without having to touch package Makegiles to manually add +libpthread to the respective DEPENDS:= lines of their Makefiles
<ByteEnable>
The IPK in the package repo has nothing to do with when someone builds glibc.
lmore377 has joined #openwrt-devel
<jow>
it has if you build with glibc and host your own package repos
<jow>
also opkg is used during firmware compilation, so dependency resolution has to work there as well to produce proper images
<ByteEnable>
If I go to software in luci and search for libpthread there is a package. You install the package. But the package is actually empty.
<jow>
yes, for officla builds it is empty
<ByteEnable>
So why package empty ipk's ?
<urjaman>
you're just running around in these silly circles and i've kinda had it lol
<ByteEnable>
Me too.
<urjaman>
you were answered
<ByteEnable>
Doesn't make sense for the end user.
<ByteEnable>
You expect to get the .a files.
<jow>
it's not an end user question
<jow>
no
<jow>
I would expect *.a files from *-dev packages (a concept which does not exist on openwrt)
<urjaman>
it exists to satisfy dependencies, those dependencies exist to support other valid configurations, end of story
<ByteEnable>
Only at build time on the host right?
<jow>
no at run time on the target
Nick_Lowe has joined #openwrt-devel
<urjaman>
if you build a repo of glibc or uclibc-based ipks they will be needed runtime too (and contain .so files as i get it? like one would expect)
<jow>
there would be multiple ways to chage that nowadays, we could move librt.so and libpthread.so into libc.ipk for glibc and ditch extra packages
<jow>
or we could introduce conditional depends
<jow>
but it is additional work for no gain
<jow>
if your actual question is "how do I compile stuff on an musl target where some build system insists on linking with "-lpthread" or "-lrt" eventhough the corresponding apis are part of the default libc.so already, then use this: https://forum.openwrt.org/t/usr-bin-ld-cannot-find-lpthread/18404/3
<jow>
but again, on-target compilation is not really supported. Not in the sense you would expect it from a Debian or CentOS or any other ordinary Linux distro
<jow>
yes, there is a gcc package, but it is neither polished, nor tested, nor are all auxiliary utilities packaged that are typically needed to compile complex software pacakges
<jow>
or header-files or development packages
<jow>
and the empty librt and libpthread packages are placeholders for libc implementations where these libs are separate shared objects
<jow>
motivation is that compiled packages always have the same dependency specs if they use rt or thread symbols, regardless of whether the crt happens to contain these symbols in the core or in extra shared objects
christiandr has quit [Quit: "Mit dem ersten Glied ist die Kette geschmiedet. Wenn die erste Rede zensiert, der erste Gedanke verboten, die erste Freiheit verweigert wird, sind wir alle unwiderruflich gefesselt"]
christiandr has joined #openwrt-devel
christiandr has quit [Quit: "Mit dem ersten Glied ist die Kette geschmiedet. Wenn die erste Rede zensiert, der erste Gedanke verboten, die erste Freiheit verweigert wird, sind wir alle unwiderruflich gefesselt"]
<aparcar[m]>
blocktrron: okay I'll give it more time next time
Nick_Lowe has quit [Client Quit]
merbanan has joined #openwrt-devel
black_ant has quit [Ping timeout: 268 seconds]
<ldir->
trying to counteract the preceding hour's 'fun'
<aparcar[m]>
ldir-: elaborate
<aparcar[m]>
jow: plans to publish ucode?
zatwai has quit [Quit: ZNC 1.8.2+deb1~bpo10+1 - https://znc.in]
zatwai has joined #openwrt-devel
valku has quit [Quit: valku]
adrianschmutzler has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
Borromini has joined #openwrt-devel
christiandr has quit [Quit: "Mit dem ersten Glied ist die Kette geschmiedet. Wenn die erste Rede zensiert, der erste Gedanke verboten, die erste Freiheit verweigert wird, sind wir alle unwiderruflich gefesselt"]
dedeckeh has quit [Remote host closed the connection]
christiandr has joined #openwrt-devel
<jow>
aparcar[m]: once it meets my quality expectations
<jow>
still finding bugs
<aparcar[m]>
is it worth to add a RC to openwrt.git so people start tinkering with it?
<Borromini>
from the moment i switched my modem to passthrough and had OpenWrt handle the PPPoE connection DNS somehow works but lan to wan traffic does not (e.g. can resolve websites but not ping or visit them)
<Borromini>
wondering if there's extra stuff i can try to find out what goes wrong where. a firewall reload fixes things.
Huntereb has quit [Ping timeout: 264 seconds]
goliath has quit [Quit: SIGSEGV]
muhaha has joined #openwrt-devel
dxld has quit [Quit: Bye]
Nick_Lowe has joined #openwrt-devel
dxld has joined #openwrt-devel
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<jow>
aparcar[m]: I think I'll merge it next week alomng with firewall4, so people can play with it
<jow>
Borromini: that forum post sounds weird
<jow>
Borromini: why should the firewall use `wan` (I assume a DSA port) instead of `pppoe-wan` if the connection is PPPoE
<jow>
Borromini: anyhow, please start with providing the contents of /var/run/fw3.state in broken and working state
<jow>
Borromini: along with the output of "ifstatus wan"
<Borromini>
jow: ok. i'll reproduce and get back to you. is that ok?
<Borromini>
it's mt7621, so dsa yes.
<jow>
sure. I assume the regression got introduced with DSA
<jow>
I vaguely remember that we have some "interpret value as logical network, then netdev" logic somewhere
<Borromini>
ok :)
<jow>
since with DSA "wan" is both a logical network and a Linux network device, things might get confused on early boot when PPPoE is not yet up
<jow>
could you also try renaming your wan in /etc/config/network to something like "wan2" or "internet" (don't forgot to adjust option/list network wan in /e/c/firewall too)
<jow>
and see if the issue still occurs then
<Borromini>
will do.
<jow>
actually I think its clear
<jow>
on boot, when pppoe is not yet up, ifstatus wan will likely report no l3_device and (DSA) "wan" as (l2_)device
<jow>
so fw3 will use that
<jow>
however, when PPPoE eventually comes up, it should trigger /etc/hotplug.d/iface/20-firewall which should then restart fw3
<jow>
I suggest to add some debugging to /etc/hotplug.d/iface/20-firewall as well
<jow>
maybe we have a race there
<Borromini>
ok. debugging as in removing the -q and /dev/null redirect?
<jow>
yeah, and adding something like `env | logger -t hotplug-vars` to dump the event env vars to logread
<jow>
to see what DEVICE, ACTION etc. are set to, ideally before the if condition filtering things out