#archlinux32 | Logs for 2019-07-18
Back
[00:19:15] -!- slacka123 has quit [Ping timeout: 264 seconds]
[00:36:51] -!- slacka123 has joined #archlinux32
[00:38:04] -!- samantaz has quit [Ping timeout: 246 seconds]
[00:40:12] -!- samantaz has joined #archlinux32
[01:16:02] <buildmaster> i686/bbswitch is broken (says eurobuild6-5): https://archlinux32.org
[01:16:29] <buildmaster> i686/broadcom-wl is broken (says eurobuild6-2): https://archlinux32.org
[01:18:22] <buildmaster> i686/acpi_call is broken (says eurobuild6-1): https://archlinux32.org
[01:20:22] -!- buildmaster has quit [Remote host closed the connection]
[01:20:35] -!- buildmaster has joined #archlinux32
[01:20:35] <buildmaster> !rq buildmaster
[01:20:36] <phrik> buildmaster: <buildmaster> I might be insane, but never confused ... ;-)
[01:25:11] <buildmaster> i686/nvidia-390xx is broken (says eurobuild6-1): https://archlinux32.org
[02:29:06] -!- isacdaavid has quit [Quit: Leaving.]
[04:14:56] -!- thePiGrepper has quit [Ping timeout: 258 seconds]
[04:24:58] -!- samantaz has quit [Read error: Connection reset by peer]
[04:57:14] -!- slacka123 has quit [Remote host closed the connection]
[04:58:09] -!- slacka123 has joined #archlinux32
[05:14:41] -!- thePiGrepper has joined #archlinux32
[05:14:49] -!- thePiGrepper has quit [Client Quit]
[05:35:42] -!- slacka123 has quit [Remote host closed the connection]
[05:36:24] -!- slacka123 has joined #archlinux32
[06:53:17] -!- titus_livius has joined #archlinux32
[06:57:35] <girls> We might/will need to publish our packager keys via WKD: https://lists.archlinux.org
[06:57:36] <phrik> Title: [pacman-dev] [PATCH 3/5] sync: lookup missing keys in the WKD using the packager email (at lists.archlinux.org)
[07:01:55] <girls> it might be as easy as setting up some aliases on archlinux32.org - or eckner.net :-D
[08:11:54] <elibrokeit> girls: honestly I strongly believe gnupg should just continue to sanely handle this via keyservers
[08:12:16] <elibrokeit> And certainly, on an application level it should be the fallback.
[08:20:36] -!- abaumann has joined #archlinux32
[08:20:48] -!- abaumann has parted #archlinux32
[08:20:59] -!- abaumann has joined #archlinux32
[08:21:19] -!- buildmaster has quit [Remote host closed the connection]
[08:23:59] -!- buildmaster has joined #archlinux32
[08:23:59] <buildmaster> !rq buildmaster
[08:24:00] <phrik> buildmaster: <buildmaster> I might be insane, but never confused ... ;-)
[08:28:57] <abaumann> buildmaster: welcome back :-)
[08:30:16] <abaumann> deep42thought: on the buildmaster: warning: archlinux32-keyring: local (20190108-1.0) is newer than archlinuxewe (20190108-1)
[08:31:30] <abaumann> 6147 packages rescheduled? that looks like a complete rebuild..
[08:32:17] <abaumann> mmh. buildmaster load increased significantly since this early morning..
[08:45:46] -!- deep42thought has joined #archlinux32
[08:45:46] <buildmaster> Hi deep42thought!
[08:45:46] <buildmaster> !rq deep42thought
[08:45:47] <phrik> buildmaster: <deep42thought> db-update --fuck-up
[08:45:51] <deep42thought> good morning, abaumann
[08:47:09] <deep42thought> I'm not sure how the package with sub_pkgrel entered the buildmaster
[08:47:17] <deep42thought> those should only appear on archlinux32 ...
[08:48:11] <deep42thought> let's have a look into the command log to see who rescheduled all that stuff :-)
[08:49:14] <deep42thought> nothing manually scheduled - I force-moved some gnome stuff
[08:49:17] <deep42thought> but no reschedules
[08:52:42] <deep42thought> 1.2 k fresh packages and 3.9k reschedules
[08:52:48] <deep42thought> this looks wrong somehow
[08:53:22] <abaumann> hi deep42thought
[08:54:05] <abaumann> well, maybe not a bad thing given those GLIBC symbol errors in some packages (trojita).
[08:54:14] <deep42thought> :-)
[08:54:30] <deep42thought> I had a "nice" glibc issue on crux yesterday: gethostid() segfaulted
[08:54:38] <abaumann> huh?
[08:54:44] <elibrokeit> interesting, how come?
[08:54:48] <deep42thought> no ide
[08:54:49] <deep42thought> a
[08:55:00] <deep42thought> I put my hostname into /etc/hosts and it solved the issue
[08:55:12] <abaumann> mmh. this sounds very wrong in so many ways :-)
[08:55:13] <deep42thought> I could alternatively add 8.8.8.8 in /etc/resolv.conf and it worked, too
[08:55:28] <deep42thought> abaumann: this is exactly, what I thought about the issue
[08:55:40] <abaumann> :-)
[08:56:06] * buildmaster goes insane.
[08:56:15] <deep42thought> buildmaster: I dare you!
[08:56:20] <abaumann> alas :-)
[08:57:21] <deep42thought> ERROR 1053 (08S01) at line 3: Server shutdown in progress
[08:57:22] <deep42thought> ??
[08:57:33] <abaumann> oeh. in mysql?
[08:57:37] <deep42thought> yes
[08:57:49] <abaumann> that's another software I utterly distrust. :->
[08:58:27] <abaumann> is a mysqldump running?
[08:58:40] <abaumann> no.
[08:58:43] <deep42thought> no
[08:58:53] <abaumann> but a backup in /data/bakcup failed
[08:58:59] <abaumann> -rw-r--r-- 1 root root 32 Jul 18 08:23 database-2019-07-18-08:23:42.xz
[08:59:02] <abaumann> -rw-r--r-- 1 root root 32 Jul 18 08:23 database-2019-07-18-08:23:43.xz
[08:59:09] <abaumann> why was it started twice?!
[08:59:16] <abaumann> systemd trickery?
[08:59:19] <deep42thought> probably
[08:59:29] <abaumann> if fail -> try again (hard)
[08:59:56] <deep42thought> !grab abaumann
[08:59:57] <phrik> deep42thought: Tada!
[09:00:19] <deep42thought> or rather `while fail: try again (hard)`
[09:00:23] <abaumann> Type=oneshot
[09:00:25] <abaumann> Restart=no
[09:00:42] <abaumann> ..speaking of software I utterly distrust..
[09:00:56] <deep42thought> :-D
[09:01:06] <deep42thought> is there software you do _not_ utterly distrust?
[09:01:08] <deep42thought> ;-)
[09:01:23] <abaumann> that's actually a good question.. :)
[09:01:26] <deep42thought> maybe the corresponding timer kicks it off again?
[09:01:38] <elibrokeit> I'm pretty fond of pacman...
[09:01:44] <abaumann> :-)
[09:08:06] * buildmaster resumes sanity.
[09:09:20] <abaumann> \o/
[09:11:12] <deep42thought> ah, in case you're interested in glibc: here is the strace https://eckner.net of that simple test program https://eckner.net
[09:14:05] <deep42thought> having a valid hostname seems crucial nowadays - I wanted to reproduce the issue here, but I'M UNABLE TO OPEN A TERMINAL when I have set my hostname to "bogus" ....
[09:14:28] <abaumann> "always connected anti-pattern" :-)
[09:14:34] <deep42thought> $ urxvt
[09:14:35] <deep42thought> No protocol specified
[09:14:35] <deep42thought> urxvt: can't open display :0.0, aborting.
[09:14:40] <deep42thought> hmmmmm
[09:15:23] <deep42thought> I'll just use a SEP-field for now
[09:16:00] <abaumann> interesting, the segfault happens after it got the IP via DNS
[09:16:13] <deep42thought> no, .13 is the ip of the router
[09:16:18] <abaumann> ah.
[09:16:19] <deep42thought> it should not resolve my hostname
[09:16:47] <abaumann> could be a problem in nsswitch.conf
[09:16:53] <abaumann> not that it should segfault.. :-)
[09:17:04] <deep42thought> this is crux
[09:17:10] <deep42thought> the nsswitch is pretty flat
[09:17:20] * abaumann considers installing a virtual crux
[09:17:35] <deep42thought> it boils down to '$whatever: files'
[09:17:42] <deep42thought> and 'hosts: files dns'
[09:21:06] <elibrokeit> Your test program is reproducibly the very elucidative value: 8323329
[09:21:34] <deep42thought> it is a 0 vs 1 thing
[09:21:40] <deep42thought> either it segfaults or it doesn't
[09:21:55] <deep42thought> (and outputs a number, then)
[09:22:02] <elibrokeit> of course, one wonders why this broken function exists ever, ever, ever
[09:22:38] <abaumann> test: 671330
[09:22:44] <abaumann> hostid 000a3e62
[09:22:49] <abaumann> this looks correct
[09:23:08] <deep42thought> test: 596483122
[09:23:08] <deep42thought> hostid 238d9c32
[09:23:15] <deep42thought> (on archlinux, not crux :-D)
[09:23:30] <elibrokeit> https://lists.debian.org
[09:23:31] <phrik> Title: About hostid and ZFS (was Re: [Pkg-zfsonlinux-devel] ZFS on Linux and native ZFS on BSD) (at lists.debian.org)
[09:23:39] <deep42thought> also with bogus host
[09:23:45] <elibrokeit> > relying on gethostid in production code
[09:24:29] <elibrokeit> > So this invalidates the original purpose of gethostid(). Which was meant to be a value unique for each host, has turned into a value that is shared by most of the hosts.
[09:25:40] <abaumann> only good it got reimplemented in systemd as machine-id, which gets copied when cloning virtual machines, with bad effects :->
[09:26:01] <deep42thought> "refusing to link journals" :-D
[09:27:01] <abaumann> mmh. no crux for 32-bit? ;-)
[09:27:09] <deep42thought> not officially
[09:27:15] <abaumann> hehe :-)
[09:27:15] <elibrokeit> well, cloning VMs seems like the sort of thing which should not contain instance-specific data...
[09:27:23] <deep42thought> it's a source distribution - you can try to compile it on ia32 if you like
[09:27:24] <elibrokeit> this is what e.g. systemd-firstboot is for
[09:28:00] <abaumann> yeah. how does it know, it's the first time to boot up? :->
[09:28:20] <elibrokeit> because it doesn't have a machine-id when booting from a golden image?
[09:28:38] <abaumann> so, after building a gold image you have to remove the machine-id.
[09:28:40] <abaumann> ok.
[09:28:54] <abaumann> or delete it after cloning,use systemd-machine-id-setup to create a new one
[09:29:14] <abaumann> I'm just pointing out, something unnecessary was added which now needs attention.
[09:29:21] <abaumann> hostid was working automatically for eons.
[09:29:38] <elibrokeit> hostid was pretending to work for eons
[09:29:53] <abaumann> using the ip is maybe not the smartest idea. :->
[09:29:53] <elibrokeit> hostid is just as identical across many machines except moreso :p
[09:30:02] <abaumann> a mac (for a machine with a nic) is more stable
[09:30:37] <abaumann> fun fact: we used gethostid for a license mechanism in a piece of software..
[09:30:39] <elibrokeit> > However, most of times the hostid of the machine will be 007f0101 because the IP address of $(hostname) on Debian systems is typically 127.0.1.1
[09:30:42] <deep42thought> looks like systemd-firstboot almost serves as an install helper :-)
[09:30:47] <abaumann> .. turned out to be _extremly_ secure :-)
[09:31:03] <elibrokeit> in fact, Arch's install guide also tells you to explicitly set this hostname IP
[09:31:11] <abaumann> true.
[09:31:14] <abaumann> good thing
[09:31:38] <elibrokeit> > If the system has a permanent IP address, it should be used instead of 127.0.1.1.
[09:31:54] <elibrokeit> but who has a permanent IP? Not my laptop...
[09:32:03] <deep42thought> on a lan, I have
[09:32:05] <abaumann> it could use systemd machine-id
[09:32:15] <abaumann> just a thought :->
[09:32:18] <elibrokeit> the only people who use gethostip is zfs pools and software license checks
[09:32:36] * abaumann hums a merry tune
[09:32:39] <deep42thought> alpine uses it, too
[09:32:39] <elibrokeit> machine-id isn't portable to bsd, so zfs won't switch :/
[09:32:49] <elibrokeit> alpine uses it to what
[09:32:54] <deep42thought> dunno
[09:32:58] <deep42thought> send emails :-/
[09:33:05] <elibrokeit> they create it, or they use it?
[09:33:07] <deep42thought> at least, that's the part, where it crashed
[09:33:10] <deep42thought> they use it
[09:33:20] <elibrokeit> or a given software uses it?
[09:33:30] <deep42thought> alpine, the mailer
[09:34:06] <elibrokeit> well, a mail program is probably trying to embed the IP address of the sender, so it actually makes sense to lookup the IP address.
[09:34:20] <deep42thought> via hostid???
[09:34:29] <abaumann> that's a long story how mailers set a unique message id
[09:34:42] <elibrokeit> seems like a roundabout way to do it, sure...
[09:35:49] <deep42thought> abaumann: harvest-commit-times might have impacted i/o
[09:36:00] <abaumann> crux install procedure strangely reminds me of Archlinux's way.
[09:36:00] <elibrokeit> gosh, it's too bad alpine cannot use uuid@domain.com
[09:36:01] <abaumann> ah.
[09:36:25] <deep42thought> it scrubs through git - which can take some time for many packages
[09:36:57] <elibrokeit> (alpine is also a linux distro, pardon my confusion)
[09:37:26] <deep42thought> yes, I noticed - np, I think, the distro is more popular than the mailer ;-)
[09:38:01] <abaumann> crux still has a dialog-style setup..
[09:38:08] <deep42thought> yes
[09:38:13] <abaumann> was wrong here, just fdisk and mount is outside setup
[09:38:42] <deep42thought> though it's still much manual stuff
[09:38:54] <deep42thought> "cd /usr/src/linux-4.9" and build your kernel
[09:39:42] <abaumann> -rw-r--r-- 1 root root 40061928 Jul 18 09:28 database-2019-07-18-09:23:19.xz
[09:39:50] <abaumann> the last backup on the buildmaster was ok
[09:40:02] <deep42thought> good
[09:41:09] <deep42thought> elibrokeit: how does makepkg and $SRCDEST cooperate with git repository sources?
[09:41:28] <deep42thought> it looks, like it replicates the repo, but does not use it as upstream
[10:20:38] <abaumann> ssh: connect to host buildmaster.archlinux32.org port 22: Connection refused
[10:20:41] <abaumann> ERROR: Unknown exit code 255 from 'get-assignment'.
[10:20:49] <deep42thought> O.o
[10:20:59] <deep42thought> I can connect
[10:20:59] <abaumann> I admit, I reboot once the buildmaster
[10:21:10] <abaumann> just some slaves where in that state
[10:21:13] <abaumann> others not
[10:21:35] <deep42thought> so we should tread 255 as a temporary error?
[10:22:29] <abaumann> 255 == exit code out of range
[10:22:42] <deep42thought> :-)
[10:22:49] <abaumann> so actually there is an exit somewhere with exit_code>255
[10:24:07] <abaumann> naeh. actually, it's mayebe better the script stops then
[10:24:22] <deep42thought> why?
[10:24:41] <deep42thought> imagine, you built gcc for 16 hours and when returning the package, the ssh connection dies ...
[10:24:44] <abaumann> we can not be sure it's temporary
[10:24:48] <abaumann> ah.
[10:24:57] <deep42thought> hmm
[10:25:17] <abaumann> it may be caused when the machine is not around, but who knows
[10:25:26] <deep42thought> hmm
[10:25:31] <deep42thought> also a valid point
[10:55:24] <deep42thought> great, our i486 build slaves build "any" packages currently - like they had nothing better to do ...
[11:04:29] <abaumann> a
[11:04:37] <abaumann> aren't those the fastest slaves? ;-)
[11:04:50] <deep42thought> and the most abundand ones ...
[11:04:54] <abaumann> :-)
[11:05:55] <abaumann> gcc and binutils are currently blocking the i686 and pentium4 slaves..
[11:06:10] <abaumann> ..so the i486 ones are the only ones allowed to build i486 or any packages.
[11:06:16] <abaumann> quite explainable, I think.
[11:07:34] <deep42thought> yes, but why is gcc/binutils not blocking i486?
[11:08:32] <abaumann> it has not been scheduled yet?
[11:08:51] <abaumann> the theory that it is already done for i486, is quite unlikely ;-)
[11:08:58] <deep42thought> it's quite elaborate to (re)schedule something for i686 and pentium4 but not i486
[11:09:43] <deep42thought> gcc /is/ sheduled for i486
[11:09:49] <deep42thought> as is binutils
[11:10:00] <abaumann> mmh
[11:12:00] <deep42thought> for whatever reason, gcc is not considered "buildable" on i486 ...
[11:13:15] <abaumann> interesting
[11:14:21] <deep42thought> oh, wait
[11:14:41] <deep42thought> gcc ended up on the deletion list
[11:15:03] <deep42thought> (I only checked for checksum==NULL, which may be true on the deletion-list, too)
[11:15:44] <deep42thought> it is there since 2019-07-18 04:36:51
[11:16:24] -!- DepositePirate has quit [Ping timeout: 260 seconds]
[11:19:33] <deep42thought> this might be due to partially blacklisting gcc splitters
[11:19:34] -!- DepositePirate has joined #archlinux32
[11:19:41] <deep42thought> e.g. gcc-ada IIRC
[11:19:55] <abaumann> yeah, but those cannot be easily bootstrapped..
[11:20:00] <deep42thought> yes
[11:20:17] <deep42thought> it's rather a data-format problem than a you-must-bootstrap-that-now problem
[11:20:24] <abaumann> ah. :-)
[11:22:48] <deep42thought> probably seed-build-list falsely inserted that package part and the blacklist logic afterwards (rightly) blacklisted it and thus all of gcc ...
[11:22:53] <deep42thought> I don't really know
[11:23:10] * deep42thought fixes it manually
[11:24:15] <deep42thought> err, there _is_ a gcc-ada for i486 (at least in the database)
[11:24:23] <abaumann> oeh. :-)
[11:24:30] <deep42thought> ah, it's a dummy package
[11:24:35] <abaumann> if, then it is a vastly empty package. :-)
[11:24:47] <deep42thought> exactly, because I was too lazy to correctly handle that case in the database
[11:25:14] <deep42thought> so: nothing left to fix manually ;-)
[11:25:26] <abaumann> :-)
[13:10:00] <abaumann> the old buildmaster is now on the new buildmaster as /data/old_buildmaster..
[13:12:48] <deep42thought> for full recursion, you should also mount the new buildmaster on the old
[13:13:42] <deep42thought> ah, this is not a mount, but a copy :-)
[13:14:21] <abaumann> yes. :-)
[13:15:17] * abaumann shudders when thinking about cross-sshfs-mounted servers..
[13:15:27] <deep42thought> I do this all the time
[13:15:36] <deep42thought> well, for some stuff we use nfs ...
[13:15:57] <abaumann> host a waits for b, b waits for a :-)
[13:21:02] <deep42thought> abaumann: you know my setup! a has its disk encryption key on b and b has its encryption key on a - and the topping: it all rests on dhcp which can only be manually accessed from a or b (in case of failure)
[13:22:48] <abaumann> mmh. funny. systemd-networkd says 'ens3: invalid argument' because the network interface is down. You have to set it manually with 'ifconfig ens3 up'..
[13:22:56] <abaumann> ..I saw a bug in our forum about the same issue.
[13:23:32] <abaumann> this doesn't make any sense: the very purpose of systemd-networkd is to start up a network, it's supposed to be down initially..
[13:23:56] * deep42thought uses netctl
[13:25:21] * abaumann uses systemd-networkd only on test machines, not for production
[13:27:47] * abaumann is wrong regarding the buildmaster.. it runs systemd-networkd
[13:27:56] <deep42thought> :-D
[13:28:07] <abaumann> it croaks about missing netmask prefix length
[13:29:24] <abaumann> mmh. does /32 and /64 for IPv4 and IPv6 sound reasonable for Hetzner?
[13:29:36] <deep42thought> yes
[13:30:29] <abaumann> yeah. the gateway says likewise in 'ip addr'
[13:40:12] <abaumann> https://bbs.archlinux32.org
[13:40:14] <phrik> Title: Network does not start at boot with 5.2.1 kernel / Servers & Networking / Arch Linux 32 Forums (at bbs.archlinux32.org)
[13:40:27] <abaumann> I really start to get fed up with the quality of systemd and Linux
[13:40:48] <abaumann> independent groups not talking to each other and updating code faster than it can possibly break.
[13:41:19] <deep42thought> this is an issue on x86_64, too, isn't it?
[13:41:26] <abaumann> didn't test yet.
[13:41:35] <deep42thought> I thought, it happened on the buildmaster, too?
[13:41:45] <abaumann> if it appears only on 32-bit, then congrats to the developers, how they managed that :->
[13:41:54] <deep42thought> :-D
[13:41:59] <abaumann> should I reboot? ;-)
[13:42:03] <deep42thought> better not
[13:42:05] <abaumann> :-)
[13:43:37] <abaumann> yeah. on my 64-bit laptop it works.. I'm using netctl :-)
[13:44:19] <abaumann> and eurobuild1 also uses netctl
[13:44:39] <abaumann> eurobuild6 should be affected
[13:46:16] * abaumann is preparing a 64-bit archlinux test machine
[13:48:36] <abaumann> huh. now I have a test machine with kernel 5.1.15 showing the same behaviour!?
[13:49:38] <abaumann> a there I see a ens3: Invalid argument and then later a ens3: Configured
[13:49:47] <abaumann> some magical correction code or what..
[13:51:09] <abaumann> 5.1.16 shows a more correct behaviour.
[13:51:33] <abaumann> sometimes I really doubt 5.x.x kernels should be considered stable
[13:53:24] * abaumann is way above his daily portion of ranting
[13:53:50] <deep42thought> :-D
[14:11:52] -!- thePiGrepper has joined #archlinux32
[14:27:50] -!- deep42thought has quit [Quit: Leaving.]
[14:40:53] -!- abaumann has quit [Quit: leaving]
[15:24:13] <buildmaster> pentium4/libunistring is broken (says eurobuild6-3): https://archlinux32.org
[15:24:28] <buildmaster> pentium4/libgudev is broken (says eurobuild6-2): https://archlinux32.org
[15:24:29] <buildmaster> pentium4/libtasn1 is broken (says eurobuild6-4): https://archlinux32.org
[15:25:29] <buildmaster> pentium4/attr is broken (says eurobuild6-1): https://archlinux32.org
[15:29:34] <buildmaster> pentium4/popt is broken (says eurobuild6-1): https://archlinux32.org
[15:31:24] <buildmaster> pentium4/menu-cache is broken (says eurobuild6-6): https://archlinux32.org
[15:50:52] <buildmaster> pentium4/mdadm is broken (says eurobuild6-5): https://archlinux32.org
[15:51:39] -!- thePiGrepper has quit [Ping timeout: 244 seconds]
[15:54:42] <buildmaster> pentium4/elfutils are broken (says nlopc46): https://archlinux32.org
[15:55:34] <buildmaster> pentium4/poppler is broken (says eurobuild6-5): https://archlinux32.org
[15:57:18] <buildmaster> pentium4/cups-filters are broken (says eurobuild6-2): https://archlinux32.org
[15:57:55] <buildmaster> pentium4/libseccomp is broken (says eurobuild6-1): https://archlinux32.org
[15:59:55] -!- buildmaster has quit [Remote host closed the connection]
[16:00:07] -!- buildmaster has joined #archlinux32
[16:00:07] <buildmaster> !rq buildmaster
[16:00:08] <phrik> buildmaster: <buildmaster> I might be insane, but never confused ... ;-)
[17:08:38] -!- thePiGrepper has joined #archlinux32
[17:27:15] -!- abaumann has joined #archlinux32
[17:27:15] <buildmaster> Hi abaumann!
[17:27:15] <buildmaster> !rq abaumann
[17:27:17] <phrik> buildmaster: <abaumann> "Santa Claus brings you bells and presents.. and bugs"
[17:27:54] <abaumann> deep42thought: there is now a munin graph for combined buildmaster behaviour: https://buildmaster.archlinux32.org
[17:27:55] <phrik> Title: Munin :: buildmaster :: buildmaster :: buildmaster combined (at buildmaster.archlinux32.org)
[17:30:58] -!- abaumann has quit [Client Quit]
[18:13:16] -!- ofara has quit [Ping timeout: 258 seconds]
[18:14:50] -!- ofara has joined #archlinux32
[19:45:19] -!- Mindi has quit [Ping timeout: 276 seconds]
[19:51:31] -!- Mindi has joined #archlinux32
[19:53:48] -!- samantaz has joined #archlinux32
[19:56:57] -!- slacka123 has quit [Remote host closed the connection]
[19:57:52] -!- slacka123 has joined #archlinux32
[20:00:17] -!- deep42thought has joined #archlinux32
[20:00:18] <buildmaster> Hi deep42thought!
[20:00:18] <buildmaster> !rq deep42thought
[20:00:19] <phrik> buildmaster: <deep42thought> good software is like a good meal: you cannot expect to get something really good if it's done in 5 minutes ...
[20:00:41] <deep42thought> abaumann: nice :-) these are count and times per day and week - as the others - I assume?
[20:14:31] -!- abaumann has joined #archlinux32
[20:14:31] <buildmaster> Hi abaumann!
[20:14:32] <buildmaster> !rq abaumann
[20:14:34] <phrik> buildmaster: <abaumann> doesn't ## uncomment the #? ;-)
[20:14:36] <deep42thought> Hi abaumann!
[20:14:37] <abaumann> deep42thought: yeah, roughly.
[20:14:40] <abaumann> hi deep42thought
[20:15:01] <abaumann> number of process times their runtime, (actually thinking about it, adding them would make more sense)
[20:15:23] <abaumann> your slave graph on the main page is unbeatable :-)
[20:15:29] <deep42thought> :-D
[20:15:53] <abaumann> you can see nicely some tendency for better buildmaster performance..
[20:15:53] <deep42thought> well, it's an unfair competition: I pull my data right from slave-build-connect
[21:02:24] <abaumann> https://archlinux32.org shows almost no slaves running, I see many of my slaves waiting in get-assignment
[21:02:27] <phrik> Title: Arch Linux 32 - List of Build Slaves (at archlinux32.org)
[21:02:35] <abaumann> this is not a lock starvation issue, I hope?
[21:05:56] <abaumann> mmh. I hoped changing the sort_area_size would improve things a little bit.
[21:06:09] <abaumann> still mysql has a little bit too much CPU for my taste
[21:07:49] <deep42thought> but the total time for get-assignment is not drastically high
[21:08:45] <abaumann> that's true
[21:08:54] <abaumann> but it looks like something is always winning.
[21:09:13] <abaumann> normally you would remember slaves or pids waiting on the lock in a queue
[21:09:32] * abaumann remember similar discussions, but doesn't remember the result of those discussions :-)
[21:09:40] <abaumann> *remembers
[21:10:08] <abaumann> come back after the next run of get-package-updates - currently there are no pending packages
[21:10:09] <deep42thought> they should all come back after $constant + $random seconds
[21:10:12] <deep42thought> so it should be fair
[21:10:14] <abaumann> yep.
[21:10:19] <deep42thought> errr
[21:10:25] <deep42thought> this is a flaw in some logic :-(
[21:10:38] <abaumann> 6000 packages on the build list, no toochain related package building.
[21:10:45] <abaumann> this sounds rather weird
[21:11:53] <abaumann> there is a chance the constant + random is too low for the number of slaves..
[21:13:10] <deep42thought> 15 + [0..30] seconds
[21:13:32] <deep42thought> why should this be an issue?
[21:14:09] <abaumann> not in terms of fairness, just in terms of efficiency as too many scripts can run then.
[21:14:16] <abaumann> but I doubt this is a big problem
[21:15:07] <abaumann> mmh always one mysql thread, are we row or table locking?
[21:15:37] * abaumann remembers some different implementations in the storage of the mysqldb data, a silly one (table locking) and a better one (row locking)
[21:18:00] <deep42thought> i686/binutils might be able to block all of i686
[21:18:03] <deep42thought> so that part is ok
[21:18:17] <deep42thought> maybe I should improve the error message
[21:18:30] <abaumann> ah. didn't see, so it also blocks pentium4
[21:18:37] <deep42thought> it should not
[21:18:48] <abaumann> yeah. there is a pentium4/mdadm
[21:18:58] <abaumann> pentium4/virtualbox, pentium4/virtualbox-modules-arch, so no
[21:18:58] <deep42thought> pentium4: mdadm, virtualbox, virtualbox-modules-arch currently building
[21:19:06] <abaumann> exactly :-)
[21:19:12] <deep42thought> these should not block /that/many/ packages ...
[21:19:20] <deep42thought> 504 Gateway Time-out
[21:19:21] <deep42thought> *grrrr*
[21:19:36] <deep42thought> who wrote that stupid complex mysql queries?
[21:20:18] <abaumann> it's not only the complexity. If we have table locking, basically every query queues after the next one
[21:20:30] <deep42thought> I think, we have that
[21:20:35] <deep42thought> but I don't really know
[21:21:05] <abaumann> it's also not that easy to find out what we currently have :->
[21:21:11] <deep42thought> we could drop all the file locks (on get-assignment and those) to have mysql queries run more concurrently
[21:21:31] <deep42thought> but we have those for a reason :-D
[21:21:34] <abaumann> would they be consistent?
[21:21:39] <abaumann> yeah
[21:21:41] <abaumann> :-)
[21:22:06] <abaumann> "MySQL uses table locking (instead of row locking or column locking) on all table types, except InnoDB and BDB tables, to achieve a very high lock speed."
[21:22:17] <abaumann> I have some really serious doubts..
[21:22:58] <deep42thought> we have innodb iirc
[21:23:31] <deep42thought> the problem is, that the queries are actually not parallelizable from an abstract point of view
[21:23:46] <abaumann> true. because you need a consistent view.
[21:23:49] <deep42thought> what do you expect if multiple build slaves ask simultanously for build assignments
[21:23:54] <deep42thought> yes
[21:24:02] <abaumann> yeah, classic ticket-selling-problem
[21:24:06] <abaumann> you make quorums
[21:24:26] <abaumann> build slaves get tasks toint(base64(package)) % build_slaves
[21:24:30] <abaumann> or something like that.
[21:24:38] <abaumann> basically a reservation scheme
[21:25:01] <abaumann> but you get into trouble if you add or remove slaves (in this case you have to have a lock)
[21:25:12] <deep42thought> yeah, we could calculate all buildable packages and hand them out randomly
[21:25:19] <deep42thought> this would be parallelizable
[21:25:36] <deep42thought> you also get into trouble as soon as your conditions change
[21:25:40] <deep42thought> e.g. a package is returned
[21:25:59] <abaumann> yep.
[21:26:36] <deep42thought> you could lock on _that_ however
[21:26:59] <deep42thought> you actually _have_ to lock on it, because we cannot edit the *.db.tar.gz simultanously
[21:27:21] <abaumann> this format is a problem as it needs a lot of changes and its not incremental.
[21:27:46] <deep42thought> how so?
[21:27:57] <deep42thought> we could have a table that holds "buildable packages"
[21:28:10] <deep42thought> (we actually _have_ that - but it's temporarily)
[21:28:21] <deep42thought> and then update that table not on each invocation of get-assignment
[21:28:26] <abaumann> the problem is pacman expects the whole community.db.tar.gz
[21:28:31] <deep42thought> but on each invocation of return-assignment and get-package-updates
[21:28:31] <abaumann> just because one package changed.
[21:28:42] <deep42thought> ah, that part you mean
[21:28:43] <deep42thought> yes
[21:28:46] <abaumann> could be solved with two communit.tar.gz's
[21:28:56] <abaumann> a stable big one and a small volatile one.
[21:29:09] <abaumann> and then merge from time to time the small one into the big one (or just build a new big one)
[21:29:14] <deep42thought> or an on-the-fly tar-compressor
[21:29:25] <deep42thought> so we could edit the files in a normal file system >:-)
[21:29:25] <abaumann> but the handling is a little bit - well - cumbersome
[21:29:41] <abaumann> actually, tar could be uncompressed.
[21:29:45] <abaumann> then it's quite updateable.
[21:30:05] <abaumann> hah|
[21:30:07] <abaumann> now
[21:30:10] <deep42thought> ?
[21:30:17] <abaumann> a build slave of mine get a new assignment
[21:30:25] * abaumann celebrates the event ;-)
[21:30:48] <abaumann> and the package is.... mdadm
[21:30:50] <abaumann> :-)
[21:31:58] <deep42thought> mdadm fails to build
[21:32:07] <abaumann> oh..
[21:32:16] <deep42thought> https://archlinux32.org
[21:32:44] <abaumann> unaligned pointer value.. seriously
[21:32:49] <abaumann> who is maintaining mdadm?
[21:33:00] <abaumann> super-intel.c:696
[21:33:02] * abaumann coughs
[21:33:52] <abaumann> obviously somebody only testing on Intel 64-bit :-)
[21:34:13] * abaumann is way over his allowed rant level and quite tired..
[21:35:02] <abaumann> mmh. could also be a new gcc 9 feature
[21:37:58] <abaumann> ..tomorrow then :-)
[21:38:11] * abaumann leaves the channel in 'abaumann' fassion.. :-)
[21:38:13] -!- abaumann has quit [Quit: leaving]
[21:38:14] <deep42thought> good night!
[21:38:19] * deep42thought is too slow
[21:41:11] <elibrokeit> I'm not sure exactly how you handle assignments, but if a bottleneck is checking inside the repository *.db couldn't you do this on the server itself?
[21:41:33] <deep42thought> yes
[21:41:46] <deep42thought> I think, this is not the real bottleneck
[21:41:53] <deep42thought> concurring mysql queries is
[21:55:07] -!- deep42thought has quit [Quit: Leaving.]
[22:49:46] -!- isacdaavid has joined #archlinux32