danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
clayface has quit [Ping timeout: 480 seconds]
clayface has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
minimal has quit []
<mangix>
stintel: so that glib2 warning only happens with -Wformat=2
<mangix>
-Wformat=2 exposes a bug in fortify-source
<mangix>
this applies to all packages
<mangix>
aparcar: ping
Tapper has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
srslypascal is now known as Guest1098
srslypascal has joined #openwrt-devel
Guest1098 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
Borromini has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
pmelange has joined #openwrt-devel
pmelange has quit []
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
floof58_ has joined #openwrt-devel
floof58 has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
\x has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Tapper has joined #openwrt-devel
<stintel>
wth :P chrony was no longer able to use the GPS HAT on my RPi4 as source, turns out it was because of a lamp between the antenna and the window :/
<hurricos>
The only time I'm awake early enough (for work, wah) to hear the european openwrters chatting, but this time there's no conversation going on
rua has joined #openwrt-devel
<hurricos>
I just want to hear about the minutia of RTL838x swithc registers. is that too much to ask
* hurricos
sighs overdramatically
<hurricos>
slh: I bought a ZyXEL GS1900 24, so I can play around with builds without risking bricking the 24HP. I should thank you, the port is looking brilliant.
<hurricos>
Still dreaming of the days where we'll have DSA support on bigger switch fabrics :^)
<Borromini>
bigger than 48?
<PaulFertser>
hurricos: people mostly do not discuss rtl838x here :(
<rsalvaterra>
stintel: Wholeheartedly agree with your UPnP stance. Haven't replied to the email because I'm on my phone and can't send plaintext emails from it. :/
<rsalvaterra>
UPnP makes life easier for Joe User while exposing them to huge security risks. The knowledge required to be able to configure and use UPnP *safely*, also makes it absolutely useless.
<stintel>
was kind of a dick move, to copy the IRC conversation and then add such ridiculous conclusion
<stintel>
and since I was quoted a few times I just had to refute that conclusion
<rsalvaterra>
Yeah, not cool.
<stintel>
now, back to some real work :P
<stintel>
infra maintenance
<stintel>
and today that might even include "replace batteries of BLE devices"
<rsalvaterra>
Rock on! ;)
<stintel>
the lamp bit was also kind of interesting lol
<stintel>
took me a while to find that old commit to add ipcs to util-linux, to check shm which is used between chrony and gpsd, only to find out it was a problem in the physical layer :D
<Borromini>
i don't get how that guy keeps hammering on an UPnP daemon being an absolute necessity despite all the glaring issues
<Borromini>
and being told NO repeatedly
<stintel>
blinded by his single use case
<stintel>
s/his/their/
<stintel>
before I get the woke police after me
<Borromini>
:P
<stintel>
Habbie: are you running OpenWrt on the ERL?
<Habbie>
yes
<stintel>
version?
<Habbie>
one 19.07, one master
<stintel>
cool, on the master one, is it running 5.4 or 5.10 ? :)
<Borromini>
=)
<Habbie>
i can find out later, it's buried under other routers and not connected
<stintel>
gotcha
<Borromini>
seems people are less interested in getting second hand ERLites than ER-4s
<Habbie>
i guess you want to know if the 5.10 is leaking memory?
<stintel>
yeah, I booted one of my SNIC10e's again and can't reproduce now
<Habbie>
ok
<Habbie>
how do i check?
<stintel>
do you perhaps have a prometheus running ?
<Habbie>
i did install grafana on the HA box yesterday
<stintel>
cool
<stintel>
I use prometheus-node-exporter-lua on my OpenWrt devices
<Habbie>
i can certainly boot it up, install that, keep stats for a few days, then do any upgrades you suggest
<Habbie>
it's running master from a few months ago now
<Habbie>
but it could be 5.4
<stintel>
well you could start with 5.4, run it a few days, check the mem usage graph, then upgrade to an image with 5.10 and compare
<Habbie>
yep
<Habbie>
will do
<stintel>
thanks
<Habbie>
does it matter if it's passing any traffic or not?
<stintel>
the SNIC10e has +~10MB of mem usage in 24h
<stintel>
while my ERL was crashing after ~8h of uptime
<stintel>
and that was in backup mode
<stintel>
there was some traffic from bird (ospf) and conntrackd (conntrack table syncing from main router) and even an IPsec tunnel
<stintel>
but it normally wouldn't have been routing a lot of traffic
<stintel>
but the ~10MB increase I see now on the SNIC10e is not near enough to cause the thing to crash/reboot due to running out of memory
<stintel>
s/thing/ERL/
<stintel>
so maybe it's just fixed and we're hunting a ghost
<stintel>
so I would get some more data and then maybe just bump octeon to 5.10 after all
<stintel>
that'll mean more people will use it and if it turns out to still be a problem we can still go back to 5.4
<Habbie>
ack - do we have 5.10 images? i guess snapshots are 5.4?
<stintel>
but that will reduce the chances of octeon being in the next stable release
<Habbie>
(i can build, of course)
<stintel>
yeah snapshots are 5.4 still
<Habbie>
got it
<Borromini>
stintel: everyone knows master is testing ground
<Borromini>
i say push 5.10 and you'll get people complain soon enough if it's a widespread issue
<stintel>
well ... yes and no, something that is known to be broken and kills devices in < 1 day is not acceptible
<stintel>
unless it is behind a "TESTING" knob :)
<Borromini>
that's where 5.10 is hiding eh :)
<stintel>
I'll have to figure out how I can automatically boot OpenWrt on an SNIC and apply OpenWrt config during host boot
<stintel>
as the NOR flash is too small and the NAND driver is typical SDK incompatible ancient shite
<Grommish>
stintel: Did you try service dnsmasq restart?
<stintel>
Grommish: I do not have dnsmasq on this thing
<Grommish>
stintel: So we are back to two issues :(
<stintel>
yes
<Grommish>
Fuuuuuuuh
<stintel>
and I think maybe the kernel one might actually be fixed
<stintel>
hence considering switching master to 5.10
<Grommish>
Well, the issue is, while you don't use dnsmasq, defconfig does
<stintel>
yeah but defconfing doesn't auto-restart dnsmasq ;)
<stintel>
let's see if I can figure out a way to autoboot SNICs with OpenWrt + config
<stintel>
I'll do a 2nd one with dnsmasq for other testing
<stintel>
and the 1st one ... I'm planning to move my guest network gateway to it
<stintel>
(corp issued devices are on my guest network so it does get used even without having guests)
Borromini has quit [Quit: leaving]
<Grommish>
I turned of ipv6, built, ran, turned ipv6 back on (in menuconfig), did a make clean and when it built, it complained about missing ipv6.ko drivers.. Any idea how to force it to rebuild if clean doesn't work?
Lechu has joined #openwrt-devel
<stintel>
dirclean ?
<stintel>
I usually do "make target/linux/clean world"
<aparcar>
jow: sorry for the late response. Yes I'm trying with APK and actual repositories, specifically the "merged" one in ./staging_dir/packages/<target>/. Currently the build system uses the hack of using a file glob which no longer works with (an unpatched) APK version. OPKG uses <packagename>_<version>.ipk while APK requires <packagename>-<version>.apk. APK automatically generates filenames based on name/version without storing them in index
<jow>
in doubt it is not possible to stay closer to upstream, case closed
<aparcar>
hauke: I'm looking for a job do you think I should apply and help them finding the right repo?
<hauke>
It is closer than QSDK with OpenWrt 15.05 ;-)
<jow>
people using CC 15.05 based QSDK probably also try to "stay as close to upstream as possible" but unfortunately it is only possible to go as far as 15.05
<jow>
well sarcastic remarks aside; it is great that new products still base upon OpenWrt
<hauke>
aparcar: you can try, it looks like they are looking for people
<aparcar>
hauke: I'll write them an email
<hauke>
The full sentence is this: "Starlink WiFi Gen2 routers are dual-band 3x3 802.11ac wireless routers based on MT7629 SoCs. This platform is derived from MediaTek's SDK, which in turn is based on OpenWrt. We try to remain as close as possible to upstream OpenWrt."
<stintel>
basically just a load of marketing horse crap
<jow>
it's the FOSS equivalent of greenwashing, let's call it FOSS-washing :)
<hauke>
probably they wanted to get full support for MTK and that is only possible when you use their SDK, at least this is pretty common in the industrie. If you want to do something different you have to be very big or you are on your own.
<aparcar>
can we pack our stuff on sources.openwrt.org differently that it does not contain the folder name itself? Currently it contains <package>-<version>/<actual stuff> as a sub folder, which means a different version structure (as introduced with APK) results in different checksums
<stintel>
aparcar: good luck with applying for them. someone needs to teach people that OEM SDK != OpenWrt
<stintel>
I've made that pretty clear during my presentation at meta :P
rua has joined #openwrt-devel
<stintel>
feels good to be able to update most of my OpenWrt devices without having to use local branches :)
<jow>
aparcar: I'd rather repack the tarballs locally for apk (means download and verify the orignal, then extract and shuffle stuff around as needed)
<jow>
(and personally I do hate tarballs without toplevel folder, you extract them unsuspiciously and suddenly there's crap splattered all over your workdir
<aparcar>
again, it's the "hash"-less issue with APK
<aparcar>
I fixed the kernel issue by having virtual packages
<aparcar>
stintel: sorry for that
<stintel>
aparcar: no worries, was an easy fix
<stintel>
only found that now, as apparently didn't build for my rpi4 for months
<stintel>
I kind of automated build+upgrade at some point but this was using OVH's CDS which turned out to be a PITA to maintain
<stintel>
I made some initial new attempt with gitea + agola but nothing working so far
<stintel>
now when checking codeberg CI related conversations I found out about ... a drone CI fork?
<stintel>
ah, woodpecker ci, indead, community for of drone CI
<stintel>
we should probably ask Adrian to report his problems with PR review in gitea
<stintel>
maybe even donate some of our funds to have gitea/codeberg fix them
eduardo010174 has joined #openwrt-devel
<aparcar>
yea they're talking about drone.io stuff. Didin't really track things since I don't want to maintain the service. I thought that was our whole point lately
<stintel>
so that we can move to codeberg and kill this ugly discussion about github being bad
<stintel>
aparcar: you can request early access to codeberg CI btw
<jow>
I'd prefer to not switch to a service which has to be debugged first
clayface_ has joined #openwrt-devel
goliath has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
eduardo010174 has quit [Quit: Leaving]
minimal has joined #openwrt-devel
srslypascal is now known as Guest1131
srslypascal has joined #openwrt-devel
Guest1131 has quit [Read error: Connection reset by peer]
<aparcar>
I agree with jow I'd prefer to move all to GitHub and then keep evaluating codeberg/srht until we find it suitable, move again
<aparcar>
I attached the second part, not implying that's jow s opinion as well
dangole has joined #openwrt-devel
<aparcar>
dangole: morning
<hurricos>
Borromini: Bigger in terms of throughput, I meant
srslypascal has quit [Quit: Leaving]
<hurricos>
stintel: rootfs on nor flash
<hurricos>
RE: snic10e. You have some 4-5MB free, that should fit it I'd think
<stintel>
hurricos: ideally I'd just stick the overlay there but is that easy to pull off ?
<stintel>
booting an initramfs image ..
<hurricos>
off the top of my head, you have to tweak the device tree to point it out
<hurricos>
you should be able to do it though. Load kernel from nand and then use bootargs-override
<stintel>
wait load kernel from nand?
<hurricos>
uboot can read NAND fine
<stintel>
interesting
<stintel>
and I can start yak shaving again
<hurricos>
not worth it :D
<stintel>
my VoIP phone no longer registers to freeswitch after sysupgrade of the VM running it
<stintel>
sigh, restarting freeswitch fixed the problem
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Misanthropos has joined #openwrt-devel
_slate_ has joined #openwrt-devel
larsc_ has quit [Remote host closed the connection]
larsc has joined #openwrt-devel
<stintel>
GS108Tv3 doesn't come back after sysupgrade, power-cycle helped
<aparcar>
hauke: can we merge the octeontx 5.10 kernel stuff?
<hauke>
aparcar: I am fine with it, did someone test it?
<stintel>
is there any Octeon TX hardware that doesn't cost a ton ?
danitool has joined #openwrt-devel
<Slimey>
what does it run
<aparcar>
hauke: I didn't test it, we could ask for dev boards and distribute them between some maintainers?
<hauke>
aparcar: I asked in the pull request to test it again lets hope someone with such a board will do so in the next week.
<blocktrron>
hauke: yes, this was due to missing swig
<hauke>
we also have some patch for sunxi to make it work without swig
<hauke>
and this is blocking the update
<blocktrron>
Which update?
<hauke>
I would like to add swig as a OpenWrt dependency at least for some targets
<blocktrron>
okay
<hauke>
u-boot for sunxi is at 2020.04, for more recent versions removing of swig was more complicated
<stintel>
/68
<hauke>
mediatek u-boot already depends on swig
<blocktrron>
Would be great - at the moment it is possible to manually generate these files per board, but this does not scale
<hauke>
the build bots already have swig
pmelange has joined #openwrt-devel
<blocktrron>
hauke: what do you mean with "at least for some targets"?
<blocktrron>
We have the dependency list on the wiki afair, and eg. qemu-tools is also listed in there, even if it is only for x86
<hauke>
blocktrron: we should probaly add swig to include/prereq-build.mk
<hauke>
but it would be a depdnecy for everything
<blocktrron>
hauke: i do not see a big problem with that
<ynezz>
other option might be to check for swig in include/u-boot.mk
<ynezz>
soft dependency only for those building u-boot
<hauke>
ynezz: you mean adding a SetupHostCommand like done in target/linux/x86/Makefile to include/u-boot.mk and check for the u-boot images which need it?
<ynezz>
yes, something like that
<svanheule>
hurricos: we're also in the #rtl83xx channel on libera.chat, if you want to rant about Realtek register layouts
<stintel>
svanheule: how's the drama in that channel nowadays ?
<svanheule>
stintel: can't have much drama if there's nothing being said :(
<JuniorJPDJ>
[*]
<stintel>
svanheule: that's what happens when someone is repeatedly throwing toxic waste at others
<svanheule>
stintel: after deserting rtl83xx on his own website, he also left the IRC channel, so maybe we're safe now
valku has joined #openwrt-devel
<stintel>
some people could really use therapy lol
<stintel>
that seems quite recent, nuking rtl83xx from the website
<svanheule>
yes, only happened this week. I did ask him to set up a permanent redirect to my domain though...