#archlinux32 | Logs for 2019-03-10

Back
[00:01:45] -!- AndrevS has quit [Remote host closed the connection]
[00:35:37] -!- thePiGrepper has joined #archlinux32
[01:29:27] <elibrokeit> abaumann: hg/git/svn/bzr are needed for downloading sources as well, which is a bit of an odd case as makedepends go, but there is a reason why devtools depends on them unconditionally
[01:46:38] -!- yans has joined #archlinux32
[01:52:12] -!- yans has quit [Quit: chaos is the only true answer]
[02:09:06] -!- jason0597 has quit [Ping timeout: 250 seconds]
[02:11:08] -!- ofara_ has joined #archlinux32
[02:13:17] -!- yans has joined #archlinux32
[03:41:22] -!- T`aZ has quit [Ping timeout: 246 seconds]
[03:43:28] -!- T`aZ has joined #archlinux32
[04:25:52] -!- samantaz_ has quit [Remote host closed the connection]
[04:26:25] -!- samantaz_ has joined #archlinux32
[05:39:12] -!- thePiGrepper has quit [Ping timeout: 252 seconds]
[07:51:23] -!- abaumann has joined #archlinux32
[07:51:23] <buildmaster> Hi abaumann!
[07:51:24] <buildmaster> !rq abaumann
[07:51:24] <phrik> buildmaster: <abaumann> does it include a dependency to a mailer, so it can send emails about temperature and usage too? ;-)
[07:51:40] <abaumann> elibrokeit: yeah, I realised to late that I was missing 'mercurial' on the build host..
[07:51:56] <abaumann> much more than an optdepends for pacman/makepkg is not feasible.
[07:52:18] <abaumann> optdepends mercurial,git,svn,bzr, I mean
[07:54:05] <elibrokeit> or devtools ;)
[07:54:48] <elibrokeit> in theory makepkg should error at you early, with a message that it cannot find the binary needed for git:// sources...
[07:55:15] <abaumann> that would be nice :-)
[07:55:16] <elibrokeit> or hg in this case
[07:55:24] <abaumann> but not really very important also..
[07:55:35] <elibrokeit> I mean that makepkg explicitly has code that is supposed to do this
[07:55:47] <elibrokeit> so I don't know why you would get command not found errors from hg.sh
[07:56:11] <abaumann> ah. that's a good point.
[07:57:41] <abaumann> "/usr/share/makepkg/source/hg.sh: line 45: hg: command not found"
[07:57:46] <abaumann> so the error is in the right place.
[07:57:58] -!- z3ntu has quit [*.net *.split]
[08:01:13] <elibrokeit> uh
[08:01:13] <elibrokeit> my bad, the check I am thinking of will ensure that it is listed in makedepends=()
[08:01:13] <elibrokeit> so it will still work... except that --verifysource is a bit funny, it doen't try to install makedepends -- even for vcs sources
[08:01:13] -!- titus_livius has quit [Ping timeout: 255 seconds]
[08:02:26] -!- titus_livius has joined #archlinux32
[08:06:20] <KitsuWhooa> abaumann: I did some quick hello world tests https://tasossah.com
[08:06:21] <phrik> Title: rustc (at tasossah.com)
[08:06:32] <KitsuWhooa> in other words, we might need to open a bug :p
[08:06:35] <KitsuWhooa> well, issue
[08:06:48] * buildmaster resumes sanity.
[08:07:58] <buildmaster> i686/qgis are broken (says buildknecht).
[08:23:58] <abaumann> yeah. Also I have seen packages starting to use rustup, because rust is broken..
[08:24:02] <abaumann> ..also upstream.
[08:25:21] <abaumann> I start to double, that i686 without SSE2 is a good idea to provide. The effort might be too big: so far I saw things in qt5-declarative, librsvg, chromium which pretty much make it impossible to switch off SSE2
[08:26:08] <abaumann> I start to think to drop the idea of a pentium4, declare i686 as "needs SSE2" and instead put more effort into the 'i486' branch (the "use as little special instructions as possible branch").
[08:27:52] <abaumann> till then, we might have some fun to patch out SSE2 in several places. If rust is downloading the compiler from somewhere, I cannot guarantee it has no SSE2 in it. So the only proper way is not to use rustup, build our own rust and make sure, nothing funny creeps in there.
[08:28:14] <abaumann> now.. rust is one of the worst compiler suits I have seen in a long time.. in terms of documentation, bootstrapping, etc.
[08:28:42] <abaumann> and cargo is just an utterly bad idea..
[08:29:17] <abaumann> *abaumann lables the last two sentences as personal opinion - and is aware, he doesn't get a job in rust-loving company in the future. :-)
[08:29:17] -!- oaken-source has joined #archlinux32
[08:29:25] <abaumann> *labels
[08:34:22] <KitsuWhooa> abaumann: I'd prefer to have i686 without SSE2. In this case not even rustup can produce a build without SSE2
[08:34:38] <KitsuWhooa> i586 is the lowest the target can go from what I can tell
[08:34:58] <KitsuWhooa> and regarding chromium, I don't think machines without SSE2 have enough resources to run chromium in the first place
[08:35:35] <KitsuWhooa> That said I am willing to put work towards this
[08:35:57] <KitsuWhooa> otherwise my laptop is pretty much useless, and I'd rather keep some extensions, due to how slow it is in the first place
[08:36:48] <abaumann> it's funny. every time I switch off an optimization feature like LTO or SSE2, I hardly feel any difference in performance.
[08:36:54] <abaumann> For normal stuff, that is.
[08:37:11] <abaumann> I'm pretty sure, chromium is usable without SSE2 to do some basic browsing.
[08:37:34] <abaumann> I also have to download youtube videos and recode them first on a faster machine.. cannot play on my eeepc directly (I could once).
[08:37:34] <KitsuWhooa> I thought webkit2 required SSE2
[08:37:43] <KitsuWhooa> I can on mine
[08:37:58] <KitsuWhooa> youtube-dl -o - | ffplay - basically
[08:38:08] <abaumann> yeah. exactly. :-)
[08:38:35] <KitsuWhooa> this can be done on the same machine though, and it doesn't need re-encoding if you pick the low formats
[08:39:30] <KitsuWhooa> either way, next step is trying clang to see if it's an llvm bug or a rust one
[08:39:37] <abaumann> true. but if I want to keep something, then I like to keep the higher resolution.
[08:40:09] <abaumann> something tells me llvm is quite unlikely to be the problem..
[08:40:17] <KitsuWhooa> likewise, but you never know
[08:40:50] <KitsuWhooa> I wonder how painful it would be to bisect :p
[08:54:19] <abaumann> error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to '/root/.rustup/tmp/7st298z1qq8ep0rq_file'
[08:54:27] <abaumann> -Z verbose is only possible on the daily build.
[08:54:29] <abaumann> *sigh*
[08:55:40] <abaumann> rustc --print target-list | grep 586
[08:55:42] <abaumann> i586-unknown-linux-gnu
[08:55:48] <abaumann> error[E0463]: can't find crate for `std` | = note: the `i586-unknown-linux-gnu` target may not be installed
[08:56:00] <abaumann> ok. officially not supported to go below i686..
[08:58:42] <buildmaster> i686/hledger-api is broken (says buildknecht) - I rescheduled: haskell-microlens-platform.
[09:07:51] <abaumann> mmh. I wonder whether mrust is able to compile librsvg..
[09:09:29] <abaumann> mrustc I meant
[09:10:00] <abaumann> the problem is again with those pre-built crates, if they contain SSE2..
[09:20:45] -!- yans has quit [Ping timeout: 246 seconds]
[09:31:12] <KitsuWhooa> abaumann: can we not build those crates manually?
[09:31:24] <KitsuWhooa> Any idea why they're binary in the first place?
[09:31:50] <KitsuWhooa> And with my experiments all I did was print hello world, so I doubt that's the case right now
[09:31:54] <KitsuWhooa> Unless you mean std
[09:31:57] <abaumann> if you have your own packaging and a slow compiler you don't want to recompile everything all the time.
[09:32:51] <abaumann> another point: just because objdump shows you movsd opcodes, doesn't mean, they are also being executed, you can have runtime features..
[09:33:18] <abaumann> could be this is a string function, SSE2 optimized just being linked in to be there in the case CPU has SSE2
[09:33:50] <KitsuWhooa> True, but I definitely got sigill when I tried the first one
[09:34:01] <KitsuWhooa> I can try them individually
[09:34:03] <abaumann> you run 'hello'?
[09:34:19] <KitsuWhooa> I ran it only the first time and it crashed, yes
[09:34:25] <abaumann> ah. ok.
[09:34:38] <KitsuWhooa> I haven't tried the i586 ones though
[09:35:14] <abaumann> the i586 need the standard libraries (std) to be bootstrapped, I'm afraid/.
[09:35:26] <KitsuWhooa> Ah
[09:35:40] <KitsuWhooa> Wonder why it's a target then
[09:36:09] <abaumann> well, it is: the compiler is maybe available, just not the runtime..
[09:36:36] <KitsuWhooa> I wonder what happens if I try to run that
[09:37:09] <KitsuWhooa> it seems to run
[09:37:10] <abaumann> another note: when stracing rustc I saw calls to /home/user/.cargo/bin/cc (ahem) and /usr/bin/cc
[09:37:13] <KitsuWhooa> (on my deskto)_
[09:37:20] <abaumann> none of them setting any flags but -m32
[09:37:31] <KitsuWhooa> I assume that's for linking
[09:37:39] <KitsuWhooa> although why cc
[09:37:41] <abaumann> I don't know, if rustc is using cc to compile some things and other things are done the LLVM-way.
[09:37:41] <KitsuWhooa> hmmm
[09:38:06] <abaumann> IMHO it's quite a mess..
[09:39:01] <abaumann> mmh. running rustc on my pentium3 gives me a SIGILL already when trying to compile a test.rs
[09:39:14] <abaumann> so, you were cross-compiling, I suppose
[09:39:16] <KitsuWhooa> yeah, I mentioned that before
[09:39:17] <KitsuWhooa> yes
[09:39:19] <abaumann> ah.
[09:39:21] <abaumann> sorry.
[09:39:25] <KitsuWhooa> it's fine :)
[09:39:26] <abaumann> didn't pay atterntion then. :-)
[09:39:49] <KitsuWhooa> huh
[09:39:51] <KitsuWhooa> okay
[09:40:00] <KitsuWhooa> tatokis@nightopia:~$ ./hello
[09:40:02] <KitsuWhooa> Hello World!
[09:40:05] <abaumann> yeah. and the generated 'test' also SIGILLs.
[09:40:05] <KitsuWhooa> the i586 target produced a working binary
[09:40:21] <KitsuWhooa> (despite objdump having sse2 as you mentioned)
[09:40:31] <abaumann> doesn't for me.
[09:40:34] <abaumann> mmh.
[09:40:56] <KitsuWhooa> https://tasossah.com if you want to try it
[09:41:23] <abaumann> code injection - yeah ;-)
[09:41:39] <abaumann> yep. works for me too.
[09:41:56] <abaumann> rustc --target i586-unknown-linux-gnu was on 64-bit Arch or Arch32?
[09:42:02] <KitsuWhooa> x86_64 on my desktop
[09:42:35] <abaumann> aha.
[09:42:58] <KitsuWhooa> I get the feeling the target-feature and target-cpu args are being ignored
[09:43:07] <abaumann> so we have another problem. rust on Archlinux32 is already buggy, doesn't support i586 target and might add the SSE2 opcodes..
[09:43:42] <KitsuWhooa> wouldn't it be possible to cross compile rustc and use the prebuilt target?
[09:43:47] <KitsuWhooa> and then use that to generate packages
[09:44:17] <abaumann> yeah. not in the current build system, I think..
[09:44:34] <KitsuWhooa> hm
[09:44:43] <abaumann> besides: if we provide a rust package for Archlinux32, it should work..
[09:44:56] <KitsuWhooa> That's what I meant, we generate it externally once and then use it to compile itself
[09:45:14] <abaumann> config.toml.patch
[09:45:34] <abaumann> contains only a target.i686-unknown-linux-gnu, which most likely misconfigures automagically itself. *grmpf*
[09:46:31] <KitsuWhooa> for reference
[09:46:34] <KitsuWhooa> https://github.com
[09:46:36] <phrik> Title: rust/i686_unknown_linux_gnu.rs at c9f8304351ad4223e4f618e9a329b2b94776b25e · rust-lang/rust · GitHub (at github.com)
[09:46:37] <KitsuWhooa> https://github.com
[09:46:38] <phrik> Title: rust/i586_unknown_linux_gnu.rs at c9f8304351ad4223e4f618e9a329b2b94776b25e · rust-lang/rust · GitHub (at github.com)
[09:46:59] -!- samantaz_ has quit [Ping timeout: 255 seconds]
[09:47:34] <abaumann> Cannot see options there, which would enable SSE2..
[09:47:54] <abaumann> https://github.com
[09:47:55] <KitsuWhooa> me neither, so it could just be from std
[09:47:55] <phrik> Title: rust/i686_unknown_linux_gnu.rs at c9f8304351ad4223e4f618e9a329b2b94776b25e · rust-lang/rust · GitHub (at github.com)
[09:47:59] <abaumann> ohoh: base.cpu = "pentium4".to_string();
[09:48:03] <KitsuWhooa> well that one passes p4
[09:48:06] <KitsuWhooa> yeah
[09:48:19] <KitsuWhooa> from what I understand, theoretically target-cpu should override that
[09:48:28] <KitsuWhooa> and these files haven't been edited in a meaningful way for a while now, so the regression can't be in those
[09:48:45] <abaumann> what we can do is to add the i586 target to rust, see: https://git.archlinux32.org
[09:48:47] <phrik> Title: archlinux32/packages: Package customizations and pure-i686 packages - Archlinux32 Gitea (at git.archlinux32.org)
[09:48:55] <abaumann> and then use i586 as target in librsvg..
[09:49:20] <KitsuWhooa> The problem is it most likely disables a bunch of other things
[09:49:34] <abaumann> rust there has a config.toml.patch (introduced a month ago), which I don't fully understand..
[09:49:52] <KitsuWhooa> I know nothing about it, sooo :p
[09:50:11] <KitsuWhooa> Thinking about it, would it be possible to s/pentium4/pentium3/ in the i686 target?
[09:50:21] <abaumann> I'll just try with i586-unknown-linux-gnu and see what happens.
[09:50:25] <KitsuWhooa> Sure
[09:50:27] <abaumann> or that.
[09:50:28] <abaumann> yes.
[09:50:38] <abaumann> actually. better.
[09:50:39] <abaumann> :-)
[09:50:42] * KitsuWhooa nods
[09:50:55] <abaumann> then i686 in rust fits the definition of our package archs.
[09:51:41] <KitsuWhooa> either way, from some quick testing I was unable to get clang to produce SSE2
[09:51:54] <KitsuWhooa> so it's probably not an llvm issue
[09:52:06] <abaumann> ok. yeah. usually, clang, gcc do what you tell them to do.. :-)
[09:52:38] <KitsuWhooa> well, if it was a problem in llvm then it would also have the same issue
[09:52:42] <KitsuWhooa> assuming I am understanding this correctly
[09:53:36] <KitsuWhooa> Do you have an i486 machine you can test that hello binary on as well? I wonder what instruction it would fail on
[09:53:39] <abaumann> yes, given, you use a function in C which triggers some SSE2 optimized code.
[09:53:49] <abaumann> hum..
[09:53:49] <KitsuWhooa> ..that's a fair point
[09:53:58] <abaumann> I have a Pentium-S and a AMD-K6..
[09:54:08] <KitsuWhooa> My P1 and K8 are both at home sadly
[09:54:13] <buildmaster> i686/haskell-authenticate is broken (says nlopc46) - I rescheduled: haskell-tagstream-conduit.
[09:54:25] <KitsuWhooa> er
[09:54:25] <abaumann> *abaumann starts old machines..
[09:54:28] <KitsuWhooa> K6
[09:58:18] <abaumann> mmh. hello works on the K6.
[09:58:36] <KitsuWhooa> interesting
[09:58:46] <abaumann> well, K6 is a i686 without cmov
[09:58:52] <abaumann> so, it should work..
[09:58:56] <KitsuWhooa> I passed target-cpu=pentium2
[09:59:04] <KitsuWhooa> which I assume got ignored as well
[09:59:16] <abaumann> yeah. but a print function cannot use a lot of optimization, I suppose.
[09:59:39] <KitsuWhooa> True, but at the same time it did crash on i686
[09:59:42] <abaumann> the problem is: what is in the startup-code of the program and what library functions have special optimizations.
[09:59:52] <KitsuWhooa> *969 target
[09:59:56] <abaumann> for instance C has special versions of strcpy for each architecture..
[10:00:00] <KitsuWhooa> ...
[10:00:02] <KitsuWhooa> *i686 target
[10:00:08] <KitsuWhooa> I don't know but there's 1.5MB worth of code in that binary :p
[10:02:29] <abaumann> yeah. I'm positive that this is all our fault, not setting the correct flags in rust.. :-)
[10:02:57] <KitsuWhooa> I still think it's a regression :;
[10:03:00] <KitsuWhooa> * :p
[10:05:45] <abaumann> oh. my K6 reboots when I download the linux kernel..
[10:05:51] <KitsuWhooa> uh oh
[10:05:52] <abaumann> ..thermal issues, I suppose..
[10:06:19] <KitsuWhooa> I almost fried my AMD Duron because the fan wasn't spinning
[10:06:38] <KitsuWhooa> it was not a pleasant experience :p
[10:06:54] <abaumann> Duron or Athlon didn't have a thermal protection inside, don't remember which one or both. :-)
[10:07:00] <KitsuWhooa> I think both
[10:07:11] <abaumann> so you had some seconds before the thing fried itself..
[10:07:22] <abaumann> I changed the fan recently on that thing.. mmh..
[10:07:29] <KitsuWhooa> well, it reached the point where it wouldn't POST
[10:07:36] <KitsuWhooa> and then I looked inside and saw the fan not spinning and panicked :p
[10:07:37] <abaumann> LOL
[10:08:15] <KitsuWhooa> reminds me of that tomshardware (?) video
[10:08:59] <KitsuWhooa> https://youtu.be
[10:09:01] <phrik> Title: CPU Overheat - YouTube (at youtu.be)
[10:10:09] <abaumann> yep. found it.
[10:10:32] <abaumann> when he tests the duron, he doesn't go close there with the heat meter.. I wonder why.. ;-)
[10:10:40] <KitsuWhooa> hah
[10:11:00] <abaumann> so sad.. killing vintage cpus for science..
[10:11:15] <KitsuWhooa> they weren't that vintage when this was made though
[10:11:41] <abaumann> true
[10:27:15] <abaumann> src/rustc-1.32.0-src/vendor/rustc-ap-rustc_target/spec/i686_unknown_linux_gnu.rs or src/rustc-1.32.0-src/src/librustc_target/spec/i686_unknown_linux_gnu.rs, that is the question..
[10:28:49] <KitsuWhooa> both? :D
[10:28:55] <abaumann> yes! :-)
[10:29:22] <KitsuWhooa> I don't see a "vendor" directory in their git repo
[10:29:37] <abaumann> no, it's in the released tarball, it seems.
[10:29:43] <abaumann> that's what we build from in PKGBUILD
[10:29:51] <KitsuWhooa> Yeah, I just found it interesting
[10:30:06] <KitsuWhooa> are they the exact same file?
[10:30:16] <abaumann> seems so.
[11:44:21] -!- samantaz_ has joined #archlinux32
[11:56:45] -!- T`aZ has quit [Remote host closed the connection]
[12:16:18] -!- thePiGrepper has joined #archlinux32
[12:45:36] -!- z3ntu has joined #archlinux32
[13:22:29] -!- jason0597 has joined #archlinux32
[14:25:33] <abaumann> + makepkg --verifysource
[14:25:33] <abaumann> ==> ERROR: is not available for the 'x86_64' architecture.
[14:25:33] <abaumann> ==> ERROR: pkgname is not allowed to be empty.
[14:25:33] <abaumann> ==> ERROR: pkgver is not allowed to be empty.
[14:25:33] <abaumann> ==> ERROR: pkgrel is not allowed to be empty.
[14:25:54] <abaumann> I'm trying now since hours to understand, why the rust PKGBUILD is not formed properly in the build system.. I have no clue..
[14:28:33] <KitsuWhooa> :(
[14:28:46] <abaumann> I'm not a big fan of bash as a programming language, really not..
[14:29:24] <abaumann> even when my diff-PKGBUILD is empty, I get those silly errors, but just with rust's PKGBUILD..
[14:32:15] <abaumann> it almost looks like the diff-PKGBUILD together with a pkgver vairable OVERWRITES the original PKGBUILD..?!
[14:32:59] <abaumann> asp export rust works, asp32 export rust works too
[14:33:09] <abaumann> makepkg --printsrcinfo on those dirs also works..
[14:35:07] <abaumann> http://bashdb.sourceforge.net yeah. bash has a debugger.. :-)
[14:37:22] <abaumann> Source file "/dev/pts/1" is not readable
[14:37:23] <abaumann> mmh
[14:46:20] <abaumann> ${PKGBUILD} is a newline.. interesting
[14:51:17] <abaumann> ..let's assume git messed up my workspace and let's reclone all workspaces..
[15:15:38] <abaumann> community/rust/trunk only has a trunk, no community.. *grmpf*
[15:16:53] <abaumann> ah. so rust moved to extra, but community/rust/trunk is still around.. well. that's it.
[15:19:06] <abaumann> maybe putting a test after $PKGBUILD=(git ...) to check for a packaage name is an idea..
[18:11:35] -!- aliemjay has joined #archlinux32
[18:29:50] -!- abaumann has quit [Quit: leaving]
[18:30:35] -!- abaumann has joined #archlinux32
[18:30:35] <buildmaster> Hi abaumann!
[18:30:35] <buildmaster> !rq abaumann
[18:30:36] <phrik> buildmaster: <abaumann> all slaves busy.. wait.. one slave in the north/western part of.. resists.. :-)
[18:32:54] <abaumann> aliemjay: kde-cli-tools seems to have more issues than just a dependency cycle..
[18:32:57] <abaumann> Could not find a configuration file for package "LibKWorkspace" that is
[18:33:00] <abaumann> compatible with requested version "5.15.2".
[18:35:12] <abaumann> error: the listed checksum of `/build/rust/src/rustc-1.32.0-src/vendor/rustc-ap-rustc_target/spec/i686_unknown_linux_gnu.rs` has changed:
[18:35:15] <abaumann> expected: 254a116e0cfbce81d1d38ddd59e1086228332746ae8916647b990dd8226079d3
[18:35:17] <abaumann> actual: 30594a90c83b496630d0b8d80ce2f93671ab6afedadcdc79afd832f4dfe499fd
[18:35:17] <abaumann> rust: really really funny.
[18:36:38] <abaumann> and this after 4 hours of building *sigh8
[18:38:20] <abaumann> I really hope, I can set those checksums somewhere and that they don't come from a cloud server. :->
[18:39:44] <buildmaster> i686/rust is broken (says eurobuild3).
[18:39:51] <abaumann> yeah. you tell me :->
[18:40:47] <aliemjay> abaumann: idk, Erich has fixed this previously, so he may know better
[18:41:00] <aliemjay> abaumann: have you tried scheduling plasma-workspace first??
[18:43:44] <aliemjay> abaumann: kde-cli-tools expect plasma-workspace 5.15.x . so if worskpace was built first, it would provide the compatble cmake config
[18:51:14] -!- oaken-source has quit [Quit: leaving]
[18:52:46] -!- oaken-source has joined #archlinux32
[18:58:45] -!- MrBIOS has joined #archlinux32
[19:04:50] -!- thePiGrepper has quit [Ping timeout: 250 seconds]
[19:10:38] <abaumann> aliemjay: aha. thanks for the clarification. deep42thought has an internet issue, so he is not online at weekends at the moment.
[19:15:14] <abaumann> about scheduling. we don't really schedule manually. so, if there is not cycle, then things should work automagically.
[19:22:10] <abaumann> rustc-1.32.0-src/vendor/rustc-ap-rustc_target/.cargo-checksum.json: yee.
[19:30:19] <abaumann> plasma-desktop doesn't build because it depends on itself..
[19:32:56] <abaumann> LibKWorkspace 5.14.90 requested, but only 5.14.4 is in extra. So I wonder, how this has been done upstream..
[19:35:00] <aliemjay> Well, the only cycle I see is between plasma-workspace and kde-cli-tools, look: https://archlinux32.org
[19:35:28] <abaumann> When I build plasma-desktop, I get a cmake complaint about a library, which cannot have been built.
[19:35:38] <abaumann> It's not a dependency in PKGBUILD makedepends or depends.
[19:36:16] <aliemjay> the library is provided by plasma-workspace
[19:36:34] <aliemjay> it should be build first for version 5.15.x
[19:36:36] <abaumann> so, then plasma-workspace is an old version.. lemme see.
[19:36:47] <aliemjay> yes..
[19:38:00] <abaumann> plasma-workspace-wallpapers-5.15.2-1.0-any.pkg.tar.xz
[19:38:08] <abaumann> but only:
[19:38:14] <abaumann> plasma-workspace-5.14.4-1.0-i686.pkg.tar.xz
[19:38:16] <abaumann> this is weird
[19:39:23] <aliemjay> yes it is stuck in build-list bcs of dependency cycle
[19:40:40] <abaumann> I'll kick in manually. but we should defenitely have a look what's wrong with the dependency logic..
[19:42:37] <buildmaster> i686/rust is broken (says nlopc46).
[19:42:43] <abaumann> ah. lovely..
[19:43:00] <abaumann> buildmaster; !wtf rust
[19:43:03] <abaumann> buildmaster: !wtf rust
[19:43:05] <buildmaster> abaumann: ruby-rouge [community]: /usr/lib/ruby/gems/2.5.0/gems/rouge-3.3.0/lib/rouge/demos/rust
[19:43:05] <buildmaster> ruby-rouge [community-testing]: /usr/lib/ruby/gems/2.6.0/gems/rouge-3.3.0/lib/rouge/demos/rust
[19:43:05] <buildmaster> gitlab-gitaly [community]: /usr/share/webapps/gitlab-gitaly/ruby/vendor/bundle/ruby/2.5.0/gems/rouge-3.3.0/lib/rouge/demos/rust
[19:43:05] <buildmaster> gitlab [community]: /usr/share/webapps/gitlab/vendor/bundle/ruby/2.3.0/gems/rouge-3.1.1/lib/rouge/demos/rust
[19:43:05] <buildmaster> redmine [community-staging]: /usr/share/webapps/redmine/vendor/bundle/ruby/2.6.0/gems/rouge-3.3.0/lib/rouge/demos/rust
[19:43:25] <abaumann> mmh. unexpected. :-)
[19:47:56] <buildmaster> i686/kde-cli-tools are broken (says nlopc46).
[19:48:23] <abaumann> ok. forced sequential builds seem to be ignored. I'm still building plasma-workspace..
[20:41:19] -!- abaumann has quit [Quit: leaving]
[21:27:27] -!- MrBIOS has quit [Quit: MrBIOS]
[21:50:06] -!- MrBIOS has joined #archlinux32
[22:10:10] -!- MrBIOS has quit [Quit: MrBIOS]
[23:14:30] -!- Dimtree has quit [Quit: Peace]
[23:14:57] -!- thePiGrepper has joined #archlinux32
[23:22:56] -!- Dimtree has joined #archlinux32
[23:52:15] -!- oaken-source has quit [Ping timeout: 246 seconds]