#archlinux32 | Logs for 2023-02-25

Back
[02:19:41] -!- iamawacko has joined #archlinux32
[02:20:55] <iamawacko> Shouldn't steam be in the blacklist? It requires x86_64
[03:30:01] <KillerWasp> i always have steam in blacklist
[03:33:31] <iamawacko> I meant in the arch32 packages repo
[03:34:08] <iamawacko> Because installing and running steam gives
[03:34:15] <iamawacko> Steam requires at least an Intel Pentium 4 or AMD Opteron, with the following features:
[03:34:24] <iamawacko> - x86-64 (AMD64) instruction set (lm in /proc/cpuinfo flags)
[03:42:34] <iamawacko> Does putting the blacklist in pentium4 effect i686 and i486? That seems to be true, but I just want to check
[05:14:34] -!- lithiumpt has quit [Ping timeout: 252 seconds]
[05:23:55] <iamawacko> I sent a patch to patches at archlinux32.org fixing this.
[07:12:54] -!- abaumann has joined #archlinux32
[07:12:55] <buildmaster> Hi abaumann!
[07:12:55] <buildmaster> !rq abaumann
[07:12:56] <phrik> buildmaster: <abaumann> 'any' not any. :-)
[07:13:26] <abaumann> iamawacko: thanks for the stream patch, I hope I applied it correctly this time :-) (a0b2b8a0ad4c074b212c1908fa7bc478a3d2580f)
[07:39:58] <girls> abaumann: looks good
[07:41:37] <girls> iamawacko: yes, blocking something on pentium4 will also block it on i686 and i486; blocking it on i686 will also block it on i486. there was some special blocking logic for "any", though, which I cant remember right now.
[07:43:04] <girls> https://git.archlinux32.org
[07:43:04] <phrik> Title: common-functions « lib - builder - Archlinux32 build system (at git.archlinux32.org)
[07:43:59] <girls> # "any" has a special role - it should be regarded as *inferior* to all architectures
[07:44:03] <girls> ah, there you go :)
[07:44:30] <girls> so blocking a package on "any" means, it will *only* be blocked on "any"
[07:44:57] <girls> if you want to block something for each architecture (including "any"), one must block it for the most-capable one, i.e. "pentium4", currently
[07:45:54] <girls> though, I wonder, what the rationale for that quirk was
[07:50:18] <abaumann> hi deep42thought: so, I'll move the stream patch, right?
[07:50:54] <abaumann> ok, done
[07:51:12] <abaumann> I should have known that.. :-)
[07:53:40] <abaumann> ugh.. it's currenty easier to enumare the things not broken on i486 than the ones which are broken.. :-(
[07:54:48] <abaumann> *enumerate
[07:57:06] <abaumann> yes, a lot of errors are due to broken python.. or python currently being rebuild..
[07:57:51] <abaumann> and having 'tk' as dependency is not helping as it creates a hell of a cycle with font libraries..
[08:04:14] <girls> yeah, I rescheduled all of python-* to finally get a working python-cryptography on pentium4
[08:04:20] <girls> this might have caused some trouble
[08:04:44] <girls> but OTOH, the packages, that are being rebuilt, but didn't need to, should not break anything
[08:05:58] <abaumann> that's fine. and on i486 I'll remove some cycles to build a plain python without tk..
[08:06:40] <girls> thx
[08:06:51] <girls> btw: the blacklisting looks good, now, thx!
[08:06:56] <abaumann> np :-)
[08:07:01] <girls> I didn't check the path :-/
[08:07:24] <girls> did you read my text about how to fix the database?
[08:07:31] <girls> (titus_livius was absent at the time)
[08:07:48] <abaumann> ah, no.
[08:08:05] <girls> in short: check https://buildmaster.archlinux32.org
[08:08:28] <girls> think, what went wrong (mostly it is "the package was moved on the mirror, but the db missed that")
[08:08:39] <girls> then fix it (i.e. move the package in the database)
[08:08:59] <girls> and to see, which table should be joined on which, look at https://buildmaster.archlinux32.org
[08:09:09] <abaumann> ah, ok. last time I tried, I think, I made a mess.. :-)
[08:09:21] <girls> also I mentioned, that we should probably get rid of mirror_statuses and command_log in the db - they're not really relational tables
[08:09:45] <abaumann> yeah, but OTOH they don't really disturb anything..
[08:09:52] <girls> we should/could move them to some other db, possibly a time series db (for the mirror_statuses) or some text-log-"db"
[08:10:02] <girls> yes, they do - they had millions of lines
[08:10:12] <abaumann> just during resynching the database from master to slave I usually shut down some stuff, in order not to have a moving target..
[08:10:20] <girls> I removed all entries before 2023-01-01 and skimmed them down to "only" 50k of lines or so
[08:10:27] <abaumann> ah.
[08:10:46] <abaumann> well. the syncs are faster now. :-)
[08:10:49] <girls> there's some auto-cleanup, which is not run automatically, because it's so heavy on those big tables, I think
[08:10:52] <girls> :D
[08:11:10] <abaumann> big tables and deletes is usually not good..
[08:11:38] <abaumann> what you can do is have a small active command_log and a big archive_command_log table, have some triggers copying stuff periodically and just wiping the small table
[08:11:51] <abaumann> and recreate it with the stats from the last month or so.
[08:12:03] <girls> or we could move it to a db, that brings all that for free, like elasticsearch or so
[08:12:19] <girls> I mean, in the end we don't join these tables anyways
[08:12:42] <abaumann> We could also just dump them to text and keep them around for historians after us to analyze ;-)
[08:12:44] <girls> failed_builds is also such a candidate, but this one is at least joined to other tables
[08:13:03] <girls> problem with that is, that we still need to sync from the buildmaster to archlinux32.org
[08:13:18] -!- lithiumpt has joined #archlinux32
[08:13:20] <abaumann> yes, and that's for all databases.
[08:13:35] <abaumann> It would really be nice to be able to sync single tables, or at least single databases.
[08:13:36] <girls> yes, but syncing text files is harder than syncing dbs
[08:14:58] <abaumann> btw: I had a look at postfix/sendmail milters: short, way complex. There is also an option to filter whole messages after receiving them (content filters). that's probably more what we want for patches@archlinux32.org
[08:15:34] <abaumann> but as long as the sent-in patches volumes is low, we can also do it manually, I think..
[08:18:11] <girls> I also had a second thought about this, and we already *do* have something similar in place for marking packages as tested
[08:18:26] <abaumann> ah, true.
[08:18:38] <girls> in that case, the buildmaster actively pulls its mail box from eckner.net
[08:18:43] <girls> and we could just do the same
[08:18:51] <girls> so, have to leave now - cu later!
[08:19:00] <abaumann> ok, cu :-)
[09:45:57] -!- iamawacko has quit [Ping timeout: 255 seconds]
[09:55:23] -!- drathir_tor has quit [Ping timeout: 255 seconds]
[10:00:59] -!- drathir_tor has joined #archlinux32
[12:45:02] -!- GNUtoo has quit [Ping timeout: 255 seconds]
[13:01:35] -!- GNUtoo has joined #archlinux32
[13:17:08] -!- abaumann has quit [Quit: leaving]
[13:51:27] -!- pants has quit [Remote host closed the connection]
[15:32:19] -!- pants has joined #archlinux32
[15:46:37] -!- City-busz has quit [Quit: http://quassel-irc.org - Csevegjen kényelmesen. Bárhol.]
[15:46:38] -!- phrik has quit [Read error: Connection reset by peer]
[15:48:07] -!- phrik has joined #archlinux32
[15:48:33] -!- City-busz has joined #archlinux32