#archlinux32 | Logs for 2023-02-13

[00:34:13] <bill-auger> base-devel meta-package is planned ?
[01:10:06] -!- wjlafrance has quit [Ping timeout: 252 seconds]
[01:20:42] -!- wjlafrance has joined #archlinux32
[01:27:28] -!- wjlafrance has quit [Ping timeout: 248 seconds]
[01:52:44] -!- wjlafrance has joined #archlinux32
[02:03:39] -!- wjlafrance has quit [Ping timeout: 252 seconds]
[02:48:05] -!- mvchtz has quit [Ping timeout: 256 seconds]
[03:51:31] -!- wjlafrance has joined #archlinux32
[09:54:08] -!- SurfBlueCrab has parted #archlinux32
[10:46:34] <KitsuWhooa> archlinux32-keyring seems to be out of date in the latest ISO image
[10:46:40] <KitsuWhooa> I had to manually update it before running pacstrap
[10:46:52] <KitsuWhooa> archlinux32-2023.01.04-i686.iso
[10:53:32] <KitsuWhooa> Hmmmm. "libbfd.so is not an ELF file - it has the wrong magic bytes at the start"
[10:59:18] <KitsuWhooa> Uh, what?
[10:59:26] <KitsuWhooa> if I cat it, I get `INPUT( /usr/lib/libbfd.a -lsframe -liberty -lz -lzstd -ldl )`
[10:59:33] <KitsuWhooa> that's definitely not a .so, nor a symlink as I'd expect
[11:01:46] <KitsuWhooa> I manually made a symlink to libbfs-2.40.so and that fixed it
[11:31:39] -!- bdju_ has joined #archlinux32
[11:36:28] -!- bdju has quit [*.net *.split]
[12:48:20] <KitsuWhooa> It looks like it's a text file in upstream arch too. I wonder what is perhaps linked against the wrong file
[12:52:00] <KitsuWhooa> Oh it's ldconfig...
[13:02:45] -!- bdju_ has quit [Quit: Reconnecting]
[13:03:19] -!- bdju has joined #archlinux32
[13:21:56] -!- drathir_tor has quit [Ping timeout: 255 seconds]
[13:27:48] -!- drathir_tor has joined #archlinux32
[14:06:07] -!- wjlafrance has quit [Quit: ZNC 1.8.2 - https://znc.in]
[14:08:00] -!- wjlafrance has joined #archlinux32
[14:29:43] -!- mvchtz has joined #archlinux32
[15:04:32] <girls> bill-auger: it should be normally built - let me check, why it's not.
[15:06:23] <girls> hah, I can ask the buildmaster - didn't do this for so long, that I completely forgot.
[15:06:32] <girls> buildmaster: why don't you build base-devel?
[15:06:52] <girls> ... clocks ticking ... sand falling ...
[15:07:57] <girls> https://archlinux32.org
[15:08:24] <buildmaster> girls: "any/base-devel" has unmet dependencies:
[15:08:24] <buildmaster> archlinux-keyring
[15:08:24] <buildmaster> "any/base-devel" has unmet dependencies:
[15:08:24] <buildmaster> base-devel
[15:08:24] <buildmaster> "any/base-devel" has unmet dependencies:
[15:08:24] <buildmaster> ... (16 lines total)
[15:10:38] <girls> let me just force it to rechenknecht - these are all no blockers, actually.
[15:11:28] <girls> KitsuWhooa: yeah, the iso still has the old keyring - your fix is exactly, how one should fix it. :-(
[15:19:35] <KitsuWhooa> ah
[15:19:46] <KitsuWhooa> girls: any idea what's wrong with libbfd.so?
[15:25:30] <KitsuWhooa> Also, is there an easy way to just say append lines to prepare()
[15:25:38] <KitsuWhooa> Doing sed on $ is being a massive pain
[16:28:09] <bill-auger> libbfd.so jas had that problem for weeks
[16:31:09] <bill-auger> <bill-auger> ldconfig: /usr/lib/libbfd.so is not an ELF file - it has the wrong magic bytes at the start.
[16:31:09] <bill-auger> <abaumann> https://bbs.archlinux32.org
[16:31:11] <phrik> Title: libbfd.so producing ldconfig warnings / Pacman / Pacman Upgrades / Arch Linux 32 Forum (at bbs.archlinux32.org)
[16:39:02] -!- GNUtoo has quit [Ping timeout: 255 seconds]
[16:41:03] -!- GNUtoo has joined #archlinux32
[17:16:37] -!- abaumann has joined #archlinux32
[17:16:37] <buildmaster> Hi abaumann!
[17:16:37] <buildmaster> !rq abaumann
[17:16:39] <phrik> buildmaster: <abaumann> I have funny nice ideas again :-)
[17:17:17] <abaumann> about libbfd. see https://bbs.archlinux32.org and https://bugs.archlinux.org
[17:17:18] <phrik> Title: libbfd.so producing ldconfig warnings / Pacman / Pacman Upgrades / Arch Linux 32 Forum (at bbs.archlinux32.org)
[17:17:56] <abaumann> about the ISO, yes, the old one has an old keyring and the new one for February got stuck in limbo (aka archinstall32)
[17:18:11] <abaumann> keyring-archlinux requires some rust to be built, IIRC.
[17:19:03] <abaumann> and rust is utterly broken currently, basically I see no other hope that to start to use rust-bin or to cross-compile rust..
[17:20:25] * abaumann didn't try yet to get chatgpt to do some sedfu on PKGBUILDS.. ;-)
[17:20:54] <abaumann> I added the patch to luajit, let's see, it it builds, thanks again for patching :-)
[17:25:27] <abaumann> on the broken asp32, I cannot really see why? I'm using it constantly..
[17:28:09] <bill-auger> you could simply re-package the arch keyring, or simply sign the arch package
[17:28:42] <abaumann> That's an idea. But I remember a discussion with deep42thought, that keyring-archlinux is actually not that important..
[17:29:05] <abaumann> ..no arch32 packages should be signed with and of those keys.
[17:29:22] <abaumann> I'm having a look: sequoia-sq was the problematic makedepend
[17:29:45] <bill-auger> its not - the proper action for arch32 , is to replace archlinux-keyring with archlinux32-keyring in the meta-package
[17:30:21] <abaumann> and import the required master keys into archlinux32-keyring, yeah probably..
[17:30:26] <bill-auger> i am debating if i should simply remove it - the dependency chain is whacky now
[17:30:42] <abaumann> or rusty ;-)
[17:31:11] <bill-auger> i have all needed keyrings as a dependency of pacman - but arch pacman depends on no keyring - instead the keyring depends on pacman
[17:32:10] <bill-auger> it seems like the direction of implication is inverted 0 im not sure why they have it that way
[17:32:43] <abaumann> mmh. the dependency might be circular..
[17:33:04] <bill-auger> no its not - it just weird
[17:33:41] <bill-auger> both base and base-devel depend on the keyring (and so pacman) - that would only make sense if it were a supported use-case to install base-devel but not base
[17:34:26] <bill-auger> i dont suppose that there i any supported use-case which does not require base
[17:34:53] <abaumann> hard to have any use-case without base, I support :-)
[17:34:53] <bill-auger> oh yea nm - im thinking too fast - we depend on that use case
[17:35:25] <bill-auger> but thats only an optimization - we probably should nto do it
[17:36:02] <abaumann> I hope I can hack out sequoia-sq, just repackaging the keys in archlinux-keyring sounds like a good idea.
[17:36:20] <bill-auger> im quite on-baord with "install 'base', or youre on your own"
[17:36:30] <abaumann> :-)
[17:37:52] <bill-auger> our build chroot only install base-devel - i needed to hack that now anyways, because sudo and fakeroot are not in the new base-devel
[17:40:50] <abaumann> I see an argument, why fakeroot and sudo are not part of base-devel: you are supposed to build the package with devtools only, fakeroot and sudo inside base-devel build be wrong if having a PKGBUILD including makedpends=(base-devel)
[17:44:08] <abaumann> error: config file /etc/pacman.d/mirrorlist32 could not be read: No such file or directory
[17:44:19] <abaumann> that's weird, never had this before when using the chroots..
[17:46:23] <abaumann> pacman inside the chroot has mirrorlist32 in /etc/pacman.conf?
[17:47:02] <girls> archlinux-keyring can be removed from base-devel, that's right
[17:47:13] <girls> we have all relevant keys in archlinux32-keyring
[17:47:16] <abaumann> I think so, yes.
[17:47:34] <girls> it's merely a nice-to-have to have the keys of upstream TUs in there, so it's less a pain to build stuff from AUR
[17:47:41] <abaumann> this has the additional benefit of making key updates _much_ faster on Arch32 :-)
[17:47:43] <girls> but that's rather an edge case, I suppose
[17:47:54] <girls> I'll fix it
[17:47:59] <abaumann> ok.
[17:48:13] <abaumann> I hunt my funny mirrorlist32 problems..
[17:48:33] <girls> is base now a meta-package, too?
[17:49:00] <abaumann> yes. since February or so..
[17:49:18] <girls> pacman depends on the mirrorlist, not the keyring
[17:49:41] <abaumann> yes, and the keyrings depends on pacman-key (pacman package)
[17:49:50] <girls> ah, right
[17:50:07] <abaumann> you played to much with Debian lately? ;-)\
[17:51:07] <girls> no, haven't touched debian in ages
[17:51:33] <girls> well, probably that's false - I might have used debian as a user at my dayjob
[17:51:51] <girls> not sure, what's running on the servers, but it might well be debian
[17:52:22] <girls> ok, base and base-devel should now depend on archlinux32-keyring and not on archlinux-keyring anymore - let's see :)
[17:52:31] <abaumann> good :-)
[17:52:44] <girls> the nice thing about the meta-package approach is, that all users will automatically pull in the new dependency :)
[17:52:49] <abaumann> I'm sure something breaks..
[17:53:10] <abaumann> ..I see some trouble for our own build machines..
[17:53:14] <abaumann> don't they import keys..?
[17:53:22] <abaumann> or just the keys in the 'keys' subdir?
[17:53:40] <girls> they don't need the archlinux-keyring, either
[17:53:59] <girls> and devtools32 depends on archlinux32-keyring since the beginning
[17:54:12] <girls> so it should be fine on the host
[17:54:17] <abaumann> ah. ok. Then I don't see anything anymore which can go wrong..
[17:54:19] <girls> inside the chroot, it should only get better
[17:54:25] <girls> :D
[17:54:30] <girls> dinner time ... cya later
[17:54:34] <abaumann> cu
[17:54:36] <KitsuWhooa> abaumann: a bit late but I have patches for protobuf too
[17:54:46] <KitsuWhooa> I'll send them later when I'm back home if you're still around
[17:55:17] <abaumann> that's fine.. not sure, if I'm still around.. but if the problems persist.. then yes :-)
[17:55:40] <girls> ah, regarding patches: maybe, we should apply them tih "git am" - then the original commiter does not get lost?
[17:55:46] <KitsuWhooa> I see :p
[17:55:48] <girls> otherwise it looks all like a 2-man show, here :D
[17:55:57] <KitsuWhooa> In my case I messed up the patch
[17:56:00] <KitsuWhooa> I noticed it afterwards
[17:56:17] <abaumann> Ah, I always add the original auhtor of patches to PKGBUILD and the patchfile..
[17:56:20] <girls> not sure, when I applied it, it showed the correct committer - but abaumann was faster ;)
[17:56:21] <abaumann> ..if it's missing.
[17:56:22] <KitsuWhooa> I meant to add a prepare function in the pkgbuild as one didn't exist in the upstream one
[17:56:34] <KitsuWhooa> But I named it build instead
[17:56:41] <abaumann> ah, there are some examples for that..
[17:56:46] <girls> regarding sed-patching: there's unfortunately no easier way (currently)
[17:56:51] <girls> but I'm open for suggestions
[17:56:58] <KitsuWhooa> I just don't know how to add two extra patches
[17:57:07] <abaumann> you get used to.. eventyually..
[17:57:10] * abaumann coughs
[17:57:11] <KitsuWhooa> As they need to be in new lines
[17:57:21] <KitsuWhooa> But yes, I do think git am would be better
[17:57:33] <KitsuWhooa> Worst case scenario you amend the commit after am and modify what needs to be modified
[17:57:37] <girls> you can add helper function "_perpare() { patch ...; }"
[17:57:55] <KitsuWhooa> Ah I see
[17:57:57] <girls> and then simply add this via sed: "sed '$ i _prepare'"
[17:58:03] <girls> it's a little bit more readable
[17:58:09] <KitsuWhooa> Good idea. I'll do that
[17:58:12] <girls> but: I never do it that way :D
[17:58:22] <abaumann> https://git.archlinux32.org
[17:58:25] <phrik> Title: openvdb « community - packages - Archlinux32 package modifications (at git.archlinux32.org)
[17:58:35] <abaumann> is a good example with one patch and the prepare with gets added, if missing
[17:58:41] <abaumann> patching should not be done in build()
[17:59:05] <girls> yeah, stick to this eval expression - it works regardless whether there is no prepare() or there is one.
[17:59:05] <abaumann> patches should be plain text, that's acutally the only requirement..
[17:59:12] <abaumann> ..maked them easier to be resued. :-)
[17:59:36] <abaumann> we can add git write access, that's not a biggie.
[17:59:45] <girls> +
[17:59:49] <abaumann> the only trouble would be to remember how gitolite works.. :-)
[17:59:57] <girls> hehe
[18:00:06] <girls> gitolite is straight-forward
[18:00:22] <girls> just add the key to keys/something.gpg and add "something" access to the repo
[18:00:39] <abaumann> basically, I need a ggp public key for write access IIRC..
[18:00:41] <abaumann> ..exactly :-)
[18:00:51] <girls> ssh, my bad
[18:00:57] <KitsuWhooa> My last patch I sent with git send-email
[18:01:03] <abaumann> that's also fine
[18:01:11] <KitsuWhooa> You can just git am the entire email
[18:01:20] <abaumann> but having the authorship in the packages git repo is a nice thing to have.
[18:01:32] <KitsuWhooa> I'm not sure what you mean
[18:01:36] <girls> if you're fine with the (possible) latency, we can also stick to sending patches and running "git am"
[18:01:56] <girls> abaumann: just "git am" the patch and the author will be correct
[18:02:01] <KitsuWhooa> ^
[18:02:02] <abaumann> git log on the packages git shows a two-man show. :-)
[18:02:09] <abaumann> ah.
[18:02:19] <abaumann> there I did the mistake, yep.
[18:02:29] <girls> that's, how the linux kernel is managed: sending patches and "git am"
[18:02:39] <KitsuWhooa> Git send email is really convenient
[18:02:53] <girls> I'm never able to remember all the correct options
[18:03:07] <girls> and then I'm too afraid to send a wrong email to a list of 100's of devs ;-)
[18:03:19] <KitsuWhooa> Heh
[18:03:20] <abaumann> especially Linux devs *shudder*
[18:03:33] <KitsuWhooa> I've sent a few patches and it went fine :p
[18:03:45] <girls> your head is still attached to your torso?
[18:03:53] <KitsuWhooa> Hahaha
[18:03:57] <abaumann> :-)
[18:03:58] <KitsuWhooa> Somehow :p
[18:06:14] <bill-auger> FWIW your patching system annoys me greatly - i really wish you would publish complete PKGBUILDs
[18:07:05] <bill-auger> me and meld get along fine with arch and archarm - arch32 is very tedious to compare/merge
[18:12:20] <bill-auger> i even have a nice helper for that `meld-pkgbuilds PKGNAME` - it will `git pull` on each repo, find the matching pkgname, and boom
[18:12:37] <bill-auger> i can only imagine that it would make your job easier to do it that way too
[18:21:07] <KitsuWhooa> I find it much easier to deal with
[18:21:37] <KitsuWhooa> having to diff with upstream constantly, especially to keep up to date and merge whatever existing changes there are sounds like a nightmare
[18:48:05] <KitsuWhooa> Uhhhh
[18:48:29] <KitsuWhooa> the upstream PKGBUILD for protobuf downloads a patch from github
[18:48:37] <KitsuWhooa> the hash for it doesn't match
[18:48:57] <KitsuWhooa> Do I fix it in my patch, or do I pretend it's not broken? :p
[18:49:45] <bill-auger> patching is more brittle though - anything cuold sneak in upstream that would break your build - and youd not know, until after the build fails
[18:49:55] <KitsuWhooa> that's less effort though :p
[18:50:36] <bill-auger> i live that nightmare daily - putting in less effort upfront, leads to more effort required later
[18:50:57] * KitsuWhooa shrugs
[18:52:32] <KitsuWhooa> either way this happens when trying to build arch64 protobuf as-is, https://tasossah.com
[18:52:32] <phrik> Title: upstream protobuf (at tasossah.com)
[18:57:32] <bill-auger> it takes about 10 times more effort to merge arch32 changes - even if nothing would change from one version to the next, that is never obvious - some packages, i usually package a (or several_ versions of _whatever_ ahead of arch32's version (mozilla especially); so i need to scrutinize the entire patch evry time, merging in my head first - the patches are not even in the right order as they appear in the PKGBUILD - overall, it
[18:57:33] <bill-auger> is definitely not less work
[18:59:16] <bill-auger> but i digress - i can live with it :)
[19:16:33] -!- abaumann has quit [Remote host closed the connection]
[19:54:47] -!- GNUtoo has quit [Ping timeout: 255 seconds]
[19:55:31] -!- GNUtoo has joined #archlinux32
[20:47:21] <KitsuWhooa> Well, I reported it upstream https://bugs.archlinux.org
[20:47:21] <phrik> Title: FS#77486 : [protobuf] sha512sum mismatch when trying to build (at bugs.archlinux.org)
[20:47:24] <KitsuWhooa> Hopefully I didn't miss anything obvious
[21:30:11] -!- drathir_tor has quit [Ping timeout: 255 seconds]
[21:34:50] -!- drathir_tor has joined #archlinux32
[21:55:24] <KitsuWhooa> abaumann, girls, can you please rebuild zeroc-ice? It depends on old openssl. I rebuilt it fine on my end with no issues
[21:59:16] <KitsuWhooa> and then after protobuf is fixed, mumble can finally be rebuilt (and it works)
[22:18:20] <girls> KitsuWhooa: I rescheduled zeroc-ice, let's see, when it gets actually built :)
[22:18:31] <KitsuWhooa> cool, thanks!
[22:21:11] <girls> looks, like there are a bunch of base-devel packages scheduled to be built first - hopefully this works out
[22:22:00] <girls> hmm, it won't - m4 fails in check() :-(
[22:26:04] <KitsuWhooa> welp
[23:15:55] <pulec> what cpus are usually running on?
[23:16:34] <bill-auger> any x86 CPU from 486 to pentium4
[23:18:26] <pulec> I am about to install on revived athlon xp ~3000+
[23:19:06] <pulec> it was off couple of years, I switched PSU, maybe exchanged a battery and had to keep it week on standby for it to finally get to boot archiso
[23:19:12] <pulec> it kept freezing for some reason
[23:19:53] <pulec> beast in museum piece case https://0x0.st
[23:20:09] <pulec> the cooler and gpu cooler are absolutely terrible
[23:20:19] <pulec> and case fans too, so frickin loud
[23:20:36] <pulec> but ye https://0x0.st