#archlinux32 | Logs for 2022-08-01
Back
[00:00:31] -!- GNUtoo has joined #archlinux32
[00:15:42] -!- drathir_tor has joined #archlinux32
[01:07:03] -!- drathir_tor has quit [Remote host closed the connection]
[01:12:25] -!- drathir_tor has joined #archlinux32
[01:25:27] -!- drathir_tor has quit [Remote host closed the connection]
[01:25:48] -!- drathir_tor has joined #archlinux32
[04:04:54] -!- abouvier has quit [Quit: kthxbye]
[04:06:52] -!- abouvier has joined #archlinux32
[04:29:46] <bill-auger> there is currently a mismatch between clang and the wasi- compilers
[04:30:28] <bill-auger> the wasi- compilers are at v14 in community; but clang 14 s in staging
[04:31:18] <bill-auger> for me, it caused a lining error building mozilla
[04:54:53] <bill-auger> and llvm 14, llvm-libs 14 are in testing
[05:14:35] <bill-auger> nope its insane - now rust wants llvm 13
[05:19:02] <bill-auger> i just had an idea though - anything that gets shifted out of core,extra,community could be heaped into a special [dustbin] repo
[05:20:49] <bill-auger> arch32 packaging guide: "you can try; but it probably wont work - if not, try to enable [staging] - if that doesnt work, try [testing] - if that doesnt work, try the [dustbin] - good luck cowboy!"
[08:03:21] <buildmaster> Hi abaumann!
[08:03:21] <buildmaster> !rq abaumann
[08:03:22] <phrik> buildmaster: <abaumann> Never understood why there is a fallback ramdisk, but no fallback kernel image.
[08:50:42] -!- abaumann has joined #archlinux32
[08:50:43] <buildmaster> Hi abaumann!
[08:50:43] <buildmaster> !rq abaumann
[08:50:43] <phrik> buildmaster: <abaumann> a babe is a checksum error
[08:51:25] <abaumann> bill-auger: yes, llvm is a mess currently, the only option is to use explicit llvm13 in depends and makedepends
[08:51:32] <abaumann> the idea with a dustbin is interesting.
[08:52:04] <abaumann> many packages just keep on being in core/extra/community, though they are stale (for example very old versions of wine), they usually don't rebuild too.
[08:52:24] <abaumann> but it means changes to the buildmaster in central places..
[09:08:11] <bill-auger> that would not have worked - iwas using llvm 13 - that what is in extra - but it wanted to link with wasi-compiler-rt 14
[09:08:40] <bill-auger> sry wasi-compiler-rt "13"
[09:08:52] <bill-auger> which is only in the archives
[09:10:00] <bill-auger> so i rolled llvm and clang up to 14, but then rust wanted v13
[09:10:55] <bill-auger> so .. in installed wasi-compiler-rt "13" fom the archive - i think it may work this time (173 minutes into the build now)
[09:16:24] <bill-auger> oh my , i see now why it is taking so long - im building mozilla for i686 and x86_64 at the same time on the same machine, and also magver started a build of linux
[09:16:36] <bill-auger> the poor thing is pegged all 16 cores at 100%
[09:18:01] <abaumann> I know the feeling, but usually mine is burning electrons using lto1-xxx and whatnot. :-)
[09:20:12] <bill-auger> i will let you know if it works - today may be a good weather day to build firefox 103 - v100 was the last one i could get to compile
[09:21:14] <abaumann> didn't try since v100, would be great if this works
[09:22:46] <bill-auger> theres a good chance - the first build failed furing linking after 65 minutes - that is a typical amount of time for completion
[09:38:27] -!- eschwartz has quit [*.net *.split]
[09:38:27] -!- petris has quit [*.net *.split]
[09:38:27] -!- KitsuWhooa has quit [*.net *.split]
[09:38:39] -!- petris has joined #archlinux32
[09:39:31] -!- KitsuWhooa has joined #archlinux32
[09:40:17] -!- drathir_tor has quit [Remote host closed the connection]
[09:50:50] -!- drathir_tor has joined #archlinux32
[11:00:05] -!- lithiumpt has quit [Ping timeout: 252 seconds]
[11:11:46] -!- lithiumpt has joined #archlinux32
[13:22:55] <bill-auger> nope it failed - same error as last month
[13:22:55] <bill-auger> /usr/bin/ld.bfd: /usr/lib/libicuuc.so.71: undefined reference to `std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30
[13:24:56] <bill-auger> that was with gcc10 again - i will try with gcc 12
[13:28:38] <abaumann> https://en.cppreference.com
[13:28:39] <phrik> Title: std::condition_variable::wait - cppreference.com (at en.cppreference.com)
[13:28:48] <abaumann> that's weird, this has been in the C++ standard for a while
[13:29:17] <abaumann> GLIBCXX_3.4.30 fits to which libstdc++ and gcc?
[13:32:21] <abaumann> I have a certain strange feeling of dejavu, like a circle between libstd++ and icu..
[13:36:30] <abaumann> https://gist.github.com
[13:36:38] <abaumann> sounds promising to get a list of ABIs avaiable..
[13:37:12] <abaumann> Something tells me libicu has been built against a newer version of gcc/libstdc++ (12) and thus is lacking the symbol if you compile it with an older gcc..
[13:38:45] <T`aZ> there are some hacks to rename or alias newer symbols so it links with the older versions, buuut , it's probably unsafe, the versioning is probably there for a reason
[13:38:53] <abaumann> ..or rather link
[13:39:51] <abaumann> yeah, rebuilding is usually the better approach..
[13:54:47] -!- GNUtoo has quit [Remote host closed the connection]
[13:54:47] -!- drathir_tor has quit [Write error: Connection reset by peer]
[14:00:09] -!- GNUtoo has joined #archlinux32
[14:05:16] -!- drathir_tor has joined #archlinux32
[14:52:57] -!- drathir_tor has quit [Remote host closed the connection]
[14:58:18] -!- drathir_tor has joined #archlinux32
[15:43:16] <abaumann> I could really pull out my hair: musl busybox still has endbr32 and mmx stuff in it..
[15:44:06] <abaumann> why -fcf-protection is even available in gcc when I specify -march-i486, I really don't know.. this doesn't make much sense..
[16:00:43] <abaumann> __do_global_dtors_aux: endbr32, sweet. the startup code has branch patching I cannot switch off
[16:03:14] <abaumann> Not to mention that busybox is a C program.
[16:20:00] <abaumann> __udivmoddi4 using mmx
[16:20:08] <abaumann> mmh. why is gcc emitting such code?
[16:20:15] <abaumann> funny, it's in fdisk.
[16:20:25] <abaumann> I suppose, it tries to compute some 1024k blocks or so :-)
[16:23:20] <KillerWasp> I don't know why, the audio starts to work 5 or 10 seconds after starting the application. The bug can be detected in mpv and timidity.
[16:23:47] <abaumann> mmh. maybe pulseaudio was shut down and has to start up again :->
[16:24:27] <abaumann> or it's a codec thing
[16:24:33] <KillerWasp> It seems more like the kernel takes a while to connect the application with the audio.
[16:24:35] <abaumann> it needs to buffer first
[16:24:58] <KillerWasp> abaumann: timidity don't use codecs/decodecs
[16:30:30] <abaumann> I would try without pulse..
[16:30:45] <abaumann> or restart your pulseaudio
[16:31:33] -!- drathir_tor has quit [Ping timeout: 268 seconds]
[16:36:31] -!- drathir_tor has joined #archlinux32
[16:46:21] -!- drathir_tor has quit [Ping timeout: 268 seconds]
[17:10:41] -!- drathir_tor has joined #archlinux32
[17:17:26] -!- abaumann has quit [Quit: leaving]
[20:16:10] -!- drathir_tor has quit [Remote host closed the connection]
[20:26:31] -!- drathir_tor has joined #archlinux32
[21:01:02] -!- drathir_tor has quit [Ping timeout: 268 seconds]
[21:01:02] -!- GNUtoo has quit [Ping timeout: 268 seconds]
[21:02:25] -!- GNUtoo has joined #archlinux32
[21:08:02] -!- drathir_tor has joined #archlinux32
[21:39:53] -!- GNUtoo has quit [Ping timeout: 268 seconds]
[21:46:17] -!- GNUtoo has joined #archlinux32
[22:24:08] -!- GNUtoo has quit [Write error: Connection reset by peer]
[22:26:45] -!- drathir_tor has quit [Ping timeout: 268 seconds]
[22:29:32] -!- GNUtoo has joined #archlinux32
[23:38:26] -!- drathir_tor has joined #archlinux32