<hurricos>
are there any other tricks that you are aware of regarindg this hardware?
<hurricos>
Particularly, do you have a draft dts anywhere? ;)
<hurricos>
It's 64MB RAM, so it needs at least *that* fixed, and because it uses RS232 oddly I haven't been able to access U-boot, so I have no test environment.
<slh>
if you have serial console access, you don't need to take care of ZYXEL_VERS, that's only checked by the firmware updater of the OEM firmware
<slh>
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/dts-5.10/rtl8382_zyxel_gs1900-24hp-v2.dts is there, v1 is probably very similar - aside from the RAM size
<slh>
chances are that the v2 DTS will already boot up fine, after changing the RAM size
<slh>
but you really need serial access to try safely
<hurricos>
I do have a flashrom dump I can resotre.
<hurricos>
I have a Pomona clip.
<slh>
o.k., that make it easier
<hurricos>
If you reckon the DTS with the RAM change will work, I have one last question -- do I just 'shadow' it by copying the segment for RAM from the dtsi to the new dts and adjusting?
<slh>
I'd probably start with a new DTS, but shadowing it is indeed the better option
<hurricos>
I've got an unfortunate predicatement. I assumed this was the v2 I was purchasing, but was wrong. This particular device needs to become the network core at my building.
<hurricos>
So I'm in a pretty ... unfortunate situation.
<hurricos>
I'll order a non-HP and test there.
<hurricos>
If I had RS-232 working, I wouldn't be here :S
<hurricos>
OK, let me try building.
<neggles>
hurricos: based on the other zyxel gpl dump i just tore apart, the ole "hold down space" trick should work
<hurricos>
It's RS232.
<slh>
yeah... I'm in a similar situation, having put mine into production way too early - before I could port OpenWrt to them, and now I can't really go back (unmanaged)
<neggles>
bootdelay is set to 1, but the prompt is set to ""
<hurricos>
It's not UART.
<neggles>
that's just UART with a level-shifter
<neggles>
:v
<hurricos>
and inversion
<neggles>
do... do you not have a cisco console cable?
<hurricos>
RJ45 to USB?
<hurricos>
you mean ... no
<hurricos>
I do
<hurricos>
I have one for an APC
<neggles>
APC is entirely different
<hurricos>
having pinned out RX TX and OH FUCK
<neggles>
that's a dumb passive cable
<hurricos>
then I'm not sure it's APC
<hurricos>
since it came up as a PL2302
<neggles>
is it one of the ones with a flat blue cable
<hurricos>
unless you mean, it's a dumb TTL
<neggles>
and a giant usb-a plug
<hurricos>
I have an RJ45 to USB, yes.
<neggles>
flat blue cable = Cisco serial console
<hurricos>
I also have an USB-A to RS232 that a coworker gave to me as an extra presumably for working with APC devices
<hurricos>
Yes, flat blue cable for one.
<slh>
no old x86 hardware with real serial ports available? until quite recently serial connectors were still onboard, just not brought out to the I/O bracket
<neggles>
APC RJ45s get *weird* and the pl2303 usb console cables suck
<hurricos>
It's a RS232, so perhaps the coworker was confused, or I misunderstood
<neggles>
but assuming you have no driver issues that cable should work
<hurricos>
Let me try a build with AAHM and a limit to 64MB
<hurricos>
neggles: Yes, I have more than a few of those
<hurricos>
ws-ap3825i, ap330, bsap2030, all take that.
<neggles>
yeah
<hurricos>
even if that's inverted correctly as rs232 I'm surprised it can take 13V
<neggles>
they have to
<neggles>
cisco use +/-9V swing on theirs
<hurricos>
oooh
<Slimey>
heh
<hurricos>
OK, thank you all. I will try a build now.
<neggles>
if you cut through the plastic molded around the USB connector you'll find (PL2303|CP2102|FT232|CH34x) + a clone of a TRS232E
philipp64 has quit [Quit: philipp64]
rua has quit [Ping timeout: 480 seconds]
<neggles>
and you will probably find that 10-pin header on the board is pinned to match https://i.imgur.com/oBYGKyF.png one of these
rua has joined #openwrt-devel
<neggles>
normally they just put an RJ45 on the thing... weird
<Slimey>
those blue cables cisco uses are roll-over cables
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
_Lechu has joined #openwrt-devel
Lechu has quit [Quit: changing servers]
minimal has quit []
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
rua has quit [Quit: Leaving.]
amaumene has quit [Read error: Connection reset by peer]
philipp64 has joined #openwrt-devel
amaumene has joined #openwrt-devel
<neggles>
stintel: supportlist in your tree matches the one in my file
<neggles>
Slimey: this is true if it's RJ45 on both ends, but those are rather rare to find these days
<neggles>
the other APC cable i was referring to is the USB-RJ45 that comes with some of their lower-end units, which is just a USB cable - but then the higher-end UPSes use a regular old cisco RJ45 serial console, 'cause that wasn't already confusing enough...
<Grommish>
The USBTTY RJ-45 ended can be used for Cisco as well, as least the older ones
<neggles>
some of the APCs use a 2.5mm TRS jack for console, too...
<neggles>
yep
<Grommish>
I used to buy and referb with bootleg iOS bins hehe
<neggles>
if you find an RJ-45 port labeled "console" on a piece of network equipment, there is a 95% chance that you've just found a cisco-console-pinout RS-232
<Grommish>
Yes.. the Itus has one, oddly enough. It's one of the right things they did
<neggles>
it is The Standard
<neggles>
the rollover cables are really annoying though. i have a nice little 4-port network console server from... perle? but it follows cisco's standard for the pinout on a terminal server, so you have to use a rollover to plug it in
<neggles>
it's the same with old lantronix, cyclades etc... newer versions of them have electronically-switchable pinout, but are rarely available for reasonable prices
<neggles>
Grommish: so my snic10e has been running for quite some time now, with dnsmasq running but not bound to ipv6, and ram usage has not appreciably increased
<neggles>
but every time i restart it, it bumps up a few hundred KiB
<Grommish>
neggles: I can't even get my local to build at the moment for some reason: bash: /home/grommish/openwrt/staging_dir/host/bin/opkg: No such file or directory hehe
<neggles>
haha
<neggles>
is it `rm -fr tmp staging_dir build_dir` time?
<Grommish>
neggles: Yeah, but I include tmp/ and .ccache/ for good measure hehe
<neggles>
Grommish: hey I had tmp in there!
<neggles>
and i don't use ccache :P
<neggles>
seems like it causes more problems than it solves
<Grommish>
neggles: True, and I've had issues in the past, but I use it for testing because most people do
<Grommish>
and normally don't have issues from it
<neggles>
tbh i am not entirely sure what ccache actually _does_
<Grommish>
but once in a while (like trying to do a CONFIG_ALL build) it borks
<neggles>
i know it involves caching compiler outputs but
<Grommish>
I thinik it attempts to reuse compiled code that hasn't changed, but I'm not sure how good the hit/miss rate is
<neggles>
it seems like most of the times it would have a significant impact on build speed, you'd want to clear the cache anyway because you can't trust it? or am i missing something and it speeds up within a build
<Grommish>
neggles: Well.. if it misses rebuilding a change for whatever reasons.. then you've got run-away issues that spiderweb
<Grommish>
neggles: But, if you're not making radical changes, I'm sure it would speed up at least subsequent builds
<neggles>
my rebuilds spend most of their time traversing directories to check if anything's changed, not actually running the compiler again
<neggles>
guess I should just benchmark :P
<Grommish>
neggles: that sounds like work
<Grommish>
not hard, just boring I mean :D
<neggles>
heh :P my suspicion is that ccache won't speed up a regular rebuild - almost all the runtime is spent just checking for changes, not actually running a compiler/preprocessor?
<neggles>
if you remove tmp/build/staging but leave ccache, *that* would build a lot faster, but if i'm removing tmp/build/staging it's because something's being Weird, so I'll probably want to remove ccache as well?
<Grommish>
neggles: Well.. a package clean removes the build_dir anyway so at some point it gets removed
<Grommish>
along with the touch-marked stamp files
<neggles>
it would be nice if there was a faster method for detecting whether a package has changed/needs rebuilding or not
<Grommish>
neggles: it looks for .configured .built .installed files in the stamp/ dir
<Grommish>
along with a hash it looks like
<neggles>
yeah, but it spends an awfully long time just traversing down to all the package dirs one by one
<Grommish>
I havent' looked into exactly how it works but I glanced at the working to try and figure out hwo to cheat it
<Grommish>
and just decided there were probably easier ways to explore first
<neggles>
turn off automatic rebuild detection and manually trigger rebuilds whenever you edit something :P
valku has quit [Quit: valku]
<mangix>
neggles: ccache makes a huge difference
<neggles>
mangix: even within a single build?
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<mangix>
yes
GNUmoon has quit [Ping timeout: 480 seconds]
gnanasandhya has joined #openwrt-devel
<gnanasandhya>
why all commercial routers are in OpenWrt 15.05 "Chaos Calmer" is there any licensing issues???
<gnanasandhya>
by commercial routers i mean TP-LINK , MI ROUTERS etc
<stintel>
neggles: great :)
<stintel>
gnanasandhya: QSDK is based on CC. you should ask QCA why they insist on using such ancient software
<stintel>
and afaik OpenWrt has always been GPL-2 so there should not be a difference between CC and more recent versions wrt licensing
<Grommish>
stintel: tl;dr they lazy?
<stintel>
s/lazy/suck/
gnanasandhya has quit [Remote host closed the connection]
md_sandhya has joined #openwrt-devel
<md_sandhya>
are banana pi routers stable
<md_sandhya>
on openwrt
<mangix>
md_sandhya: the r2, yes
<md_sandhya>
do weed need license to use openwrt 21.02 version comercially
<rmilecki>
md_sandhya: ask your lawyer
<rmilecki>
md_sandhya: OpenWrt is GPL
<rmilecki>
md_sandhya: you need to fulfill GPL requirements
<rmilecki>
md_sandhya: if someones takes you to the court, opinion of random IRC user won't help you ;)
<Grommish>
neggles: I built out with IPv6 turned off.. No apparent leak
<Grommish>
Sitting at 27332 idle
<Grommish>
I'm going to let it sit overnight because it isn't being used
<stintel>
would be nice if someone can find a reproducer that makes it leak like >100MB in a short time
lmore377 has joined #openwrt-devel
<Grommish>
stintel: Yah.. at this point, we are just narrowing what it isn't
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Tapper has joined #openwrt-devel
<f00b4r0>
Grommish: ccache should only be used on host bits (if at all). It's not designed for cross-compile scenarios: all sorts of nasties may happen if you use it there. This used to be mentioned in the docs.
goliath has joined #openwrt-devel
rua has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<karlp>
f00b4r0: hve you got explicit cases again? you didn't have anything concrete last time?
<karlp>
because it absolutely should work for cross compile, because there's no reason for it even care about the target arch
rua has joined #openwrt-devel
<dangole>
dwmw2_gone: I didn't try loading the vendor image with new U-Boot, would be nice to try, but most easy with local TFTP server. Can you start a TFTP server on the i7 and give me write access to the folder it is serving?
srslypascal is now known as Guest885
srslypascal has joined #openwrt-devel
rua1 has joined #openwrt-devel
<dwmw2_gone>
Should be serving /var/lib/tftpboot ?
<f00b4r0>
karlp: ISTR the previous conversation was about why it was a bad idea to use ccache on the buildroot for the cross-compile bits, and that was mainly because it's trashing the cache, making ccache negatively affect performance. As for why it shouldn't be used for cross-compiling, i firmly remember reading something to that extent on the ccache website but I see it's changed and I can't find it anymore, so maybe things have changed.
<f00b4r0>
However it still says "The fastest mode (the "direct mode") has a corner case which can result in false positive cache hits."
<f00b4r0>
karlp: tl;dr: I think it should never be used in production, and that was the previous conversation as I remember it :)
<karlp>
so, yeah, nothing concrete then :)
<f00b4r0>
the comment i quoted is very concrete, unless you're talking building material ;P
<karlp>
you can have whtever opinion you like on caching, but the "don't use it for cross compiling" is cargo culting at this point.
<f00b4r0>
ok, if you say so.
<aparcar>
nbd: opinion on switching Kernel versions to something "release" based rather than the Kernel magic hash? Working on APK it doesn't support "hashes" in the version since it's unclear what's newer. Instead we could have something like 5.15.23-r12, where r12 is the release, representing the number of config changes since last kernel bump
<dwmw2_gone>
dangole: oh... and I plugged the Ethernet cable back in :)
<dwmw2_gone>
You should be able to TFTP now
<stintel>
aparcar: what about committer date ?
<dangole>
dwmw2_gone: thing is I can't start a local TFTP server without superuser rights. So you have to start the server and grant write access to the folder it is serving to me
<stintel>
aparcar: we already kind of use that
<stintel>
albeit manually
<aparcar>
stintel: I've seen people committing kernel changes more than once a day :)
<dwmw2_gone>
dangole: I did that but forgot to tag you when I said so above :)
<aparcar>
I'd use something like AUTORELEASE for the kernel release
<stintel>
aparcar: commit date contains timestamp too
<dwmw2_gone>
You should have write perms to /var/lib/tftpboot
<karlp>
your quote is about direct mode, and it's certainly an issue, but it's _independent_ of "cross compiling" whichfrom ccaches poitn of view is just the name of your compiler, it's all just command line hashes, there's no "magic" for cross compiling
<dangole>
dwmw2_gone: seeing it just now :)
<PaulFertser>
aparcar: OpenWrt has the whole kernel .config in kernel hash, so it's not about how many times it was changed but what exactly it is.
<jow>
aparcar: it does not matter if the kernel hash is newer or older
<jow>
it must match exactly
<PaulFertser>
aparcar: it's not exactly hash of .config, it's sorted and massaged a bit, but the idea is that any config change will produce a different hash. So you can e.g. select some package from packages feed, and it'll select a kmod and that will change the config and all your newly built modules are now incompatible.
<jow>
neither a "newer" nor an "older" hash will have a compatible ABI
<f00b4r0>
karlp: istr it was something about how it's more likely to hit false positives, but again, i may be wrong and things may have changed. Regardless, when debugging compilation problems or software misbehavior, not having ccache in the way seems like a Good Idea™.
<jow>
and the current mechanism is an ugly cludge because we didn't have access to the kernel symbol table at the time when kmods are built
<jow>
I believe current master now builds the kernel image before kmods (finally) so we might simply hash the symvers file instead which should be way more accurate than hashing the .config
<jow>
because that should onyl change if actually exported symbols change
<jow>
in any case we require a very strong coupling of kmod-* to the kernel ABI they're built against
srslypascal has quit [Remote host closed the connection]
<jow>
the version alone is not sufficient for that
<jow>
neither is the number of commits since bumping the kernel
<jow>
since the kenrel config might change locally
<PaulFertser>
So probably if APK can't encode that in the version the same hash can be added to the package names?
<jow>
I don't see why APK should have problmes there
<jow>
the hash is nothing special, it's just another part of the version string
<PaulFertser>
Looks like there's no version _string_ in APK.
<jow>
APK shouldn't semantically parse versions, just decide if version_string1 == version_string2
<jow>
so it does not support e.g. openssl versions?
srslypascal has joined #openwrt-devel
<jow>
1.0.0c
<jow>
is not really different to 5.10.0-defabcdbeef
<aparcar>
well currently APK doesn't support that, I might patch that in. Another way is for packages to depend on other package hashes, so not 5.15.12-asdf but some APK specific checksum directly. If the kernel and kernel pseudo package is build before kmods, I can just let those depend on the checksum
<aparcar>
I talked to Alpine folks and they use the releases for their kernels, so in that case 5.10.0-p4 would do the same trick as a checksum
<jow>
and how is using "p4" different to using an sha1 hash?
<jow>
I don't get it
<aparcar>
p4 > p3, for things considered a "version" apk requires it to be comparable . For other cases this package hash seems the solution
<jow>
then let it assume that it is comparable
<jow>
as long as dependencies can specify a fixed version constraint it does not matter if apk considers the mismatching candidate to be "newer" or "older"
<dwmw2_gone>
dangole: bah, just spent a while testing TFTP actually worked from elsewhere on the network. tl;dr: yes it does if you actually talk to the correct server
<aparcar>
yes I understand that kernel and mods are glued together, I'm just thinking of a way around using the current hash which seems to be a ugly solution anyway
<jow>
there is no way around describing the exported ABI in a sufficiently explicit manner
<jow>
no kind of semantic versioning will be able to describe local config deviations
<aparcar>
I'll see to hash the symvers and use that hash for the kernel and then depend on the pkg hast of the virtual kernel package
<aparcar>
yea you're right, if I modify stuff locally I'd end up at p42 which "matches" even though it's a different thing than upstream would consider as p42, a hash is needed
<dangole>
aparcar: why is it a problem to have a hash as part of the version? correct order can still be established by prefixing it with a date or something sortable...
<jow>
so it does support version equality constraints
<jow>
and yeah, maybe you could suffix the hash with something like the getver.sh output
<jow>
but it will not prevent situations where apk considers two differnetly configured kernel builds of the same revision to be newer or older relative to each other
rua1 has quit [Quit: Leaving.]
<jow>
so the additional effort likely isn't worth it in the first place
<aparcar>
using symvers seems a fruit hanging on the way
<jow>
seems to me that prefixing the hash with "p" will be enough
<jow>
or rather with _p
<aparcar>
I tried that but it doesn't work
<aparcar>
I didn't run it through a debugger though
<aparcar>
20211216_p123 works fine, 20211216_p123a is rejected
<aparcar>
we can just convert our hashes to something number based, easy ;)
rua has joined #openwrt-devel
<ynezz>
it's a number but quite huge
aiyion_ has joined #openwrt-devel
<aparcar>
some 12 digits should be enough entropy
<aparcar>
but that doesn't sound very appealing still
aiyion has quit [Ping timeout: 480 seconds]
<ynezz>
anyway it makes no sense to use it for version comparison
dangole_ has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
<stintel>
nbd: ok, so the qosify ubus dump call shows the info I was asking about earlier, it's just udnssnoop that is doing an empty add_dns_host call and as a result nothing is added
mattytap__ has quit [Quit: Leaving]
ldir has joined #openwrt-devel
ldir has quit []
<stintel>
* add outgoing DNS over HTTPS support, using new dependency nghttp2
<stintel>
why was this only added recently o_O
<jow>
hm?
<stintel>
dnsdist - author date is from september, commit date a week ago or so
<aparcar>
jow: do you see an obvious flaw in the apk version handling? if not I'll try to patch it now
<aparcar>
also right now the symvers contain the full build path making it barely reproducible
<Habbie>
stintel, that sat on a branch here since september, when dnsdist 1.7.0 went into alpha
<Habbie>
stintel, i guess when i updated to 1.7.0 final and squashed, it took the old date
<stintel>
ahhh
<stintel>
ok. so 1.7.0 *is* the new release
<Habbie>
yes
<Habbie>
very new
<stintel>
awesome
<stintel>
I know what to do this weekend
<stintel>
there goes the snowboarding :P
<Habbie>
haha
<stintel>
does that also do DoT ?
* stintel
reads the release post
<hgl>
jow, it seems luci directly depends on uhttpd, but since nginx is also able to serve it, do you think it'd be possible to make luci depend on either of them, so that as long as one is installed, the other can be removed? I currently have both uhttpd and luci-ssl-nginx installed, opkg won't let me uninstall uhttpd unless I force it, because of the luci dependency.
<hgl>
i'd be happy to send a PR if it's something doable.
<stintel>
maybe we could add a PROVIDES luci-httpd ?
<Habbie>
stintel, it also does DoT, i believe
<stintel>
Habbie: yeah, I checked the release post
<stintel>
great, glib2 doesn't build
<hgl>
stintel, there doesn't seem to exist luci-httpd package (neither does luci depend on it) I'm not wrong
<hgl>
*if i'm not wrong
<stintel>
I'm suggesting to add a PROVIDES for that
<stintel>
not that it exists
<jow>
"luci" is just an empty meta package to conveniently select the most commonly used configuration
<jow>
if you want to use another httpd, jsut don't select "luci" but pick the comonents manually
* stintel
cleans up some old cruft so that he doesn't need to start yak shaving glib2
<hgl>
jow, i didn't really pick it. I use the official image, and luci comes with it. Are you suggesting I should simply do opkg remove uhttpd --force-depends?
<jow>
opkg remove luci uhttpd should be enough
<stintel>
> Parallel mksquashfs: Using 1 processor
<stintel>
how does that make sense :P
<hgl>
jow, luci-ssl also depends on luci, is it a meta package too that is safe to remove?
<jow>
yes and yes
<hgl>
jow, that works, thanks
<hgl>
i'm not happy with how the acme package works. It tries to update uhttpd or nginx by messing with their confs, I also think it shouldn't provide an init script and should use the hotplug system to notify issue & renew events. I'd like to write a new version for it. Should I discuss it with the maintainer or just create a separate package?
valku has joined #openwrt-devel
_Lechu has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<stintel>
nbd: is there a way to just use classification without shaping in qosify?
<nbd>
not at the moment
<stintel>
ok, any plans to add that?
<stintel>
because right now non of the classification works for internal communication (internal VLANs)
<stintel>
and configuring cake ingress/egress on both incoming and outgoing interfaces is really messing with performance ;)
<stintel>
hmmm wait a minute, I seem to have a performance regression with cake in general :/
<stintel>
download goes from ~900Mbps to ~315Mbps
<Slimey>
ew
<stintel>
hah
<stintel>
udnssnoop is to blame
<stintel>
ok, so it's a combination of udnssnoop + qosify
<stintel>
heh
<stintel>
[vr jan 28 17:02:51 2022] ixgbe 0000:02:00.0 eth2: NIC Link is Down
<stintel>
[vr jan 28 17:02:55 2022] ixgbe 0000:02:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: None
<stintel>
sit/stand desk issue 😂
<Habbie>
haha
<Habbie>
i currently cannot stand due to a short power cable
<stintel>
I went a bit nuts, switches mounted to the bottom of the tabletop even
<stintel>
but that's not 10GbE capable, so the workstation itself has a cable coming from elsewhere
<stintel>
can probably fix that wit zip ties
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Slimey>
i hate zip ties even more when someone uses them in a environment you know they will have to be undone
<stintel>
Slimey: what's your alternative?
<Slimey>
velcro
<Slimey>
the strips in a roll
<stintel>
not sure it's strong enough to solve my link down on sit/stand desk up/down problem
<Slimey>
oh i was just making a general statement :P
<Slimey>
i must have missed it whats the issue ahain
<Slimey>
*again
* stintel
double checks switch logs, maybe something else is going on
<stintel>
because I pulled the cable a few times and didn't manage to get a link down
<Slimey>
oh
<stintel>
Jan 28 2022 17:19:19+02:00 cs0 %%01MSTP/3/PACKET_ERR_COMPLIAN(l)[27]:The port compliance protocol type of the packet received by MSTP from the port MultiGE0/0/15,(InsId:0,RcvInt:0,SrcMAC:f492-bfa9-f4ab,RootId:32768.f492-bfa9-f4ab,ExCost:0,BdgId:32768.f492-bfa9-f4ab,PortId:128.1,RegRootId:0.0000-0000-0000,InCost:0) is invalid.
<stintel>
sigh
<stintel>
ustpd is fucking up my network again
<Slimey>
;/
<f00b4r0>
speaking of cake, what's the best qdisc to use for host fairness when you have variable bandwidth (e.g. LTE)?
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
BPDU Sent :80
<stintel>
TCN: 0, Config: 0, RST: 80, MST: 0
<stintel>
BPDU Received :2
<stintel>
TCN: 0, Config: 0, RST: 2, MST: 0
<stintel>
on the time my Huawei sends 80 RSTP packets, the Unifi Switch Flex running OpenWrt only sends 2
<stintel>
that makes no sense at all
<stintel>
assign(br->Hello_Time, (__u8)2); /* 17.14 of 802.1D */
<mangix>
i never merged as I don't like disabling PKG_FORTIFY_SOURCE. It typically indicates an actual problem.
neoraider has quit [Remote host closed the connection]
<mangix>
stintel: got a config?
neoraider has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
neoraider has quit [Remote host closed the connection]
neoraider has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<mangix>
stintel: is qoriq source only? I don't see it under downloads.openwrt.org
<stintel>
it is
<stintel>
config uploaded to the PR
<Grommish>
neggles: Well.. I dunno if it's "creep" or not.. but I shot up to 30.8Mb used .. laugh, of course, it's literally just connected on the WAN, so..
<Grommish>
from like 27Mb, so.. if it's there, it's dead slow
Luke-Jr has quit [Ping timeout: 480 seconds]
<mangix>
stintel: reproduced. such a strange error
<Borromini>
neggles: thanks for digging through the sources :)
<Borromini>
would a binary patch be able to change the u-boot auto prompt behaviour?
<Borromini>
i'm looking into squeezing a functional OpenWrt image into the flash dump atm.
neoraider has quit [Remote host closed the connection]
<mangix>
stintel: building with CONFIG_ALL makes the kernel build fail:https://gist.github.com/neheb/39bd6deb98934a785f9300fe28766305
<mangix>
note the NEW entries
<Grommish>
mangix: When using CONFIG_ALL, I had to add IGNORE_ERRORS="m,n" to get it to build otherwise it'll fail on packages for other arches
<stintel>
mangix: target/linux/qoriq/config-5.10:# CONFIG_LD_HEAD_STUB_CATCH is not set
<mangix>
ah yeah
<Grommish>
I also had ulimit issues when dealing with luci under config_all
<stintel>
I wrote that in my cover letter
<mangix>
make kernel_oldconfig deleted it
<stintel>
something keeps removing that
<stintel>
no clue why
<mangix>
i have no idea about the last error
<mangix>
the middle one is probably related to rsalvaterra's zstd patches
<mangix>
stintel: flac fails to build. does qoriq support altivec?
<stintel>
yes
<stintel>
well
<stintel>
it's ... tricky
<stintel>
and explained in the commit messages / cover letter
<mangix>
warning: implicit declaration of function 'vec_vsx_ld'; did you mean 'vec_sld'? [-Wimplicit-function-declaration]
<mangix>
:)
<stintel>
smells like a bug in flac
<stintel>
Using CONFIG_E6500_CPU here due to the kernel using -mcpu=powerpc64
<stintel>
rather than -mcpu=e5500 when selecting CONFIG_E5500_CPU. The only
<stintel>
difference between e5500 and e6500 is AltiVec support, and the kernel
<stintel>
support is disabled at compile-time, so we need to use e5500 in CPU_TYPE
<stintel>
checks for it at runtime. Musl will only check at runtime if AltiVec
<stintel>
to avoid SIGILL.
<stintel>
so userspace builds with -mcpu=e5500 which does not have altivec
<stintel>
if flac failes to build, that's a bug in flac
<mangix>
seems there's a --disable-vsx configure flag
<mangix>
fdk-aac fails in a much more bizarre way: error: inlining failed in call to 'always_inline' 'void fft_4(FIXP_DBL*)': indirect function call with a yet undetermined callee
<mangix>
fdk-aac as a package is a nightmare. maybe i'll look into fixing some day
neoraider has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Slimey>
firewall4 is live in snapshots?
<Borromini>
Slimey: yeah
<Slimey>
i saw on reddit just making sure
<Borromini>
hehe
<Borromini>
well there's people crying wolf, so...
<Borromini>
yep, fw4 is live :^)
<mangix>
Slimey: reddit?
shibboleth has quit [Quit: shibboleth]
<Slimey>
yes
svlobanov has joined #openwrt-devel
<mangix>
stintel: there's something magical about your config. I get errors that I don't get otherwise
<svlobanov>
stintel: hi. network/services/lldpd/Makefile has strange dependency: +LLDPD_WITH_SNMP:libnetsnmp, but libnetsnmp is not present in OpenWrt core tree
<stintel>
svlobanov: dependencies of core -> feeds are OK, just not allowed default on
<svlobanov>
ok, thanks for the explanation
<mangix>
svlobanov: It is preferred but not required for optional dependencies to not be present in core.
<svlobanov>
I'm trying to reproduce your glib2 issue with your config on ubuntu20.04