#archlinux32 | Logs for 2018-06-13

Back
[00:19:24] <buildmaster> dbeaver is broken (says eurobuild3).
[00:33:43] <buildmaster> atom is broken (says nlopc46).
[00:35:19] <buildmaster> flashplugin is broken (says nlopc46).
[00:49:16] <buildmaster> ponyc is broken (says eurobuild3).
[01:12:50] <buildmaster> spring is broken (says tyzoid-srv0-bs0).
[01:15:59] -!- eschwartz[m] has quit [Remote host closed the connection]
[01:17:37] <buildmaster> embree is broken (says buildknecht).
[01:24:41] <buildmaster> libreoffice-still is broken (says eurobuild3).
[01:36:36] -!- eschwartz[m] has joined #archlinux32
[01:38:09] -!- bill-auger has quit [Remote host closed the connection]
[01:40:31] -!- bill-auger has joined #archlinux32
[01:57:35] <elibrokeit> git.archlinux32.org is super slow...
[01:57:37] <taiga> i'm puzzled. found out by accident that when i have 'Adwaita' icon theme active 'doublecmd' works but any other icon theme and it throws access violation
[01:57:49] <elibrokeit> https://git.archlinux32.org
[01:57:51] <phrik> Title:#1 - upgpkg: archlinux32-keyring-transition 20180603-1 - Archlinux32 Gitea (at git.archlinux32.org)
[01:57:55] <taiga> whyyy
[02:03:00] <buildmaster> mksh is broken (says nlopc46).
[02:20:25] -!- taiga has quit [Remote host closed the connection]
[02:34:23] <buildmaster> mysql-workbench is broken (says nlopc46).
[05:04:08] -!- jetfrog28 has joined #archlinux32
[05:15:36] -!- jetfrog28 has quit [Quit: WeeChat 2.1]
[05:20:33] <buildmaster> kitty is broken (says tyzoid-srv0-bs0).
[05:22:30] <buildmaster> teamspeak3 is broken (says eurobuild3).
[05:47:07] <buildmaster> libvirt-python is broken (says nlopc46).
[05:56:51] <buildmaster> deep42thought: Your buildslave "buildknecht3" builds some outdated package.
[06:17:37] <buildmaster> electron is broken (says nlopc46).
[06:33:55] -!- NoobAlice1 has quit [Quit: Leaving.]
[06:42:20] <buildmaster> girls, my database is dirty again ...
[06:43:04] <girls> buildmaster, sometimes you're just too fast for me
[06:56:10] * buildmaster resumes sanity.
[07:08:27] <buildmaster> mapnik is broken (says buildknecht).
[07:33:35] -!- eduardoeae has quit [Ping timeout: 245 seconds]
[08:03:29] -!- oaken-source has joined #archlinux32
[08:31:15] -!- deep42thought has joined #archlinux32
[08:31:16] <buildmaster> Hi deep42thought!
[09:35:00] <buildmaster> gcc7 is broken (says nlopc46).
[09:36:33] -!- oaken-source has quit [Ping timeout: 248 seconds]
[10:20:33] <buildmaster> virtualbox is broken (says nlopc46).
[10:33:52] -!- phrik has quit [Remote host closed the connection]
[10:34:06] -!- phrik has joined #archlinux32
[10:34:07] <buildmaster> Hi phrik!
[10:58:25] -!- AndrevS has joined #archlinux32
[11:50:24] -!- oaken-source has joined #archlinux32
[11:55:32] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.query.stdin.2018-06-13T11:55:32.MNoe9O"?.
[12:01:44] -!- eduardoeae has joined #archlinux32
[12:18:21] -!- eduardoeae has quit [Ping timeout: 268 seconds]
[12:29:21] -!- eduardoeae has joined #archlinux32
[12:57:40] <buildmaster> firefox-developer-edition is broken (says nlopc46).
[12:58:30] <deep42thought> ok, I just found out, why all the deepin-* stuff gets blacklisted: in the end, it depends on qcef which is not available for i686
[12:58:43] <deep42thought> so I'll just let it move on and delete all those packages when they're due
[13:02:18] -!- deep42thought has quit [Quit: Leaving.]
[13:36:28] -!- AndrevS has quit [Remote host closed the connection]
[13:57:09] <buildmaster> libfbclient is broken (says buildknecht).
[14:59:56] <tyzoid> abaumann: The server running your vm had a hard restart last night, so your i486 vm was ungracefully shutdown
[15:43:50] -!- deep42thought has joined #archlinux32
[15:43:50] <buildmaster> Hi deep42thought!
[15:43:57] <tyzoid> wb
[15:44:49] <deep42thought> Hi tyzoid
[15:45:02] <deep42thought> all good?
[15:45:26] <tyzoid> Mostly, yeah
[15:45:42] <tyzoid> been a bit of mayhem yesterday
[15:45:52] <tyzoid> but after some sleep, and after fires put out, better now
[15:46:19] <deep42thought> not long and we'll be below 1k packages on the build list again :-D
[15:47:36] <tyzoid> nice
[15:58:28] <tyzoid> deep42thought: Yeah, the high load avg on that server is actually from the build slave
[15:58:42] <deep42thought> ah, semi-ok :-)
[15:58:57] <tyzoid> some build are running with more jobs than available processing threads
[16:00:05] <tyzoid> but it's just an artificially high load average, since those processes are limited by the container's processing limit
[16:00:21] <deep42thought> ah, ok
[16:00:24] <deep42thought> so nothing to worry
[16:00:33] <tyzoid> yeah, just the number is artificially high
[16:13:58] <tyzoid> I feel like we need an arch32 sso provider
[16:16:51] <deep42thought> is there something like that?
[16:17:05] <deep42thought> I mean a general sso implementation?
[16:17:13] <tyzoid> There's OpenID
[16:17:18] <tyzoid> but that's more for third party integration
[16:17:25] <tyzoid> I'll probably end up writing one for ourselves
[16:18:18] <deep42thought> don't add too many items to your todo list :-D
[16:18:33] <deep42thought> mine keeps growing indefinitely, it seems
[16:18:58] <tyzoid> well, for me, I just add interesting projects to the list
[16:19:12] <tyzoid> and if I have sufficient motivation / the problem seems tacklable, I'll finish it
[16:19:18] <tyzoid> otherwise it gets pushed off indefinately
[16:19:28] <tyzoid> that way I'm always working on something interesting
[16:22:44] <tyzoid> deep42thought: Can you CNAME account.archlinux32.org to sso.arch32.tyzoid.com?
[16:22:58] <tyzoid> Or if you prefer a different subdomain, that's fine too
[16:23:26] <deep42thought> google uses "accounts" :-D
[16:25:33] <deep42thought> done: https://ptpb.pw
[16:26:04] <tyzoid> sweet
[16:26:27] <deep42thought> notice I chose the plural
[16:27:28] <tyzoid> yup, noted
[16:31:12] -!- deep42thought has quit [Quit: Leaving.]
[16:34:30] -!- isacdaavid has joined #archlinux32
[16:36:27] <buildmaster> nextcloud is broken (says nlopc46).
[17:21:17] <buildmaster> firefox is broken (says buildknecht3).
[17:41:12] -!- abaumann has joined #archlinux32
[17:41:13] <buildmaster> Hi abaumann!
[17:41:14] <abaumann> tyzoid: no problem, the 486 vm didn't do anything.. I'm just editing some things
[17:41:19] <abaumann> there..
[17:42:37] <abaumann> mmh. slowly the build slaves tackle the big mountain of packages to build. :-)
[18:55:25] -!- deep42thought has joined #archlinux32
[18:55:25] <buildmaster> Hi deep42thought!
[18:55:46] <deep42thought> Hi abaumann, yeah, this is currently a point, where more build slaves actually _do_ more :-)
[18:55:55] <deep42thought> or rather "would do more"
[18:57:13] <deep42thought> my favorite build job is qt5-webengine with 1.5 mio logged lines (for 3 trials so far) :-D
[19:18:55] <abaumann> yeah. that one I should have a look at, it blocks quite some things..
[19:48:10] <deep42thought> abaumann: is the wrong-linked-library issue still present?
[19:49:07] <deep42thought> I mean the libjson-c.so.3 thingy
[19:51:55] <deep42thought> I'm asking, because the database of the buildmaster does not see any (link) dependencies to that library in testing or staging (any more)
[19:56:21] <deep42thought> buildmaster: wtf libjson-c.so.3
[19:56:29] <buildmaster> [core] json-c (0.13-1.0): /usr/lib/libjson-c.so.3
[20:00:44] <abaumann> ldd `which systemctl` | grep json: libjson-c.so.4 => /usr/lib/libjson-c.so.4 (0x00007fb9919f9000)
[20:00:47] <abaumann> so seems to be ok.
[20:01:06] <deep42thought> I just updated the vagrant box, but it seems to fail to boot
[20:01:23] <deep42thought> plus I needed to extract the old library in order to properly (?) shut it down in the first place
[20:01:29] <deep42thought> ah, now it booted ...
[20:01:34] <abaumann> uff :-)
[20:01:36] <deep42thought> ah, no, it didn't
[20:01:37] <deep42thought> sry
[20:01:58] <abaumann> does it bail out in the ram disk when starting initd/systemd?
[20:02:24] <deep42thought> dunno, I'm logged in via ssh to the host and I don't want to open the virtualbox window :-)
[20:02:29] <deep42thought> soooo sloooow
[20:02:41] <abaumann> no serial console?
[20:02:58] <deep42thought> how do I access that?
[20:03:16] <abaumann> you don't have access to the physical box, I reckon?
[20:03:26] <deep42thought> only ssh access, currently
[20:03:56] <abaumann> I have to dig. There was a way to attach the serial output to a virtual box vm.
[20:04:40] <abaumann> but the linux inside must be configured to output to the serial port..
[20:04:50] <abaumann> ..which gives us a henn and egg problem :-)
[20:04:55] <deep42thought> :-)
[20:05:35] <deep42thought> ok, trying with my physical arch32 box next to me ... let's see, what happens ...
[20:06:12] <abaumann> have an iso ready. :-)
[20:06:15] <deep42thought> I do
[20:10:33] <abaumann> mmh. on testing I have ldd /usr/bin/systemctl | grep json
[20:10:33] <abaumann> libjson-c.so.3 => /usr/lib/libjson-c.so.3 (0xb76f6000)
[20:10:54] <abaumann> /usr/lib/libjson-c.so.3 is a symblink at the moment on my test machine
[20:11:00] <abaumann> so there we still have the issue
[20:14:45] <abaumann> after updating I have ldd `which systemctl` | grep json: libjson-c.so.3 => /usr/lib/libjson-c.so.3 on both staging and testing
[20:15:01] <abaumann> I'm slightly confused. :-)
[20:15:38] <deep42thought> do we have systemd in testing at all?
[20:15:46] <deep42thought> buildmaster: wtf /usr/bin/systemd
[20:15:48] <buildmaster> Huh, I don't know that one.
[20:16:03] <deep42thought> buildmaster: wtf systemctl
[20:16:41] <abaumann> buildmaster: wtf /usr/bin/systemctl
[20:16:43] <buildmaster> [testing] systemd (238.133-2.0): /usr/bin/systemctl /usr/share/bash-completion/completions/systemctl
[20:16:43] <buildmaster> [core] systemd (238.133-1.0): /usr/bin/systemctl /usr/share/bash-completion/completions/systemctl
[20:16:44] <buildmaster> Huh, I don't know that one.
[20:17:21] <deep42thought> hmmmm
[20:18:01] <abaumann> ah and some xorg/slim/sddm segfaulting, nice.
[20:18:17] <abaumann> oh. it's xorg again.
[20:18:20] <abaumann> also startx segfaults
[20:18:30] <abaumann> modesetting_drv.so
[20:18:41] <abaumann> aha. rings a bell with a post in the forum. *grmpf*
[20:19:03] <abaumann> I have xf86-video-vesa, why does xorg insist on modesetting?
[20:19:18] <abaumann> X gets worse and worse from version to version.
[20:21:17] <deep42thought> systemctl does not link against libjson-c.so.* itself
[20:21:24] <deep42thought> which library is it, that links against that?
[20:21:44] <abaumann> libcryptsetup
[20:21:55] <abaumann> at least lddtree tells me that.
[20:22:06] <abaumann> there was a recent update IIRC
[20:22:17] <deep42thought> !wtf libcryptsetup.so
[20:22:21] <phrik> deep42thought: core/cryptsetup
[20:22:49] <deep42thought> buildmaster: wtf libcryptsetup.so
[20:22:50] <buildmaster> [core] cryptsetup (2.0.3-2.0): /usr/lib/libcryptsetup.so
[20:23:09] <deep42thought> _that_'s the problem, then
[20:24:49] <deep42thought> ok, cryptsetup is (re)scheduled and prioritized
[20:25:49] <abaumann> I remember a dependency cyrcle there around cryptsetup (from bootstrapping).
[20:25:58] <abaumann> *cyrcle
[20:26:01] <abaumann> lol
[20:28:48] <abaumann> openat(AT_FDCWD, "/usr/lib/dri/../../../mapi/shared-glapi/tls/i686/sse2/libLLVM-6.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
[20:28:58] <abaumann> when starting X
[20:29:25] <abaumann> ah. no.
[20:30:01] <abaumann> gbm_create_device, then a dlopen aborts.
[20:30:14] <abaumann> vesa mode sees no screens.
[20:32:50] <elibrokeit> deep42thought: I might've fixed the haskell bootstrapping thing
[20:34:29] <deep42thought> elibrokeit: great! may I ask, how?
[20:35:06] <elibrokeit> So, like felixonmars said, the issue is (as usual) testsuites are unbootstrappable, right?
[20:35:16] <deep42thought> yes
[20:35:34] <deep42thought> plus the fact, that you need to tell build(), that you want to be able to run the testsuite
[20:35:53] <elibrokeit> I asked him if there's some way to build the testsuite just during the check function... but if not, I've got a toggle to check if --nocheck is passed, and use --disable-tests
[20:36:02] <deep42thought> I just read that after my last post
[20:36:08] <elibrokeit> does haskell really require thqt?
[20:36:20] <elibrokeit> * that
[20:36:28] <deep42thought> I don't know
[20:43:13] <abaumann> (EE) Caught signal 4 (Illegal instruction). Server aborting
[20:43:22] <abaumann> sweet, so xorg has now sse2 optimizations per default.
[20:44:09] <abaumann> oh. or AVX? I do have SSE2
[20:44:39] <deep42thought> ah shit
[20:44:46] <deep42thought> I found my problem
[20:45:03] <deep42thought> I untar'ed the libjson-c.so.3 and libjson-c.so.3.0.1
[20:45:13] <deep42thought> but I did not recreate the initramdisk afterwards ...
[20:45:20] <abaumann> yes. :-)
[20:45:29] <abaumann> fell into that trap too.
[20:45:54] <abaumann> => 0xb7f2dd21 <+9>: pop %ebp
[20:47:29] <abaumann> I think, I get stuck in a int 0x80 syscall somewhere
[20:47:46] <abaumann> the real offending code is at 0xb636bd37
[20:47:57] <abaumann> so it's time to bring out the debug symbols for X. :-)
[20:48:23] <deep42thought> got the wrong live medium - I do not install crux on that box :-D
[20:48:47] <deep42thought> ... huh my archiso32-dual medium claims to boot an x86_64 kernel O.o
[20:50:17] <deep42thought> "VIA Nano U3400@800MHz" - is this thing 64 bit???
[20:51:20] <abaumann> yep. it is.
[20:51:37] <deep42thought> oooh, archlinux32 just lost one of its developers
[20:51:49] <abaumann> lol
[20:51:52] * deep42thought was joking
[20:52:12] <abaumann> http://www.cpu-world.com U3400.html
[20:52:19] <abaumann> 2010, so, not that old..
[20:52:34] <abaumann> but you're right: VIA usually doesn't ring a 64-bit bell..
[20:57:50] <deep42thought> ok, new cryptsetup is ready, let's move it to testing ...
[20:58:38] <abaumann> let's see
[20:59:05] <deep42thought> ... still moving ...
[21:02:01] <deep42thought> elibrokeit: how is pacman.conf assembled in the pacman package?
[21:02:16] <abaumann> libcryptsetup.so.12 shows libjson-c.so.4 on staging, I remove the symlink, redo the ramdisk and boot..
[21:02:24] <elibrokeit> what do you mean?
[21:02:26] <deep42thought> wait a sec
[21:02:32] <deep42thought> it's moving to testing currently
[21:02:39] <deep42thought> elibrokeit: there is a pacman.conf.in
[21:02:49] <deep42thought> but all the repositories are missing (except core)
[21:02:52] <deep42thought> who adds them?
[21:03:01] <deep42thought> abaumann: in testing, now
[21:03:09] <abaumann> deep42thought: thanks
[21:04:06] * deep42thought crosses fingers
[21:04:16] <elibrokeit> deep42thought: there's one maintained in the pacman source code, installed by make install, which contains distribution-neutral
[21:04:19] <abaumann> * abaumann smiles, nothing should go wrong
[21:04:38] <elibrokeit> we ship our own from scratch in svn together with the PKGBUILD
[21:04:46] <deep42thought> ah, ok
[21:04:47] <abaumann> deep42thought: all ok.
[21:05:08] <deep42thought> elibrokeit: because I was bothered by the order of repositories
[21:05:14] <elibrokeit> the pacman.conf is highly not-portable, the majority of it is configuring distribution-specific repository settings.
[21:05:25] <elibrokeit> what's wrong with them
[21:06:01] <deep42thought> imho, staging->testing->stable should be the "main" sequence and core->extra->community the minor
[21:06:27] <elibrokeit> I'm not sure I grok your meaning
[21:06:33] <deep42thought> so "staging -> community-staging -> testing -> community-testing -> core -> extra -> community"
[21:07:01] <elibrokeit> why does community-staging need to override core?
[21:07:19] <deep42thought> it needs to override extra
[21:07:24] <elibrokeit> why?
[21:07:32] <deep42thought> if a package moves from extra to community
[21:07:37] <deep42thought> it will first be in community-staging
[21:07:39] <elibrokeit> then it is db-moved directly
[21:07:44] <deep42thought> and should override the one in extra at that point
[21:07:49] <elibrokeit> staging is totally different
[21:07:55] <elibrokeit> it's for rebuilds only
[21:08:10] <deep42thought> well, ok, on archlinux
[21:08:17] <deep42thought> but the testing part still applies
[21:08:28] <deep42thought> or?
[21:08:30] <elibrokeit> I'm not sure I understand there either
[21:08:51] <deep42thought> if a package is moved from extra to community (e.g. maintainer change), what is done?
[21:08:57] <elibrokeit> if a package moves to a new repo, any version in community gets moved directly to extra, not to testing
[21:09:11] <elibrokeit> and same with extra ==> community
[21:09:13] <deep42thought> this direction is uncritical
[21:09:16] <deep42thought> ah, ok
[21:09:24] <deep42thought> so this is a archlinux32 specific problem
[21:09:32] <elibrokeit> if there's a copy in the testing repos, it gets moved testing <--> community-testing
[21:09:37] <deep42thought> because moved packages will apear in testing first for us
[21:09:43] <elibrokeit> hmm, why?
[21:09:50] <deep42thought> yeah, I understand
[21:09:59] <elibrokeit> if it was in stable extra, why would it need testing
[21:10:01] <deep42thought> because we rebuild it as soon as the source changes
[21:10:24] <elibrokeit> and the source changes because why?
[21:10:32] <deep42thought> and we cannot (easily) distinguish between "new package" and "new package in community, that was in extra before"
[21:10:41] <deep42thought> because it appears in community
[21:10:45] <deep42thought> and vanishes in packages
[21:10:57] <elibrokeit> oh, true
[21:11:13] <deep42thought> or even for extra <-> core
[21:11:18] <elibrokeit> maybe you should consider this an opimization opportunity :)
[21:11:25] * elibrokeit cracks the whip
[21:11:31] <deep42thought> it moves between repos/extra-... repos/core-...
[21:11:46] <deep42thought> hard to detect
[21:12:01] <elibrokeit> yes, but if trunk does not change then repos/{extra,core}- does not either
[21:12:04] <deep42thought> the svn2git is a few minutes out of sync wrt the svn
[21:12:13] <elibrokeit> we use the db-move command for this
[21:12:29] <elibrokeit> You could, I guess, read the commit message to see if it sayys db-move
[21:12:31] <deep42thought> so we should look at the commit message, you say?
[21:12:37] <deep42thought> ok
[21:12:52] <deep42thought> unfortunately, trunk is not really reliable
[21:13:33] <deep42thought> there is all kind of stuff happening in trunk - plus, we want to build the stable packages, not the ones in testing (which would be in trunk)
[21:13:54] <elibrokeit> well, the point is if trunk did not change, this is a heuristic that says repos/* did not change either
[21:14:20] <deep42thought> works for extra <-> core, but not for extra <-> community
[21:14:25] <elibrokeit> I'm not saying to just build from trunk :)
[21:14:33] <deep42thought> phew
[21:14:37] <elibrokeit> yes, I know it's an incomplete solution
[21:14:53] <elibrokeit> OTOH the db-move commit message should be IIRC
[21:15:23] <elibrokeit> https://git.archlinux.org
[21:15:25] <phrik> Title:svntogit/packages.git - Git clone of the 'packages' repository (at git.archlinux.org)
[21:15:30] <elibrokeit> community2extra:
[21:15:41] <deep42thought> abaumann: my box rebooted successfully, too, and jethro tull is playing nicely again :-)
[21:16:06] <elibrokeit> if you see this, you should check, because the pkgver/pkgrel most likely did not change
[21:17:08] <deep42thought> hmmm
[21:17:26] <deep42thought> moving packages "horizontally" is not really something I had in mind, when designing the database
[21:17:33] <deep42thought> I'm not sure it will not break by this :-D
[21:17:39] <deep42thought> rebuilding is safer
[21:18:34] <abaumann> deep42thought: that's good music playing there. :-)
[21:20:36] <deep42thought> abaumann: I knew, you'd appreciate it :-D
[21:23:12] <deep42thought> tyzoid: the archlinux32-keyring on the vagrant file is outdated
[21:23:28] <deep42thought> so, your key is not trusted fully
[21:25:12] <deep42thought> elibrokeit: just for completeness, how does the corresponding commit message in community look like?
[21:25:14] <deep42thought> the same?
[21:25:32] <elibrokeit> extra2community :)
[21:26:07] <deep42thought> no, I mean the commit message deleting the package from community
[21:28:17] <tyzoid> deep42thought: Dang, I'll need to fix that
[21:30:35] -!- deep42thought has parted #archlinux32
[21:30:45] <elibrokeit> should be the same
[21:30:52] <elibrokeit> the script is in devtools BTW
[21:32:03] -!- abaumann has quit [Quit: leaving]
[22:29:35] -!- isacdaavid has quit [Ping timeout: 260 seconds]
[22:48:57] <tyzoid> bill-auger / elibrokeit / dopsi: we've got cgit working now https://git.archlinux32.org
[22:48:59] <phrik> Title:Git repository browser (at git.archlinux32.org)
[22:49:12] <tyzoid> as an alternative interface instead of gitea
[22:49:47] <tyzoid> deep42thought / abaumann ^
[22:50:09] <elibrokeit> well, just so long as pushing over ssh doesn't totally lock up...
[22:50:53] <tyzoid> elibrokeit: Yeah, there was some load on the server a few nights ago
[22:51:03] <tyzoid> *should* be better for now, but I'm monitoring it
[22:55:36] <dopsi> tyzoid: thanks (there is some tweaking to do with descriptions but other than that it works great)
[22:56:18] <tyzoid> dopsi: Yeah, not sure what I can do about that.
[22:56:25] <tyzoid> It's a bare repo, so it doesn't have .git
[22:56:34] <tyzoid> which is where that metadata would be
[22:58:49] <elibrokeit> err, no
[22:59:05] <elibrokeit> the bare repo is in fact the .git, except its not called .git
[22:59:38] <elibrokeit> It is, in fact, the $GIT_DIR (which may or may not be .git)
[23:01:57] <tyzoid> Yeah, looking at it again, looks right
[23:02:05] <tyzoid> but the description isn't being set by gitea :/
[23:07:25] <lukeshu> 1. Do you guys publish sourceballs (.src.tar.gz) anywhere?
[23:08:44] <lukeshu> 2. gimp seems uninstallable, because of a dep on gegl02, which seems to have been dropped from the repos
[23:09:07] <lukeshu> 3. Same for vlc and ffmpeg2.8
[23:09:20] <elibrokeit> I think usualy the package just gets dropped here too...
[23:09:38] <elibrokeit> does archlinux32 not have the latest gimp?
[23:10:34] <lukeshu> I think the problem is that the latest gimp & vlc are stuck in testing/staging, despite the ones in the stable repos needing no-longer-existent dependencies.
[23:11:57] <lukeshu> yup, gimp-2.10.2 is in [testing], and [extra] still has gimp-2.8.22
[23:13:23] <lukeshu> [extra] has vlc 2.2.8, [testing] has 3.0.2, [staging] has 3.0.3
[23:14:17] <tyzoid> buildmaster: wtf gimp
[23:14:52] <buildmaster> [testing] gimp (2.10.2-1.0): /usr/bin/gimp
[23:14:52] <buildmaster> [extra] gimp (2.8.22-1): /usr/bin/gimp
[23:14:52] <buildmaster> [community] radare2 (2.5.0-1.0): /usr/share/radare2/2.5.0/magic/gimp
[23:15:40] <tyzoid> Yeah, things are backed-up in general due to some server issues
[23:15:49] <tyzoid> and the build-slaves are starting to reduce the backlog
[23:17:33] <tyzoid> lukeshu: https://sources.archlinux32.org
[23:17:35] <phrik> Title:Index of / (at sources.archlinux32.org)
[23:17:55] <tyzoid> but that's just for packages we release
[23:19:05] <lukeshu> 4. xorg-server 1.20 gives me problems with tigervnc's vncviewer, on x86_64 1.20 works fine
[23:21:31] <lukeshu> tyzoid: ok, thanks
[23:23:11] <tyzoid> lukeshu: do you have bugtracker access?
[23:23:49] <lukeshu> I do.
[23:24:13] <tyzoid> ok, 2/3/4 should be reported there if not already
[23:24:30] <lukeshu> Will do.
[23:25:41] <lukeshu> buildmaster: wtf gegl
[23:25:46] <buildmaster> [testing] gegl (0.4.2+14+g190a81b4a-1.0): /usr/bin/gegl
[23:25:46] <buildmaster> [extra] gegl (0.3.34-1.0): /usr/bin/gegl
[23:30:56] <lukeshu> tyzoid: Completely unexpected exception: Connection to 172.18.0.1:25 Timed Out
[23:30:57] <lukeshu> This should never happend, please inform Flyspray Developers
[23:31:13] <tyzoid> Drat, yeah, I keep forgetting about that
[23:31:14] <tyzoid> one sec
[23:31:19] <tyzoid> Btw, that info is also available here https://packages.archlinux32.org and via api here: https://pkgapi.arch32.tyzoid.com
[23:31:21] <phrik> Title:Arch Linux 32 - Package Search (at packages.archlinux32.org)
[23:34:44] <tyzoid> lukeshu: That should be fixed, try now
[23:40:50] <tyzoid> lukeshu: Btw, the old ffmpeg2.8 packages can be grabbed from https://archive.archlinux32.org if you need them.
[23:40:51] <phrik> Title:Index of /packages/f/ffmpeg2.8 (at archive.archlinux32.org)
[23:59:17] <tyzoid> deep42thought: This suggests that we've got some bad logic in the deletion script as well
[23:59:29] <tyzoid> since vlc depends on ffmpeg2.8 which was removed.