01:01
theJoker8814 is now known as Guest214
01:01
thejoker8814 has joined #openwrt-devel
01:08
Guest214 has quit [Ping timeout: 480 seconds]
01:20
Emantor has joined #openwrt-devel
01:30
<
schmars[m] >
about xz and PKG_MIRROR_HASH - for a custom package of mine, the snapshot docker.io/openwrt/sdk container complains about a mismatch, the tarballed sdk from downloads.openwrt.org doesn't complain
01:33
<
mirko >
mrnuke: what was the reason not to include it as base pkg?
01:40
<
mirko >
i have a question re sda switch config - is it expected that [1] is working but [2] isn't? At least that's the case for my gs1900 switch right now. mind the vlan id
01:47
<
mrnuke >
mirko: I don't remember the full discussion.
01:48
<
mrnuke >
Someone suggested adding it as a feeds package. hurricos and I then set up the realtek-poe repo to allow this use case, and we
01:50
<
mrnuke >
and we hit <Enter> too early. I need to stop typing when it's this late at night :p
01:53
goliath has quit [Quit: SIGSEGV]
02:00
tSYS has quit [Quit: *squeak*]
02:00
skynet2 has quit [Ping timeout: 480 seconds]
02:00
tSYS has joined #openwrt-devel
02:02
minimal has quit [Quit: Leaving]
02:25
<
Mangix >
schmars[m]: yep. this is temporary until the zstd transition is done.
02:31
Slimey has quit [Read error: No route to host]
02:31
Slimey has joined #openwrt-devel
02:48
rua has quit [Quit: Leaving.]
03:27
rz has quit [Ping timeout: 480 seconds]
04:26
rz has joined #openwrt-devel
06:59
rz has quit [Ping timeout: 480 seconds]
07:11
_lore_ has quit [Ping timeout: 480 seconds]
08:58
robimarko has joined #openwrt-devel
09:24
<
f00b4r0 >
robimarko: congrats for your hard work! Let's ship it :)
09:24
<
robimarko >
f00b4r0: Just did it, lets see what breaks :)
09:25
<
robimarko >
Probably a good idea to refresh the default feed hashes
09:26
<
f00b4r0 >
#14619 should be a walk in the park in comparison
09:27
<
robimarko >
Making git clones reproducible was a major pain
09:27
<
robimarko >
Ansuel did his magic on that
09:27
<
f00b4r0 >
yeah I think we probably want to announce on m-l/wiki that we're switching away from xz so that packages maintainers know what to expect
09:27
<
f00b4r0 >
yeah that was really cool
09:28
<
f00b4r0 >
i'll test #14619 on top of current master to make sure nothing broke there
09:28
<
robimarko >
that would be great
09:28
<
f00b4r0 >
let's make use of all these idle cpu cores :)
09:31
<
stintel >
yay, eth0 link up on EAP683-LR, no traffic though
09:32
<
stintel >
and no GPL dump on the TP-Link website
09:34
<
f00b4r0 >
robimarko: from a clean master checkout, I git am'd 14619, fetched config.buildinfo from x86/64, ran make defconfig and just fired make -j`nproc`
09:34
<
f00b4r0 >
i didn't bother with feeds to make the test a bit speedier since feeds are orthogonal to the changes tested
09:34
<
robimarko >
Yeah, I ignored the feeds for this PR as well
09:34
<
f00b4r0 >
this should essentially reproduce a buildbot image build
09:35
<
f00b4r0 >
result expected in ~50mn
09:43
<
f00b4r0 >
we'll get some numbers on memory usage as well, which'll be interesting
09:49
<
robimarko >
packaging repos is much faster
09:57
<
f00b4r0 >
gdb and binutils failed to build. /me checks
09:57
<
f00b4r0 >
compress.c:24:10: fatal error: zstd.h: No such file or directory
09:58
<
f00b4r0 >
that's in gdb-14.1/bfd
09:58
<
robimarko >
Ugh, I just built the whole toolchain
10:00
<
f00b4r0 >
no zstd.h in staging_dir/host/include
10:01
<
robimarko >
Hm, so it could be getting header from my host then?
10:01
<
f00b4r0 >
quite likely
10:02
<
f00b4r0 >
I don't have libzstd-dev installed
10:03
<
robimarko >
Ugh, indeed header is not getting installed
10:05
<
robimarko >
Yeah, install-includes is not called
10:06
<
robimarko >
Yeah, just testing it out
10:08
<
f00b4r0 >
lemme know when I should pull and restart test
10:09
<
f00b4r0 >
don't bother looking, it's the same thing
10:11
<
robimarko >
f00b4r0: fix pushed
10:12
<
f00b4r0 >
btw we didn't document why we use install-pc install-static
10:12
<
robimarko >
Because if just install was used then shared library would be installed as well
10:13
<
f00b4r0 >
gdb builds
10:14
<
f00b4r0 >
it seems gcc is still using xz, I caught an xzcat something on top
10:15
<
robimarko >
GCC is still fetched as XZ
10:15
<
f00b4r0 >
one thing at a time i guess :)
10:16
<
robimarko >
I just love how people start commenting on merged changes while they had 0 comments on a PR that has been open for a long time
10:17
<
f00b4r0 >
just ignore them :P
10:17
<
f00b4r0 >
also zstd takes a few seconds to build, this is completely irrelevant
10:19
<
f00b4r0 >
just ignore the noise
10:24
<
f00b4r0 >
toolchain built
10:24
<
robimarko >
Buildbots were fast, they caught the commit before zstd was fixed
10:24
<
f00b4r0 >
probably a couple bots ended their run at the time you pushed
10:25
<
f00b4r0 >
good thing it's caturday and nobody's paying attention ;D
10:25
<
robimarko >
Yeah, unlucky timing
10:26
<
robimarko >
Do I not understand english or?
10:26
<
f00b4r0 >
building target/linux atm. I'm quite ahead of the bots so we should be able to catch any remaining nasties
10:26
<
robimarko >
ZSTD readme clearly states that Make is the only official build system
10:26
<
f00b4r0 >
robimarko: just ignore the guy
10:26
<
f00b4r0 >
it's falling on deaf ears
10:27
<
robimarko >
BTW, I should really make some minimal docker image without anything other than minimal prereq to build stuff
10:27
<
f00b4r0 >
yeah; i've been thinking exactly the same
10:27
<
f00b4r0 >
though I keep my buildbox very lean for that reason
10:28
<
robimarko >
Cause even minimal Alpine wasnt enough since it has zstd
10:28
<
f00b4r0 >
i'll try to time make tools/zstd/compile in buildbot conditions if other make silly comments about which build scheme we're using.
10:28
<
f00b4r0 >
target built
10:28
<
f00b4r0 >
it's almost over
10:30
<
robimarko >
That PR should work as its just changing the compression for IB and SDK
10:30
<
f00b4r0 >
but it's using --ultra -20, the important info will be mem usage I think
10:30
<
robimarko >
We are currently using --ultra -20 for all packaging
10:31
<
f00b4r0 >
true. But IB/SDK aren't exactly small :)
10:31
<
\x >
ximi shipping 1GB ram on these
10:32
<
f00b4r0 >
xdp-tools still fails to build
10:32
<
f00b4r0 >
it's been failing for me forever
10:32
<
robimarko >
Yeah, that thing has been broken
10:32
<
f00b4r0 >
how come it builds on buildbots though
10:32
<
robimarko >
I think there is a huge PR trying to fix it
10:33
<
robimarko >
Basically I think its picking up stuff from the host
10:33
<
robimarko >
OMG, we have package that is being fetched from SVN
10:33
* f00b4r0
disables xdp, restarts build
10:34
<
robimarko >
make package/download failed and it turns out I dont have subversion client at all
10:37
<
robimarko >
All builds will fail as they just managed to pick the same commit
10:37
<
f00b4r0 >
let's pretend it never happened :)
10:38
<
robimarko >
Luckily its early in the process
10:38
<
robimarko >
So they will move on quickly
10:38
<
f00b4r0 >
and luckily we caught it before the first failures so the next run will be good
10:38
<
f00b4r0 >
package/install finishing here
10:39
<
f00b4r0 >
doing sdk/install I saw a few calls to xz in top
10:40
<
f00b4r0 >
we might have some leftover cruft
10:40
<
f00b4r0 >
zstd topped out at 2.7G use
10:41
<
f00b4r0 >
all good!
10:43
<
f00b4r0 >
robimarko: for the record: time make -j8 tools/zstd/compile real 0m32.589s
10:44
<
f00b4r0 >
anyone who gives you shit about using make, just tell them that ;P
10:44
<
f00b4r0 >
(cpu is old - E5-2697 v2)
10:45
<
f00b4r0 >
and time given icludes libdeflate build
10:46
<
robimarko >
libdeflate is extremely quick
10:46
<
robimarko >
zstd as well
10:46
<
stintel >
ah this EAP683-LR is not playing along :(
10:46
<
stintel >
tried both mac@0 and mac@1 but no traffic in either direction afaict
10:47
<
robimarko >
stintel: TP-Link has an GPL email that you can request sources for devices that dont have them listed
10:47
<
stintel >
already done ;)
10:48
<
f00b4r0 >
robimarko: so I see why there was xz calls: toolchain is still packaged as xz
10:49
<
robimarko >
f00b4r0: nice catch
10:51
KGB-2 has quit [Remote host closed the connection]
10:55
<
f00b4r0 >
llvm is also packaged as xz
10:55
<
f00b4r0 >
these were the only two hits found in find bin -iname '*.xz'
10:58
KGB-2 has joined #openwrt-devel
11:00
<
robimarko >
Ok, now buildbots are failling on cp: cannot stat '/builder/shared-workdir/build/build_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-13.2.0_musl_eabi/gdb-14.1/gdb/data-directory/python': No such file or directory
11:00
<
f00b4r0 >
sounds like disk full
11:02
<
f00b4r0 >
ls: cannot access 'build_dir/toolchain-x86_64_gcc-13.2.0_musl/gdb-14.1/gdb/data-directory/python': No such file or directory
11:02
<
f00b4r0 >
that didn't fail the build though
11:02
<
f00b4r0 >
i have a 'stamp-python' in that folder
11:04
<
robimarko >
One more thing that doesnt fail locally
11:05
<
f00b4r0 >
i have to admit I can't make sense of that one
11:05
<
f00b4r0 >
i don't see how it could be remotely related to your changes
11:07
<
f00b4r0 >
I think it's unrelated but I think I've found the bug
11:07
<
f00b4r0 >
ifneq ($(CONFIG_GDB_PYTHON),)
11:08
<
robimarko >
But its been like that for 3 years
11:08
<
f00b4r0 >
# CONFIG_GDB_PYTHON is not set
11:09
<
f00b4r0 >
wanna bet python was indirectly pulled in by something else through xz?
11:09
<
f00b4r0 >
so the makefile is broken and that's why it fails
11:09
<
f00b4r0 >
have to run now, feel free to try a patch if you have time :)
11:14
<
robimarko >
Gotta run now, will fixup in the evening
11:20
vincejv has quit [Ping timeout: 480 seconds]
11:25
goliath has joined #openwrt-devel
11:45
dannyAAM has joined #openwrt-devel
11:46
dannyAAM has quit []
11:47
<
f00b4r0 >
so looking again, the 'cp' is prefixed with '-' so it shouldn't fail
11:48
dannyAAM has joined #openwrt-devel
11:49
<
f00b4r0 >
ha, the error is actually higher up in the log
11:51
<
f00b4r0 >
phtread symbols not found
11:53
<
f00b4r0 >
there's a -lpthread missing on that libtool line
11:54
<
f00b4r0 >
wild guess, we have HAVE_PTHREAD=1 in zstd build, it probably needs to have -lpthread when -lzstd is set
11:55
<
f00b4r0 >
wonder why this didn't break locally
11:55
<
f00b4r0 >
-pthread*
11:56
<
f00b4r0 >
staging_dir/host/lib/pkgconfig/libzstd.pc specifies -pthread in Libs.private
11:57
<
f00b4r0 >
I suspect this is related to using a static build
11:57
<
f00b4r0 >
Ansuel: ping?
12:06
<
Ansuel >
f00b4r0 pong?
12:06
<
f00b4r0 >
see above
12:06
<
Ansuel >
did you manage to find the cause?
12:06
<
f00b4r0 >
i think we have a dependency issue
12:06
<
f00b4r0 >
I don't fully understand why we're doing a static build but I suspect that's part of the problem
12:07
<
Ansuel >
it wasn't a problem with gdb ?
12:08
<
f00b4r0 >
it calls -lzstd but without -pthread and so pthread symbols (from libzstd presumably) are unresolved
12:09
<
f00b4r0 >
or it's pulling something from the host (since I didn't trigger this problem locally)
12:10
<
Ansuel >
Libs: -L${libdir} -lzstd
12:10
<
Ansuel >
Libs.private: -pthread
12:10
<
f00b4r0 >
yes that's what I pointed out. But obviously the Libs.private isn't being used here
12:11
<
f00b4r0 >
I just checked, the POOL_* symbols are from libzstd.a
12:12
<
f00b4r0 >
so it has an implicit dep on pthread which isn't passed to subsequent builds
12:12
<
f00b4r0 >
I have zero pkg-config skills so I don't know how to fix that
12:12
<
Ansuel >
Libs.private: The link flags for private libraries required by this package but not exposed to applications. The same rule as Cflags applies here.
12:12
<
Ansuel >
-pthread should be moved to libs with static probably
12:12
<
Ansuel >
let me check zstd
12:13
<
Ansuel >
When linking a POSIX program with a multithreaded version of libzstd, note that it's necessary to invoke the -pthread flag during link stage.
12:14
<
Ansuel >
but i though that was handled in pkg-config
12:14
<
f00b4r0 >
it probably is handled for the shared lib
12:15
<
f00b4r0 >
but we're doing something extra special here
12:15
<
f00b4r0 >
"When building with make, by default the dynamic library is multithreaded and static library is single-threaded (for compatibility reasons)."
12:15
<
f00b4r0 >
I'm going to bet these "compatibility reasons" are what we're seeing now :)
12:16
<
f00b4r0 >
note: "Force enable multithreading on both dynamic and static libraries by appending -mt to the target, e.g. make lib-mt"
12:16
<
f00b4r0 >
maybe that's what we should be using?
12:17
<
f00b4r0 >
i.e. +$(MAKE) $(HOST_JOBS) -C $(HOST_BUILD_DIR)/lib-mt install-pc install-static PREFIX=$(HOST_BUILD_PREFIX)
12:23
<
stintel >
ping dangole
12:26
<
f00b4r0 >
Ansuel: I suspect that the reason why it didn't fail locally is because I have libzstd1 installed and it probably picked that up instead of the staging_dir one. This suggests we still pull in host bits, alas
12:31
<
Ansuel >
thing is gdb worked previusly right?
12:31
<
Ansuel >
and zstd was still used as a dependency
12:31
<
f00b4r0 >
it wasn't built the same way
12:32
<
f00b4r0 >
specifically, I don't think it was statically built (or it's not obvious from the build recipe)
12:32
<
Ansuel >
yes it was
12:32
<
f00b4r0 >
then maybe the pc was different?
12:32
<
Ansuel >
check the meson build args
12:32
<
stintel >
looking at this patch: mtd: ubi: provide NVMEM layer over UBI volumes
12:32
<
Ansuel >
i have an old buildroot so i'm checking just that
12:33
<
stintel >
the EAP683-LR has mt76 caldata in a file on UBI filesystem
12:33
<
Ansuel >
Name: libzstd
12:33
<
Ansuel >
Description: fast lossless compression algorithm library
12:33
<
Ansuel >
Version: 1.5.5
12:33
<
Ansuel >
Libs: -L${libdir} -lzstd -pthread
12:33
<
f00b4r0 >
well I don't know if '-Ddefault_library=static' has the same consequences as 'make install-static'
12:33
<
Ansuel >
Cflags: -I${includedir} -pthread
12:33
<
stintel >
I'm just not seeing how to refer to a filename with nvmem-layout
12:33
<
f00b4r0 >
there you go
12:33
<
Ansuel >
well yep meson pkg-config just adds -pthread
12:33
<
stintel >
maybe I do
12:33
<
f00b4r0 >
Ansuel: maybe make lib-mt is the fix?
12:33
<
f00b4r0 >
given the README suggestion
12:34
<
Ansuel >
IMHO it's more of a problem in the makefile and meson fixing it under the hood
12:34
<
f00b4r0 >
oh we already do lib-mt
12:35
<
f00b4r0 >
Ansuel: well at least we know
*where* the problem is :)
12:35
<
Ansuel >
i have the downstream patch ready to fix the pc.in file
12:35
<
Ansuel >
but i'm searching if my theory about meson doing STUFF is correct
12:36
<
Ansuel >
ok yep meson pkgconfig logic is totally different...
12:37
<
Ansuel >
maybe I can create a not shit enough patch to have this merged in zstd
12:38
<
f00b4r0 >
Ansuel: goes to show that using 3rd-party build recipes may be another vector ;P
12:39
<
f00b4r0 >
but I agree this should probably be fixed upstream Makefile
12:43
<
f00b4r0 >
Ansuel: that aside we really need to harden our build recipe to stop using standard library search path. Dunno if it can easily be done though
12:45
<
Ansuel >
it's possible... my dream some month ago was to swich our ci to use an alpine image
12:46
<
Ansuel >
but the fact that alpine use musl instead of glibc cause some trouble with our host tools
12:46
<
Ansuel >
there is alpine-debian but mhe...
12:46
<
f00b4r0 >
robimarko pointed out earlier that even minimal-alpine has zstd
12:46
<
Ansuel >
some user also use nix since there were some commit that fixed some bugs with it
12:47
<
f00b4r0 >
I think unless we can be absolutely sure we forbid the default search path for ld, we will never be safe, regardless of the underlying os
12:51
<
f00b4r0 >
just a handful more builds to fail and then we should have quiet again ;)
12:53
<
Ansuel >
did you manage to repro the bug ?
12:54
<
f00b4r0 >
Ansuel: I can't, due to having libzstd locally
12:55
<
f00b4r0 >
and I can't uninstall that because world+dog depends on it
12:55
<
f00b4r0 >
i would have caught the issue earlier otherwise, but my testbuild of master+#14619 went through mighty fine
12:56
<
f00b4r0 >
testbuild == buildbot .config
12:59
<
f00b4r0 >
ugh, Nick Hainke pushed a revert. The failure dance is restarted
13:00
<
f00b4r0 >
lets' pause the buildbots maybe?
13:01
<
f00b4r0 >
Ansuel: I'd suggest pushing a quick temporary patch to pc.in to add -pthread and then revisit with an upstream fix later, maybe?
13:02
<
Ansuel >
yep just pushed the commit (i verified the generated .pc match the one from meson)
13:02
<
f00b4r0 >
oh you did even better
13:02
<
Ansuel >
and i'm creating a branch and proposing this upstream
13:03
<
f00b4r0 >
very cool
13:07
<
f00b4r0 >
we'll have another 3 failures then the builders will catch the current HEAD
13:09
<
Ansuel >
only 5 minutes to make it fail
13:11
<
Ansuel >
but still it does fail on gdb wonder why...
13:11
<
f00b4r0 >
these are still old failures
13:11
<
f00b4r0 >
ignore them
13:13
<
f00b4r0 >
there will be one more
13:14
<
f00b4r0 >
or maybe not ;)
13:16
<
Ansuel >
mhhh no new build got triggered?
13:16
<
f00b4r0 >
it should happen any moment now
13:16
<
f00b4r0 >
tree must be stable for 15mn before builds are triggered, and we just crossed that
13:20
<
Ansuel >
there we go
13:21
<
Ansuel >
btw the ccache thing is run locally and wiped every time?
13:21
<
f00b4r0 >
i'm not sure I understand?
13:21
<
Ansuel >
2 s property 'ccache_command' set6 ccache
13:21
<
Ansuel >
we use ccache on buildbot?
13:22
<
f00b4r0 >
only for tool
13:24
<
f00b4r0 >
tools and tar, actually
13:29
<
Ansuel >
oh ok now i have to understand why the hell nginx is broken on mips -.-
13:30
<
f00b4r0 >
heh, can't help you with that I'm afraid
13:31
<
Ansuel >
got triggered when LTO was enabled
13:31
<
Ansuel >
but only for mips...
13:32
<
f00b4r0 >
oh zstd have a soul-sucking CLA
13:34
<
f00b4r0 >
well it seems to be telling you exactly what it wants? :)
13:42
<
f00b4r0 >
toolchain built successfully on buildbost
13:43
<
Ansuel >
well it seems the patch did the trick
13:43
enyc has quit [Ping timeout: 480 seconds]
13:44
<
f00b4r0 >
Ansuel: re your build failure, I suspect it may be related to different flags passed to gcc between object build and final link
13:44
<
f00b4r0 >
specifically, -fPIC is missing from the latter
13:44
<
stintel >
aha, got wifi working on the EAP683-LR
13:45
<
f00b4r0 >
iirc when using LTO, great care must be taken for consistent build flags or shit may happen
13:49
<
Ansuel >
mhhh where did you notice -fpic is missing?
13:50
<
f00b4r0 >
look at the few lines above the beginning of the error messages
13:51
<
f00b4r0 >
and the ones above that that do the link step (gcc -o FOO.so FOO.o BAR.o BAZ.o etc)
13:51
<
f00b4r0 >
none of these specify -fPIC, but all the objects are built with -fPIC (further up in the log)
13:52
<
f00b4r0 >
i think that's why it fails and why it complains that you need to recompile with -fPIC
13:56
<
f00b4r0 >
put differently: the objects were built for position independent code, but the final shared object isn't. That's why it fails (i think)
13:56
<
f00b4r0 >
anyhow, I'm off; bbiaw
13:57
<
Ansuel >
oh wow core is not build -fpic but addons are
13:58
<
stintel >
time to run dl_cleanup it seems
14:00
<
stintel >
holy shit already running for 3 minutes
14:00
<
stintel >
this was long overdue
14:02
rua has joined #openwrt-devel
14:06
<
Ansuel >
ok good i at least manage to repro the error
14:07
skynet2 has joined #openwrt-devel
14:14
dangole has joined #openwrt-devel
14:23
<
f00b4r0 >
Ansuel: also beware that -fpic != -fPIC
14:26
<
f00b4r0 >
stintel: i didn't even know about dl_cleanup ;P
14:26
<
stintel >
now you do ;)
14:27
<
f00b4r0 >
rm -rf works just fine :D
14:27
<
stintel >
right I was going to grab my laptop and connect to the EAP683-LR via Wi-Fi so I can take a nanddump
14:30
<
stintel >
or maybe just do client mode
14:35
<
stintel >
nanddump: error!: mtd_get_dev_info failed
14:37
<
svanheule >
mirko: the GS1900-24E(P) is a different form factor than the GS1900-24(P), so that port order may be a restriction of the PCB layout. And I agree that poe_enable node isn't pretty
14:37
rz has joined #openwrt-devel
14:38
<
svanheule >
mirko: uart1 being defined-but-disabled is because, as part of the SoC, it is always present (but not always used)
14:41
<
Ansuel >
f00b4r0 well -fPIC was present in cflags but missing in ldflags
14:41
<
Ansuel >
aka it was missing on linking
14:41
<
f00b4r0 >
this explains that
14:49
skynet2 has quit [Ping timeout: 480 seconds]
14:52
skynet2 has joined #openwrt-devel
15:00
rua has quit [Remote host closed the connection]
15:01
rua has joined #openwrt-devel
15:09
<
Ansuel >
ahhh so much green
*.*
15:19
<
stintel >
dangole: for that caldata on ubifs, would it be acceptable to configure the ubi volume containing the ubifs in the DTS, so that it's attached during boot, or would you handle attach and mount also in userspace ?
15:21
<
stintel >
dangole: also, do you have any suggestions to try to make ethernet work? link is detected but I'm not seeing any traffic, tried both mac@0 and mac@1, no GPL dump available, I've requested it from TP-Link today
15:35
<
f00b4r0 >
so it turns out gnu git repos are accessible over http
15:35
* f00b4r0
is going through the remaining .tar.xz tools
16:04
<
stintel >
ah, putting the ubi factory volume in the dts causes that to be ubi0, and then boot fails because there is no /dev/ubiblock0_0
16:22
minimal has joined #openwrt-devel
16:49
robimarko has joined #openwrt-devel
16:54
<
f00b4r0 >
robimarko: so I took a look at the remaining tools Makefiles that pull .tar.xz
16:55
<
f00b4r0 >
turns out the gnu utils are available over http(s) git
16:55
<
f00b4r0 >
and the others are on GH
16:55
<
f00b4r0 >
dunno if it's worth the effort
16:56
<
robimarko >
Not really sure
16:56
<
robimarko >
BTW, I am looking at IRC log
16:56
<
robimarko >
What was the root cause of GDB python?
16:56
<
f00b4r0 >
it wasn't the cause of failure
16:57
<
f00b4r0 >
the cause of failure was missing -pthread LDFLAG
16:57
<
f00b4r0 >
which I traced down to using the statically linked variant of zstd, but which shipped a .pc that didn't pass the flag
16:57
<
robimarko >
Oh, I am reading the commit now
16:57
<
f00b4r0 >
Ansuel kindly cooked a patch
16:57
<
robimarko >
Its rather crazy
16:58
<
f00b4r0 >
it took a bit of rabbit-holeing yeah :)
16:58
<
robimarko >
Speaking of rabbit-holes
16:59
<
f00b4r0 >
robimarko: btw if you want to convert llvm-bpf package, I think it's the only one missing
16:59
<
robimarko >
Somehow this random package hash is broken still
17:00
<
f00b4r0 >
sms-tools?
17:03
<
f00b4r0 >
lets see if I can repro
17:04
<
f00b4r0 >
could this be an apk-related thing?
17:05
<
f00b4r0 >
it uses PKG_SOURCE_DATE
17:08
<
robimarko >
It shouldnt, not for the hash
17:08
<
f00b4r0 >
actually, unfold the errors
17:09
<
f00b4r0 >
it tries to dl .tar.xz, fails that, falls back to git, then the check compares with .tar.xz
17:09
<
f00b4r0 >
so of course that's going to fail
17:09
<
robimarko >
Its probably outdated tooling
17:09
<
robimarko >
Cause buildbots just kicked in high gear
17:10
<
robimarko >
Cause I think they are using SDK for the tests
17:12
<
f00b4r0 >
i can't reproduce locally. make check passes
17:12
<
f00b4r0 >
oh wait stupid me
17:12
<
f00b4r0 >
Im' not testing the PR
17:13
<
f00b4r0 >
same player tries again
17:16
<
f00b4r0 >
still works
17:17
<
robimarko >
OK, lets give buildbots some time to generate all of the SDK-s
17:17
<
robimarko >
As its clearly using one without all of the changes
17:20
dannyAAM has joined #openwrt-devel
17:49
<
hauke >
nbd: I am looking into TLS 1.3 support with mbedtls, I saw that you are also looking into it
17:50
dannyAAM has quit [Remote host closed the connection]
17:52
<
mrnuke >
svanheule: If we can somehow get kernel 6.1 on realtek, I'd be interested to look into adding PSE functionality to the tps23861 driver
17:53
dannyAAM has joined #openwrt-devel
17:53
<
mrnuke >
svanheule: I realize it's just a handful of TP-Link switcces that would benefit
17:57
<
robimarko >
mrnuke: That is just the bare minimum
18:04
<
mrnuke >
robimarko: great! I have a ready-written example :D
19:11
<
svanheule >
mrnuke: robimarko: I'm also looking forward to being able to use the kernel PoE framework :-)
19:12
<
svanheule >
PD692x0 support would be really nice for my Cisco SG220
19:13
<
robimarko >
PD692x0 is quite popular in switches so we chose it for the reference
19:20
<
mrnuke >
svanheule: I haven't been able to follow the thread. Believe it or not, all four of my realtek switches with PoE are in use
20:03
dannyAAM has quit [Remote host closed the connection]
20:03
dannyAAM has joined #openwrt-devel
20:08
<
mrnuke >
Any idea why "mhi mhi0: Image transfer failed" would fail on an IPQ chip? All the references I could fins balme it on "bad firmware"
20:29
<
Mangix >
Ansuel: meson is a lot simpler than Make and CMake. pkgconfig files don't have to be a manual mess.
20:30
<
Mangix >
Besides that, meson benefits from having way better defaults than CMake.
20:35
<
Mangix >
I tried proposing meson versions of core openwrt libraries. Rejected.
20:37
<
mirko >
svanheule: point re port order and splitting dts off into a common part is, that the port order on the 24ep is correct while for the 24e even and uneven port numbers are flipped (according to current DTS at least)
20:38
<
mirko >
hence the common part of the two is rather minimal
20:38
<
mirko >
so i consider the PR valid as it is
20:39
<
Mangix >
hmmm can't find it. From what I remember, core developers were happy with CMake
20:56
<
f00b4r0 >
countless reports of packages updating meson resulting in FTBFS unless you run bleeding edge meson
20:56
<
f00b4r0 >
meson breaking on python update or vice-versa
20:57
<
f00b4r0 >
we don't need such a stable build system I think.
20:57
<
Mangix >
meson breaking on python update?
20:59
<
Mangix >
that is highly specific
20:59
<
Mangix >
Ubuntu 18.04 is no longer supported.
21:00
<
f00b4r0 >
just top of quick search
21:00
<
Mangix >
that's the same bug
21:00
<
f00b4r0 >
yeah and it's great not to be able to build older releases after a few years
21:00
<
f00b4r0 >
such a feature.
21:01
<
f00b4r0 >
I can grab a source archive that uses 'make' from 20y ago and build it just fine.
21:01
<
robimarko >
CMake is also quite good for supporting rather old CMake recipes
21:01
<
robimarko >
For core tools meson changing minimal python is not good
21:02
<
f00b4r0 >
meson is as broken as python is, from a stability PoV. Let's not spread this cancer further
21:02
<
Mangix >
fake news.
21:02
<
f00b4r0 >
robimarko: currently test building your last push to 14619 :)
21:02
<
Mangix >
from working on various packages, meson tends to be the least broken.
21:02
<
f00b4r0 >
for about 2 weeks
21:03
<
f00b4r0 >
then you can no longer build the archive.
21:03
<
robimarko >
Again, what good is it if it decides that python 3.X is now required
21:03
<
Mangix >
robimarko: older versions of meson can be kept in that case. actually, that was the case until 18.04 compatibility was dropped.
21:04
<
f00b4r0 >
meson completely eschew backward compatibility. Therefore it's not suitable as a long term build management.
21:04
<
f00b4r0 >
QED. Let's move on.
21:04
<
Mangix >
f00b4r0: source?
21:04
<
Habbie >
is muon any help here?
21:04
<
robimarko >
Mangix: Yeah, and then we had packages that cannot be updated because they require meson X but it requires python X and so on
21:04
<
f00b4r0 >
openwrt GH
21:04
<
f00b4r0 >
and you just admitted "18.04 is no longer supported" so you know it very well
21:05
<
Mangix >
backwards compatibility with older meson versions?
21:05
<
f00b4r0 >
makefiles don't suddenly stop working with newer make versions
21:05
<
Mangix >
well actually...
21:05
<
f00b4r0 >
I know that may sound incredibly useless to you
21:06
<
Mangix >
I do remember a GNU make update that screwed some packages
21:06
<
f00b4r0 >
"a". Assuming it did happen, I suppose it was quickly fixed?
21:06
<
robimarko >
Mangix: How long did it take for Meson 1.X to be merged?
21:07
<
Mangix >
it was with make 4.3 i believe
21:07
<
Mangix >
f00b4r0: moot point. meson behaviors can also be patched quickly.
21:07
<
f00b4r0 >
no I mean it was fixed in make. Or amply documented and probably only affected some arcane gnu-specific corner cases
21:08
<
f00b4r0 >
anyway, we know you won't hear these arguments so let's agree to disagree
21:08
<
Mangix >
no, the packages using deprecated functionality were patched
21:10
<
f00b4r0 >
robimarko: build successful. I'll report on PR
21:11
<
Mangix >
robimarko: may 23,2023 vs jun 26,2022
21:12
<
robimarko >
Mangix: well the issue was that some packages also depended on that newer meson that we could not use if older distros like 18.04 were to be supported
21:13
<
robimarko >
Other of the issue that it usually requires quite new Python I dont have anything against it
21:13
<
robimarko >
If anything I find it rather efficient
21:13
<
Mangix >
upstream maintains support for the older supported Ubuntu LTS
21:13
<
Mangix >
once 18.04 became EOL, meson dropped support for python 3.6
21:14
<
f00b4r0 >
also how often is make updated? Every 2-4 years typically. Much more conservative.
21:14
<
robimarko >
And the issue is that doesnt really align with our release cadence
21:14
<
Mangix >
actually Canonical backpported Python 3.7 and 3.8 so 18.04. I tried getting patches in to keep it supported in OpenWrt. Rejected.
21:15
<
Mangix >
it was decided to kill 18.04 support. Not my decision.
21:20
<
Mangix >
there was also the pkgconfig issue with zstd that Ansuel had to patch in and add a bunch of code while meson just worked.
21:21
<
f00b4r0 >
it's certainly simpler to hide things
21:23
<
Mangix >
hmm? pkgconfig is a manual ordeal with both make and cmake
21:24
<
Mangix >
meson has a generator based on the libraries.
21:39
dannyAAM has joined #openwrt-devel
22:20
slh has quit [Quit: leaving]
22:20
dannyAAM has quit [Remote host closed the connection]
22:21
dannyAAM has joined #openwrt-devel
22:24
slh64 has quit [Quit: gone]
22:46
rz has quit [Remote host closed the connection]
22:47
rz has joined #openwrt-devel
23:00
slh has joined #openwrt-devel
23:03
parazyd has quit [Ping timeout: 480 seconds]