#archlinux32 | Logs for 2019-07-05

Back
[00:10:13] <buildmaster> i686/qcad is broken (says eurobuild6-1).
[00:11:08] <buildmaster> pentium4/bzip2 is broken (says eurobuild6-3).
[00:28:30] -!- thePiGrepper has quit [Ping timeout: 244 seconds]
[00:35:52] -!- charims has quit [Ping timeout: 245 seconds]
[00:37:45] -!- charims has joined #archlinux32
[00:56:10] -!- thePiGrepper has joined #archlinux32
[01:12:27] -!- djmoch has quit [Quit: ZNC 1.7.3 - https://znc.in]
[01:14:27] -!- djmoch has joined #archlinux32
[01:19:10] <buildmaster> pentium4/qcad is broken (says nlopc43).
[01:57:30] -!- quequotion has quit [Quit: quequotion]
[02:14:50] <buildmaster> i686/vsftpd is broken (says eurobuild6-3).
[02:16:53] <buildmaster> i686/teamspeak3-server is broken (says eurobuild6-5).
[02:19:51] <buildmaster> pentium4/teamspeak3-server is broken (says eurobuild6-5).
[02:58:22] -!- samantaz has quit [Read error: Connection reset by peer]
[04:59:05] -!- quequotion has joined #archlinux32
[05:41:19] -!- thePiGrepper has quit [Ping timeout: 268 seconds]
[06:00:12] -!- quequotion has quit [Quit: quequotion]
[06:32:51] -!- DepositePirate has quit [Remote host closed the connection]
[06:33:17] -!- DepositePirate has joined #archlinux32
[07:01:23] <buildmaster> i686/gcc8 is broken (says buildknecht).
[07:05:00] -!- DepositePirate has quit [Ping timeout: 260 seconds]
[07:06:31] -!- DepositePirate has joined #archlinux32
[07:38:06] -!- abaumann has joined #archlinux32
[07:38:37] <buildmaster> Hi abaumann!
[07:38:37] <buildmaster> !rq abaumann
[07:38:38] <phrik> buildmaster: <abaumann> a babe is a checksum error
[07:40:45] -!- charims has quit [Read error: Connection reset by peer]
[08:38:10] -!- deep42thought has joined #archlinux32
[08:38:11] <buildmaster> Hi deep42thought!
[08:38:11] <buildmaster> !rq deep42thought
[08:38:12] <phrik> buildmaster: <deep42thought> good night, python - cu tomorrow python2!
[08:38:24] <deep42thought> Good morning!
[09:03:40] <abaumann> hi deep42thought
[09:03:59] <deep42thought> there is some `rm -r` in gcc8's package() function failing
[09:04:02] * abaumann my chat window was burried under a pile of other windows.. hence the late good morning..
[09:04:12] <deep42thought> I'll disable it in the hope, that the build is not actually broken
[09:04:25] <abaumann> what is it trying to delete?
[09:04:35] <abaumann> I hoped to fix it with porting the gcc stuff to gcc8
[09:04:35] <deep42thought> np - when you're busy, I have the hope, tons of packages get fixed ;-)
[09:05:13] <deep42thought> https://git.archlinux.org
[09:05:14] <phrik> Title: PKGBUILD\trunk - svntogit/community.git - Git clone of the 'community' repository (at git.archlinux.org)
[09:05:22] <abaumann> rm: cannot remove '/build/gcc8/pkg/gcc8/usr/lib/gcc/i686-pc-linux-gnu/8.3.0/../lib': No such file or directory
[09:05:26] <abaumann> yeah. same old same
[09:05:38] <deep42thought> I changed it to `rm -rf`
[09:06:13] <deep42thought> or does this mean, the gcc8 build itself is broken?
[09:06:17] <abaumann> isn't that the rm in gcc8 to remove the libs, which are in gcc8-libs
[09:06:23] <abaumann> could be
[09:06:34] <abaumann> so, the support libraries are not built somehow
[09:06:59] <abaumann> hard to believe, gcc8 was gcc some time ago, why should it suddenly fail building? because gcc 8 cannot be built with gcc 9?
[09:07:11] <deep42thought> lol
[09:08:23] <abaumann> make[2]: *** [Makefile:176: check] Error 127
[09:08:23] <abaumann> make[2]: Leaving directory '/build/gcc8/src/gcc-build/fixincludes'
[09:08:23] <abaumann> make[1]: *** [Makefile:3747: check-fixincludes] Error 2
[09:08:33] <abaumann> tests
[09:09:01] <abaumann> there are so many tests failing in there, I doubt the compiler actually works.
[09:09:05] <abaumann> what is gcc8 used for anyway>
[09:09:06] <abaumann> ?
[09:09:20] <abaumann> for software which doesn't build with gcc9?
[09:09:25] <abaumann> could be nvidia drivers..
[09:09:46] <deep42thought> the list is short: cuda gcc8-fortran root (make)
[09:10:11] <abaumann> if your software depends on the gcc version, you should really stop developping software because your development process is seriously flawed.
[09:10:20] <deep42thought> !grab abaumann
[09:10:20] <phrik> deep42thought: Bingpot!
[09:10:23] <abaumann> cuda. aha. thought so
[09:10:35] <abaumann> didn't we blacklist cuda anyways for 32-bit
[09:10:48] <abaumann> gcc8-fortran is a sub-package of gcc8
[09:10:55] <deep42thought> yup, we did
[09:11:04] <abaumann> so, onto the blacklist with gcc8
[09:12:00] <deep42thought> I almost blacklisted gcc :-D
[09:12:15] <deep42thought> this would have interesting results
[09:12:18] <abaumann> that would have been interesting :-)
[09:12:57] <deep42thought> not much to loose, probably: the buildmaster would simply say "refusing to blacklist 2114215231 packages)
[09:13:09] <abaumann> most likely
[09:14:32] <abaumann> https://bbs.archlinux32.org
[09:14:33] <phrik> Title: [LibreOffice] error while loading shared libraries: libicuuc.so / Creating/Maintaining Packages / Arch Linux 32 Forums (at bbs.archlinux32.org)
[09:14:43] <deep42thought> checking the installed JDK... configure: error: JDK is too old, you need at least 1.6
[09:14:44] <abaumann> ah, I see: that's why you asked about the status of Java/Ant
[09:14:56] <deep42thought> yeah
[09:15:18] <deep42thought> and: checking if /usr/share/ant/bin/ant works... configure: error: Ant does not work - Some Java projects will not build!
[09:15:22] <abaumann> it is silly that you need Java to build the core of libreoffice, as I understand it, only small parts actually require java.
[09:15:30] <deep42thought> yeah
[09:15:48] <abaumann> Java, Rust: the usual big blockers..
[09:16:03] <abaumann> let me see what I can do..
[09:16:07] <deep42thought> and the kde-thing I just don't understand :-(
[09:16:11] <abaumann> ..but the weather is nice.. so.. :-)
[09:16:14] <deep42thought> :-D
[09:16:56] -!- finsternis has quit [Excess Flood]
[09:17:05] <deep42thought> ... and there was light
[09:17:11] <abaumann> lol
[09:17:27] -!- finsternis has joined #archlinux32
[09:17:50] <abaumann> [ 94%] Linking CXX shared library ../../bin/libKF5CoreAddons.so
[09:17:50] <abaumann> /usr/bin/ld: warning: /usr/lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
[09:17:53] <abaumann> collect2: error: ld returned 1 exit status
[09:17:58] <abaumann> why should the warning be fatal.
[09:18:09] <deep42thought> -Werror?
[09:18:09] <abaumann> If we are lucky, some binutils/ld stuff is seriously broken
[09:18:15] <abaumann> not for the linker usually
[09:18:19] <deep42thought> ah, right :-)
[09:18:21] <abaumann> this is a gcc thing.
[09:18:32] <abaumann> but, you _can_ link with gcc, then gcc invokes ld
[09:18:37] <abaumann> might be the case here
[09:18:43] <abaumann> I have to build it and debug it
[09:21:17] * abaumann abusing the new buildmaster for some high parallel test builds..
[09:21:23] <deep42thought> :-D
[09:21:31] <abaumann> called hardware stress test :-)
[09:21:47] -!- quequotion has joined #archlinux32
[09:26:32] <abaumann> mmh. still the segfaults for pentium4 in java/ant
[09:26:52] <abaumann> let me try to set some kernel params on the buildmaster
[09:26:57] <abaumann> (the new one)
[09:27:04] <deep42thought> I think java has not rebuilt in quite some time ...
[09:27:07] <deep42thought> (it's scheduled)
[09:27:20] <abaumann> yeah, but it fails in other beatiful ways.
[09:27:30] <abaumann> I would be happy to get the current package running
[09:27:38] <deep42thought> ok
[09:27:39] <abaumann> because that's a kernel stack glibc thingy
[09:27:54] <abaumann> stack_guard_gap=1
[09:33:19] -!- charims has joined #archlinux32
[09:34:19] <abaumann> nope.
[09:34:32] <abaumann> I always hated Java for it's stupid tricks..
[09:36:58] <abaumann> ..could be, it runs only on real hardware and has problems in a pentium4 chroot on a 64-bit host?
[09:45:01] -!- quequotion has quit [Quit: quequotion]
[09:59:49] <abaumann> no. javac 8 crashes on the P4 test machine too..
[10:00:07] <deep42thought> at least something we can rely on
[10:00:10] <abaumann> ..I'm a little bit clueless.
[10:00:16] <deep42thought> you tested the binary or the build?
[10:00:23] <abaumann> the binary.
[10:00:32] <abaumann> rebuilding the jdk fails in bootstrapping errors in configure
[10:00:37] <abaumann> so, this is no option.
[10:00:48] <abaumann> you need a working javac in order to rebuild the JDK
[10:00:53] <deep42thought> ah, right
[10:02:58] <abaumann> maybe I have to bootstrap the pentium4 jdk with the i686 binary package
[10:03:07] <abaumann> because the i686 jdk works
[10:03:14] <abaumann> in all jdk versions
[10:03:20] <deep42thought> might be an option
[10:03:34] <deep42thought> "direct GOT relo
[10:03:34] <deep42thought> cation R_386_GOT32X against `_ZN6Thread8allocateEjb10MemoryType' without base re
[10:03:34] <deep42thought> gister can not be used when making a shared object"
[10:03:47] <deep42thought> this means, it pulled the lib for the wrong architecture?
[10:03:57] <abaumann> c++filt: Thread::allocate(unsigned int, bool, MemoryType)
[10:04:21] <abaumann> or an ABI mismatch
[10:04:44] -!- lodger has joined #archlinux32
[10:05:05] <abaumann> what package is that?
[10:05:15] <deep42thought> the build of java-openjdk
[10:21:18] <deep42thought> aha! https://bugs.archlinux.org
[10:21:19] <phrik> Title: FS#63015 : [lib32-glibc] ld warning: /usr/lib32/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0 (at bugs.archlinux.org)
[10:21:40] <deep42thought> so should we enable "cet" in glibc?
[10:22:58] <deep42thought> hmm, it *should* be enabled, already
[10:35:53] <abaumann> yes.
[10:35:56] <abaumann> it is enabled
[10:36:39] <abaumann> just for i486 you have to disable it, otherwise your systems starts with a SIGILL
[10:37:26] -!- lodger has quit [Remote host closed the connection]
[10:39:33] <abaumann> it happened when we split pentium4 from i686, so most likely is has to do with SSE2/SSE2 and stack alignment
[10:40:00] <abaumann> the relink with GOTs seems to be a new bug in JDK12 only, doing some link tricks, which fail for i686
[10:41:06] <deep42thought> what do you mean? the error I posted?
[10:41:13] <abaumann> yeah.
[10:41:18] <deep42thought> this one also happens in java11
[10:41:24] <abaumann> cool
[10:41:38] <deep42thought> and java 10
[10:41:42] <abaumann> the other possibility is a fatal bug for i686 in binutils/ld
[10:42:18] <deep42thought> that's quite improbable, isn't it?
[10:42:42] <abaumann> well, it's possible, as i386 support in binutils is slowly fading..
[10:42:54] <deep42thought> hmm, ok
[10:43:06] <abaumann> remember we had bugs in there before..
[10:43:31] <abaumann> ..those are very hard to track and to fix. Usually only the architecture maintainer of binutils can help there.
[10:43:42] <abaumann> but before bothering them.. we must be sure.
[10:44:17] * abaumann tries to update his eeepc with full disk space - he didn't do it for two weeks
[10:44:30] <deep42thought> it would be good to have a minimal working example
[11:11:39] -!- abaumann has quit [Quit: leaving]
[11:21:44] -!- AndrevS has joined #archlinux32
[12:11:53] -!- abaumann has joined #archlinux32
[12:11:59] <abaumann> yeah, -Wl,--fatal-warnings
[12:11:59] <buildmaster> Hi abaumann!
[12:11:59] <buildmaster> !rq abaumann
[12:12:00] <phrik> buildmaster: <abaumann> again. I'm in favour of a database which is not dropping its pants..
[12:13:26] <abaumann> so, the harmless GNU_PROPERTY(5), size:0 causes KDE packages on i686 to fail.. I'll fix that.
[12:14:03] <abaumann> https://github.com
[12:14:04] <phrik> Title: extra-cmake-modules/extra-cmake-modules-1.0.0-no-ld-fatal-warnings.patch at master · OpenMandrivaAssociation/extra-cmake-modules · GitHub (at github.com)
[12:34:39] <buildmaster> i686/geany-plugins are broken (says eurobuild6-3).
[12:41:03] <deep42thought> probably a bit tedious to fix all packages that have these switched, isn't it?
[12:43:05] <buildmaster> pentium4/geany-plugins are broken (says eurobuild6-2).
[13:14:55] <abaumann> ah. no, the kde-linker flags are in a common cmake module in extra-cmake-modules
[13:15:09] <deep42thought> better :-)
[13:15:11] <abaumann> this should then spread to all affected KDE packages
[13:15:18] <deep42thought> yeah
[13:15:27] <abaumann> still.. a workaround.. but I don't know what this linker error could be or cause..
[13:15:28] <deep42thought> I wonder though, why the linker is "broken" in the first place
[13:15:46] <deep42thought> the bug on archlinux I linked (to which you are described anyways) mentions cep
[13:16:03] <deep42thought> *cet
[13:16:03] <abaumann> CET.
[13:16:20] <abaumann> yeah. could be the compiler generates some ELF segment or code, which then troubles the linker.
[13:16:21] <deep42thought> yes, cep is "carrier envelope phase" - a property of very short laser pulses
[13:16:29] <abaumann> basically.. untested setup..
[13:16:43] <abaumann> those could also help ;-)
[13:18:03] <deep42thought> what I find strange is, that the guy in this bugreport repaird his glibc by enabling cet
[13:27:50] <buildmaster> pentium4/kate is broken (says eurobuild6-5).
[13:29:32] <deep42thought> maybe we should recompile binutils against the cet-enabled glibc?
[13:29:43] <buildmaster> pentium4/kompare is broken (says nlopc46).
[13:29:58] <abaumann> I enabled CET some year ago.. so I don't understand quite
[13:30:24] <deep42thought> hmm, ok
[13:30:33] <abaumann> but, we should check, if it is still in.
[13:30:38] <abaumann> I disabled CET for i486
[13:30:41] <deep42thought> it is
[13:30:43] <abaumann> CET was enabled upstream.
[13:31:02] <deep42thought> the question is if it always was (or at least: if it was when we build binutils)
[13:31:07] <abaumann> my patch-foo is a little bit broken today.. kcoreaddons still fails..
[13:31:44] <abaumann> we should see that binaries on i686/pentium4 contain CET specific fencing opcodes
[13:32:11] <abaumann> and we built the toolchain many times in the meantime
[13:32:23] <deep42thought> why do you patch extra-cmake-modules on i686 but not pentium4?
[13:32:39] <abaumann> because there the linker error doesn't happen
[13:32:46] <deep42thought> ah, ok
[13:32:56] <abaumann> as far as I can tell..
[13:35:52] <abaumann> oh. carch of extra-cmake-modules is any
[13:35:54] <abaumann> cool :-)
[13:36:05] <deep42thought> no it's notttt....wait
[13:36:08] <deep42thought> umm
[13:36:18] <deep42thought> CARCH is whatever the host builds on
[13:36:26] <deep42thought> hmmm
[13:36:31] <abaumann> well. ah. so it could also be pentium4
[13:36:37] <deep42thought> or even i486
[13:36:44] <abaumann> I spot a problem with that logic here :-)
[13:37:10] <abaumann> the CARCH sections might be applied random..
[13:37:15] <deep42thought> yeah
[13:37:21] <abaumann> *randomly
[13:37:22] <deep42thought> just apply it always :-D
[13:37:33] <abaumann> yeah.
[13:37:49] <abaumann> but. what if a crucial patch gets wrongly applied?
[13:38:03] <buildmaster> pentium4/telepathy-kde-common-internals are broken (says eurobuild6-1).
[13:38:15] <deep42thought> what do you mean "wrongly"?
[13:38:28] <abaumann> glibc with a i686 specific patch runs on a pentium4 host
[13:38:45] <abaumann> CARCH should be the architecture we are bulding _for_
[13:38:47] <deep42thought> CARCH depends on the build command, not on the host
[13:38:51] <abaumann> uff.
[13:38:54] <deep42thought> e.g. if you build with i686-staging-build
[13:38:58] <deep42thought> then it's i686
[13:38:58] <abaumann> then I misunderstood you.
[13:39:10] <deep42thought> maybe I misphrased that ;-)
[13:39:26] <deep42thought> but there is no staging-any-build
[13:39:39] <deep42thought> this would be funny, though :-D
[13:39:45] <abaumann> so patches for any packages should not rely on CARCH
[13:39:50] <deep42thought> yes
[13:39:55] <abaumann> 'any' not any. :-)
[13:40:01] <deep42thought> !grab abaumann
[13:40:01] <phrik> deep42thought: Tada!
[13:40:37] <deep42thought> it is also not clear from an abstract point of view, what a CARCH-dependent patch for an 'any' package should mean
[13:40:56] <abaumann> very true that
[13:46:10] <abaumann> aha:
[13:46:12] <abaumann> /usr/bin/ld: warning: /usr/lib32/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
[13:46:22] <deep42thought> lib32?
[13:46:24] <abaumann> it's also on lib32 upstream
[13:46:28] <deep42thought> yes
[13:46:34] <abaumann> so, this is an intrinsic problem with the linker on 32bit
[13:46:36] <deep42thought> !bug 63015
[13:46:37] <phrik> https://bugs.archlinux.org
[13:46:57] <abaumann> aha
[13:47:01] <abaumann> "
[13:47:02] <abaumann> Rebuilding 32bit glibc with "--enable-cet" fixes this for me."
[13:47:06] <deep42thought> (you are subscribed to that)
[13:47:37] <abaumann> yes, I even wrote a comment. :-)
[13:47:39] <abaumann> forgot.
[13:47:41] <abaumann> ok.
[13:47:50] <abaumann> I'll check the CET properties of our toolchain.
[13:52:53] <abaumann> as far as I can see all CET patching in glibc/gcc/binutils is for i486, to disable CET
[13:53:01] <deep42thought> yes
[13:53:03] <abaumann> for i686/pentium4 there is a --with-cet=auto
[13:53:09] <abaumann> which might be not that 'auto'..
[13:53:20] <deep42thought> where?
[13:53:35] <deep42thought> I only saw --enable-cet
[13:53:56] <abaumann> in gcc
[13:54:03] <abaumann> s/--enable-cet=auto/--disable-cet/
[13:54:39] <deep42thought> ah, indeed
[13:55:11] <abaumann> so, I would understand if things break in the linker on i486, but I don't understand why it breaks in i686 and in pentium4 all is ok again.
[13:55:40] <deep42thought> maybe, i686 selects "no" for "auto", while pentium4 selects "yes" for "auto"?
[13:56:22] <abaumann> that's an idea. so we can forcefully enable it for i686 and pentium4 and forcefully disable it for i486
[13:56:31] <deep42thought> yes
[13:56:43] <deep42thought> is there a way to check if cet actually entered the package?
[13:56:59] <abaumann> yeah. you can check for endbr opcodes with objdump
[13:57:01] <deep42thought> e.g. look at the compiled gcc and tell whether cet was enabled or not?
[13:57:15] <abaumann> ah. maybe in compiler flags somewhere, but.
[13:57:30] <abaumann> it's easier to compile a test program and see if CET endbr code is in there.
[13:57:47] <deep42thought> ok
[13:58:14] <abaumann> but I have to dig through some READMEs of mine to find more information.. :-)
[14:03:39] <deep42thought> the doxygen patch for i486 gcc is also obsolete now, right?
[14:06:25] <abaumann> yeah, think so.
[14:06:35] <abaumann> yes.. we do have a doxgen now on i486
[14:06:52] <deep42thought> let's see if the new gcc works better
[14:07:49] <buildmaster> pentium4/kile is broken (says eurobuild6-3).
[14:08:32] <buildmaster> pentium4/kbibtex is broken (says buildknecht).
[14:08:36] <buildmaster> pentium4/rocs are broken (says buildknecht2).
[14:36:23] <abaumann> let's hope :-)
[14:36:51] <abaumann> kcoreaddons builds now
[14:37:04] <deep42thought> \o/
[14:37:08] <deep42thought> is gcc done already?
[14:37:11] <abaumann> nope
[14:37:17] <deep42thought> errr
[14:37:21] <deep42thought> strange
[14:37:23] <abaumann> why>
[14:37:39] <deep42thought> ah, right, you silenced the warning
[14:37:58] <abaumann> exactly: short-term hack from my side, possibly long-term solution from you part ;-)
[14:44:33] -!- slacka123 has joined #archlinux32
[15:18:47] <elibrokeit> deep42thought, abaumann: "it is also not clear from an abstract point of view, what a CARCH-dependent patch for an 'any' package should mean" -- it means the package does not run the same on any architecture, and therefore cannot be an 'any' package...
[15:18:59] <elibrokeit> 'any' does not mean 'contains no ELF code'
[15:19:14] <deep42thought> yes, I know
[15:19:23] <deep42thought> so it is _not_ an 'any' package anymore :-)
[15:19:36] <elibrokeit> also why is kde so disgusting
[15:19:44] <elibrokeit> enabling -Werror is not cool
[15:21:59] * abaumann sighs where has the maintainer mode gone?
[15:22:42] <abaumann> ok, technically it was a -Wl,--fatal-warnings
[15:22:52] <abaumann> same effect :-)
[15:23:04] <elibrokeit> quite the same, yes
[15:32:13] <abaumann> https://bugs.openjdk.java.net
[15:32:39] <abaumann> interesting. so stacks may be unaligned for SSE ops? but why only on pentium4, some SSE is also added in i686
[15:36:56] <deep42thought> this bug is open since march O.o
[15:37:23] <abaumann> March last year :-)
[15:37:28] <deep42thought> WHAT
[15:37:34] <deep42thought> indeed
[15:37:51] <abaumann> this is conforting ;-)
[15:38:02] <deep42thought> "Note - Gentoo Linux is not the supported configuration (32-bit x86 Gentoo Linux, vanilla kernel 4.15.10)"
[15:38:04] <deep42thought> hahaha
[15:38:31] <deep42thought> you don't run on i7 amd64 win10? well, then your platform is not supported, sry
[15:39:04] <deep42thought> I have to go, have a nice weekend, cu!
[15:39:13] <abaumann> ok. have a nice weekend too. :-)
[15:39:19] -!- deep42thought has quit [Quit: Leaving.]
[16:18:27] -!- abaumann has quit [Quit: leaving]
[18:06:10] -!- andrimne has joined #archlinux32
[18:07:17] <andrimne> I get this, then systemd dumps core. Jul 05 20:00:07 archkoala sddm-greeter[441]: Cannot mix incompatible Qt library (version 0x50c03) with this library (version 0x50c04)
[18:07:55] <andrimne> Seemingly this problem. https://bugs.archlinux.org
[18:07:56] <phrik> Title: FS#62494 : [qt5ct] 0.38-1 Cannot mix incompatible Qt library (at bugs.archlinux.org)
[18:08:37] <andrimne> I recompiled the breeze theme from aur, but it didn't help.
[18:08:56] <andrimne> Anyone knows what todo?
[18:09:38] <elibrokeit> andrimne: which program is erroring?
[18:13:46] <bill-auger> sddm-greeter apparently - which is not an official package
[18:15:19] <andrimne> Not official? It shouldnät be called by sddm?
[18:15:52] <bill-auger> oh yes maybe so
[18:15:56] <bill-auger> i had the same problem last month when using 'qt5-styleplugins' https://bugs.archlinux32.org
[18:15:58] <phrik> Title: FS#65 : [qt5-styleplugins] incompatile QT version (at bugs.archlinux32.org)
[18:17:15] <bill-auger> QT is very picky about all programs using the same QT version - it seems that if any program on the system includes any QT binding, it causes other unrelated programs to fail with that "incompatible mixture" message
[18:17:44] <bill-auger> in my case it was preventing _any_ QT program from starting
[18:25:13] <bill-auger> that is, the program causing the problem may not be the program that fails to run - if you have 'qt5-styleplugins' installed, that seemed to be the culprit in my situation
[18:25:45] <bill-auger> removing it allowed QT programs to start, but they will be ugly
[18:25:47] <andrimne> does it help to install qt5-styleplugins in the git version in aur?
[18:26:16] <bill-auger> i dont know - i havent solved it yet
[18:26:36] <andrimne> No workaround?
[18:27:06] <bill-auger> try rebuilding 'qt5-styleplugins' with makepkg
[18:28:08] <bill-auger> last month the QT libs were in transition and that was rather tricky to do, but i expect QT has stabalized since then
[18:29:07] <bill-auger> if 'qt5-styleplugins' is also the cause of your problem, do bump that bug report
[18:33:05] <andrimne> bill-auger: I don't have styleplugins installed, so must be something else. I uninstalled all qt5 I had from aur. Didn't help.And I updated the breeze theme.
[18:33:36] <andrimne> rebuilt the gnome breeze theme from aur
[18:34:33] <andrimne> bill-auger: How did you find out which library was causing the problem?
[18:35:15] <bill-auger> because i had only 2 QT programs installed, calamares and qt5ct
[18:35:54] <bill-auger> andrimne: there is an open bug report that looks exactly like your problem https://bugs.archlinux32.org
[18:35:55] <phrik> Title: FS#62 : sddm-greeter aborts (at bugs.archlinux32.org)
[18:37:31] <andrimne> OK. I run plasma, so it's all qt
[18:37:56] <andrimne> bill-auger: I canät see that these problems are related
[18:39:12] <bill-auger> me either; but it is about sddm-greeter failing to start
[18:39:32] <bill-auger> thats somewhere to begin - one should always search the bug tracker for problems and open new bug reports if there is not a similar one already
[18:40:10] <andrimne> http://pasted.co
[18:40:11] <phrik> Title: Jul 05 18:24:16 archkoala sddm[627]: Greeter session started successfully Jul... - 70bb3dd8 (at pasted.co)
[18:40:37] <bill-auger> using the bug tracker is much more likely to get the problem solved than if you only ask for help on IRC
[18:51:24] <elibrokeit> bill-auger: qt5-styleplugins should work fine now that it is in the official repos again...
[18:51:49] <elibrokeit> unless arch32 is mismatching things due to failing buildorder
[18:52:26] <elibrokeit> the trick is that with Qt, a styleplugin can actually cause other Qt programs to fail because it is dynamically loaded into the process.
[18:53:14] <elibrokeit> but this is not because "any binding on the system" -- it is because a styleplugin is specifically meant to modify other programs, rather than being a plugin in its own right.
[18:53:28] <elibrokeit> *program in its own right
[18:58:11] <bill-auger> yea that sounds more reasonable to me - i will try it agai in the next few days
[19:13:28] -!- samantaz has joined #archlinux32
[19:16:12] <andrimne> It seems the qt5 group contains a qt5-base which is of a later revision, 5.12.4 instead of 5.12.3. I downgraded it and its working again. pyside2 is also of a this later revision, but I don't use it. I guess the group should be fixed.
[19:29:17] <bill-auger> andrimne: it would be awesome of you would open a bug report describing that
[19:30:39] <tirsek> @deep42thought, @abaumann (in case you check logs later): I don't know if this is of any use to you, but the corrupt GNU_PROPERTY_TYPE problem showed up here after a glibc upgrade from 2.28 to 2.29. `/usr/lib/ld-2.28.so` does not contain the .note.gnu.property ELF section that seems to trip up binutils, but ld-2.29.so does:
[19:30:41] <tirsek> [pti@wolfie lib]$ objcopy -j .note.gnu.property -O binary ld-2.28.so /dev/stdout | hexdump -C
[19:30:44] <tirsek> [pti@wolfie lib]$ objcopy -j .note.gnu.property -O binary ld-2.29.so /dev/stdout | hexdump -C
[19:30:47] <tirsek> objcopy: warning: ld-2.29.so: corrupt GNU_PROPERTY_TYPE (5) size: 0
[19:30:49] <tirsek> 00000000 04 00 00 00 00 00 00 00 05 00 00 00 47 4e 55 00 |............GNU.|
[19:30:51] <tirsek> 00000010
[19:33:50] <tirsek> As far as I can tell, that is indeed a properly formatted .note. section, but binutils doesn't like the fact that the properties section has a zero-length descriptor.
[19:43:19] <tirsek> The code to read this in libbfd in binutils appears to have been this way for a long time, so the problem must be in glibc. Somehow that section is now present, when it wasn't before. I'm not sure how this relates to the Intel CET stuff though, but https://github.com does seem to mention that CET-enabled code should include some appropriate properties in their ELF
[19:43:20] <phrik> Title: X86 psABI · hjl-tools/x86-psABI Wiki · GitHub (at github.com)
[19:43:21] <tirsek> binaries. Might be relevant? Either way, glibc should probably not include a property section that binutils can't read. Perhaps it's malformed when CET is enabled, and omitted (as maybe it should be) when CET is disabled? So far, I'm kinda just guessing here, haven't had time to look into it a whole lot more yet...
[19:54:23] -!- ofara has quit [Ping timeout: 258 seconds]
[19:56:34] -!- ofara has joined #archlinux32
[20:07:17] -!- skydrome has joined #archlinux32
[20:14:25] <andrimne> This problem hung the boot until I provided some entropy by clicking som keys. https://bugs.archlinux.org I use the linux-lts kernel. version 4.19.34-1.0. Not sure if the latest version works. The solution was to install and enable haveged. settings random.trust_cpu=on did not help.
[20:37:04] -!- slacka123 has quit [Remote host closed the connection]
[20:47:35] <andrimne> bill-auger: I created an ID, andrimne. Am I allowed to create bug reports? In case I am, how?
[20:57:09] <bill-auger> oh im not sure - i think you may need to ask for permission still
[20:57:31] <girls> andrimne: I promoted you
[20:57:37] <girls> you should be able to report bugs now
[20:57:42] <bill-auger> TADA!
[21:15:59] <buildmaster> i686/kactivities-stats are broken (says eurobuild6-5).
[21:31:17] <girls> andrimne: a quick check reveals, that _several_ qt5-* packages are of 5.12.4 in stable ...
[21:35:29] <girls> it appears, my logic which is supposed to extract that version, does not work as intended ...
[21:36:44] <andrimne> bill-auger: girls: I reported the bug. Opinions are welcome. It is my first bug report here. https://bugs.archlinux32.org
[21:36:45] <phrik> Title: FS#78 : The qt5 group contains packages of different versions. (at bugs.archlinux32.org)
[21:38:36] <bill-auger> awesome andrimne - and it already got the attention of the devs
[21:38:58] <girls> unfortunately only the attention of the less-talented dev ;-)
[21:40:22] <andrimne> I think no talent is needed in this case.
[21:40:25] <bill-auger> i do think that is the same reason for the problem i had last month with 'qt5-styleplugins' https://bugs.archlinux32.org
[21:40:30] <phrik> Title: FS#65 : [qt5-styleplugins] incompatile QT version (at bugs.archlinux32.org)
[21:40:40] <bill-auger> i have not tried it again since, but i will soon
[21:40:56] <girls> yes, as I said: the logic which should add dependencies to the database to prevent this is most probably broken
[21:41:57] <andrimne> OK. Maybe talent is needed than.
[21:44:01] <girls> hmm, the elf metadata only distinguishes the second digit of the qt version :-/
[21:44:08] <girls> required from libQt5Core.so.5:
[21:44:08] <girls> 0x08a28112 0x00 15 Qt_5.12
[21:50:34] <girls> probably, we should really just pin the $pkgver of all qt5-* dependencies
[21:50:43] <girls> ... at least in our mysql database
[21:55:45] -!- samantaz has quit [Ping timeout: 248 seconds]
[21:57:49] -!- samantaz has joined #archlinux32
[22:12:27] -!- djmoch has quit [Quit: ZNC 1.7.3 - https://znc.in]
[22:12:50] -!- djmoch has joined #archlinux32
[22:18:30] <buildmaster> pentium4/geany-plugins are broken (says eurobuild6-1).
[22:19:32] <girls> ah, I know, why we didn't extract $pkgver before: there are qt5-* packages with quite strange pkgvers, e.g. qt5-styleplugins-5.0.0.20170311-15.0-pentium4
[22:20:03] <girls> hmmmm
[22:29:02] <girls> ok, hopefully, I fixed the logic now (without breaking the build slaves) - now on to part 2: repairing the qt5-* mess :-D
[22:33:34] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.query.2019-07-05T20:31:14.WWR7YX.stdin"?.
[22:37:30] <girls> typo :-(
[22:47:09] * buildmaster resumes sanity.
[22:48:14] <buildmaster> pentium4/kbibtex is broken (says rechenknecht).
[22:54:52] <buildmaster> pentium4/kompare is broken (says eurobuild6-5).
[22:58:11] -!- thePiGrepper has joined #archlinux32
[23:01:04] <buildmaster> pentium4/kde-cli-tools are broken (says nlopc46).
[23:04:12] <buildmaster> pentium4/haskell-sbv is broken (says eurobuild6-3).
[23:08:15] <buildmaster> pentium4/telepathy-kde-common-internals are broken (says buildknecht).
[23:10:53] <buildmaster> i686/haskell-sbv is broken (says rechenknecht).
[23:11:20] -!- andrimne has parted #archlinux32
[23:21:04] -!- isacdaavid has quit [Quit: Leaving.]