<slh>
rsalvaterra: well, I don't really care about the overclocking - so mine is self compiled, but unchanged (iirc there was a question of there being potentially an issue with non-stock/ non-breed bootloaders, which seem to have been resolved as being different switch revisions by now)
danitool has quit [Ping timeout: 480 seconds]
<mangix>
aparcar[m]: after thinking about it some more, I whipped up a new version of the bcm patch. Easier to read and reason about.
<mangix>
Note that I can't get rid of the m variable. In C++ I can but not C.
Tapper has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
* Luke-Jr
now wonders what GCC 21.02 was built with :x
<Luke-Jr>
ah, 8.4, phew
<Luke-Jr>
(GCC 9 has an unfixed bug that can cause security issues in theory)
<mangix>
musl creator says it's a critical issue. I trust him.
<Luke-Jr>
idk why they've basically left it unfixed in 9
<mangix>
Luke-Jr: it's an issue in 10 apparently
<Luke-Jr>
there's a fix in 10.3 tho
<mangix>
cool
<Luke-Jr>
I'm still patching out the builtin memcmp anyway, but in theory 10.3+ should be safe XD
<mangix>
the backport in the bug report is pretty huge
<Luke-Jr>
yeah
* Luke-Jr
ponders who to ask to add wifi drivers to the x86-64 images <.<
<mangix>
hmm?
<aparcar[m]>
mangix: please start using the CI so I can see that your patches work
<Luke-Jr>
forgot to download the wifi ipks manually before sysupgrading :P
<aparcar[m]>
Else I have to run them in my ci
<Luke-Jr>
maybe I would regret such a change tho, the number of possible x86 drivers is unlimited :/
victhor has quit [Ping timeout: 480 seconds]
<Tusker>
Luke-Jr: then I think the sysupgrade mechanism should detect kmod's currently in use, and show a warning saying "kmod wifi driver is missing, are you sure you want to upgrade?"
<Tusker>
and then you can rebuild your sysupgrade image to include the missing drivers
<Tusker>
hmmm... anyone here experienced in building a DSA switch config within dts ? I am trying to bring up two marvell switches on the WatchGuard XTM330, which detects the marvell switches, but I am having issues trying to figure out how the ports are meant to work...
grid has quit [Quit: grid]
grid has joined #openwrt-devel
<Luke-Jr>
Tusker: rebuilding a custom image is a pain :P
<Luke-Jr>
maybe sysupgrade should preemptively fetch the package ;)
<mangix>
aparcar[m]: I ran them locally. Should be fine.
<Tusker>
Luke-Jr: yeah, that might work too.
rmilecki has joined #openwrt-devel
<rmilecki>
rsalvaterra: is there any ongoing work on swconfig -> DSA migration?
<aparcar[m]>
Luke-Jr: try auc or luci-app-attendedsysupgrade
<mangix>
rmilecki: there's WIP work for ath79
justas has quit [Quit: Page closed]
<slh>
ipq806x is basically ready (the ath79 work for ar8337/ ar8327 evloved out of that), ipq40xx is a bit more difficult (and ipq807x even more so)
<Tusker>
damn, they have a kernel module that does the DSA setup :(
<rmilecki>
mangix: wow, that's really interesting what causes that difference
<rmilecki>
mangix: DSA header maybe? for whatever reason
<mangix>
rmilecki: beats me. What's more interesting is that qca8k is faster only with ath79. With ipq, it's slower.
<rmilecki>
uh
<mangix>
slower compared to the swconfig driver that is
goliath has quit [Quit: SIGSEGV]
<rsalvaterra>
Uh… qca8k is *slower* on ipq targets?
<mangix>
rsalvaterra: AFAIK
<mangix>
at least according to Ansuel
<rsalvaterra>
Interesting.
<mangix>
probably some CPU scheduling problem. That whole platform is a disaster.
<mangix>
booo this router has no wifi LED configuration.
<mangix>
just switch LEDs with no driver support.
<rsalvaterra>
mangix: Atheros was wonderful, until Qualcomm fscked it up. :P
<mangix>
so there's only one upstream DSA driver with LED support
<mangix>
hirschmann/hellcreek_ptp.c
<mangix>
I have never heard of this
<mangix>
there might be hope for qca8k
<rsalvaterra>
Hm… "hellcreek" isn't entirely unfamiliar, I've probably seen patches for it in linux-netdev. No idea where it's used, though.
Pepes has joined #openwrt-devel
nitroshift has joined #openwrt-devel
Pepes has quit [Ping timeout: 480 seconds]
<mangix>
rsalvaterra: in case you missed it, my dsa PR was updated.
Pepes has joined #openwrt-devel
<rsalvaterra>
I saw it, now supporting the other devices. ;)
SwedeMike has joined #openwrt-devel
<mangix>
just tp link ones. Those tend to be similar enough
<mangix>
I still don't know if you got the LEDs working
danitool has joined #openwrt-devel
<rmilecki>
mangix: can you point me to ath79 work on porting swconfig->DSA?
<rsalvaterra>
mangix: Now having a look at this baby… https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/qca9563_tplink_archer-x6-v2.dtsi;h=fc6206d891a92249eabad471934ccade3b1ff7f3;hb=HEAD
<mangix>
rsalvaterra: ar8337. I don’t even know how it’s set up. Might need some of those magic qca8k parameters.
<mangix>
Like 1.8 volt or w/e.
<rsalvaterra>
Ouch. If voltages are involved, I'm not touching it. :/
<rsalvaterra>
And with no serial console, it's just too risky.
<mangix>
That’s why I’ve avoided it. That and I have no hardware.
<mangix>
Ansuel knows more I’m sure
goliath has joined #openwrt-devel
<mangix>
Conspiracy: what if the switch on this archer is faster because I’m feeding it more than 1.8 volts.
<rmilecki>
rsalvaterra: ah, I thought that "automated conversion" means some script for config migration
<rmilecki>
I think you just meant DT stuff
<rsalvaterra>
mangix: It wouldn't have survived for so long at 3.3 V…
<rsalvaterra>
rmilecki: Yeah, that's what Ansuel wants to do, trying to automagically convert supported ath79 targets to DSA (for qca8k, at least). :)
<stintel>
definitely not. I read a 1.8v flash chip once with a 3.3v reader. on the 2nd attempt, the flash type was no longer correctly detected, but was still able to read the data (with same checksum as previous image), but on the 3rd attempt the chip was dead
<rsalvaterra>
Oh… the DIR-685 has an RTL8366RB, while the WNDR3700 has an RTL8366S… I wanted to give the WNDR3700 a shot at DSA support, but the switches probably aren't compatible… :(
<rsalvaterra>
(Unless the RTL8366RB DSA driver also supports the RTL8366S, but there are so many variants of the RTL8366 family…)
<rmilecki>
[ 0.000000] ---[ end trace 21f061879615f4fd ]---
<rmilecki>
[ 0.000000] arch_timer: cp15 timer(s) running at 0.03MHz (virt).
<rmilecki>
ok, that's something I have to debug & fix
<rmilecki>
thanks PaulFertser
<PaulFertser>
Warnings like that would explain it
<PaulFertser>
rmilecki: so glad to be of help to you
<Tusker>
stintel: any idea on the pastebin issue with the marvell switch on the xtm330 ? (scroll up...)
<Tusker>
i requested for gpl source for the kernel module wg_dsa.ko (it has license=GPL in it... so technically they should provide it)
<PaulFertser>
You meant s/should/MUST/ I believe
<Tusker>
ha... yes... they called me on the phone trying to sell me a new firewall, and I said "well, in parellel to this sales excercise, can you please action my request for the GPL source?"
aleksander has joined #openwrt-devel
<hauke>
nbd: ustp does not compile against glibc, because it is not linked against -lpthread: https://pastebin.com/YTpj9MMd
glbp has joined #openwrt-devel
slh64 has joined #openwrt-devel
slh has joined #openwrt-devel
pmelange has quit [Quit: Leaving.]
PtitGNU has joined #openwrt-devel
minimal has joined #openwrt-devel
<stintel>
Tusker: please reping after 1600 UTC
mrkiko has joined #openwrt-devel
<mrkiko>
Hi all!
<mrkiko>
digitalcircuit: hi
<mrkiko>
digitalcircuit: how is the bug hunt going??
<rsalvaterra>
rmilecki: With Linux 5.10 in OpenWrt, even /dev/random shouldn't block anymore.
<PaulFertser>
rsalvaterra: how does it guarantee entropy quality then?
<minimal>
kernel should typically have jitterentropy to "help"
<minimal>
for kernel during early boot
<stintel>
doesn't work on some devices though
<stintel>
like rpi1/0
<minimal>
stintel: interesting, what's the issue?
<stintel>
it's not supported
<stintel>
dunno exact details, probably some discussion on ml about it
<stintel>
[ 13.222651] jitterentropy: Initialization failed with host not compliant with requirements: 2
<minimal>
generally for systems the more entropy sources available the better - so on servers I tend to run rngd with jitterentropy-rngd (requires kernel module to be loaded), hardware RNGd and RDRAND enabled.
<minimal>
stintel: that's the kernel module failing to init, it does some sanity checks so guess it thinks in that case there is no valid entropy. As the RPIs generally have a HW RNG you can run rngd with both jitterentropy and hw rng enabled and even if jitter fails it'll use the HW
<stintel>
I have rngd with /dev/hwrng running, just wanted to point out that jitterentropy doesn't always work
<minimal>
AFAIK the jitterentropy-rng kernel module is separate from the built-in jitter entropy used for kernel early entropy init (for kernel-only use)
<minimal>
stintel:its interesting, haven't seen that module fail, could ask the author - I maintain jitterentropy-library and rngd for Alpine Linux so interact with him sometimes
<PaulFertser>
Error 2 and jitterentropy is probably the same reason urngd wasn't starting.
jbowen has joined #openwrt-devel
<PaulFertser>
Lack of hrtimers most probably.
<minimal>
lookinh at the kernel, 2 means: /* Timer too coarse for RNG */
<PaulFertser>
So same as userspace implementation we were checking earlier.
<minimal>
yeah jitterentropy-library is derived from the kernel source (same author)
<minimal>
there's been quite a few changes in jitterentropy-library recently to deal with some corner cases (i.e. single core CPUs), I think there was some talk about coarse timers
<minimal>
however this talk was in the context of the library, not with regard to the kernel module failing to load
<stintel>
indeed, urngd also doesn't work on pi1/0
<minimal>
stintel: urngd? is this rngd from rng-tools?
<minimal>
ah, the rng-tools rngd let you configure more than 1 entropy source - that's why on my RPIs (2/3/4) running Alpine Linux I enable both jitterentropy and HW rng)
<rsalvaterra>
PaulFertser: It never did.
<minimal>
stintel: is this based on/exactly the same the same author's jitterentropy-rngd?
<stintel>
no idea
<stintel>
have not looked at the code
<stintel>
only complained that it didn't work ;)
<PaulFertser>
rsalvaterra: man random tells me: /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.
<minimal>
stintel: does haveged work on the RPI 0/1 then?
<stintel>
have not tried
nitroshift has quit [Quit: Gone that way --->]
<minimal>
wondering if the same sort of issue would happen with haveged
<minimal>
haveged & jitterentropy are basically kludges to try and scrape some entropy from devices that don't have any valid entropy source(s)
<stintel>
at some point it started causing issues, took >1m after boot before wifi could connect due to lack of entropy
<stintel>
I then suggested to move rng-tools from -packages to core and enable by default on rpi0/1
<minimal>
stintel: the bigger concern is that without any entropy if you deploy multiple of the same devices running the same code then there's a risk that any initial generation of SSH keys could generate exactly the same keys on multiple devices (from memory this was found to have happened with an ISP in Brazil several years ago)
<stintel>
heh
<rsalvaterra>
minimal: Use urng insted of haveged.
<rsalvaterra>
PaulFertser: After initialisation, both random and urandom behave the same way.
<rsalvaterra>
(Since Linux 5.6.)
<minimal>
rsalvaterra: urng relies on jitterentropy-rngd kernel module which, as stintel pointed out, fails to load/init on a RPI 0/1
<rsalvaterra>
minimal: Uhh…? Ok, that's news to me. Carry on, then. :P
<PaulFertser>
rsalvaterra: does this mean random was guaranteed quality before but not anymore?
<PaulFertser>
minimal: I think it relies on userspace implementation of that module
<minimal>
rsalvaterra: yes the jitter kernel module does sanity checks and apparently fails on RPI 0/1 as the time is too coarse
<minimal>
PaulFertser: urngd appears to be based on jitterentropy-rngd (in the urngd git repo there's a .gitmodules file referencing that repo) which replies on the jitterentropy-rngd kernel module
rua has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 3 days 14 hours 39 minutes 27 seconds]
<PaulFertser>
minimal: are you sure the code runs in kernel space and not in userspace when urngd is working?
<PaulFertser>
rsalvaterra: got it, thank you.
<minimal>
PaulFertser: your earlier comment made be think about this - indeed I had a look at the jitterentropy-library code and don't see any signs of it referencing the module - I'm currently tweaking a VM to block the kernel module from loading to check if rngd (from rng-tools) manages to initialises the jitter code still
<minimal>
if that's the case it seems strange - but then again until not too longer ago the jitterentropy-rngd code had a complete set of duplicated code form the jitterentropy-library, its only recently he removed that from j-rngd and simply used his own library
Lynx- has joined #openwrt-devel
<minimal>
PaulFertser: yupe, rngd with jitter inits fine without jitterentropy-rngd kernel module
<minimal>
for some reason I thought there was a connection/interaction between the kernel module and the jitterentropy-library
<minimal>
rsalvaterra: yeah LRNG is by the same author as the jitter lib/rngd etc. He's been working on it for sometime, wonder if it will get accepted
<PaulFertser>
This looks impressively credible.
<rsalvaterra>
It's at v42… he's persistent, for sure. :)
<minimal>
rsalvaterra: as opposed to him being random? ;-)
<rsalvaterra>
Get out. :P
<rsalvaterra>
Hm… my WDR3600 kernel build failed…?
pmelange has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
pmelange1 has quit [Ping timeout: 480 seconds]
<chadn>
Hi. I was wondering if someone could give me a bit of help. I am trying to test a fix for the Atheros WDS issue. I have compiled an updated version of the NETIFD package.
<chadn>
How do I install the updated version?
<stintel>
scp the ipk and opkg install --force-reinstall /path/to/ipk
<chadn>
thanks.
<stintel>
welcome
<PaulFertser>
btw, it's not really specific to atheros, it affects all the sane softmac wifi drivers.
<stintel>
wait. atheros and sane in the same sentence?
<stintel>
that's enough internet for today
<rsalvaterra>
stintel: Atheros was relatively sane until ath9k… it was all downhill from there. :)
<stintel>
s/9/10/
<dwfreed>
hey, I have an ath10k router running openwrt
<dwfreed>
seems fine
<rsalvaterra>
stintel: Since when is ath10k sane? o_O
<stintel>
I never said that
<olmari>
rsalvaterra: it isn't.. that's why "until 10"
<stintel>
until ath10k means to me that since ath10k it's downhil
<olmari>
I was about to say that wasn't ath9k kinda the peak of OSS wifi..
<PaulFertser>
Well, ath10k is saner than realtek and other out-of-tree trash.
<stintel>
no
<stintel>
it's not usable
<stintel>
I feel we should even remove anything ath10k based from the recommended hardware page(s)
<stintel>
or even stronger: advise people not to buy atheros based crap
Lynx-- has joined #openwrt-devel
<olmari>
what is there left for 11ac and onwards then?
<PaulFertser>
So only mediatek left? And not mt7620. And probably not mt7602. And and...
<rsalvaterra>
olmari: Mediatek, pretty much.
<rsalvaterra>
ath11k is even more horrible than ath10k.
<rsalvaterra>
Intel is basically useless.
<stintel>
look vanilla ath10k crashes with no automatic recovery, qca doesn't give a flying fuck about ath10k, ath10k-ct fixed some of that, unfortunately there are new crashes, and Ben (CT) is not able to fix them
<dwfreed>
sounds like the summary is "wifi is insane"
<stintel>
PaulFertser: I believe that was a recently introduced bug in rs algo
<stintel>
and has been fixed
<PaulFertser>
stintel: I haven't seen rmilecki happy with mt76 so unlikely.
<rsalvaterra>
stintel: I don't know, I've seen rmilecki still complaining recently (days ago?).
<rsalvaterra>
There are, however, mt76 systems with bad calibration data. I don't know if the Mi Router 4C is one of them.
<stintel>
I got a macbook pro and galaxy s9 from my new client, connected that to my network and ath10k started crapping itself 20 times per minute
Lynx- has quit [Ping timeout: 480 seconds]
<PaulFertser>
rsalvaterra: how does vendor firmware work on them?
Lynx-- has quit [Read error: Connection reset by peer]
<stintel>
at that point I replaced my main AP at that location with my travel router, GL-iNet MT-1300
<rsalvaterra>
PaulFertser: Does it?
Lynx-- has joined #openwrt-devel
<stintel>
that thing is amazing
Lynx- has quit [Read error: Connection reset by peer]
<PaulFertser>
rsalvaterra: I would guess so, people often downgrade to vendor's for testing.
Lynx- has joined #openwrt-devel
<olmari>
I don't think wifi itself is that insane.. insanity is why isn't OSS appreciated by.. well OEM's at the least... while I can not say anything what runs on say arbitary oem broadcom, but that damned Inteno devices wifi is absolutely amazing.. and it runs some bloody abomination oftheir custom openwrt.. was it "chaos breaker" or "barrier calmer" I don't remember how thy named it
<rsalvaterra>
mangix: ping.
chadn has quit [Quit: Leaving]
<Borromini>
rsalvaterra: isn't the bad calibration data often a NAND bad block issue?
<Borromini>
at least, that's what a lot of NAND devices seem to suffer from, from OpenWrt not implementing that
<olmari>
..I mean they can make working proper wifi, but for any reason wholey closed up always
<rsalvaterra>
Borromini: Could be…
Lynx-- has joined #openwrt-devel
<PaulFertser>
What's most worrying is that Rafal's detailed and quality report on the mailing list received _zero_ replies.
Lynx--_ has joined #openwrt-devel
<rsalvaterra>
PaulFertser: The mt76 team is most likely aware of the issue. Maybe it's just not easily reproducible?
<PaulFertser>
rsalvaterra: maybe they could just talk to get remote access then, and additional devices to capture over-the-air traffic? It's not like Rafal is someone not capable to arrange that.
botchedrepair has joined #openwrt-devel
<olmari>
I have to admit I've not read mailing list lately much at all
<stintel>
I'll add the topic on the next meeting agend
Lynx--_ has quit [Read error: Connection reset by peer]
<PaulFertser>
rsalvaterra: and not answering at all is just downright wrong in any case IMHO.
Lynx- has quit [Ping timeout: 480 seconds]
<Borromini>
stintel: which topic? I just joined mid-conversation
<stintel>
Borromini: ath10k being shit and mt76 not being much better for some
Lynx--_ has joined #openwrt-devel
Lynx--_ is now known as Lynx-
Lynx-- has quit [Ping timeout: 480 seconds]
brpr has quit [Ping timeout: 480 seconds]
<rsalvaterra>
I've actually seen something very weird on my mt7603e. It's extremely rare, only happened twice: the Wi-Fi signal completely dissapeared, as if the radio was disabled.
<rsalvaterra>
*disappeared
<stintel>
no indicators in logs ?
<rsalvaterra>
Absolutely nothing. From the router's point of view, everything was working.
<Borromini>
stintel: ok :)
minimal has quit []
bookworm has quit []
bookworm has joined #openwrt-devel
Lynx- has quit [Read error: Connection reset by peer]
<Borromini>
i'm secretly hoping the AC codebase will keep seeing improvements but focus really seems to be on AX, with mt76. so I'm curious.
<Borromini>
e.g. stuff like MT7613 seems to be a second wave AC late comer and support is so-so
Lynx- has joined #openwrt-devel
Lynx- has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
aleksander has quit [Quit: Leaving]
Lynx- has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
Lynx- has quit [Read error: Connection reset by peer]
botchedrepair has quit [Read error: Network is unreachable]
Lynx- has joined #openwrt-devel
Lynx- has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
<stintel>
!seen tusker
<stintel>
should he join and I'm idle, tell him his switch node is missing phys
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<nick[m]12>
@dangowrt I wrote a script that takes other control of the procd watchdog. however, if I try to enable the daemon again it does not work. it always needs multiple runs of the ubus call to enable it again :/ any idea how to cleanly let procd take control of the watchdog again?
<nick[m]12>
maybe file handle is not closed sucessfully :/
<nick[m]12>
or if someone else has any idea I'm always thankful for some tips
rua has quit [Quit: Leaving.]
jbowen has quit [Quit: leaving]
<mangix>
aparcar[m]: both PRs are ready.
<mangix>
rsalvaterra: pong
<aparcar[m]>
mangix: but dani said you're copying some bytes rather than the content of the registry
<aparcar[m]>
Can that be correct?
<rsalvaterra>
mangix: You broke my router. ;)
<rsalvaterra>
No biggie, it was just the LED bindings. :)
<mangix>
rsalvaterra: asaaaand rejected upstream. As expected.
<will[m]>
if i wanted to compile this myself inside of an openwrt box (using the openwrt os as a development platform because getting my laptop set up right is a pain) how might i compile it?
<will[m]>
i've gotten to the point of for example `gcc -v -o nfnetlink -I/usr/include/libnl-tiny -lnl-tiny nfnetlink.c` but it keeps complaining that netlink commands are undefined references, despite having libnl-tiny installed
<mangix>
I should really contact that deng guy to see if he can add LED support to mt7530
<will[m]>
i'm wondering if the only way to develop packages for openwrt is to change a line, rebuild the whole package with the sdk, install the resulting ipk, rinse, repeat
<champtar>
will[m]: you can easily boot openwrt on your laptop using qemu
<will[m]>
that's not the question, i'm "booted" into openwrt, now how do i compile and run when there's no package for sources and -lnl-tiny doesn't seem to link the nl_recv function during runtime
<will[m]>
i manually downloaded and copied the source headers from git, but getting the functions to actually be usable is the hangup
<champtar>
sorry read only half of your messages, it's pretty rare to build on openwrt
<champtar>
just build from source or use the SDK
<stintel>
indeed. and nlbwmon was most likely written targetting openwrt, which means compiling it outside buildroot/sdk/... might be challenging
<stintel>
why not just opkg install nlbwmon ?
<will[m]>
i'm writing my own thing for openwrt that uses netlink
<will[m]>
so if you were going to develop your own new project for running on openwrt, you'd write a .c file, shove it into /packages/, build it into an IPK, copy the IPK to your router, and run it to see if it crashes or not?
<stintel>
yes
<will[m]>
:gun_emoji: :smiling_face_emoji:
<will[m]>
no way of making that take less than ten minutes and five commands across two terminals?
<stintel>
the average OpenWrt-supported device doesn't even have space to install a compiler
<aparcar[m]>
mangix: that's not helpful. Why would we merge that change if it breaks the MAC address?
<rsalvaterra>
mangix: Speaking of which, I stole your Mediatek PHY and MT7530 interrupt patches. Working fine on my Redmi AC2100. What triggers those interrupts, anyway?
<stintel>
there's a reason there's no gcc package in core, it's just not the way we do things
<will[m]>
it sounds like the real answer is, set up your laptop or VM to be kinda sorta like a linux router, develop there, then build it as an IPK when you think it has a chance of not segfaulting
<champtar>
yes
<stintel>
why would you need to setup your laptop or vm like a router ?
<will[m]>
because netlink firstly isn't installed on my laptop, and secondly won't behave like a router when i ask it questions unless it actually kinda is a router
<stintel>
just use buildroot
<will[m]>
so, again, "just" compile and build an IPK, scp it to openwrt, opkg install it, and then run, every time i change the code
<stintel>
setup buildroot, takes a while initially because needs to compile toolchain and all but once that is done, building a small package will take few minutes, scp command will be in your history so you can ctrl-r it
<will[m]>
yeah ok
<will[m]>
y'all are insane but at least that's the answer
<will[m]>
i get irritated having to ctrl-shift-R refresh webpages when i'm doing webdev, your fortitude at enduring all that, while developing in C, is impressive
<lemoer>
will[m]: besides the initial toolchain build, there is a script for automating the rest
<champtar>
(the ADD_DEFINITIONS should not have -Os -ggdb)
<stintel>
will[m]: well I'm sorry you don't like the way we do things since forever, either you suck it up and accept it, or find a better way, document it, send patches, yadi yadi
<mangix>
rsalvaterra dunno. Just took those patches from deng’s tree
<mangix>
aparcar[m]: ignore it for now. Did you test layerscape?
<rsalvaterra>
mangix: Fair enough. :)
<will[m]>
hmmmmm that script makes it much less awful-looking thanks lemoer
<will[m]>
stintel: lemoer has found a better way
<stintel>
great, now you can stop insulting people
<lemoer>
actually if there is interest, we could upstream this to openwrt :)
<will[m]>
now i just need a laptop with 50gb of free space so i can actually run a buildroot without dying
<lemoer>
you can try out the openwrt sdk
<lemoer>
(depending on what you are trying to to)
<lemoer>
if you only want to build packages, this should work for you
<will[m]>
that'll work for this yeah, i had to go with cloud builds for images for the rest