2024-09-01 01:03:04 <celie> Bouncer fail led to replay of old messages, sorry
2024-09-01 05:22:18 <Ariadne> looks like libadwaita is due to mesa not supporting orcjit, but there is mesa 24.2 coming out which has orcjit
2024-09-01 05:22:27 <Ariadne> so maybe we just go to mesa 24.2 git snapshot?
2024-09-01 05:25:43 <cely> There is a mesa MR: !70830
2024-09-01 05:26:07 <cely> But when i tried that, it didn't fix the tests
2024-09-01 05:27:23 <cely> Same test issue affects (at least) !71153, !68002
2024-09-01 06:13:49 <Ariadne> i tried that but i get "unsupported relocation type 14" and cannot determine what that is
2024-09-01 06:18:11 <Ariadne> R_LARCH_TLS_DESC64
2024-09-01 06:20:42 <Ariadne> should be pretty straightforward to teach musl to handle these, other archs already have them
2024-09-01 06:51:35 <Ariadne> workaround for now: add -mtls-dialect=trad to default CFLAGS when building on loongarch
2024-09-01 07:11:18 <Ariadne> cool
2024-09-01 07:11:19 <Ariadne> ok
2024-09-01 07:11:47 <Ariadne> i have confirmed that upgrade mesa to 24.2.1 fixes the libadwaita and other builds
2024-09-01 07:21:29 <mio> for libshumate, the checks can be re-enabled for loongarch64 and riscv64 after mesa is upgraded?
2024-09-01 07:21:48 <mio> or only loongarch64?
2024-09-01 07:26:22 <Ariadne> probably both. the issue with mesa is OrcJIT, which is only supported in the new mesa.
2024-09-01 07:26:58 <Ariadne> though at the moment, the mesa 24.2.1 build is broken for some targets on riscv64, but 70830 fixes it with the GCC fix I just landed
2024-09-01 07:33:00 <mio> cool. will check back on libshumate when mesa upgrade is merged
2024-09-01 08:39:16 <Ariadne> upgrade is a no-go because of riscv64 but looking into getting the relocation type issue alone fixed in mesa, at least that should allow the tests to pass without llvmpipe
2024-09-01 08:42:38 <Ariadne> if my current mesa build passes libadwaita tests i will push that instead for now until we can get riscv64 unblocked for mesa
2024-09-02 02:13:58 <cely> The builder is currently building community/datovka, which produced a 445.1G log file the last time it ran
2024-09-02 03:29:42 <huajingyun> It's been a long time, datovka is still being built
2024-09-02 03:30:35 <huajingyun> ikke:Thanks
2024-09-02 03:34:22 <cely> Yes, datovka very likely isn't going to pass
2024-09-02 03:34:40 <cely> Hopefully, the log won't be bigger than last time
2024-09-02 03:41:44 <huajingyun> I now try to build datovka locally
2024-09-02 03:42:16 <huajingyun> Wondering why there is such a large log file
2024-09-02 07:27:29 <cely> I think i've broke GCC on ppc64le (while trying to fix it, ironically), sorry about that
2024-09-02 07:27:53 <cely> It should be fixed with a pkgrel bump, which i am hoping to do together with enabling GDC for Loongarch
2024-09-02 07:28:30 <cely> So, riscv64 doesn't have to do two 8-hours builds of GCC
2024-09-02 07:52:15 <znley> I failed to build 'community/datovka' on x86_64 and loongarch64.
2024-09-02 07:52:52 <znley> Error messages are same.
2024-09-02 07:53:33 <huajingyun> cely:That's ok, you already know how to fix it
2024-09-02 07:53:53 <znley> I also build datovaka==4.23.7(a lower version), also failed.
2024-09-02 09:27:29 <clandmeter> znley: can you update the MR for openjdk11?
2024-09-02 09:27:39 <clandmeter> you mention we can remove that option?
2024-09-02 09:44:31 <znley> I have updated.
2024-09-02 09:45:05 <znley> Added two options, can only remove one.
2024-09-02 11:04:11 <clandmeter> https://tpaste.us/yYVg
2024-09-02 11:04:44 <clandmeter> this is the problem with datovka
2024-09-02 11:05:10 <clandmeter> -rw-r--r-- 1 buildoze buildoze 955.9G Sep 2 10:58 /var/cache/distfiles/buildlogs/build-edge-loongarch64/community/datovka/datovka-4.23.8-r0.log
2024-09-02 15:25:25 <clandmeter> https://tpaste.us/YYQw current build failures on community
2024-09-03 06:19:22 <huajingyun> Regarding the error “LLVM ERROR: Relocation type not implemented yet!”, do we need to disable checks for loongarch64 and riscv64 first, or continue waiting for !70830 ?
2024-09-03 07:52:15 <cely> For !71345, try https://files.pythonhosted.org/packages/source/j/jaraco_text/jaraco_text-$pkgver.tar.gz instead
2024-09-03 07:53:44 <cely> as we usually don't prefer the URL with the checksum
2024-09-03 07:54:12 <cely> Going AFK, bye
2024-09-03 07:58:01 <huajingyun> cely: done,thanks
2024-09-03 14:07:28 <ncopa> would be good if we could get !70830 fixed. I'm trying to bisect it now
2024-09-03 14:38:21 <ncopa> looks like it was a fix for loongarch that broke riscv64 build: This MR introduced the regression for riscv64: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30599
2024-09-04 03:45:11 <cely> So, GCC Gnat successfully builds testing/gprbuild
2024-09-04 03:47:38 <cely> Will update the patch so if anyone needs it in the future, they can get it bootstrapped (i probably won't be pushing for this, at least for now, as it seems gprbuild is the only aport needing Gnat)
2024-09-04 06:04:09 <huajingyun> cely:Yeah, thank you anyway:)
2024-09-04 06:06:22 <znley> Does anyone know what's going on !71321.
2024-09-04 06:06:39 <znley> It passed on my pc.
2024-09-04 06:06:56 <znley> But all pipelines failed.
2024-09-04 06:13:38 <cely> Somehow, i remembered main/yash
2024-09-04 06:14:46 <cely> I mean, it just popped into my mind
2024-09-04 06:14:51 <cely> Try removing the sticky bit
2024-09-04 06:15:03 <cely> setgid bit*
2024-09-04 06:16:29 <cely> Quite a number of packages in main/ are affected, iirc
2024-09-04 06:18:18 <cely> However, usually the CI is okay, and it's the builders that have that set, causing things to fail
2024-09-04 06:45:11 <cely> I'll be going AFK, bye
2024-09-04 06:47:37 <huajingyun> Bye
2024-09-04 06:53:52 <mps> what does build-edge-tmp-loongarch64, and we have build-edge-loongarch64
2024-09-04 06:54:29 <mps> I guess there are two for good reason but don't know what does second one
2024-09-04 07:18:09 <huajingyun> Currently, build-edge-tmp-loongarch64 is still in the transitional stage. It has built complete packages for all repos. The packages built here will be uploaded to dev.a.o/edge and provided to gitlab CI for use
2024-09-04 07:18:14 <huajingyun> When the official builder(build-edge-loongarch64) has finished all 3 repos (that is, the packages of the 3 repos are uploaded to dl-cdn), it may be considered to be offline
2024-09-04 07:18:23 <huajingyun> So now build-edge-loongarch64 is still in the community, and there will be testing later, so we also need to keep build-edge-tmp-loongarch64
2024-09-04 07:24:21 <mps> thank you for explanation
2024-09-04 07:25:42 <huajingyun> You're welcome
2024-09-04 11:48:57 <cely> mio: mesa 24.2.1 has been merged, and !67997 is now passing, so you can try re-enabling rv64 and loongarch on !71153
2024-09-04 12:42:34 <mio> cely: thanks
2024-09-04 12:47:18 <cely> You're welcome
2024-09-04 12:47:59 <cely> If anyone finds any other MR blocked by tests failing due to mesa, feel free to mention it here
2024-09-04 12:48:23 <cely> I've rebased !68002, and will get it in when CI is green
2024-09-04 15:23:41 <cely> Hmm, the aports enabled in community/ went from 6031 to 6030, so i went looking for the aport that just got disabled, and it is: ima-evm-utils (!71313)
2024-09-04 15:24:29 <cely> Anyway, 1020 aports left to build in community :)
2024-09-04 16:23:13 <cely> We will very likely be able to reach < 1000 aports left soon
2024-09-04 16:32:00 <ncopa> we are less than 1000 \o/
2024-09-04 16:33:36 <cely> 995 aports left :)
2024-09-05 01:10:44 <huajingyun> Nice, now there are 940:)
2024-09-06 02:07:21 <Ariadne> 652 now
2024-09-06 02:48:29 <huajingyun> Yeah, thanks for fixing some more aports
2024-09-06 03:13:59 <qaqland> i tried to update !71507 and loongarch passed, but upstream introduced an overflow bug on 32-bit architecture :(
2024-09-06 03:16:47 <cely> Maybe the libc crate can just be updated to at least 0.2.155
2024-09-06 03:59:58 <cely> I hope i didn't enable some problematic LDC tests that passes in the CI, but not on the builders
2024-09-06 04:00:07 <cely> pass*
2024-09-06 04:05:24 <cely> Ok...at least Loongarch finally moved on to Dub (DLang's package manager)
2024-09-06 04:06:56 <cely> Hmm, 1814 tests ran, in CI it was 1818
2024-09-06 04:07:44 <cely> and the tests only took 45 seconds, so most of the (extra, compared to CI) time was spent building
2024-09-06 04:14:06 <cely> Dub took 7 minutes in CI, i think the tmp builder taking longer may be due to Dub fetching packages to build
2024-09-06 04:14:37 <cely> Ok, now it's done :)
2024-09-06 04:15:01 <cely> x86_64 on the other hand...probably got hit by some long running tests
2024-09-06 04:15:34 <cely> As there's a difference in the number of tests ran in CI and on the builder, i think that may be the issue
2024-09-06 04:17:10 <cely> Oh wait, hmm, just rechecked, and it is 1814 tests for Loongarch on the CI too
2024-09-06 04:17:25 <cely> 1818 was from a previous run, with more tests enabled
2024-09-06 04:18:16 <cely> x86_64 very likely has more tests enabled though
2024-09-06 04:24:02 <cely> For reference, a successful build of community/ldc on x86_64 in CI: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1506408
2024-09-06 04:25:32 <cely> 1822 tests ran, and it took just 20 seconds
2024-09-06 04:25:52 <cely> So, not sure what's going on with the builder
2024-09-06 05:54:18 <huajingyun> Now it looks like everything is built successfully
2024-09-06 05:55:42 <cely> Yes :)
2024-09-06 14:36:16 <cely> Almost reaching 500 aports left to build
2024-09-06 15:57:25 <cely> It seems Loongarch has 1 failing test for SDL2 (testautomation): !71540
2024-09-06 15:57:36 <cely> I'll rerun CI in case the test is just flaky
2024-09-07 01:05:30 <huajingyun> cely: It seems that CI still fails now
2024-09-07 01:07:02 <cely> Yeah, so that's something you all can look into
2024-09-07 01:08:39 <huajingyun> Ok,sure
2024-09-07 01:21:26 <huajingyun> I built sdl2 2.30.7 locally and all tests passed, I am using dl-cdn.a.o/alpine/edge/main and dev.a.o/edge/community/
2024-09-07 01:24:32 <cely> Hmm, ok, i guess it will be up to SDL2's maintainer then what to do about this
2024-09-07 01:28:59 <huajingyun> I updated comment in MR
2024-09-07 01:36:06 <cely> Ok, thanks
2024-09-07 02:04:02 <huajingyun> Does anyone remember which aports reported R_LARCH_TLS_DESC64 related errors on loongarch64?
2024-09-07 02:04:55 <cely> mesa
2024-09-07 02:04:56 <huajingyun> As GCC now TLS descriptors on loongarch64, I don't think I can find them easily
2024-09-07 02:05:59 <cely> Is it mesa you're thinking about?
2024-09-07 02:06:17 <cely> Also, there's now !71529
2024-09-07 02:06:47 <cely> So, maybe mesa won't be built with GCC anymore soon
2024-09-07 02:11:33 <huajingyun> I tried to build mesa 24.2.1 with gcc-14.2.0-r1, but it did not report this error
2024-09-07 02:11:58 <huajingyun> I now have a musl TLSDESC patch that I want to verify
2024-09-07 02:14:15 <cely> It happens when running tests
2024-09-07 02:14:30 <cely> for libadwaita or libshumate, or more likely, both
2024-09-07 02:17:54 <huajingyun> Ok, thanks
2024-09-07 17:51:58 <mio> error in libnids-1.26-r1 might be loongarch64 specific, can't reproduce the issue on x86_64 http://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/libnids/libnids-1.26-r1.log
2024-09-08 05:05:25 <Ariadne> needs update_config_sub
2024-09-08 05:11:28 <mio> https://git.alpinelinux.org/aports/tree/community/libnids/APKBUILD#n17 ? or like https://github.com/MITRECND/libnids/pull/12/files ?
2024-09-08 05:11:54 <mio> lol nvm
2024-09-08 05:12:02 <mio> thanks for handling that
2024-09-09 06:58:17 <znley> cely: I got "aports-openjdk8-corretto/community/openjdk8-corretto/pkg/openjdk8-corretto/usr/lib/jvm/java-1.8-openjdk/jre/lib/jfr.jar': No such file or directory" when build openjdk8-corretto.
2024-09-09 06:58:49 <znley> This happend at ">>> openjdk8-corretto-jre-lib*: Running split function jrelib..."
2024-09-09 07:03:47 <cely> Ok
2024-09-09 07:06:36 <cely> This is very likely due to using amove with an absolute path
2024-09-09 07:07:06 <cely> $_java_home begins with /, so the `*` is expanded wrongly
2024-09-09 07:07:38 <cely> I think this should be solved by changing the two instance of `*.jar` in jrelib() to `\*.jar`
2024-09-09 07:08:22 <znley> I add '--disable-jfr' for configuration according community/openjdk8, but it didn't solve.
2024-09-09 07:09:42 <cely> No, this issue happens after package() when the subpackages are built
2024-09-09 07:09:59 <cely> So, try changing escaping `*.jar` to `\*.jar`
2024-09-09 07:10:59 <znley> Ok, Magical amove.
2024-09-09 07:11:00 <cely> It is expanding *.jar to jfr.jar from the host compiler due to $_java_home beginning with /, this is one of the problems with using amove with an absolute path
2024-09-09 07:11:50 <cely> (if the absolute path exists, globs are expanded wrongly)
2024-09-09 07:13:32 <znley> Thanks, this solved it, I knew very little about abuild.
2024-09-09 07:15:03 <cely> You're welcome
2024-09-09 07:25:21 <ikke> This is just a shell thing
2024-09-09 07:33:37 <cely> So, here's my findings from a weekend of trying to get openjdk8 to build
2024-09-09 07:34:49 <cely> Alpine's community/openjdk8 uses icedtea, which introduces some complications for cross-compiling, so the method that worked for openjdk17/21 doesn't work for community/openjdk8 (icedtea)
2024-09-09 07:35:10 <cely> and i think i've read somewhere that icedtea actually builds the jdk twice
2024-09-09 07:36:03 <cely> Which means openjdk8 bootstrap will probably have to involve an intermediary openjdk, and i've been looking for that, Amazon Corretto was the first to work for me
2024-09-09 07:36:56 <cely> and i've been puzzled why others can't build, in the end, it turns out that the others have build scripts that depend on some GNU sed behavior
2024-09-09 07:38:31 <cely> add GNU sed to makedepends_build, and it seems all the other JDKs start building properly, i'm currently running Adoptium Temurin through CI, and it seems to work too (but with more patches required than Corretto)
2024-09-09 07:39:44 <cely> (the other JDK versions that we have in aports do not depend on GNU sed anymore)
2024-09-09 07:41:30 <cely> With GNU sed in makedepends, i think even https://github.com/openjdk/jdk8u will work, after the correct set of patches needed has been determined
2024-09-09 07:44:11 <cely> So, my current through process is: Icedtea on x86_64 cross-compiles Corretto (or some other JDK8), then Corretto bootstraps Icedtea on Loongarch
2024-09-09 07:45:15 <cely> Going AFK now, bye
2024-09-09 09:05:34 <znley> Greet job.
2024-09-09 09:57:22 <ncopa> do we need openjdk8 for loongarch?
2024-09-09 10:00:31 <ncopa> i think we have kept openjdk8 so we didnt need to do manual bootstrap
2024-09-09 11:26:20 <cely> ncopa: We already have openjdk8 enabled for loongarch, it just hasn't been bootstrapped on the official builder
2024-09-09 11:27:07 <cely> and disabling it would mean disabling almost all of the Java aports
2024-09-09 11:48:42 <ncopa> aha
2024-09-09 16:33:38 <Ariadne> cely: afaik there are patches for GCC 6 that make it support loongarch and risc-v?
2024-09-09 16:33:54 <Ariadne> if so we can use gcj to bootstrap openjdk8
2024-09-09 17:44:13 <cely> You will have to ask Jingyun about GCC 6, i don't know about it, sorry
2024-09-09 17:44:58 <cely> Even if GCC 6 works on Loongarch, are we sure gcj will be able to boostrap the version of openjdk8 we currently have?
2024-09-09 17:45:43 <cely> I have already spent a lot of time on Corretto, and i think it should work
2024-09-09 17:46:53 <cely> If anyone else has some time to spare, instead of looking into gcj from an old GCC, maybe find out why openjdk8 cannot be cross-compiled now
2024-09-09 17:46:58 <cely> It was done before
2024-09-09 17:47:28 <cely> but apparently no one is able to get it to work again
2024-09-09 17:51:49 <cely> (and yes, this is very likely partly due to the fact that when the first bootstrap was done, we were not aware that it would have to be done again, otherwise more details records would've been kept)
2024-09-09 17:52:34 <cely> s/details/detailed/
2024-09-09 18:38:24 <Ariadne> we bootstrapped with gcc6
2024-09-09 18:38:38 <Ariadne> gcc6 -> gcj -> ecj -> openjdk7 -> openjdk8
2024-09-10 00:14:36 <znley> The original openjdk8 of loongarch64 was enabled by me, but I compiled it manually.
2024-09-10 00:15:52 <znley> The compilation process was quite difficult, and it was not even completed in the end, only a certain stage of compilation was completed.
2024-09-10 00:16:52 <znley> Then I used this unfinished openjdk8 to successfully native build on loongarch64.
2024-09-10 00:17:26 <znley> This is where the first version came from, but it actually didn't work for bootstrap.
2024-09-10 00:29:08 <celie> If the GCJ bootstrap path has to involve JDK7, then i think that's a big roadblock itself
2024-09-10 00:30:07 <celie> Even if we could find the required GCC 6 patches to get it to work on Loongarch, and then in turn got GCJ and ECJ working, JDK7 has no support for Loongarch, as far as i know
2024-09-10 00:38:39 <znley> I also think this introduces too much complexity。
2024-09-10 00:43:26 <znley> Either keep openjdk8 of loongarch64 non-bootable, or consider using openjdk8-corretto instead of openjdk8.
2024-09-10 00:57:43 <huajingyun> I agree with cely, we are already working on openjdk8-corretto and this can make openjdk8 work properly
2024-09-10 01:03:33 <huajingyun> Ariadne: We do not have patches for GCC 6, upstream support for loongarch64 since GCC 12
2024-09-10 01:04:05 <Ariadne> (i'm talking about openjdk in alpine to begin with)
2024-09-10 01:07:43 <huajingyun> Oh, So the original openjdk in alpine was bootstrapped with gcc6
2024-09-10 04:59:53 <cely> I just found out something, it seems s390x and 32-bit arm* are also using zero variant for openjdk8, it seems icedtea does that for you, without you having to specify --with-jvm-variants (community/openjdk11/17/21 has this)
2024-09-10 05:23:59 <cely> So, that is probably the deeper meaning behind "oracle dropped support for 32 bit"
2024-09-10 05:24:29 <cely> and people wonder why other distros are still able to package 32-bit JDKs :)
2024-09-10 05:28:30 <cely> Very likely the situation is similar to that of GHC, where i think i've seen other distros build it in "unregisterised" mode just to enable it on more archs (s390x being one of them, iirc)
2024-09-10 05:35:20 <cely> and this also answers why some archs took more than 6 hours to build community/abcl, all those are on zero variant (i switched to using openjdk11 for s390x back then, and now i know it is because jdk11 is where s390x got support for server variant)
2024-09-10 05:42:19 <cely> The speed difference is really apparent, what takes server variant 15 minutes or less to complete, will take more than an hour on zero variant
2024-09-10 05:47:26 <cely> Looking around icedtea's $builddir, i see openjdk.build-boot and openjdk.build directories, so that probably means icedtea builds openjdk in 2 stages
2024-09-10 05:48:04 <cely> and the file list seems to be the same
2024-09-10 06:58:06 <huajingyun> Thanks cely, openjdk8-corretto has been built successfully on tmp builder
2024-09-10 06:58:12 <huajingyun> It would be great if someone could cross-build an openjdk8-corretto bootstrap for the official loongarch64 builder
2024-09-10 13:06:38 <cely> 99 aports left to build :)
2024-09-10 15:05:52 <ikke> toss one down, spin it around
2024-09-10 15:42:57 <mio> ... 99 aports left on the wall
2024-09-10 15:43:23 <ikke> That does not sound like progress
2024-09-10 15:43:29 <ikke> :P
2024-09-10 15:44:03 <mio> lol it actually happened for a short while yesterday at the 110 mark, went back up to 112 briefly
2024-09-10 15:45:36 <mio> that said, there are a few more MRs in the queue so it should come back down again later
2024-09-10 15:46:46 <ikke> It's now in 86 btw
2024-09-10 15:48:24 <mio> maybe we could get it to 80 or 75 today
2024-09-10 15:51:48 <cely> If anyone wants to try openjdk8 bootstrap, this is the command i used: `EXTRADEPENDS_BUILD="build-base-loongarch64" EXTRADEPENDS_TARGET="libgcc libstdc++-dev musl-dev" CHOST=loongarch64 BOOTSTRAP=bootimage abuild -r`
2024-09-10 15:51:59 <cely> Probably it will work even without BOOTSTRAP set
2024-09-10 15:53:29 <cely> Packages i have in ~/packages were probably leftover from running the normal bootstrap.sh, and also https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk-bootstraps
2024-09-10 15:54:45 <cely> What znley and i tried was cross-compiling openjdk8-corretto first, and then using that to build community/openjdk8 (which is now disabled for Loongarch)
2024-09-10 15:55:56 <cely> That's because openjdk8 uses icedtea, which builds jdk8 in 2 stages, and i think one of the stages is failing when cross-compiled (znley tried it, but i didn't)
2024-09-10 16:01:27 <cely> After openjdk8-corretto is available, community/openjdk8 can be re-enabled, and it should build itself with corretto without needing any further interaction
2024-09-10 16:06:40 <ikke> I don't have time now, but which package needs to be bootstrapped like that?
2024-09-10 16:06:56 <cely> community/openjdk8-corretto
2024-09-10 16:07:03 <ikke> right
2024-09-10 16:07:38 <ikke> But right now it will fail because openjdk8-bootstrap is not available?
2024-09-10 16:07:53 <cely> Yes
2024-09-10 16:08:36 <ikke> So should we remove that from the makedepends then?
2024-09-10 16:08:44 <cely> openjdk8-corretto provides openjdk8-bootstrap, and it will be able to bootstrap itself
2024-09-10 16:09:26 <ikke> abuild -r will try to install openjdk8-bootstrap, which does not exist
2024-09-10 16:10:01 <cely> I think you might be looking at community/openjdk8
2024-09-10 16:10:12 <cely> openjdk8-corretto has the -bootstrap package in makedepends_build
2024-09-10 16:11:21 <ikke> I had the correct one open, but I don't cross-compile that often, so forgot the implications of makedepends_build
2024-09-10 16:12:49 <cely> A complicating factor to cross-compiling openjdk is that it needs all those X11/cups/alsa libs in sysroot, which are not built by the normal bootstrap.sh, the bootstrap.sh in my "try-openjdk-bootstraps" branch does though, but i didn't tidy that up specifically for openjdk8-corretto
2024-09-10 16:13:27 <cely> I think clandmeter was just installing them from the main/ repository, instead of bootstrapping everything from scratch
2024-09-10 16:14:38 <cely> I haven't confirmed this, but corretto should depend only on packages in main/ (community/openjdk8 depends on other things in community/ like gtk+2.0)
2024-09-10 16:56:09 <cely> I'll be going AFK, bye
2024-09-10 17:18:58 <mio> bye!
2024-09-11 00:11:40 <znley> morning
2024-09-11 00:19:34 <mio> hello!
2024-09-11 00:23:20 <mio> builder made it to 75 aports left
2024-09-11 01:09:53 <huajingyun> 71 aports left
2024-09-11 01:36:21 <mio> yes ... waiting for a few more aports to come through (package maintainer approval)
2024-09-11 01:37:59 <mio> it's good though, was hoping to reach 75 today and it's past that
2024-09-11 01:38:32 <mio> thanks to all the people reporting, fixing and merging
2024-09-11 01:41:56 <huajingyun> !71321 seems to fail only on CI
2024-09-11 04:41:34 <cely> I'm now trying https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk8-bootstrap
2024-09-11 04:42:11 <cely> So far, util-linux has failed to build, and alsa-lib and libxcb tried to link to /usr/lib/libgcc_s.so.1 (from the host architecture)
2024-09-11 04:43:12 <cely> They use libtool, so maybe something is going on there, or maybe this has to do with the /usr merge
2024-09-11 04:45:10 <cely> As for util-linux, i've just removed it from bootstrap.sh for now, i don't remember what required it, but the build log for main/fontconfig just scrolled by
2024-09-11 04:45:21 <cely> and util-linux-dev is there, but it's in makedepends_build
2024-09-11 04:45:36 <cely> In my branch, that is
2024-09-11 04:46:00 <cely> and now a third package (libwebp) has tried to link to /usr/lib/libgcc_s.so.1
2024-09-11 04:50:11 <cely> Maybe something else needs to be installed into sysroot, libgcc already is
2024-09-11 04:58:22 <cely> Ok, libsm needs util-linux-dev, and libsm in turn is needed by libxt
2024-09-11 05:01:11 <cely> util-linux tries to link to /usr/lib/libncursesw.so from host architecture
2024-09-11 05:22:17 <cely> Oh well, since there are problems with using bootstrap.sh from scratch, perhaps i could just provide the bootstrap openjdk8-corretto, since i am abuild to build it from what i have built before
2024-09-11 05:52:55 <cely> Anyway, my changes have been pushed to "try-openjdk8-bootstrap" (this is a new rebased branch, compared to yesterday's "try-openjdk-bootstraps")
2024-09-11 05:54:04 <cely> I'm keeping the old branch as the diff between the 2 probably contains the answer to why alsa-lib, libxcb, and libwebp failed to build due to libtool trying to link against host libgcc_s.so
2024-09-11 05:54:44 <cely> or maybe my setup just got messed up, or i tried different archs between then and now
2024-09-11 06:38:28 <cely> Tried to cross-compile openjdk8-corretto to riscv64 and armv7 with the changes in "try-openjdk8-bootstrap", and it builds
2024-09-11 06:38:51 <cely> I'm seeing the libtool-libgcc_s issue on armv7, but not riscv64, which is able to skip the incompatible /usr/lib/libgcc_s.so.1
2024-09-11 06:50:44 <huajingyun> So, this means that cross-build openjdk8-corretto for all arches is now successful
2024-09-11 07:07:49 <cely> I didn't really try all
2024-09-11 07:08:26 <cely> Just tried Loongarch again, and the incompatible /usr/lib/libgcc_s.so.1 is also skipped, so this is probably an issue with 32-bit, where it can't skip the incompatible libgcc and tries to use it
2024-09-11 07:09:37 <huajingyun> OK
2024-09-11 07:09:45 <huajingyun> Thanks
2024-09-11 07:10:57 <cely> So, running `./bootstrap loongarch64` with the "try-openjdk8-bootstrap" branch should result in a working openjdk8-corretto for Loongarch, and bootstrap.sh can be edited to remove openjdk11/17/21 from the packages list, or the build process just stopped after jdk8
2024-09-11 07:11:22 <cely> ./bootstrap.sh*
2024-09-11 07:17:34 <huajingyun> very nice
2024-09-11 07:21:27 <huajingyun> So you have also cross-built openjdk8-corretto-*.apk for loongarch64
2024-09-11 07:21:42 <huajingyun> If we temporarily install these apk packages to the official builder, and use them to build openjdk8-corretto and openjdk8 locally, this will not require anyone to cross-build again, and can solve some of the builder blocking
2024-09-11 09:28:16 <ncopa> clandmeter did you bootstrap the other openjdk packages?
2024-09-11 09:54:17 <huajingyun> ncopa: Yeah, clandmeter has cross-built openjdk 11/17/21 bootstrap before
2024-09-11 09:58:05 <ncopa> clandmeter: do you have time to help with openjdk8?
2024-09-11 10:34:03 <mps> he is on holydays/vacation I think
2024-09-11 10:35:07 <mps> or some other 'task', didn't contacted me for about 7 days which is unusual
2024-09-11 10:44:32 <ikke> I can work on it after work
2024-09-11 14:17:29 <clandmeter> i can work on it next week, but not now
2024-09-11 19:17:34 <ikke> cely: Am I supposed to run bootstrap.sh first?
2024-09-11 19:17:51 <ikke> I get a bunch of errors when trying to run the command you provided
2024-09-11 20:11:11 <Ermine> loongarch builder apparently can access xkbcommon.org, so it can't build libxkbcommon
2024-09-11 20:12:28 <ikke> Ermine: link?
2024-09-11 20:12:44 <Ermine> nevermind, I've restarted the job and it went ok
2024-09-11 20:13:58 <Ermine> this one tho: https://gitlab.alpinelinux.org/Ermine/aports/-/jobs/1514202
2024-09-11 20:20:12 <ikke> I don't expect anything being blocked on those
2024-09-12 00:47:56 <celie> ikke: With the "try-openjdk8-bootstrap" branch, it's just run bootstrap.sh
2024-09-12 00:48:51 <celie> You'll probably want to edit it as it will build openjdk11/17/21 as well
2024-09-12 05:06:16 <cely> How was !57351 handled?
2024-09-12 05:07:21 <cely> If i'm reading the comment correctly, Simon provided a bootstrap openjdk21 that he cross-compiled locally
2024-09-12 05:08:48 <ikke> right
2024-09-12 06:36:14 <huajingyun> ikke: do you have time to help with openjdk8-corretto bootstrap? thanks
2024-09-12 06:37:03 <ikke> In my afternoon
2024-09-12 06:38:08 <huajingyun> Ok, that's great, thank you
2024-09-12 06:41:52 <cely> To prevent any confusion, the branch i tried (and it was working) was: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk8-bootstrap
2024-09-12 06:42:29 <cely> and the command i used was `./bootstrap.sh loongarch64`
2024-09-12 06:50:02 <ikke> Ok, thanks. When I ran that command on the master branch, it complained about $CBUILDROOT not being set for loongarch64
2024-09-12 06:53:33 <cely> From openjdk8-corretto or one of its dependencies?
2024-09-12 06:54:48 <cely> The changes needed for openjdk8-corretto itself are in master, but its dependencies aren't, there are about 30 of them, and i modified them in one sitting
2024-09-12 06:56:05 <cely> If bootstrap.sh becomes the preferred way of bootstrapping OpenJDKs, i'll see if i can find time to tidy up my work, but there are 2 or 3 aports using meson that i just couldn't get to work, so i went back to using ./configure
2024-09-12 07:06:08 <ikke> cely: the bootstrap script itself
2024-09-12 07:06:54 <ikke> I think I understand why
2024-09-12 07:07:37 <cely> You have an older abuild that doesn't recognize loongarch?
2024-09-12 07:09:28 <cely> I thought of using qemu-user to run OpenJDK on Loongarch, but i need to find which arch has the faster emulated JVM
2024-09-12 07:09:55 <cely> Apparently, emulated x86_64 is faster than aarch64, but still not really fast enough
2024-09-12 07:12:18 <ikke> It needs to be cross-compiled from a different starting arch
2024-09-12 07:15:57 <cely> Yeah, you tried it on Loongarch?
2024-09-12 07:17:12 <ikke> 😶
2024-09-12 07:19:29 <clandmeter> 😀
2024-09-12 07:21:28 <clandmeter> That’s the idea of bootstrap, to have a cross compiler.
2024-09-12 07:22:36 <clandmeter> but to cross compile Java via bootstrap.sh it’s easier to have the builders repo in sysroot repofile.
2024-09-12 07:23:03 <clandmeter> else you will get into a dependency hell
2024-09-12 07:34:47 <mps> hm, 3A6000 could be good desktop machine
2024-09-12 07:35:25 <mps> just need few kernel tweaks
2024-09-12 07:36:00 <mps> especially if kernel 6.12 get PREEMT_RT
2024-09-12 07:36:23 <clandmeter> It had a pretty slow console for me. Not sure what was wrong
2024-09-12 07:36:53 <mps> what is slow?
2024-09-12 07:38:37 <clandmeter> Scrolling
2024-09-12 07:39:24 <clandmeter> like connecting to a remove serial console
2024-09-12 07:39:25 <mps> yes, it is not fast but I hope it will be better with 6.12
2024-09-12 07:39:33 <clandmeter> remote*
2024-09-12 07:39:51 <mps> but with X it is fine
2024-09-12 07:40:13 <clandmeter> it must be some setting
2024-09-12 07:40:29 <clandmeter> but yes. in general its a nice system.
2024-09-12 07:40:32 <mps> maybe some tweaks for radeon card
2024-09-12 07:40:46 <clandmeter> i think the onboard is similar
2024-09-12 07:40:52 <mps> I will test its internal video card
2024-09-12 07:41:14 <mps> next week though, when 6.11 will be released
2024-09-12 07:41:20 <clandmeter> ones ssh was running i disconnected the screen
2024-09-12 07:42:18 <mps> I didn't had time to work previous days on it, wasted time on kernel for bananapi f3
2024-09-12 07:43:19 <mps> but on weekend I will try to prepare loongarch64 flavor for linux-edge
2024-09-12 07:45:02 <mps> not sure should I base config on riscv64 or aarch64
2024-09-12 07:45:35 <mps> probably on both
2024-09-12 07:47:14 <clandmeter> looks like lts is not based on any of them, maybe ppc
2024-09-12 07:47:59 <mps> right, but I mean about kernel config
2024-09-12 07:48:17 <clandmeter> x86* and aarch64 are considerable larger compared to loongarch
2024-09-12 07:48:31 <clandmeter> yes thats what im refering to
2024-09-12 07:49:13 <mps> it is RISC so I think it is closer to riscv and ppc64
2024-09-12 07:49:55 <mps> hope it doesn't have 'speculative' execution :-)
2024-09-12 07:49:57 <clandmeter> i dont think the major size difference is arch related?
2024-09-12 07:50:55 <mps> yes, but all of them have their 'special' add-ons, usually
2024-09-12 07:52:49 <mps> instruction decoders, "execution path" (hardware), and address 'model'
2024-09-12 07:53:46 <mps> though I still didn't read much about this base for loongarch
2024-09-12 07:54:13 <clandmeter> there are probably a lot more drivers and such enabled for the major arches
2024-09-12 07:54:39 <mps> I think so, but loongarch devs are active
2024-09-12 07:59:37 <mps> anyway, I'm pleased with machine
2024-09-12 08:00:21 <mps> hm s/pleased/satisfied/
2024-09-12 08:00:58 <mps> huajingyun: thank you :-)
2024-09-12 08:09:11 <huajingyun> mps: You're welcome, glad you're satisfied with machine;-)
2024-09-12 08:09:20 <huajingyun> It's great that you are also going to enable loongarch64 for linux-edge, thanks
2024-09-12 08:09:53 <mps> np, pleasure will be mine (as they say)
2024-09-12 08:10:11 <mps> also forgot to say thank you to clandmeter
2024-09-12 08:10:27 <mps> you are awesome
2024-09-12 08:11:11 <mps> you both
2024-09-12 08:18:35 <huajingyun> Yeah,thanks clandmeter:)
2024-09-12 11:22:35 <ikke> running bootstrap.sh now
2024-09-12 11:47:31 <cely> Has it encountered any issues so far?
2024-09-12 11:51:28 <ikke> Hmm, so far expart fetch failed
2024-09-12 11:51:31 <ikke> expat
2024-09-12 11:51:50 <ikke> sourceforge is not cooporating
2024-09-12 11:56:38 <huajingyun> ikke: if you set DISTFILES_MIRROR to https://distfiles.alpinelinux.org/distfiles/edge?
2024-09-12 12:01:49 <ikke> huajingyun: It's working already
2024-09-12 12:01:55 <ikke> And finished
2024-09-12 12:02:08 <ikke> >> openjdk8-corretto: Updating the community/loongarch64 repository index...
2024-09-12 12:03:10 <huajingyun> That is good!
2024-09-12 12:04:01 <ikke> So now the goal is to use that package to provide openjdk8-bootstrap on the builder, right?
2024-09-12 12:06:09 <cely> I think the usual process is this cross-compile package is manually installed, openjdk8-corretto is rebuilt natively, then this cross-compiled package is uninstalled
2024-09-12 12:06:29 <huajingyun> right
2024-09-12 12:06:39 <ikke> makes sense
2024-09-12 12:19:14 <ikke> building openjdk8-corretto now on the builder
2024-09-12 12:24:28 <ikke> After that, the builder should be able to do it's own thing, right?
2024-09-12 12:24:48 <ikke> Then there is a native openjdk8-bootstrap provider and it can build everything else?
2024-09-12 12:25:11 <cely> Yes
2024-09-12 12:25:41 <cely> After the cross-compiled bootstrap aport is removed, there should be no further manual interaction needed
2024-09-12 12:26:48 <huajingyun> cely: Then may also need to re-enable community/openjdk8 for loongarch
2024-09-12 12:27:17 <cely> Yes, but maybe tomorrow for that
2024-09-12 12:27:27 <cely> The native build will take a while
2024-09-12 12:27:50 <cely> and community/openjdk8 (icedtea) will take twice as long due to building the JDK in 2 stages
2024-09-12 12:28:15 <huajingyun> Yes, it is
2024-09-12 12:29:00 <cely> I wonder why we are even sticking with icedtea anyway, probably that was needed during the initial bootstrap gcj -> ecj -> icedtea7 -> icedtea8 process, but not it seems a bit outdated
2024-09-12 12:29:08 <cely> s/not/now/
2024-09-12 12:32:25 <cely> As in, building in 2 stages may have made sense back then, but that may be redundant now
2024-09-12 12:40:08 <ikke> Maybe you can open an issue on gitlab
2024-09-12 12:41:34 <cely> There is no replacement yet though, as Corretto crashes on x86
2024-09-12 12:44:09 <cely> and switching to Zero variant would mean long compile times, as you've probably noticed now, the difference between how fast the cross-compilation takes, and how slow it is natively
2024-09-12 13:35:43 <ikke> Still building
2024-09-12 13:36:15 <cely> It takes about 1.5 hours
2024-09-12 13:38:24 <cely> Server variant (and cross-compiling from x86_64) takes less than 10 minutes
2024-09-12 13:44:05 <cely> Anyway, it should hopefully be finishing soon
2024-09-12 13:44:10 <cely> Thanks for bootstrapping it
2024-09-12 13:53:26 <ikke> It's finished
2024-09-12 13:53:43 <ikke> starting the builder again
2024-09-12 13:58:10 <cely> \o/
2024-09-12 13:58:37 <ikke> cely: thank you as well for doing all the work to make this possible
2024-09-12 14:00:38 <cely> You're welcome
2024-09-12 14:04:25 <cely> I've also taken into consideration the next stable bootstrap process, and have tried to make sure that things can be bootstrapped uniformly, as in you only need to bootstrap one and the same aport for all archs, which is community/openjdk8, all the other providers will take care of themself
2024-09-12 14:05:41 <cely> but i am aware that no cross-compilation is involved then, and the bootstrap aport is just installed from edge
2024-09-13 01:19:19 <cely> 40 aports left to build :)
2024-09-13 10:15:44 <mps> firefox is not enabled on loongarch64, anyone knows anything about this
2024-09-13 10:19:00 <mps> oh, '/work/aports/community/firefox-esr/src/firefox-115.14.0/ipc/chromium/src/build/build_config.h:133:4: error: Please add support for your architecture in build/build_config.h'
2024-09-13 10:19:29 <mps> so chromium must be supported also iiuc
2024-09-13 10:19:57 <mps> didn't know that firefox depends on chromium
2024-09-13 10:20:39 <mps> (why then it is separate browser I wonder)
2024-09-13 11:55:50 <mps> nice news for loongarch64 and kernel 6.12 https://lore.kernel.org/lkml/20240913085812.1030686-1-chenhuacai@loongson.cn/
2024-09-13 13:54:49 <mps> ohm, I didn't noticed that setserial have a problem to build with gcc 14, sorry. thanks for fixing it ncopa
2024-09-13 16:05:43 <mio> reposting this for visibility #16448
2024-09-13 16:21:15 <mio> (in case anyone might be interested in debugging the issue)
2024-09-13 16:23:20 <mio> odd, that just went by the builders
2024-09-13 16:23:36 <mio> seems to only happen in ci?
2024-09-13 22:55:23 <Ariadne> mps: i started working on it a while back, but there is a mess of rust dependencies that need to be bumped
2024-09-13 23:00:44 <Ariadne> mio: SIGILL almost always means fortify violation, so it is most likely code which is overrunning buffer
2024-09-13 23:05:14 <mio> okay, thanks. why does it only manifest in loongarch64?
2024-09-13 23:06:30 <Ariadne> not sure. if it's only on loongarch, it could be memory alignment related
2024-09-13 23:06:50 <Ariadne> i would run the testcase manually
2024-09-13 23:06:56 <Ariadne> on gdb
2024-09-13 23:09:41 <mio> okay
2024-09-14 10:34:49 <huajingyun> Hi everyone, sorry I was so busy today and didn't check here
2024-09-14 10:35:08 <huajingyun> But I have to say we have a few days off and will be back next Wednesday
2024-09-14 10:45:17 <ikke> huajingyun: Sure, don't worry. Enjoy your time off
2024-09-14 12:49:21 <mio> huajingyun: thanks for the notice, enjoy the holiday
2024-09-15 13:12:13 <mps> Ariadne: nice. I don't have time because working to get bananapi F3 to work with all things built on alpine and add loongarch64 to linux-edge
2024-09-15 13:12:40 <mps> though loongarch64 kernel is easy and don't take much time
2024-09-15 13:13:05 <mps> I wrongly thought it will require more time
2024-09-15 13:13:58 <mps> and TBH I don't like idea to again wrestle with making firefox to another alpine arch
2024-09-15 13:14:22 <mps> wont to use my free time with some system things
2024-09-18 07:22:12 <cely> If anyone works on LLVM 19, let me know if tests still fail if some targets are disabled
2024-09-18 07:22:44 <cely> (I tried some of the release candidates, and i think tests now look for the X86 target.)
2024-09-18 15:13:10 <mio> does anyone have any ideas why this community/dendrite test is failing on the loongarch64 builder? https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/dendrite/dendrite-0.13.8-r0.log
2024-09-18 15:14:34 <mio> tests were able to pass in ci, but this one test is failing repeatedly now on the builder
2024-09-18 15:15:09 <mio> thanks for any insights
2024-09-18 16:07:04 <mps> yesterday I added loongarch64 flavor to linux-edge. not sure is it built yet and is it on download repo
2024-09-18 16:07:21 <mps> that is, kernel 6.11
2024-09-18 16:07:53 <mps> works very fine built locally
2024-09-18 16:09:29 <mio> think it already built https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/linux-edge/linux-edge-6.11.0-r0.log
2024-09-18 16:11:21 <mio> not in dl-cdn (-tmp builder) yet maybe, think it's in dev.* now
2024-09-18 16:14:54 <mio> mps: a bit offtopic, but testing/gforth is ftbfs (at least in my testing), just an early notification before builder switches to testing
2024-09-18 16:16:13 <mps> mio: on loongarch64?
2024-09-18 16:16:48 <mio> mps: x86_64 https://0x0.st/X39L.3-r3.log
2024-09-18 16:17:02 <mps> aha, will look later
2024-09-18 16:17:12 <mio> but since arch="all !x86", might fail on loongarch64 as well
2024-09-18 16:17:29 <mps> will look
2024-09-18 16:17:30 <mio> sure, no rush, just a notification
2024-09-18 16:17:45 <mio> while you're here lol
2024-09-18 16:18:33 <mio> was running a select check on testing aports when it came up
2024-09-18 16:24:26 <mps> I'm usually busy but these days I'm really busy
2024-09-18 16:26:59 <mio> hopefully a good sort of busy
2024-09-18 16:27:39 <mps> meh
2024-09-18 16:27:55 <mps> good but annoying
2024-09-18 16:31:13 <mio> may the good part win out over the annoying
2024-09-18 16:33:16 <mps> hehe yes. that is always my 'point of view' but sometimes it doesn't work. mostly works which is good
2024-09-18 16:33:42 <mps> usually 'good' comes when finished
2024-09-18 16:34:02 <mps> and 'annoying' is forgotten
2024-09-18 16:37:28 <mio> lol forgotten until next time ... if the good remains, that's fine too
2024-09-18 16:39:41 <mps> mio: :)
2024-09-18 16:44:33 <mio> :)
2024-09-18 17:55:14 <mps> mio: gforth is really outdated and now we have good reason to remove it from aports. I thought of removal earlier but didn't had good reason
2024-09-18 17:55:36 <mps> gforth nowadays is really useless
2024-09-18 17:56:26 <mps> (and there are more packages which I maintain which is good candidates for removal)
2024-09-18 18:13:11 <mps> mio: btw, gforth could be built by adding '-Wno-all' to CFLAGS
2024-09-18 21:02:09 <mio> mps: okay, if you prefer ^^
2024-09-18 21:03:05 <mio> does it still function properly after -Wno-all?
2024-09-18 21:12:14 <mio> no worries if it hadn't been checked, just curious
2024-09-19 00:57:06 <huajingyun> Good morning
2024-09-19 01:02:42 <huajingyun> mps: thanks for enabling linux-edge for loongarch64, still can't build on tmp builder, probably because busybox is blocking
2024-09-19 01:02:44 <huajingyun> I'll take a look
2024-09-19 01:08:36 <mio> welcome back from holiday
2024-09-19 01:10:32 <mio> if you or one of your colleagues has a moment, could you maybe check if community/dendrite-0.13.8 fails on a test in loongarch64?
2024-09-19 01:11:41 <mio> it keeps failing now on the other builder, but cannot reproduce it on x86_64
2024-09-19 01:12:06 <mio> https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/dendrite/dendrite-0.13.8-r0.log
2024-09-19 01:13:30 <huajingyun> mio:Ok, no problem, we'll take a look
2024-09-19 01:14:07 <mio> and not sure if you saw #16448 thanks a lot for checking!
2024-09-19 01:28:25 <mio> should be ~18 aports left to build, 17 when the dendrite one passes
2024-09-19 01:53:30 <huajingyun> I rebuilt dendrite locally, but did not reproduce this test error, and all tests passed
2024-09-19 01:53:37 <huajingyun> The error log of build-edge-loongarch64 is "disk I/O error: no such file or directory"
2024-09-19 01:54:07 <huajingyun> I suspect that the "/tmp" directory of the new builder has no extra space (temporary files of the go project will be stored in /tmp), but I can't access the new builder, so I may need ncopa (clandmeter or ikke) to help check it out
2024-09-19 02:01:33 <mio> okay, thanks
2024-09-19 02:14:11 <huajingyun> mio:You're welcome
2024-09-19 02:14:30 <huajingyun> Is ada failing only on CI? I see https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/main/ada/ada-2.7.8-r1.log, ada passes and is based on simdjson-3.10.1-r0
2024-09-19 02:23:24 <mio> yes, apparently. but it only happens on loongarch64, not sure if it's something specific to the server or not
2024-09-19 02:23:59 <mio> i.e. if it's server or arch
2024-09-19 02:25:11 <mio> if it passes on the builder then probably not arch, but don't know why it didn't come up on the other servers
2024-09-19 03:16:25 <huajingyun> I don't think it's arch, it could be something else, but I can't reproduce this error locally at the moment, after the new builder community is finished, it might be time to update gitlab CI and use dl-cdn.a.o
2024-09-19 03:19:12 <mio> okay, thanks for checking
2024-09-19 04:25:39 <ikke> Reminds me that I need to setup building a base image for loongarch64 in CI
2024-09-19 05:12:32 <ikke> huajingyun: /tmp is just stored on disk on the builder (not tmpfs) and not full at all. 3% disk usage, 0% inode usage
2024-09-19 06:08:04 <huajingyun> ikke:Ok, thanks for checking
2024-09-19 06:09:35 <huajingyun> But when I build locally, the test is good as CI.Do you have any idea?
2024-09-19 06:38:59 <mps> huajingyun: np, pleasure is mine
2024-09-19 06:41:41 <huajingyun> mps:Thanks
2024-09-19 06:43:09 <mps> till now I don't see much problems with system tools on loongarch (or I didn't meet them yet)
2024-09-19 06:44:57 <mps> imo, all in all very good architecture. it's a pity it is not fully free as riscv
2024-09-19 06:45:41 <ikke> huajingyun: it did fail for me when I ran abuild check manually on the builder.
2024-09-19 06:48:45 <ncopa> clandmeter: how do i connect to build-edge-loongarch64?
2024-09-19 06:49:13 <ncopa> i think i found it
2024-09-19 06:49:16 <clandmeter> ssh 172.16.24.22
2024-09-19 06:49:30 <clandmeter> but we are still having issues with ssh from time to time
2024-09-19 06:49:41 <clandmeter> think still mtu related on the dmvpn
2024-09-19 06:49:59 <ncopa> probably
2024-09-19 06:50:59 <mps> btw, if anyone have or need some drivers and/or options enabled/disabled on linux-edge loongarch64 flavor please tell here or create issue/wishlist on gitlab
2024-09-19 06:51:58 <ncopa> im gonna reboot the build-edge-loongarch64
2024-09-19 06:53:05 <ncopa> ikke: i think we should set up /tmp as tmpfs. it is currently not
2024-09-19 06:54:52 <clandmeter> i lost console
2024-09-19 06:54:58 <clandmeter> oh its rebooting
2024-09-19 06:55:04 <ncopa> i powered it of to clean /tmp
2024-09-19 06:55:11 <ncopa> im setting up /tmp as tmpfs
2024-09-19 06:56:03 <huajingyun> ncopa:this might be a possible solution
2024-09-19 06:58:51 <clandmeter> reminds me, huajingyun did we fix the lxc pkg for loongarch?
2024-09-19 07:04:39 <huajingyun> clandmeter:Not yet, I remember this, I was going to remind you after the community is finished
2024-09-19 07:04:49 <huajingyun> To be precise, it is main/lxc-templates-legacy, and you need to add loongarch64 key to lxc-alpine.in
2024-09-19 07:05:31 <clandmeter> i think we need to add loongarch key to a.o
2024-09-19 07:16:24 <huajingyun> https://gitlab.alpinelinux.org/huajingyun01/aports/-/commit/95ac56f9549a6308643c84b32e5099e672c6cdd1
2024-09-19 07:16:38 <huajingyun> clandmeter: this is a temporary patch for lxc-templates-legacy that I used before
2024-09-19 07:30:50 <clandmeter> yes ive seen it and had to modify it to make it work :)
2024-09-19 07:44:05 <huajingyun> clandmeter: Yeah, in addition to adding loongarch key, I think there is one more thing to note, lxc-alpine.in uses dl-cdn.a.o/alpine/latest-stable, but loongarch is only in edge and has not been uploaded to latest-stable yet.
2024-09-19 12:17:52 <znley> I notice https://gitlab.alpinelinux.org/alpine/aports/-/commit/d3ba0ef70076a87c23813c9fa02ee94e69c7873e removed checksum
2024-09-19 12:18:31 <ikke> let me fix it
2024-09-19 12:19:36 <ikke> https://git.alpinelinux.org/aports/commit/?id=7d8a0b4f9d8e
2024-09-19 16:44:20 <clandmeter> mps: did you run X on loongarch desktop?
2024-09-19 16:45:27 <mps> clandmeter: yes
2024-09-19 16:45:57 <clandmeter> pkgs from dev.a.o?
2024-09-19 16:46:33 <mps> let me check
2024-09-19 16:47:03 <mps> yes, dev.a.o
2024-09-19 16:50:53 <clandmeter> ok thx
2024-09-19 16:51:04 <clandmeter> ill rsync community lcoally :)
2024-09-19 17:38:08 <mps> kde is not ported to loongarch64?
2024-09-19 17:39:53 <mps> ah, konqueror is blocked by qt6-qtwebengine
2024-09-19 19:24:30 <clandmeter> looks like we are missing a browser on loongarch?
2024-09-19 19:25:09 <mps> right
2024-09-19 19:26:24 <ikke> curl, lynx?
2024-09-19 19:26:33 <ikke> :p
2024-09-19 19:26:56 <mps> netsurf also, I used to test
2024-09-19 19:27:52 <mps> netsurf works for simple sites, but not for heavy ones with JS
2024-09-19 19:28:06 <clandmeter> X does not start
2024-09-19 19:28:14 <clandmeter> mps: what did you do to get x running?
2024-09-19 19:28:41 <mps> /etc/init.d/slim start, but also startx works
2024-09-19 19:29:08 <mps> but also setup-xorg-base before this
2024-09-19 19:29:49 <mps> I hope you remember how to get X on alpine
2024-09-19 19:30:45 <clandmeter> ive used setup-desktop
2024-09-19 19:30:55 <clandmeter> but had to remove firefox first
2024-09-19 19:31:08 <clandmeter> lookking at xorg log
2024-09-19 19:31:13 <clandmeter> but cant find something usefull
2024-09-19 19:31:24 <clandmeter> it tries to start and quits
2024-09-19 19:38:34 <clandmeter> interesting, its lightdm that is crashing
2024-09-19 19:39:43 <clandmeter> slim does work
2024-09-19 19:40:03 <mps> nice
2024-09-19 19:40:29 <mps> also awesomewm works nicely
2024-09-19 19:40:32 <mps> :)
2024-09-19 19:52:17 <clandmeter> i cannot find the exact reason for lightdm not to start
2024-09-19 19:52:38 <clandmeter> seat greeting does return:Failed to open PAM session: Permission denied
2024-09-19 19:53:03 <mps> hm, why do we have pam
2024-09-19 19:53:23 <mps> PAM is security hole
2024-09-19 19:53:43 <mps> false sense of security
2024-09-19 19:54:58 <clandmeter> we dont have pam
2024-09-19 19:55:02 <clandmeter> well we dont use it
2024-09-19 19:55:11 <clandmeter> not sure why its complaining about it
2024-09-19 19:55:42 <clandmeter> why are we missing ff?
2024-09-19 19:56:34 <mps> iiuc upstream doesn't support loongarch
2024-09-19 19:56:51 <mps> something about chromium part of FF
2024-09-19 19:57:07 <clandmeter> same goes for chromium i guess?
2024-09-19 19:57:21 <mps> I think so
2024-09-19 20:01:33 <mps> also, konqueror is blocked
2024-09-19 20:05:55 <clandmeter> would be nice to have a fully working desktop
2024-09-19 20:07:34 <mps> agree
2024-09-20 07:14:24 <clandmeter> huajingyun: ping
2024-09-20 07:16:40 <ncopa> did anyone report pydantic build error upstream?
2024-09-20 07:17:02 <huajingyun> clandmeter:Hi clandmeter,Ia bit busy today
2024-09-20 07:17:48 <clandmeter> huajingyun: no worries, just wanted to know if there is any work on getting a decent browser on loongarch?
2024-09-20 07:18:13 <huajingyun> No, I tried to build the latest pydantic 2.9.2 yesterday and the test still failed
2024-09-20 07:20:45 <huajingyun> clandmeter: OK, I've seen your discussion with mps, I might need to see which one can be supported
2024-09-20 07:21:41 <clandmeter> I am not sure what the showstoppers are.
2024-09-20 07:22:32 <cely> I think it would be best to get the Rust 1.82+LLVM 19 issue sorted out first, if we are talking about Firefox
2024-09-20 07:23:12 <mps> clandmeter: I tried to build firefox but when I saw what is the problem I stopped. Don't want again to fix it for new arch
2024-09-20 07:23:38 <clandmeter> i remember mps mentioned some chromium error in firefox build
2024-09-20 07:23:44 <mps> and rust! oh nooooooooooooo
2024-09-20 07:23:53 <huajingyun> firefox or chromium
2024-09-20 07:23:56 <clandmeter> does that mean we need chromium support first?
2024-09-20 07:24:18 <mps> huajingyun: some chromium parts in firefix
2024-09-20 07:24:38 <clandmeter> firefix is the right name :)
2024-09-20 07:24:39 <mps> yes, firefox uses some parts from chrome
2024-09-20 07:25:39 <mps> however it sounds stupid
2024-09-20 07:26:01 <cely> https://github.com/loongson/chromium https://github.com/sunhaiyong1979/CLFS-for-LoongArch/tree/main/patches https://github.com/loongarchlinux/extra/tree/main/firefox
2024-09-20 07:27:29 <mps> hmm, maybe worth try
2024-09-20 07:27:36 <mps> thanks cely
2024-09-20 07:27:46 <cely> You're welcome
2024-09-20 07:28:09 <huajingyun> Yes, this link should have been verified
2024-09-20 07:28:43 <huajingyun> Ok, I think I'll take a look at that first as well. If we have any questions, don't worry, my firefix colleagues will be there to help as well.
2024-09-20 07:29:15 <mps> firefix :)
2024-09-20 07:29:54 <cely> Oops, sorry, typo in the middle link, correct one is: https://github.com/sunhaiyong1978/CLFS-for-LoongArch/tree/main/patches (1978 instead of 1979)
2024-09-20 07:30:19 <mps> for years I wonder why free/open source people can't (or don't want) really decent and really free web browser
2024-09-20 07:30:47 <mps> can't write*
2024-09-20 07:31:54 <clandmeter> you have colleagues for each specific pkg? :)
2024-09-20 07:31:59 <cely> I see that https://github.com/sunhaiyong1978/CLFS-for-LoongArch/blob/main/patches/firefox-100-add-loongarch.patch has some changes for ipc/chromium
2024-09-20 07:32:26 <mps> ok, there is konqueror but I don't like to use kde
2024-09-20 07:32:45 <clandmeter> i guess firefox is using pkgs from community
2024-09-20 07:33:19 <clandmeter> we need to get community fixed so it can upload
2024-09-20 07:36:00 <huajingyun> clandmeter:there is a browser group, they will take care of these tasks
2024-09-20 07:36:14 <clandmeter> huajingyun: ah nice
2024-09-20 07:37:21 <cely> Isn't webkit2gtk-4.1 enabled for Loongarch?
2024-09-20 07:37:57 <cely> There are some browsers using that, badwolf, vimb, surf (in testing)
2024-09-20 07:41:10 <huajingyun> Already have webkit2gtk-4.1
2024-09-20 07:42:14 <clandmeter> should we be able to build ff with the patches in these links?
2024-09-20 07:47:23 <cely> If they still apply, maybe, i note that Loongarchlinux's Firefox is at version 122.0
2024-09-20 07:47:54 <clandmeter> yes we are on 130 i believe
2024-09-20 07:48:25 <clandmeter> if i can find some time ill see if i can look into it
2024-09-20 07:48:53 <cely> and https://github.com/loongarchlinux/extra/blob/main/firefox/0004-Fix-libyuv-build-with-LSX-LASX.patch says the patch "is not of upstream quality"
2024-09-20 07:49:23 <cely> but author of that patch is in this channel, so you can ask him about that
2024-09-20 19:36:43 <Ariadne> we will have a full build of main and community on loongarch in ~minutes
2024-09-20 19:36:57 <Ariadne> it would be nice to decommission the build-edge-tmp-loongarch64
2024-09-20 19:37:14 <mio> \o/
2024-09-20 19:37:29 <ikke> Would be nice to have an official minirootfs image
2024-09-20 19:37:48 <Ariadne> we can do a tag for it after the packages are uploaded
2024-09-20 19:39:15 <ikke> I'll use it to make are own docker base image (docker does not want to support loongarch yet)
2024-09-20 19:39:44 <Ariadne> oh, the docker library?
2024-09-20 19:39:48 <ikke> yup
2024-09-20 19:39:52 <ikke> They asked, got a nack
2024-09-20 22:17:10 <Ariadne> any objection to cutting a tag?
2024-09-20 22:17:22 <Ariadne> though the loong builder will need to be stopped
2024-09-20 22:17:27 <Ariadne> since it's building all of testing :P
2024-09-20 22:17:42 <Ariadne> or i guess actually we need testing first
2024-09-20 22:48:49 <Ariadne> we can and should disconnect the build-edge-tmp-loongarch64 though
2024-09-20 22:49:33 <Ariadne> at this point it is not giving us useful surveillance of testing, and the packages it has generated are obsolete
2024-09-21 05:29:59 <cely> Found repo with more up-to-date set of patches: https://github.com/AOSC-Dev/chromium-loongarch64
2024-09-21 05:30:48 <cely> https://github.com/lcpu-club/loongarch-packages/tree/master/firefox
2024-09-21 06:28:53 <ikke> Ariadne: we need to switch over CI before we can discontinue the tmp builder
2024-09-21 06:37:33 <cely> Seems to build: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1525165
2024-09-21 06:40:39 <cely> Grab it while it's hot: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1525165/artifacts/download
2024-09-21 06:43:37 <cely> Branch: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-firefox-130-loongarch64
2024-09-21 06:44:37 <cely> I've rebased it after that successful CI run, to rename the patches (002* are what i added, 000* and 001* are from lcpu-club)
2024-09-21 06:45:17 <cely> and also added another patch to fix a warning, this may not be necessary though as it doesn't cause the build to fail
2024-09-21 06:53:30 <mps> cely: congrats
2024-09-21 06:56:21 <cely> Thanks
2024-09-21 06:57:01 <cely> A majority of the credit goes to lcpu-club and those who've worked on this before
2024-09-21 06:57:45 <cely> I think Firefox upstream probably already has some support for Loongarch
2024-09-21 06:58:04 <Ariadne> nice
2024-09-21 06:58:17 <mps> well, it is important who is front man :) (backstage never counts and no one interested in their hard work :-) )
2024-09-21 06:58:40 <cely> I just bumped the libc crate to 0.2.155, which we've been doing to the Rust aports
2024-09-21 06:59:01 <cely> and added some 2 define which seem to be missing in musl
2024-09-21 06:59:44 <mps> I guess clandmeter will be happy by this
2024-09-21 06:59:45 <cely> I think i've seen those defines in some of the earlier patches sent to musl, don't know why it didn't make it into musl 1.2.5
2024-09-21 07:04:14 <mps> cely: and it works
2024-09-21 07:07:57 <cely> That's good :)
2024-09-21 07:08:21 <cely> Better than Chromium, which i also tried, but apparently, it can't find C++ includes
2024-09-21 07:10:03 <cely> s/it/the build system/
2024-09-21 07:12:45 <mps> will you create MR for FF
2024-09-21 07:12:48 <mps> ?
2024-09-21 07:14:14 <cely> I would like to ask huajingyun first, if their Firefox team has another set of patches, or if this set looks good
2024-09-21 07:14:28 <cely> Better to have Jingyun as contact person in case the patches ever stop working
2024-09-21 07:14:52 <cely> and, maintainer of Firefox is in this channel
2024-09-21 07:14:58 <cely> So, ptrc, what do you think?
2024-09-21 07:15:08 <cely> Would you accept an MR to enable Firefox on Loongarch?
2024-09-21 15:44:29 <ptrc> sure, as long as it builds :P
2024-09-21 15:46:43 <cely> How would you like the patches applied? For all archs, or just Loongarch?
2024-09-21 15:47:12 <cely> Patch source is https://github.com/lcpu-club/loongarch-packages/tree/master/firefox
2024-09-21 15:48:44 <cely> and on top of that there's another not-really-small patch to bump libc crate to 0.2.155
2024-09-21 15:49:28 <cely> but that may be alright to apply everywhere, as we've already been bumping the Rust aports' libc to 0.2.155
2024-09-21 15:50:46 <cely> and that's the next version after 0.2.153, as 0.2.154 was yanked
2024-09-21 15:51:05 <cely> 0.2.153 is what Firefox 130 uses now
2024-09-21 20:28:47 <ptrc> hm, i'll look through the patches later today and try to apply them onto our Firefox in a MR, if nobody's done that yet
2024-09-21 20:29:07 <ptrc> at a glance they look alright to me
2024-09-22 00:16:28 <celie> I've done it
2024-09-22 00:17:16 <celie> I'll try to look through what i've done one more time, i think i noticed a few things that can be skipped
2024-09-22 01:50:10 <cely> ptrc: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-firefox-130-loongarch64
2024-09-22 01:50:55 <cely> Renamed the patches again, as the commit message says, loong000* are from lcpu-club, loong002* are my additions
2024-09-22 01:51:14 <cely> lcpu-club has a 0011 patch for libpng, which i've removed, as we use system libpng
2024-09-22 01:53:23 <cely> and the original loong0001 patch also added `#include <cstdint>` to pingsender.cpp, which doesn't seem to be necessary, and is probably not relevant to the patch subject (Add support for LoongArch64)
2024-09-22 01:53:37 <cely> So, those have been removed
2024-09-22 01:59:56 <cely> I wonder if i really need to modify supply-chain/imports.lock for the 0021 libc crate patch, so if you know that that isn't needed, then you can remove it
2024-09-22 02:06:03 <cely> Hmm, main/libpng was upgraded 5 days ago, but the tmp builder has been blocked, so the Loongarch CI still uses libpng 1.6.43
2024-09-22 02:08:22 <cely> The x86 and armv7 CIs have also passed (didn't run the x86_64, aarch64, and ppc64le ones with profiling, as that will take hours)
2024-09-22 02:08:48 <cely> So, the patches don't cause other archs to fail
2024-09-22 23:59:02 <Ariadne> working on getting qt6-qtwebengine up
2024-09-23 00:31:23 <Ariadne> hmm, nodejs seems broken entirely
2024-09-23 00:31:31 <Ariadne> digging into that first...
2024-09-23 00:39:46 <Ariadne> oh that is because i am on openpax kernel
2024-09-23 00:40:01 <Ariadne> restoring the pax markings is on my list of things to do...
2024-09-23 00:51:05 <celie> Are you trying the patches from https://github.com/AOSC-Dev/chromium-loongarch64 ?
2024-09-23 00:53:10 <Ariadne> with some modifications yes
2024-09-23 00:55:59 <Ariadne> the rest of KDE is basically blocked on qt6-qtwebengine
2024-09-23 00:56:01 <Ariadne> soooo
2024-09-23 00:56:22 <Ariadne> i would also buy riscv64 machine if there was one actually worth buying
2024-09-23 00:56:36 <Ariadne> milk-v pioneer has lots of cores, but still slow
2024-09-23 00:59:34 <cely> Speaking of that, there's https://github.com/felixonmars/archriscv-packages/tree/master/qt6-webengine
2024-09-23 01:01:59 <Ariadne> the 3a6000 is pretty decently performance competitive, but the 2.5ghz clock is a really limiting factor
2024-09-23 01:02:27 <Ariadne> if loongson made parts with 4ghz clocks with turbo like x86 has it would be very competitive
2024-09-23 01:17:37 <huajingyun> cely:Thanks for doing this, I will ask the browser team later about these patches you added for firefox, please wait
2024-09-23 01:19:06 <cely> Ok, thanks
2024-09-23 01:57:43 <Ariadne> hmm looks like the loongarch v8 patch is slightly off
2024-09-23 02:07:31 <Ariadne> oh i forgot to add it to the list
2024-09-23 02:07:35 <Ariadne> haha
2024-09-23 06:39:15 <Ariadne> 4 hours later
2024-09-23 06:39:24 <Ariadne> and it built a working qt6-qtwebengine
2024-09-23 06:43:33 <cely> Hehe, never expected qt6-qtwebengine to be the first to get Loongarch support
2024-09-23 06:44:41 <cely> Did the build fail without -mcmodel=medium?
2024-09-23 06:45:53 <Ariadne> yeah
2024-09-23 06:46:11 <cely> Ok
2024-09-23 06:46:32 <cely> As for ffmpeg, isn't qt6-qtwebengine using system ffmpeg?
2024-09-23 06:47:44 <Ariadne> it does appear so, we may be able to drop that patch but at 4 hours per build on 3a6000 SoC, i did not wish to argue about it
2024-09-23 06:48:04 <Ariadne> get the thing working, then slim it down :)
2024-09-23 06:49:41 <cely> Ok :)
2024-09-23 06:49:52 <Ariadne> there is a lot of other vendored stuff in qt6-qtwebengine too
2024-09-23 06:50:13 <Ariadne> trying to get this loongarch machine to be acceptable as daily driver
2024-09-23 06:50:31 <Ariadne> sway just isn't doing it for me, i want kde ;)
2024-09-23 06:54:16 <cely> I wonder if Crashpad is being built
2024-09-23 06:54:35 <cely> because for Chromium, that part didn't build
2024-09-23 06:55:37 <cely> It probably needs the latest patch submitted to musl: https://www.openwall.com/lists/musl/2024/09/23/1
2024-09-23 06:56:07 <cely> for the sctx_info and fpu_context struct definitions
2024-09-23 06:56:57 <Ariadne> it does build crashpad
2024-09-23 06:58:57 <cely> Hmm, i wonder if it is GCC that makes the difference
2024-09-23 07:05:54 <Ariadne> does anyone know what is up with opencv ?
2024-09-23 07:11:10 <cely> Looks like it was disabled before the SIMD patch was backported to musl
2024-09-23 07:11:30 <Ariadne> would be cool if someone can look into that :)
2024-09-23 07:20:42 <znley> opencv failed with "opencv-4.9.0/modules/core/include/opencv2/core/hal/intrin_lasx.hpp:661:24: error: argument to '__builtin_lasx_xvpermi_d' must be a constant integer"
2024-09-23 07:21:19 <Ariadne> is it possible to disable intrinsics or cast the integer to a const
2024-09-23 07:22:08 <znley> This is because the upstream code is incompatible with gcc builtin functions.
2024-09-23 07:22:53 <znley> I consulted with the upstream maintainers and they are working on replacing these built-in functions.
2024-09-23 07:22:59 <Ariadne> okay
2024-09-23 07:23:25 <Ariadne> i mostly ask because that's the last thing blocking `setup-desktop plasma` from just working on loongarch
2024-09-23 07:24:15 <znley> I haven't contacted the maintainer for a long time. Let me ask about the latest progress.
2024-09-23 07:27:29 <Ariadne> well other than spectacle, i managed to get kde running on my loongarch machine :)
2024-09-23 07:28:14 <Ariadne> (i wonder why spectacle depends on opencv at all)
2024-09-23 07:36:13 <cely> Looks like someone asked that question on Reddit
2024-09-23 07:36:49 <Ariadne> so firefox and opencv are the last main blockers for me i guess
2024-09-23 07:36:53 <cely> has asked*
2024-09-23 07:37:02 <Ariadne> but this is cool seeing KDE running on my machine
2024-09-23 07:38:16 <znley> A good news, opencv upstream has fixed this problem, let me try backport.
2024-09-23 07:39:17 <Ariadne> nice!
2024-09-23 07:39:34 <Ariadne> i'll be around for a while if you need a review
2024-09-23 07:40:51 <cely> I'll be going AFK, bye
2024-09-23 07:41:38 <znley> Thanks, build may take some time
2024-09-23 07:44:59 <mps> Ariadne: firefox from cely's branch works fine in my test, so I hope it will be soon in repo
2024-09-23 07:45:35 <Ariadne> mps: yeah i'm going to try it now and if it works for me i'm going to push it
2024-09-23 07:46:08 <mps> someone already preparing MR
2024-09-23 07:46:14 <Ariadne> cool
2024-09-23 07:46:26 <mps> ptrc iirc
2024-09-23 07:47:28 <mps> did anyone tested linux-edge on loongarch64? any comments, bugs, wishlist
2024-09-23 07:47:29 <Ariadne> anyway i am bullish on loongarch in a way i am not on risc-v
2024-09-23 07:47:56 <Ariadne> you can actually buy desktop class boards for loongarch at prices that are cost competitive
2024-09-23 07:48:31 <mps> loongarch is good but I prefer riscv in longterm plans
2024-09-23 07:48:33 <Ariadne> risc-v you have the sifive boards which are expensive and slow, or milk-v pioneer which is hyperscale with slow cores
2024-09-23 07:49:17 <Ariadne> i like the idea of risc-v, but taping out a performant CPU which does not brush up against sifive / imgtec / intel patents is challenging
2024-09-23 07:49:32 <Ariadne> with loongarch, loongson either doesn't care or already has licenses
2024-09-23 07:50:00 <Ariadne> what risc-v needs is desktop boards for $400 US
2024-09-23 07:50:15 <Ariadne> with a similar performance profile
2024-09-23 07:50:19 <mps> few days ago I read somewhere that Qualcomm will probably buy intel
2024-09-23 07:50:37 <Ariadne> good maybe they will kill x86 :)
2024-09-23 07:50:57 <mps> +1
2024-09-23 07:52:44 <Ariadne> firefox package works!
2024-09-23 07:53:12 <mps> now I'm sure when I need new laptop I will buy loonson or if risc-v good enough materialize on market. No more intel or arm
2024-09-23 07:53:27 <mps> and no apple
2024-09-23 07:53:50 <Ariadne> i like apple for business just because they have a good "my laptop got stolen" story
2024-09-23 07:54:03 <mps> :)
2024-09-23 07:54:15 <Ariadne> but yes, otherwise, i prefer my thinkpad x13s
2024-09-23 07:54:22 <Ariadne> i might gamble on a musebook
2024-09-23 07:55:06 <mps> also I thought about it but having board with this SoC not sure
2024-09-23 07:55:57 <mps> thought we got X60 spacemit to work with alpine and it is now stable
2024-09-23 07:56:22 <mps> last thing left is to fix u-boot+opensbi for it
2024-09-23 07:58:57 <mps> yesterday I used loongarch 3A6000 desktop all day as working machine, very responsive and stable but my moitor is bad
2024-09-23 08:02:43 <Ariadne> my machine is less stable because i need to add paxmarkings to binaries
2024-09-23 08:08:21 <znley> create !72367
2024-09-23 08:10:07 <znley> Ariadne: I have submitted.
2024-09-23 08:15:37 <Ariadne> it'll merge once its passed CI
2024-09-23 08:23:19 <huajingyun> I just updated !71733, adding two loongarch64 patches for musl
2024-09-23 08:47:49 <Ariadne> has the musl patches been accepted upstream?
2024-09-23 08:52:26 <huajingyun> Ariadne: Not yet, the TLSDESC patch I think rich will accept (https://www.openwall.com/lists/musl/2024/09/09/2), the fpu and simd context patch was submitted today, rich has not responded yet.
2024-09-23 08:54:49 <Ariadne> okay, we can merge these. the kstat i would like to avoid merging
2024-09-23 09:09:08 <ncopa> Maybe we can drop the build-edge-tmp-loongarch64 builder now?
2024-09-23 09:16:02 <huajingyun> Ariadne: Thanks, I didn't add the kstat patch, and we probably won't push it upstream to musl in the future
2024-09-23 09:16:22 <huajingyun> ncopa: Maybe wait until the official builder completes the testing build
2024-09-23 09:17:00 <huajingyun> Oh, but busybox is blocked now, so new packages will not be synchronized for the time being (https://dev.alpinelinux.org/edge/)
2024-09-23 09:19:51 <huajingyun> The failure of busybox seems to be caused by the update of utmps and skalibs. I tried to rebuild busybox on x86_64 and it also failed to compile
2024-09-23 09:19:59 <huajingyun> https://git.alpinelinux.org/aports/commit/?id=8e8468058e7e
2024-09-23 09:19:59 <huajingyun> https://git.alpinelinux.org/aports/commit/?id=b585da532f
2024-09-23 09:20:23 <Ariadne> busybox is blocked due to network error
2024-09-23 09:20:42 <Ariadne> or at least was as of a few days ago
2024-09-23 09:22:26 <huajingyun> It was a few days ago, I contacted the network administrator and solved it
2024-09-23 09:22:44 <huajingyun> The error now is: cannot find -lutmps: No such file or directory ,cannot find -lskarnet: No such file or directory
2024-09-23 09:22:56 <ikke> ncopa: our current CI image still depends on it
2024-09-23 09:23:14 <clandmeter> i think there is a MR for the bb issue
2024-09-23 09:23:20 <ikke> huajingyun: there is an MR for that yes
2024-09-23 09:23:33 <ncopa> so we need edge snapshot
2024-09-23 09:23:41 <ikke> ncopa: exactly
2024-09-23 09:23:53 <Ariadne> i don't think edge snapshot will complete until testing is ready
2024-09-23 09:24:05 <ikke> We can disable edge temporarily
2024-09-23 09:24:11 <ikke> Testing*
2024-09-23 09:25:23 <huajingyun> Can we create a new minirootfs for edge?
2024-09-23 09:28:40 <ncopa> it comes with the snapshot release
2024-09-23 09:29:52 <huajingyun> Oh, okay
2024-09-23 09:31:35 <huajingyun> musl TLSDESC patch has been merged, now is also the time to restores TLS descriptors for gcc !71734
2024-09-23 09:35:45 <huajingyun> ncopa:Thanks for merging:)
2024-09-23 10:52:16 <mps> hm, busybox nned utmps and skalibs?
2024-09-23 11:19:20 <huajingyun> Yes, they are needed for busybox compilation
2024-09-23 11:20:52 <huajingyun> The library names provided by utmps and skalibs have been changed from /usr/lib/libskarnet.a to /usr/lib/skalibs/libskarnet.a, and from /usr/lib/libutmps.a to /usr/lib/utmps/libutmps.a, so busybox fails to link
2024-09-23 11:21:48 <huajingyun> I'll be going AFK, bye
2024-09-23 11:38:53 <mps> hm, how then busybox was compiled when these libs were not in aports
2024-09-23 11:41:09 <ncopa> mps: git log will tell you the story
2024-09-23 11:46:43 <ncopa> 511351f2e01347483a8cdb8d4cecc4e3cea578fa
2024-09-23 12:07:37 <mps> my question was rhetorical, actually
2024-09-23 12:07:52 <mps> anyway thanks for answer
2024-09-23 12:17:02 <cely> !72377 has the aport name wrong, it is community/cbindgen, not cargo-auditable
2024-09-23 15:52:05 <ptrc> cely: your Firefox changes look good, do you wanna open a MR with them?
2024-09-23 15:52:09 <ptrc> sorry, i kinda forgot about it for a second
2024-09-23 15:53:05 <cely> I wouldn't mind if you handle it
2024-09-23 16:03:33 <ptrc> i mean i'd just take your commit so
2024-09-23 16:11:05 <cely> That's fine, i'll be going AFK, so if the ball is passed back to me, i'll see what i can do tomorrow
2024-09-23 16:42:22 <ptrc> cely: okie, see you later \o
2024-09-23 19:35:20 <ncopa> i have temp disabled testing for loongarch64 so I can make an edge snapshot
2024-09-23 19:36:32 <clandmeter> 🤞
2024-09-23 19:37:58 <ncopa> https://dl-master.alpinelinux.org/alpine/edge/releases/loongarch64/
2024-09-23 19:38:04 <Ariadne> did it make a release?
2024-09-23 19:38:10 <Ariadne> build.a.o shows the builder as idle
2024-09-23 19:38:13 <ncopa> it did!
2024-09-23 19:38:32 <Ariadne> no ISO?
2024-09-23 19:38:33 <ncopa> it only made an minirootfs image
2024-09-23 19:38:52 <ncopa> no, edge snapshots only makes minirootfs and netboot
2024-09-23 19:39:07 <Ariadne> ah
2024-09-23 19:39:19 <Ariadne> it used to make ISOs
2024-09-23 19:39:22 <ncopa> but I did verify that the script is capable of making iso
2024-09-23 19:39:33 <ncopa> yeah, we stopped doing those some time ago
2024-09-23 19:40:02 <ncopa> i can make a custom one for you if you want though
2024-09-23 19:40:17 <Ariadne> i don't need it
2024-09-23 19:40:44 <Ariadne> well, congrats to us, we have the first set of independently built loongarch packages i think
2024-09-23 19:41:19 <ncopa> this also opens up to build official docker edge image
2024-09-23 19:41:41 <ncopa> yeah, congrats indeed!
2024-09-23 19:54:28 <ncopa> the arch for go is loong64, right?
2024-09-23 19:54:40 <ncopa> that is the docker architecture?
2024-09-23 19:56:29 <Ariadne> yes
2024-09-23 19:56:37 <Ariadne> OCI architecture is linux/loong64
2024-09-23 19:59:00 <ncopa> do you have any ref for that?
2024-09-23 20:00:38 <ncopa> Tags: 20240923, edge
2024-09-23 20:00:39 <ncopa> Architectures: arm64v8, arm32v6, arm32v7, loong64, ppc64le, riscv64, s390x, i386, amd64
2024-09-23 20:01:01 <ncopa> ok, I'm pushing it and creating a PR
2024-09-23 20:05:45 <ncopa> alright, lets see if we can get an official alpine docker loongarch64 image https://github.com/docker-library/official-images/pull/17607
2024-09-23 20:16:54 <ikke> ncopa: docker indicated that they do not support loongarch, and afaik, don't have any infrastructure for it yet
2024-09-23 20:19:35 <ncopa> https://github.com/docker-library/official-images/issues/16404
2024-09-23 20:21:14 <ikke> In the meantime, I'll use https://gitlab.alpinelinux.org/alpine/infra/docker/alpine
2024-09-23 20:24:22 <ncopa> maybe we need build our own images?
2024-09-23 20:24:39 <ikke> that's what I'm doing there
2024-09-23 20:24:54 <ikke> Although, that's still based on alpine
2024-09-23 20:25:16 <ikke> But I can just create a new base image with FROM scratch and then import the minirootfs
2024-09-23 20:25:58 <ikke> The only `issue` is that the repo name is quite long
2024-09-23 20:28:08 <ncopa> do we have all architectures there?
2024-09-23 20:29:58 <ikke> except loongarch, yes
2024-09-23 20:30:08 <ikke> And I'm working on adding loongarch
2024-09-23 20:30:14 <ncopa> :)
2024-09-23 20:50:14 <Ariadne> we should really transition away from docker library as the blessed base image source anyway
2024-09-23 20:50:31 <Ariadne> IMO it gives them power over the alpine ecosystem that is unwarranted
2024-09-23 20:50:55 <Ariadne> (though i do admit that i have no idea how to handle the infrastructure cost of that)
2024-09-23 20:53:08 <ikke> Right now I'm hosting images on linode object storage
2024-09-23 20:54:28 <ikke> Perhaps with a CDN in front we could get quite for
2024-09-23 20:54:30 <ikke> far
2024-09-23 21:12:15 <Ariadne> i am actually pretty impressed with the stability of this loongson system verses older lemote mips64el kit i have
2024-09-23 21:12:25 <Ariadne> the older loongson cores were not the most stable...
2024-09-24 01:04:15 <huajingyun> Thanks to ncopa for creating a PR to docker
2024-09-24 01:04:21 <huajingyun> It's a pity that docker still doesn't want to accept loongarch64:-(
2024-09-24 01:07:30 <huajingyun> Ariadne: Are you still using firefox? Have you opened any video files yet? I want to know if they play smoothly,thanks
2024-09-24 01:15:23 <huajingyun> cely:Thanks,I updated !72377
2024-09-24 01:17:34 <Ariadne> have not tried youtube, but will this evening
2024-09-24 01:23:31 <huajingyun> Ariadne: OK, thanks
2024-09-24 05:25:56 <mps> huajingyun: I watched videos with firefox, works fine for me. though I'm far from expert in video
2024-09-24 05:26:39 <mps> it is better than on my arm64 with panfrost driver
2024-09-24 05:27:05 <mps> panfrost GPU driver*
2024-09-24 06:24:10 <huajingyun> mps:Ok, thank you
2024-09-24 07:20:06 <cely> The Loongarch CI pipeline for !72425 has passed, 2 patches have been removed based on feedback from Jingyun's Firefox team
2024-09-24 07:22:05 <cely> I'll be going AFK now, bye
2024-09-24 07:29:00 <mps> hm, to merge or not to merge is the question. :) will wait till someone promise to merge do this
2024-09-24 07:29:16 <mps> promised*
2024-09-24 07:42:33 <Ariadne> huajingyun: performance seems OK. a few frames dropped on youtube, but that's not much different than other systems i have
2024-09-24 07:51:04 <huajingyun> Ariadne: OK, thanks for telling me
2024-09-24 08:39:40 <clandmeter> huajingyun: ff youtube is fine
2024-09-24 08:39:53 <clandmeter> i think even on very high bitrates
2024-09-24 09:14:50 <znley> I'm curious what model of graphics card on your loongarch64 machine?
2024-09-24 09:21:11 <huajingyun> clandmeter:Thanks
2024-09-24 09:21:26 <clandmeter> znley: the amd one that is shipped
2024-09-24 09:22:36 <huajingyun> [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM] (rev 87)
2024-09-24 09:23:05 <huajingyun> Is that right? I think it should be this
2024-09-24 09:45:19 <clandmeter> tbh, i didnt check the model, it just works :)
2024-09-24 10:09:46 <cely> I'm a bit confused why we would get a comment that we should also patch mozjz, thunderbird, firefox-esr, and librewolf
2024-09-24 10:12:04 <cely> Though Firefox shares code with all of those, Firefox is Firefox, why should other things that share code with Firefox also be patched if Firefox is patched..
2024-09-24 10:14:55 <cely> If there are enough people working on it, of course it may be done, but why come out of the blue with a comment like that as if it "has to be" done
2024-09-24 10:15:06 <cely> Anyway, AFK again, bye
2024-09-24 10:15:38 <ptrc> yeah, the wording was definitely odd
2024-09-24 10:15:56 <ptrc> anyway, i'll try to merge firefox today, thanks for the MR again! see ya \o
2024-09-24 19:36:22 <clandmeter> znley: http://www.link-high.com/index.php/en_product_detail/id/39.html
2024-09-24 19:36:24 <clandmeter> thats the gpu
2024-09-24 19:57:51 <Ariadne> znley: in my case it is radeon 5700xt
2024-09-24 20:12:12 <mps> my is 'VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM] (rev 87)' from lspci
2024-09-24 20:15:15 <mps> there is also on-board one but there is no mesa driver for it, iiuc
2024-09-24 20:17:19 <Ariadne> the onboard is just a framebuffer afaik
2024-09-24 20:18:07 <mio> could anyone by chance unblock the loongarch builder? it can't switch back to testing due to cyclone
2024-09-24 20:18:08 <mps> I think so
2024-09-24 20:19:24 <mps> mio: only by fix cyclone or disable it for loongarch
2024-09-24 20:20:07 <mio> it was reenabled for loongarch but seems to be failing due to test
2024-09-24 20:20:35 <mps> or temporarily disable check in it
2024-09-24 20:20:46 <mio> pinged the maintainer but got unlucky and probably missed them
2024-09-24 20:21:40 <mps> if arch eq "loongarch64" ... options="!check"
2024-09-24 20:22:07 <mps> $arch*, or something like this
2024-09-24 20:25:24 <mio> okay. the previous commit was to explicitly reenable check, a bit hesitant to MR to disable
2024-09-24 20:25:47 <mio> thanks for confirming the options
2024-09-24 20:29:30 <mps> idk what is cyclone at all, but I think it is ok to disable test temporarily to unblock builder
2024-09-24 20:29:54 <mps> other option could be to patch it to skip failing test
2024-09-24 20:30:20 <mps> but anyway best is to contact upstream and ask for solution
2024-09-24 20:30:57 <mps> yes, I know that some upstream devs are not responsive
2024-09-24 20:32:05 <mps> and some ignores us because we use musl
2024-09-24 20:32:59 <mps> some even doesn't know that musl exists :)
2024-09-24 20:34:51 <mio> lol would hope there is more awareness now thanks to distros like alpine
2024-09-24 20:36:29 <mps> most upstream devs are ok and kind, ready to fix issues and help us. some contacted me by private channels even when I don't ask them
2024-09-24 20:36:58 <mps> but some simply ignores me when I report issue or asking for help
2024-09-24 20:43:49 <mio> yeah, it's unfortunate when it does happen. but in a way things will probably turn out okay, either it works or gets temporarily disabled if broken
2024-09-24 23:10:41 <Ariadne> i would just disable cyclone on loongarch for now
2024-09-24 23:22:52 <mio> okay, thanks
2024-09-25 06:44:12 <huajingyun> ikke: It looks like we have a loongarch64 docker edge image that we can use（https://gitlab.alpinelinux.org/alpine/infra/docker/alpine）
2024-09-25 06:45:02 <ikke> Yes, I have been working on making that available
2024-09-25 06:45:47 <ikke> My goal is to have it as registry.alpinelinux.org/img/alpine
2024-09-25 06:51:18 <huajingyun> Thank you very much!
2024-09-25 06:51:33 <huajingyun> So,will we make it an official alpine image in the future as well?
2024-09-25 06:55:22 <ikke> We have to think about that
2024-09-25 06:55:33 <ikke> Regarding bandwidth and availability
2024-09-25 07:03:05 <huajingyun> ikke:If there's anything we can help you with, please let me know
2024-09-25 10:19:27 <ikke> Would probably be good for the TSC to take a decission
2024-09-25 12:38:56 <clandmeter> Sounds scary
2024-09-25 12:40:18 <ikke> It does
2024-09-25 19:19:01 <Ariadne> it would be nice to have alpine images that are signed with something more meaningful than docker notary v1
2024-09-25 19:19:59 <ikke> Something like cosign?
2024-09-25 19:20:07 <Ariadne> yeah
2024-09-25 19:20:41 <Ariadne> imo the ideal scenario is one where the docker library just becomes `FROM registry.alpinelinux.org/img/alpine:${VERSION}`
2024-09-25 19:21:31 <ikke> I doubt docker will do that
2024-09-25 19:21:42 <ikke> depend on another registry
2024-09-25 19:22:46 <Ariadne> they do for some other images
2024-09-25 19:24:29 <ikke> Hmm, we control the actual docker files
2024-09-26 05:04:36 <cely> Anyone interested in Librewolf on Loongarch?
2024-09-26 05:05:24 <cely> I'm trying another approach to patching the libc crate with Librewolf, and if CI is green, i'll probably open an MR for that, and use the same approach for Firefox as well
2024-09-26 05:50:15 <cely> ptrc: i think i have now addressed your concerns regarding the size of the Rust libc patch
2024-09-26 05:50:38 <cely> The same patch is used in !72531 and !72075
2024-09-26 06:37:10 <huajingyun> cely: use "_clear_vendor_checksums libc" instead of Rust libc patch?
2024-09-26 06:38:14 <cely> No, i just patched Loongarch support, instead of upgrading the whole libc crate to 0.2.155
2024-09-26 06:38:24 <cely> It is a similar patch to the one we used to use for main/rust
2024-09-26 06:38:56 <cely> and of course, with that, we can use `_clear_vendor_checksums`
2024-09-26 06:39:08 <cely> The idea came to me as we used _clear_vendor_checksums in main/rust too
2024-09-26 06:39:25 <cely> So, i decided to try following what we did for main/rust, which is to patch only Loongarch support, instead of the whole libc crate
2024-09-26 06:39:44 <cely> and it seems to work, at least it builds
2024-09-26 06:40:45 <cely> Unless there is some other Loongarch commit you know that i should backport
2024-09-26 06:41:05 <cely> The commit i used is in Patch-Source of loong0021
2024-09-26 06:42:08 <mps> ACTION remember time when patches are not welcomed in alpine
2024-09-26 06:42:40 <cely> ACTION wonders, how many archs were enabled back then?
2024-09-26 06:43:02 <mps> 7 iirc
2024-09-26 06:43:12 <cely> Ok
2024-09-26 06:44:05 <mps> cely: I don't say anything against your effort and work, just nostalgia
2024-09-26 06:44:39 <cely> No worries, i know
2024-09-26 06:44:46 <mps> your work is awesome and I only say "big thanks to you"
2024-09-26 06:44:51 <cely> You're welcome
2024-09-26 06:45:17 <cely> The next version of libc will have Loongarch support, so whenever upstream decides to finally upgrade, we will be able to drop that patch
2024-09-26 06:45:30 <cely> or rather, the next version after what Firefox currently uses
2024-09-26 06:45:34 <huajingyun> cely:Oh, it looks very good,thanks
2024-09-26 06:45:52 <cely> You're welcome as well
2024-09-26 06:46:08 <cely> and it seems the tmp builder has finally cleared the backlog it had while being blocked on busybox
2024-09-26 06:46:18 <mps> cely: libc? you mean musl?
2024-09-26 06:46:26 <cely> No, Rust libc crate
2024-09-26 06:46:30 <cely> https://github.com/rust-lang/libc
2024-09-26 06:46:31 <mps> ah, ok
2024-09-26 06:46:48 <mps> thanks for info
2024-09-26 06:47:00 <cely> Firefox uses 0.2.153 now, and Loongarch support was added in 0.2.154
2024-09-26 06:47:17 <cely> but 0.2.154 was yanked, so 0.2.155 is what we've been using
2024-09-26 06:47:30 <cely> Now i see the latest is 0.2.159
2024-09-26 06:48:53 <cely> No idea what upstream's upgrade schedule is for that, but sooner or later, they'll have to upgrade
2024-09-26 06:55:13 <huajingyun> Yeah,indeed
2024-09-26 11:01:18 <ncopa> has anyone tried passive cooling for the 3A6000?
2024-09-26 11:02:28 <ncopa> also, are there any temperature sensors to monitor the temp?
2024-09-26 11:29:36 <mps> ncopa: lm-sensors works
2024-09-26 11:31:42 <mps> btw, thanks for fixing qemu
2024-09-26 11:32:37 <ncopa> yw
2024-09-26 11:35:36 <mps> afaik temperature measurement of cpu for linux still doesn't work
2024-09-26 11:35:50 <mps> or I didn't tried more hardly
2024-09-26 12:12:53 <clandmeter> By the noise I hear passive will be challenging
2024-09-26 12:13:03 <clandmeter> maybe liquid cooling
2024-09-26 12:13:15 <clandmeter> bigger fan will make less noise
2024-09-26 12:13:54 <clandmeter> Or noctua
2024-09-26 14:02:39 <ncopa> does the cpu actually have temp sensors and it is only the linux driver that is missing? or is the sensors missing?
2024-09-26 14:03:05 <ncopa> im slightly scared of experimenting with the cooing without being able to measure the difference
2024-09-26 14:14:05 <mps> I bet they have but drivers is not yet ready
2024-09-26 20:48:43 <Ariadne> clandmeter: the default thermal compound shipped out by loongson is terrible. i replaced it with some high quality thermal compound and my CPU temps are very low
2024-09-26 20:49:45 <clandmeter> ah nice
2024-09-26 20:50:10 <clandmeter> would it run passive?
2024-09-26 20:50:30 <clandmeter> i guess you would need more flow in the chassis
2024-09-26 20:52:27 <clandmeter> Ariadne: you have the same setup?
2024-09-26 20:52:35 <Ariadne> i suspect with good thermal compound (i used alumichill from TCRS thermal) you could run passively
2024-09-26 20:52:54 <Ariadne> (and an appropriate heat sink of course)
2024-09-26 20:52:57 <clandmeter> i have some indium in my office, which should also work nicely :)
2024-09-26 20:54:01 <Ariadne> i have 3a6000 evaluation board, and the other board from ASUS China
2024-09-26 20:54:25 <clandmeter> you didnt get the complete desktop like we have?
2024-09-26 20:54:35 <Ariadne> no :)
2024-09-26 20:54:46 <Ariadne> but it is likely the same thermal compound nonetheless
2024-09-26 20:54:54 <clandmeter> nod
2024-09-26 20:55:49 <Ariadne> if i were to do it again i would probably get the full desktop SKU instead, because the shipping quality was ... less than confidence inspiring
2024-09-26 20:57:38 <Ariadne> https://usercontent.irccloud-cdn.com/file/xHRVG2vt/IMG_4229.JPG
2024-09-26 20:57:50 <Ariadne> https://usercontent.irccloud-cdn.com/file/2FQAXImF/IMG_4230.JPG
2024-09-26 20:58:07 <Ariadne> that's the box it came in and the 3a6000 evaluation board i have, haha
2024-09-26 20:58:17 <clandmeter> ah same board
2024-09-26 20:58:21 <clandmeter> just bad packaging
2024-09-26 20:58:27 <clandmeter> our packaging was pretty nice
2024-09-26 20:58:38 <clandmeter> i would dare to drop it from a meter or so
2024-09-26 20:58:49 <Ariadne> yeah i was very worried when i saw it came that way
2024-09-26 20:59:16 <Ariadne> but it survived :)
2024-09-26 20:59:18 <clandmeter> which probably happened along the way here, following the current standards of forwarders
2024-09-26 21:00:11 <Ariadne> from my understanding it will thermal throttle if it overheats
2024-09-26 21:00:40 <Ariadne> but yeah they used the typical OEM thermal compound
2024-09-26 21:00:43 <clandmeter> if the fan some kind of custom design?
2024-09-26 21:00:50 <clandmeter> is*
2024-09-26 21:01:00 <Ariadne> no, i think it is just a standard intel one
2024-09-26 21:01:24 <Ariadne> one catch of course is that its a soldered on SoC instead of socketed
2024-09-26 21:01:29 <Ariadne> so some coolers may be incompatible
2024-09-26 21:02:00 <clandmeter> ah ok, did you make a pic of the chip?
2024-09-26 21:02:05 <Ariadne> there is an IHS though so it's not like old school athlon xp days where you could crack the package
2024-09-26 21:02:13 <clandmeter> i havent removed the HS/fan
2024-09-26 21:03:44 <Ariadne> the chip is boring, it's just a typical ceramic package with integrated heat spreader soldered onto it
2024-09-26 21:03:55 <Ariadne> like any modern amd or intel chip
2024-09-26 21:03:57 <clandmeter> overall its pretty mature, design, hw, and sw too. much more mature compared to the rv ones.
2024-09-26 21:04:09 <Ariadne> yes, i was pleasantly surprised
2024-09-26 21:04:39 <clandmeter> and performance aint bad
2024-09-26 21:05:03 <Ariadne> because when i was considering expanding our mips64 port with mips64el, i looked at loongson for that and it was hard to source one and reviews indicated the hw was somewhat unstable
2024-09-26 21:05:43 <Ariadne> so loongarch being production quality is much better
2024-09-26 21:06:35 <Ariadne> unfortunately, i am not sure how the current trade climate will impact their ability to sell loongarch in the west
2024-09-26 21:08:02 <Ariadne> but i've been using my loongarch machine as a daily driver for personal tasks and it's been solid
2024-09-26 21:08:41 <clandmeter> any idea what the nm process of cpu is?
2024-09-26 21:08:45 <Ariadne> 14nm
2024-09-26 21:09:04 <Ariadne> but process node at this point isn't that important anymore
2024-09-26 21:09:15 <Ariadne> the real challenge will be for them to get higher clock speeds
2024-09-26 21:10:06 <Ariadne> loongson does have a US subsidiary now -- Loongson Technology LLC
2024-09-26 21:10:22 <Ariadne> which indicates to me that they are likely to launch products in the west formally
2024-09-26 21:10:35 <Ariadne> and verses RISC-V and ARM it could be very competitive
2024-09-26 21:11:51 <Ariadne> i think that's kind of a key difference between loongarch and risc-v. there is an actual business with actual business goals backing loongarch, while risc-v is more of a "if we build it, they will come" type of thinking. problem is risc-v you still need to license patents if you want things like out-of-order execution. with loongarch they already have the patent licenses.
2024-09-26 21:12:00 <clandmeter> it will be hard for their semi manufacturer to get proper machines like the ones from ASML in china
2024-09-26 21:12:44 <Ariadne> i don't think that part is so important. AFAIK the loongarch chips today are fabbed by TSMC
2024-09-26 21:13:04 <clandmeter> are you sure?
2024-09-26 21:13:20 <Ariadne> that is what i've read, that it is on TSMC's 14nm process node
2024-09-26 21:13:29 <Ariadne> and TSMC has fabs in mainland china
2024-09-26 21:14:02 <clandmeter> maybe, but they wont have euv
2024-09-26 21:14:09 <Ariadne> though i don't think the Nanjing facility has the latest process nodes
2024-09-26 21:14:34 <clandmeter> so they will get stuck on 14 or whatever is possible with it.
2024-09-26 21:14:43 <clandmeter> without it
2024-09-26 21:14:44 <Ariadne> the smarter plan would be to sublicense loongarch to other companies
2024-09-26 21:14:54 <Ariadne> like intel did with x86
2024-09-26 21:15:42 <Ariadne> but to me, a weirdo living in the US buying things off aliexpress, this is all just a curiosity
2024-09-26 21:16:38 <clandmeter> from what i read the main goal is china, and lots of schools would move to it.
2024-09-26 21:16:39 <mps> few days ago I read somewhere that ASML is ready to work with chinese manufacturers
2024-09-26 21:16:52 <clandmeter> which means millions of systems
2024-09-26 21:17:26 <Ariadne> yeah i think we will see loongarch gain dominance first in china, but other markets like india seem likely too
2024-09-26 21:17:37 <mps> though 'ready' doesn't mean they will do, imo
2024-09-26 21:17:54 <clandmeter> I only read the US is putting more presure on ASML
2024-09-26 21:18:02 <clandmeter> and the dutch gov
2024-09-26 21:18:03 <Ariadne> most likely ARM will become dominant in the west
2024-09-26 21:19:05 <Ariadne> but loongson can build a very healthy business just from china alone, and expand to other economies which don't necessarily trust the west
2024-09-26 21:19:15 <clandmeter> it took ampere long enough for their new chips to be general available
2024-09-26 21:19:18 <Ariadne> india being a large example, but also africa
2024-09-26 21:19:39 <Ariadne> ampere i don't think will be the one to do it
2024-09-26 21:19:43 <Ariadne> i think it will be qualcomm and apple
2024-09-26 21:19:55 <mps> india and china have some conflicts, iiuc
2024-09-26 21:20:00 <Ariadne> qualcomm is trying to buy intel, probably to kill x86 :P
2024-09-26 21:20:04 <clandmeter> well im talking more in the server business now
2024-09-26 21:20:20 <Ariadne> oh, loongarch isn't anywhere near ready yet to compete in server
2024-09-26 21:20:53 <Ariadne> 16 cores can't compete with AMD EPYC and other big machines like POWER (although IBM seems to be doing a great job at convincing folks to not buy POWER10)
2024-09-26 21:22:53 <clandmeter> i had a talk with one of the power ppl some time ago
2024-09-26 21:23:12 <clandmeter> i think their focus is on ocp?
2024-09-26 21:24:34 <Ariadne> it was, but they've made moves with POWER10 to make some parts closed source again
2024-09-26 21:25:18 <Ariadne> mps: yes, india and china have a complicated relationship, but while they bicker with each other they also collaborate in a number of areas too
2024-09-26 21:26:55 <Ariadne> (at least those 16 3c5000 cores are reasonably performant though... the milk-v builder we have is... well, ouch)
2024-09-26 21:27:34 <clandmeter> i think they would love us to make ppc servers again, or atleast make them compatible with that ocp interchangeable socket design (don't remember the name) which sound pretty complicated to do right.
2024-09-26 21:27:39 <mps> yes, milk-v pioneer is surprisingly slow
2024-09-26 21:28:00 <Ariadne> i guess it is technically faster than qemu :D
2024-09-26 21:28:24 <mps> yes, and it is realy faster
2024-09-26 21:28:34 <mps> but still slow
2024-09-26 21:28:34 <clandmeter> depends which cpu you throw at it :)
2024-09-26 21:29:03 <Ariadne> afaik we were running on some AMD EPYC system with qemu before
2024-09-26 21:29:30 <Ariadne> i am just glad somebody kept MIPS going
2024-09-26 21:29:43 <Ariadne> because MIPS themselves are now slinging risc-v :D
2024-09-26 21:29:48 <clandmeter> yes it was single socket rome i think
2024-09-26 21:30:03 <clandmeter> so we need to move to Zen 5c dual socket :)
2024-09-26 21:30:11 <clandmeter> 192 cores x 2 :D
2024-09-26 21:31:10 <clandmeter> how would 768 threads look like in htop?
2024-09-26 21:31:23 <mps> when started to making riscv opensbi, u-boot and kernel for alpine I worked with old macbook from 2009 year with 4 cores and 8MB RAM
2024-09-26 21:31:45 <mps> that was slow
2024-09-27 04:26:04 <cely> !72598 the patches apply, let's see if it builds
2024-09-27 04:27:59 <cely> ptrc: i have rebased !72425 for what is likely the last time, i have tried, as much as possible, to reduce the size of the patches, and i feel this is as small as it can get
2024-09-27 04:28:56 <cely> The largest, the Rust libc crate patch, was also used in main/rust (not the exact patch, as i think main/rust used a previous version)
2024-09-27 04:31:15 <cely> and i think for one or two versions of main/rust, that patch was actually duplicated 3 times (for the 3 versions of vendored libc), before the vendored libc's started to multiply out of control, and so i started applying the same patch to all vendored libc's
2024-09-27 04:32:04 <cely> Anyway, what i am getting at is, this is not the first time the Rust libc patch has been imported into aports
2024-09-27 04:33:32 <cely> I guess this time, instead of being duplicated 3 times for the same aport, it is duplicated for different aports: firefox, firefox-developer-edition, librewolf, mozjs
2024-09-27 04:33:43 <cely> Maybe you will want to put the patch on dev.a.o, or something
2024-09-27 04:34:01 <cely> As it seems the same patch can be applied to all of them, for now at least
2024-09-27 04:42:40 <cely> For firefox-developer-edition, --disable-elf-hack isn't available for Loongarch, so i've taken the method for applying it conditionally from firefox-esr
2024-09-27 04:44:25 <cely> Looking at the WebRTC patch, it seems that's only enabled for X11, and not Wayland, mentioning it here in case anyone wants to look into that later
2024-09-27 04:50:19 <cely> and actually, as i was saying yesterday, Firefox currently uses version 0.2.153 of the Rust libc crate, which is the last version without Loongarch support
2024-09-27 04:51:39 <cely> So, if an upgrade causes that patch to no longer apply, most likely, the patch won't be needed anymore (unless upstream downgraded the crate, which would be a bit weird)
2024-09-27 05:49:23 <cely> For firefox-developer-edition, it seems --enable-sandbox is also not available for Loongarch
2024-09-27 17:08:12 <Ariadne> this loongarch desktop is ridiculously solid
2024-09-27 17:08:51 <Ariadne> like definitely one of the better non-x86 setups i have
2024-09-27 17:18:50 <mps> yes, especially when yesterday found in garage my old logitech bluetooth keyboard with trackpad on it, so no mouse to annoy me
2024-09-27 17:19:26 <mps> only need better monitor, one I use is about 16-20 years old
2024-09-27 17:21:49 <mps> slider with leds on keyboard to control sound volume is awesome thing
2024-09-27 17:53:39 <ikke> CI has now been switched over to our own images, meaning it gets pacakges now from dl-cdn
2024-09-27 17:54:02 <Ariadne> mps: be careful with those old logitech K400s
2024-09-27 17:54:07 <Ariadne> they can be MITM'd :)
2024-09-27 17:54:50 <ikke> Hmm, I have one
2024-09-27 17:54:52 <ikke> k400r
2024-09-27 17:55:17 <mps> IDK model for my
2024-09-27 17:55:23 <ikke> Use it only occasionally though
2024-09-27 17:56:02 <mps> though I don't use bluetooth for years, don't like it
2024-09-27 17:56:34 <Ariadne> K400 is the bluetooth keyboard with touchpad
2024-09-27 17:57:09 <ikke> The one I have is not bluetooth
2024-09-27 17:58:55 <mps> can't find that model is printed on it. it has aluminium palm rest part
2024-09-27 18:00:31 <mps> mine is different of this https://www.logitech.com/en-ca/shop/p/k400-plus-touchpad-keyboard.920-007119
2024-09-27 18:03:47 <Ariadne> ah ok
2024-09-27 18:04:45 <mps> but anyway, if it is bluetooth it is suspicious
2024-09-27 18:06:40 <mps> I doubt there are a hackers near me
2024-09-27 21:22:59 <ikke> packages in testing will fail on loongarch now though in CI due to testing not yet being available
2024-09-27 21:29:18 <mio> fail at the builder or the ci?
2024-09-27 21:37:57 <ikke> CI
2024-09-27 21:38:18 <ikke> The builder itself has the repo, but it's not uploaded to dl-cdn yet untill everything suceeeds
2024-09-27 21:39:43 <mio> okay
2024-09-27 21:43:06 <mio> it's waiting for the ~119 testing/ aports?
2024-09-27 22:01:31 <mio> in that case, might have to move up some abumps, was hoping to wait for some to come in organically
2024-09-27 22:02:47 <ikke> yes, now 121 aports left
2024-09-28 02:50:46 <cely> Are there plans to manually sync testing/ to dl-cdn?
2024-09-28 04:30:42 <cely> Until a few minutes ago, i was under the impression that only packages in testing/ that depends on things in testing/ would fail in CI
2024-09-28 04:31:52 <cely> and packages in testing/ that depend only main/ and community/ would still succeed.
2024-09-28 04:32:44 <cely> Now it seems that is not the case, and everything in testing/ fails
2024-09-28 04:33:12 <cely> so, we have no CI for Loongarch now for packages in testing/
2024-09-28 04:36:32 <cely> I guess that means any new aport added to testing/ will also fail CI for Loongarch, which means we are working blind here
2024-09-28 04:38:56 <cely> I wonder, if there are no plans to sync testing/ before all aports pass, perhaps at least a temporary APKINDEX.tar.gz with no aports (if such a thing is allowed) can be added to dl-cdn's testing/ directory
2024-09-28 04:39:36 <cely> and that can make CI work for aports in testing/ that only depend on main/ and community/
2024-09-28 05:48:55 <cely> 98 aports left to build in testing/
2024-09-28 07:54:18 <mps> does this means that we can use CDN as repositories for main and community?
2024-09-28 08:22:45 <cely> Yes, i think that has been possible ever since the official builder finished uploading community/
2024-09-28 08:24:18 <cely> and i guess (but am not certain) even before that, community/ had been manually sync'ed once
2024-09-28 08:52:11 <mps> nice, thanks for info
2024-09-28 08:54:02 <cely> You're welcome
2024-09-28 19:38:27 <mps> hm, I expected more for loongarch with 6.12 kernel https://lore.kernel.org/lkml/20240927142320.2144898-1-chenhuacai@loongson.cn/
2024-09-29 03:02:50 <cely> community/firefox and librewolf are now available on Loongarch
2024-09-29 07:22:51 <cely> So, what do we do now that a rather heavyweight aport like !72721 needs to be added to testing/ and the CI for Loongarch is not working testing/?
2024-09-29 07:23:04 <cely> for testing/*
2024-09-29 19:21:17 <mio> ikke: do you have a plan for how to proceed to remove(? disable?) broken testing/ aports?
2024-09-29 19:21:48 <mio> or rather, is there anything could help with to supplement your efforts to avoid duplication?
2024-09-29 19:23:22 <mio> was initially going to check my list of ftbfs testing/ aports against the listing on pkgs.a.o where maintainer = None and repo = testing
2024-09-29 19:23:50 <ikke> If there is no maintainer, I'd say just drop it. I'm not personally actively working on that though
2024-09-29 19:24:04 <mio> then open MRs based on matches, with priority to the ~63 aports left
2024-09-29 19:24:39 <mio> on the loongarch builder
2024-09-29 19:24:45 <ikke> ahuh, that would help
2024-09-29 19:25:14 <ikke> We will run into this anyway with the 3.21 release, so it's either doing the work now, or doing it later
2024-09-29 19:25:41 <mio> okay. from the brief discussion on #alpine-devel thought you were starting on it
2024-09-29 19:25:59 <mio> 3.21 release includes rebuilding testing/ ?
2024-09-29 19:26:09 <ikke> Hmm, actually it doesn't
2024-09-29 19:28:10 <mio> okay. the short-term objective for me at the moment is to unblock the loongarch builder so we could get loongarch ci back
2024-09-29 19:28:21 <ikke> Yup, that's a good plan
2024-09-29 19:30:48 <mio> yeah. as mentioned in -devel already started to ping maintainers about existing ftbfs, especially among the ~60 aports
2024-09-29 19:32:06 <mio> hopefully when the ones with no maintainers are set aside the remaining ones with maintainers will come through by then
2024-09-29 19:32:53 <mio> if not, would try to disable on loongarch64 for now to unblock the builder
2024-09-29 19:33:06 <mio> (that's the fallback workaround)
2024-09-29 19:33:13 <ikke> palp has no maintainer
2024-09-29 19:34:26 <mio> okay, thanks ... will send MR, unless it is easier/more convenient for you to push a commit directly
2024-09-29 19:34:47 <ikke> Hmm, I may have a solution
2024-09-29 19:35:25 <mio> batch rebuild on ci?
2024-09-29 19:35:39 <ikke> No, I mean for palp :p
2024-09-29 19:36:00 <mio> lol
2024-09-29 19:37:05 <mio> rue's maintainer is likely inactive, already flagged it 3 days ago and no update. newer versions don't work
2024-09-29 19:37:38 <mio> s/don't work/ftbfs/, project website 404 though repo is available still
2024-09-29 19:38:23 <mio> wol has a patchset on gentoo, haven't gotten around to it yet
2024-09-29 19:40:14 <mio> (will leave that one for now, unless ptrc gets to it first)
2024-09-29 19:40:30 <ikke> I suppose we should drop palp as well
2024-09-29 19:42:10 <mio> zile hasn't been updated in a while, don't know if maintainer is still active. was considering using -Wno-incompatible-pointer-types on it as the errors appear to be coming from vala generated code and vala hasn't been updated yet
2024-09-29 19:43:52 <mps> ikke: I think to remove pfqueue from repo, it is old, outdated and not maintained upstream
2024-09-29 19:44:16 <mio> (just going through the gcc 14 list, of the ones currently ftbfs on the builder)
2024-09-29 19:44:25 <ptrc> mio: now that you've said it, i might go and fetch the patch :p
2024-09-29 19:44:29 <ptrc> thanks for checking!
2024-09-29 19:45:00 <ikke> mps: Yeah, I'd say drop it
2024-09-29 19:45:15 <mps> thanks
2024-09-29 19:45:43 <mio> ptrc: thanks for handling that one :) sorry, been meaning to contact you or do it via MR, but didn't get around to it
2024-09-29 19:46:31 <mps> heh, just noticed that I don't know how to remove pkg from aports
2024-09-29 19:46:46 <mio> ikke: there's an open MR to disable pfqueue, feel free to close it lol
2024-09-29 19:47:04 <ikke> mps: Just remove the files and commit that
2024-09-29 19:47:38 <mps> ok, lets try to learn something new, would be useful in near future :)
2024-09-29 19:47:51 <ikke> git rm -r testing/pfqueue
2024-09-29 19:51:00 <mps> already done
2024-09-29 19:51:18 <ikke> 👍
2024-09-29 19:51:19 <mps> anyway, thanks again
2024-09-29 19:51:40 <mio> cool, closed the other MR
2024-09-29 19:52:00 <ikke> That cleans up
2024-09-29 19:52:10 <mio> better direct from the maintainer :)
2024-09-29 19:52:17 <mps> I think I have few other pkgs candidates for `git rm -r ...` ;)
2024-09-29 19:52:34 <ikke> mio: Not sure if it helps, and a bit late, but we could make a milestone for this effort, just like we did for the /usr merge
2024-09-29 19:52:52 <ikke> https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16#tab-issues
2024-09-29 19:53:15 <mps> `git rm -r /usr merge`
2024-09-29 19:53:32 <mio> sure, not too late if it helps with visibility for notifying maintainers
2024-09-29 19:53:54 <ikke> Helps to keep track of all the various issues and MRs
2024-09-29 19:56:39 <ikke> https://gitlab.alpinelinux.org/groups/alpine/-/milestones/17#tab-issues
2024-09-29 20:00:30 <mio> fwiw a preliminary list of ftbfs in testing on x86_64 if people want to check if their packages are possibly affected https://0x0.st/Xg1o.log
2024-09-29 20:02:17 <mio> a chunk of them have been fixed, so that list is more for awareness
2024-09-29 20:03:37 <mio> if maintainers recognise one on the list and it hasn't been fixed yet, to work out something
2024-09-29 20:03:38 <mps> mio: now I think it would be better to remove also gforth, same reasons as for pfqueue
2024-09-29 20:04:23 <mio> mps: okay, go for it. will close the other MR
2024-09-29 20:04:52 <mps> last release is from 2014-07-09
2024-09-29 20:05:39 <mio> it's kind of popular among esolang and retrocomputing ethusiasts
2024-09-29 20:06:43 <mps> removed
2024-09-29 20:07:30 <mps> but it is buggy, at least with musl. probably upstream don't care about musl
2024-09-29 20:08:36 <mps> yes, I like forth and still plays sometimes with it but think that gforth shouldn't be in alpine
2024-09-29 20:11:50 <mio> that's unfotunate, but understandable to remov rather than ship a bugged build
2024-09-29 20:12:01 <mio> s/remov/remove/
2024-09-29 20:12:15 <mps> right
2024-09-29 20:12:40 <mps> I don't want alpine to become trash can
2024-09-29 20:13:08 <mps> "bloated trach can" TM :)
2024-09-29 20:13:31 <mps> s/trach/trash/
2024-09-29 20:16:27 <mio> s/unfotunate/unfortunate/ one person's trash is another's treasure :)
2024-09-29 20:17:49 <mio> not pushing for or against keeping, just that the saying could sometimes apply to packages as well
2024-09-29 20:19:48 <mps> mio: I'm not surprised because our civilization became 'trash civilization'. we produce mostly trash, but enough OT
2024-09-29 20:20:51 <mio> lol
2024-09-29 20:24:13 <mio> ikke: gtk4-layer-shell ftbfs due to failed tests, no maintainer according to pkgs.a.o
2024-09-29 20:26:11 <mio> liblinbox, gcc/c++20 errors
2024-09-29 20:33:44 <mio> evolution-on, ftbfs with gcc 14
2024-09-29 20:35:22 <mio> those are the remaining ones not yet fixed with no maintainer ... unfortunately(?) a few were already fixed, maybe those could be left in for now?
2024-09-29 20:47:04 <mio> compton-conf, ftbfs with gcc 14
2024-09-29 20:59:40 <mio> correction, not gcc 14 issue, vaguely recall it had some problem finding required qt libs
2024-09-29 23:35:56 <mio> !72763
2024-09-29 23:38:05 <mio> for avdl/rue, the maintainer has not had any gitlab activity for >=2 years, so the packages are likely unmaintained
2024-09-30 03:07:54 <huajingyun> Does anyone want to merge !72526 and !72493? This fixes lua-xml and beancount-language-server in testing
2024-09-30 03:16:43 <mio> +1 lua-xml, that one has been in the queue for a while
2024-09-30 03:17:03 <mio> both are still blocking the loongarch builder
2024-09-30 03:22:06 <huajingyun> Yes
2024-09-30 03:22:14 <huajingyun> and there are 40 left for testing
2024-09-30 03:25:57 <mio> yes, a number of us are gradually working through them, removing aports that are unmaintained or temporarily disabling ones for loongarch64 which are non-trivial to fix or upstream fix is unavailable yet
2024-09-30 03:26:57 <mio> to clarify, for most the issue is not limited to loongarch64 but it will enable unblocking the builder to restore ci to testing/
2024-09-30 03:29:42 <mio> and buy some time for maintainers to find/wait for upstream fix as applicable
2024-09-30 03:32:06 <huajingyun> Thanks for all the hard work, once the testing are unlocked, ci and builder will all be on track.
2024-09-30 03:34:49 <mio> thanks for helping out as well and being available to answer questions about loongarch!
2024-09-30 03:39:40 <huajingyun> You're welcome, this is what I do, I'm happy to share what I know with you, and I'm glad that loongarch64 can bring you a good experience.
2024-09-30 03:41:11 <huajingyun> We will have 7 days holiday starting tomorrow. Hopefully, when I come back, all the testing will be done and unlocked:-D
2024-09-30 03:45:47 <cely> 33 aports left
2024-09-30 07:16:59 <cely> We should be down to 19 aports left
2024-09-30 07:19:41 <cely> but i can only identify 18: apt-dater, asteroid-launcher, beancount-language-server, bordeaux, clipit, dnssec-tools, goomwwm, ideviceinstaller, libretro-daphne, lua-xml, node-libpg-query, php82-pecl-jsmin, postgresql-pg_variables, shellinabox, wmi-client, wol, xsane, youki
2024-09-30 07:19:48 <cely> Quite a few of them have open MRs
2024-09-30 07:27:17 <mio> huajingyun: afk for a bit, enjoy the holiday! yes, hopefully loongarch64 testing/ will be done by then, or at least ci restored
2024-09-30 08:07:57 <cely> Ok, another 2 more fixed, which should bring the number down to 17
2024-09-30 08:08:02 <cely> I'll be going AFK, bye
2024-09-30 08:38:00 <qaqland> community/git-interactive-rebase-tool has libc patch, but is not enabled
2024-09-30 08:38:09 <qaqland> was is forgotten?
2024-09-30 08:38:39 <qaqland> !66670
2024-09-30 09:06:27 <huajingyun> mio: Thanks
2024-09-30 09:06:32 <huajingyun> qaqland: Hmm, it seems it was missed in https://git.alpinelinux.org/aports/commit/?id=2eca57288555
2024-09-30 09:07:34 <huajingyun> cely: Thank you for the list
2024-09-30 09:18:10 <huajingyun> qaqland: Rebuild git-interactive-rebase-tool for loongarch64 reports an error. Maybe I'll take some time to look at it next week, if you're willing to look at it, I'll be very grateful.
2024-09-30 10:03:43 <huajingyun> I'm going AFK, bye
2024-09-30 13:11:16 <clandmeter> Ariadne: plasma working ok on loong?
2024-09-30 13:45:31 <mio> could we possibly get some assistance to merge open MRs for beancount-language-server, postgresql-pg_variables and youki? or someone to alternatively fix?
2024-09-30 13:47:03 <mio> !72493 !72664 !72350
2024-09-30 13:49:03 <mio> they are among the 14 aports left on the builder
2024-09-30 13:49:43 <mio> thanks
2024-09-30 13:50:32 <mps> ask jirutka in comments for youki, I don't like to touch MRs assigned to him
2024-09-30 13:51:32 <mps> and for postgresql-pg_variables
2024-09-30 13:52:26 <mps> for !72493 also ask assignee
2024-09-30 13:53:00 <mio> okay, thanks. will try to ping them again
2024-09-30 14:54:26 <Ariadne> clandmeter: yes
2024-09-30 16:11:08 <cely> It seems J0WI has started looking over their "enable on more archs" MRs
2024-09-30 16:11:27 <cely> Hopefully that does not run into issues due to the lack of Loongarch CI for testing/
2024-09-30 16:50:05 <cely> I have counted 10 aports left to build (there is the last one that i keep being unable to identify): apt-dater, asteroid-launcher, beancount-language-server, dnssec-tools, libretro-daphne, postgresql-pg_variables, wmi-client, wol, xsane, youki
2024-09-30 17:09:38 <mps> cely: asteroid-launcher fail with message 'lipstick-asteroidos-dev (no such package):'
2024-09-30 17:09:50 <mps> have no idea why
2024-09-30 17:10:46 <mps> maybe lipstick-asteroidos isn't built on loongarch
2024-09-30 17:12:35 <mio> yeah, lipstick-asteroidos ftbfs, a commit was merged to temporarily disable it for loongarch64
2024-09-30 17:13:00 <mio> though not sure if it is the cause of the unknown package
2024-09-30 17:13:48 <mps> I guess yes
2024-09-30 17:13:53 <mio> (with permission from the maintainer)
2024-09-30 17:14:28 <mps> I think similar issue is with xsane but not sure
2024-09-30 17:14:41 <mps> I don't want to touch these pkgs
2024-09-30 17:16:14 <mps> if lipstick-asteroidos is disabled then trying to build asteroid-launcher will not work and it also should be disabled
2024-09-30 17:16:19 <cely> Seems there is !65080 from a few months ago
2024-09-30 17:16:53 <cely> and it is being moved to community in !72749
2024-09-30 17:19:09 <mps> apt-dater failed while patching
2024-09-30 17:20:19 <mps> sorry, missing shtool
2024-09-30 17:22:19 <cely> Yeah, i think it's due to old automake
2024-09-30 17:23:15 <cely> Anyway, thanks for looking into the packages, i think most of them will need to wait for maintainer to handle them though
2024-09-30 17:23:51 <mps> or disabled
2024-09-30 17:25:36 <mps> these pkgs doesn't look as important and could be disabled on loongarch till maintainers fix them
2024-09-30 17:26:10 <mps> they don't work on loongarch anyway so no issues
2024-09-30 17:28:53 <cely> Ok, will consider that option, still waiting for the few MRs where mio pinged the maintainers to see if there will be any feedback
2024-09-30 19:19:31 <clandmeter> chromium still having issues on loong/
2024-09-30 19:35:02 <clandmeter> that was a question :)
2024-09-30 19:38:12 <mps> and answer :)