gromero has quit [Remote host closed the connection]
hbug has joined #openwrt-devel
hbug___ has quit [Ping timeout: 268 seconds]
victhor has quit [Ping timeout: 265 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Darkmatter66 has quit [Ping timeout: 264 seconds]
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 256 seconds]
valku has joined #openwrt-devel
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
lukedashjr has joined #openwrt-devel
luke-jr has quit [Ping timeout: 264 seconds]
lukedashjr is now known as luke-jr
daregap has joined #openwrt-devel
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
valku has quit [Quit: valku]
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
goliath has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 264 seconds]
muhaha has joined #openwrt-devel
ivanich has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
<ynezz>
Pepe: or just send me an email
<ynezz>
or /msg ynezz wiki username/email
Tost has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
Borromini has joined #openwrt-devel
goliath has quit [Ping timeout: 256 seconds]
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
goliath has joined #openwrt-devel
Night-Shade has quit [Read error: Connection reset by peer]
feriman has joined #openwrt-devel
<Namidairo>
rsalvaterra: it's supposed to be probed, and the amount of ram looks correct here on mine at r15253
<rsalvaterra>
Not at r15642, though… :/
feriman has quit [Quit: WeeChat 3.0]
<Borromini>
rsalvaterra: i'm seeing ram correctly detected on my R6800 (256 MiB) and DIR-878 A1 (128 MiB)
<Borromini>
with r15661
<Namidairo>
now I'm starting to wonder whether I actually flashed an image 2 days ago or it just rebooted and didn't sysupgrade
<rsalvaterra>
Namidairo: I see that all the time. Sometimes it takes three, four, five tries(!!), until it flashes.
<rsalvaterra>
But I'm sure it's a completely unrelated issue, since I see this on every devices I have.
<rsalvaterra>
*device
<Namidairo>
whelp
<Namidairo>
serves me right for not checking uname after I guess
<rsalvaterra>
I always check the version after sysupgrading, to be sure. ;)
<rsalvaterra>
Namidairo: you also have a Redmi RM2100, right?
<Namidairo>
...yes
<rsalvaterra>
Of course, we could just say it's a feature and tell everybody to replace their RAM chips… :P
<Namidairo>
they do mix and match parts on there
<rsalvaterra>
Yeah, I remember reading somewhere about the possibility of extending the RAM to 512 MiB by replacing the chip, but I'm not going there… not in the near future, at least.
<rsalvaterra>
128 MiB should be enough for anybody.
danitool has joined #openwrt-devel
<Borromini>
rsalvaterra: that much tries for a device with relatively high ram? that's weird.
<Borromini>
Namidairo: i have a small script that does nothing but pull openwrt versions off all the devices in the house here, to make sure the upgrade actually happened
<rsalvaterra>
Borromini: tell me about it. I see this on my Omnia, with 2 GiB.
<Borromini>
eh :-/
<Borromini>
rsalvaterra: i kill the wireless before i sysupgrade (wrapper script)
<rsalvaterra>
I usually kill Tor, but mostly out of faith. In practice, doesn't seem to help.
<Borromini>
that used to be one of the reasons why devices wouldn't sysupgrade
<rsalvaterra>
(Tor takes about 25 Mb of RAM, it's the heaviest process I run.)
<rsalvaterra>
*MB
Darkmatter66 has joined #openwrt-devel
<mangix>
rsalvaterra: insert joke about downloading more RAM
<mangix>
on an unrelated note, gcc's -fanalyzer takes a lot of RAM
<rsalvaterra>
Ah, the new static analyser thingy?
<mangix>
fedora was killing firefox tabs while running make -j 12
<mangix>
yeah
<Namidairo>
at least you have 12 threads
<mangix>
says who?
<mangix>
j parameter should be 1.5x your threads
<rsalvaterra>
Uhh… all suggestions I've read say that it should be your number of logical CPUs + 1…
<mangix>
that works out when CPUs = 2
<Borromini>
mangix: people seemed to recommend j+1 for a long time
<Borromini>
i'm on j now again.
<Borromini>
so apparently opinion widely varies
<rsalvaterra>
Yeah, 1.5x means you're expecting 50 % of your threads to be blocked at any given time, no?
<Borromini>
rsalvaterra: do you feel like running through the git log or bisecting for your regression?
* Borromini
is just curious
<rsalvaterra>
Borromini: I… would like to avoid it… cheap NAND flash and all…
<Borromini>
ok
<rsalvaterra>
One of my units was DoA, with a bad flash chip…
<rsalvaterra>
… I'd rather not push my luck. :P
<Namidairo>
they're actually shipping units with bad blocks
<Namidairo>
and it's hilarious
snh has quit [Read error: Connection reset by peer]
<Borromini>
:-/
<rsalvaterra>
Namidairo: a couple of bad blocks is to be expected on NAND.
<rsalvaterra>
This unit had basically every second block damaged.
<Namidairo>
I never checked if my bad block table was populated
snh has joined #openwrt-devel
<Borromini>
openwrt uses ubifs no for nand? or does that depend on the device
<Namidairo>
if the flash is non-poop it "just works"
<mangix>
rsalvaterra: how difficult is it to solder ona new one?
<rsalvaterra>
[ 3.326058] Bad eraseblock 768 at 0x000006000000
<mangix>
oh this is nand
<mangix>
nvm
<mangix>
NOR is easy. just 8 pins
<Borromini>
i saw stuff on the ML about mikrotik handling nand... doesn't inspire confidence
<rsalvaterra>
NAND isn't terrible too, with the proper equipment and experience, which I don't have. :P
<mangix>
uhhhh, NAND is BGA
<mangix>
or am I confusing it with emmc?
<rsalvaterra>
mangix: I think this one is TSOP48.
<karlp>
bga is just packaging,
<karlp>
nand can come in whatever.
<mangix>
32 pins
<mangix>
that's more than 8
victhor has joined #openwrt-devel
<rsalvaterra>
mangix: 48 pins. :P
<karlp>
you can get spi nand in 8pin too, for more fun
<mangix>
rsalvaterra: that's several orders of magnitude harder :)
<mangix>
wait a minute....
<mangix>
that should be doable with flux, which i don't have
<rsalvaterra>
mangix: And remember, I need to dump the NAND of a working unit, change a couple of bytes at a specific offset (the MAC address) and flash the new chip with it. :P
<mangix>
i assume no usb boot :)
<Namidairo>
no usb port :)
<rsalvaterra>
mangix: what USB? :P
<Namidairo>
i think mt7621 needs a preloader anyway
<mangix>
i remember owning a pogoplug 4. had USB, SD, SATA, and NAND boot
<rsalvaterra>
So, aside from desoldering the chip of a working router and dumping it, my only option would be to dump the flash through the serial port.
<mangix>
gold standard
<rsalvaterra>
Which means dumping 128 MiB at 115200 bps.
<Namidairo>
most of the large partitions on there you can skip anyway
<Namidairo>
you'd just need uboot, factory, and uhh
<rsalvaterra>
Namidairo: That's my hope, yes.
<mangix>
NOR is still easier :)
<rsalvaterra>
mangix: sure, just clip it and go. :P
<mangix>
I remember several years back bricking my dad's desktop during a BIOS update. I was lucky the chip was removable...
<Namidairo>
some of the boards have unpopulated spi
<Namidairo>
and you just solder one on and pull down the right pin
<mangix>
wonder if asrock still makes motherboards with removable flash chips...
<Namidairo>
i think most just end up with two now
<danitool>
there's also a clip for TSOP NAND flash chips used with a teensy microcrontroller to read/write
<rsalvaterra>
I have a board which downloads and updates the firmware. From the UEFI setup itself, which is downright terrifying (for me, at least).
<mangix>
rsalvaterra: that's where it bricked :)
<danitool>
that's what Playstation crackers use
<rsalvaterra>
mangix: before making it easy to update, they probably should have made it reliable. :P
<rsalvaterra>
But firmware is usually written by hardware engineers… and we all know the only worse thing than a software engineer with a soldering iron is a hardware engineer with a compiler.
<mangix>
rsalvaterra: I thought about that actually. their definition of reliable is running the SPI bus at the slowest possible speed
<rsalvaterra>
mangix: I used to burn CDs at the lowest possible speed for reliability… :P
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
<mangix>
i don't think the two are equivalent
<rsalvaterra>
I'm pretty sure they aren't. ;)
<mangix>
anyway, my 16MB archer c7v2 flashes the firmware faster than my 16MB motherboard
<Borromini>
:P
<Borromini>
yeah it's crazy how dog slow a modern x86 is in that regard
<rsalvaterra>
Wait, 16 MiB of UEFI…? O_o
<stintel>
my Power8 box does Quad SPI it's pretty fast :)
<mangix>
rsalvaterra: oh the latest stuff uses 32MB flash chips
* rsalvaterra
misses 256 kiB BIOSes…
<mangix>
there was controversy around it
<Namidairo>
gotta cram the microcode in it too
<mangix>
AMD killed support for older chipsets because of those flash chips
<Namidairo>
or cpu support or whatever
<mangix>
not big enough
<Namidairo>
yeah x450 had too small ones apparently
<Namidairo>
then they finally went "fine we'll put some out where we drop the old cpu support so we can fit the new one in"
<mangix>
yep
<rsalvaterra>
stintel: Yeah, but large firmware on POWER doesn't scare me. x86, on the other hand, has this atrocious thing called SMM…
<rsalvaterra>
… God knows what the firmware could be doing at runtime.
<stintel>
:P
<rsalvaterra>
Can't wait to move to something saner… ARM64 seems to be the most obvious candidate, at the moment. POWER is still too expensive…
<rsalvaterra>
stintel: are you doing OpenWrt builds on POWER? :)
<mangix>
rsalvaterra: I've compiled openwrt on an mvebu device. AMA.
<stintel>
rsalvaterra: I did
<rsalvaterra>
mangix: wait, that's illegal. :P
<Namidairo>
how many weeks did it take
<mangix>
how so?
<stintel>
rsalvaterra: even had a buildslave on it at some point, but the problem was something with the SDK
<mangix>
Namidairo: I just left it overnight. It's so slow.
<stintel>
stage 2 uses SDK, stage 1 builds SDK and uploads is, so there was a PPC64 SDK in an x86_64 tarbal name :P
<stintel>
and that didn't really work very well :P
<rsalvaterra>
mangix: well, with enough storage, RAM and free time…
<stintel>
or something like that, don't recall 100%
<stintel>
but build times were close'ish to my previous workstation, i7 3930k 6c/12t
<stintel>
the thing is also really noisy :P
<stintel>
and powerhungry
<rsalvaterra>
stintel: I think it's "only" really SMT4… SMT8 merges two physical cores, doesn't it?
<stintel>
rsalvaterra: dunno. it has 80 "CPUs" in /proc/cpuinfo
<ynezz>
did anyone compiled openwrt on apple m1 yet?
<rsalvaterra>
mangix: Ah, the Kobols, right.
<stintel>
I was looking to get a mac mini for trying a matrix imessages bridge so I can communicate with fanbois in their natural habitat
<stintel>
but 2 months wait so I didn't order 1
<rsalvaterra>
ynezz: still waiting for marcan and Corellium to upstream support for it. I won't be getting an M1 without full GPU support, though.
<mangix>
ynezz: why?
<ynezz>
seems to be fast arm
<Borromini>
yeah apple went all-out
<ynezz>
stintel: it seems like the tarball name for the sdk comes from SDK_NAME:=$(VERSION_DIST_SANITIZED)-sdk-$(if $(CONFIG_VERSION_FILENAMES),$(VERSION_NUMBER)-)$(BOARD)$(if $(SUBTARGET),-$(SUBTARGET))$(if $(GCCV),_gcc-$(GCCV))$(DIR_SUFFIX).$(HOST_OS)-$(HOST_ARCH)
<Borromini>
they had to. can't afford to replace x86 with something that performs *worse*
<ynezz>
stintel: perhaps that HOST_OS/ARCH needs some love?
<mangix>
seems homebrew doesn't have full support for m1
<stintel>
ynezz: maybe, but the box is mostly switched of, it's too noisy for having it on all the time :)
<ynezz>
make me wonder how power8 becomes x86_64 :p
<stintel>
maybe that was fixed afterwards
<Borromini>
anyone know by heart what to append to the LuCI URL in the browser to force it to clear the cache?
<karlp>
hrm, anyone know if there's a trick for packages that use submodules in git?
<Borromini>
shift+ctrl+r isn't helping and luci keeps throwing me back to the login page. private window does work.
<ynezz>
you need to delete cookie
<Borromini>
ok thanks
CrazyLemon has quit [Ping timeout: 260 seconds]
<stintel>
ynezz: 21|15:13:13< jow> stintel: I disabled your buildslave for now. Since it is a PPC host, it produces IB and SDK binaries unusable by x86 users
<ynezz>
ah, different issue
<stintel>
we might want to look into that though
<stintel>
as I predict a future where more !x86 will be used
<ynezz>
we should just not upload the results
<mangix>
karlp: elaborate
<stintel>
arm, riscv, power to a less extent
<stintel>
right, I still need to order that risc-v board
<karlp>
mangix: nvm, it didnt' seem to be doing the recursive submoudle checkout, but it is, some paths are busted.
<mangix>
while on that topic, several people sold theirs on the forums. first batch had some rough edges
<Borromini>
mangix: yeah. have kept an eye on it as well
<Borromini>
stintel: it sure does but quite its share of teething problems
<Borromini>
modern kernel still seems unstable etc.
<mangix>
karlp: submodules only work with PKG_SOURCE_PROTO:=git . does not work with codeload
<mangix>
Borromini: it's the rockchip platform. it's a disaster.
<mangix>
previous one was mvebu
<stintel>
Borromini: I see
<karlp>
mangix: yeah, I knew that, this is doing a git clone, and it has done the right thing, I'll figure out what paths I've got wrong
<Borromini>
mangix: yes, bad rep
<stintel>
Borromini: well I have a self-built thing anyway, silverstone cs381 with ASRock Rack E3C224D4I-14S, 8x SAS2 + 4x SATA3 + 2x SATA2 + extra Intel X550-T2 :)
<Borromini>
stintel: hahaha. here i am with my skylake celeron 'home server' xD
<stintel>
but I'm already considering replacing it with EPYC3451D4U-2L2T2O8R :P
<stintel>
as the current one is limited to 32GB :(
<mangix>
Borromini: it just needs a lot of development. there is a lot of stuff that has not made it upstream.
<mangix>
it's similar to sunxi actually...
<karlp>
I gave up on rockchip's fragmentation and supported/notsupproted and moved to sunxi personally
<mangix>
hmm? elaborate
* Borromini
only has exynos/odroid stuff
<Borromini>
very happy with that. lucky odroid-xu4 has armbian support now too, though.
<karlp>
rockchip has/had no support for even _slightly_ older stuff, the bootloader tooling was way harder to work with, and while rk employees seemed to be doing upstream work, it was only for very specific targets, other rk targes were completely sidelined.
<mangix>
unfortunate
<karlp>
it's hopefully gotten better, but sunxi has always felt more broadly complete, you're not going to get blindsided as much
<mangix>
I should start judging platform stability based on the number of out of tree patches
<karlp>
because of that, I haven't been following the dev of rk much for the last two yers or so.
<Borromini>
:P
<mangix>
moar patches = less stability
<karlp>
mangix: so, toss all ath79?
<karlp>
sunxi was almost zero :)
<Namidairo>
i think the helios64 blog posts on "what's broken on what kernel" says it all really
<Borromini>
Namidairo: yeah. at least they're acknowledging and working with rockchip it seems, but first batch = guinea pigs with that kind of stuff always
<Borromini>
i wouldn't mind such a form factor, very neat. but i have the space to just tuck away a regular atx box, so for now...
<mangix>
wonder if the smarter thing would have been to stick with mvebu...
<Borromini>
was helios4 mvebu?
<mangix>
yes
<Borromini>
oh. yeah.
<Borromini>
when you see espressobin etc i've wondered why they didn't use that too. rockchip was probably cheaper.
<mangix>
funny thing is, I have a helios 4 and a turris omnia. both mvebu, both 1.6ghz, both 38x
<Borromini>
:)
<mangix>
omnia is 385, helios is 388. just a product differentiation. the 388 has 4 sata ports. 385 has 1
<mangix>
the omnia has 0 because...
flokli has quit [Ping timeout: 240 seconds]
<Pepe>
That was not fair mangix. :) Turris Omnia has two minipcie slots and the third is minipcie/msata. You might add miniPCIe controller which adds 2 or 4 SATA ports (e.g. IOCREST Marvell 9215). Also, there are 2 USB 3 ports without using hub.
flokli has joined #openwrt-devel
<rsalvaterra>
Borromini: No, but I wouldn't mind… I'm entertaining the idea of making my own "cloud". :)
<Borromini>
:)
<Borromini>
with owncloud or another product?
<rsalvaterra>
nextCloud, most likely.
<rsalvaterra>
Or OpenMediaVault with nextCloud… I don't know, haven't explored the possibilities yet.
Tapper has quit [Ping timeout: 240 seconds]
Tapper has joined #openwrt-devel
<mangix>
Pepe: I'm well aware, but to add SATA to it would require a separate controller. The armada SoC comes with one AFAIK.
<mangix>
I do have a minipcie one actually. However it is limited by pcie speeds. The armada one connects through SERDES I think.
<mangix>
rsalvaterra: I run openmediavault on mine. AMA.
<rsalvaterra>
mangix: RAID level? Filesystem(s)?
<mangix>
btrfs. RAID 5. metadata RAID1c4
<rsalvaterra>
Hmm… btrfs still scares me a bit… the free space issues bit me really badly, years ago.
* rsalvaterra
is looking forward to bcachefs…
Tapper1 has joined #openwrt-devel
<mangix>
free space issues?
Tapper has quit [Ping timeout: 240 seconds]
Tapper1 has quit [Ping timeout: 240 seconds]
<mangix>
Interesting tidbit: the armada SoC has an XOR offload engine that speeds up RAID parity calculations. mdadm uses it. btrfs does not (neither does bcachefs). I brought it up on the btrfs mailing list. The head honcho loved the idea. I hope it gets implemented.
<mangix>
It basically requires switching kernel APIs
<rsalvaterra>
mangix: Yes. When you have your volume about 70 % full. When I used btrfs, I had problems with that, the system complaining I had no free space, when I still had quite a bit.
<Namidairo>
30% can be a lot in todays drives lol
csrf has joined #openwrt-devel
<rsalvaterra>
Namidairo: this was my Debian root partition, at the time. About 8 GB, iirc.
<Namidairo>
I wonder if synology used btrfs in their roots
feriman has joined #openwrt-devel
<mangix>
Sounds wrong. I have around 80% used currently. I get no such warnings.
<rsalvaterra>
mangix: I don't know how it is nowadays. I stopped using btrfs about 8 years ago.
<mangix>
Makes sense. That was the stone age.
<rsalvaterra>
:P
noltari_ has quit [Quit: Bye ~ Happy Hacking!]
<mangix>
The design of btrfs unfortunately made it take a long time to get a good degree of stability.
<mangix>
In 2021, it's usable.
<karlp>
fedora defaults to it now for new installs iirc
dedeckeh has quit [Quit: Connection closed]
<mangix>
karlp: red hat wants testers before they put it in RHEL.
noltari has joined #openwrt-devel
Acrisor has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
Acrisor has joined #openwrt-devel
<mangix>
stratis is... interesting. Guessing they are looking forward to deprecate it.
Darkmatter66 has quit [Ping timeout: 246 seconds]
gch981213 has joined #openwrt-devel
<mangix>
gch981213: rsalvaterra has questions for you :)
<rsalvaterra>
mangix: I do? :)
<gch981213>
Oh
<Borromini>
rsalvaterra: ram autodetection
<rsalvaterra>
gch981213: My Redmi RM2100 suddenly doubled the RAM. :P
<karlp>
Borromini: iirc, only uses feeds.conf.default if feeds.conf doesn't exist/isn't readable
<Borromini>
karlp: ok, will double check
champtar has joined #openwrt-devel
dorf has joined #openwrt-devel
hsp has quit [Read error: Connection reset by peer]
Namidairo has quit [Ping timeout: 240 seconds]
<gch981213>
rsalvaterra: If the ram detection goes wrong, adding a ram node in dts is the way to go.
<gch981213>
rsalvaterra: Is it always wrong or are there some previous versions working fine on your router?
<rsalvaterra>
gch981213: Yeah, I thought about hacking the device tree myself, but I wouldn't do it without confirmation from you. ;)
<rsalvaterra>
The thing is, the last (or second to last, I don't remember exactly) build had the RAM detection working correctly.
<rsalvaterra>
For that reason, I'm positive it's a regression.
valku has joined #openwrt-devel
hsp has joined #openwrt-devel
SmugLeaf has joined #openwrt-devel
grift has quit [Quit: Bye]
Weedy has quit [Ping timeout: 246 seconds]
grift has joined #openwrt-devel
gromero has joined #openwrt-devel
luke-jr has quit [Ping timeout: 265 seconds]
luke-jr has joined #openwrt-devel
<champtar>
ynezz: Hi, I was CCed on the github email, I'll not discuss it further on Github, but claiming Signed-off-by is personal information is just mind blowing for me, except if really the Signed-off-by was put by someone else without consent
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
luke-jr has quit [Ping timeout: 264 seconds]
luke-jr has joined #openwrt-devel
Borromini has quit [Ping timeout: 260 seconds]
Borromini has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<ynezz>
champtar: :)
<ynezz>
I've same view on that
<ynezz>
don't we sometime attribute someone else's work by simply keeping their Signed-off-by ?
<ynezz>
I mean, without explicit written consent
Borromini has joined #openwrt-devel
gch981213 has quit [Read error: Connection reset by peer]
<nbd>
do you know if this is a recent regression, or if older versions have the same issue?
<Borromini>
i can try an older driver if you'd like, but i just put openwrt on this thing a few days ago
<Borromini>
want me to try an older mt76 version?
<rsalvaterra>
tmn505: The bootloader (u-boot) doesn't pass any arguments to the kernel, that I know of. The kernel command line is embedded in the kernel itself.
zkrx has quit [Ping timeout: 246 seconds]
<rsalvaterra>
And mem= is a debugging aid, not something to be used in production.
<tmn505>
Oh! I've got production device where it's used :)
<rsalvaterra>
tmn505: It doesn't surprise me, but still doesn't make it right. :P
<rsalvaterra>
Whisky Tango Foxtrot…!
<rsalvaterra>
I just compiled a new image.
<rsalvaterra>
Now the RAM size is correct. *facepalm*
<tmn505>
Well if it's there, someone's bound to use it sooner or later.
<nbd>
can you use it to git bisect in the mt76 tree between 8696919d9aae9b673f916bca41c5e1671eec5b0e (new) and 4c8a09cc45d03897a473c270fede699a0420a483 (old)
<nbd>
if the ap goes down pretty quickly, it shouldn't take long to find the faulty commit
<Borromini>
will do!
<nbd>
thanks
romany3 has joined #openwrt-devel
CrazyMelon has joined #openwrt-devel
fblaese__ has joined #openwrt-devel
Rene__ has joined #openwrt-devel
<f00b4r0>
hmm, looks like I can't get usb tethering to work reliably with 19.07.6. *sigh*
zkrx has quit [Ping timeout: 264 seconds]
CrazyLemon has quit [*.net *.split]
fblaese_ has quit [*.net *.split]
romany has quit [*.net *.split]
zjason has quit [*.net *.split]
soma has quit [*.net *.split]
CrazyMelon is now known as CrazyLemon
romany3 is now known as romany
soma has joined #openwrt-devel
zkrx has joined #openwrt-devel
<Borromini>
nbd: are patches in patches/ still getting applied with git-src?
<Borromini>
ie package/kernel/mt76/patches/
<Borromini>
doesn't look like it
finsternis has quit [Remote host closed the connection]
<aparcar[m]>
nbd: I still couldn't figure out how to make the profile variables available during initramfs building. Do you have any idea how to do that or can you explain how that's different from the image building step, where all variables are available?
<Borromini>
nbd: added the single eeprom commit on top, thanks
CrazyLemon has quit [Ping timeout: 264 seconds]
<nbd>
aparcar[m]: please show me again the current version of the patch that you're testing
<Hauke>
lechner: I am missing a stable branch for wolfssl like openssl has it that would make maintaining it easier, you probably only get this as a paying customer
<Hauke>
at least this bussiness model would make sense to me
ivanich has quit [Quit: Konversation terminated!]
<Hauke>
lechner: You can send a patch to update wolfssl to 4.6 in openwrt 19.07
<zorun>
it looks like wolfssl is not in debian stable
<zorun>
so probably the "problem" did not yet show up in debian
<lechner>
zorun: not yet but it will be in bullseye. stable backport is available though. Hauke means something else
matteo has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<lechner>
Hauke: can you please explain how the openssl stable branch works? i am very close with wolfssl and can get whatever is needed
black_ant has quit [Ping timeout: 260 seconds]
<zorun>
lechner: what Hauke means is that to we need to update from e.g. 4.5.X to 4.6.X to get security fixes
<zorun>
but this brings tons of other changes, and is possibly not ABI compatible (I haven't checked that last part)
<zorun>
it would be nice to have e.g. a 4.5.1 release with just security fixes
<lechner>
zorun: same ABI
<zorun>
ok, that's good
matteo has joined #openwrt-devel
<zorun>
that never break the ABI?
<zorun>
*they
<lechner>
zorun: we do but i protest every time :) 4.6.0 still supports 24 though
Borromini has quit [Quit: leaving]
<zorun>
ok :)
<zorun>
what would happen for Debian stable if a new release is not ABI compatible? introduce a new package and rebuild all dependent packages?
<zorun>
there is a nice website that compares the ABI of different versions of libs, but I can't find it now
zatwai has quit [Quit: ZNC 1.8.2+deb1~bpo10+1 - https://znc.in]
<lechner>
zorun: probably. to minimize that risk i will ask wolfssl to run all symbol removals by me
zatwai has joined #openwrt-devel
<Hauke>
lechner: how wil you fix a security problem after bullseye is released?
<Hauke>
I think we should update wolfssl to 4.6.0 in openwrt 19.07, it is not used very much so if something breaks probably not so many people will complain
<zorun>
agreed
<zorun>
but for the next release it's much more critical
<zorun>
given the diversity of targets/architectures, the potential for regression is significant
<Hauke>
zorun: normally our use case are a bigger problem, hostapd suppro is broken in 4.6.0 for example
<zorun>
lechner: btw, I don't see anything about CVE-2020-36177 in the changelog for wolfssl 4.6.0 or in their "vulnerabilities" page
<lechner>
Hauke: I can talk to David, but you can't patch Makefiles on your end?
<Hauke>
yes we have this patch in our tree
<zorun>
it's patched in openwrt already
<zorun>
since it broke the build, it was easy to spot I guess
<Hauke>
I am just strugeling with the contributor agreement, I hate these documents
<lechner>
Hauke: don't worry about it then. those two lines are not worth it.
<karlp>
they have a manual CLA process?! that sounds effective...
muhaha has quit [Quit: Connection closed]
<lechner>
Hauke: thanks for the pointer on hostapd. in Debian we still use openssl for that
feriman has quit [Ping timeout: 265 seconds]
<Hauke>
openwrt has more stoarge constrains than debian
<Hauke>
from debian's point of view I would continue with openssl
<Hauke>
this is normally the best supported option
rmilecki has quit [Ping timeout: 264 seconds]
<lechner>
zorun: i am not sure why the CVE is not mentioned but they approached me, and it's a 9.8 on the NVD scale
<ynezz>
ouch
<lechner>
Hauke: just in case you are wondering. David asked me to help him. I have known him for many years, and packaged wolfssl in Debian for six
lnslbrty has quit [Ping timeout: 256 seconds]
swex has quit [Ping timeout: 256 seconds]
Tapper has quit [Ping timeout: 240 seconds]
kontaxis has quit [Remote host closed the connection]
lnslbrty has joined #openwrt-devel
kontaxis has joined #openwrt-devel
<blocktrron>
karlp: just to answer your question about arc - I've just discovered the crappy quantenna based WiFi mesh extender I have around here is based on arc
<blocktrron>
So yes, there looks like there's platforms out there in the wild using it. Not that this matters to mush about how we go on with it