#archlinux32 | Logs for 2024-04-26

Back
[04:56:19] -!- drathir_tor has quit [Remote host closed the connection]
[04:57:28] -!- drathir_tor has joined #archlinux32
[06:05:16] -!- abaumann has joined #archlinux32
[06:05:16] <buildmaster> Hi abaumann!
[06:05:17] <buildmaster> !rq abaumann
[06:05:17] <phrik> buildmaster: <abaumann> policy delegation to chat bots :->
[06:05:21] <abaumann> 2 any util-linux be66c23555e4e185afba1f3dadea68ee640c396a f728c73443cb00589d648d61f0e9bcb726024b99 core
[06:05:31] <abaumann> but we should have:
[06:05:32] <abaumann> c64eb64e0941e5cec2c6bdf1f5c1f2fb70b4179b refs/tags/2.40-3
[06:05:49] <abaumann> so, I should see after a get-package-updates:
[06:05:57] <abaumann> c64eb64e0941e5cec2c6bdf1f5c1f2fb70b4179b f728c73443cb00589d648d61f0e9bcb726024b99
[06:06:18] <KitsuWhooa> abaumann: isn't that for python 3.12?
[06:06:35] <KitsuWhooa> it's still in testing
[06:07:08] <KitsuWhooa> Also, I've been toying around with schedule-for-rebuild and I think I got it to always have the latest commit at the bottom
[06:07:10] <KitsuWhooa> haven't pushed it yet
[06:07:11] <abaumann> it's util-linux, what is the link to python here?
[06:07:16] <KitsuWhooa> https://gitlab.archlinux.org
[06:07:16] <phrik> Title: upgpkg: 2.40-3: Python modules part 1 (62b8e7f7) · Commits · Arch Linux / Packaging / Packages / util-linux · GitLab (at gitlab.archlinux.org)
[06:07:26] <KitsuWhooa> idk :p
[06:07:34] <abaumann> Ah, just push it, it can not get worse in my opinion.
[06:07:36] <KitsuWhooa> but that looks like a python rebuild bump
[06:07:41] <abaumann> The list is just random at the moment.
[06:07:56] <KitsuWhooa> I so made a variant that schedules the latest commit for each package for rebuild
[06:08:01] <KitsuWhooa> which is how I scheduled all of ruby
[06:08:03] <KitsuWhooa> and it seems to have worked
[06:08:07] <abaumann> the strange thing is, that there is a bump and a bump back.
[06:08:55] <abaumann> in theory you have to build all the intermediate versions, because something could depend on an exact state of a package, but this is unrealistic.
[06:09:07] <KitsuWhooa> yes
[06:09:20] <KitsuWhooa> I pushed it
[06:09:38] <abaumann> coll. I'll test it with quite some 486 packages today and keep count. :-)
[06:09:41] <abaumann> *cool
[06:09:43] <KitsuWhooa> thanks
[06:09:50] <KitsuWhooa> let me know if you find any that don't have the latest one at the end
[06:10:05] <KitsuWhooa> as for ruby
[06:10:06] <abaumann> right. will do.
[06:10:10] <KitsuWhooa> most packages failed to rebuild due to dependencies
[06:10:18] <abaumann> yeah, no wonder.
[06:10:27] <KitsuWhooa> as in, the packages they depended on hadn't been built yet
[06:10:37] <KitsuWhooa> maybe it's an effect of -j ?
[06:10:50] <abaumann> or they also just failed because of other things
[06:11:16] <abaumann> if I recall I had similar issues once with perl.
[06:11:24] <abaumann> or/and python.
[06:11:52] <KitsuWhooa> hm, maybe
[06:13:36] <KitsuWhooa> ah yes
[06:13:38] <KitsuWhooa> I misread the output of pacman
[06:13:49] <KitsuWhooa> I hate the "missing dependencies:" output because it's so misleading
[06:13:55] <KitsuWhooa> it lists a bunch of dependencies and not all of them are missing
[06:18:03] <KitsuWhooa> I'm so tempted to wget all the upstream ruby any arch packages and put them in build-support-manual
[06:20:07] <abaumann> yes, this is like this probably since the beginning of pacman dependencies
[06:20:09] <abaumann> 1 any util-linux 0929deb8c9e4949ea85f8b5fc46c1b00de4c86c5 f7cde3df7662dc5af69f133453e299d35606554c core
[06:20:12] <abaumann> 2 any util-linux c5b9322e19edb0928733c0889d0ff4c2c9b74e3f 0000000000000000000000000000000000000000 core
[06:20:15] <abaumann> 3 any util-linux be66c23555e4e185afba1f3dadea68ee640c396a f728c73443cb00589d648d61f0e9bcb726024b99 core
[06:20:49] <abaumann> be66c23555e4e185afba1f3dadea68ee640c396a refs/tags/2.40-2
[06:20:51] <KitsuWhooa> last one looks to be the latest
[06:20:53] <abaumann> latest is the newest.
[06:20:55] <abaumann> yes.
[06:20:56] <KitsuWhooa> yup
[06:21:03] <abaumann> c64eb64e0941e5cec2c6bdf1f5c1f2fb70b4179b refs/tags/2.40-3
[06:21:09] <KitsuWhooa> I think that just hasn't made it yet
[06:21:16] <abaumann> is newer, but let's see if it is also referenced from the state git repo..
[06:22:08] <abaumann> cat ./core-x86_64/util-linux
[06:22:08] <abaumann> util-linux 2.40-2 2.40-2 be66c23555e4e185afba1f3dadea68ee640c396a
[06:22:17] <abaumann> cat core-testing-x86_64/util-linux
[06:22:17] <abaumann> util-linux 2.40-3 2.40-3 c64eb64e0941e5cec2c6bdf1f5c1f2fb70b4179b
[06:22:22] <abaumann> yep, this is correct.
[06:22:24] <KitsuWhooa> yup, it's only in testing
[06:22:43] <abaumann> I'm in the "scratch and sniff mode": I'm checking everything at the moment.
[06:22:48] <KitsuWhooa> hah
[06:50:00] <KitsuWhooa> right, let's see how badly this goes
[06:53:59] -!- ssserpent has joined #archlinux32
[06:55:28] <abaumann> 1 any coreutils 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 core
[06:55:31] <abaumann> 2 any coreutils 7c12bb575b4fa75970a38e83ffc93979df2c855f 48ef4e5554cd437a4f8487f30cfd6393dd02847f core
[06:55:43] <abaumann> I made a get-package-updates and the latest arch32 patch is not picked up
[06:55:56] <abaumann> 6124fcf88fc07628fdb979f5eee2670b130989fd
[06:56:27] <abaumann> that was a package-get-updates-ignore, let me test with a package-get-updates
[06:59:03] <KitsuWhooa> did it show up in the log?
[07:00:22] <abaumann> coreutils 7c12bb575b4fa75970a38e83ffc93979df2c855f 6124fcf88fc07628fdb979f5eee2670b130989fd core
[07:00:26] <abaumann> yes, it did
[07:00:35] <KitsuWhooa> hm
[07:00:50] <KitsuWhooa> last time that happened, I made another commit and pushed it and it worked
[07:00:58] <KitsuWhooa> I think it happens if there are multiple commits for the same package
[07:01:01] <KitsuWhooa> ast once
[07:01:02] <KitsuWhooa> *at once
[07:01:08] <abaumann> ah. that's a good hint.
[07:01:18] <abaumann> though it should really pick up both changes..
[07:01:29] <KitsuWhooa> yeah
[07:06:34] <bill-auger> those changes seem to suggest a rebase - that is, 6124 was pushed with -f, and clobbered 48ef
[07:07:43] <KitsuWhooa> I didn't get any conflicts when doing a git pull
[07:07:50] <KitsuWhooa> so I think a -f is unlikely?
[07:08:07] <bill-auger> maybe the auto-buillder des not handle rebase well - our does not either - rather than accomodate that use-case, i simply made git reject rebases
[07:09:32] <bill-auger> KitsuWhooa: if that is true, then you should have all three of 7c12, 6124 , and 48ef - and then it does not make much sense what those reports are indicating
[07:09:59] <KitsuWhooa> 7c12bb575b4fa75970a38e83ffc93979df2c855f is upstream
[07:10:21] <KitsuWhooa> but I do have both 6124 and 48ef
[07:10:23] <abaumann> In my brain the state git repo should be pulled and the single package repos should just be checked out, preferably with pkgctl --arch32
[07:10:48] <abaumann> so neither merges nor rebases should happen but in the state databse (which is basically a single line per file)
[07:10:49] <bill-auger> if that data is coming from git during a push event, then those IDS should represent the branch HEAD before and after
[07:11:09] <KitsuWhooa> https://git.archlinux32.org
[07:11:10] <phrik> Title: packages - Archlinux32 package modifications (at git.archlinux32.org)
[07:11:11] <bill-auger> 7c12, being the HEAD before both events
[07:11:19] <KitsuWhooa> er
[07:11:21] <KitsuWhooa> wrong link
[07:11:27] <KitsuWhooa> https://git.archlinux32.org
[07:11:28] <phrik> Title: packages - Archlinux32 package modifications (at git.archlinux32.org)
[07:11:45] <KitsuWhooa> that is confusing
[07:12:13] <KitsuWhooa> https://git.archlinux32.org isn't there
[07:12:13] <phrik> Title: core/coreutils: redone i486 uname patch - packages - Archlinux32 package modifications (at git.archlinux32.org)
[07:12:21] <KitsuWhooa> er
[07:12:26] <KitsuWhooa> sorry my brain is fried
[07:12:27] <abaumann> maye the git move from oldpatch to newpatch and then overwritting the newpatch with new content is a problem?
[07:13:24] <abaumann> the sha1 are not the ones of the artifact being changed, but the whole sha commits in the packages repo?
[07:13:27] <abaumann> maybe?
[07:13:48] <abaumann> I would prefer it to be the one belonging to the artifact and not to the tree
[07:14:04] <abaumann> but I think it was always the other way round
[07:17:57] <bill-auger> i was describing how git would pass the changes to hooks - the hooks would see one line per each branch pushed - each line would be two hashes HEAD before push and HEAD after push
[07:18:14] <abaumann> ah, got you. :-)
[07:18:24] <KitsuWhooa> aaah
[07:19:13] <bill-auger> lines with all zeros, would indicate a new branch or deleted branch
[07:20:40] <bill-auger> but i dont think you would ever see a line with both hases all zeros
[07:21:33] <bill-auger> the state repos is a different format - that does incude hases of the file contents
[07:22:01] <bill-auger> [pkgbase pkgver git-tag checksum] (which also would never be all zeros)
[07:30:00] <KitsuWhooa> > node: error while loading shared libraries: libicui18n.so.72: cannot open shared object file: No such file or directory
[07:30:02] <KitsuWhooa> ugh
[07:30:07] <KitsuWhooa> I'm going to have to fix node won't I
[07:30:30] <abaumann> or add a makedpeends+=(icu72) temporarily
[07:31:51] <KitsuWhooa> I'd really rather not
[08:18:25] <abaumann> 1 any coreutils 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 core
[08:18:28] <abaumann> 2 any coreutils 7c12bb575b4fa75970a38e83ffc93979df2c855f 48ef4e5554cd437a4f8487f30cfd6393dd02847f core
[08:18:31] <abaumann> still
[08:18:34] <abaumann> event after bumping an get-package-updates
[08:20:55] <KitsuWhooa> let me try
[08:26:13] <KitsuWhooa> abaumann: worked for me :p
[08:26:16] <KitsuWhooa> 3 any coreutils 7c12bb575b4fa75970a38e83ffc93979df2c855f 4365df91bb9a120ac95ec3e493d303b6e4bdc208 core
[08:26:22] <KitsuWhooa> I scheduled it
[08:37:33] <abaumann> mmh. I think I don't understand this output, so 4365df91bb9a120ac95ec3e493d303b6e4bdc208 is not the SHA into the packages arch32 repo
[08:38:11] <abaumann> -rw-r--r-- 1 http mirror 2848839 Apr 26 10:31 coreutils-9.5-1.1-i686.pkg.tar.zst
[08:38:25] <abaumann> obviously it has built and applied the patch, because the build would fail otherwise.
[08:38:33] <abaumann> This is all a little bit confusing :-)
[08:38:46] <KitsuWhooa> that is the hash
[08:38:56] <KitsuWhooa> I just made a new commit
[08:39:08] <KitsuWhooa> https://git.archlinux32.org
[08:39:09] <phrik> Title: core/coreutils: Bump - packages - Archlinux32 package modifications (at git.archlinux32.org)
[08:39:34] <abaumann> ah, but you made a "real" commit and changed a line..
[08:39:38] <KitsuWhooa> yes
[08:39:40] <abaumann> .. I did an --allow-empty
[08:39:46] <abaumann> so that's the difference :-)
[08:39:57] <KitsuWhooa> perhaps it actually checks for changes
[08:40:02] <abaumann> apparently, yes
[08:40:18] <abaumann> ok, good to know,m so I don't use --allow-empty anymore
[08:40:44] <abaumann> the "rulke of least surprise" is violated here for me :-)
[08:44:01] <abaumann> *rule
[08:46:43] -!- n0tiz has quit [Ping timeout: 256 seconds]
[09:10:44] -!- n0tiz has joined #archlinux32
[09:24:12] -!- n0tiz has quit [Quit: Bye]
[09:28:04] -!- n0tiz has joined #archlinux32
[09:47:44] -!- abaumann has quit [Quit: leaving]
[10:58:10] -!- ssserpent has quit [Ping timeout: 246 seconds]
[11:00:18] -!- ssserpent has joined #archlinux32
[11:21:50] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[11:23:08] -!- ssserpent has joined #archlinux32
[14:07:15] -!- AtleoS has joined #archlinux32
[16:36:29] -!- ssserpent has quit [Quit: WeeChat 4.2.2]
[16:44:50] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[16:52:23] -!- drathir_tor has joined #archlinux32
[17:14:20] -!- AtleoS has quit [Ping timeout: 260 seconds]
[17:18:36] -!- gehidore has quit [Read error: Connection reset by peer]
[17:23:42] -!- gehidore has joined #archlinux32
[17:36:10] -!- drathir_tor has quit [Ping timeout: 260 seconds]
[17:38:28] -!- drathir_tor has joined #archlinux32
[21:28:30] <KitsuWhooa> ...why are we building tons of haskell?!
[21:38:58] <gehidore> to get gud?