#archlinux-ports | Logs for 2018-01-26

Back
[00:04:00] <buildmaster> haskell-graphviz is broken (says buildknecht).
[00:06:23] <buildmaster> haskell-tamarin-prover-utils is broken (says buildknecht).
[00:08:02] <guys> omg everything is broken
[00:08:38] <guys> /usr/lib/gcc/i686-pc-linux-gnu/7.2.1/cc1: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory
[00:08:45] <guys> I see
[00:08:46] <buildmaster> haskell-glob is broken (says buildknecht).
[00:08:48] <guys> What did you do
[00:11:37] <buildmaster> haskell-tagstream-conduit is broken (says buildknecht).
[00:14:11] <buildmaster> haskell-x11 is broken (says buildknecht).
[00:17:04] <buildmaster> haskell-aeson-compat is broken (says buildknecht).
[00:18:50] <tyzoid> guys: I think they had an issue with gcc on the build system
[00:19:28] <buildmaster> haskell-sourcemap is broken (says buildknecht).
[00:23:31] <buildmaster> haskell-aeson-pretty is broken (says buildknecht).
[00:25:54] <buildmaster> haskell-microstache is broken (says buildknecht).
[00:28:21] <buildmaster> haskell-hjsonpointer is broken (says buildknecht).
[00:30:45] <buildmaster> haskell-binary-tagged is broken (says buildknecht).
[00:33:13] <buildmaster> haskell-path is broken (says buildknecht).
[00:33:16] -!- MrBIOS has parted #archlinux-ports
[00:33:40] -!- guys has quit [Ping timeout: 240 seconds]
[00:36:22] <buildmaster> haskell-wai-extra is broken (says buildknecht).
[00:38:56] <buildmaster> haskell-xml-hamlet is broken (says buildknecht).
[00:41:36] <buildmaster> haskell-texmath is broken (says buildknecht).
[00:46:52] <buildmaster> tp_smapi is broken (says buildknecht).
[00:54:11] -!- guys has joined #archlinux-ports
[00:54:12] <buildmaster> nvidia is broken (says buildknecht).
[01:14:46] -!- yans has joined #archlinux-ports
[01:29:55] <buildmaster> haskell-hasql-transaction is broken (says buildknecht2).
[01:30:38] <buildmaster> haskell-hasql-pool is broken (says buildknecht).
[01:31:31] <buildmaster> smplayer is broken (says rechenknecht).
[01:33:31] -!- buildmaster has quit [Remote host closed the connection]
[01:34:17] -!- buildmaster has joined #archlinux-ports
[01:50:56] -!- bill-auger has quit [Quit: No Ping reply in 180 seconds.]
[01:52:22] -!- bill-auger has joined #archlinux-ports
[02:01:06] -!- hringriin has quit [Ping timeout: 246 seconds]
[02:01:23] -!- hringriin has joined #archlinux-ports
[02:05:59] guys is now known as ztrawhcse
[02:10:07] -!- bill-auger has quit [Quit: No Ping reply in 180 seconds.]
[02:11:35] -!- bill-auger has joined #archlinux-ports
[02:19:00] <buildmaster> hwloc is broken (says rechenknecht).
[03:32:01] -!- oaken-so1rce has joined #archlinux-ports
[03:35:15] -!- oaken-source has quit [Ping timeout: 256 seconds]
[04:17:34] -!- yans has quit [Quit: chaos is the only true answer]
[05:21:35] ztrawhcse is now known as guys
[05:24:37] -!- hringriin_ has joined #archlinux-ports
[05:27:18] -!- hringriin has quit [Ping timeout: 240 seconds]
[05:27:18] hringriin_ is now known as hringriin
[05:37:05] -!- alyptik has quit [Ping timeout: 256 seconds]
[05:37:40] -!- alyptik has joined #archlinux-ports
[06:21:36] -!- deep42thought has joined #archlinux-ports
[06:22:53] <deep42thought> yeah, we tried to compile against the new mpfr but fails
[06:22:56] <deep42thought> *failed
[06:23:12] <deep42thought> ... compile gcc against ...
[06:29:18] <deep42thought> brtln: How did you get gcc to run with the old libmpfr but compile against the new one?
[06:52:23] -!- deep42thought has quit [Quit: Leaving.]
[08:01:04] -!- abaumann has joined #archlinux-ports
[08:01:08] <buildmaster> gcc is broken (says eurobuild3).
[08:01:20] <abaumann> error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
[08:01:20] <abaumann> Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
[08:01:21] <abaumann> their locations.
[08:01:37] <abaumann> gcc -o conftest -march=i686 -mtune=generic -O2 -fstack-protector-strong -fno-plt -D_FORT
[08:01:40] <abaumann> IFY_SOURCE=2 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now conftest.c -lmpc -lmpfr -lgmp >&5
[08:01:43] <abaumann> /usr/bin/ld: warning: libmpfr.so.4, needed by /usr/lib/gcc/i686-pc-linux-gnu/7.2.1/../../../libmpc.so, may
[08:01:46] <abaumann> conflict with libmpfr.so.6
[08:01:49] <abaumann> /usr/bin/ld: mpfr_reallocate_func: TLS definition in /usr/lib/libmpfr.so.4 section .tbss mismatches non-TL
[08:01:52] <abaumann> S definition in /usr/lib/gcc/i686-pc-linux-gnu/7.2.1/../../../libmpfr.so section .text
[08:01:55] <abaumann> /usr/lib/libmpfr.so.4: error adding symbols: Bad value
[08:01:57] <abaumann> collect2: error: ld returned 1 exit status
[08:02:27] <abaumann> So, gcc configure tries to link a test program which uses mpfr and mpc, the new mpfr is broken (or at least not usable by the old gcc)
[08:03:34] <abaumann> So mpc is linked against mpfr.4. I'm afraid, only rebuilding the toolchain by hand is an option here.
[08:03:40] -!- oaken-so1rce has quit [Ping timeout: 240 seconds]
[08:04:40] <abaumann> I don't see who you can gradually upgrade the dependencies of gcc (mpfr, mpc) into a staging area.
[08:04:48] <abaumann> *who -> how
[08:31:54] -!- deep42thought has joined #archlinux-ports
[08:35:05] <deep42thought> ok, let me try this:
[08:35:13] <deep42thought> I untar'ed the old mpfr
[08:35:23] <deep42thought> and now, during the build of gcc I removed it again
[08:35:44] <deep42thought> either the build fails, because it's gone, or the build succeeds and does not link against it :-/
[08:36:04] <deep42thought> looks like it fails :-/
[08:41:04] <deep42thought> hah, I think I got a real idea
[08:41:18] <abaumann> yes?
[08:41:34] <deep42thought> the problem might to be, that the symlink /usr/lib/libmpfr.so points to /usr/lib/libmpfr.so.4.1.6
[08:41:41] <deep42thought> and not *.6.0.0
[08:41:59] <abaumann> I think, the .so is ok.
[08:42:42] <abaumann> I generally think, we have problems with SObumps.
[08:43:07] <deep42thought> yes
[08:43:11] <deep42thought> we have
[08:43:32] <deep42thought> I was thinking of having a "gcc-old" which depends on "libmpfr-old", etc.
[08:43:47] <deep42thought> which can be installed and used to compile "gcc" linked against "libmpfr"
[08:43:52] <abaumann> I'm really curious how Archlinux 64 does it..
[08:44:01] <deep42thought> they manually modify chroots
[08:44:08] <abaumann> cool.
[08:44:58] <abaumann> basically, the icu sobump was handled in this way: there was an icu-old and an icu.
[08:45:13] <deep42thought> https://mirror.archlinux32.org
[08:45:14] <phrik> Title: #archlinux-ports | Logs for 2018-01-08 (at mirror.archlinux32.org)
[08:45:59] <abaumann> aha.
[08:46:06] <abaumann> I remember.
[08:46:56] <abaumann> I start to think that for stabilizing the whole thing the base and base-devel packages should not be built in a bleading edge manner but be bootstrapped every time afresh.
[08:47:17] <abaumann> basically, what I'm doing for i486 or the ARM people for Archlinux ARM.
[08:47:48] <abaumann> at least when the toolchain is upgraded.
[08:47:51] <deep42thought> sounds sane, but I have no idea how an implementation of that would look like
[08:47:55] <abaumann> not if there is some CVE patching..
[08:48:23] <abaumann> I'm currently doing that semi-automatic and with a cross-compiler (which is overkill for i686 and x86)
[08:49:02] <abaumann> another option is to build mpfr-new, mpc-new in some /opt/xxx directories and modify the PKBUILDs of gcc to use those libraries.
[08:49:38] <abaumann> --with-gmp, --with-mpc and --with-mpfr
[08:49:54] <abaumann> gcc behaves well in this situation and really picks the libraries you tell it to use.
[08:50:50] <abaumann> yet another one is to build gcc/mpfr/mpc/gmp now on a sane environment and to manually add them to the staging area.
[08:51:10] <abaumann> also not really elegant.
[08:51:23] <deep42thought> I prefer whichever option requires the least manual intervention (in the future)
[08:51:33] <abaumann> true
[08:52:56] <deep42thought> https://ptpb.pw
[08:53:05] <deep42thought> let's see if that's the correct configuration
[08:53:18] <deep42thought> but we should definitely fix this mess for future updates
[08:55:05] <deep42thought> hmm, this does not work :-/
[08:55:08] <abaumann> libmpc is still linked against libmpfr.so.4
[08:55:22] <deep42thought> ah, so I need to rebuild that first?
[08:55:40] <abaumann> so when the configure test tries to link a binary against libmpc and libmpfr.6 it also picks libmpfr.4 as a dependency of mpc
[08:55:58] <abaumann> thus the croaks of gcc that you are linking twice against different versions of the same library.
[08:56:26] <deep42thought> ah, ok
[08:56:27] <abaumann> I would build a libmpc using libmpfr.6 first
[08:56:32] <deep42thought> yeah
[08:56:36] <deep42thought> which package is that?
[08:56:36] <abaumann> then try gcc again with the new mpfr and mpc
[08:56:40] <abaumann> libmpc
[08:56:48] <deep42thought> ah, ok :-)
[08:57:31] <abaumann> but you will also need libmpfr.4 in the chroot for this to work (as gcc is linked against it)
[08:57:39] <deep42thought> yes
[08:57:42] <deep42thought> understood
[08:57:49] <abaumann> hope the configure mechanism of libmpc doesn't make a mess of it :-)
[09:00:18] <deep42thought> "Unused shared library '/usr/lib/libm.so.6'"
[09:00:23] <deep42thought> it links against the correct one :-)
[09:00:31] <abaumann> cool :-)
[09:01:16] <deep42thought> and now for gcc ...
[09:01:36] <abaumann> luckily we see result fast. :-)
[09:01:56] <deep42thought> how so?
[09:02:07] <abaumann> it fails in confiugre.. if it fails. :-)
[09:02:09] <deep42thought> should I not keep libmpfr.so.4?
[09:02:16] <abaumann> yes.
[09:02:19] <abaumann> you should.
[09:02:24] <abaumann> and new mpfr and new libmpc
[09:02:30] <deep42thought> I should keep, or should not keep?
[09:02:37] <deep42thought> ok
[09:02:41] <deep42thought> so all of them
[09:02:50] <abaumann> exactly
[09:03:18] <deep42thought> it compiles something
[09:03:25] <deep42thought> but it has done so before
[09:03:44] <deep42thought> the question is rather if the compiled gcc will be linked against the correct libmpfr
[09:03:47] <abaumann> for me it always failed in this configure check for mpfr and mpc
[09:03:52] <deep42thought> ah, right
[09:04:00] <deep42thought> if I had the correct symlink, it did
[09:04:06] <abaumann> that's the tricky part, yes.
[09:04:28] <abaumann> but the tests use libmpc.so and libmpfr.so which should point to the new libraries.
[09:04:50] <abaumann> autoconf is not know to play stupid tricks and find libraries in places where the are not supposed to be.
[09:05:09] <deep42thought> :-)
[09:05:22] <deep42thought> you have a hate against such hand-crafted magic ;-)
[09:05:39] <deep42thought> .. probably for a good reason :-D
[09:06:55] <abaumann> yes.
[09:07:20] <abaumann> everything deviating from the official way usually breaks in subtle ways somewhere where you don't expect it. :-)
[09:08:35] <abaumann> ..but what we do now cannot possible go wrong (TM) ;-)
[09:15:08] <deep42thought> it should be made possible to relink a binary w/o requiring to rebuild the whole beast ;-)
[09:16:57] <deep42thought> "Hey, gcc, I know you're linked against libmpfr.so.4.1.6, but can you replace your jump coordinates by the ones from libmpfr.so.6.0.0?"
[09:17:34] <abaumann> I'm sure you can patch the ELF binary. ;-)
[09:18:03] <abaumann> rpath patching elf hacks :->
[09:18:22] <abaumann> ok. gcc went over the critical mpfr/mpc point on my slave.
[09:18:49] <abaumann> so, if things fail again, at least I have a workspace where I can debug. :-)
[09:19:37] <deep42thought> :-)
[09:19:50] <deep42thought> btw: you're a huge help
[09:19:58] <abaumann> np :-)
[09:21:55] <deep42thought> regarding the buildmaster hook to shut up: it does not have something like that, but feel free to implement something
[09:22:20] <abaumann> :-)
[09:22:46] <abaumann> I wanted to do a better opcode sniffer, but the new one is much slower than the old one. :-(
[09:23:03] <deep42thought> how much is "much"?
[09:23:11] <abaumann> 10 times or so?
[09:23:26] <deep42thought> doesn't sound too bad
[09:23:30] <deep42thought> what's the improvement?
[09:23:45] <abaumann> silly idea of mine, I wanted to go through all files and use libmagic to detect all binaries and not only shared libraries.
[09:24:02] <deep42thought> and that makes it so slow?
[09:24:12] <abaumann> I don't know..
[09:24:36] <deep42thought> hmm, anyway: can you pleas check you pull requests with "shellcheck"?
[09:24:40] <abaumann> Maybe some heuristics like "check for files in *bin/, *lib/ only" would help.
[09:24:48] <abaumann> shellcheck?
[09:24:59] <abaumann> ah.
[09:25:05] <abaumann> didn't know that one.
[09:25:07] <deep42thought> I use it in a git hook
[09:25:09] <abaumann> goot point.
[09:25:12] <abaumann> *good
[09:25:27] <abaumann> yes. will do.
[09:25:31] <deep42thought> it is quite pedantic, so you may need to switch off some tests
[09:25:41] <deep42thought> # shellcheck disable=SC2016
[09:26:06] <deep42thought> ... for all the mysql queries (with "`" which should not run a shell command)
[09:26:12] <deep42thought> as an example
[09:26:33] <abaumann> :-)
[09:26:56] <deep42thought> but it detects useful other stuff
[09:27:05] <deep42thought> typos in variable names
[09:27:17] <deep42thought> variables that won't expand but you expect them to
[09:27:19] <deep42thought> and so on ...
[09:27:36] <abaumann> the better the lint tools of a language, the crappier the language ;-)
[09:27:48] <deep42thought> :-D
[09:27:55] <deep42thought> !grab abaumann
[09:27:56] <phrik> deep42thought: 🎉
[09:27:56] <abaumann> (one polemic statement a day)
[09:28:46] <abaumann> /usr/include/features.h:376:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
[09:29:02] <deep42thought> is that the reason, why debian has such a nice linter?
[09:29:06] <abaumann> mmh. playing with flags when compiling a compiler is very dangerous.
[09:29:09] <deep42thought> which even finds typos in man pages?
[09:29:29] <deep42thought> I've seen that warning befor
[09:29:30] <deep42thought> e
[09:29:40] <deep42thought> but I'm not sure that it was with gcc, though
[09:30:15] <abaumann> I think it just tells you, that fortify is now disabled because of lacking -O2 parameters.
[09:30:41] <abaumann> because makepkg.conf has fortify enabled, which is correct for 99.99% of all packages.
[09:31:01] <deep42thought> ah, ok
[09:31:02] <abaumann> I have seen this before on the upstream gcc, it's fine.
[09:31:08] <deep42thought> but gcc does not need fortification?
[09:31:14] <deep42thought> ok
[09:31:26] <abaumann> it breaks in certain parts, if you optimize the code, I suppose.
[09:31:57] <abaumann> in compiler and kernel code you usually don't want the optimizer to reorganize or remove code. :-)
[09:32:11] <abaumann> on the other hand, that's what CPUs are doing nowadays :->
[09:40:22] <brtln> deep42thought: figured it out?
[09:40:36] <deep42thought> brtln: I think so
[09:40:47] <brtln> it wasn't me this time but I planned to extract only libraries that gcc/mpfr/mpc link to
[09:40:59] <brtln> not the headers or pkg-config files
[09:41:01] <deep42thought> but I'd really love to have a procedure which makes automatically building gcc possible :-)
[09:41:15] <deep42thought> yeah
[09:41:18] <deep42thought> something like that
[09:42:01] <brtln> we don't really have automation to here's arch for you :)
[09:42:04] <deep42thought> that's a pretty good and easy-to-implement idea, actually
[09:43:24] <deep42thought> we create a package 'gcc-dependency-libs' or something, which includes libmpfr.so.4* and alike, and list it as a makedepend of gcc
[09:43:40] <deep42thought> then we just need to make sure that gcc-dependency-libs is compiled _after_ gcc
[09:53:51] <deep42thought> or we can keep the old version of it around in build-support
[09:54:22] <abaumann> I like that idea :-)
[09:55:03] <deep42thought> the only malus is, that we need to keep the list of to-be-kept libraries up to date
[09:55:07] -!- oaken-source has joined #archlinux-ports
[09:55:28] <deep42thought> but it should be much cleaner than what we're doing right now :-)
[09:55:57] <abaumann> and it's a very cheap solution to implement compared to do bootstrapping or smart depenedency detection or whatever.
[09:56:08] <deep42thought> yes
[09:56:23] <deep42thought> we have basically all required things in place, already
[09:56:34] <deep42thought> we just need to write a PKGBUILD for the package
[09:56:42] <abaumann> yeah
[09:56:46] <deep42thought> and modify gcc's PKGBUILD
[09:57:14] <deep42thought> is there an easy way to detect which libraries we need?
[10:00:36] <deep42thought> ah, I can see one problem:
[10:01:19] <deep42thought> if we have libraries from say mpfr and mpc, but only one receives a so bump, then we will get file conflicts for the other one
[10:01:43] <deep42thought> so we'd need separate a libraries-only package for each
[10:02:11] <deep42thought> ah, no, this will create file conflicts, too
[11:32:23] <deep42thought> this gcc seems to be linked completely against libm.so.6 :-)
[11:43:26] <abaumann> ah. so your build has finished.
[11:43:32] <deep42thought> yep
[11:43:43] <deep42thought> and we already have some non-failing builds afterwards :-)
[11:43:56] <abaumann> but to make sure. I'll check the libraries.. :-)
[11:44:04] <deep42thought> sure, go ahead!
[11:44:29] <deep42thought> but namcap only complained about "unneeded shared library /usr/lib/libmpfr.so.6.0.0"
[11:44:40] <deep42thought> and not the other "uninstalled ... libmpfr.so.4.1.6"
[11:45:02] <abaumann> ldd usr/lib/gcc/i686-pc-linux-gnu/7.2.1/cc1 says:
[11:45:08] <abaumann> libmpfr.so.6
[11:45:10] <abaumann> ok.
[11:45:36] <deep42thought> lol, we have currently "60 broken packages"
[11:46:19] <abaumann> btw: it's quite funny: we linked a new libmpc with a stable ABI against a newer libmpfr.so.6. gcc was not rebuilt against mpc and runs with both versions of mpc.
[11:46:46] <abaumann> so the ABI of mpc was stable no matter whether mpfr.4 or mpfr.6 was underneath.
[11:47:14] <abaumann> 60 packages.. and the buildmaster compiles haskell-* first :-)
[11:47:30] <deep42thought> well, he schedules broken packages last
[11:47:51] <abaumann> which is a good thing. :-)
[11:50:24] <abaumann> namcap seems to be wrong. /usr/lib/libmpfr.so.6.0.0 is hardly unneeded..
[11:51:12] <deep42thought> yeah, I read namcaps "unneeded library x" as "did you know, that you also linked against x?"
[11:51:24] <abaumann> aha.
[11:51:37] <abaumann> then it makes sense.
[11:51:53] <deep42thought> well, the message literally says something different
[11:52:01] <deep42thought> but I read it the other way
[12:04:15] <abaumann> ui.. new kernels with new compiler.. :-)
[12:04:20] <deep42thought> yeah
[12:04:31] <deep42thought> I thought, I can accelerate those a little
[12:04:37] <abaumann> how?
[12:04:44] <deep42thought> by removing the "broken" marker
[12:04:51] <deep42thought> so they get scheduled earlier
[12:05:01] <abaumann> ah.
[12:32:02] -!- MrBIOS has joined #archlinux-ports
[14:26:57] <buildmaster> intel-gpu-tools is broken (says buildknecht).
[14:49:48] <deep42thought> hmm, one barely notices the increase in traffic on the master mirror due to the finished gcc build: https://jeti100.ioq.uni-jena.de
[15:23:06] <buildmaster> python2 is broken (says nlopc46).
[15:23:18] <deep42thought> it can't run xvfb-run for some reason
[15:41:00] <buildmaster> gnome-builder is broken (says nlopc46).
[15:41:24] <deep42thought> maybe, nlopc46 is broken (says me)
[15:44:39] <abaumann> let my build a package on my slave, then we'll see..
[15:44:49] <deep42thought> the other slaves build fine
[15:44:54] <abaumann> oh.. my slave still does gcc ieee testing. :-)
[15:44:59] <deep42thought> it's just nlopc46 which breaks packages currently :-)
[15:45:04] <abaumann> ah.
[15:45:32] <abaumann> so, no harm, because the builds hop slaves and get built eventually. :-)
[15:45:34] <deep42thought> we have now 280 packages in staging and co.
[15:45:52] <deep42thought> abaumann: either that or they're really broken anyway
[15:45:59] <deep42thought> (the last one looked like a real error to me)
[15:46:54] <deep42thought> currently, nlopc46 built ruby-ng successfully
[15:47:00] <deep42thought> so it's not totally broken :-D
[15:47:13] <deep42thought> um "ruby-pg"
[16:00:58] <buildmaster> android-tools is broken (says nlopc46).
[16:18:10] -!- MrBIOS has quit [Quit: MrBIOS]
[16:53:23] <buildmaster> python-astroid is broken (says buildknecht).
[17:13:40] -!- oaken-source has quit [Ping timeout: 240 seconds]
[17:22:16] -!- MrBIOS has joined #archlinux-ports
[17:24:02] -!- MrBIOS has quit [Client Quit]
[17:24:57] -!- MrBIOS has joined #archlinux-ports
[18:00:18] -!- guys has quit [Ping timeout: 240 seconds]
[18:15:00] -!- guys has joined #archlinux-ports
[18:23:42] -!- deep42thought has quit [Quit: Leaving.]
[18:36:49] -!- abaumann has quit [Quit: leaving]
[18:39:15] eschwartz is now known as anyone
[19:07:26] -!- deep42thought has joined #archlinux-ports
[19:09:57] <buildmaster> electron is broken (says nlopc46).
[19:30:27] -!- abaumann has joined #archlinux-ports
[19:39:48] -!- bill-auger has quit [Ping timeout: 240 seconds]
[19:40:04] -!- bill-auger has joined #archlinux-ports
[19:44:03] -!- MrBIOS has quit [Quit: MrBIOS]
[19:45:16] <deep42thought> lol, electron has like a dozen patches applied, which are called like "use-system-libraryx.patch"
[19:45:17] <deep42thought> ...
[19:45:28] -!- CashDash123 has joined #archlinux-ports
[19:45:34] -!- MrBIOS has joined #archlinux-ports
[19:53:40] -!- bill-auger has quit [Ping timeout: 268 seconds]
[19:53:54] -!- bill-auger has joined #archlinux-ports
[19:54:35] <tyzoid> imo electron can go die in a dumpster fire.
[19:54:37] <CashDash123> So hows the fork going?
[19:54:41] <tyzoid> going well
[19:54:42] <tyzoid> ish
[19:54:53] <deep42thought> we have a working gcc (again) :-)
[19:55:12] <CashDash123> deep42thought, it broke?
[19:55:32] <deep42thought> yeah, it does so with each so-name bump of its dependencies
[19:55:42] <tyzoid> deep42thought spent most the past day and a half dealing with out of date libraries
[19:56:08] <CashDash123> So you all updated now?
[19:56:12] <deep42thought> well, only with one half of my brain
[19:56:13] <deep42thought> ;-)
[19:56:16] <tyzoid> lol
[19:56:23] <deep42thought> still some packages to be built
[19:56:29] <deep42thought> but it's rolling again
[19:56:40] <tyzoid> We're still rolling. Things tend to lag a bit because of the build system and lack of manpower.
[19:56:47] <deep42thought> https://buildmaster.archlinux32.org
[19:56:48] <tyzoid> More people working on different packages would speed the process up
[19:56:48] <phrik> Title: Buildmaster for Archlinux32 packages (at buildmaster.archlinux32.org)
[19:56:57] <CashDash123> I thought most of the packages were still built for i686?
[19:57:21] <tyzoid> Arch stopped that in November of last year
[19:57:22] <deep42thought> no packages are built officially for i686
[19:57:43] <deep42thought> but fortunately, most packages can be built for i686 with minimal changes
[19:57:51] <deep42thought> (e.g. only adding "i686" to the arch=... array)
[20:02:09] <deep42thought> tyzoid: btw, the database on the buildmaster seems to work correctly
[20:02:48] <deep42thought> so if you want to write some json interface to it, have a look here: https://buildmaster.archlinux32.org
[20:03:04] <tyzoid> ok, sounds good.
[20:03:33] <tyzoid> deep42thought: any opposition to running PHP as the jsonapi host? Or would you rather some other service?
[20:03:38] <deep42thought> note, that I took the liberty to not bootstrap the dependencies and build-assignments of current stable packages
[20:03:52] <deep42thought> we have already php on the buildmaster
[20:03:54] <deep42thought> so php is fine
[20:03:57] <tyzoid> ok
[20:04:12] <tyzoid> deep42thought: Can you send me a dump of the db to do some local testing/dev on?
[20:04:17] <deep42thought> only downside is, that currently, php pages are cached
[20:04:25] <deep42thought> so we might want to change that
[20:04:27] <tyzoid> doesn't need to have 100% complete data, just needs to have some data
[20:04:44] <tyzoid> deep42thought: Does your reverse proxy honor pragma:cache headers?
[20:04:44] <deep42thought> um, let me try :-)
[20:04:57] <deep42thought> dunno ^
[20:05:40] <tyzoid> Yeah, PHP can set a custom header saying "Hey, don't cache me!"
[20:11:20] <deep42thought> tyzoid: If you find anything to improve on the db, feel free to tell me so
[20:11:26] <deep42thought> I'm a database noob
[20:11:31] <tyzoid> yeah, no problem.
[20:11:32] <deep42thought> (this is my first) ^^
[20:11:37] <tyzoid> nice :)
[20:12:18] <deep42thought> I understand quantum mechanics, relativity and nonlinear optics - I can do anything *murr* *harr* *harr*
[20:12:52] <abaumann> that laser of yours.. some pinky and the brain project? ;-)
[20:13:24] <deep42thought> no
[20:13:26] <deep42thought> well
[20:13:32] <deep42thought> actually, we shot on mice once
[20:13:33] <abaumann> aha!
[20:13:41] <deep42thought> to treat cancer ...
[20:13:47] <deep42thought> (not my project)
[20:13:53] <abaumann> ah yeah, heard of that..
[20:14:06] <deep42thought> I just create boring different radiation ...
[20:14:15] <abaumann> :-)
[20:14:47] <tyzoid> deep42thought: You're a PHD student, right?
[20:14:52] <deep42thought> yes
[20:15:09] <tyzoid> What's your intention after your dissertation? Professorship? Looking towards Tenure, or industry?
[20:15:22] <deep42thought> industry
[20:15:33] <tyzoid> nice.
[20:15:49] <deep42thought> currently, the situation in Germany is not that nice for a career at the university
[20:15:58] <deep42thought> you hop from one contract to another
[20:16:12] <deep42thought> and there is not really a different chance than to become a professor
[20:16:27] <tyzoid> makes sense.
[20:16:35] <deep42thought> but if you count the numbers, there are too many people, which can't all become professors
[20:16:56] <tyzoid> yeah. So where to next? Fiber optics?
[20:17:19] <deep42thought> or some optics production
[20:17:26] <deep42thought> but this is more solid state physics
[20:17:27] <deep42thought> ...
[20:17:34] <deep42thought> well, I don't know yet :-)
[20:17:57] <tyzoid> lol
[20:18:05] <deep42thought> there are quite some optics centered companies here around Jena
[20:18:11] <tyzoid> You need to get into liquid state optics :P
[20:18:19] <deep42thought> ^^
[20:18:46] <MrBIOS> what are you guys testing on, as far as true 32-bit hardware is concerned?
[20:18:48] <deep42thought> I'm doing plasma physics currently - that's pretty close to "liquid states physics"
[20:19:12] <deep42thought> MrBIOS: "VIA C7-D Processor 1800MHz"
[20:19:15] <tyzoid> MrBIOS: I mostly test in a VM, but I've got an old E-Machines laptop from the early 2000s to test with
[20:19:53] <deep42thought> and "Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz"
[20:19:53] <abaumann> MrBios: vm with features tweaking, eeepc 701, alix.1e, AMD-K6 machine (homebrew)
[20:20:16] <deep42thought> abaumann: you test on the alix?
[20:20:27] <MrBIOS> abaumann: glad to hear you have an ALIX :)
[20:20:27] <abaumann> yes :-)
[20:20:40] <deep42thought> oh, nice
[20:20:41] <guys> lol @ electron
[20:20:46] <deep42thought> I really should kick out debian
[20:20:49] <MrBIOS> abaumann: if you have any interest in having an OLPC XO-1 laptop, let me know
[20:20:54] <guys> but hey, people apparently want it
[20:21:14] <deep42thought> guys: current error is "Do not know how to build a snapshot for //build/toolchain/linux:clang_x64 on linux x86"
[20:21:22] <deep42thought> do you have any idea?
[20:21:24] <abaumann> MrBIOS: that would be very handy. But sending it will be expensive, or not?
[20:21:33] <guys> deep42thought: sounds bizarre
[20:22:09] <deep42thought> abaumann: didn't we have a problem with "gn" before?
[20:22:47] <MrBIOS> abaumann: not necessarily. If you e-mail me an address, I can look into it. I have a few options.
[20:22:48] <abaumann> gn? help me.. :-)
[20:23:07] <deep42thought> this fails during the electron build
[20:23:18] <abaumann> http://www.andreasbaumann.cc
[20:23:18] <phrik> Title: Contact (at www.andreasbaumann.cc)
[20:23:19] <deep42thought> I thought, I've seen a failing gn before ...
[20:24:14] <abaumann> MrBIOS: that would be really nice :-)
[20:24:35] <deep42thought> abaumann: ah, right, it was skia-sharp and skia-sharp58
[20:24:46] <abaumann> rings a bell..
[20:25:16] <MrBIOS> abaumann: I have been looking for a “long term” 32-bit distribution for use with the XO-1 and XO-1.5 (both of which are i686) and Arch is compact enouh that it fits the bill pretty well
[20:25:37] <abaumann> line 63: bin/gn: No such file or directory
[20:25:39] <abaumann> aha.
[20:26:06] <abaumann> MrBIOS: really sad, they didn't continue with the XO line, the XO-3 would have been a nice machine..
[20:26:16] <MrBIOS> the XO-4 exists, it was based on a Marvell ARM part
[20:26:23] <abaumann> ah?!
[20:26:27] <MrBIOS> there was no XO-2 or XO-3
[20:26:32] <abaumann> just plans.
[20:27:01] <abaumann> ah. the green color is a datum, I see..
[20:27:06] <MrBIOS> I can get one to you for USD $32.95
[20:27:24] <abaumann> the XO-4 is far too modern for me :-)
[20:27:30] <deep42thought> lol
[20:27:50] <MrBIOS> which, incidentally, is around what I sell them for, normally.
[20:28:21] <MrBIOS> I’ll send you one for free if you promise to actually test arch32 on it ;)
[20:28:31] <abaumann> ok. deal. :-)
[20:28:47] <deep42thought> MrBIOS: thanks for the support!
[20:28:49] <abaumann> and I'll add a section in the wiki about installation issues..
[20:28:55] <abaumann> yes, really appreciated. :-)
[20:29:06] <MrBIOS> if you would prefer to have a serial console, there is a connector for that on the XO
[20:29:44] <MrBIOS> it would be really great to have an alternate kernel package built with the XO-1 specific defconfig, too
[20:30:26] <MrBIOS> I’d be happy to help maintain that
[20:30:52] <abaumann> i586 instruction set (including MMX and 3DNow! Enhanced) with additional Geode-specific instructions
[20:31:00] <abaumann> sounds very Geode-ish to me.
[20:31:33] <abaumann> Geode LX. Bingo.
[20:31:43] <abaumann> Did you ever try to install the current Archlinux32 on it.
[20:31:43] <MrBIOS> yep, it’s LX
[20:32:00] <abaumann> Because that's the same or a similar chip as in the Alix 1.E
[20:32:03] <MrBIOS> abaumann: I have not tried yet, I am reasonably confident it will work fine.
[20:32:09] <MrBIOS> They are both Geode LX
[20:32:29] <MrBIOS> if there were a filesystem image I could just DD, I’d hve tested it already :
[20:32:31] <abaumann> the X11 driver is tricky. so far I didn't manage to use it.
[20:32:38] <MrBIOS> yeah that’s a mess
[20:32:56] -!- CashDash123 has quit [Remote host closed the connection]
[20:33:14] <abaumann> iPXE as for upstream would be neat actually.
[20:33:16] <MrBIOS> its almost probably easier to use an old custom version of X that’s known to work with 2D hardware acceleration, in the case of the XO
[20:34:08] <abaumann> ohje: electron. typicall modern software development. git with submodules builds half an operating system..
[20:34:31] <abaumann> Downloading electron-chromium-58.... give me a break.
[20:35:06] <deep42thought> the pkgdesc also sounds like half a operating system :-)
[20:35:13] <abaumann> :-)
[20:35:40] <MrBIOS> abaumann: the only thing that’s weird about the XO is there is no legacy PC BIOS
[20:35:42] <MrBIOS> it’s all OpenFirmware
[20:35:53] <MrBIOS> well, there are many things werid about it, actually, so that’s a lie
[20:35:58] <abaumann> yeah. like some alix machines. that's nice actually.
[20:36:03] <MrBIOS> I like it, personally
[20:39:22] <abaumann> deep42thought: electron, yea. it builds a Javascript interpreter like skia: ERROR at //v8/snapshot_toolchain.gni:95:1: Assertion failed.
[20:39:26] <abaumann> Do not know how to build a snapshot for //build/toolchain/linux:clang_x64 on linux x86
[20:39:36] <abaumann> So, there is no other option I'm afraid but blacklisting it.
[20:39:54] <deep42thought> ok
[20:40:07] <abaumann> Extracting chromium source...
[20:40:11] <abaumann> ok. that's it.
[20:40:18] <abaumann> This is 30000 source files. :-)
[20:40:23] <deep42thought> :-)
[20:40:44] <abaumann> We learned to build software in layers, and reuse was shared libraries.
[20:40:58] <deep42thought> this is so last-century ...
[20:41:26] <abaumann> you cannot image what fight I have with some people at work who are all in gitmodules, C++ fanciness and docker.. :->
[20:41:37] <deep42thought> :-)
[20:42:23] <deep42thought> I guess, when it comes to programming standards, physicists are the worst of all :-/
[20:42:37] <abaumann> linguists? :-)
[20:42:39] <tyzoid> lol
[20:42:56] <abaumann> from a small sample of 5 people or so.. :-)
[20:42:59] <deep42thought> well, you need to be able to write compiling code to contribute to that list
[20:45:17] <tyzoid> Tom Scott can write code
[20:45:25] <tyzoid> He's a linguistics major
[20:45:27] <abaumann> true.
[20:45:35] <abaumann> like his channel BTW
[20:46:31] <tyzoid> but yeah. People who write electron apps are usually just lazily writing something that will work in browser and on desktop
[20:47:00] <tyzoid> Usually with little regard to performance issues.
[20:47:27] <tyzoid> Increasingly, it's companies that are the cause of the issues. Slack and Discord are the two big ones
[20:48:31] <tyzoid> But yeah. I've got no problem with javascript on desktop, but once you recreate a web browser just for window management and rendering it, that's where I draw the line.
[20:52:05] <abaumann> https://bugs.archlinux32.org just retested and stabilized.
[20:52:07] <phrik> Title: FS#24 : [extra/viewnior] Needs rebuild against exiv2=0.26 (at bugs.archlinux32.org)
[20:52:09] <abaumann> works for me.
[20:52:26] <deep42thought> thanks!
[20:52:35] <abaumann> I hope stabilize works..
[20:53:24] <MrBIOS> abaumann: would you like me to include a US 12 volt charger? the XO1 just takes 9-20VDC in (~1.5A@12VDC) via a barrel jack.
[20:53:39] <deep42thought> buildmaster: why dont you stabilize viewnior
[20:53:40] <buildmaster> "viewnior" is not tested yet!
[20:53:48] <abaumann> huh?
[20:54:12] <abaumann> MrBIOS: does the charger work on 220V?
[20:54:29] <MrBIOS> it’s a dual-ranging switching power supply, so yes, but you’d obviously need mechanical adapter
[20:54:38] <abaumann> ah. this is no problem.
[20:54:44] <abaumann> my eeepc also has an US plug. :-)
[20:54:52] <abaumann> buildmaster: why dont you stabilize viewnior
[20:54:53] <buildmaster> "viewnior" is not tested yet!
[20:55:23] <deep42thought> ok, i marked it as tested
[20:55:25] <abaumann> mmh, weird. https://buildmaster.archlinux32.org doesn't show the mail. The invalid stamp is an older mail.
[20:55:29] <abaumann> ok. thanks.
[20:56:05] <deep42thought> the status update is asynchronous
[20:56:13] <deep42thought> of the mail log
[20:56:25] <abaumann> ah.
[20:56:38] <abaumann> ..and I'm inpatient.. :-)
[20:56:51] <deep42thought> I just force-updated it, but it didn't show anything new :-/
[20:57:00] <deep42thought> can you send again?
[20:58:19] <abaumann> ok
[20:58:29] <abaumann> buildmaster: why dont you stabilize viewnior
[20:58:29] <buildmaster> Package "viewnior" can be stabilized.
[20:58:47] <deep42thought> "reading message archlinux32-buildmaster@eckner.net@eckner.net:1 of 1 (3736 octets) flushed"
[20:58:51] <deep42thought> so it arrived ...
[20:58:56] <abaumann> good :-)
[20:59:12] <abaumann> thanks for testing..
[21:00:01] <deep42thought> hmm, it didn't log anything :-/
[21:00:03] <deep42thought> strange
[21:00:08] <deep42thought> can you send once more, please?
[21:00:14] <deep42thought> I try not to delete that one :-)
[21:01:02] <abaumann> ok
[21:03:42] <deep42thought> hah!
[21:03:49] <deep42thought> your key is not listed for testing packages
[21:03:52] <deep42thought> O.o
[21:03:57] <deep42thought> why did I do that?
[21:04:08] <abaumann> ah. this explains it. lol
[21:04:41] <buildmaster> libasl is broken (says buildknecht3).
[21:06:12] <deep42thought> https://ptpb.pw
[21:06:13] <tyzoid> lol
[21:06:43] <abaumann> well, marking 0 packages as tested is a success. :-)
[21:06:49] <deep42thought> yes
[21:06:58] <deep42thought> since it's like the 10th time I ran that command :-)
[21:07:46] <deep42thought> " No rule to make target '/usr/lib/libnetcdf.so', needed by 'src/libaslvtk.so.0.1.7'. Stop."
[21:07:47] <deep42thought> huh?
[21:08:23] <deep42thought> is it common to list absolute paths to system libraries as dependencies for make?
[21:08:43] <abaumann> aeh. I think libtool does it sometimes.
[21:08:58] <abaumann> no, -L<path> -l<library> is the standard way.
[21:09:21] <abaumann> why doesn't that break on 64-bit?
[21:10:23] <abaumann> ah. it's cmake-ish..
[21:14:58] <deep42thought> !wtf /usr/lib/libnetcdf.so
[21:14:59] <phrik> deep42thought: community/netcdf
[21:16:04] <deep42thought> this is also present in our netcdf
[21:16:24] <deep42thought> which is not installed O.o
[21:16:50] <abaumann> it's not in depends.
[21:17:02] <deep42thought> so why is it installed upstream, then?
[21:17:51] <abaumann> something in base installs it, so it's always around?
[21:18:05] <abaumann> pactree -a -r netcdf -> gdal, postgis.
[21:18:07] <abaumann> not really.
[21:18:38] <deep42thought> I guess, it's some "provides"
[21:18:50] -!- MrBIOS has quit [Quit: MrBIOS]
[21:18:58] <deep42thought> which is different, because our netcdf is in stable and the other which provides the same is in testing
[21:20:08] <deep42thought> I remember networkmanager being an issue
[21:20:13] <deep42thought> in the past
[21:20:13] <abaumann> I built on testing, there it works, so the problem is in staging.
[21:20:34] <deep42thought> just compare what gets installed
[21:20:42] <deep42thought> compared to when you build from staging
[21:21:05] <deep42thought> or even better: compare our staging against upstreams stable
[21:24:54] <deep42thought> I can see libglvnd vs nvidia-340xx-utils
[21:27:19] <abaumann> vtk added netcdf as dependency?
[21:27:56] <abaumann> and I have vtk always installed, as I use the geany editor..
[21:29:36] <deep42thought> nope, our vtk is identical
[21:29:44] <abaumann> mmh. sad.
[21:29:55] <abaumann> well, not sad. I thought, I found it :-)
[21:30:49] <deep42thought> let me check all packages :-)
[21:35:33] <abaumann> aha: got it on 64-bit.. :-)
[21:39:42] <deep42thought> I haven't found a difference yet
[21:39:48] <deep42thought> what do you think the issue is?
[21:40:08] <abaumann> some transitive dependency on libcdf
[21:40:26] <abaumann> it's not libasl's fault, I think.
[21:40:45] <abaumann> aslvtk_LIB_DEPENDS contains /usr/lib/libnetcdf.so
[21:40:55] <abaumann> via vtk.
[21:43:54] <abaumann> Tue Jan 16 18:22:59 2018 +0000, upgpkg: vtk 8.1.0-2, use system netcdf
[21:46:00] <deep42thought> vtk has a _make_dependency on netcdf
[21:47:29] <abaumann> and an optdepend, then in build it enable it with -DVTK_USE_SYSTEM_NETCDF
[21:47:48] <deep42thought> clicking through the dependencies of netcdf on packages.archlinux.org I can't find a link to libasl
[21:48:11] <abaumann> it might me just a plugin
[21:48:42] <abaumann> required by vtk (optional), vtk is a dependency of libasl
[21:48:48] <deep42thought> yes
[21:48:51] <deep42thought> but it's optional
[21:50:52] -!- MrBIOS has joined #archlinux-ports
[21:54:48] <abaumann> but: if it is a makedepend, it gets installed and is in the chroot, so it is picked up as a library dependency. besides, having something as makedepend AND optdepend doesn't make sense so me..
[21:55:03] <abaumann> *to me
[21:56:39] <deep42thought> you may need something at build time, which is optional at runtime?
[21:57:46] <abaumann> yeah. but not a library.
[21:58:17] <deep42thought> if the functionality provided by that library is optional?
[21:59:31] <abaumann> it's the only change in vtk regarding libnetcdf, otherwise, I don't see what could be the probme.
[21:59:47] <abaumann> *problem.
[21:59:48] <deep42thought> well, just open a bug reoport upstream
[21:59:54] <abaumann> ok.
[22:00:02] <deep42thought> it fails on x86_64, so we should do so :-)
[22:00:17] <abaumann> throwing it over the architecture wall. ;-)
[22:01:27] <deep42thought> :-)
[22:09:01] <guys> abaumann: some things use dlopen to make compile-time features be runtime optional
[22:09:06] <guys> Which is awesome
[22:14:17] <abaumann> yes. but somehow it ends up as a cmake dependency in libasl.
[22:15:15] <abaumann> well, too late, I have to sleep, I don't see clearly anymore. :-)
[22:15:16] <abaumann> bye.
[22:15:26] -!- abaumann has quit [Quit: leaving]
[22:18:16] <tyzoid> ♫ I can see clearly now, the rain has gone! ♫
[22:18:30] <tyzoid> ♫ I can see alllll obstacles in myyyyy waaayyyyy! ♫
[22:23:14] <guys> I guess, cmake isn't using dlopen for runtime-optional features. ;)
[22:51:07] -!- deep42thought has quit [Quit: Leaving.]
[23:02:17] -!- oaken-source has joined #archlinux-ports
[23:03:24] -!- isacdaavid has joined #archlinux-ports