#archlinux32 | Logs for 2024-01-12

Back
[05:36:14] -!- drathir_tor has quit [Remote host closed the connection]
[05:37:02] -!- drathir_tor has joined #archlinux32
[06:54:25] -!- abaumann has joined #archlinux32
[06:54:25] <buildmaster> Hi abaumann!
[06:54:25] <buildmaster> !rq abaumann
[06:54:26] <phrik> buildmaster: <abaumann> if analog tv would have been engineered nowadays with all this software nonsense, it would explode every second weekend..
[06:54:56] <abaumann> KitsuWhooa: matter of priorization: first is shipping product (aka Arch32), second is improving the build tools, third is improving infrastructure.
[06:55:07] <abaumann> That's why php7 to php8 lands on place 3 :-)
[06:55:11] <KitsuWhooa> understood :p
[06:55:30] <abaumann> php7.4 is not such a problem. I still patch and run it for things like owncloud for instance.
[06:55:49] <abaumann> but you are right, migration has to happen sooner or later
[06:55:51] <KitsuWhooa> (and as you can tell, I'm working towards #1)
[06:56:03] <abaumann> yep. noticed. :-)
[06:56:06] <abaumann> and appreciated.
[06:56:54] <KitsuWhooa> but yeah, since you're here, I don't suppose you know what is up with buildmaster
[06:57:05] <abaumann> There is a longer philosophical issue here, that as long upstream is not implementing a #2 and is doing things manually, we will always have a problem to rebuild parts of #1 :-)
[06:57:11] <KitsuWhooa> yes
[06:57:25] <KitsuWhooa> but I don't think arch32 has the resources to do things manually
[06:57:26] <abaumann> no. the buildmaster has to be reverse engineered and fixed or rewritten
[06:57:35] <abaumann> exactly
[06:58:01] <abaumann> there is another issue: upstream/upstream does silly things, like depending on ever growing binary seeds for instance for python.
[06:58:09] <abaumann> there is not much we can do against that
[06:58:23] <KitsuWhooa> as long as it's on build support only, I think it's okay?
[06:58:33] <abaumann> yes.
[06:59:12] <abaumann> but, to be frank: I stopped doing manual things some months ago, because it just took too much time and the buildmaster was not very fast in rebuilding things for the buildmaster.
[06:59:24] <KitsuWhooa> yeah it's an absolute chore
[06:59:34] <KitsuWhooa> I build packages locally to test where I can, but still
[06:59:51] <abaumann> In the past I had to do outside-of-buildmaster-builds with a sane python, java, ghc whatever, just to get some sane build-support packages.
[07:00:01] <KitsuWhooa> rechenknecht also doesn't help because it's broken at the moment
[07:00:05] <KitsuWhooa> and just fails to build anything
[07:00:05] <abaumann> I would prefer to manually build packages and somehow register them into the buildmaster
[07:00:22] <abaumann> yes, it has to be reinstalled with devtools32, I adapted that some time ago for arch32
[07:00:36] <KitsuWhooa> it's not just that
[07:00:38] <KitsuWhooa> it has pgp errors :p
[07:00:41] <abaumann> ah.
[07:00:48] <abaumann> but those are easy to fix :-)
[07:00:50] <abaumann> usually..
[07:00:58] <KitsuWhooa> Yeah
[07:01:03] <KitsuWhooa> I just don't have access to it to fix it
[07:01:17] <KitsuWhooa> I tried disabling it in the database but then buildmaster went insane because "the ssh keys didn't match"
[07:01:25] <KitsuWhooa> so I re-enabled it and that made it sane again
[07:01:26] <abaumann> deep42thought has just very very little time at the moment
[07:01:33] <KitsuWhooa> yeah, I very much understand that
[07:02:11] <abaumann> manage-slaves on the buildmaster
[07:02:23] <KitsuWhooa> oooh
[07:02:26] <abaumann> ./manage-slaves disable rechenknecht
[07:02:28] <KitsuWhooa> I'll have a look at it
[07:02:35] <KitsuWhooa> thanks!
[07:02:44] <abaumann> but it's - aeh - somewhat experimental :-)
[07:02:48] <KitsuWhooa> (I manually did the edit in the database)
[07:03:17] <abaumann> the script does that - and hopefully - correctly. :-)_
[07:03:23] <KitsuWhooa> but for example
[07:03:24] <KitsuWhooa> 05:16:55 <buildmaster> any/fcitx5-table-extra is broken (says rechenknecht): https://archlinux32.org
[07:03:31] <KitsuWhooa> this is all it does at the moment
[07:03:49] <KitsuWhooa> I'll disable it and then run a sanity check, so we'll see
[07:04:02] <KitsuWhooa> I just hope it doesn't permanently remove an ssh key or something
[07:04:16] <abaumann> yes, the arch32 keyring is not up to date on that build machine
[07:04:28] <abaumann> we can safely disable it.
[07:04:50] <KitsuWhooa> did you already disable it
[07:04:51] <KitsuWhooa> ?
[07:04:54] <abaumann> yep
[07:04:56] <KitsuWhooa> > Cannot find build slave "rechenknecht" in the database to disable.
[07:04:57] <KitsuWhooa> ah
[07:05:01] <KitsuWhooa> thanks!
[07:05:09] <abaumann> ./manage-slaves list
[07:05:12] <KitsuWhooa> yup
[07:05:22] <KitsuWhooa> I did that and it said "disabled" so I got confused
[07:05:29] <abaumann> if we do something, we should write cli tools in shell
[07:05:48] <abaumann> rechenknecht disabled sane
[07:06:03] <abaumann> the sane is relative and represents the perspective of the buildmaster, I suppose :-0
[07:06:07] <KitsuWhooa> hah
[07:06:22] <abaumann> it sets things to insane automatically
[07:06:30] <abaumann> but it has a limited number of conditions it checks
[07:06:32] <abaumann> IIRC
[07:08:27] <KitsuWhooa> Okay, yeah, the script worked fine. It passed the sanity check
[07:08:42] <abaumann> fine
[07:09:18] <KitsuWhooa> Do you know who wrote the buildmaster?
[07:09:19] <abaumann> my build slaves are a bigger issue, I have to set it up again. I basically lost a machine (build machine) and my web mirror (old hardware)
[07:09:28] <abaumann> yes, deep42thought :-)
[07:09:29] <KitsuWhooa> It sounds like it was deep42tought
[07:09:30] <KitsuWhooa> ah
[07:09:46] <abaumann> eveery time I start to dable with it, I make something worse or I break things
[07:09:49] <KitsuWhooa> as for the builders, ouch
[07:09:54] <abaumann> yep
[07:10:16] <KitsuWhooa> I'm trying to figure out how it works, but the queries are super complex
[07:10:33] <abaumann> and they are a mixture of SQL and shell, I know.
[07:10:47] <abaumann> mysql doesn't help either
[07:11:05] <abaumann> and it represents graphs in a relative database, which is never an easy thing to do
[07:11:36] <KitsuWhooa> agreed
[07:12:03] <abaumann> I would prefer to have simple managerial scripts like move-package-from-repo-to-repo, here-I-have-a-prebuilt-package-please-add-it-to-the-buildmaster
[07:12:08] <abaumann> and things like that.
[07:12:19] <KitsuWhooa> I mean, I'm sure it can be done
[07:12:28] <abaumann> because then we don't have to fully understand the automatic stuff, which actually works fine
[07:13:10] <abaumann> there are minor issues with double state git-states since the package git move (for instance in 'filesystem') where we have to respect the date when a package is both in 'x86_64' and 'noarch' in the state db upstream.
[07:14:05] <KitsuWhooa> mhm
[07:14:14] <abaumann> now that even Debian is considering dropping 32-bit (e.g. the bootability and the ISO, not chrooting or multilib 32-bit), things don't get exactly easier either. :-)
[07:14:33] <KitsuWhooa> I did not know that
[07:16:04] <abaumann> https://www.theregister.com
[07:16:04] <phrik> Title: Debian preps ground to drop 32-bit x86 as a separate edition • The Register (at www.theregister.com)
[07:17:11] <KitsuWhooa> surely it's not that much extra work to build the isos when they're going to support chroots
[07:17:17] <KitsuWhooa> the packages will need to be built anyway
[07:17:41] <KitsuWhooa> but I'm just speaking without knowing anything about their process
[07:18:32] <abaumann> basically kernel, ramdisk, bootloader, ISO mastering, yes
[07:19:08] <abaumann> this is not the problem, but if a architecture is no longer tier 1, it usually gets also less love :-)
[07:19:15] <KitsuWhooa> yeah
[07:19:28] <abaumann> that said: we should not copy patches from Debian anyway. :->
[07:19:36] <KitsuWhooa> why not? :p
[07:19:53] <abaumann> we loose the ability to fix things ourselves
[07:20:02] <KitsuWhooa> I'm not sure I understand
[07:20:03] <abaumann> better: the skills
[07:20:18] <KitsuWhooa> I think we have enough broken things to want to take as much load off as possible
[07:20:30] <abaumann> :-)
[07:20:31] <KitsuWhooa> SDL is still broken last I checked, even on penium4
[07:20:34] <KitsuWhooa> *pentium4
[07:20:41] <KitsuWhooa> and I bet I can't build it because python is broken
[07:20:48] <abaumann> that is a simple SSE patch not applied issue..
[07:20:56] <KitsuWhooa> on pentium4?
[07:21:02] <KitsuWhooa> usually the issue is SSE2
[07:21:35] <abaumann> ..or a much worse upstream: the flag is there but code uses SSE2 without respecting the flag
[07:21:44] <KitsuWhooa> I'd hope not
[07:21:48] <abaumann> then you need exactly the mentioned skills :-)
[07:22:11] <KitsuWhooa> I'd like to think I can fix some of these issues
[07:22:20] <KitsuWhooa> ...as long as buildmaster builds the packages :p
[07:22:47] <abaumann> as long no python is involved - probably yes :-)
[07:23:01] <KitsuWhooa> well, cmake is broken and it wanted python when I tried building it
[07:23:09] <KitsuWhooa> so anything that uses cmake is currently unbuildable
[07:23:11] <abaumann> uh. yeah.
[07:23:12] <KitsuWhooa> SDL uses cmake last I checked
[07:23:24] <abaumann> python is a show-stopper in many areas
[07:23:41] <abaumann> since my last bootstrapping trial last year it's pretty much in shambles
[07:23:44] <KitsuWhooa> I am currently stuck trying to build python-trove-classifiers which for some rason demands pip
[07:23:49] <KitsuWhooa> *reason
[07:24:14] <KitsuWhooa> I could build pip locally (with the custom diff'd PKGBUILD concatenated), but buildmaster just doesn't want to try building it
[07:24:27] <abaumann> using pip is not an option
[07:24:40] <abaumann> it draws in either old 32-bit modules or not 32-bit modules at all
[07:24:42] <KitsuWhooa> once python-trove-classifiers is fixed, the jaraco stuff can be built
[07:24:50] <KitsuWhooa> I don't think it actually wants to use pip
[07:24:54] <KitsuWhooa> it just probes it/checks it for something
[07:24:56] <KitsuWhooa> let me find the logs
[07:25:12] <abaumann> one has to bootstrap python, then python-bootstrap and then slowly all essentials tools like python-pip, python-setuptools etc.
[07:25:31] <KitsuWhooa> I do have python-setuptools and python-setuptools-scm in build-support through python-bootstrap
[07:25:51] <KitsuWhooa> https://buildmaster.archlinux32.org
[07:26:16] <abaumann> python-bootstrap downloads the binary seed of core packages and then provides some shim packages for modules which can then be properly rebuild.
[07:26:40] <abaumann> the problem is: the binary seed is too small, some really stupid modules (functools) are now needed in places they don't belong
[07:26:44] <KitsuWhooa> Yeah. I added some more packages to it for arch32 because I couldn't untangle the mess otherwise
[07:27:07] <KitsuWhooa> ...I wonder if it's trying to use pip because python-calver doesn't work
[07:27:14] <abaumann> setuptools.in
[07:27:15] <abaumann> staller is deprecated. Requirements should be satisfied by a PEP 517 installer.
[07:27:32] <abaumann> nice, setuptools at least WAS working. so it had to be deprecated of couse.
[07:27:34] <abaumann> *course
[07:27:34] <KitsuWhooa> I noticed that, but I don't think we can do anything about it
[07:28:03] <KitsuWhooa> it also complained about wheel not being present, which is why I added it to the deps
[07:28:13] <KitsuWhooa> but it doesn't seem to have helped
[07:28:16] <abaumann> python-wheel should be in python-bootstrap as a shim
[07:28:21] <KitsuWhooa> it is
[07:28:26] <KitsuWhooa> it just wasn't getting installed when buildin this
[07:28:28] <KitsuWhooa> *building
[07:28:31] <abaumann> ah, maybe the check for it is bad
[07:28:44] <abaumann> you can always make a patch "pretending it found something" :-)
[07:28:50] <KitsuWhooa> ...good point
[07:29:24] <abaumann> I'm still searching good bootstrapping documnetation upstream and from Python itself.
[07:29:36] <KitsuWhooa> I'm brute forcing through it
[07:29:40] <KitsuWhooa> which I can definitely not recommend
[07:29:44] <abaumann> If - any - then it is in a mailing list of another guy struggling and finding it out the hard way - I'm afraid.
[07:29:49] <KitsuWhooa> also speaking of cmake, buildmaster is trying to build it
[07:29:58] <KitsuWhooa> can't wait for it to fail :D
[07:30:06] <abaumann> sometimes python support can just be disabled or patched out.
[07:30:21] <KitsuWhooa> yeah, but then there are other packages that fail because they need python
[07:30:28] <abaumann> I don't see any reason why cmake should depend on python - but for some obscure feature like python bindings or documentation
[07:30:32] <KitsuWhooa> so it is going to need to be fixed
[07:30:35] <KitsuWhooa> no matter what
[07:30:39] <abaumann> true
[07:30:46] <abaumann> meson would come to my mind
[07:30:53] <KitsuWhooa> yes
[07:31:00] <KitsuWhooa> I was thinking of the gio scanner stuff
[07:31:04] <KitsuWhooa> but meson is even more important
[07:31:12] <abaumann> yeah, agreed, python is essential for a modern linux system somehow.
[07:31:18] <abaumann> sad - but reality.
[07:31:25] <KitsuWhooa> I don't think it's a bad thing personally
[07:31:38] <abaumann> it's just bad made, my personal opinion.
[07:31:49] * KitsuWhooa shrugs
[07:31:50] <abaumann> an alternative implementation of python would help.
[07:31:57] <abaumann> bootstrappable.org
[07:31:57] <KitsuWhooa> there are a few
[07:32:07] <abaumann> having a second implementation of a language is never a bad thing.
[07:32:15] <abaumann> go has two, C++ has many, C has many
[07:32:26] <abaumann> just python, rust, perl have a single implementation
[07:32:47] <abaumann> and if that one causes trouble when bootstrapping or porting, you basically have to either fix it or roll your own
[07:33:08] <abaumann> very few people understand the importance of bootstrappability, sadly :-(
[07:33:15] <KitsuWhooa> I mean
[07:33:27] <KitsuWhooa> I didn't even think about it before I tried fixing python
[07:33:39] <abaumann> exactly
[07:33:55] <abaumann> but if more people would try, they would see the mess we are in :-)
[07:34:16] <KitsuWhooa> > ModuleNotFoundError: No module named 'calver'
[07:34:21] <KitsuWhooa> okay I think that's why it's trying to use pip
[07:34:41] <KitsuWhooa> or not
[07:34:55] <KitsuWhooa> > python-calver-2022.06.26-1.1
[07:34:57] <KitsuWhooa> 2022?!
[07:35:03] <abaumann> sweet :-)
[07:35:13] <abaumann> welcome to the python dependency hell ;-)
[07:35:25] <KitsuWhooa> I've been enjoying my stay since December 2023 :p
[07:35:36] <abaumann> :-)
[07:35:55] <KitsuWhooa> I think you broke something
[07:36:14] <KitsuWhooa> https://tasossah.com
[07:36:15] <phrik> Title: schedule-for-rebuild (at tasossah.com)
[07:36:17] <abaumann> that's abolutely very likely :-)
[07:36:35] <abaumann> uh.
[07:36:40] <abaumann> the pkginfo cache
[07:36:48] <abaumann> yep, I'll have a look
[07:36:53] <KitsuWhooa> thanks :0
[07:36:54] <KitsuWhooa> * :)
[07:36:58] <abaumann> could easily be a fall-out from yesterday's move
[07:38:11] <KitsuWhooa> Yeah, I think so. It worked yesterday
[07:39:06] <abaumann> I switched from php in apache to fpm fastcgi
[07:39:15] <abaumann> and I forgot some configuration maybe
[07:39:24] <KitsuWhooa> Ah, yeah
[07:39:24] <KitsuWhooa> nginx?
[07:39:29] <abaumann> no, apache
[07:39:31] <KitsuWhooa> oh
[07:39:34] <KitsuWhooa> I don't know then :p
[07:39:46] <KitsuWhooa> I could never configure apache properly
[07:39:50] <abaumann> that's something I noticed a lot lately.
[07:40:02] <abaumann> apache falls behind nginx
[07:40:13] <abaumann> in terms of people knowing it
[07:40:20] <abaumann> they are quite similar actually
[07:40:29] <abaumann> just the configuration is a little bit different
[07:40:33] <abaumann> the concepts are the same
[07:40:36] <KitsuWhooa> I think configuring nginx is considerably easier
[07:40:53] <abaumann> for easy cases, yes
[07:41:09] <KitsuWhooa> even for complicated things
[07:41:59] <abaumann> what I never liked about nginx is it's understanding of modularization, I personally thinkg apache modules are superior.
[07:42:10] <abaumann> functionallity-wise they do pretty much the same
[07:42:25] <abaumann> I never tried modern HTTP/2 or HTTP/3 stuff though
[07:42:44] <KitsuWhooa> all you have to do is add a keyword to enable http2 in nginx :p
[07:43:12] <KitsuWhooa> or, well, used to
[07:43:16] <KitsuWhooa> it's on by default now I think
[07:46:08] <abaumann> <FilesMatch \.php$>
[07:46:08] <abaumann> SetHandler "proxy:unix:/run/php74-fpm/php-fpm.sock|fcgi://localhost"
[07:46:11] <abaumann> </FilesMatch>
[07:46:12] <abaumann> strange
[07:47:24] <abaumann> mmh. how can I test pkginfo computation anf fetches _standalone_ without the buildmaster
[07:47:27] <abaumann> ?
[07:47:33] <abaumann> this is the problem, lack of modularization.
[07:47:39] <KitsuWhooa> one moment
[07:47:45] <abaumann> get-source-fino
[07:47:50] <abaumann> did I write something?
[07:48:22] <abaumann> ./get-source-info python-calver extra d6f050bc1218ca255c99f38dd3d32c2267a4eff3 0000000000000000000000000000000000000000
[07:48:25] <abaumann> gzip: stdin: not in gzip format
[07:48:27] <abaumann> tar: Child returned status 1
[07:48:30] <abaumann> tar: Error is not recoverable: exiting now
[07:48:32] <abaumann> aha
[07:48:39] <KitsuWhooa> my builders have been doing that too
[07:49:03] <abaumann> lacking error handling
[07:49:08] <KitsuWhooa> you can try something like
[07:49:09] <KitsuWhooa> curl -LSs https://buildmaster.archlinux32.org
[07:49:26] <KitsuWhooa> just loading that in your browser spews out php
[07:49:34] <abaumann> ah, right.
[07:49:36] <abaumann> perfect.
[07:49:51] <KitsuWhooa> (I use bash -x a lot for the tools to figure out what they do without reading the code)
[07:49:57] <KitsuWhooa> bash -x `which schedule-for-rebuild` -f -w -j -p '^python-calver$'
[07:50:00] <abaumann> so, the php execution is checked before rewrite?
[07:50:02] <abaumann> mmh.
[07:50:11] <abaumann> bash -x is really really nice :-)
[07:50:15] <KitsuWhooa> indeed
[07:51:11] <KitsuWhooa> > <FilesMatch \.php$>
[07:51:16] <KitsuWhooa> there is no .php there
[07:51:18] <KitsuWhooa> so maybe that's why?
[07:51:31] <KitsuWhooa> there, as in, the url
[07:51:36] <KitsuWhooa> or is it a rewrite
[07:51:36] <abaumann> there is: pkginfo.php
[07:51:38] <KitsuWhooa> ah
[07:51:39] <abaumann> yes.
[07:51:48] <abaumann> and that's what's puzzling me
[07:52:03] <abaumann> services.d/pkginfo.conf has a FilesMatch
[07:52:04] <KitsuWhooa> yeah, same thing https://buildmaster.archlinux32.org
[07:52:08] <abaumann> maybe I need a LocationMatch
[07:52:22] <KitsuWhooa> is it possibly a separate vhost?
[07:52:26] <KitsuWhooa> than the one you're looking at?
[07:52:38] <abaumann> no, things are organized as follows on the buildmaster:
[07:52:46] <abaumann> sites.d and sites-ssl.d do the vhost stuff
[07:53:03] <abaumann> services.d are included there and hold the configuration of fluxbb, flyspray, pkginfo, etc.
[07:53:14] <abaumann> in order not to do copy-paste-configurations :->
[07:53:22] <KitsuWhooa> I see
[07:53:59] <abaumann> so. much better
[07:54:14] <abaumann> silly me: I need a LocationMatch on rewrites, not FileMatch (because there are no files) :-)
[07:54:29] <abaumann> curl -LSs https:// works now
[07:54:31] <KitsuWhooa> nice, it works
[07:54:32] <abaumann> ./get-source-info python-calver extra d6f050bc1218ca255c99f38dd3d32c2267a4eff3 0000000000000000000000000000000000000000
[07:54:33] <KitsuWhooa> well
[07:54:34] <KitsuWhooa> "works"
[07:54:35] <abaumann> curl: (22) The requested URL returned error: 500
[07:54:38] <abaumann> well.
[07:54:41] <KitsuWhooa> yeah, that happened before too
[07:54:48] <abaumann> what do you want, the php code gets executed ;-)
[07:55:03] <KitsuWhooa> https://buildmaster.archlinux32.org
[07:55:04] <abaumann> no, before you got badly written php code (from me) ;-)
[07:55:05] <KitsuWhooa> this is new though
[07:55:12] <abaumann> uh
[07:55:14] <abaumann> community?
[07:55:19] <abaumann> that's not good
[07:55:24] <KitsuWhooa> I do not know
[07:55:36] <abaumann> but maybe the buildmaster still wants to unquue old community things
[07:55:37] <KitsuWhooa> schedule-for-rebuild tries that first, it fails, and then it does the one in extra
[07:55:38] <KitsuWhooa> which succeeds now
[07:55:40] <KitsuWhooa> yeah
[07:55:43] <KitsuWhooa> I think that's the case
[07:55:44] <abaumann> ah. ok.
[07:56:12] <abaumann> ah.
[07:56:13] <KitsuWhooa> we'll see if it tries to build it
[07:56:16] <abaumann> upstream-package, the same problem
[07:56:34] <KitsuWhooa> ==> Making package: python-calver 2022.06.26-2.0 (2024-01-12T07:55:38 UTC)
[07:56:37] <abaumann> due to bandwith limitations upstream we have to create a cache of upstream packages.
[07:56:58] <KitsuWhooa> why is it building 2022...
[07:57:02] <KitsuWhooa> is that the version upstream too?
[07:57:14] <KitsuWhooa> yes it is
[07:57:19] <KitsuWhooa> oh well
[07:57:22] <abaumann> yep
[07:57:41] <abaumann> the module didn't change since then. fine. and now has most likely a forced rebuild in the buildmaster queue
[07:57:42] <KitsuWhooa> well, it's not looking good. It failed to build under build-support
[07:58:01] <KitsuWhooa> it just failed
[07:58:09] <KitsuWhooa> https://buildmaster.archlinux32.org
[07:58:25] <KitsuWhooa> > ModuleNotFoundError: No module named 'iniconfig'
[07:58:28] <KitsuWhooa> OH COME ON
[07:58:43] <KitsuWhooa> iniconfig is what needs python-trove-whatever, which needs calver
[07:58:50] <abaumann> cycle? :-)
[07:58:53] <KitsuWhooa> yes.
[07:59:00] <KitsuWhooa> time to add another package into bootstrap.
[07:59:10] <abaumann> welcome do the even deeper hell of cyclic python dependencies. ;-)
[08:00:13] <abaumann> -rw-r--r-- 1 http http 0 Jan 12 08:54 python-calver-d6f050bc1218ca255c99f38dd3d32c2267a4eff3.tar.gz
[08:00:23] <abaumann> in upstream-packages cache, yep. have to clean that one...
[08:00:32] <KitsuWhooa> there's a few more old packages like that
[08:00:34] <KitsuWhooa> how do you delete it?
[08:00:47] <abaumann> rm?
[08:00:52] <KitsuWhooa> as in, from where
[08:00:59] <KitsuWhooa> sorry, I'm not familiar with the cache
[08:01:00] <abaumann> ah, on the buildmaster itself
[08:01:10] <abaumann> /srv/http/upstream-packages and /srv/http/pkginfo
[08:01:16] <KitsuWhooa> perfect
[08:01:17] <KitsuWhooa> thanks
[08:01:23] <abaumann> it's sort of a - aeh - new feature :-)
[08:01:41] <KitsuWhooa> also
[08:01:49] <abaumann> curl: (22) The requested URL returned error: 500
[08:01:55] <abaumann> mmh. better. or worse.
[08:01:56] <KitsuWhooa> do you know if there's a way to have buildmaster pick up changes in git.archlinux32.org/packages?
[08:02:01] <KitsuWhooa> without waiting for it to update everything
[08:02:20] <KitsuWhooa> ./get-package-updates takes ages
[08:02:23] <abaumann> -rw-r--r-- 1 http http 0 Jan 12 09:01 python-calver-d6f050bc1218ca255c99f38dd3d32c2267a4eff3.tar.gz
[08:02:30] <abaumann> yes, I know.
[08:02:47] <abaumann> There are two issues there: pkginfo didn't get cached
[08:02:57] <abaumann> this adds 2-5 seconds per pkginfo call
[08:03:17] <abaumann> and second we go through _all_ disabled packages (for instance all Haskell modules) _every_ time
[08:03:36] <KitsuWhooa> yup
[08:03:38] <abaumann> the problem is, just because we ignore a package, doesn't mean we don't have to compute the dependencies.
[08:03:59] <abaumann> the pkginfo cache is not that stable yet - as we see
[08:04:12] <abaumann> but it brings down the execution time from hours to 30 minutes or so
[08:04:22] <KitsuWhooa> mhm
[08:05:06] <abaumann> the ignoring packages mechanism has never been meant to be used for something that low-level and big as Haskell
[08:05:16] <abaumann> more for a funny desktop application or so.
[08:05:21] <KitsuWhooa> mhm
[08:05:25] <KitsuWhooa> oh well...
[08:06:46] <abaumann> where is the upstream-packages.php script?
[08:06:52] <KitsuWhooa> I have no idea
[08:06:56] <abaumann> this is a retorical question
[08:07:05] <abaumann> it would explain the error 500 pretty well :-)
[08:07:15] <KitsuWhooa> wouldn't that be a 404?
[08:09:19] <abaumann> Directory /srv/http/upstream-packages/ RewriteRule ^(.*)$ /upstream-packages.php?$1 [NC,QSA,L]
[08:10:26] <abaumann> ah
[08:10:30] <abaumann> /srv/http
[08:11:20] <abaumann> php74-curl would be a good idea :-)
[08:11:56] <KitsuWhooa> indeed
[08:12:46] <abaumann> tar tvf python-calver-ef9af9cee6798d2329b9e3e81612fac37b3f6b94.tar.gz
[08:12:46] <abaumann> drwxrwxr-x root/root 0 2023-04-06 20:39 python-calver-ef9af9cee6798d2329b9e3e81612fac37b3f6b94/
[08:12:49] <abaumann> -rw-rw-r-- root/root 897 2023-04-06 20:39 python-calver-ef9af9cee6798d2329b9e3e81612fac37b3f6b94/PKGBUILD
[08:12:52] <abaumann> better
[08:14:29] <abaumann> [Fri Jan 12 09:14:15.897547 2024] [proxy_fcgi:error] [pid 237477] [client 83.150.2.48:57928] AH01071: Got error 'PHP message: ERROR: https://gitlab.archlinux.org returned unexpected HTTP code: 404'
[08:15:45] <abaumann> https://gitlab.archlinux.org
[08:15:45] <phrik> Title: Tags · Arch Linux / Packaging / Packages / python-calver · GitLab (at gitlab.archlinux.org)
[08:15:54] <abaumann> I fail to see a tag SHA d6f050bc1218ca255c99f38dd3d32c2267a4eff3
[08:17:43] <abaumann> I really hope upstream migrated _all_ commits
[08:21:01] <abaumann> git clone https://gitlab.archlinux.org
[08:21:02] <phrik> Title: Arch Linux / Packaging / State · GitLab (at gitlab.archlinux.org)
[08:21:10] <abaumann> more state/extra-any/python-calver
[08:21:13] <abaumann> python-calver 2022.06.26-2 2022.06.26-2 ef9af9cee6798d2329b9e3e81612fac37b3f6b94
[08:21:18] <abaumann> pkgctl repo clone --protocol=https python-calver
[08:21:23] <abaumann> git -C python-calver show-ref --tags
[08:21:29] <abaumann> 9911e39b8888f33173566eacca1bba73d20ca9d4 refs/tags/2021.7.30-1
[08:21:30] <abaumann> 34e0d5bde36c2e5e852094b4a1d430a3f44baadc refs/tags/2022.06.26-1
[08:21:30] <abaumann> ef9af9cee6798d2329b9e3e81612fac37b3f6b94 refs/tags/2022.06.26-2
[08:21:45] <abaumann> but the buildmaster insists on a commit d6f050bc1218ca255c99f38dd3d32c2267a4eff3
[08:22:04] <abaumann> probably pointing into the big old all-in-one git repo
[08:22:45] <abaumann> upstream-packages.php is just handling the new gitlab case, so.
[08:23:10] <abaumann> Easiest is to adapt that one.. given the old git repo is still available somwhere read-only
[08:23:45] <KitsuWhooa> is it okay if I run ./get-package-updates ?
[08:23:53] <KitsuWhooa> or is it going to get in the way of what you're working on?
[08:23:58] <abaumann> no problem.
[08:24:04] <KitsuWhooa> alright
[08:24:12] <abaumann> it will just fail in python-calver, and probably stop then.
[08:24:26] <abaumann> but as it takes so long, it might be fixed till then :-)
[08:25:10] <KitsuWhooa> I've seen other packages like this, so it probably won't fial
[08:25:12] <KitsuWhooa> *fail
[08:25:33] <abaumann> yes.
[08:26:31] <abaumann> so, we either have to find the old git-svn repo mirror or make one with the contents before the git migration upstream
[08:26:45] <KitsuWhooa> can we not remove these from buildmaster entirely?
[08:26:52] <abaumann> no
[08:27:12] <abaumann> because it might be we have to build an older version first to fullfil some dependency before we can build a newer version
[08:27:19] <KitsuWhooa> ah...
[08:27:27] <abaumann> and I wouldn't try to mess with the git shas in the buildmaster db.
[08:27:33] <KitsuWhooa> fair
[08:28:09] <abaumann> but I would really have hoped the git migration upstream would not have had such implications.
[08:31:02] <abaumann> didn't we have copies of packages and community as local git workspaces (from the git-svn bridge)? why are not those taken?
[08:32:48] <abaumann> https://github.com and https://github.com
[08:33:01] <abaumann> ok, we can link to those archived repos in uptream-packages.php
[08:33:12] <abaumann> in case gitlab new one are not found
[08:34:27] <KitsuWhooa> nice
[08:37:41] <abaumann> python-calver is not there?
[08:38:11] <KitsuWhooa> https://github.com
[08:38:41] <abaumann> oeh.
[08:38:51] <abaumann> I just cloned the repos and there they are missing?
[08:39:10] <abaumann> ah. not finished yet.
[08:39:30] <abaumann> so. I think its best not to link to github.com, but to get them from a local repo
[08:39:42] <KitsuWhooa> probably, yeah
[08:41:53] <KitsuWhooa> oops, it just failed
[08:41:57] <KitsuWhooa> primesieve c36ad68718355746233006b15d5435a446481aa7 0000000000000000000000000000000000000000 extra "make_source_info" did not return a "pkgbase" - eh, what?
[08:41:57] <KitsuWhooa> >curl: (22) The requested URL returned error: 500<
[08:42:22] <KitsuWhooa> right before python-*...
[08:42:29] <abaumann> [root@buildmaster upstream-packages]# l
[08:42:34] <abaumann> ls -lal primesieve-4771dac82bf2c345835039e920f2b96f64946fbe.tar.gz
[08:42:39] <abaumann> probably the same root cause
[08:42:56] <KitsuWhooa> and there's no way to ignore errors in get-package-updates :/
[08:43:10] * KitsuWhooa sighs
[08:43:24] <abaumann> not really. the code is a little bit on the sunshine case side
[08:43:53] <KitsuWhooa> I don't understand though
[08:43:56] <abaumann> I think, it only happened because old package revisions got forced builds
[08:43:57] <KitsuWhooa> It ran a few days ago just fine
[08:44:05] <abaumann> mmh.
[08:45:05] <KitsuWhooa> oh and now it won't re-run because "nothing changed"
[08:45:38] <KitsuWhooa> oh no, nevermind, I did something silly
[09:27:44] <abaumann> get-package-updates passed
[09:28:01] <KitsuWhooa> yup
[09:31:23] <KitsuWhooa> ModuleNotFoundError: No module named 'iniconfig'
[09:31:24] * KitsuWhooa sighs
[09:32:02] <KitsuWhooa> it did build, but it failed in check()
[09:33:56] <abaumann> forget checks
[09:34:02] <KitsuWhooa> I'm about to unset check
[09:34:02] <KitsuWhooa> :p
[09:34:10] <abaumann> just do on unset check and unset checkdepends
[09:34:16] <abaumann> makes your life much easier :-)
[09:34:24] <KitsuWhooa> uyp
[09:34:25] <KitsuWhooa> yup
[09:34:47] <KitsuWhooa> time for another get-package-updates
[09:35:57] <abaumann> \o/
[09:41:51] <abaumann> electron26 electron27 ui.
[09:44:04] <KitsuWhooa> Yeah I don't even think about those :p
[09:44:11] <KitsuWhooa> Anyway, thank you for the help. Much appreciated
[09:44:15] <abaumann> no problem
[09:44:17] <KitsuWhooa> I'll head off for now and hopefully this mess is resolved
[09:45:45] <abaumann> ok.
[09:46:25] <abaumann> me also gone for lunches now.. cu :-)
[09:46:48] <KitsuWhooa> see ya
[09:47:42] <KitsuWhooa> > +# Try to break the dependency cicle for iniconfig
[09:47:44] <KitsuWhooa> I see I made a typo
[09:47:47] <KitsuWhooa> oh well
[11:03:32] -!- ssserpent has joined #archlinux32
[11:26:52] -!- ssserpent has quit [Quit: WeeChat 4.1.2]
[11:43:08] <abaumann> python-setuptools-scm: ModuleNotFoundError: No module named 'jaraco.functools'
[11:43:23] <abaumann> at least one build machine (eurobuild3) sort of builds packages again on my side.
[11:54:17] <abaumann> oh, it built a python-trove-classifiers
[11:54:33] <abaumann> not all hope is lost (yet) ;-)
[11:57:39] <abaumann> There is a screen on: 1847307.pts-1.buildmaster (Attached)
[11:57:39] <abaumann> 1 Socket in /run/screens/S-master.
[11:57:52] <abaumann> oups, I closed that one because I thought the buildmaster is creating one.
[11:58:00] <abaumann> sorry. but get-package-updates was finished
[12:25:45] <abaumann> error: sudo: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust
[12:25:55] <abaumann> oups, also my build machines expose pgp errors
[12:54:48] -!- abaumann has quit [Quit: leaving]
[13:19:54] -!- abaumann has joined #archlinux32
[13:19:55] <buildmaster> Hi abaumann!
[13:19:55] <buildmaster> !rq abaumann
[13:19:55] <phrik> buildmaster: <abaumann> nono, it's self-cooking :-)
[13:37:10] <abaumann> rsync: [receiver] mkstemp "/.go-ethereum-1.13.10-1.0-i686.pkg.tar.zst.NW4upI" (in transfer32) failed: Permission denied (13)
[13:37:13] <abaumann> rsync: [receiver] mkstemp "/.go-ethereum-1.13.10-1.0-i686.pkg.tar.zst.sig.sdkHFN" (in transfer32) failed: Permission denied (13)
[13:37:16] <abaumann> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1336) [sender=3.2.7]
[13:37:19] <abaumann> is this normal? or good?
[14:26:16] <KitsuWhooa> <abaumann> python-setuptools-scm: ModuleNotFoundError: No module named 'jaraco.functools'
[14:26:25] <KitsuWhooa> Yeah I've been untangling that
[14:26:55] <KitsuWhooa> <abaumann> oh, it built a python-trove-classifiers <-- awesome
[14:27:18] <KitsuWhooa> <abaumann> sorry. but get-package-updates was finished <-- no worries. I just don't trust my Internet here to not die
[14:27:47] <KitsuWhooa> <abaumann> is this normal? or good? <-- it usually means it can't write to the destination directory
[14:28:02] <KitsuWhooa> First it tries to make a temp file, which is what fails
[14:28:10] <KitsuWhooa> But it might still succeed afterwards
[14:29:10] <abaumann> the packages appear on the buildmaster software archive, so it's just a glitch, I think.
[14:49:06] <KitsuWhooa> python-iniconfig is being built now
[14:49:08] <KitsuWhooa> fingers crossed
[14:50:12] <KitsuWhooa> I think it's going to fail because I need to build python-hatchling first
[14:51:33] <KitsuWhooa> yeah, iniconfig failed
[14:52:15] <KitsuWhooa> python-hatchling built!
[14:53:15] <KitsuWhooa> yeah iniconfig failed because of ModuleNotFoundError: No module named 'hatchling'
[14:53:24] <KitsuWhooa> if I queue up iniconfig again it should build
[14:57:45] <KitsuWhooa> ERROR Missing dependencies: hatch-vcs
[14:57:46] <KitsuWhooa> huh?
[14:59:00] <KitsuWhooa> okay I need python-hatch-vcs
[15:01:27] <KitsuWhooa> uh oh, it's not queueing it up
[15:16:18] <KitsuWhooa> Why does buildmaster not try to build python-hatch-vcs....
[15:16:26] * KitsuWhooa sighs
[15:16:37] <KitsuWhooa> It's so close
[15:26:07] <KitsuWhooa> the good news is that a bunch of other python packages are building now
[15:29:49] -!- epony has quit [Remote host closed the connection]
[15:30:55] <KitsuWhooa> aaand buildmaster went insane
[15:35:29] <KitsuWhooa> looks like a package made it into the master mirror that's not in the db
[15:36:14] <KitsuWhooa> i486/extra-staging python-ziafont-0.6-1.0
[15:40:53] -!- epony has joined #archlinux32
[15:43:10] <KitsuWhooa> abaumann: if you have time, please have a look. I have no idea how to fix this
[15:43:18] <KitsuWhooa> it looks like something went wrong when the package was getting uploaded
[15:44:08] <KitsuWhooa> there's a pending query from intention.9 which I think is meant to return the assignment to fix it, but I don't know how to try running it again
[15:58:57] <abaumann> mmh. the intension is away now.
[15:59:03] <abaumann> maybe it got executed?
[16:28:53] <abaumann> The following packages in i486/extra-staging are missing from the database or vice versa:
[16:28:56] <abaumann> in_repository python-ziafont-0.6-1.0-any.pkg.tar.zst
[16:29:03] <abaumann> yep. that's an inconsistency between database and mirror
[16:29:11] <abaumann> and the database file for pacman
[16:29:17] <abaumann> the naming is really not stelar.
[16:30:55] <abaumann> so I usually do a bunch of cd /srv/http/mirror/mirror.archlinux32.org/i486/extra-staging
[16:31:03] <abaumann> repo-add extra-staging.db.tar.gz python-ziafont-0.7-1.0-any.pkg.tar.zst
[16:31:10] <abaumann> move things around like broken links etc.
[16:31:16] <abaumann> in all kind of directions
[16:31:22] <abaumann> till the buildmaster is happy again
[16:31:45] <abaumann> this is still a race condition between file operations, sftp uploads of files, database operations and pacman-repo-operations
[16:32:48] <abaumann> now in this case it seems it is on the mirror and in the pacman database but not in the database.
[16:33:16] <abaumann> as manipulating the database is a nono (at least for me), I usually prefer to remove the file from the pacman db files and the repos (as well as the pool directory).
[16:33:31] <abaumann> repo-remove extra-staging.db.tar.gz python-ziafont
[16:34:17] <abaumann> so the module has to be built again, because now it is version 0,6 again and I had to remove version 0.7
[16:34:28] <abaumann> cd ../../pool/
[16:34:31] <abaumann> rm -f python-ziafont-0.7-1.0-any.pkg.tar.zst.sig python-ziafont-0.7-1.0-any.pkg.tar.zst
[16:34:52] <abaumann> (instead of rm a move to a safe space might be better, in case of errors)
[16:35:20] <abaumann> yeah, and 0.6 is missing in the pacman db
[16:35:52] <abaumann> repo-add extra-staging.db.tar.gz python-ziafont-0.6-1.0-any.pkg.tar.zst
[16:36:39] <abaumann> same goes for i686 and pentium4 of course
[16:41:12] <abaumann> ok, fixed.
[16:41:35] <abaumann> but this is really a problem. it means, nothing was built (otherwise we would not have had a sane buildmaster).
[16:58:34] -!- abaumann has quit [Quit: leaving]
[18:00:56] -!- ssserpent has joined #archlinux32
[18:14:39] -!- drathir_tor has quit [Remote host closed the connection]
[18:20:19] -!- drathir_tor has joined #archlinux32
[18:58:02] -!- ssserpent has quit [Quit: WeeChat 4.1.2]
[18:58:55] -!- drathir_tor has quit [Ping timeout: 240 seconds]
[19:11:23] -!- drathir_tor has joined #archlinux32
[21:25:25] <KitsuWhooa> abaumann: thank you for fixing it
[21:25:45] <KitsuWhooa> I tried moving stuff around in the mirror but while that fixed one error it seemed to cause another and I was too worried of breaking things badly so I undid everything
[21:25:52] <KitsuWhooa> and yeah I just mv'd things away instead of rm'ing them
[23:43:44] <KitsuWhooa> it's still not trying to build python-hatch-vcs
[23:44:00] <KitsuWhooa> I wonder if making a dummy mod PKGBUILD will convince it to try again