T_X has quit [Read error: Connection reset by peer]
abiliomarques has quit [Remote host closed the connection]
glbp has joined #openwrt-devel
goliath has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador has joined #openwrt-devel
<ldir>
is jow lurking here?
<ldir>
think I've fallen over a bug in fw3 ipsets creation
<Habbie>
sometimes
<Habbie>
maybe just share your problem :)
<ldir>
I don't seem to be able to specify a 'hashsize' with certain match types (all storage class of 'hash')
<ldir>
So a set with "option match 'src_ip'" gets created with my specified hashsize, but a set with "option match 'src_ip src_port dest_ip'" doesn't - it gets the default hashsize of 1024
<ldir>
I can manually create sets of that type with a non-default hashsize eg. ipset create wibble hash:ip,port,ip hashsize 64
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
<ldir>
my guess is that it's somewhere in fw3/ipsets.c and the evaluation in check_types but urm, arrrghhh! :-)
<ldir>
I confess using these sorts of options is unusual.
fda has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
rejoicetreat has quit [Ping timeout: 480 seconds]
clef has joined #openwrt-devel
clef_ has joined #openwrt-devel
clef has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
clef has joined #openwrt-devel
clef_ has quit [Ping timeout: 480 seconds]
clef_ has joined #openwrt-devel
rua has quit [Quit: Leaving.]
clef has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
clef has joined #openwrt-devel
clef_ has quit [Ping timeout: 480 seconds]
clef has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 is now known as jlsalvador
hemispur has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
hemispur has left #openwrt-devel [#openwrt-devel]
Rentong has quit [Ping timeout: 480 seconds]
arifre has quit [Remote host closed the connection]
Luke-Jr has joined #openwrt-devel
arifre has joined #openwrt-devel
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
dangole has joined #openwrt-devel
nickname2378789 has joined #openwrt-devel
<nickname2378789>
Hi all! I develop some custom proto in openwrt and i want report "fatal error" to netifd when my protocol have some fatal unrecoverable error
<nickname2378789>
I tried proto_notify_error, but after this interface restarts infinity
<nickname2378789>
I tried proto_set_available, but after this interface losses any my errors, interface have only one error "NO_DEVICE"
<nickname2378789>
How properly set "fatal error" to netifd interface?
<nickname2378789>
And yes, "force link" disabled on interface
<stintel>
hexagonwin[m]: did you find the dsa guide in the forum by now?
* stintel
was on holiday and hasn't touched a computer for almost a week
<Thermi>
stintel, oh good. I guess I need to do that, too.
<stintel>
got a nice tan, too :P
<stintel>
and met a jellyfish, fortunately wasn't a painful kind
<stintel>
58
rsalvaterra has joined #openwrt-devel
glbp has quit [Quit: leaving]
shibboleth has joined #openwrt-devel
rsalvaterra has quit [Quit: Leaving]
<nickname2378789>
i found proto_block_restart
<nickname2378789>
works fine for my purposes
rsalvaterra has joined #openwrt-devel
robin_ has joined #openwrt-devel
<stintel>
did anything change in the 6in4 proto in netifd recently? I hit again "netifd: Interface 'wan6' is setting up now" "netifd: wan6 (23706): Command failed: Unknown error" "netifd: Interface 'wan6' is now down" - ifstatus wan6 not helpful at all: https://gist.github.com/stintel/dbd3ba8a13a31de9ad8a59be7bd2293f
<stintel>
the command failed unknown error seems to come from "ubus call network.interface notify_proto ..."
<stintel>
now having several perl packages failing to build, due to ==> Your Makefile has been rebuilt. <== ==> Please rerun the make command. <== false
<stintel>
anyone know how to deal with that ?
<stintel>
WARNING: Your GNU C 10.3.0 compiler is very old. Please upgrade it and rebuild perl.
<mangix>
stintel: the perl packages are a weird arcanery that I don'tdare deal with
<stintel>
dafuq
<mangix>
oh that bug
<mangix>
you see, 10 < 9
<stintel>
:D
<mangix>
because it starts with 1
<mangix>
it matches only the first digit
<stintel>
dafuq
<stintel>
let's see if bumping to 5.34 helps
<stintel>
*shH
<stintel>
¯\_(ツ)_/¯
<stintel>
that's going to be another bald yak this evening
<mangix>
according to wikipedia, SPARC seems abandoned. cool.
<stintel>
still looking forward to find some cheap M12 on ebay some day :P
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<stintel>
yeah perl in -packages is a mess
<mangix>
hmmm. Also causes issues with the CI
<mangix>
*mhmm
<slh>
I referred to sigbus being a rather common occurance on sparc/ sparc64, technically always code errors, just ones you don't ever see on x86/ x86_64 - never had any ppc/ pcc64 devices
<mangix>
ah OK. From the looks of things, it seems I tried compiling on both sparc64 and ppc64
<mangix>
don't remember the results
<slh>
and yeah, I've kept looking at ebay for cheap sparc systems for years in the past, but they never really came - and by now the prices are insane, relative to their performance (and household compatibility in terms of power usage and cooling requirements/ noise)
<mangix>
based on cfarm performance, I don't recommend them
<slh>
development effectively stopped in 2010
<slh>
thanks to Oracle
<mangix>
PPC?
<slh>
SPARC
<mangix>
Isn't that a Fujitsu thing?
<stintel>
no
<stintel>
Sun
<slh>
Oracle bought SUN Microsystems in January 2010
<slh>
until the late 90s/ very early 00s, these were really highend systems
<slh>
I personally had a SPARCstation 20/ SuperSPARC 50 (50 MHz sun4m, 160 MB RAM, 1 GB SCSI HDD), pizza box form factor and 20" SUN branded Sony monitor, great system - but I never really got a successor (at work I've played with UltraSPARC2/ sun4u, up to Blade 2000)
<slh>
then Oracle came, and it died quickly (support costs no longer viable, let alone new purchases)
<slh>
(and yes, general purpose performance also lagged behind past the mid 00s)
<stintel>
I actually wonder how many CVEs are in the perl version in -packages
<stintel>
I've got an Ultra 5 in my parents' attic
<stintel>
and a Sunfire v210 here
<mangix>
Oh I see why I have them confused. On cfarm, both a sparc64 and ppc64 system are listed as 8 core 64 thread
<stintel>
ah yes, 8 way smt
<mangix>
doesn't seem to improve speeds though. lol.
<stintel>
depends on the workload iirc
<mangix>
reminds me of IBM's CELL
<stintel>
:P
<stintel>
I ran Gentoo on my CELL!
<slh>
SUN in their later days concentrated solely on integer performance, database and webserver workloads
<mangix>
stintel: was it a PS3?
<stintel>
yeah :)
<stintel>
thanks Sony for nuking OtherOS!
<slh>
many cores, for the time
<mangix>
what's the opinion of M1 here?
<stintel>
Apple, kill it with fire
<Habbie>
there's a bunch of really clever stuff in the M1
<stintel>
sure, it
<stintel>
sure, but it's horrible vendor lockin
<Habbie>
ARM64+some instructions that really help JS+support for the amd64 boundary model for cheaper emulation
<Habbie>
but yes
<Habbie>
i'd love to buy a non-Apple device with M1 :)
<slh>
not enough, not for that price - and yes, desktop/ workstation performance *cheap* ARMv8 is (and has been-) missing for years, performance-wise the M1 is the first option to fill that gap. but at least I'm not paying the Apple tax just for that, and even less accept the vendor lock-in
<mangix>
It's insane that in ARM terms, Apple's 2 generations ahead of Qualcomm
<slh>
different target market, a smartphone just has other needs than a workstation
<slh>
yes, Apple has put all their weight in, and they are ahead
<slh>
but it's not as if the competition had been trying, at all
<mangix>
Right. Apple has really good engineers
<slh>
those mystical ARMv8 servers promised for at least a decade still don't exist
<slh>
(unless you're Facebook and friends, with the means and very targetted requirements)
<Habbie>
slh, amazon sells them now, and online/scaleway
<mangix>
Didn't someone here try compiling OpenWrt on the M1?
<Habbie>
packet.net (sorry, equinix metal) kind of stopped selling them
<slh>
Habbie: you mean some cloud (v-)servers? or physical iron you can actually get delivered on a private budget?
<slh>
because that's (always been) the problem
<Habbie>
slh, packet.net is physical rentable iron; the other two are v, i believe
<Habbie>
none of them deliver to your home
<slh>
yeah, rented server space just isn't the same as a box on my desk
<mangix>
oh cool. cfarm's m1 is reachable
<slh>
one is a service, the other a physical product
<Habbie>
slh, yep
<Habbie>
of course pi4 is armv8
<mangix>
/Users/mangix/devstuff/openwrt/include/toplevel.mk:29: *** Please use a newer version of GNU make. The version shipped by Apple is not supported. Stop.
<mangix>
booooooo
<ynezz>
brew something
<mangix>
yeah. no brew on this machine unfortunately
<slh>
Habbie: what I've been waiting for, is something like a ~100 EUR mainboard and a ~150-250 EUR ARMv8 CPU, that can compete against similarly priced x86_64 gear (doesn't need to be exactly on par, but at least providing an acceptable comparision, something that can compile a fully modular vendor kernel in less than an hour), with RAM and storage as I need it (and at least a /basic/, fully supported
<slh>
Habbie: the RPi stuff is a step in the right direction, but it's still too little ARMv8, too much fruit-cake for me (aside from block storage not being ideal)
<ynezz>
IIRC we've compared build time on 16 Cortex-A72, NVME storage (honeycomb) with Hetzner cpx41 VPS (AMD EPYC 2nd Gen 8 vCPUs) and the difference was like 12 minutes in favor for the AMD
<mangix>
*this thing
<Habbie>
ynezz, 12 minutes on what total?
<ynezz>
compiling ath79 generic config
<ynezz>
what buildbots build
<mangix>
ynezz: out of curiousity, do any of the build bots run ccache?
<stintel>
all of them should, no ?
<mangix>
I don't think any of them do
<ynezz>
I assume, that 2nd stage, packages, yes
<stintel>
because build_dir and staging_dir aren't kept, not using ccache would result in much slower build times
<slh>
mangix: my solution is two fold, small Pentium j1900 with just enough storage (2.5" HDD/ 500 GB) to take care of the always-on stuff stuff (~6 watts idle), 1 SSD and 7 spinning HDDs in my desktop/ workstation, available at my fingertips when I need it most (but also acting as fileserver, when it's powered on). not ideal, but at least close enough
<ynezz>
images are built from scratch
<stintel>
anyway that's what I remember from before the stuff was dockerized
<mangix>
OTOH, I've seen ccache failures that the build bots have not caught
<mangix>
slh: Yeah. I run Nextcloud, Gerbera, and BitTorrent on mine. Too heavy.
<mangix>
2GB is also not enough RAM. I need to use swap.
<philipp64>
it might have been merged... we're quite behind.
<stintel>
but nukes all patches that don't apply
<philipp64>
If anyone else wants to be a co-maintainer, let me know...
<stintel>
I don't use perl, so even trying this was already goodwill ;)
Tapper has joined #openwrt-devel
<philipp64>
"don't apply because they're no longer relevant" or "don't apply because they need to be updated"?
<stintel>
both
<mangix>
Could just throw it as a PR and see what the CI thinks
<philipp64>
The point of replacing -@rm 's was if we don't care if they fail (-) then why not just remove them with -f so they don't generate noise on stderr?
<stintel>
philipp64: so it's a valid improvement, but if they don't fail the build and upstream doesn't care, why keep the maintenance burden
<stintel>
see things like this is why packages stay outdated and become frustrated to maintain
<stintel>
frustrating*
<philipp64>
no, it's frustrating to maintain because they're a new cross-build setting I need to figure out for N >> 8 platforms everytime a new major release ships...
<philipp64>
Alas, a lot of things need it... Like ipt_geoip.
<stintel>
:(
<stintel>
yeah I can think of net-snmp too
<mangix>
another issue with the packages feed is that I drive people away from what I'm told.
<Habbie>
net-snmp, the bane of any packager
<mangix>
Habbie: I tried updating it once. Gave up. autotools can go kick rocks.
<Habbie>
i don't hate autotools
<mangix>
I do
<philipp64>
but... hopefully the CI/CD coverage is good... so if the PR does pass, I'll merge it.
<Habbie>
i do hate the net-snmp .pc files
<mangix>
Habbie: the main problem with autotools is that you have to put in extra work to make it parallel friendly.
<Habbie>
sure
<mangix>
All CMake and Meson projects build in parallel by default. There are no exceptions.
<mangix>
That is, no package disables PKG_BUILD_PARALLEL
<philipp64>
you'd think of anything could build proper parallel-friendly Makefiles, it would be automake.
<philipp64>
_sigh_
<Habbie>
i haven't had parallel problems with automake except when there are makefiles in subdirs
<mangix>
philipp64: It's a harder problem than you would think. CMake for example had to be fixed to compile all packages in parallel.
<stintel>
philipp64: you mean the perl 5.34 bump ?
<karlp>
autowinning....
<karlp>
stintel: has anyone come up with any sane alternaive to net-snmp yet?
<mangix>
The jury is still out on whether meson is better than CMake. The former is much easier to write though.
<karlp>
that lua one looked promising, but dead-ended.
<Habbie>
i'd like to subscribe to this thread
<mangix>
Habbie: wait don't you maintain the pdns stuff?
<Habbie>
i do
<Habbie>
which is why i hate net-snmp
<mangix>
I remember parallel build problems on my CentOS 7 VM that has since been nuked
<mangix>
I think it was a RAM issue
<Habbie>
for pdns? we recommend 2GB per -jX, ignore your core count
<mangix>
Habbie: I ran make -j 12 with 6GB assigned :)
<stintel>
karlp: maybe we can start one in rust
* stintel
hides
<Habbie>
mangix, yes that is going to hurt :)
<stintel>
:P
<stintel>
I don't regret 256GB RAM in my workstation. I do regret the low clock speed :(
<Habbie>
that reminds me of the first ARM64 server i tried
<Habbie>
it had like 400GB of RAM
<Habbie>
and 96 cores
<Habbie>
which is great for compiling -after- ./configure
<stintel>
yeah
<Habbie>
which took forever on a single core
* stintel
found and fixed another host lib leakage in packages feed
<stintel>
I should do this no computer for a week thing more often :P
<Habbie>
haha
<Habbie>
i also had a host lib issue a few months ago i think
<Habbie>
for boost
<Habbie>
but it was a pdns bug
<stintel>
hmmm should have cleaned up my kernel config. building both nouveau and amdgpu ... waste of time on this not so fast risc-v system
<karlp>
stintel: rust still makes like 3MB binaries right? :)
<stintel>
karlp: ah right
<stintel>
I forgot about limited storage
<stintel>
although even net-snmp is a pita on >=8MB
<mangix>
Habbie: do tell
<Habbie>
mangix, our autotools stuff fell back to checking a bunch of static dirs (think /usr/lib and friends) if boost was not found not not thought to be good enough
<mangix>
joy
<Habbie>
*or not
<mangix>
does boost use pkgconfig?
<mangix>
stintel: bus errors are on SPARC, not PPC. Just built.
<karlp>
bus error is just space for segfault normally isn' tit?
<karlp>
sparc for segfault..
<mangix>
beats me. The whole platform is alien to me.
<mangix>
funny that pkgconfig packages use the same syntax
<mangix>
I guess boost is hardcoded
Weasel___ has quit [Ping timeout: 480 seconds]
<Grommish>
mangix: ping
<stintel>
pfft, more host leakage, this time cmake
<philipp64>
stintel: yes, the 5.34 bump
<philipp64>
sorry, dealing with faulty wiring in the walls...
<philipp64>
speaking of Makefile issues, Noel is trying to factor some of the BuildPkg stuff so he can use it two different ways... who can help out with a review of that?