#archlinux32 | Logs for 2019-08-02

[00:37:18] -!- pulec has quit [*.net *.split]
[02:49:37] -!- bill-auger has quit [Remote host closed the connection]
[02:51:44] -!- bill-auger has joined #archlinux32
[04:22:00] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.query.2019-08-02T04:11:26.QdzhMc.stdin"?.
[06:44:21] * buildmaster resumes sanity.
[06:49:52] <buildmaster> pentium4/libmypaint is broken (says eurobuild6-1): https://archlinux32.org
[06:51:18] <buildmaster> i686/libmypaint is broken (says rechenknecht): https://archlinux32.org
[06:56:59] -!- titus_livius has joined #archlinux32
[08:30:13] -!- nit-picker has joined #archlinux32
[08:32:32] -!- deep42thought has joined #archlinux32
[08:32:33] <buildmaster> Hi deep42thought!
[08:32:34] <buildmaster> !rq deep42thought
[08:32:34] <phrik> buildmaster: <deep42thought> nah, I never ran emacs - it's a nice os, but I couldn't find a suitable editor for it
[08:33:35] -!- nit-picker has quit [Remote host closed the connection]
[08:42:54] -!- abaumann has joined #archlinux32
[08:42:55] <buildmaster> Hi abaumann!
[08:42:55] <buildmaster> !rq abaumann
[08:42:56] <phrik> buildmaster: <abaumann> canary no. 2 is back on testing. :-)
[08:43:05] <abaumann> hi deep42thought
[08:44:10] <deep42thought> Hi abaumann!
[08:48:27] <abaumann> I think the high number of blocks of js60 is explainable: it's just two direct packages which depend on it, but one of them is polkit.
[08:48:39] <deep42thought> ui
[08:49:00] <deep42thought> does it make sense to force-build polkit and reschedule it afterwards?
[08:49:12] <deep42thought> (e.g. when all dependencies are built)
[08:49:23] <deep42thought> or is js60 build-critically broken for polkit?
[08:49:41] <abaumann> dunno. If policies are written in Javascript maybe.
[08:50:10] <abaumann> which IMHO is a stupid idea: domain-specific languages are better suited to do something like a security configuration
[08:50:22] <abaumann> Javascript brings in also a big attack vector
[08:50:39] <abaumann> I try to fix libidn and libseccomp (both in core)
[08:50:46] <abaumann> they are also blocking quite some stuff
[08:50:49] <deep42thought> good, thank you!
[08:51:21] <abaumann> and I try to avoid to solve the Java or the Rust/librsvg problems as long as possible. :-)
[08:51:40] <deep42thought> they are a big demotivator ...
[08:51:57] <abaumann> indeed!
[08:58:37] <bill-auger> did you guys try building rust 1.36 for i686 yet? - i see you have it for pentium4 but i could not find those patches
[08:58:57] <deep42thought> we tried
[08:59:10] <bill-auger> i applies the patches from the arch32 gittea extra but the build failed
[08:59:15] <deep42thought> https://bugs.archlinux32.org
[08:59:17] <phrik> Title: FS#71 : rust doesn't rebuild (at bugs.archlinux32.org)
[08:59:32] <bill-auger> did it look like this http://termbin.com
[09:00:01] <deep42thought> no
[09:00:01] <bill-auger> thats a drag - firefox will not build against the rust in i686
[09:01:18] <bill-auger> firefox 68
[09:01:26] <deep42thought> it looked to me, like if rust 1.36 is not buildable by rust 1.33
[09:01:33] <deep42thought> so I tried building rust 1.34 instead
[09:01:43] <deep42thought> ... which had the issues mentioned in the bugtracker ...
[09:01:48] <bill-auger> i think 1.34 would satisy firefox
[09:02:07] <abaumann> I tried once to go through Slackwares bootstrap sequence which starts with mrustc, I also got stuck in a micro updates from a 1.xx to 1.(xx+1)
[09:02:09] <deep42thought> 1.34 is certainly a step forward in direction of rust 1.36 ...
[09:03:11] <abaumann> not to mention that every build step takes very long as the compiler is SLOW...
[09:04:22] <deep42thought> oh, I thought, it was only my box ...
[09:06:22] <abaumann> ..no, things fail in my part of the universe too.. ;-)
[09:06:39] <deep42thought> ... and they fail slowly at your location, too :-D
[09:06:47] <abaumann> true :-)
[09:26:27] <bill-auger> debian has rust i386 1.34 in main and 1.36 in unstable so there must be a way - maybe iu will look at their patches tomorrow
[09:29:09] <abaumann> oi: new glib introduced some format forifictaion for fprintf-style functions, this break tests en masse..
[09:33:42] <abaumann> the root cause in libidn is a failure around creating threads..
[10:08:05] <deep42thought> debian patched rust to build from local sources
[10:08:17] <deep42thought> this sounds like it could be useful for us, too
[10:08:47] <deep42thought> though, I find it amusing, that something like that needs to be patched by distributions :-D
[10:20:19] -!- thePiGrepper has quit [Ping timeout: 248 seconds]
[10:23:11] <bill-auger> i find it amusing that it can not bootstrap itself from one version to the very next
[10:23:21] <deep42thought> yes, that too
[10:23:56] <deep42thought> but it's also annoying, that it's so hard to patch something, because the whole build is literally only running "python ./x.py" which downloads and bootstraps everything as far as i can tell ...
[10:33:47] <abaumann> tyzoid-srv0-vm486 is completly borked. I think, I have to set it up anew..
[10:33:55] <deep42thought> :-(
[10:33:57] <deep42thought> how so?
[10:34:09] <abaumann> broken keyring
[10:34:18] <abaumann> git gc sometimes takes hours to complete
[10:34:29] <abaumann> git clone dito
[10:34:42] <deep42thought> check out bin/clean-git
[10:34:53] <deep42thought> it re-clones your git repos
[10:35:01] <abaumann> ah right
[10:35:52] <abaumann> and redo the keyring of the build user
[10:36:14] <abaumann> but I'm afraid some software got a SKS attack and as soon as we autofetch the key, we end up in the same mess again
[10:36:47] <deep42thought> just remove keyserver entries from gpg.conf
[10:36:55] <deep42thought> or put keys.gnupg.net there
[10:37:08] <deep42thought> (and watch builds failing due to not-auto-fetching keys)
[10:41:47] -!- deep42thought has quit [Ping timeout: 258 seconds]
[10:44:45] -!- deep42thought has joined #archlinux32
[10:44:45] <buildmaster> Hi deep42thought!
[10:44:46] <buildmaster> !rq deep42thought
[10:44:47] <phrik> buildmaster: <deep42thought> doesn't one usually try to avoid rust on metals?
[11:47:26] <abaumann> clean-git reclones bare repos..
[11:47:32] <deep42thought> yes
[11:47:39] <deep42thought> yours aren't bare?
[11:47:43] <abaumann> usually not
[11:47:50] <abaumann> because I also use it to check for things
[11:47:55] <deep42thought> hmm
[11:48:03] <abaumann> and I use packages32 directly to check in and test things
[11:48:07] <abaumann> but that's me :-)
[11:48:18] <deep42thought> that's fine
[11:48:25] <deep42thought> it should run a normal "git gc", then
[11:48:31] <deep42thought> but that tends to become slow :-/
[11:48:35] <abaumann> yes. that's waht I'm usually doing.
[11:48:39] <abaumann> exactly.
[11:49:11] <abaumann> I'm actually quite shocked how inefficient git is.
[11:49:51] <deep42thought> it seems to produce a huge trail of left-overs ...
[11:50:07] <abaumann> yeah, exactly
[11:51:07] <deep42thought> suggestion: use bare repos and clone *those* locally into a non-bare repo
[11:51:18] <abaumann> yeah. that's what I did. :-)
[11:51:26] <deep42thought> you can then easily dispose the non-bares and reclone
[11:51:48] <deep42thought> but let the builder use the bare repos
[11:52:02] <abaumann> It seems to work on both though
[11:52:08] <deep42thought> yes
[11:52:12] <abaumann> tyzoid-srv0-vm486 is up and running again (I hope)
[11:52:12] <deep42thought> I have non-bare over here, too
[11:52:20] <deep42thought> for pretty much the same reasons as yours :-)
[11:52:39] <deep42thought> you can still manually re-clone the non-bare repos
[11:52:54] <deep42thought> it's merely a safety-feature to not accidentally erase my repos here :-)
[11:54:24] <abaumann> I'll experiment with a new 486 build slave on eurobuild6..
[11:54:28] <abaumann> ..but after lunch :-)
[11:54:42] <deep42thought> enjoy!
[11:54:48] <abaumann> likewise! :-)
[12:01:01] -!- deep42thought has quit [Quit: Leaving.]
[13:51:13] -!- pulec has joined #archlinux32
[14:18:16] -!- infides has joined #archlinux32
[14:30:58] -!- infides has quit [Ping timeout: 246 seconds]
[15:27:50] -!- ofara has quit [Quit: ofara]
[15:28:08] -!- ofara_ has quit [Quit: ofara_]
[15:29:48] -!- ofara has joined #archlinux32
[15:30:59] -!- ofara_ has joined #archlinux32
[15:43:59] -!- thePiGrepper has joined #archlinux32
[16:33:26] <abaumann> eurobuild6-7-i486 is alive :-)
[16:33:39] <abaumann> I updated also mysql on the buildmaster, everything seems fine.
[17:02:57] -!- infides has joined #archlinux32
[17:15:10] <buildmaster> pentium4/binaryen is broken (says eurobuild6-4): https://archlinux32.org
[17:28:04] -!- infides has quit [Ping timeout: 272 seconds]
[17:31:17] <buildmaster> i686/ripgrep is broken (says eurobuild6-5): https://archlinux32.org
[17:34:57] <buildmaster> i686/binaryen is broken (says eurobuild6-1): https://archlinux32.org
[17:38:14] -!- abaumann has quit [Quit: leaving]
[17:44:03] -!- davor has quit [Ping timeout: 244 seconds]
[17:47:18] -!- davor has joined #archlinux32
[18:15:31] -!- thePiGrepper has quit [Ping timeout: 248 seconds]
[18:36:08] -!- thePiGrepper has joined #archlinux32
[18:48:19] -!- DepositePirate has quit [Remote host closed the connection]
[18:48:46] -!- DepositePirate has joined #archlinux32
[19:29:01] -!- isacdaavid has joined #archlinux32
[19:29:38] -!- thePiGrepper has quit [Ping timeout: 245 seconds]
[19:35:03] -!- abaumann has joined #archlinux32
[19:35:04] <buildmaster> Hi abaumann!
[19:35:04] <buildmaster> !rq abaumann
[19:35:05] <phrik> buildmaster: <abaumann> * abaumann looks at his hands.. counts them.. shakes his head and sighs about the fact he cannot grow some more..
[19:35:07] <abaumann> mmh. puzzling.
[19:35:15] <abaumann> I seem to fail to start a gdb inside an arch-chroot
[19:35:32] <abaumann> all I'm getting is 'Warning: Cannot insert breakpoint 1. Cannot access memory at address 0xcdb5'
[19:35:46] <abaumann> and gdb drops to the shell in Stopped state
[19:35:50] <abaumann> this is sort of quite unusable..
[19:38:15] <abaumann> happens also outside of the chroot. O well, this might be some libseccomp trickery..
[19:39:11] <abaumann> this makes debugging failing libseccomp bugs so much easier. :->
[19:42:34] <abaumann> ..back to good old fprintf debugging..
[19:55:23] -!- MrBIOS has joined #archlinux32
[20:14:34] <DCyrax> abaumann : does setting sysctl variable kernel.yama.ptrace_scope to zero (0) help?
[20:15:56] <abaumann> against the gdb issue? no.
[20:16:09] <abaumann> no problem. printf is your friend in this case :-)
[20:16:35] <abaumann> I found a libseccomp problem for IRC calls like shmget in libseccomp.
[20:16:38] <abaumann> reported upstream
[20:16:48] <abaumann> https://github.com
[20:16:49] <phrik> Title: test failures on 32-bit x86 in 36-sim-ipc_syscalls and 37-sim-ipc_syscalls_be · Issue #166 · seccomp/libseccomp · GitHub (at github.com)
[21:00:35] -!- abaumann has quit [Quit: leaving]
[21:32:47] -!- thePiGrepper has joined #archlinux32
[22:56:38] -!- DCyrax has quit [Ping timeout: 258 seconds]