<Hauke>
nbd: I fixed also some other libraries and the Depends lines are loking now ok, but I am still getting this error
rsalvaterra has quit [Ping timeout: 256 seconds]
Tost2 has quit [Ping timeout: 265 seconds]
Grommish[m] has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
valku has joined #openwrt-devel
<rsalvaterra>
adrianschmutzler: remember that issue I had, with sysupgrade failing sometimes (the system rebooting without upgrading)? I just sysupgraded my Redmi AC2100 after *six* attempts. Five sysupgrade -u -v <image> failed, the sixth sysupgrade <image> (without fancy arguments) worked. I don't know if it was a fluke, but it's not the first time this happens.
f00b4r0 has quit [Quit: This computer has gone to sleep]
<lipnitsk>
rsalvaterra: if you have rs232 connected to your box a failure log would help - may be some issue with non-vol partitions
<rsalvaterra>
lipnitsk: right, here's the rub… It never happens when I do it through serial.
<lipnitsk>
well you can still do it through network, but while reading and saving serial output
<lipnitsk>
don't send any data via rs232
<lipnitsk>
just reading from uart should not affect anything
<lipnitsk>
are you sysupgrading an image in /tmp? or some remote location?
<rsalvaterra>
Yes, /tmp. It's mandatory, iirc.
<rsalvaterra>
Oh, well… off to bed, getting late here.
<lipnitsk>
good night. Try to reproduce with serial connected when you get a chance :)
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
Tapper has quit [Ping timeout: 240 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<m4t>
philipp64: i replied to your github comment, dunno what's going on...
<m4t>
btw, is there any way to get that dump.txt file from CI? logs/feeds/packages_ci/lang/perl-try-tiny/dump.txt
<m4t>
only thing that comes to mind is maybe CI doesn't like include $(TOPDIR)/feeds/packages/lang/perl/perlmod.mk
<m4t>
but it's not happening all the time :/
<philipp64>
Odd that it would start now... missing dependency maybe?
<m4t>
well, for the build error you saw, sure
<m4t>
but for the try-tiny thing, idk. maybe CI lays out the feeds dir outside of $(TOPDIR) only sometimes
<m4t>
anyways, i'll open a PR for that shortly
hbug___ has joined #openwrt-devel
valku has quit [Remote host closed the connection]
hbug__ has quit [Ping timeout: 268 seconds]
valku has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
valku has quit [Remote host closed the connection]
valku has joined #openwrt-devel
slh64 has quit [Quit: gone]
<philipp64>
m4t: not clear what's going on with builds lately... seems a lot is broken of late...
<philipp64>
mangix: how does PR #14760 look?
<Grommish>
Is there a way to disable CI processing on a PR?
<Grommish>
It's a waste of resources because it keeps running out of space.
<Grommish>
5-5.5 hours of build time to error with: 2021-02-15T19:50:06.3800728Z ##[warning]You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 89 MB
<Grommish>
and it really doesn't need to run ;/
<lipnitsk>
is this for a package?
<Grommish>
Yes
<lipnitsk>
if so you should ping aparcar[m]
<Grommish>
Thanks lipnitsk :) ping apacar[m]
<Grommish>
err aparcar[m]
<aparcar[m]>
Grommish: pong
<Grommish>
Is there a way to disable CI for a package PR?
<aparcar[m]>
Grommish: i hope not
<Grommish>
Its a draft and chew for 5-5.5 hours before failing beacuse it runs out of space.. Doesn't need to actually run for a draft
<Grommish>
2021-02-15T19:50:06.3800728Z ##[warning]You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 89 MB
<Grommish>
and.. it runs 9 times
<aparcar[m]>
Wow what are you building?
<Grommish>
Its the rust-lang package
<aparcar[m]>
Oh sweet
<Grommish>
It's been working for a while, but its why I had the PKG_HASH as skip, but people complained hehe
<Grommish>
CI won't touch the hash mismatch
<Grommish>
but I'd rather not do that
<Grommish>
if not, I'm not stressing, but I find its a huge waste of resources
<m4t>
i wonder if there is a middle ground between relative & absolute that makes both local out-of-tree and CI builds happy
<philipp64>
aparcar[m]: What do you think of the above patchwork?
<lipnitsk>
Grommish, aparcar[m]: It's probably the fact that the container/VM runs out of space that causes it to take so long
<Grommish>
Its a 2h20m build for the rust toolchain on my i7-7500u w/28Gb ram.. It's just big for the first compile
<Grommish>
and it would die at 6 hours anyway if Openwrt's CI is like the personal ones
<lipnitsk>
CI not beefy enough probably, too little RAM/CPU?
<Grommish>
Dunno..
<mangix>
Grommish: CI jobs can be manually canceled by package maintainers
<mangix>
m4t: the perl packages are defined...weird. I initially added --force-removal-of-dependent-packages to fix CI problems. It's more of a workaround though.
<m4t>
ah
<m4t>
i wonder if that patch should be picked up, then
<mangix>
the migration to apk should solve this
* m4t
has no idea where/when/if opkg diverged from upstream
<mangix>
aparcar[m]: what's the story there actually? Anything missing?
<aparcar[m]>
mangix: im wondering what's up with libubox in snapshots
<aparcar[m]>
Uhttpd doesn't start
<mangix>
i was asking about apk. This ABI stuff is voodoo
<aparcar[m]>
sorry trying to fix my homes network
<aparcar[m]>
I'll read the log once done
<mangix>
sounds like btrfs snapshot magic is needed :)
<Grommish>
aparcar[m]: nbd was working on the ubox stuff earlier
<Grommish>
but I'm not sure if he got it fixed or not
<Grommish>
I know I updated from main branch earlier and it wasn't an issue anymore for the uci/ubox error I was having.. then it was spreading to dmesg and something else I saw before I stepped away
black_ant has quit [Ping timeout: 264 seconds]
<aparcar[m]>
mangix: want to help with the APK project?
rmilecki has joined #openwrt-devel
<mangix>
what do you mean?
lucenera7 has joined #openwrt-devel
lucenera has quit [Read error: Connection reset by peer]
lucenera7 is now known as lucenera
xback has quit [Remote host closed the connection]
Immanuel_ has joined #openwrt-devel
glyph_ has joined #openwrt-devel
glyph has quit [Quit: End of line.]
xback has joined #openwrt-devel
Immanuel has quit [Quit: Connection reset by reptilians]
glyph_ is now known as glyph
slh64 has joined #openwrt-devel
noltari_ has joined #openwrt-devel
noltari has quit [Ping timeout: 246 seconds]
<nbd>
Hauke: what packages are you still getting the errors with?
<nbd>
i tried building images with fdisk=y and it worked just fine for me
nitroshift has joined #openwrt-devel
<lipnitsk>
nbd: I'm trying to profile my SW offload changes on mt7621 and not getting much difference in measurement. in fact CPU0 seems swamped with IRQs from the NIC. Do you expect any benefit while using sw offload or should I just try to work out the HW offload piece? Testing with VLAN+PPPoE on eth0
<lipnitsk>
as a corollary, on 19.07 with SW offload I'm also seeing ksoftirqd taking up CPU, but it seems distributed across the 4 cores:
<lipnitsk>
24 2 root RW 0 0% 25% [ksoftirqd/3]
<lipnitsk>
7 2 root RW 0 0% 10% [ksoftirqd/0]
<lipnitsk>
19 2 root SW 0 0% 20% [ksoftirqd/2]
<lipnitsk>
14 2 root SW 0 0% 21% [ksoftirqd/1]
<lipnitsk>
vs on master I see:
<lipnitsk>
21 2 root RW 0 0% 27% [ksoftirqd/2]
<lipnitsk>
so maybe some SMP issue too (btw not quite master, I am testing 5.10)
<lipnitsk>
that's a crusty old long thread :) I'll take a look tomorrow
<lipnitsk>
thanks
lipnitsk has quit [Quit: Leaving.]
ivanich has joined #openwrt-devel
<owrt-snap-builds>
build #797 of ramips/rt3883 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/797 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Paul Spooren <mail@aparcar.org>, Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, R. Diez <rdiezmail-openwrt@yahoo.com>,
<owrt-snap-builds>
build #639 of x86/64 is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2F64/builds/639 blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Paul Spooren <mail@aparcar.org>, Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, R. Diez <rdiezmail-openwrt@yahoo.com>, Hauke
<owrt-snap-builds>
Mehrtens <hauke@hauke-m.de>
<rmilecki>
i suppose it's about
<rmilecki>
sh: 1: /builder/shared-workdir/build/staging_dir/host/bin/autom4te: not found
<rmilecki>
(buildbot fail)
<owrt-snap-builds>
build #789 of lantiq/xway_legacy is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway_legacy/builds/789 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, R. Diez <rdiezmail-openwrt@yahoo.com>, Paul Spooren
<owrt-snap-builds>
<mail@aparcar.org>
swegener has quit [Changing host]
swegener has joined #openwrt-devel
owrt-1907-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-1907-builds has joined #openwrt-devel
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
owrt-1907-builds has quit [Remote host closed the connection]
owrt-1907-builds has joined #openwrt-devel
owrt-snap-builds has quit [Remote host closed the connection]
owrt-1907-builds has quit [Remote host closed the connection]
owrt-snap-builds has joined #openwrt-devel
owrt-1907-builds has joined #openwrt-devel
owrt-2102-builds has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
pine127 has quit [Remote host closed the connection]
<owrt-snap-builds>
build #648 of mediatek/mt7629 is complete: Failure [failed toolchain] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7629/builds/648 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Felix Fietkau <nbd@nbd.name>, R. Diez <rdiezmail-openwrt@yahoo.com>, Paul Spooren
<owrt-snap-builds>
<mail@aparcar.org>
<jow>
^ /builder/shared-workdir/build/tmp/ccVlOak8.s:729266: Warning: end of file not at end of a line; newline inserted
<jow>
ldir: since nbd drover over that entire abi version handling with a tank and reassembled the scrap afterwards, I have no idea how to fix or debug
<jow>
doing the stuff took me about a week when I implemented it
<ynezz>
I've just removed all the ABI commits
<ldir>
lol
* jow
is slightly annoyed
<jow>
whenever I don't pay attention for two or three weeks and return to it, everything is f'ed up
<jow>
maybe we should just drop binary package repos
<jow>
everyone is just building his own perfectly customized images, right?
<jow>
so why bother
<f00b4r0>
:3
<blogic>
jow: there are people not building their own images ?
* ldir
hides the RPG launcher from jow
<jow>
blogic: apparently not
Tapper has joined #openwrt-devel
<mangix>
Unfortunately that's a necessity for some people
decke has joined #openwrt-devel
<blogic>
why do we even have wolfssl ?!
<mangix>
blogic: wolfssl people added patch
<blogic>
but why ?!
<blogic>
its worse than openssl and no one uses it
<stintel>
let's nuke it. less is more?
* stintel
hides
<blogic>
with openssl you at least have 1bn users effected by bugs that will then get fixed fast
<blogic>
stintel: ... from orbit
<ldir>
stintel: from orbit?
<mangix>
yeah openssl is also more t
<mangix>
han half the size
<mangix>
openssl is ~1MB
<blogic>
you are right, not noticing bugs is a fair tradeoff for safing some flash space
<blogic>
*sving
<mangix>
hahaha. The question you meant to ask is why doesn't hostapd support mbedtls.
<blogic>
no
<blogic>
not at all, first thing i do on any build is enable hapd full with openssl
<mangix>
If it did I think wolfssl can be nuked
<ynezz>
we've had those ABI issue with other packages as well
pmelange has joined #openwrt-devel
<ynezz>
hostapd doesn't support mbedtls because nobody cared enough to add support for it
<ynezz>
AFAIK it took more then year to include wolfssl into hostapd
<mangix>
Code was contributed by wolfssl team, no?
<ynezz>
I think so
<ynezz>
does it matter?
<jow>
problem with wolfssl is it's horrible ifdef forest
<nbd>
i just need some more information on what dependencies are still wrong
<nbd>
because i can't reproduce it myself
<ynezz>
blogic: BTW I've nothing against openssl, actually would prefer that, but it's huge, so we would make openwrt probably unusable on bunch of devices
<ynezz>
so we either have ABI issues which might be fixed OR flash space issues
<karlp>
is installable, but broken/non-functional better?
<ynezz>
how is wolfssl broken?
guidosarducci_ has joined #openwrt-devel
<lynxis>
pmelange: it sounds to me it's not yet a final decision. but as I wrote in the comment we can remove it if freifunk want to withdraw the repo.
<ldir>
nbd: you have me & my very slow macbook for 30 mins before I have to go to $dayjob.
<pmelange>
I think it's difficult to know what freifunk wants as it seems like there is very little to no participation from anyone.
<pmelange>
But since creating of the branch is stopping openwrt-21.02, I can just go and make a branch. The feed can be removed at a later time.
<lynxis>
pmelange: andi already created it
<ynezz>
pmelange: just propose the patch :p
<nbd>
ldir: which platform are you building for?
<ldir>
x86-64 for a pcengines APU2
<pmelange>
@ynezz first I thought that I would get some opinions before submitting a patch.
<nbd>
ldir: please show me the output of cat build_dir/target-x86*/util-linux-2.36.1/ipkg-*/*/CONTROL/control
<f00b4r0>
ynezz: openssl isn't a requirement to run openwrt though. I don't have openssl installed on any of my owrt devices.
<mangix>
OK. At least 1 package is held back because of C++17
<ynezz>
one out of 5000? :p
<mangix>
Well, I assume mpd is widely used :)
<mangix>
speaking of C++, I found out today that GCC6 is broken with lambdas using this.
<f00b4r0>
ynezz, jow: I don't know if this has been considered but if buildbot is upgraded, one might want to re-enable network locks which were implemented in 0edb4934 and disabled in 1e1a326 due to lack of support in 0.9
<ldir>
nbd: sorry felix, my machine is busy melting itself on ' make[3] -C target/linux install' - frustrating 'cos I only reverted & then restored one commit and it needs to build the whole darn thing again.
<nbd>
ldir: well, if it's doing target/linux install it means that it already did package/install
<nbd>
so it's working
<ldir>
it is working - I've changed nothing. WTH!?
<nbd>
maybe on the last build you still had some stale stuff in there
<ldir>
anyway, sorry have to get on the road to work. If I get a moment I'll make clean and try again.
<nbd>
thanks
<ldir>
I've done make dirclean and rebuiltd entire toolchain.
<nbd>
jow: sorry for the mess i've caused
<nbd>
the removal of abiversion from metadata was necessary in order to deal with the wolfssl config dependent ABI version
koniu has quit [Remote host closed the connection]
<jow>
nbd: as long as it ends up in the reverse dependencies it is fine for me. From a cursory look it seems you pushed the info from a generated makefile to per-package files instead
<nbd>
for intra-package dependencies it uses the ABIV_$(1) variable now, for inter-package dependencies the .version files
<nbd>
had to change the order of a few BuildPackage calls in package makefiles to make it work
<karlp>
luci's way smallerthan openssl...
<karlp>
sorry, lost in the scrollback again
<karlp>
mangix: why were you using gcc6?
<ynezz>
its used by buildbots
<mangix>
User had issues with some changes I did on Debian 9. Non OpenWrt related.
<mangix>
Apparently GCC6 has a compiler bug with lambdas
koniu has joined #openwrt-devel
<mangix>
I told him to just use clang
<karlp>
debian, "stable" again I suppose....
<mangix>
It’s an LTS release
<mangix>
Debian is on a 5 year support cycle
<mangix>
Not infinite like CentOS :)
<pmelange>
speaking of build systems, on the 9th I asked in irc if openwrt is still dependent on python2. The wiki page for imagebuilder still has python as a requirement on "Arch / Manjaro" or "Debian / Ubuntu". If anyone can confirm that they can build on either of these systems without python2 being installed, then I would be happy to update the wiki
<pmelange>
page.
<ynezz>
19.07 needs Python2, snapshot and 21.02 shouldn't
<nbd>
guidosarducci_: there's a reference to libelf for gcc
<nbd>
not sure if it's still needed
<nbd>
but that might be one reason for libelf
<nbd>
i'd be fine with replacing libelf with elfutils if we can get elfutils to compile on macOS
<jow>
ynezz: nice :)
<ynezz>
well, I assume there is still long road towards 21.02.1 :]
<guidosarducci_>
nbd: on Linux it can be completely removed and builds still work, thought maybe same on OSX but I have no way to test
<nbd>
linux systems probably typically have some variant of libelf on the host
<nbd>
the same can't be said for macOS, since it doesn't use ELF natively
<mangix>
Looks like I should try with my macOS VM.
<guidosarducci_>
nbd: I did some experiments removing libelf-dev too. *But* I didn't rebuild toolchains so there may be a gcc dep.
<mangix>
nbd: how supported is macOS?
<guidosarducci_>
nbd: problem I stumbled across (during BPF work) was we have 3 sources of libbpf: host build from elfutils pkg, system prereq, and the 9-year old BSD tools/libelf
<nbd>
mangix: not everything works, but the core stuff does. i use it for almost all of my dev work
<guidosarducci_>
nbd: which can cause build conflicts.
<mangix>
OK.
<nbd>
guidosarducci_: right, it's a mess
<nbd>
i would like to switch to elfutils, but it might be quite a bit of work to get it building on macOS
<nbd>
if i remember correctly, last time i looked at it, it was having lots of portability issues
<nbd>
but that was years ago
<guidosarducci_>
nbd: in my BPF/BTR PR, for now I just isolate tools/libelf to non-Linux, drop the host-build from target pkg elfutils, and instead add a host pkg elfutils.
<guidosarducci_>
but I wanted to clean thing up a bit more than that...
<mangix>
I kind of wish I had a proper VM. That was I can build stuff comfortably.
<nbd>
mangix: it's possible to run macOS in KVM
<mangix>
Yeah I have one running with QEMU. It’s quite subpar. Small resolution and significant lag.
<guidosarducci_>
nbd: what I've read show elfutils working on FreeBSD, but request for OSX ports marked "wontfix", but I can't be certain of any of it.
<nbd>
mangix: i got it working reasonably well
<nbd>
i can give you my libvirt config if you're interested
stintel has quit [Quit: reboot - kernel update]
stintel has joined #openwrt-devel
SpaceRat has joined #openwrt-devel
<ynezz>
+1
<guidosarducci_>
nbd: on Linux, is the OWRT preference for adding host packages or system prerequisites? I needed to also add host libdw-dev, and thought an elfutils host pkg best
<nbd>
guidosarducci_: depends on how common the dependency is
<guidosarducci_>
nbd: atm building dwarves tools needs it, and in past some target pkgs needed host libelf. But I saw there are no make prereq checks for libelf, so we can't always assume they're there...
<guidosarducci_>
nbd: I'd be OK with adding a system prerequisite, but don't know the change process for it, and it means possibly updated a lot of build bot too no?
<guidosarducci_>
nbd: No build bot updates needed with a host package...
<ynezz>
ok, nobody :) so I'm going to rebase that patch and send it out for final review
<rmilecki>
ynezz: i'm againt removing bcm4908, it's source-only, doesn't bother anyone, i'm planning to use it
<mangix>
ynezz: but muh centos 7 VM
<rsalvaterra>
ynezz: speaking of which, could we now bump master to gcc 10? I've been using if for months on x86-64, mvebu, mips (24/74kc) and mipsel. :)
<ynezz>
adrianschmutzler: BTW what is so special about ipq807x? Why simply not remove all of the source-only targets (minus the bcm4908) ?
bala has quit [Quit: WeeChat 2.8]
<adrianschmutzler>
ynezz: I just removed that one because blogic specifically stated it and it's obviously incomplete
<adrianschmutzler>
so one thing less to care with an easy decision
<ynezz>
adrianschmutzler: do you plan to address the rest as well?
<rmilecki>
nbd: with echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus I get 880 Mb/s and 20% [ksoftirqd/1]
<rmilecki>
what the hell is limiting that NAT speed :(
<adrianschmutzler>
I considered removing realtek as well, but since that one looks so ready, I would prefer to leave that to blogic, and not have my name on the removal
<adrianschmutzler>
rmilecki can surely decide himself on bcm4908 ...
<adrianschmutzler>
do we have other SOURCEONLY targets left?
<ynezz>
yeah, but it would be quite strange to make it out of source-only in 21.02.3 :p
<adrianschmutzler>
I don't really have a strong opinion on that
<adrianschmutzler>
uml is source-only as well, but that's somewhat a special case
<adrianschmutzler>
beyond that, only subtargets
<ynezz>
on the other hand realtek works for a few people already, so I'm really not sure if it should be removed :)
<adrianschmutzler>
subtargets won't be a problem with patches, only with config, which should be much more limited
valku has joined #openwrt-devel
<adrianschmutzler>
I personally share the same perception about realtek, that's why I did not touch it
<adrianschmutzler>
And since I was not involved there apart from cosmetic stuff, I cannot really judge myself
<adrianschmutzler>
but to me it seems in better state than many other old targets
<Grommish>
PKG_BUILD_DEPENDS are host packages that need to be installed prior to building the package.. I use: PKG_BUILD_DEPENDS:=rust/host for exampe
<philipp64>
I had put "libcurl" as the dependency, but was told it should be "curl" instead as that's one of the subpackages built by "curl".
<Grommish>
Ah, isn't curl a build system package/ though?
<Grommish>
and not in feeds?
<philipp64>
In this case, I need headers appropriate to the target, so I don't think it would be "/host".
<Grommish>
it's a package in feeds
<Grommish>
and jut called curl it looks like
<philipp64>
it's in package/feeds/net/curl
<Grommish>
its in package/feeds/packages/curl
<philipp64>
so... what's correct?
<philipp64>
libmariadb needs <curl/curl.h>
kab-el_ has joined #openwrt-devel
kab-el_ has quit [Changing host]
kab-el_ is now known as kab-el
<Grommish>
and symlinked.. I;d use PKG_BUILD_DEPENDS:=curl and see what happens
<philipp64>
okay, thanks
<Grommish>
I can pull and test if you'd like as well
<philipp64>
as best as I can tell they both work...
<philipp64>
sure, that would be great if you have time.
<nbd>
i just pushed the generic 5.10 patches to master
<rsalvaterra>
mangix: I'm trying another approach regarding the interrupts on the Omnia. The upstream device tree changed quite a bit, since the 5.4 series. I backported all the changes, minus the LED bindings (since they don't exist on 5.4). I don't know if it will fix anything, but at least we'll have hardware buffer management. :P
<philipp64>
btw, what does everyone think about the idea of installing the previous build of a package under test, doing the build of the PR, and then doing an upgrade of the package, as part of the CI pipeline... so it's "upgradability" gets tested... instead of doing a virgin install of the just built package, which is what we currently do?
<philipp64>
also, how did px5g-wolfssl get commited? I'm surprised it passed CI given that there's no PKG_VERSION... doesn't that get checked?
<rr123>
21.02 still has the 'pkg_hash_fetch_best_installation_candidate: Packages for qdecoder found, but incompatible with the architectures configured' for me, though here qdecoder is not a core package, but still
<rr123>
with fresh make-distclean build
<Borromini>
rr123: i still get it with dmesg
<Borromini>
on 21.02 branch as well
<Borromini>
and now bridge-utils breaking on ipq40xx...
<Borromini>
philipp64: that's just what make will translate make package/libgpg-error to from what i can tell
<Borromini>
i can still do make package/bla/{clean,compile} here
<blogic>
unfortunatly the unit is on on sale in US right now, but the EU outfit started selling them in UK last week, lets hope the start selling them in EU shortly
<Borromini>
blogic: i got some in-wall APs for the new place, i wanted them to be mt76
<Borromini>
i have like five or six :P MT7615, MT7613, MT7612
<Borromini>
(not all in-wall of course those are just the MT7613 ones)
<svanheule>
Borromini: MT7613 support could be better
* svanheule
hides
<blogic>
Borromini: been doing mt915 testing the last 2 weeks, its amazing
<blogic>
the best wifi i had in 2 decades
Darkmatter66 has quit [Quit: ZNC 1.8.2 - https://znc.in]
<blogic>
we imported 15 linksys e8450 units
shibboleth has joined #openwrt-devel
<blogic>
dangole made uboot 2021 work on them
<Borromini>
svanheule: true =) let's just hope it's too recent a radio all in all (haven't seen too many openwrt devices with it yet)
<Borromini>
blogic: project for a client?
<blogic>
I am rolling the device on bleeding edge uboot, sbl, atf, v5.10, mt76 and it is performing better than anything i have ver seen
<blogic>
Borromini: no side tracking clinet budget for fun stuff ;)
<Borromini>
i wouldn't mind AX but then you're looking at > 1 gbps backbone i reckon, so you can start over again... so maybe when one day some nice unobtrusive AX wall APs come along :)
<rr123>
Borromini: i got the external built after removed its fcgi dependencies, which does not exist and was indeed my error. Basically i makde sure 'make' spits no warning (missing dependencies)
<Borromini>
blogic: haha
<rr123>
s/external/external package qdecoder/
<blogic>
Borromini: the unit unforutnaly only has 1gbit phys
<Borromini>
blogic: yeah, but it's sure nice to test the waters i reckon
<blogic>
yet best wifi i had ever
<Borromini>
and it's still a sizeable bump over 802.11ac probably
<svanheule>
blogic: enough GbE phys to try trunking?
<blogic>
indeed
<shibboleth>
<Borromini> and it's still a sizeable bump over 802.11ac probably
<shibboleth>
wifi6, not very likely
<shibboleth>
wifi6e, more likely, but still hit-and-miss
<blogic>
cant wait till 3-6 months down the road when we will see other mt7622 off the helf units
<shibboleth>
802.11ad/ay=for sure
<rr123>
for mt76 i recall the mt7613 2.4ghz is not that robust
<blogic>
shibboleth: i have 6e on my desk ;)
<shibboleth>
nice
<shibboleth>
which device?
<blogic>
rr123: times are a change
<shibboleth>
waiting for the tplink from ces2021
<blogic>
shibboleth: qca hastings
<blogic>
shibboleth: oushed 4+ gbit over the ref kit using ath11k
<blogic>
+pushed
<shibboleth>
between two similar devices i take it?
<blogic>
correct
<blogic>
1 ref kit as sta the other as sta
<blogic>
1 ref kit as sta the other as ap
<rr123>
sometimes i'm unsure if wifi is becoming a microwave these days, super speed, lots of antenna...i moved it further from my head depends on how many antennas it has
<shibboleth>
as they say in australia: noice
<blogic>
well, the question is do we really need wifi7 EHT
<blogic>
max rat is 10+ gbit
<blogic>
*rate
<blogic>
so the thing is this is living room RF
<blogic>
no uplink can be saturated with wifi 7 EHT
<blogic>
yet the latency is very low
<Hauke>
blogic: my RT3200 from the UK just arrived today
<blogic>
Hauke: mail me your postal and i will send a cable to you
<Hauke>
blogic: shipping to Germany was no problem amazon took care of customs
<Hauke>
I will have a look at it on the weekend
<rr123>
i bought quite a few 7603 devices and now they're all collecting dust, the 2.4G worked well with ath9 clients but not broadcom ones in my test
<shibboleth>
blogic, oh, you've tested 128 6e STAs connected to a single 6e ap?
<Hauke>
blogic: what cable?
<Borromini>
rr123: i'm using MT7615 2,4 GHz here as a poor man's WDS backhaul
<blogic>
shibboleth: the mt7915 can in theory do 280 sta, there is a race between FW and drv on one of the registers right now that limits it to 127 but MTK prmoised to fix thix the next few weeks
<blocktrron>
blogic: can second your mt7915 claim :)
<shibboleth>
noice
<blogic>
Hauke: the serial is 1,2mil pitch (molex)
<blocktrron>
however GTK rekeying is still broken for me when using 802.11w
<blogic>
blocktrron: will try
<Borromini>
eh 90 EUR for an AX device?
<Borromini>
that's not bad
<blogic>
shibboleth: on 6e yes
<blogic>
Borromini: and it is the best unit i ever had
<blocktrron>
I'm still waiting for a 2.5GE network card to see whether or not the PHY in the U6-LR works
Tapper has joined #openwrt-devel
<Borromini>
blogic: haha. my wife is already moaning about the footprint of an EAP235-Wall against the wall :P
<blogic>
Borromini: we will be pushing docs on how reflash the unit with uboot 2021.1 vanilla shortly
<Borromini>
neat!
rmilecki has quit [Ping timeout: 256 seconds]
<blocktrron>
blogic: your will try is for the 11w GTK issue?
<blogic>
mtk provided opnocd scripts that allow us to jatg that unit with a 10e ftdi 245 dongle
<rr123>
will mediatek push atheros out in the wifi market as what hisilicon did to TI for ipcamera chips, the latter only took 2-3 years
<blogic>
blocktrron: mail me and i'll put it on my todo
<blocktrron>
blogic: will do
<rr123>
i feel there are more mediatek wifi devices than atheros and it became a trend somehow
<blogic>
rr123: i see mtk as the plaform that will allow owrt to provide AX
<Hauke>
blogic: are you able to access the CPU over jtag?
<blogic>
also on mtk we have full wired flow offload in HW and wifi flow offload is being worked on
<blogic>
Hauke: yes
<blocktrron>
blogic: do you have any information about it's zero-wait DFS feature?
<blogic>
Hauke: we can jtag direct into the bootrom
<Hauke>
so you can stop the CPU look at registers and memory?
<blocktrron>
The U6-LR has an additional antenny (presumably for that), but even UBNT does not list it in their spec-sheet
<Hauke>
blogic: have you dumped bootrom to see how they do secure boot? ;-)
<blogic>
mtk provided src for the second stage loader incl the 3 flavours of ddr calib stubs + atf src
<blogic>
Hauke: yes
<blogic>
Hauke: yes
<hurricos>
Jesus christ, Mediatek really wants to get eaten by the FCC don't they
<hurricos>
well, good for them
<blogic>
mt7622 has a fully open bootchain
<blogic>
if you get the right device that is
<blogic>
there are tplinks avail that are fully rsa locked
<hurricos>
blogic: mt7622 has silicon stage1?
<blogic>
hurricos: depends on the otp/efuse
<hurricos>
If they don't have a fully silicon stage1, the fix is just to externally reflash
<blogic>
but there is a stage1 bootrom as with all SOC that is cfg via bootstap
<blogic>
*bootstrap
<Hauke>
supprot for secure boot with keys in OTP is more or less standard nowadays
<hurricos>
aha
<blogic>
it is arm so otp rsa atf lockin is possiblr
<blogic>
Hauke: correct
<Hauke>
but it is not often used because it is complicated and you often needs additional NDAs and fees
<hurricos>
Well, given how long it takes to get the drivers right we'll probably be cracking those keys at a good time for getting OpenWrt flashed.
<hurricos>
)
<hurricos>
B)
<blogic>
B)
<Hauke>
and most vendors are fine if the web UI checks some signature
<Hauke>
this is much easier and cheaper than secure boot
<blogic>
cheaper is the key
<lechner>
Hauke: wolfssl 4.7.0 is out
<PaulFertser>
Mediatek sent OpenOCD configs upstream.
<Hauke>
lechner: thanks for the info
<Hauke>
lechner: foes it fix more security problem than the one you told me before?
<Grommish>
oof.. opkg update tries to get 15.03-rc3
<mangix>
Hauke: thanks
<mangix>
rsalvaterra: how so?
<rsalvaterra>
mangix: still digging, could be on my side.
<hurricos>
Grommish: Pong
ivanich has quit [Quit: Konversation terminated!]
<Grommish>
hurricos: I've got this secondary device pulled that used the Cavium SDK from the OEM/ODM.. Is there anything on here you might like/need that i can pull off before i blow it up?
<hurricos>
you can always dump the nand / ubi volumes to tmpfs and save them
<Grommish>
I'd like to try and pull the /proc/device-tree off for my own purposes
<hurricos>
s/nand/mtd/
<Grommish>
It uses emmc, I have ELF .bins
<Grommish>
in a vfat, so that isn't an issue, but I meant from the live system
<hurricos>
eww ... well raw storage dumps would be appreciatd if you can get them
<hurricos>
yeah, you can dd off live file systems just fine.
<hurricos>
It's just like shutting them off hard, but with the rolling shutter effect
<hurricos>
Just poke the block device.
<rsalvaterra>
mangix: It's not here, mvebu master build is definitely broken. The kernel isn't compiling.
<Grommish>
It's running 15.03-rc2 ;/ so I need to figureo out how to put dtc on there
<rsalvaterra>
cc1: fatal error: symtab.h: No such file or directory
<rsalvaterra>
Hmm…
<Grommish>
er rc3
<hurricos>
err, for what
<hurricos>
dd?
<hurricos>
you can do it with a tempfs or with network+busybox nc
<hurricos>
you can get the dt*s* straight out of your u-boot
<hurricos>
fdt show
<Grommish>
I'm sure I am missing most, if not all, of the i2c stuff
black_ant has quit [Ping timeout: 256 seconds]
<Grommish>
I don't have fdt show in uboot
<hurricos>
ah
<hurricos>
well dd straight off the raw block dev will get you u-boot's imgae
<Grommish>
Ive got fdt, but not fdt show
<hurricos>
fdt help then
<Grommish>
uboot is also a .bin :D
<Grommish>
for stage1 and 2
<hurricos>
yeah you can extract teh device tree from those
<rsalvaterra>
I have a config-5.4 for cortexa9, but it worked just fine until four days ago (last time I built mvebu)…
<hurricos>
it's the dtb, sure, but finding what you need from that is fairly easy
<hurricos>
's/[^[:ascii:]]/ /g;s/}/\n/g'
<Grommish>
I'm just trying to see what I missed when I made the shield target. I'm sure it could be cleaned up.. works well, but since I've got the second untouched device
<hurricos>
I completely lost the links to the .bins
<Grommish>
I'm hoping they might have something from RhiNo or Cavium
<hurricos>
binwalk for the dtb, `dd if=$file bs=1 skip=$offset count=1000 of=file.db`