#archlinux32 | Logs for 2025-03-30
Back
[02:03:29] -!- lithium_pt has joined #archlinux32
[02:04:08] -!- lithiumpt has quit [Ping timeout: 245 seconds]
[03:23:50] -!- lithiumpt has joined #archlinux32
[03:24:10] -!- lithium_pt has quit [Ping timeout: 272 seconds]
[05:11:24] -!- h|weechat has quit [Ping timeout: 265 seconds]
[07:34:55] -!- abaumann has joined #archlinux32
[07:34:56] <buildmaster> Hi abaumann!
[07:34:56] <buildmaster> !rq abaumann
[07:34:56] <phrik> buildmaster: <abaumann> I fail to decive what is crappier: rust or LTO in gcc..
[07:35:58] <abaumann> I personally would use any packages from upstream just in the build-support to support some non-buildable any packages.
[07:36:00] <girls> Hi abaumann!
[07:36:06] <abaumann> morning :-)
[07:36:27] <girls> that's what we will have in a few minutes, once Kuchen picks up the new devtools32 build ...
[07:36:29] <abaumann> any could mean, the built package runs on any, but for building, it does something beatifully different.
[07:36:45] <abaumann> kuchen? ah, the pendant to streusel ;-)
[07:36:56] <girls> the host of streusel, correct
[07:37:09] <abaumann> suitable naming :-)
[07:37:29] <girls> I started naming my machines after food
[07:37:43] <abaumann> that's more creative than eurobuildX
[07:38:10] <abaumann> speaking of which: I made a test run of eurobuild6 after reinstalling it (disk issues, don't ask). Seemed to work fine for 2 days..
[07:42:53] <abaumann> about using signify. this would deviate from upstream. if they move from gpg to signify, fine, if not, gpg it is.
[07:43:06] <girls> yes, I know
[07:43:22] <abaumann> though gpg is a mess on steroids :-)
[07:43:24] <girls> just wanted to say, that others use different tools, which are more suitable for our case
[07:43:26] <girls> :D
[07:43:41] <abaumann> signify? that's the OpenBSD signify?
[07:43:45] <girls> yeah
[07:44:29] <abaumann> the problem is also: gpg offers a way to manage your keys, not so sure about signify..
[07:44:48] <girls> we do not need key management, we can just distribute them via package
[07:45:03] <abaumann> that's true
[07:45:21] <girls> or did you mean on the developer side?
[07:45:47] <abaumann> for convenience for the developer: having a master key, derive the subkeys for emailing, siging packages. all in one package.
[07:45:55] <abaumann> yes, there I see a benefit.
[07:46:24] <girls> anyways - as you said, we stick with whatever upstream uses.
[07:49:21] <girls> ok, new devtools arrived
[07:50:32] <girls> the build-support straw should now also use the upstream any package repository
[07:50:45] <girls> not sure, if this breaks something, as it comes before our repositories
[07:50:53] <girls> thinking of keyring and such ...
[07:56:48] -!- h|weechat has joined #archlinux32
[07:57:05] <abaumann> new devtools always arrive :-)
[07:57:36] <girls> well, I broke the automation on my side a few months back, so now there are a couple manual steps at the end ...
[07:57:39] <abaumann> Usually I merge them from upstream into upstreamMaster, then into master (which currently only has the --arch32 option support and some minor things)
[07:59:58] <girls> hmm, the mirror script currently re-creates the repo database from scratch each time. This is probably a bit too much :D
[08:00:12] <abaumann> uh.
[08:02:23] <girls> why repo-add does not handle this case leniently, is also beyond me. The answer is probably "because noone needed it so far".
[08:02:50] <abaumann> probably. and with the advent of SSDs nobody cares anyway :-)
[08:03:19] <abaumann> the buildmaster is still holding up fine.. not super-efficient, but working.
[08:03:59] <girls> it's not _just_ about disk speed: it also computes all checksums again ...
[08:04:19] <girls> which may or may not be, what the caller intended, though
[08:04:48] <abaumann> uh, yes. this also requires quote some CPU time.
[08:05:36] <girls> I was pondering to just butcher the repo db together myself: In the end, it is a gzipped tar of files, that we could verbatimly take from the upstream repo db >:-)
[08:06:21] <abaumann> The same applies for packages, it's also just .MTREE .PKGINFO .BUILDINF and a tar
[08:07:57] <girls> well, we copy the whole package and signature from upstream. You cannot really have more "verbatimity"
[08:08:18] <abaumann> :-)
[08:24:09] <girls> ok, creating the db manually is _a_lot_ faster. Also, we now have the signatures in the db. Not sure, why repo-add didn't add them otherwise ...
[08:31:23] <abaumann> upstream never used the signing of the dbs, I don't know why it was never used. pacman has the ability since ages.
[08:31:30] <abaumann> There must be a reason, why they are not doing it.
[08:48:36] <girls> that's something else
[08:48:54] <girls> I was talking about the signature of the packages, that is also persisted inside the db - or not in my first case
[08:49:19] <girls> the signature on db level is not used upstream, because it brings little benefit
[08:49:23] <girls> all packages are signed anyways
[08:50:07] <girls> and if you want to attack a machine by handing out outdated packages, you can do this as mirror operator anyways by providing an old state - with or without signature
[08:51:39] <girls> that being said: I'm signing archlinuxewe since ages and it just works - except, if you break your keyring, then you are not even able to do a `pacman -Sy` anymore :D
[08:55:50] <abaumann> ah. breaking my key(ring), my speciality. ;-)
[08:56:34] <abaumann> I had a archlinuxaba repo, but I was doing everything manually or with the scripts. I never tried the new repod infrastructure upstream (mainly because it's written in Python).
[08:58:03] <abaumann> I went to a simpler system: build on one machine (euronuc) and then rsync the build directories to all other machines.
[08:58:32] <abaumann> that's why the buildmaster and archlinux32.org have local packages in /data/INSTALL, I'm not building there, I just sync things from euronuc and install locally then.
[08:58:46] <abaumann> just in case you wonder why thing are commented out in pacman.conf :-)
[08:58:53] <abaumann> *things == repos
[09:16:29] <girls> ok, makes sense - I tried to go the automatic approach (without repod, too), but at some point I neglected it and you took over with your approach. Sounds legit :)
[09:17:27] <abaumann> I'm always open to a new automatized way. :-)
[09:45:46] <girls> I'll look into it. Currently, archlinuxewe should be quite usable. It pins the dependencies by version (to avoid breaking linking when deps want to get updated), but I now regularly rebuild packages.
[10:41:34] <abaumann> extra-any/rocprim rocprim 6.3.3-1 6.3.3-1 7ebc9f3d2ae4ee8f2831bb7615190f73ea5ad870
[10:42:07] <abaumann> I doubt you should really assume any is usable on all architectures..
[10:52:43] <KitsuWhooa> it doesn't harm anything by being there though
[11:55:32] -!- abaumann has quit [Quit: leaving]
[12:19:18] <girls> well, it will be installed instead of our packages, if it is there - so yes, it may harm.
[12:24:37] -!- texus has joined #archlinux32
[12:27:33] -!- ssserpent has quit [Ping timeout: 248 seconds]
[12:28:44] <KitsuWhooa> I'm confused
[12:32:57] <KitsuWhooa> it won't be installed in the first place because nothing of ours will ever depend on it
[14:37:04] -!- texus has quit [Ping timeout: 260 seconds]
[18:38:00] -!- drathir_tor has quit [Ping timeout: 264 seconds]
[19:19:47] -!- drathir_tor has joined #archlinux32
[20:03:45] mavicaway is now known as mavica
[20:57:26] -!- lithium_pt has joined #archlinux32
[20:59:18] -!- lithiumpt has quit [Ping timeout: 272 seconds]
[21:27:05] mavica is now known as mavicaway
[22:04:07] -!- jacobk_ has joined #archlinux32