#archlinux32 | Logs for 2024-08-06
Back
[04:36:23] -!- ssserpent has joined #archlinux32
[04:53:49] -!- ssserpent has quit [Quit: WeeChat 4.3.5]
[04:56:35] -!- titus_livius has joined #archlinux32
[05:04:34] -!- buildmaster has quit [Remote host closed the connection]
[05:19:41] -!- buildmaster has joined #archlinux32
[05:56:39] -!- ssserpent has quit [Ping timeout: 260 seconds]
[05:59:05] -!- ssserpent has joined #archlinux32
[06:58:16] -!- ssserpent has quit [Quit: WeeChat 4.3.5]
[07:00:01] -!- ssserpent has joined #archlinux32
[07:57:53] -!- ssserpent has quit [Quit: WeeChat 4.3.5]
[07:59:21] -!- ssserpent has joined #archlinux32
[08:39:06] <KitsuWhooa> abaumann: How stupid would it be to delete all build assignments from the database? I assume running get-package-updates will fill in the needed ones again, right?
[08:39:17] <KitsuWhooa> I suspect the issue might be there
[08:39:30] <KitsuWhooa> but I really can't tell. Some packages get marked as broken, shuffled to another builder, and then skipped
[08:39:35] <KitsuWhooa> and others just get stuck nonstop
[08:43:42] <KitsuWhooa> the ones I delete keep coming back eventually, so I assume there's no harm being done
[09:37:17] -!- abaumann has joined #archlinux32
[09:37:17] <buildmaster> Hi abaumann!
[09:37:17] <buildmaster> !rq abaumann
[09:37:18] <phrik> buildmaster: <abaumann> I'm back, together with my lazy build slaves..
[09:38:09] <abaumann> KitsuWhooa: mmh. We should ask deep42thought about what happens, when we delete all build assignments. In theory you are right, id should be idempotent and refill the build tasks.
[09:39:01] <abaumann> I just see that a lot of packages are being build on the mirror/pool.
[09:40:01] <abaumann> s/id/it/g
[09:40:13] <KitsuWhooa> that's because I'm deleting stuck build assignments manually :p
[09:40:18] <KitsuWhooa> so they don't clog up the builders
[09:40:28] <KitsuWhooa> and when they come back I delete them again
[09:42:03] <abaumann> Sounds something to automatize. ;-)
[09:42:07] <KitsuWhooa> hahaha
[09:42:26] <abaumann> classical approach in IT hosting: you cannot fix the problem, so you script the hacks. :-)
[09:43:54] <KitsuWhooa> so, when are we paying deep42thought to fix this /j
[09:44:37] <KitsuWhooa> but jokes aside, I'm just trying to observe and better understand the problem right now
[09:45:00] <abaumann> that's a good approach. :-)
[09:45:23] <abaumann> and there IS tons of things being built. With more build machines. So I let mine running (they seem somewhat more stable now).
[09:45:34] <KitsuWhooa> mine keep getting stuck
[09:45:38] <KitsuWhooa> and I've seen euronuc get stuck as well
[09:45:55] <KitsuWhooa> incoming slight spam:
[09:45:57] <KitsuWhooa> DELETE FROM build_assignments WHERE id IN (SELECT build_assignments.id FROM build_assignments INNER JOIN package_sources ON build_assignments.package_source = package_sources.id WHERE (pkgbase LIKE 'hunspell%' OR pkgbase IN ('fcitx5-pinyin-zhwiki', 'breeze-gtk', 'perl-svn-simple-edit', 'ruby-octokit', 'tex-gyre-fonts', 'dark-reader', 'ruby-console', 'jellyfin-web', 'netbeans', 'buildbot',
[09:45:59] <KitsuWhooa> 'gnuradio-iqbal', 'coin-or-lemon', 'opensearch-dashboards-index-management-plugin', 'consul', 'embree3', 'libcdio', 'libpst', 'libredefender')) AND return_date IS NULL);
[09:46:04] <KitsuWhooa> I just keep adding packages to that list that are stuck
[09:46:13] <KitsuWhooa> then get-package-updates runs automatically and I have to re-run it :p
[09:46:44] <abaumann> I fail to see a pattern in those packages.. but for the fact that they don't build.
[09:46:50] <KitsuWhooa> been trying to compare packages that fail in a loop and packages that fail "correctly" and I couldn't find anything
[09:46:52] <KitsuWhooa> yeah
[09:46:53] <abaumann> I mean, if built by hand.
[09:46:54] <KitsuWhooa> exactly
[09:47:14] <abaumann> We could try to fix some of the packages and see if they get built properly then.
[09:47:14] <KitsuWhooa> either the failure isn't correctly recorded, or something makes it keep wanting to build them
[09:47:18] <KitsuWhooa> as if they were a library or something
[09:47:23] <KitsuWhooa> I have done that, and they do get build
[09:47:32] <KitsuWhooa> built
[09:47:35] <KitsuWhooa> but it gets stuck on another one
[09:47:56] <KitsuWhooa> it's almost as if it thinks they are a toolchain package
[09:48:05] <KitsuWhooa> like you know how it'll keep trying to build glibc over and over and over
[09:48:08] <abaumann> opensearch-dashboards-index-management-plugin for instance is extremely high-level, so it's hard to imagine it's rescheduled because of dependencies.
[09:48:20] <KitsuWhooa> one of them has only one dependency and it's minor too
[09:48:24] <KitsuWhooa> I can't remember which one it was
[09:48:38] <KitsuWhooa> I think it was tex-gyre-fonts
[09:48:53] <KitsuWhooa> it's just fonts
[09:48:54] <abaumann> toolchain packages are a fixed list somewhere in the code or in a special table. It should be changed.
[09:49:00] <KitsuWhooa> yeah, it's in a table in the db
[09:49:04] <abaumann> ah.
[09:49:11] <KitsuWhooa> I'm just wondering if it gets confused somehow
[09:49:15] <KitsuWhooa> but why would it just suddenly happen
[09:49:37] <abaumann> yep, that's puzzling.
[09:49:50] <abaumann> I have seen gcc, binutils, glibc, boost and others build just fine.
[09:50:00] <KitsuWhooa> yeah, glibc built earlier just fine
[09:50:14] <KitsuWhooa> It must be something bad in a build assignment or a package source I think
[09:50:22] <KitsuWhooa> that's why I'm thinking of clearing out all the assignments
[09:50:31] <KitsuWhooa> or rather
[09:50:34] <KitsuWhooa> all the unbuilt assignments
[09:50:44] <KitsuWhooa> thus the return_date IS NULL
[09:51:06] <KitsuWhooa> if it's a package that got built, then... good luck
[09:52:05] <abaumann> tex-gyre-fonts is a good test example. It fails to download the fonts. So core-staging-pentium4-build fails with exit code 255
[09:52:27] <abaumann> So it should really return a proper build assignment. Let me force it on my machine and see what happens..
[09:53:33] <abaumann> And I have to fetch lunchees (feeling a tickling grummling sound from further below).
[09:53:52] <KitsuWhooa> that's fine
[09:53:54] <KitsuWhooa> hope you enjoy your food
[09:54:04] <abaumann> sure. why not. :-)
[09:54:23] <abaumann> if the grummling sound gets louder _after_ eating, then it's a problem. ;-)
[10:12:19] <abaumann> Aug 06 12:06:10 euronuc.lan build-packages[3255487]: --2024-08-06 12:06:10-- https://sources.archlinux32.org
[10:12:19] <abaumann> Aug 06 12:06:10 euronuc.lan build-packages[3255487]: Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
[10:12:20] <abaumann> Aug 06 12:06:10 euronuc.lan build-packages[3255487]: Resolving sources.archlinux32.org (sources.archlinux32.org)... 85.10.198.216, 2a01:4f8:a0:5264::2
[10:12:20] <abaumann> Aug 06 12:06:10 euronuc.lan build-packages[3255487]: Connecting to sources.archlinux32.org (sources.archlinux32.org)|85.10.198.216|:443... connected.
[10:12:21] <abaumann> Aug 06 12:06:10 euronuc.lan build-packages[3255487]: HTTP request sent, awaiting response... 404 Not Found
[10:12:21] <abaumann> Aug 06 12:06:10 euronuc.lan build-packages[3255487]: 2024-08-06 12:06:10 ERROR 404: Not Found.
[10:12:30] <abaumann> Maybe this is buffdiwuff not generating the tarball?
[10:12:42] <abaumann> And this is an unhandled case in return-assignment?
[10:13:08] <KitsuWhooa> it's not always 404 by the way
[10:13:14] <KitsuWhooa> as in, not all the failing packages are 404s
[10:13:25] <abaumann> Why it tries to download tg2_501otf.zip as pre-caches source makes no sense to me. This has been invented for big git-repo-tarballs like linux, firefox, chromium, etc.
[10:13:30] <abaumann> ah.
[10:13:33] <KitsuWhooa> but those 404s have been an issue for a while
[10:13:35] <KitsuWhooa> and it'd move on from them
[10:13:38] <KitsuWhooa> I remember it clearly
[10:28:53] -!- abaumann has quit [Quit: Client closed]
[10:38:03] <KitsuWhooa> yeah, my builder is stuck on gource now
[10:38:09] <KitsuWhooa> which fails because SDL2 doesn't have png support for some reason
[11:01:33] <KitsuWhooa> note to self: libsquish needs xmmintrin
[13:08:56] mavicaway is now known as mavica
[13:53:12] -!- mvchtz has quit [Remote host closed the connection]
[14:12:20] <KillerWasp> https://www.youtube.com
[14:12:23] <phrik> Title: - YouTube (at www.youtube.com)
[14:12:50] <KillerWasp> a little of offtopic.
[14:22:14] -!- mvchtz has joined #archlinux32
[14:28:00] -!- ssserpent has quit [Ping timeout: 252 seconds]
[14:35:00] -!- ssserpent has joined #archlinux32
[17:19:09] -!- Cthuutloops has quit [Ping timeout: 260 seconds]
[18:20:10] <gehidore> "a little"
[18:28:55] -!- ssserpent has quit [Quit: WeeChat 4.3.5]
[19:04:02] -!- drathir_tor has quit [Remote host closed the connection]
[19:12:45] <girls> There are two caches, and I think you mix them up, abaumann: the buffdiwuff one (which resides in sources.archlinux32.org/$sumname/$hash) caches sources by their hash. This is intended for stuff, that gets re-released and changes its hash, so we still have the old one. This should only be queried as fallback if the regular download from the upstream source already failed. The other one, that you mention is the git tarballer, which c
[19:12:45] <girls> reates tarballs of git repositories (like linux), but has to be added via PKGBUILD patch.
[19:13:49] <girls> That being said: buffdiwuff needs to run as cronjob, otherwise it will not download and cache the sources. Since I forgot, where it runs, I cannot check, whether it properly runs. I would _assume_, it's on the buildmaster, but I don't really recall - sry.
[19:14:11] <KitsuWhooa> oh hi girls
[19:14:12] <girls> the git tarballer should work in-situ: you query a hash and it should do its thing.
[19:14:13] <KitsuWhooa> save us
[19:14:15] <KitsuWhooa> :p
[19:14:15] <girls> Hi KitsuWhooa!
[19:14:21] <KitsuWhooa> pretty please
[19:14:33] <KitsuWhooa> buffdiwuff does in fact run on buildmaster
[19:14:40] <girls> \o/
[19:15:11] <girls> ok, what's the most-pressing issue, currently?
[19:15:21] <girls> Where should I put my attention?
[19:15:24] <KitsuWhooa> packages are being marked as broken, but they keep getting scheduled on the builders
[19:15:45] <KitsuWhooa> so once a builder encounters a broken package, it will never try to build anything else
[19:15:54] <KitsuWhooa> it started happening randomly a month ago
[19:16:05] -!- drathir_tor has joined #archlinux32
[19:16:09] <KitsuWhooa> and if you can see the logs, I've been deleting the broken build assignments from the db to get the builders unstuck
[19:16:19] <KitsuWhooa> until of course get-package-updates runs again and re-adds the build jobs
[19:16:38] <girls> hmm, I see
[19:16:40] <KitsuWhooa> you know how glibc will keep getting built repeatedly if it fails? It's doing that with way way way more packages
[19:16:56] <KitsuWhooa> a few still get marked as broken correctly, but most either aren't marked correctly, or get-assignment picks them again anyway
[19:17:00] <girls> that's the biggest crutch in buildmaster, I fear :(
[19:17:23] <KitsuWhooa> I was thinking of deleting any unreturned build assignments from the db
[19:17:27] <KitsuWhooa> hoping it might fix something
[19:17:32] <KitsuWhooa> but obviously I'm worried it might break things\
[19:17:52] <girls> you know, there's the file-overwrite which hooks in pretty far in get-assignment?
[19:18:00] <KitsuWhooa> file-overwrite?
[19:18:20] <KitsuWhooa> I tried to read the queries on get-assignment but uh, it is going to take a while to understand it all
[19:18:41] <girls> https://git.archlinux32.org
[19:18:43] <phrik> Title: get-assignment « bin - builder - Archlinux32 build system (at git.archlinux32.org)
[19:19:00] <KitsuWhooa> oh
[19:19:16] <KitsuWhooa> I think I looked for those files but I didn't find any
[19:19:17] <girls> you can create a file forced-package-builds.$yourslave format is I think "$arch $pkgbase" per line
[19:19:34] <KitsuWhooa> that wouldn't help though, right?
[19:19:34] <girls> this will force the respective package to the slave, only checking that it is to be built at all
[19:19:44] <girls> yeah, you can just create them
[19:19:46] <KitsuWhooa> we can't do this with every package that fails
[19:19:49] <girls> they will get deleted when empty
[19:19:54] <girls> nono
[19:20:03] <KitsuWhooa> sorry, I misunderstood
[19:20:07] <girls> the idea is to schedule whatever makes the broken packages fail, first
[19:20:22] <KitsuWhooa> Oooh I see
[19:20:34] <girls> i.e. the buildmaster sees a cycle, but is unable to break it / hands out the wrong package over and over again
[19:20:47] <KitsuWhooa> it's happening with many packages though
[19:20:49] <KitsuWhooa> it didn't use to do that
[19:20:54] <girls> you look at the issue and see, that for example "cmake" needs to be built first, so you schedule it
[19:21:11] <KitsuWhooa> like, I don't see how a font package will be doing this
[19:21:15] <KitsuWhooa> but hm
[19:21:54] <KitsuWhooa> for example
[19:21:57] <KitsuWhooa> https://archlinux.org has 0 dependencies
[19:21:59] <phrik> Title: Arch Linux - tex-gyre-fonts 2.501-3 (any) (at archlinux.org)
[19:22:03] <KitsuWhooa> yet it keeps getting cycled over and over and over
[19:22:23] <KitsuWhooa> (it's failing because the source 404s)
[19:22:38] <girls> I'll look, why the buildmaster wants to schedule it
[19:22:50] <KitsuWhooa> you might need to run get-package-updates first
[19:22:54] <girls> it's currently not on the build list, because you deleted it?
[19:22:57] <KitsuWhooa> yes
[19:22:59] <girls> I see :)
[19:23:13] <KitsuWhooa> it will first try to build hunspell-*
[19:23:23] <girls> deps=0 is a pretty good reason for the buildmaster to schedule the package
[19:23:25] <KitsuWhooa> after the get-package-updates
[19:23:32] <KitsuWhooa> yes, but if it fails, shouldn't it move on?
[19:23:40] <KitsuWhooa> I'm pretty sure it did that in the past
[19:23:48] <girls> yes, it should, if there are other unblocked packages
[19:23:54] <KitsuWhooa> there definitely are
[19:24:02] <KitsuWhooa> once I delete it, it moves on and successfully builds other stuff
[19:24:13] <KitsuWhooa> until it hits another one and gets stuck in the same way
[19:24:20] <girls> if you delete the package, you may also delete dependencies
[19:24:35] <girls> maybe it sees too many dependencies, hmm
[19:24:46] <KitsuWhooa> I don't think deleting the build assignment deletes the package source
[19:24:52] <girls> nono
[19:24:54] <girls> in the db
[19:24:58] <KitsuWhooa> yeah, in the db
[19:25:13] <KitsuWhooa> this is what I last ran (spam)
[19:25:15] <KitsuWhooa> DELETE FROM build_assignments WHERE id IN (SELECT build_assignments.id FROM build_assignments INNER JOIN package_sources ON build_assignments.package_source = package_sources.id WHERE (pkgbase LIKE 'hunspell%' OR pkgbase IN ('fcitx5-pinyin-zhwiki', 'breeze-gtk', 'perl-svn-simple-edit', 'ruby-octokit', 'tex-gyre-fonts', 'dark-reader', 'ruby-console', 'jellyfin-web', 'netbeans', 'buildbot',
[19:25:16] <girls> you delete the build assignment -> the binary_package gets deleted -> its dependencies (I mean only the links) get deleted
[19:25:17] <KitsuWhooa> 'gnuradio-iqbal', 'coin-or-lemon', 'opensearch-dashboards-index-management-plugin', 'consul', 'embree3', 'libcdio', 'libpst', 'libredefender', 'gource', 'jack_utils', 'jack_delay', 'g2reverb', 'libshairport', 'libva-vdpau-driver', 'libsquish', 'ambdec', 'fil-plugins', 'libopenshot', 'liquid-dsp')) AND return_date IS NULL);
[19:25:25] <KitsuWhooa> ooooooh
[19:25:31] <girls> there is a cascade delete on it
[19:25:38] <KitsuWhooa> I see
[19:25:54] <girls> because the binary_package makes no sense without a package_source, which is linked via build_assignment (because we need to multiply over the architectures)
[19:26:04] <KitsuWhooa> there is no binary_package if it failed though, right?
[19:26:12] <girls> there is a dummy
[19:26:19] <KitsuWhooa> oh, I see
[19:26:20] <girls> so in the db, there _is_ a binary_package
[19:26:25] <KitsuWhooa> I understand now
[19:26:41] <girls> with all the projected dependencies (i.e. the ones, that makepkg --printsrcinfo shows)
[19:26:47] <KitsuWhooa> I see
[19:27:09] <girls> I'll run get-package-updates, now
[19:27:23] <girls> then I'll look, what blocks e.g. systemd on pentium4
[19:27:29] <KitsuWhooa> thumbs up
[19:27:40] <KitsuWhooa> Right now two builders are spinning on mcp-plugins
[19:27:42] <girls> then I can walk up the dependency tree to see, where some dependency is seen "too eager"
[19:27:56] <KitsuWhooa> If you don't mind, please let me know how you end up troubleshooting this
[19:28:01] <KitsuWhooa> oh, and thank you
[19:28:37] <KitsuWhooa> one of my builders has been trying to build pentium4/mage since 19:08
[19:28:45] <KitsuWhooa> (utc)
[19:29:12] <girls> mage sounds reasonable to build early: pacman claims, it is "a build system" (yet another ... sigh)
[19:29:25] <KitsuWhooa> I counted 5 "Done" messages in the build log on that builder
[19:29:30] <KitsuWhooa> so it's the 6th time it's trying the package
[19:30:15] <girls> can you paste the log (mainly the upload part) of your builder?
[19:30:24] <KitsuWhooa> upload?
[19:30:37] <KitsuWhooa> 2024-08-06 19:29:34: building package "mage" (revisions 057f74efc7152715e0777e501bf8710a4221ba97 0000000000000000000000000000000000000000, repository extra, straw :with_build_support:haskell_without_check:) for pentium4 ... failed.
[19:30:37] <girls> build-package uploads the package in the end
[19:30:39] <KitsuWhooa> Done.
[19:30:51] <girls> ah, it failed :(
[19:30:58] <KitsuWhooa> yes, it only does this if it fails
[19:31:17] <girls> fascinating, the buildmaster doesn't see, that it failed
[19:31:19] <KitsuWhooa> I think now we're on the 7th attempt
[19:31:27] <KitsuWhooa> I checked and it definitely returns "ERROR" in return-assignment
[19:31:37] <KitsuWhooa> and in devops it says "broken" for most of them
[19:31:37] <girls> it should count the attempts and then schedule other, not-yet-tried packages
[19:31:43] <KitsuWhooa> yup
[19:31:46] <KitsuWhooa> that's how it behaved before
[19:32:00] <girls> I'll take a look at return-assignment, then :)
[19:32:18] <KitsuWhooa> I wasn't sure if the issue was in return assignment or get assignment
[19:32:47] <KitsuWhooa> I think this started on, or around 2024-07-12
[19:32:50] <KitsuWhooa> if that helps at all
[19:32:52] <girls> I can't speak for the innocence of get-assignment, but return-assignment definitely does something weird in the error case
[19:33:01] <KitsuWhooa> I see
[19:36:53] <girls> we do have recent fail logs, so it's not completely broken, and your slave is probably also fine
[19:37:00] <KitsuWhooa> yeah
[19:37:06] <KitsuWhooa> it does this with both mine, euronuc and eurobuild
[19:37:12] <KitsuWhooa> and as I said, some do fail and move on
[19:37:14] <KitsuWhooa> but most don't
[19:37:19] <KitsuWhooa> it's really weird
[19:38:03] <KitsuWhooa> once get-package-updates finished, I can spin up my third builder and it will most likely queue up hunspell
[19:39:24] <girls> it's really weird: there are log files, but the db claims, mage for pentium4 never failed
[19:39:39] <KitsuWhooa> how are you checking that the db says it never failed?
[19:39:43] <KitsuWhooa> because return_date is null?
[19:39:53] <girls> mariadb buildmaster -e 'select * from build_assignments'"$(mysql_join_build_assignments_package_sources)$(mysql_join_build_assignments_failed_builds)"' where package_sources.pkgbase="mage" and build_assignments.architecture=4 and return_date IS NULL'
[19:39:56] <girls> returns empty
[19:40:03] <KitsuWhooa> ooooh
[19:40:09] <KitsuWhooa> that's a really cool way of doing the joins
[19:40:09] <girls> but without the join to "failed_builds", I see the row
[19:40:21] <KitsuWhooa> I see. Thank you
[19:40:32] <girls> that's the only way I found to not break auto-complete in my shell
[19:40:47] <KitsuWhooa> I've been doing everything by hand inside the mariadb interactive shell
[19:40:54] <girls> you need to ". lib/load-configuration" first, of course
[19:40:55] <KitsuWhooa> I even made it show the results in a pager
[19:40:58] <KitsuWhooa> yup
[19:46:01] <girls> it gets even weirder: the build_assignment of mage has the "is_broken" flag set (as it should be) - but there are no fail reasons attached to it - which should actually happen _before_ setting the flag
[19:46:22] <KitsuWhooa> huh
[19:46:52] <girls> ah, ok, it may happen if the upload of the logs fails for whatever reason (but we know, it didn't, because the logs are there)
[19:48:25] <girls> unfortunately, the build-list.php view does not show the flag, because it is built under the assumption, that if is_broken is set, there are also fail reasons attached - and we show them :(
[19:51:11] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[19:54:04] <KitsuWhooa> oh, get-package-updates finished
[19:54:09] <KitsuWhooa> guess what's being built :p
[19:54:27] <KitsuWhooa> totally not any/hunspell-en
[19:54:52] <KitsuWhooa> here comes any/hunspell-pl too
[19:55:10] <KitsuWhooa> I bet next one is going to be hunspell-hu
[19:55:16] <girls> :D
[19:55:24] <KitsuWhooa> ...or -el
[19:55:48] <girls> I don't see any suspicious package updates arount the 11th of july
[19:56:26] <KitsuWhooa> that's when all the builders started looping and no more packages were being marked as broken
[19:56:41] <KitsuWhooa> maybe it started earlier, but surely it couldn't have been that far back
[19:56:48] <KitsuWhooa> it's not like we don't have packages that fail :p
[19:58:18] <girls> why-don't-you claims, for systemd to be built, it needs clang,curl,git,llvm,xz,zstd
[19:58:30] <girls> maybe one of those has weird dependencies on a spellchecker
[19:58:32] <girls> :-/
[19:59:17] <girls> perl is also in the list
[19:59:26] <girls> https://archlinux32.org
[19:59:29] <KitsuWhooa> When I ran it earlier on glibc before it got built, it told me
[19:59:31] <KitsuWhooa> 22:28:45 <KitsuWhooa> "i686/glibc" has unmet dependencies: glibc
[19:59:36] <KitsuWhooa> it's been built since then though
[19:59:55] <girls> let's try to build perl - it needs "patchutils"
[19:59:58] <girls> https://archlinux32.org
[20:00:08] <girls> which should be buildable
[20:00:11] <girls> https://archlinux32.org
[20:00:21] <KitsuWhooa> those graphs are really good
[20:00:32] <KitsuWhooa> they have been very useful
[20:03:16] -!- drathir_tor has joined #archlinux32
[20:03:20] <girls> let's force patchutils onto build-tasossah-1
[20:03:28] <KitsuWhooa> have fun
[20:03:38] <KitsuWhooa> (fx is slower, so avoid that if possible)
[20:03:43] <KitsuWhooa> the FX means FX8350 :p
[20:05:29] <girls> I'll just randomly throw packages on build-tasossah-1, of which I believe, they're crucial (like git, llvm, ...)
[20:05:41] <KitsuWhooa> llvm built recently IIRC
[20:05:43] <girls> let's see, if building any of those unblock something
[20:06:25] <KitsuWhooa> I don't know if it's related, but when I scheduled webkitgtk-6.0 for rebuild, it only built on i686 and was nowhere on the build list for pentium4
[20:06:37] <KitsuWhooa> s/ on/ for/
[20:08:57] <girls> sry, I don't remember, how the rescheduling should work. Maybe there's some filter for architectures involved
[20:09:31] <KitsuWhooa> fair
[20:12:06] <girls> looks like patchutils was built successfully for i686 and pentium4
[20:12:09] -!- drathir_tor has quit [Remote host closed the connection]
[20:12:12] <girls> https://archlinux32.org
[20:12:36] <girls> ah, one can _filter_ on the is_broken flag
[20:13:48] <girls> perl for i686 was also built
[20:14:24] <girls> I threw all base and base-devel packages at your builder. Let's see, if this solves the knot :-/
[20:14:56] <girls> The re-scheduling of gcc and glibc never really worked nicely. We could rip it out and simply re-schedule those packages manually.
[20:15:09] <girls> but I was too afraid to start completely without it in the first place.
[20:16:00] <KitsuWhooa> fingers crossed
[20:16:09] <KitsuWhooa> I'll be happy if this technique works :p
[20:16:39] <girls> you can at least always use it to move packages in front, of which you believe, they are more urgent than whatever the buildmaster hands out currently
[20:16:55] <KitsuWhooa> yup
[20:35:00] <KitsuWhooa> girls: I think perl is failing to build...
[20:35:15] <girls> well, that should not block everything else
[20:35:20] <KitsuWhooa> yeah
[20:35:27] <girls> but it's something that someone(tm) should look into ;)
[20:35:28] <KitsuWhooa> one of the tests fails
[20:35:31] <KitsuWhooa> yeah I'll do it :p
[20:35:33] <KitsuWhooa> not now though
[20:35:39] <girls> yeah, no hurry
[20:44:00] <KitsuWhooa> oh, it's not going to stop trying to build it until someone fixes it, right?
[20:44:20] <girls> it's removed from the force file, once it's handed out
[20:44:31] <KitsuWhooa> oh
[20:44:37] <KitsuWhooa> fair
[20:48:17] -!- drathir_tor has joined #archlinux32
[20:52:06] -!- drathir_tor has quit [Remote host closed the connection]
[20:58:08] -!- drathir_tor has joined #archlinux32
[21:13:08] <girls> so if you're really desperate, a `pacman -Ssq | sed 's@.*@i686 \0\npentium4 \0@' >> ~/builder/work/forced-package-builds.build-tasossah-1` will schedule all currently build-list'ed packages to your builder. Each package will be built once, and the order is fixed by how pacman put the packages out.
[21:29:11] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[21:36:27] -!- drathir_tor has joined #archlinux32
[22:08:12] -!- Cthuutloops has joined #archlinux32