danitool has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
t4h4[m] has quit [Server closed connection]
t4h4[m] has joined #openwrt-devel
<russell-->
another weirdness, i just installed a vanilla build on a tp-link eap225-outdoor-v3, it comes up with eth0 in br-lan with the expected 192.168.1.1 address, i can reach it over ethernet, ssh in, modify the config so that eth0 is the device for wan, proto dhcp, it never comes up. i can connect from wifi, eth0 has no address, running udhcpcd manually doesn't help, i configure an address manually, ip
<russell-->
shows a configured interface, up, etc. but not can ping
<jow>
managed to make the new release actually smaller than the old one, despite the added features
<jow>
will prepare a package bump for openwrt, but I am unsure if I'll bump it in 22.03 since the ABI will change
<jow>
probably not before 22.03.1
<aparcar[m]>
Do you have a fuzzer for it?
<aparcar[m]>
We could add it to google fuzz
<jow>
fuzzing no but quite comprehensive test coverage thanks to ynezz
<jow>
clang analyzer and address sanitizer catched quite some issues in the past already
<jow>
most bug fixes these days are logic ones
<jow>
hm, do we have an example package using a Git tag somewhere?
<russell-->
svanheule: i tried reconfiguring again, power cycled, normal dhcp client resolution failed (no address on WAN interface), but manual udhcpc -i eth0 succeeded. whatever that means.
<Piraty>
any prediction when 22.03 will be tagged ? since i'll have a timeframe for some updates this weekend, and i don't feel like flashing 21.02 if 22.03 is near
<ynezz>
Piraty: soon (tm) :)
<Piraty>
classic
<Piraty>
"Sysupgrade from 19.07 to 22.03 is not supported. " yay, i'm on 18.06 :D
<aparcar[m]>
Piraty: looks like your weekend just got booked
<aparcar[m]>
ynezz: thanks I'll check out the fuzz
<Piraty>
and the one right after 22.03 i guess
<aparcar[m]>
ynezz: what made you use cram btw? it looks like nobody touched the code in a while and then there is this fork which got renamed and all
<ynezz>
aparcar[m]: simplicity, stability, easy of use
<ynezz>
it's feature complete, it works, so why to touch it?
<aparcar[m]>
i.e. because it no longer uploaded to pypi
<aparcar[m]>
anyway I'll give it another look
<aparcar[m]>
we could use cram for lava testing too, I guess
<ynezz>
it shouldn't be relevant how do you bringup the DUT in order to use the tests
<aparcar[m]>
jep
<ynezz>
interactive mode is nice as well, since you can update the tests automagically
<aparcar[m]>
that's what I thought
<ynezz>
or you could just download the new test output available in test.t.err and thus update the tests without much work
<aparcar[m]>
I can give tests remote repos so it can be continuously updated without touching the lava setup
<ynezz>
don't forget about that rule, the more layers you add, the more pain you're going to suffer in long term, during maintenance :)
<aparcar[m]>
currently I'm dealing with raspbian and debian raspi images since there is no lava support for openwrt (yet), you don't need to explain me what suffering means
<ynezz>
hm, what does it mean, that lava has no openwrt support?
<aparcar[m]>
the lava-worker does not run on openwrt at this point
rsalvaterra has quit [Server closed connection]
rsalvaterra has joined #openwrt-devel
<aparcar[m]>
they hard import i.e. guestfs (libguestfs) which isn't ported to openwrt. guestfs is afaik only relevant for qemu setups which we unlikely ever run on openwrt anyway
<Piraty>
hmm, reflashing factory would be a nice chance to set up extroot finally
<ynezz>
hm, do you really want to run anything on the DUT itself? I mean, this can already influence the test results
<aparcar[m]>
no, but you need a controller
<aparcar[m]>
my plan would be to have lava.openwrt.org and everyone intersted sets up a worker at home and provides some devices to a distributed testbed
<aparcar[m]>
those workers are currently based on debian
<aparcar[m]>
ideally it's just a openwrt image with lava-dispatcher-lite installed
<aparcar[m]>
off for lunch
robimarko_ has joined #openwrt-devel
<f00b4r0>
jow: purely FYI I kept digging on the wild goose chase for the DSA mt7530 throughput issue, and I'm down to a point where the 5.10 version of the driver is now nearly identical to the 5.15 "working" version, prompting me to suspect a more generic code bug
robimarko has quit [Ping timeout: 480 seconds]
<Piraty>
where can i find the kconfig files leading to the release builds of my device ?
<jow>
now there's a ton of features which are all broken :)
<f00b4r0>
^
<stintel>
submodules suck hard anyway :)
<robimarko_>
Well, that is what backporting selectively gets you
<jow>
yeah, but aggresively updating everything loses you working support for existing platforms
<jow>
there'S arguments for either way
<robimarko_>
And that brings us around to the issue of platforms newer getting upstreamed
<jow>
maybe the "single kernel for all targets" strategy should be revisisted
<robimarko_>
I dont see how that will help
<jow>
apparently bleeding edge architectures like qca/mt76 force too much stress onto the rest of the ecosystem due to their need for relatively new kernels
<jow>
and associated tooling
<jow>
even if everything is perfectly ported forward you still loose a bunch of devices with every iteration due to overall bloat increase
<jow>
and - thats probably just a personal feeling - we're now even regressing with basic things like ethernet connectivity
<aparcar[m]>
jow: you want to support more kernel versions at the same time?
<jow>
aparcar[m]: no, I want to give the codebase time to settle and mature
<robimarko_>
But how?
<jow>
currently we're adding/losing features faster than we can fix or test them
<jow>
robimarko_: maybe there should be a bleeding edge openwrt and stable openwrt which focuses on keeping (or even making) the stuff working we have so far
<robimarko_>
jow: That sounds good to me
<robimarko_>
I personally hate adding new stuff to OpenWrt currently, for example I upstreamed ton of IPQ807x stuff
<robimarko_>
To 5.18+
<robimarko_>
And now I gotta do that twice as all of that needs to be modified to run on 5.15
<jow>
right now the desire to support "bleeding edge targets" (as in devices requiring relatively new kernels) and to maintain "legacy targets" (as in resource constrained) introduces conflicting goals into opposite directions
<jow>
robimarko_: that's what I mean; while people struggle to go to 5.15 you already eye 5.18 because that's where all the things are happen now
<jow>
and by the time openwrt is ready to adopt 5.18, you look at 5.22 because that's where all the fixes go
* f00b4r0
realizes he's been testing kernels that don't include some of the latest patches he dropped into generic/backport-5.10, curses build system ;P
<robimarko_>
jow: Yes, exactly
<jow>
in the meanwhile we lost another few dozen devices, ethernet is quirky, flow offloading broken, qos stopped working properly 6 months ago
<jow>
(intentionally exagerating here a bit, but I guess the point is clear)
<robimarko_>
Its clear, but how would anybody solve that?
<aparcar[m]>
jow: can't you cut down your $dayjob a bit and become a proper release manager? I heard other distro do have that, too
<robimarko_>
We have some really exotic targets that will never get upstream
<jow>
aparcar[m]: no
<aparcar[m]>
we can pay... 10k at least 😛
<jow>
robimarko_: I see a "passive" and an "active" solution
<jow>
passive would be "don't touch once it's working", kinda like debian or maybe even the dd-wrt approach
<jow>
active would be "always update, do serious regression testing and fixing work"
<jow>
for the latter we lack the resources
<robimarko_>
Debian and DD-Wrt are exactly the thing I dont want to use
<jow>
I know, me neither
<jow>
and I don't want to imply that these are good role models
* Piraty
grabs popcorn
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
<robimarko_>
jow: to be honest, we kind of lack resources for most things
<f00b4r0>
jow: could it be that our current release schedule is a bit too aggressive for the resources (manpower) we have?
<robimarko_>
Well, I mean its one release per year usually
<robimarko_>
Dont see how it can be too agressive
<f00b4r0>
with as many devices/targets, that's already quite aggressive imho. As we're seeing right now.
<robimarko_>
To me it seems a lot of people including me dont care about the "stable" releases at all
<f00b4r0>
you're a power user
<robimarko_>
I meant developers
<f00b4r0>
i bet you don't care about stable distro releases either
<f00b4r0>
ah
<robimarko_>
Kind of, that is why I roll Fedora
<f00b4r0>
heh
<f00b4r0>
I only use stable releases (distro and openwrt) and I certainly care about them
<aparcar[m]>
I guess companies like stable
<f00b4r0>
and that too
<robimarko_>
And that is another issue
<f00b4r0>
you can't build a product out of master, that's a non-starter.
<robimarko_>
They like "stable" but arent really willing to support that
<robimarko_>
Only use it
<f00b4r0>
depends
<robimarko_>
I know only of Turris that send stuff upstream for stable releases
<takimata>
jow: listening to you speak, I can't help but wonder if yesterday's MT76/DSCP marker heisenbug could also be rooted in DSA, not in the MT76 driver?
<f00b4r0>
you're looking at hw manufacturers. There's a larger ecosystem around openwrt
<robimarko_>
f00b4r0: Yeah, but what do they contribute back?
<robimarko_>
What is benefit for OpenWrt that QCA or MTK base their SDK off OpenWrt?
<f00b4r0>
robimarko_: I can disclose that the work I'm currently doing on bridge-vlans and trying to hunt the mt7530 DSA bug is sponsored.
<f00b4r0>
sadly I'm out of depth, so it's probably not that efficient :P
<robimarko_>
And that is great
<robimarko_>
But its not like that is so abundant
<f00b4r0>
and i'm not working for a hw manufacturer, which is why i was mentioning the larger ecosystem :)
<jow>
even for non-stable releases we lack sufficient capabilities
<jow>
like the sloppy packaging situation (outdated kmods, broken package manager, uninstallable packages after a few days/weeks, hard or soft bricks on updates, ...)
<f00b4r0>
yeah that would never fly
srslypascal is now known as Guest465
srslypascal has joined #openwrt-devel
<robimarko_>
My point is that current status is not good for anybody
<jow>
it's the tradeoff making all sides equally unhappy
<aparcar[m]>
should we work more with alpine? they have a big ecosystem and already use openssl
<f00b4r0>
on a personal, hobbyist level, i certainly appreciate that openwrt helps prevent further electronic landfill by allowing me to keep using old(er) devices. As a pro-bono contributors that certainly motivates me
<aparcar[m]>
*package eco system
<f00b4r0>
-s
<jow>
aparcar[m]: the bottleneck is the kernel level work
<robimarko_>
f00b4r0: yeah, that is great
<aparcar[m]>
automated device testing plus ci?
<jow>
alpine can't help with dsa, wifi drivers, hostapd quirks, ...
<Piraty>
also, (current) apk is meh
<robimarko_>
jow: nothing except more humans can help that
<jow>
exactly
<aparcar[m]>
let's make the website nicer and attract more people?
<f00b4r0>
;)
<jow>
and the "join us, if you do good work you might not get yelled at" approach only goes so far
<f00b4r0>
heh
<robimarko_>
I would actually say that there is a rather good amount of people trying to contribute
<jow>
yes, contribution could be easier
<jow>
but sometimes hard things are hard
<robimarko_>
But the issue is reviews
<robimarko_>
We have around 300 PR-s, most have not been even looked at
<f00b4r0>
in truth the kernel has gotten very complex over the years. It's (imho) extremely hard now to contribute across the board when you don't know the code inside out. I can feel the gap after having been on a contribution hiatus of 10+ years
<jow>
robimarko_: I usually look at random PRs and they often have issues, they're almost never merge-ready
<robimarko_>
jow: its like that pretty much anywhere
<robimarko_>
Just look at the kernel
<robimarko_>
It takes revision after revision for anything
<jow>
right, and because such non-good PRs aren't quickly merged, people complain that the barrier to entry is too high
Guest465 has quit [Ping timeout: 480 seconds]
<jow>
anyhow, that's all been discussed in the past already. The only way forward without increasing manpower would be to decrease the scope
<robimarko_>
Maybe its just me, but I really like when I get a review that its good or to change something
<jow>
maybe some increased automatism
<f00b4r0>
jow: incidentally that's exactly what happened in Debian
<f00b4r0>
years ago
<f00b4r0>
they second-citizend all exotic archs
<jow>
robimarko_: I recall some github issues that quickly escalated because you demanded changes to a "simple one line PR that takes you onyl a minute to do"
<robimarko_>
jow: Oh yeah
<robimarko_>
To those I have no explanation, my idea is that kind of time to get some kind of a review should be shorter
<robimarko_>
Those that refuse to change things after are a special kind
<jow>
more CI bot stuff can help to at least straighten out the formalities
<f00b4r0>
yeah. And there will always be some like that
<jow>
maybe loosen requirements (users refuses S-o-b with realname, committer does S-o-b and adds Suggested-by of original author, original author agrees to that through contribution guidelines)
<robimarko_>
Personally, I am not for it
<jow>
in LuCI there's a lot of onew, two line drive-by PRs with cannot be merged due to S-o-b
<jow>
the kind of PRs made with the github web editor
<robimarko_>
Those kinds are 90%+ of issues
<robimarko_>
Github just gave a loaded gun with the stupid web editor
<jow>
whenever I see a PR these days with a source branch name of "patch-1", I skip over it right away
<PaulFertser>
If you're not worried of accidentally pulling in copyrighted incompatible material then you can avoid requiring S-o-b altogether.
<f00b4r0>
that's exactly my concern
<f00b4r0>
I fear it may promote bad copyright behaviour (code steal / copy pasta from someone else with no crediting)
<jow>
exactly
<f00b4r0>
and it may lead to unupstreamable contributions
<PaulFertser>
Because S-o-b gives you plausible denial, if someone complains you just revert the edit and blame the S-o-b person.
<jow>
and enforcing higher standards means "project is not nice to contributors"
<jow>
they constantly bitch about technicalities and take months to years to merge one line fixes that took 30s to make
<robimarko_>
Without these standards, we would be back to patches without a name and descriptions
<PaulFertser>
So the committer wouldn't be adding S-o-b because it'd be impossible to verify if the original contribution is legit.
<f00b4r0>
well I guess a line must be drawn somewhere. Are there often "anonymous" contributions of acceptable quality that the contributor refuses to disclose their ID?
<robimarko_>
Dont thinks so, at least not for the main repo
<jow>
f00b4r0: not only refuse, often also incapable to do
<f00b4r0>
but are their contributions even relevant then?
<jow>
because, lack of git skills, lack of Github web facility to do
<jow>
forcing maintainers to redo the changes on their behalf
<jow>
exponentiate the effort
<jow>
submitter did 30s job in web editor to open PR
<jow>
maintainers require 5 minutes to spot, explain the problems
<jow>
PR is idle for months
<robimarko_>
I dont see a way around it
<jow>
maintainer deems change too worthwhile to be forgotten and redos it by himself, spending another 10 minutes
<jow>
contributor is unhappy
<f00b4r0>
jow: I see your point, but I think these aren't the type of contributors we should be attracting anyway. Because they will only degrade the overall quality of the project if they can't cope with basic housekeeping
<PaulFertser>
Probably an exception can be made for few lines drive-by contributions then. A maintainer would assume that it's unlikely any copyright owner will appear and complain.
Misanthropos has quit [Ping timeout: 480 seconds]
<f00b4r0>
PaulFertser: imho if no SoB and no real ID, there's no copyright anyway. IANAL though.
<jow>
f00b4r0: true, but these are the contributors that shape a public perception of the project as elitist cabal refusing outside contributions
<f00b4r0>
ah, i see
<jow>
discouraging others
<robimarko_>
How can we get around that?
<PaulFertser>
f00b4r0: you can't shift the blame in that case. The material might be copyrighted but the anonymous person isn't telling you, and isn't assuming the responsibility.
<robimarko_>
If they dont put titles and description
<f00b4r0>
personally I find the openwrt community rather nice and welcoming. And I've been a DD for 15 years, and a kernel contributors for almost as long :)
<robimarko_>
I am afraid to even think of the git history after that
<f00b4r0>
PaulFertser: sure, I was reasoning on 1-2 lines drive bys
csharper2005 has quit [Remote host closed the connection]
<jow>
I guess in the end you do need paid maintainers
<jow>
because some grunt work simply isn't rewarding enough to do on a voluntary basis for long
<robimarko_>
Kernel barely has any full time people
<jow>
documenation, managing etc.
<robimarko_>
AFAIK, we can barely afford buildbots as it is
<jow>
we're not good at PR and fundraising :)
<f00b4r0>
heh
<jow>
and we lack the organizational structure to make good use of them, even if we would have funds
<robimarko_>
It all kind of stems from that those that utilize OpenWrt the most dont really return that
<jow>
exactly
<robimarko_>
All of those vendor SDK-s
<jow>
one idea might be sponsored releases
<jow>
or sponsored features
<jow>
but it would need to be transparent and fair
<jow>
another idea might be licensing, but that likely would just lead to forks
<f00b4r0>
do we know what prevents vendors from using stock openwrt (possibly with their own gui branding)?
<jow>
f00b4r0: one anecdote I heard was regressions
<f00b4r0>
*sigh*
<jow>
like, simply updating the kenrel leading to throughput regressions
<f00b4r0>
yeah clearly that doesn't bode well
<jow>
not acceptable in a commercial setting with long term contracts
<f00b4r0>
my idea obviously being that if we can make it easier for vendors to use stock, then they might be more likely to sponsor
<stintel>
they rather have their clients vulnerable like crazy than lose 1% of performance!
<jow>
there's probably others (ip protection, not well formalized ways to interact with foss development organizations, ...)
<jow>
also I think vendors often involve upstream far too late in the development cycle
<jow>
they already went ahead creating a non-upstreamable software architecture
<robimarko_>
To me it seems that they use their kernels anyway
<jow>
thne when trying to upstream, are faced with the prospect of redoing it all over
<jow>
for only hypothetical commercial benefit
<jow>
also making own changes to the kernel in a way that those play nice with other existing targets is harder than just trampling all over the code base, hacking in the required bits
<jow>
a define here, an hardcoded assumption there, ...
<jow>
and the usual lack of in-depth architectural documentation does not help either
<jow>
so tl;dr you need good personell
<jow>
and that is hard/expensive to come by
<robimarko_>
jow: they will just do whatever takes least money and time
<jow>
and you need to keep it attrtacted
<robimarko_>
So basically, fork one of the LTS releases
<robimarko_>
Keep pilling on your non-upstremable sh*t
<jow>
exactly
<jow>
you're not going to update the kernel anyway
<jow>
because it's going to be bigger, slower
<jow>
and 4 years down the road the product is obsolete anyway
<robimarko_>
And maybe, just maybe they will update the OpoenWrt base used just for the userspace
<robimarko_>
Or not care at all and ship CC in 2022
<jow>
that is the approach of achieving stable software by freezing it
<robimarko_>
Those that use OpenWrt with its kernel are really rare vendors
<robimarko_>
So its really, really niche market
<robimarko_>
jow: That is why I hate the concept of calling SW stable
<robimarko_>
Cause they usually mean, never, ever update it
<jow>
and by us being such a fast moving target, there's even less incentivation for vendors to adopt newer openwrt releases
Tapper has joined #openwrt-devel
<jow>
because by the time they're done with their integration work, we discontinued support
<jow>
I could imagine that justa modenr openwert userland on top of an older/proprietary kernel could already be beneficial to vendors
<jow>
*openwrt
<jow>
but it's hard to do within our current build environment
<robimarko_>
Its impossible to do for any project
<robimarko_>
Cause, modifications that they do are so intrusive
<robimarko_>
And totaly ignorant of the rest of the worl
<robimarko_>
*world
<jow>
exactly
<robimarko_>
So, OpenWrt-s once a year release is always gonna be too fast
<robimarko_>
Any release schedule will be too fast
<f00b4r0>
not sure about the generalization there :)
<jow>
vendors aside, it's primarily too fast for us right now
<jow>
look at thel ong stabilization phase
<robimarko_>
f00b4r0: the sad thing is that its true
<robimarko_>
Outside of Turris, do yo know of a vendor using anything else than the "vendor BSP" SDK
<ynezz>
8devices?
<f00b4r0>
robimarko_: well sure, but we haven't really offered a longer release cycle for vendors to try either
<f00b4r0>
and as jow explained, I can see them being put off by the current one
<f00b4r0>
heck, even *I* am being put off by it ;P
<f00b4r0>
Florian's email earlier this week imho made sense in that context, but look how he's been completely dismissed as well
<robimarko_>
ynezz: Well, 8devices stopped doing that
<robimarko_>
They are using OpenWrt+vendor kernel and packages for newer boards
<robimarko_>
f00b4r0: How can we offer those if there is nobody to actually do it?
<ynezz>
robimarko_: ah, bummer
<robimarko_>
They only used if to platforms where everything was already done, so it was just a matter of adding a board
<Piraty>
if i flash 22.03-r6 , is that planned to be binary compatible with the final release?
<PaulFertser>
Piraty: kernel modules are not binary compatible between any releases.
<Piraty>
duh
<Piraty>
userland packages
<PaulFertser>
Piraty: so if you need to sysupgrade anyway, you upgrade all the userspace as well.
<jow>
PaulFertser: userland should be mostly finished
<jow>
there'll be updates to fw4 at least
<jow>
maybe the odd bugfix update here or there
<jow>
but no breaking bumps
<Piraty>
`opkg upgrade` will (very probably) work then?
<jow>
if you can affort the space waste
<Piraty>
will do extroot this time
<jow>
s/PaulFertser/Piraty/
<Piraty>
i figured ;)
<f00b4r0>
dear lord i read much more dsa code than I ever wanted to and I still can't figure out what's happening :/
danitool has joined #openwrt-devel
<robimarko_>
f00b4r0: Have you maybe looked at using Buildroot to roll mainline and see if its broken there
<f00b4r0>
robimarko_: didn't need to: it's not broken in the testing kernel (5.15)
<f00b4r0>
I've been poring at the differences to no avail
<f00b4r0>
i'm left with two major API rework that simply seem too daunting to backport
<f00b4r0>
(plus a myriad of other more or less related changes that make diff'ing even more complex)
<f00b4r0>
i think i'm going to stop now and look again next week with a cleaner mind. I have a suspicion about the implications of one of the two major changes which rework port setup and thus could play a role, but the change is extremely invasive. *sigh*
Misanthropos has joined #openwrt-devel
xback has quit [Ping timeout: 480 seconds]
<robimarko_>
Ok, that makes it only a bit easier
* f00b4r0
curses. Stupid Apple Mail client always wants to send RTF even tho I checked "reply in same format as sender" and it always bites me
nixuser has quit [Server closed connection]
nixuser has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<f00b4r0>
wow I completely missed #10238. Might be worth a shot
fpsusername[m] has quit [Server closed connection]
fpsusername[m] has joined #openwrt-devel
<f00b4r0>
i wish there was a way to automatically subscribe to PRs matching certain keywords
<takimata>
super stupid question: should include/target.mk not also include "odhcp6c" for DEFAULT_PACKAGES.nas ?
<takimata>
I was wondering why my MBL on 21.02.0-rc6 would not get an ipv6 address, until I saw odhcpc is not installed.
<takimata>
(I would even be willing to argue that odhcp6c belongs into DEFAULT_PACKAGES, not just into DEFAULT_PACKAGES.router)
<takimata>
(given that the default network config comes with a lan6 interface, proto dhcpv6, which then fails out of the box)
noltari has quit [Quit: Bye ~ Happy Hacking!]
<jow>
takimata: yes, I'd say if we make a device class using DHCP(v4) by default it should also do DHCPv6
karlp has quit [Quit: one more time.]
<takimata>
so if the "nas" device class uses it by default on lan, and the "router" device class uses it by default on wan ... it should go into default_packages because both need it? :)
<jow>
seems like a valid conclusion to me
<takimata>
yay, I'm useful.
<jow>
DHCP client functionality seems essential
<jow>
for gadgets anyway
<jow>
and for routers to obtain wan connectivity
noltari has joined #openwrt-devel
<takimata>
should I open an issue? or is there a "kurzer amtsweg"?
noltari has quit [Read error: Connection reset by peer]
karlp has joined #openwrt-devel
<jow>
der korrekte dienstweg ist einzuhalten. ohne gültige papiere können wir gar nichts machen
noltari has joined #openwrt-devel
* takimata
löst den passierschein A38.
<takimata>
(creating issue.)
<zorun>
proto dhcpv6 on lan6? so it's acting as a DHCP client on the LAN? that sounds weird
<jow>
zorun: for nas devices, those do default to dhcp on lan
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<takimata>
jftr: they already *try* to do dhcpv6, but missing odhcpc they fail. i.e., they ship with a broken default network config because of it.
<takimata>
(only slightly broken, but still.)
Piraty_ has joined #openwrt-devel
Piraty has quit [Remote host closed the connection]
<schmars[m]>
how can i get the sdk to build libuci, so my custom version of poemgr finds uci.h?
<schmars[m]>
okay it's smart to not just do scripts/feeds update, but also install
goliath has quit [Quit: SIGSEGV]
<philipp64>
trying to pull dangole's staging branch from git.openwrt.org ... Is this repo accessible via dialup? Because that's the sort of speed I'm seeing...
goliath has joined #openwrt-devel
schwicht has quit [Remote host closed the connection]