#archlinux32 | Logs for 2022-07-04

Back
[07:20:08] -!- ejjdhfjsu has joined #archlinux32
[07:26:14] -!- petris has quit [*.net *.split]
[07:26:14] -!- JerryXiao has quit [*.net *.split]
[07:26:14] -!- KitsuWhooa has quit [*.net *.split]
[07:27:13] -!- KitsuWhooa has joined #archlinux32
[07:27:16] -!- petris has joined #archlinux32
[07:27:23] -!- JerryXiao has joined #archlinux32
[07:37:28] -!- joakim has quit [*.net *.split]
[14:16:48] -!- ejjdhfjsu has quit [Remote host closed the connection]
[14:20:43] <deep42thought> abaumann: How did you add the mingw-w64-* packages to build-support? Did you use some script? If so, this script missed to add them to the database. And, IMHO, disabling the sanity-check to "fix" this is the wrong approach - in this case, we can dispose the complete concept of sanity checks, just hope the best and most probably let the repository and database diverge more and more.
[14:27:03] <deep42thought> also, the versions look odd to me: two packages are 5.0.3-1 and one is 7.2.0 - is this really, what you intended?
[16:31:25] -!- GNUtoo has quit [Ping timeout: 268 seconds]
[16:32:41] -!- GNUtoo has joined #archlinux32
[17:06:57] -!- GNUtoo has quit [Remote host closed the connection]
[17:07:21] -!- GNUtoo has joined #archlinux32
[17:32:38] -!- GNUtoo_ has joined #archlinux32
[17:33:05] -!- GNUtoo has quit [Remote host closed the connection]
[21:00:18] -!- lithiumpt has quit [Ping timeout: 240 seconds]
[21:02:11] <deep42thought> ok, I fixed the db
[21:02:21] <deep42thought> ... and removed your quirk ;)
[21:07:28] -!- abaumann has joined #archlinux32
[21:07:29] <buildmaster> Hi abaumann!
[21:07:29] <buildmaster> !rq abaumann
[21:07:30] <phrik> buildmaster: <abaumann> singularity applied to software development - releases and changes get faster and faster.. till..
[21:07:49] <abaumann> deep42thought: the idea was to add a package built or manipulated outside of the build system (mingw)
[21:07:58] <abaumann> they have never been known to the buildmaster database
[21:08:05] <deep42thought> did you just use repo-add?
[21:08:23] <abaumann> I can not, because those take some base64 of an existing package.
[21:08:32] <deep42thought> I think the add build-support script (or how it's called) can handle adding "external" packages, too - or at least I once planned it :D
[21:08:32] <abaumann> the package never existed for the dataase
[21:08:39] <abaumann> ah. :-)
[21:08:46] <abaumann> on of TODO_XXXX? ;-)
[21:08:48] <deep42thought> ok, so maybe I never implemented that part:D
[21:08:53] <abaumann> never mind.
[21:09:03] * deep42thought whistle
[21:09:05] <abaumann> The other solution is to have a local repo on some build slaves.
[21:09:11] <abaumann> there I can add whatever I want. :-)
[21:09:22] <abaumann> anyway. I have trouble to get mingw up again.
[21:09:25] <abaumann> so wine.
[21:10:00] <abaumann> mingw64 is now a cross-compiler for 32-bit and 64-bit windows, but it stumbles at some GNU architecture triplets
[21:10:06] <deep42thought> I cannot find a related todo in bin/create-build-support-package
[21:10:13] <abaumann> oh. :-)
[21:10:20] <abaumann> then it's one of the imaginary ones.. ;-)
[21:10:56] <deep42thought> it's already there (I presume): create-build-support-package [options] --from $pkgname-$epoch:$pkgver-$pkgrel.$sub_pkgrel [--] $file1 $file2 $file3 ...
[21:11:18] <deep42thought> ah no, this will create a shim package
[21:11:40] <abaumann> In this case I had to copy i686 to i486/pentium4
[21:11:48] <abaumann> and take packages from archive.archlinux32.org
[21:12:11] <deep42thought> it should not matter, where you take the package from, as long as you have it already built
[21:12:15] <abaumann> They are from 2019, so I thought they must actually have been in the buildmaster dastabase
[21:12:22] <deep42thought> the only remaining question is, what git revision to put in
[21:12:31] <deep42thought> because all dependencies and alike will be created from that
[21:12:41] <abaumann> mmh. that's a tricky one.
[21:12:50] <deep42thought> yeah, they *have* been there, but they have been deleted in the meantime
[21:13:05] <abaumann> I can only think about going back in time and picking any commit corresponding to the moddate of the package.
[21:13:15] <abaumann> deleted?
[21:13:26] <deep42thought> the database removes old packages
[21:13:32] <abaumann> oh. it does?
[21:13:38] <deep42thought> yes, of course!
[21:13:43] <abaumann> then this might happen for any package which is not build in time.
[21:13:50] <deep42thought> no
[21:13:50] <abaumann> ah. but it's still in the archive..
[21:13:51] <abaumann> so..
[21:14:12] <deep42thought> it removes all packages, that are not on the mirror anymore, not on the deletion-list and not on the build-list
[21:14:23] <deep42thought> yes, the archive is not tracked by the database
[21:14:30] <abaumann> that's good.
[21:14:33] <deep42thought> otherwise the db would be even slowerd :D
[21:14:45] <abaumann> seems a sane policy.
[21:15:10] <abaumann> still, a little bit sad if the last compiler gets removed for bootstrapping a new one :-)
[21:15:25] <deep42thought> not sure, why it was deleted in the first place
[21:15:30] <deep42thought> it should not have been
[21:15:40] <deep42thought> maybe there were issues and I was annoyed and just deleted it ;)
[21:15:47] <abaumann> :-)
[21:20:54] -!- lithiumpt has joined #archlinux32
[21:26:50] <deep42thought> ok, there's no todo, but also the script cannot do it
[21:27:07] <deep42thought> it can only create shim packages from packages, that are already in the database
[21:28:58] <abaumann> ok, no problem. I'll add them locally.. I have to fiddle anyway to find a way to build it..
[21:29:24] <deep42thought> if you need this functionality more often, we should really add this option
[21:29:26] <abaumann> ..we could add a TODO? ;-)
[21:29:29] <deep42thought> :D
[21:30:19] <abaumann> Usually I prefer rebuilding it in build-support via a PKGBUILD, so it's reproducable and tracked.. it's a corner case.
[21:30:49] <deep42thought> having it in the db also makes dependency resolving for get-build-assignment easier / possible
[21:31:01] <abaumann> true
[21:31:29] <deep42thought> but for this, we need real git revisions :D
[21:31:42] <abaumann> 'configure: error: cannot compute suffix of object files: cannot compile'
[21:31:44] <abaumann> urgh..
[21:33:26] <abaumann> i686-w64-mingw32-gcc -m64
[21:33:45] <abaumann> yeah.
[21:34:45] <abaumann> i686-w64-mingw32 x86_64-w64-mingw32
[21:34:56] <abaumann> but will wine build a pure 32-bit version of wine?
[21:35:02] <abaumann> and will that be able to play games?
[21:35:05] <abaumann> I doubt it :-)
[21:40:18] <abaumann> depmod: WARNING: could not open modules.builtin.modinfo at /tmp/mkinitcpio.PQFXZU/root/lib/modules/5.15.52-1-lts: No such file or directory
[21:40:26] <abaumann> interesting. and this is 64-bit..
[21:40:57] GNUtoo_ is now known as GNUtoo
[21:41:29] <abaumann> and missing shared libraries..
[21:42:58] <abaumann> ==> ERROR: binary dependency `libf2fs.so.9' not found for `/usr/bin/fsck.f2fs'
[21:43:01] <abaumann> ==> ERROR: binary dependency `libreiserfscore.so.0' not found for `/usr/bin/fsck.reiserfs'
[21:43:20] <abaumann> I'm sort of afraid to reboot now :-)
[21:44:01] <abaumann> https://bbs.archlinux.org
[21:44:01] <phrik> Title: [SOLVED] Module error on upgrade / Newbie Corner / Arch Linux Forums (at bbs.archlinux.org)
[21:44:22] <abaumann> cd /var/cache/pacman/pkg/
[21:44:22] <abaumann> ls
[21:45:31] <abaumann> kmod downgrade to 29, confirmed, works
[21:46:53] <abaumann> the other shared libraries are harmless, as long you don't have a forced fsck in the ramdisk for reiserfs or f2fs
[21:47:22] <Foxboron> abaumann: https://github.com maybe?
[21:47:28] <abaumann> f2fs-tools: /usr/bin/defrag.f2fs exists in filesystem
[21:47:28] <abaumann> f2fs-tools: /usr/bin/dump.f2fs exists in filesystem
[21:47:29] <Foxboron> hmm, or maybe not
[21:47:30] <abaumann> mmh
[21:47:35] <abaumann> this also looks weird..
[21:47:45] <abaumann> yep.
[21:47:50] <abaumann> thanks Foxboron :-)
[22:01:53] <abaumann> Actually, yes, the https://github.com fix works just fine with kmod 30. Just tested..
[22:02:01] <KitsuWhooa> silly question, but are two captchas really needed? https://bugs.archlinux32.org :p
[22:02:02] <phrik> Title: Archlinux32Register new user (at bugs.archlinux32.org)
[22:02:42] <abaumann> @KitsuWhooa: sigh. yes. I think, I added a second one after to many spammers got into the system.. :-)
[22:02:48] <abaumann> *too
[22:02:56] <KitsuWhooa> I somehow completely glanced over the first one and was very confused as to why it said the captcha failed
[22:03:05] <abaumann> lol :-)
[22:03:07] <abaumann> sorry. :-)
[22:03:12] <KitsuWhooa> it's fine, and it's really minor anyway :p
[22:03:17] <KitsuWhooa> was just making sure that it's as intended
[22:03:27] <abaumann> You would really think one captcha should be enough.
[22:03:29] <abaumann> I agree.
[22:05:02] <abaumann> pacman -S reiserfsprogs f2fs-tools helps to get rid of the mkinitcpio lost library errors, but I fail to see where the [fsck] hook grabs reiserfs or f2fs. I would expect, it checks if the fsck.XXX helpers are actually installed..
[22:07:55] <abaumann> ah. I had those bocus fsck.<xx> installed. This looks more like a pacman database problem of my machine:
[22:07:58] <abaumann> pacman -S reiserfsprogs f2fs-tools --overwrite='*'
[22:08:04] <abaumann> followed by:
[22:08:04] <abaumann> pacman -Rs reiserfsprogs f2fs-tools
[22:08:08] <abaumann> resolved it for me
[22:08:58] <abaumann> the fsck hook looks at the helper fsck.XXX and installs them, if they are there. If they are old and stale, nothing checks that which ldd as one can assume, that they are installed correctly with their dependencies.
[22:09:20] <abaumann> "tempest in a teapot" :-)
[22:16:33] <abaumann> @KitsuWhooa: thanks for reporting libreoffice issues, it's now also boost-libs and icu linking issues..
[22:16:44] <KitsuWhooa> I didn't report any libreoffice issues
[22:16:45] <KitsuWhooa> :p
[22:16:52] <abaumann> mmh? ;-)
[22:16:58] <abaumann> ok. somebody did. :-)
[22:17:02] <KitsuWhooa> https://bugs.archlinux32.org is mine :p
[22:17:02] <phrik> Title: FS#273 : Quazip Qt5 package contains Qt6 libraries (at bugs.archlinux32.org)
[22:17:15] <abaumann> oh.
[22:17:28] <abaumann> that's a nice one.. :-)
[22:17:45] <KitsuWhooa> yeah idk how it happened :p
[22:18:10] <KitsuWhooa> I found out by accident while testing ckb-next to make sure I didn't mess up some data type for i686/pentium4
[22:19:54] <abaumann> mmh. this should actually also happen on 64-bit, the PKGBUILD is not special in any way..
[22:20:10] <KitsuWhooa> the upstream packages are fine :p
[22:20:17] <KitsuWhooa> assuming you're referring to quazip
[22:20:22] <abaumann> yep.
[22:20:30] <abaumann> mmh. weird.. really weird..
[22:21:12] <abaumann> "/build/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc: cannot compute suffix of object files: cannot compile", yep, my mingw cross-compilers are broken.. sigh..
[22:26:56] <abaumann> http://mirror.archlinux32.org
[22:26:57] <phrik> Title: #archlinux32 | Logs for 2022-07-01 (at mirror.archlinux32.org)
[22:27:03] <abaumann> sorry. Thanks to KillerWasp. :-)
[22:27:20] <abaumann> It's the usually mess around icu and boost-libs..
[22:27:31] <abaumann> ..and I'm just not fast enough to rebuild everything..
[22:28:43] <KitsuWhooa> :p
[22:35:26] -!- abaumann has quit [Quit: leaving]
[23:10:52] -!- GNUtoo has quit [Remote host closed the connection]
[23:11:10] -!- GNUtoo has joined #archlinux32