<Grommish>
Does anyone know if Host/Uninstall actually works? I can't call it on the make, but then again I can't call Host/Install either, so,..
<Grommish>
I just end up getting: *** No rule to make target 'package/feeds/packages/rust/host/uninstall'.
<Grommish>
Oh, it seems it's called during (yet before) Host/Clean
<guidosarducci>
ldir: that NLS problem with iproute2 is like pulling loose yarn on a sweater. Upstream change exposed strange problem where LDFLAGS aren't being passed to $CC, causing test compile to fail. Why do I keep pulling?!
<mangix>
zorun: any way to request installed packages on cfarm?
indy has joined #openwrt-devel
<Grommish>
Do any targets use ARMel Arch? I've not been able to find any, but..
<mangix>
Grommish: all of them?
<Grommish>
mangix: Educate me?
<mangix>
all supported ARM targets are little endian
<Grommish>
Ah ha
<mangix>
there was a big endian one, but that got removed
<Grommish>
mangix: Thanks :)
<Grommish>
mangix: I'm trying to figure out which archs need libatomic and which don't and how to dep it
<mangix>
Grommish: good luck figuring that out
<mangix>
I recommend adding it as an unconditional dependency
<mangix>
to avoid that headache
<Grommish>
Well.. It's mipsel and arm
<Grommish>
Yeah, That's how I have it now. I suppose it won't hurt the mips64 platform, but I have to test that still
<mangix>
speaking of mips64, I'm connected to one running debian 10
<mangix>
it's so slow
<mangix>
oh man I should be running time on this for the lulz
<Grommish>
mangix: I think this should be ok for the time being: ifeq ($(ARCH),$(filter $(ARCH),mipsel arm))
bernrad has joined #openwrt-devel
bernrad has quit [Quit: Connection closed]
<slh64>
Grommish: just very roughly speaking, what would you think the chances could be for a cn5010 octeon plus with 700 MHz, 512 MB RAM and BCM53118?
<Grommish>
slh64: Well, the Broadcom chipset will make it difficult regardless.. The CN5xxx is supported by the kernel, so I don't see why it couldn't work
<slh64>
could that be worth looking at, or should I run away screaming ;)
<slh64>
Netgear srx5308 is the device I might get my hands on
<Grommish>
slh64: Honestly, couldn't tell ya. I've only got exp with the Octeon3 and while it was easy, eh.. I'd ask damex, he has a vast knowledge of the Octeon line
<slh64>
thanks, at least not a no-go yet
<slh64>
I might have to escort it to the trash, so might take on a vacation before - no good memories about the (4 years abandoned) OEM firmware though
<damex>
i don't care much for octeon target since 'people' started rushing changes there so feel free to add necessary support for main board and then consult with forums/github issue/anything else about bringing up that switch (broadcom is not know to work). you need to check what place does it take and how connectivity is working. cn5010 can have 3 mac interfaces
<damex>
you might have some ports directly connected to soc (with external phy) and other would use that switch
Borromini has joined #openwrt-devel
<slh64>
thanks, I'm nit quite sure if I'll take the challenge - or if the device finds other uses beford I get to it
<slh64>
thanks, that might be 'fun' to integrate into a non DSA target
<Grommish>
I need to find a rtl8367rb dsa file, but haven't had luck yet
ivanich has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Oddstr13 has quit [Ping timeout: 245 seconds]
Oddstr13 has joined #openwrt-devel
dwmw2_gone has quit [Ping timeout: 250 seconds]
<zorun>
mangix: see the website
<Grommish>
aparcar[m]: I'm looking at revising a Makefile for LibHTP. Someone had one for an older version, It passes -fno-stack-protector, but then the way the Make was invoked was odd. I compiled/ran without an issue without passing -fno-stack-protector. Opinion on keeping it in?
<zorun>
mangix: that mips host has known I/O issues, that's why it's so slow
dwmw2_gone has joined #openwrt-devel
<plntyk>
Grommish, the older version with "-fno-stack-protector" was probably because compiler/toolchain issues or upstream source issues - now its supposed to work since many distros use it
<plntyk>
issues with older compilers
<Grommish>
plntyk: So I can remove it? I couldn't find a reason to keep it, which is why I was asking :)
<plntyk>
i would remove it - libhtp source history does not indicate that there is major incompatibility with that compile flag
<ynezz>
Thermi: we've gitlab.com/openwrt for evaluation where some projects already has CI implemented so the CI checks are run after push and on daily basis like for example https://gitlab.com/openwrt/project/libubox/-/pipelines
<ynezz>
Thermi: some projects like for example libubox, ubus have even unit tests, libFuzzer based fuzzing, sanitizers, valgrind and more.
_lore_ has quit [Read error: Connection reset by peer]
_lore_ has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
<Hauke>
xdarklight: I think you have to configure the link status, speed, duplex mode, tx flow controll and rx flow controll manually when you do not use the phy polling
<Hauke>
this is in the same register
<Hauke>
The documentation for the GSW140 is very similar to the VRX200 documentation in this area
<xdarklight>
Hauke: ah, so instead of using any of the _AUTO values we need the "fixed" values instead
<Hauke>
yes
<Hauke>
xdarklight: the gswip_phylink_mac_link_up() function is called with all these avlues
<xdarklight>
Hauke: yes, at least in Linux 5.7 and newer. for older kernels only gswip_phylink_mac_config has the values
<Hauke>
ok, I didn't check older kernels
* ldir
ughs
Tost has quit [Ping timeout: 240 seconds]
Borromini has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 265 seconds]
_lore_ has quit [Ping timeout: 268 seconds]
_lore_ has joined #openwrt-devel
dedeckeh has quit [Ping timeout: 240 seconds]
<mangix>
ynezz: ping
Nick_Lowe has joined #openwrt-devel
black_ant has quit [Ping timeout: 246 seconds]
<mangix>
my ninja treewide commit broke nothing. cool.
caiortp has joined #openwrt-devel
caiortp has quit [Read error: Connection reset by peer]
<Pepe>
mangix: are you thinking about to backporting it to 21.02?
<karlp>
why would they? it's hardly a bugfix or security issue....
<karlp>
I mean, "let's change how things are built, on the stable branch..." ?
user890104 has quit [Ping timeout: 240 seconds]
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<Pepe>
Well, OpenWrt 21.02 was not released into RC yet. It should provide faster compilation of packages feed, it makes things easier to backport. And who knows when another version of OpenWrt will be released, so waiting for it 1-2 year does not have much sense in my point of view.
<karlp>
the fact that people keep treating stablisation release branches as "just throw more in" is _why_ releases are always late...
<karlp>
IMO
<Pepe>
In case of 21.02, there is a difference, because it was waiting for LuCI support for DSA, etc. But all the stuff is documented on OpenWrt doc and sb said in #openwrt-adm that RC should be gone in week or two, but yeah, I understand your reasoning, however, faster compile time is something what we can all benefit from, though.
<jow>
cpu time is cheap
<jow>
developer time is not
<jow>
you'll need hundreds of hours in saved compilation time to make up just a couple of lost hours in developer time due to introduced regressions
<rsalvaterra>
Yeah, let's not delay OpenWrt 20.x (yes, it's 21.x because it slipped) even more.
* Borromini
is pining for 21.02
<Borromini>
about to test drive the LuCI DSA support
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
also meson/ninja... pft
<jow>
you need friggin python3 for the former and a C++ compiler for the latter
Borromini has quit [Quit: Lost terminal]
<jow>
and 15 years down the road python 3 will be EOL, python 4 will be around, introducing incompatible syntax changes and suddnely your "makefiles" (meson build recipes) stop working
<jow>
the same shit happened with scons already, yet another "let's do a build system just because" thing
rmilecki has quit [Quit: Konversation terminated!]
<mangix>
Pepe: no plans to do so. One thing about that PR is that I split it up to make it easier to verify with CI
<jow>
to be fair, cmake requires C++ as well, but I am not fan of that either
rmilecki has quit [Ping timeout: 268 seconds]
<rsalvaterra>
mangix: C++ 98… Got Stroustrup's third edition sitting in the shelf behind me. Never really loved it. :P
<mangix>
Pepe: lots of problems were discovered that way. It seems that the treewide PR broke nothing
<Pepe>
mangix: okay, understood.
<mangix>
rsalvaterra: C++98 is cavetime. It maps to C89. C++11 maps to C99
<karlp>
and all the cool kids are on c++20 already
<mangix>
karlp: no way. C++20 is not complete implementation wise
<rsalvaterra>
Heh… It's what we studied at the university, at the time. :P
<mangix>
not even GCC10
<jow>
the cool kids are working on a Go build system generating Rust code which transpiles to WASM running on node.js to invoke gcc on three C file and one include
<mangix>
lol
<jow>
because its faster!
<jow>
for the 2% of projects having 100.000+ C++ source files to compile
<mangix>
what is this go build system?
<jow>
a joke
<jow>
(I hope)
<mangix>
i do too
<karlp>
mangix: you thinkthat stops anyone?
<mangix>
karlp: I mean...maybe they use parts. Not the significant stuff
<jow>
I tihnk for a build system it makes sense to be very conservative about prereqs
<mangix>
I'm pretty sure constexpr std::string is implemented nowhere
<jow>
not every environment has modern C++ compilers available
<jow>
anyhow, time to hit the sack. bbl/gn8
<mangix>
jow: the irony in what you said is that master currently assumes a modern environment
<karlp>
mangix: hrm, pretty sure enough of it is... I've seen people doing lots with the co-routine stuff
<mangix>
coroutines are nice
<mangix>
Anyway, ninja is extremely conservatice
<mangix>
*conservative
<mangix>
The fact that it's not as broken as make is a net positive.
<jow>
mangix: it wasn't me introducing all this newfangled whizbang
<mangix>
sure. but as it stands, master cannot be built with Debian 9
<mangix>
which is still a supported distro
<jow>
when I stopped looking it was able to, since then it detoriated
<mangix>
sorry, LTS
Nick_Lowe has joined #openwrt-devel
<jow>
so whoever merged stuff that cannot build on Debian 9, should probably fix it
<jow>
bbl for real now
<rsalvaterra>
mangix: Is ninja a drop-in replacement of make?
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user890104 has joined #openwrt-devel
<mangix>
rsalvaterra: no
<rsalvaterra>
Thought so… I had to deal with meson/ninja last year, when I sent a patch to Mesa… Haven't really enjoyed the experience. :P
Nick_Lowe has joined #openwrt-devel
<mangix>
rsalvaterra: it's drop in if using cmake. but otherwise no.