cbeznea has quit [Read error: Connection reset by peer]
bluew has quit [Ping timeout: 480 seconds]
djfe_ has joined #openwrt-devel
<Ansuel>
hauke ping?
<hauke>
Ansuel: pong
<hgl>
await Ansuel.finish()
djfe has quit [Ping timeout: 480 seconds]
<Ansuel>
hauke pm
goliath has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
G10h4ck_ has joined #openwrt-devel
<Ansuel>
hgl really need the compat thing tested and then i will merge the pr
<hgl>
Ansuel: I know. I want to discuss something else. E.g., dropping nginx-ssl and the issues mentioned in the PR
<Ansuel>
the conflict is a limitation of the ci
<Ansuel>
and intended
<Ansuel>
the conclict is there just for that
<Ansuel>
nginx-luci might be very confusing... the mod prefix is O.K. IMHO
madwoota has quit [Read error: Connection reset by peer]
madwoota has joined #openwrt-devel
<hgl>
ok, after thinking about it, yeah, reasonable
<hgl>
and should we drop nginx or nginx-ssl?
<Ansuel>
i'm more inclined to nginx and keep nginx-ssl
<Ansuel>
there was a big discussion at times on what to use
<Ansuel>
and we agreed in keeping nginx-ssl
<hgl>
Ansuel: could the conflict be resolvable if we introduce a package like nginx-core that nginx-mod-* depends on. making nginx and nginx-full meta packages?
<Ansuel>
eh nope since nginx-ssl have many feature of nginx-full disabled
<hgl>
Ansuel: is the discussion public? I'm current quite confused that ssl should be unconditional, yet there exists both nginx and nginx-ssl
<Ansuel>
eh it's quite old it was done when nginx-util was introduced
maciekb has quit [Quit: bye]
maciekb has joined #openwrt-devel
<hgl>
I'm worried that some old concern might not apply now, especially after the introducing of dynamic conf. It'd be great if you could recall
<Ansuel>
the concern at times was just migration and all
<hgl>
by dropping I don't mean it literally, just that nginx is the main package, and nginx-ssl depends on it for backward compatibility
<hgl>
this feels more reasonable, IMHO
<Ansuel>
and here we are again with another virtual package solution :(
<hgl>
ideally nginx-ssl could eventually be dropped. once we jump to the conclusion that ssl should be unconditional, keeping both nginx and nginx-ssl, or dropping nginx can be quite confusing
<hgl>
like people can ask what's the difference if we choose the former, or why there is no nginx but only nginx-ssl if we choose the latter
<hgl>
"since nginx-ssl have many feature of nginx-full disabled", the config options all depends on nginx-ssl, if nginx-ssl is selected, they are displayed, if nginx-full is selected, they're not, maybe I missed something, but why that could lead to issues?
<Ansuel>
the rationale for nginx-ssl is that openwrt at times didn't had ssl library by default... then we introduced some light ssl library (wolfssl for example) but for nginx openssl is always needed since no other lib are supported... so on openwrt scenario it does make sense to declare a package that have ssl support
<hgl>
I see, thanks for letting me know the history
<Ansuel>
also since nginx is pretty special user would refer to wiki and all to install and setup it
<hgl>
tbh, this make -ssl sounds more like a legacy
<Ansuel>
so having only nginx-ssl is not that of a problem... the main problem here is that at times we made the conclusion that switching ssl by default and putting that in nginx would make confusion on the user installing nginx and expecting the non ssl variant
<Ansuel>
since from the start nginx nginx-ssl were present
<Ansuel>
what i'm saying is that it's all a mess of migration problem and trying to create less confusion on the user
<hgl>
i see
<hgl>
so do you think it's time to drop -ssl? since we introduced new package names already
<hgl>
or both nginx and nginx-ssl should continue to live?
<Ansuel>
i would love to have this discussion also with nginx-utils dev so we can take a decision once and for all
<hgl>
sorry
<hgl>
I mean drop nginx
<Ansuel>
hgl ideally one of them should be dropped
<hgl>
so let's drop nginx?
<Ansuel>
we need to decide if we can accept creating confusion and fixing the thing for once
<hgl>
i start to understand you want to emphasize the ssl part, since uhttpd made difference between ssl and non-ssl, keeping only nginx-ssl sounds reasonable after thinking about it.
<robimarko>
I would argue its better to just fix it than care about naming
<hgl>
robimarko: certains, but since some renaming is done (nginx-mod-*, nginx-all-module -> nginx-full), I thought it would be a good opportunity to address the naming issue fully
<hgl>
*certainly
<hgl>
nginx currently has a couple comments mentioned this or that sub packages are transitional, and should be remove in the next major version
<robimarko>
That is what I mean, just fix the naming as well
<hgl>
ok, i thought you wanted us to leave the naming alone
<Ansuel>
also i think i will bloat the init.d to add the module.d thing
<Ansuel>
migration disaster saddly...
<hgl>
I think an uci-defaults script that adds the line to user config should work
<hgl>
do nothing if the line exists
<Ansuel>
the script is already there
<Ansuel>
i need to check when is run tho
<hgl>
oh, i misunderstood you in that comment
<Ansuel>
but wait
<Ansuel>
actually...
<hgl>
so why it's not working?
<Ansuel>
i need to check when uci-defaults scripts are run...
<Ansuel>
think they are run on reboot after a sysupgrade
<hgl>
init.d/boot if I'm not wrong
<Ansuel>
might be a simple fix a post install script that check if the entry is present in the template and just adds it
<hgl>
post install also run uci-defaults if one exists, so you only need uci-defaults
<Ansuel>
ok so in theory sysupgrade can be upgraded that way
minimal has joined #openwrt-devel
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<PaulFertser>
karlp: Ansuel: do you probably have an opinion on this statement: "To my understanding, decision to add some numbers to MAC address does not look like DT property at all." (in an attempt to add mac-addr-increment upstream), probably want to chime in: https://lore.kernel.org/all/5b826dc7-2d02-d4ed-3b6a-63737abe732b@linaro.org/ ?
<hgl>
jow_: config_foreach_break good to merge?
<Ansuel>
PaulFertser main problem is that there was a similar attempt for that and we got the same response
<Ansuel>
and he is 99% correct about that saddly... DT should describe the device so mac address increment is a big grey zone
<robimarko>
Yeah, it doesnt fit the goal of describing the HW itself
<PaulFertser>
Ansuel: but what about the fixed MAC address location in an MTD partition then?
<PaulFertser>
Should it not be there ither?
<Ansuel>
the main justification might be that OEM put a master MAC
<robimarko>
Well, a good case would be like that one
<PaulFertser>
MAC address assignment policy is part of hardware as released by the manufacturer, so it is part of hardware.
<Ansuel>
and then offset that master MAC by incrementing it for each device. that might be a justification of a way to describe the device
<PaulFertser>
Yes, of course that's exactly the case OpenWrt targets with this option.
<Ansuel>
but you should try to find a better approach to that
<Ansuel>
maybe they would like that more
<robimarko>
Well, its a matter of somehow explaining that upstream
<Ansuel>
(nvmem transformation binding)
<Ansuel>
that would also permit the ascii thing to be used
Slimey has joined #openwrt-devel
<PaulFertser>
How about the case where we have a separate PCIe Ethernet chip on the motherboard, with its separate flash memory accessible only by the chip? And manufacturer assigns two addresses to that card from its MAC pool, for the host system, and for the BMC using same card over a side channel. nvmem subsystem can't get access to MAC but the ethernet hardware driver can.
<Ansuel>
the mac comes from a nvmem cell right?
<Ansuel>
mhhh you might have a point actually
valku has joined #openwrt-devel
<Mangix>
Ansuel: qca8k in tree wen?
<Ansuel>
Mangix 6.1
<Ansuel>
multi cpu support in theory
<Ansuel>
or at least assigning the secondary cpu to wan port
<Mangix>
That work's not stalled?
<Ansuel>
nope evolved in using LAG and supporting multiple cpu
<Ansuel>
my simple implementation evolved in something much bigger
<Mangix>
Hmm OK.
<PaulFertser>
Ansuel: thank you for the discussion, I'll try to prepare it in some more solid hopefully convincing way for a reply upstream.
<Mangix>
Too bad qca switches don't support the phy reassignment thing mt7530 does
<Ansuel>
well qca8k design is quite old and still for the days it was O.K.
<Ansuel>
the idea was one cpu port for LAN
<Ansuel>
and a dedicated one for WAN port
<Mangix>
Although with the multiCPU work, I wonder if it makes sense to revert the mt7530 phy thing and do the whole thing with DSA
<Mangix>
Sounds like extra overhead
<karlp>
PaulFertser: I've got zero interest in having any sort of discussion with kernel cliques sorry,and certainly no weight for my comments to have any meaning in those circles
<karlp>
_personally_ I feel mac addresses, as being required(intended) globalyl unique resources _are_ part of the hardware.
<karlp>
but it matters not one jot what I think to those people :)
cmonroe has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
<mirko_>
i'm trying to make use of the pypi.mk file but end up with redundant copies of files in my install-dir as well as final package - /usr/bin/X.py as well as /usr/lib/python3.10/site-packages/X.py .
G10h4ck_ has quit [Quit: Konversation terminated!]
<EsdiDude>
Hello all, I just wanted to mention that I spent quite some time yesterday trying to bring a dlink 868 up. In the end I got frustrated with the broadcom CFE, decided that the heatsink, pcb antenna's and the 12v adaptor was worth the $4 I spend on a good donation. So, so much for that. The great material universe will provide, so who knows what I'll find tomorrow.
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cbeznea has quit [Quit: Leaving.]
MaxSoniX has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
schwicht has joined #openwrt-devel
philipp64 has left #openwrt-devel [#openwrt-devel]
philipp64 has joined #openwrt-devel
<f00b4r0>
seems libradcli in 22.03 is somewhat broken
maciekb has quit [Read error: Connection reset by peer]
maciekb has joined #openwrt-devel
zer0def has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<yolo>
to build for different arch and musl vs glibc, staging_dir and build_dir can differentiate them well, so does bin/target, but bin/packages does not, should bin/packages/arch/{mucl,glibc} to distinguish musl and glibc too?
<Ansuel>
well in theory you will never face a situation where both libs are installed on the same arch and target
<yolo>
i could have a x86_64-musl and x86_64-glibc though, same as to other builds, bin/packages does not distinguish anything at all it seems
<yolo>
and i would put bin/ to my web server for opkg to pull as well, with various builds combinations, including musl and glibc options
<Ansuel>
opkg can't distinguish between glibc and musl so that will be problematic
<yolo>
if some of your boards added more storage and memory(same cpu), you can opt for glibc, the old boards with less memory still use musl, for exmaple
djfe_ is now known as djfe
<yolo>
so, bin/targets/x86/{64,64-glibc}, but bin/packages/{x86_64}, the packages under bin/packages has no idea about libraries, which is unfortunate, I will need use different bin/packages for that. ideally there should be bin/packages/{64,64-glibc} as well. opkg is no problem, opkg.conf can be adjusted for it to work with musl|glibc easily
<yolo>
maybe I can work out a patch to add that, let's see
<Ansuel>
if you do please don't change the default state
<Ansuel>
maybe add some kind of configuaration in menuconfig
<Ansuel>
it should not be hard
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<yolo>
change bin/packages/arch to bin/packages/arch/{musl,glibc} might break default opkg.conf, the non-intrusive way will be bin/packages/{arch-musl, arch-glibc} and provide a symlink to the default one as arch, i.e. we can have bin/packages/{x86_64, x86_64-musl, x86_86-glibc} where x86_64 is a symlink to either of the rest two