<Levitator>
Hey, was wondering if you guys know of someone having success with the Espressobin v7 and a Marvell 8997 Wifi NIC.
<Levitator>
Because I ran into nasty problems, but I'm not sure if it's something I missed.
Levitator has quit [Remote host closed the connection]
Levitator has joined #openwrt-devel
<Levitator>
Well, given that I don't have infinite time, I'm just going to set up a forwarding rule so that the Wifi subnet fetches DNS from the LAN subnet, which works properly.
<Levitator>
But it annoys me slightly that I have no idea why the WAN subnet has no DNS service of its own.
goliath has quit [Quit: SIGSEGV]
william_guo has joined #openwrt-devel
william_guo has quit []
Tapper1 has quit [Ping timeout: 480 seconds]
minimal has quit []
Levitator has quit [Remote host closed the connection]
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
rmilecki has joined #openwrt-devel
nitroshift has joined #openwrt-devel
lmore377_ has joined #openwrt-devel
lmore377 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nitroshift has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
Grommish has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
lmore377_ has quit [Read error: Connection reset by peer]
<f00b4r0>
it's ok. I prefer to have tools that help me do what I do, rather than things I need to fix first before I can try to use them :3
<rsalvaterra>
mangix: The cube is just… silly. :P
<mangix>
since you mentioned compiz :)
<aparcar[m]>
can I use grep with spaces instead of newlines without using tr twice?
<rsalvaterra>
aparcar[m]: Not really, sorry… And this machine is running Catalina. :/
<rsalvaterra>
mangix: There's a lot more to Compiz than the cube. ;)
<mangix>
hmmm pegasus explout is fixed in 14.8. maybe i should update...
* enyc
meeps
<enyc>
so many PRs in github hrrrm
<f00b4r0>
aparcar[m]: what sort of horsepower do you need and how long would you need it?
<aparcar[m]>
f00b4r0: I'm collaborating with the APK developer and he'd use it to compile APK on mac until... it compiles
<aparcar[m]>
so maybe 5g of storage, 512mb ram, 1 core, 1 month?
<f00b4r0>
does he need a specific version of macOS or would any do? If the latter, I might be able to help
<mangix>
aparcar[m]: has he looked at cfarm?
<f00b4r0>
also that ^
<aparcar[m]>
cfarm is a good pointer, I didn't know they have apple stuff now
<aparcar[m]>
I'll point him to that thank you!
<mangix>
hmmmm
<mangix>
gcc304 is red for some reason...
<aparcar[m]>
too many context switches?
<f00b4r0>
:D
<mangix>
ssh: Connection to mangix@gcc304.fsffrance.org:22 exited: Connect failed: Operation timed ou
<mangix>
meh
<rsalvaterra>
Speaking of macOS…
<Grommish>
mangix: Thanks for pointing out the ping for Lucian, I wish github usernames were part of the Maintainer field, and i didn't think bout a general search until after you mentioned it, so thank you :)
<rsalvaterra>
… does anyone have any idea on how to corretly map a normal keyboard? Especially in Portuguese, the keys are completely wrong.
<f00b4r0>
a pc keyboard you mean?
<rsalvaterra>
f00b4r0: Yes, PC keyboard.
<f00b4r0>
system pref -> keyboard -> input methods
<f00b4r0>
+ -> chose your language variant with the "PC" tag
<rsalvaterra>
f00b4r0: There isn't one.
<mangix>
what OS is this?
<rsalvaterra>
10.15.7 Catalina.
<f00b4r0>
indeed. Portuguese seems leftover
<f00b4r0>
well, you have two options
<f00b4r0>
you can switch to good old US QWERTY layout, if you know from memory where the keys are
<nbd_>
i order my macs with english (international) layout
<nbd_>
which is quite decent
<nbd_>
i don't like the return key placement of the us layout
<Grommish>
rsalvaterra: That help at all?
<f00b4r0>
nbd_: agreed, it's annoying. That's why running US on EU keyboard is nicer :)
<nbd_>
english (international) is like the eu layouts, but with QWERTY
<rsalvaterra>
Grommish: Not really, but thanks anyway. Note that I have all the PT keyboard keys, they're just mapped wrong on the 105 key PC keyboard. :)
<nbd_>
very close to the US layout, but without the crappy return key placement/shape
<f00b4r0>
nbd_: oh, that's nice
<rsalvaterra>
nbd_: You mean ISO vs ANSI return?
<nbd_>
probably
<f00b4r0>
yes
<f00b4r0>
vertical return key vs horizontal return
<Grommish>
rsalvaterra: Gotcha. Mac doesn't have a keyboard remapping software? I'm completely Mac-stupid
<rsalvaterra>
nbd_: I like the ISO layout. :)
<rsalvaterra>
The "two row" return key.
Tapper has joined #openwrt-devel
<nbd_>
yes, me too
<karlp>
they normally don't even bother makingkeyboards for my local layout.
<karlp>
we get stickers from the shop to fix the keys for most of them :|
<Grommish>
rsalvaterra: I would have had you down as a mechanical KB afficionato
<f00b4r0>
Grommish: I have a pile of AEK2s. I only use that keyboard on desktop machines :D
<Grommish>
a solder-your-own DIY kit :D
<rsalvaterra>
Grommish: I am. I have a very nice Logitech keyboard with brown switches. :)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<aparcar[m]>
nbd_: do you remember why OpenWrt chose to use IPKG_INSTROOT and not chroot for the rootfs creation?
<nbd_>
we can't chroot, since we can't execute binaries from the rootfs dir on the host
<aparcar[m]>
nbd_: sure but if we'd temporarily copy busybox?
<aparcar[m]>
the APK developer is willing to fix APK for macos, we just need a SSH-able mac device.
<aparcar[m]>
nbd_: sure I know. a quick rebase
<nbd_>
why is this necessary?
<aparcar[m]>
APK, busybox? macos?
<nbd_>
busybox + fakechroot
<nbd_>
when it comes to dealing with portability issues of busybox vs dealing with a few shell script path issues, my preference is very clear
<aparcar[m]>
APK uses chroot for installations != /. While this can be patched away, I found (within 5 seconds) at least one that doesn't use IPKG_INSTROOT in a postinstall script
<aparcar[m]>
so I thought to solve this type of problem by using chroot
<aparcar[m]>
however I can also remove the chroot behavior and imitate exactly what opkg does
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nbd_>
i'd prefer leaving out chroot for now
<aparcar[m]>
ack
goliath has joined #openwrt-devel
<nbd_>
btw. in that osx busybox tree it's not just the top commits needed for osx support
<nbd_>
there's a merge commit and some more hackery further down in the history
<nbd_>
and this stuff looks ugly
<nbd_>
so it's not just a simple quick rebase job
<aparcar[m]>
good to know, macos isn't yet fully on my radar
<nbd_>
i use it for most of my openwrt dev work
<aparcar[m]>
Well good thing without chroot only APK needs mac support
Grommish has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
Grommish_ has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<nbd_>
aparcar[m]: i expect it will be quite a bit of work to make it portable
<nbd_>
lots of non-portable stuff in there
<aparcar[m]>
nbd_: there is an open issue where I posted a wip patch and the developer is also willing to check it out. Let me know if you consider it as not feasible at all
f00b4r0 has joined #openwrt-devel
<karlp>
the end goal here is to replace opkg with apk for ... reasons right?
<Habbie>
i was just wondering why all the talk about apk
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
hanetzer: my EAP615-Walls have arrived =)
<hanetzer>
stintel: nice. they're a bit of a prick to get open :)
<hanetzer>
still, no 'special screws'. just two phillips and clips around the side.
<stintel>
I nuked the LED button already 😂
<hanetzer>
there appears to be an unpopulated serial header, but I don't have any pin headers to test it with
<stintel>
it came of the SoC, with the PCB traces still on it :D
<hanetzer>
whoa
<stintel>
I have a pin header on it already, and made a hole in the case so I could reassemble with the header on it
<stintel>
I don't have 90 degree headers in my stock anymore
<hanetzer>
nice. yeah, those are what I intend to use.
<stintel>
so that was the only option besides leaving the device open
<hanetzer>
so, did you capture a bootlog, from u-boot onward?
<hanetzer>
stintel: nice. its pretty easy to grab the dtb out of either a flash dump or the firmware they provide. binwalk on it; it will show two device trees. the first one is the FIT image containing the kernel and actual device tree, you can dd out the second one using the size and offsets it gives.
mva has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
c0sm1cSlug has joined #openwrt-devel
c0sm1cSlug_ has quit [Ping timeout: 480 seconds]
nitroshift has quit [Quit: Gone that way --->]
<aparcar[m]>
karlp: Habbie correct
<Habbie>
cool
<Habbie>
this is not a joke question: are you expecting more convergence between Alpine and OpenWrt?
<jow>
karlp: yes, the end goal is to switch to apk eventually
<jow>
karlp: opkg is a dead end. Upstream is extremely bloated (libsolv, libarchive, ...)
<jow>
karlp: the opkg-lede fork will go nowhere
<stintel>
I was about to say, if it suits our needs and we get to maintain 1 less fork, it's a win
<stintel>
and that's already like that without all the arguments against opkg :)
<jow>
a big problem is opkg's naive package list format and parsing logic
<jow>
it is fine for 200-300 packages
<jow>
but if the plaintext lists approach >> 1MB raw file size, opkg's "lets gobble up the entire dependency graph in main memory" approach falls flat
<jow>
it uses very inefficient internal data structures, requires reading the entire lists even for just simple operations etc.
<jow>
changing that would essentially be a rewrite of opkg (after opkg-lede already rewrote large chunks and led nowhere)
bluew has joined #openwrt-devel
aleksander has quit [Quit: Leaving]
mva has joined #openwrt-devel
linusw_ has quit []
<aparcar>
and that's why I'm working on APK, thanks jow
<Grommish_>
You know that feeling, when you're 2+ hours into the build and it fails because you forgot that single line? *facepalm* I'm deep into that at the moment :D
<stintel>
:D
<Grommish_>
stintel: oo.. So, I think I'm just going to create rust-lang tuples for openwrt toolchains and upstream them They seem receptive and it'll simplify things for me
<Grommish_>
and, of course, it'll make all that arm target handling completely moot :/
Grommish_ is now known as Grommish
anon_ has joined #openwrt-devel
anon_ has quit [Remote host closed the connection]
<stintel>
Grommish: nice work!
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
hanetzer: tftpboot working, but have to go :(
f00b4r0 has quit [Remote host closed the connection]
f00b4r0 has joined #openwrt-devel
Lynx- has joined #openwrt-devel
<Lynx->
hey what is the command to expand each shell call and print again?
<slh>
6 GHz is still 'fun' in Europe, Intel's ax210 drivers don't support it yet
<stintel>
and actually the dts does ieee80211-freq-limit = <0x4c4b40 0x5b8d80>;
<Borromini>
but that's a product using MT7916 so maybe the 6E capability is handled by other hardware
<stintel>
which is 5G-6G
<stintel>
so not > 6G
<stintel>
as of December all EU countries are expected to have implemented the regulation to allow it
<stintel>
so it'll come
<Borromini>
well could as well be a neutered design no? wouldn't be the first vendor to sell such stuff
<stintel>
really looking forward to have 6E APs :)
<stintel>
my phone supports it already!
<stintel>
but I might fix that piece of crap with a hammer
<stintel>
today I'm in the bakery, and my google pay says "doesn't meet security requirements"
<slh>
sadly the Intel drivers don't allow it so far, not linux, not windows 10, not windows 11 (just installed that for this purpose,but no dice with Intel's 22.90.0 ax210 drivers)
<stintel>
I used google pay the day before no issue, not running beta, not rooted, no update between yesterday and today
<stintel>
and samsung support says "reset all settings"
<stintel>
how about no, at least look at some goddamn logs wankers
<stintel>
I'm actually close to buying a bloody iphone
<Borromini>
all I read about Google Pay is it's a sh*tshow the way any Google product tends to be
<Borromini>
seems short attention span deficit is something Google selects their hires on
* Borromini
waits till they throw out Google Workplace whatever
<stintel>
I've been using Google pay for years without issues
<stintel>
workplace is a facebook product? :P
<Borromini>
but they did an overhaul recently didn't they?
<Borromini>
stintel: idk :P. Their MS O365 suite counterpart :P
<Borromini>
ah Workspace it's called.
<Borromini>
...
rmilecki has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
Habbie has joined #openwrt-devel
* Borromini
is out
<stintel>
o/
<Borromini>
stintel: the EAP615-Wall looks enticing but I have no AX clients and 3 EAP235-Walls already :P
<Borromini>
missus won't be happy with me :P
<Borromini>
later
<stintel>
:P
<stintel>
she doesn't need to know
<stintel>
the APs look identical to your current ones :P
<Borromini>
true :P
Borromini has quit [Quit: leaving]
<stintel>
I have 3 AX devices
<slh>
with 802.11ax you can usually easily achieve 650 to >1 GBit/s throughput over wireless, at least within the same room. it's really a quite significant speedup
<slh>
also quite some improvement for 2.4 GHz
<stintel>
well proper 11ac wave2 is already quite fast
<slh>
~350-400 MBit/s
<stintel>
but indeed, the improvements on 2.4 are more interesting
<stintel>
slh: I get >600Mbps on my phone on an ac AP
<slh>
in praczice, with 2x2 clients
<stintel>
sorry, not 600
<stintel>
close to 500
<stintel>
saw ~650 when connected to the EAP615 running stock firmware