#archlinux32 | Logs for 2022-10-01

Back
[00:16:21] -!- epony has quit [Ping timeout: 252 seconds]
[00:21:12] -!- epony has joined #archlinux32
[00:26:37] -!- epony has quit [Ping timeout: 252 seconds]
[00:29:53] -!- epony has joined #archlinux32
[01:36:39] -!- epony has quit [Ping timeout: 252 seconds]
[01:47:20] -!- epony has joined #archlinux32
[04:09:39] -!- drathir_tor has quit [Remote host closed the connection]
[04:20:14] -!- drathir_tor has joined #archlinux32
[05:11:44] -!- abouvier has quit [Read error: Connection reset by peer]
[05:13:19] -!- abouvier has joined #archlinux32
[06:19:46] -!- epony has quit [Quit: QUIT]
[06:43:28] -!- GNUtoo has quit [Ping timeout: 258 seconds]
[07:07:57] -!- GNUtoo has joined #archlinux32
[07:54:00] -!- GNUtoo has quit [Ping timeout: 258 seconds]
[08:08:18] -!- GNUtoo has joined #archlinux32
[09:26:46] -!- GNUtoo has quit [Ping timeout: 258 seconds]
[09:33:33] -!- GNUtoo has joined #archlinux32
[09:36:05] -!- abaumann has joined #archlinux32
[09:36:06] <buildmaster> Hi abaumann!
[09:36:06] <buildmaster> !rq abaumann
[09:36:06] <phrik> buildmaster: <abaumann> anybody thought about producing less bloat instead of trying hard to compress bloat? ;-)
[09:36:29] <abaumann> ruby packages depend all on ruby, and ruby is not found. When triggering a rebuild of ruby on the buildmaster, I get:
[09:36:32] <abaumann> ruby f02cbc60d54561c4db7f788d26fc2f81c186d9a4 b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb community
[09:36:35] <abaumann> ruby 265036afcfb45e3c8abd5642b55d0effb3449b2b b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb extra
[09:36:38] <abaumann> Neither PKGBUILD nor modification of PKGBUILD found for package "ruby" from extra (packages), revisions 265036afcfb45e3c8abd5642b55d0effb3449b2b and b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb.
[09:36:42] <abaumann> "make_source_info ruby extra 265036afcfb45e3c8abd5642b55d0effb3449b2b b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb /tmp/tmp.mysql-functions.mysql_generate_package_metadata.QCe2NjqSV6/SRCINFO" failed.
[09:36:46] <abaumann> ruby 265036afcfb45e3c8abd5642b55d0effb3449b2b b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb core
[09:36:49] <abaumann> Neither PKGBUILD nor modification of PKGBUILD found for package "ruby" from core (packages), revisions 265036afcfb45e3c8abd5642b55d0effb3449b2b and b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb.
[09:36:53] <abaumann> "make_source_info ruby core 265036afcfb45e3c8abd5642b55d0effb3449b2b b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb /tmp/tmp.mysql-functions.mysql_generate_package_metadata.di79g3Emrs/SRCINFO" failed.
[09:36:57] <abaumann> ruby 265036afcfb45e3c8abd5642b55d0effb3449b2b b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb extra
[09:37:00] <abaumann> Neither PKGBUILD nor modification of PKGBUILD found for package "ruby" from extra (packages), revisions 265036afcfb45e3c8abd5642b55d0effb3449b2b and b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb.
[09:37:04] <abaumann> "make_source_info ruby extra 265036afcfb45e3c8abd5642b55d0effb3449b2b b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb /tmp/tmp.mysql-functions.mysql_generate_package_metadata.uzBO9xLzI1/SRCINFO" failed.
[09:37:08] <abaumann> ruby f02cbc60d54561c4db7f788d26fc2f81c186d9a4 b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb community
[09:37:11] <abaumann> This doesn't look good..
[09:37:35] <abaumann> it seems to build though now..
[09:43:52] <abaumann> uh. archinstall broke completely again on the ISO and the keys are outdated..
[09:48:34] <abaumann> ah, and pacman-init.service is also failing hapilly to initialize the keyring
[09:49:33] <abaumann> I personally would do all this before building the ISO, so a new ISO has current keys, and people don't have to wait to key updates to fail. You could still provide instructions or a script to update the keys on an old ISO, when keys have changed in the meantime..
[09:50:48] <abaumann> Also there is no keyserver configured in pacman, so it just takes one (randomly?), so you get all kind of error reports by users..
[09:51:00] <abaumann> ..and you can never reproduce their problems..
[09:52:06] <abaumann> The refrsh of keyring fails, so it never gets to refreshing the archlinux32 keyring, thus the keys are not trusted.
[09:53:38] <abaumann> Mmh. I'll put a simple vi onto the ISO, not everyone likes nano.. :-)
[09:54:04] <abaumann> ah, vim is there, ok..
[09:55:19] <abaumann> ah, and archinstall later fails to refresh the keys (this has to be done again?) because archlinux32 keys are missing..
[09:56:17] <abaumann> I don't know, but no pacman-key ever works for me, they all fail in the service or manually with some broken keys.. maybe the result should be ignored?
[09:59:16] <abaumann> I start to suspect gpg to be broken on 32-bit..
[10:02:20] <abaumann> let's use a working keyserver like the one from ubuntu fix on the ISO..
[10:05:00] <abaumann> ok, archinstall bug gone. :-)
[10:32:02] -!- deep42thought has joined #archlinux32
[10:32:02] <buildmaster> Hi deep42thought!
[10:32:02] <buildmaster> !rq deep42thought
[10:32:03] <phrik> buildmaster: <deep42thought> db-update --fuck-up
[10:32:08] <deep42thought> ruby is in community now
[10:32:18] <deep42thought> I'll see, why the buildmaster looks for it in extra ...
[10:32:30] <abaumann> hi deep42thought
[10:32:35] <abaumann> ah, it got moved?
[10:32:37] <deep42thought> hi abaumann
[10:32:43] <deep42thought> I thinks so
[10:35:09] <deep42thought> $ get-package-updates -w
[10:35:09] <deep42thought> Nothing changed.
[10:35:11] <deep42thought> looks good
[10:35:32] <abaumann> ok, I force a rebuild..
[10:35:52] <abaumann> no, same errors..
[10:36:03] <abaumann> but, the last line is a:
[10:36:04] <abaumann> ruby f02cbc60d54561c4db7f788d26fc2f81c186d9a4 b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb community
[10:36:12] <abaumann> and afterwards builds are starting just fine.
[10:36:16] <deep42thought> ah, I see it: it's in the database with the wrong repository
[10:40:03] <deep42thought> only community rubys should be on the build list
[10:40:45] <abaumann> 2022-10-01 09:36:34: building package "ruby" (revisions f02cbc60d54561c4db7f788d26fc2f81c186d9a4 b3f7a95f396d2c0d1bfadcfc3344fe483f0f50fb, repository community, straw :mirrored_source:mirrored_source_by_hash:) for i486 ...
[10:40:50] <abaumann> this looks actually just fine..
[10:41:05] <deep42thought> yeah, f02cbc60d54561c4db7f788d26fc2f81c186d9a4 is the right one
[10:41:34] <deep42thought> so it was probably just some hickup during the transition from extra to community
[10:41:59] <deep42thought> because the git repositories are not synchronized with each other - e.g. there might be a time, when ruby is in both repositories or in none of them ...
[10:42:33] <abaumann> could this also explain, why staging sees for instance a new version of ruby and old versions of ruby modules?
[10:42:58] <deep42thought> staging can be broken at any time
[10:43:10] <deep42thought> this could just be, because the new ruby modules have not yet been built
[10:43:18] <deep42thought> are they on the buildlist?
[10:43:48] <abaumann> I have the suspicion, they were all on the build list and then failed building
[10:44:10] <abaumann> I'm trying to build now a low-level ruby module like ruby-hitimes, which only depends on the rybu interpreter..
[10:44:24] <deep42thought> there are plenty of ruby-* packages on the buildlist
[10:44:32] <abaumann> :: The following package cannot be upgraded due to unresolvable dependencies: ruby-rdoc
[10:44:35] <abaumann> yeah.
[10:44:43] <deep42thought> ruby-htimes is not on the buildlist
[10:44:56] <deep42thought> ruby-rdoc is neither
[10:45:05] <deep42thought> we could re-schedule all ruby-* packages
[10:45:14] <deep42thought> maybe some of them got built against the old ruby
[10:45:26] <abaumann> ah, sorry, ruby-rdoc
[10:45:34] <abaumann> ruby-docs is a subpackage of ruby
[10:46:11] <deep42thought> I'll reschedule all ruby-* packages
[10:46:17] <deep42thought> maybe this fixes something :)
[10:46:18] <abaumann> oh.
[10:46:21] <abaumann> that was not good.
[10:46:25] <deep42thought> hmm?
[10:46:26] <abaumann> they will fail
[10:46:33] * deep42thought holds his breath
[10:46:35] <abaumann> I fear, there are tons of cycles around.
[10:46:41] <deep42thought> :'-(
[10:46:42] <abaumann> otherwise, it would have worked
[10:46:45] <abaumann> well. ok.
[10:46:56] <deep42thought> so we need shims for ruby, too?
[10:47:01] <deep42thought> how does upstream update?
[10:47:15] <abaumann> that's one of the problems. I can never find documentation about that..
[10:48:42] <abaumann> That's why I see it critical to use buildbot, without any dependency management, builds will mostly fail and then you loose the history of what was built in which order upstream.
[10:49:45] <abaumann> mmh. did I bootstrap ruby on i486 or did it just magically work? :-)
[10:50:45] <deep42thought> :D
[10:50:50] <abaumann> magically..
[10:51:22] <abaumann> now, I tried to build ruby-hitimes, removed ruby-rdoc, so the only remaining dependency is ruby itself, and it says:
[10:51:29] <abaumann> :: The following package cannot be upgraded due to unresolvable dependencies: ruby
[10:51:33] <abaumann> and
[10:51:35] <abaumann> warning: cannot resolve "ruby-abbrev", a dependency of "ruby-stdlib"
[10:51:35] <abaumann> warning: cannot resolve "ruby-base64", a dependency of "ruby-stdlib"
[10:51:35] <abaumann> warning: cannot resolve "ruby-benchmark", a dependency of "ruby-stdlib"
[10:51:37] <abaumann> warning: cannot resolve "ruby-bigdecimal", a dependency of "ruby-stdlib"
[10:51:40] <abaumann> warning: cannot resolve "ruby-cgi", a dependency of "ruby-stdlib"
[10:51:42] <abaumann> warning: cannot resolve "ruby-csv", a dependency of "ruby-stdlib"
[10:51:45] <abaumann> warning: cannot resolve "ruby-delegate", a dependency of "ruby-stdlib"
[10:51:47] <abaumann> warning: cannot resolve "ruby-did_you_mean", a dependency of "ruby-stdlib"
[10:51:50] <abaumann> warning: cannot resolve "ruby-digest", a dependency of "ruby-stdlib"
[10:51:52] <abaumann> warning: cannot resolve "ruby-drb", a dependency of "ruby-stdlib"
[10:51:55] <abaumann> ...
[10:52:00] <abaumann> I don't understand how upstream rebuilt it..
[10:52:22] <deep42thought> maybe the git history has some insights into that?
[10:52:38] <abaumann> maybe, I particulalry don't like ruby-stdlib
[10:52:50] <abaumann> seems it draws in all packages which first need to be rebuilt.
[10:54:43] <deep42thought> maybe there's some self-contained ruby package, which we could use to bootstrap new versions?
[10:55:15] <abaumann> yeah, thought about just removing ruby-stdlib in ruby, it looks like a virtual package to me..
[10:55:40] <abaumann> then we should get a first version of ruby with just ruby, then build all packages required by ruby-stdlib, then build ruby again with ruby-stdlib..
[10:55:41] <deep42thought> you can add a package in build-support
[10:55:59] <abaumann> only if it has been built or if it builds..
[10:56:16] <deep42thought> let the build slaves test that :)
[10:56:19] <abaumann> or I can just build an intermediate version of ruby..
[10:56:48] <deep42thought> I would prefer a clean build-support package over an intermediate ruby version
[10:57:40] <abaumann> this works, if ruby-bootstrap has a provides ruby, so that I don't have to change tons of PKGBUILDS of python-* packages..
[10:57:52] <deep42thought> yeah, exactly
[10:57:54] <abaumann> ..build-support has precedence.
[10:57:55] <abaumann> ok.
[10:58:04] <abaumann> then we have a way.. :-)
[10:58:13] <deep42thought> provides=(ruby=$pkgver)
[10:58:27] <abaumann> I don't like the $pkgver, in general
[10:58:45] <deep42thought> it makes it break when we forget to update the build-support package
[10:58:46] <abaumann> it can cause problems between minor revisions of in theory backwards-compatible packages.
[10:58:54] <deep42thought> ok, I see
[10:59:07] <abaumann> but, then it depends on the specific package.
[10:59:20] <deep42thought> but then the packages should depend on ruby>=$major.$minor and ruby <$major.$((minor+1))
[10:59:23] <deep42thought> like with python
[10:59:29] <abaumann> I don't know if ruby 3.0.x is fairly compatible..
[10:59:38] <abaumann> or if 3.1 breaks maybe.
[10:59:54] <abaumann> or if something chages in the glibc it may even break 3.0.1 to 3.0.2 for instance.
[10:59:58] <deep42thought> with python packages you often have depends=(python>=3.10 python<3.11)
[11:00:00] <abaumann> It really depends, I think.
[11:00:07] <abaumann> python is fine
[11:00:18] <abaumann> because they are not compatible between 3.10 and 3.11
[11:00:37] <abaumann> there is no general rule..
[11:01:05] <deep42thought> what I meant to say is: the provides should be as specific as possible, the depends is who has to decide what information should be compared/checked
[11:01:17] <abaumann> right.
[11:01:30] <abaumann> I was just think aloud to myself.. ;-)
[11:01:34] <abaumann> *thinking*
[11:04:32] <abaumann> https://github.com
[11:04:51] <abaumann> yep, this is just a depedency convienence virtual pcakage
[11:04:57] <abaumann> ruby-stdlib, I meant
[11:05:41] <deep42thought> this should probably be its own PKGBUILD, then
[11:05:55] <deep42thought> I fail to see, why it's part of the ruby pkgbase
[11:06:06] <abaumann> an interesting question to upstream :-)
[11:06:53] <abaumann> asp difflog ruby shows also it's a relative new feature in the ruby PKGBUILD
[11:07:06] <deep42thought> 3 months old, yes
[11:07:22] <deep42thought> that explains, why we didn't have that trouble in the past
[11:07:28] <abaumann> exactly
[11:07:39] <abaumann> why _they_ didn't have the problem.. who knows..
[11:07:41] <deep42thought> I'll open a bug >:-)
[11:07:46] <abaumann> aeh.
[11:08:08] <deep42thought> ?
[11:08:08] <abaumann> I had some trouble lately when I was opening bugs refering to potential future issues (like quazip Qt5/Qt6)
[11:08:33] <deep42thought> trouble with moderators?
[11:08:36] <abaumann> their attitude is: the current binary (upstream) is correct, so let's close the bug and stumble upon themselves when they hit it.
[11:08:47] <abaumann> no, I think the problem is: there are bugs and bugs.
[11:08:53] <deep42thought> :)
[11:09:00] <abaumann> bugs for future problems or potential issues are nothing for the public.,
[11:09:12] <deep42thought> I'll just try it
[11:09:13] <abaumann> it's just confusing, because technically it's not a bug.
[11:09:31] <abaumann> I started to fix it downstream locally, they can have a look at our bug reporting,
[11:09:35] <abaumann> when they hit the bug :-)
[11:10:12] <abaumann> bootstrapping issues I also removed completely for instance from the AUR..
[11:10:26] <abaumann> ..it affects only very few people and all others get confused :-)
[11:10:44] <deep42thought> !bug 75765
[11:10:44] <phrik> https://bugs.archlinux.org
[11:10:54] <deep42thought> this goes in the same direction
[11:11:50] <abaumann> Wasn't that what groups have been invented for?
[11:12:01] <deep42thought> groups?
[11:12:14] <abaumann> you don't have a depends shim package for 'mate' for instance
[11:12:20] <abaumann> you install the _group_ 'mate'
[11:12:25] <deep42thought> ah, yes
[11:12:30] <abaumann> so there could also be a group _ruby-stdlib_
[11:12:36] <deep42thought> but you won't pick up new packages, when the group gets expanded
[11:12:47] <abaumann> ah, that's a good point.
[11:12:48] <abaumann> mmh.
[11:13:07] <deep42thought> this is especially bad, if they're rather "hard" dependencies than some collection of packages (like for desktop environments)
[11:14:27] <abaumann> yeah, and a shim package just works when new packages are added..
[11:14:38] <abaumann> ..and even if they are removed.
[11:14:49] <deep42thought> I wouldn't call it a shim package, it's rather a virtual package
[11:15:37] -!- T`aZ has quit [Ping timeout: 252 seconds]
[11:16:12] <abaumann> aeh. yes. shim acts up as the real package..
[11:16:15] <abaumann> true
[11:16:38] <deep42thought> yeah, or they provide the diff between the old and new version of some real package
[11:17:33] -!- T`aZ has joined #archlinux32
[11:18:16] <deep42thought> thinking about it, I won't open a bug upstream, because splitting this into multiple PKGBUILDs won't solve the cycles, because ruby depends on ruby-stdlib and ruby-bundledgems
[11:22:23] <deep42thought> ah, damn
[11:22:47] <deep42thought> I think, our latest run of delete-packages might have prematurely deleted some ruby-* packages, that got *moved* from extra to community
[11:23:42] <abaumann> so we have more motivation to fix ruby now. ;-)
[11:25:37] <deep42thought> ls: cannot access 'mirror.archlinux32.org/*/*/ruby-abbrev-*': No such file or directory
[11:25:41] <deep42thought> yep \o/
[11:26:46] <deep42thought> ah, I see
[11:27:00] <deep42thought> the *new* ruby depends on ruby-stdlib, which depends on stuff like ruby-abbrev
[11:27:05] <deep42thought> but ruby-abbrev is not yet built
[11:27:15] <abaumann> so, nothing got deleted.
[11:27:17] <deep42thought> so we need the *old* ruby, which did not yet depend on that stuff
[11:27:39] <deep42thought> so maybe just put some older ruby PKGBUILD into build-support?
[11:27:57] <abaumann> and just increase the build version or pkgver, yeah, might work
[11:27:58] <deep42thought> or a installable ruby from the package archive ...
[11:28:14] <deep42thought> no need to fiddle with the pkgver
[11:28:32] <deep42thought> the with-build-support straw will use the build-support version no matter what pkgver it has
[11:28:36] <abaumann> ah, it might also draw in new stuff we don't want (like new packages in standard ruby)
[11:29:13] <deep42thought> we need some ruby, that can be installed
[11:29:23] <deep42thought> and my suspicion is, that an older ruby will do just fine
[11:29:37] <deep42thought> then we can use that to build all the ruby-* packages needed for ruby-stdlib
[11:29:37] <abaumann> yeah, for instance the one in stable..
[11:29:41] <deep42thought> and then we can build the new ruby
[11:29:49] <deep42thought> the one in stable works?
[11:29:52] <abaumann> sounds also good.
[11:29:57] <deep42thought> then we can just copy that to build-support
[11:30:03] <abaumann> at least I could install things like asciidoctor on stable..
[11:30:12] <deep42thought> well, that's enough
[11:31:53] <deep42thought> copying ruby to build-support now
[11:32:33] <deep42thought> "Depends On : gdbm openssl libffi libyaml gmp zlib rubygems ruby-irb"
[11:32:42] <deep42thought> yeah, it does not depend on ruby-stdlibs :)
[11:33:01] <deep42thought> let's see, if things around ruby magically unbreak themself :D
[11:39:07] <abaumann> I like magic, especially if it involves rubies..
[11:46:59] -!- T`aZ has quit [Ping timeout: 248 seconds]
[11:49:55] -!- T`aZ has joined #archlinux32
[11:54:46] -!- T`aZ has quit [Ping timeout: 246 seconds]
[11:56:54] -!- T`aZ has joined #archlinux32
[12:01:49] -!- T`aZ has quit [Ping timeout: 252 seconds]
[12:03:53] -!- T`aZ has joined #archlinux32
[12:12:03] -!- T`aZ has quit [Ping timeout: 248 seconds]
[12:13:53] -!- T`aZ has joined #archlinux32
[12:30:46] -!- epony has joined #archlinux32
[15:18:50] -!- deep42thought has quit [Quit: Leaving.]
[15:21:14] -!- drathir_tor has quit [Remote host closed the connection]
[15:31:49] -!- drathir_tor has joined #archlinux32
[15:47:25] -!- drathir_tor has quit [Ping timeout: 258 seconds]
[15:54:17] -!- drathir_tor has joined #archlinux32
[16:11:52] -!- GNUtoo has quit [Remote host closed the connection]
[16:32:06] -!- GNUtoo has joined #archlinux32
[17:05:39] -!- drathir_tor has quit [Remote host closed the connection]
[17:30:59] -!- T`aZ has quit [Ping timeout: 248 seconds]
[17:33:00] -!- T`aZ has joined #archlinux32
[18:26:12] -!- drathir_tor has joined #archlinux32
[18:56:34] -!- abaumann has quit [Quit: leaving]
[19:22:12] -!- drathir_tor has quit [Remote host closed the connection]
[19:42:51] -!- drathir_tor has joined #archlinux32
[20:54:39] -!- buildmaster has quit [Remote host closed the connection]
[20:56:39] -!- titus_livius has joined #archlinux32
[20:59:02] -!- buildmaster has joined #archlinux32
[21:13:08] -!- abaumann has joined #archlinux32
[21:13:08] <buildmaster> Hi abaumann!
[21:13:08] <buildmaster> !rq abaumann
[21:13:09] <phrik> buildmaster: <abaumann> wasn't I saying something lately about setarch being broken? ;-)
[21:13:50] <abaumann> ISO 2022-10-01 is out, it has a botched archinstall. Only trouble ATM is that you have to wait for pacman-init.service to finish, then the pacman keys are correct for sure..
[21:14:11] <abaumann> There is a crutch when calling 'archinstall' updating also the Arch32 keyring.
[21:14:30] <abaumann> Still, most graphical things don't really install right away from the ISO..
[21:14:46] <abaumann> ..xorg-server minimal with twm, or a mate might work..
[21:14:54] <abaumann> (with archinstall, I mean).
[21:17:50] <abaumann> The 486 ISO is sadly bigger than a CD, not quite sure, how I can shrink it..
[21:20:12] -!- abaumann has quit [Quit: leaving]
[21:39:05] <bill-auger> arch past that point of no return a while back - the arch kernel alone is nearly 200MB now
[21:40:47] <bill-auger> parabola's kernel is only 100MB and the last ISO i made in april was 620 MB - its only a matter of time
[22:07:40] -!- drathir_tor has quit [Remote host closed the connection]
[22:18:10] -!- drathir_tor has joined #archlinux32
[22:50:38] -!- CalimeroTeknik has quit [Quit: バイバイ]
[22:52:59] -!- CalimeroTeknik has joined #archlinux32
[23:40:44] -!- CalimeroTeknik has quit [Quit: バイバイ]
[23:47:31] -!- GNUtoo has quit [Remote host closed the connection]
[23:47:54] -!- CalimeroTeknik has joined #archlinux32